DNS enviado pelo OpenVPN ignorado: que componente o aplica

O registo mostra a opção enviada pelo servidor, o túnel está ativo e os nomes internos continuam a falhar. Uma consulta direta ao resolvedor responde, portanto o servidor está bem, mas todas as aplicações continuam a perguntar ao router local. O que chegou ao cliente é uma oferta, não uma alteração no resolvedor, e o componente que possui a resolução de nomes difere no Linux, Windows e macOS. Assim que separa a opção do seu dono, quatro falhas cobrem quase todos os relatórios: nenhum hook, dois hooks em competição, DNS dividido a funcionar como previsto, ou um nome curto que precisa de um sufixo e não de um servidor.

Uma opção enviada é uma oferta, não uma instalação

No servidor, duas diretivas descrevem a intenção, não o efeito:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

O cliente não recebe um resolvedor configurado. Recebe variáveis de ambiente, foreign_option_1 e seguintes, uma por cada linha enviada, e algo local tem de as ler e reescrever o estado do resolvedor do sistema operativo. No Linux nada o faz por predefinição, por isso um servidor correto e um cliente ligado ainda podem resolver através da LAN.

Entre os dois extremos há três etapas: o envio tem de chegar, o cliente tem de o expor e um hook tem de o aplicar. Leia a etapa intermédia no registo do cliente e a última no estado do resolvedor, nunca ao contrário, porque uma linha de registo só prova as duas primeiras.

Confirme que o envio chegou e encontre o dono

Comece por nomear o lançador: um comando openvpn simples, uma instância systemd, NetworkManager ou um cliente de fornecedor. Isso decide onde pode viver um hook. Num anfitrião com systemd-resolved, resolvectl status lista cada ligação com os servidores DNS e os domínios de pesquisa que realmente usa, e a ligação do túnel nem sempre se chama tun0.

Se o endereço enviado aparece no registo mas em nenhuma ligação, falta a integração. Se aparece na ligação e as consultas continuam a sair para outro lado, o problema é que consultas selecionam essa ligação. O NetworkManager dns=dnsmasq no ficheiro /etc/NetworkManager/NetworkManager.conf executa um reencaminhador local que implementa DNS dividido de propósito: os nomes dentro do domínio VPN vão para o resolvedor VPN e todo o resto mantém o caminho anterior. Este comportamento parece uma falha quando esperava que todo o tráfego se movesse; verifique as definições por ligação com nmcli connection show "My VPN", onde ipv4.dns e ipv4.dns-search guardam os valores por trás do que o dispositivo relata, antes de o chamar avariado. Se todas as consultas devem realmente chegar ao resolvedor VPN, remova dns=dnsmasq de NetworkManager.conf e reinicie o NetworkManager, o que devolve a resolução às definições da ligação; caso contrário, mantenha o DNS dividido e corrija a lista de domínios enviada.

Linux: entregue as opções ao resolvedor

Os pacotes das distribuições incluem um hook para isto, e o cliente tem de estar autorizado a executá-lo. Uma disposição típica num anfitrião sem systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Com systemd-resolved, o script antigo de resolv.conf pode não mudar nada de importante, porque o resolvedor stub mantém estado por ligação. update-systemd-resolved o auxiliar documenta uma forma de hook que usa up-restart e down-pre, o que conta quando uma interface sobrevive a uma única tentativa de ligação. Escolha o que escolher, um componente tem de possuir o estado. Acrescentar um hook alheio ao lado do NetworkManager dá dois escritores à mesma ligação, e o resultado passa a depender da ordem e não da sua configuração.

Existe também o caso em que o NetworkManager ignorou por completo a opção enviada até o endereço do servidor ser introduzido nas definições IPv4 da ligação, e só então o estado do resolvedor mostrou que estava em uso. Vale a pena tentar antes de reescrever scripts, porque move o problema de um hook de shell para o perfil de ligação que já transporta o túnel.

Windows e macOS aplicam partes diferentes

