DNS de OpenVPN en la puerta de enlace: dnsmasq y alcance del cortafuegos

Los clientes del túnel pueden llegar a la puerta de enlace, y la puerta de enlace puede llegar al resolutor interno, así que DNS debería funcionar. No funciona, porque son dos permisos distintos y un servicio DNS operativo es una tercera cosa. El oyente debe existir en una dirección a la que lleguen los clientes, el cortafuegos debe permitir consultas a esa dirección y hay que decirle al cliente que lo use. Abrir el túnel en ambos sentidos resuelve los dos primeros por casualidad y deja el tercero sin hacer.

El oyente es un servicio local con dos direcciones

De entrada, un cliente envía una consulta a la dirección del túnel de la puerta de enlace en el puerto 53. De salida, el demonio reenvía esa consulta a su servidor ascendente configurado. Ambas mitades deben funcionar, y fallan de maneras distintas.

Un tiempo de espera informado por el cliente y un tiempo de espera visto en la puerta de enlace no son la misma avería.

Vincule la dirección del túnel, no todas las direcciones

Una instancia dedicada de dnsmasq para esta tarea necesita una dirección de escucha explícita, un modo de vinculación que tolere la aparición del túnel después del arranque y un ascendente claro. Esta es la versión más pequeña que uso:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic vincula las direcciones individuales y soporta que tun0 aparezca más tarde, lo que importa en un equipo donde el servicio VPN se reinicia. Listar loopback mantiene las herramientas locales funcionando sin añadir un oyente público. no-resolv evita que el demonio herede ascendentes de la configuración del resolutor del equipo, y no-hosts evita que esta instancia publique el archivo hosts de la puerta de enlace. Ninguna de esas opciones da permiso a nadie para consultar el servicio.

Compruebe si hay un oyente existente en el puerto 53 antes de iniciar un segundo demonio, y use el propietario de configuración de la distribución en lugar de un archivo suelto en el directorio equivocado.

Permita la entrada de DNS, no el tránsito del túnel

Las reglas de cortafuegos que hacen que esto funcione son reglas de entrada local limitadas a la interfaz del túnel, el grupo de clientes, la dirección de la puerta de enlace y el puerto 53. Dos reglas, una por protocolo, bastan:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS funciona sobre TCP igual que sobre UDP, así que una regla solo para UDP deja las respuestas grandes fallando de una forma que parece intermitente. Estas no son ufw route permisos, y no deben convertirse en un permiso amplio en tun0. El orden importa tanto como el contenido: una regla anterior que descarte toda la entrada de tun0 sigue ganando, y añadir un permiso por debajo de un descarte terminal no crea nada.

Si el DNS de la puerta de enlace ahora forma parte del diseño, revise esa política anterior a propósito y anote por qué.

La mitad ascendente es una ruta aparte

Las consultas salen de la puerta de enlace desde su propia dirección hacia el resolutor ascendente, así que la ruta de la puerta de enlace y la política de salida hacia ese resolutor deben permitir el intercambio. Es una regla distinta de la que deja a los clientes llegar al oyente, y falla con un síntoma distinto.

No añada salida de túnel sin restricciones para que funcionen las respuestas; las respuestas rastreadas no lo necesitan.

Propague la opción y luego compruebe la entrega

El servidor puede anunciar el resolutor a los clientes con una opción propagada. Eso es una opción, no una instrucción que el sistema operativo deba obedecer:

push "dhcp-option DNS 10.90.0.1"

Un cliente de Linux en línea de comandos puede necesitar la integración del resolutor de su gestor de conexiones, y un dispositivo gestionado puede necesitar su perfil de gestión actualizado. Confirme el resolutor activo en el cliente tras conectar en lugar de suponer que la propagación se aplicó. Cuando dos mecanismos intentan establecer DNS a la vez, se produce una carrera que se presenta como resolución intermitente.

La meta es un solo propietario de la configuración del resolutor del cliente, y la propagación suele ser ese propietario solo cuando la plataforma del cliente está de acuerdo.

Pruebe lo que realmente construyó

Consulte un nombre privado totalmente cualificado y un nombre externo permitido directamente contra la dirección del túnel, por UDP y TCP. Luego repita por la ruta de búsqueda habitual de la aplicación.

Si las consultas directas funcionan y la aplicación sigue fallando, la avería está en la entrega y no en el servidor:

• El cliente nunca aplicó la opción propagada.
• Otro resolutor se estableció después y ganó la carrera.
• La aplicación usa su propia biblioteca de resolutores o una respuesta en caché.

Termine confirmando que una fuente fuera de la ruta VPN aprobada no puede usar el oyente en absoluto. Una resolución correcta no autoriza la dirección que devolvió, así que mantenga esas dos preguntas separadas.