Porque o DNS deixa de funcionar após a ligação do OpenVPN no Windows

Um ping ao resolver do escritório continua a obter resposta depois de o "OpenVPN" ligar, e mesmo assim cada pesquisa de nome falha. O endereço está acessível e a porta não, uma combinação que faz sentido quando se sabe que o Windows pode filtrar DNS por adaptador. Com block-outside-dns no perfil, esse filtro é o primeiro suspeito e a tabela de rotas é o local errado para procurar. Os dois testes abaixo separam as camadas em segundos.

Endereço acessível, porta morta

Um ping bem-sucedido prova que o anfitrião está ativo e que existe um caminho. Não diz nada sobre a permissão para alcançar a porta 53, porque o filtro em causa trabalha noutra camada e depende do adaptador. É por isso que a mesma máquina pode responder a ICMP e recusar cada consulta enviada para o mesmo endereço. Execute os dois testes na mesma sessão antes de alterar qualquer configuração.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Esse par é o diagnóstico. O tráfego normal para a sub-rede continua a funcionar enquanto a resolução de nomes morre, e as pessoas concluem que o servidor está avariado ou que o DNS nunca foi enviado. Ambas as explicações são caras de perseguir, e as provas apontam para algo mais estreito. Confirme o par antes de tocar numa definição.

A opção é uma regra da plataforma de filtragem

A referência do OpenVPN descreve o block-outside-dns como uma restrição do Windows Filtering Platform que impede as aplicações de alcançar o DNS em adaptadores fora do túnel. Abrange TCP e UDP na porta 53. Como o filtro vive no WFP e não na lista habitual de regras da firewall, acrescentar uma regra de permissão noutro local não altera necessariamente o resultado. É por isso que o conselho comum de permitir DNS continua a falhar.

A definição pode vir do perfil importado ou do servidor, e o ficheiro que editou por último "não é prova do que o cliente carregou". Leia a configuração efetiva e o registo de ligação em conjunto. A opção também é específica do Windows, e tratá-la como portátil produz conselhos que não se aplicam.

Procure o componente de cliente que possui a restrição em vez de acrescentar mais regras. O proprietário é aquilo que realmente a pode remover.

Um filtro não é um resolver

Bloquear o tráfego fora do túnel não instala um resolver funcional dentro dele. A opção remove um caminho e deixa a configuração de DNS do túnel a quem montou o perfil. Um perfil que nunca enviou um resolver agora não tem nenhum.

Percorra três verificações por ordem. Primeiro, que resolver a aplicação que falha usa realmente. Segundo, se o cliente aplicou as definições de DNS da VPN. Terceiro, que interface transporta o tráfego até esse resolver.

1. Resolver em uso: compare Resolve-DnsName -Server <resolver-ip> <name> com os servidores DNS que ipconfig /all lista.
2. DNS da VPN aplicado: examine as entradas DNS do adaptador do túnel na mesma saída de ipconfig /all.
3. Interface usada: Find-NetRoute -RemoteIPAddress <resolver-ip> indica a interface de saída para esse destino.

Um resolver de LAN fica inalcançável por desenho com esta política, mesmo enquanto outro tráfego de LAN funciona. É a opção a fazer o seu trabalho. Se o desenho precisar de DNS pela VPN, corrija o registo do resolver e o caminho do túnel; se for necessário split DNS com exceções locais, o proprietário da configuração tem de expressar essas exceções de forma suportada.

O que a opção não cobre

A porta 53 não é toda a resolução de nomes. DNS over HTTPS e DNS over TLS usam transportes diferentes, e algumas aplicações executam a sua própria lógica de resolver independentemente das definições do sistema. Um navegador pode, portanto, resolver nomes enquanto a linha de comandos não consegue.

Trate essa diferença como diagnóstico e não como contradição. Compare as duas coisas antes de decidir que o resolver do sistema está avariado.

Mantenha a conclusão estreita ao escrevê-la. Esta opção limita um transporte numa plataforma, e o resto do caminho de resolução é uma questão de desenho separada com o seu próprio proprietário.

Verifique o estado antes e depois da desligação

Execute a mesma pesquisa durante a ligação e de novo depois de o cliente proprietário se desligar. A primeira deve falhar para um resolver externo enquanto o túnel está ativo, e a segunda deve funcionar logo que o filtro é removido. Se continuar a falhar depois da desligação, o filtro não foi limpo.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Reiniciar o serviço de cliente ou a máquina costuma limpar um filtro antigo. Isso confirma o diagnóstico sem provar uma correção permanente. Anote o que viu, porque um filtro que sobrevive a uma desligação vai repetir, e é a nota que justifica um relatório de erro.

Só depois dessas verificações faz sentido substituir o resolver ou reconstruir a política da firewall. Ambas são mudanças maiores do que as provas sustentam.