Mehrere Netzwerkschnittstellen mit dem selben Gateway konfigurieren

[Norcoen]

Hallo zusammen,

ich versuche mich an einer scheinbar ungewöhnlichen Netzwerkkonfiguration, jedenfalls finde ich dazu bisher keine Hinweise oder ich bin mal wieder komplett auf dem Holzweg und es geht eigentlich viel leichter.

Zur Situation:
Ich habe einen Server im Netz von OVH mit mehreren IP Adressen auf einer einzigen physischen Schnittstelle.
Darauf läuft ein Debian9 mit Proxmox, auf dem ich folgende Netzwerkkonfiguration habe:

eno1 ist die physische Schnittstelle auf die Proxmox standardmäßig die Bridge vmbr0 aufschaltet, wenn ich das richtig verstanden habe
vmbr99 habe ich neu angelegt um ein privates Netz anzulegen, dass ohne weiteres Zutun von außen erstmal nicht erreichbar ist

Das resultiert in folgender Konfiguration in /etc/network/interfaces:

Code: Alles auswählen

root@pve2:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage part of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface eno1 inet manual

iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
        address  37.187.92.191
        netmask  255.255.255.0
        gateway  37.187.92.254
        bridge_ports eno1
        bridge_stp off
        bridge_fd 0

auto vmbr99
iface vmbr99 inet manual
        bridge_ports none
        bridge_stp off
        bridge_fd 0
#Privates Netzwerk (LAN) als Kompatibilitaetsschicht zum Proxmox Server Zuhause

Des weiteren habe ich eine virtuelle Maschine als LXC Container (ich erhoffe mir daraus bessere Performance bzw. weniger Overhead anstatt eine komplette Virtualisierung per KVM, falls es daran scheitert würde ich wohl pfsense, ipfire oder VyOS verwenden, möchte es aber erstmal per Hand in Debian und Iptables lösen, da ich gerne verstehen will was da passiert bevor ich es per GUI verwalten kann)

Die Konfiguration der virtuellen Maschine sieht so aus:

eth0 ist die Verbindung in das private Netzwerk an vmbr99
eth1 bis eth4 (ggf. später weitere) sind Verbindungen in das Netz von OVH über vmbr0, die IPs sind also global erreichbar.
Ich habe mir dies in meiner Ahnungslosigkeit so angelegt, vllt gibt es ja auch einen leichteren Weg.
Letztendliches möchte ich erreichen, dass ich über diesen Router eine Art Mapping der IPs verwalten kann, z.B.:
eth1(164.132.217.176) -> 192.168.0.220
eth2(164.132.217.177) -> 192.168.0.230
eth3(164.132.217.178) -> 192.168.0.205
ggf. kommen noch weitere ethX dazu wo kein direktes Mapping auf eine andere IP vorgesehen ist, sondern "normales" NAT, wo för eine externe IP verschiedene Ports auf verschiedene interne IPs verteilt werden

Das erscheint im ersten Moment wahrscheinlich Schwachsinnig, da ich die virtuellen Maschinen ja auch direkt mit den öffentlichen IPs ausstatten und ans Netz hängen könnte, hat aber den Grund, dass ich den Router als Kompatibilitätsschicht zu einem anderen Server brauche, auf dem mir nur eine einzige öffentliche IP zur Verfügung steht. Ich möchte die Maschinen daher unverändert zwischen den Servern austauschen können und nur über den jeweiligen Router (am besten anhand der MAC-Adressen?) das Mapping festlegen.

Das resultiert in folgender Konfiguration in /etc/network/interfaces:

Code: Alles auswählen

root@router1:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.0.1
        netmask 255.255.0.0

auto eth1
iface eth1 inet static
        address 164.132.217.176
        netmask 255.255.255.255
# --- BEGIN PVE ---
        post-up ip route add 37.187.92.254 dev eth1
        post-up ip route add default via 37.187.92.254 dev eth1
        pre-down ip route del default via 37.187.92.254 dev eth1
        pre-down ip route del 37.187.92.254 dev eth1
# --- END PVE ---

auto eth2
iface eth2 inet static
        address 164.132.217.177
        netmask 255.255.255.255

auto eth3
iface eth3 inet static
        address 164.132.217.178
        netmask 255.255.255.255

auto eth4
iface eth4 inet static
        address 164.132.217.179
        netmask 255.255.255.255

Außerdem habe ich eine weitere virtuelle Maschine testweise in das private Netz gehangen um das ganze zu testen (Kopie eines Teamspeak Servers von einem anderen Proxmox-Host, welche Software darauf ist, ist aber nicht von Bedeutung für das Setup)


Das resultiert in folgender Konfiguration in /etc/network/interfaces:

