
Asymmetrische Routing-Probleme machen mich verrückt!
Ich versuche, einen Multi-Homed-Server mit 3 Netzwerkkarten aufzubauen. Jede Netzwerkkarte ist mit 3 verschiedenen Subnetzen verbunden:
eth0: LAN verbunden, 10.99.72.38; Funktion: Verwaltungsverkehr
eth1: LAN verbunden, 10.99.70.150; Funktion: Benutzerverkehr
eth2: WAN verbunden, 10.99.74.85; Funktion: Benutzerverkehr
Ich verwende ein Amazon Linux-Image (Linux 3.14.20-20.44.amzn1.x86_64 x86_64), aber ich kann zu CentOS wechseln, wenn es wirklich einen Unterschied macht.
Die Funktionalität, die ich zu implementieren versuche:
eth0: Management-Verkehr
- Adresse: 10.99.72.38
- Ich möchte, dass dies eine „isolierte“ Schnittstelle ist, die nur Adressen in 10.0.0.0/8 akzeptiert und beantwortet
- Stellen Sie sich dies als eine Netzwerkkarte „Nur SSH vom lokalen LAN“ vor.
- Kann NUR über eth0 antworten
- Alle anderen Ziele sind gesperrt, d.h. es können keine anderen Ziele über diese Schnittstelle erreicht werden
- Wird eth1 oder eth2 NICHT für Antwortverkehr für Verkehr verwenden, der auf eth0 ankommt.
eth1: Benutzerverkehr zum/vom LAN
- Adresse: 10.99.70.150
- akzeptiert jeglichen Benutzerverkehr vom LAN zu jedem Ziel
- leitet Pakete für den für 10.xxx bestimmten Datenverkehr über eth1 weiter
- leitet Pakete über eth2 an jedes andere Ziel weiter (Standardroute)
- leitet eingehende Pakete NICHT über eth0 weiter
eth2: Benutzerverkehr zum/vom WAN
- Adresse: 10.99.74.85
- akzeptiert jeglichen Benutzerverkehr von eth1 und sendet Pakete über eth2 an alle Ziele, die nicht in 10.xxx sind
- akzeptiert Antwortpakete auf eth2 und leitet den gesamten für 10.xxx bestimmten Datenverkehr über eth1 weiter
- leitet eingehende Pakete NICHT über eth0 weiter
Ich habe in rt_tables eine iproute2-Tabelle namens „mgmt“ erstellt und richtlinienbasierte Routing-Regeln mit hoher Priorität hinzugefügt, um diese Schnittstelle zu isolieren, aber egal, was ich versuche, die Hauptrouting-Tabelle scheint immer noch aufgerufen zu werden, da eth0 die Standardroute ist. Zu den Problemen gehören:
- Eingehende Pakete von eth1 werden über eth0 geleitet (das will ich nicht!)
- Eingehende Pakete von eth2 mit Ziel 10.xxx werden über eth0 geleitet (das will ich nicht!)
- Wenn ich die Standardroute eth0 aus dem Main lösche, geht die Funktionalität von eth0 vollständig verloren, selbst mit einer Route in der Verwaltungstabelle, aber eth1 antwortet dann korrekt.
Beginnen wir von vorne, mit der unveränderten Routentabelle (route -n):
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.99.72.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 10.99.70.1 0.0.0.0 UG 10001 0 0 eth1
0.0.0.0 10.99.74.1 0.0.0.0 UG 10002 0 0 eth2
10.99.70.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.99.72.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.99.74.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
Unveränderte IP-Regeln sind:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Ich wäre für jede Hilfestellung bei der korrekten Formulierung der spezifischen Routing-Regeln, -Tabellen und -Routen sehr dankbar und würde mir auch gerne zeigen, wie die endgültigen Routing-Tabellen und -Regeln aussehen würden.
Antwort1
eth0
Sie sollten die Standard-Gateway-Einstellung für und löschen eth1
. Wie das geht, hängt von Ihrer Distribution ab.
Sie benötigen wahrscheinlich kein Policy-Routing. Ich denke, was Sie wollen, lässt sich am besten mit Netfilter / erreichen iptables
.
iptables -I INPUT 1 -i eth0 ! -s 10.99.72.0/24 -j DROP
iptables -I FORWARD 1 -i eth0 -j DROP
iptables -I FORWARD 2 -o eth0 -j DROP
iptables -I INPUT 2 -i eth1 ! -s 10.0.0.0/8 -j DROP
iptables -I FORWARD 3 -i eth1 -j ACCEPT
iptables -I INPUT 3 -i eth2 -m conntrack --ctstate NEW -j DROP
iptables -I FORWARD 4 -i eth2 -j ACCEPT
Dies kann wahrscheinlich ohne Netfilter, sondern stattdessen mit Policy-Routing erfolgen.