Verouderde DDNS-rekord teenoor ’n stukkende VPN-eindpunt: hoe om te onderskei

Van buite lyk ’n verouderde hostnaam en ’n stukkende VPN identies. Die kliënt los ’n naam op, die naam wys êrens heen, en die verbinding keer of weier. Die een is ’n DNS-opdateringsprobleem en die ander is ’n verifikasie- of deurstuurprobleem, en die verskil word eers duidelik wanneer jy die adres wat gepubliseer word vergelyk met die adres wat jou lyn werklik het.

Twee foute wat dieselfde lyk

Die eerste fout is dat die rekord nog gister se WAN-adres lys. Die tweede is dat die rekord korrek is en die tonnel jou om sy eie redes weier. Albei lewer dieselfde boodskap by die kliënt, en die versoeking is om sertifikate te begin herskep.

Orde maak hier saak. Om DNS na te gaan neem ’n minuut en is omkeerbaar. Om ’n CA te herskep is nie.

Vergelyk die adresse voor enigiets anders

Vra die netwerkeienaar watter adres die lyn tans het, en vra dan vir DNS wat dit publiseer. dig +short vpn.example.com gee die antwoord wat jou kliënt sal kry, en dig @1.1.1.1 vpn.example.com wys of ’n ander resolver iets anders sien. As dié twee verskil, kyk jy na kasgedrag eerder as ’n stukkende opdateringsprogram.

’n Rekursiewe antwoord kan ’n opdatering met sy TTL vertraag, so hou die gesaghebbende rekord en wat jou skootrekenaar gekas het in aparte boksies.

Wat die opdateringsprogram se geloofsbrief werklik is

Ouer DDNS-toestelle verifieer dikwels met die rekeningwagwoord self, en daarom breek ’n verandering aan daardie wagwoord hulle stilweg. Hulle bly met die ou waarde probeer en rapporteer niks nuttigs nie. No-IP se riglyn vir toestelwagwoorde dokumenteer presies hierdie versoenbaarheidsprobleem by ouer hardeware, en die verstandige reaksie is ’n beperkte opdateringsgeloofsbrief eerder as ’n swakker rekeningwagwoord.

Nuwe meganismes reik ’n aparte opdateringstoken of -sleutel uit met sy eie lewensiklus. Dit is die waarde wat jy in die router moet roteer, en die een wat jy in jou geloofsbriefinventaris moet aanteken. Dit is ook nie die waarde om in ’n kletsdraad te plak terwyl jy foutsoek nie.

Kyk na die opdateringsprogram se nie-geheime status: laaste suksestyd, tipe antwoord, en die hostnaam wat dit dink hy besit. ’n Geloofsbriefverwerping en ’n verbindingsfout het verskillende regstellings nodig.

Wat ’n DNS-regstelling nie kan doen nie

Om die rekord reg te maak skep nie inkomende bereikbaarheid nie. As die lyn agter carrier-grade NAT sit, sal geen hostnaam ’n inkomende verbinding laat werk nie. Dit maak ook nie ’n firewallreël oop of stuur ’n poort deur nie. En dit is nooit ’n rede om bedienerverifikasie by die kliënt af te skakel nie, wat die stap is wat mense maak wanneer hulle besluit die sertifikaat moet die probleem wees.

Omgekeerd is ’n verandering van die VPN-wagwoord nie ’n oplossing vir verouderde DNS nie. Dit voeg net ’n tweede fout by dieselfde kaartjie.

Herverbind en bewys dit end-tot-end

Sodra die gesaghebbende rekord reg is, kan die kliënt steeds ’n ou opsoeking hou. Gebruik sy ondersteunde herverbinding of eindpuntverfrissing en gee dit ’n oomblik eerder as om herhaaldelik op verbind te druk. Bewys dan die pad in vier stappe: los die naam op, bevestig die adres, kyk of die luisteraar bereikbaar is, en verifieer. Vier aparte resultate, vier aparte antwoorde.

Hou die opdateringsprogram in die rotasiekontrolelys langs die VPN-rekening. Een bedoelde rekordeienaar, ’n geldige geloofsbrief en ’n waarneembare sukses is wat die volgende weergawe van hierdie kaartjie voorkom.