Um registro DDNS obsoleto frente a um endpoint VPN quebrado: como distinguir

Por fora, um nome de host obsoleto e uma VPN quebrada parecem idênticos. O cliente resolve um nome, o nome aponta para algum lugar, e a conexão expira ou é recusada. Um é um problema de atualização de DNS e o outro é um problema de autenticação ou de encaminhamento, e a diferença só fica evidente quando você compara o endereço publicado com o endereço que a sua linha realmente tem.

Duas falhas que se apresentam da mesma forma

A primeira falha é que o registro ainda lista o endereço WAN de ontem. A segunda é que o registro está correto e o túnel o recusa por motivos próprios. As duas produzem a mesma mensagem no cliente, e a tentação é começar a regenerar certificados.

A ordem importa aqui. Verificar o DNS leva um minuto e é reversível. Regenerar uma AC não é nem uma coisa nem outra.

Compare os endereços antes de tudo

Pergunte ao dono da rede qual endereço a linha tem agora e depois pergunte ao DNS o que ele publica. dig +short vpn.example.com dá a resposta que o seu cliente vai receber, e dig @1.1.1.1 vpn.example.com mostra se outro resolvedor vê algo diferente. Se esses dois não concordarem, você está olhando para o comportamento de cache e não para um atualizador quebrado.

Uma resposta recursiva pode ficar atrasada em relação a uma atualização pelo seu TTL, então mantenha o registro autoritativo e o que o seu portátil guardou em cache em caixas separadas.

O que é realmente a credencial do atualizador

Dispositivos DDNS antigos frequentemente se autenticam com a própria senha da conta, e é por isso que mudar essa senha os quebra em silêncio. Eles continuam tentando com o valor antigo e não relatam nada útil. O guia de senhas de dispositivo da No-IP documenta exatamente esse problema de compatibilidade em hardware mais antigo, e a resposta sensata é uma credencial de atualização de escopo limitado em vez de uma senha de conta mais fraca.

Mecanismos mais novos emitem um token ou chave de atualização separado com o seu próprio ciclo de vida. Esse é o valor a rotacionar no roteador, e o que deve ser registrado no seu inventário de credenciais. Também não é o valor a colar em uma conversa de chat enquanto você depura.

Examine o estado não secreto do atualizador: hora do último sucesso, categoria de resposta e o nome de host que ele acredita possuir. Uma recusa de credencial e uma falha de conectividade exigem correções diferentes.

O que uma correção de DNS não pode fazer

Corrigir o registro não cria alcançabilidade de entrada. Se a linha está atrás de NAT de nível de operadora, nenhum nome de host fará uma conexão de entrada funcionar. Também não abre uma regra de firewall nem encaminha uma porta. E nunca é motivo para desativar a verificação do servidor no cliente, que é o movimento que as pessoas fazem quando decidem que o certificado deve ser o problema.

Por outro lado, mudar a senha da VPN não é uma correção para um DNS obsoleto. Apenas acrescenta uma segunda falha ao mesmo chamado.

Reconecte e prove de ponta a ponta

Quando o registro autoritativo estiver correto, o cliente ainda pode manter uma consulta antiga. Use a reconexão ou a atualização de endpoint suportada e dê a ele um momento em vez de martelar conectar. Depois prove o caminho em quatro passos: resolva o nome, confirme o endereço, verifique se o ouvinte é alcançável e autentique-se. Quatro resultados separados, quatro respostas separadas.

Mantenha o atualizador na lista de verificação de rotação ao lado da conta VPN. Um dono de registro pretendido, uma credencial válida e um sucesso observável são o que evita a próxima versão deste chamado.