La Wi-Fi de invitados sigue usando la ruta principal: dale su propia salida

Creaste una red de invitados, añadiste una ruta para ella y los invitados siguen saliendo por tu conexión normal a internet. El túnel está activo, la LAN principal funciona y los dispositivos de invitados informan de una dirección dentro del rango que asignaste, así que nada parece roto. Lo que suele faltar no es una ruta sino un selector: el router decide la ruta antes de considerar por qué interfaz llegó el paquete, y a menos que algo coincida explícitamente con el tráfico de invitados, ese tráfico hereda el valor por defecto. La solución es un segmento, una regla de política y una ruta de respuesta, en ese orden.

El síntoma: los invitados siguen saliendo por la WAN

La señal es la dirección de salida. Un dispositivo de invitado que llega a internet por el túnel informará de la dirección del proveedor del túnel, y uno que heredó la ruta por defecto informará de tu conexión normal. Compara lado a lado un dispositivo de invitado y uno de la LAN principal, porque el caso interesante es cuando difieren de lo que configuraste y coinciden entre sí.

La segunda señal es la ausencia de tráfico en la interfaz del túnel mientras los invitados navegan. Si los contadores no se mueven, la política nunca se aplicó, y ajustar el túnel en sí no puede ayudar.

Paso 1: un segmento real, no solo un nombre

Un nombre de SSID no crea aislamiento. Comprueba que la red de invitados termina en su propia interfaz, VLAN o puente, y que el rango de direcciones es distinto del de la LAN de confianza. En muchos puntos de acceso domésticos, el SSID de invitados se puentea en el mismo segmento que todo lo demás, lo que hace imposible el resto de este trabajo hasta que se corrija.

Después confirma el rango de invitados y su servidor DHCP, y mantén la configuración del resolutor asociada a ese segmento en lugar de a todo el router. Una subred de invitados que solo existe como comentario en una regla de firewall no es un segmento, y el router no tendrá ninguna interfaz con la que coincidir.

No puentees a los invitados en la LAN principal para que el VPN sea más fácil de configurar. Eso cambia el aislamiento que querías por un atajo de enrutamiento, y es la razón habitual por la que una red de invitados acaba con acceso a la impresora y al NAS.

Paso 2: selecciona el túnel por origen

Las tablas de enrutamiento se eligen por destino, así que una regla que dice «envía 0.0.0.0/0 al túnel» se aplica a todos. El enrutamiento por políticas añade una segunda dimensión: seleccionar la tabla por dirección de origen. En un router basado en Linux, eso es una regla adicional más una tabla dedicada, y el orden importa porque gana la primera regla que coincide:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Ese último comando responde directamente a la pregunta: qué interfaz usará este origen para este destino. Ejecútalo antes y después del cambio y sabrás si la política surtió efecto sin tocar un navegador.

La mayoría de los firmwares de router expresan lo mismo como una regla de interfaz o una selección de puerta de enlace basada en el origen. Sea cual sea la sintaxis que use tu plataforma, el principio es idéntico: coincide con la interfaz de entrada o el prefijo de origen y luego anula la ruta solo para esa coincidencia. Una regla que coincide por destino no puede distinguir a un invitado de un dispositivo del hogar.

Paso 3: la ruta de respuesta y la traducción

Un paquete que sale por el túnel tiene que volver. O el par del túnel conoce una ruta de vuelta al prefijo de invitados, o el router traduce el origen de invitados a la dirección del túnel. Elige una y anótala, porque los modos de fallo se ven distintos: una ruta de retorno ausente da una conexión que se establece y nunca responde, mientras que la traducción ausente a menudo no produce nada en absoluto.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Si eliges la traducción, recuerda que el par ahora ve una sola dirección para todos los invitados, así que cualquier política por cliente en el extremo remoto desaparece. Si en cambio conservas las direcciones, ambos extremos necesitan el prefijo de invitados en su enrutamiento y su política, lo que es más trabajo y más predecible.

IPv6 necesita su propia regla. Una política escrita para IPv4 no cubre la otra familia, y un dispositivo de invitados con IPv6 funcionando la usará encantado mientras tu cuidadosamente enrutada ruta IPv4 queda inactiva. Enruta ambas familias o desactiva IPv6 en el segmento de invitados, pero no supongas que la regla combinada que escribiste cubre lo que el dispositivo hace realmente. Prueba con un cliente que tenga ambas familias habilitadas, porque ese es el caso que el diseño tiene que resistir. Un portátil que prefiere IPv6 parece correcto en una prueba solo IPv4 y filtra en la real.

Prueba el aislamiento, no solo la navegación

Navegar demuestra que la salida cambió. No demuestra que el segmento esté aislado, y el aislamiento es la razón por la que existe la red de invitados. Desde un dispositivo de invitados, intenta alcanzar la interfaz de administración del router, un host de la LAN de confianza y un servicio que debería rechazarse; los tres deberían fallar, y el fallo debería ser una decisión de política en lugar de un tiempo de espera que nadie puede explicar.

Luego prueba un dispositivo de la LAN principal y confirma que su salida no cambió. Ese es el retroceso que este diseño causa con más frecuencia: una regla amplia pensada para invitados, aplicada a todas las interfaces porque la coincidencia se escribió por destino.

Por último, decide qué ocurre cuando el túnel está caído. Los invitados o se quedan sin internet o pasan a una ruta que apruebas, y dejar eso sin decidir significa un retroceso silencioso a la conexión normal, que es exactamente la fuga que la política de invitados debía evitar. La receta de enrutamiento del tráfico de internet recorre la misma selección de ruta para un router basado en pfSense.

El DNS originado en el router es el caso que sorprende a la gente al final. Si los invitados usan el router como su resolutor, las propias consultas del router siguen la ruta del router en lugar de la regla de invitados, así que las búsquedas pueden salir por la conexión normal mientras el tráfico de la aplicación no. Mantén el segmento, el resolutor y la política de fallo en una sola nota, y la siguiente persona podrá comprobar los tres sin volver a deducir el diseño.