metamorworks - stock.adobe.com
Operativ arbeiten im Netzwerk: Grundlagen
Planung, Betreuung und Einsatz moderner Netzwerktechnik im operativen Tagesgeschäft sind eine große Herausforderung. Wir befassen uns zunächst mit den Grundlagen dieser Tätigkeiten.
Für die Nutzer ist es eigentlich ganz einfach: Das Netzwerk ist für ihre Arbeit so omnipräsent, dass sie in der Regel keinen Gedanken daran verschwenden (müssen), ob und wie es funktioniert – geschweige denn, wie es organisiert ist. Für die Mitarbeiter der IT-Abteilung und dort besonders für die Netzwerk-Administratoren sieht das aber ganz anders aus: Sie müssen sich nicht nur Gedanken darüber machen, wie sie das Netzwerk grundsätzlich planen, aufbauen und gegebenenfalls erweitern können – sie müssen auch dafür sorgen, dass der tägliche Betrieb reibungslos verläuft.
Firmen, die beispielsweise Web-Hosting und/oder Cloud-Dienste anbieten sowie Internet Service Provider regeln diese Dinge meistens mit einem sogenannten Network Operations Center (NOC). In einer solchen Zentrale wird der Betrieb eines Rechner- oder eines Telekommunikations-Netzwerks (oder auch nur eines bestimmten Teils des jeweiligen Netzwerks) zentral überwacht und geregelt. Diese Zentralen, die mit ihren Video-Walls und vielen Arbeitsplätzen mit Workstations oft aussehen wie die Kommandobrücke eines Raumschiffes in einem Science-Fiction-Film, überwachen möglichst viele Aspekte des Netzwerkbetriebs. Das reicht dabei unter anderem von Stromausfällen über Sicherheitseinrichtungen wie beispielsweise Firewalls, Intrusion Detection Systeme (IDS) und AV-Software bis hin zu Problemen mit der Geschwindigkeit und dem Durchsatz im Netz.
In kleineren Unternehmen, so sie sich nicht ein solches NOC weder vor Ort noch als Managed Service leisten können oder wollen, werden die Administratoren wohl eher mit konventionellen Mitteln an die operativen Tätigkeiten zur Verwaltung/Betreuung ihres Netzwerks herangehen. Wir wollen deshalb in dieser kleinen Serie einige grundsätzliche Techniken und Probleme vorstellen, auf die ein Netzwerk-Administrator in der täglichen Arbeit immer wieder stoßen kann.
In diesem ersten Teil haben wir uns einiger grundlegender Themen angenommen, die vielleicht wie ein alter Hut wirken – aber in der täglichen Praxis leider immer (mal wieder) auftauchen können. Dabei geht es uns in diesem Beitrag vor allen Dingen um interne Probleme, die also das eigentliche Firmennetzwerk belasten können und deren Auswirkungen die Administratoren bei ihren operativen Aufgaben in Betracht ziehen sollten.
Standard, aber nicht ohne Probleme: Private IPv4-Adressräume und NAT
Zu den ersten Dingen, die wohl jeder IT-Einsteiger lernt, gehört die Tatsache, dass es sogenannte private IPv4-Adressen gibt, deren Bereich im RC 1918 einheitlich geregelt ist. Die Vorteile dieser IP-Adressen, deren Datenpakete grundsätzlich nicht in das Internet geroutet werden, sind vielfach.
So bieten sie im Hinblick auf die weltweit fast nicht mehr vorhandenen freien IPv4-Adressen nach wie vor eine gute Möglichkeit, weiterhin eine ganze Reihe von Systemen und Subnetzen unabhängig zu betreiben. Was aber aus der Sicht der meisten Administratoren wichtiger ist: Die Rechner mit der privaten IP-Adresse können nicht direkt von einem Paket aus dem Internet erreicht werden. Genauso wenig kann ein Datenpaket von einer solchen privaten Adresse das Netz verlassen und werden diese Adressen in der Regel an einem NAT-Gateway (Network Address Translation) umgesetzt. Dabei kommt das sogenannte 1:N-NAT zum Einsatz, das auch als IP-Masquerading bezeichnet wird. Dabei werden alle Adressen (N) des internen Netzes auf eine einzige öffentlich IP-Adresse umgesetzt.
Das Problem mit zwei (oder mehr) privaten Adressräumen: Dieses Vorgehen funktioniert aber in einigen Konfigurationen nicht mehr. So beispielsweise dann nicht, wenn zwei (oder auch mehr) interne Netze via einer VPN-Strecke miteinander verbunden werden und die Nutzer in der Lage sein sollen, in beiden Netzen zu arbeiten. Setzen nun – was sicher nicht selten ist – beispielsweise beide Netze auf den privaten Adressbereich 192.168.1.0/24, so werden Pakete aus Netz A, die einen Rechner im Netz B erreichen sollen, dort nicht ankommen, weil sie im eigenen Netz geroutet werden und das Gateway erst gar nicht erreichen. Hier muss dann ein N:N-Mapping zum Einsatz kommen. Dabei werden alle Adressen des eigenen LANs für die Kopplung mit dem anderen Netzwerk in einen neuen Kreis von Adressen übersetzt. Die Bezeichnung N:N-Mapping wird dabei unter anderem von den Lancom-Routern verwendet, während andere Hersteller die dafür notwendigen Einstellungen auch als 1:1-NAT bezeichnen.
IPv6 – lieber einfach abschalten?
Es kann kaum Zweifel daran geben, dass es sich bei IPv6 nicht nur um ein Hype-Thema handelt. Ebenso dürfte es jedem IT-Profi klar sein, dass die Anzahl der freien IPv4-Adressen langsam aber sicher gegen Null geht. Aber ebenso sicher werden wohl die großen Anteile an der Netzwerkinfrastruktur auch in den Unternehmen, die immer noch problemlos mit IPv4 arbeiten, nicht binnen weniger Wochen oder auch Monate zusammenbrechen. Zahlen und Statistiken, die von Firmen wie Akamai, Cisco und Google veröffentlicht werden, zeigen zudem, dass Deutschland insgesamt sicher nicht so schlecht dasteht, was den Umstieg auf diese Technik angeht. IPv6 ist also definitiv schon da – es ist nur in deutschen Unternehmen noch nicht so verbreitet.
IPv4 ist nach wie vor der Standard, wenn es um die Anbindung an Provider/Internet geht: Viele Firmen sind noch via IPv4 mit ihrem Provider und damit mit dem Internet verbunden. Vielfach wird sowohl von Provider-Seite als auch von Seite der Geschäftskunden als Begründung dafür aufgeführt, dass die IPv6-Techniken „noch nicht mit der entsprechenden Zuverlässigkeit eingesetzt und betrieben werden können, die im geschäftlichen Bereich erwartet wird“. Nichtsdestotrotz zeigen aktuelle Recherchen, dass die meisten renommierten Provider dazu in Lage sind, die Anbindung via IPv6 auch ohne Dual-Stack-Brücken und DSL-Lite-Krücken anzubieten. Doch wie sieht es im internen Netzwerk aus?
„Ich brauche IPv6 (noch) nicht – also schalte ich es einfach ab“, – wer sich ein wenig umhört, wird schnell feststellen, dass viele Administratoren nach wie vor nach dieser Maxime vorgehen: Das gilt vor allen Dingen beim Einsatz von Windows, obwohl Microsoft ja bereits seit Windows Vista IPv6 unterstützt und alle aktuellen Windows-Versionen sowohl auf der Client- als auch auf der Server-Seite mit einem Dual-Stack ausgestattet sind, der IPv4 und IPv6 unterstützt.
So sieht Microsoft das Bestreben der Administratoren, ihre Windows-Rechner von IPv6 zu befreien auch sehr kritisch und stellt auf einer speziell zu diesem Zweck eingerichteten Webseite fest, dass das IPV6 ein „obligatorischer“ Teil von Windows Vista und höheren Versionen ist. Der Betriebssystemhersteller empfiehlt deshalb nachdrücklich, IPv6 und IPv6-Komponenten nicht zu deaktivieren. Dabei weist die Firma darauf hin, dass „einige Windows-Komponenten“ dann möglicherweise nicht mehr funktionieren. So kann es beispielsweise zu einem verzögerten Systemstart kommen, wenn Administratoren den Registry-Eintrag DisabledKomponents mit einem falschen Wert zur Deaktivierung von IPv6 belegen.
Was Administratoren zudem beachten sollten: Das 6to4-Tunneling-Protokoll wird in Windows 7, Windows Vista, Windows Server 2008 R2 und Windows Server 2008 standardmäßig aktiviert, wenn einer Schnittstelle eine öffentliche IPv4-Adresse (eine IPv4-Adresse, die nicht in den Bereichen 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 liegt) zugewiesen wird. 6to4 weist dabei den 6to4-Tunneling-Schnittstellen dieser zugewiesenen Adressen automatisch eine IPv6-Adresse zu. Zudem registriert das Protokoll diese IPv6-Adressen automatisch auf dem zugewiesenen DNS-Server. Sollte das von den Systemverwaltern nicht erwünscht sein, so empfiehlt Microsoft, die IPv6-Tunnelschnittstellen auf den betreffenden Hosts zu deaktivieren. Auf der oben genannten Webseite stellt Microsoft für die Deaktivierung und Aktivierung von Tunnelschnittstellen und die Änderung der Präfixrichtlinien entsprechende Assistenten bereit, die die gewünschte Änderungen ausführen.
Wichtig beim Einsatz von Exchange 2013 und 2016: Wer den Mail-Server mit IPv6 einsetzen will, muss sicherstellen, dass IPv4 auch installiert und aktiviert ist. Wenn dann das Netzwerk ebenfalls beide (!) Protokolle unterstützt, kann der Exchange-Server dann Pakete zu den Clients, die IPv6 einsetzen, senden und auch von ihnen empfangen.
DHCP: Wichtiges Protokoll, das aber auch Nachteile hat
Zu Abschluss unternehmen wir hier noch einen kurzen Ausflug zu einem anderen gängigen Netzwerkprotokoll DHCP (Dynamic Host Configuration Protocol). Der Einsatz von DHCP bietet dem Administrator viele Vorteile:
- Einfache Adressverwaltung: Kommt im IPv4-Netzwerk ein DHCP-Server zum Einsatz, so werden die Systeme automatisch mit einer gültigen Netzwerkadresse versorgt. Dabei stellt das Protokoll auch sicher, dass keine IP-Adresse zweimal vergeben wird.
- Große Flexibilität: Das Protokoll unterstützt unter anderem Bootp-Clients (Bootstrap Protocol) und das Booten vom Netzwerk, dadurch, dass ein DHCP-Server nicht nur auf die Anforderungen von DHCP-Clients, sondern auch auf die von Endgeräten via Bootp reagiert, die dann eine IP-Adresse und die weiteren Informationen zum Booten vom Server erhalten. Es können sowohl lokale als auch Remote-Clients unterstützt werden.
- Auch für große Netzwerke geeignet: Der Einsatz des DHCP-Protokolls ist nicht auf kleine Netzwerke beschränkt, sondern dadurch, dass DHCP-Server mit Multithreading-Techniken arbeiten, können sie auch eine große Anzahl von gleichzeitigen Client-Anforderungen verwalten.
Allerdings kann der Einsatz von DHCP durchaus auch Probleme verursachen:
- Rogue-Server: Ein DHCP-Server ist grundsätzlich leicht zu manipulieren, da die Clients immer jeden DHCP-Server akzeptieren. So können sich dann die automatischen Funktionen des DHCP-Protokoll negativ auf das Netzwerk auswirken. Durch diese Sicherheitslücke kann dann ein solcher Rogue-Server beispielsweise den Nutzern IP-Adressen anbieten. Die Informationen auf dem Weg zu diesem falschen Server können anschließend von einem Angreifer problemlos ausgelesen werden (Man-in-the-Middle-Attacke). Da diese Vorgänge beim Einsatz von DHCP alle vollautomatisch ablaufen, kann es eine gewisse Zeit dauern, bis die Administratoren überhaupt bemerken, dass ein solcher falscher Server die Nutzer mit IP-Adressen versorgt.
- Single Point of Failure: Der Vorteil, dass ein einzelner DHCP-Server sehr viele Clients bedienen kann, beinhaltet auch ein Risiko. Fällt dieser Server aus, so versuchen alle Clients, die zu diesem Zeitpunkt noch keine gültige IP-Adresse besitzen, eine zu bekommen. Die Systeme, die bereits eine IP-Adresse besitzen, werden hingegen versuchen, ihre IP-Adresse zu erneuern: Das Betriebssystem besitzt dann also keine gültige IP-Adresse mehr. Im schlimmsten Fall geht der Netzwerkzugriff für sämtliche Client-Systeme verloren, wenn der Rechner mit dem DHCP-Server ausfällt.
- Versehentliche Aktivierung: Ein Szenario, das gerade Systembetreuer in kleinen Netzen, wie sie in Bürogemeinschaften oder im SOHO-Umfeld verwendet werden, häufiger antreffen. Ein Nutzer hat einen neuen DSL- oder WLAN-Router mit dem Netzwerk verbunden. Bei vielen dieser Geräte ist DHCP standardmäßig aktiviert. Dann befinden sich zwei DHCP-Server im Netz, die aber unterschiedliche Konfigurationen besitzen und somit auch Adressen aus verschiedenen Bereichen verteilen. Das führt dann dazu, dass einige Systeme nicht mehr erreichbar sind oder dass sie keine Verbindung mehr mit dem Internet aufbauen können.
Windows Server 2003: Obwohl diese Version des Windows-Server-Betriebssystems schon sehr alt ist, kommt sie gelegentlich noch in einigen Netzwerken zum Einsatz. Wird auch der DHCP-Server dieses Betriebssystems verwendet, so kann es passieren, dass einige DHCP-Clients sind nicht mit ihm verbinden können. In diesen Fällen sollten Administratoren auf ein anderes System als DHCP-Server setzen oder gleich den alten Windows-Server auf einen neuen Stand bringen.
Den zweiten Teil dieser Serie „Operativ arbeiten im Netzwerk“ mit den Grundlagen finden Sie hier.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
