Warum passiert ICMP Redirect Host?

25

Ich richte eine Debian-Box als Router für 4 Subnetze ein. Dafür habe ich 4 virtuelle Schnittstellen auf der Netzwerkkarte definiert, an die das LAN angeschlossen ist ( 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)

Ich habe zwei andere Computer an dieses Netzwerk angeschlossen. Einer hat IP 10.1.1.12 (Subnetzmaske 255.255.255.0) und der andere 10.1.2.20 (Subnetzmaske 255.255.255.0). Ich möchte 10.1.1.12 von 10.1.2.20 erreichen können.

Da die Paketweiterleitung im Router aktiviert ist und die Richtlinie der FORWARD-Kette ACCEPT lautet (und es gibt keine anderen Regeln), sollte es meines Erachtens kein Problem geben, Pings von 10.1.2.20 bis 10.1.1.12 über den Router zu senden.

Dies ist jedoch, was ich bekomme:

$ 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

Warum passiert das?

Nach dem, was ich gelesen habe, hat die Redirect HostAntwort etwas mit der Tatsache zu tun, dass sich die beiden Hosts im selben Netzwerk befinden und es eine kürzere Route gibt (oder wie ich verstanden habe). Sie befinden sich tatsächlich im selben physischen Netzwerk, aber warum sollte es eine bessere Route geben, wenn sie sich nicht im selben Subnetz befinden (sie können sich nicht sehen)?

Was vermisse ich?

Einige zusätzliche Informationen, die Sie vielleicht sehen möchten:

# 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
quelle

Antworten:

22

Auf den ersten Blick sieht es so aus, als würde Debian die Grenzen für das Senden einer ICMP-Umleitung erweitern. unter Angabe von 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.

In diesem Fall ist G1 10.1.2.1( eth1:0oben), X ist 10.1.1.0/24und G2 ist 10.1.1.12und die Quelle ist 10.1.2.20(dh G2 and the host identified by the internet source address of the datagram are **NOT** on the same network). Vielleicht wurde dies historisch anders interpretiert, im Fall von Schnittstellen-Aliasen (oder sekundären Adressen) auf derselben Schnittstelle, aber genau genommen bin ich mir nicht sicher, ob Debian diese Weiterleitung senden sollte.

Je nach Bedarf könnten Sie in der Lage sein , dies zu , indem sie das Subnetz zu lösen , eth1wie etwas 10.1.0.0/22(Host - Adressen aus 10.1.0.1- 10.1.3.254) anstelle von Interface - Aliase für einzelne /24Blöcke ( eth1, eth1:0, eth1:1, eth1:2); In diesem Fall müssen Sie die Netzmaske aller angehängten Hosts ändern und können 10.1.4.x nur verwenden, wenn Sie zu a erweitert haben /21.

BEARBEITEN

Wir wagen uns ein bisschen außerhalb des Rahmens der ursprünglichen Frage, aber ich werde Ihnen dabei helfen, die in Ihrem Kommentar erwähnten Design- / Sicherheitsprobleme zu lösen.

Wenn Sie Benutzer in Ihrem Büro voneinander isolieren möchten, lassen Sie uns einen Schritt zurücktreten und einige Sicherheitsprobleme untersuchen, die sich mit dem beschäftigen, was Sie jetzt haben:

Sie haben derzeit vier Subnetze in einer Ethernet-Broadcast-Domäne. Alle Benutzer in einer Broadcast - Domäne nicht die Sicherheitsanforderungen erfüllen , in den Kommentaren artikuliert (alle Maschinen werden Sendungen von anderen Maschinen sehen und könnte Verkehr miteinander bei Layer2, unabhängig von ihrer Standard - Gateway Sein spontan senden eth1, eth1:0, eth1:1oder eth1:2). Es gibt nichts, was Ihre Debian-Firewall tun kann, um dies zu ändern (oder vielleicht sollte ich sagen, dass Ihre Debian-Firewall nichts tun sollte, um dies zu ändern :-).

  • Sie müssen Vlans Benutzer zuweisen, basierend auf den in den Kommentaren angegebenen Sicherheitsrichtlinien. Ein richtig konfiguriertes Vlan kann die oben genannten Probleme beheben. Wenn Ihr Ethernet-Switch Vlans nicht unterstützt, sollten Sie einen Switch erwerben, der dies unterstützt.
  • In Bezug auf den Zugriff auf mehrere Sicherheitsdomänen 10.1.1.12haben Sie mehrere Möglichkeiten:
    • Option 1 : Angesichts der Anforderung, dass alle Benutzer auf Dienste zugreifen müssen 10.1.1.12, können Sie alle Benutzer in ein IP-Subnetz einbinden und Sicherheitsrichtlinien mit Private Vlans (RFC 5517) implementieren , vorausgesetzt, Ihr Ethernet-Switch unterstützt dies. Für diese Option sind keine iptablesRegeln erforderlich , um das Überschreiten von Sicherheitsgrenzen für den Intra-Office-Verkehr zu begrenzen (dies wird mit privaten Vlans erreicht).
    • Option 2 : Sie können Benutzer in verschiedene Subnetze (entsprechend Vlans) einteilen und iptablesRegeln implementieren , um Ihre Sicherheitsrichtlinien bereitzustellen
  • Nachdem Sie Ihr Netzwerk auf Vlan-Ebene gesichert haben, richten Sie quellbasierte Routing-Richtlinien ein , um verschiedene Benutzer über mehrere Uplinks zu informieren.

