Linux 2 IP auf einem Interface und Routing einrichten

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

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 !

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.

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:

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...).



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.

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

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

lks

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

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".


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?


Ich zitiere jetzt mal aus dem RFC:


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