Cambiar de provedor de VPN: planifique o nome de host, non só o IP
Un rexistro DNS novo non move as sesións existentes. Planifique quen controla o nome, cando o resolve cada cliente e como retirará o punto final antigo.
O seu rexistro DNS é correcto, o substituto está san e, aínda así, algúns clientes pasan horas marcando o enderezo antigo. Uns poucos fallan de inmediato contra un nome que se resolve e nunca responde. Ambos os resultados veñen dunha mesma fenda: un nome de host cambia o que consulta un cliente, non cando o consulta, nin en que confía cando chega a resposta.
O síntoma: un rexistro correcto, túneles obsoletos
Un perfil que garda un nome non é un cliente que o resolva continuamente. A maioría resólveo unha vez, ao aplicar a configuración ou cando sobe o túnel, e despois reutiliza ese enderezo ata que remata a sesión. Un TTL longo por riba é a razón pola que o cambio debe planificarse arredor das reconexións e non arredor da edición do DNS.
Ningún dos dous comportamentos é un defecto, e iso é o que fai confuso o síntoma. O cliente traballa cunha resposta que obtivo antes, e nada do lado do servidor mostra cal foi esa resposta. Planifique a reconexión dentro da xanela de mantemento e diga aos usuarios que verán, ou pase a xanela respondendo tickets. Unha cola de informes idénticos é o resultado habitual.
Quen controla o nome e que verifica o cliente
O control da zona decide a rapidez con que pode avanzar unha migración. Manteña o rexistro nun rexistrador ao que poida entrar e anote quen máis pode cambialo.
A confianza non segue o nome. Un cliente baseado en TLS pode comprobar a identidade dun certificado ou un nome fixado, mentres que WireGuard autentica a clave pública do par e ignora por completo o nome de host. Esa diferenza decide se abonda cunha edición do DNS ou se cada perfil necesita unha impresión nova. Un cambio de rexistro nunca debería autorizar un punto final que ninguén aprobou.
Manteña o acceso administrativo e de recuperación lonxe do nome público do cliente. Perder unha conta de aloxamento non debería costarlle tamén o rexistro que redirixe os clientes. Garde a ruta de recuperación nun lugar que non dependa do provedor que deixa.
Cando volve ler o nome cada cliente
O momento da resolución é unha propiedade de cada cliente, así que revise a implementación que realmente distribúe antes de prometer unha xanela de cambio. wg-quick resolve o punto final cando sobe a interface e conserva ese enderezo ata que se reinicia o túnel. Un cliente OpenVPN consulta o nome ao conectarse, e se volve mirar ao reconectarse depende das súas opcións.
| 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 |
Os clientes móbiles son a sorpresa habitual, porque poden conservar un enderezo resolto durante a suspensión ou un cambio de rede. Publique rexistros A e AAAA só se o substituto responde nas dúas familias. Un enderezo que responde nunha familia non demostra nada sobre a outra, e un rexistro AAAA morto engade un tempo de espera a cada intento. Documente o comportamento de resolución de cada cliente que admita e despois probe nos dispositivos que a xente usa de verdade.
A reconexión é unha acción do usuario na maioría dos clientes, e o servidor non pode forzala. Inclúa ese paso na nota de mantemento, cunha liña sobre o que verá o usuario cando ocorra.
Cambie con probas e despois retire o punto final antigo
Antes do cambio, demostre cada capa no substituto: o oínte responde, a devasa deixa pasar o porto, as rutas volven polo camiño correcto, o nome resólvese ao enderezo novo e unha identidade coñecida é aceptada. Un oínte que acepta unha conexión non é o mesmo que un que completa un handshake, así que probe o handshake e non o porto. Manteña a lista de revocación actual xunto á configuración, porque unha copia de seguridade restaurada recrea a lista de pares tal como estaba e reabriría un acceso que xa pechara. Anote con que identidade probou, porque «funciona» non é unha proba que ninguén poida repetir.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesDurante a transición, observe os intentos de conexión nos dous puntos finais para a mesma identidade. Un cliente que aínda se autentica contra o enderezo antigo é un perfil ou unha resposta na caché que nunca se moveu. Retire o punto final antigo segundo un plan con data, porque dous servizos que aceptan unha identidade deixan dúas portas abertas.
A proba do cambio é unha sesión de aplicación a través do punto final novo, non un ping. Cando esa sesión funcione e o punto final antigo non rexistre intentos autorizados durante un ciclo completo de reconexión, o traslado rematou.