Dubbel NAT en je VPN: de client werkt, de server niet

Je router staat achter een andere router, het WAN-adres is privé, en de VPN-client maakt toch verbinding. Die combinatie verrast mensen die verwachten dat dubbel NAT de tunnels breekt, maar juist uitgaande verbindingen handelt de vertaling het best af. Een VPN-server achter dezelfde twee lagen hosten is het geval dat meestal mislukt. Teken de richting van de verbinding voordat je iets verandert.

Teken eerst de richting van de verbinding

Open de statuspagina van de binnenrouter en noteer het WAN-adres, en vergelijk dat daarna met het adres dat een publieke dienst je meldt. Als de twee verschillen, staat er minstens één vertaler tussen je router en het internet. Als het WAN-adres binnen 100.64.0.0/10 valt, is de buitenste vertaler waarschijnlijk van je provider, en die beheer je niet. Die twee feiten bepalen welke van de latere stappen überhaupt kan werken.

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

Dubbel NAT is geen dubbel VPN. De vertaling herschrijft adressen en poorten; ze voegt geen tweede versleutelde tunnel toe en versleutelt niets. De twee ideeën gescheiden houden is belangrijk omdat de oplossingen totaal verschillend zijn, en een ervan vraagt een gesprek met je provider in plaats van een instellingenpagina.

Uitgaand: de client vraagt, de vertalers mappen

Een uitgaande tunnel begint met een pakket van je machine, dus elke vertaler kan een mapping maken en het antwoord weer binnenlaten. Het protocol, de poort en de inactiviteitstimers bepalen of die mapping lang genoeg overleeft om nuttig te zijn. De meeste consumentenrouters doen dit zonder enige configuratie.

De fouten die echt optreden gaan meestal over time-outs en protocolondersteuning, niet over het aantal routers. Een tunnel die na een paar minuten stilte wegvalt, is een mapping die verloopt, en een keepalive is het standaardantwoord. IPsec heeft standaard NAT-traversal-extensies, dus beweren dat het geen vertaling kan passeren is simpelweg onjuist. Als de tunnel helemaal niet tot stand komt, kijk dan naar het eindpunt en de inloggegevens voordat je de topologie de schuld geeft.

wg show
ping -c3 10.8.0.1

Stop als de uitgaande tunnel vanuit het ene netwerk werkt en vanuit het andere niet. Die vergelijking gaat over de netwerken, niet over het aantal routers.

Inkomend: doorsturen dekt alleen apparatuur die je bezit

Een server hosten is de omgekeerde richting: een nieuwe verbinding komt van het internet en moet je machine door elke laag heen bereiken. Een poortdoorschuifregel op de binnenrouter helpt alleen als de buitenste vertaler dat verkeer ook bij jou aflevert. De lokale regel herhalen geeft je geen controle over de apparatuur van de provider.

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

Vergelijk het WAN-adres van de binnenrouter met het publieke adres dat je hebt waargenomen, en noteer waar elke waarde vandaan kwam. Als het WAN-adres privé is of in het gedeelde bereik ligt, doet de buitenste laag een vertaling die je niet kunt configureren. Vraag de provider welke inkomende bereikbaarheid hij ondersteunt voordat je een hele avond besteedt aan regels die niet kunnen ingaan. Een router verwijderen of een firewall breed uitschakelen is geen diagnose, en het is een slechte ruil voor één open poort.

Stop als de buitenste laag van de provider is en niet doorstuurt. Dan zijn de ondersteunde antwoorden een andere toegangsmethode of een relay, niet nog een regel aan jouw kant.

Test één variabele tegelijk

Verander één ding per test en noteer het resultaat, want een dubbel-NAT-pad heeft meer variabelen dan een pad met één router. Houd het profiel en het apparaat vast en vergelijk daarna een ander toegangsnetwerk. Noteer of de onderhandeling mislukt, of de sessie na inactiviteit wegvalt, of dat alleen private bestemmingen falen. Die drie observaties wijzen op drie verschillende lagen.

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

Overlappende private subnetten zijn een aparte valkuil die geen enkele hoeveelheid vertaling oplost. Als je thuisnetwerk en het externe netwerk dezelfde reeks gebruiken, ontstaat er een routeconflict ongeacht hoeveel vertalers ertussen zitten. Eén kant opnieuw nummeren is het enige duurzame antwoord.

De externe gateway verdient dezelfde aandacht, want de doorgifteregegels en retourroutes kunnen het ontbrekende stuk zijn. Een tunnel die authenticeert kan nog steeds geen bruikbaar applicatiepad hebben, en die fout ziet er vanaf de clientkant identiek uit. De wandeling eindigt wanneer je kunt zeggen welke richting faalt en welke laag daar verantwoordelijk voor is.