sonie69
Goto Top

Linux 2 IP auf einem Interface und Routing einrichten

Ich habe hier ein Redhat 8.8.,

auf dem sind für ein physikalisches Interface 2 IP-Adressen konfiguriert. Wie muss das Routing eingerichtet werden, damit der Traffic auch die richtige IP für ausgehend verwendet?

Bsp:
IP1 10.0.0.10 GW 10.0.0.1
IP2 10.0.0.12

Das Routing für eine DST soll also hier dann die IP2 verwenden.

Content-Key: 93297565890

Url: https://administrator.de/contentid/93297565890

Printed on: February 23, 2024 at 06:02 o'clock

Member: NordicMike
NordicMike Sep 04, 2023 at 11:33:53 (UTC)
Goto Top
Ich gehe mal davon aus, dass du eine 24er Subnetzmaske verwenden willst, dann wirst du mit zwei gleichen IPs Probleme haben.
Mitglied: 7907292512
7907292512 Sep 04, 2023 updated at 12:11:11 (UTC)
Goto Top
Was sagt der Bauer wenn er in den Stall kommt?

Per Default muss man da gar nichts am Routing machen, das klappt out of the Box, die SRC IP wird automatisch passend zur der Verbindung in der Connection-State-Table gewählt, sonst würde TCP ja gar nicht funktionieren wenn der Host einfach nach belieben eine andere Adresse wählen würde....

Nur in Spezialfällen braucht man das, wenn es um ausgehende Verbindungen zu bestimmten Gegenstellen geht ...
Multiple IP source on single interface in Linux
Und zwei IPs aus dem selben Subnetz (sieht hier so aus) macht keinen Sinn.

Gruß sid
Member: Sonie69
Sonie69 Sep 04, 2023 at 11:59:07 (UTC)
Goto Top
Zitat von @7907292512:

Per Default muss man da gar nichts am Routing machen, das klappt out of the Box, die SRC IP wird automatisch passend zur der Verbindung in der Connection-State-Table gewählt, sonst würde TCP ja gar nicht funktionieren wenn der Host einfach nach belieben eine andere Adresse wählen würde....

Nur in Spezialfällen braucht man das, wenn es um ausgehende Verbindungen zu bestimmten Gegenstellen geht ...
Multiple IP source on single interface in Linux
Und zwei IPs aus dem selben Subnetz (sieht hier so aus) macht keinen Sinn das führt am Ende nur zu Problemen diverser Art.

Gruß sid

Danke für die Info, war auch nicht meine ID. Aber RedHat beschreibt das in der Konfig und SAP meldet Fehler, wenn die Verbindung ausgehend ist.
Mitglied: 7907292512
7907292512 Sep 04, 2023 updated at 12:05:51 (UTC)
Goto Top
Wenn du das für ausgehende Verbindungen brauchst, wie im Link eine separate Routing-Tabelle mit Default Route und passender SRC Address darin anlegen und eine Routing-Rule erstellen die den Traffic an die jeweilige Gegenstelle über diese Tabelle laufen lässt, fertsch.
Aber wie gesagt zwei IPs am selben IF ist bäh bäh und nochmals bäh vor allem wenn hier SAP im Einsatz ist, wenn dann separate VLAN Interfaces oder MACVLAN IFs auf dem Parent IF benutzen !
Member: aqui
aqui Sep 04, 2023 updated at 12:03:34 (UTC)
Goto Top
Vielleicht sollte man noch erwähnen das ein solches Stetup im TCP/IP nicht Standard konform ist. 2 IP Netze auf einem gemeinsamen Layer 2 "Draht" sind auf produktiven Servern immer ein NoGo und sollte nur kurzfristig zur Migration von z.B. IPs gemacht werden, niemals aber produktiv. Solche Gruselsetups zeugen immer von schlechtem oder mangelhaftem IP Adressdesign.
Einer der gravierensten Gründe ist das alle ICMP Steuerpakete immer nur vom Primärinterface kommen niemals aber vom Secondary. Desweiteren belastet ein Routing solcher Netze immer die CPU da sowas nur in Software rennt.
Sowas schafft über kurz oder lang immer Probleme und Instabilitäten und daraus resultieren genau diese Fehler wie oben beschrieben.
Deutlich sinnvoller und netztechnisch korrekt wäre ein Splitting bzw. eine saubere Segmentierung in VLAN Interfaces wie z.B. HIER beschrieben oder ein korrektes IP Adressdesign mit einer singulären IP auf der NIC.
Member: LordGurke
LordGurke Sep 04, 2023 at 12:08:46 (UTC)
Goto Top
Die Source-IP wird nicht durch die Reihenfolge der IPs auf dem Netzwerkinterface bestimmt sondern basierend auf der "Nähe" zum Gateway. Klingt erstmal komisch, aber es wird in dem Fall die 10.0.0.10 als Source genommen, weil sie näher an 10.0.0.1 dran ist, als die .12.

