Re: [PM] Re: Netzwerkfrage: Kanalisation- und Tunnelbau
Hallo Fritz,
natürlich erschlägt Dein Posting !
Argh! Ja, ich hatte es befürchtet :( Kein Problem, war auch nur ironisch gemeint.
Beschreibe mal, was Du von wo kommend wohin umlenken willst, also z.B. http auf port 80 von der Aussenwelt via Server 1 auf Server 2, bzw. was Du sonst noch alles umbiegen willst. -- Viele Grüsse Bernd
Hallo Bernd, hallo Liste, Bernd Glueckert schrieb:
[...] Beschreibe mal, was Du von wo kommend wohin umlenken willst, also z.B. http auf port 80 von der Aussenwelt via Server 1 auf Server 2, bzw. was Du sonst noch alles umbiegen willst. Also, ich muß letztendlich virtuelle VMware-Maschinen temporär von einem Server auf einen anderen ausquartieren. Es ist mit dem Umzug echter Maschinen von einem Netz in ein anderes Netz zu vergleichen. Der Gedanke kam mir gerade, aber ich bleibe jetzt mal bei den virtuellen Systemen.
Das virtuelle System soll auf dem neuen Server weiterhin unter der alten IP erreichbar sein. Damit sollen alle angebotenen Dienste wie www, ftp, ssh und co verfügbar sein. Es wird nicht nur eine virtuelle Maschine sein, sondern mehrere. Die Maschinen werden step by step kopiert. Ich muß also jede IP einzeln umleiten können. Die IPs der Hosts und der virtuellen Maschinen sind keine privaten (192.168er & Co), sondern die Hosts stehen in völlig verschiedenen öffentlichen Netzen. Ich hab mal ein paar Grafiken gebastelt, die die ganze Situation etwas veranschaulichen: Wie es zur Zeit ist: http://www.webof.de/mundtart/aktuell.gif Wie es sein soll: http://www.webof.de/mundtart/ziel.gif Und alles zusammen: http://www.webof.de/mundtart/all.gif Meine große Frage ist, wie Pakete an eine virtuellen Maschine (A1) nach deren Umzug auf den neuen Server (B) ihren Weg zum Ziel finden. Das Internet weiß ja von dem Umzug nichts. Damit landen alle Pakete ersteinmal auf dem alten Server (A). Wie bekommt man es nun am geschicktesten hin, daß der alte Server die Pakete an den neuen Server (B) weiterleitet. So wie es scheint, könnte wohl ein Tunnel funktionieren, aber ein Routingeintrag müsste doch auch helfen, oder? Ich könnte mir so ganz grob folgenden Routingeintrag auf dem alten Server vorstellen: Dest Gateway Mask iface 210.100.222.13 88.100.100.100 FFFF eth0 Funktioniert das überhaupt, wenn der Gateway nicht im selben Subnetz liegt? Wie ist das mit einem Tunnel: geht das über Subnetzgrenze hinaus? Und: wie funktioniert der Rückweg vom umgezogenen Server (A1) zum anfragenden Client? Was geht, was geht nicht? Und welche Lösung wäre zu empfehlen? Vielen Dank und beste Grüße Fritz
Hallo Fritz, so, wie ich es verstehe, willst Du also Deine Services umschalten können und das soll nach draussen hin transparent geschehen. Damit ziehst Du also ganze Server um. Warum änderst Du nicht einfach den DNS-Eintrag? Sind die Sachen zeitkritisch? Wenn das mit dem DNS nicht klappt dann kannst Du eine sehr fein zu steuernde Umleitung via iptables bauen. Ist denn jetzt eine Firewall und ggf. auch iptables schon im Einsatz? Damit kannst Du dann sehr exakt sagen, welcher Port von wo kommend wohin weitergeroutet wird. Da ich vermute, dass Du aussert TCP auch UDP brauchst - z.B. für die Zeitsynchronisation - fallen einige andere Tunnelprodukte weg, z.B. stunnel, der nur auf TCP baut. Mit ein bisschen Überlegung kannst Du die Konfiguration der Firewall via Skript steuern und damit die Umstellung auch fehlerfreier duchführen. -- So long Bernd Fritz Mundtart wrote:
Hallo Bernd, hallo Liste,
Bernd Glueckert schrieb:
[...] Beschreibe mal, was Du von wo kommend wohin umlenken willst, also z.B. http auf port 80 von der Aussenwelt via Server 1 auf Server 2, bzw. was Du sonst noch alles umbiegen willst. Also, ich muß letztendlich virtuelle VMware-Maschinen temporär von einem Server auf einen anderen ausquartieren. Es ist mit dem Umzug echter Maschinen von einem Netz in ein anderes Netz zu vergleichen. Der Gedanke kam mir gerade, aber ich bleibe jetzt mal bei den virtuellen Systemen.
Das virtuelle System soll auf dem neuen Server weiterhin unter der alten IP erreichbar sein. Damit sollen alle angebotenen Dienste wie www, ftp, ssh und co verfügbar sein. Es wird nicht nur eine virtuelle Maschine sein, sondern mehrere. Die Maschinen werden step by step kopiert. Ich muß also jede IP einzeln umleiten können.
Die IPs der Hosts und der virtuellen Maschinen sind keine privaten (192.168er & Co), sondern die Hosts stehen in völlig verschiedenen öffentlichen Netzen.
Ich hab mal ein paar Grafiken gebastelt, die die ganze Situation etwas veranschaulichen:
Wie es zur Zeit ist: http://www.webof.de/mundtart/aktuell.gif Wie es sein soll: http://www.webof.de/mundtart/ziel.gif Und alles zusammen: http://www.webof.de/mundtart/all.gif
Meine große Frage ist, wie Pakete an eine virtuellen Maschine (A1) nach deren Umzug auf den neuen Server (B) ihren Weg zum Ziel finden. Das Internet weiß ja von dem Umzug nichts. Damit landen alle Pakete ersteinmal auf dem alten Server (A). Wie bekommt man es nun am geschicktesten hin, daß der alte Server die Pakete an den neuen Server (B) weiterleitet.
So wie es scheint, könnte wohl ein Tunnel funktionieren, aber ein Routingeintrag müsste doch auch helfen, oder?
Ich könnte mir so ganz grob folgenden Routingeintrag auf dem alten Server vorstellen:
Dest Gateway Mask iface 210.100.222.13 88.100.100.100 FFFF eth0
Funktioniert das überhaupt, wenn der Gateway nicht im selben Subnetz liegt? Wie ist das mit einem Tunnel: geht das über Subnetzgrenze hinaus? Und: wie funktioniert der Rückweg vom umgezogenen Server (A1) zum anfragenden Client?
Was geht, was geht nicht? Und welche Lösung wäre zu empfehlen?
Vielen Dank und beste Grüße Fritz
Hallo Bernd, Bernd Glueckert schrieb:
[...] Damit ziehst Du also ganze Server um. Stimmt genau! Es ist fast wirklich so, wie wenn man sich die 19" Pizza-Server-Schachtel unter den Arm klemmt, von Hamburg nach Frankfurt fährt und dort das gute Stück wieder anschließt. Eine Woche später geht es dann wieder zurück ....
Warum änderst Du nicht einfach den DNS-Eintrag? Sind die Sachen zeitkritisch?
Das Problem ist, dass ich mir sparen möchte, in allen Konfigdatein rumzueditieren. Das ist fehlerträchtig und vorallem geht es halt nach ein paar Tagen wieder zurück. Das potenziert die Fehlerwahrscheinlichkeit. Hinzukommt, daß manche Dienste nur an die IPs gebunden sind. Zum Beispiel der MySQL-Cluster-Manager.
Wenn das mit dem DNS nicht klappt dann kannst Du eine sehr fein zu steuernde Umleitung via iptables bauen. Ist denn jetzt eine Firewall und ggf. auch iptables schon im Einsatz?
Ich hab die hauseigene SuSEFirewall im Einsatz. Hab dazu das Config-Script angepasst. Soviel ich weiß ist das ja wohl nur ein Frontend zu IPTables, oder? Aber letztendlich hab ich leider von dem IpTable Thema (noch) keinen Plan ... :( Wie lege ich wo Regeln an, wie greife ich darauf zu, etc? Ich hab mir vor einiger Zeit verschiedene man's angesehen, aber das hat mich auf den ersten Blick erschlagen :/
Damit kannst Du dann sehr exakt sagen, welcher Port von wo kommend wohin weitergeroutet wird.
Das klingt gut! Wäre das die FW_FORWARD Option im SuSEFirewall Script? Da hab ich nämlich schon definiert, daß man von 0.0.0.0 (überall) in das "interne" Netz kommen kann.
Da ich vermute, dass Du aussert TCP auch UDP brauchst Ja, ich denke schon - wäre besser, auch wenn es nur ein paar wenige sind.
- z.B. für die Zeitsynchronisation - fallen einige andere Tunnelprodukte weg, z.B. stunnel, der nur auf TCP baut.
Wie sähe es mit openvpn aus? Basiert der auch nur auf TCP? Vielen Dank und viele Grüße Fritz
Hallo Fritz, morgen setze ich mich mal an ein paar Zeilen IPTABLES - quasi zur Selbstkasteiung. Heute ist Kindergeburtstag und da ist gleich das Haus voll. Cu - Bernd Fritz Mundtart wrote:
Hallo Bernd,
Bernd Glueckert schrieb:
[...] Damit ziehst Du also ganze Server um. Stimmt genau! Es ist fast wirklich so, wie wenn man sich die 19" Pizza-Server-Schachtel unter den Arm klemmt, von Hamburg nach Frankfurt fährt und dort das gute Stück wieder anschließt. Eine Woche später geht es dann wieder zurück ....
Warum änderst Du nicht einfach den DNS-Eintrag? Sind die Sachen zeitkritisch?
Das Problem ist, dass ich mir sparen möchte, in allen Konfigdatein rumzueditieren. Das ist fehlerträchtig und vorallem geht es halt nach ein paar Tagen wieder zurück. Das potenziert die Fehlerwahrscheinlichkeit. Hinzukommt, daß manche Dienste nur an die IPs gebunden sind. Zum Beispiel der MySQL-Cluster-Manager.
Wenn das mit dem DNS nicht klappt dann kannst Du eine sehr fein zu steuernde Umleitung via iptables bauen. Ist denn jetzt eine Firewall und ggf. auch iptables schon im Einsatz?
Ich hab die hauseigene SuSEFirewall im Einsatz. Hab dazu das Config-Script angepasst. Soviel ich weiß ist das ja wohl nur ein Frontend zu IPTables, oder? Aber letztendlich hab ich leider von dem IpTable Thema (noch) keinen Plan ... :( Wie lege ich wo Regeln an, wie greife ich darauf zu, etc? Ich hab mir vor einiger Zeit verschiedene man's angesehen, aber das hat mich auf den ersten Blick erschlagen :/
Damit kannst Du dann sehr exakt sagen, welcher Port von wo kommend wohin weitergeroutet wird.
Das klingt gut! Wäre das die FW_FORWARD Option im SuSEFirewall Script? Da hab ich nämlich schon definiert, daß man von 0.0.0.0 (überall) in das "interne" Netz kommen kann.
Da ich vermute, dass Du aussert TCP auch UDP brauchst Ja, ich denke schon - wäre besser, auch wenn es nur ein paar wenige sind.
- z.B. für die Zeitsynchronisation - fallen einige andere Tunnelprodukte weg, z.B. stunnel, der nur auf TCP baut.
Wie sähe es mit openvpn aus? Basiert der auch nur auf TCP?
Vielen Dank und viele Grüße Fritz
participants (2)
-
Bernd Glueckert -
Fritz Mundtart