Schimbarea furnizorului de VPN: planificați numele de host, nu doar IP-ul

Înregistrarea DNS este corectă, înlocuitorul este sănătos, și totuși unii clienți petrec ore formând adresa veche. Câțiva eșuează imediat pe un nume care se rezolvă și nu răspunde niciodată. Ambele rezultate vin dintr-o singură lipsă: un nume de host schimbă ce caută un client, nu când caută, și nici în ce are încredere când sosește răspunsul.

Simptomul: o înregistrare corectă, tuneluri învechite

Un profil care stochează un nume nu este un client care îl rezolvă continuu. Majoritatea îl rezolvă o dată, la aplicarea configurației sau când tunelul urcă, apoi refolosesc adresa până la sfârșitul sesiunii. Un TTL lung peste asta este motivul pentru care tranziția trebuie planificată în jurul reconectărilor, nu în jurul editării DNS.

Niciunul dintre cele două comportamente nu este un defect, și exact asta face simptomul confuz. Clientul lucrează cu un răspuns obținut mai devreme, iar nimic din partea serverului nu arată care a fost acel răspuns. Planificați reconectarea în fereastra de mentenanță și spuneți utilizatorilor ce vor vedea, sau petreceți fereastra răspunzând la tichete. O coadă de rapoarte identice este rezultatul obișnuit.

Cine controlează numele și ce verifică clientul

Controlul asupra zonei decide cât de repede poate avansa o migrare. Țineți înregistrarea la un registrator în care puteți intra și notați cine altcineva o poate schimba.

Încrederea nu urmează numele. Un client bazat pe TLS poate verifica identitatea unui certificat sau un nume fixat, în timp ce WireGuard autentifică cheia publică a partenerului și ignoră complet numele de host. Această diferență decide dacă o editare DNS este suficientă sau dacă fiecare profil are nevoie de o amprentă nouă. O modificare de înregistrare nu ar trebui să autorizeze niciodată un punct final pe care nimeni nu l-a aprobat.

Țineți accesul administrativ și accesul de recuperare departe de numele public al clientului. Pierderea unui cont de găzduire nu ar trebui să vă coste și înregistrarea care redirecționează clienții. Păstrați calea de recuperare undeva care nu depinde de furnizorul pe care îl părăsiți.

Când recitesc numele fiecare client

Momentul rezolvării este o proprietate a fiecărui client, așa că verificați implementarea pe care o livrați efectiv înainte de a promite o fereastră de tranziție. wg-quick rezolvă punctul final când interfața urcă și păstrează adresa până când tunelul repornește. Un client OpenVPN caută numele la conectare, iar dacă se uită din nou la reconectare depinde de opțiunile sale.

Clienții mobili sunt surpriza obișnuită, pentru că pot păstra o adresă rezolvată peste somn sau o schimbare de rețea. Publicați înregistrări A și AAAA doar dacă înlocuitorul răspunde în ambele familii. O adresă care răspunde într-o familie nu dovedește nimic despre cealaltă, iar o înregistrare AAAA moartă adaugă un timeout la fiecare încercare. Documentați comportamentul de rezolvare pentru fiecare client pe care îl susțineți, apoi testați pe dispozitivele pe care oamenii le folosesc cu adevărat.

Reconectarea este o acțiune a utilizatorului în majoritatea clienților, iar serverul nu o poate impune. Includeți acel pas în nota de mentenanță, cu o linie despre ce va vedea utilizatorul când se întâmplă.

Treceți pe baza dovezilor, apoi retrageți vechiul punct final

Înainte de comutare, dovediți fiecare strat la înlocuitor: ascultătorul răspunde, firewallul lasă portul să treacă, rutele se întorc corect, numele se rezolvă la adresa nouă și o identitate cunoscută este acceptată. Un ascultător care acceptă o conexiune nu este același lucru cu unul care finalizează un handshake, așa că testați handshake-ul, nu portul. Țineți lista de revocare curentă lângă configurație, pentru că o copie de siguranță restaurată recreează lista de parteneri așa cum era și ar redeschide accesul pe care l-ați închis deja. Notați cu ce identitate ați testat, pentru că „funcționează” nu este o dovadă pe care cineva o poate repeta.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

În timpul tranziției, urmăriți încercările de conexiune la ambele puncte finale pentru aceeași identitate. Un client care încă se autentifică față de adresa veche este un profil sau un răspuns din cache care nu s-a mutat niciodată. Retrageți vechiul punct final conform unui plan cu dată, pentru că două servicii care acceptă o identitate lasă două uși deschise.

Testul tranziției este o sesiune de aplicație prin noul punct final, nu un ping. Odată ce acea sesiune funcționează și punctul final vechi nu înregistrează nicio încercare autorizată pe un ciclu complet de reconectare, mutarea este terminată.