Mudar de provedor de VPN: planeje o nome de host, não apenas o IP

Seu registro DNS está correto, a substituição está saudável, e ainda assim alguns clientes passam horas discando o endereço antigo. Alguns falham de imediato contra um nome que resolve e nunca responde. Ambos os resultados vêm de uma mesma lacuna: um nome de host muda o que um cliente consulta, não quando ele consulta, nem no que ele confia quando a resposta chega.

O sintoma: um registro correto, túneis obsoletos

Um perfil que guarda um nome não é um cliente que continua a resolvê-lo. A maioria resolve uma vez, ao aplicar a configuração ou quando o túnel sobe, e depois reutiliza esse endereço até a sessão terminar. Um TTL longo por cima disso é a razão pela qual a transição precisa ser planejada em torno das reconexões e não da edição do DNS.

Nenhum dos dois comportamentos é um defeito, e é justamente isso que torna o sintoma confuso. O cliente trabalha com uma resposta que obteve antes, e nada do lado do servidor mostra qual foi essa resposta. Planeje a reconexão na janela de manutenção e diga aos usuários o que eles verão, ou gaste a janela respondendo tickets. Uma fila de relatos idênticos é o resultado habitual.

Quem controla o nome e o que o cliente verifica

O controle da zona decide a rapidez com que uma migração pode avançar. Mantenha o registro em um registrador em que você possa entrar e anote quem mais pode alterá-lo.

A confiança não segue o nome. Um cliente baseado em TLS pode verificar a identidade de um certificado ou um nome fixado, enquanto o WireGuard autentica a chave pública do par e ignora completamente o nome de host. Essa diferença decide se uma edição de DNS basta ou se cada perfil precisa de uma nova impressão digital. Uma alteração de registro nunca deveria autorizar um ponto final que ninguém aprovou.

Mantenha o acesso administrativo e o acesso de recuperação longe do nome público do cliente. Perder uma conta de hospedagem não deveria custar também o registro que redireciona clientes. Guarde o caminho de recuperação em um lugar que não dependa do provedor que você está deixando.

Quando cada cliente relê o nome

O momento da resolução é uma propriedade de cada cliente, então verifique a implementação que você realmente distribui antes de prometer uma janela de transição. O wg-quick resolve o ponto final quando a interface sobe e mantém esse endereço até o túnel reiniciar. Um cliente OpenVPN consulta o nome ao se conectar, e se volta a olhar na reconexão depende de suas opções.

Clientes móveis são a surpresa habitual, porque podem manter um endereço resolvido durante a suspensão ou uma troca de rede. Publique registros A e AAAA apenas se a substituição responder nas duas famílias. Um endereço que responde em uma família não prova nada sobre a outra, e um registro AAAA morto acrescenta um tempo limite a cada tentativa. Documente o comportamento de resolução de cada cliente que você suporta e depois teste nos dispositivos que as pessoas realmente usam.

A reconexão é uma ação do usuário na maioria dos clientes, e o servidor não pode forçá-la. Inclua esse passo na nota de manutenção, com uma linha sobre o que o usuário verá quando isso acontecer.

Faça a transição com base em evidências e depois aposente o ponto final antigo

Antes da troca, prove cada camada na substituição: o ouvinte responde, o firewall deixa passar a porta, as rotas voltam pelo caminho certo, o nome resolve para o novo endereço e uma identidade conhecida é aceita. Um ouvinte que aceita uma conexão não é o mesmo que um que conclui um handshake, então teste o handshake e não a porta. Mantenha a lista de revogação atual ao lado da configuração, porque um backup restaurado recria a lista de pares como estava e reabriria um acesso que você já fechou. Anote com qual identidade você testou, porque «funciona» não é uma prova que alguém possa repetir.

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

Durante a transição, observe as tentativas de conexão nos dois pontos finais para a mesma identidade. Um cliente que ainda se autentica contra o endereço antigo é um perfil ou uma resposta em cache que nunca se moveu. Aposente o ponto final antigo segundo um plano com data, porque dois serviços que aceitam uma identidade deixam duas portas abertas.

O teste da transição é uma sessão de aplicação pelo novo ponto final, não um ping. Quando essa sessão funcionar e o ponto final antigo não registrar tentativas autorizadas durante um ciclo completo de reconexão, a mudança estará concluída.