Los clientes de la LAN ignoran la VPN del router hasta aplicar el enrutamiento por políticas

El router llega a internet por su túnel mientras un portátil detrás sigue informando de la dirección del ISP. Añadir reglas de aceptación no ayuda, y ese fallo es revelador: el filtrado responde si un paquete puede pasar, no hacia dónde va. La elección de interfaz ya la hizo una consulta de enrutamiento que no sabe nada de tu lista de clientes. Arregla la consulta y el cortafuegos deja de ser el sospechoso.

Una regla de filtrado no puede elegir una interfaz

El flujo de paquetes en un router Linux ejecuta primero la decisión de enrutamiento y después el gancho de reenvío. Cuando una regla coincide con el dispositivo de túnel saliente, el núcleo ya ha decidido que el túnel es la salida. Si la tabla principal sigue prefiriendo la ruta por defecto de la WAN, el paquete va camino del ISP y la regla de aceptación que acabas de escribir nunca lo ve. Ese único hecho de orden explica por qué una página de reglas nuevas de cortafuegos no cambia nada.

El ejemplo siguiente usa una LAN de 192.168.8.0/24 en br-lan, un dispositivo de túnel tun0 y un decodificador en 192.168.8.23 que debería usar el túnel.

Lee la consulta antes de editar reglas

Pide al núcleo que resuelva una ruta en nombre de ese cliente. La respuesta incluye el dispositivo saliente y la dirección de origen que se elegiría, y eso es todo lo que necesitas para confirmar el diagnóstico. Si la respuesta nombra el dispositivo de la WAN, el paquete nunca tuvo ocasión de llegar a tu regla.

ip -4 route get 198.51.100.7 from 192.168.8.23

Repite la consulta para un cliente que debería quedarse en el camino normal. Cuando ambas respuestas nombran el mismo dispositivo, todavía no hay ninguna política por origen en juego, y el arreglo corresponde al enrutamiento y no al filtrado.

Asocia una tabla a los clientes que quieres cubrir

El enrutamiento por políticas inserta una consulta de reglas antes de la tabla principal. Crea una tabla cuya ruta por defecto sea el túnel y luego ata esa tabla a un selector: una interfaz de entrada, una dirección de origen o una marca de cortafuegos. Las prioridades deciden el orden, y la tabla principal está muy abajo en la lista, en 32766, así que una regla con un número bajo se consulta primero. Los selectores de interfaz cubren a todos los clientes del puente; los selectores de dirección cubren una máquina.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Las interfaces del firmware suelen exponer los mismos objetos que una página de enrutamiento por políticas o de política de VPN. Una lista de dispositivos allí es más fácil de mantener que las reglas escritas a mano y suele sobrevivir a las actualizaciones que cambian la sintaxis de las reglas.

Elige el selector a propósito. Una regla de interfaz es corta y duradera, pero también captura el tráfico de gestión del propio router que llega a ese puente. Una regla de origen es exacta y necesita una edición cada vez que cambia la lista de dispositivos. Anota la elección, porque la necesitará la próxima persona que pregunte por qué un dispositivo se comporta distinto.

Mantén los destinos locales fuera del túnel

Una tabla nueva solo conoce las rutas que le pones. Falta el prefijo de la LAN, así que el tráfico de la impresora y del NAS seguiría la ruta por defecto del túnel y desaparecería. Una ruta throw termina la consulta en esta tabla y devuelve la decisión a la tabla principal.

ip -4 route add throw 192.168.8.0/24 table 200

Si te saltas esa ruta, los recursos compartidos locales se rompen, y la sesión de gestión del propio router puede desaparecer si el selector es más amplio de lo previsto. Luego resuelve la cuestión del origen: los paquetes del túnel que aún llevan direcciones de la LAN necesitan que el otro lado conozca un camino de vuelta, mientras que el masquerading en el túnel elimina ese requisito y también elimina la identidad del cliente que vería el otro lado.

Las reglas y rutas añadidas en tiempo de ejecución desaparecen tras un reinicio o una actualización del firmware. Añádelas al mecanismo de arranque del router, reinicia una vez y vuelve a probar desde el cliente: su dirección pública, un segundo cliente que debería quedarse en la WAN y los contadores del túnel durante una conexión nueva.