IP > IP weiterleiten

B

bibabu

Registered User
Hallo Foren Gemeinde :-)

Ich plane demnächst mir einen neuen Server zu kaufen und würde gerne alle Anfragen von IP1 (IP des alten Servers) auf IP2 (IP des neuen Server) weiterleiten.

Über Google konnte ich bis jetzt in Erfahrung bringen das dafür Iptables verwendet werden kann. Wäre super nett wenn mir jemand mal nen stichwort für Google oder sogar nen Lösungsvorschalg posten könnte.
 
Für TCP-Verbindungen würde ich rinted benutzen. Das ist IMHO stressfreier eingerichtet, als ein entsprechender Netfilter-Regelsatz.
 
Unter iptaples wäre(!) das nur ein Befehl für so eine pauschale Weiterleitung. Allerdings gibt es da ein paar Probleme:, die dafür sorgen, dass so eine Weiteleitung nix bringt:

- Du kannst auf den alten Server nicht mehr zugreifen kannst (z.b. auch nicht mit ssh), weil ja schließlich alles weitergeleitet wird. (kleineres Problem)

- Du musst genauso alle Pakete rückwärts über deine IP1 routen bzw. die Absenderadresse von Pakten IP2->Client auf IP1 setzen, weil sonst Server und Client von unterschiednlichen Verbindungen reden.
Hintergrund ist folgender: Jede Verbindung wird als 5 Tupel identifiziert: (Client-IP, Client-Port, Server-IP, Server-Port, verwendetes Transportprotokol).

Wenn du nur Pakete von Server-IP1 zu Server-IP2 weiterleitest, hast du aus Sicht deines Clients eine Verbindung (Client-IP, Client-port, Server-IP1, Server-Port, verwendetes Transportprotokol), weil der Client ja denkt, dass er mit der IP1 kommuniziert.
Der neue Server hat aber eine Verbindung (Client-IP, Client-port, Server-IP2, Server-Port, verwendetes Transportprotokol), weil dieser ja nicht mitkriegt, dass das Paket weitergeleitet wurde.

TCP-Verbindungen (verbindungsorientiert) könnten so schonmal gar nicht zustande kommen. Allein der Aufbau schlägt schonmal fehl.

Bei UDP-Verbindungen bin ich mir grad etwas unsicher. Der Client Socket würde die Pakete zwar annehmen, aber ich kann mir nicht vorstellen, dass irgendeine Application akzeptiert, dass die UDP-Datagrams zu einer Adresse x rausgehen und von einer Adresse y zurückkommen.


- Du kriegst sowieso durch die Weiterleitung ein höheres Delay, was auch nicht so toll ist, da du vermutlich viele Streams hast (wegen UDP)?



Die Sache ist also etwas komplizierter, weshalb es z.B. auch rinetd gibt.

Dennis
 
Hallo,

ich habe bereits ein wenig im Iptables gearbeitet.

Code: 
iptables -t nat -A PREROUTING -d 85.131.xxx.xxx -j DNAT --to-destination 85.131.xxx.xxx
iptables -t nat -A POSTROUTING -s 85.131.xxx.xxx -j SNAT --to-source 85.131.xxx.xxx

Das Problem mit dem SSH kann ich leicht umgehen da ich mehrere IPs habe.
Die anderen Punkte muss ich mal genauer analysieren.
 
naja, wenn du NAT machst, umgehst du das Problem der Verbindungen, weil maskiert wird. Aus Sicht des Clients wird nur mit dem alten Server geredet.

NAT hat aber ein paar Nachteile, die einem evtl einen Strich durch die Rechnung machen könne, z.B. falls dein neuer Server einen Rückkanal aufbauen will. Du müsstest also deinem neuen Server sagen, dass er den alten als Gateway nutzen muss. Das muss er sowieso, weil er ansonsten Antworten an den Client direkt schicken würde.

Meiner Meinung nach, macht NAT hier keinen Sinn, weil du den neuen Server komplett versteckst!
Ich hab auch keine Ahnung was passiert, wenn ein Client direkt mit dem neuen Server kommunizieren will, weil die Antwort dann ja über den alten Server geNATed wird...

was für Dienste bietet der Server denn eigentlich an?

Dennis
 
Warum so kompliziert? Die kanonische Vorgehensweise wäre, vor dem Umzug die TTL der gewünschten Einträge im DNS schrittweise zu reduzieren: D.h. die Gültigkeit eine Woche vorher auf einen halben Tag zu stellen und dann einen halben Tag vorher auf 5 Minuten. Wenn der neue Server läuft, stellst Du die DNS-Einträge auf den neuen Server um und setzt die TTL wieder auf den ursprünglichen Wert zurück.
Auf diese Weise hast Du nur während 5 Minuten nicht-eindeutige Zugriffe (und die höhere Last auf die Nameserver ist auch auf kurze Zeit begrenzt) und kannst Dir die ganze Mühe mit iptables sparen.

Viele Grüße,
LinuxAdmin
 
You must log in or register to reply here.
Back
Top