Per què nslookup resol per la VPN però el navegador no

nslookup envia una consulta al servidor que indiqueu i imprimeix la resposta, per això pot tenir èxit mentre totes les pestanyes del navegador fallen. El navegador demana al sistema operatiu que resolgui, i el sistema pesa els resolutors de cada interfície, les regles de política de resolució de noms i la ubicació de xarxa de l'adaptador. Després el navegador pot afegir-hi el seu propi DNS xifrat. Tres camins diferents, un símptoma, i el túnel normalment no és la part espatllada.

Les comprovacions següents segueixen aquests camins des del sistema cap enfora. No editeu el perfil de la VPN fins que no sapigueu quin camí ha respost i quin ha fallat.

Tres polítiques decideixen la resposta

Cada interfície porta la seva pròpia llista de resolutors i els seus sufixos de cerca. Un adaptador de VPN afegeix servidors mentre l'adaptador físic conserva els seus, i el sistema pot prendre el que respongui primer, així que una consulta pot ser atesa fora del túnel sense que ningú ho hagi triat. Les regles de la taula de política de resolució de noms poden enviar dominis seleccionats a servidors seleccionats, que és com normalment s'expressa el DNS dividit a Windows. I el client o la passarel·la de la VPN poden empènyer una adreça de resolutor que només existeix dins de la xarxa privada.

Aquests tres interactuen de maneres que des del navegador semblen arbitràries. Un resolutor empès a una adreça privada sense ruta pel túnel dividit fa que cada consulta s'encalli i després falli. Una regla de política que cobreix el sufix intern i apunta a un servidor aturat produeix el mateix error visible que una ruta absent. Un sufix de cerca que falta a l'adaptador de la VPN converteix un nom curt en una consulta pública pel domini equivocat. Cadascun necessita una reparació diferent.

Per què el navegador fa una pregunta diferent

nslookup emet la seva pròpia consulta al servidor que tria i no segueix ni la política d'espai de noms ni el paràmetre de DNS xifrat del navegador. Per això una consulta manual contra un resolutor públic respon mentre el navegador informa que el lloc no existeix. Compareu dos programes, no dos estats d'un mateix programa.

La preferència de família d'adreces explica un retard, no un error. Un navegador que demana primer registres IPv6 en un túnel que només porta IPv4 espera que passi el temps d'espera abans de recular. Firefox ha portat una preferència precisament per això, i desactivar-la és un pas de diagnòstic, no una reparació.

Llegiu la llista de resolutors i les regles

A Windows, aboqueu el que el sistema té abans de teoritzar. Get-DnsClientServerAddress mostra els servidors per interfície, Get-DnsClientNrptRule llista les regles d'espai de noms, i Resolve-DnsName respon el nom exacte pel camí del sistema. Compareu aquesta resposta amb una consulta directa al servidor de la VPN per adreça. Quan Resolve-DnsName falla i la consulta directa té èxit, el sospitós és la llista de resolutors o una regla d'espai de noms.

Comproveu també el nom en si. Un nom curt intern pot necessitar el sufix privat que només proporciona l'adaptador de la VPN, mentre que el nom completament qualificat es resol bé. Un avís de certificat després d'una consulta correcta pertany a un altre problema.

El resolutor empès inabastable

La passarel·la o el client poden empènyer una adreça de resolutor, i aquesta adreça ha de ser abastable pel túnel. En un túnel dividit, el rang privat que conté el resolutor pot no ser a les rutes incloses, cosa que produeix una consulta que no rep mai resposta. Confirmeu que la ruta existeix, i després consulteu aquella adreça específicament, pel túnel. Aquesta és la fallada darrere d'un error de domini al navegador mentre un resolutor públic encara respon.

Si el resolutor és inabastable, la reparació és una ruta o una subxarxa inclosa, no un altre servidor DNS.

El DNS xifrat evita tot el camí

Els navegadors amb DNS-over-HTTPS resolen els noms ells mateixos per una connexió HTTPS a un proveïdor triat. Amb això activat, el resolutor del sistema i les regles de DNS dividit s'eviten del tot per a aquestes consultes, així que els noms interns fallen al navegador mentre el sistema operatiu els resol correctament. També passa el contrari: noms interns tenen èxit al navegador a través d'un proveïdor que no els hauria de veure mai, i això és un problema de política, no de connectivitat.

Decidiu deliberadament si el DNS xifrat es permet als dispositius gestionats, i després configureu-lo per la superfície de gestió del navegador perquè l'elecció sigui visible. Deixar-ho a la preferència individual produeix un parc on la mateixa VPN es comporta diferent a cada portàtil.

Reparacions que encaixen amb la fallada

Si la VPN empeny el seu resolutor, feu que el túnel hi porti trànsit i que el mateix paràmetre sigui visible als adaptadors que participen en la resolució. Si els llocs locals deixen de resoldre's mentre esteu connectats, afegiu excepcions explícites d'espai de noms o un reenviador condicional en lloc de substituir el resolutor sencer. Si el DNS xifrat del navegador evita la política, aquest és el paràmetre que cal canviar. No afegiu mai un resolutor públic per arreglar un nom intern: filtra consultes privades i no resol el nom.

Després separeu la consulta de la connexió. Un nom que es resol a l'adreça correcta però refusa una connexió és un problema de servei, tallafoc o certificat, i els canvis de DNS no l'arreglaran.

Enregistreu quin camí ha respost, quin ha fallat i què heu canviat. El proper informe del mateix símptoma costarà llavors una ordre en lloc d'una tarda.