¿Falla el DNS privado de Pritunl? Añada una ruta estrecha para el resolutor

Los nombres privados se resuelven para todos en la red corporativa y caducan para todos en la VPN. El resolutor responde a la puerta de enlace, la ruta hasta él existe, y la consulta sigue sin recibir nunca respuesta. Lo que falta no es otro resolutor público ni una ruta más amplia: es una dirección de origen a la que el servidor de DNS privado esté dispuesto a responder.

Confirme que el resolutor rechaza su grupo de clientes

Empiece demostrando que el fallo tiene que ver con el origen, no con la accesibilidad. Desde un cliente conectado, consulte el resolutor privado directamente y observe si la petición caduca o vuelve como un rechazo. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 caducando mientras la misma consulta desde la puerta de enlace tiene éxito apunta a una política de acceso en el resolutor. Una respuesta SERVFAIL apunta a otro sitio por completo, normalmente a la zona o al reenviador superior.

Anote la dirección del cliente antes de probar. ip -4 addr show tun0 en el cliente, o la concesión que muestra la consola, le dice qué grupo ve el resolutor.

Después confirme que la ruta existe. Una ruta que envía la dirección del resolutor al túnel es un requisito previo, no la solución; si los paquetes nunca llegan, la política de origen nunca se consulta. Compruébelo con ip route get 10.40.0.53 en el cliente.

Añada una ruta de host en lugar de traducirlo todo

La guía de DNS privado de Pritunl describe el remedio estrecho: una ruta /32 con NAT para la dirección del resolutor, con esa dirección seleccionada como servidor DNS de los clientes. La ruta cambia el origen que ve el resolutor solo para el tráfico DNS. El tráfico de aplicaciones conserva el diseño que preserva el origen que eligió para él.

Configúrela a través del propietario de rutas admitido del servidor, tras revisar las rutas existentes por si hay solapamiento. En el ejemplo anterior el destino es 10.40.0.53/32 con NAT habilitado, y el grupo de clientes sigue siendo 10.90.0.0/24. No traduzca todo el rango privado para arreglar un servicio, porque cada política posterior que dependa de la dirección real del cliente empezará a ver la puerta de enlace en su lugar. Confirme la dirección que el resolutor recibe realmente observando su registro de consultas durante una búsqueda de prueba. Una ruta de host por sí sola no demuestra nada sobre la traducción ni el permiso.

El resolutor todavía tiene que permitir el origen traducido en UDP y TCP, y sus respuestas deben poder volver. Cambiar el origen no puede crear una zona ni un registro que falte.

Decida si el servidor o el cliente envía la consulta

Pritunl también documenta un arreglo de proxy DNS vinculado a VPN Client DNS Mapping, donde el servidor reenvía consultas superiores por los clientes. En ese modelo el origen superior pertenece al contexto de red propio del servidor, y una excepción en el lado del cliente es la solución equivocada.

Identifique qué modelo está activo antes de añadir nada. Tres reparaciones superpuestas, un proxy, una sustitución del resolutor en el cliente y un script de NAT manual normalmente significan que nadie ha establecido: qué componente debe enviar la consulta. Compruebe también el arranque: un resolutor solo privado no puede ser la única forma de encontrar el punto final antes de que exista el túnel, y una modificación permanente del resolutor no debería sobrevivir a la conexión.

Pruebe una búsqueda privada, no una página web pública

Después de aplicar el cambio y volver a conectarse, inspeccione la configuración efectiva del resolutor del cliente y luego resuelva un nombre que sepa que solo existe en la zona privada. dig intranet.example.net sin servidor explícito muestra qué usa realmente el cliente. Sígalo con una petición a la dirección que devolvió esa búsqueda, porque la resolución y el acceso al servicio son pasos separados. Un navegador que carga sitios públicos mediante DNS-over-HTTPS no demuestra nada sobre la ruta del resolutor privado del sistema operativo. Un resolutor secundario público tampoco es una autoridad para una zona interna.

Anote la dirección del resolutor, la ruta /32 y la configuración de DNS del cliente juntas en las notas del servidor. La mitad de esa configuración restaurada sola reproduce el fallo original.

Por último, confirme que el túnel sigue enrutando el destino de la aplicación después de que el DNS tenga éxito. La ruta, el acceso al servicio y la autenticación siguen siendo independientes de la resolución de nombres, y una búsqueda que funciona no dice nada sobre el rendimiento. Si la página privada es lenta pero se resuelve, el resolutor hizo su trabajo y el problema se trasladó a la ruta.