Dubbel NAT och din VPN: klienten fungerar, servern gör det inte

Din router står bakom en annan router, WAN-adressen är privat, och VPN-klienten ansluter ändå. Den kombinationen förvånar folk som väntar sig att dubbel NAT ska bryta tunnlarna, men det är just utgående anslutningar som översättningen hanterar bäst. Att driva en VPN-server bakom samma två lager är fallet som vanligtvis misslyckas. Rita upp anslutningens riktning innan du ändrar något.

Rita först upp anslutningens riktning

Öppna den inre routerns statussida och skriv ner dess WAN-adress, jämför den sedan med adressen som en offentlig tjänst rapporterar till dig. Om de två skiljer sig finns det minst en översättare mellan din router och internet. Om WAN-adressen ligger inom 100.64.0.0/10, tillhör den yttre översättaren troligen din leverantör, och du kontrollerar den inte. Dessa två fakta avgör vilket av de senare stegen som alls kan fungera.

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

Dubbel NAT är inte dubbel VPN. Översättningen skriver om adresser och portar; den lägger inte till en andra krypterad tunnel och krypterar ingenting. Att hålla de två idéerna isär är viktigt eftersom lösningarna är helt olika, och en av dem kräver ett samtal med din leverantör i stället för en inställningssida.

Utgående: klienten frågar, översättarna mappar

En utgående tunnel börjar med ett paket från din maskin, så varje översättare kan skapa en mappning och släppa in svaret igen. Protokollet, porten och inaktivitetstimmarna avgör om mappningen överlever tillräckligt länge för att vara användbar. De flesta konsumentroutrar klarar detta helt utan konfiguration.

De fel som faktiskt dyker upp handlar oftast om tidsgränser och protokollstöd, inte om antalet routrar. En tunnel som faller efter några minuters tystnad är en mappning som löper ut, och en keepalive är det vanliga svaret. IPsec har standardiserade NAT-traversal-tillägg, så påståendet att det inte kan korsa en översättning är helt enkelt fel. Om tunneln inte etableras alls, titta på slutpunkten och inloggningsuppgifterna innan du skyller på topologin.

wg show
ping -c3 10.8.0.1

Stoppa om den utgående tunneln fungerar från ett nätverk och inte från ett annat. Den jämförelsen handlar om nätverken, inte om antalet routrar.

Inkommande: vidarebefordran täcker bara utrustning du äger

Att driva en server är motsatt riktning: en ny anslutning kommer från internet och måste nå din maskin genom varje lager. En portvidarebefordringsregel på den inre routern hjälper bara om den yttre översättaren också levererar den trafiken till dig. Att upprepa den lokala regeln ger dig inte kontroll över leverantörens utrustning.

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

Jämför den inre routerns WAN-adress med den offentliga adress du observerade, och notera var varje värde kom ifrån. Om WAN-adressen är privat eller i det delade intervallet utför det yttre lagret en översättning som du inte kan konfigurera. Fråga leverantören vilken inkommande nåbarhet den stöder innan du lägger en hel kväll på regler som inte kan träda i kraft. Att ta bort en router eller stänga av en brandvägg brett är ingen diagnos, och det är ett dåligt byte för en enda öppen port.

Stoppa om det yttre lagret tillhör leverantören och det inte vidarebefordrar. Då är de stödda svaren en annan åtkomstmetod eller en relay, inte ännu en regel på din sida.

Testa en variabel i taget

Ändra en sak per test och notera resultatet, eftersom en dubbel-NAT-väg har fler variabler än en väg med en enda router. Håll profilen och enheten fasta och jämför sedan ett annat åtkomstnätverk. Notera om förhandlingen misslyckas, om sessionen faller efter inaktivitet, eller om bara privata mål misslyckas. De tre observationerna pekar på tre olika lager.

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

Överlappande privata subnät är en separat fälla som ingen mängd översättning åtgärdar. Om ditt hemnätverk och fjärrnätverket använder samma intervall uppstår en rutkonflikt oavsett hur många översättare som står emellan. Att numrera om ena sidan är det enda hållbara svaret.

Fjärrgatewayen förtjänar samma uppmärksamhet, eftersom dess vidarebefordringsregler och returvägar kan vara den saknade pusselbiten. En tunnel som autentiserar kan fortfarande sakna en användbar applikationsväg, och det felet ser identiskt ut från klientsidan. Genomgången slutar när du kan säga vilken riktning som misslyckas och vilket lager som äger den.