O OpenVPN envia DNS, mas o seu resolver pode nunca o ver

O log do cliente mostra o servidor DNS enviado, o túnel está ligado e um nome interno continua sem resolver. Nada está avariado no próprio envio. A opção chegou e o resolver do sistema operativo nunca a usou, porque na maioria dos clientes Unix o OpenVPN entrega o valor e deixa a aplicação para a plataforma.

O sintoma: o log mostra DNS e os nomes continuam a falhar

OpenVPN dhcp-option transporta informações de DNS e de domínio, e o cliente regista o que recebeu. Nalgumas implementações o cliente aplica essas definições internamente; noutras exporta-as para um script de integração ou um serviço de rede. A linha do log descreve apenas a primeira metade da história. A segunda metade acontece num lugar que o cliente não controla. É aí que a falha costuma viver.

Por isso um túnel ligado e um nome interno que falha coexistem tantas vezes. O valor está presente, o consumidor falta ou está mal configurado, e o resolver continua silenciosamente a usar o servidor público que usava antes da ligação.

Recebido não é aplicado

Um cliente pode registar um valor DNS enviado enquanto o resolver do sistema continua a pertencer a outro serviço. Um navegador pode também ter a sua própria política de DNS cifrado que contorna totalmente o resolver do sistema, o que produz a memorável situação em que uma aplicação resolve nomes internos e outra não.

Verifique a integração suportada pela implementação em vez de assumir que todos os clientes Unix reescrevem o mesmo ficheiro. É essa suposição a razão pela qual as pessoas editam uma configuração de resolver que nada lê.

Encontre o proprietário do resolver em cada plataforma

No Windows, a tabela de políticas de resolução de nomes pode encaminhar sufixos específicos para servidores específicos, e o cliente VPN pode instalar regras aí. Verifique a política, não apenas a lista DNS do adaptador. No Linux, o NetworkManager ou o systemd-resolved podem ser donos da configuração, e qual deles é o dono determina o que uma reconexão preserva.

Leia o estado efetivo com a ferramenta que realmente responde a consultas: resolvectl query internal.example.net num anfitrião com systemd-resolved, ou o equivalente da plataforma. Depois compare essa resposta com o servidor DNS que o log do cliente diz ter enviado.

Evite executar vários serviços que substituem as definições do resolver sem coordenação. Dois proprietários produzem um resultado que parece intermitente, e cada reconexão parece corrigi-lo ou quebrá-lo ao acaso.

Scripts e foreign_option

O OpenVPN exporta as opções enviadas para scripts através de variáveis chamadas foreign_option_N, e um script pode traduzi-las em comandos do resolver. Essa disposição é uma integração suportada, não um comportamento automático, e tem de ser instalada e invocada no cliente.

Se depender de um script, registe a sua execução e o seu estado de saída. Um script que corre mas falha em silêncio deixa o mesmo sintoma de nenhum script, e é mais difícil de notar porque a configuração parece completa. Verifique a saída do script, não o ficheiro do script. Um ficheiro que existe não é um script que correu.

Teste o nome, não o log

Pergunte ao cliente por um nome de anfitrião apenas interno depois de ligar, depois pergunte por um nome público e depois verifique qual servidor respondeu. Numa configuração que funciona, as duas respostas vêm de lugares diferentes, e ambas devem corresponder ao projeto.

Se o nome resolve mas o serviço falha, avance para encaminhamento e acesso de aplicações em vez de mudar o DNS outra vez. O manual do OpenVPN documenta o dhcp-option e o ambiente de scripts; use-o para confirmar o que se espera que o seu cliente aplique antes de editar outro ficheiro de resolver.