ddclient publică ieșirea VPN: repară sursa de descoperire

Numele tău DNS se rezolvă acum la o adresă a unui furnizor VPN, iar jurnalul de actualizare arată perfect sănătos. Această combinație este normală. O sondă de descoperire bazată pe web întreabă un serviciu extern ce sursă vede, iar când cererea iese printr-un VPN cu tunel complet, răspunsul este ieșirea VPN, nu adresa WAN de acasă. Actualizatorul și-a făcut treaba; treaba era îndreptată spre o observație greșită.

Confirmă la ce trebuie să ajungă numele

Un nume public pentru un serviciu casnic de intrare are nevoie de o adresă prin care conexiunile de intrare aprobate pot ajunge la acel serviciu. Publicarea unei ieșiri partajate a furnizorului nu aranjează acolo redirecționare de intrare, iar nicio configurație DNS nu creează acea redirecționare. Decide asta înainte să atingi actualizatorul, pentru că determină care adresă este corectă.

Un nume privat pentru adresa tunelului unui client VPN este altă problemă cu alt răspuns: aparține DNS-ului privat și nu are deloc nevoie de un serviciu public de descoperire. Amestecarea celor două cerințe este felul în care o configurație funcțională începe să publice o adresă pe care nimeni nu a cerut-o.

Adresele de interfață au nevoie și ele de interpretare. Adresa unui laptop din spatele unui router de acasă nu este adresa WAN publică, iar chiar adresa WAN a routerului poate sta în spatele NAT-ului de operator, unde publicarea ei nu poate produce accesibilitate de intrare.

Reproduce valoarea înainte de a schimba ceva

Observă cele două căi separat. Cu tunelul pornit, o sondă raportează ieșirea; cu tunelul oprit, sau cu sonda legată de interfața fizică, raportează adresa de acasă: curl --interface eth0 https://ifconfig.me. Dacă cele două răspunsuri diferă, ai reprodus defectul fără să atingi actualizatorul.

Apoi rulează clientul într-un mod care verifică configurația fără a efectua o actualizare, de exemplu ddclient -verbose -noexec, și citește ce metodă de descoperire a ales. Ieșirea detaliată numește metoda și valoarea obținută, iar acesta este faptul de care ai nevoie înainte de orice editare.

Îndreaptă descoperirea spre calea aleasă

Dacă numele trebuie să publice adresa WAN de acasă, descoperirea trebuie să observe exact acea adresă. Funcționează trei opțiuni, în ordine aproximativă a preferinței: lasă routerul să publice prin propriul actualizator acceptat; folosește descoperirea stării routerului din ddclient împotriva unei pagini pe care routerul chiar o servește; sau păstrează o sondă web, dar leagă-o de interfața fizică pentru a ieși în afara tunelului.

Pentru calea stării routerului, versiunile mai noi de ddclient folosesc familia de opțiuni usev4 și fwv4, cu un model de omitere opțional pentru textul din jurul paginii. Verifică README pentru versiunea instalată, pentru că versiunile mai vechi scriu aceeași idee cu use și fw, iar un nume de opțiune copiat din versiunea greșită eșuează la pornire.

Dacă păstrezi descoperirea web, ține minte că rutarea sondei și rutarea apelului API de actualizare sunt decizii separate. Apelul de actualizare livrează înregistrarea; sonda decide ce valoare este livrată.

Ține secretele și versiunile în ordine

Acreditările routerului și tokenurile furnizorului aparțin unui fișier de configurare protejat, nu unei linii de comandă care ajunge în istoricul shell-ului. Urmele detaliate pot conține ambele, așa că redactează-le înainte de a le lipi într-un tichet. O metodă de descoperire care cere extragerea unei pagini autentificate a routerului cere și să menții acele acreditări funcționale peste actualizările de firmware. Păstrează-le cu aceeași grijă ca tokenul furnizorului.

Fișierul ddclient README documentează abordările de descoperire și numele opțiunilor lor. Nu amesteca rezultate IPv4 și IPv6 într-o singură înregistrare și nu presupune că o opțiune prezentă într-o versiune există în alta.

Verifică valoarea, apoi accesibilitatea

Compară adresa propusă cu punctul final dorit înainte de a permite o actualizare live, apoi verifică DNS-ul autoritativ după o actualizare autorizată și ține cont de cache-urile rezolvatoarelor. Un TTL mic scurtează așteptarea; nu face o valoare greșită corectă.

Abia după ce înregistrarea este corectă ar trebui să testezi serviciul de intrare dintr-o rețea independentă, cu firewallul și redirecționarea necesare deja aprobate. O înregistrare A corectă nu dovedește un serviciu accesibil, iar un lease VPN static poate simplifica denumirea privată fără a repara un nume de gazdă public care indică spre WAN-ul greșit.