Erzwingen des Pings zum Ausgang, wenn die Zielschnittstelle lokal ist (Debian)
1308
Dave
Ich führe einen Debian-basierten Linux-Container unter Proxmox 4.4 aus. Dieser Host verfügt über fünf Netzwerkschnittstellen (obwohl bei dem Problem, das ich habe, nur zwei ins Spiel kommen).
Während ich in diesen Host eingebunden bin, ping ich die mit eth1 verknüpfte IP-Adresse. Was passiert und was meiner Meinung nach passieren sollte, sind zwei sehr unterschiedliche Dinge.
Ich möchte, dass das Ping-Paket an eth3 übergeben wird, wo es an eth1 geleitet wird.
Was passiert, ist, dass der IP-Stack sieht, dass ich eine lokale Schnittstelle pingte, und sendet dann die Antwort direkt an den Stack. Ich weiß, dass das Paket aus zwei Gründen nicht herauskommt und zurückkommt:
Eine Paketerfassung zeigt nichts, was entweder auf eth1 oder eth3 trifft.
Die Ping-Latenzzeit beträgt durchschnittlich 0,013 ms. Wenn das Paket wie beabsichtigt ab- und zurückgeht, beträgt die Latenz etwa 60 ms.
Natürlich wünsche ich mir ein entsprechendes Verhalten, wenn ich die mit eth3 verknüpfte IP-Adresse anpinge. In diesem Fall möchte ich, dass das Paket eth1 verlässt, wo es an eth3 weitergeleitet wird. Leider passiert ein ähnliches Verhalten wie oben beschrieben.
Im Folgenden zeige ich die statischen Routen, die ich eingerichtet habe, um das gewünschte Verhalten herbeizuführen. Solche Routen funktionieren wie vorgesehen auf einem Windows-Computer, sie funktionieren jedoch nicht unter dem von mir verwendeten Linux-Setup.
Wie kann ich diesen Host so konfigurieren, dass er wie beabsichtigt weitergeleitet wird?
Auf Anfrage von Dirkt gehe ich auf unsere Architektur und den Grund meiner Frage ein.
Der virtuelle Host, der Gegenstand dieses Beitrags ist (dh der Host mit den Netzwerkschnittstellen eth1, eth3 und drei anderen Netzwerkschnittstellen, die nicht mit meiner Frage zusammenhängen), wird zum Testen einer von uns eingerichteten physischen, verdrahteten TCP / IP-Netzwerkinfrastruktur verwendet . Wir testen gerade die Routing-Funktionalität dieser TCP / IP-Netzwerkinfrastruktur.
Wir hatten früher zwei virtuelle Hosts, keinen, wie ich in meinem ursprünglichen Beitrag beschrieben habe. Ein Ping zwischen diesen beiden Hosts wäre unser Rauchtest, um sicherzustellen, dass die getestete TCP / IP-Netzwerkinfrastruktur weiterhin funktioniert.
Aus Gründen, die zu detailliert waren, um daran zu arbeiten, erschwerten zwei Hosts das Sammeln der erforderlichen Protokolle. Also haben wir zu einem Host gewechselt, ihm zwei NICs gegeben und statische Routen eingerichtet, so dass alles, was für NIC 2 bestimmt ist, NIC 1 verlässt und umgekehrt. Das Problem ist, wie gesagt, sie treten nicht aus.
Diese Konfiguration mit einem Host und zwei NICs funktioniert seit Jahren unter Windows. Ich weiß nicht, ob dies daran liegt, dass Windows defekt ist und wir aus Versehen einen Fehler ausnutzten oder ob Windows in Ordnung ist (dh RFC-kompatibel) und wir nur die Konfiguration unserer Linux-VMs richtig einstellen müssen, um dasselbe zu erhalten Verhalten.
Um den langen Block des Shell-Textes oben zusammenzufassen und zu beschreiben:
Zwei Schnittstellen:
eth1: 128.66.100.10/24; the router on this interface's network has IP address 128.66.100.1 eth3: 128.66.200.10/24; the router on this interface's network has IP address 128.66.200.1
Was ich versuche zu verstehen, ist, warum das Paket aufgrund dieser Route nicht aus eth3 austritt, durch unsere TCP / IP-Netzwerkinfrastruktur reist, zurückkommt und von außen auf eth1 trifft .
Der TCP / IP-Stack konsultiert anscheinend die Weiterleitungstabelle nicht. Es sieht so aus, als würde ein TCP / IP-Stack sagen, dass ich eine lokal verbundene Schnittstelle anrufe, und sagt: "Oh, das ist eine lokale Schnittstelle. Ich werde also nicht die Weiterleitungstabelle konsultieren. lch schicke einfach eine Echo-Antwort direkt auf den Stack ".
Ist das gewünschte Verhalten RFC-konform? Wenn nicht, muss ich den Versuch aufgeben. Wenn es jedoch RFC-kompatibel ist, möchte ich erfahren, wie der Linux-TCP / IP-Stack konfiguriert wird, um dieses Verhalten zuzulassen.
MONTAG, 21.08.2017 AKTUALISIERUNG
Ich habe die sysctl rp_filter- und accept_local- Kernel-Parameter entdeckt. Ich habe sie wie folgt eingestellt:
Das Einstellen dieser Kernel-Parameter, das Neustarten, Überprüfen, dass sie den Neustart überstanden haben, und das erneute Testen zeigte keinen Unterschied im Verhalten.
Bitte beachten Sie, dass my-host ein lxc-Linux-Container ist, der unter Proxmox 4.4 läuft. Ich habe auch rp_filter und accept_local wie oben auf den Hypervisor-Schnittstellen eingestellt, die den Schnittstellen eth1 und eth3 auf meinem Host entsprechen .
Um mein Ziel zusammenzufassen, habe ich einen Linux-Host mit zwei NICs, eth1 und eth3. Ich versuche, eth1 zu pingen, das Ping-Paket durch eine TCP / IP-Netzwerkinfrastruktur leiten zu lassen und den Weg zurück zu eth3 zu finden.
Nichts, was ich oben ausprobiert habe, hat es mir erlaubt. Wie kann ich das machen?
8/27/2017 AKTUALISIERUNG
Nach einer Notiz von dirkt, die ich nicht erwähnen konnte, ob eth1 und eth3 rein virtuell sind oder ob sie einer physischen Schnittstelle entsprechen ... entsprechen sowohl eth1 als auch eth3 der gleichen physischen Schnittstelle auf dem Hypervisor. Die Absicht ist, dass ein Paket, das eth1 aufhebt, tatsächlich die Hypervisor-Box verlässt, in ein echtes TCP / IP-Netzwerk geht und zurückgeleitet wird.
8/27/2017 UPDATE # 2
Ich habe die Netzwerk-Namespaces untersucht, da es vielversprechend schien. Es funktioniert jedoch nicht "nur".
Ich verwende LXC-Container, und es scheint, dass einige der Isolationsmechanismen in Containern mich daran hindern, einen Netzwerk-Namespace zu erstellen. Wenn ich nicht in einem Container ausgeführt würde, hätte ich kein Problem damit, den Netzwerk-Namespace hinzuzufügen.
Ich finde einige Hinweise, wie man diese Arbeit in LXC-Containern machen kann, aber sie sind ziemlich dunkel und geheimnisvoll. Noch nicht da und muss heute das Handtuch werfen ... Wenn jemand irgendwelche Vorschläge in dieser Hinsicht hat, bitte beraten ...
Falsche Site Sie suchen stattdessen nach [unix.se] oder [su]. Diese Seite dient zur Programmierung von Fragen.
Ken White vor 7 Jahren
0
Ja, stimmte zu und entschuldige mich. Gepostet hier durch Zufall. Beabsichtigter SuperUser.
Dave vor 7 Jahren
0
Verschieben wurde über Flag angefordert.
Dave vor 7 Jahren
0
Ihre Beschreibung dessen, was Sie möchten, ist etwas verwirrend und stimmt nicht mit dem Routing des Kernels überein. Wenn ein Paket auf "eth3" aufbricht und die physische Schnittstelle verlässt, kann es danach nicht mehr zu "eth1" geroutet werden. Das Routing erfolgt * immer * nach Zielort. Kannst du den * Grund * erklären, warum du deinen Ping brauchst, um sich so zu verhalten? Wenn Sie die Weiterleitung von "eth3" an "eth1" testen möchten, müssen Sie "eth3" von außen anrufen, dh von einem anderen Computer, der mit diesem LAN-Segment verbunden ist. Oder es gibt eine Möglichkeit, * eindringende * Pakete unter 'eth3' zu simulieren, jedoch nicht mit 'ping'.
dirkt vor 7 Jahren
1
dirkt, ich habe meinen ursprünglichen Beitrag erweitert, um deine Fragen zu beantworten.
Dave vor 7 Jahren
0
Ich glaube, dies könnte ein Problem des RFC 1122 "starkes Hostmodell" vs. "schwaches Hostmodell" sein. Ich untersuche, wie ich Linux so konfigurieren kann, dass es das schwache Hostmodell verwendet (wenn es tatsächlich das starke Hostmodell verwendet).
Dave vor 7 Jahren
0
Moderatoren: Ist es möglich, einen Link in die Stack-Exchange-Gruppe "Unix & Linux" zu setzen, damit dieser Thread auch dort angezeigt wird? Es mag durchaus Leute in diesem Forum geben, die diese Frage beantworten könnten.
Dave vor 7 Jahren
0
Sie finden Ihre Antwort hier [https://serverfault.com/questions/127636/force-local-ip-traffic-to-an-external-interface).
harrymc vor 7 Jahren
1
2 Antworten auf die Frage
1
dirkt
(Ich lasse die andere Antwort wegen der Kommentare).
Beschreibung der Aufgabe: Wenn ein einzelner virtueller Host in einem LXC-Container mit zwei Netzwerkschnittstellen eth1und eth3, die sich in verschiedenen LAN-Segmenten befinden und extern über Router verbunden sind, beschrieben wird, wie kann ein "Bumerang" -Ping implementiert werden, der auf eth3und zurück bleibt eth1(oder umgekehrt) umgekehrt)?
Das Problem hierbei ist, dass der Linux-Kernel erkennt, dass die Zieladresse zugewiesen ist eth1, und versucht, die Pakete direkt zuzustellen eth1, selbst wenn die Routingtabellen vorschreiben, dass die Pakete über geleitet werden sollen eth3.
Es ist nicht möglich, die IP-Adresse einfach zu entfernen eth1, da der Ping beantwortet werden muss. So ist die einzige Lösung ist irgendwie zwei unterschiedliche Adressen zu verwenden (oder zu trennen eth1und eth3voneinander).
Eine Möglichkeit, dies zu tun, ist zu verwenden iptables, wie in dieser Antwort durch harrymc in den Kommentaren verknüpft.
Eine andere Methode, die ich auf meinem Computer mit dem folgenden Setup getestet habe, wobei ein Netzwerk-Namespace zur Simulation des externen Netzwerks und zwei Netzwerk-Namespaces zum Trennen der Ziel-IP-Adressen verwendet wurden:
Die Routing NSWeiterleitung ist aktiviert. Die zusätzlichen 10.0.*.2Adressen werden einem IPVLAN- Gerät zugewiesen, das man sich als zusätzliche IP-Adresse vorstellen kann, die der Master-Schnittstelle zugewiesen ist, mit der es verbunden ist. Weitere Details zu IPVLAN finden Sie hier . Erstellen Sie wie
ip link add ipvl0 link veth0a type ipvlan mode l2 ip link set ipvl0 netns nsx
Wo nsxist der neue Netzwerk-Namespace, dann in diesem Namespace,
ip netns exec nsx ip addr add 10.0.0.2/24 dev ipvl0 ip netns exec nsx ip link set ipvl0 up ip netns exec nsx ip route add default via 10.0.0.1 dev ipvl0
Das Main NShat die folgenden Routing-Regeln zusätzlich zu den Standardregeln
ip route add 10.0.0.2/32 via 10.0.1.1 dev veth1a ip route add 10.0.1.2/32 via 10.0.0.1 dev veth0a
und dann ping 10.0.0.2wird eine „Bumerang“ Rundreise machen, wie durch gesehen werden tcpdumpauf beide veth0aund veth1a. Mit diesem Setup kann also die gesamte Protokollierung von Main NSPinging usw. aus durchgeführt werden, aber für ausgefallenere Tests mit ncusw. sind möglicherweise die anderen Namespaces erforderlich, um zumindest einen Empfänger usw. bereitzustellen.
Der LXC-Container verwendet Netzwerk-Namespaces (und andere Namespaces). Ich bin mit LXC-Containern nicht so vertraut, aber wenn das Erstellen neuer Netzwerk-Namespaces innerhalb des Containers blockiert wird, können Sie von außerhalb des Containers arbeiten. Identifizieren Sie zuerst den Namen des Containers mit
ip netns list
und dann ip netns exec NAME_OF_LXC_NS ...wie oben beschrieben. Sie können auch verzögern zu bewegen eth1und eth3in den LXC Behälter, und zuerst die beiden IPVLANs erstellen, und dann in den Behälter bewegen. Skript entsprechend.
Bearbeiten
Es gibt eine dritte Variante, die ohne Netzwerknamensräume funktioniert. Der Trick besteht darin, das Richtlinienrouting zu verwenden und der lokalen Suche eine höhere ("schlechtere") Priorität als normal zu geben und Pakete von einem an eine bestimmte Schnittstelle gebundenen Socket unterschiedlich zu behandeln. Dies verhindert die Zustellung an die lokale Adresse, die die Hauptursache des Problems war.
Mit dem gleichen Simulationsaufbau wie oben ohne IPVLANs,
ip rule add pref 1000 lookup local ip rule del pref 0 ip rule add pref 100 oif veth0a lookup 100 ip rule add pref 100 oif veth1a lookup 101 ip route add default dev veth0a via 10.0.0.1 table 100 ip route add default dev veth1a via 10.0.1.1 table 101
Ich habe es auch versucht ncoder socat, aber ich konnte sie nicht zum Laufen bringen, weil es keine Optionen gibt nc, um den Hörer zu zwingen, auf einem bestimmten Gerät zu antworten, und obwohl es eine solche Option socatgibt, scheint es keine Wirkung zu haben .
Mit diesem Setup sind Netzwerktests über Pings hinaus etwas eingeschränkt.
0
dirkt
Zusammenfassend haben Sie die folgende Konfiguration:
Im Haupthost /proc/sys/net/ipv4/ip_forwardist aktiviert, und Sie möchten testen, ob die Verbindung zwischen Host 1 und Host 2 funktioniert.
Erinnern Sie sich schnell daran, wie Linux IP-Pakete pro Schnittstelle verarbeitet:
Ein eindringendes Paket von der physikalischen Schicht durchquert also PREROUTINGdie Eintrittsschnittstelle, wird dann nach dem Ziel geroutet, dann POSTROUTINGvon der Austrittsschnittstelle durchlaufen und tritt auf die physikalische Schicht auf. Umgekehrt pingsenden Anwendungen wie Pakete an die OUTPUTKette, werden sie geroutet (im Bild nicht dargestellt), durchlaufen die POSTROUTINGKette und schließlich treten sie aus.
Hier verwende ich Eindringung im Sinne von "tritt in die physikalische Schicht" ein und Austritt im Sinne von "Verlasse die physikalische Schicht".
Was Sie versuchen zu tun ist, um irgendwie dem Linux - Kernel nicht zu sagen, Pakete auf diese Weise zu handhaben, sondern um ein Paket zu simulieren Zutritte auf eth3die Anwendung mit ping, das sollte dann geroutet eth1, wo es Ausläufe .
Das funktioniert aber einfach nicht : Anwendungen senden Pakete über die OUTPUTKette. Wenn Sie mit der Option pingeine Bindung erzwingen, entscheidet Linux einfach, dass dies die falsche Schnittstelle für das Paket ist, und legt das Paket ab. Es wird niemals versuchen, das Paket so zu behandeln, als würde es in das Paket eindringen .eth3-Ieth3
Der normale Weg, dies zu tun, besteht darin, einfach den Ping von Host 1 zu senden und zu überprüfen, ob er auf Host 2 (und der anderen Richtung) ankommt. Schön, einfach und leicht, keine Verzerrungen nötig.
Als „Haupt Host“ virtuell ist, eth1und eth3sind sehr wahrscheinlich nicht real Schnittstellen (Sie hat nicht gesagt). Wenn sie nur ein Ende eines veth-Paars sind, ist es einfach, das andere Ende zu ergattern und einfach das pingan diesem Ende zu erzeugen (wo auch immer es gerade ist).
Wenn Sie darauf bestehen, alles auf "Main Host" zu testen, können Sie auch einige Verzerrungen durchgehen und eine Brücke eth3zu einem anderen veth-pair der Schnittstelle und dann pingam anderen Ende dieses veth-pair herstellen. Da das Paket aus dem veth überbrückt wird, wird es als behandelnde eindringende in eth3, so dass das tut, was Sie wollen. Aber es ist wirklich unnötig kompliziert.
Ich kenne keine anderen Möglichkeiten, um einfallende Pakete zu simulieren .
Sie versuchen vielleicht etwas iptableMagie, aber wenn Sie versuchen, Ihre Netzwerkverbindung zu testen, ist das eine schlechte Idee: Sie werden nie wissen, dass Ihre iptablesRegeln auch für echten Datenverkehr funktionieren, denn dies ist nicht das, was Sie testen.
dirkt, danke für diese Antwort. Ich werde es mir in ein paar Stunden genauer ansehen (sicher, bevor die Kopfgeldperiode endet). Aber ein paar kurze Kommentare ... Ich habe * nicht / proc / sys / net / ipv4 / ip_forward aktiviert, ich versuche nicht, meine Dual-NIC-VM als Router zu verwenden. Ich versuche vielmehr, dass es sich wie zwei Hosts verhält.
Dave vor 7 Jahren
0
Außerdem versuche ich nicht, den Ein- und Austritt zu simulieren. Wenn es mir gelingt, dies nach Belieben zu arbeiten, wird der Ping wirklich aus einer der physischen Schnittstellen des Hypervisors austreten und zu einem realen, physischen, drahtgebundenen TCP gelangen / IP-Intranet, lassen Sie sich dahin zurückleiten, wo er wieder in dieselbe physische Hypervisor-Schnittstelle eindringt, und erhalten Sie den Stack des Hypervisors über die virtuelle Schnittstelle, die eth3 in meiner VM entspricht.
Dave vor 7 Jahren
0
dirkt, du hast recht, ich habe nicht gesagt, ob eth1 und eth3 physischen Schnittstellen entsprechen. eth1 und eth3 entsprechen tatsächlich einer physischen Schnittstelle am Hypervisor. Sie entsprechen jedoch der * gleichen * physikalischen Schnittstelle. Sie haben * nicht * jeweils eine * eigene * physikalische Schnittstelle zugewiesen.
Dave vor 7 Jahren
0
Vielleicht verstehe ich dein Setup immer noch nicht. "Eth3" und "eth1" sind also miteinander verbunden (wie? Über mehrere Router? Sie befinden sich nicht im selben LAN-Segment), und das Problem besteht darin, dass Sie den Linux-Kernel benötigen, wenn Sie "ping 128.66.200.10" machen zu ignorieren, dass diese Adresse bereits auf "eth1" vorhanden ist, und stattdessen durch "eth3" geleitet wird, wo sie durch das Netzwerk reisen und zu "eth1" zurückkehren wird? Wenn das stimmt, habe ich Ihre Frage völlig falsch verstanden ...
dirkt vor 7 Jahren
0
In diesem Fall ist die einfachste Lösung, die ich mir vorstellen kann, einen zusätzlichen Netzwerk-Namespace (etwa "Mini-virtueller Host"), so dass Sie eine ähnliche Situation wie zuvor haben, aber jetzt die Protokollierung in einem einzelnen virtuellen Host durchführen kann. Ich glaube nicht, dass eine Route, die mit einer Schnittstellenadresse in Konflikt steht, zum Laufen gebracht werden kann (möglicherweise mit etwas "iptables" -Magie, aber das müsste ich versuchen).
dirkt vor 7 Jahren
0
Die von harrymc verknüpfte [Antwort] (https://serverfault.com/a/128680/378724) ist eine Möglichkeit, dies mit `iptables 'zu tun. Das Problem wird durch die Einführung zusätzlicher Adressen umgangen, so dass das Routing nicht durcheinander geraten und anschließend NATinget werden, so dass sie äußerlich Ihren Wünschen entsprechen. Ich bin mir nicht sicher, welche Variante ich bevorzugen würde. Es hängt wirklich davon ab, welche Art von Tests Sie durchführen und welche Protokolle Sie benötigen.
dirkt vor 7 Jahren
0
