Zugschlusbeobachtungen

Das schließt insbesondere ein, dass ich in dem Lab dieselben IP-Adressen verwende, wie sie auch beim Kunden in Benutzung sind, inklusive dessen öffentlicher Adressen. Das bedeutet natürlich, dass man höllisch aufpassen muss, dass die im Lab "widerrechtlich" verwendeten Adressen irgendwie nach draußen leaken, weil Wechselwirkungen mit den produktiven Systemen des Kunden nicht ausgeschlossen sind. Meist wird man das Lab also von "richtiger" Infrastruktur getrennt aufbauen und den mit hoher Wahrscheinlichkeit trotzdem benötigten Internetzugang über NAT realisieren, wie man es auch machen würde, wenn das Lab im Internet nicht geroutete site-local-Adressen verwenden würde. Und wenn man schonmal dabei ist, kann man auch gleich die Zugriffe aus dem eigenen Office so natten, dass sie beim Zielsystem so ankommen, als stünde dies schon an seinem endgültigen Einsatzort.

So ein Setup ist zwar eine ausgesuchte Sammlung aus verschiedenen Netzschweinereien, hat aber den Vorteil, dass man das System zur Migration 1:1 aus dem Lab in die Produktivumgebung versetzen kann, ohne sich Gedanken darüber machen zu müssen, ob IP-Adressen, Routen, Gateways und Accesslisten auch an der produktiven Position so stimmen, dass das System direkt funktioniert. Das hilft, die Downtime bei der Umstellung zu verkürzen und nimmt deutlich Stress aus der eigentlichen Migration.

Der Aufbau eines solchen Setups benötigt allerdings erheblich mehr Kenntnisse über IP und NAT, als beim durchschnittlichen Administrator eines Endkunden oder Techniker des Mitbewerbs zu finden ist. Ich empfehle diese Vorgehensweise trotzdem dringend, da sie erhebliche Vorteile mit sich bringt. Außerdem ist das ein Alleinstellungsmerkmal gegenüber dem allergrößten Teil der Marktbegleiter, die mangels Kenntnissen auf solche Ideen gar nicht erst kommen. Ich wäre ja schön blöd, wenn ich diesen Vorteil nicht nutzen würde.