Frage Warum passiert ICMP Redirect Host?


Ich richte eine Debian-Box als Router für 4 Subnetze ein. Dafür habe ich 4 virtuelle Schnittstellen auf der NIC definiert, wo das LAN verbunden 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 mit diesem Netzwerk verbunden. 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 vom 10.1.2.20 erreichen können.

Da die Paketweiterleitung im Router aktiviert ist und die Richtlinie der FORWARD-Kette ACCEPT ist (und es keine anderen Regeln gibt), verstehe ich, dass es kein Problem geben sollte, von 10.1.2.20 bis 10.1.1.12 über den Router zu pingen.

Das bekomme ich aber:

$ 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?

Von dem, was ich gelesen habe Redirect Host Antwort hat etwas mit der Tatsache zu tun, dass die beiden Hosts im selben Netzwerk sind und es eine kürzere Route gibt (so habe ich das verstanden). 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 

25
2018-06-25 14:07


Ursprung




Antworten:


Auf den ersten Blick sieht es so aus, als ob Debian die Grenzen für das Senden einer ICMP-Weiterleitung überschreitet. zitierend RFC 792 (Internetprotokoll).

  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:0 oben), X ist 10.1.1.0/24 und G2 ist 10.1.1.12und die Quelle ist 10.1.2.20 (d.h. G2 and the host identified by the internet source address of the datagram are **NOT** on the same network). Vielleicht wurde dies im Fall von Interface-Aliases (oder sekundären Adressen) auf der gleichen Schnittstelle historisch anders interpretiert, aber streng genommen bin ich nicht sicher, ob Debian diese Weiterleitung senden soll.

Je nach Ihren Anforderungen können Sie dies möglicherweise beheben, indem Sie das Subnetz für eth1 so etwas wie 10.1.0.0/22 (Hostadressen von 10.1.0.1 - 10.1.3.254) statt Aliase für einzelne Benutzer zu verwenden /24 Blöcke (eth1, eth1:0, eth1:1, eth1:2); Wenn Sie dies getan haben, müssen Sie die Netzmaske aller angeschlossenen Hosts ändern, und Sie könnten 10.1.4.x nicht verwenden, wenn Sie nicht zu a erweitert wurden /21.

BEARBEITEN

Wir gehen ein wenig über den Rahmen der ursprünglichen Frage hinaus, aber ich werde helfen, die in Ihrem Kommentar erwähnten Design- / Sicherheitsprobleme zu lösen.

Wenn Sie Benutzer in Ihrem Büro voneinander isolieren möchten, sollten Sie einen Moment zurücktreten und sich einige Sicherheitsprobleme mit dem, was Sie jetzt haben, ansehen:

Sie haben derzeit vier Subnetze in einer Ethernet-Broadcast-Domäne. Alle Benutzer in einer Broadcast-Domäne erfüllen nicht die Sicherheitsanforderungen, die Sie in den Kommentaren formuliert haben (alle Computer sehen Broadcasts von anderen Computern und können spontan auf Layer2 Datenverkehr unabhängig von ihrem Standard-Gateway senden eth1, eth1:0, eth1:1 oder eth1:2). Es gibt nichts, was Ihre Debian-Firewall tun könnte, um dies zu ändern (oder vielleicht sollte ich sagen, dass es nichts Debian-Firewall gibt sollte tu dies zu ändern :-).

  • Sie müssen Benutzer basierend auf den in den Kommentaren angegebenen Sicherheitsrichtlinien Benutzern in Vlans zuweisen. Ein richtig konfiguriertes Vlan wird einen großen Beitrag zur Behebung der oben genannten Probleme leisten. Wenn Ihr Ethernet Switch Vlans nicht unterstützt, sollten Sie einen solchen bekommen.
  • Im Hinblick auf den Zugriff mehrerer Sicherheitsdomänen 10.1.1.12, Sie haben ein paar Möglichkeiten:
    • Option 1: Angesichts der Anforderung, dass alle Benutzer auf Dienste zugreifen müssen 10.1.1.12können Sie alle Benutzer in ein IP-Subnetz einfügen und Sicherheitsrichtlinien mit implementieren Private Vlans (RFC 5517), vorausgesetzt, Ihr Ethernet-Switch unterstützt dies. Diese Option wird nicht benötigt iptables Regeln, um den innerbetrieblichen Verkehr vom Überschreiten von Sicherheitsgrenzen zu begrenzen (dies wird mit privaten VLANs erreicht).
    • Option 2: Sie könnte Versetzen Sie Benutzer in verschiedene Subnetze (entsprechend Vlans) und implementieren Sie sie iptables Regeln zum Bereitstellen Ihrer Sicherheitsrichtlinien
  • Nachdem Sie Ihr Netzwerk auf der VLAN-Ebene gesichert haben, richten Sie es ein quellenbasierte Routing-Richtlinien um verschiedene Benutzer aus Ihren mehreren Uplinks zu senden.

FYI, wenn Sie einen Router haben, der unterstützt VRFsEinige davon werden noch einfacher; IIRC, Sie haben eine Cisco IOS-Maschine vor Ort. Je nachdem, welches Modell und welches Software-Image Sie bereits haben, könnte Cisco einen fantastischen Job machen, um Ihre Benutzer voneinander zu isolieren und Implementieren von quellenbasierten Routing-Richtlinien.


