Um dispositivo pela VPN do roteador exige três regras, não um interruptor

Não existe um interruptor por dispositivo numa VPN do roteador; o interruptor que você procura é um atalho que escreve regras de roteamento de política em seu nome. No momento em que um notebook, uma faixa de portas, uma lista de endereços ou um segmento de LAN precisa usar o túnel enquanto todo o resto fica na WAN, você está construindo uma rota de política, não ativando um recurso. O trabalho tem três partes móveis, e cada uma falha de um jeito: uma tabela marcada sem rota parece silêncio, uma marca aplicada na cadeia errada parece que nada aconteceu, e uma regra NAT ausente parece um túnel que conecta e não transporta nada. Mais duas peças somem porque nunca aparecem na regra mangle, e são o DNS e o IPv6.

O mito: o túnel é uma configuração do cliente

Um cliente VPN do lado do roteador faz bem uma coisa grosseira: coloca 0.0.0.0/0 na tabela de roteamento principal e aponta para o túnel. O WireGuard deriva isso das AllowedIPs, OpenVPN e de um redirect-gateway empurrado pelo servidor, e ambos mudam o caminho de cada host atrás do roteador. Restringir as AllowedIPs ou adicionar route-nopull muda o que o cliente instala. Não muda a quem a instalação se aplica, porque o cliente nunca vê dispositivos. Ele só vê pacotes.

A seleção por origem ou destino é uma decisão de roteamento, então pertence à camada de política do roteador: uma regra mangle mais uma segunda tabela no RouterOS, um MARK mais um ip rule no OpenWrt ou DD-WRT, ou uma regra de firewall cujo gateway é o túnel no pfSense. A receita de cliente WireGuard da Netgate é a que se deve ler antes de chutar, porque nessa plataforma o gateway da regra, a atribuição da interface e a entrada de NAT de saída precisam concordar antes que um único cliente use o túnel.

A outra metade do mito é o segundo roteador. Comprar outra caixa, ou mover o dispositivo para um SSID de convidados, muitas vezes funciona, e a razão não é o hardware: coloca o dispositivo na própria sub-rede, o que dá o seletor de origem que o firmware já entende. Se você consegue definir esse segmento no roteador que possui, a caixa extra resolve um problema que você não tinha.

Peça um: um túnel que não é a rota padrão

No RouterOS, adicione o cliente sem rota padrão e dê ao túnel a própria tabela. A primeira rota é a padrão marcada; a segunda é a metade da falha.

/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 rota unreachable é o motivo pelo qual uma tabela marcada vence uma lista de exceções na tabela principal. Quando o túnel cai, os pacotes marcados recebem unreachable imediato em vez de voltarem silenciosamente para a WAN, então a falha aparece na mensagem de erro da aplicação e não numa página de geolocalização que você confere uma hora depois.

O RouterOS 7 separa o que o 6.x mantinha junto: você declara a tabela com /routing table add name=vpn fib e depois referencia por nome na rota e na regra mangle. Um trecho de 6.x que escreve routing-mark sem definir a tabela carrega limpo e não corresponde a nada. O outro clássico são duas metades 0.0.0.0/1, ou dois padrões na mesma distância numa tabela: o kernel escolhe um, e o comportamento pode mudar após reiniciar.

Peça dois: marque antes da consulta de rota

O seletor decide quais pacotes entram nessa tabela. O RouterOS costuma começar com uma lista de endereços para política de destino, ou um endereço de origem para 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 Linux faz o mesmo com uma marca netfilter e uma regra que direciona pacotes marcados para uma tabela que você populou:

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 cadeia não é escolha de estilo. Quando um pacote chega ao FORWARD a consulta de rota já aconteceu, então um MARK ou DROP ali só pode reescrever ou descartar. A marca precisa cair em PREROUTING para o tráfego encaminhado e em OUTPUT para o tráfego que o roteador origina, onde vivem DNS, NTP e as verificações de atualização do roteador. Esse caminho de saída é o motivo comum de uma implantação totalmente tunelada ainda responder pelo resolver do provedor num teste de vazamento.

