O teu dominio VPN en dnsmasq non é unha transferencia de zona

Buscas a zona corporativa na configuración de dnsmasq do cliente, non a atopas e conclúes que a VPN non enviou o seu dominio. O que se enviou é unha pista de encamiñamento, non unha zona. O cliente rexistra o dominio e o resolutor que debe responder por el, e o backend xestionado convérteo en reenvío condicional. Mirar no lugar equivocado produce un diagnóstico seguro e completamente falso.

O que o cliente aceptou non é o que a pasarela ofreceu

Unha pasarela pode ofrecer un resolutor, un dominio e a ruta necesaria para chegar a ese resolutor, e o cliente pode aceptar os tres ou ningún deles. Un perfil importado, un script auxiliar ou unha política que ignora as opcións enviadas poden deixar o conxunto aceptado baleiro mentres o lado do servidor parece correcto. Comeza polo estado rexistrado do cliente e non pola configuración do servidor, porque ese estado é o que o resolutor recibe realmente. Se falta o dominio aceptado, nada máis adiante terá importancia. Comproba as propiedades DNS da conexión antes de inspeccionar calquera caché.

Esa distinción explica a maioría dos informes dun dominio que nunca chegou. Ofreceuse, e non se aplicou.

Dous tipos de entrada de dominio

Unha conexión pode levar dominios de busca ordinarios e dominios só de encamiñamento, e o segundo tipo comeza cun til. Un dominio de busca encamiña as consultas e permite expandir nomes curtos, o que é cómodo nunha estación de traballo e sorprendente nun servidor. Un dominio só de encamiñamento indica que as consultas para ese sufixo deben ir a servidores concretos sen cambiar como se resolven os nomes curtos. Escribir o mesmo dominio das dúas maneiras non é redundancia, porque as dúas entradas fan traballos distintos.

Para un espazo de nomes privado, a forma só de encamiñamento adoita ser a que queres. Mantén o sufixo corporativo apuntando ao resolutor corporativo e deixa todo o demais en paz.

localhost en resolv.conf non é un erro

Cando se usa un resolutor local de caché, o ficheiro do sistema apunta ao enderezo de loopback e a nada máis. Ese rexistro identifica o oínte local, non os servidores ascendentes que o xestor lle entregou. O enderezo corporativo estará lexitimamente ausente do ficheiro.

Substituír ese rexistro por un resolutor público é a corrección errónea clásica. Restaura a resolución pública de nomes e descarta a política condicional na mesma edición.

Non confundas os backends

Unha instancia xestionada de dnsmasq e un resolutor do sistema son programas distintos con configuración distinta e vistas de estado distintas. Unha orde de estado para un non di nada útil sobre o outro.

Determina que backend ten configurado o xestor e despois le a configuración xerada dese backend en lugar dun ficheiro de toda a distribución que casualmente exista. O xestor escribe a súa propia configuración de instancia e admite opcións personalizadas para esa instancia, así que editar un ficheiro global non relacionado non cambia nada e parece un cambio sen efecto. Iniciar un segundo daemon no porto 53 é peor que inútil, porque agora dous programas non se poñen de acordo sobre quen é o dono do porto. Establece primeiro o propietario e despois edita onde ese propietario le.

Proba o espazo de nomes, non só a resposta

Consulta un nome privado permitido e un nome de control público polo camiño normal da aplicación. Unha consulta directa ao servidor corporativo demostra que o rexistro existe; non demostra que o cliente escollese ese servidor. A segunda consulta é a que proba a política.

Despois repíteo tras unha reconexión e tras unha desconexión. A asociación debe seguir o ciclo de vida da conexión, e os nomes privados deben deixar de resolverse cando o túnel desaparece, en lugar de recaer nun resolutor público que responde ao mesmo sufixo. Se recaen, atopaches unha fuga, que é un defecto distinto dunha busca rota. Anota que backend se executaba, que dominios se aplicaron e que devolveu cada consulta.