Per què el DNS deixa de funcionar després de connectar OpenVPN a Windows

Un ping al resolutor de l’oficina encara respon després que "OpenVPN" es connecti, i tot i així cada consulta de nom falla. L’adreça és abastable mentre el port no ho és, una combinació que té sentit quan sabeu que Windows pot filtrar DNS per adaptador. Amb block-outside-dns al perfil, aquest filtre és el primer sospitós i la taula d’encaminament és el lloc equivocat on mirar. Les dues proves següents separen les capes en segons.

Adreça abastable, port mort

Un ping correcte demostra que l’equip és actiu i que existeix un camí. No diu res sobre el permís per arribar al port 53, perquè el filtre en qüestió treballa en una altra capa i depèn de l’adaptador. Per això la mateixa màquina pot respondre a ICMP i refusar cada consulta enviada a la mateixa adreça. Executeu les dues proves a la mateixa sessió abans de canviar cap configuració.

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

La parella és el diagnòstic. El trànsit ordinari a la subxarxa continua funcionant mentre la resolució de noms mor, i la gent conclou que el servidor està espatllat o que el DNS no es va enviar mai. Totes dues explicacions són cares de perseguir, i les evidències apunten a un lloc més estret. Confirmeu la parella abans de tocar cap paràmetre.

L’opció és una regla de la plataforma de filtratge

La referència d’OpenVPN descriu block-outside-dns com una restricció de Windows Filtering Platform que impedeix que les aplicacions arribin al DNS en adaptadors fora del túnel. Cobreix TCP i UDP al port 53. Com que el filtre viu a WFP i no a la llista habitual de regles del tallafoc, afegir una regla de permís en un altre lloc no canvia necessàriament el resultat. Per això el consell habitual de permetre DNS continua fallant.

El paràmetre pot arribar del perfil importat o del servidor, i el fitxer que vau editar l’última vegada "no és prova del que el client ha carregat". Llegiu la configuració efectiva i el registre de connexió alhora. L’opció també és específica de Windows, i tractar-la com a portàtil produeix consells que no s’apliquen.

Busqueu el component de client que posseeix la restricció en lloc d’afegir més regles. El propietari és allò que realment la pot eliminar.

Un filtre no és un resolutor

Bloquejar el trànsit fora del túnel no instal·la cap resolutor funcional dins seu. L’opció elimina un camí i deixa la configuració DNS del túnel a qui va muntar el perfil. Un perfil que mai va enviar cap resolutor ara no en té cap.

Passeu per tres comprovacions en ordre. Primer, quin resolutor fa servir realment l’aplicació que falla. Segon, si el client ha aplicat els paràmetres DNS de la VPN. Tercer, quina interfície porta el trànsit cap a aquest resolutor.

1. Resolutor en ús: compareu Resolve-DnsName -Server <resolver-ip> <name> amb els servidors DNS que llista ipconfig /all.
2. DNS de la VPN aplicat: reviseu les entrades DNS de l’adaptador del túnel a la mateixa sortida de ipconfig /all.
3. Interfície utilitzada: Find-NetRoute -RemoteIPAddress <resolver-ip> indica la interfície de sortida per a aquesta destinació.

Un resolutor de LAN esdevé inabastable per disseny amb aquesta política, fins i tot mentre altre trànsit de LAN funciona. Això és l’opció fent la seva feina. Si el disseny necessita DNS per VPN, arregleu el registre del resolutor i el camí del túnel; si cal split DNS amb excepcions locals, el propietari de la configuració ha d’expressar aquestes excepcions d’una manera suportada.

Què no cobreix l’opció

El port 53 no és tota la resolució de noms. DNS over HTTPS i DNS over TLS fan servir transports diferents, i algunes aplicacions executen la seva pròpia lògica de resolutor independentment dels paràmetres del sistema. Per tant, un navegador pot resoldre noms mentre la línia d’ordres no pot.

Tracteu aquesta diferència com un diagnòstic i no com una contradicció. Compareu les dues coses abans de decidir que el resolutor del sistema està espatllat.

Mantingueu la conclusió estreta quan la redacteu. Aquesta opció restringeix un transport en una plataforma, i la resta del camí de resolució és una qüestió de disseny separada amb el seu propi propietari.

Comproveu l’estat abans i després de desconnectar

Executeu la mateixa consulta durant la connexió i de nou després que el client propietari es desconnecti. La primera hauria de fallar per a un resolutor extern mentre el túnel és actiu, i la segona hauria de funcionar quan el filtre s’hagi eliminat. Si encara falla després de desconnectar, el filtre no s’ha netejat.

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

Reiniciar el servei de client o la màquina normalment neteja un filtre antic. Això confirma el diagnòstic sense demostrar una solució permanent. Anoteu què vau veure, perquè un filtre que sobreviu a una desconnexió ho tornarà a fer, i l’anotació és el que justifica un informe d’error.

Només després d’aquestes comprovacions té sentit substituir el resolutor o reconstruir la política del tallafoc. Tots dos són canvis més grans del que les evidències suporten.