O roteamento está na camada IP 3. O TCP está na camada 4, portanto, o roteamento sozinho não é suficiente para lidar com isso.
Resumindo: o tráfego interessante deve ser marcado com iptables , e marcou os pacotes selecionados com ip rule 's fwmark para usar uma tabela de roteamento separada. Em seguida, duas outras correções devem ser aplicadas para o caso de tráfego iniciado / recebido localmente, o que é mais difícil do que o caso roteado. Todas as configurações são feitas no sistema local.
Tabela de roteamento 80 (um nome simbólico correspondente pode ser adicionado em /etc/iproute2/rt_tables , mas isso não é obrigatório) e a marca 0x80 foi "arbitrariamente" escolhida.
ip route add table 80 192.168.1.0/24 dev eth0 scope link src 192.168.1.56
ip route add table 80 default dev eth0 via 192.168.1.1
Usando -I para garantir que as regras do iptables não sejam anexadas tarde demais. Você deve verificar com suas regras atuais como reordenar, se necessário:
iptables -t mangle -N markports
iptables -t mangle -I PREROUTING 1 -j CONNMARK --restore-mark
iptables -t mangle -I OUTPUT 1 -m mark --mark 0 -j markports
iptables -t mangle -I OUTPUT 2 -j CONNMARK --save-mark
iptables -t mangle -A markports -p tcp --dport 80 -j MARK --set-mark 0x80
iptables -t mangle -A markports -p tcp --dport 443 -j MARK --set-mark 0x80
ip rule add fwmark 0x80 lookup 80
Este blogue: Netfilter Connmark »Para Linux e além! fornece boas informações sobre CONNMARK .
Isso deveria estar funcionando, mas na verdade o IP de saída padrão incorreto terá sido selecionado na primeira decisão de roteamento, porque a rota estava prestes a passar por tun0 . Na verificação de reencaminhamento feita por causa da marca mangle/OUTPUT (consulte este Fluxo de pacotes no esquema Netfilter e General Networking para esclarecimento), este IP não mudará. Se o tráfego manipulado fosse roteado em vez de ser iniciado localmente, esse problema não aconteceria (usando um namespace de rede separado para garantir que essa seja uma solução para serviços, provavelmente não para um Desktop). Isso requer também uma camada de MASQUERADE (ou SNAT para casos mais complexos) sobre ele:
iptables -t nat -I POSTROUTING 1 -m mark --mark 0x80 -j MASQUERADE
Agora que o IP de origem de saída está correto, ele ainda não está funcionando: o reverse filter filter dispara no caminho de retorno pelo mesmo motivo: a decisão de roteamento feita antes de PREROUTING doesn ' Não sei o fwmark por enquanto (apesar do esquema anterior Colocar mangle/PREROUTING antes da decisão de roteamento, aparentemente não é o caso), portanto, considera os pacotes de tráfego de retorno a serem falsificados e os descarta antecipadamente. O eth0 interface rp_filter precisa ser colocado em modo solto para que isso seja permitido. Isso pode ter alguns problemas de segurança (muito pequenos por trás do NAT), mas achei inevitável esse caso não roteado:
echo 2 > /proc/sys/net/ipv4/conf/eth0/rp_filter
Você terá que descobrir como defini-lo permanentemente (por exemplo, echo net.ipv4.conf.eth0.rp_filter=2 > /etc/sysctl.d/90-local-loose-mode.conf se nada mais alterar depois).
Testei usando namespaces com configurações semelhantes às do OP.
NOTA: As solicitações de DNS ainda passarão pelo túnel. Alguns serviços da Web geolocalizados podem não funcionar como esperado.