¿Script de bajada o regla de cortafuegos: cuál detiene la fuga?

Dos diseños prometen lo mismo: cuando el túnel cae, nada sale al exterior en claro. Uno ejecuta un script al desmontar y corta las interfaces. El otro deja una regla de cortafuegos en vigor y no le pide nada al cliente VPN. Difieren en quién tiene el privilegio de actuar, en qué ocurre durante el hueco y en cómo la máquina vuelve a estar en línea después. Compararlos en esos tres puntos es más útil que discutir cuál es más estricto.

El mismo trabajo con dos mecanismos

El cliente puede ejecutar ganchos cuando el túnel sube y cuando se desmonta, siempre que el perfil permita ejecutar scripts. Ese gancho se ejecuta dentro del ciclo de vida del cliente, en el momento en que la conexión se cierra. Una regla de cortafuegos, en cambio, pertenece al sistema y no le importa si el cliente está funcionando, se ha colgado o lo han matado.

Esa tabla es todo el argumento. Un script que solo se ejecuta en un cierre ordenado cubre el caso que menos le preocupaba; el caso que importa es el fallo o la desaparición de la red, y ninguno de los dos produce un desmontaje limpio.

Qué puede y qué no puede hacer el gancho de desmontaje

El patrón documentado recorre las interfaces de red y baja todo excepto loopback. Con el dispositivo físico bajado, nada puede escapar fuera del túnel, que es exactamente la intención.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

También baja la red local, cualquier servicio que aloje la máquina y la ruta que usaría para arreglar el problema. En un portátil el dispositivo inalámbrico a veces necesita un cambio manual después, así que una interrupción breve se convierte en una sesión de reparación. Peor aún, puede que no se permita al gancho hacer nada de eso: cuando el cliente renuncia a los privilegios, el script de desmontaje se ejecuta con la cuenta sin privilegios y cada cambio de interfaz falla con un error de permisos escrito en el momento en que nadie lee el registro.

Compruebe cómo se inicia el cliente antes de confiar en el gancho. Un script que funciona al ejecutarlo a mano como root no demuestra nada sobre el servicio que arranca en el inicio.

Qué hace distinta la regla de cortafuegos

Una regla que solo permite el tráfico del túnel sigue funcionando cuando el proceso del cliente ha desaparecido, porque el núcleo no depende de ese proceso. La regla también es más estrecha: bloquea exactamente los flujos que coincide y deja en paz loopback, la subred local y la ruta de recuperación, y por eso no deja la máquina aislada.

El precio es que la regla debe escribirla y mantenerla quien posee el cortafuegos del equipo, y tiene que nombrar el dispositivo de túnel que el cliente crea realmente. Eso significa que la regla y el perfil deben mantenerse juntos; una interfaz renombrada deja un cortafuegos que lo bloquea todo y no explica nada.

Ninguno de los dos mecanismos hace superfluo al otro. Una regla de cortafuegos que nunca se recarga tras una edición es tan ficticia como un script que nunca se ejecuta.

persist-tun decide si existe un hueco

Cuando el dispositivo de túnel sobrevive a una desconexión, las rutas que apuntan a él también sobreviven. El tráfico entonces se descarta en lugar de redirigirse, así que la ruta por defecto no vuelve a la pasarela física. Ese es el comportamiento que hace improbable una fuga incluso antes de que intervenga ninguna regla de cortafuegos.

Sin ese ajuste, el dispositivo se elimina y las rutas con él, y la ruta por defecto puede volver a resolverse hacia la pasarela física. Si lo hace depende de la plataforma y del cliente, y por eso mismo el estado debe observarse en lugar de suponerse. Trate el ajuste como parte del kill switch, no como una opción de rendimiento.

Mantenga vivo el camino de reconexión y luego pruebe cuatro estados

Un bloqueo estricto también puede impedir que el cliente se reconecte, porque el cliente sigue necesitando una ruta al servidor a través de la pasarela física mientras todo lo demás se deniega. Instale una ruta de host para esa única dirección antes de que suba el túnel, y resuelva el nombre primero, porque el DNS puede estar bloqueado cuando lo necesite.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Luego verifique los estados y no la etiqueta. Practique cuatro momentos a propósito: un arranque en frío sin túnel, una sesión sana, una caída que nadie pidió y la sesión después de que se recupere. En cada momento lea la ruta por defecto y haga una petición cuya dirección de salida sea visible. Una aplicación que se rinde mientras el túnel está abajo no dice nada de un cliente de correo ni de un actualizador, así que repita la última comprobación con una aplicación en segundo plano. Anote la regla, los nombres de las interfaces y los pasos de recuperación, porque un kill switch que nadie puede verificar es un rumor.