El VPN va prendre el DNS i va trencar els noms locals: arregla la llista

El túnel puja, la intranet carrega i el nom de la impressora deixa de resoldre's. O al revés: els noms locals encara funcionen mentre tot el que hi ha dins de la xarxa corporativa expira. Tots dos símptomes vénen del mateix lloc, una llista de resolutors que el client VPN va reescriure en connectar-se.

Repara la llista deliberadament i després tracta el mecanisme push per separat. Les rutes són un tercer tema i no és el que s'arregla aquí.

Quina llista fan servir realment les aplicacions

Windows resol mitjançant paràmetres a nivell d'interfície i no pas mitjançant el que mostra un diàleg, així que comença per les llistes efectives de cada interfície. L'àlies importa més que el nom mostrat, perquè cada ordre d'aquí sota adreça una interfície. Si t'equivoques amb l'àlies, la reparació caurà a l'adaptador equivocat. Semblarà que funciona fins a la propera reconnexió, quan torni l'entrada pròpia del túnel.

La pregunta és quins servidors van acabar al davant i si van arribar com a entrades estàtiques o com a lloguer DHCP. Tots dos fets decideixen quina reparació tens disponible.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Llegeix la sortida de l'adaptador del túnel i de l'adaptador físic, i anota cada adreça de cadascun. Una entrada estàtica es pot eliminar amb una política o un script; una entrada proporcionada per DHCP està lligada al lloguer i tornarà, cosa que canvia la reparació que has de triar. Els noms de la xarxa remota els resol el resolutor anunciat, els noms de la LAN local l'adaptador físic, i la consulta va a la llista que es consulta primer.

Elimina els servidors empesos o posa'ls més avall

Esborra els servidors empesos quan res dins del túnel no els necessita, perquè els resolutors propis de l'adaptador físic tornen a prendre el relleu. Conserva'ls només si la xarxa remota té zones que només els seus servidors poden respondre, i en aquest cas posa un resolutor local al davant. Les dues ordres d'aquí sota cobreixen totes dues opcions, així que tria la que encaixi amb la situació en lloc d'executar-les totes dues.

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

L'índex 1 es consulta primer, així que les adreces empeses continuen disponibles però deixen de ser la resposta per defecte a cada consulta. L'indicador validate=no omet una prova d'abastabilitat que sovint falla mentre el túnel encara s'assenta, així que confirma el resultat amb l'ordre show en lloc de confiar en el codi de sortida.

Val la pena conèixer dos límits abans de fiar-te'n. Windows no esborrarà els servidors que van arribar per DHCP a través de netsh, i aquests valors persisteixen com a DhcpNameServer sota la clau de registre de la interfície, així que editar el registre és un últim recurs que cal tornar a comprovar després del proper lloguer. L'ordre d'enllaç dels adaptadors tampoc no és un mecanisme de classificació fiable, perquè un client VPN pot inserir la seva entrada al capdamunt de la llista.

On es pot filtrar el push

Una reparació millor treu l'opció abans que s'apliqui. El client Community OpenVPN pot filtrar una directiva empesa pel nom, cosa que deixa la configuració del servidor intacta.

pull-filter ignore "dhcp-option DNS "

L'espai final pertany a la coincidència i el filtre anomena l'opció, no una adreça de servidor. Si el perfil també conté una directiva block-outside-dns, treure-la canvia la protecció contra fuites i no la resolució de noms, així que decideix-ho a part en lloc d'ajuntar les dues edicions.

Per a un sol nom d'amfitrió tossut, una línia al fitxer hosts de Windows és més estable que reordenar resolutors per a tota la màquina. També és invisible per a la propera persona, així que anota-ho on es documenti la configuració de la màquina.

Fes que la reparació sobrevisqui a una reconnexió

La resolució s'ha de provar dues vegades, una contra un servidor triat i una en la forma que fa servir una aplicació. Aquest parell separa un problema d'ordre de resolutors d'un servidor que no respon mai. Saltar-se la primera prova deixa les dues causes embullades.

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

Torna a connectar el túnel i repeteix totes dues ordres. El que hagis canviat a mà només dura fins a la propera connexió, perquè el client reconstrueix el seu estat de resolutors mentre aixeca l'adaptador. Posa les línies netsh a l'script de connexió admès del teu client, deixa que aquest script acabi amb èxit i afegeix una espera curta abans que s'executi. Un client que apliqui DNS després de l'script sobreescriurà el resultat igualment.

Si els noms públics es resolen i els interns encara fallen després de la reparació, la llista de resolutors ha deixat de ser el sospitós. La consulta probablement no arriba gens al servidor, cosa que apunta a l'encaminament o a una regla de tallafoc i no a un altre paràmetre DNS. Anota l'àlies de la interfície i les adreces amb què t'has quedat, perquè tots dos difereixen entre màquines i cap no sobreviu sol a una reconstrucció.