Conexão VPN interrompe o tráfego de entrada

Eu tenho um servidor com (66.66.66.66) (não é o IP real, é claro), e minha rede doméstica também tem um IP público (202.202.122.123).

Depois de me conectar ao servidor do roteador (172.22.34.1) usando VPN (tecnicamente OpenVPN, isso não deve importar) para proxy,

Então eu tenho uma tabela de rota principal como esta: 202.202.122.1 dev ppp0 proto kernel scope link 172.22.34.0/24 dev br0 proto kernel scope link src 172.22.34.1 10.12.12.0/24 dev tap11 proto kernel scope link src 10.12.12.2 default via 202.202.122.1 dev ppp0 e uma tabela de rota ov1 como esta: 172.22.34.0/24 dev br0 scope link 66.66.66.66/32 via 202.202.122.1 dev ppp0 0.0.0.0/1 via 10.12.12.1 dev tap11 128.0.0.0/1 via 10.12.12.1 dev tap11 e regra de ip como esta (eu faço isso para controlar quem pode usar o túnel da VPN): 0: from all lookup local 32764: from 172.22.34.101 lookup ov1 32765: from 172.22.34.44 lookup ov1 32766: from all lookup main 32767: from all lookup default

O servidor com IP 66.66.66.66 pode exibir a web HTTPS hospedada em casa (202.202.122.123:443 DNAT para 172.22.34.44:443), mas outros não (Meu telefone, ferramenta de verificação de porta on-line etc.).

Em seguida, rastreei pacotes usando o tshark (CLI do wireshark) em 172.22.34.44, não há tráfego de entrada ao tentar visualizar a Web do meu telefone (usando rede celular), mas depois que eu SOMENTE preciso adicionar manualmente o IP do telefone à tabela de rotas ov1 como o servidor ( ip route add PHONEIP dev ppp0 table ov1), então funciona bem.

O que me deixa confusa é que, como sei , a tabela de rotas diz "Destino" e não "Origem": Kernel IP routing table Destino....Gateway Genmask Flags Metric Ref Use Iface 202.202.122.1 * 255.255.255.255 UH 0 0 0 ppp0 172.22.34.0 * 255.255.255.0 U 0 0 0 br0 10.12.12.0 * 255.255.255.0 U 0 0 0 tap11 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 202.202.122.1 0.0.0.0 UG 0 0 0 ppp0 Que deve afetar apenas o tráfego de saída, eu não esperava que o tráfego de entrada desaparecesse.

Onde esta errado?

PS.1 Quando del 172.22.34.44 da regra ip, para fazê-lo usar a tabela de rotas principal, também funciona bem.

O PS.2.1 ip route add 0.0.0.0/0 dev ppp0 table ov1não tem efeito, o que o
PS.2.2 ip route add PHONEIP dev ppp0 table ov1tem efeito. (Mencionado anteriormente)

PS.3 Existem documentos a recomendar?

A questão principal parece resolvida usando-se echo 0 > /proc/sys/net/ipv4/conf/ppp0/rp_filterpara desativar a verificação do caminho reverso. A tabela de rotas significa realmente o destino, não o IP de origem.

Para quem se pergunta o que aconteceu, aqui está uma explicação rápida.

Quando um IP de 0.0.0.0/0(equals 0.0.0.0/1 + 128.0.0.0/1 na tabela de rotas ov1) via ppp0 (eth0) tenta conectar 202.202.122.123:443, o
roteador irá DNAT,
e usará a rota principal porque, como o ip rulecomando mostra ( da ALL pesquisa principal),
respostas 172.22.34.44 (: 443),
mas agora o roteador agora usa a tabela ov1 ( da pesquisa ov1 172.22.34.44),
tenta enviar este pacote via tap11 e, em
seguida , inverte Se a verificação de caminho estiver ativada no roteador,
este pacote será descartado.

Portanto, a melhor solução para o meu problema é para adicionar uma interface virtual 172.22.34.45 em 172.22.34.44 e, em seguida, DNAT para 172.22.34.45. use fwmark e priorize-o sobre a regra 172.22.34.44 e DISABLE RP_FILTER.