Ich habe einen PC mit zwei Schnittstellen: eth0(IP-Adresse 192.168.1.16) und eth2(IP-Adresse 10.10.10.73). Außerdem habe ich in diesem PC eine Host-Route in der Tabelle, die besagt, dass die Schnittstelle verwendet werden soll, mainwenn die Zieladresse ist .172.16.1.1eth0
Wenn ich jetzt eine ICMP-Echoanforderung von 172.16.1.1an 10.10.10.73( eth2Schnittstelle) sende, wird eine ICMP-Echoantwort von eth0(ich habe RPF deaktiviert) unter Verwendung 192.168.1.16einer Quell-IP gesendet. Dies alles ist aufgrund dieser Host-Route wie erwartet.
Wenn ich jedoch direkt nach der Regelnummer einen ip ruleSelektor from 10.10.10.73und eine Aktion hinzufüge und die Tabelle einfach eine Standardroute mithilfe der Schnittstelle enthält, wird von der Schnittstelle eine ICMP-„Echoantwort“ gesendet .lookup test0testeth2eth2
Ich bin verwirrt, wie dieser from 10.10.10.73Selektor übereinstimmen kann. Wann war am Tag des Lebens einer ICMP-Nachricht „Echo Reply“ die Quell-IP, 10.10.10.73sodass eine Übereinstimmung zustande kam?
Antwort1
Entsprechend derBuch „Policy Routing mit Linux“, Pakete vom lokalen Rechner, die für externe Systeme bestimmt sind, gelangen nach Durchlaufen der Ausgabeketten in die Routing-Richtlinien-Datenbank, und hier from 10.10.10.73gleicht Ihr Selektor das ausgehende Echo-Antwort-Paket ab, das für 10.10.10.73bestimmt ist 172.16.1.1.
Aushttp://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH03.web.html:
Betrachten Sie den Pfad für ein extern bezogenes Paket, das für einen internen Dienst bestimmt ist. Es gelangt in das System und wird von der Eingangsphase zur Paketmanipulation und -kennzeichnung, Pre-Route(1), verarbeitet. In dieser Phase würden Sie Paketmanipulationsvorgänge wie fwmark und TOS/QoS-Kennzeichnung oder vielleicht NetFilter NAT anwenden. Das Paket gelangt dann in den RPDB, um geroutet zu werden, und wird an die Input(2)-Kette weitergeleitet. Die Input-Kette stellt die Firewall-Funktionen für Pakete bereit, die für die lokalen Maschinendienste bestimmt sind.
Das umgekehrte Szenario ist der Paketpfad für ein Paket aus einem internen Dienst, das für ein externes System bestimmt ist, wie etwa das Antwortpaket auf das im vorherigen Absatz beschriebene. Es verlässt die lokale Maschine und gelangt in die Output(4)-Ketten, die die Firewall-Funktionen bereitstellen. Anschließend gelangt es zur Routenverarbeitung in den RPDB und verlässt das System über die Phase der Paketveränderung und -markierung, Post-Route(5).
Antwort2
Der Selektor from 10.10.10.73stimmt überein, weil die Echo-Antwort von dieser Adresse ausgegeben wird. In diesem Fall ist dies jedoch nicht die empfohlene Vorgehensweise. Denn from 10.10.10.73es kann auf alles angewendet werden, was an eine andere Schnittstelle als eth0 geht, was in diesem Fall eine schlechte Route ergibt. Sie sollten es to 172.16.1.1stattdessen in Ihrer IP-Regel verwenden.
Die Sache mit der passenden Quelladresse hängt damit zusammen, dass die Verwendung ip ruleder Routing-Entscheidung in Bezug auf eine dedizierte Looktable dazu führt, dass das Paket die srcvon der Route dieser Schnittstelle angegebene Standardadresse ignoriert, wie Sie sie in sehen werden.ip route list table local
Was passiert, ist im roten Teil dieses Diagramms dargestellt:Diagramm zur Ausbreitung von Kernel-Paketen
Ohne ip ruledas Paket kommt es für den lokalen Prozess auf Ihrem Computer an, und aufgrund der Standardroute kommt die Antwort von eth0 (offensichtlich mit der eth0-IP-Adresse). Aufgrund des ip rule add from 10.10.10.73 table testRoutingprozesses ändert sich die Nachschlagetabelle und verwendet nicht die Standard-IP-Adresse der Schnittstelle, die die Route zum Ziel enthält, sondern verwendet jetzt die IP-Adresse der antwortenden Schnittstelle.