Hjemme-VPN-server ikke tilgængelig: gå NAT-kæden igennem

Serveren svarer på LAN, portvideresendelsesreglen ser rigtig ud, og alligevel kan en ekstern klient ikke oprette forbindelse. At gå udad én grænse ad gangen er hurtigere end at redigere reglen en fjerde gang, fordi hver grænse efterlader sit eget bevis: routerens WAN-side, udbyderens oversættelse og lytteren på værten. Start på den administrationsside, du allerede har åben, og slut med en test fra et netværk, du ikke kontrollerer. Skriv hvert resultat ned undervejs, fordi rækkefølgen er diagnosen, og et husket tal er ikke bevis. Hvis du kun har brug for en udgående tunnel, er oversættelse ikke dit problem: kun uopfordret indgående trafik blokeres.

Start på routerens WAN-side

Log ind på routeren og læs statussiden i stedet for portvideresendelseslisten. Noter WAN-adressen, det interface den hører til, og om forbindelsestypen er DHCP, PPPoE eller noget, som udbyderen stiller til rådighed. Sammenlign derefter den adresse med det, en ekstern tjeneste rapporterer, og brug en telefon på mobildata, så observationen ikke rejser tilbage gennem den samme router. De to tal besvarer forskellige spørgsmål, og at sammenligne dem er hele pointen med dette trin.

En WAN-adresse, der afviger fra den observerede offentlige adresse, betyder, at mindst én oversætter sidder oven over routeren. Det er endnu ikke en fejl, fordi mange udbydere oversætter ved design, og tjenesten virker stadig. Hvis de to stemmer overens, ejer routeren sandsynligvis adressen, og problemet er flyttet ind i dit netværk. Under alle omstændigheder skal du skrive parret ned med datoen, fordi udbydere tildeler adresser igen, og en sammenligning med sidste måneds noter er værdiløs.

Gå et hop opad

Kør traceroute fra routeren selv, og læs de første par hop. Gentagne offentlige adresser, et første hop, der svarer med en privat adresse, eller en adresse inden for det delte område 100.64.0.0/10 peger alle på en oversætter længere oppe. RFC 6598 definerer netop det område til denne slags udrulning, og derfor er det et stærkt signal og ikke en kuriositet at se det i WAN-feltet. To oversættere i stien gør sporet mindre tydeligt, så læs mønstret i stedet for en enkelt linje.

Nogle udbydere viser kun den tildelte adresse i kundeportalen, så kig der, før du konkluderer, at routeren lyver. En portaladresse, der matcher din eksterne observation, mens routeren rapporterer noget andet, er det klareste bevis på en oversætter længere oppe. Gem begge sider i ændringsloggen, fordi diskussionen om, hvem der ejer hvilken grænse, går meget hurtigere med to daterede billeder.

Bekræft lytteren og videresendelsen

En LAN-test beviser, at tjenesten virker lokalt, og beviser intet om tilgængelighed udefra. Mange routere svarer på deres egen videresendelsesregel indefra, så en hårnåletest lykkes, mens den eksterne vej stadig er lukket. Bekræft, at daemonen er bundet til den adresse og port, du tror, den bruger, og test derefter udefra. Alt nedenfor er kun 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

Hvis den eksterne test viser, at ingen pakke når routeren, er tabet sket længere oppe, og ingen lokal regel kan rette det. Hvis pakkerne ankommer, og intet svarer, er lytteren eller værtens firewall den næste grænse. En pakkefangst på værten afgør, hvilken af de to du kigger på, og det tager kortere tid end endnu en runde med regelsjusk. Hold lytteren og dens transport uændret, mens du sammenligner, ellers besvarer den næste test et andet spørgsmål.

Ændr topologien, ikke den samme regel

Når oversætteren tilhører udbyderen, er løsningen en anden vej og ikke endnu en videresendelse. En lille VPS med offentlig adresse, forbundet med en udgående tunnel fra hjemmesiden, sætter et tilgængeligt endepunkt foran tjenesten. En offentlig adresse fra udbyderen er enklere, hvor den findes, og normalt billigere end at drive en maskine. IPv6 fjerner oversættelsen helt, forudsat at klientnetværket, DNS-posterne og firewallpolitikken alle understøtter det.

Dynamisk DNS opdaterer kun et navn; det skaber ikke tilgængelighed, og at pege det mod en delt adresse sender klienter til en udbydergateway, som andre abonnenter også bruger. Den fejl ligner præcis en død server, og derfor er notatet fra de tidligere trin vigtigt. Noter, hvilken adresse navnet blev opløst til, da testen fejlede, og gem svaret sammen med testresultatet.

Skriv planen omkring den grænse, du kontrollerer: lytteren, tunnelen og ruterne. Behold den gamle videresendelse kun, mens den stadig beskriver noget sandt, fordi en regel, der ikke længere passer til topologien, er værre end ingen regel. Noter, hvilket lag der faktisk blokerede, og hvilket bevis der viste det. Ellers gentager den næste person, der åbner administrationssiden, hvert trin i denne vandring fra begyndelsen.