Du kannst aber die Source-IP definieren, allerdings nur über eine statische Route:
ip route replace default via 10.0.0.1 src 10.0.0.12
ip route replace 10.0.0.0/24 dev ethX src 10.0.0.12 metric 0

Mit der ersten Zeile setzt du die Source-Adresse die verwendet wird, sobald Traffic über das Default-Gateway geschickt wird. Die zweite Zeile definiert die Source-Adresse, wenn du im selben Subnetz arbeitest - da muss "ethX" durch den Namen des Netzwerk-Interface gesetzt werden.

Wie die Routen bootfest konfiguriert werden hängt davon ab, wie du das Netzwerk konfigurierst (NetworkManager, systemd-networkd, Interface-Scripts...).


Zitat von @NordicMike:

Ich gehe mal davon aus, dass du eine 24er Subnetzmaske verwenden willst, dann wirst du mit zwei gleichen IPs Probleme haben.

Das Gerücht hält sich hartnäckig, aber es ist nach RFC 791 von 1981, Abschnitt 3.2, Absatz "Addressing", absolut standardkonform sowas zu tun.
Member: Lochkartenstanzer
Lochkartenstanzer Sep 04, 2023 at 12:44:45 (UTC)
Goto Top
Zitat von @7907292512:

Und zwei IPs aus dem selben Subnetz (sieht hier so aus) macht keinen Sinn.
Das kann schon sinnvoll sein, wenn eine Kiste Dienste mit übernehmen soll, die bisher auf einer anderen Kiste mit einer anderen IP-Adresse waren und die Clients schwierig umzustellen sind. Das gilt allerdings i.d.R. nur für eingehende Verbindungen.

Bei ausgehenden verbindungen ist das i.d.R. weniger sinnvoll, außer man halt noch Anwendungen an der Backe, die nur von bestimmten IP-Adressen aus Verbindungen zum Partner aufbauen dürfen. Dann hat man aber an der Konzeption etwas falsch gemacht.

lks
Member: Lochkartenstanzer
Lochkartenstanzer Sep 04, 2023 at 12:46:53 (UTC)
Goto Top
Zitat von @aqui:

Vielleicht sollte man noch erwähnen das ein solches Stetup im TCP/IP nicht Standard konform ist. 2 IP Netze auf einem gemeinsamen Layer 2 "Draht" sind auf produktiven Servern immer ein NoGo und sollte nur kurzfristig zur Migration von z.B. IPs gemacht werden, niemals aber produktiv. Solche Gruselsetups zeugen immer von schlechtem oder mangelhaftem IP Adressdesign.

Der Jung hat, so wie es aussieht nicht 2 Netze sondern zwei IP-Adressen aus demselben Netz am gleichen Draht. face-smile

lks
Member: Lochkartenstanzer
Lochkartenstanzer Sep 04, 2023 at 12:51:21 (UTC)
Goto Top
Zitat von @Sonie69:

Bsp:
IP1 10.0.0.10 GW 10.0.0.1
IP2 10.0.0.12


Moin,

frag nach, ob die erste IP-Adresse (hier 10.0.0.10/24) wichtig ist und wofür die gebraucht wird. Wenn nicht, einfach diese entfernen und nur noch die zweite IP-Adresse am Interface konfigurieren.

lks
Member: LordGurke
LordGurke Sep 04, 2023 updated at 13:01:55 (UTC)
Goto Top
Zitat von @aqui:

Vielleicht sollte man noch erwähnen das ein solches Stetup im TCP/IP nicht Standard konform ist. 2 IP Netze auf einem gemeinsamen Layer 2 "Draht" sind auf produktiven Servern immer ein NoGo und sollte nur kurzfristig zur Migration von z.B. IPs gemacht werden, niemals aber produktiv. Solche Gruselsetups zeugen immer von schlechtem oder mangelhaftem IP Adressdesign.

Ich verstehe das so, dass es zwei IP-Adressen aus dem selben Präfix sind.
Nichtsdestotrotz verweise ich ein weiteres Mal auf RFC 791 von 1981, Abschnitt 3.2, Absatz "Addressing".
Da gibt es keine Einschränkung auf "Muss im selben Subnetz" oder - gemäß der damaligen Zeit - "Muss in der selben Netzklasse sein".

