A VPN assumiu o DNS e quebrou os nomes locais: conserte a lista

O túnel sobe, a intranet carrega e o nome da impressora deixa de resolver. Ou o contrário: os nomes locais ainda funcionam enquanto tudo dentro da rede corporativa expira. Os dois sintomas vêm do mesmo lugar, uma lista de resolvedores que o cliente VPN reescreveu ao conectar.

Conserte a lista de propósito e depois trate o mecanismo de push separadamente. As rotas são um terceiro assunto e não é o que está sendo consertado aqui.

Qual lista os aplicativos realmente usam

O Windows resolve por configurações no nível da interface e não pelo que uma caixa de diálogo mostra, então comece pelas listas efetivas de cada interface. O alias importa mais que o nome exibido, porque cada comando abaixo se dirige a uma interface. Erre o alias e o conserto cai no adaptador errado. Vai parecer funcionar até a próxima reconexão, quando a entrada do próprio túnel voltar.

A pergunta é quais servidores ficaram na frente e se chegaram como entradas estáticas ou como concessão DHCP. Os dois fatos decidem qual conserto está disponível para você.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Leia a saída do adaptador do túnel e do físico, e anote cada endereço em cada um. Uma entrada estática pode ser removida por política ou script; uma fornecida por DHCP está presa à concessão e vai voltar, o que muda o conserto que você deve escolher. Os nomes da rede remota são resolvidos pelo resolvedor anunciado, os da LAN local pelo adaptador físico, e a consulta vai para a lista consultada primeiro.

Remova os servidores empurrados, ou coloque-os mais abaixo

Apague os servidores empurrados quando nada dentro do túnel precisar deles, porque os resolvedores do adaptador físico assumem de novo. Mantenha-os só se a rede remota tiver zonas que apenas os servidores dela conseguem responder, e nesse caso ponha um resolvedor local na frente deles. Os dois comandos abaixo cobrem as duas escolhas, então escolha o que combina com a situação em vez de executar os dois.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

O índice 1 é consultado primeiro, então os endereços empurrados continuam disponíveis mas deixam de ser a resposta padrão para cada consulta. A sinalização validate=no pula um teste de alcance que costuma falhar enquanto o túnel ainda se acomoda, então confirme o resultado com o comando show em vez de confiar no código de saída.

Vale conhecer dois limites antes de confiar nisso. O Windows não apaga servidores que chegaram por DHCP através de netsh, e esses valores persistem como DhcpNameServer sob a chave de registro da interface, então editar o registro é o último recurso e precisa ser reconferido após a próxima concessão. A ordem de vinculação dos adaptadores também não é um mecanismo confiável de classificação, porque um cliente VPN pode inserir a própria entrada no topo da lista.

Onde o push pode ser filtrado

Um conserto melhor remove a opção antes de ela ser aplicada. O cliente Community OpenVPN consegue filtrar uma diretiva empurrada por nome, o que deixa a configuração do servidor intacta.

pull-filter ignore "dhcp-option DNS "

O espaço final pertence à correspondência e o filtro nomeia a opção, não um endereço de servidor. Se o perfil também contiver uma diretiva block-outside-dns, removê-la muda a proteção contra vazamento e não a resolução de nomes, então decida isso em separado em vez de juntar as duas edições.

Para um único nome de host teimoso, uma linha no arquivo hosts do Windows é mais estável que reordenar resolvedores para a máquina inteira. Também é invisível para a próxima pessoa, então registre onde a configuração da máquina é documentada.

Faça o conserto sobreviver a uma reconexão

A resolução precisa ser testada duas vezes, uma contra um servidor escolhido e outra na forma que um aplicativo usa. Esse par separa um problema de ordem de resolvedores de um servidor que não responde de jeito nenhum. Pular o primeiro teste deixa as duas causas emaranhadas.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Reconecte o túnel e repita os dois comandos. O que você mudou à mão dura só até a próxima conexão, porque o cliente reconstrói o estado dos resolvedores ao levantar o adaptador. Coloque as linhas netsh no script de conexão suportado do seu cliente, deixe esse script terminar com sucesso e acrescente uma espera curta antes de ele rodar. Um cliente que aplica DNS depois do script sobrescreve o resultado de qualquer forma.

Se os nomes públicos resolvem e os internos ainda falham depois do conserto, a lista de resolvedores deixou de ser a suspeita. A consulta provavelmente não chega ao servidor, o que aponta para roteamento ou uma regra de firewall e não para outra configuração de DNS. Anote o alias da interface e os endereços com que você ficou, porque ambos variam entre máquinas e nenhum sobrevive sozinho a uma reconstrução.