Anfängerfrage: IP Route

[haunt]

Hallo zusammen,
vielleicht mag und kann mir jemand helfen.

Ich habe eine Netzwerkadresse 192.168.1.81
dort habe ich im Yast zwei weitere Adressen hinzugefügt.
virtuellerName A 192.168.1.50
virtuellerName B 192.168.1.52

Also auf eth0, damit ich die IP Adresse auch mal auf einem anderen Gerät aktivieren kann. Soweit klar.
Doch IP Route habe ich vergessen - die Verbindung soll eigentlich über den Virtuellen Namen B gehen.

Ich versteh ehrlich gesagt nicht wie ich jetzt die Priorität für B erhöhen, kann? Kann mir da jemand helfen?

Beste Grüße

 

[conf_t]

XY-Problem ?
Was willst du denn überhaupt erreichen? Wenn wir das wissen, kann man schauen, ob du das überhaupt richtig angehst. So versteht man jedenfalls nicht, was dein Ziel ist und kann so nicht helfne.

Bisher verstehe ich nur, du hast an einem Rechner die IP 192.168.1.81 auf der physikalischen NIC, dann noch dort 2 weitere mit der .50 und .52 gesetzt, aber warum soll der Verkehr eine der virtuellen NICs nutzen? Sind doch alle im gleichen Netz (nehme mal an, du has /24er Maske ), was spricht dagegen weiterhin die 192.168.1.81 zu nutzen?

 

[d2boxSteve]

Wo genau (welcher Datei) hast du diese Adressen eingefügt?
Yast ist im allgemeinen das Installertool von Suse ...

Zu einer IP Adresse gehört immer auch eine Subnetzmaske. Ohne die kann man deine Frage auch nicht beantworten. Wenn die Adressen alle die selbe Maske haben (z.B. 255.255.255.0) dann kennt der Rechner das bereits weil direct connected.

 

[madmax2010]

Ich habe keine ahnung, was diese deutschen Fantasy Bgeriffe bedeuten sollen, aber:

ip route add {NETWORK/MASK} via {GATEWAYIP}
ip route add {NETWORK/MASK} dev {DEVICE}

ist so die generelle syntax.
und hier ein Beispiel:
ip route add 192.168.42.0/24 via 10.0.0.100 dev eth0

eine route ins Netz 192.168.42.0/24 via 10.0.0.100 unter verwendung von dev eth0

 

[Drewkev]

Was ist denn das eigentliche Ziel? Denn irgendwie ist das nicht ganz klar.

Die sind doch alle im gleichen Netz, oder nicht?

 

[d2boxSteve]

@Drewkev das Netz ist ja nichtmal angegeben, könnte ja auch in /30 zerteilt sein .... deswegen fragte ich nach der Netzmaske.

 

[Drewkev]

Ja, muss er eh nachreichen.

 

[Raijin]

Bitte erkläre in einfachen Worten was dein ZIEL ist. Was soll am Ende dabei rauskommen, wenn es fertig ist? Idealerweise noch ergänzt um das WARUM, weil gegebenenfalls das ganze Vorhaben bereits auf falschen Vorstellungen basiert und eventuell sogar hinfällig ist.

Um das WIE kann sich dann der Thread kümmern, weil du ja offenbar nicht weiterkommst und dich eventuell schon viel zu weit auf den Holzweg begeben hast, weiter weg von der Lösung des eigentlichen Problems als zu Beginn....

 

[0x8100]

Ich versteh ehrlich gesagt nicht wie ich jetzt die Priorität für B erhöhen, kann?

entsprechende route mit passender metric hinzufügen.

ausgangspunkt:

root@ryzen: ~ # ip addr show wlp5s0
3: wlp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.1.28/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp5s0
root@ryzen: ~ # ip route show
default via 192.168.1.1 dev wlp5s0 proto dhcp src 192.168.1.28 metric 600
192.168.1.0/24 dev wlp5s0 proto kernel scope link src 192.168.1.28 metric 600

secondary ip hinzufügen -> route bleibt gleich und traffic geht weiterhin über die primary ip:

root@ryzen: ~ # ip addr add 192.168.1.111/24 dev wlp5s0
root@ryzen: ~ # ip addr show wlp5s0
3: wlp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.1.28/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp5s0
    inet 192.168.1.111/24 scope global secondary wlp5s0
root@ryzen: ~ # ip route show
default via 192.168.1.1 dev wlp5s0 proto dhcp src 192.168.1.28 metric 600
192.168.1.0/24 dev wlp5s0 proto kernel scope link src 192.168.1.28 metric 600

