Un dispositivo por un VPN del router necesita tres reglas, no un interruptor

En un VPN del router no hay interruptor por dispositivo; el interruptor que buscas es un atajo que escribe reglas de enrutamiento por política por ti. En el momento en que un portátil, un rango de puertos, una lista de direcciones o un segmento LAN tiene que usar el túnel mientras todo lo demás sigue en la WAN, estás construyendo una ruta de política, no activando una función. El trabajo tiene tres piezas móviles, y cada una falla de forma distinta: una tabla marcada sin ruta parece silencio, una marca aplicada en la cadena equivocada parece que no pasó nada, y una regla NAT que falta parece un túnel que conecta y no transporta nada. Faltan dos piezas más porque nunca aparecen en la regla mangle, y son DNS e IPv6.

El mito: el túnel es un ajuste del cliente

Un cliente VPN en el router hace bien una cosa contundente: pone 0.0.0.0/0 en la tabla de enrutamiento principal y lo apunta al túnel. WireGuard lo deriva de AllowedIPs, OpenVPN de un redirect-gateway empujado, y ambos cambian la ruta de cada host detrás del router. Estrechar AllowedIPs o añadir route-nopull cambia lo que instala el cliente. No cambia a quién se aplica la instalación, porque el cliente nunca ve dispositivos. Solo ve paquetes.

Elegir por origen o destino es una decisión de enrutamiento, así que pertenece a la capa de política del router: una regla mangle más una segunda tabla en RouterOS, un MARK más una ip rule en OpenWrt o DD-WRT, o una regla de cortafuegos cuya puerta de enlace sea el túnel en pfSense. La receta de cliente WireGuard de Netgate es la que hay que leer antes de adivinar, porque en esa plataforma la puerta de enlace de la regla, la asignación de interfaz y la entrada NAT de salida tienen que coincidir antes de que un solo cliente use el túnel.

La segunda mitad del mito es el segundo router. Comprar otra caja o mover el dispositivo a un SSID de invitados a menudo funciona, y la razón no es el hardware: pone el dispositivo en su propia subred, lo que te da el selector de origen que el firmware ya entiende. Si puedes definir ese segmento en el router que tienes, la caja extra resuelve un problema que no tenías.

Primera pieza: un túnel que no es la ruta por defecto

En RouterOS, añade el cliente sin ruta por defecto y dale al túnel su propia tabla. La primera ruta es la por defecto marcada; la segunda es la mitad del fallo.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

La ruta unreachable es la razón por la que una tabla marcada gana a una lista de excepciones en la tabla principal. Cuando el túnel cae, los paquetes marcados reciben un unreachable inmediato en lugar de volver en silencio a la WAN, así que el fallo aparece en el mensaje de error de la aplicación y no en una página de geolocalización que consultas una hora después.

RouterOS 7 separa lo que 6.x mantenía junto: declaras la tabla con /routing table add name=vpn fib y luego la referencias por nombre en la ruta y en la regla mangle. Un fragmento de 6.x que pone routing-mark en línea sin definir la tabla se carga limpio y no coincide con nada. El otro clásico son dos mitades 0.0.0.0/1, o dos rutas por defecto a la misma distancia en una tabla: el núcleo elige una, y el comportamiento puede cambiar tras un reinicio.

Segunda pieza: marca antes de la consulta de ruta

El selector decide qué paquetes entran en esa tabla. RouterOS suele empezar con una lista de direcciones para la política de destino, o con una dirección de origen para la política de dispositivo:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

El firmware de Linux hace lo mismo con una marca netfilter y una regla que lleva los paquetes marcados a una tabla que has llenado:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

La cadena no es una cuestión de estilo. Cuando un paquete llega a FORWARD, la consulta de ruta ya ha ocurrido, así que un MARK o un DROP ahí solo puede reescribir o descartar. La marca debe caer en PREROUTING para el tráfico reenviado y en OUTPUT para el tráfico que origina el router, que es donde viven el DNS, el NTP y las comprobaciones de actualización del router. Ese camino de salida es la razón habitual de que una configuración totalmente tunelizada siga respondiendo desde el resolutor del ISP en una prueba de fugas.

