NAT rozhoduje, ktorú zdrojovú adresu tvoj VPN server skutočne vidí

Predstavuješ si, že VPN server číta adresu tvojho notebooku z paketu a zapisuje ju do logu. Číta to, čo posledný NAT skok vložil do vonkajšej hlavičky, a na telefóne použitom ako prístupový bod je to často adresa zdieľaná so stovkami ďalších účastníkov. Vlastná adresa tvojho stroja 192.168.x.x nikdy v tej hlavičke neprejde internetom a adresu tunela pridelí server až po tom, čo je spojenie nadviazané. Keď sa teda log servera a ip addr na notebooku nezhodujú, ani jedno nie je nesprávne; opisujú rôzne vrstvy jednej relácie.

Tri adresy a v logu je len jedna

Zmätok vzniká tým, že sa tri adresy stlačia do jednej. Každá má iného vlastníka, žije v inej hlavičke a k serveru sa dostáva inou cestou.

V okamihu pripojenia nie je známy len prostredný riadok. Server ho zapisuje do svojej tabuľky partnerov, stavového súboru alebo logu tokov podľa démona: WireGuard ho nazýva koncový bod, stavový súbor OpenVPN ho označuje ako Real Address a strongSwan ho hlási ako vzdialeného hostiteľa IKE_SA. Táto hodnota sa obnovuje pri každom pakete z iného zdroja, takže sa mení bez toho, aby ktokoľvek čokoľvek reštartoval.

Spodný riadok je to, čo ľudia nesprávne čítajú ako tvrdenie o identite. Označuje miesto v konfigurácii servera, nie osobu, pretože ho server vybral z vlastného fondu. Dvaja používatelia môžu v rôznych dňoch dostať rovnakú adresu tunela a jeden môže mať dve z dvoch zariadení.

Prečo sa zaznamenaný tuple mení, kým tunel zostáva aktívny

Preklad adries je tabuľka s časovačom, nie trvalé previazanie. Domáci router drží svoje UDP mapovanie ešte chvíľu po poslednom pakete, brána operátora recykluje porty podľa vlastného plánu a telefón, ktorý prejde z Wi-Fi na LTE, sa vráti s úplne iným zdrojom. Predvolené hodnoty conntracku v Linuxe sú tu užitočným meradlom: nf_conntrack_udp_timeout je 30 sekúnd a streamingový variant 120, takže tichý tunel môže stratiť mapovanie dávno predtým, než si to používateľ všimne.

Tunel prežíva preto, lebo protokol overuje partnera, nie adresu. WireGuard je po handshake bezstavový, takže každý overený paket aktualizuje uložený koncový bod a opätovné previazanie sa spraví pri ďalšom pakete; preto existuje persistent-keepalive = 25, aby udržal mapovanie teplé počas nečinnosti. --float v OpenVPN robí to isté a umožňuje overenému klientovi pokračovať z novej adresy a portu. V zostaveniach 2.4 a 2.5, kde je float predvolene vypnutý, opätovné previazanie resetuje reláciu a klient sa znova pripojí.

IPsec sa tam dostane s viacerými pohyblivými časťami. IKEv2 rozpozná preklad porovnaním hašov zdroja a cieľa v užitočnom zaťažení detekcie NAT, prejde na zapuzdrenie do UDP 4500 a sleduje keepalive k novému tupleu. Keď sú keepalive blokované, SA zostáva na papieri aktívna, kým prevádzka v jednom smere ticho ustane.

Čo server môže pripísať a čo nie

Mýtus, ktorý stojí za to zabiť, je, že vás preklad skryje pred operátorom. Mení označenie, nie pozorovanie. Brána za NAT operátora vidí priestor 100.64.0.0/10 alebo jednu verejnú adresu zdieľanú mnohými účastníkmi a tok dokáže aj tak spojiť so subjektom certifikátu, verejným kľúčom WireGuardu, pridelenou adresou tunela, počítadlami bajtov a časovým oknom. Nič z toho nepotrebuje vašu LAN adresu.

Hranice idú aj opačným smerom. Zdieľaná adresa v logu ukazuje na bránu, nie na domácnosť; dve relácie z tej istej preloženej adresy na rôznych portoch sú rôzne zariadenia; tá istá adresa v dva rôzne dni môže byť dvaja nesúvisiaci účastníci, ak bol port recyklovaný. Server, ktorý zaznamenáva iba kľúče partnerov, ich bez databázy účtov nedokáže priradiť klientovi, a server, ktorý zaznamenáva iba adresy, nerozozná notebook od telefónu za tým istým routerom.

Porovnajte oba konce namiesto hádania

Aby ste zistili, čo sa stalo, zachyťte to isté spojenie na oboch koncoch v tom istom okamihu a porovnajte tuple, nie adresu. Na klientovi, pred akýmkoľvek prekladom:

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

Potom si prečítajte záznam prekladu na routeri alebo bráne CGNAT a to, čo nakoniec dorazí na server:

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

Tri vzory vysvetľujú väčšinu nezrovnalostí. Zdrojový port na serveri sa líši od lokálneho portu, kým cieľ sa zhoduje: bežný preklad portov. Zdrojová adresa na serveri patrí do bloku ISP, ktorý nie je váš: aspoň jedna ďalšia vrstva NAT. Pakety sa po období nečinnosti zastavia a pokračujú s novým portom: mapovanie vypršalo, nie porucha smerovania. Ak sú časové značky od seba viac ako sekundu alebo dve, porovnávate dva rôzne pokusy.

Kde rozdiel láme veci

Výpadky, ktoré vyzerajú ako poruchy servera, zvyčajne začínajú tu. Pravidlo prístupu pripnuté k vašej domácej adrese prestane fungovať po zmene leasingu ISP. Pravidlo fail2ban zodpovedajúce preloženej adrese zablokuje všetkých účastníkov za touto bránou naraz. Partner site-to-site s pevnou vzdialenou adresou prestane obnovovať kľúče po zmene mobilného spoja. Protokol tunela bol v poriadku; predpoklad o vonkajšom tuple nebol.

Ten istý zmätok sa objavuje aj na strane servera. Ak samotná VPN krabica stojí za NAT, potrebujete presmerovanie portu a funkčnú cestu presmerovania; sprievodca strongSwan pre presmerovanie pokrýva tento prípad pre IPsec. Server dostupný len na súkromnej adrese nikdy nevidí preložený tuple, ktorý mu predkladajú jeho klienti, a to je iný problém než preklad klientov.

Prejdite tieto štyri kontroly v poradí a zastavte sa pri prvej, ktorá zlyhá:

• Zachyťte na oboch koncoch súčasne; potvrďte, že zdrojový port, cieľový port a časové značky sa zhodujú.
• Prečítajte v zozname partnerov servera adresu, ktorú práve drží, nie tú, ktorú ste očakávali.
• Skontrolujte tabuľku conntrack alebo NAT na záznam a jeho zostávajúcu životnosť.
• Potvrďte, že adresa tunelového rozhrania na klientovi zodpovedá tej, ktorú pridelil server, nie adrese LAN.

Ak sa obe zachytenia zhodujú na tuple a tunel napriek tomu zlyhá, preklad nie je váš problém; prejdite k handshake a k smerovacej tabuľke vnútri tunela.