Com o conjunto de rotas padrão, a VM ubuntu recebe um pacote em eth1 (de 192.168.1.15: ping 192.168.7.100). Será:
- descarta o pacote por causa da filtragem de caminho reverso: pacote recebido em uma interface onde não há rota para a origem deste pacote.
- responda pela eth0 porque 192.168.1.15 corresponde à rota padrão via 192.168.1.253 em eth0
O comportamento depende dos valores de /proc/sys/net/ipv4/conf/{all,eth1}/rp_filter
, mas a queda é o padrão: todos / rp_filter = 1 e eth1 / rp_filter = 1
No caso em que não é descartado: o roteador ERL3 vê um pacote de resposta de 192.168.1.7.100 que deve estar em lan-mgmt, mas transita de lan-dmz. Dependendo das configurações, talvez descritas na configuração do seu roteador, você escreveu, mas eu não sei:
- irá diminuir, mais ou menos pela mesma razão que o ubuntu o soltar quando o rp_filter estiver ativado: a rota para ele é em outro lugar
- aceitará mesmo assim.
Vamos considerar que o ERL3 o aceita. Então a "correção" é simples: menor segurança no Ubuntu, desabilitando a filtragem de caminho reverso:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
ref: link (rp_filter)
(a maneira como está funcionando, a eth0 permanece protegida, mas isso é irrelevante aqui)
Tente primeiro, se funcionar, problema resolvido. Considere substituir os dois echo 0
por echo 2
apenas pela eth1 (modo solto). Mas considere que isso ainda é um problema: o roteamento assimétrico pode criar outros problemas, especialmente com o firewall.
Se o roteador ERL3 estiver filtrando também (isto é: acima não funcionou): o ubuntu deve estar ciente da existência do 192.168.1.0/24 para ambas as interfaces e usar as configurações table
e rule
para uma correta roteamento. Isso é um pouco difícil de explicar por que, além de como, aqui está uma referência, que não é exatamente para este caso, mas pode ser baseada principalmente em (o que eu fiz aqui):
ref: link
Eu escolhi as tabelas arbitrárias 7 e 67 para corresponder a 192.168.7.0/24 e 192.168.67.0/24. Comece pelas rotas vazias (ao lado das rotas lan locais criadas automaticamente) e:
ip route add 192.168.67.0/24 dev eth0 src 192.168.67.100 table 67
ip route add default via 192.168.67.253 table 67
ip route add 192.168.7.0/24 dev eth1 src 192.168.7.100 table 7
ip route add 192.168.1.0/24 via 192.168.7.253 table 7 #enable only LAN to have a route to access MGMT. Feel free to replace 192.168.1.0/24 with default, you have a firewall too.
Eu não sei se isso é realmente necessário, mas isso está na documentação, então ...:
ip route add 192.168.7.0/24 dev eth1 src 192.168.7.100
ip route add 192.168.67.0/24 dev eth0 src 192.168.67.100
Sua rota padrão permanece a mesma, aqui novamente na sintaxe de ip route
:
ip route add default via 192.168.67.253
E a parte realmente importante que conta para usar a interface certa:
ip rule add from 192.168.67.100 table 67
ip rule add from 192.168.7.100 table 7
Nota final: certifique-se de que o ubuntu não faz o roteamento, senão um host DMZ comprometido pode tentar gerenciar um outro através do Ubuntu:
echo 0 > /proc/sys/net/ipv4/conf/default/forwarding
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding