Eu tenho uma conexão a cabo com um roteador baseado em Linux. O roteador tem duas interfaces físicas:
enp1s0 (dhcp from cable provider)
enp2s0 (192.168.1.1)
com mascaramento em enp1s0. então, eu tenho uma conexão com o cliente OpenVPN:
tun0 (10.0.0.4)
Mais uma vez, com o mascaramento neste dispositivo. A tabela de roteamento regular não tem entradas apontando para este dispositivo, mas eu tenho uma tabela de roteamento adicional:
vpn-clients
para que eu possa adicionar uma rota padrão usando este dispositivo:
ip route add default via 10.0.0.1 dev tun0 table vpn-clients
e, em seguida, especificar por cliente qual tabela usar:
ip rule add from 192.168.1.200 lookup vpn-clients
ip rule add from 192.168.1.201 lookup vpn-clients
...
e encaminhamento de porta no tun0:
/sbin/iptables -t nat -A PREROUTING -i tun0 -p udp --dport 5555 -j DNAT --to-destination 192.168.1.200:5555
Parece que está funcionando (pelo menos para conexões de saída). Todo o tráfego dos clientes que são roteados por origem parece ser roteado por meio da VPN.
Agora, as conexões de entrada são uma história totalmente diferente. Eu costumava ter cargas e cargas de marcianos logados.
Percebi que isso pode ser causado pela combinação de roteamento de origem, encaminhamento de porta e mascaramento, isto é, o kernel pode não estar ciente de que o destino de um pacote recebido será modificado e, em vez disso, assume que o 10.0.0.4 é o destino final, o que seria impossível, porque não há nenhuma rota definida que explique as coisas que chegam para este destino de qualquer coisa, mas é própria sub-rede.
Então, eu adicionei uma rota um tanto falsa:
ip rule lookup from 10.0.0.4 lookup vpn-clients
para que a "tabela de roteamento" para essa interface se torne "vpn-clients", que tem uma rota padrão apontando nessa direção.
Isso impediu que os marcianos estivessem logados & desistiu. Conexões de entrada estão funcionando bem agora. É este o caminho "correto", embora? Seria possível melhorar isso?