Ulf Volmer schrieb:
On 11.01.24 08:37, Manfred Haertel, DB3HM wrote:
Das geht ja schon mit den ausgehenden Paketen los: Welche Source-IP-Adresse haben die denn, wenn sie einen Knoten im selben Subnetz adressieren? Denn "passen" würden ja alle vier. Es ist nicht immer sicher (zumindest nicht ohne weitere Maßnahmen), dass die genommen wird, die man gerne hätte. Das ist wirklich eine Einladung für unerwartete "Phänomene" im Netzwerk.
Ausgehende, **neue** Verbindungen verwenden die /primäre/ IP, das ist üblicherweise die erste konfigurierete. Anworten auf Anfragen verwenden die Adresse, an die die Anfrage geschickt wird. Also alles gut.
Das mag so sein, wenn das im Kernel so implementiert ist. Nach meiner Kenntnis ist das aber Implementations-abhängig. Und ob es das ist, was man bei einer Server-Konsolidierung ERWARTET, ist noch mal eine andere Frage. Da kann es ja sein, dass ein Client eben die ANDERE IP erwartet, unter der er auch den Server kontaktiert, weil es eben die IP des alten Servers ist. Kann, nicht muss - aber das sind Fallen, die tief irgendwo in Applikationen versteckt sind und die man nur schwer findet. Ich bleibe dabei, ich würde es nicht (mehr) machen und habe auch früher schon schlechte Erfahrungen damit gemacht. Das ist mein Rat, andere mögen das anders sehen.
Ich würde immer zuerst versuchen, die IP auf den Clients, die sie benutzt haben, zu ändern. Man wird das eh irgendwann mal tun müssen und mit einem Workaround schiebt man den Zeitpunkt, wo man in diesem sauren Apfel beißen muss, nur hinaus und sorgt dafür, dass die IPs nie geändert werden - schon gar nicht, wenn z.B. im beruflichen Umfeld andere Leute für die Clients verantwortlich sind und man die überzeugen muss, die IP zu ändern. Da ist eine Server-Konsolidierung ein gutes Argument, ein halbes Jahr später ist "ich will das jetzt aber so" ein schlechtes Argument (weil es ging ja die ganze Zeit)...
Es ist halt häufig so, gerade im beruflichen Umfeld, dass man nicht alles beteiligten Geräte (Clients, Firewalls und Co.) im Zugriff hat.
Da macht man sich das Leben einfacher, wenn man, wie bnacht, dem Dienst eine dedizierte IP gibt, die man später mit migrieren kann.
Wenn ich "bnacht" richtig verstanden habe, ging es ihm um den konkreten Fall der Migration unter Beibehaltung der IP und eben nicht um eine strukturelle Maßnahme, um eine spätere Migration zu vereinfachen. Und das würde ich mit derselben Argumentation eben nicht machen, denn in DEM Moment ist ja auch bei den anderen Leuten die Einsicht, eine Änderung machen zu müssen, am größten. Bei mir auf der Arbeit war es in den letzten Jahren vor meiner Rente so, dass eh (fast) alle Server virtualisiert waren und es ohnehin keinen Sinn gemacht hätte, zwei Server-Funktionen auf derselben VM zu betreiben. Dann lieber für einen neuen Server-Dienst eine neue VM einrichten, die ist in wenigen Minuten betriebssystemmäßig aufgesetzt und hat sowieso eine eigene IP - und da dann den neuen Server-Dienst drauf. Da die Anzahl der Server-Dienste langsamer wuchs als Hauptspeicher und Massenspeicher immer größer und gleichzeitig billiger pro Datenmenge wurden, funktionierte das gut. Und dann stellten sich Fragen wie mehrere IPs im selben Subnetz auf derselben Maschine nicht wirklich. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel