Wie lange wird eine (akzeptierte) ICMP-Weiterleitung beobachtet und wie kann ich diese Zeit verkürzen?

Question

Wenn ein Linux-Host eine ICMP-Umleitung empfängt und akzeptiert ( accept_redirects=1auf der betreffenden Schnittstelle), wie lange wird diese Route zwischengespeichert und überwacht? Kann ich diese Zeit verkürzen?

Ich frage, weil ich mehrere Systeme habe, die mit einer falschen Route vergiftet sind, die höchstwahrscheinlich auf eine unglückliche ICMP-Umleitung zurückzuführen ist:

$ ip route get 10.2.2.2 10.2.2.2 via 10.2.2.2 dev eth0 src 10.1.1.2 cache <redirected>

und sie sind einfachNicht vergessen, die Weiterleitung zu aktivieren, auch wenn die letzte ICMP-Weiterleitung länger als 12 Stunden zurückliegt! Ich muss ip route flush cacheden Eintrag manuell entfernen und die richtige Route wiederherstellen:

$ ip route get 10.2.2.2 10.2.2.2 via 10.1.1.1 dev eth0 src 10.1.1.2 cache

Ich weiß, wie und warum die ICMP-Weiterleitung überhaupt gesendet, empfangen und akzeptiert wurde. Darum geht es in dieser Frage nicht.

---

Ich denke, das ist für die Frage nicht relevant, aber hier sind einige Einzelheiten:

Wir haben ein internes Netzwerk, sagen wir 10.1.0.0/16. Einer der Rechner 10.1.1.1 ist ein OpenVPN-Server mit Remote-Clients, denen Adressen innerhalb von 10.2.0.0/16 zugewiesen werden. Die anderen internen Rechner haben eine statische Route 10.0.0.0/8 --> 10.1.1.1. Sie ist absichtlich breiter als 10.2.0.0/16, da der VPN-Server in Zukunft möglicherweise mehr Clients bedienen kann.

Leider schiebt unser Konfigurationsmanagement die breitere statische Route 10/8-->10.1.1.1 auch auf den VPN-Server selbst, wo sie als 10/8-->eth0 eingerichtet wird. Diese unnötige Route hat normalerweise keine Wirkung.

Unter normalen Umständen funktioniert dieses Setup einwandfrei. Aber dann passierte Folgendes:

• VPN-Server 10.1.1.1 wird neugestartet
• Ein anderer interner Host (z. B. 10.1.1.2) versucht, einen VPN-Client (z. B. 10.2.2.2) zu kontaktieren, sobald der VPN-Server seinen IP-Stack eingerichtet hat, aber bevor OpenVPN aktiv ist, sodass die Routen zu 10.2.0.0/16 noch nicht eingerichtet sind.
• Der VPN-Server hat send_redirects=1auf seiner internen Schnittstelle eth0 und sendet aufgrund der unglücklichen Route 10/8->eth0 eine entsprechende ICMP-Umleitung zurück zu 10.1.1.2
• 10.1.1.2 hat accept_redirects=1auf seiner internen Schnittstelle die im ICMP-Redirect angekündigte Route im Cache und sendet verzweifelt ARP-Anfragen für 10.2.2.2 in das interne Netzwerk:

Kurz darauf richtet der VPN-Server seine VPN-Routen ein, sendet keine Weiterleitungen mehr und alle anderen VPN-Verbindungen funktionieren einwandfrei.

So weit, so gut. Ich glaube, ich verstehe, was passiert ist und warum, und ich kenne verschiedene Möglichkeiten, um kurzfristig ( ip route flush cacheauf dem internen Host) und langfristig Abhilfe zu schaffen (natürlich die breitere Route auf dem VPN-Server loswerden; aber wir könnten sie auch accept_redirects=0auf internen Hosts einrichten; oder send_redirects=0auf dem VPN-Server einrichten), also das istnichtmeine Frage.

---

Anmerkungen:

• Ubuntu-Kernel 3.13.0-141
• Der Ubuntu-Kernel 4.4.0-116 scheint sich anders zu verhalten: Er akzeptiert die ICMP-Umleitung (if accept_redirects=1) ebenfalls, sofern er auch lokale ARP-Anfragen an das Ziel sendet. Aber zumindest solange diese unbeantwortet bleiben, sendet er die IP-Pakete weiterhin an den ursprünglichen nächsten Hop und ip route get 10.2.2.2zeigt weiterhin den ursprünglichen, nicht umgeleiteten nächsten Hop an.
• Entsprechendhttps://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux, net.ipv4.route.gc_intervalhätte dies möglicherweise vor 2.6.38 (2011) geregelt, seitdem jedoch nicht mehr.

Answer 1

Die ICMP-Umleitungen werden für die von gc_timeout () angegebene Zeit zwischengespeichert /proc/sys/net/ipv4/gc_timeout. Beachten Sie jedoch, dass das Timeout mit der letzten Aktivität beginnt, sodass der Fehler in manchen Situationen ewig anhalten kann.

Ich bin nicht sicher, ob alle Ubuntu-Distributionen über diese Funktionalität verfügen.