Vor kurzem war ich mit einer Situation konfrontiert, in der zwei IP-Adressen in demselben Subnetz benötigt wurden, die einem Linux-Host zugewiesen waren, damit wir zwei SSL / TLS-Sites ausführen konnten. Mein erster Ansatz war die Verwendung von IP-Aliasing, z. B. mit eth0: 0, eth0: 1 usw., aber unsere Netzwerkadministratoren haben einige ziemlich strenge Einstellungen für die Sicherheit vorgenommen, die diese Idee zunichte gemacht haben:
- Sie verwenden DHCP-Snooping und erlauben normalerweise keine statischen IP-Adressen. Die statische Adressierung erfolgt über statische DHCP-Einträge, sodass dieselbe MAC-Adresse immer dieselbe IP-Zuweisung erhält. Diese Funktion kann pro Switchport deaktiviert werden, wenn Sie danach fragen und Sie einen Grund dafür haben (zum Glück habe ich eine gute Beziehung zu den Netzwerk-Jungs und das ist nicht schwer zu tun).
- Da das DHCP-Snooping für den Switchport deaktiviert war, mussten sie für den Switch eine Regel festlegen, dass die MAC-Adresse X die IP-Adresse Y haben darf. Leider hatte dies den Nebeneffekt, dass auch die MAC-Adresse X NUR darf IP-Adresse Y. Für das IP-Aliasing war es erforderlich, dass der MAC-Adresse X zwei IP-Adressen zugewiesen wurden, sodass dies nicht funktionierte.
Möglicherweise gab es einen Ausweg aus diesen Problemen bei der Switch-Konfiguration, aber in dem Versuch, gute Beziehungen zu den Netzwerkadministratoren aufrechtzuerhalten, habe ich versucht, einen anderen Weg zu finden. Zwei Netzwerkschnittstellen zu haben schien der nächste logische Schritt zu sein. Zum Glück ist dieses Linux-System eine virtuelle Maschine, daher konnte ich problemlos eine zweite Netzwerkschnittstelle hinzufügen (ohne Neustart, könnte ich hinzufügen - ziemlich cool). Ein paar Tastenanschläge später hatte ich zwei Netzwerkschnittstellen in Betrieb und beide zogen IP-Adressen von DHCP.
Aber dann trat das Problem auf: Die Netzwerkadministratoren konnten (auf dem Switch) den ARP-Eintrag für beide Schnittstellen sehen, aber nur die erste Netzwerkschnittstelle, die ich aufrief, reagierte auf Pings oder jede Art von TCP- oder UDP-Verkehr.
Nach vielem Graben und Stöbern habe ich mir Folgendes ausgedacht. Es scheint zu funktionieren, aber es scheint auch eine Menge Arbeit für etwas zu sein, das so aussieht, als ob es einfach sein sollte. Gibt es alternative Ideen?
Schritt 1: Aktivieren Sie die ARP-Filterung für alle Schnittstellen:
# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf
Aus der Datei networking / ip-sysctl.txt in den Linux-Kerneldokumenten:
arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.
0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.
arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise
Schritt 2: Implementieren Sie quellbasiertes Routing
Ich bin im Grunde nur den Anweisungen von http://lartc.org/howto/lartc.rpdb.multiple-links.html gefolgt , obwohl diese Seite mit einem anderen Ziel geschrieben wurde (mit zwei ISPs).
Angenommen, das Subnetz ist 10.0.0.0/24, das Gateway ist 10.0.0.1, die IP-Adresse für eth0 ist 10.0.0.100 und die IP-Adresse für eth1 ist 10.0.0.101.
Definieren Sie zwei neue Routingtabellen mit den Namen eth0 und eth1 in / etc / iproute2 / rt_tables:
... top of file omitted ...
1 eth0
2 eth1
Definieren Sie die Routen für diese beiden Tabellen:
# ip route add default via 10.0.0.1 table eth0
# ip route add default via 10.0.0.1 table eth1
# ip route add 10.0.0.0/24 dev eth0 src 10.0.0.100 table eth0
# ip route add 10.0.0.0/24 dev eth1 src 10.0.0.101 table eth1
Definieren Sie die Regeln für die Verwendung der neuen Routingtabellen:
# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1
Die Hauptrouting-Tabelle wurde bereits von DHCP verwaltet (und es ist nicht einmal klar, dass dies in diesem Fall unbedingt erforderlich ist), entspricht jedoch im Wesentlichen dem Folgenden:
# ip route add default via 10.0.0.1 dev eth0
# ip route add 130.127.48.0/23 dev eth0 src 10.0.0.100
# ip route add 130.127.48.0/23 dev eth1 src 10.0.0.101
Und voila! Alles scheint gut zu funktionieren. Das Senden von Pings an beide IP-Adressen funktioniert einwandfrei. Das Senden von Pings von diesem System an andere Systeme und das Erzwingen, dass der Ping eine bestimmte Schnittstelle verwendet, funktioniert einwandfrei ( ping -I eth0 10.0.0.1, ping -I eth1 10.0.0.1). Und am wichtigsten ist, dass der gesamte TCP- und UDP-Verkehr von / zu einer der IP-Adressen wie erwartet funktioniert.
Meine Frage lautet also erneut: Gibt es einen besseren Weg, dies zu tun? Dies scheint eine Menge Arbeit für ein scheinbar einfaches Problem zu sein.
Update: Die oben genannte Lösung ist unvollständig. Wenn der Datenverkehr im selben Subnetz verbleibt, funktioniert die Kommunikation mit anderen Subnetzen über die zweite Schnittstelle nicht ordnungsgemäß. Anstatt ein größeres Loch zu graben, habe ich mich mit den Netzwerkadministratoren unterhalten und sie dazu gebracht, mehrere IP-Adressen für eine Schnittstelle zuzulassen und IP-Aliasing zu verwenden (z. B. eth0 und eth0: 0).
ipfrom iproute2, um mehr als eine Adresse zur gleichen Schnittstelle hinzuzufügen.