default-route ändern, traffic geht jetzt über 192.168.1.111:

root@ryzen: ~ # ip route add default via 192.168.1.1 src 192.168.1.111 metric 500
root@ryzen: ~ # ip route show
default via 192.168.1.1 dev wlp5s0 src 192.168.1.111 metric 500
default via 192.168.1.1 dev wlp5s0 proto dhcp src 192.168.1.28 metric 600
192.168.1.0/24 dev wlp5s0 proto kernel scope link src 192.168.1.28 metric 600

 

[haunt]

Ah sorry, also die Idee ist eben, eine Hochverfügbarkeitslösung zu "simulieren". Daher wird mal von dem einen, mal vom anderen Rechner gesendet. Das soll über die "virtuelle IP Adresse" realisiert werden. Subnetmaske ist /24.
Die generelle Syntax, denke ich, verstehe ich. Aber wie kann ich in diesem Fall den Rechner B in der Prio nach oben bekommen.

Wenn ich

ip route add 192.168.1.0/24 dev eth0

einfüge wird mir das ja nicht helfen, dass die Kommunikation via Server B geht?

 

[Drewkev]

Aber wie kann ich in diesem Fall den Rechner B in der Prio nach oben bekommen.

Routen haben eine sog. Metrik, das dürfte das sein was du suchst.

 

[madmax2010]

eine Hochverfügbarkeitslösung zu "simulieren". Daher wird mal von dem einen, mal vom anderen Rechner gesendet

da kannst du ja schon fast dns-rr machen.
Oder einfach HA Proxy nehmen.
Oder nginx

 

[haunt]

Hier sind Anfänger am Werk. Die Config sieht jetzt erstmal aus wie bei 0x8100( Andere IP Adressen ist klar )
Vielen Dank für die Tipps und Anregungen, man lernt ja auch nur aus Fehlern. Kann ja auch falsch sein. Wenn ich denn dann auch auf dem Holzweg sein mag, verstehe ich vielleicht später besser wie ich die Routen nutzen kann.
Daher danke für das ganze Verständnis und ich gebe gleich mal Rückmeldung ob es geklappt hat.

 

[Raijin]

Niedrige Metrik = höhere Priorität.

Die Routingtabelle funktioniert im Prinzip so:


Das Betriebssystem sucht eine Route, die zum Ziel X führt. Die Routingtabelle wird nun zunächst nach dem Eintrag durchsucht, der am genauesten passt. Entscheidend ist dabei ob die Ziel-IP X im in der Route definierten Subnetz liegt und die Subnetzmaske möglichst spezifisch ist
Subnetzmaske = 0.0.0.0 <<<unspezifischer spezifischer>>> 255.255.255.255
Werden zwei bis auf das Gateway und die Metrik identische Routen gefunden - wie es bei deinen virtuellen Schnittstellen der Fall wäre - wird die Route mit der niedrigeren Metrik genommen:


Beispiele:

Ziel: 192.168.1.23

#1
Route 1: 192.168.1.0 / 255.255.255.0 / via Interface1 @ 192.168.1.50 / Metrik 1
Route 2: 192.168.1.0 / 255.255.255.0 / via Interface 2 @ 192.168.1.51 / Metrik 2

Beide Routen decken das komplette /24er Subnetz (Bereich = 192.168.1.0 - 192.168.1.255) ab und sind somit gleich spezifisch, aber Route 1 hat die niedrigere Metrik und gewinnt. Die Metrik wird nur dann ausgewertet, wenn es notwendig ist, weil mehrere gleiche Routen gefunden wurden wie hier.


#2
Route 1: 192.168.0.0 / 255.255.254.0 / via Interface1 @ 192.168.1.50 / Metrik 1
Route 2: 192.168.1.0 / 255.255.255.0 / via Interface 2 @ 192.168.1.51 / Metrik 2

In diesem Beispiel würden zwar beide Routen das Ziel erreichen können, aber Route 1 umfasst einen größeren Bereich (Subnetz = 192.168.0.0 - 192.168.1.255) und ist somit unspezifischer als Route 2. Deswegen gewinnt Route 2 und die Metrik wird nicht ausgewertet.


#3
Route 1: 192.168.1.0 / 255.255.255.0 / via Interface1 @ 192.168.1.50 / Metrik 1
Route 2: 192.168.1.23 / 255.255.255.255 / via Interface2 @ 192.168.1.51 / Metrik 2

