2 unterschiedliche IP-Subnetze auf meiner Mietleitung [Gelöst]

[jmar83]

Hallo zusammen

Wie kriege ich es da "sauber" hin, dass ich über 1 Kabel beide IPs auf dem System einrichten kann?

Was ich bis anhin kannte, war der sog. "macvlan"-Adapter, welcher als eine Art Bridge (Layer ll soviel ich weiss) zum phys. Adapter fungiert. (Je nach Einstellung in der /etc/systemctl.conf kriegen dann beide IPs [phys. & virt.] gar die gleiche IP (ist mir mir im IP-Scanner aufgefallen), was ich allerdings eher weniger möchte. Wenn schon "macvlan"-Adapter, dann mit der systemctl.conf-ARP-Einstellung dass ich dem "macvlan"-Adapter ne eigene MAC-Adresse (aus einem dafür vorgesehenen Bereich) zuweisen kann...

Oder kann man einem [1] phys. Adapter "einfach so" 2 versch. IPs zu weisen, welches quasi parallel nebeneinander koexistieren?

Vielen Dank für die Feedbacks.

[unitra]

Hallo zusammen

Wie kriege ich es da "sauber" hin, dass ich über 1 Kabel beide IPs auf dem System einrichten kann?

Was ich bis anhin kannte, war der sog. "macvlan"-Adapter, welcher als eine Art Bridge (Layer ll soviel ich weiss) zum phys. Adapter fungiert. (Je nach Einstellung in der /etc/systemctl.conf kriegen dann beide IPs [phys. & virt.] gar die gleiche IP (ist mir mir im IP-Scanner aufgefallen), was ich allerdings eher weniger möchte. Wenn schon "macvlan"-Adapter, dann mit der systemctl.conf-ARP-Einstellung dass ich dem "macvlan"-Adapter ne eigene MAC-Adresse (aus einem dafür vorgesehenen Bereich) zuweisen kann...

Oder kann man einem [1] phys. Adapter "einfach so" 2 versch. IPs zu weisen, welches quasi parallel nebeneinander koexistieren?

Vielen Dank für die Feedbacks.

Vermutlich hast schon 2 IP's auf einem Kabel. Siehe Dual-Stack (IPv4 und IPv6) laufen gleichzeitig auf einem "Kabel" und koexistireren gleichzeitig. Das ist die sauberste Lösung. Alles andere erfordert viel Plannung, und eine klare Eingrenzung zwischen Sicherheit und Handhabung und der dazu erforderlichen Mittel (Hardware/Konfiguration) usw.

Denkbare Lösunen wären auf layer3 Ebene (IP) - VRF und MPLS, oder VLAN's auf Layer2 (Ethernetrahmen). Zwischen den beiden Layern ist das einzusiedeln. Und ja alles lösbar nur mit dem Einsatz von Linux da die Data Plane (also die Protokolle zur Umsetzung) im Linuxkernel bereits alle vorhanden. Nur die Controlplane (Die Tools und Werkzeuge um es zu konfigurieren) müsste man noch festlegen.

Denk mal über die einfachste Lösung nach, also einfach nur dual-stack. Dann bist Du fein raus und zusätzliche notwendige Tools nicht unbedingt notwendig sind. Alles schon da. Man kann auch IPv4 über IPv6 Tunneln, das nur zur Info. Ich will dir nur den Ärger mit einlesen und verstehen ersparren, wenn keine tiefgründige Experise in Netzwerk vorhanden ist. (Nein, das ist nicht persönlich gemeint mit der Expertise, das ist pragmatisches Denken). Mit IPv6 geht so Einiges, ohne dass wirklich viele andere zusätzliche Protokolle hinzufügen muss, was die Komplexität einer Lösung steigert und nicht unbedingt ratsam ist. Simplicity - the ultimate sohpistication.

Aber ohne weitere Informationen ist ein Rat hier wirklich schwer, nicht nur für mich. Das kannst nur Du am besten entscheiden und beurteilen welchen Grad an Sicherheit das mit dieser Mietleitung da erfordert.

[jmar83]

Aha - vielem Dank für dein schnelles und kompetentes Feedback, aber IPv6 ist kein Thema (ob nun verfügbar oder nicht: das weiss ich nciht mal?) und es gibt auf jedem Subnetz auf der Mietleitung 2 Subnetze mit einer 24er-CIDR:

1.) 193.x.x.0/24

SOWIE

2.) 62.x.x.0/24