O cliente Windows define de facto os servidores DNS do adaptador VPN, mas o Windows continua a escolher a interface por métrica e continua a precisar de um sufixo para expandir um nome curto. Confirme o estado do adaptador e não o perfil:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Se o endereço faltar, defina-o com Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, depois acrescente o sufixo às propriedades IPv4 do adaptador para que fileserver se torne fileserver.corp.example. Um valor SearchList de toda a máquina em Tcpip\Parameters faz o mesmo. Onde o nome longo resolve e o simples não, o resolvedor já está correto e a culpa é da lista de pesquisa. As correções, por ordem: envie um DOMAIN para o cliente aprender o sufixo, acrescente esse sufixo à lista de pesquisa do adaptador ou da ligação, e como medida temporária fixe o nome em hosts, ou LMHOSTS no Windows; a navegação NetBIOS não atravessa um router, por isso o broadcast que encontra um nome curto na LAN do escritório nunca chega a um cliente de túnel.

block-outside-dns block-outside-dns é um comportamento do cliente Windows, não uma linha de perfil portátil, e copiá-lo para um perfil Linux ou macOS não o reproduz ali. Se os nomes públicos funcionam e os internos falham no Windows, compare a ordem dos adaptadores em Definições avançadas com ipconfig /all. No macOS a ordem dos resolvedores por serviço pertence ao sistema, por isso use scutil --dns para ver que resolvedor é consultado para que domínio, e trate qualquer correção de perfil reportada como dependente do cliente e não geral.

Uma máquina virtual no mesmo portátil não herda nada disto. Dê ao convidado a sua própria entrada de resolvedor para o domínio interno, ou deixe o NAT do hipervisor reencaminhar as consultas através do anfitrião, o que só é correto enquanto o túnel do anfitrião estiver ativo.

O histórico é a terceira causa. Servidores DNS ou definições de sufixo de um perfil anterior podem sobreviver a reconexões, por isso quando o adaptador parece correto e as pesquisas continuam a falhar, compare o adaptador ativo com Get-VpnConnection e apague ou substitua a entrada obsoleta antes de tocar no servidor.

Prove para onde foi a consulta

Uma captura durante uma pesquisa resolve a discussão: tcpdump -ni eth0 port 53 mostra consultas na interface física, o que significa que saem fora do túnel e que o resolvedor nunca foi trocado. dig @10.8.0.1 name.corp.example depois separa os dois casos restantes. Se a consulta direta responde, o resolvedor funciona e o cliente não o usa; se expira, o resolvedor é inalcançável pelo túnel e nenhuma alteração local ajudará.

Se o resolvedor ainda em uso é o que o fornecedor distribuiu, o túnel cifra o tráfego mas os nomes continuam visíveis para esse fornecedor. É uma questão de fuga e não de funcionamento, e a mesma captura responde: uma consulta na interface física vai para alguém fora do túnel.

A acessibilidade inclui a firewall no anfitrião VPN, que deve permitir UDP e TCP 53 a partir do conjunto. Uma porta bloqueada parece exatamente um envio quebrado, e também um resolvedor que só responde de dentro da rede do túnel. Repita a captura após uma desconexão e reconexão, porque definições que aparecem na primeira ligação e desaparecem na segunda são uma falha do ciclo de vida no hook, não uma opção em falta.

Mantenha um único dono e verifique por ordem

Um script que reescreve o DNS do adaptador com base num estado de túnel suposto duplica configuração que o perfil já transporta, e falha em silêncio na primeira vez que a suposição está errada. Prefira as definições DNS da própria ligação ou um único hook documentado, e registe qual escolheu para que a pessoa seguinte não acrescente um segundo.

Feche o ciclo com quatro verificações: o endereço enviado presente na ligação do túnel, o nome interno resolvido como nome plenamente qualificado, o mesmo nome resolvido sem o sufixo, e ambos ainda verdadeiros após uma reconexão. Uma captura diz-lhe qual das quatro falhou. O manual do OpenVPN 2.6 enumera dhcp-option e as diretivas de script com as suas notas de plataforma.