Pourquoi ICMP Redirect Host se produit-il?
Je configure une boîte Debian comme routeur pour 4 sous-réseaux. Pour cela, j'ai défini 4 interfaces virtuelles sur le 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 P-t-P: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 a 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 accéder au 10.1.1.12 à partir du 10.1.2.20.
Étant donné que le transfert de paquets est activé dans le routeur et que la politique de la chaîne FORWARD est ACCEPT (et qu'il n'y a pas d'autres règles), je comprends qu'il ne devrait y avoir aucun problème à envoyer une requête ping du 10.1.2.20 au 10.1.1.12 en passant par le routeur.
Cependant, voici ce que j'obtiens:
$ 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 arrive-t-il?
D'après ce que j'ai lu le Redirect Host la réponse 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 si j'ai bien compris). Ils sont en fait dans le même réseau physique, mais pourquoi y aurait-il un meilleur itinéraire s'ils ne sont pas sur le même sous-réseau (ils ne peuvent pas se voir)?
Qu'est-ce que je rate?
Quelques informations supplémentaires que vous voudrez peut-être 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
À première vue, il semble que Debian repousse les limites pour l'envoi d'une redirection ICMP; 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 que nous devrions voir Debian envoyer cette redirection.
Selon vos besoins, vous pourrez peut-être résoudre ce problème en créant le sous-réseau pour eth1 quelque chose comme 10.1.0.0/22 (Adresses d'hôtes de 10.1.0.1 - 10.1.3.254) au lieu d'utiliser des alias d'interface pour chaque /24 blocs (eth1, eth1:0, eth1:1, eth1:2); si vous avez fait cela, vous devrez changer le masque de réseau de tous les hôtes attachés et vous ne pourrez pas utiliser 10.1.4.x à moins que vous n'ayez développé un /21.
[~ # ~] modifier [~ # ~]
Nous nous aventurons un peu en dehors de la portée de la question d'origine, mais je vais vous aider à résoudre les problèmes de conception/sécurité mentionnés dans votre commentaire.
Si vous souhaitez isoler les utilisateurs de votre bureau les uns des autres, reculons un instant et examinons 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 satisfont pas aux exigences de sécurité que vous avez énoncées dans les commentaires (toutes les machines verront les diffusions d'autres machines et pourraient spontanément s'envoyer du trafic entre elles sur Layer2, quelle que soit 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 devrais-je dire qu'il n'y a rien que votre pare-feu Debian devrait faire pour changer cela :-).
- Vous devez affecter des utilisateurs à Vlans, en fonction de la politique de sécurité énoncée dans les commentaires. Un Vlan correctement configuré contribuera grandement à résoudre les problèmes mentionnés ci-dessus. Si votre commutateur Ethernet ne prend pas en charge les réseaux locaux virtuels, vous devriez en obtenir un qui le fait.
- En ce qui concerne plusieurs domaines de sécurité accédant à
10.1.1.12, vous avez plusieurs options:- Option 1 : étant donné que tous les utilisateurs doivent accéder aux services sur
10.1.1.12, vous pouvez mettre tous les utilisateurs dans un sous-réseau IP et implémenter des politiques de sécurité avec Private Vlans (RFC 5517) , en supposant que votre commutateur Ethernet le supporte. Cette option ne nécessitera pas de règlesiptablespour limiter le trafic intra-bureau de franchir les limites de sécurité (ce qui est accompli avec les VLAN privés). - Option 2 : Vous pourriez mettre les utilisateurs dans différents sous-réseaux (correspondant à Vlans) et implémenter
iptablesrègles pour déployer vos politiques de sécurité
- Option 1 : étant donné que tous les utilisateurs doivent accéder aux services sur
- Après avoir sécurisé votre réseau au niveau Vlan, configurez politiques de routage basées sur la source pour envoyer différents utilisateurs sur vos multiples liaisons montantes.
Pour info, si vous avez un routeur qui prend en charge VRF , cela devient encore plus facile; IIRC, vous avez une machine Cisco IOS sur place. Selon le modèle et l'image logicielle que vous avez déjà, Cisco pourrait faire un travail fantastique en isolant vos utilisateurs les uns des autres et implémenter des politiques de routage basées sur la source.
Ce que vous essayez de faire n'est pas vraiment clair, mais je peux dire ce qui suit.
Ces sous-réseaux sont connectés à la même interface physique. Le routeur Linux renvoie un message de redirection ICMP lorsque le paquet reçu doit être transmis sur la même interface physique.
Je suis d'accord avec les commentaires de Khaled et ajouterais également à la fin de sa phrase:
"Ces sous-réseaux sont connectés à la même interface physique. Le routeur Linux renvoie un message de redirection ICMP lorsque le paquet reçu doit être transféré sur la même interface physique" vers le même sous-réseau de destination puis redirige la demande vers le saut suivant. Cela m'arrive aujourd'hui en utilisant un routeur linux Mikrotik et un appareil F5 bigip LTM.
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
Faire cela semble physiquement comme une solution plus facile - mettez chaque LAN sur son propre commutateur et installez un 4 ports NIC dans votre seul boîtier qui veut les servir tous).