Ubuntu Ignorando pacotes da rede A em eth0 quando eth4 configurado na rede A

Question

Eu tenho um servidor Ubuntu 12.04 (beta final, atualizado) com duas interfaces de rede configuradas:

root@mac:/home/sysadm# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1e:4f:28:fd:7b
          inet addr:172.18.8.10  Bcast:172.18.8.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:4fff:fe28:fd7b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3362 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8561 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:273506 (273.5 KB)  TX bytes:3174766 (3.1 MB)
          Interrupt:38 Memory:dc000000-dc012800

eth4      Link encap:Ethernet  HWaddr 00:02:c9:09:a4:c8
          inet addr:xxx.yy.4.235  Bcast:xxx.yy.5.255  Mask:255.255.254.0
          inet6 addr: fe80::202:c9ff:fe09:a4c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:59277 errors:0 dropped:52 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5138237 (5.1 MB)  TX bytes:6462 (6.4 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1412 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1412 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:107356 (107.3 KB)  TX bytes:107356 (107.3 KB)

root@mac:/home/sysadm# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.18.8.254    0.0.0.0         UG    100    0        0 eth0
xxx.yy.4.0      0.0.0.0         255.255.254.0   U     0      0        0 eth4
172.18.8.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0

Como você pode ver, eth0 está na rede 172.18.8.0/24 ("8-net") e eth4 está na rede xxx.yy.4.0 / 23 ("4-net"). Ambas as redes estão conectadas através de um roteador. Muitas máquinas estão em ambas as redes (uma de cada vez) e são capazes de se comunicar sem problemas. Quando uma segunda máquina na rede 4 tenta falar com 172.18.8.10, os pacotes parecem ter sido descartados. Um tcpdump de uma tentativa de SSH está abaixo:

root@mac:/home/sysadm# ufw allow from any to any port 1022
Rule added
Rule added (v6)
root@mac:/home/sysadm# sshd -de -p 1022
sshd re-exec requires execution with an absolute path
root@mac:/home/sysadm# which sshd
/usr/sbin/sshd
root@mac:/home/sysadm# /usr/sbin/sshd -de -p 1022
debug1: sshd version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: read PEM private key done: type ECDSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-de'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='1022'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 1022 on 0.0.0.0.
Server listening on 0.0.0.0 port 1022.
debug1: Bind to port 1022 on ::.
Server listening on :: port 1022.
^Z
[1]+  Stopped                 /usr/sbin/sshd -de -p 1022
root@mac:/home/sysadm# bg
[1]+ /usr/sbin/sshd -de -p 1022 &
root@mac:/home/sysadm# tcpdump -nvlli eth0 'host xxx.yy.4.29'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:16:33.370081 IP (tos 0x0, ttl 63, id 29087, offset 0, flags [DF], proto TCP (6), length 60)
    xxx.yy.4.29.42667 > 172.18.8.10.1022: Flags [S], cksum 0xdc29 (correct), seq 107513294, win 14600, options [mss 1460,sackOK,TS val 3473994833 ecr 0,nop,wscale 7], length 0
18:16:36.369860 IP (tos 0x0, ttl 63, id 29088, offset 0, flags [DF], proto TCP (6), length 60)
    xxx.yy.4.29.42667 > 172.18.8.10.1022: Flags [S], cksum 0xd071 (correct), seq 107513294, win 14600, options [mss 1460,sackOK,TS val 3473997833 ecr 0,nop,wscale 7], length 0
18:16:42.369300 IP (tos 0x0, ttl 63, id 29089, offset 0, flags [DF], proto TCP (6), length 60)
    xxx.yy.4.29.42667 > 172.18.8.10.1022: Flags [S], cksum 0xb901 (correct), seq 107513294, win 14600, options [mss 1460,sackOK,TS val 3474003833 ecr 0,nop,wscale 7], length 0

Para completar:

root@mac:/home/sysadm# ufw status
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
1022                       ALLOW       Anywhere
22                         ALLOW       Anywhere (v6)
1022                       ALLOW       Anywhere (v6)

O nó que faz a conexão experimenta um tempo limite. Outros protocolos também são afetados. O eco solicita tempo limite. No entanto, os nós na rede 8 e todas as outras redes que não são a rede 4 são capazes de se comunicar sem falhas. Logs não mostram nada. Outras entradas do "UFW BLOCK" existem em / var / log / syslog mas não existem relevantes.

Em suma, uma máquina tem duas interfaces, eth0 na rede 8 e eth4 na rede 4. Outros nós da rede 4 não podem se comunicar com eth0, mas nós de todas as outras redes podem. O oposto lógico também se aplica: nós da rede 8 tentando falar com timeouts de experiência da eth4. Isso é um recurso ou um erro? Eu não deveria esperar poder falar com a interface logicamente errada em uma máquina com duas interfaces?

Se for importante, este é um Dell PowerEdge R900. eth0 é uma porta integrada "NetXtreme II BCM5708 Gigabit Ethernet" e eth4 é uma das duas portas em uma placa adicional "MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT / s]" da Mellanox Technologies.

EDITAR: O problema persiste quando o firewall está desativado. O tcpdump ainda mostra pacotes chegando (solicitações de eco) sem nenhuma resposta sendo enviada.

EDIT: Mais saída: Este é um dump do tráfego eth4 envolvendo o host remoto 'xxx.aa.4.29'. De xxx.yy.4.29, eu pingado 172.18.8.10 e xxx.yy.4.235. Esta é a saída.

root@mac:/home/sysadm# tcpdump -nvlli eth4 'host xxx.yy.4.29'
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes
20:25:04.401449 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has xxx.yy.4.235 tell xxx.yy.4.29, length 46
20:25:04.401492 ARP, Ethernet (len 6), IPv4 (len 4), Reply xxx.yy.4.235 is-at 00:02:c9:09:a4:c8, length 28
20:25:04.401647 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    xxx.yy.4.29 > xxx.yy.4.235: ICMP echo request, id 32312, seq 1, length 64
20:25:04.401706 IP (tos 0x0, ttl 64, id 42264, offset 0, flags [none], proto ICMP (1), length 84)
    xxx.yy.4.235 > xxx.yy.4.29: ICMP echo reply, id 32312, seq 1, length 64
20:25:05.401200 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    xxx.yy.4.29 > xxx.yy.4.235: ICMP echo request, id 32312, seq 2, length 64
20:25:05.401211 IP (tos 0x0, ttl 64, id 42265, offset 0, flags [none], proto ICMP (1), length 84)
    xxx.yy.4.235 > xxx.yy.4.29: ICMP echo reply, id 32312, seq 2, length 64
20:25:09.402234 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has xxx.yy.4.29 tell xxx.yy.4.235, length 28
20:25:09.402383 ARP, Ethernet (len 6), IPv4 (len 4), Reply xxx.yy.4.29 is-at 78:2b:cb:90:95:98, length 46
20:25:09.402747 ARP, Ethernet (len 6), IPv4 (len 4), Reply xxx.yy.4.29 is-at 78:2b:cb:90:95:98, length 46

EDIT: Esta é apenas uma máquina de teste. Não consigo imaginar um cenário do mundo real em que precise rotear a comunicação de 8 redes pela interface de 4 redes. Eu posso ver como isso seria um problema conhecido em que o benefício de uma solução não vale o esforço de resolver o problema.

    

Answer 1

O que você provavelmente está vendo aqui é filtragem de caminho inverso . O kernel está descartando pacotes porque eles parecem vir da interface "errada". Para verificar se o RPF está ativado, execute cat /proc/sys/net/ipv4/conf/eth0/rp_filter (e da mesma forma para eth4). Para desativá-lo, efetue o eco 0 nesses arquivos.

Mesmo com o RPF desabilitado, seu roteamento será um pouco estranho, como disse @NathanG (os pacotes de resposta irão sair de uma interface diferente da que eles acessaram). Se os seus roteadores não forem muito inteligentes (ou seja, não tiverem RPF ou outra proteção contra falsificação), isso ainda deve funcionar.

O que você precisa para configurar isso corretamente é algum roteamento de políticas com base no endereço de origem (ou seja, informe o kernel para rotear os pacotes de maneira diferente com base no seu endereço de origem). Fazemos isso configurando várias tabelas de roteamento e adicionando algumas regras para selecionar qual tabela usar.

Primeiro, nomeie algumas tabelas (você só precisa fazer isso uma vez).

echo "14 net4" >> /etc/iproute2/rt_tables
echo "18 net8" >> /etc/iproute2/rt_tables

Em seguida, adicione rotas a essas novas tabelas (suponho que esta máquina possa acessar a Internet através de roteadores em eth0 ou eth4).

ip route add xx.yy.4.0/23 dev eth4 table net4
ip route add default via xx.yy.4.1 table net4
ip route add 172.18.8.0/24 dev eth0 table net8
ip route add default via 172.18.8.254 table net8

E, finalmente, adicione algumas regras para selecionar a tabela apropriada com base na origem de origem do pacote.

ip rule add from xx.yy.4.0/23 lookup net4
ip rule add from 172.18.8.0/24 lookup net8

    

Answer 2

Isso parece um problema de roteamento. Se houver um pacote de entrada no eth0 de 4-net, seu sistema quer responder. A única rota que tem para a 4-net é a eth4, mas precisa responder a partir do endereço IP original - na eth0. Tente adicionar uma rota para que o tráfego possa sair da eth0 para a 4-net:
route add -net xx.yy.4.0 netmask 255.255.254.0 metric 100 dev eth0
A linha métrica faz com que esta não seja a rota preferida para a rede 4 (a menos que algo aconteça com a eth4)