Einer der gravierensten Gründe ist das alle ICMP Steuerpakete immer nur vom Primärinterface kommen niemals aber vom Secondary. Desweiteren belastet ein Routing solcher Netze immer die CPU da sowas nur in Software rennt.

A1) ICMP-Antworten auf Dinge wie Echo-Request werden von der richtigen IP kommen. Also, da bin ich mir sogar sicher, denn das funktioniert in der Praxis wirklich so. Damit folgt das dem beschriebenen Modus Operandi aus dem RFC.
A2) Dass ICMP-Pakete von einer unerwarteten IP kommen ist in vielen Fällen rein prinzipbedingt überhaupt nicht anders möglich. Ich verweise da auf "Packet too big", "Administratively prohibited" oder "Time exceeded". Die können ja rein logisch nur von den zwischenliegenden Routern generiert werden und können nicht von der adressierten Ziel-IP kommen. Das ist also auch kein Problem, damit muss ein standardkonformer Client nämlich rechnen. Und, nachdem ja die Header des ursprünglichen Paket in den meisten Nachrichten mitgeliefert werden, ist es für den Client auch ohne weiteres möglich zu erkenenn worum es geht.

B) Dass "das Routing nur auf der CPU" stattfindet ist doch prinzipbedingt bei allen Servern so, egal wie viele Adressen du hast. Oder spielst du auf die Inhärente Krankheit der Cisco-Gurken an, die mehrere Subnetze auf einem Routing-Interface betrifft und die man mit "ip route-cache same-interface" lösen muss?

Deutlich sinnvoller und netztechnisch korrekt wäre ein Splitting bzw. eine saubere Segmentierung in VLAN Interfaces wie z.B. HIER beschrieben oder ein korrektes IP Adressdesign mit einer singulären IP auf der NIC.

Ich zitiere jetzt mal aus dem RFC:

The local address, assigned by the local network, must allow for a single physical host to act as several distinct internet hosts.
That is, there must be a mapping between internet host addresses and network/host interfaces that allows several internet addresses to correspond to one interface.

Das ist standardkonform sagen die Leute, die den Standard geschrieben haben.
Falls es Betriebssysteme oder Router gibt, die damit nicht klar kommen, sind die es, die den Standard verletzen.
Member: Lochkartenstanzer
Lochkartenstanzer Sep 04, 2023, updated at Sep 08, 2023 at 10:30:45 (UTC)
Goto Top
Zitat von @LordGurke:

Ich zitiere jetzt mal aus dem RFC:

The local address, assigned by the local network, must allow for a single physical host to act as several distinct internet hosts.
That is, there must be a mapping between internet host addresses and network/host interfaces that allows several internet addresses to correspond to one interface.

Das ist standardkonform sagen die Leute, die den Standard geschrieben haben.
Falls es Betriebssysteme oder Router gibt, die damit nicht klar kommen, sind die es, die den Standard verletzen.

In früheren zeiten hatte ich ja schon öfter Diskussionen mit aqui über diese Thema.
Fakt ist:

  • Es verkompliziert die Dinge.
  • Jemand mit Erfahrung hat kein Problem das so zu verwenden und auch mit eventuellen Problemen zurecht zu kommen.
  • Jemand ohne Erfahrung sitzt da wie der Ochse vor der Melkanlage und weiß nicht, was er im Problemfall machen soll.

Daher ist das sinnvollste, so ein Setup i.d.R. zu vermeiden., wenn man nicht der Netzwerkprofi ist.

lks
Member: Sonie69
Sonie69 Sep 08, 2023 at 10:27:46 (UTC)
Goto Top
Vielen Dank für die vielen Antworten und Meinungen. Redhat betont hier die RFC 791. Und der Sinn der Sache ist die Anwendung auf eine virtuelle IP zu konfigurieren um sich die Anpassung der Hardware IP zu sparen... liegt nicht in meinem Verantwortungsbereich.
Member: aqui
aqui Sep 08, 2023 updated at 10:36:52 (UTC)
Goto Top
Redhat betont hier die RFC 791.
Der aber mit einer nicht Standard konformen und falschen Anwendung einer Secondary IP auf einem Interface rein gar nichts zu tun hat. Es ist und bleibt eine unsaubere Frickelei mit der man niemals einen Produktionsserver langfristig betreiben sollte. Aber nundenn...(glücklicherweise) ja nicht dein Verantwortungsbereich... face-wink

Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!