Utdatert DDNS-post eller øydelagd VPN-endepunkt: slik skil du dei

Utanfrå ser eit utdatert vertsnamn og ein øydelagd VPN identiske ut. Klienten slår opp eit namn, namnet peikar ein stad, og tilkoplinga går ut på tid eller blir avvist. Det eine er eit DNS-oppdateringsproblem, det andre eit autentiserings- eller vidaresendingsproblem, og skilnaden blir først tydeleg når du samanliknar adressa som blir publisert med adressa linja di faktisk har.

To feil som ser like ut

Den første feilen er at posten framleis listar WAN-adressa frå i går. Den andre er at posten er korrekt og tunnelen avviser deg av sine eigne grunnar. Begge gir same melding på klienten, og freistinga er å byrje å generere sertifikat på nytt.

Rekkefølgja har noko å seie her. Å sjekke DNS tek eitt minutt og er reversibelt. Å generere ein CA på nytt er verken det eine eller det andre.

Samanlikn adressene før alt anna

Spør nettverkseigaren kva adresse linja har akkurat no, og spør deretter DNS kva han publiserer. dig +short vpn.example.com gir svaret klienten din vil få, og dig @1.1.1.1 vpn.example.com viser om ein annan resolver ser noko anna. Viss dei to er usamde, ser du på cacheåtferd og ikkje ein øydelagd oppdaterar.

Eit rekursivt svar kan henge etter ei oppdatering med TTL-en sin, så hald den autoritative posten og det laptoppen din har cacha i separate boksar.

Kva oppdateringslegitimasjonen eigentleg er

Eldre DDNS-einingar autentiserer ofte med sjølve kontopassordet, og difor øydelegg eit byte av det passordet dei lydlaust. Dei held fram med å prøve med den gamle verdien og rapporterer ingenting nyttig. No-IP sin rettleiar for einingpassord dokumenterer nettopp dette kompatibilitetsproblemet på eldre maskinvare, og det fornuftige svaret er ein avgrensa oppdateringslegitimasjon i staden for eit svakare kontopassord.

Nyare mekanismar gjev ut eit eige oppdateringstoken eller ein nøkkel med sin eigen livssyklus. Det er verdien du skal rotere inn i rutaren, og den du skal føre i legitimasjonsregisteret ditt. Det er heller ikkje verdien du skal lime inn i ein chattråd medan du feilsøkjer.

Sjå på den ikkje-hemmelege statusen til oppdateraren: tidspunkt for siste suksess, svarkategori og vertsnamnet han meiner å eige. Ei avvising av legitimasjon og ein tilkoplingsfeil krev ulike rettingar.

Kva ei DNS-retting ikkje kan gjere

Å rette posten skaper ikkje innkomande tilgjenge. Viss linja sit bak carrier-grade NAT, vil ingen vertsnamn få ei innkomande tilkopling til å verke. Det opnar heller ikkje ein brannmurregel eller vidaresender ein port. Og det er aldri ein grunn til å slå av serververifisering på klienten, som er trekket folk gjer når dei bestemmer seg for at sertifikatet må vere problemet.

Omvendt er eit byte av VPN-passord ikkje ei retting for utdatert DNS. Det legg berre til ein andre feil i same saka.

Kopla til på nytt og prov det ende til ende

Når den autoritative posten er riktig, kan klienten framleis halde eit gammalt oppslag. Bruk den støtta gjenoppkoplinga eller endepunktsoppdateringa hans og gje han eit augneblink i staden for å hamre på kople til. Prov deretter vegen i fire trinn: slå opp namnet, stadfest adressa, sjekk at lyttaren er nåbar, og autentiser. Fire separate resultat, fire separate svar.

Hald oppdateraren på rotasjonssjekklista ved sida av VPN-kontoen. Éin tiltenkt posteigar, ein gyldig legitimasjon og ein observerbar suksess er det som hindrar neste versjon av denne saka.