Bloquear un cliente OpenVPN de la LAN sin detener el túnel

Un cliente de tu servidor OpenVPN debe perder el acceso a la LAN mientras el resto de túneles siguen activos. Si lo buscas, la respuesta más votada suele decir que el demonio no puede hacerlo, lo cual solo es medio cierto: OpenVPN no tiene cortafuegos por cliente, pero el host que termina el túnel ya filtra paquetes. Las dos decisiones que importan son la identidad que bloqueas y la posición de la regla. Acertar con ambas convierte el cambio en una línea que puedes probar y quitar.

Fija el cliente antes de escribir la regla

OpenVPN asigna direcciones de túnel desde un grupo, así que 10.8.0.6 es un asiento, no una persona. Cuando termina la sesión el alquiler vuelve y puede entregarse a la siguiente conexión, lo que significa que una regla escrita contra esa dirección sigue al asiento, no al usuario. Decide primero qué bloqueas de verdad: una dirección para un experimento corto o un certificado para alguien a quien quieres dejar fuera.

Para vincular la dirección al certificado, crea un archivo en el directorio que indica client-config-dir y dale exactamente el common name del certificado. Pon dentro una directiva, ifconfig-push 10.8.0.6 255.255.255.0, y ese cliente conserva la misma dirección de túnel entre reconexiones. Deben existir dos ajustes para que esto surta efecto: client-config-dir tiene que estar declarado en la configuración del servidor y la dirección enviada debe estar en una subred que el servidor pueda enrutar. Si falta uno, el archivo se ignora sin error, lo que hace engañosa la siguiente prueba de cortafuegos.

Un bloqueo temporal puede usar una dirección del grupo, siempre que el ticket registre qué sesión la tenía en ese momento.

El orden decide si el descarte se ejecuta

En una puerta de enlace Linux que reenvía entre el túnel y la LAN, los paquetes cruzan la cadena FORWARD. Lee el comando de abajo como una frase: inserta al principio de FORWARD, coincide con el tráfico que entra desde tun0, de ese único host, dirigido a la subred de la LAN, y descártalo.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

El -I es lo que hace que la regla se ejecute. Añadida con -A, cae por debajo de cualquier aceptación amplia para la subred del túnel y nunca ve un paquete. Verifica la posición con iptables -vnL FORWARD --line-numbers y lee también los contadores: un descarte arriba que no cuenta nada significa que el tráfico llega por otro camino.

La propia dirección LAN de la puerta de enlace es otro camino. Los paquetes enviados a la máquina van a INPUT, no a FORWARD, así que un cliente puede perder un host de la LAN y aun así abrir la página de administración del router. Añade la regla INPUT correspondiente cuando eso importe.

Lo que el filtro no puede ver

El filtrado ocurre cuando se evalúa un paquete, así que una sesión TCP establecida puede continuar hasta que se cierre o se reinicie. Si el bloqueo debe morder de inmediato, limpia los flujos rastreados de esa fuente con conntrack -D -s 10.8.0.6 después de poner la regla. Si unos segundos de solapamiento son aceptables, registra esa elección en vez de dejarla implícita. En cualquier caso, la siguiente persona necesita saber si la regla detiene el tráfico vivo o solo las conexiones nuevas.

El tráfico entre pares nunca toca el cortafuegos del host. Con client-to-client activado, OpenVPN reenvía esos paquetes dentro del demonio, así que ni FORWARD ni INPUT los ven. Las únicas soluciones son desactivar client-to-client o aceptar que los pares pueden alcanzarse; una regla de iptables no verá ese tráfico.

IPv6, firmware y supervivencia al reinicio

Una regla IPv4 no dice nada sobre IPv6. Si el túnel y la LAN llevan ambas familias, la regla equivalente debe existir en ip6tables, o en el conjunto de reglas nftables que posee la política en ese host. El firmware del router a menudo esconde netfilter tras su propia abstracción, así que la sintaxis y los nombres de tabla copiados de un foro pueden no aplicarse.

En OpenWrt, la ruta documentada es una entrada de configuración del cortafuegos y no una línea de iptables escrita a mano, y una línea escrita a mano puede desaparecer cuando el cortafuegos se recarga. Otras distribuciones restauran las reglas mediante netfilter-persistent, una unidad de arranque o un almacén del fabricante, y esos mecanismos no son intercambiables. Demuestra el que hayas elegido con un reinicio, porque una recarga ejercita un camino distinto.

Verifica por camino y luego revierte limpio

Prueba cada camino por separado, porque una comprobación correcta esconde las demás. Un cliente bloqueado debería seguir llegando a internet por el túnel mientras falla contra un host de la LAN, un segundo cliente debería llegar a ese mismo host, y la dirección de la puerta de enlace y el camino entre pares necesitan cada uno su propia observación. Escribe los resultados junto a la regla para que el siguiente cambio tenga una base. La tabla de abajo es el conjunto que vale la pena guardar en el ticket.

La reversión es un borrado por especificación, no un flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP elimina exactamente esa entrada y deja intacto el resto de la cadena. Quita la misma línea del archivo que restaure las reglas al arrancar, recárgalo y confirma que el cliente vuelve a llegar al host de la LAN. Un flush de FORWARD también desharía reglas que no escribiste, lo que convierte una reversión en un segundo incidente.

Antes de cerrar el ticket, confirma tres cosas: la dirección fijada coincide con el certificado, la regla está por encima de las aceptaciones con un contador distinto de cero y el archivo de persistencia contiene la misma regla que probaste. Si falta alguna, el bloqueo es una ilusión de sesión de shell.