Política de dispositivo exige uma correspondência que não escorrega. Reserve o endereço no DHCP, ou combine uma interface para um segmento dedicado; um endereço que depois se muda para outro dispositivo aplica o túnel silenciosamente ao cliente errado. Uma bridge por SSID com sub-rede própria é a versão mais durável da mesma ideia, e dá às regras IPv6 um lugar para morar também.

Peça três: NAT, DNS e a exceção de LAN

O tráfego que sai pelo túnel precisa de um endereço de origem que o outro lado responda. Restrinja a tradução à interface do túnel: out-interface=VPN_NAME no RouterOS, -o tun0 no Linux, uma entrada de NAT de saída correspondente no pfSense. Uma regra masquerade sem esse escopo reescreve tráfego que você queria deixar em paz, e o sintoma é o dispositivo fora do túnel perder o endereço público.

A exceção de LAN gera mais tópicos de suporte do que o próprio túnel. Se a tabela marcada guarda apenas uma rota padrão, um destino de impressora ou NAS do dispositivo selecionado casa com esse padrão e desaparece no túnel. Adicione a rota de LAN à mesma tabela, ou exclua a sub-rede local no seletor; os dois funcionam, e a exclusão é mais fácil de manter correta quando você adiciona VLANs depois.

O DNS segue um caminho separado. As consultas que o roteador encaminha são originadas no roteador e seguem OUTPUT, não a marca encaminhada, então um notebook totalmente tunelado ainda pode resolver pelo provedor. Aponte os clientes para um resolver alcançável pelo túnel, ou marque o tráfego port-53 do próprio roteador, e depois verifique o endereço resolvido em vez de supor que a resposta viajou junto com a requisição web.

Quando a regra casa mas o app continua usando a WAN

Listas de destino envelhecem mal. Um nome resolve para um endereço que não está na lista, então a requisição pega a WAN enquanto todo teste que você fez contra o endereço listado funcionava. Atualize a lista a partir do mesmo resolver que o cliente usa, e prefira um seletor baseado na origem quando você realmente quer todo o tráfego de um dispositivo.

O IPv6 é o desvio silencioso. O dispositivo tem uma segunda família de endereços com a própria rota padrão e o próprio conjunto de regras, e casar apenas o endereço IPv4 é metade da política. Aplique o mesmo seletor ao ip6tables ou ao equivalente nftables, ou desligue o IPv6 nesse segmento de propósito, não por acidente.

Conexões estabelecidas também importam. Uma entrada de conntrack criada antes da mudança continua seguindo o caminho antigo até expirar, então um navegador que ficou aberto durante a edição parece exatamente uma regra que nunca foi aplicada. Abra uma conexão nova, ou limpe o estado, antes de julgar a política.

Verifique com dois dispositivos e um reinício

Teste o dispositivo que deveria estar no túnel e o que não deveria, e compare o segundo salto em vez de um número de velocidade. Um traceroute de cada um mostra o gateway do túnel ou o gateway do provedor no segundo salto; se os dois parecerem iguais, a marca ou a tabela não está fazendo o que a regra diz. Use conexões novas no teste.

Depois reinicie. A ordem de inicialização é onde uma política que funciona quebra, porque o cliente precisa estar no ar antes de a rota unreachable ser instalada, e um snapshot salvo que restaura o conjunto antigo de regras sobrescreverá sua tabela. Verifique que cada regra está na configuração salva e que a padrão marcada existe após o boot, não só depois de você digitá-la.

Se algo falhar, remova a marca primeiro e veja se o tráfego normal volta, depois remova a tabela. Essa ordem diz se você está caçando um problema de roteamento ou de firewall, e deixa a casa com uma impressora funcionando enquanto você termina o serviço.