Hjemme-VPN-server ikke tilgjengelig: gå gjennom NAT-kjeden

Serveren svarer på LAN, regelen for portvideresending ser riktig ut, og likevel får en ekstern klient ikke forbindelse. Å gå utover én grense om gangen er raskere enn å redigere regelen en fjerde gang, fordi hver grense etterlater sitt eget bevis: WAN-siden i ruteren, oversettelsen hos leverandøren og lytteren på verten. Begynn på administrasjonssiden du allerede har åpen og avslutt med en test fra et nettverk du ikke kontrollerer. Skriv ned hvert resultat underveis, fordi rekkefølgen er diagnosen og et husket tall er ikke bevis. Hvis du bare trenger en utgående tunnel, er oversettelse ikke problemet ditt: bare uoppfordret innkommende trafikk blokkeres.

Begynn på WAN-siden i ruteren

Logg inn på ruteren og les statussiden i stedet for listen over portvideresendinger. Noter WAN-adressen, grensesnittet den hører til, og om forbindelsestypen er DHCP, PPPoE eller noe leverandøren skaffer. Sammenlign deretter den adressen med det en ekstern tjeneste rapporterer, og bruk en telefon på mobildata slik at observasjonen ikke går tilbake gjennom samme ruter. De to tallene svarer på ulike spørsmål, og å sammenligne dem er hele poenget med dette trinnet.

En WAN-adresse som avviker fra den observerte offentlige adressen betyr at minst én oversetter sitter over ruteren. Det er ennå ikke en feil, fordi mange leverandører oversetter ved design og tjenesten virker fortsatt. Hvis de to stemmer, eier ruteren sannsynligvis adressen og problemet har flyttet seg inn i nettverket ditt. Uansett bør du skrive ned paret med dato, fordi leverandører tildeler adresser på nytt og en sammenligning med forrige måneds notater er verdiløs.

Gå ett hopp oppover

Kjør traceroute fra ruteren selv og les de første hoppene. Gjentatte offentlige adresser, et første hopp som svarer med en privat adresse eller en adresse innenfor det delte området 100.64.0.0/10 peker alle på en oversetter lenger oppe. RFC 6598 definerer nettopp dette området for slik utrulling, og derfor er det et sterkt signal og ikke en kuriositet å se det i WAN-feltet. To oversettere i banen gjør sporet mindre tydelig, så les mønsteret og ikke én linje.

Noen leverandører viser den tildelte adressen bare i kundeportalen, så se der før du konkluderer med at ruteren lyver. En portaladresse som samsvarer med din eksterne observasjon mens ruteren rapporterer noe annet, er det klareste beviset på en oversetter lenger oppe. Ta vare på begge sidene i endringsloggen, fordi diskusjonen om hvem som eier hvilken grense går mye raskere med to daterte bilder.

Bekreft lytteren og videresendingen

En test på LAN beviser at tjenesten virker lokalt og beviser ingenting om tilgjengelighet utenfra. Mange rutere svarer på sin egen videresendingsregel innenfra, slik at en hårnåltest lykkes mens den eksterne veien fortsatt er stengt. Bekreft at daemonen er bundet til den adressen og porten du tror, og test deretter utenfra. Alt nedenfor er bare lesing.

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 testen viser at ingen pakke når ruteren, skjedde fallet lenger oppe og ingen lokal regel vil rette det. Hvis pakkene kommer og ingenting svarer, er lytteren eller vertens brannmur neste grense. En pakkefangst på verten avgjør hvilken av de to du ser på, og det tar kortere tid enn enda en runde med gjetting av regler. Hold lytteren og transporten uendret mens du sammenligner, ellers svarer neste test på et annet spørsmål.

Endre topologien, ikke den samme regelen

Når oversetteren tilhører leverandøren, er løsningen en annen vei og ikke nok en videresending. En liten VPS med offentlig adresse, koblet til med en utgående tunnel fra hjemmesiden, setter et tilgjengelig endepunkt foran tjenesten. En offentlig adresse fra leverandøren er enklere der den finnes og vanligvis billigere enn å drive en maskin. IPv6 fjerner oversettelsen helt, forutsatt at klientnettet, DNS-oppføringene og brannmurpolicyen alle støtter det.

Dynamisk DNS oppdaterer bare et navn; det skaper ikke tilgjengelighet, og å peke det mot en delt adresse sender klienter til en leverandørgateway som andre abonnenter også bruker. Den feilen ser nøyaktig ut som en død server, og derfor er notatet fra de tidligere trinnene viktig. Noter hvilken adresse navnet ble løst til da testen feilet, og ta vare på svaret sammen med testresultatet.

Skriv planen på nytt rundt grensen du kontrollerer: lytteren, tunnelen og rutene. Behold den gamle videresendingen bare så lenge den fortsatt beskriver noe sant, fordi en regel som ikke lenger passer med topologien er verre enn ingen regel. Noter hvilket lag som faktisk blokkerte og hvilket bevis som viste det. Ellers gjentar den neste som åpner administrasjonssiden hvert trinn i denne vandringen fra begynnelsen.