Das ist die Ausgangslage. Wir haben schon erlebt, dass das eine, aber nicht das andere Subnetz ausfällt. Deshalb würde wir gerne 2 IPs von den untersch. Subnetzen der Mietleitung über 1 Kabel / 1 Adapter in die DNS A-Record-Round-Robin-Liste aufnehmen...

[jmar83]

Also das hier geht schon mal nicht - "eth0" wäre in diesem Fall der "virtuelle physische" Adapter * :

Code: Alles auswählen

ip link add link eth0 address a2:cc:18:9c:d7:e9 virteth0 type macvlan mode bridge
ifconfig virteth0 62.x.x.111 netmask 255.255.255.0 up
ip route add 62.x.x.0/24 dev virteth0 src 62.x.x.111 table rt4
ip route add default via 62.x.x.1 dev virteth0 table rt4
ip rule add from 62.x.x.111/32 table rt4
ip rule add to 62.x.x.111/32 table rt4

...demzufolge wäre dann "virteth0" der "virtuelle virtuelle" Adapter.

* -> Weil das ganze ne VM ist, welche auf Hyper-V läuft.


Jedenfalls ist es so, dass ich dann weder 62.x.x.111 "von aussen" (irgend ein Rechner, welcher mit dem Internet verbunden ist), allerdings von "innen" [SSH] pingen kann. Beim Gateway 62.x.x.111 ist's dann das Gegenteil: den kann ich natürlich "von aussen" (wäre nicht gut wenn nicht, dann hätte der Provider ein Problem ), aber nicht von "innen" [SSH] pingen.

Aber ich hab ja NULL AHNUNG (!!) wie sich diese "macvlan"-Adapter in Kombination mit Hyper-V-VMs verhalten. Ob das überhaupt klappt?

-> Jedenfalls erinnere ich mich noch gut daran, dass ich vor ca. 2 Jahren mal einen "macvlan"-Adapter auf Raspbian 9 aufgesetzt habe - lief. Dann habe ich EXAKT das gleiche auf einer Oracle VirtualBox VM (wenn ich mich richtig erinnere in einer 5er-Version) mit Debian 9 ("Original" von debian.org) gemacht - null & nix ging.

Dazu hörte ich schlussendlich nur: "It's by design"...

Aber vorher war's natürlich so, dass man in der Debian-Community Oracle die Schuld gab und gesagt ich solle zu denen, aber als ich dann bei denen war wurde mir wieder gesagt: "Nein, Debian ist schuld, gehe zu denen"...

LOL...

[jmar83]

Wenn ich jetzt hier frage "Könnte es sein dass Hyper-V das verursacht" heisst es wohl auch in solle ins M$-Forum.

Und wenn ich um MS-Forum bin, heisst's: Hier geht's nicht um Debian.


VirtualBox vs. Debian ist gegen M$ vs. Debian [Linux] politisch betrachtet wohl nur ein "Kindergeburtstag"...

[jmar83]

Zurück zum technischen...

"route" gibt aktuell folgendes aus:

Code: Alles auswählen

root@debian11-nopcommerce:~# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         193.x.x.1     0.0.0.0         UG    0      0        0 eth0
62.x.x.0      0.0.0.0         255.255.255.0   U     0      0        0 virteth0
192.168.80.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
localnet        0.0.0.0         255.255.255.0   U     0      0        0 eth0

[bluestar]

Hallo zusammen

