Dieselbe IP auf mehreren Schnittstellen

Hallo Netzwerkgurus,

Ich habe einen Linux-Server (Kernel 3.14), der als TFTP-, NFS- und HTTP-Server für eine Farm von Geräten der Unterhaltungselektronik (Set-Top-Boxen - STBs) fungiert. Die Geräte verwenden TFTP, um ihre Kernel zu starten und dann ihre Root-FSes vom NFS-Server auf unserem Computer usw. bereitzustellen.

Aus einem esoterischen technischen Grund werde ich hier nicht näher darauf eingehen (glauben Sie mir einfach :), jede STB muss sich in einem eigenen, physisch getrennten LAN befinden. Die Art und Weise, wie Netzwerke eingerichtet werden, ist:

Der Server verfügt über 1 Netzwerkkarte, mit der auf den Rest der Welt zugegriffen werden kann. Es hat auch 1 Netzwerkkarte für jede STB, die es bedient - und jede davon ist mit einem kleinen Router verbunden, an den die STB + einige andere Geräte angeschlossen sind und ein LAN bilden.

Derzeit sind 3 STBs verbunden, und die LANs sind 172.16.50.0/24, 172.16.51.0/24 und 172.16.52.0/24. Es funktioniert alles gut.

Die Tatsache, dass wir 3 verschiedene LANs haben, bedeutet, dass auf denselben Server als 172.16.50.1 von STB1, 172.16.51.1 von STB2 und 172.16.52.1 von STB3 zugegriffen werden muss - und das bedeutet, dass wir eine etwas andere Umgebung haben Jedes STB und jedes Mal, wenn wir beispielsweise neues RootFS hochladen, um es auf den STBs zu verwenden, müssen wir einige Konfigurationsdateien manuell bearbeiten und die richtige IP eingeben, auf die der Server von diesem bestimmten STB aus zugreifen muss. Nicht sehr praktisch und fehleranfällig!

Das brachte mich zum Nachdenken: Was wäre, wenn wir diese drei LANs einfach so konfigurieren würden, dass sie alle gleich sind? 172.16.50.0/24? Aus Sicht der STB (und der übrigen Geräte im LAN) sollte alles in Ordnung sein, aber was ist mit der Sicht des Servers?

Kann ein Linux-Server N verschiedene Ethernet-Schnittstellen haben, die alle mit derselben statischen IP konfiguriert sind, aber jeweils mit einem physisch separaten LAN verbunden sind?

linux linux-networking

— Leszek
quelle

Vielleicht könnte uns das Teilen des esoterischen Grundes (obwohl ich glaube, dass es einen Grund gibt) einen Hinweis auf eine Lösungsrichtung geben, da drei separate Netzwerkkarten mit derselben IP-Adresse wahrscheinlich nichts nützen, selbst wenn Sie dies tun Verwenden Sie ein paar Tricks, um es zum Laufen zu bringen. Beispiel: Haben diese STBs den Server als Standard-Gateway, da dies eine Lösung sein könnte?

— Fox

Nein, alle STBs, die mit dem Server arbeiten, starten ihre Kernel und mounten ihre RootFSes von diesem. Nach dem Booten greifen sie auf völlig andere Weise auf das Internet zu und benötigen den Server überhaupt nicht.

— Leszek

Ich fürchte, es wäre nicht einfach, den esoterischen Grund zu teilen, da es derzeit einen E-Mail-Thread mit 3207 E-Mails von 113 verschiedenen Personen aus 4 verschiedenen Unternehmen zu dieser esoterischen "Bug-Slash-Funktion" gibt. Der Thread läuft seit 1,5 Jahren. Ja, ich habe die .odf-Datei aus Outlook heruntergeladen und ein Python-Skript geschrieben, um sie zu analysieren und diese Zahlen zu ermitteln, da ich das Gefühl hatte, dass dies ein Rekordbrecher sein könnte.

— Leszek

