NAT VPN serveringiz aslida qaysi manba manzilini ko‘rishini belgilaydi
Noutbukingiz manzili VPN serveriga hech qachon yetib bormaydi. NAT uni oxirgi sakrashda qayta yozadi va tunnel IP manzili keyinroq beriladi. Ikki uchni qanday solishtirish kerak.
Siz VPN serveri noutbukingiz manzilini paketdan o‘qib, jurnalga yozadi deb tasavvur qilasiz. U o‘qiydigan narsa oxirgi NAT sakrashi tashqi sarlavhaga qo‘ygan manzil, hotspot sifatida ishlatiladigan telefonda esa bu ko‘pincha yuzlab boshqa abonentlar bilan bo‘lishilgan manzil bo‘ladi. Mashinangizning o‘z 192.168.x.x manzili bu sarlavhada hech qachon internetdan o‘tmaydi, tunnel manzilini esa server aloqa allaqachon o‘rnatilgandan keyin beradi. Shuning uchun server jurnali va noutbukdagi ip addr mos kelmasa, ikkalasi ham xato emas; ular bitta sessiyaning turli qatlamlarini tavsiflaydi.
Uch manzil, jurnalda esa faqat bittasi
Chalkashlik uch manzilni bittaga jamlashdan kelib chiqadi. Har birining egasi boshqa, u boshqa sarlavhada yashaydi va serverga boshqa yo‘l bilan yetib boradi.
| Address | Who assigns it | Where it sits | Visible to the VPN server |
|---|---|---|---|
Device address, e.g. 192.168.1.24 | Your router via DHCP | Outer header, before translation | No, rewritten in place |
| Translated address and port | Router, ISP CGNAT, or both | Outer header, after translation | Yes, this is the tuple it logs |
Tunnel address, e.g. 10.8.0.6 | The VPN server itself | Inner header, after decapsulation | Yes, but it chose it |
Ulanish paytida faqat o‘rta qator noma’lum. Server uni demon turiga qarab sheriklar jadvaliga, holat fayliga yoki oqim jurnaliga yozadi: WireGuard uni oxirgi nuqta deb ataydi, OpenVPN holat fayli uni Real Address deb belgilaydi, strongSwan esa uni IKE_SA ning uzoq hosti sifatida bildiradi. Bu qiymat boshqa manbadan paket kelganda yangilanadi, shuning uchun hech kim hech narsani qayta ishga tushirmasdan o‘zgaradi.
Pastki qator — odamlar xato bilan shaxsiyat da’vosi deb o‘qiydigan narsa. U server konfiguratsiyasidagi o‘rinni belgilaydi, shaxsni emas, chunki server uni o‘z hovuzidan tanlagan. Ikki foydalanuvchi turli kunlarda bir xil tunnel manzilini olishi mumkin, bittasi esa ikki qurilmadan ikkitasini ushlab turishi mumkin.
Tunnel ishlab turganda jurnalga yozilgan kortej nima uchun o‘zgaradi
Manzillarni tarjima qilish taymerli jadval, doimiy bog‘lanish emas. Uy routeri oxirgi paketdan keyin UDP xaritasini biroz vaqt saqlaydi, operator shlyuzi portlarni o‘z jadvali bo‘yicha qayta ishlatadi, Wi-Fi dan LTE ga o‘tgan telefon esa butunlay boshqa manba bilan qaytadi. Bu yerda Linux conntrack standart qiymatlari foydali mezon: nf_conntrack_udp_timeout 30 soniya, oqim varianti esa 120, shuning uchun jim tunnel xaritani foydalanuvchi sezishidan ancha oldin yo‘qotishi mumkin.
Tunnel tirik qoladi, chunki protokol manzilni emas, sherikni autentifikatsiya qiladi. WireGuard qo‘l berib ko‘rishishdan keyin holatsiz, shuning uchun har qanday autentifikatsiya qilingan paket saqlangan oxirgi nuqtani yangilaydi va qayta bog‘lanish keyingi paketda tuzaladi; persistent-keepalive = 25 aynan shu uchun bor — bo‘sh turganda xaritani issiq ushlab turish uchun. OpenVPN ning --float parametri ham xuddi shu ishni qiladi va autentifikatsiya qilingan klientga yangi manzil va portdan davom etishga ruxsat beradi. float standart bo‘yicha o‘chirilgan 2.4 va 2.5 buildlarida qayta bog‘lanish sessiyani qayta tiklaydi va klient qaytadan ulanadi.
IPsec u yerga ko‘proq harakatlanuvchi qismlar bilan yetib boradi. IKEv2 NAT aniqlash yuklamalaridagi manba va manzil xeshlarini solishtirib tarjimani sezadi, UDP 4500 inkapsulyatsiyasiga o‘tadi va keepalive larni yangi kortejgacha kuzatadi. keepalive lar bloklanganda SA qog‘ozda ishlab turadi, bir yo‘nalishdagi trafik esa jimgina to‘xtaydi.
Server nimani bog‘lay oladi, nimani olmaydi
O‘ldirishga arziydigan afsona — tarjima sizni operatordan yashiradi degani. U yorliqni o‘zgartiradi, kuzatuvni emas. Operator NAT i orqasidagi shlyuz 100.64.0.0/10 maydonini yoki ko‘p abonent bo‘lishadigan bitta ommaviy manzilni ko‘radi va oqimni baribir sertifikat sub’ektiga, WireGuard ommaviy kalitiga, berilgan tunnel manziliga, bayt hisoblagichlariga va vaqt oynasiga bog‘lay oladi. Ularning hech biriga sizning LAN manzilingiz kerak emas.
Chegaralar teskari yo‘nalishda ham ishlaydi. Jurnaldagi umumiy manzil uyga emas, shlyuzga ishora qiladi; bir tarjima qilingan manzildan turli portlardagi ikki sessiya turli qurilmalar; port qayta ishlatilgan bo‘lsa, ikki turli kundagi bir xil manzil ikki bog‘lanmagan abonent bo‘lishi mumkin. Faqat sherik kalitlarini yozadigan server hisob ma’lumotlar bazasisiz ularni mijozga bog‘lay olmaydi, faqat manzillarni yozadigan server esa bir router orqasidagi noutbukni telefondan ajrata olmaydi.
Taxmin qilish o‘rniga ikki uchni solishtiring
Nima bo‘lganini aniqlash uchun bir xil aloqani ikki uchda bir vaqtda ushlang va manzilni emas, kortejni solishtiring. Klientda, har qanday tarjimadan oldin:
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpointsKeyin router yoki CGNAT shlyuzidagi tarjima yozuvini va serverga oxir-oqibat nima yetib borishini o‘qing:
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820Muvofiqsizliklarning ko‘pini uch naqsh tushuntiradi. Serverdagi manba porti mahalliy portdan farq qilsa, manzil esa mos kelsa: oddiy port tarjimasi. Serverdagi manba manzili sizga tegishli bo‘lmagan ISP blokiga mansub bo‘lsa: kamida bitta qo‘shimcha NAT qatlami. Paketlar bo‘sh turgandan keyin to‘xtab, yangi port bilan davom etsa: xarita muddati tugagan, marshrutlash nosozligi emas. Vaqt belgilari bir-ikki soniyadan ko‘proq farq qilsa, siz ikki turli urinishni solishtiryapsiz.
Farq qayerda narsalarni buzadi
Server nosozligidek ko‘rinadigan uzilishlar odatda shu yerdan boshlanadi. Uy manzilingizga bog‘langan kirish qoidasi ISP ijara muddati o‘zgargandan keyin ishlamay qoladi. Tarjima qilingan manzilga mos keladigan fail2ban qoidasi o‘sha shlyuz orqasidagi barcha abonentlarni birdan bloklaydi. Ruxsat etilgan uzoq manzilli sayt-sayt sherigi mobil aloqa o‘zgargandan keyin kalitlarni yangilashni to‘xtatadi. Tunnel protokoli joyida edi; tashqi kortej haqidagi taxmin unday emas edi.
Ayni chalkashlik server tomonida ham ko‘rinadi. Agar VPN qutisi o‘zi NAT orqasida bo‘lsa, port yo‘naltirish va ishlaydigan yo‘naltirish yo‘li kerak; strongSwan yo‘naltirish qo‘llanmasi IPsec uchun shu holatni qamrab oladi. Faqat shaxsiy manzilda yetib boriladigan server o‘z klientlari taqdim etadigan tarjima qilingan kortejni hech qachon ko‘rmaydi, va bu klientlarning tarjima qilinishidan boshqa muammo.
Ushbu to‘rtta tekshiruvni tartib bilan bajaring va birinchi muvaffaqiyatsizlikda to‘xtang:
- Ikki uchda bir vaqtda ushlang; manba porti, manzil porti va vaqt belgilari mos kelishini tasdiqlang.
- Kutgan manzilni emas, server hozir ushlab turgan manzilni sheriklar ro‘yxatidan o‘qing.
- Yozuv va uning qolgan umri uchun conntrack yoki NAT jadvalini tekshiring.
- Klientdagi tunnel interfeysi manzili LAN manziliga emas, server bergan manzilga mos kelishini tasdiqlang.
Agar ikkala ushlash ham kortejda kelishsa-yu, tunnel baribir ishlamasa, tarjima sizning muammoingiz emas; qo‘l berib ko‘rishish va tunnel ichidagi marshrutlash jadvaliga o‘ting.