NAT bestemmer hvilken kildeadresse VPN-serveren din faktisk ser

Du ser for deg at VPN-serveren leser adressen til den bærbare datamaskinen din fra pakken og skriver den i en logg. Det den leser, er det siste NAT-hoppet la i den ytre headeren, og på en telefon som brukes som hotspot er det ofte en adresse som deles med hundrevis av andre abonnenter. Maskinens egen 192.168.x.x krysser aldri internett i den headeren, og tunneladressen deles ut av serveren etter at forbindelsen allerede er oppe. Når en serverlogg og ip addr på den bærbare maskinen derfor ikke stemmer, er ingen av dem feil; de beskriver ulike lag av én sesjon.

Tre adresser, og bare én av dem står i loggen

Forvirringen kommer av at tre adresser slås sammen til én. Hver har en annen eier, lever i en annen header og når serveren ad en annen vei.

Bare den midterste raden er ukjent ved tilkobling. Serveren skriver den i peertabellen, statusfilen eller flytloggen avhengig av daemonen: WireGuard kaller den endepunktet, en OpenVPN-statusfil kaller den Real Address, og strongSwan rapporterer den som fjernverten til IKE_SA. Verdien oppdateres hver gang en pakke kommer fra en annen kilde, så den endres uten at noen starter noe på nytt.

Den nederste raden er det folk feilaktig leser som et identitetskrav. Den markerer en plass i serverkonfigurasjonen, ikke en person, fordi serveren valgte den fra sin egen pool. To brukere kan få samme tunneladresse på ulike dager, og én kan ha to av dem fra to enheter.

Hvorfor den loggede tuplen endres mens tunnelen blir stående

Adresseoversettelse er en tabell med en timer, ikke en permanent binding. En hjemmeruter beholder UDP-mappingen en stund etter siste pakke, en operatørgateway resirkulerer porter etter sin egen plan, og en telefon som hopper fra Wi-Fi til LTE kommer tilbake med en helt annen kilde. Linux-conntracks standardverdier er et nyttig holdepunkt her: nf_conntrack_udp_timeout er 30 sekunder og strømmevarianten er 120, så en stille tunnel kan miste mappingen lenge før brukeren merker det.

Tunnelen overlever fordi protokollen autentiserer peeren, ikke adressen. WireGuard er tilstandsløs etter håndtrykket, så enhver autentisert pakke oppdaterer det lagrede endepunktet, og en ny binding leges på neste pakke; derfor finnes persistent-keepalive = 25, for å holde mappingen varm mens den er inaktiv. OpenVPNs --float gjør samme jobben og lar en autentisert klient fortsette fra en ny adresse og port. På 2.4- og 2.5-bygg der float er slått av som standard, nullstiller en ny binding økten, og klienten kobler til på nytt.

IPsec kommer dit med flere bevegelige deler. IKEv2 oppdager oversettelsen ved å sammenligne kilde- og destinasjonshashene i NAT-deteksjonsnyttelasten, bytter til UDP 4500-innkapsling og følger keepalives til den nye tuplen. Når keepalives blokkeres, blir SA-en stående på papiret mens trafikk i én retning stille stopper.

Hva serveren kan tilskrive, og hva den ikke kan

Myten som er verdt å drepe, er at oversettelse skjuler deg for operatøren. Den endrer etiketten, ikke observasjonen. En gateway bak operatørens NAT ser 100.64.0.0/10-rom eller én offentlig adresse som mange abonnenter deler, og kan fortsatt knytte flyten til et sertifikatsubjekt, en offentlig WireGuard-nøkkel, en tildelt tunneladresse, byttetellere og et tidsvindu. Ingenting av dette trenger LAN-adressen din.

Grensene går også den andre veien. En delt adresse i en logg peker på en gateway, ikke en husstand; to økter fra samme oversatte adresse på ulike porter er ulike enheter; samme adresse på to ulike dager kan være to ubeslektede abonnenter hvis porten ble resirkulert. En server som bare registrerer peer-nøkler, kan ikke knytte en til en kunde uten kontodatabasen, og en server som bare registrerer adresser, kan ikke skille en bærbar maskin fra en telefon bak samme ruter.

Sammenlign begge ender i stedet for å gjette

For å avgjøre hva som skjedde, fang samme forbindelse i begge ender på samme tidspunkt og sammenlign tuplen, ikke adressen. På klienten, før noen oversettelse:

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

Les deretter oversettelsesoppføringen på ruteren eller CGNAT-gatewayen, og det som til slutt kommer fram til serveren:

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

Tre mønstre forklarer de fleste avvikene. Kildeporten på serveren er forskjellig fra den lokale porten mens destinasjonen stemmer: vanlig portoversettelse. Kildeadressen på serveren tilhører en ISP-blokk som ikke er din: minst ett ekstra NAT-lag. Pakkene stopper etter en inaktiv periode og fortsetter med en ny port: mappingen er utløpt, ikke en rutingfeil. Hvis tidsstemplene er mer enn ett eller to sekunder fra hverandre, sammenligner du to ulike forsøk.

Hvor forskjellen ødelegger ting

Avbrudd som ser ut som serverfeil, begynner vanligvis her. En tilgangsregel festet til hjemadressen din feiler etter at ISP-leasen endres. En fail2ban-regel som treffer en oversatt adresse, utestenger alle abonnenter bak den gatewayen på én gang. En site-til-site-peer med fast fjernadresse slutter å fornye nøkler etter at en mobillenke endres. Tunnelprotokollen var i orden; antakelsen om den ytre tuplen var det ikke.

Den samme forvirringen dukker opp på serversiden. Hvis selve VPN-boksen står bak NAT, trenger du portvideresending og en fungerende videresendingsvei; strongSwans videresendingsveiledning dekker det tilfellet for IPsec. En server som bare er tilgjengelig på en privat adresse, ser aldri den oversatte tuplen klientene presenterer, og det er et annet problem enn at klienter blir oversatt.

Gå gjennom disse fire kontrollene i rekkefølge og stopp ved den første som feiler:

• Fang i begge ender samtidig; bekreft at kildeport, destinasjonsport og tidsstempler stemmer.
• Les peer-listen til serveren for adressen den holder nå, ikke adressen du forventet.
• Sjekk conntrack- eller NAT-tabellen for oppføringen og dens gjenværende levetid.
• Bekreft at tunnelgrensesnittets adresse på klienten stemmer med den serveren tildelte, ikke LAN-adressen.

Hvis begge opptakene er enige om tuplen og tunnelen fortsatt feiler, er ikke oversettelsen problemet ditt; gå videre til håndtrykket og til rutingtabellen inne i tunnelen.