O seu domínio VPN no dnsmasq não é uma transferência de zona

Procura a zona corporativa na configuração do dnsmasq do cliente, não a encontra e conclui que a VPN não enviou o seu domínio. O que foi enviado é uma pista de encaminhamento, não uma zona. O cliente registra o domínio e o resolver que deve responder por ele, e o backend gerido transforma isso em reencaminhamento condicional. Procurar no lugar errado produz um diagnóstico confiante e totalmente falso.

O que o cliente aceitou não é o que o gateway ofereceu

Um gateway pode oferecer um resolver, um domínio e a rota necessária para alcançar esse resolver, e o cliente pode aceitar os três ou nenhum deles. Um perfil importado, um script auxiliar ou uma política que ignora as opções enviadas podem deixar o conjunto aceito vazio enquanto o lado do servidor parece correto. Comece pelo estado registado do cliente e não pela configuração do servidor, porque esse estado é o que o resolver recebe de facto. Se faltar o domínio aceito, nada mais adiante terá importância. Verifique as propriedades DNS da ligação antes de inspecionar qualquer cache.

Essa distinção explica a maioria dos relatos de um domínio que nunca chegou. Foi oferecido, e não foi aplicado.

Dois tipos de entrada de domínio

Uma ligação pode transportar domínios de pesquisa comuns e domínios apenas de encaminhamento, e o segundo tipo começa com um til. Um domínio de pesquisa encaminha as consultas e permite expandir nomes curtos, o que é cómodo numa estação de trabalho e surpreendente num servidor. Um domínio apenas de encaminhamento indica que as consultas para esse sufixo devem ir para servidores específicos sem alterar a forma como os nomes curtos são resolvidos. Escrever o mesmo domínio das duas maneiras não é redundância, porque as duas entradas fazem trabalhos diferentes.

Para um espaço de nomes privado, a forma apenas de encaminhamento é normalmente a que quer. Mantém o sufixo corporativo apontado para o resolver corporativo e deixa todo o resto em paz.

localhost no resolv.conf não é um erro

Quando é usado um resolver local de cache, o ficheiro do sistema aponta para o endereço de loopback e para nada mais. Essa entrada identifica o ouvinte local, não os servidores upstream que o gestor lhe entregou. O endereço corporativo estará legitimamente ausente do ficheiro.

Substituir essa entrada por um resolver público é a correção errada clássica. Restaura a resolução pública de nomes e descarta a política condicional na mesma edição.

Não confunda os backends

Uma instância gerida de dnsmasq e um resolver do sistema são programas diferentes com configuração diferente e vistas de estado diferentes. Um comando de estado para um não diz nada de útil sobre o outro.

Determine qual backend o gestor está configurado para usar e depois leia a configuração gerada desse backend em vez de um ficheiro de toda a distribuição que por acaso exista. O gestor escreve a sua própria configuração de instância e suporta opções personalizadas para essa instância, pelo que editar um ficheiro global não relacionado não muda nada e parece uma alteração sem efeito. Iniciar um segundo daemon na porta 53 é pior do que inútil, porque agora dois programas discordam sobre quem é o dono da porta. Estabeleça primeiro o proprietário e só depois edite onde esse proprietário lê.

Teste o espaço de nomes, não apenas a resposta

Consulte um nome privado permitido e um nome de controlo público pelo caminho normal da aplicação. Uma consulta direta ao servidor corporativo prova que o registo existe; não prova que o cliente escolheu esse servidor. A segunda consulta é a que testa a política.

Depois repita após uma reconexão e após uma desconexão. A associação deve seguir o ciclo de vida da ligação, e os nomes privados devem deixar de resolver quando o túnel desaparece, em vez de recaírem num resolver público que responde ao mesmo sufixo. Se recaírem, encontrou uma fuga, que é um defeito diferente de uma pesquisa quebrada. Anote qual backend estava a correr, que domínios foram aplicados e o que cada consulta devolveu.