Roteador Linux com 4 NICs não funcionando

2

Estou configurando um roteador baseado em Linux, com 4 NICs, e não consigo convencê-lo a funcionar, apesar das etapas sugeridas em vários sites.

Cada interface está em uma sub-rede separada, como segue:

eth0 10.1.0.254 (255.255.255.0)
eth1 10.1.1.254 (255.255.255.0)
eth2 10.1.2.254 (255.255.255.0)
eth3 10.1.3.254 (255.255.255.0)

Cada dispositivo em cada rede é configurado para usar 10.1. x .254 como o gateway na rede local.

Eu habilitei o encaminhamento de IP (e também o tornei permanente em /etc/sysctl.conf )

$ cat /proc/sys/net/ipv4/ip_forward
1

E a tabela de roteamento parece correta

$ route
Kernel IP routing table
Destination     Gateway    Genmask         Flags Metric Ref    Use Iface
localnet        *          255.255.255.0   U     0      0        0 eth0
10.1.1.0        *          255.255.255.0   U     0      0        0 eth1
10.1.2.0        *          255.255.255.0   U     0      0        0 eth2
10.1.3.0        *          255.255.255.0   U     0      0        0 eth3

Interfaces

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:8d:xx:xx:xx
          inet addr:10.1.0.254  Bcast:10.1.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28919 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16132 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:35054376 (35.0 MB)  TX bytes:1424175 (1.4 MB)
          Interrupt:22

eth1      Link encap:Ethernet  HWaddr 00:1b:21:xx:xx:xx
          inet addr:10.1.1.254  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:480 (480.0 B)  TX bytes:3996 (3.9 KB)

eth2      Link encap:Ethernet  HWaddr 00:1b:21:xx:xx:xx
          inet addr:10.1.2.254  Bcast:10.1.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1024 (1.0 KB)  TX bytes:4122 (4.1 KB)

eth3      Link encap:Ethernet  HWaddr 00:1b:21:xx:xx:xx
          inet addr:10.1.3.254  Bcast:10.1.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6419 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6702 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:701177 (701.1 KB)  TX bytes:612622 (612.6 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1753 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1753 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:194373 (194.3 KB)  TX bytes:194373 (194.3 KB)

Um PC conectado à rede 10.1.1.0/24 (com um endereço IP de 10.1.1.1, gateway configurado corretamente como 10.1.1.254), pode fazer ping na interface local do roteador Linux, mas nenhum dos outros 3 interfaces do roteador no gateway.

Eu não tenho nenhum firewall (hardware ou software) nesta configuração de rede.

Eu estou sentindo falta de algo fundamental?

Editar 1

No PC 10.1.1.1, agora posso fazer o ping de todas as interfaces no roteador, exceto uma, que é 10.1.0.254. (Não tenho certeza do que fiz para consertar isso!)

Todas as sub-redes envolvidas são hospedadas por um número de switches da camada 3 como VLANs. A interface no roteador Linux que não está respondendo é a única VLAN que tem uma interface de roteamento no nosso switch principal.

tcpdump on eth1 não mostra nenhum sinal de eco ICMP quando tento acessar essa interface, apesar de 10.1.1.1 estar configurado para usar 10.1.1.254 (eth1 no roteador Linux).

Poderia ser protocolos de roteamento transmitidos do switch que estão fazendo com que o PC no 10.1.1.1 não seja roteado via 10.1.1.254?

Editar 2

Enquanto estou trabalhando em outra coisa, agora volto a isso (sem alterar nada no roteador Linux) e ele parou de funcionar novamente.

Editar 3

Configuração do iptables

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination    
    
por Bryan 07.05.2011 / 14:21

3 respostas

2

Do que você descreve, deve funcionar. Se você puder fazer o ping da interface do gateway na mesma rede, mas não puder fazer o ping em nenhuma outra interface, isso é muito estranho. A pilha TCP / IP deve responder corretamente ao ping para a interface A, mesmo se recebida pela interface B.

Como você está pingando o endereço local do gateway (embora em uma rede diferente), nenhum encaminhamento de pacote está envolvido. Eu vejo três razões possíveis:

1) O gateway não recebeu o pacote (problema de roteamento / fileterização no cliente).

2) O gateway não enviou a resposta para o local correto.

3) O gateway optou por não responder (algum tipo de firewall. Eu iria verificar isso, só para ter certeza que não é o caso).

Eu usaria o tcpdump ou o wireshark para ter certeza do que está acontecendo no fio. Você deve ver solicitações de ping saindo do cliente. Então, na interface do gateway, você deve vê-los chegando. Então eu ouvia em todas as interfaces para ver se alguma resposta é enviada em qualquer lugar. Se você vir uma solicitação de ping chegando, o roteamento será OK no lado do cliente. Se você não vir a resposta ping saindo de qualquer interface, então é um firewall ou alguma estranheza acontecendo com as tabelas de roteamento no gateway. Finalmente, se o gateway envia a resposta pela interface correta e não se registra no cliente, é culpa do cliente.

Eu tentaria um dispositivo em alguma outra rede (por exemplo, 10.1.3.0/24), de preferência conectado diretamente à placa de rede do servidor para ter certeza de que nada interfere na comunicação. Pode ser apenas um erro de digitação, que é diabolicamente difícil de ver se você sabe o que deve ver. Configurar outro dispositivo (ou reconfigurar o PC usado para o primeiro teste) torna menos provável que você faça o erro de digitação novamente.

E a última pergunta - alguma vez funcionou, ou é uma nova caixa configurada e inserida na rede?

Editar:

Desde que você não tenha ativado nenhum daemon de roteamento na caixa Linux, ele ignorará o tráfego do roteador de seus switches.

O que você observa strongmente indica alguma influência externa (switches, firewalls, alienígenas ou um interno bloqueado no NOC;)). Tente testar a configuração com dois clientes conectados diretamente à caixa do Linux, assim:

           +-------------+
client1 ---+ ethX   ethY +--- client2
           +-------------+
              Linux box

Neste roteiro de teste de configuração na caixa Linux entre todas as interfaces. Caso contrário, você estará lutando em várias frentes ao mesmo tempo e isso reduz as chances de solução de problemas bem-sucedida. Depois que você souber que a caixa do Linux funciona (ou não é), será hora de procurar por motivos de interferência observada.

Se você tiver switches inteligentes conectados a todas as interfaces da sua caixa Linux, você pode definir um endereço IP na porta diretamente conectada à caixa Linux e tentar fazer o ping entre a caixa e o roteador. Eu, sendo um paranóico suspeito, levaria meu próprio laptop para a caixa junto com um punhado de patch cords conhecidos para ver o que está acontecendo.

    
por 07.05.2011 / 16:00
1

Provavelmente uma pergunta idiota, mas ... você está dizendo que não tem firewall nesta rede, mas tem certeza absoluta disso?

O Linux tem seu firewall habilitado por padrão, portanto, mesmo que você habilite o encaminhamento de IP, ele não deixará nenhum pacote passar se você não configurar explicitamente o IPTABLES para ele (ou desativar o firewall).

O mesmo vale para os seus PCs, é claro: sejam eles Linux ou Windows, eles terão um firewall embutido, que por padrão estará ativo, a menos que você desabilite-o explicitamente.

    
por 07.05.2011 / 18:53
0

As regras do Iptables permitem o encaminhamento?

iptables -L -n -v

    
por 07.05.2011 / 16:18