NAT afgør, hvilken kildeadresse din VPN-server faktisk ser

Du forestiller dig, at VPN-serveren læser din laptops adresse fra pakken og skriver den i en log. Det, den læser, er hvad det sidste NAT-hop lagde i den ydre header, og på en telefon, der deler forbindelse, er det ofte en adresse, som hundredvis af andre abonnenter deler. Din maskines egen 192.168.x.x krydser aldrig internettet i den header, og tunneladressen tildeles af serveren, efter at forbindelsen allerede er oppe. Når en serverlog og ip addr på laptop'en derfor er uenige, er ingen af dem forkert; de beskriver forskellige lag af én session.

Tre adresser, og kun én af dem står i loggen

Forvirringen opstår, fordi tre adresser smeltes sammen til én. Hver har en anden ejer, lever i en anden header og når serveren ad en anden vej.

Kun den midterste række er ukendt på forbindelsestidspunktet. Serveren skriver den i sin peertabel, statusfil eller flowlog afhængigt af daemonen: WireGuard kalder den endpoint, en OpenVPN-statusfil kalder den Real Address, og strongSwan rapporterer den som IKE_SA'ens fjernvært. Værdien opdateres, hver gang en pakke ankommer fra en anden kilde, så den ændrer sig, uden at nogen genstarter noget.

Den nederste række er det, folk fejlagtigt læser som et identitetskrav. Den markerer en plads i serverkonfigurationen, ikke en person, fordi serveren valgte den fra sin egen pulje. To brugere kan få samme tunneladresse på forskellige dage, og én kan have to af dem fra to enheder.

Hvorfor den loggede tuple ændrer sig, mens tunnelen bliver oppe

Adresseoversættelse er en tabel med en timer, ikke en permanent binding. En hjemmerouter holder sin UDP-mapping et stykke tid efter den sidste pakke, en operatørgateway genbruger porte efter sin egen tidsplan, og en telefon, der skifter fra Wi-Fi til LTE, vender tilbage med en helt anden kilde. Linux-conntracks standardværdier er et nyttigt benchmark her: nf_conntrack_udp_timeout er 30 sekunder, og streamingvarianten er 120, så en stille tunnel kan miste sin mapping længe før, brugeren bemærker det.

Tunnelen overlever, fordi protokollen autentificerer peeren, ikke adressen. WireGuard er tilstandsløs efter handshaken, så enhver autentificeret pakke opdaterer det gemte endpoint, og en genbinding heles på den næste pakke; derfor findes persistent-keepalive = 25, for at holde mappingen varm, mens den er inaktiv. OpenVPNs --float gør det samme og lader en autentificeret klient fortsætte fra en ny adresse og port. På 2.4- og 2.5-builds, hvor float er slået fra som standard, nulstiller en genbinding sessionen, og klienten genopretter forbindelsen.

IPsec når derhen med flere bevægelige dele. IKEv2 bemærker oversættelsen ved at sammenligne kilde- og destinationshashes i NAT-detektionspayloads, skifter til UDP 4500-indkapsling og følger keepalives til den nye tuple. Når keepalives blokeres, forbliver SA'en oppe på papiret, mens trafik i én retning stille stopper.

Hvad serveren kan tilskrive, og hvad den ikke kan

Myten, der er værd at dræbe, er, at oversættelse skjuler dig for operatøren. Den ændrer etiketten, ikke observationen. En gateway bag operatørens NAT ser 100.64.0.0/10-plads eller én offentlig adresse, som mange abonnenter deler, og kan stadig knytte flowet til et certifikatsubject, en WireGuard-offentlig nøgle, en tildelt tunneladresse, byttetællere og et tidsvindue. Intet af det kræver din LAN-adresse.

Grænserne går også den anden vej. En delt adresse i en log peger på en gateway, ikke på en husstand; to sessioner fra samme oversatte adresse på forskellige porte er forskellige enheder; samme adresse på to forskellige dage kan være to ubeslægtede abonnenter, hvis porten blev genbrugt. En server, der kun registrerer peer-nøgler, kan ikke knytte en til en kunde uden konto-databasen, og en server, der kun registrerer adresser, kan ikke skelne en laptop fra en telefon bag samme router.

Sammenlign begge ender i stedet for at gætte

For at afgøre, hvad der skete, skal du optage den samme forbindelse i begge ender på samme tidspunkt og sammenligne tuple, ikke adresse. På klienten, før nogen oversættelse:

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

Læs derefter oversættelsesposten på routeren eller CGNAT-gatewayen, og hvad der til sidst ankommer til serveren:

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

Tre mønstre forklarer de fleste uoverensstemmelser. Serverens kildeport afviger fra den lokale port, mens destinationen matcher: almindelig portoversættelse. Serverens kildeadresse tilhører en ISP-blok, der ikke er din: mindst et ekstra NAT-lag. Pakkerne stopper efter en inaktiv periode og genoptages med en ny port: mappingen er udløbet, ikke en routingfejl. Hvis tidsstemplerne er mere end et sekund eller to fra hinanden, sammenligner du to forskellige forsøg.

Hvor forskellen ødelægger ting

Nedbrud, der ligner serverfejl, starter normalt her. En adgangsregel fastgjort til din hjemadresse fejler, efter at ISP'ens lease ændrer sig. En fail2ban-regel, der matcher en oversat adresse, bandlyser alle abonnenter bag den gateway på én gang. En site-to-site-peer med en fast fjernadresse holder op med at forny nøgler, efter at et mobillink ændrer sig. Tunnelprotokollen var fin; antagelsen om den ydre tuple var det ikke.

Den samme forvirring dukker op på serverenden. Hvis selve VPN-boksen står bag NAT, har du brug for en portforwarding og en fungerende videresendelsesvej; strongSwans videresendelsesguide dækker det tilfælde for IPsec. En server, der kun er tilgængelig på en privat adresse, ser aldrig den oversatte tuple, dens klienter præsenterer, og det er et andet problem end at klienter bliver oversat.

Gå gennem disse fire kontroller i rækkefølge, og stop ved den første, der fejler:

• Optag i begge ender på samme tid; bekræft, at kildeport, destinationsport og tidsstempler stemmer overens.
• Læs serverens peer-liste for den adresse, den aktuelt holder, ikke den adresse, du forventede.
• Tjek conntrack- eller NAT-tabellen for posten og dens resterende levetid.
• Bekræft, at tunnelgrænsefladens adresse på klienten matcher den, serveren tildelte, og ikke LAN-adressen.

Hvis begge optagelser er enige om tuple, og tunnelen stadig fejler, er oversættelse ikke dit problem; gå videre til handshaken og til routingtabellen inde i tunnelen.