Estou configurando um host que tem duas rotas para a Internet pública: uma através do meu roteador de gateway doméstico comum, a outra através de um roteador de gateway em uma rede semi-privada (AMPRNet em 44.0. 0,0 / 8). A maior parte disso é direta, mas há um truque:
Principalmente o IP 44.x.x.1 é usado para comunicação com outros hosts em 44.0.0.0/8. Isso é fácil para rotear pacotes de saída para a interface de túnel (tunl0) configurada para o propósito.
Os hosts na Web pública podem também alcançar meu IP semi-privado (44.x.x.1) por meio de um roteador de gateway no UCSD (169.228.66.251) que anuncia o 44.0.0.0/8 no BGP. As respostas a esses pacotes do meu nó, no entanto, acabam saindo da eth0 de volta para o host de origem, o que não funciona porque elas ficam NATed ao longo do caminho pelo meu roteador de gateway.
O que eu acho que preciso fazer é usar o iptables para enviar pacotes SNAT no tunl0 de hosts não-44.0.0.0 / 8 para um IP fictício no espaço 44.0.0.0/8, e DNAT-los no caminho de volta usando rastreamento de conexão com estado. Isso, no entanto, não parece estar funcionando.
Depois de executar
iptables -t nat -A INPUT -s 44.0.0.0/32 -d 44.x.x.1 -j ACCEPT
iptables -t nat -A INPUT -s 0.0.0.0 -d 44.x.x.1 -j SNAT --to 44.0.0.2
quando faço ping em 44.x.x.1 de um host remoto, o tcpdump na interface tunl0 mostra pacotes do IP externo real, não a partir de 44.0.0.2. E se eu tcpdump eth0, eu vejo os pacotes de resposta voltando para aquele IP externo.
Esta configuração é possível? Se sim, o que me falta?
Como enviar pacotes provenientes de um segundo roteador em uma porta específica de volta ao roteador, usando iptables não uma rota parece estar relacionado.
EDIT: adicionando mais alguns detalhes da rede
pi@raspberrypi ~ $ ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:3b:93:ba
inet addr:192.168.3.192 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14477 errors:0 dropped:0 overruns:0 frame:0
TX packets:6131 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4475095 (4.2 MiB) TX bytes:1651639 (1.5 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tunl0 Link encap:IPIP Tunnel HWaddr
inet addr:44.x.x.1 Mask:255.255.255.255
UP RUNNING NOARP MULTICAST MTU:1480 Metric:1
RX packets:424 errors:0 dropped:0 overruns:0 frame:0
TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:176191 (172.0 KiB) TX bytes:836 (836.0 B)
pi@raspberrypi ~ $ sudo ip route
default via 192.168.3.1 dev eth0
192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.192
pi@raspberrypi ~ $ sudo ip rule
0: from all lookup local
44: from all to 44.0.0.0/8 lookup 44
45: from 44.x.x.0/28 lookup 44
32766: from all lookup main
32767: from all lookup default
pi@raspberrypi ~ $ sudo ip route show table 44 | head
44.0.0.1 via 169.228.66.251 dev tunl0 onlink window 840
44.2.2.0/24 via 157.130.198.190 dev tunl0 onlink window 840
44.2.10.0/29 via 71.130.72.52 dev tunl0 onlink window 840
44.2.14.0/29 via 50.79.156.221 dev tunl0 onlink window 840
44.2.50.0/29 via 68.189.35.197 dev tunl0 onlink window 840
44.4.2.152/29 via 173.167.109.217 dev tunl0 onlink window 840
44.4.10.40 via 69.12.138.16 dev tunl0 onlink window 840
44.4.22.198 via 67.161.9.80 dev tunl0 onlink window 840
44.4.22.200 via 50.136.207.176 dev tunl0 onlink window 840
44.4.28.50 via 50.79.209.150 dev tunl0 onlink window 840
...
Welp, parece que a resposta foi bem simples, afinal de contas:
ip route add default dev tunl0 via 169.228.66.251 onlink table 44
Os pacotes entram em uma interface específica, então as respostas voltam para a mesma interface. O tunl0 é o roteamento através da tabela 44, então com uma rota padrão na tabela 44, estamos prontos.
Tags networking iptables routing