ketanest112
Goto Top

Root Server sekundäre IP auf anderen Server routen

Hallo zusammen,

Ich habe diesbezüglich leider nichts im Netz gefunden, daher frag ich mal wieder bei euch nach.

Folgendes Szenario:
Ich habe einen Root-Server (KVM) bei netcup. Auf dem Server habe ich eine zweite IP Adresse eingerichtet.
Ich habe jetzt ein Upgrade auf einen performanteren Root-Server gemacht, dazu musste ich ihn bestellen und den anderen kündigen (anders ist es laut Support Team nicht möglich).
Die Umstellung der zweiten IP Adresse auf den anderen Server kostet einmalig 45 €, die würde ich gerne vermeiden. Ich werde mir dann für den neuen Server sowieso eine zusätzliche IP bestellen, da das günstiger ist.
Bis dahin müsste ich allerdings die 2. IP vom alten Server auf dem neuen Server nutzen. Sollte mit Routing ja eigentlich kein Problem sein.
Also die 2. IP des alten Servers auf dem neuen Server als zusätzliche Adresse eingerichtet und beim alten entfernt. Dann zwei Routen auf dem alten Server eingerichtet (eine für den neuen Server und einen für die IP Adresse).
Routingtabelle schaut jetzt so aus (S1-IP2 = Server alt sekundäre IP, S2-IP1 = Server neu primäre IP)

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 188.68.36.1 0.0.0.0 UG 0 0 0 ens3
188.68.36.0 0.0.0.0 255.255.252.0 U 0 0 0 ens3
S1-IP2 S2-IP1 255.255.255.255 UGH 0 0 0 ens3
S2-IP1 0.0.0.0 255.255.255.255 UH 0 0 0 ens3

Wenn ich jetzt die S1-IP2 pingen will, kommt nix bei raus (außer auf dem neuen Server logischerweise). Ein Traceroute hört bei Server 1 auf der primären IP auf und meldet dann "Zielhost nicht erreichbar".

Firewalltechnisch ist icmp auf beiden Servern freigegeben.

Habt ihr da vielleicht eine Idee?

Danke euch schonmal
Grüße
Ketanest

EDIT: Hab grad mal den Ping auf den zweiten Server getestet: Auch unreachable. Daraufhin die Routingtabelle angepasst. Der letzte Eintrag lautet jetzt nicht mehr:
S2-IP1 0.0.0.0 255.255.255.255 UH 0 0 0 ens3
sondern:
S2-IP1 188.68.36.1 255.255.255.255 UH 0 0 0 ens3
aber es geht trotzdem noch nicht

Content-Key: 389744

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

Ausgedruckt am: 29.03.2024 um 11:03 Uhr

Mitglied: falscher-sperrstatus
falscher-sperrstatus 17.10.2018 um 11:49:16 Uhr
Goto Top
Hallo Ketanest,

das, was du machst ist hunderte an € in Zeit in den Sand setzen, damit du 45€ sparst.

Aber kann man schon so machen, die Routingtabelle bringt dir aber nichts, denn du musst forwarden

Viele Grüße,

certifiedit.net
Mitglied: ketanest112
ketanest112 17.10.2018 um 11:59:00 Uhr
Goto Top
Hallo certified.net,

danke für die schnelle Antwort.
Warum bringt mir denn die Routingtabelle nichts?
Wenn ich forwarde, benötige ich doch die zweite IP auf dem neuen Server direkt oder bin ich da auf dem falschen Dampfer?
Mir gehts ja drum, die 2. IP Adresse noch nutzen zu können, solange der erste Server noch läuft, ohne die 2. Adresse für den 2. Server schon buchen zu müssen.
Bin halt ein kleiner Sparfuchs... Da investiere ich lieber mehr Zeit darin...

Gruß
Ketanest
Mitglied: SlainteMhath
SlainteMhath 17.10.2018 um 12:03:26 Uhr
Goto Top
Moin,

wenn du die 2te IP von Server Alt auf Server Neu Umleiten willst hilft dir nur ein Portforward am Server Alt.

Die Routingtabelle interessiert alle Host ausserhalb deiner Server nicht.

Sparfuchs
Beachten solltest du auch das du dann 3fachen Traffic hast: Server Alt eingehend + ausgehend, Server neu eingehend

lg,
Slainte
Mitglied: ketanest112
ketanest112 17.10.2018 aktualisiert um 12:12:24 Uhr
Goto Top
Hi SlainteMhath,

woran liegt das denn, dass die Routingtabelle keinen außer meiner Server interessiert.
Laut netcup wird von denen die sekundäre IP auf die Primäre IP des Servers geroutet. Wen mein Server jetzt aber sagt: "Moment Leute, die IP gehört mir gar nicht, um die IP zu erreichen, müsst ihr euch an den S2-IP1 wenden", sollte das doch eigentlich gehen oder irre ich mich da (offensichtlich tu ich das, sonst würde es ja gehen).
EDIT: Beziehungsweise das wäre ja Forwarding, mein Server müsste ja die Pakete an die S1-IP2 aufgrund seiner Routingtabelle an den S2-IP1 weiterrouten oder?
Hab mit Routing noch nicht allzuviel Erfahrung (zumindest nicht mit WAN-Routing).