Wie kriege ich es da "sauber" hin, dass ich über 1 Kabel beide IPs auf dem System einrichten kann?

Beide IPs auf die Netzwerkkarte legen und mit Source based Routing und zwei Routingtabellen arbeiten.

[jmar83]

Vielen Dank, werde mal schauen!!

[unitra]

Ja, Source Based Routing und 2 Routingtabellen ist ein gutes Stichwort. Source Based Routing hatten wir schon mal als Lösung diskutiert hier im Forum. Siehe hier wenn das weiter hilft. viewtopic.php?t=173007

Viel Erfolg bei der Umsetzung.

[bluestar]

Ich an deiner Stelle würde das ganze Thema auch nicht per Hand angehen, es gibt da u.a. Shorewall als Firewall/Routing-Frontend, da braucht es genau vier Zeilen (2 Zeilen für die Providerdefinitionen und jeweils eine pro IP-Range) und die ganzen Regeln werden für dich automatisch erstellt.

[jmar83]

Besten Dank!!

[jmar83]

Zusatzfrage: "Gewöhnliche" NAT-Home-Router sind wohl selten bis nie in der Lage, mehrere statische IPs am ext.-Port anzunehmen? (wir verwenden praktisch nur Fritz-Boxen, auch im professionellen Bereich, ist aber nicht meine Entscheidung, der Chef will das so weil er damit klarkommt)

Vielleicht würde es mit OpenWRT, dd-WRT oder Tomato USB gehen?

[bluestar]

Zusatzfrage: "Gewöhnliche" NAT-Home-Router sind wohl selten bis nie in der Lage, mehrere statische IPs am ext.-Port anzunehmen? (wir verwenden praktisch nur Fritz-Boxen, auch im professionellen Bereich, ist aber nicht meine Entscheidung, der Chef will das so weil er damit klarkommt)

Das sind halt nur Home-Router, damit kannst du keine komplexeren Setups realisieren.

Vielleicht würde es mit OpenWRT, dd-WRT oder Tomato USB gehen?

Mit OpenWRT lässt sich das problemlos umsetzen, falls du jedoch auf OpenWRT was größeres planst denk bitte daran das du etwa 2GB für die BGP Full Table an RAM brauchst.

[jmar83]

Danke!!

[jmar83]

...nun habe ich das gemacht, was unter https://unix.stackexchange.com/question ... twork-card steht. Zuerst ging's nicht von selbst, bis ich herausgefunden habe dass es dazu noch einen "auto ... "-Eintrag braucht:

Code: Alles auswählen

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary [public] network interface

auto eth0
allow-hotplug eth0
iface eth0 inet static
address 193.x.x.22/24

# Defines the "default gateway" on a specific adapter and must not be applied to multiple adapters {
gateway 193.x.x.1
# } Defines the "default gateway" on a specific adapter and must not be applied to multiple adapters

#post-up ip route add 193.x.x.0/24 dev eth0 src 193.x.x.22 table rt2
#post-up ip route add default via 193.x.x.1 dev eth0 table rt2
#post-up ip rule add from 193.x.x.22/32 table rt2
#post-up ip rule add to 193.x.x.22/32 table rt2


auto eth0:0
allow-hotplug eth0:0
iface eth0:0 inet static
address 62.x.x.111/24

post-up ip route add 62.x.x.0/24 dev eth0:0 src 62.x.x.111 table rt4
post-up ip route add default via 62.x.x.1 dev eth0:0 table rt4
post-up ip rule add from 62.x.x.111/32 table rt4
post-up ip rule add to 62.x.x.111/32 table rt4


# The secondary [private] network interface
allow-hotplug eth1
iface eth1 inet static
address 192.168.80.251/24
post-up ip route add 192.168.80.0/24 dev eth1 src 192.168.80.251 table rt3
post-up ip route add default via 192.168.80.1 dev eth1 table rt3
post-up ip rule add from 192.168.80.251/32 table rt3
post-up ip rule add to 192.168.80.251/32 table rt3
root@debian11-nopcommerce:~#

