O túnel dividido exclúe o navegador, non as súas consultas DNS

Navegador excluído do túnel, a páxina de IP pública confirma que o seu tráfico sae pola conexión da casa, e a wiki interna segue sen abrirse. A resolución de nomes foise a outro sitio, e ese outro sitio adoita ser o resolutor que configurou a VPN. A ruta de datos e a ruta do resolutor son decisións separadas na maioría dos deseños de túnel dividido. Comprobe cal usou realmente o navegador antes de chamar rota á exclusión.

A ruta de datos e a ruta do resolutor sepáranse

Unha exclusión saca os paquetes dunha aplicación do túnel, o que é unha decisión de encamiñamento e cortafogos na ruta de datos. A resolución de nomes é outra consulta: un proceso pregunta ao resolutor do sistema, e ese resolutor decide que servidor recibe a pregunta.

Ambas poden ser intencionadas e distintas. Un despregamento de traballo pode manter os espazos de nomes internos no resolutor corporativo mentres envía a navegación pública seleccionada fóra do túnel, precisamente porque os nomes internos non se resolven en ningún outro sitio. O caso confuso é o contrario: un sitio público falla porque o navegador nunca preguntou ao resolutor que o despregamento esperaba. Anote a ruta e o resolutor por separado, e a metade das discusións desaparece.

Averigüe que proceso fai a pregunta

Un navegador pode usar o resolutor do sistema, o seu propio servizo de DNS cifrado, ou un resolutor que o sistema operativo asigna por rede. O primeiro segue a política da plataforma, o segundo evita esa política por completo, e o terceiro depende de a que ligazón se encamiña a consulta.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Lea a configuración efectiva antes de probar: que ligazóns levan servidores DNS, que espazos de nomes reclaman, e se unha política por nome substitúe o valor predeterminado. En Linux, o DNS dividido usa dominios de encamiñamento; en Windows, a táboa de políticas de resolución de nomes fai o mesmo para os espazos de nomes. Ningunha das dúas se ve desde unha páxina de proba de fugas.

Decida que resolutor debe ver cada nome

Escriba a asignación prevista antes de cambiar nada: nomes internos ao resolutor corporativo, nomes públicos ao servizo que a política permita, e excepcións cun responsable. Sen esa lista, cada etiqueta da proba de fugas convértese nunha discusión de política que ninguén pode pechar.

Logo revise a configuración propia do navegador, porque o DNS cifrado do navegador aplícase antes de que o sistema operativo reciba a consulta. Un usuario que o activou para saltar un portal cativo substituíu en silencio o resolutor que escolleu o despregamento. Iso é unha decisión de configuración e non unha fuga, e merece unha decisión en lugar dunha lista de bloqueo.

Non reescriba todos os campos DNS para que unha etiqueta de proba se poña verde. A etiqueta describe unha consulta dun proceso nun momento.

Verifique consulta e conexión por separado

Probe as dúas rutas por separado. A proba de conexión mostra a ruta de datos, e a proba do resolutor mostra quen recibiu o nome.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Pregunte tamén ao resolutor de forma explícita, para que un fallo se poida atribuír ao servidor e non á ruta. Despois reinicie o navegador e repita, porque as aplicacións gardan en caché as respostas negativas e un fallo antigo parece persistente.

Tras un cambio aprobado, anote a ruta de datos e o destinatario do resolutor como dúas liñas separadas coa data. Se o comportamento volve na próxima reconexión, o perfil que o proporciona é o que hai que corrixir, non o navegador.