Eigentlich war ich nicht daran interessiert zu wissen, wer schuld ist oder aus welchem Grund die STB stammt. Ich war daran interessiert, so etwas zu wissen - Sendungen von einer STB töten die andere oder so etwas. Können Sie Routing-Tabellen auf den STBs beeinflussen?

— Fox

Nun, dies führt mich dazu, die Lösung um Cha0s zu erweitern, indem ich dazwischen ebtables hinzufüge, um den Verkehr von einer STB zur anderen zu filtern. Brücke allein würde zu der Situation führen, in der sich die STBs sehen. Dies kann mit verwalteten Switches und VLANs kombiniert werden. Sie benötigen nur ein VLAN pro STB. Und es ist möglicherweise einfacher zu verwenden als Namespaces.

— Fox

Antworten:

Ja, dies ist mit einer netten Funktion namens network namespaces(siehe man ip-netns(8)) möglich. Grundsätzlich erhalten Sie mehrere unterschiedliche Netzwerkstapel mit jeweils eigenen Schnittstellen, Routen usw.

Sie müssten für jede Ihrer STBs einen Namespace erstellen und könnten dann Ihre erforderlichen Dienste in jedem Namespace separat ausführen.

Für die Namespaces müssten Sie wie folgt vorgehen:

Erstellen Sie einen Namespace mit dem Namen net1:
```
ip netns add net1
```

Weisen Sie Ihre Schnittstelle ethXdem neuen Namespace zu und konfigurieren Sie Ihre IP-Adresse 172.16.50.1:

ip link set dev ethX netns net1
ip netns exec net1 ip link set dev ethX up
ip netns exec net1 ip address add 172.16.50.1/24 dev ethX

Die IP-Adresse 172.16.50.1 ist jetzt in Ihrem Standard-Namespace nicht mehr sichtbar. Ein einfaches ping 172.16.50.1funktioniert nicht, Sie müssen zuerst zum net1Namespace wechseln und dort den Befehl ausführen:

ip netns exec net1 <command>

Auf diese Weise können Sie jetzt jeden Dienst in jedem Ihrer Namespaces ausführen.

Wenn Sie sich abenteuerlustig fühlen, können Sie sogar versuchen, alle Anfragen von Ihren STBs irgendwie an einen zentralen Dienst umzuleiten. Dazu benötigen Sie einen Tunnel von jedem Namespace zu Ihrem Standard-Namespace (siehe ip link help veth) und einige iptables Magie ...

— Oliver
quelle

Ich liebe es, wie du auf SF: D neue Dinge lernen kannst. Danke für deine Infos! Sehr nützlich! Bezieht sich diese Funktion auf VRF? (klingt irgendwie so)

— Cha0s

@ Cha0s Ich weiß nichts über VRF unter Linux, aber netns sieht mit Sicherheit genauso aus wie VRF auf Routern (obwohl es in Bezug auf die Leistung wahrscheinlich nicht dasselbe ist).

— Oliver

Ausgezeichnet! Jetzt hoffe ich, dass Sie diese Idee mit einer anderen kombinieren können: einem verwalteten Switch. Ich möchte die mehreren Netzwerkkarten loswerden. Richten Sie 3 VLANs-ID 2,3,4 ein, ein VLAN für jede STB, richten Sie einen Trunked-Port zum Server ein, drei Schnittstellen eth1.2, eth1.3, eth1.4, jede in einem eigenen Netzwerk-Namespace und mit derselben Statik IP? Das wäre süß.

— Leszek

Oh, also starte ich entweder eine separate Instanz von TFTP-, NFS- und HTTP-Servern in jedem Namespace oder vertiefe mich in das Tunneln von Sachen von den STB-Namespaces zu den Standard-Namespaces? Hmm ...

— Leszek

