Conexão VPN quebra o tráfego de entrada

Question

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

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

Então eu tenho uma tabela de rotas principal como esta: %código% e uma tabela de rota ov1 como esta: %código% e regra de IP como esta (eu faço isso significa controlar quem pode usar o túnel VPN): 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

O servidor com o 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 outras não (Meu telefone, verificação de porta on-line ferramenta, etc.).

Em seguida, acompanhei os pacotes usando o tshark (wireshark CLI) em 172.22.34.44, não há tráfego de entrada ao tentar visualizar a web a partir do meu telefone (usando rede celular), mas depois eu SOMENTE precisa adicione manualmente o IP do telefone à tabela de rota ov1 como o servidor ( 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 ), então funciona bem.

O que me deixa confuso é como eu sei , a tabela de rotas disse "Destino" e não "Fonte": 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 Destino ip route add PHONEIP dev ppp0 table ov1 O que deve afetar apenas o tráfego de saída, não esperava que o tráfego de entrada desaparecesse.

Onde está errado?

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

PS.2.1 Kernel IP routing table não tem efeito. PS.2.2 ....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 tem efeito. (Mencionado antes)

PS.3 Algum documento para recomendar?

    

Answer 1

A questão principal parece resolvida usando echo 0 > /proc/sys/net/ipv4/conf/ppp0/rp_filter para desabilitar a verificação do caminho inverso. A tabela de rotas significa destino, não o IP de origem.

Para quem quer saber o que aconteceu, aqui vai 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 DNAT em seguida, use a rota principal porque como qual comando ip rule mostra ( de ALL lookup principal),
172.22.34.44 (: 443) respostas, mas agora roteador agora vai usar a tabela ov1 ( de 172.22.34.44 lookup ov1), tenta enviar este pacote para fora via tap11, e, em seguida, se a verificação de caminho inverso está ligada no roteador,
este pacote será descartado.

Portanto, a melhor solução para o meu problema é adicionar uma interface virtual 172.22.34.45 em 172.22.34.44, depois DNAT para 172.22.34.45.