Es gibt zwei mögliche Entwurfsmodelle für einen TCP/IP-Netzwerkstapel:ein starkes Hostmodell und ein schwaches Hostmodell. Sie erwarten ein Verhalten, das dem starken Hostmodell entspricht. Linux ist darauf ausgelegt, das schwache Host-Modell zu verwenden. Im Allgemeinen ist das schwache Host-Modell üblicher, da es die Komplexität des Routing-Codes reduziert und somit möglicherweise eine bessere Leistung bietet. Ansonsten sind die beiden Host-Modelle nur unterschiedliche Designprinzipien:Keines ist von Natur aus besser als das andere.
Grundsätzlich bedeutet das schwache Hostmodell, dass ausgehender Datenverkehr ohne Rücksicht auf die erste in der Routing-Tabelle aufgeführte Schnittstelle gesendet wird, die mit der IP-Adresse des Ziels (oder des ausgewählten Gateways, wenn das Ziel nicht direkt erreichbar ist) übereinstimmt die Quell-IP-Adresse .
Aus diesem Grund ist es im Allgemeinen nicht ratsam, zwei separate physikalische Schnittstellen zu verwenden, wenn Sie zwei IP-Adressen im selben Netzwerksegment benötigen. Vergeben Sie stattdessen zwei IP-Adressen für eine Schnittstelle (IP-Aliase:z. B. eth1 =192.168.8.142 und eth1:0 =192.168.8.140). Wenn Sie mehr Bandbreite benötigen, als eine einzelne Schnittstelle bereitstellen kann, verbinden (oder verbinden Sie, falls zutreffend) zwei oder mehr Schnittstellen miteinander und führen Sie dann beide IPs auf der Verbindung/dem Team aus.
Indem Sie eine Reihe von sysctl-Einstellungen optimieren und die „erweiterte Routing“-Funktion verwenden, um unabhängige Routing-Tabellen für jede NIC einzurichten, ist es möglich, Linux dazu zu bringen, sich wie ein System mit starkem Host-Modell zu verhalten. Aber das ist eine sehr spezielle Konfiguration, und ich würde empfehlen, zweimal darüber nachzudenken, bevor Sie sie implementieren.
Siehe die Antworten unter Linux Source Routing, Strong End System Model / Strong Host Model? wenn du es wirklich brauchst.
Ein weiterer zu berücksichtigender Punkt ist, dass die eth1-Schnittstelle mit einer Subnetzmaske von 255.255.255.255 konfiguriert ist.
Das bedeutet, dass die eth1-Schnittstelle so konfiguriert ist, dass sie keine anderen Geräte (Hosts) an ihrer Netzwerkschnittstelle erwartet. Dies bedeutet, dass es nicht mit Ihrem 192.168.8.142-Client kommunizieren kann.
Nach langem Suchen fand ich Warum verwendet netcat nicht die richtige Schnittstelle, die der IP zugeordnet ist? , und das ist das gleiche Problem. Wie @telcoM sagte, wird ausgehender Datenverkehr an die erste Schnittstelle gesendet, und das ist das Problem, also ist der einfachste Weg, dies zu lösen:
ip route add default via 192.168.8.142 dev eth1 table 142
ip rule add from 192.168.8.142 table 142
Diese Route führt zu ip route get 192.168.8.135 from 192.168.8.142 gibt eth1 statt eth0 zurück. Dann funktioniert alles wie erwartet.