Nachdem ich im ersten Teil auf die Theorie eingegangen bin, kommen wir jetzt auf die Konzeption und Planung zu sprechen: Der erste Schritt vor der Planung ist zunächst einmal ein Proof of Concept, um die Idee des CIDR zu validieren.
Deshalb setzten wir zunächst einmal eine kleine Testumgebung samt einem Domain Controller auf. Bei uns waren es zwei Server, wobei einer die Rolle des DC innehatte, sowie 3 Clients, davon 2 virtuell. Die Clients erhielten per DHCP ihre IP vom DC, der zweite Server hatte eine feste Adresse. Außerdem lief auf dem zweiten Server eine kleine Serversoftware, auf welche von den Clients zugriffen wurde (beispielsweise könnte man hier einen FTP Server aufsetzen). Das Einrichten der Testumgebung ist der anspruchsvollste Teil. Danach ändert man lediglich an den zwei Servern manuell die Subnetzmaske. Darüber hinaus muss man auf dem DC noch prüfen, ob dieser per DHCP auch die richtige Subnetzmaske verteilt. Im Anschluss funktionierte alles weiterhin wie gewohnt. Demzufolge hatten wir im kleinen Rahmen sichergestellt, dass der Gedanke zur Vergrößerung unseres Netzes durchaus funktionieren kann.
Um zumindest ein gewisses Maß an Sicherheit über das geplante Vorhaben zu bekommen, recherchierten wir im Internet noch über etwaige bekannte Probleme. Da es hier stark davon abhängt, wie die eigene Infrastruktur aussieht, will ich nicht näher auf die Funde eingehen. Lediglich folgendes sei angemerkt: Einige alte Protokolle können hier durchaus Probleme haben. Außerdem stießen wir auf Einzelfälle, die über Schwierigkeiten beim VPN Zugriff berichteten. Diesen Punkt schrieben wir auf unsere Liste.
Abgesichert durch unseren Test und die Recherche, gingen wir zur detaillierten Planung über. Wir begannen mit einer Bestandsaufnahme, d.h. welche Geräte hängen alle am Netzwerk, wie sind sie angeschlossen und – was oft vergessen wird – funktionieren diese überhaupt. In der Regel ist es so, dass der verfügbare Adressbereich des eigenen Netzes (bei uns 192.168.115.0 bis 192.168.115.256) in zwei Segmente aufgeteilt wird: Den DHCP Bereich, aus dem der Domain Controller IPs an die Clients verteilt, und den festen Adressbereich, der vorwiegend für Server, aber auch diverse Peripherie verwendet wird. Während das DHCP Segment keinerlei Vorüberprüfung bedarf, sieht die Sache bei den festen IPs anders aus. Wir nahmen unseren bereits existierenden Netzwerkplan (den es hoffentlich in jeder Firma gibt), auf dem neben den Servern auch alle sonstigen, ans Netzwerk angeschlossenen Geräte vermerkt sind, darunter Drucker, Faxe, Scanner, Multifunktionsgeräte, Audio Codes, Webcams, Printserver und viele mehr (z.B. die Alarmanlage!). Bei der Überprüfung kam heraus, dass der Plan lediglich zwei falsche Geräte auswies, die drei Tage vorher gegen neuere getauscht wurden. Ich selbst würde dies als durchaus guten Wert bezeichnen, wenn man bedenkt wie viele Geräte wir haben und wie oft welche getauscht werden. Danach nutzten wir einen klassischen Netzwerkscanner, um erstens zu prüfen, ob wir irgendwelche Peripherie aus dunklen Kämmerchen vergessen hatten, und zweitens, um auch sicherzustellen, dass die Hardware überhaupt funktionierte. Das Ergebnis des Ping-Tests haben wir uns für einen späteren Vergleich abgespeichert. Zu guter Letzt prüften wir noch, ob wir auf alle gefundenen Geräte Zugriff hatten (z.B. über das Webinterface eines Audio Codes) und ob es dort auch möglich war die Netzwerkeinstellung zu ändern. Dabei stellten wir fest, dass wir von zwei Druckern keine Zugangsdaten hatten. Diese waren durch das Handbuch schnell gefunden.
Hier nochmal zusammengefasst, welche Punkte wir bereits abgehandelt haben:
1. Proof of Concept
2. Recherche bzgl. bekannter Probleme
3. Bestandsaufnahme / Analyse der Ausgangssituation
In Teil 3 gehen wir dann auf die konkrete Umstellung ein.
Uli Armbruster 