A VPN tomou o control do DNS e rompeu os nomes locais: arranxa a lista

O túnel sobe, a intranet carga e o nome da impresora deixa de resolverse. Ou ao revés: os nomes locais seguen funcionando mentres todo o que hai dentro da rede corporativa esgota o tempo. Ambos os síntomas veñen do mesmo sitio, unha lista de resolutores que o cliente VPN reescribiu ao conectarse.

Arranxa a lista a propósito e despois ocúpate do mecanismo push por separado. As rutas son un terceiro tema e non é o que se arranxa aquí.

Que lista usan realmente as aplicacións

Windows resolve mediante axustes a nivel de interface e non mediante o que mostre un diálogo, así que comeza polas listas efectivas de cada interface. O alias importa máis que o nome mostrado, porque cada comando de abaixo diríxese a unha interface. Se te equivocas co alias, a reparación caerá no adaptador incorrecto. Parecerá funcionar ata a seguinte reconexión, cando volva a entrada propia do túnel.

A pregunta é que servidores acabaron diante e se chegaron como entradas estáticas ou como concesión DHCP. Ambos os feitos deciden que reparación tes dispoñible.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Le a saída do adaptador do túnel e do físico, e anota cada enderezo de cada un. Unha entrada estática pódese eliminar cunha directiva ou un script; unha proporcionada por DHCP está ligada á concesión e volverá, o que cambia a reparación que debes elixir. Os nomes da rede remota resólveos o resolutor anunciado, os da LAN local o adaptador físico, e a consulta vai á lista que se consulte primeiro.

Elimina os servidores empurrados ou colócaos máis abaixo

Borra os servidores empurrados cando nada dentro do túnel os necesite, porque os resolutores propios do adaptador físico volven tomar o relevo. Consérvaos só se a rede remota ten zonas que unicamente os seus servidores poden responder, e nese caso pon un resolutor local por diante. Os dous comandos de abaixo cobren ambas as opcións, así que escolle o que encaixe coa situación en vez de executar os dous.

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 consúltase primeiro, así que os enderezos empurrados seguen dispoñibles pero deixan de ser a resposta predeterminada a cada consulta. O indicador validate=no omite unha proba de accesibilidade que a miúdo falla mentres o túnel aínda se asenta, así que confirma o resultado co comando show en lugar de fiarte do código de saída.

Vale a pena coñecer dous límites antes de fiarse disto. Windows non borrará os servidores que chegaron por DHCP a través de netsh, e eses valores persisten como DhcpNameServer baixo a clave de rexistro da interface, así que editar o rexistro é un último recurso que hai que volver comprobar tras a seguinte concesión. A orde de enlace dos adaptadores tampouco é un mecanismo de clasificación fiable, porque un cliente VPN pode inserir a súa propia entrada na parte superior da lista.

Onde se pode filtrar o push

Unha reparación mellor quita a opción antes de que se aplique. O cliente Community OpenVPN pode filtrar unha directiva empurrada por nome, o que deixa intacta a configuración do servidor.

pull-filter ignore "dhcp-option DNS "

O espazo final pertence á coincidencia e o filtro nomea a opción, non un enderezo de servidor. Se o perfil tamén contén unha directiva block-outside-dns, quitala cambia a protección contra fugas e non a resolución de nomes, así que decide iso por separado en vez de agrupar as dúas edicións.

Para un só nome de host teimudo, unha liña no ficheiro hosts de Windows é máis estable que reordenar resolutores para toda a máquina. Tamén é invisible para a seguinte persoa, así que anótaa onde se documente a configuración da máquina.

Fai que a reparación sobreviva a unha reconexión

A resolución debe probarse dúas veces, unha contra un servidor elixido e outra na forma que usa unha aplicación. Ese par separa un problema de orde de resolutores dun servidor que non responde en absoluto. Saltarse a primeira proba deixa as dúas causas enredadas.

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

Reconecta o túnel e repite ambos os comandos. O que cambias a man só dura ata a seguinte conexión, porque o cliente reconstrúe o seu estado de resolutores mentres levanta o adaptador. Pon as liñas netsh no script de conexión admitido do teu cliente, deixa que ese script remate con éxito e engade unha espera breve antes de que se execute. Un cliente que aplique DNS despois do script sobrescribirá o resultado de todos os xeitos.

Se os nomes públicos se resolven e os internos seguen fallando tras a reparación, a lista de resolutores deixou de ser o sospeitoso. A consulta probablemente non chega ao servidor en absoluto, o que apunta ao enrutamento ou a unha regra de devasado e non a outro axuste de DNS. Anota o alias da interface e os enderezos cos que quedaches, porque ambos difiren entre máquinas e ningún sobrevive só a unha reconstrución.