NAT nusprendžia, kurį šaltinio adresą jūsų VPN serveris iš tikrųjų mato

Jūs įsivaizduojate, kad VPN serveris nuskaito jūsų nešiojamojo kompiuterio adresą iš paketo ir įrašo jį į žurnalą. Tai, ką jis nuskaito, yra tai, ką paskutinis NAT šuolis įdėjo į išorinę antraštę, o telefone, naudojamame kaip prieigos taškas, tai dažnai adresas, kurį dalijasi šimtai kitų abonentų. Jūsų įrenginio savas 192.168.x.x adresas niekada nekerta interneto toje antraštėje, o tunelio adresą serveris suteikia po to, kai ryšys jau užmegztas. Taigi, kai serverio žurnalas ir ip addr nešiojamajame kompiuteryje nesutampa, nė vienas nėra klaidingas; jie apibūdina skirtingus vienos sesijos sluoksnius.

Trys adresai, o žurnale yra tik vienas

Painiava kyla sujungus tris adresus į vieną. Kiekvienas turi skirtingą savininką, gyvena skirtingoje antraštėje ir pasiekia serverį skirtingu keliu.

Tik vidurinė eilutė nežinoma prisijungimo metu. Serveris ją įrašo į savo partnerių lentelę, būsenos failą arba srautų žurnalą priklausomai nuo demono: WireGuard ją vadina galiniu tašku, OpenVPN būsenos failas ją žymi kaip Real Address, o strongSwan praneša ją kaip nuotolinį IKE_SA mazgą. Ši reikšmė atnaujinama kiekvieną kartą, kai ateina paketas iš kito šaltinio, todėl ji keičiasi niekam nieko perkraunant.

Apatinė eilutė yra tai, ką žmonės klaidingai skaito kaip tapatybės teiginį. Ji žymi vietą serverio konfigūracijoje, o ne asmenį, nes serveris ją pasirinko iš savo paties telkinio. Du naudotojai skirtingomis dienomis gali gauti tą patį tunelio adresą, o vienas gali turėti du iš dviejų įrenginių.

Kodėl įrašytas kortetas keičiasi, kai tunelis lieka aktyvus

Adresų vertimas yra lentelė su laikmačiu, o ne nuolatinis susiejimas. Namų maršrutizatorius savo UDP susiejimą laiko kurį laiką po paskutinio paketo, operatoriaus tinklo vartai perdirba prievadus pagal savo grafiką, o telefonas, pereinantis iš Wi-Fi į LTE, grįžta visiškai kitu šaltiniu. Linux conntrack numatytosios reikšmės čia yra naudingas matas: nf_conntrack_udp_timeout yra 30 sekundžių, o srautinio perdavimo variantas 120, todėl tylus tunelis gali prarasti susiejimą kur kas anksčiau, nei naudotojas tai pastebės.

Tunelis išlieka todėl, kad protokolas autentifikuoja partnerį, o ne adresą. WireGuard po rankos paspaudimo yra be būsenos, todėl bet kuris autentifikuotas paketas atnaujina išsaugotą galinį tašką, o persiejimas išsigydo kitame pakete; todėl egzistuoja persistent-keepalive = 25, kad susiejimas išliktų šiltas neveiklumo metu. OpenVPN --float atlieka tą patį darbą ir leidžia autentifikuotam klientui tęsti iš naujo adreso ir prievado. 2.4 ir 2.5 versijose, kur float pagal nutylėjimą išjungtas, persiejimas atstato sesiją, o klientas jungiasi iš naujo.

IPsec ten patenka su daugiau judančių dalių. IKEv2 pastebi vertimą lygindamas šaltinio ir paskirties maišas NAT aptikimo naudingojoje apkrovoje, pereina prie UDP 4500 inkapsuliavimo ir seka keepalive iki naujo korteto. Kai keepalive yra blokuojami, SA lieka aktyvus tik popieriuje, o srautas viena kryptimi tyliai sustoja.

Ką serveris gali priskirti, o ko ne

