Por que o DNS deixa de funcionar despois de conectar OpenVPN en Windows

Un ping ao resolutor da oficina segue respondendo despois de que "OpenVPN" se conecte, e aínda así cada consulta de nome falla. O enderezo é alcanzable mentres o porto non o é, unha combinación que ten sentido cando sabe que Windows pode filtrar DNS por adaptador. Con block-outside-dns no perfil, ese filtro é o primeiro sospeitoso e a táboa de rutas é o lugar equivocado onde mirar. As dúas probas seguintes separan as capas en segundos.

Enderezo alcanzable, porto morto

Un ping correcto demostra que o host está activo e que existe unha ruta. Non di nada sobre o permiso para chegar ao porto 53, porque o filtro en cuestión traballa noutra capa e depende do adaptador. Por iso a mesma máquina pode responder a ICMP e rexeitar cada consulta enviada ao mesmo enderezo. Execute ambas as probas na mesma sesión antes de cambiar calquera configuración.

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

O par é o diagnóstico. O tráfico normal cara á subrede segue funcionando mentres morre a resolución de nomes, e a xente conclúe que o servidor está roto ou que o DNS nunca se enviou. Ambas as explicacións son caras de perseguir, e a evidencia apunta a algo máis estreito. Confirme o par antes de tocar calquera axuste.

A opción é unha regra da plataforma de filtrado

A referencia de OpenVPN describe block-outside-dns como unha restrición de Windows Filtering Platform que impide que as aplicacións cheguen ao DNS en adaptadores fóra do túnel. Cobre TCP e UDP no porto 53. Como o filtro vive en WFP e non na lista habitual de regras da devasa, engadir unha regra de permiso noutro lugar non cambia necesariamente o resultado. Por iso o consello común de permitir DNS segue fallando.

O axuste pode chegar do perfil importado ou do servidor, e o ficheiro que editou por última vez "non é proba do que cargou o cliente". Lea a configuración efectiva e o rexistro de conexión xuntos. A opción tamén é específica de Windows, e tratala como portátil produce consellos que non se aplican.

Busque o compoñente de cliente que posúe a restrición en lugar de engadir máis regras. O propietario é o que realmente pode eliminala.

Un filtro non é un resolutor

Bloquear o tráfico fóra do túnel non instala un resolutor funcional dentro del. A opción elimina unha ruta e deixa a configuración DNS do túnel a quen montou o perfil. Un perfil que nunca enviou un resolutor agora non ten ningún.

Percorra tres comprobacións en orde. Primeiro, que resolutor usa realmente a aplicación que falla. Segundo, se o cliente aplicou os axustes de DNS da VPN. Terceiro, que interface leva o tráfico a ese resolutor.

1. Resolutor en uso: compare Resolve-DnsName -Server <resolver-ip> <name> cos servidores DNS que enumera ipconfig /all.
2. DNS da VPN aplicado: examine as entradas DNS do adaptador do túnel na mesma saída de ipconfig /all.
3. Interface utilizada: Find-NetRoute -RemoteIPAddress <resolver-ip> nomea a interface de saída para ese destino.

Un resolutor de LAN vólvese inalcanzable por deseño con esta política, mesmo mentres outro tráfico de LAN funciona. Iso é a opción facendo o seu traballo. Se o deseño necesita DNS por VPN, corrixa o rexistro do resolutor e a ruta do túnel; se se require split DNS con excepcións locais, o propietario da configuración debe expresar esas excepcións dun xeito admitido.

O que a opción non cobre

O porto 53 non é toda a resolución de nomes. DNS over HTTPS e DNS over TLS usan transportes distintos, e algunhas aplicacións executan a súa propia lóxica de resolutor con independencia dos axustes do sistema. Un navegador pode por tanto resolver nomes mentres a liña de comandos non pode.

Trate esa diferenza como un diagnóstico e non como unha contradición. Compare ambas antes de decidir que o resolutor do sistema está roto.

Manteña a conclusión estreita ao redactala. Esta opción restrinxe un transporte nunha plataforma, e o resto do camiño de resolución é unha cuestión de deseño aparte co seu propio propietario.

Comprobe o estado antes e despois de desconectar

Execute a mesma consulta durante a conexión e de novo despois de que o cliente propietario se desconecte. A primeira debería fallar para un resolutor externo mentres o túnel está activo, e a segunda debería funcionar unha vez eliminado o filtro. Se segue fallando despois de desconectar, o filtro non se limpou.

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

Reiniciar o servizo de cliente ou a máquina adoita limpar un filtro antigo. Iso confirma o diagnóstico sen demostrar unha solución permanente. Anote o que viu, porque un filtro que sobrevive a unha desconexión faráo outra vez, e a anotación é o que xustifica un informe de erro.

Só despois desas comprobacións ten sentido substituír o resolutor ou reconstruír a política da devasa. Ambas son cambios maiores do que a evidencia respalda.