El túnel dividit exclou el navegador, no les seves consultes DNS

El navegador exclòs del túnel, la pàgina d’IP pública confirma que el seu trànsit surt per la connexió de casa, i la wiki interna encara no s’obre. La resolució de noms va anar a un altre lloc, i aquest altre lloc sol ser el resolutor que va configurar la VPN. El camí de dades i el camí del resolutor són decisions separades en la majoria de dissenys de túnel dividit. Comproveu quin va fer servir realment el navegador abans de dir que l’exclusió està trencada.

El camí de dades i el camí del resolutor se separen

Una exclusió treu els paquets d’una aplicació del túnel, cosa que és una decisió d’encaminament i tallafoc al camí de dades. La resolució de noms és una consulta diferent: un procés pregunta al resolutor del sistema, i aquell resolutor decideix quin servidor rep la pregunta.

Tots dos poden ser intencionats i diferents. Un desplegament de treball pot mantenir els espais de noms interns al resolutor corporatiu mentre envia la navegació pública seleccionada fora del túnel, precisament perquè els noms interns no es resolen enlloc més. El cas confús és el contrari: un lloc públic que falla perquè el navegador mai no va preguntar al resolutor que el desplegament esperava. Anoteu la ruta i el resolutor per separat, i la meitat de les discussions desapareix.

Trobeu quin procés fa la pregunta

Un navegador pot usar el resolutor del sistema, el seu propi servei de DNS xifrat, o un resolutor que el sistema operatiu assigna per xarxa. El primer segueix la política de la plataforma, el segon evita aquesta política del tot, i el tercer depèn de a quin enllaç s’encamina la consulta.

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

Llegiu la configuració efectiva abans de provar: quins enllaços porten servidors DNS, quins espais de noms reclamen, i si una política per nom substitueix el valor predeterminat. A Linux, el DNS dividit usa dominis d’encaminament; a Windows, la taula de política de resolució de noms fa la mateixa feina per als espais de noms. Cap de les dues no es veu des d’una pàgina de prova de fuites.

Decidiu quin resolutor ha de veure cada nom

Escriviu el mapatge previst abans de canviar res: noms interns al resolutor corporatiu, noms públics al servei que la política permeti, i excepcions amb un responsable. Sense aquesta llista, cada etiqueta de la prova de fuites es converteix en una discussió de política que ningú no pot tancar.

Després comproveu la configuració pròpia del navegador, perquè el DNS xifrat del navegador s’aplica abans que el sistema operatiu rebi la consulta. Un usuari que el va activar per saltar-se un portal captiu ha substituït en silenci el resolutor que el desplegament va triar. Això és una decisió de configuració i no una fuita, i mereix una decisió i no una llista de bloqueig.

No reescriviu tots els camps DNS per fer que una etiqueta de prova es torni verda. L’etiqueta descriu una consulta d’un procés en un moment.

Verifiqueu consulta i connexió per separat

Proveu els dos camins de manera independent. La prova de connexió mostra la ruta de dades, i la prova del resolutor mostra qui va rebre el nom.

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

Pregunteu també al resolutor explícitament, perquè un fracàs es pugui atribuir al servidor i no al camí. Després reinicieu el navegador i repetiu, perquè les aplicacions emmagatzemen les respostes negatives i un fracàs antic sembla persistent.

Després d’un canvi aprovat, anoteu la ruta de dades i el destinatari del resolutor com dues línies separades amb la data. Si el comportament torna a la propera reconnexió, el perfil que el proporciona és el que cal arreglar, no el navegador.