Kill switch en el router que cubre FORWARD, OUTPUT e IPv6

Usted entra en el router, pega un conjunto de reglas de kill switch sacado de un mensaje de foro, y la LAN deja de navegar en el momento en que el túnel cae. Dos días después, el router sigue actualizando su registro DNS dinámico por la WAN normal, y el portátil de invitados sigue llegando a sitios IPv6. Ambos comportamientos son normales, porque las reglas pegadas cubrían una cadena y una familia de direcciones, y ninguna de las dos es todo el router. Recorrer las rutas de los paquetes en orden muestra exactamente qué se quedó fuera.

Empiece por el router, no por el portátil

Una política a nivel de router es atractiva para una oficina pequeña porque cada dispositivo detrás hereda el mismo comportamiento y nadie puede olvidarse de activar un interruptor en el cliente. También le da un único lugar donde probar tras cada actualización de firmware. Lo que no le da es cobertura automática del tráfico propio del router ni de una segunda familia de direcciones, y esas son las dos brechas detrás de la mayoría de los despliegues fallidos.

Antes de tocar nada, anote tres datos en papel: el nombre de la interfaz WAN, el nombre del puente LAN y la dirección y el puerto del extremo de la VPN. Los necesitará los tres en las reglas, y adivinar nombres de interfaces es la causa más común de que un conjunto de reglas que parece correcto no haga nada.

Recorra los tres caminos que puede tomar un paquete

El tráfico de un portátil a internet se reenvía, así que pasa por la cadena FORWARD. El tráfico que genera el propio router, como el reenvío de DNS, las consultas NTP, las actualizaciones DDNS y el canal de control de la VPN, pasa por OUTPUT. El tráfico de gestión dirigido al router llega por INPUT.

Un kill switch construido solo en FORWARD protege, por tanto, a los clientes y nada más. La tabla muestra por qué la fuga de la escena inicial es previsible y no misteriosa.

En la mayoría de los diseños no necesita un kill switch en INPUT, pero sí debe mantener funcionando el acceso de gestión mientras el túnel está caído. De lo contrario, la primera vez que falle la VPN irá a la oficina con un cable de consola.

Ordene las reglas para que el túnel aún pueda levantarse

Un kill switch que funciona es una lista de permitidos que termina en un rechazo, y el orden es lo que lo convierte en un kill switch en lugar de un ladrillo. Permita primero loopback, el extremo de la VPN, las respuestas de los flujos establecidos y la interfaz del túnel; rechace el resto al final.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

El extremo debe ser una dirección en este punto, no un nombre de host. Una vez que el rechazo final bloquea DNS, una regla que nombre el host del proveedor ya no puede resolverse, y el túnel no vuelve a arrancar nunca tras un reinicio. Si el proveedor rota los extremos, resuelva el nombre antes de aplicar la política y refresque esa regla desde el mismo script.

Reproduzca la forma en FORWARD para el tráfico de los clientes y coloque una regla de gestión explícita por encima del rechazo. Mantenga esa regla de gestión estrecha pero alcanzable, y confírmela abriendo una segunda sesión SSH antes de cerrar la primera. Quedarse fuera durante un cambio de kill switch es lo bastante habitual como para planificarlo. En un router con WireGuard, los allowed-ips del par deciden qué entra en el túnel, mientras que estas reglas deciden qué puede salir sin él.

IPv6 necesita su propia puerta

Todo lo anterior es IPv4. Si su LAN tiene IPv6 funcionando y el túnel solo transporta IPv4, cada dispositivo cubierto sigue teniendo una ruta directa a internet que sus nuevas reglas nunca ven. Un portátil de doble pila la preferirá sin dudar, y el kill switch solo parecerá roto a quien prueba con IPv4.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Aquí el orden también importa: la aceptación de loopback debe preceder al rechazo de la WAN, o los servicios locales del router empezarán a fallar de formas extrañas. Si la red no usa IPv6 en absoluto, desactivarlo en la WAN y la LAN es más sencillo y no deja nada que olvidar.

Algunos clientes de VPN instalan una ruta por defecto solo para IPv4 y dejan intacta la ruta por defecto IPv6 existente. Compruebe la tabla de enrutamiento después de que el túnel se conecte en lugar de suponer que el cliente se encargó de ello.

Demuéstrelo con el túnel caído

Detenga el túnel desde el router y pruebe desde tres lugares en este orden:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

La consulta de ruta le dice adónde iría un paquete, y los contadores le dicen si sus reglas llegaron a coincidir. Una regla con cero paquetes tras una prueba fallida no protege nada, y la causa habitual es un nombre de interfaz distinto del que escribió. Pruebe explícitamente el tráfico generado por el router, porque una prueba desde el lado de la LAN no puede ejercitar OUTPUT.

Decida el modo de fallo antes de necesitarlo. Fail-closed mantiene a los clientes sin conexión hasta que vuelve el túnel; fail-open restaura el acceso normal a la WAN y arruina el propósito para el tráfico que le importaba. Una ruta blackhole hacia el pool de la VPN con una métrica alta es una segunda capa útil para los diseños fail-closed, ya que sobrevive cuando desaparece la ruta del túnel en lugar de volver a la ruta por defecto.

Acepte la configuración solo cuando un cliente de la LAN, una petición generada por el router y una petición IPv6 fallen todas con el túnel caído, y las tres vuelvan a funcionar una vez levantado.