So senden Sie unter Linux Pakete mit lokalem Ziel NICHT über die Loopback-Schnittstelle

So senden Sie unter Linux Pakete mit lokalem Ziel NICHT über die Loopback-Schnittstelle

Ich habe einen Linux-Server mit zwei Ethernet-Schnittstellen, die mit demselben Switch verbunden sind und sich im selben Subnetz befinden. Die Topologie ist wie folgt

+--------------------+
|                    |
|         +----------+        +----------+
|         | enp1s0f0 |<======>|          |
|         +----------+        | ethernet |
|  Server            |        |          |
|         +----------+        |  switch  |
|         | enp1s0f1 |<======>|          |
|         +----------+        +----------+
|                    |
+--------------------+

Die IP-Adressen dieser beiden Schnittstellen sind 172.16.0.100bzw. 172.16.1.100.

$ ip addr
...
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 10:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 172.16.0.100/16 brd 172.16.255.255 scope global noprefixroute enp1s0f0
       valid_lft forever preferred_lft forever
5: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 10:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.100/16 brd 172.16.255.255 scope global noprefixroute enp1s0f1
       valid_lft forever preferred_lft forever
...

enp1s0f0Jetzt möchte ich Pakete von und über den externen Switch senden enp1s0f1(zu Testzwecken kommunizieren aus Sicht des Switches zwei einzelne Computer miteinander). Daher binde ich die lokale Adresse des Sockets an 172.16.0.100 und verbinde sie mit 172.16.1.100 (zum Beispiel mit dem telnet -b 172.16.0.100 172.16.1.100 22Befehl). Ich kann jedoch nur sehen, wie diese Pakete durch die loSchnittstelle gehen (indem ich erfasste Pakete überprüfe), und nicht durch diese beiden Ethernet-Schnittstellen und den Switch.

Meine erste Frage ist alsowie kann ich Linux zwingen, diese Pakete mit lokalem Ziel über eine externe Schnittstelle zu senden?

Ich denke, ich habe Adressen und Routingtabelle richtig eingestellt. Die Routingtabelle enthält folgende Einträge

$ ip route
...
172.16.0.0/16 dev enp1s0f0 proto kernel scope link src 172.16.0.100 metric 100
172.16.0.0/16 dev enp1s0f1 proto kernel scope link src 172.16.1.100 metric 101

Und die ARP-Tabelle scheint auch richtig konfiguriert zu sein

$ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
172.16.1.100             ether   10:00:00:00:01:00   CM                    enp1s0f0
172.16.0.100             ether   10:00:00:00:00:00   CM                    enp1s0f1

Allerdings routet Linux diese Pakete weiterhin über die loSchnittstelle

$ ip route get from 172.16.0.100  172.16.1.100
local 172.16.1.100 from 172.16.0.100 dev lo uid 1000
    cache <local>
$ ip route get from 172.16.1.100  172.16.0.100
local 172.16.0.100 from 172.16.1.100 dev lo uid 1000
    cache <local>

Ich habe auch versucht ping, von diesen Schnittstellen aus zu ing, z. B. ping -I enp1s0f0 172.16.1.100. Die erfassten Pakete zeigen, dass die gesendeten ICMP-Pakete wie erwartet über den Switch am Ziel ankommen können, jedoch keine Antwortpakete auf der enp1s0f1Schnittstelle zu sehen sind. Ich habe nach einer Lösung für dieses Problem gesucht und gefundenDasAntwort, und es heißt, dass dies zusammenhängen könnte mitRückwärtspfadfilterung. Ich habe also versucht, es zu deaktivieren, rp_filterindem ich den Standardwert und rp_filterden Wert der Schnittstellen auf 0 oder 2 gesetzt habe, aber das hat das Problem nicht gelöst. Meine zusätzliche Frage istist meine Konfiguration korrekt und wie bringe ich Linux dazu, in dieser Situation auf ICMP-Ping-Pakete zu antworten?

Mein Betriebssystem ist Ubuntu 20.04 und ICMP-Antworten funktionieren auf anderen Schnittstellen gut und es sind keine iptable-Einträge konfiguriert.

verwandte Informationen