Un record DDNS învechit sau un endpoint VPN stricat: cum le distingi

Din exterior, un nume de gazdă învechit și un VPN stricat arată identic. Clientul rezolvă un nume, numele indică undeva, iar conexiunea fie expiră, fie este refuzată. Una este o problemă de actualizare DNS, cealaltă este o problemă de autentificare sau de redirecționare, iar diferența devine evidentă doar când compari adresa publicată cu adresa pe care linia ta o are de fapt.

Două defecțiuni care se prezintă la fel

Prima defecțiune este că înregistrarea listează încă adresa WAN de ieri. A doua este că înregistrarea este corectă și tunelul te refuză din motivele lui. Ambele produc același mesaj pe client, iar tentația este să începi să regenerezi certificate.

Ordinea contează aici. Verificarea DNS durează un minut și este reversibilă. Regenerarea unui CA nu este nici una, nici alta.

Compară adresele înainte de orice altceva

Întreabă proprietarul rețelei ce adresă are linia acum, apoi întreabă DNS-ul ce publică. dig +short vpn.example.com oferă răspunsul pe care îl va primi clientul tău, iar dig @1.1.1.1 vpn.example.com arată dacă un alt resolver vede altceva. Dacă acestea două nu sunt de acord, te uiți la comportamentul cache-ului și nu la un actualizator stricat.

Un răspuns recursiv poate rămâne în urmă față de o actualizare cu TTL-ul său, așa că ține înregistrarea autoritativă și ce a stocat laptopul tău în cache în cutii separate.

Ce este de fapt acreditarea actualizatorului

Dispozitivele DDNS vechi se autentifică adesea chiar cu parola contului, motiv pentru care schimbarea acelei parole le strică în tăcere. Ele continuă să încerce cu valoarea veche și nu raportează nimic util. Ghidul No-IP privind parola dispozitivului documentează exact această problemă de compatibilitate pe hardware mai vechi, iar răspunsul rezonabil este o acreditare de actualizare cu scop limitat, nu o parolă de cont mai slabă.

Mecanismele mai noi emit un token sau o cheie de actualizare separată cu propriul ciclu de viață. Aceasta este valoarea care trebuie rotită în router și cea care trebuie înregistrată în inventarul tău de acreditări. Nu este nici valoarea care ar trebui lipită într-un fir de chat în timp ce depanezi.

Examinaază starea ne-secretă a actualizatorului: momentul ultimului succes, categoria răspunsului și numele de gazdă pe care crede că îl deține. Respingerea acreditării și o defecțiune de conectivitate necesită corecții diferite.

Ce nu poate face o corecție de DNS

Corectarea înregistrării nu creează accesibilitate de intrare. Dacă linia stă în spatele unui NAT la nivel de operator, niciun nume de gazdă nu va face o conexiune de intrare să funcționeze. De asemenea, nu deschide o regulă de firewall și nu redirecționează un port. Și nu este niciodată un motiv să dezactivezi verificarea serverului pe client, care este mișcarea pe care o fac oamenii când decid că certificatul trebuie să fie problema.

Dimpotrivă, schimbarea parolei VPN nu este o corecție pentru DNS învechit. Doar adaugă o a doua defecțiune la același tichet.

Reconectează-te și demonstrează totul de la un capăt la altul

După ce înregistrarea autoritativă este corectă, clientul poate păstra încă o căutare veche. Folosește reconectarea sau reîmprospătarea punctului final acceptate de acesta și dă-i un moment în loc să apeși insistent conectare. Apoi demonstrează calea în patru pași: rezolvă numele, confirmă adresa, verifică dacă ascultătorul este accesibil și autentifică-te. Patru rezultate separate, patru răspunsuri separate.

Ține actualizatorul pe lista de verificare a rotației, lângă contul VPN. Un singur proprietar intenționat al înregistrării, o acreditare validă și un succes observabil sunt ceea ce împiedică următoarea versiune a acestui tichet.