Histórico:
Eu estabeleço uma conexão com pacotes VPN e NAT de terceiros marcados como parte de um cgroup específico (para executar seletivamente processos através da VPN ou não) ao dispositivo tun da VPN de terceiros (tun2 neste exemplo) e usando um script de roteamento definiu o gateway padrão como sendo o da VPN para uma tabela de rotas separada chamada 'vpn'. Que tudo funciona com o seguinte (alguns detalhes menores são omitidos).
executado na inicialização:
iptables -t mangle -A OUTPUT -m cgroup --cgroup 0x00110011 -j MARK --set-mark 11
iptables -t nat -A POSTROUTING -m cgroup --cgroup 0x00110011 -o tun2 -j MASQUERADE
ip rule add fwmark 11 table vpn
contido no openvpn client.conf:
route-noexec
route-up /etc/openvpn/3rdparty/routeup.sh
e routeup.sh para definir o gateway padrão para a vpn da tabela de rotas
#!/bin/bash
/sbin/ip route replace default via $route_vpn_gateway dev $dev table vpn
Problema:
Se a interface da VPN de terceiros (tun2) cair (por exemplo, falhas de openvpn), não há mais uma rota padrão na tabela de roteamento 'vpn' e todo o tráfego (mesmo o que é executado em meu cgroup separado) é roteado através do principal tabela e através da interface eth0 padrão. Então, eu preciso definir uma rota de fallback no iptables ou na tabela de rotas 'vpn' separada. Se eu usar algo parecido,
iptables -A OUTPUT -m cgroup --cgroup 0x00110011 -o eth0 -j REJECT
ele acaba perdendo todos os pacotes, então é claramente processado antes da entrada nat. Da mesma forma, não consigo encontrar uma maneira de usar 'ip route' para alterar a tabela de rotas para 'vpn', de modo que, uma vez que a entrada do gateway padrão seja removida após a interface tun2 ser descartada, bloqueie todo o tráfego. Em vez disso, não há nenhuma entrada e parece que todo o tráfego vai para a próxima tabela de roteamento, que deve ser principal.
UPDATE: Eu agora tenho uma solução completa para o problema de executar seletivamente o processo através de uma VPN.
link