Thuis-VPN-server niet bereikbaar: loop de NAT-keten af

De server antwoordt op de LAN, de poortdoorgiftregel ziet er goed uit, en toch kan een externe client geen verbinding maken. Grens voor grens naar buiten lopen is sneller dan de regel een vierde keer bewerken, omdat elke grens zijn eigen bewijs achterlaat: de WAN-pagina van de router, de vertaling van de provider en de luisteraar op de host. Begin bij de beheerpagina die u al open hebt en eindig met een test vanaf een netwerk dat u niet beheert. Noteer elk resultaat onderweg, want de volgorde is de diagnose en een onthouden getal is geen bewijs. Als u alleen een uitgaande tunnel nodig hebt, is vertaling niet uw probleem: alleen ongevraagd inkomend verkeer wordt geblokkeerd.

Begin bij de WAN-pagina van de router

Log in op de router en lees de statuspagina in plaats van de lijst met poortdoorgiften. Noteer het WAN-adres, de interface waarbij het hoort en of het verbindingstype DHCP, PPPoE of iets is dat de provider levert. Vergelijk dat adres vervolgens met wat een externe dienst meldt, met een telefoon op mobiele data zodat de waarneming niet via dezelfde router teruggaat. De twee getallen beantwoorden verschillende vragen, en ze vergelijken is het hele doel van deze stap.

Een WAN-adres dat afwijkt van het waargenomen openbare adres betekent dat er minstens één vertaler boven de router zit. Dat is nog geen fout, omdat veel providers ontwerpmatig vertalen en de dienst toch werkt. Als de twee overeenkomen, bezit de router het adres waarschijnlijk en is het probleem uw netwerk in geschoven. Schrijf het paar in elk geval met datum op, want providers delen adressen opnieuw uit en een vergelijking met de notities van vorige maand is waardeloos.

Ga één hop omhoog

Voer een traceroute uit vanaf de router zelf en lees de eerste paar hops. Herhaalde openbare adressen, een eerste hop die antwoordt met een privéadres of een adres binnen het gedeelde bereik 100.64.0.0/10 wijzen allemaal op een vertaler hogerop. RFC 6598 definieert dat bereik juist voor dit soort uitrol, en daarom is het in het WAN-veld een sterk signaal en geen curiositeit. Twee vertalers in het pad maken het spoor minder duidelijk, dus lees het patroon en niet één regel.

Sommige providers tonen het toegewezen adres alleen in het klantenportaal, dus kijk daar voordat u concludeert dat de router liegt. Een portaaladres dat overeenkomt met uw externe waarneming terwijl de router iets anders meldt, is het duidelijkste bewijs van een vertaler hogerop. Bewaar beide pagina's in het wijzigingslog, want de discussie over wie welke grens bezit gaat veel sneller met twee gedateerde afbeeldingen.

Bevestig de luisteraar en de doorsturing

Een test op de LAN bewijst dat de dienst lokaal werkt en bewijst niets over bereikbaarheid van buitenaf. Veel routers beantwoorden hun eigen doorstuurregel van binnenuit, zodat een haakjestest slaagt terwijl het externe pad nog dicht is. Bevestig dat de daemon gebonden is aan het adres en de poort die u vermoedt, en test daarna van buitenaf. Alles hieronder is alleen lezen.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Als de externe test laat zien dat er geen pakket bij de router aankomt, is de drop hogerop gebeurd en geen enkele lokale regel lost dat op. Als pakketten wel aankomen en niets antwoordt, is de volgende grens de luisteraar of de firewall van de host. Een pakketopname op de host beslist welke van de twee u bekijkt, en dat kost minder tijd dan nog een ronde regels raden. Houd de luisteraar en zijn transport ongewijzigd terwijl u vergelijkt, anders beantwoordt de volgende test een andere vraag.

Verander de topologie, niet dezelfde regel

Als de vertaler van de provider is, is de oplossing een ander pad en niet nog een doorsturing. Een kleine VPS met een openbaar adres, verbonden via een uitgaande tunnel vanaf de thuiszijde, zet een bereikbaar eindpunt voor de dienst. Een openbaar adres van de provider is eenvoudiger waar het bestaat en meestal goedkoper dan een machine draaien. IPv6 haalt de vertaling helemaal weg, mits het klantnetwerk, de DNS-records en het firewallbeleid het allemaal ondersteunen.

Dynamische DNS werkt alleen een naam bij; het maakt geen bereikbaarheid, en het richten op een gedeeld adres stuurt clients naar een providergateway die andere abonnees ook gebruiken. Die storing lijkt precies op een dode server, en daarom is het verslag van de eerdere stappen belangrijk. Noteer naar welk adres de naam oploste toen de test faalde, en bewaar het antwoord bij het testresultaat.

Herschrijf het plan rond de grens die u beheert: de luisteraar, de tunnel en de routes. Laat de oude doorsturing alleen staan zolang die nog iets waars beschrijft, want een regel die niet meer bij de topologie past is erger dan geen regel. Noteer welke laag werkelijk blokkeerde en welk bewijs dat liet zien. Anders herhaalt de volgende persoon die de beheerpagina opent elke stap van deze wandeling vanaf het begin.