Und der Traffic stellt kein Problem dar, es sind nur geringe Datenmengen, die da drüber laufen (außerdem hab ich keine Trafficbegrenzung).

Gruß
Ketanest
Mitglied: falscher-sperrstatus
falscher-sperrstatus 17.10.2018 um 12:12:14 Uhr
Goto Top
weil du keinen Router von denen bedienst, sondern einen Server, der nur für sich da steht.

Ich würde sagen, weitere Antworten dann gegen Dienstleistung (=PN/Geld), damit die Entscheidung leichter fällt es gleich richtig über die zweite IP@Server2 zu machen.
Mitglied: SlainteMhath
SlainteMhath 17.10.2018 um 12:38:05 Uhr
Goto Top
Hab mit Routing noch nicht allzuviel Erfahrung
merkt man face-smile

Routing: Layer 3-7 des Pakets werden "unbearbeitet" an den next hop weitergeleitet
Forwarding: Ziel-IP und/oder Port wird (im Layer 3/4) ersetzt und das Paket wird ans routing übergeben.

Mein Tipp: Zahl die 45 Euro, alles andere ist Gefrickel und führt eher früher als später zu Problemen
Mitglied: maretz
Lösung maretz 17.10.2018 um 16:25:56 Uhr
Goto Top
Nun - warum SOLLTE meinen Rechner deine Routing-Tabelle interessieren? Mich interessiert ja auch nicht die Routing-Tabelle von meinem Provider. Ich schicke dem ein Paket in dem ne IP steht. DER soll sehen was der damit macht. Also hat der bestimmte Regeln und leitet die weiter.
DU hast aber nur nen Server. Der weiss nichts davon das er ein Paket weiterleiten soll. Also fällt dem das Paket auf die Füsse, der guckt "jap, is eine von meinen IPs" und stellt dann verwirrt fest das er kein Programm hat was damit umgehen will -> also zurück zum Absender mit "no socket".

Also musst du jetzt deinem Rechner irgendwie 2 Dinge sagen:
a) Er soll generell erst mal überhaupt die Daten für die IP xyz an den Host ABC weiterleiten
b) Er soll das ganze für den Port X und Protokoll Y machen.
c) (Je nach Struktur) Er soll das ganze auch noch NAT'en

Nehmen wir mal an du hast 2 IPs: 1.1.1.1 und 1.1.1.2. Jetzt willst du irgendwie (tm) deinem Server sagen das er die 1.1.1.1 hinter einem Gateway findet (was ja schon mal ok ist). ABER: Die IP hängt ja jetzt nicht auf irgendeiner deiner Karten. Komme ich also von aussen und sage "ich hab hier nen Paket für 1.1.1.1" dann sagt der Router im RZ "jo, kenn ich, der sollte da hängen" und leitet mich auf dein Kabel bzw. auf deinen Switch. Dein Rechner sagt aber "Schön, ich habe aber nicht die 1.1.1.1 sondern nur die .2" und lehnt das Paket dankend ab. Es wird niemals überhaupt deine Routing-Regeln sehen. Wenn du aber die 1.1.1.1 auf ne Karte legst dann nimmt die das zwar an -> aber wie soll die Routing-Regel aussehen die dann sagt die 1.1.1.1 ist irgendwo anders? Dein Rechner WEISS das er jetzt die IP hat, er wird nicht routen. Somit musst du eben forwarden -> d.h. du nimmst das an und sagst dem "leite weiter an die IP xyz".

Du merkst - mit nem bisserl "Route add" ist es da nicht getan...
Mitglied: falscher-sperrstatus
falscher-sperrstatus 17.10.2018 um 17:13:59 Uhr
Goto Top
Zitat von @maretz:

? Mich interessiert ja auch nicht die Routing-Tabelle von meinem Provider.

Doch die 'interessiert' dich, denn ohne die kommt keines deiner Geräte über diesen Hinaus. (Hatte das mal, es gingen keine Mails aus dem deutschen Sprachraum raus - ich wunderte mich ewig, bis ich dem Provider auf die Füße trat - keine Routings über Landesgrenzen bzw nicht auf einen besonderen Kontinent hinaus - super!)
Mitglied: ketanest112
ketanest112 17.10.2018 um 17:18:27 Uhr
Goto Top
Hallo Maretz,


Zitat von @maretz:

Nun - warum SOLLTE meinen Rechner deine Routing-Tabelle interessieren? Mich interessiert ja auch nicht die Routing-Tabelle von meinem Provider. Ich schicke dem ein Paket in dem ne IP steht. DER soll sehen was der damit macht. Also hat der bestimmte Regeln und leitet die weiter.
DU hast aber nur nen Server. Der weiss nichts davon das er ein Paket weiterleiten soll. Also fällt dem das Paket auf die Füsse, der guckt "jap, is eine von meinen IPs" und stellt dann verwirrt fest das er kein Programm hat was damit umgehen will -> also zurück zum Absender mit "no socket".