Ich bin sicher, dass es auch mit dem VLAN funktioniert, sodass Sie nicht für jede Ihrer STBs einen separaten Netzwerkadapter benötigen. Was Ihre andere Frage betrifft, sollte der Tunnel nicht zu schwer zu implementieren sein. Ich würde mit einer gerouteten Lösung mit nur einem STB-Netzwerk beginnen und dann mit iptables an beiden Enden des Tunnels experimentieren. Ich bin kein Iptables-Experte, daher habe ich nicht die erforderlichen Befehle parat, aber ich bin sicher, Sie werden es schaffen (oder vielleicht eine Folgefrage zu SF stellen).

— Oliver

Technisch können Sie, aber die Konfiguration wäre bunt. Es wäre ein Kludge und es würde erfordern, dass jede STB eine eindeutige IP hat, während sie auf ihrem eigenen Draht isoliert ist, um Ihre Anforderung zu erfüllen. Die Konfiguration auf den Clients ändert sich nicht. Hier ist die Konfiguration auf dem Server:

ifconfig eth0 10.0.50.1 netmask 255.0.0.0
route del -net 10.0.0.0 netmask 255.0.0.0 dev eth0
route add 10.0.50.2 dev eth0
ifconfig eth1 10.0.50.1 netmask 255.0.0.0
route del -net 10.0.0.0 netmask 255.0.0.0 dev eth1
route add 10.0.50.3 dev eth1
# ...

Dies sollte nur zu einer IP pro Schnittstelle in der Routing-Tabelle führen. Diese befinden sich auf separaten Drähten, sodass kein Übersprechen auftritt. Jedes dieser Geräte würde denken, dass sie sich auf einem 2-Knoten 10.0.0.0/8 befinden.

Wenn der Server mit 10.0.50.2 kommunizieren möchte, überprüft er die ARP-Tabelle und anschließend die Routing-Tabelle. Wenn die ARP-Tabelle leer ist, weist die Routing-Tabelle sie an, eine ARP-Anforderung an die jeweilige Schnittstelle zu senden. Daher MÜSSEN sie eindeutige IP-Adressen haben, da der Server sonst nur mit der zuletzt hinzugefügten Route sprechen kann.

Sie können Ihren DHCP-Server so einstellen, dass er IPs basierend auf den Hardwareadressen zuweist, oder auf jeder Schnittstelle einen separaten dynamischen DHCP-Bereich ausführen. Der DHCP-Server kann alles ausgeben, aber 10.0.50.3 auf der eth0-Leitung ist nicht erreichbar.

— Pedro
quelle

Sie können nicht dieselbe IP-Adresse auf mehreren Schnittstellen verwenden. Es funktioniert einfach nicht richtig (normalerweise funktioniert es nur auf der letzten Schnittstelle, auf der die IP zugewiesen wurde).

Sie müssen die Ethernet-Schnittstellen in eine Bridge einfügen und die IP-Adresse auf der Bridge selbst zuweisen.

Im Wesentlichen funktionieren alle Ethernet-Ports in dieser Bridge als Switch.

Alternativ können Sie alle Ethernet-Karten für jede STB entfernen und einfach einen Switch hinzufügen (der skalierbarer ist als das Hinzufügen neuer Ethernet-Karten auf Ihrem Server).

Da es jedoch erforderlich ist, dass sich jede STB in einer eigenen Broadcast-Domäne befindet, müssen Sie sich leider an Ihr aktuelles Setup halten.

Um zumindest den Teil der Serverhardware in Ihrem Setup zu vereinfachen, lassen Sie die mehreren Ethernet-Karten fallen und fügen Sie einfach einen verwalteten Switch hinzu. Verwenden Sie VLANs, um die "mehreren Ethernet-Karten" mit nur einer physischen Ethernet-Karte zu simulieren.

— Cha0s
quelle

Wir haben über einen verwalteten Switch und VLANs nachgedacht, und höchstwahrscheinlich werden wir dies tun, sobald wir neue STBs hinzufügen müssen. In der Zwischenzeit werde ich Ihre Brückenidee ausprobieren. Vielen Dank!

— Leszek