O WireGuard continua a usar o endpoint antigo após alterações de DNS

O túnel deixou de passar tráfego depois de o registo DNS do servidor se mover, e o nome resolve corretamente a partir da mesma máquina. Estes dois factos não estão em conflito. Uma configuração do WireGuard contém um endpoint, e a ferramenta resolve o nome no momento em que aplica essa configuração, pelo que a interface em execução pode continuar a usar o endereço que consultou há horas. Verifique o que a interface usa antes de substituir chaves ou de tocar no intervalo do túnel.

O nome é resolvido uma vez, não continuamente

A configuração base do WireGuard recebe um endpoint como endereço e porta, e a ferramenta que levanta uma interface resolve um nome de anfitrião nesse momento. Nada no protocolo base consulta o DNS segundo um calendário, e uma aplicação cliente pode acrescentar por cima o seu próprio comportamento de atualização. Registar o endereço resolvido, a família e a porta ao lado do nome torna a lacuna visível. Sem esse registo a configuração parece correta enquanto a interface fala com outro sítio.

Existe uma atualização automática genuína, e vale a pena conhecê-la porque se parece com uma atualização de DNS sem o ser. O endpoint de um par pode deslocar-se quando chega tráfego corretamente autenticado de um endereço novo, o que é itinerância e não resolução de nomes. Segue o par, por isso não pode descobrir um servidor novo não relacionado que o endpoint antigo nunca contactou.

Compare o registo com o endereço em uso

Consulte o nome documentado através do resolvedor que o cliente usa e depois pergunte à interface que endpoint mantém. As duas respostas são a comparação que decide o resto desta página:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

A página de manual wg(8) documenta os subcomandos show usados por estas linhas. Compare também a família do endereço, não apenas o endereço, porque um registo que ganhou uma entrada IPv6 é uma comparação diferente de um cujo endereço IPv4 mudou. Se o endpoint diferir do registo, a interface está a funcionar com informação desatualizada e o nome nunca foi o problema. Se coincidirem e o túnel continuar a falhar, passe ao ouvinte e às regras em vez de ao perfil.

O registo temporal do aperto de mão está nesse bloco porque o endpoint sozinho não diz se o par é alcançável. Um registo temporal desatualizado ao lado de um endpoint correto é um problema de caminho, não de resolução, e essa distinção muda o que toca a seguir.

Reinicie através do gestor da interface

Depois de confirmado que o endpoint está desatualizado, atualize-o através do mecanismo que possui a interface em vez de editar a configuração em execução. Para uma interface iniciada por wg-quick isso é um descer e subir, para uma unidade systemd é um reinício, e para uma interface propriedade de um gestor é uma alteração feita nesse gestor, porque uma edição em tempo de execução é substituída na aplicação seguinte:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Depois confirme que o ouvinte de substituição e a sua identidade são o serviço que pretendia. Um movimento de DNS não é uma mudança de identidade, por isso nunca deve ser a ocasião para confiar numa chave que não verificou. Se a interface agora reporta o endereço novo e continua a não produzir qualquer aperto de mão, a falha mudou para o novo caminho de rede ou para o ouvinte, o que é progresso e não a mesma falha duas vezes.

Primeiro o aperto de mão, depois o caminho de dados

Separe os dois resultados antes de escolher uma lista de verificação. Um aperto de mão que tem sucesso sob uma aplicação que falha é um problema do caminho de dados: rotas, prefixos permitidos ou DNS dentro do túnel. Um aperto de mão que nunca acontece é um problema de alcançabilidade ou de identidade no endpoint. Misturar os dois produz um relatório que ninguém consegue reproduzir e um registo de alterações com três edições não relacionadas.

Anote o nome, o endereço resolvido, o endpoint em uso e se o aperto de mão foi concluído. Esses quatro factos respondem à pergunta que esta falha não se cansa de fazer, e transformam a próxima ocorrência numa verificação de dois minutos. A manutenção do nome e a adoção do cliente continuam a ser tarefas separadas: corrigir o registo não realiza a adoção, e reiniciar a interface não corrige um registo que continua errado.