soweit verstanden
Also musst du jetzt deinem Rechner irgendwie 2 Dinge sagen:
a) Er soll generell erst mal überhaupt die Daten für die IP xyz an den Host ABC weiterleiten
b) Er soll das ganze für den Port X und Protokoll Y machen.
c) (Je nach Struktur) Er soll das ganze auch noch NAT'en

Nehmen wir mal an du hast 2 IPs: 1.1.1.1 und 1.1.1.2. Jetzt willst du irgendwie (tm) deinem Server sagen das er die 1.1.1.1 hinter einem Gateway findet (was ja schon mal ok ist). ABER: Die IP hängt ja jetzt nicht auf irgendeiner deiner Karten. Komme ich also von aussen und sage "ich hab hier nen Paket für 1.1.1.1" dann sagt der Router im RZ "jo, kenn ich, der sollte da hängen" und leitet mich auf dein Kabel bzw. auf deinen Switch. Dein Rechner sagt aber "Schön, ich habe aber nicht die 1.1.1.1 sondern nur die .2" und lehnt das Paket dankend ab. Es wird niemals überhaupt deine Routing-Regeln sehen. Wenn du aber die 1.1.1.1 auf ne Karte legst dann nimmt die das zwar an -> aber wie soll die Routing-Regel aussehen die dann sagt die 1.1.1.1 ist irgendwo anders? Dein Rechner WEISS das er jetzt die IP hat, er wird nicht routen. Somit musst du eben forwarden -> d.h. du nimmst das an und sagst dem "leite weiter an die IP xyz".

Genau da liegt ja meine Absicht, ich möchte meinem Server sozusagen das Routen beibringen. So wie ich meinem Provider ein Paket mit ner IP gebe und mir denke DER soll doch schauen was er damit macht, sagt ja der RZ Router "jo, kenn ich, der sollte da hängen" und der Rest (also was mein Server damit macht) ist dem RZ Router ja auch egal. Und ich möchten meinem Server jetzt beibringen, dass er das Paket für die 2. IP nicht annimmt (daher die IP-Config entfernt), sondern mit Nexthop "Primäre IP neuer Server" weiterleitet. Sprich mein Server soll Router spielen.
Du merkst - mit nem bisserl "Route add" ist es da nicht getan...
das scheint wohl so.

Kann es sein, dass es so nicht funktioniert, weil die Nexthop Adresse (also die primäre IP vom neuen Server) nicht direkt von einem Interface des alten Servers erreichbar ist (sprich in einem der unmittelbar angrenzenden Netze liegt)? Das ist mir grad noch gekommen.

Grüße
Ketanest
Mitglied: ketanest112
ketanest112 17.10.2018 um 18:38:11 Uhr
Goto Top
Ich habs nun doch geschafft.
Zwar quick and dirty aber immerhin mal was.
Lösungsansatz:
Der nexthop muss wohl wirklich direkt in einem "angrenzenden" Netz liegen.
Daher:
ssh Tunnel aufgemacht (vom neuen Server): ssh -f -w 5:5 root@IPAlterServer touch /tmp/a (touch /tmp/a, da -f sonst nicht geht)
dann den beiden Interfaces ne IP Adresse gegeben:
Server neu: ip addr add 10.0.0.1 dev tun5 und hochbringen: ip link set tun5 up
Server alt: ip addr add 10.0.0.2 dev tun5 ; ip link set tun5 up

Dann die Server miteinenader bekannt machen (Routing)
Server Neu: ip route add 10.0.0.2/32 dev tun5
Server alt: ip route add 10.0.0.1/32 dev tun5

damit sehen sich die Server gegenseitig schonmal, kann man mit ping testen
Server alt: ping 10.0.0.1
Server neu: ping 10.0.0.2

Der neue Server hatte ja bereits die zweite IP des alten Servers konfiguriert.
Damit er die Antworten auch über den richtigen Weg zurückschickt, noch auf dem alten Server schnell ein
iptables -t nat -A POSTROUTING -d 1.1.1.1 -j SNAT --to 10.0.0.2 (wobei 1.1.1.1 die 2. IP des alten Servers ist)

und siehe da: es funktioniert.

Ich weiß, ist doppelt erzeugter Traffic und nicht die schöne Art aber es geht. Außerdem ist es nur übergangsweise.

Danke trotzdem für die Hilfe!

Grüße
Ketanest
Mitglied: aqui
aqui 18.10.2018 aktualisiert um 11:04:28 Uhr
Goto Top
Der nexthop muss wohl wirklich direkt in einem "angrenzenden" Netz liegen.
Simple Grundlogik beim Routen !
Wie sollte das System auch sonst den Next Hop erreichen ? Das wäre ja dann technisch unmöglich wenn das next Hop Netz nicht direkt angeschlossen wäre !
Generell sind Secondary IPs NICHT Standard konform weil der TCP/IP Standard sowas nicht vorsieht. Das gesamte ICMP Handlich ist dann funktionslos um nur mal einen Nachteil zu nennen....
Sowas kann man temporär z.B. für Adressmigrationen immer mal machen aber in einem produktiven Netz hat es nichts zu suchen logischerweise.