UFW descarta el servidor DNS de la VPN en cuanto el túnel está activo
La política de denegación por defecto de UFW también cubre la interfaz del túnel. Ordena el tráfico por dirección, admite el resolutor empujado en tun0 y después abre el camino exterior.
Los nombres dejan de resolverse en el momento en que la VPN se conecta, mientras que un ping a una dirección pública sigue respondiendo y el estado del cortafuegos no muestra nada que parezca incorrecto. No ha cambiado nada en la política; lo que ha cambiado es que ha aparecido una interfaz nueva, y la denegación por defecto la cubre desde el primer paquete. UFW decide por dirección e interfaz, así que una regla escrita para el enlace inalámbrico no dice nada sobre el tráfico que sale del túnel. La reparación es un puñado de reglas estrechas aplicadas en un orden concreto.
El síntoma solo aparece cuando el túnel está activo
Una política de denegación por defecto hace exactamente lo que se le dijo: todo lo que no tiene una regla coincidente se rechaza, en cada interfaz que existe. El túnel no existía cuando se escribieron las reglas, así que ninguna de ellas puede cubrirlo, y la denegación que siempre estuvo ahí ahora se aplica a la resolución de nombres. El tráfico directo a una dirección literal todavía puede funcionar cuando lo cubre un permiso más amplio, y por eso un ping a un resolutor público tiene éxito mientras que la consulta de un nombre falla. El hueco es una regla para una interfaz que la política nunca ha visto.
Eso también explica por qué el fallo se invierte limpiamente: quita el túnel y los nombres vuelven a resolverse, porque la consulta vuelve a una interfaz que sí tiene reglas. Una política que solo falla mientras el túnel está activo no es un problema de DNS, y ajustar el propio resolutor es lo que más tiempo hace perder aquí. Lee la lista de interfaces antes de leer la configuración del resolutor.
Tres direcciones, tres conjuntos de reglas distintos
Una sola sesión toca reglas en más de una dirección, y un túnel añade una segunda interfaz a casi todas ellas. Ordenar el tráfico primero por dirección e interfaz hace mecánico el resto, porque cada fila de abajo necesita su propia regla en su propio sitio. Los ejemplos usan tun0 y un grupo de 10.8.0.0/24, así que sustituye los nombres y los rangos por los de la propia salida del cliente.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Dos filas se confunden a menudo porque ambas mencionan el túnel. Una regla para el resolutor admite el tráfico que el cliente envía al túnel, mientras que una regla para SSH admite el tráfico que el servidor recibe de él; viven en máquinas distintas y fallan de forma independiente. La fila que más a menudo se olvida es la segunda, porque el cliente no puede establecer el túnel en absoluto hasta que se permite su tráfico a la dirección pública del servidor. Trabaja de arriba abajo y cada fallo tiene una única causa candidata.
Un resolutor empujado necesita su propia regla
Que el túnel lleve DNS depende de lo que envíe el servidor. Un servidor que empuja una opción de resolutor instala una dirección privada en la configuración del cliente, y esa dirección solo es enrutable a través del túnel. Si el servidor no empuja nada, el cliente conserva el resolutor que ya tenía y las reglas de abajo no tienen nada que admitir. Comprueba el estado empujado y el resultado actual de la consulta antes de escribir nada:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedLa salida de estado nombra el resolutor en uso y el enlace al que está ligado, y la búsqueda de ruta que hay detrás muestra qué interfaz llevaría una consulta a esa dirección. Cuando el resolutor está en otro enlace, el problema es anterior al cortafuegos y ninguna regla ayudará. Cuando ambos coinciden en el túnel, hacen falta dos reglas, porque UDP lleva la mayoría de las consultas y TCP toma el relevo cuando una respuesta se trunca. Anota ambos valores, porque son los que las reglas nombrarán:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Abre el camino exterior antes que el interior
El cliente tiene que alcanzar la dirección pública del servidor antes de que exista un túnel, así que la regla para ello se sienta en el enlace físico y debe estar en su sitio primero. Una política que admite el resolutor pero olvida el servidor deja al cliente incapaz de construir el túnel, y ese síntoma suele achacarse a un kill switch. Después admite los servicios que de verdad querías a través del túnel, una regla estrecha cada vez, en lugar de abrir la interfaz entera. Las reglas estrechas son la razón por la que la denegación puede quedarse en su sitio.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'El orden importa mientras pruebas, porque la primera regla es la que permite que el túnel suba. Añádela, conéctate y confirma que el túnel está activo antes de añadir la regla del servicio, porque hacer ambas cosas a la vez hace que un fallo no te diga nada sobre qué mitad está mal. Sustituye la dirección de documentación de arriba por el punto de conexión para el que está configurado el cliente.
Termina el lado del cliente desconectando a propósito. La denegación debería seguir rechazando el tráfico que has excluido a propósito, porque un resolutor que responde mientras el túnel está activo cubre solo la mitad de una política que deniega en caso de duda.
Un cliente que se conecta aún no está admitido
El servidor tiene su propia dirección que considerar, y un cliente que completa el apretón de manos todavía no alcanza nada que se ejecute en el servidor hasta que el servidor lo admita. La regla del listener público solo permite que el túnel exista; no deja entrar el tráfico del túnel. En el servidor eso son dos reglas más una comprobación de que el servicio escucha de verdad:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'El grupo de la regla debe ser igual al rango que asigna el servidor, y el número del túnel debe coincidir con el que el servidor creó, porque una regla para otra interfaz es indistinguible de ninguna regla. limit es deliberado para un puerto administrativo, porque limita las conexiones repetidas en lugar de admitirlas sin límite. La comprobación del listener separa un puerto cerrado de un paquete descartado, que desde el cliente parecen idénticos. Las reglas numeradas tampoco son toda la imagen: las reglas before de UFW y cualquier línea de nftables escrita a mano coinciden antes y todavía pueden rechazar un paquete que la lista parece permitir.