Mitas, kurį verta nužudyti, yra tai, kad vertimas jus paslepia nuo operatoriaus. Jis keičia etiketę, o ne stebėjimą. Vartai už operatoriaus NAT mato 100.64.0.0/10 erdvę arba vieną viešą adresą, kurį dalijasi daug abonentų, ir vis tiek gali susieti srautą su sertifikato subjektu, WireGuard viešuoju raktu, priskirtu tunelio adresu, baitų skaitikliais ir laiko intervalu. Nė vienam iš jų nereikia jūsų LAN adreso.

Ribos veikia ir priešinga kryptimi. Bendras adresas žurnale rodo į vartus, o ne į namų ūkį; dvi sesijos iš to paties išversto adreso skirtingais prievadais yra skirtingi įrenginiai; tas pats adresas dviem skirtingomis dienomis gali būti du nesusiję abonentai, jei prievadas buvo perdirbtas. Serveris, įrašantis tik partnerių raktus, be paskyrų duomenų bazės negali jų priskirti klientui, o serveris, įrašantis tik adresus, negali atskirti nešiojamojo kompiuterio nuo telefono už to paties maršrutizatoriaus.

Palyginkite abu galus, o ne spėliokite

Norėdami išsiaiškinti, kas įvyko, užfiksuokite tą patį ryšį abiejuose galuose tuo pačiu metu ir palyginkite kortetą, o ne adresą. Kliente, prieš bet kokį vertimą:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Tada perskaitykite vertimo įrašą maršrutizatoriuje arba CGNAT vartuose ir tai, kas galiausiai pasiekia serverį:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Trys modeliai paaiškina daugumą neatitikimų. Serverio šaltinio prievadas skiriasi nuo vietinio prievado, o paskirtis sutampa: įprastas prievadų vertimas. Serverio šaltinio adresas priklauso ISP blokui, kuris ne jūsų: bent vienas papildomas NAT sluoksnis. Paketai sustoja po neveiklumo ir vėl prasideda nauju prievadu: susiejimas pasibaigė, o ne maršrutizavimo gedimas. Jei laiko žymos skiriasi daugiau nei sekunde ar dviem, lyginate du skirtingus bandymus.

Kur skirtumas sugadina daiktus

Pertraukimai, atrodantys kaip serverio gedimai, paprastai prasideda čia. Prieigos taisyklė, prisegta prie jūsų namų adreso nustoja veikti pasikeitus ISP nuomai. fail2ban taisyklė, atitinkanti išverstą adresą, vienu metu užblokuoja visus abonentus už tų vartų. Svetainės su svetaine partneris su fiksuotu nuotoliniu adresu nustoja atnaujinti raktus pasikeitus mobiliojo ryšio linijai. Tunelio protokolas buvo tvarkingas; prielaida apie išorinį kortetą ne.

Ta pati painiava pasireiškia ir serverio pusėje. Jei pati VPN dėžė yra už NAT, jums reikia prievado persiuntimo ir veikiančio persiuntimo kelio; strongSwan persiuntimo vadovas apima tą atvejį IPsec. Serveris, pasiekiamas tik privačiu adresu, niekada nemato išversto korteto, kurį pateikia jo klientai, ir tai yra kita problema nei klientų vertimas.

Atlikite šiuos keturis patikrinimus iš eilės ir sustokite ties pirmuoju, kuris nepavyksta:

• Fiksuokite abiejuose galuose tuo pačiu metu; patvirtinkite, kad šaltinio prievadas, paskirties prievadas ir laiko žymos sutampa.
• Serverio partnerių sąraše perskaitykite adresą, kurį jis dabar turi, o ne tą, kurio tikėjotės.
• Patikrinkite conntrack arba NAT lentelę dėl įrašo ir jo likusio galiojimo.
• Patvirtinkite, kad tunelio sąsajos adresas kliente atitinka serverio priskirtą, o ne LAN adresą.

Jei abu fiksavimai sutampa dėl korteto, o tunelis vis tiek nepavyksta, vertimas nėra jūsų problema; pereikite prie rankos paspaudimo ir maršrutizavimo lentelės tunelio viduje.