Dobbelt NAT og din VPN: klienten virker, serveren gør ikke

Din router står bag en anden router, WAN-adressen er privat, og VPN-klienten forbinder alligevel. Den kombination overrasker folk, der forventer, at dobbelt NAT ødelægger tunneller, men netop udgående forbindelser er det, oversættelse håndterer bedst. At hoste en VPN-server bag de samme to lag er det tilfælde, der normalt fejler. Tegn forbindelsens retning, før du ændrer noget.

Tegn først forbindelsens retning

Åbn den indre routers statusside, og skriv dens WAN-adresse ned, og sammenlign den derefter med den adresse, en offentlig tjeneste rapporterer til dig. Hvis de to er forskellige, står der mindst én oversætter mellem din router og internettet. Hvis WAN-adressen ligger inden for 100.64.0.0/10, tilhører den ydre oversætter sandsynligvis din udbyder, og du kontrollerer den ikke. De to fakta afgør, hvilke af de senere trin der overhovedet kan virke.

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

Dobbelt NAT er ikke dobbelt VPN. Oversættelse omskriver adresser og porte; den tilføjer ikke en anden krypteret tunnel, og den krypterer ikke noget. Det er vigtigt at holde de to ideer adskilt, fordi løsningerne er helt forskellige, og en af dem kræver en samtale med din udbyder i stedet for en indstillingsside.

Udgående: klienten spørger, oversætterne mapper

En udgående tunnel begynder med en pakke fra din maskine, så hver oversætter kan oprette en mapping og lukke svaret ind igen. Protokollen, porten og inaktivitetstimerne afgør, om den mapping overlever længe nok til at være nyttig. De fleste forbrugerroutere klarer dette helt uden konfiguration.

De fejl, der faktisk opstår, handler normalt om timeouts og protokolunderstøttelse frem for antallet af routere. En tunnel, der falder efter få minutters stilhed, er en mapping, der udløber, og en keepalive er det standardmæssige svar. IPsec har standard NAT-traversal-udvidelser, så det er ganske enkelt forkert at påstå, at det ikke kan krydse oversættelse. Hvis tunnellen slet ikke etableres, så se på endepunktet og legitimationsoplysningerne, før du bebrejder topologien.

wg show
ping -c3 10.8.0.1

Stop, hvis den udgående tunnel virker fra ét netværk og ikke fra et andet. Den sammenligning handler om netværkene, ikke om antallet af routere.

Indgående: videresendelse dækker kun udstyr, du ejer

At hoste en server er den modsatte retning: en ny forbindelse ankommer fra internettet og skal nå din maskine gennem hvert lag. En portvideresendelsesregel på den indre router hjælper kun, hvis den ydre oversætter også leverer den trafik til dig. At gentage den lokale regel giver ikke kontrol over udbyderens udstyr.

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

Sammenlign den indre routers WAN-adresse med den offentlige adresse, du observerede, og noter, hvor hver værdi kom fra. Hvis WAN-adressen er privat eller i det delte område, udfører det ydre lag en oversættelse, du ikke kan konfigurere. Spørg udbyderen, hvilken indgående tilgængelighed den understøtter, før du bruger en aften på regler, der ikke kan træde i kraft. At fjerne en router eller slå en firewall bredt fra er ikke en diagnose, og det er en dårlig handel for én åben port.

Stop, hvis det ydre lag er udbyderens, og det ikke videresender. Så er de understøttede svar en anden adgangsmetode eller et relay, ikke endnu en regel på din side.

Test én variabel ad gangen

Ændr én ting pr. test, og noter resultatet, fordi en dobbelt-NAT-sti har flere variabler end en sti med én router. Hold profilen og enheden fast, og sammenlign derefter et andet adgangsnetværk. Noter, om forhandlingen fejler, om sessionen falder efter inaktivitet, eller om kun private destinationer fejler. De tre observationer peger på tre forskellige lag.

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

Overlappende private undernet er en separat fælde, som ingen mængde oversættelse retter. Hvis dit hjemmenetværk og fjernnetværket bruger det samme område, opstår der en rutekonflikt, uanset hvor mange oversættere der står imellem. Omnummerering af den ene side er det eneste holdbare svar.

Fjern-gatewayen fortjener samme opmærksomhed, fordi dens videresendelsesregler og returruter kan være den manglende brik. En tunnel, der autentificerer, kan stadig ikke have nogen brugbar applikationssti, og den fejl ser identisk ud fra klientsiden. Gennemgangen slutter, når du kan sige, hvilken retning der fejler, og hvilket lag der ejer den.