Un dispositivo por un VPN do router necesita tres regras, non un interruptor

Nun VPN do router non hai ningún interruptor por dispositivo; o interruptor que buscas é un atallo que escribe regras de enrutamento por política no teu lugar. No momento en que un portátil, un rango de portos, unha lista de enderezos ou un segmento LAN ten que usar o túnel mentres todo o demais segue na WAN, estás a construír unha ruta de política, non a activar unha función. O traballo ten tres pezas móbiles, e cada unha falla de forma distinta: unha táboa marcada sen ruta parece silencio, unha marca aplicada na cadea equivocada parece que non pasou nada, e unha regra NAT que falta parece un túnel que conecta e non transporta nada. Faltan dúas pezas máis porque nunca aparecen na regra mangle, e son DNS e IPv6.

O mito: o túnel é un axuste do cliente

Un cliente VPN no router fai ben unha cousa contundente: pon 0.0.0.0/0 na táboa de enrutamento principal e apúntao ao túnel. WireGuard derívao de AllowedIPs, OpenVPN dun redirect-gateway empurrado, e ambos cambian a ruta de cada host detrás do router. Estreitar AllowedIPs ou engadir route-nopull cambia o que instala o cliente. Non cambia a quen se aplica a instalación, porque o cliente nunca ve dispositivos. Só ve paquetes.

Escoller por orixe ou destino é unha decisión de enrutamento, así que pertence á capa de política do router: unha regra mangle máis unha segunda táboa en RouterOS, un MARK máis unha ip rule en OpenWrt ou DD-WRT, ou unha regra de devasado cuxa porta de enlace sexa o túnel en pfSense. A receita de cliente WireGuard de Netgate é a que hai que ler antes de adiviñar, porque nesa plataforma a porta de enlace da regra, a asignación de interface e a entrada NAT de saída teñen que coincidir antes de que un só cliente use o túnel.

A segunda metade do mito é o segundo router. Comprar outra caixa ou mover o dispositivo a un SSID de convidados a miúdo funciona, e a razón non é o hardware: pon o dispositivo na súa propia subrede, o que che dá o selector de orixe que o firmware xa entende. Se podes definir ese segmento no router que tes, a caixa extra resolve un problema que non tiñas.

Primeira peza: un túnel que non é a ruta por defecto

En RouterOS, engade o cliente sen ruta por defecto e dálle ao túnel a súa propia táboa. A primeira ruta é a por defecto marcada; a segunda é a metade do 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

A ruta unreachable é a razón pola que unha táboa marcada gaña a unha lista de excepcións na táboa principal. Cando cae o túnel, os paquetes marcados reciben un unreachable inmediato en lugar de volver en silencio á WAN, así que o fallo aparece na mensaxe de erro da aplicación e non nunha páxina de xeolocalización que consultas unha hora despois.

RouterOS 7 separa o que 6.x mantén xunto: declaras a táboa con /routing table add name=vpn fib e despois refírela por nome na ruta e na regra mangle. Un fragmento de 6.x que pon routing-mark en liña sen definir a táboa cárgase limpo e non coincide con nada. O outro clásico son dúas metades 0.0.0.0/1, ou dúas rutas por defecto na mesma distancia nunha táboa: o núcleo escolle unha, e o comportamento pode cambiar tras un reinicio.

Segunda peza: marca antes da consulta de ruta

O selector decide que paquetes entran nesa táboa. RouterOS adoita comezar cunha lista de enderezos para a política de destino, ou cun enderezo de orixe para a 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

O firmware de Linux fai o mesmo cunha marca netfilter e unha regra que leva os paquetes marcados a unha táboa que enches:

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

A cadea non é unha cuestión de estilo. Cando un paquete chega a FORWARD, a consulta de ruta xa ocorreu, así que un MARK ou un DROP alí só pode reescribir ou descartar. A marca debe caer en PREROUTING para o tráfico reenviado e en OUTPUT para o tráfico que orixina o router, que é onde viven o DNS, o NTP e as comprobacións de actualización do router. Ese camiño de saída é a razón habitual de que unha configuración totalmente tunelizada siga respondendo desde o resolutor do ISP nunha proba de fugas.

