NAT otsustab, millist lähteaadressi sinu VPN-server tegelikult näeb

Sa kujutad ette, et VPN-server loeb paketist sinu sülearvuti aadressi ja kirjutab selle logisse. See, mida ta loeb, on see, mille viimane NAT-hüpe välisesse päisesse pani, ja jagatud ühendusega telefonis on see sageli aadress, mida jagavad sajad teised abonendid. Sinu masina enda aadress 192.168.x.x ei ületa selles päises kunagi internetti ja tunneli aadressi annab server pärast seda, kui ühendus on juba püsti. Kui serveri logi ja sülearvuti ip addr ei klapi, ei ole kumbki vale; need kirjeldavad ühe sessiooni erinevaid kihte.

Kolm aadressi ja logis on neist ainult üks

Segadus tekib sellest, et kolm aadressi surutakse üheks. Igal on erinev omanik, see elab erinevas päises ja jõuab serverini erinevat teed pidi.

Ühenduse hetkel on teadmata ainult keskmine rida. Server kirjutab selle deemonist sõltuvalt oma partnerite tabelisse, olekufaili või voologisse: WireGuard nimetab seda lõpp-punktiks, OpenVPN olekufail märgib selle kui Real Address ja strongSwan teatab selle IKE_SA kaugvastuvõtjaks. See väärtus uuendatakse iga kord, kui saabub pakett teisest allikast, seega muutub see ilma, et keegi midagi taaskäivitaks.

Alumine rida on see, mida inimesed ekslikult loevad identiteediväitena. See märgib kohta serveri konfiguratsioonis, mitte inimest, sest server valis selle oma personalist. Kaks kasutajat võivad erinevatel päevadel saada sama tunneli aadressi ja üks võib hoida kahte sellist kahest seadmest.

Miks logitud korteež muutub, kui tunnel jääb püsti

Aadressitõlge on ajatiga tabel, mitte püsiv sidumine. Kodu-ruuter hoiab oma UDP-vastendust mõnda aega pärast viimast paketti, operaatori lüüs ringleb porte oma ajakava järgi ja telefon, mis liigub Wi-Fi-lt LTE-le, naaseb täiesti teise allikaga. Linuxi conntracki vaikeväärtused on siin kasulik mõõdupuu: nf_conntrack_udp_timeout on 30 sekundit ja voogedastuse variant 120, seega vaikne tunnel võib oma vastenduse kaotada ammu enne, kui kasutaja seda märkab.

Tunnel jääb ellu, sest protokoll autendib partnerit, mitte aadressi. WireGuard on pärast kätlust olekutu, seega iga autenditud pakett uuendab salvestatud lõpp-punkti ja ümbersidumine paraneb järgmise paketiga; just sellepärast on olemas persistent-keepalive = 25, et hoida vastendust jõudeajal soojas. OpenVPN-i --float teeb sama töö ja lubab autenditud kliendil jätkata uuelt aadressilt ja pordilt. Versioonides 2.4 ja 2.5, kus float on vaikimisi väljas, lähtestab ümbersidumine sessiooni ja klient ühendub uuesti.

IPsec jõuab sinna rohkemate liikuvate osadega. IKEv2 märkab tõlget, võrreldes NAT-tuvastuse kandurites allika ja sihtkoha räsisid, läheb üle UDP 4500 kapseldamisele ja järgib keepalive'e uue korteežini. Kui keepalive'id on blokeeritud, jääb SA paberil püsti, samal ajal kui liiklus ühes suunas vaikselt seiskub.

Mida server saab omistada ja mida mitte

Müüt, mida tasub tappa, on see, et tõlge peidab sind operaatori eest. See muudab silti, mitte vaatlust. Operaatori NAT-i taga olev lüüs näeb 100.64.0.0/10 ruumi või ühte avalikku aadressi, mida jagavad paljud abonendid, ja suudab voo ikkagi siduda sertifikaadi subjektiga, WireGuardi avaliku võtmega, määratud tunneli aadressiga, baidilugejatega ja ajavahemikuga. Mitte miski sellest ei vaja sinu LAN-aadressi.

Piirid lähevad ka teises suunas. Logis olev jagatud aadress osutab lüüsile, mitte majapidamisele; kaks sessiooni samalt tõlgitud aadressilt erinevatel portidel on erinevad seadmed; sama aadress kahel erineval päeval võib olla kaks mitteseotud abonenti, kui port ringlusse läks. Server, mis registreerib ainult partnerite võtmeid, ei saa ilma kontode andmebaasita neid kliendiga siduda, ja server, mis registreerib ainult aadresse, ei suuda eristada sülearvutit telefonist sama ruuteri taga.

Võrdle mõlemat otsa, mitte ära arva

Et selgitada, mis juhtus, jäädvusta sama ühendus mõlemas otsas samal hetkel ja võrdle korteeži, mitte aadressi. Kliendis, enne igasugust tõlget:

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

Seejärel loe tõlke kirjet ruuteril või CGNAT-lüüsil ja seda, mis lõpuks serverini jõuab:

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

Kolm mustrit selgitavad enamikku lahknevusi. Serveri lähteport erineb kohalikust pordist, samal ajal kui sihtkoht klapib: tavaline portide tõlge. Serveri lähteaadress kuulub ISP plokki, mis pole sinu oma: vähemalt üks täiendav NAT-kiht. Paketid peatuvad pärast jõudeperioodi ja jätkuvad uue pordiga: vastendus aegus, mitte marsruutimise rike. Kui ajatemplid on enam kui sekundi või kaks erinevad, võrdled kahte erinevat katset.

Kus erinevus asju lõhub

Serveri riketena näivad katkestused algavad tavaliselt siit. Sinu kodu-aadressi külge kinnitatud juurdepääsureegel ebaõnnestub pärast ISP rendilepingu muutumist. Tõlgitud aadressiga sobiv fail2ban reegel blokeerib korraga kõik selle lüüsi taga olevad abonendid. Fikseeritud kaugaadressiga sait-sait partner lõpetab võtmete uuendamise pärast mobiilse lingi muutumist. Tunneli protokoll oli korras; eeldus välimise korteeži kohta ei olnud.

Sama segadus ilmneb ka serveri poolel. Kui VPN-kast ise on NAT-i taga, vajad portide suunamist ja töötavat suunamisteed; strongSwani suunamisjuhend katab selle juhtumi IPseci jaoks. Ainult privaataadressil kättesaadav server ei näe kunagi tõlgitud korteeži, mida tema kliendid esitavad, ja see on teine probleem kui klientide tõlkimine.

Käi need neli kontrolli järjest läbi ja peatu esimesel, mis ebaõnnestub:

• Jäädvusta mõlemas otsas samal ajal; kinnita, et lähteport, sihtport ja ajatemplid klapivad.
• Loe serveri partnerite loendist aadress, mida see praegu hoiab, mitte see, mida sa ootasid.
• Kontrolli conntracki või NAT-tabelist kirjet ja selle järelejäänud eluiga.
• Kinnita, et kliendi tunneli liidese aadress vastab serveri määratud aadressile, mitte LAN-aadressile.

Kui mõlemad jäädvustused korteežis kokku langevad ja tunnel ikka ei tööta, ei ole tõlge sinu probleem; liigu kätluse ja tunneli sees oleva marsruutimistabeli juurde.