Canviar de proveïdor de VPN: planifiqueu el nom d'amfitrió, no només la IP
Un registre DNS nou no mou les sessions existents. Planifiqueu qui controla el nom, quan el resol cada client i com retirareu el punt final antic.
El vostre registre DNS és correcte, el substitut està sa, i alguns clients passen hores marcant l'adreça antiga de totes maneres. Uns quants fallen de cop contra un nom que es resol i no respon mai. Tots dos resultats vénen d'una mateixa escletxa: un nom d'amfitrió canvia què consulta un client, no quan ho consulta, ni què confia quan arriba la resposta.
El símptoma: un registre correcte, túnels obsolets
Un perfil que desa un nom no és un client que el resolgui contínuament. La majoria el resolen un cop, en aplicar la configuració o quan puja el túnel, i després reutilitzen aquella adreça fins que acaba la sessió. Un TTL llarg a sobre és per què la transició s'ha de planificar al voltant de les reconnexions i no de l'edició del DNS.
Cap dels dos comportaments no és un defecte, i això és el que fa confús el símptoma. El client treballa amb una resposta que va obtenir abans, i res al costat del servidor no mostra quina resposta era. Planifiqueu la reconnexió dins de la finestra de manteniment i digueu als usuaris què veuran, o passeu la finestra responent tiquets. Una cua d'informes idèntics és el resultat habitual.
Qui controla el nom i què verifica el client
El control de la zona decideix com de ràpid pot anar una migració. Manteniu el registre en un registrador on pugueu entrar i anoteu qui més el pot canviar.
La confiança no segueix el nom. Un client basat en TLS pot comprovar la identitat d'un certificat o un nom fixat, mentre que WireGuard autentica la clau pública del parell i ignora completament el nom d'amfitrió. Aquesta diferència decideix si n'hi ha prou amb una edició del DNS o si cada perfil necessita una empremta nova. Un canvi de registre no hauria d'autoritzar mai un punt final que ningú no ha aprovat.
Manteniu l'accés administratiu i de recuperació lluny del nom públic del client. Perdre un compte d'allotjament no hauria de costar-vos també el registre que redirigeix els clients. Guardeu el camí de recuperació en un lloc que no depengui del proveïdor que deixeu.
Quan cada client rellegeix el nom
El moment de la resolució és una propietat de cada client, així que comproveu la implementació que realment distribuïu abans de prometre una finestra de transició. wg-quick resol el punt final quan puja la interfície i conserva aquella adreça fins que el túnel es reinicia. Un client OpenVPN consulta el nom quan es connecta, i si torna a mirar en reconnectar depèn de les seves opcions.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
Els clients mòbils són la sorpresa habitual, perquè poden conservar una adreça resolta durant la suspensió o un canvi de xarxa. Publiqueu registres A i AAAA només si el substitut respon a les dues famílies. Una adreça que respon en una família no demostra res sobre l'altra, i un registre AAAA mort afegeix un temps d'espera a cada intent. Documenteu el comportament de resolució de cada client que suporteu i després proveu-ho en els dispositius que la gent fa servir de debò.
La reconnexió és una acció de l'usuari en la majoria de clients, i el servidor no la pot forçar. Poseu aquest pas a la nota de manteniment, amb una línia sobre què veurà l'usuari quan passi.
Feu la transició amb proves i després retireu el punt final antic
Abans del canvi, proveu cada capa al substitut: l'oient respon, el tallafoc deixa passar el port, les rutes tornen pel camí correcte, el nom es resol a l'adreça nova i una identitat coneguda és acceptada. Un oient que accepta una connexió no és el mateix que un que completa un handshake, així que proveu el handshake i no el port. Manteniu la llista de revocació actual al costat de la configuració, perquè una còpia de seguretat restaurada recrea la llista de parells tal com era i reobriria un accés que ja havíeu tancat. Anoteu amb quina identitat vau provar, perquè «funciona» no és una prova que ningú pugui repetir.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesDurant la transició, observeu els intents de connexió als dos punts finals per a la mateixa identitat. Un client que encara s'autentica contra l'adreça antiga és un perfil o una resposta en memòria cau que no s'ha mogut mai. Retireu el punt final antic segons un pla amb data, perquè dos serveis que accepten una identitat deixen dues portes obertes.
La prova de transició és una sessió d'aplicació a través del punt final nou, no un ping. Quan aquella sessió funcioni i el punt final antic no registri cap intent autoritzat durant un cicle complet de reconnexió, el trasllat ha acabat.