22
2018-06-25 14:41



Grundsätzlich brauche ich 4 Subnetze für verschiedene Bereiche eines Büros. Einige Subnetze gehen mit einem ISP ins Internet und andere verwenden ein anderes. Computer aus verschiedenen Subnetzen sollten nicht in der Lage sein, miteinander zu kommunizieren. AUSSER für Host 10.1.1.12, der einige Dienste anbietet, die für alle verfügbar sein sollten. Zurzeit habe ich noch keine entsprechenden FORWARD-Regeln eingerichtet. Da jedoch alle Weiterleitungen akzeptiert werden, dachte ich, ich sollte in der Lage sein, von 10.1.2.20 zu 10.1.1.12 zu pingen. - El Barto
Hmm ... ok, danke Mike. Ich werde tiefer in VLANs schauen. Ich hatte darüber nachgedacht, bevor ich all das angefangen hatte, und dachte, ich würde es nicht brauchen. Die Switches, die wir haben, unterstützen VLANs, obwohl sie unmanaged Switches sind. Wenn ich also nicht falsch liege, werde ich das Tagging auf dem Debian-Router machen müssen, richtig? Die Isolation von Subnetzen ist eigentlich kein kritisches Thema in diesem Büro, aber es ist etwas, von dem ich denke, dass es gut wäre, wenn es nicht zu viel zusätzliche Arbeit erfordert. Ich werde es sehen und sehen, was ich tun kann :) - El Barto
@ ElBarto, wenn deine Switches kein Vlan-Tagging unterstützen (und das ist unwahrscheinlich, wenn sie nicht verwaltet werden), würde nur das Tagging auf Debian nicht helfen. Wenn die Subnetzisolierung innerhalb eines Büros kein kritisches Problem darstellt, sollten Sie alle in zwei verschiedene Subnetze aufnehmen und die Dinge vereinfachen (zwei Subnetze stellen sicher, dass Sie eine Richtlinienroute für Debian durchführen können). Ich würde sagen, dass das aktuelle Schema mit vier Debian-Schnittstellen-Aliases keine echte Subnetz-Isolation bietet, und es fügt viel mehr Komplikationen hinzu. - Mike Pennington
Das stimmt, nach dem, was ich aus dem Benutzerhandbuch verstehe, unterstützen die Switches "das Tag behalten", aber nicht "das eigentliche Tagging". Danke für die Klärung bezüglich Debian. Die Sache ist, dass, selbst wenn ich zwei Subnetze behalte, ich noch Maschinen vom Subnetz 10.1.2.0/24 benötige, um auf 10.1.1.12 zuzugreifen. - El Barto
Die Maschinen in einem anderen Subnetz sollten weiterhin darauf zugreifen können 10.1.1.12. Wenn Sie verhindern, dass Linux mit ICMP unreachables sendet iptables, dann werden Sie immer noch die CPU brennen, die die ICMP-Nachrichten sendet, aber sie werden zumindest nicht in Ihren Host-Tabellen installiert. Das heißt, wenn Sie eine weitere Ethernet-Schnittstelle auf dem Debian hinzufügen (d. H. Eine Schnittstelle pro Benutzer 'Klasse' zuweisen), Debian sollte ICMP-Unreachables nicht mehr senden; Das würde bedeuten, dass Sie zwei verschiedene Ethernet-Switches haben: einen für jede Benutzerklasse. Ihre Verkabelungstechniker würden es nicht mögen, aber es macht die Arbeit erledigt - Mike Pennington


Es ist nicht wirklich klar, was Sie zu tun 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 die gleiche physische Schnittstelle weitergeleitet werden soll.


3
2018-06-25 14:33



Ich muss mit diesen 4 Subnetzen umgehen, die alle über die gleiche NIC verbunden sind. Die Idee ist, dass Hosts aus den verschiedenen Subnetzen nicht miteinander verbunden werden können, mit Ausnahme von Host 10.1.1.12, der für alle verfügbar sein sollte. Ich habe die Weiterleitungsregeln noch nicht definiert, daher dachte ich, dass jeder Host aus einem dieser Subnetze 10.1.1.12 erreichen könnte. Gibt es eine Möglichkeit, die ICMP-Umleitung zu vermeiden? - El Barto
@ElBarto, eine Methode ist das Hinzufügen eines iptables Regel, die Redirects löscht eth1 - Mike Pennington


Ich stimme Khaleds Kommentaren zu und würde auch am Ende seines Satzes hinzufügen:

"Diese Subnetze sind mit derselben physikalischen Schnittstelle verbunden. Das Linux   Router wird ICMP-Umleitungsnachricht zurückgeben, wenn das Paket empfangen wird   sollte über die gleiche physikalische Schnittstelle weitergeleitet werden " zum Selben   Zielsubnetz Weiterleiten der Anfrage zum nächsten Hop.   Das passiert mir heute mit einem Mikrotik Linux Router und einem F5 Bigip   LTM-Gerät.

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

1
2018-04-29 01:22