Els noms interns fallen a la VPN mentre els llocs públics es resolen

Un usuari informa que el nom d'amfitrió de la intranet no es resol per la VPN. Un segon informe, del mateix portàtil, diu que una prova de fuites encara mostra consultes contestades pel resolutor local. Semblen un sol problema i són dos, amb proves diferents, i la reparació habitual del primer empitjora el segon. Separeu-los abans de tocar cap paràmetre.

Dos símptomes que no són una sola fallada

No poder resoldre un nom intern vol dir que la pregunta ha anat a un lloc que no en té la resposta. Que les consultes surtin del túnel vol dir que la pregunta ha anat al lloc equivocat fins i tot quan la resposta era disponible. Són fallades oposades: una és una resposta que falta, l'altra és una destinació de més.

El parany és que afegir el resolutor de l'oficina a tot arreu arregla la primera i garanteix la segona. Afegir un resolutor públic a tot arreu fa el contrari.

Anoteu les dues observacions amb marca de temps i després passeu les quatre comprovacions de sota en ordre.

Quin resolutor de l'adaptador rep la pregunta

A Windows el client DNS tria servidors segons l'ordre d'enllaç dels adaptadors, i l'adaptador del túnel no és automàticament el primer. Obriu la configuració avançada de l'adaptador i moveu la connexió d'accés remot per sobre de l'adaptador físic, i torneu a connectar perquè el canvi valgui en una sessió nova.

L'ordre d'enllaç només és la primera meitat. El client també ha de saber quins noms pertanyen a aquell adaptador, i això és una qüestió de sufix, no d'ordre.

Poseu la sortida de ipconfig /all de la màquina que funciona al costat de la del portàtil, totes dues preses amb el túnel aixecat. La màquina que funciona mostrarà un sufix DNS específic de la connexió al seu adaptador d'oficina, i el portàtil potser no en mostrarà cap al túnel. Aquesta diferència explica tota una classe d'informes del tipus el servidor és just aquí i el nom encara falla, perquè sense sufix el nom curt no s'acaba mai dins de la zona que serveix el resolutor de l'oficina.

Un nom curt necessita un sufix abans que una ruta

Escriure un nom d'amfitrió no qualificat demana al resolutor que endevini un domini. L'endevinalla ve de la llista de sufixos enllaçada a la connexió, i si aquesta llista és buida la consulta surt com una sola etiqueta que cap zona privada no encaixarà.

Copieu el sufix de la màquina que funciona a les propietats IPv4 de l'adaptador de la VPN, a la pestanya DNS, i torneu a connectar. A Linux l'equivalent és el domini de cerca de l'enllaç del túnel, que systemd-resolved exposa per enllaç i no globalment.

Manteniu els dos paràmetres separats a les notes. El sufix canvia què es pregunta; l'adreça del resolutor canvia a qui es pregunta. Arreglar un mentre l'altre és dolent produeix un resultat que sembla aleatori.

Pregunteu al resolutor directament, després al nom

Una consulta directa al resolutor de l'oficina separa un problema de nom d'un problema de camí, perquè salta del tot la tria de resolutor del client.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

La primera ordre demana un nom totalment qualificat a un servidor concret. Si respon, el resolutor i la ruta cap a ell estan bé i la fallada és a la tria o al sufix. Si esgota el temps, l'adreça és incorrecta o inabastable i el problema és d'encaminament, no de DNS. La segona ordre mostra què passa amb el nom curt, i la tercera imprimeix la configuració de resolutor per enllaç en un amfitrió amb systemd.

Vigileu les respostes comodí que algunes xarxes retornen per a noms desconeguts. Una resposta versemblant no prova que hagi contestat el servidor volgut, així que compareu l'adreça retornada amb la que el servei intern fa servir de debò. Si l'adreça pertany a una pàgina d'aparcament o a un proxy, el resolutor ha contestat però la resposta no era mai vostra. Aquesta distinció estalvia una hora perseguint un túnel que funcionava tot el temps.

A Linux, un client de VPN que reescriu /etc/resolv.conf substitueix del tot els resolutors locals. vpnc exposa DNSUpdate no per aturar-ho, i systemd-resolved pot encaminar només els dominis llistats a l'enllaç del túnel. Tots dos enfocaments mantenen els noms públics al resolutor local i envien els noms interns a l'oficina.

Les fuites són una regla, no una casella

La resolució de noms és un intercanvi UDP al port 53, així que un túnel que porta tràfic web però no UDP deixa la consulta al camí físic. Demostreu-ho capturant a la targeta de xarxa física mentre es resol un nom públic. Una consulta visible en aquesta interfície en forma llegible vol dir que el túnel no la porta.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Si la consulta apareix en aquesta interfície en forma llegible, el túnel no la porta. La reparació és una regla que permet el port 53 només al resolutor que ha empès la VPN i descarta altres destinacions, més una configuració de client que no descarti en silenci l'opció empesa.

Aquesta darrera part importa més del que sembla. Engegueu OpenVPN amb route-nopull i l'opció DNS empesa desapareix juntament amb les rutes, tret que el filtre d'estirada s'ampliï per retenir-la. I un client que ignori dhcp-option DNS continuarà fent servir el que tenia abans. Qualsevol canvi al costat del servidor necessita una sessió nova per valer, perquè la llista de resolutors es lliura quan el túnel puja i una sessió vella continua mostrant l'estat antic.

Anoteu quina fallada heu observat realment abans de tancar el tiquet. Una resposta interna que falta i una consulta que s'escapa del túnel demanen reparacions diferents, i un canvi de sufix que arregla la primera pot empitjorar en silenci la segona. Qui agafi el tiquet després es refiarà de l'etiqueta, així que feu l'etiqueta exacta.