Pourquoi ICMP Redirect Host se produit-il?

25

Je configure une boîte Debian comme routeur pour 4 sous-réseaux. Pour cela, j'ai défini 4 interfaces virtuelles sur la carte réseau 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 l'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, la Redirect Hostré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
networking debian iptables routing icmp El Barto
la source

Réponses:

22

À première vue, il semble que Debian repousse les limites pour l'envoi d'une redirection ICMP; citant la 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:0ci-dessus), X est 10.1.1.0/24et G2 est 10.1.1.12, et la source est 10.1.2.20(ie 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.

En fonction de vos besoins, vous pourriez être en mesure de résoudre ce problème en rendant le sous - réseau pour eth1quelque chose comme 10.1.0.0/22(adresses d'hôtes à partir de 10.1.0.1- 10.1.3.254) au lieu d'utiliser un alias d'interface pour les différents /24blocs ( 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 étendu à a /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 répond pas aux exigences de sécurité que vous articulée dans les commentaires (toutes les machines verront les émissions d'autres machines et peuvent envoyer spontanément le trafic à l'autre à Layer2, quel que soit leur être la passerelle par défaut eth1, eth1:0, eth1:1ou 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 l'accès à plusieurs domaines de sécurité 10.1.1.12, vous avez deux options:
    • Option 1 : Compte tenu de la nécessité pour tous les utilisateurs d'accéder aux services 10.1.1.12, vous pouvez mettre tous les utilisateurs dans un sous-réseau IP et mettre en œuvre des politiques de sécurité avec Private Vlans (RFC 5517) , en supposant que votre commutateur Ethernet le prend en charge. Cette option ne nécessitera pas de iptablesrègles pour limiter le trafic intra-bureau de franchir les limites de sécurité (ce qui est accompli avec des VLAN privés).
    • Option 2 : vous pouvez placer les utilisateurs dans différents sous-réseaux (correspondant aux réseaux locaux virtuels) et implémenter des iptablesrègles pour déployer vos politiques de sécurité
  • Après avoir sécurisé votre réseau au niveau Vlan, configurez des stratégies 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 les 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 possédez déjà, Cisco pourrait faire un travail fantastique en isolant vos utilisateurs les uns des autres et en mettant en œuvre des politiques de routage basées sur la source.

Mike Pennington
la source
Fondamentalement, ce dont j'ai besoin, c'est d'avoir 4 sous-réseaux pour différentes zones d'un bureau. Certains sous-réseaux iront sur Internet à l'aide d'un FAI et d'autres en utiliseront un autre. Les machines de différents sous-réseaux ne devraient pas pouvoir se voir ni se connecter les unes aux autres. SAUF pour l'hôte 10.1.1.12 qui offre certains services qui devraient être disponibles pour tous. Actuellement, je n'ai pas configuré les règles FORWARD appropriées pour cela. Cependant, comme tous les attaquants sont acceptés, j'ai pensé que je devrais être en mesure de faire un ping de 10.1.2.20 à 10.1.1.12.
El Barto
Hmm ... ok, merci Mike. J'examinerai plus en détail les VLAN. J'y avais pensé avant de commencer tout ça, et je pensais que je n'en aurais pas besoin. Les commutateurs que nous avons prennent en charge les VLAN, bien qu'ils soient des commutateurs non gérés, donc, si je ne me trompe pas, je suppose que je devrai faire le balisage sur le routeur Debian, non? L'isolement des sous-réseaux n'est en fait pas un problème critique dans ce bureau, mais c'est quelque chose que je pense qu'il serait bon d'avoir s'il ne nécessite pas trop de travail supplémentaire. Je vais l'examiner et voir ce que je peux faire :)
El Barto
@ElBarto, si vos commutateurs ne prennent pas en charge le balisage Vlan (et c'est peu probable s'ils ne sont pas gérés), alors seul le balisage sur Debian n'aiderait pas. Si l'isolation des sous-réseaux intra-bureau n'est pas un problème critique, alors mettez tout le monde dans deux sous-réseaux différents et simplifiez les choses (deux sous-réseaux vous garantissent un itinéraire de politique sur Debian). Je dirais que le schéma actuel avec quatre alias d'interface Debian n'offre pas de véritable isolation de sous-réseau, et il ajoute beaucoup plus de complications.
Mike Pennington
C'est vrai, d'après ce que je comprends du manuel d'utilisation, les commutateurs prennent en charge "garder la balise" mais pas "faire le marquage réel". Merci pour la clarification concernant Debian. Le fait est que même si je garde deux sous-réseaux, j'aurai toujours besoin de machines du sous-réseau 10.1.2.0/24 pour accéder à 10.1.1.12.
El Barto
Les machines d'un sous-réseau différent devraient toujours pouvoir accéder 10.1.1.12. Si vous empêchez Linux d'envoyer des messages ICMP inaccessibles avec iptables, alors vous pourrez toujours graver le CPU à partir de lui en envoyant les messages ICMP, mais au moins ils ne seront pas installés dans vos tables d'hôtes. Cela dit, si vous ajoutez une autre interface Ethernet sur Debian (c'est-à-dire que vous dédiez une interface par «classe» d'utilisateur), Debian ne devrait plus envoyer ICMP inaccessible; cela impliquerait que vous avez deux commutateurs Ethernet différents: un pour chaque «classe» d'utilisateur. Vos techniciens de câblage ne l'aimeraient pas, mais cela fait le travail
Mike Pennington
3

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 renverra le message de redirection ICMP lorsque le paquet reçu doit être transféré sur la même interface physique.

Khaled
la source
J'ai besoin de gérer ces 4 sous-réseaux qui sont tous connectés via la même carte réseau. L'idée est que les hôtes des différents sous-réseaux ne devraient pas pouvoir se connecter les uns aux autres, à l'exception de l'hôte 10.1.1.12 qui devrait être disponible pour tous. Je n'ai pas encore défini les règles de transfert pour cela, j'ai donc pensé que tout hôte de l'un de ces sous-réseaux devrait être en mesure d'atteindre 10.1.1.12. Existe-t-il un moyen d'éviter la redirection ICMP?
El Barto
1
@ElBarto, une méthode consiste à ajouter une iptablesrègle qui supprime les redirections sortanteth1
Mike Pennington
1

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 transmis sur la même interface physique" au 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
user352048
la source