A política de dispositivo necesita unha coincidencia que non derive. Reserva o enderezo no DHCP ou fai coincidir unha interface para un segmento dedicado; un enderezo que despois pasa a outro dispositivo aplica o túnel en silencio ao cliente equivocado. Unha ponte por SSID coa súa propia subrede é a versión máis duradeira da mesma idea, e dálle ás regras IPv6 un lugar onde vivir.

Terceira peza: NAT, DNS e a excepción da LAN

O tráfico que sae polo túnel necesita un enderezo de orixe ao que responda o lado remoto. Limita a tradución á interface do túnel: out-interface=VPN_NAME en RouterOS, -o tun0 en Linux, unha entrada NAT de saída coincidente en pfSense. Unha regra masquerade sen ese alcance reescribe tráfico que querías deixar tranquilo, e o síntoma é que o dispositivo non tunelizado perde o seu enderezo público.

A excepción da LAN xera máis fíos de soporte que o túnel. Se a táboa marcada só ten unha ruta por defecto, un destino de impresora ou NAS desde o dispositivo seleccionado coincide con esa por defecto e desaparece no túnel. Engade a ruta LAN á mesma táboa, ou exclúe a subrede local no selector; ambas funcionan, e a exclusión é máis doada de manter correcta cando engadas VLAN máis adiante.

DNS toma un camiño aparte. As consultas que o router reenvía orixínanse no router e seguen OUTPUT, non a marca de reenvío, así que un portátil totalmente tunelizado aínda pode resolver a través do ISP. Apunta os clientes a un resolutor alcanzable polo túnel, ou marca o tráfico do porto 53 do propio router, e despois comproba o enderezo resolto en vez de supor que a resposta viaxou coa petición web.

Cando a regra coincide pero a aplicación segue usando a WAN

As listas de destinos envellecen mal. Un nome resólvese a un enderezo que non está na lista, así que a petición toma a WAN mentres cada proba que fixeches contra o enderezo listado funcionaba. Actualiza a lista desde o mesmo resolutor que usa o cliente, e prefire un selector baseado na orixe cando de verdade queres todo o tráfico dun dispositivo.

IPv6 é o desvío silencioso. O dispositivo ten unha segunda familia de enderezos coa súa propia ruta por defecto e o seu propio conxunto de regras, e facer coincidir só o enderezo IPv4 é media política. Aplica o mesmo selector a ip6tables ou ao equivalente de nftables, ou desactiva IPv6 nese segmento a propósito en vez de por accidente.

As conexións establecidas tamén contan. Unha entrada conntrack creada antes do cambio segue o camiño vello ata que caduca, así que un navegador que quedou aberto durante a edición parece exactamente unha regra que nunca se aplicou. Abre unha conexión nova, ou baleira o estado, antes de xulgar a política.

Verifica con dous dispositivos e un reinicio

Proba o dispositivo que debería ir polo túnel e o que non, e compara o segundo salto en lugar dun número de velocidade. Un traceroute desde cada un mostra ou a porta de enlace do túnel ou a do ISP no segundo salto; se ambos parecen iguais, a marca ou a táboa non fan o que di a regra. Usa conexións novas para a proba.

Despois reinicia. A orde de arranque é onde unha política que funciona se converte nunha rota, porque o cliente debe estar activo antes de que se instale a ruta unreachable, e unha instantánea gardada que restaura o conxunto de regras antigo sobrescribirá a túa táboa. Comproba que cada regra está na configuración gardada e que a ruta por defecto marcada existe tras o arranque, non só despois de que a escribas.

Se algo falla, quita primeiro a marca e mira se volve o tráfico normal, logo quita a táboa. Ese orde diche se persegues un problema de enrutamento ou de devasado, e deixa a casa cunha impresora que funciona mentres rematas o traballo.