Hemmets VPN-server går inte att nå: gå igenom NAT-kedjan

Servern svarar på LAN, regeln för portvidarebefordran ser korrekt ut, och ändå kan en extern klient inte ansluta. Att gå utåt en gräns i taget är snabbare än att redigera regeln en fjärde gång, eftersom varje gräns lämnar sitt eget bevis: routerns WAN-sida, leverantörens översättning och lyssnaren på värden. Börja på administratörssidan du redan har öppen och avsluta med ett test från ett nätverk du inte kontrollerar. Skriv ner varje resultat medan du går, eftersom ordningen är diagnosen och ett ihågkommet tal inte är bevis. Om du bara behöver en utgående tunnel är översättningen inte ditt problem: bara oombedd inkommande trafik blockeras.

Börja på routerns WAN-sida

Logga in på routern och läs statussidan i stället för listan över portvidarebefordringar. Notera WAN-adressen, gränssnittet den hör till och om anslutningstypen är DHCP, PPPoE eller något leverantören tillhandahåller. Jämför sedan den adressen med vad en extern tjänst rapporterar, med en telefon på mobildata så att observationen inte går tillbaka genom samma router. De två talen svarar på olika frågor, och att jämföra dem är hela poängen med det här steget.

En WAN-adress som skiljer sig från den observerade offentliga adressen betyder att minst en översättare sitter ovanför routern. Det är ännu inte ett fel, eftersom många leverantörer översätter enligt design och tjänsten fungerar ändå. Om de två stämmer överens äger routern troligen adressen och problemet har flyttat in i ditt nätverk. Skriv i alla fall ner paret med datum, eftersom leverantörer tilldelar adresser på nytt och en jämförelse med förra månadens anteckningar är värdelös.

Gå ett hopp uppåt

Kör traceroute från routern själv och läs de första hoppen. Upprepade offentliga adresser, ett första hopp som svarar med en privat adress eller en adress inom det delade intervallet 100.64.0.0/10 pekar alla på en översättare högre upp. RFC 6598 definierar just det intervallet för sådan utrullning, och därför är det en stark signal och inte en kuriositet att se det i WAN-fältet. Två översättare i vägen gör spåret mindre tydligt, så läs mönstret och inte en enda rad.

Vissa leverantörer visar den tilldelade adressen bara i kundportalen, så titta där innan du drar slutsatsen att routern ljuger. En portaladress som stämmer med din externa observation medan routern rapporterar något annat är det tydligaste beviset på en översättare högre upp. Spara båda sidorna i ändringsloggen, eftersom diskussionen om vem som äger vilken gräns går mycket snabbare med två daterade bilder.

Bekräfta lyssnaren och vidarebefordran

Ett test på LAN bevisar att tjänsten fungerar lokalt och bevisar ingenting om nåbarhet utifrån. Många routrar svarar på sin egen vidarebefordringsregel inifrån, så ett hårnålstest lyckas medan den externa vägen fortfarande är stängd. Bekräfta att daemonen är bunden till den adress och port du tror, och testa sedan utifrån. Allt nedan är bara läsning.

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

Om det externa testet visar att inget paket når routern skedde tappet högre upp och ingen lokal regel åtgärdar det. Om paketen kommer och ingenting svarar är lyssnaren eller värdens brandvägg nästa gräns. En paketfångst på värden avgör vilken av de två du tittar på, och det tar kortare tid än ännu en runda med gissningar om regler. Håll lyssnaren och dess transport oförändrade medan du jämför, annars svarar nästa test på en annan fråga.

Ändra topologin, inte samma regel

När översättaren tillhör leverantören är lösningen en annan väg och inte ännu en vidarebefordran. En liten VPS med offentlig adress, ansluten med en utgående tunnel från hemsidan, sätter en nåbar ändpunkt framför tjänsten. En offentlig adress från leverantören är enklare där den finns och vanligtvis billigare än att driva en maskin. IPv6 tar bort översättningen helt, förutsatt att klientnätet, DNS-posterna och brandväggspolicyn alla stöder det.

Dynamisk DNS uppdaterar bara ett namn; det skapar ingen nåbarhet, och att peka det mot en delad adress skickar klienter till en leverantörsgateway som andra abonnenter också använder. Det felet ser exakt ut som en död server, och därför är anteckningen från de tidigare stegen viktig. Notera vilken adress namnet löstes till när testet misslyckades, och spara svaret tillsammans med testresultatet.

Skriv om planen kring den gräns du kontrollerar: lyssnaren, tunneln och rutterna. Behåll den gamla vidarebefordran bara så länge den fortfarande beskriver något sant, eftersom en regel som inte längre passar topologin är värre än ingen regel. Notera vilket lager som faktiskt blockerade och vilket bevis som visade det. Annars upprepar nästa person som öppnar administratörssidan varje steg i den här vandringen från början.