A VPN mudou-se: porque é que o seu cliente OpenVPN continua a marcar o IP antigo

O fornecedor alterou o seu endereço público, atualizou o registo DNS dinâmico e o cliente continua sem conseguir ligar-se. De fora, parece que o registo não se propagou. Na maioria das vezes o registo está correto e o cliente marca o endereço que resolveu antes da mudança, porque um túnel em execução e um perfil guardado têm cada um a sua ideia de onde vive o servidor. Três camadas têm de concordar, e atualizam-se em calendários diferentes.

Veja o que o perfil marca, não o que o DNS diz

Abra a ligação que usa realmente e leia a linha remote. Um endereço numérico ali nunca segue uma atualização do nome do anfitrião, por muito correto que o registo fique.

Depois verifique se o perfil que editou é o que o cliente carregou. Os perfis importados são comuns: um gestor pode ter tirado uma cópia há meses e guardado a sua própria versão, por isso o ficheiro na sua pasta de transferências e a entrada na aplicação podem divergir. Compare o ponto final nos detalhes de ligação do próprio cliente antes mesmo de depurar o DNS.

Dois ficheiros, um ponto final: é o achado habitual aqui.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Leia a próxima tentativa de ligação do cliente

Reinicie a ligação com registo detalhado e leia a linha onde é indicado o endereço que vai contactar. É esse valor que conta, não o que o seu navegador resolveu.

A cache do resolvedor pode ainda guardar a resposta anterior, e algumas redes guardam-na mais tempo do que o TTL do registo exige. Consulte o resolvedor que o cliente usa realmente, e não um público que testou a partir de outro local.

Se o registo mostra o novo endereço e a ligação continua a falhar, o problema mudou de lugar: o pacote vai para algum lado e ninguém responde. É uma questão de ouvinte, firewall ou reencaminhamento de porta, e está do lado do servidor, não no caminho de resolução do cliente. Mantenha estas duas falhas separadas, porque tratar um ouvinte inalcançável como problema de DNS faz você dar duas voltas ao mesmo ciclo.

Saiba qual reinício está a fazer

Nem todos os reinícios preservam o mesmo estado, e é por isso que uma mudança de endereço pode comportar-se de forma diferente consoante o processo é reciclado. Um reinício suave desencadeado por um sinal preserva mais do contexto da sessão anterior, enquanto uma paragem e arranque completos recomeçam a partir da configuração. Se está a testar se o cliente volta a resolver, quer o caminho que parte da configuração.

As definições de persistência também contam, porque foram feitas para conservar o que foi autenticado, não para andar atrás de endereços novos.

O teste mais limpo é um arranque de raiz a partir do perfil previsto, seguido de uma vista de olhos pela linha de registo que nomeia o ponto final. Tudo o que aprender de uma sessão parcialmente conservada é uma afirmação sobre essa sessão.

As quatro opções e as suas tarefas separadas

remote com um nome de anfitrião é a definição que torna a nova resolução possível; um endereço literal nessa linha exclui-a. resolv-retry controla o que acontece quando uma pesquisa falha, e a 2.6 já a define como infinita por omissão. Acrescentá-la, portanto, não muda nada, e nunca agenda uma verificação periódica de outra resposta. Quem diz que ela sonda endereços novos confundiu a recuperação com a frescura.

persist-remote-ip tem a ver com continuidade e não com frescura: reutiliza o ponto final que se autenticou por último, ao longo dos reinícios suaves que suporta. Enquanto testa uma mudança, isso é o contrário do que quer. Desative-o para o teste se a sua compilação o ativa, e volte a ativá-lo quando o novo ponto final estiver provado. Se ficar ligado, uma reconexão bem-sucedida pode não lhe dizer nada sobre o DNS.

float aceita um par autenticado cujo endereço mudou a meio da sessão, e apenas em configurações que o suportam. Não atualiza o DNS e não seguirá por si uma mudança de fornecedor. Trate-o como uma funcionalidade de resiliência para pares que se deslocam, não como um mecanismo de endereços dinâmicos para servidores.

Confirme o novo ponto final antes de culpar o cliente

De fora da sua rede, verifique se o novo endereço tem um ouvinte na porta configurada e se o reencaminhamento do fornecedor aponta para ele. Um registo A correto para uma máquina sem porta aberta produz exatamente o sintoma que as pessoas atribuem à cache.

Depois volte a ligar e verifique duas coisas: o cliente autenticou-se contra o certificado de servidor esperado, e a sessão chega ao recurso que pretendia. Uma mudança de endereço não baixa os requisitos de identidade, e uma ligação que tem êxito para o ponto final errado é pior do que uma que falha. O manual do OpenVPN 2.6 lista as quatro opções com o seu próprio âmbito, e é a lista de verificação a manter ao lado do perfil.

Mantenha uma via fora de banda para o servidor antes de reiniciar o túnel que transporta o seu acesso administrativo. Essa única precaução evita a maioria dos incidentes que este cenário produz.