NAT avgjer kva for kjeldeadresse VPN-tenaren din faktisk ser

Du ser føre deg at VPN-tenaren les adressa til den berbare datamaskina di frå pakken og skriv henne i ein logg. Det han les, er det siste NAT-hoppet la i den ytre headeren, og på ein telefon som blir brukt som hotspot er det ofte ei adresse som blir delt med hundrevis av andre abonnentar. Maskina si eiga 192.168.x.x kryssar aldri internett i den headeren, og tunneladressa blir delt ut av tenaren etter at sambandet allereie er oppe. Når ein tenarlogg og ip addr på den berbare maskina derfor ikkje stemmer, er ingen av dei feil; dei skildrar ulike lag av éin sesjon.

Tre adresser, og berre éi av dei står i loggen

Forvirringa kjem av at tre adresser blir slått saman til éi. Kvar har ein annan eigar, lever i ein annan header og når tenaren på ein annan veg.

Berre den midterste rada er ukjend ved tilkopling. Tenaren skriv henne i peertabellen, statusfila eller flytloggen avhengig av daemonen: WireGuard kallar henne endepunktet, ei OpenVPN-statusfil kallar henne Real Address, og strongSwan rapporterer henne som fjernverten til IKE_SA. Verdien blir oppdatert kvar gong ein pakke kjem frå ei anna kjelde, så han endrar seg utan at nokon startar noko på nytt.

Den nedste rada er det folk feilaktig les som eit identitetskrav. Ho markerer ein plass i tenarkonfigurasjonen, ikkje ein person, fordi tenaren valde henne frå sin eigen pool. To brukarar kan få same tunneladresse på ulike dagar, og éin kan ha to av dei frå to einingar.

Kvifor den logga tuplen endrar seg medan tunnelen blir ståande

Adresseomsetjing er ein tabell med ein timer, ikkje ei permanent binding. Ein heimeruter held UDP-mappinga eit stykke etter siste pakke, ein operatørgateway resirkulerer portar etter sin eigen plan, og ein telefon som hoppar frå Wi-Fi til LTE kjem tilbake med ei heilt anna kjelde. Standardverdiane til Linux-conntrack er eit nyttig halepunkt her: nf_conntrack_udp_timeout er 30 sekund og straumevarianten er 120, så ein roleg tunnel kan miste mappinga lenge før brukaren merkar det.

Tunnelen overlever fordi protokollen autentiserer peeren, ikkje adressa. WireGuard er tilstandslaus etter handtrykket, så kvar autentisert pakke oppdaterer det lagra endepunktet, og ei ny binding blir lækt på neste pakke; difor finst persistent-keepalive = 25, for å halde mappinga varm medan ho er inaktiv. --float i OpenVPN gjer same jobben og lèt ein autentisert klient halde fram frå ei ny adresse og port. På 2.4- og 2.5-bygg der float er slått av som standard, nullstiller ei ny binding økta, og klienten koplar til på nytt.

IPsec kjem dit med fleire bevegelege delar. IKEv2 oppdagar omsetjinga ved å samanlikne kilde- og destinasjonshashene i NAT-deteksjonsnyttelasta, byter til UDP 4500-innkapsling og følgjer keepalives til den nye tuplen. Når keepalives blir blokkerte, blir SA-en ståande på papiret medan trafikk i éi retning stille stoppar.

Kva tenaren kan tilskrive, og kva han ikkje kan

Myten som er verdt å drepe, er at omsetjing skjuler deg for operatøren. Ho endrar etiketten, ikkje observasjonen. Ein gateway bak NAT-en til operatøren ser 100.64.0.0/10-rom eller éi offentleg adresse som mange abonnentar deler, og kan framleis knyte straumen til eit sertifikatsubjekt, ein offentleg WireGuard-nøkkel, ei tildelt tunneladresse, bytteteljarar og eit tidsvindauge. Ingenting av dette treng LAN-adressa di.

Grensene går òg den andre vegen. Ei delt adresse i ein logg peikar på ein gateway, ikkje ein husstand; to økter frå same omsette adresse på ulike portar er ulike einingar; same adresse på to ulike dagar kan vere to uslekta abonnentar om porten blei resirkulert. Ein tenar som berre registrerer peer-nøklar, kan ikkje knyte ein til ein kunde utan kontodatabasen, og ein tenar som berre registrerer adresser, kan ikkje skilje ein berbar maskin frå ein telefon bak same ruter.

Samanlikne begge endar i staden for å gjette

For å avgjere kva som skjedde, fang same sambandet i begge endar på same tidspunkt og samanlikne tuplen, ikkje adressa. På klienten, før noka omsetjing:

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

Les deretter omsetjingsposten på ruteren eller CGNAT-gatewayen, og det som til slutt kjem fram til tenaren:

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

Tre mønster forklarar dei fleste avvika. Kildeporten på tenaren er forskjellig frå den lokale porten medan destinasjonen stemmer: vanleg portomsetjing. Kildeadressa på tenaren høyrer til ein ISP-blokk som ikkje er din: minst eitt ekstra NAT-lag. Pakkane stoppar etter ein inaktiv periode og held fram med ein ny port: mappinga er gått ut, ikkje ein rutefeil. Viss tidsstempla er meir enn eitt eller to sekund frå kvarandre, samanliknar du to ulike forsøk.

Kvar skilnaden øydelegg ting

Avbrot som ser ut som tenarfeil, byrjar vanlegvis her. Ein tilgangsregel festa til heimeadressa di feilar etter at ISP-leasen blir endra. Ein fail2ban-regel som treffer ei omsett adresse, stenger ute alle abonnentar bak den gatewayen på éin gong. Ein site-til-site-peer med fast fjernadresse sluttar å fornye nøklar etter at ei mobillenke blir endra. Tunnelprotokollen var i orden; antakinga om den ytre tuplen var det ikkje.

Den same forvirringa dukkar opp på tenarsida. Viss sjølve VPN-boksen står bak NAT, treng du portvideresending og ein fungerande videresendingsveg; videresendingsrettleiinga til strongSwan dekkjer det tilfellet for IPsec. Ein tenar som berre er tilgjengeleg på ei privat adresse, ser aldri den omsette tuplen klientane presenterer, og det er eit anna problem enn at klientar blir omsette.

Gå gjennom desse fire kontrollane i rekkjefølgje og stopp ved den første som feilar:

• Fang i begge endar samstundes; stadfest at kildeport, destinasjonsport og tidsstempel stemmer.
• Les peer-lista til tenaren for adressa han held no, ikkje adressa du venta.
• Sjekk conntrack- eller NAT-tabellen for posten og den attverande levetida hans.
• Stadfest at adressa til tunnelgrensesnittet på klienten stemmer med den tenaren tildelte, ikkje LAN-adressa.

Viss begge opptaka er samde om tuplen og tunnelen framleis feilar, er ikkje omsetjinga problemet ditt; gå vidare til handtrykket og til rutetabellen inne i tunnelen.