Cerqueu la zona corporativa a la configuració dnsmasq del client, no la trobeu i concloeu que la VPN no va empènyer el seu domini. El que es va empènyer és una pista d'encaminament, no una zona. El client registra el domini i el resolutor que hi ha de respondre, i el backend gestionat ho converteix en reenviament condicional. Mirar al lloc equivocat produeix un diagnòstic confiat i completament fals.

El que el client va acceptar no és el que la passarel·la va oferir

Una passarel·la pot oferir un resolutor, un domini i la ruta necessària per arribar a aquest resolutor, i el client pot acceptar els tres o cap d'ells. Un perfil importat, un script auxiliar o una política que ignora les opcions emeses poden deixar el conjunt acceptat buit mentre el costat del servidor sembla correcte. Comenceu per l'estat registrat del client i no per la configuració del servidor, perquè aquest estat és el que el resolutor rep realment. Si falta el domini acceptat, res més avall no tindrà importància. Comproveu les propietats DNS de la connexió abans d'inspeccionar cap memòria cau.

Aquesta distinció explica la majoria d'informes d'un domini que mai no va arribar. Es va oferir, i no es va aplicar.

Dos tipus d'entrada de domini

Una connexió pot portar dominis de cerca ordinaris i dominis només d'encaminament, i el segon tipus comença amb una titlla. Un domini de cerca encamina les consultes i permet expandir noms curts, cosa que és convenient en una estació de treball i sorprenent en un servidor. Un domini només d'encaminament indica que les consultes per a aquest sufix han d'anar a servidors concrets sense canviar com es resolen els noms curts. Escriure el mateix domini de les dues maneres no és redundància, perquè les dues entrades fan feines diferents.

Per a un espai de noms privat, la forma només d'encaminament sol ser la que voleu. Manté el sufix corporatiu apuntant al resolutor corporatiu i deixa la resta tranquil·la.

localhost a resolv.conf no és un error

Quan s'utilitza un resolutor local de memòria cau, el fitxer del sistema apunta a l'adreça de loopback i a res més. Aquesta entrada identifica l'oient local, no els servidors upstream que el gestor li va lliurar. L'adreça corporativa estarà legítimament absent del fitxer.

Substituir aquesta entrada per un resolutor públic és la correcció errònia clàssica. Restaura la resolució pública de noms i descarta la política condicional en la mateixa edició.

No confongueu els backends

Una instància gestionada de dnsmasq i un resolutor del sistema són programes diferents amb configuració diferent i vistes d'estat diferents. Una ordre d'estat per a un no diu res útil sobre l'altre.

Determineu quin backend té configurat el gestor i, després, llegiu la configuració generada d'aquest backend en lloc d'un fitxer de tota la distribució que casualment existeixi. El gestor escriu la seva pròpia configuració d'instància i admet opcions personalitzades per a aquesta instància, de manera que editar un fitxer global no relacionat no canvia res i sembla un canvi sense efecte. Iniciar un segon dimoni al port 53 és pitjor que inútil, perquè ara dos programes no es posen d'acord sobre qui és el propietari del port. Establiu primer el propietari i després editeu on aquest propietari llegeix.

Proveu l'espai de noms, no només la resposta

Consulteu un nom privat permès i un nom de control públic pel camí normal de l'aplicació. Una consulta directa al servidor corporatiu demostra que el registre existeix; no demostra que el client hagi triat aquest servidor. La segona consulta és la que prova la política.

Després repetiu-ho després d'una reconnexió i després d'una desconnexió. L'associació ha de seguir el cicle de vida de la connexió, i els noms privats han de deixar de resoldre's quan el túnel desapareix, en lloc de recaure en un resolutor públic que respon al mateix sufix. Si hi recauen, heu trobat una fuita, que és un defecte diferent d'una cerca trencada. Anoteu quin backend s'executava, quins dominis es van aplicar i què va retornar cada consulta.

Articles relacionats