Dobbel NAT og VPN-en din: klienten virker, serveren gjør det ikke

Ruteren din står bak en annen ruter, WAN-adressen er privat, og VPN-klienten kobler likevel til. Den kombinasjonen overrasker folk som forventer at dobbel NAT skal ødelegge tunneler, men nettopp utgående forbindelser er det oversettelsen håndterer best. Å drifte en VPN-server bak de samme to lagene er tilfellet som vanligvis feiler. Tegn retningen på forbindelsen før du endrer noe.

Tegn retningen på forbindelsen først

Åpne statussiden til den indre ruteren og skriv ned WAN-adressen, og sammenlign den deretter med adressen en offentlig tjeneste rapporterer til deg. Hvis de to er forskjellige, står det minst én oversetter mellom ruteren din og internett. Hvis WAN-adressen ligger innenfor 100.64.0.0/10, tilhører den ytre oversetteren sannsynligvis leverandøren din, og du kontrollerer den ikke. Disse to fakta avgjør hvilke av de senere trinnene som i det hele tatt kan virke.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Dobbel NAT er ikke dobbel VPN. Oversettelsen skriver om adresser og porter; den legger ikke til en andre kryptert tunnel, og den krypterer ingenting. Å holde de to ideene fra hverandre er viktig fordi løsningene er helt forskjellige, og en av dem krever en samtale med leverandøren din i stedet for en innstillingsside.

Utgående: klienten spør, oversetterne mapper

En utgående tunnel begynner med en pakke fra maskinen din, så hver oversetter kan opprette en mapping og slippe svaret inn igjen. Protokollen, porten og inaktivitetstimene avgjør om mappingen overlever lenge nok til å være nyttig. De fleste forbrukerrutere klarer dette helt uten konfigurasjon.

Feilene som faktisk dukker opp handler vanligvis om tidsavbrudd og protokollstøtte, ikke om antallet rutere. En tunnel som faller etter noen minutters stillhet, er en mapping som utløper, og en keepalive er det vanlige svaret. IPsec har standard NAT-traversal-utvidelser, så påstanden om at det ikke kan krysse en oversettelse er rett og slett feil. Hvis tunnelen ikke etableres i det hele tatt, se på endepunktet og påloggingsdetaljene før du gir topologien skylden.

wg show
ping -c3 10.8.0.1

Stopp hvis den utgående tunnelen virker fra ett nettverk og ikke fra et annet. Den sammenligningen handler om nettverkene, ikke om antallet rutere.

Inngående: videresending dekker bare utstyr du eier

Å drifte en server er motsatt retning: en ny forbindelse kommer fra internett og må nå maskinen din gjennom hvert lag. En portvideresendingsregel på den indre ruteren hjelper bare hvis den ytre oversetteren også leverer den trafikken til deg. Å gjenta den lokale regelen gir deg ikke kontroll over leverandørens utstyr.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Sammenlign WAN-adressen til den indre ruteren med den offentlige adressen du observerte, og noter hvor hver verdi kom fra. Hvis WAN-adressen er privat eller i det delte området, utfører det ytre laget en oversettelse du ikke kan konfigurere. Spør leverandøren hvilken inngående tilgjengelighet den støtter før du bruker en hel kveld på regler som ikke kan tre i kraft. Å fjerne en ruter eller slå av en brannmur bredt er ikke en diagnose, og det er en dårlig byttehandel for én åpen port.

Stopp hvis det ytre laget er leverandørens og det ikke videresender. Da er de støttede svarene en annen tilgangsmetode eller et relay, ikke enda en regel på din side.

Test én variabel om gangen

Endre én ting per test og noter resultatet, fordi en dobbel-NAT-vei har flere variabler enn en vei med én ruter. Hold profilen og enheten fast, og sammenlign deretter et annet tilgangsnettverk. Noter om forhandlingen feiler, om økten faller etter inaktivitet, eller om bare private mål feiler. De tre observasjonene peker på tre forskjellige lag.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Overlappende private subnett er en egen felle som ingen mengde oversettelse retter opp. Hvis hjemmenettverket og fjernnettverket bruker samme område, oppstår en rutekonflikt uansett hvor mange oversettere som står imellom. Å nummerere om den ene siden på nytt er det eneste varige svaret.

Fjernporten fortjener samme oppmerksomhet, fordi videresendingsreglene og returrutene kan være den manglende brikken. En tunnel som autentiserer kan fortsatt mangle en brukbar applikasjonsvei, og den feilen ser identisk ut fra klientsiden. Gjennomgangen slutter når du kan si hvilken retning som feiler og hvilket lag som eier den.