wg-quick quebra o DNS ao conectar: leia o erro de configuração
A linha DNS pertence ao auxiliar de configuração, não ao protocolo par. Leia o primeiro erro, verifique a rota do resolvedor e confirme que a limpeza restaura o estado anterior.
O túnel sobe, o handshake termina e a resolução de nomes para. Nada na configuração do par mudou, porque a linha DNS nunca fez parte dessa configuração. Ela pertence ao auxiliar de configuração, o que significa que a falha vive nas ferramentas do resolvedor do host e não nas chaves do WireGuard.
Leia a primeira mensagem que o auxiliar imprimiu, não a última, e a diferença entre um utilitário ausente e um servidor inalcançável fica óbvia.
A linha DNS é um recurso do auxiliar
Os campos básicos da configuração descrevem pares, chaves e endereços permitidos. A resolução é adicionada por cima pelo script que levanta a interface, e cada implementação faz isso de modo diferente. Um cliente de desktop pode gerenciar o DNS pelo próprio serviço, um script de distribuição pode chamar um de vários utilitários de resolvedor, e um contêiner pode não fazer nenhum dos dois. O arquivo de configuração não pode dizer qual desses caminhos está em jogo.
Por isso um arquivo de configuração pode ser válido para o protocolo e ainda assim falhar durante a configuração: a falha pertence a um gancho que o protocolo nunca vê.
Escrever um campo estendido numa configuração básica e esperar que a ferramenta do protocolo o aceite produz a mesma confusão na direção oposta. Os dois analisadores leem arquivos diferentes.
Saber qual dos dois está rodando é o primeiro passo de diagnóstico, e normalmente aparece no comando digitado, não no arquivo de configuração.
Leia o primeiro erro que o auxiliar imprime
Levante a interface em primeiro plano e leia a saída em ordem. Um utilitário de resolvedor ausente, um gancho falho e um servidor inalcançável param o mesmo comando em pontos diferentes, e cada um tem um conserto diferente.
wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1
O primeiro comando relata o progresso da configuração, o segundo mostra quais servidores a interface reivindica agora, e o terceiro mostra se o endereço do resolvedor é realmente alcançável pelo túnel. Um resolvedor configurado mas não roteável produz tempos limite em vez de erros de configuração, por isso as duas verificações andam juntas. Ler apenas a saída de status produz uma conclusão confiante e errada.
Se a configuração terminou e a resolução de nomes ainda falha, compare o resolvedor que o auxiliar instalou com o que a rede usava antes. Um resolvedor privado precisa de uma rota pelo túnel, e uma configuração que o lista sem cobrir seu prefixo deixa toda consulta esperando.
Qual resolvedor o host realmente tem
Hosts Linux modernos costumam executar um resolvedor stub local, então o endereço que o auxiliar instala é consumido por esse stub e não diretamente pelos aplicativos. Editar à mão um arquivo gerado pode parecer funcionar até a próxima reconexão, quando o auxiliar o reescreve.
Use a integração suportada para a distribuição e deixe um único componente ser dono do estado do resolvedor. Dois donos produzem a mesma corrida que dois donos de um endereço de interface, e o sintoma é um host que resolve corretamente por alguns minutos após cada mudança.
Nomes internos merecem verificação própria. Um resolvedor público pode restaurar a navegação geral enquanto faz todo nome corporativo falhar, o que é o oposto do propósito do túnel. Consulte o nome interno no servidor pretendido antes de concluir que o DNS está consertado.
A limpeza importa tanto quanto a configuração
Derrube a interface e inspecione novamente o estado do resolvedor. Um auxiliar que restaura a configuração anterior deixa o host utilizável; um que deixa os próprios servidores para trás cria a próxima falha, muitas vezes horas depois, quando o túnel já se foi há muito.
Estado obsoleto é fácil de ver quando se procura. Uma lista de resolvedores pode apontar para um endereço numa interface que não existe mais, e um domínio de busca pode sobreviver a uma rede que você deixou esta manhã. Qualquer um dos dois torna a próxima conexão imprevisível, e nenhum aparece na saída de status do próprio túnel. A verificação leva dez segundos e poupa uma hora à próxima pessoa.
Mantenha o diagnóstico separado do conserto. Se todo destino falha e não apenas as consultas de nomes, as rotas e o encaminhamento são os suspeitos e a linha DNS é uma distração. O manual do wg-quick documenta quais campos ele trata e quais pertencem ao protocolo, e essa fronteira é toda a resposta para a maioria desses relatos.