Problema de roteamento da interface eth1 interna para uma interface ppp0 externa

Question

Estou tentando conectar duas LANs usando um link ppp. Eu tinha um diagrama básico de topologia de rede, mas não saiu bem. Isso pode ser visto aqui .

Routing Problem
================


172.20.0.0/16                                 192.168.2.0/24
              eth1  +-----------------+ eth0                                                  
  172.20.0.1 |======|      Ubuntu     |======| 192.168.2.231
                    |                 |
                    |      Router     |======| 192.168.254.253    192.168.254.254 |=====> To: 172.30.0.0/16
                    +-----------------+ ppp0

Todos os computadores na sub-rede 172.20.0.0/16 podem acessar a Internet via eth0. Todos os dispositivos na sub-rede 172.20.0.0/16 usam o 172.20.0.1 como seu gateway. Quando faço ping em qualquer dispositivo na sub-rede 172.30.0.0/16 de um dispositivo na sub-rede 172.20.0.0/16, vejo que nada está passando de eth1 para ppp0. A maneira como testei isso foi fazendo ping de um dispositivo na sub-rede 172.20.0.0/16 ( ping -s 10240 172.30.0.9 ) e verificando todas as três interfaces no roteador usando tcpdump ( tcpdump -vv -x -X -s 1500 -i eth1 ). Eu não estou vendo nenhum pacote ICMP em nenhuma dessas interfaces. Eu suspeito que o problema é com o iptables.

As configurações no Ubuntu Router são assim:

ip route show
default via 192.168.2.1 dev eth0 
172.20.0.0/16 dev eth1  proto kernel  scope link  src 172.20.0.1 
172.30.0.0/16 dev ppp0  scope link 
172.30.0.0/16 via 192.168.250.254 dev ppp0 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.231 
192.168.250.254 dev ppp0  proto kernel  scope link  src 192.168.250.253


cat /proc/sys/net/ipv4/ip_forward 
1
cat /proc/sys/net/ipv4/conf/ppp0/forwarding 
1
cat /proc/sys/net/ipv4/conf/eth0/forwarding
1
cat /proc/sys/net/ipv4/conf/eth1/forwarding
1


iptables --list-rules
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -j ACCEPT
-A FORWARD -i eth1 -o ppp0 -j ACCEPT
-A FORWARD -i ppp0 -o eth1 -j ACCEPT

iptables -t nat --list-rules
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -d 192.168.250.254/32 -j DNAT --to-destination 172.30.0.1
-A POSTROUTING -o eth1 -j SNAT --to-source 172.20.0.1

Devo acrescentar que tentei muitas combinações diferentes de regras iptables, além de tentar diferentes opções de roteamento.

    

Answer 1

Primeiro, as regras de filtragem são de alguma forma redundantes. Quando você nunca cai e sua política é ACEITAR, adicionar mais algumas regras de ACEITAR não tem sentido. Nenhum pacote será filtrado.

The way I tested this was by pinging from a device on the 172.20.0.0/16 subnet( ping -s 10240 172.30.0.9 )

Eu nunca tentei enviar grandes blocos de ping de 10kByte através de uma rede e eu não sei porque você faz isso, mas um pacote padrão de ping de 56 bytes deve funcionar perfeitamente, para verificar a conexão e não sofrer fragmentação de MTU questões.

and checking all three interfaces on the router using tcpdump( tcpdump -vv -x -X -s 1500 -i eth1 ).

É claro que quando você verifica com tcpdump -i eth1 ... você verifica apenas eth1 , mas isso é trivial.

Como não existe uma regra de filtragem, não deve haver nenhum problema com o iptables. Pelo menos deve haver alguma entrada em alguma interface.

Você verificou o seu roteiro de onde você enviou o seu ping?

Eu não entendo a ideia por trás da regra

-A PREROUTING -d 192.168.250.254/32 -j DNAT --to-destination 172.30.0.1

Em palavras, pacotes que são endereçados para 192.168.250.254, então todos os pacotes que de alguma forma querem sair através de ppp0, serão reescritos para ir para 172.30.0.1, que deve ser ppp0 também (não está claro!). Posteriormente no estágio de roteamento, qualquer pacote que vá para a sub-rede ppp0 172.30.0.0/16 será roteado para 192.168.250.254. Esta regra parece inútil para mim, se não destrutiva.

Quando você envia pacotes para 172.30.0.9 ou qualquer 172.30.0.0/16, talvez queira -j MASQUERADE quando eles saírem, que o destino saiba para onde responder, embora não saiba como rotear.

'iptables -t nat -A POSTROUTING -s 172.20.0.0/16 -i ppp0 -j MASQUERADE'

Mas isso não resolverá o problema de você não ver nenhum pacote de ping em qualquer interface do seu roteador.

Minha primeira tentativa seria ver os pacotes de ping saindo do sistema do qual eu os enviei, com o tcpdump no sistema.

'tcpdump -i eth0 'icmp'

ou apenas pacotes que devem ser sobre ppp0

'tcpudmp -i eth0 'net 172.30.0.0/16'

assumindo que os hosts 172.20.0.0/16, que não são seu roteador, tenham apenas uma interface chamada eth0.