Nun gibt ifconfig folgendes aus:

Code: Alles auswählen

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 193.x.x.22  netmask 255.255.255.0  broadcast 193.x.x.255
        ether 00:15:5d:79:97:2e  txqueuelen 1000  (Ethernet)
        RX packets 5886  bytes 417815 (408.0 KiB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 567  bytes 76131 (74.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
eth0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 62.x.x.111  netmask 255.255.255.0  broadcast 62.x.x.255
        ether 00:15:5d:79:97:2e  txqueuelen 1000  (Ethernet)
        
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.80.251  netmask 255.255.255.0  broadcast 192.168.80.255
        ether 00:15:5d:79:97:30  txqueuelen 1000  (Ethernet)
        RX packets 344  bytes 58536 (57.1 KiB)
        RX errors 0  dropped 184  overruns 0  frame 0
        TX packets 23  bytes 2818 (2.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 1030  bytes 1102813 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1030  bytes 1102813 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        

Sind die fehlenden "RX"/"TX"-Zeilen bei "eth0:0" normal weil diese generell bei "ethX:Y"-Einträgen nicht angezeigt werden?, sondern nur bei Einträgen mit "ethX"...? Falls das so ist, so ist das m.E. ziemlich strange - schliesslich sollte man ja pro IP erfahren wie es um die Pakete steht

(Auch dass 2 versch. IPs auf einem Adapter mit ein- und derselben MAC-Adresse sind ist m.E. ein wenig "irritierend" - nur schon deshalb hätte mir die Lösung mit dem virt. "macvlan"-Adapter, welcher als Bridge/Switch (Layer 2?) zu "eth0" fungiert besser gepasst. -> Dazu halt die spez. (A)RP-Filter-Einstellungen in der sysctl.conf damit der "macvlan"-Adapter ne eigene MAC-Adresse kriegen kann... aber wenn 2 versch. IP's mit einer MAC problemlos zusammenarbeiten - na ja, "keep it stupid simple" ist meist kein sooo schlechter Ansatz)

/etc/network/interfaces:

Code: Alles auswählen

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary [public] network interface

auto eth0
allow-hotplug eth0
iface eth0 inet static
address 193.x.x.22/24

# Defines the "default gateway" on a specific adapter and must not be applied to multiple adapters {
gateway 193.x.x.1
# } Defines the "default gateway" on a specific adapter and must not be applied to multiple adapters

#post-up ip route add 193.x.x.0/24 dev eth0 src 193.x.x.22 table rt2
#post-up ip route add default via 193.x.x.1 dev eth0 table rt2
#post-up ip rule add from 193.x.x.22/32 table rt2
#post-up ip rule add to 193.x.x.22/32 table rt2


auto eth0:0
allow-hotplug eth0:0
iface eth0:0 inet static
address 62.x.x.111/24

post-up ip route add 62.x.x.0/24 dev eth0:0 src 62.x.x.111 table rt4
post-up ip route add default via 62.x.x.1 dev eth0:0 table rt4
post-up ip rule add from 62.x.x.111/32 table rt4
post-up ip rule add to 62.x.x.111/32 table rt4


# The secondary [private] network interface
allow-hotplug eth1
iface eth1 inet static
address 192.168.80.251/24
post-up ip route add 192.168.80.0/24 dev eth1 src 192.168.80.251 table rt3
post-up ip route add default via 192.168.80.1 dev eth1 table rt3
post-up ip rule add from 192.168.80.251/32 table rt3
post-up ip rule add to 192.168.80.251/32 table rt3
root@debian11-nopcommerce:~#

...irgendwie bin ich nah dran. Werde mal noch ein wenig weiter recherchieren....

[bluestar]

Sind die fehlenden "RX"/"TX"-Zeilen bei "eth0:0" normal weil diese generell bei "ethX:Y"-Einträgen nicht angezeigt werden?

Ja, da es sich nur um einen Alias handelt und nicht um ein weiteres Netzwerkinterface.

Falls das so ist, so ist das m.E. ziemlich strange - schliesslich sollte man ja pro IP erfahren wie es um die Pakete steht

Das ist nicht strange sondern vollkommen normal und deine Anforderungen sind ja auch sehr schwammig, was du eigentlich genau erreichen möchtest.

(Auch dass 2 versch. IPs auf einem Adapter mit ein- und derselben MAC-Adresse sind ist m.E. ein wenig "irritierend" - nur schon deshalb hätte mir die Lösung mit dem virt. "macvlan"-Adapter, welcher als Bridge/Switch (Layer 2?) zu "eth0" fungiert besser gepasst. -> Dazu halt die spez. (A)RP-Filter-Einstellungen in der sysctl.conf damit der "macvlan"-Adapter ne eigene MAC-Adresse kriegen kann... aber wenn 2 versch. IP's mit einer MAC problemlos zusammenarbeiten - na ja, "keep it stupid simple" ist meist kein sooo schlechter Ansatz)

Der macvlan Ansatz kostet dich definitiv Performance zumindest wenn du über 10GBit Netzwerkkarten hast & bringt nur eine zusätzliche Fehlerquelle mit sich.

...irgendwie bin ich nah dran.

Da wir hier deinen Netzplan, deine genauen Anforderungen und dein Ziel nicht wirklich kennen, kann das niemand bestätigen oder wiederlegen.

[jmar83]

"Da wir hier deinen Netzplan, deine genauen Anforderungen und dein Ziel nicht wirklich kennen, kann das niemand bestätigen oder wiederlegen."

1 Kabel einer Mietleitung mit 2 Subnetzen drauf (193.x.x.0/24 sowie 62.x.x.0/24) und auf einer Debian 11 Hyper-V-VM soll nun über 1 Hyper-V-Netzwerkbridge (eth0 in Debian) jeweils 1 IP aus dem 193.x.x.0/24er-Netz (läuft bereits auf eth0) sowie eine weitere IP (gem. eurem Vorschlag auf eth0:0) vom 62.x.x.0/24er-Netz gesetzt werden.


(Wenn das Kabel unterbrochen ist, ist klar - aber wir haben schon erlebt, dass das eine ODER das andere Subnetz ausfällt... deshalb sollten die beiden IPs in einem DNS-A-Record-Round-Robin verwendet werden)

-> Das Routing sollte korrekt sein (die Einträge beim 192.168.80.x-Adapter -> ganz unten mit "rt3" funktionieren ja auch), aber der ping auf 62.x.x.111 geht leider noch immer nicht.

Während er aber geht auf: 193.x.x.22 sowie 192.168.80.251... na gut, evtl. ist irgendwo noch ein Flüchtigkeitsfehler drin, nehme die Einträge noch mal unter die Lupe.

[unitra]

[...]
Sind die fehlenden "RX"/"TX"-Zeilen bei "eth0:0" normal weil diese generell bei "ethX:Y"-Einträgen nicht angezeigt werden?, sondern nur bei Einträgen mit "ethX"...? Falls das so ist, so ist das m.E. ziemlich strange - schliesslich sollte man ja pro IP erfahren wie es um die Pakete steht

(Auch dass 2 versch. IPs auf einem Adapter mit ein- und derselben MAC-Adresse sind ist m.E. ein wenig "irritierend" - nur schon deshalb hätte mir die Lösung mit dem virt. "macvlan"-Adapter, welcher als Bridge/Switch (Layer 2?) zu "eth0" fungiert besser gepasst. -> Dazu halt die spez. (A)RP-Filter-Einstellungen in der sysctl.conf damit der "macvlan"-Adapter ne eigene MAC-Adresse kriegen kann... aber wenn 2 versch. IP's mit einer MAC problemlos zusammenarbeiten - na ja, "keep it stupid simple" ist meist kein sooo schlechter Ansatz)
[...]

RX/TX Statistiken für Subinterfaces ala eth0:0 sind glaube ich nicht möglich mit linux. Aber probiere es damit, eventuell spuckt das KOmmando etwas aus:

Code: Alles auswählen

ip -s a

Habe keine Subinterfaces gerade zur Hand.

Zu der 2-ten Frage. Die MAC Adresse ist nur lokal signifikant. Sobald das Paket die NIC Schinttstelle passiert hat und in Richtung LAN geschickt wird, erstetzt der Router die incoming MAC Adresse (eth0) mit der MAC Adressee der outgoing Schnittstelle (eth1). MAC Adresse wird getauscht, da aber noch 2 IP Adressen genutzt werden auf der selben NIC und es noch zusätzlich ein Router ist (Layer3) IP layer, sieht kommisch aus, ist aber irrelevant für den Router. Eindeutige MAC Adressen sind wichtig für Switches, nicht so für Router.

[jmar83]

Danke für die Feedbacks!!

Eine andere Möglichkeit wäre es, unter Hyper-V 2 virt. Bridges auf dieses Kabel einzurichten, dann hätte man in der VM 2 [virtuelle] phys. Adapter eth0 sowie eth1.

Und wenn das dann auch Stress macht, so könnte man noch 2 echte phys. Adapter verwenden, sprich: 2 Kabel (vom gleichen phys. SWitch aus!) am phys. Server montieren, dann pro (phys.) Etherneh-Anschluss jeweils eine Hyper-V-Bridge (1:1) einrichten... *** BASTEL, BASTEL!! ***

[jmar83]

Oder eben die Sache mit z.B. einem OpenWRT-Router, der am ext.-Port jeweils die 2 IPs (aus dem 2 Subnetzen) annimmt und dann per Portforward weiterleitet.

Gibt schätzungsweise ca. 27 Lösungsvarianten...

[jmar83]

Eigentlich hab ich mal gedacht dies wäre ein 5-Minuten-Task. Realiter ist's eher ein 5-Tage-Task...

[bluestar]

-> Das Routing sollte korrekt sein (die Einträge beim 192.168.80.x-Adapter -> ganz unten mit "rt3" funktionieren ja auch), aber der ping auf 62.x.x.111 geht leider noch immer nicht.

Deine interfaces Datei ist auch nach wie nicht korrekt.
1) Prüfe mal ob deine Regeln, die du mit ip rule add ... anlegst auch die korrekten Prioritäten haben, ein einfaches ip rule liefert dir da die Antwort.
2) Wenn in deiner "main" Routing-Tabelle der Default-Gateway hinterlegt ist, dann bekommst du mit ip rule auch Schwierigkeiten, daher wäre es besser auf gateway x.x.x.x zu verzichten und das Default-Gateway in die Routing-Tabelle “default" einzutragen.
3) Deine komische ip rule add to Regel ist komplett unnötig.

Letztlich müssen deine ip rule Prioritäten etwa folgendermaßen aussehen:

Code: Alles auswählen

0:	from all lookup local
999:	from all lookup main
20000:	from 62.x.x.0/24 lookup rt3
32767:	from all lookup default

Und die Routingtabellen "rt3" und "default" korrekt befüllen.

[jmar83]

@unitra: "Die MAC Adresse ist nur lokal signifikant."

Beides IPs sind aber öffentlich... 193.x.x.0/24 sowie 62.x.x.0/24...

[bluestar]

@unitra: "Die MAC Adresse ist nur lokal signifikant."

Beides IPs sind aber öffentlich... 193.x.x.0/24 sowie 62.x.x.0/24...

Und wen juckt da die MAC Adresse? Am Ende des jeweiligen Routers deiner Provider gibt's die MAC eh nicht mehr, sondern nur noch IP Pakete.

[jmar83]

@bluestar: Danke, werde mal weiterschauen...

@bluestar: Ebenfalls vielen Dank!!