Heime-VPN-tenar ikkje tilgjengeleg: gå gjennom NAT-kjeda
Rutaren, omsetjaren hos leverandøren og lyttaren på tenaren er tre skilde grenser. Gå utover frå administrasjonssida før du skriv den same vidaresendingsregelen på nytt.
Tenaren svarar på LAN, regelen for portvidaresending ser rett ut, og likevel får ein ekstern klient ikkje samband. Å gå utover éi grense om gongen er snøggare enn å endre regelen ein fjerde gong, fordi kvar grense let att sitt eige prov: WAN-sida i rutaren, omsetjinga hos leverandøren og lyttaren på verten. Byrja på administrasjonssida du alt har open og avslutt med ein test frå eit nettverk du ikkje styrer. Skriv ned kvar resultat undervegs, fordi rekkjefølgja er diagnosen og eit hugse tal er ikkje prov. Viss du berre treng ein utgåande tunnel, er omsetjing ikkje problemet ditt: berre uoppmoda innkomande trafikk vert blokkert.
Byrja på WAN-sida i rutaren
Logg inn på rutaren og les statussida i staden for lista over portvidaresendingar. Noter WAN-adressa, grensesnittet ho høyrer til, og om sambandstypen er DHCP, PPPoE eller noko leverandøren skaffar. Samanlikn så den adressa med det ein ekstern teneste rapporterer, og bruk ein telefon på mobildata slik at observasjonen ikkje går attende gjennom same rutar. Dei to tala svarar på ulike spørsmål, og å samanlikne dei er heile poenget med dette steget.
Ei WAN-adresse som skil seg frå den observerte offentlege adressa tyder på at minst éin omsetjar sit over rutaren. Det er enno ikkje ein feil, fordi mange leverandørar omset ved design og tenesta verkar framleis. Viss dei to stemmer, eig rutaren truleg adressa og problemet har flytta seg inn i nettverket ditt. Uansett bør du skrive ned paret med dato, fordi leverandørar tildeler adresser på nytt og ein samanliknad med førre månads notat er verdilaus.
Gå eitt hopp oppover
Køyr traceroute frå rutaren sjølv og les dei fyrste hoppa. Gjentekne offentlege adresser, eit fyrste hopp som svarar med ei privat adresse eller ei adresse innanfor det delte området 100.64.0.0/10 peikar alle på ein omsetjar lenger oppe. RFC 6598 definerer nettopp dette området for slik utrulling, og difor er det eit sterkt signal og ikkje ei kuriositet å sjå det i WAN-feltet. To omsetjarar i banen gjer sporet mindre tydeleg, så les mønsteret og ikkje éi line.
Nokre leverandørar viser den tildelte adressa berre i kundeportalen, så sjå der før du konkluderer med at rutaren lyg. Ei portaladresse som samsvarar med din eksterne observasjon medan rutaren rapporterer noko anna, er det klåraste provet på ein omsetjar lenger oppe. Ta vare på båe sidene i endringsloggen, fordi diskusjonen om kven som eig kva grense går mykje snøggare med to daterte bilete.
Stadfest lyttaren og vidaresendinga
Ein test på LAN provar at tenesta verkar lokalt og provar ingenting om tilgjenge utanfrå. Mange rutarar svarar på sin eigen vidaresendingsregel innanfrå, slik at ein hårnåltest lukkast medan den eksterne vegen enno er stengd. Stadfest at daemonen er bunden til den adressa og porten du trur, og test deretter utanfrå. Alt nedanfor er berre 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
Viss den eksterne testen viser at ingen pakke når rutaren, skjedde fallet lenger oppe og ingen lokal regel vil rette det. Viss pakkane kjem og ingenting svarar, er lyttaren eller brannmuren på verten neste grense. Ein pakkefangst på verten avgjer kva av dei to du ser på, og det tek kortare tid enn endå ein runde med gjetting av reglar. Hald lyttaren og transporten hans uendra medan du samanliknar, elles svarar neste test på eit anna spørsmål.
Endre topologien, ikkje den same regelen
Når omsetjaren høyrer til leverandøren, er løysinga ein annan veg og ikkje endå ei vidaresending. Ein liten VPS med offentleg adresse, knytt til med ein utgåande tunnel frå heimesida, set eit tilgjengeleg endepunkt framfor tenesta. Ei offentleg adresse frå leverandøren er enklare der ho finst og vanlegvis billegare enn å drive ein maskin. IPv6 fjernar omsetjinga heilt, føresett at klientnettverket, DNS-oppføringane og brannmurpolitikken alle støttar det.
Dynamisk DNS oppdaterer berre eit namn; det skaper ikkje tilgjenge, og å peike det mot ei delt adresse sender klientar til ein leverandørgateway som andre abonnentar òg brukar. Den feilen ser nøyaktig ut som ein daud tenar, og difor er notatet frå dei tidlegare stega viktig. Noter kva adresse namnet vart løyst til då testen feila, og ta vare på svaret saman med testresultatet.
Skriv planen på nytt kring grensa du styrer: lyttaren, tunnelen og rutene. Hald den gamle vidaresendinga berre så lenge ho enno skildrar noko sant, fordi ein regel som ikkje lenger passar med topologien er verre enn ingen regel. Noter kva lag som faktisk blokkerte og kva prov som viste det. Elles gjer den neste som opnar administrasjonssida om att kvart steg i denne vandringa frå byrjinga.