Ubuntu Ignorant les packages du réseau A sur eth0 lorsque eth4 est configuré sur le réseau A

J'ai un server Ubuntu 12.04 (beta final, à jour) avec deux interfaces réseau configurées:

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 Mesortingc: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 Mesortingc: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 Mesortingc: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 Mesortingc 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 

Comme vous pouvez le voir, eth0 est sur le réseau 172.18.8.0/24 ("8-net") et eth4 est sur le réseau xxx.yy.4.0 / 23 ("4-net"). Ces deux réseaux sont connectés via un routeur. De nombreuses machines sont sur les deux réseaux (une à la fois) et peuvent communiquer sans problème. Lorsqu'une deuxième machine sur le 4-net essaie de parler à 172.18.8.10, les packages semblent être abandonnés. Une tentative de tentative de SSH est ci-dessous:

 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 listning on 0.0.0.0 port 1022. debug1: Bind to port 1022 on ::. Server listning 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: listning 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 

Pour l'exhaustivité:

 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) 

Le noeud qui établit la connection connaît un timeout d'attente. D'autres protocoles sont également affectés. Echo request un timeout d'attente. Cependant, les noeuds sur le 8-net et tous les autres réseaux qui ne sont pas les 4-net sont en mesure de communiquer sans problème. Les journaux ne montrent rien. D'autres inputs "UFW BLOCK" existent dans / var / log / syslog, mais il n'existe pas de pertinence.

En bref, une machine a deux interfaces, eth0 sur le réseau 8 et eth4 sur le réseau 4. D'autres noeuds du réseau 4 ne peuvent pas communiquer avec eth0, mais les nœuds de tous les autres réseaux peuvent. L'opposé logique s'applique également: les nœuds du réseau 8 essayant de parler aux timeouts d'expérience de l'eth4. Est-ce une caractéristique ou un bug? Dois-je ne pas espérer pouvoir parler de l'interface logiquement incorrecte sur une machine avec deux interfaces?

Si cela count, il s'agit d'un Dell PowerEdge R900. eth0 est un port embedded "NetXtreme II BCM5708 Gigabit Ethernet" et eth4 est l'un des deux ports d'une carte complémentaire "MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT / s]" de Mellanox Technologies.

EDIT: le problème persiste lorsque le pare-feu est désactivé. tcpdump affiche encore des packages entrant (requests d'écho) sans envoi de réponses.

EDIT: Plus de sortie: il s'agit d'une décharge de trafic eth4 impliquant l'hôte distant 'xxx.yy.4.29'. À partir de xxx.yy.4.29, j'ai fait un ping 172.18.8.10 et xxx.yy.4.235. C'est la sortie.

 root@mac:/home/sysadm# tcpdump -nvlli eth4 'host xxx.yy.4.29' tcpdump: listning 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: Ce n'est qu'une machine à tester. Je ne peux pas imaginer un scénario réel où je devrais rouler la communication 8-net sur l'interface 4-net. Je peux voir comment ce serait un problème connu où le bénéfice d'une solution ne vaut pas l'effort de résoudre le problème.

2 Solutions collect form web for “Ubuntu Ignorant les packages du réseau A sur eth0 lorsque eth4 est configuré sur le réseau A”

Ce que vous voyez probablement ici, c'est le filtrage de path inverse . Le kernel supprime les packages car ils semblent provenir de l'interface «fausse». Pour vérifier si le RPF est activé, exécutez cat /proc/sys/net/ipv4/conf/eth0/rp_filter (et de manière similaire pour l'eth4). Pour le désactiver, écho 0 dans ces files.

Même avec le RPF désactivé, votre routing sera un peu bizarre comme l'a dit @NathanG (les packages de réponse sortiront d'une interface différente de celle qu'ils ont entré). Si vos routeurs ne sont pas trop intelligents (c'est-à-dire ne disposent pas de RPF ou d'une autre protection contre la parodie), cela devrait encore fonctionner.

Ce que vous devez configurer correctement est un routing de politique basé sur l'adresse source (c'est-à-dire dire au kernel que les packages de route diffèrent selon leur adresse source). Nous procédons en configurant plusieurs tables de routing, puis en ajoutant certaines règles pour sélectionner le tableau à utiliser.

D'abord, nommez quelques tables (il suffit de le faire une fois).

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

Ensuite, ajoutez des routes à ces nouvelles tables (je suppose que cette machine peut accéder à Internet via des routeurs sur 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 

Enfin, ajoutez certaines règles pour sélectionner le tableau approprié en fonction de l'adderess source du package.

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

Cela ressemble à un problème de routing. S'il y a un package entrant sur eth0 de 4-net, votre système souhaite répondre. La seule route qu'il a pour 4-net est sur l'eth4, mais elle doit répondre à partir de l'adresse IP d'origine – sur eth0. Essayez d'append un itinéraire afin que le trafic puisse sortir d'eth0 à 4-net:
route add -net xx.yy.4.0 netmask 255.255.254.0 mesortingc 100 dev eth0
La ligne mésortingque fait que ce ne sera pas l'itinéraire privilégié vers 4-net (sauf si quelque chose arrive à l'eth4)

  • Les adresses IPv6 provoquant l'échec des lists blanches du relais Exchange
  • Comment puis-je envoyer du trafic vers des adresses IP spécifiques via VPN et d'autres personnes directement sur Internet?
  • Est-il possible d'utiliser 1 adresse IP vers RDP dans différentes machines?
  • Reg Exp pour URL dans HAProxy
  • VPN Client ne peut pas accéder à un certain sous-réseau
  • DHCP renouvelle l'échec - internet goutte toutes les 2 heures
  • Ouverture et test des ports sur le modem> login du routeur
  • Pourquoi les users de Facebook finissent-ils parfois sur mon site lorsqu'ils entrent sur www.facebook.com dans leur browser?
  • Voies statiques IPv6
  • Modification de l'adresse IP sortante au hasard
  • OpenVPN - VM-Setup avec MacVTap, fonctionne ICMP echo, TCP / UPD ne fonctionne pas
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.