Forældet DDNS-post kontra et brudt VPN-endpoint: sådan skelner du

Udefra ser et forældet værtsnavn og en brudt VPN identiske ud. Klienten slår et navn op, navnet peger et sted hen, og forbindelsen timer ud eller afvises. Det ene er et DNS-opdateringsproblem, og det andet er et godkendelses- eller videresendelsesproblem, og forskellen bliver først tydelig, når du sammenligner den adresse, der offentliggøres, med den adresse, din linje faktisk har.

To fejl, der viser sig på samme måde

Den første fejl er, at posten stadig viser gårsdagens WAN-adresse. Den anden er, at posten er korrekt, og tunnelen afviser dig af sine egne grunde. Begge giver den samme meddelelse i klienten, og fristelsen er at begynde at gendanne certifikater.

Rækkefølgen betyder noget her. At tjekke DNS tager et minut og kan rulles tilbage. At gendanne en CA er hverken det ene eller det andet.

Sammenlign adresserne før alt andet

Spørg netværksejeren, hvilken adresse linjen har i øjeblikket, og spørg derefter DNS, hvad den offentliggør. dig +short vpn.example.com giver det svar, din klient får, og dig @1.1.1.1 vpn.example.com viser, om en anden resolver ser noget andet. Hvis de to er uenige, ser du på cacheadfærd og ikke på en brudt opdatering.

Et rekursivt svar kan halte efter en opdatering med sin TTL, så hold den autoritative post og det, din bærbare computer har cachet, i hver sin kasse.

Hvad opdateringens legitimationsoplysning egentlig er

Ældre DDNS-enheder godkender ofte med selve kontoadgangskoden, og derfor bryder en ændring af den adgangskode dem lydløst. De bliver ved med at prøve med den gamle værdi og rapporterer intet brugbart. No-IP’s vejledning om enhedsadgangskoder dokumenterer netop dette kompatibilitetsproblem på ældre hardware, og det fornuftige svar er en afgrænset opdateringslegitimation frem for en svagere kontoadgangskode.

Nyere mekanismer udsteder et separat opdateringstoken eller en nøgle med sin egen livscyklus. Det er den værdi, du skal rotere ind i routeren, og den, du skal logge i dit legitimationsregister. Det er heller ikke den værdi, du skal indsætte i en chattråd, mens du fejlfinder.

Kig på opdateringens ikke-hemmelige status: seneste succes, svarkategori og det værtsnavn, den mener at eje. En afvisning af legitimationsoplysninger og en forbindelsesfejl kræver forskellige rettelser.

Hvad en DNS-rettelse ikke kan gøre

At rette posten skaber ikke indgående tilgængelighed. Hvis linjen sidder bag carrier-grade NAT, vil intet værtsnavn få en indgående forbindelse til at virke. Det åbner heller ikke en firewallregel eller videresender en port. Og det er aldrig en grund til at slå serververifikation fra i klienten, hvilket er det træk, folk gør, når de beslutter, at certifikatet må være problemet.

Omvendt er en ændring af VPN-adgangskoden ikke en rettelse af forældet DNS. Det tilføjer bare en anden fejl i samme sag.

Genopret forbindelsen og bevis det end to end

Når den autoritative post er rigtig, kan klienten stadig holde et gammelt opslag. Brug dens understøttede genopkobling eller endpoint-opdatering, og giv den et øjeblik i stedet for at hamre på forbind. Bevis derefter vejen i fire trin: slå navnet op, bekræft adressen, tjek at lytteren kan nås, og godkend. Fire separate resultater, fire separate svar.

Hold opdateringen på rotationschecklisten ved siden af VPN-kontoen. Én tiltænkt postejer, en gyldig legitimation og en observerbar succes er det, der forhindrer den næste version af denne sag.