¿El interruptor de corte de UFW bloquea tu VPN? Permite el par

Seguiste la lista de comprobación: denegar la salida, permitir el túnel, activar ufw. Luego el cliente espera en el handshake y nunca conecta, o conecta y no se carga ninguna página. Ambos fallos vienen del mismo hueco. Falta la regla que deja existir al túnel, porque el túnel no es una interfaz por la que salgan tus paquetes.

Por qué un permiso en tun0 no coincide con nada al principio

tun0 lo crea el cliente una vez que existe una sesión. Los datagramas que construyen esa sesión son paquetes UDP corrientes dirigidos al proveedor en el puerto 1194, y salen por wlan0 o eth0 con la dirección de origen física. allow out on tun0 solo coincide con el tráfico cuya interfaz de salida es tun0, así que durante el handshake no coincide con nada.

Pon default deny outgoing encima y los paquetes exteriores se descartan antes de que la interfaz aparezca siquiera. El cliente reintenta, agota el tiempo de espera e informa de un fallo de TLS o de handshake, lo que manda a la gente a buscar entre certificados y MTU mientras el cortafuegos se come la conexión en silencio. La regla que debía contener tu tráfico impide que ese tráfico se contenga.

El arreglo reflejo hace permanente la fuga. sudo ufw allow out on wlan0, o devolver el valor por defecto a permitir, levanta el túnel y deja la máquina sin interruptor de corte: la próxima vez que caiga el túnel, todo se reanuda por el adaptador físico. Perdí una tarde exactamente con ese par de ediciones antes de averiguar qué paquete estaba filtrando en realidad.

Qué necesitan los dos conjuntos de paquetes

Tu tráfico cruza el cortafuegos dos veces, en dos formas. El paquete interior va de la dirección del túnel hacia fuera por tun0. El paquete exterior va de la dirección física al par, y es lo único visible en el cable. Una regla por forma:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Sustituye la dirección y el puerto por los de tu propio perfil. Los pares de WireGuard suelen responder en 51820/udp; los perfiles de OpenVPN que van por TCP 443 necesitan ese puerto en su lugar. Los detalles cambian, la forma no: ambas reglas son estrechas y juntas definen los únicos destinos que la máquina puede alcanzar mientras el túnel está caído.

El orden es el segundo mito. Con iptables en bruto lees la cadena de arriba abajo y razonas qué regla gana. ufw no es un envoltorio fino de la lista que escribiste; compila tus reglas en sus propias cadenas y elige los puntos de inserción. ufw status las imprime en el orden de ufw, no en el tuyo. Cuando una regla parece ignorada, compara ufw show added con el conjunto compilado de iptables -S | grep ufw antes de reescribir nada.

La excepción tiene que quedarse ancha de una sola dirección

Una regla de par solo es correcta mientras nombra la dirección a la que marca el cliente. Los proveedores rotan puntos de conexión, y un perfil que resuelve un nombre de host seguirá un cambio de DNS hacia una dirección nueva mientras la regla sigue apuntando a la vieja. Cuando un túnel que funcionó durante meses deja de levantarse, compara la dirección de la regla con la que busca el cliente antes de ampliar nada.

Ampliar a toda una subred, o a cada destino en el puerto 1194, vuelve a convertir la política en un cortafuegos con un agujero. La excepción es el interruptor de corte; una vez que es amplio, no queda nada que cortar. Mantenla en una sola dirección y deja un comentario que nombre el perfil y el proveedor al que pertenece, porque dentro de seis meses la dirección parecerá arbitraria.

La resolución de nombres merece su propia línea. La consulta ocurre antes de que exista el túnel, por la interfaz física, así que una política estricta de denegación de salida puede dejar al cliente incapaz de encontrar su propio servidor. Permite el puerto 53 hacia la dirección de tu resolutor, o resuelve una vez y fija la dirección en el perfil. Permitir DNS en todas las interfaces es una decisión, no un valor por defecto.

Construye la política antes de que haga falta el túnel

ufw enable aplica toda la política de golpe y recarga sus cadenas, y cambiar una política por defecto en un cortafuegos en marcha también las recarga. El manual de ufw advierte de que eso puede tirar conexiones existentes como SSH. Por eso los comandos van en este orden, con la regla SSH antes de la activación y una sesión de consola abierta:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset se deja fuera de ese bloque a propósito. Borra todas las reglas y desactiva el cortafuegos, y en un host remoto la activación siguiente es lo que tira tu sesión. Si haces el reset, añade la regla SSH y confirma una segunda vía de vuelta por consola antes de seguir.

La secuencia no es cosmética. Las reglas añadidas mientras ufw corre no vacían nada, pero en el momento en que giras una política por defecto las cadenas se recargan, y una sesión que la política antigua permitía se va con ellas. Haz los valores por defecto, los permisos y la activación en una sola pasada, mientras todavía tienes una vía de entrada que no depende de la máquina.

Prueba el estado bloqueado y conserva la marcha atrás

Un interruptor de corte sin probar es una suposición. Desconecta el cliente a propósito e intenta cargar una página: debe fallar. Vuelve a conectar y debe recuperarse sin tocar ninguna regla. sudo ufw status verbose confirma los valores por defecto y el estado del registro, y ufw status numbered muestra qué regla de prueba borrar cuando sobreviva a su propósito.

Mantén el script inverso junto al directo. Una máquina con denegación de salida y un túnel muerto no puede descargar su propia reparación, así que la marcha atrás tiene que estar en el disco y ser legible desde una consola:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Ejecútalo cuando el túnel ya está caído y hay que quitar las reglas, no como un paso rutinario. Antes de cerrar el terminal, cuatro cosas deben cumplirse: la regla del par nombra exactamente una dirección, el DNS tiene una excepción nombrada, la activación llegó después de los permisos, y tirar del túnel mata el tráfico normal sin matar al cliente para siempre.