Zu Ihrer Information , wenn Sie einen Router haben, der VRFs unterstützt , wird einiges davon noch einfacher. IIRC, Sie haben eine Cisco IOS-Maschine vor Ort. Abhängig von dem Modell und dem Software-Image, über das Sie bereits verfügen, kann Cisco Ihre Benutzer hervorragend voneinander isolieren und quellbasierte Routing-Richtlinien implementieren.

— Mike Pennington
quelle
Grundsätzlich brauche ich 4 Subnetze für verschiedene Bereiche eines Büros. Einige Subnetze gehen mit einem ISP ins Internet, andere mit einem anderen. Computer aus verschiedenen Subnetzen sollten nicht in der Lage sein, einander zu sehen oder eine Verbindung herzustellen. AUSGENOMMEN für Host 10.1.1.12, der einige Dienste anbietet, die für alle verfügbar sein sollten. Derzeit habe ich die entsprechenden FORWARD-Regeln dafür nicht eingerichtet. Da jedoch alle Weiterleitungen akzeptiert werden, dachte ich, dass ich in der Lage sein sollte, vom 10.1.2.20 bis zum 10.1.1.12 zu pingen.
— El Barto
Hmm ... ok, danke Mike. Ich werde näher auf VLANs eingehen. Ich hatte darüber nachgedacht, bevor ich anfing, und dachte, ich würde es nicht brauchen. Die Switches, die wir haben, unterstützen VLANs, obwohl es sich um nicht verwaltete Switches handelt. Wenn ich mich also nicht irre, muss ich wohl das Tagging auf dem Debian-Router durchführen, oder? Die Isolierung von Subnetzen ist in diesem Büro eigentlich kein kritisches Thema, aber ich denke, es wäre gut, wenn es nicht zu viel zusätzliche Arbeit erfordert. Ich werde es untersuchen und sehen, was ich tun kann :)
— El Barto
@ElBarto, wenn Ihre Switches kein Vlan-Tagging unterstützen (und das ist unwahrscheinlich, wenn sie nicht verwaltet werden), hilft es nicht, nur unter Debian zu taggen. Wenn die Isolierung von Intra-Office-Subnetzen kein kritisches Problem ist, ordnen Sie alle in zwei verschiedene Subnetze ein und vereinfachen Sie die Arbeit (zwei Subnetze stellen sicher, dass Sie Richtlinien für Debian festlegen können). Ich würde sagen, dass das aktuelle Schema mit vier Debian-Schnittstellen-Aliasen keine echte Subnetz-Isolation bietet und viel mehr Komplikationen mit sich bringt.
— Mike Pennington
Das ist richtig, nach dem, was ich aus dem Benutzerhandbuch verstehe, unterstützen die Schalter das "Beibehalten des Tags", aber nicht das "Ausführen des eigentlichen Tags". Vielen Dank für die Klarstellung bezüglich Debian. Die Sache ist, dass ich auch dann Computer aus dem Subnetz 10.1.2.0/24 brauche, wenn ich zwei Subnetze habe, um auf 10.1.1.12 zugreifen zu können.
— El Barto
Die Computer in einem anderen Subnetz sollten weiterhin Zugriff haben 10.1.1.12. Wenn Sie Linux daran hindern iptables, ICMP-Nachrichten zu senden, mit denen es nicht erreichbar ist , brennen Sie weiterhin die CPU, indem Sie die ICMP-Nachrichten senden, aber zumindest werden sie nicht in Ihren Hosttabellen installiert. Das heißt, wenn Sie dem Debian eine weitere Ethernet-Schnittstelle hinzufügen (dh eine Schnittstelle pro Benutzer 'Klasse' zuweisen), sollte Debian ICMP nicht mehr unerreichbar senden. Das würde bedeuten, dass Sie zwei verschiedene Ethernet-Switches haben: einen für jede Benutzer- "Klasse". Ihre Verkabelungstechniker würden es nicht mögen, aber es wird die Arbeit erledigt
— Mike Pennington
3

Es ist nicht wirklich klar, was Sie versuchen, aber ich kann Folgendes sagen.

Diese Subnetze sind mit derselben physischen Schnittstelle verbunden. Der Linux-Router gibt eine ICMP-Umleitungsnachricht zurück, wenn das empfangene Paket über dieselbe physische Schnittstelle weitergeleitet werden soll.

— Khaled
quelle
Ich muss mit diesen 4 Subnetzen umgehen, die alle über dieselbe Netzwerkkarte verbunden sind. Die Idee ist, dass Hosts aus den verschiedenen Subnetzen keine Verbindung miteinander herstellen können sollten, mit Ausnahme von Host 10.1.1.12, der für alle verfügbar sein sollte. Ich habe die Weiterleitungsregeln dafür noch nicht definiert, daher dachte ich, dass jeder Host aus einem dieser Subnetze in der Lage sein sollte, 10.1.1.12 zu erreichen. Gibt es eine Möglichkeit, die ICMP-Umleitung zu vermeiden?
— El Barto
1
@ElBarto, eine Methode ist, eine iptablesRegel hinzuzufügen, die das Erlöschen von Weiterleitungen verhinderteth1
— Mike Pennington
1

Ich stimme den Kommentaren von Khaled zu und möchte auch das Ende seiner Formulierung ergänzen:

"Diese Subnetze sind mit derselben physischen Schnittstelle verbunden. Der Linux-Router gibt eine ICMP-Umleitungsnachricht zurück, wenn das empfangene Paket über dieselbe physische Schnittstelle an dasselbe Ziel-Subnetz weitergeleitet werden soll, und leitet die Anforderung dann an den nächsten Hop weiter. Das ist mir heute mit einem Mikrotik-Linux-Router und einem F5-Bigip-LTM-Gerät passiert.

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
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.