Azure P2S VPN qaytish trafigi faqat bir yo‘nalishda ishlaydi

Tunnel belgisi yashil, NSG ruxsat berayotgandek ko‘rinadi, samarali marshrutlar to‘g‘ri ko‘rinadi, va shunga qaramay VM ulangan mijozga qaytib aloqa ocha olmaydi. Odatiy taxmin — ishlaydigan point-to-site tunnel simmetrik: mijoz VM ga yetib borsa, VM ham mijozga yetib boradi. Bu taxmin mulohazadagi xato, konfiguratsiyadagi emas. Tunnel so‘ralmagan oqimning bir yo‘nalishini olib o‘tib, ikkinchisini tashlab yuborishi mumkin, va tuzatish uni qaysi qatlam tashlab yuborayotganiga bog‘liq.

Afsona: ulangan tunnel ikki tomonlama tunnel

VPN tunnel — sim emas, siyosat yo‘li. Har bir yo‘nalish selektorlar, marshrutlar va filtrlar bilan solishtiriladi, va ularning har biri bir yo‘nalishga ruxsat berib, ikkinchisini to‘sishi mumkin.

Amalda assimetriya shunchalik keng tarqalganki, yo‘nalish oxirgi emas, birinchi sinovda bo‘lishi kerak. Mijoz boshlaydi, shlyuz oqimni kuzatadi, javob esa yaratilgan holatga ergashadi. Yangi oqim boshlagan VM da bunday holat yo‘q, shuning uchun qaytish yo‘li ochiq marshrutlanadigan va ruxsat etilgan bo‘lishiga bog‘liq. O‘sha yo‘l bo‘lmasa, ulanish urinishi uni hech qanday dastur ko‘rmasidan oldin o‘ladi.

Yetib borishni sinashdan oldin yo‘nalishni sinang

Bitta mijoz manzili, bitta VM manzili va bitta protokol tanlang. Mijozdan ulanib natijani yozib oling; so‘ng xuddi shu sinovni VM dan boshlab, uni ham yozib oling. Birinchisi muvaffaqiyatli, ikkinchisi muvaffaqiyatsiz bo‘lsa, mijozlar puli, shlyuz bog‘lanishi va mijozdan VNet gacha yo‘l ishlayapti.

Keyingi qadam — dalil, ko‘proq qoida emas. VM quyi tarmog‘idagi NSG ni ikki yo‘nalishda tekshiring, VM NIC dagi samarali marshrutlarni o‘qing va mijoz trafik yuborayotganda VM da paketlarni ushlang. Javobsiz kelgan so‘rov filtr yoki qaytish marshruti muammosi; umuman kelmaydigan so‘rov yo‘l muammosi. Muvaffaqiyatsiz ping ni VM yetib bo‘lmaydi degan dalil deb hisoblamang, chunki TCP ishlayotganda ICMP siyosati javobni tashlab yuborishi mumkin.

IKEv2 point-to-site qaytish yo‘li odatiy gumondor

Ushbu maqola asosidagi Azure hisobotida mijoz IKEv2 orqali VM larga yetib borgan, lekin VM dan mijozga kiruvchi ICMP shlyuz tunnel turi OpenVPN ga o‘zgartirilmaguncha muvaffaqiyatsiz bo‘lgan. Hisobot muallifi Microsoft IKEv2 point-to-site yo‘lida cheklovni tasdiqlaganini aytadi: agar sessiyani mijoz boshlamagan bo‘lsa, VM dan mijozga qaytish trafigi simmetrik marshrutlanmaydi. IKEv2 trafik selektorlariga tayanadi, shlyuz esa bu holatda qaytish yo‘nalishini hisobga olmadi.

Bu OpenVPN ni umuman yaxshiroq tunnel turiga aylantirmaydi. Bu tunnel turini ushbu ish yuklamasi uchun sinov matritsasida o‘zgaruvchiga aylantiradi.

Tunnel turini almashtirish — xizmat o‘zgarishi, kalit emas. Har bir mijozga mos profil kerak, shlyuzga esa boshqa sertifikat yoki autentifikatsiya sozlamasi kerak bo‘lishi mumkin. Bir tomonlama xatti-harakatni bitta sinov mijozi va bitta sinov VM bilan qayta hosil qiling, turni tasdiqlangan jadval bo‘yicha o‘zgartiring, so‘ng o‘sha yo‘nalish sinovlarini takrorlang. Xatti-harakat almashtirishdan keyin ham saqlanib qolsa, tunnel turi sabab emas edi va ishlab chiqarishga tegmasdan muammoni toraytirdingiz.

Afsona: broadcast orqali aniqlash VNet chegarasidan o‘tadi

Ikkinchi taxmin aloqasiz sabab bilan buziladi. Azure virtual tarmog‘i broadcast trafigini o‘tkazmaydi, shuning uchun VM site-to-site yoki point-to-site ulanishi orqali mahalliy tarmoqdan broadcast kadrlarini ololmaydi. Broadcast orqali sheriklarini topadigan dasturlar, masalan eski fayl ko‘rish yoki ba’zi qurilma aniqlash protokollari, marshrutlar qanday yozilishidan qat’i nazar, uzoq tomonni hech qachon ko‘rmaydi.

Broadcast orqali aniqlashni DNS nomlari, katalog xizmati yoki aniq sheriklar ro‘yxati bilan almashtiring. Agar dasturda unicast muqobili bo‘lmasa, dizaynga kengroq tunnel emas, boshqa aniqlash mexanizmi kerak.

Nimani o‘zgartirish kerak va buni qanday isbotlash mumkin

Agar yo‘nalish sinovi faqat IKEv2 da muvaffaqiyatsiz bo‘lsa, shlyuz tunnel turini, mijoz manzillari pulini va aniq ICMP yoki TCP sinovini yozib oling, so‘ng zararlangan mijozlar uchun tasdiqlangan OpenVPN profilini baholang. Agar u har qanday tunnel turida muvaffaqiyatsiz bo‘lsa, qaytish yo‘li ustida ishlang: mijoz manzili VM quyi tarmog‘idan marshrutlanadigan bo‘lishi kerak, foydalanuvchi belgilagan har qanday marshrut haqiqiy keyingi sakrashga ishora qilishi kerak, va mijoz firewalli kiruvchi oqimni qabul qilishi kerak. NSG va marshrut dalillarini bileta bilan biriktiring.

ping bilan emas, dastur bilan tekshiring. O‘zgarishdan keyingi muvaffaqiyatli ICMP almashinuvi xizmat porti, uning autentifikatsiyasi yoki nom hal qilinishi haqida hech narsa demaydi. Qayta ulangandan keyin sinovni takrorlang, chunki puldan boshqa manzil olgan mijoz natijani o‘zgartirishi mumkin. So‘ng mijoz uxlab uyg‘ongandan keyin yana bir marta takrorlang, chunki aynan davom ettirilgan sessiyada bir tomonlama xatti-harakat ko‘pincha yana namoyon bo‘ladi.