Auch hier gewinnt wieder Route 2, weil sie in diesem Fall extrem spezifisch ist und ausschließlich die Ziel-IP umfasst. Die Metrik ist ebenso irrelevant wie in #2.


Die Standard-Route 0.0.0.0 / 0.0.0.0 ist im übrigen eine extrem unspezifische Route, weil sie auf ALLE Ziel-IP-Adressen passt, wie eine Wildcard. Wird also keine bessere Route gefunden, gewinnt die Standard-Route, wenn denn eine konfiguriert ist (kommt automatisch, wenn man bei einer Schnittstelle ein Standard-Gateway einträgt.

 

[conf_t]

Sehr gut erklärt. Mir war das ehrlich zu viel Arbeit das soweit herunter zu brechen

 

[riversource]

Ich dachte, das Ziel ist es, dass der Rechner von unterschiedlichen IP Adressen sendet und so tut, als seien es mehrere? Weil das wird mit Routen allein nicht funktionieren. Wenn ich mehrere IPs auf einem Interface habe, dann kann ich so viele Subnetzrouten ins gleiche Netz mit unterschiedlichen Metriken hinzufügen, wie ich möchte, das wird an der Quelladresse nichts ändern.

Welche Absenderadresse ein Gerät standardmäßig nimmt, kann ich in gewissen Grenzen mit der preferred_lft beeinflussen. Außerdem gibt es eine gewisse Chance, dass er mit der Adresse antwortet, auf der er angesprochen wurde (nicht sicher!). Nicht zuletzt kann man policy based routing einführen und nach spezifischen Kriterien eine Routenauswahl treffen (aber nicht zwangsläufig die Quelladresse).

Ich denke, um eine "Hochverfügbarkeitslösung" zu simulieren, muss man tatsächlich irgendwie mehrere Instanzen eines Servers bereitstellen. Zum Beispiel in Form von Containern.

 

[haunt]

Also eigentlich wollte ich nur wissen wie ich, wenn ich mehere IPs habe, die Kommunikation über eine priorisieren kann.
Das klappt jetzt auch erfolgreich.

 

[Raijin]

Wenn ich mehrere IPs auf einem Interface habe, dann kann ich so viele Subnetzrouten ins gleiche Netz mit unterschiedlichen Metriken hinzufügen, wie ich möchte, das wird an der Quelladresse nichts ändern.

Na eben doch. Mit dem src Parameter bei ip route add teilt man dem System mit welche Quell-IP beim Abschicken von Paketen verwendet werden soll. Hat ein Interface also mehrere IP-Adressen und man legt für jede solch eine Route an bzw ändert die Metrik, kann man steuern von welcher IP das Betriebssystem Pakete abschickt. (*)
Unter Linux kann man wahlweise ein Interface angeben - hierbei sucht sich das OS in der Tat selbst die "Haupt-IP" raus - oder man spezifiziert die konkrete Quell-IP.

Mit Windows ginge das so nicht, wenn ich mich nicht täusche, weil man keine IP als Quelle angeben kann, sondern nur die ID der Schnittstelle. Folglich würde Windows sich eine der IP-Adressen aussuchen, sei es die erste, die niedrigste, die höchste oder die hübscheste.

Natürlich kann eine Lösung via Routingtabelle nur die Quell-IP anhand der Metrik umschalten. Damit lässt sich keine dynamische Umgebung bauen, bei der parallel von allen lokalen IPs gesendet wird. Es wird ausschließlich die Route mit der niedrigsten Metrik und die damit verbundene Quell-IP verwendet, die anderen Routen mit den übrigen IPs werden NICHT genutzt bis man die Metriken ändert.

Unterm Strich hätte solch eine Lösung also denselben Effekt wie wenn man einfach die lokale IP der Schnittstelle ändert.


(*)
Das bezieht sich zumindest auf Pakete von Verbindungen deren Quell-IP von der Anwendung, die die Verbindung aufbaut, nicht näher spezifiziert wurde.
Möchte man parallel mehrere Absende-IPs verwenden, so muss dies von der Anwendung selbst getan werden. Einem socket teilt man vor dem connect() mit bind() mit welche Quell-IP verwendet werden soll. Lässt man bind() weg, entscheidet das Betriebssystem automatisch welche Quell-IP verwendet wird.
Für parallele Verbindungen von verschiedenen Quell-IPs müsste eine Anwendung daher explizit mehrere Verbindungen von bestimmten Quell-IPs aufbauen - oder mehrere Anwendungen bzw. Instanzen, die jeweils eine andere IP verwenden.