Utdatert DDNS-post eller ødelagt VPN-endepunkt: slik skiller du dem

Utenfra ser et utdatert vertsnavn og en ødelagt VPN identiske ut. Klienten slår opp et navn, navnet peker et sted, og tilkoblingen går ut på tid eller avvises. Det ene er et DNS-oppdateringsproblem, det andre et autentiserings- eller videresendingsproblem, og forskjellen blir først tydelig når du sammenligner adressen som publiseres med adressen linjen din faktisk har.

To feil som ser like ut

Den første feilen er at posten fortsatt lister gårsdagens WAN-adresse. Den andre er at posten er korrekt og tunnelen avviser deg av sine egne grunner. Begge gir samme melding på klienten, og fristelsen er å begynne å regenerere sertifikater.

Rekkefølgen betyr noe her. Å sjekke DNS tar et minutt og er reversibelt. Å regenerere en CA er verken det ene eller det andre.

Sammenlign adressene før alt annet

Spør nettverkseieren hvilken adresse linjen har akkurat nå, og spør deretter DNS hva den publiserer. dig +short vpn.example.com gir svaret klienten din vil få, og dig @1.1.1.1 vpn.example.com viser om en annen resolver ser noe annet. Hvis de to er uenige, ser du på cacheatferd og ikke en ødelagt oppdaterer.

Et rekursivt svar kan henge etter en oppdatering med TTL-en sin, så hold den autoritative posten og det laptoppen din har cachet i separate bokser.

Hva oppdatererens legitimasjon egentlig er

Eldre DDNS-enheter autentiserer ofte med selve kontopassordet, og derfor ødelegger et bytte av det passordet dem lydløst. De fortsetter å prøve med den gamle verdien og rapporterer ingenting nyttig. No-IPs veiledning for enhetspassord dokumenterer nettopp dette kompatibilitetsproblemet på eldre maskinvare, og det fornuftige svaret er en avgrenset oppdateringslegitimasjon i stedet for et svakere kontopassord.

Nyere mekanismer utsteder et eget oppdateringstoken eller en nøkkel med sin egen livssyklus. Det er verdien du skal rotere inn i ruteren, og den du skal føre i legitimasjonsregisteret ditt. Det er heller ikke verdien du skal lime inn i en chat-tråd mens du feilsøker.

Se på oppdatererens ikke-hemmelige status: tidspunkt for siste suksess, svarkategori og vertsnavnet den mener å eie. En avvisning av legitimasjon og en tilkoblingsfeil krever forskjellige rettelser.

Hva en DNS-rettelse ikke kan gjøre

Å rette posten skaper ikke innkommende tilgjengelighet. Hvis linjen sitter bak carrier-grade NAT, vil ingen vertsnavn få en innkommende tilkobling til å virke. Det åpner heller ikke en brannmurregel eller videresender en port. Og det er aldri en grunn til å slå av serververifisering på klienten, som er trekket folk gjør når de bestemmer seg for at sertifikatet må være problemet.

Omvendt er et bytte av VPN-passord ikke en rettelse for utdatert DNS. Det legger bare til en andre feil i samme sak.

Koble til på nytt og bevis det ende til ende

Når den autoritative posten er riktig, kan klienten fortsatt holde et gammelt oppslag. Bruk dens støttede gjenoppkobling eller endepunktsoppdatering og gi den et øyeblikk i stedet for å hamre på koble til. Bevis deretter veien i fire trinn: slå opp navnet, bekreft adressen, sjekk at lytteren er nåbar, og autentiser. Fire separate resultater, fire separate svar.

Hold oppdatereren på rotasjonssjekklisten ved siden av VPN-kontoen. Én tiltenkt posteier, en gyldig legitimasjon og en observerbar suksess er det som hindrer neste versjon av denne saken.