O DNS privado do Pritunl falha? Adicione uma rota estreita para o resolvedor

Os nomes privados resolvem-se para todos na rede corporativa e expiram para todos na VPN. O resolvedor responde ao gateway, a rota até ele existe, e a consulta continua a nunca receber resposta. O que falta não é outro resolvedor público nem uma rota mais ampla: é um endereço de origem ao qual o servidor DNS privado esteja disposto a responder.

Confirme que o resolvedor está a recusar o seu pool de clientes

Comece por provar que a falha tem a ver com a origem, não com a acessibilidade. A partir de um cliente ligado, consulte o resolvedor privado diretamente e observe se o pedido expira ou volta como recusa. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 a expirar enquanto a mesma consulta a partir do gateway tem sucesso aponta para uma política de acesso no resolvedor. Uma resposta SERVFAIL aponta para outro sítio por completo, normalmente a zona ou o reencaminhador a montante.

Anote o endereço do cliente antes do teste. ip -4 addr show tun0 no cliente, ou a concessão mostrada na consola, diz-lhe que pool o resolvedor vê.

Depois confirme que o caminho existe. Uma rota que envia o endereço do resolvedor para o túnel é um pré-requisito, não a solução; se os pacotes nunca chegam, a política de origem nunca é consultada. Verifique-o com ip route get 10.40.0.53 no cliente.

Adicione uma rota de host em vez de traduzir tudo

A orientação de DNS privado da Pritunl descreve o remédio estreito: uma rota /32 com NAT para o endereço do resolvedor, com esse endereço escolhido como servidor DNS dos clientes. A rota altera a origem que o resolvedor vê apenas para o tráfego DNS. O tráfego das aplicações mantém o desenho que preserva a origem que escolheu para ele.

Configure-a através do proprietário de rotas suportado do servidor, após rever as rotas existentes para sobreposição. No exemplo acima o destino é 10.40.0.53/32 com NAT ativo, e o pool de clientes mantém-se 10.90.0.0/24. Não traduza todo o intervalo privado para corrigir um serviço, porque cada política a jusante que depende do endereço real do cliente começará a ver o gateway em vez disso. Confirme o endereço que o resolvedor recebe realmente observando o seu registo de consultas durante uma pesquisa de teste. Uma rota de host sozinha não prova nada sobre tradução ou permissão.

O resolvedor ainda tem de permitir a origem traduzida em UDP e TCP, e as suas respostas têm de poder voltar. Alterar a origem não pode criar uma zona ou registo em falta.

Decida se é o servidor ou o cliente que envia a consulta

A Pritunl também documenta um arranjo de proxy DNS ligado ao VPN Client DNS Mapping, em que o servidor reencaminha consultas a montante pelos clientes. Nesse modelo a origem a montante pertence ao contexto de rede próprio do servidor, e uma exceção do lado do cliente é a solução errada.

Identifique que modelo está ativo antes de acrescentar algo. Três reparações sobrepostas, um proxy, uma substituição do resolvedor no cliente e um script NAT manual normalmente significam que ninguém estabeleceu: que componente deve enviar a consulta. Verifique também o bootstrap: um resolvedor apenas privado não pode ser a única forma de encontrar o ponto final antes de o túnel existir, e uma alteração permanente do resolvedor não deve sobreviver à ligação.

Teste uma pesquisa privada, não uma página web pública

Depois de aplicar a alteração e voltar a ligar, inspecione a configuração efetiva do resolvedor do cliente e, em seguida, resolva um nome que sabe existir apenas na zona privada. dig intranet.example.net sem servidor explícito mostra o que o cliente usa realmente. Faça seguir um pedido ao endereço que essa pesquisa devolveu, porque resolução e acesso ao serviço são passos separados. Um navegador que carrega sítios públicos através de DNS-over-HTTPS não prova nada sobre o caminho do resolvedor privado do sistema operativo. Um resolvedor secundário público também não é autoridade para uma zona interna.

Registe o endereço do resolvedor, a rota /32 e a definição de DNS do cliente em conjunto nas notas do servidor. Metade dessa configuração restaurada sozinha reproduz a falha original.

Por fim, confirme que o túnel continua a encaminhar o destino da aplicação depois de o DNS ter sucesso. Rota, acesso ao serviço e autenticação permanecem independentes da resolução de nomes, e uma pesquisa funcional não diz nada sobre o débito. Se a página privada é lenta mas resolve, o resolvedor fez o seu trabalho e o problema passou para o caminho.