Pourquoi l'ICMP Redirect Host se produit-il?

Je configure une boîte Debian comme un routeur pour 4 sous-réseaux. Pour cela, j'ai défini 4 interfaces virtuelles sur la NIC où le LAN est connecté ( eth1 ).

 eth1 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::960c:6dff:fe82:d98/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6026521 errors:0 dropped:0 overruns:0 frame:0 TX packets:35331299 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:673201397 (642.0 MiB) TX bytes:177276932 (169.0 MiB) Interrupt:19 Base address:0x6000 eth1:0 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98 inet addr:10.1.2.1 Bcast:10.1.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:19 Base address:0x6000 eth1:1 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98 inet addr:10.1.3.1 Bcast:10.1.3.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:19 Base address:0x6000 eth1:2 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98 inet addr:10.1.4.1 Bcast:10.1.4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:19 Base address:0x6000 eth2 Link encap:Ethernet HWaddr 6c:f0:49:a4:47:38 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::6ef0:49ff:fea4:4738/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:199809345 errors:0 dropped:0 overruns:0 frame:0 TX packets:158362936 errors:0 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:1000 RX bytes:3656983762 (3.4 GiB) TX bytes:1715848473 (1.5 GiB) Interrupt:27 eth3 Link encap:Ethernet HWaddr 94:0c:6d:82:c8:72 inet addr:192.168.2.5 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::960c:6dff:fe82:c872/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:110814 errors:0 dropped:0 overruns:0 frame:0 TX packets:73386 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16044901 (15.3 MiB) TX bytes:42125647 (40.1 MiB) Interrupt:20 Base address:0x2000 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:22351 errors:0 dropped:0 overruns:0 frame:0 TX packets:22351 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2625143 (2.5 MiB) TX bytes:2625143 (2.5 MiB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 PtP:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:41358924 errors:0 dropped:0 overruns:0 frame:0 TX packets:23116350 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:3065505744 (2.8 GiB) TX bytes:1324358330 (1.2 GiB) 

J'ai deux autres ordinateurs connectés à ce réseau. L'un possède IP 10.1.1.12 (masque de sous-réseau 255.255.255.0) et l'autre 10.1.2.20 (masque de sous-réseau 255.255.255.0). Je veux pouvoir atteindre 10.1.1.12 à partir du 10.1.2.20.

Étant donné que le renvoi de paquets est activé dans le routeur et que la politique de la chaîne FORWARD est ACCEPTÉE (et qu'il n'y a pas d'autres règles), je comprends qu'il n'y ait pas de problème de ping du 10.1.2.20 au 10.1.1.12 en passant par le routeur.

Cependant, c'est ce que je reçois:

 $ ping -c15 10.1.1.12 PING 10.1.1.12 (10.1.1.12): 56 data bytes Request timeout for icmp_seq 0 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 81d4 0 0000 3f 01 e2b3 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 1 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 899b 0 0000 3f 01 daec 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 2 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 78fe 0 0000 3f 01 eb89 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 3 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 14b8 0 0000 3f 01 4fd0 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 4 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 8ef7 0 0000 3f 01 d590 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 5 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 ec9d 0 0000 3f 01 77ea 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 6 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 70e6 0 0000 3f 01 f3a1 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 7 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 b0d2 0 0000 3f 01 b3b5 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 8 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 f8b4 0 0000 3f 01 6bd3 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 9 Request timeout for icmp_seq 10 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 1c95 0 0000 3f 01 47f3 10.1.2.20 10.1.1.12 Request timeout for icmp_seq 11 Request timeout for icmp_seq 12 Request timeout for icmp_seq 13 92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 62bc 0 0000 3f 01 01cc 10.1.2.20 10.1.1.12 

Pourquoi cela se produit-il?

D'après ce que j'ai lu, la réponse de l' Redirect Host a quelque chose à voir avec le fait que les deux hôtes sont dans le même réseau et qu'il y a un itinéraire plus court (ou j'ai compris). Ils sont en fait dans le même réseau physique, mais pourquoi y aurait-il une meilleure route s'ils ne se trouvent pas sur le même sous-réseau (ils ne peuvent pas se voir)?

Qu'est-ce qui me manque?

Quelques informations supplémentaires que vous voudrez voir:

 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth2 10.1.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.1.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth2 0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 eth3 # iptables -L -n 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 # iptables -L -n -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- !10.0.0.0/8 10.0.0.0/8 MASQUERADE all -- 10.0.0.0/8 !10.0.0.0/8 Chain OUTPUT (policy ACCEPT) target prot opt source destination 

3 Solutions collect form web for “Pourquoi l'ICMP Redirect Host se produit-il?”

Au premier rougissement, il semble que Debian étend les limites pour l'envoi d'une redirection ICMP; En citant RFC 792 (Internet Protocol) .

  The gateway sends a redirect message to a host in the following situation. A gateway, G1, receives an internet datagram from a host on a network to which the gateway is attached. The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the datagram's internet destination network, X. If G2 and the host identified by the internet source address of the datagram are on the same network, a redirect message is sent to the host. The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination. The gateway forwards the original datagram's data to its internet destination. 

Dans ce cas, G1 est 10.1.2.1 ( eth1:0 ci-dessus), X est 10.1.1.0/24 et G2 est 10.1.1.12 , et la source est 10.1.2.20 (c'est-à-dire G2 and the host identified by the internet source address of the datagram are **NOT** on the same network ). Peut-être que cela a été historiquement interprété différemment dans le cas d'alias d'interface (ou d'adresses secondaires) sur la même interface, mais à proprement parler, je ne suis pas sûr de voir Debian envoyer cette redirection.

Selon vos besoins, vous pourriez peut-être résoudre ceci en faisant du sous-réseau pour eth1 quelque chose comme 10.1.0.0/22 (adresses d'hôte de 10.1.0.110.1.3.254 ) au lieu d'utiliser des alias d'interface pour des blocs individuels /24 ( eth1 , eth1:0 , eth1:1 , eth1:2 ); Si vous avez fait cela, vous devrez modifier le masque de réseau de tous les hôtes et vous ne pourrez pas utiliser 10.1.4.x à moins d'être étendu à /21 .

MODIFIER

Nous nous aventurons un peu en dehors de la question initiale, mais je vais aider à résoudre les problèmes de conception et de sécurité mentionnés dans votre commentaire.

Si vous souhaitez isoler les utilisateurs de votre bureau les uns des autres, revenons en arrière pour une seconde et regardez certains problèmes de sécurité avec ce que vous avez maintenant:

Vous disposez actuellement de quatre sous-réseaux dans un domaine de diffusion Ethernet. Tous les utilisateurs d'un domaine de diffusion ne répondent pas aux exigences de sécurité que vous avez énoncées dans les commentaires (toutes les machines verront des émissions provenant d'autres machines et pourraient envoyer spontanément du trafic à Layer2 indépendamment de leur passerelle par défaut eth1 , eth1:0 , eth1:1 ou eth1:2 ). Il n'y a rien que votre pare-feu Debian puisse faire pour changer cela (ou peut-être que je devrais dire qu'il n'y a rien que votre pare-feu Debian fasse pour changer ceci :-).

  • Vous devez affecter des utilisateurs à Vlans, en fonction de la politique de sécurité indiquée dans les commentaires. Un Vlan correctement configuré permettra de résoudre les problèmes mentionnés ci-dessus. Si votre commutateur ethernet ne supporte pas les Vlans, vous devriez en avoir un.
  • En ce qui concerne les domaines de sécurité multiples accessibles au 10.1.1.12 , vous avez quelques options:
    • Option 1 : Compte tenu de l'exigence pour tous les utilisateurs d'accéder aux services du 10.1.1.12 , vous pouvez mettre tous les utilisateurs dans un sous-réseau IP et mettre en œuvre des stratégies de sécurité avec Private Vlans (RFC 5517) , en supposant que votre commutateur ethernet prend en charge cela. Cette option n'oblige pas les règles iptables à limiter le trafic intra-office de la traversée des limites de sécurité (cela s'effectue avec les VLans privés).
    • Option 2 : Vous pouvez placer les utilisateurs dans différents sous-réseaux (correspondant à Vlans) et implémenter des règles iptables pour déployer vos stratégies de sécurité
  • Après avoir sécurisé votre réseau au niveau de Vlan, configurez des stratégies de routage basées sur la source pour envoyer différents utilisateurs de vos multiples liens de liaison.

FYI, si vous avez un routeur prenant en charge les VRF , cela devient encore plus facile; IIRC, vous disposez d'une machine Cisco IOS sur place. Selon l'image modèle et logiciel que vous avez déjà, Cisco pourrait faire un travail fantastique en isolant vos utilisateurs les uns des autres et implémentant des politiques de routage basées sur la source.

Ce n'est pas vraiment clair ce que vous essayez de faire, mais je peux dire ce qui suit.

Ces sous-réseaux sont connectés à la même interface physique. Le routeur Linux renverra le message de redirection ICMP lorsque le paquet reçu devrait être transféré sur la même interface physique.

Je suis d'accord avec les commentaires de Khaled et ajouterai aussi à la fin de sa phrase:

"Ces sous-réseaux sont connectés à la même interface physique. Le routeur Linux renverra le message de redirection ICMP lorsque le paquet reçu devrait être transféré sur la même interface physique" vers le même sous-réseau de destination puis en réorientant la requête vers le prochain saut. Cela m'arrive aujourd'hui à l'aide d'un routeur linux Mikrotik et d'un périphérique LTM Fip Bigm.

 root@(primaryadc)(cfg-sync In Sync)(Standby)(/Common)(tmos)# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. From 192.168.153.20: icmp_seq=1 Redirect Host(New nexthop: 192.168.153.2) 64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=82.8 ms From 192.168.153.20: icmp_seq=2 Redirect Host(New nexthop: 192.168.153.2) 64 bytes from 8.8.8.8: icmp_seq=2 ttl=128 time=123 ms **routing table** 0.0.0.0 192.168.153.20 0.0.0.0 UG 0 0 0 external 
  • Pourquoi la pile réseau ignore les réponses icmp à partir d'une interface non par défaut?
  • Nginx rend le site inaccessible via IP
  • OpenVPN: le client Windows 7 x64 ne peut pas voir le LAN distant, mais le client XP peut
  • Définir un itinéraire par défaut statique dans un routeur, dans linux
  • Systemd-networkd et routes directes
  • Supprimer les entrées spécifiques de connripck?
  • Comment configurer deux routes par défaut dans linux
  • Comment puis-je acheminer le trafic vers un site spécifique / IP-block via un nic, avec d'autres trafics à travers un autre nic?
  • Création d'un routeur personnalisé
  • Plusieurs adresses IP dans le même sous-réseau sur le même hôte
  • Comment définir une source d'itinéraire personnalisée dans openvpn
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.