Ich habe ein Problem. Alle meine Maschinen befinden sich hinter einem Router, der mit einem ETH-Port am Modem verbunden ist. Dieser Port ist beim Download/Upload zu eingeschränkt. Also habe ich versucht, zwei Kabel vom Router an zwei Ports mit dem Modem zu verbinden. Ich habe lange daran gearbeitet, dieses Problem zu lösen, aber ich weiß nicht mehr, was ich versuchen soll.
Mein Router hat 4 Schnittstellen:
enp1s0f0 172.16.0.3
enp4s0f1 10.0.0.6
enp1s0f1 192.168.0.3
enp4s0f0 192.168.0.6
Wie Sie sehen, befinden sich eth3 und eth4 im selben Netzwerk, was seltsam ist. Das musste so sein, wenn ich über zwei ETH-Ports eine Verbindung zum Modem (192.168.0.1) herstellen wollte.
Also, hier ist, was ich versucht habe:
echo "1 myorg" >> /etc/iproute2/rt_tables #added a custom routing table myorg
sudo ip route add 192.168.0.1 scope link dev enp4s0f0 #don't know if it is really necessary
sudo ip rule add from 192.168.0.6 table myorg
sudo ip route add default via 192.168.0.1 dev enp4s0f0 table myorg #second default gateway through myorg table
Als Ergebnis erhalte ich diese Routen:
$ ip -4 route show table main
default via 192.168.0.1 dev enp1s0f1 onlink
10.0.0.0/24 dev enp4s0f1 proto kernel scope link src 10.0.0.6
172.16.0.0/24 dev enp1s0f0 proto kernel scope link src 172.16.0.3
192.168.0.0/24 dev enp1s0f1 proto kernel scope link src 192.168.0.3
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.6
192.168.0.1 dev enp4s0f0 scope link
$ ip -4 route show table myorg
default via 192.168.0.1 dev enp4s0f0
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 enp1s0f1
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f1
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f0
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp4s0f0
Ich verwende ufw als NAT-Firewall. Ich habe im Abschnitt *nat Folgendes hinzugefügt:
:POSTROUTING ACCEPT - [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o enp1s0f1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -o enp4s0f0 -j MASQUERADE
Das Problem ist, dass entweder Maschinen im Netzwerk 10.0.0.0 eine Ping-Antwort vom Modem (Gateway 192.168.0.1) erhalten oder die Maschinen im Netzwerk 172.16.0.0. Je nach Situation kann es auch andersherum sein, ich weiß nicht, warum.
Mein Modem erkennt beide Clients 192.168.0.3 und 192.168.0.6 auf zwei ETH-Ports.
Ist es also mit dieser Topologie (Router mit zwei Schnittstellen im selben Netzwerk) möglich, auf allen Maschinen und allen Netzwerken WAN-Zugriff zu haben?
Antwort1
Auch wenn es nicht explizit geschrieben steht, besteht das Ziel vermutlich darin, den Verkehr folgendermaßen aufzuteilen:
- 172.16.0.0/24 Datenverkehr fließt durch enp1s0f1
- 10.0.0.0/24 Datenverkehr fließt durch enp4s0f0
Wie OP schrieb, ist hierfür ein richtlinien-/quellenbasiertes Routing erforderlich.iptablesUndNetzfiltersind selten nützlich (zumindest allein):
- allgemein gesagtiptablesUndNetzfilterrouten nicht und kümmern sich nicht um Routen. Der Netzwerk-Routing-Stack routet. Einige deriptables'-Aktionen führen weiterhin zu Änderungen der Routing-Entscheidungen (wie in diesemschematisch)
- jede Handlung, die inNach dem Routing, wie der Name schon sagt, geschiehtnachEntscheidungen zur Streckenführung wurden getroffen: Es ist zu spät, die Route zu ändern. Hier, während dienat/POSTROUTINGRegeln sind erforderlich, sie ändern die Route nicht.
Wann immeriptableskann vermieden werden, um ein Routing-Problem zu lösen, vermeiden Sie es besser. Manchmal kann es nicht vermieden werden (und dann in der Regeliptableswird verwendet, um Paketen eine Markierung hinzuzufügen und diese Markierung wird in einem ip ruleEintrag verwendet).
Routen
Ich gehe davon aus, dassrp_filter=1ist auf allen Schnittstellen eingestellt, da dies bei den meisten Distributionen der Standard ist, umStrikte Reverse Path Forwarding.
Die Quelladresse wird per Regel ausgewählt, das Ziel per Routing-Tabelle. Die zusätzlichen Routing-Tabellen sollten genügend Informationen enthalten, um Routen (ohne Mehrdeutigkeiten) zu überschreiben, wenn nur eine von mehreren ausgewählt werden soll (dann wird nur diese zur Tabelle hinzugefügt). Oft müssen auch zusätzliche Routen aus der Haupttabelle kopiert werden, sonst können schlimme Dinge passieren.
In meiner Antwort werde ich keinem Netzwerk den Vorzug geben: Jedes erhält seine eigene Routing-Tabelle. Ich werde Tabelle 1 vergessen und die Tabellen 10 für LAN 10.0.0.0/24 und 172 für LAN 172.16.0.0/24 verwenden. Behalten Sie die NAT-Regeln bei, entfernen Sie die Regeln und zusätzlichen Routing-Tabellen sowie 192.168.0.1 dev enp4s0f0 scope linkdie Haupttabellen.
Routen für 10.0.0.0/24 <--> 10.0.0.6 enp4s0f0 | enp4s0f1 192.168.0.6 <--> 192.168.0.1/Standard:
ip rule add from 10.0.0.0/24 lookup 10 ip route add table 10 10.0.0.0/24 dev enp4s0f1 ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6 ip route add table 10 default via 192.168.0.1
Ohne den duplizierten Routeneintrag für 10.0.0.0/24 wäre das System nicht in der Lage, selbst auf dieses LAN zuzugreifen: Es würde die Route so auflösen, dass sie über das Standard-Gateway gehen muss, nur fürStrikte Reverse Path Forwarding(SRPF)-Zwecke, die das Debuggen erschweren. Das ist ein Beispiel für eine schlechte Sache, wenn es nicht hinzugefügt wird. Im Zweifelsfall duplizieren Sie einfach die Routen.
Eine andere gleichwertige Option hätte darin bestehen können, anstelle der zusätzlichen Route die obige Regel wie folgt zu ändern:
ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10
Daher wäre es für den lokalen (nicht gerouteten) Datenverkehr nicht zutreffend und es würde nur die Haupttabelle verwendet.
Routen für 172.16.0.0/24 <--> 172.16.0.3 enp1s0f0 | enp1s0f1 192.168.0.3 <--> 192.168.0.1/Standard:
ip rule add from 172.16.0.0/24 lookup 172 ip route add table 172 172.16.0.0/24 dev enp1s0f0 ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3 ip route add table 172 default via 192.168.0.1Um auch die Route (den Link) für lokal initiierten ausgehenden Datenverkehr zu ändern, wenn die ausgehende Quell-IP-Adresse auf dem Linux-System geändert wird. Dies sollte optional sein, wird aber im nächsten Teil über ARP-Flux zwingend vorgeschrieben:
ip rule add from 192.168.0.6 lookup 10 ip rule add from 192.168.0.3 lookup 172Jeder nicht-Sonderfall, der die überschriebenen Routen aus den Regeln betrifft, muss ebenfalls dupliziert werden
Hier fehlen lediglich die Routen zwischen den beiden speziellen LANs selbst:
in Tabelle 10, um 172.16.0.0/24 zu erreichen
in Tabelle 172, um 10.0.0.0/24 zu erreichen
Da jede zusätzliche Tabelle noch keine Route für die andere Seite hat, würde sie die Standardroute verwenden (würde aber erneut von SRPF blockiert werden), wodurch die beiden Spezialnetzwerke nicht mehr miteinander kommunizieren könnten. Dupliziere also einfach die fehlende Route für jede Tabelle:
ip route add table 10 172.16.0.0/24 dev enp1s0f0
ip route add table 172 10.0.0.0/24 dev enp4s0f1
Wenn bei diesem Modell beispielsweise zwei weitere „normale“ interne Netzwerke hinzugefügt würden, könnten diese ohne zusätzliche Einstellungen untereinander kommunizieren (und würden die Standardroute der Haupttabelle nach außen verwenden), aber zur Kommunikation mit den beiden speziellen LANs wäre erneut eine Duplizierung ihrer Routen in jeder zusätzlichen Routing-Tabelle erforderlich.
Die Routen sind jetzt in Ordnung, aber es gibt immer noch …
DerARP-FlussProblem
Linux folgt demschwaches Wirtsmodell. Das ist beim IP-Routing der Fall und ebenso bei der Art und Weise, wie Linux ARP-Anfragen beantwortet: von jeder Schnittstelle für jede IP, aber natürlich unter Verwendung der eigenen MAC-Adresse der Schnittstelle. Da dies auf allen Schnittstellen gleichzeitig passieren kann, wenn sich mehrere Schnittstellen im selben LAN befinden, gewinnt normalerweise die schnellste. Dann werden die ARP-Informationen auf dem Remote-System zwischengespeichert und bleiben dort für einige Zeit. Wenn der Cache irgendwann abläuft, passiert dasselbe, möglicherweise mit einem anderen Ergebnis. Wie also verursacht dies ein Problem? Hier ist ein Beispiel:
- Der Router (Modem) sendet eine ARP-Anfrage für 192.168.0.6, um eine geroutete und NAT-basierte (von Linux) Antwort auf den Datenverkehr zurückzusenden, der ursprünglich von 10.0.0.0/24 gesendet wurde.
- Linux antwortet aufenp1s0f1(enp1s0f1hat das Rennen gewonnen) mitenp1s0f1Geben Sie als Antwort die MAC-Adresse 192.168.0.6 ein.
- Für einige Sekunden bis einige Minuten kommen zukünftige eingehende IP-Pakete vom Router für 192.168.0.6 anenp1s0f1,
- gleichzeitigAusgangPakete von 192.168.0.6 verlassen mitenp4s0f0.
Dieses asymmetrische Routing wird aufgefangen durchStrikte Reverse Path Forwarding(rp_filter) und der Datenverkehr wird fehlschlagen. Dies kann sogar für einige Sekunden scheinbar zufällig funktionieren und dann wieder fehlschlagen. Abhängig vom Gesamtverkehr kann das Problem später sogar auf die andere Verbindung wechseln (und dann wechseln die Probleme auf das andere LAN).
Um dies zu verhindern, bietet Linux glücklicherweise eine Einstellung, die nur zusammen mit Policy-Routing verwendet werden kann und dafür sorgt, dass ARP den gleichen Regeln folgt, die durch das Routing definiert werden:arp_filter.
arp_filter - BOOLEAN
1 - Ermöglicht Ihnen, mehrere Netzwerkschnittstellen im selben Subnetz zu haben und die ARPs für jedeSchnittstellebeantwortet werden auf der Grundlage vonob der Kernel ein Paket von der ARP-IP über diese Schnittstelle weiterleitet oder nicht(daherSie müssen quellenbasiertes Routing verwendendamit dies funktioniert). Mit anderen Worten ermöglicht es die Kontrolle darüber, welche Karten (normalerweise 1) auf eine ARP-Anfrage antworten.
sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1
Jetzt ist das ARP-Verhalten korrekt. Wenn die Einstellungen gerade vorgenommen wurden, sollte man den ARP-Cache zwangsweise leeren.Gleichaltrige(hier: das Modem) durch eine Duplikatserkennung mitarping(ausiputils/iputils-arping), das an die Peers sendet und sie dazu veranlasst, ihren Cache zu aktualisieren:
arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3
Beachten Sie, dass die beiden Regeln in Aufzählungspunkt 3 im vorherigen Teil jetzt obligatorisch sind, da die IP-Adressen 192.168.0.3 und 192.168.0.6 in den Richtlinien-Routingregeln für eine korrekte ARP-Auflösung übereinstimmen müssen arp_filter=1.
So debuggen Sie
ip route getist sehr nützlich zum Überprüfen von Routen und zum umgekehrten Pfadfiltern:
neuer Testfall für Punkt 4 oben:
# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10
cache iif enp4s0f0
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172
cache iif enp1s0f0
beim Löschen von Regeln oder Routen:
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10
cache iif enp4s0f1
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link
Dies zeigt, wie sich die Ergebnisse je nach (fehlenden) Regeln und zusätzlichen Routen ändern. Das letzte Ergebnis ist die Fehlermeldung, die besagt, dass die Prüfung der Rückwärtspfadweiterleitung fehlgeschlagen ist (=> Abbruch).
Dann gibt es ip neigh(am nützlichsten aufPeerSysteme), um ARP-Einträge tcpdumpusw. zu überprüfen.