Server migrieren aber über alte Adresse erreichbar machen
Hallo,
wir migrieren unsere Server in ein zentrales Datacenter.
Dabei erhalten alle unsere Server auch neue IP-Adressen.
Dies ist insofern problematisch, da es sicherlich Anwendungen gibt, die nicht den Hostnamen sondern die IP verwenden.
Ich weiß, sollte nicht so sein, aber gibt es leider.
Beide Netze sind im Range 10.x.y.z ( nicht überlappend ) und die Verbindung ist eine eigene Glasfaser.
Da zwischen unserem Netz und dem Datacenter eine Fortigate Firewall aktiv ist frage ich mich, ob es möglich wäre die Adresse der migrierten Server auf unserer Seite als virtuelle IP der Firewall zu vergeben und ein NAT zu aktivieren.
Lässt sich so etwas machen bzw welche Schwierigkeiten würden wir uns ins Haus holen?
Danke
Andreas
wir migrieren unsere Server in ein zentrales Datacenter.
Dabei erhalten alle unsere Server auch neue IP-Adressen.
Dies ist insofern problematisch, da es sicherlich Anwendungen gibt, die nicht den Hostnamen sondern die IP verwenden.
Ich weiß, sollte nicht so sein, aber gibt es leider.
Beide Netze sind im Range 10.x.y.z ( nicht überlappend ) und die Verbindung ist eine eigene Glasfaser.
Da zwischen unserem Netz und dem Datacenter eine Fortigate Firewall aktiv ist frage ich mich, ob es möglich wäre die Adresse der migrierten Server auf unserer Seite als virtuelle IP der Firewall zu vergeben und ein NAT zu aktivieren.
Lässt sich so etwas machen bzw welche Schwierigkeiten würden wir uns ins Haus holen?
Danke
Andreas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7193275563
Url: https://administrator.de/contentid/7193275563
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
8 Kommentare
Neuester Kommentar
Huhu,
habt ihr da auchn DC und ähnliches laufen die dorthin migriert werden? Das wäre schon problematisch
wenn die plötzlich in nem anderen Netz sind. Da musst du Guides für lesen und einige Dinge für ne saubere mig durchführen (DC wäre sauberer neu aufzusetzen im neuen Netz und dann erstmal als secondary und richtig die Rollen migrieren). Für alles andere kannst du - aus meiner Erfahrung - mit einem einfachen NAT arbeiten und ggf. je nach Dienst die Konfig leicht anpassen (z.B. Webserver - htaccess und co).
Grüße
bloody
habt ihr da auchn DC und ähnliches laufen die dorthin migriert werden? Das wäre schon problematisch
wenn die plötzlich in nem anderen Netz sind. Da musst du Guides für lesen und einige Dinge für ne saubere mig durchführen (DC wäre sauberer neu aufzusetzen im neuen Netz und dann erstmal als secondary und richtig die Rollen migrieren). Für alles andere kannst du - aus meiner Erfahrung - mit einem einfachen NAT arbeiten und ggf. je nach Dienst die Konfig leicht anpassen (z.B. Webserver - htaccess und co).
Grüße
bloody
Hi,
es kommt darauf an, ob auf die Server aus dem gleichen Subnetz heraus zugegriffen werden soll. Wenn ja, dann muss die Firewall auf die IP-Adressen reagieren. Zum Beispiel, indem man ihr die IP-Adressen vergibt.
Wenn nicht, reicht ein einfacher NAT-Eintrag an der Firewall.
Ich würde es aber vermeiden. Es macht das Setup komplexer und viel schwerer wartbar.
Ich würde den schmerzhafteren Weg gehen und die Migration in das Rechenzentrum ordentlich machen, oder das NAT-Setup nachher wieder zurückbauen.
Meine Meinung.
Grüße
es kommt darauf an, ob auf die Server aus dem gleichen Subnetz heraus zugegriffen werden soll. Wenn ja, dann muss die Firewall auf die IP-Adressen reagieren. Zum Beispiel, indem man ihr die IP-Adressen vergibt.
Wenn nicht, reicht ein einfacher NAT-Eintrag an der Firewall.
Ich würde es aber vermeiden. Es macht das Setup komplexer und viel schwerer wartbar.
Ich würde den schmerzhafteren Weg gehen und die Migration in das Rechenzentrum ordentlich machen, oder das NAT-Setup nachher wieder zurückbauen.
Meine Meinung.
Grüße
Dann hast du ja praktisch bisher soweit alles richtig gemacht. Musst halt ggf. mal Logs beobachten
ob da irgendwelche auffälligen Fehler oder Warnungen auftauchen. Oder wenn mal irgend ein Client welcher auf einen dieser Server zugreift irgendwas ungewöhnlich langsam macht. Projekte öffnen oder speichern oder so. Manche Fachsoftware mag solche NAT-Setups aus welchen Gründen auch immer nicht und dann gibts "Geschwindigkeitsprobleme" schon öfter beobachtet.
ob da irgendwelche auffälligen Fehler oder Warnungen auftauchen. Oder wenn mal irgend ein Client welcher auf einen dieser Server zugreift irgendwas ungewöhnlich langsam macht. Projekte öffnen oder speichern oder so. Manche Fachsoftware mag solche NAT-Setups aus welchen Gründen auch immer nicht und dann gibts "Geschwindigkeitsprobleme" schon öfter beobachtet.
Man müsste heutzutage auch gar keine IP Adress Änderung mehr vornehmen. Mit modernen Switches realisiert man einem Layer 2 Tunnel mit z.B. VxLAN oder anderen Tunneltechnologien in das Rechenzentrum. Das bedeutet dann keinerlei Stress mit irgendwelchen IPs weil man seine bestehende Adressierung einfach "mitnimmt". Vereinfacht auch deutlich ein redundantes Ausfall Szenario beim Betrieb von Server Clustern.
Mit VmWare bräuchte man nicht einmal entsprechende Infrastruktur weil diese VxLAN out of the Box supporten. Heutzutage supporten auch ein Großteil sogar der einfachen Access Switches VxLAN.
Hört sich ein bisschen danach an als ob bei der Netzwerkplanung dieser Migration ggf. aus Unwissenheit etwas schnarchnasig und mit antiken Methoden vorgegangen wurde.
Mit heutzutage üblicher Layer 2 Tunneltechnik wäre es dann völlig egal in welches RZ ihr demnächst umzieht wenn es irgendwo bessere Vertragskonditionen gibt und die (nicht IT affine) Führung entscheidet zu wechseln. Der tiefere Sinn eines solchen L2 Designs.
Aber warum einfach und flexibel machen wenn es umständlich und kompliziert auch geht...?!
Mit VmWare bräuchte man nicht einmal entsprechende Infrastruktur weil diese VxLAN out of the Box supporten. Heutzutage supporten auch ein Großteil sogar der einfachen Access Switches VxLAN.
Hört sich ein bisschen danach an als ob bei der Netzwerkplanung dieser Migration ggf. aus Unwissenheit etwas schnarchnasig und mit antiken Methoden vorgegangen wurde.
Mit heutzutage üblicher Layer 2 Tunneltechnik wäre es dann völlig egal in welches RZ ihr demnächst umzieht wenn es irgendwo bessere Vertragskonditionen gibt und die (nicht IT affine) Führung entscheidet zu wechseln. Der tiefere Sinn eines solchen L2 Designs.
Aber warum einfach und flexibel machen wenn es umständlich und kompliziert auch geht...?!
Moin,
Gruß,
Dani
Dies ist insofern problematisch, da es sicherlich Anwendungen gibt, die nicht den Hostnamen sondern die IP verwenden.
an deiner Stelle würde ich das klären bzw. nachschauen und entsprechend einen Action Plan überlegen.Die NAT-Lösung würde ich gerne für smtp verwenden, aber auch für andere Dienste aber nur gezielt für einige.
Für SMTP? Da ist es doch eigentlich noch am Einfachen einen DNS anzulegen und damit zu referenzieren.Gruß,
Dani
Wenn's das denn war bitte nicht vergessen deinen Thread als erledigt zu schliessen!