NAT VPN serverinizin hansı mənbə ünvanını həqiqətən gördüyünü müəyyən edir
Noutbukunuzun ünvanı heç vaxt VPN serverinə çatmır. NAT onu son atlamada yenidən yazır, tunel IP-si isə sonra təyin edilir. Hər iki tərəfi necə müqayisə etmək olar.
Siz VPN serverinin noutbukunuzun ünvanını paketdən oxuyub jurnala yazdığını təsəvvür edirsiniz. Oxuduğu şey son NAT atlamasının xarici başlığa qoyduğu ünvandır və modem kimi istifadə olunan telefonda bu, çox vaxt yüzlərlə digər abunəçi ilə paylaşılan ünvan olur. Cihazınızın öz 192.168.x.x ünvanı heç vaxt həmin başlıqda interneti keçmir və tunel ünvanı server tərəfindən bağlantı artıq qurulduqdan sonra verilir. Ona görə də server jurnalı ilə noutbukdakı ip addr bir-birindən fərqlənəndə heç biri səhv deyil; onlar bir sessiyanın müxtəlif qatlarını təsvir edir.
Üç ünvan və onlardan yalnız biri jurnalda
Qarışıqlıq üç ünvanın birinə yığılmasından gəlir. Hər birinin sahibi fərqlidir, fərqli başlıqda yaşayır və serverə fərqli yolla çatır.
| 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 |
Qoşulma anında yalnız orta sətir məlum deyil. Server onu demonundan asılı olaraq həmkar cədvəlinə, status faylına və ya axın jurnalına yazır: WireGuard onu son nöqtə adlandırır, OpenVPN status faylı onu Real Address kimi işarələyir, strongSwan isə onu IKE_SA-nın uzaq hostu kimi bildirir. Bu dəyər fərqli mənbədən paket gələndə yenilənir, yəni heç kim heç nəyi yenidən başlatmadan dəyişir.
Alt sətir insanların səhvən şəxsiyyət iddiası kimi oxuduğu şeydir. O, server konfiqurasiyasında bir yeri işarələyir, şəxsi deyil, çünki server onu öz hovuzundan seçib. İki istifadəçi müxtəlif günlərdə eyni tunel ünvanını ala bilər və biri iki cihazdan iki belə ünvan saxlaya bilər.
Tunel işlək qaldığı halda jurnaldakı dəst niyə dəyişir
Ünvan tərcüməsi taymeri olan cədvəldir, daimi bağlama deyil. Ev marşrutlaşdırıcısı son paketdən sonra UDP uyğunlaşdırmasını bir müddət saxlayır, operator şlüzü portları öz cədvəlinə uyğun təkrar istifadə edir və Wi-Fi-dən LTE-yə keçən telefon tamamilə fərqli mənbə ilə qayıdır. Linux conntrack standart dəyərləri burada faydalı ölçüdür: nf_conntrack_udp_timeout 30 saniyədir, axın variantı isə 120-dir, yəni sakit tunel istifadəçi hiss etməzdən çox əvvəl uyğunlaşdırmasını itirə bilər.
Tunel ona görə yaşayır ki, protokol ünvanı deyil, həmkarı doğrulayır. WireGuard əl sıxmadan sonra vəziyyətsizdir, ona görə doğrulanmış istənilən paket saxlanan son nöqtəni yeniləyir və yenidən bağlama növbəti paketdə sağalır; persistent-keepalive = 25 məhz buna görə var, boşdayanma zamanı uyğunlaşdırmanı isti saxlamaq üçün. OpenVPN-in --float parametri eyni işi görür və doğrulanmış müştəriyə yeni ünvan və portdan davam etməyə imkan verir. float-un standart olaraq söndürüldüyü 2.4 və 2.5 buraxılışlarında yenidən bağlama sessiyanı sıfırlayır və müştəri yenidən qoşulur.
IPsec ora daha çox hərəkətli hissə ilə çatır. IKEv2 NAT aşkarlama yüklərində mənbə və təyinat heşlərini müqayisə edərək tərcüməni görür, UDP 4500 enkapsulyasiyasına keçir və keepalive mesajlarını yeni dəstəyə qədər izləyir. Keepalive mesajları bloklananda SA kağız üzərində qalır, bir istiqamətdə trafik isə səssizcə dayanır.
Server nəyi aid edə bilər, nəyi bilməz
Öldürməyə dəyər mif tərcümənin sizi operatordan gizlətməsidir. O, etiketi dəyişir, müşahidəni deyil. Operator NAT-ının arxasındakı şlüz 100.64.0.0/10 fəzasını və ya çoxsaylı abunəçinin paylaşdığı bir açıq ünvanı görür və yenə də axını sertifikat subyektinə, WireGuard açıq açarına, təyin edilmiş tunel ünvanına, bayt sayğaclarına və zaman pəncərəsinə bağlaya bilir. Bunların heç biri sizin LAN ünvanınıza ehtiyac duymur.
Məhdudiyyətlər də əks istiqamətdə işləyir. Jurnaldakı paylaşılan ünvan evə deyil, şlüzə işarə edir; eyni tərcümə edilmiş ünvandan fərqli portlarla gələn iki sessiya fərqli cihazlardır; port təkrar istifadə olunubsa, eyni ünvan iki fərqli gündə əlaqəsiz iki abunəçi ola bilər. Yalnız həmkar açarlarını qeyd edən server hesab verilənlər bazası olmadan onları müştəriyə bağlaya bilməz, yalnız ünvanları qeyd edən server isə eyni marşrutlaşdırıcının arxasındakı noutbuku telefondan ayıra bilməz.
Təxmin etmək əvəzinə hər iki tərəfi müqayisə edin
Nə baş verdiyini aydınlaşdırmaq üçün eyni bağlantını hər iki tərəfdə eyni anda tutun və ünvanı deyil, dəsti müqayisə edin. Müştəri tərəfində, hər hansı tərcümədən əvvəl:
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints
Sonra marşrutlaşdırıcıdakı və ya CGNAT şlüzündəki tərcümə qeydini və serverə nəhayət nə çatdığını oxuyun:
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820
Uyğunsuzluqların çoxunu üç nümunə izah edir. Server mənbə portu yerli portdan fərqlənir, təyinat isə uyğun gəlir: adi port tərcüməsi. Server mənbə ünvanı sizə aid olmayan ISP blokuna aiddir: ən azı bir əlavə NAT qatı. Paketlər boşdayanmadan sonra dayanır və yeni portla davam edir: uyğunlaşdırmanın müddəti bitib, marşrut xətası deyil. Zaman nişanları bir-iki saniyədən çox fərqlənirsə, iki fərqli cəhdi müqayisə edirsiniz.
Fərq harada problem yaradır
Server xətası kimi görünən kəsintilər adətən burada başlayır. Ev ünvanınıza bərkidilmiş giriş qaydası ISP icarəsi dəyişdikdən sonra uğursuz olur. Tərcümə edilmiş ünvana uyğun gələn fail2ban qaydası həmin şlüzün arxasındakı bütün abunəçiləri birdən bloklayır. Sabit uzaq ünvanlı sayt-sayt həmkarı mobil xətt dəyişdikdən sonra açarları yeniləməyi dayandırır. Tunel protokolu qaydasında idi; xarici dəstlə bağlı fərziyyə isə deyildi.
Eyni qarışıqlıq server tərəfində də görünür. VPN qutusu özü NAT-ın arxasındadırsa, port yönləndirməsi və işlək yönləndirmə yolu lazımdır; strongSwan yönləndirmə bələdçisi IPsec üçün bu halı əhatə edir. Yalnız şəxsi ünvandan əlçatan server müştərilərinin təqdim etdiyi tərcümə edilmiş dəsti heç vaxt görmür və bu, müştərilərin tərcümə olunmasından fərqli bir problemdir.
Bu dörd yoxlamanı sıra ilə keçin və uğursuz olan birincidə dayanın:
- Hər iki tərəfdə eyni vaxtda tutun; mənbə portunun, təyinat portunun və zaman nişanlarının uyğun gəldiyini təsdiqləyin.
- Server həmkar siyahısında gözlədiyiniz ünvanı deyil, hazırda saxladığı ünvanı oxuyun.
- conntrack və ya NAT cədvəlində qeydi və onun qalan ömrünü yoxlayın.
- Müştəridəki tunel interfeysi ünvanının LAN ünvanına deyil, serverin təyin etdiyi ünvana uyğun gəldiyini təsdiqləyin.
Hər iki tutma dəstdə uzlaşırsa və tunel hələ də işləmirsə, tərcümə sizin probleminiz deyil; əl sıxmağa və tunelin içindəki marşrut cədvəlinə keçin.