La política de dispositivo necesita una coincidencia que no derive. Reserva la dirección en DHCP o haz coincidir una interfaz para un segmento dedicado; una dirección que luego pasa a otro dispositivo aplica el túnel en silencio al cliente equivocado. Un puente por SSID con su propia subred es la versión más duradera de la misma idea, y da a las reglas IPv6 un lugar donde vivir.

Tercera pieza: NAT, DNS y la excepción de la LAN

El tráfico que sale por el túnel necesita una dirección de origen a la que responda el lado remoto. Limita la traducción a la interfaz del túnel: out-interface=VPN_NAME en RouterOS, -o tun0 en Linux, una entrada NAT de salida coincidente en pfSense. Una regla masquerade sin ese alcance reescribe tráfico que querías dejar en paz, y el síntoma es que el dispositivo no tunelizado pierde su dirección pública.

La excepción de la LAN genera más hilos de soporte que el túnel. Si la tabla marcada solo tiene una ruta por defecto, un destino de impresora o NAS desde el dispositivo seleccionado coincide con esa por defecto y desaparece en el túnel. Añade la ruta LAN a la misma tabla, o excluye la subred local en el selector; ambas funcionan, y la exclusión es más fácil de mantener correcta cuando añadas VLAN más adelante.

DNS toma un camino aparte. Las consultas que el router reenvía se originan en el router y siguen OUTPUT, no la marca de reenvío, así que un portátil totalmente tunelizado todavía puede resolver a través del ISP. Apunta los clientes a un resolutor alcanzable por el túnel, o marca el tráfico del puerto 53 del propio router, y luego comprueba la dirección resuelta en vez de suponer que la respuesta viajó con la petición web.

Cuando la regla coincide pero la aplicación sigue usando la WAN

Las listas de destinos envejecen mal. Un nombre se resuelve a una dirección que no está en la lista, así que la petición toma la WAN mientras cada prueba que hiciste contra la dirección listada funcionaba. Actualiza la lista desde el mismo resolutor que usa el cliente, y prefiere un selector basado en origen cuando de verdad quieres todo el tráfico de un dispositivo.

IPv6 es el desvío silencioso. El dispositivo tiene una segunda familia de direcciones con su propia ruta por defecto y su propio conjunto de reglas, y hacer coincidir solo la dirección IPv4 es media política. Aplica el mismo selector a ip6tables o al equivalente de nftables, o desactiva IPv6 en ese segmento a propósito en vez de por accidente.

Las conexiones establecidas también cuentan. Una entrada conntrack creada antes del cambio sigue el camino viejo hasta que caduca, así que un navegador que quedó abierto durante la edición se ve exactamente como una regla que nunca se aplicó. Abre una conexión nueva, o vacía el estado, antes de juzgar la política.

Verifica con dos dispositivos y un reinicio

Prueba el dispositivo que debería ir por el túnel y el que no, y compara el segundo salto en lugar de un número de velocidad. Un traceroute desde cada uno muestra o la puerta de enlace del túnel o la del ISP en el segundo salto; si ambos parecen iguales, la marca o la tabla no hacen lo que dice la regla. Usa conexiones nuevas para la prueba.

Luego reinicia. El orden de arranque es donde una política que funciona se vuelve una rota, porque el cliente debe estar activo antes de que se instale la ruta unreachable, y una instantánea guardada que restaura el conjunto de reglas antiguo sobrescribirá tu tabla. Comprueba que cada regla está en la configuración guardada y que la ruta por defecto marcada existe tras el arranque, no solo después de que la hayas escrito.

Si algo falla, quita primero la marca y mira si vuelve el tráfico normal, luego quita la tabla. Ese orden te dice si persigues un problema de enrutamiento o de cortafuegos, y deja la casa con una impresora que funciona mientras terminas el trabajo.