bnacht schrieb:
Am 11.01.24 um 06:41 schrieb Manfred Haertel, DB3HM:
bnacht schrieb:
Hi,
ich habe drei secondary IP-Adressen via YaSt eingetragen.
================================================================ host1:~ # cat /etc/sysconfig/network/ifcfg-eth1 IPADDR='10.10.10.41/24' IPADDR_1='10.10.10.42/24' IPADDR_2='10.10.10.43/24' IPADDR_3='10.10.10.45/24' BOOTPROTO='static' STARTMODE='auto' ZONE='public' Es hat zwar wahrscheinlich erst mal nichts mit dem geschilderten Problem zu tun, aber mir stellt sich schon die Frage: Was ist das Ziel des ganzen? Denn alle vier Adressen sind im selben Subnetz.
Sicher, man könnte unterschiedliche Dienste an unterschiedliche IPs "binden". Aber wozu sollte man das tun? Um bei einer Migration mit Konsolidierung externen Geräten die bekannten IP präsentieren zu können.
OK, das ist ein Grund - aber aus der alten Erfahrung heraus würde ich das IMMER anders lösen als mit mehreren Adressen im selben Subnetz auf dem selben Interface. 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. 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)... Und wenn es gar nicht anders geht würde ich an geeigneter Stelle zu einem NATing greifen (wenn das geht, weil das Netzwerk eine geeignete Routing-Struktur ist - oder man NATet direkt auf dem Betriebssystem des Clients, wenn keiner sich traut, die Anwendung anzupassen, weil die IP drin hard codiert ist und der Source-Code nicht mehr da ist - soll es alles geben...). Das ist zwar auch intransparent, aber keine Einladung für Phänomene. Ich weiß ja nicht, ob das betroffene Netz bei Dir im Wohnzimmer oder auf der Arbeit steht. Zuhause wäre es wohl egal. Aber auf der Arbeit würde ich so ein Übergangs-Konstrukt eher nicht machen - ist halt traurige Erfahrung... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel