Esta pergunta é similar a muitos outros que eu consultei enquanto procurava uma resposta, tanto no ServerFault como em outros lugares, mas eu estou presa porque, até onde eu posso ver, configurei isso corretamente, mas não tenho alegria em trabalhar.
Configurei um ambiente simulado usando várias máquinas no VirtualBox, uma representa um servidor (para ser usado como um roteador) e a outra simula dois modems ADSL (apenas se comporta como um roteador NAT com duas portas no lado da LAN e um no lado da WAN para a Internet).
O servidor (SRV) conecta duas portas (ETH2 e ETH3) a duas redes virtuais Vbox separadas através da máquina ADSL (conectando-se às suas portas ETH2 / 3, respectivamente).
+----------+
| SRV |
+----------+
ETH2 (192.168.1.10) | | ETH3 (192.168.2.11)
| |
| |
ETH2 (192.168.1.1) | | ETH3 (192.168.2.1)
+----------+
| ADSL |
+----------+
As portas ADSL são ETH2 (192.168.1.1) e ETH3 (192.168.2.1).
As portas SRV são ETH2 (192.168.1.10) e ETH3 (192.168.2.11).
SRV iptables não faz nada de interesse, além de ver os comentários abaixo sobre os ajustes na rota padrão main durante o teste.
ip route show
default via 192.168.1.1 dev eth2
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.10
192.168.2.0/24 dev eth3 proto kernel scope link src 192.168.2.11
192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.1
192.168.13.0/24 dev admin.tinc proto kernel scope link src 192.168.13.1
Configure duas tabelas adsl1 e ads2
ip route show table adsl1
default via 192.168.1.1 dev eth2
192.168.1.0/24 dev eth2 scope link src 192.168.1.10
ip route show table adsl2
default via 192.168.2.1 dev eth3
192.168.2.0/24 dev eth3 scope link src 192.168.2.11
ip rule
0: from all lookup local
32762: from all to 192.168.1.0/24 lookup adsl1
32763: from all to 192.168.2.0/24 lookup adsl2
32764: from 192.168.2.0/24 lookup adsl2
32765: from 192.168.1.0/24 lookup adsl1
32766: from all lookup main
32767: from all lookup default
Se eu fizer ping via ETH2, não há problema.
ping -I eth2 -c 1 google.com
PING google.com (216.58.214.14) from 192.168.1.10 eth2: 56(84) bytes of
data.
64 bytes from lhr26s05-in-f14.1e100.net (216.58.214.14): icmp_seq=1 ttl=61
time=20.2 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.288/20.288/20.288/0.000 ms
Se eu fizer ping via ETH3, não haverá tráfego no ETH3.
PING google.com (216.58.213.110) from 192.168.2.11 eth3: 56(84) bytes of
data.
--- google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Se eu alterar o gateway padrão da tabela main ...
ip route replace default via 192.168.2.1 dev eth3
ocorre o inverso (o ETH3 funciona, o ETH2 falha). Na minha opinião, isso sugere que as tabelas de roteamento adsl1 e adsl2 estão erradas ou simplesmente não estão sendo consultadas (regras estão erradas). Mas não consigo descobrir por quê?
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.eth2.rp_filter=0
sysctl -w net.ipv4.conf.eth2.rp_filter=0
Repetido ping -I eth3 google.com enquanto ...
tcpdump -i eth3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
20:26:32.207178 ARP, Request who-has lhr35s11-in-f14.1e100.net tell 192.168.2.11, length 28
20:26:33.221587 ARP, Request who-has lhr35s11-in-f14.1e100.net tell 192.168.2.11, length 28
Quando o ETH3 é definido como rota padrão em main (nenhuma outra alteração), o tcpdump é:
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
21:41:51.865488 IP (tos 0x0, ttl 64, id 31173, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.11 > google-public-dns-a.google.com: ICMP echo request, id 2962, seq 1, length 64
21:41:51.866542 IP (tos 0x0, ttl 64, id 18679, offset 0, flags [DF], proto UDP (17), length 71)
192.168.2.11.36067 > one.one.one.one.domain: [bad udp cksum 0xc4f9 -> 0xb220!] 31965+ PTR? 11.2.168.192.in-addr.arpa. (43)
21:41:51.885947 IP (tos 0x0, ttl 61, id 4776, offset 0, flags [DF], proto ICMP (1), length 84)
google-public-dns-a.google.com > 192.168.2.11: ICMP echo reply, id 2962, seq 1, length 64
ip route get 8.8.8.8 oif eth3
8.8.8.8 dev eth3 src 192.168.2.11
cache users 1
Então, definitivamente algo danificado com roteamento (ao invés de problemas em outros lugares). Também explica a presença singular de ARP !
Ok!
Parece que quando o tráfego é direcionado para a interface ETH3, não é atribuído um endereço 'de' de 192.168.2.11 , como esperado, pelo menos não a tempo para a decisão do db da diretiva de roteamento.
Eu adicionei manualmente uma regra simples:
ip rule add to 8.8.8.8 lookup adsl2
Então
ip route get 8.8.8.8 oif eth3
8.8.8.8 via 192.168.2.1 dev eth3 table adsl2 src 192.168.2.11
cache
Evidentemente, a tabela adsl2 está sendo usada e define corretamente o via 192.168.2.1 . Viva!
MAS se eu substituir essa regra pela regra mais específica
ip rule add to 8.8.8.8 from 192.168.2.11 lookup adsl2
Eu obtenho
ip route get 8.8.8.8 oif eth3
8.8.8.8 dev eth3 src 192.168.2.11
cache
Volta para o estado em que via não está definido, conclusão: adsl2 table não está sendo usada. Conclusão adicional: from não é efetivo, então interface eth3 não definindo endereço src para 192.168.2.11 apesar de ip a mostrando
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:e5:7e:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.2.11/24 brd 192.168.2.255 scope global eth3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fee5:7eeb/64 scope link
valid_lft forever preferred_lft forever
Onde eu estraguei tudo?