O DNS privado de Pritunl falla? Engada unha ruta estreita para o resolutor

Os nomes privados resólvense para todos na rede corporativa e caducan para todos na VPN. O resolutor responde á pasarela, a ruta ata el existe, e a consulta segue sen recibir nunca resposta. O que falta non é outro resolutor público nin unha ruta máis ampla: é un enderezo de orixe ao que o servidor DNS privado estea disposto a responder.

Confirme que o resolutor rexeita o seu grupo de clientes

Comece demostrando que o fallo ten que ver coa orixe, non coa accesibilidade. Desde un cliente conectado, consulte o resolutor privado directamente e observe se a petición caduca ou volve como un rexeitamento. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 caducando mentres a mesma consulta desde a pasarela ten éxito apunta a unha política de acceso no resolutor. Unha resposta SERVFAIL apunta a outro sitio por completo, normalmente á zona ou ao reenviador superior.

Anote o enderezo do cliente antes de probar. ip -4 addr show tun0 no cliente, ou a concesión que mostra a consola, dille que grupo ve o resolutor.

Despois confirme que a ruta existe. Unha ruta que envía o enderezo do resolutor ao túnel é un requisito previo, non a solución; se os paquetes nunca chegan, a política de orixe nunca se consulta. Compruébeo con ip route get 10.40.0.53 no cliente.

Engada unha ruta de host en lugar de traducilo todo

A guía de DNS privado de Pritunl describe o remedio estreito: unha ruta /32 con NAT para o enderezo do resolutor, con ese enderezo seleccionado como servidor DNS dos clientes. A ruta cambia a orixe que ve o resolutor só para o tráfico DNS. O tráfico de aplicacións conserva o deseño que preserva a orixe que elixiu para el.

Configúrea a través do propietario de rutas admitido do servidor, tras revisar as rutas existentes por se hai solapamento. No exemplo anterior o destino é 10.40.0.53/32 con NAT activado, e o grupo de clientes segue sendo 10.90.0.0/24. Non traduza todo o rango privado para arranxar un servizo, porque cada política posterior que dependa do enderezo real do cliente comezará a ver a pasarela no seu lugar. Confirme o enderezo que o resolutor recibe realmente observando o seu rexistro de consultas durante unha busca de proba. Unha ruta de host por si soa non demostra nada sobre a tradución nin o permiso.

O resolutor aínda ten que permitir a orixe traducida en UDP e TCP, e as súas respostas deben poder volver. Cambiar a orixe non pode crear unha zona nin un rexistro que falte.

Decida se o servidor ou o cliente envía a consulta

Pritunl tamén documenta un arranxo de proxy DNS vinculado a VPN Client DNS Mapping, onde o servidor reenvía consultas superiores polos clientes. Nese modelo a orixe superior pertence ao contexto de rede propio do servidor, e unha excepción no lado do cliente é a solución equivocada.

Identifique que modelo está activo antes de engadir nada. Tres reparacións superpostas, un proxy, unha substitución do resolutor no cliente e un script de NAT manual normalmente significan que ninguén estableceu: que compoñente debe enviar a consulta. Comprobe tamén o arranque: un resolutor só privado non pode ser a única forma de atopar o punto final antes de que exista o túnel, e unha modificación permanente do resolutor non debería sobrevivir á conexión.

Probe unha busca privada, non unha páxina web pública

Despois de aplicar o cambio e volver conectarse, inspeccione a configuración efectiva do resolutor do cliente e logo resolva un nome que saiba que só existe na zona privada. dig intranet.example.net sen servidor explícito mostra que usa realmente o cliente. Sígao cunha petición ao enderezo que devolveu esa busca, porque a resolución e o acceso ao servizo son pasos separados. Un navegador que carga sitios públicos mediante DNS-over-HTTPS non demostra nada sobre a ruta do resolutor privado do sistema operativo. Un resolutor secundario público tampouco é unha autoridade para unha zona interna.

Anote o enderezo do resolutor, a ruta /32 e a configuración de DNS do cliente xuntas nas notas do servidor. A metade desa configuración restaurada soa reproduce o fallo orixinal.

Por último, confirme que o túnel segue encamiñando o destino da aplicación despois de que o DNS teña éxito. A ruta, o acceso ao servizo e a autenticación seguen sendo independentes da resolución de nomes, e unha busca que funciona non di nada sobre o rendemento. Se a páxina privada é lenta pero se resolve, o resolutor fixo o seu traballo e o problema trasladouse á ruta.