Code: Alles auswählen

root@teamspeak1:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.0.220
        netmask 255.255.255.0
        gateway 192.168.0.1

Problem:
1)Ich schaffe es nicht die Schnittstellen eth1 bis eth4 auf eine IP zu mappen, ich weiß noch gar nicht ob dies überhaupt einfach so über normale iptable-rules möglich ist. Bisher habe ich mit normalem NAT bzw. mit Beispielen zu 1:1NAT experimentiert.

2)Alle Schnittstellen nach außen, also eth1 bis eth4 haben das gleiche Gateway (37.187.92.254), dieses wird von Proxmox bzw. von mir über die Proxmox GUI auf eth1 gesetzt, bei den weiteren Schnittstellen kann ich es zumindest über die GUI nicht setzen, da sonst die Fehlermeldung

Code: Alles auswählen

Nov 21 21:34:18 router1 ifup[447]: ifup: failed to bring up eth3
Nov 21 21:34:18 router1 ifup[447]: RTNETLINK answers: File exists

für die weiteren Schnittstellen im Log erscheint, oder in manchen Fällen die GUI die Eingabe direkt ablehnt mit dem Hinweis, dass das Gateway schon vorhanden ist.

Ich habe dazu den folgenden Artikel gefunden, in dem eine Lösung per iproute2 beschrieben wird. Der Artikel ist aber scheinbar schon recht alt und ggf. veraltet:
https://www.thomas-krenn.com/de/wiki/Zw ... nem_System

Ich habe daher nach iproute2 gesucht und bin über die Wikipedia (https://de.wikipedia.org/wiki/Iproute2) darüber gestolpert, dass diese wohl jetzt das Standardwerkzeug sind (zumindest Konfiguriert man ja spätestens seit Debian9 über den Befehl "ip" das Routing, wenn ich das richtig verstanden habe)

Gibt es dazu irgendeinen relativ unkomplizierten Weg mit den unter Debian vorhanden (ip?) Tools oder gibt es einen ganz anderen Weg, auf den ich noch nicht gekommen bin?

Aus diesem Grund schaffe ich auch keine normale NAT bzw. IPv4 Forwarding Verbindung nach außen über diese Schnittstellen, also es so einzurichten, dass die Maschinen im privaten Netz einen Internetzugang haben.
Ich kann das über die Schnittstelle eth1 machen, da da diese ja ein Gateway hat. Sobald ich es aber mit eth2 versuche, klappt es nicht mehr:

Code: Alles auswählen

root@router1:~# cat /etc/iptables/rules.v4
*nat
# teamspeak haengt an der IP von eth2
-A POSTROUTING -o eth2 -j MASQUERADE
COMMIT

*filter
-A INPUT -i lo -j ACCEPT
# eingehenden Traffic erlauben der zu ausgehenden Verbindungen,
# u.a. fuer Clients aus dem privaten Netzwerk
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# alles andere eingehend verbieten
-A INPUT -i eth2 -j DROP
COMMIT

Wenn ich in diesem Code eth2 durch eth1 ersetze und per iptables-restore einspiele, kann die Maschine im internen Netz einen Ping auf 8.8.8.8 absetzen.

Ich hoffe ich habe jetzt nicht gleich alle mit diesem Megapost verschreckt.

LG, Frank

[BenutzerGa4gooPh]

Letztendliches möchte ich erreichen, dass ich über diesen Router eine Art Mapping der IPs verwalten kann, z.B.:
eth1(164.132.217.176) -> 192.168.0.220
eth2(164.132.217.177) -> 192.168.0.230
eth3(164.132.217.178) -> 192.168.0.205

Bisher habe ich mit normalem NAT bzw. mit Beispielen zu 1:1NAT experimentiert.

Richtig wäre Destination-NAT (DNAT): Änderung der Zieladdressen (auch Änderung Zielports möglich).
http://linux-ip.net/html/nat-dnat.html

Für ausgehenden Traffic ( ping 8.8.8.8 ) ist Source-NAT zu verwenden (Änderung Quelladressen). Üblicher Spezialfall Port Address Translation (PAT, 1:N-NAT) -> 1 externe Adresse verwendet. 1:1-NAT würde Quell-Adress-Pool verwenden (freie Adressen, Pool wohl schnell am Ende).

Dein (virtuelles) Bridging verstehe ich nicht, kenne Proxmox auch nicht. Ich denke mal, man könnte entweder 1:1 bridgen (mit 3 bzw. 4 VBridges), so dass der Debian-Router mehrere (virtuelle) WAN-Interfaces mit je einer öffentlichen IP-Adresse hätte oder aber nur ein einziges WAN-IF verwenden, das aber mit mehreren Sub-IFs ("Secondary IP-Address"). Wobei ich mir das Routing im ersten Fall schwieriger vorstelle.
https://www.racksrv.com/portal/knowledg ... buntu.html

Möglichkeiten, einer Schnittstelle gleichzeitig mehr als eine IP-Adresse zuzuweisen
...
Eine solche Konfiguration könnte man für einen Server verwenden, der gleichzeitig auf mehreren IP-Adressen unterschiedliche Dienste bereitstellt, z.B. auf 192.0.2.254 einen Webserver und auf 198.51.100.1 einen E-Mail-Server. iptables ist in der Lage, die Schnittstellen über die Namen voneinander zu unterscheiden und ermöglicht damit dienst-spezifische Filtersätze.

https://wiki.ubuntuusers.de/interfaces/

Die WAN-Konfiguration kannst du mit

Code: Alles auswählen

route -n
und
ifconfig
bzw.
ip a 

und mit Aktivierung nur je eines Interfaces und ping auf Internet-Adressen ja gut ausprobieren - vom Debian-Router selber aus! Wäre eigentlich der 1. Schritt gewesen. 2. Schritt wäre Test der Erreichbarkeit aller öffentlichen IPs des Debian-Routers aus dem Internet.

Übrigens: Als (Netzwerk-/iptables-) Anfänger würde ich nicht gerade an einem öffentlichen Server spielen, sondern mir dafür ein Testnetz mit VirtualBox basteln und erst wenn fertig, den Server konfigurieren. Zwischenzeitlich abschalten (lassen)?
https://www.debian.org/doc/manuals/secu ... l#contents

[Norcoen]

Richtig wäre Destination-NAT (DNAT): Änderung der Zieladdressen (auch Änderung Zielports möglich).
http://linux-ip.net/html/nat-dnat.html

Für ausgehenden Traffic ( ping 8.8.8.8 ) ist Source-NAT zu verwenden (Änderung Quelladressen). Üblicher Spezialfall Port Address Translation (PAT, 1:N-NAT) -> 1 externe Adresse verwendet. 1:1-NAT würde Quell-Adress-Pool verwenden (freie Adressen, Pool wohl schnell am Ende).

Ich glaube nach deiner Beschreibung möchte ich eigentlich genau das haben [(PAT, 1:N-NAT) -> 1 externe Adresse verwendet], ich habe ja aktuell 16 IPs zur Verfügung die ich auch an die virtuellen Maschinen verteilen möchte. Lediglich bei einigen wenigen werden sich mehrere virtuelle Maschinen eine externe IP Adresse teilen, was für mich dann wieder normales NAT wäre, mit dem ich zumindest schon ein bisschen Erfahrung habe.

Dein (virtuelles) Bridging verstehe ich nicht, kenne Proxmox auch nicht. Ich denke mal, man könnte entweder 1:1 bridgen (mit 3 bzw. 4 VBridges), so dass der Debian-Router mehrere (virtuelle) WAN-Interfaces mit je einer öffentlichen IP-Adresse hätte oder aber nur ein einziges WAN-IF verwenden, das aber mit mehreren Sub-IFs ("Secondary IP-Address"). Wobei ich mir das Routing im ersten Fall schwieriger vorstelle.
https://www.racksrv.com/portal/knowledg ... buntu.html

Möglichkeiten, einer Schnittstelle gleichzeitig mehr als eine IP-Adresse zuzuweisen
...
Eine solche Konfiguration könnte man für einen Server verwenden, der gleichzeitig auf mehreren IP-Adressen unterschiedliche Dienste bereitstellt, z.B. auf 192.0.2.254 einen Webserver und auf 198.51.100.1 einen E-Mail-Server. iptables ist in der Lage, die Schnittstellen über die Namen voneinander zu unterscheiden und ermöglicht damit dienst-spezifische Filtersätze.

https://wiki.ubuntuusers.de/interfaces/

Ich habe dem Debian-Router ja mehrere virtuelle WAN-Interfaces (eth1-eth4) zugewiesen. Oder verstehe ich hier was falsch? Die IPs von eth1 bis eth4 kann ich alle von Zuhause anpingen, sobald diese mit dem virtuellen Debian-Router verknüpft sind.
Die Möglichkeit mehrere IPs an nur eine Schnittstelle zu binden ist tatsächlich eine Lösung die ich mit den Mitteln, die ich aktuell kenne umsetzen könnte, denke ich. Ich verliere dabei aber einen Teil der Abstraktion den ich damit überhaupt erst schaffen möchte. Im besten Falle kann ich die virtuellen Maschinen und den virtuellen Router dann auf einem anderen proxmox-host einspielen und muss nur über die GUI die externen IPs der virtuellen WAN-Interfaces anpassen, da die restliche Konfiguration an den Interfaces festgemacht sein soll. Evtl. muss ich noch die Routen anpassen, aber ggf. lässt sich das ja auch irgendwie automatisch einstellen, da ich zumindest dem virtuellen WAN-Interface eth1 ja das Standardgateway auch per GUI zuweisen kann. Ggf. kann man dies ja als Variable auch für die anderen setzen.

Die WAN-Konfiguration kannst du mit

Code: Alles auswählen

route -n
und
ifconfig
bzw.
ip a 

und mit Aktivierung nur je eines Interfaces und ping auf Internet-Adressen ja gut ausprobieren - vom Debian-Router selber aus! Wäre eigentlich der 1. Schritt gewesen. 2. Schritt wäre Test der Erreichbarkeit aller öffentlichen IPs des Debian-Routers aus dem Internet.

Ich glaube genau das hab ich gemacht. Bin mir nicht sicher ob es aus meinem Text so hervorgeht. Also die öffentlichen IPs sind alle erreichbar und ich habe für eth1 ja auch eine Route vom Debian nach draußen.
Entsprechend konnte ich per iptables und NAT auch die andere virtuelle Maschine nach draußen verbinden lassen. Aber leider nur wenn ich das NAT für eth1 einrichte, nicht wenn ich es für eth2 einrichte.

Übrigens: Als (Netzwerk-/iptables-) Anfänger würde ich nicht gerade an einem öffentlichen Server spielen, sondern mir dafür ein Testnetz mit VirtualBox basteln und erst wenn fertig, den Server konfigurieren. Zwischenzeitlich abschalten (lassen)?
https://www.debian.org/doc/manuals/secu ... l#contents

Die Maschinen selbst sind alle abgesichert und auf aktuellem Stand. Zwar keine Spielereien wie IntrusionDetection oder Fail2ban oder sowas, aber grundsätzliche ist das schon abgesichert. Ich bin zwar auch nur interessierter Laie, aber die einzigen Einbrüche auf meinen Servern waren über SQL-Injection und der gleichen von den jeweiligen Webframeworks wie TYPO3.
Der Proxmox-Host hat zwar leider nur eine einzige physische Schnittstelle, aber durch die eigene IP Adresse für seine Verwaltung sollte da relativ wenig schief gehen können, wenn ich in den Routen der VMs experimentiere. Im schlimmsten Falle muss ich ein Backup einspielen.
Grundsätzlich würde mich aber interessieren ob ich mir durch die vielen virtuellen Switches und Schnittstellen nicht neue Sicherheitslücken erstelle. Ich würde z.B. davon ausgehen, dass unverschlüsselter Traffic der VM mit der IP 192.168.0.1 mit der VM mit der IP 192.168.0.220 nicht von außen gelesen werden kann. Wenn dem doch so wäre, wäre das eine Katastrophe für mich, da dort u.a. unverschlüsselte HTTP Verbindungen laufen sollen, die erst über einen ReverseProxy mit SSL an die Außenwelt durchgereicht werden sollen.
Daher ist das auch so ein spannendes Thema für mich mit den Routen und den Gateways, usw. Ich hatte das nur ganz Grundlegend vor über 10 Jahren im Abitur angerissen bekommen.

Aktuell versuche ich zu verstehen was es mit proxy_arp auf sich hat und ob das ggf. einen Teil der Lösung für mich ausmachen könnte.

LG, Frank

[BenutzerGa4gooPh]

Ich glaube nach deiner Beschreibung möchte ich eigentlich genau das haben [(PAT, 1:N-NAT) -> 1 externe Adresse verwendet], ich habe ja aktuell 16 IPs zur Verfügung die ich auch an die virtuellen Maschinen verteilen möchte. Lediglich bei einigen wenigen werden sich mehrere virtuelle Maschinen eine externe IP Adresse teilen, was für mich dann wieder normales NAT wäre, mit dem ich zumindest schon ein bisschen Erfahrung habe.

Und ich glaube, du willst oder besser brauchst auch DNAT fuer Erreichbarkeit von Servern mit privaten IPs aus dem Internet. Mit PAT (1:N-NAT oder NAT overload) sind deine Maschinen mit privaten IPs hinter Router jedenfalls nicht ohne Weiteres (Portforwarding) oeffentlich erreichbar, also wozu mehrere oeffentliche IPs?
https://de.m.wikipedia.org/wiki/Netzwer ... bersetzung
https://de.m.wikipedia.org/wiki/Port_Ad ... ranslation
(Die englischen Pendants sind oft ausfuehrlicher.)
Ansonsten kannst du auch (oder zusaetzlich zum virtuellen Router) pro oeffentlicher IP eine VM (Server mit oeffentlicher IP) konfigurieren. Fuer Performance sind mehrere VMs "ungut", Container sind momentan state of the art (Docker & Co.).

Aktuell versuche ich zu verstehen was es mit proxy_arp auf sich hat und ob das ggf. einen Teil der Lösung für mich ausmachen könnte.

Das und Gratuitous ARP schaltest du auf einem oeffentlich erreichbaren Router/Server besser ab! So wegen ARP-Spoofing.

Ich würde z.B. davon ausgehen, dass unverschlüsselter Traffic der VM mit der IP 192.168.0.1 mit der VM mit der IP 192.168.0.220 nicht von außen gelesen werden kann.

Wenn das Hostsystem kompromittiert wurde, ist ALLES moeglich.

Ausserdem habe ich die Ahnung, du baust viel zu kompliziert. Warum nicht ein oder mehrere oeffentliche (V)Server ohne (V)Router? Was du machst, klingt fuer mich eher nach Firmennetzwerk mit physischem Router/Firewall, NAT, LAN, Server im LAN (und DNAT/Portforwarding, da oeffentliche Server mit privaten IPs). Wobei eine DMZ und Server mit oeffentl. IPs state of the art waeren - zumindest bei mehreren Servern und Vorhandensein mehrerer oeffentlicher IPs. NAT/DNAT ist dafuer eine Kruecke (Adresseinsparung verbunden mit schlechterer Netzwerk-Performance).

Und nochmals: 1 oeffentlicher Server ist kein Versuchskaninchen. Letzteres haelt man zu Hause, ist sicherer.

[Norcoen]

Und ich glaube, du willst oder besser brauchst auch DNAT fuer Erreichbarkeit von Servern mit privaten IPs aus dem Internet. Mit PAT (1:N-NAT oder NAT overload) sind deine Maschinen mit privaten IPs hinter Router jedenfalls nicht ohne Weiteres (Portforwarding) oeffentlich erreichbar, also wozu mehrere oeffentliche IPs?
https://de.m.wikipedia.org/wiki/Netzwer ... bersetzung
https://de.m.wikipedia.org/wiki/Port_Ad ... ranslation
(Die englischen Pendants sind oft ausfuehrlicher.)

Das war mir bisher nicht bewusst! Ich hab zwar schon mit SNAT UND DNAT gearbeitet, dachte aber bei einem 1:1 Mapping wird einfach jeglicher Traffic durchgeleitet, quasi ext.IP<->interne IP

Ansonsten kannst du auch (oder zusaetzlich zum virtuellen Router) pro oeffentlicher IP eine VM (Server mit oeffentlicher IP) konfigurieren. Fuer Performance sind mehrere VMs "ungut", Container sind momentan state of the art (Docker & Co.).

Das hab ich tatsächlich probiert, wenn ich für jede externe IP eine VM als Router dazwischenschalte, dann habe ich nicht mehr das Problem mit dem ich eigentlich kämpfe: mehrere Schnittstellen mit dem selben Gateway.
Meine VM sind übrigens LXC-Container, das dürfte sich Performancetechnisch mit Docker nicht viel nehmen. Allerdings weiß ich nicht wie viel Last mir die ganzen virtuellen Schnittstellen, NAT, usw. auf die CPU schlagen. Da würde ich natürlich gerne so sparsam wie möglich für mein gewünschtes Setup arbeiten.

Das und Gratuitous ARP schaltest du auf einem oeffentlich erreichbaren Router/Server besser ab! So wegen ARP-Spoofing.

Für mich klang es wie eine Möglichkeit mit dem virtuellem Router den virtuellen Maschinen eine Verbindung nach außen vorzugaukeln. Aber es wird überall geraten es lieber über das Routing zu machen.
Das mit dem Spoofing stand sogar direkt zu anfang, klang aber für mich gar nicht so interessant, da ich es nur im internen Netz einsetzen wollte. Scheint wohl ein irrweg gewesen zu sein.

Wenn das Hostsystem kompromittiert wurde, ist ALLES moeglich.

Wenn das Hostsystem, dass nur auf SSH lauscht bzw. soll, kompromittiert wurde, kann es ja eigentlich nur über die Abstraktionsschicht (KVM/LXC) zu den virtuellen Maschinen passiert sein. Dagegen fiele mir höchstens noch SELinux als Schutz sein. Es geht mir auch nicht darum ob eins meiner Systeme kompromittiert ist, denn wenn das der Fall ist kann ich dem ganzen eh nicht mehr trauen und muss alles neu aufsetzen.
Es geht mir darum, unter der Annahme, das alles abgesichert und richtig konfiguriert ist, dass dann von außen nicht der interne Datenverkehr der VMs mitgelesen werden kann, durch eine Fehlkonfiguration des Routings oder andere Schnitzer. Das ist meine größte Sorge, da ich davon keine Ahnung habe.
Wenn ich es richtig verstanden habe, sollte das Gateway ja für allen Traffic zuständig sein, der nicht für das lokale Netz bestimmt ist oder für den eine statische Route angelegt wurde.
Angenommen meine Konfiguration ist so kaputt, dass aller Traffic erst zum OVH-Gateway und dann zurück zur virtuellen Maschine läuft, das wäre für mich der SuperGAU.

Ausserdem habe ich die Ahnung, du baust viel zu kompliziert. Warum nicht ein oder mehrere oeffentliche (V)Server ohne (V)Router? Was du machst, klingt fuer mich eher nach Firmennetzwerk mit physischem Router/Firewall, NAT, LAN, Server im LAN (und DNAT/Portforwarding, da oeffentliche Server mit privaten IPs). Wobei eine DMZ und Server mit oeffentl. IPs state of the art waeren - zumindest bei mehreren Servern und Vorhandensein mehrerer oeffentlicher IPs. NAT/DNAT ist dafuer eine Kruecke (Adresseinsparung verbunden mit schlechterer Netzwerk-Performance).

Ja und nein. Ich will es so simpel und sicher wie möglich. Aber die Abstraktionsschicht mit dem virtuellen Debian als Router dazwischen geschaltet brauche ich einfach schon deshalb um die anderen virtuellen Maschinen ohne viel Aufwand zwischen verschiedenen Systemen transferieren zu können. Das ist leider alles andere als Optimal, aber auf der Situation sitze ich nunmal leider erstmal :/
Mit den verschiedenen Zonen in der Firewall habe ich auch gelesen und im Grunde versuche ich tatsächlich so ein Art Firmennetz wie du es beschreibst aufzubauen, wahrscheinlich schon weil ich es so auch immer im Hinterkopf hatte.

Der Kern meines Problems ist doch eigentlich nur, dass ich nicht weiß wie ich aus Debian einen Router mache. Zumindest in dem Falle, dass er mehrere WAN-Schnittstellen hat, die aber alle dasselbe Gateway eingetragen haben müssten. Wenn das schonmal funktionieren würde, könnte ich mich damit beschäftigen, wie ich das ganze per iptables auf die angeschlossenen VMs verteile. Für eine einzelne WAN-Schnittstelle ist das bisher ja kein Problem. Ich müsste also sagen können, Anfragen die z.B. auf eth2 reinkommen werden auf die IP 192.168.0.220 umgeschrieben und Antworten von 192.168.0.220 gehen auch zwingend wieder über eth2 raus. Das geht aber nicht, weil eth2 kein Gateway hat, da es das gleiche Gateway wie bei eth1 wäre.

Ich finde dazu dutzende Threads auf StackExchange und Co. aber es passt nie zu 100%, weil z.B. zwar 2 Gateways verwendet werden sollen, aber unterschiedliche.
Oder aber die haben tatsächlich 2 WAN-Interfaces im selben Subnet mit dem selben Gateway, wollen es aber zum Load-Balancing einsetzen.
Also in Teilen sind irgendwie alle Probleme dich ich habe schon gelöst worden, ich schaffe es nur nicht das zusammen zu führen.
Vielleicht sollte ich aber auch erstmal ein Bild malen, wie ich mir das Netzwerk denke - ich habe das Gefühl bei einigen Begriffen wie Gateway kann man auch gut aneinander vorbei reden - gibt es dazu ein simples Tool?

LG, Frank

[Norcoen]

Ausserdem habe ich die Ahnung, du baust viel zu kompliziert. Warum nicht ein oder mehrere oeffentliche (V)Server ohne (V)Router?

Sorry für den Doppelpost, aber auf diesen Teil muss ich noch ein weiteres mal einzeln Antworten:
Eigentlich will ich genau das!
Die vServer können direkt am öffentlichen Netz hängen, da sie ihre eigene Firewall, etc. mitbringen.
Der Router dazwischen soll transparent sein und dient lediglich meiner Sonderwurst, dass die Maschinen auf unterschiedlichen Servern ohne Mühe ausgetauscht werden können.
Zusätzlich sollen die vServer mit einem internen Netz verbunden sein, dass von außen nicht erreichbar ist, damit dort (teilweise) unverschlüsselt kommuniziert werden kann.

ich habe solche Konfigurationen sogar schon in freier Wildbahn gesehen, so bin ich ja erst auf die Idee gekommen. Das Problem war, dass dort kein Debian bzw. Linux auf dem transparenten Router eingesetzt wurde.
Ganz dunkel kann ich mich erinnern das Linux irgendwas nicht gut könnte, weil es ein "weak bonding" oder so hätte, und irgendwie hing ARP da mit drin, wenn man es doch mit Linux machen wollte... ist aber Jahre her und ich erinnere mich leider nur noch an sehr wenig.

[BenutzerGa4gooPh]

Der Kern meines Problems ist doch eigentlich nur, dass ich nicht weiß wie ich aus Debian einen Router mache. Zumindest in dem Falle, dass er mehrere WAN-Schnittstellen hat, die aber alle dasselbe Gateway eingetragen haben müssten.

Ein Router besitzt Netzwerkinterfaces und (Default-) Routen, keine Gateways. Seine internen Interfaces sind Gateways fuer daran angeschlossenen Netzwerke.
Wohin der Router Pakete sendet, bestimmt die Routing Table. Bei doppelten Routen (z. B. mehreren Uplinks wie bei dir) zum gleichen Zielnetz wird die Route mit den geringsten Kosten / "Metrik" benutzt. Kann man fuer statische Routen manuell festlegen.
http://www.fibel.org/linux/lfo-0.6.0/node477.html
Jedenfalls ist immer nur eine Route aktiv. Diese kann wechseln, z. B. wenn Uplink ausfaellt, Qualitaet schlechter wird oder mit Policy Based Routing der zu sendende Verkehr untersucht wird und je nach Klassifikation ueber unterschiedliche Uplinks gesendet wird. Routing-Protokolle (BGP, RIP, OSPF, ISIS, EIRP) lasse ich mal aussen vor.

Was du suchst, koennte die Vergewaltigung eines Load Balancers sein. https://en.m.wikipedia.org/wiki/HAProxy
In Paketquellen: haproxy
Zum Einen habe ich damit 0 Erfahrung, zum Anderen ist mir nicht klar, wie der zu deinem Konzept passen koennte.

Eine weitere Moeglichkeit - falls es "nur" um Webserver geht: Diese koennen Anfragen untereinander weiterleiten.

Irgendwie erscheint mir bei Verwendung eines virtuellen Routers fuer virtuelle Maschinen fuer das WAN-IF des Routers am passendsten:

... nur ein einziges WAN-IF verwenden, das aber mit mehreren Sub-IFs ("Secondary IP-Address").

Möglichkeiten, einer Schnittstelle gleichzeitig mehr als eine IP-Adresse zuzuweisen
...
Eine solche Konfiguration könnte man für einen Server verwenden, der gleichzeitig auf mehreren IP-Adressen unterschiedliche Dienste bereitstellt, z.B. auf 192.0.2.254 einen Webserver und auf 198.51.100.1 einen E-Mail-Server. iptables ist in der Lage, die Schnittstellen über die Namen voneinander zu unterscheiden und ermöglicht damit dienst-spezifische Filtersätze.
https://wiki.ubuntuusers.de/interfaces/

bzw. https://www.racksrv.com/portal/knowledg ... buntu.html
Damit waere das einfach "standardmaessig" realisierbar:

Letztendliches möchte ich erreichen, dass ich über diesen Router eine Art Mapping der IPs verwalten kann, z.B.:
eth1(164.132.217.176) -> 192.168.0.220
eth2(164.132.217.177) -> 192.168.0.230
eth3(164.132.217.178) -> 192.168.0.205

Ein Zugriff auf 164.132.217.176 aus dem Internet wird zum Server 192.168.0.220 geforwardet. Usw.
Mit DNAT: http://linux-ip.net/html/nat-dnat.html
Deine Server koennten im "Pseudo-LAN" 192.168.0.0/24 z. B. untereinander kommunizieren und haetten bei Bedarf per PAT/1:N-NAT Internetzugang. Gateway der Server waere z. B. 192.168.0.254/24 als internes ("LAN"-) Interface des Routers. Somit haette der Router 1 WAN-Interface mit 3 Subinterfaces (3 oeffentl. IPs fuer 1 Hauptinterface) und 1 LAN-Interface (Gateway) fuer alle Server.
Mit DNAT+Portforwarding waeren sie geschuetzter als mit DNAT- "Komplettumleitung" (entspricht "Exposed Host" bei Fritzbuechsen).

Entspricht einfachem Standard-Firmen/Hemnetzwerk. Ob diese Komplexitaet fuer VServer geeignet/sicher ist, wage ich zu bezweifeln. Lies das 2. Zitat im Beitrag nochmals! Technisch sollte es so funktionieren.

Konzept und Spezialitaeten habe ich genannt, Debian-Router-Grundkonfiguration findest du im Netz zuhauf. Google: "debian linux router".

[BenutzerGa4gooPh]

Vielleicht sollte ich aber auch erstmal ein Bild malen, wie ich mir das Netzwerk denke ... gibt es dazu ein simples Tool?

Ich glaube, Libre Office (Draw) hat einen MS Visio Importfilter:
http://www.linux-magazin.de/NEWS/Libre- ... o-Formate/
Versuche, die Visio-Icons von Cisco zu importieren:
https://www.cisco.com/c/en/us/about/bra ... icons.html
Oder Import der oberen (EPS, JPG) oder der Powerpoint-Symbole testen?!
Zeichnung sollte am Ende qualitativ etwa so aussehen: https://www.administrator.de/wissen/kop ... html#toc-3

(Selber probiert hab ich's nicht.)

[Norcoen]

Ein Router besitzt Netzwerkinterfaces und (Default-) Routen, keine Gateways. Seine internen Interfaces sind Gateways fuer daran angeschlossenen Netzwerke.
Wohin der Router Pakete sendet, bestimmt die Routing Table. Bei doppelten Routen (z. B. mehreren Uplinks wie bei dir) zum gleichen Zielnetz wird die Route mit den geringsten Kosten / "Metrik" benutzt. Kann man fuer statische Routen manuell festlegen.
http://www.fibel.org/linux/lfo-0.6.0/node477.html
Jedenfalls ist immer nur eine Route aktiv. Diese kann wechseln, z. B. wenn Uplink ausfaellt, Qualitaet schlechter wird oder mit Policy Based Routing der zu sendende Verkehr untersucht wird und je nach Klassifikation ueber unterschiedliche Uplinks gesendet wird. Routing-Protokolle (BGP, RIP, OSPF, ISIS, EIRP) lasse ich mal aussen vor.

Ich glaube das ist ein ganz wichtiger Teil, der mir gefehlt hat. Ich habe die Angabe des Gateways an allen Schnittstellen entfernt und versuche mich jetzt an den Routingtabellen. Dazu hab ich tatsächlich schon einige Beispiele gesehen, die mir aber zunächst zu umständlich erschienen, da ich glaubte das direkt an den Interfaces regeln zu können.

Was du suchst, koennte die Vergewaltigung eines Load Balancers sein. https://en.m.wikipedia.org/wiki/HAProxy
In Paketquellen: haproxy
Zum Einen habe ich damit 0 Erfahrung, zum Anderen ist mir nicht klar, wie der zu deinem Konzept passen koennte.

Einen HAProxy habe ich tatsächlich an anderer Stelle im Einsatz, hinter dem virtuellen Router, da auf dem anderen Server ja nur eine IP zu Verfügung steht, terminiert dieser mir die SSL Verbindungen für Webserver, openVPN, SSHoverSSL, Mails(Imap, Pop, Smtp), usw.


Den Rest des Threads muss ich jetzt erstmal sacken lassen, es gibt viele Dinge die ich noch nicht verstanden habe und mich ein wenig einlesen muss.
Ich danke dir herzlich für deine Hilfe und hoffe ich kann dich die Tage vielleicht nochmal mit dem Thema nerven

LG, Frank

[BenutzerGa4gooPh]

und versuche mich jetzt an den Routingtabellen.

Du versuchst dich maximal an statischen Routen. Da du nur 1 Router hast, sind alle Netze direct connected und somit dem Router bekannt.
Also sind nur Default-Routen zu erstellen.
https://www.cyberciti.biz/faq/linux-set ... e-command/
Gateway waere der des Hosters. Koennte sein, dass das Gleiche auch mit einem Default Gateway auf dem Interface klappt.

Code: Alles auswählen

route -n

wird dir's verraten.

[bluestar]

Das von dir beschriebene Setup ist echt an vielen Stellen kompliziert.

Ich denke du kannst deine Wünsche einfacher erreichen.
1) Hostsystem: Hier hast du folgende Netzwerkinterfaces:
eno1 mit der 1. öffentlichen IP
eno1:1 mit der 2. öffentlichen IP
eno1:n mit der n. öffentlichen IP
br0 mit dem privaten Netz/24.

Dann baust du deine DNAT und SNAT Regeln auf dem Host,
parallel noch eine MASQ Regel für den Internetzugriff derVMs ohne SNAT/DNAT.
IP Forwading noch einschalten.

Deine VMs oder LXC Container hängst du mit privaten IPs alle an br0.

Und fertig ist das Setup ohne Router und dennoch flexibel... Das Hostsystem schafft mit den SNAT/DNAT Regeln die Flexibilität/deine Abstraktionsschicht.