Ai nevoie de DNS dinamic pentru un server VPN de acasă?

DNS-ul dinamic repară numele, nu calea de intrare. Trei verificări decid dacă un nume de gazdă este suficient pentru un server VPN de acasă sau dacă ruta de intrare este stricată.

Majoritatea defecțiunilor VPN de acasă despre care mă întreabă oamenii nu sunt defecțiuni DNS, și totuși cumpără mai întâi un abonament DNS dinamic. Înainte să configurezi ceva, decide dacă numele de gazdă este partea care este într-adevăr stricată. Un actualizator rescrie o înregistrare când adresa dată de furnizor se mută; nu poate deschide un port, nu poate trece prin NAT-ul operatorului și nu poate face o sesiune WireGuard activă să observe că punctul ei final s-a schimbat. Trei condiții decid dacă DNS-ul dinamic este întreaga soluție sau doar o linie din ea.

Prima condiție: adresa ta chiar se mută

Adresele rezidențiale se mută din motive banale: modemul se resincronizează după o pană de curent, furnizorul reechilibrează un pool, un lease nou sosește după o întrerupere lungă. Pe unele linii se mută și rar, iar eu am văzut aceeași adresă rezistând un an; abonamentele de afaceri includ adesea una statică. Dacă nimic nu s-a schimbat în douăsprezece luni, o singură înregistrare A editată manual este un daemon mai puțin de ținut în viață.

Măsoară, nu ghici. Citește adresa WAN din pagina de stare a routerului și compară-o cu ce vede lumea exterioară. Rulează asta de pe o mașină din LAN:

curl -fsS https://api.ipify.org; echo

Dacă cele două valori diferă, ceva traduce în fața routerului tău și nicio actualizare a numelui de gazdă nu va repara asta. O adresă din 100.64.0.0/10 este intervalul partajat pentru NAT de nivel de operator, și acesta este motivul obișnuit pentru care un nume actualizat corect tot expiră din exterior.

A doua condiție: clienții rezolvă din nou numele

TTL-ul scurt este partea pe care oamenii o sar. Rezolvatorii recursivi respectă TTL-ul înregistrării, dar stivele clienților memorează separat, iar un tunel deja ridicat nu mai rezolvă nimic. Setează înregistrarea la 60-300 secunde cât timp depanezi; asta scurtează fereastra în care se servește un răspuns vechi și nu migrează o sesiune conectată.

OpenVPN rezolvă din nou linia remote vpn.example.net 1194 la fiecare reconectare, iar resolv-retry infinite îl face să reîncerce în loc să iasă când căutarea eșuează. Pe server, float permite unei sesiuni stabilite să urmeze un partener căruia i s-a schimbat adresa sursă. WireGuard este mai direct: wg-quick up rezolvă Endpoint când se aplică configurația, iar clientul îl rezolvă din nou când reconstruiește tunelul, așa că un handshake care încă reușește către adresa veche continuă să reușească până se oprește.

Această diferență modelează planul. Dacă clienții se conectează la cerere, o schimbare de adresă costă o reconectare. Dacă țin o sesiune deschisă zile întregi, așteaptă-te ca tunelul să moară la următorul handshake și fă clientul să reîncerce în loc să presupui că rămâne.

A treia condiție: calea de intrare este încă deschisă

DNS-ul dinamic schimbă doar unde indică numele și nimic altceva. Redirectarea portului pe router, regula de firewall pe gazda VPN și permisiunea furnizorului pentru pachetele de intrare trebuie să existe toate înainte ca înregistrarea să conteze. Urmărește spre ce țintește redirectarea: dacă este fixată de o adresă WAN în loc de interfață, o schimbare de adresă strică redirectarea în tăcere și înregistrarea ia vina.

Testează din exterior. Un telefon pe date mobile cu Wi-Fi oprit este cel mai ieftin test onest; un laptop în același LAN nu este. Când numele se rezolvă la adresa ta publică și routerul nu are buclă NAT, un test din interior eșuează în timp ce înregistrarea este perfect corectă, iar asta trimite majoritatea oamenilor să editeze o înregistrare care nu a fost niciodată greșită.

Ce să rulezi când toate trei se aplică

ddclient este actualizatorul cel mai puțin surprinzător pentru un host mic. O configurație minimă publică adresa pe care o vede furnizorul, ceea ce ocolește greșeala NAT-ului dublu:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Rulează-l dintr-un timer systemd la câteva minute, nu dintr-o buclă shell, și înregistrează răspunsul furnizorului în loc să presupui succes. Tratează acreditarea ca pe o cheie, pentru că ea decide unde este trimis fiecare client: folosește un token de actualizare limitat în loc de parola contului, ține fișierul în modul 0600 și trimite actualizările prin HTTPS.

Verifică înainte de a te angaja

O singură interogare îți spune ce vede restul lumii și tipărește TTL-ul pe care trebuie să-l aștepți după o schimbare:

dig +noall +answer vpn.example.net @1.1.1.1

Compară acea adresă cu adresa WAN a routerului. Dacă se potrivesc, numele își face treaba și ce încă eșuează este accesibilitatea de intrare, o cheie sau un client care nu a rezolvat din nou. Dacă diferă, actualizatorul publică interfața greșită, adesea pentru că rula pe gazda VPN din spatele routerului în loc de pe routerul însuși.

Păstrează un rollback care durează un minut: notează ultima adresă funcțională și TTL-ul anterior, ca să le poți publica pe amândouă manual cât timp furnizorul are o după-amiază proastă.

Când răspunsul este nu

Dacă prima sau a treia condiție eșuează, se schimbă decizia, nu configurația. În spatele NAT-ului operatorului, opțiunile practice sunt să ceri furnizorului o adresă publică, să muți punctul de intrare pe un VPS mic cu adresă stabilă, sau să folosești un strat suprapus care își ține propriul punct de întâlnire. Dacă adresa este statică, sari peste actualizator: o înregistrare A, o înregistrare AAAA dacă folosești IPv6, aceeași redirectare de port.

Dacă adresa se schimbă în timp ce clienții rămân conectați, corectura onestă stă în client: logică de reconectare și un interval de reîncercare, nu un actualizator mai rapid. Un al doilea furnizor doar ascunde intervalul.

Înainte să continui, confirmă patru lucruri în ordine:

  • Adresa publicată de actualizator se potrivește cu adresa WAN a routerului.
  • TTL-ul înregistrării este suficient de scurt ca o schimbare să apară în câteva minute.
  • Redirectarea portului este legată de interfață, nu de o adresă fixă.
  • Un client real s-a reconectat și a trecut trafic de la ultima schimbare.

Dacă toate patru se aplică, lasă configurația în pace; următoarea defecțiune este o cheie sau o regulă de firewall, nu o problemă de denumire. Dacă vreuna eșuează, repară acel rând înainte de a adăuga încă o piesă mobilă. RFC 2136 descrie mecanismul de actualizare în sine, dacă vrei să vezi ce pune daemonul pe fir.

Articole similare