Hairpin NAT: VPN oxirgi nuqtasi nega ichkaridan ishlamaydi

Mobil tarmoqdan javob beradigan, lekin divandan ishlamaydigan VPN server odatda sertifikat muammosi emas. LAN ichidagi mijoz routerdan manzili routerning o‘z ommaviy manzili bo‘lgan paketni o‘girishni so‘raydi, ya’ni paket tashqariga chiqib, darhol qaytishi kerak. Bu manevr hairpinning deb ataladi va ko‘p routerlar uni yo umuman joriy qilmaydi, yo faqat belgilash katakchasi yoqilganda bajaradi. Tashqi testning o‘tishi chalkashtiradi, chunki u tinglovchi va yo‘naltirish qoidasi joyida ekanini isbotlaydi.

Paket tashqariga chiqadi va qaytadi

Paketni kuzatib boring. Mijoz ommaviy nomni hal qiladi, ommaviy manzilga ulanadi va routerning manzil NAT’i manzilni ichki serverga qayta yozadi. Serverning javobi mijozning LAN manziliga yo‘naltirilgan, shuning uchun u manbani qaytarib o‘girishi mumkin bo‘lgan NAT qoidasidan hech o‘tmasdan routerning LAN interfeysi orqali qaytadi.

Endi mijoz hech qachon hech narsa yubormagan manzildan paket oladi va uni tashlab yuboradi. Ana shu asimmetriya butun nosozlikdir.

RFC 4787 bu holatda NAT’dan kutiladigan xatti-harakatni tavsiflaydi va qisqa versiyasi shuki, nazariyada belgilangan joyda ham amalda bu ixtiyoriy. Ba’zi routerlar bu sozlamani NAT loopback deb ataydi, boshqalari hairpin NAT yoki NAT reflection deydi, yana ba’zilari umuman hech narsa ko‘rsatmaydi. Bunday funksiyasi yo‘q router noto‘g‘ri sozlangan emas; u odatdagi ishni qilmoqda va tuzatish boshqa joyga tegishli. Mahalliy test muvaffaqiyatsiz bo‘ldi deb ommaviy yo‘naltirish qoidasi noto‘g‘ri degan xulosaga kelmang.

Tekshiruv 1: ikki yo‘lni alohida sinab ko‘ring

LAN tashqarisidan haqiqiy foydalanuvchi ishlatadigan bir xil profil bilan ulanib, sessiya o‘rnatilishini tasdiqlang. Ichkaridan o‘sha profil bilan ommaviy manzilga ulanib, aniq xatoni va vaqtni yozib oling.

Aniq mahalliy test xost nomini saqlab qoladi va faqat manzilni almashtiradi: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ so‘rovni ommaviy manzilga yuboradi, shu bilan birga to‘g‘ri server nomini taqdim etadi. Bu nomni hal qilish muammosini o‘girish muammosidan ajratadi, va ular bir xil nom kafedan ishlaganda oson chalkashadi. Mijoz TCP ulanishida yoki keyinroq TLS’da muvaffaqiyatsiz bo‘ladimi, buni belgilang, chunki birinchisi o‘girishga, ikkinchisi shaxsga ishora qiladi.

Tekshiruv 2: server nima ko‘rishini o‘qing

Eng foydali kuzatuv serverning nuqtai nazaridir. VPN xostda mijozning LAN manzili va routerning LAN manziliga filtrlab yozib olishni ishga tushiring, so‘ng mahalliy urinishni takrorlang. Hech narsa kelmasa, paket o‘girishdan omon qolmagan.

Agar ulanish mijozning manzilidan emas, routerning LAN manzilidan kelsa, hairpinning sodir bo‘lmoqda va manba qayta yozilgan. Bu ishlaydigan konfiguratsiya, nosozlik emas.

Tekshiruv 3: tashqi yo‘lga tegmasdan tuzating

Uchta qo‘llab-quvvatlanadigan shakl bor, ta’sir radiusi ortib borishi tartibida. Eng tori — bo‘lingan DNS: ichki yozuvni e’lon qiling, shunda o‘sha server nomi LAN’dagi mijozlar uchun ichki manzilga hal qilinadi, bu esa ommaviy yo‘lni butunlay chetlab o‘tadi. Keyingisi — routerning hujjatlashtirilgan loopback yoki reflection parametrini yoqish, agar mavjud bo‘lsa, va uni faqat shu xizmatga qo‘llash. Eng kengi — routerdagi source-NAT qoidasi bo‘lib, u LAN’dan kelgan trafikni serverga qayta yozadi, shunda javob router orqali qaytadi; Linux routerda bu serverning manzili va portiga mos keladigan MASQUERADE qoidasi POSTROUTING bo‘ladi. Uchtasi ham tashqi yo‘lni tegilmagan holda qoldiradi va saqlanishi kerak bo‘lgan xususiyat shu.

Mahalliy yo‘lni tashqi yo‘lga o‘xshatish uchun aloqasiz port yo‘naltirishni kengaytirmang va muammodan qochish uchun xizmatni boshqa portga ko‘chirmang. Ikkala o‘zgarish ham faqat ichki dunyo ko‘radigan narsani tuzatish uchun tashqi dunyo yetib boradigan narsani o‘zgartiradi.

Bo‘lingan DNS’ning aytib o‘tishga arziydigan bitta tuzog‘i bor. Xost nomini ixtiyoriy IP bilan almashtirish mijoz nimani tekshirishini o‘zgartiradi, shuning uchun ichki yozuv baribir sertifikatdagi nomga mos kelishi kerak.

Tekshiruv 4: keyin ikkala yo‘lni tekshiring

Tashqi urinishni LAN tashqarisidan takrorlang, ichki urinishni o‘sha profil bilan takrorlang va server jurnali bitta muvaffaqiyat va bitta sukunat emas, ikki alohida muvaffaqiyatli sessiyani ko‘rsatishini tasdiqlang. So‘ng boshqa mijozlar hali ham tinglovchiga yetib borishini va shaxsiy resurslarga yo‘llar o‘zgarmaganini tekshiring.

Yozuvni qisqa saqlang: qaysi mijoz qaysi manzildan foydalandi, server nima ko‘rdi va uchta tuzatishdan qaysi biri qo‘llanildi. RFC 4787’dagi hairpinning talablari bu yerda NAT’dan nima kutilishiga oid ma’lumotnoma va bu xususiyatsiz router nima uchun odatdagidek ishlashini tushuntiradi. Tashqi dunyo takrorlay olmaydigan mahalliy nosozlik aksi isbotlanmaguncha o‘girish masalasidir, shuning uchun uni shunday sinab ko‘ring.