Ein neuer Glasfaseranschluss verspricht mehr Geschwindigkeit und eine zukunftssichere Internetverbindung. Doch manchmal bringt eine vermeintlich einfache Routerumstellung unerwartete Herausforderungen mit sich. Ein Praxisbericht aus unserem IT-Alltag.
Ausgangssituation: Neue Glasfaser, bestehende IT-Infrastruktur
Bei einem unserer Kunden aus dem Labor- und Forschungsumfeld stand die Umstellung auf einen neuen Glasfaseranschluss an.
Die bestehende IT-Infrastruktur umfasste unter anderem:
- Eine Windows-Server-Domäne mit Active Directory
- Mehrere Domänencontroller mit internen DNS-Diensten
- Einen lokalen Microsoft Exchange Server
- Ein separates WLAN-Netz für mobile Geräte
- VPN-Zugänge für Mitarbeiter
- Eine zentral verwaltete Firewall auf Basis eines LANCOM-Routers
Der neue Glasfaseranschluss sollte die bestehende Internetanbindung ersetzen. Gleichzeitig war der Austausch des bisherigen LANCOM-Routers gegen ein leistungsfähigeres Modell vorgesehen.
Eine wichtige Anforderung: Die vorhandenen Server, Arbeitsplatzrechner und Laborgeräte sollten möglichst ohne Änderungen an ihrer Netzwerkkonfiguration weiterarbeiten.
Die erste Überraschung: IPv6 beeinflusst Active Directory und Exchange
Mit der Aktivierung des neuen Anschlusses wurde erstmals auch IPv6 im internen Netzwerk verfügbar.
Die Windows-Rechner erhielten automatisch öffentliche IPv6-Adressen. Das ist grundsätzlich kein Fehler, denn moderne Betriebssysteme unterstützen IPv6 standardmäßig.
Problematisch wurde jedoch eine zusätzliche Funktion des Routers: Er kündigte sich über IPv6-Router-Advertisements selbst als DNS-Server an.
Dadurch verwendeten einige Windows-Systeme neben den internen Active-Directory-DNS-Servern auch den LANCOM-Router zur Namensauflösung.
Die Besonderheit: Im Router existierte noch eine DNS-Weiterleitung, die Anfragen für die interne Domäne an das Internet weiterleitete.
Externe DNS-Server kennen die internen Active-Directory-Einträge jedoch nicht.
Die Folgen waren unmittelbar spürbar
Mitarbeiter meldeten Probleme bei der Windows-Anmeldung. Gleichzeitig funktionierte die E-Mail-Zustellung über den lokalen Exchange Server nicht mehr zuverlässig.
Im Exchange-Transportprotokoll erschienen unter anderem Fehlermeldungen wie:
451 4.4.0 DNS query failed
SMTPSEND.DNS.NonExistentDomain
Auch die vorgeschaltete POPCon-Software meldete temporäre SMTP-Zustellfehler.
Die Exchange-Dienste waren zunächst überwiegend aktiv. Erst die systematische Untersuchung der Transportwarteschlangen und DNS-Abfragen führte zur eigentlichen Ursache.
Der entscheidende Test
Eine gezielte Abfrage der Active-Directory-Diensteinträge lieferte unterschiedliche Ergebnisse:
- Über den internen Windows-DNS-Server funktionierte die Auflösung.
- Über den IPv6-DNS-Dienst des Routers wurde die benötigte Domäneninformation nicht gefunden.
Damit war der fehlerhafte DNS-Pfad identifiziert.
Die DNS-Weiterleitung im LANCOM wurde korrigiert, sodass Anfragen für die interne Domäne wieder an den zuständigen Active-Directory-DNS-Server gingen.
Nach der Wiederherstellung der korrekten Namensauflösung und dem Start des Exchange-Transportdienstes funktionierte die E-Mail-Zustellung wieder.
Die Erkenntnis: Nicht IPv6 selbst verursachte den Fehler. Durch IPv6 wurde ein bisher nicht genutzter und falsch konfigurierter DNS-Weg aktiv.
Kontrollierte IPv6-Einführung statt ungeplanter Umstellung
Nach der Störungsbehebung entschieden wir uns, die IPv6-Einführung im produktiven Netzwerk zunächst zurückzustellen.
Der neue Glasfaseranschluss verfügte bereits über eine funktionierende öffentliche IPv4-Verbindung. Deshalb konnte IPv6 auf dem Router vorläufig deaktiviert werden, ohne die bestehende IPv4-Kommunikation aufzugeben.
Anschließend wurden die wesentlichen Funktionen überprüft:
- Internetzugang über IPv4
- Erreichbarkeit des Standardgateways
- DNS-Auflösung der Domänencontroller
- Active-Directory-Dienstsuche
- Fehlende IPv6-Standardroute auf den Testclients
So blieb das Netzwerk während der weiteren Arbeiten stabil. Die spätere IPv6-Einführung wird als eigenständige, geplante Änderung behandelt.
Routerwechsel: Die bestehende Netzwerkstruktur erhalten
Bei der anschließenden Routermigration sollte der neue LANCOM die bisherige interne Gateway-Adresse übernehmen.
Um den Austausch kontrolliert durchführen zu können, erhielt der alte Router zunächst eine freie Verwaltungsadresse. Anschließend wurde die bisherige Gateway-Adresse auf den neuen Router übertragen.
Auf diese Weise blieben beide Geräte für administrative Arbeiten erreichbar.
Die vorhandenen Arbeitsplatzrechner und Server konnten ihre Gateway-Konfiguration beibehalten.
Nach der Umschaltung wurden der Internetzugang, die interne DNS-Auflösung und die Erreichbarkeit der Netzwerkdienste erfolgreich geprüft.
WLAN und DMZ: Physische Anschlüsse sind nicht gleich logische Netze
Eine weitere Herausforderung entstand beim separat betriebenen WLAN.
Aus Sicherheitsgründen sollten WLAN-Clients ausschließlich auf das Internet zugreifen dürfen, nicht jedoch auf interne Dateifreigaben oder produktive Laborserver.
Dafür wurde eine eigene DMZ eingerichtet.
Obwohl das WLAN-Netz auf dem neuen Router bereits mit einem eigenen IP-Adressbereich und DHCP-Server eingerichtet war, erhielten die verbundenen WLAN-Clients zunächst keine IP-Adresse.
Die Ursache lag in der Zuordnung des physischen Ethernet-Anschlusses.
Bei LANCOM-Geräten können physische Ethernet-Ports unterschiedlichen logischen LAN-Schnittstellen zugewiesen werden. Entscheidend ist daher nicht allein, an welcher Buchse ein Access Point angeschlossen wird, sondern welchem logischen Netzwerk diese Buchse zugeordnet ist.
Nach der Anpassung der Portzuordnung funktionierte die DHCP-Adressvergabe wieder.
Zusätzlich wurden Firewallregeln eingerichtet, die Verbindungen aus der DMZ zum produktiven Intranet unterbinden sollen. Die vollständige Wirksamkeitsprüfung der Netztrennung gehört zu den abschließenden Sicherheitskontrollen.
VPN verbunden – aber kein Zugriff auf interne Rechner
Nachdem die Internet- und WLAN-Verbindungen funktionierten, zeigte sich eine weitere Auffälligkeit.
Ein Mitarbeiter konnte die VPN-Verbindung erfolgreich aufbauen. Trotzdem waren weder ein interner Arbeitsplatzrechner über Remote Desktop noch die Telefonanlage erreichbar.
Die Routingtabelle des Laptops zeigte jedoch eine passende Route zum internen Netzwerk.
Ein zweites Laptop konnte über denselben WLAN-Zugang erfolgreich auf interne Geräte zugreifen.
Damit konzentrierte sich die Fehlersuche auf die individuelle VPN-Konfiguration beziehungsweise die zugewiesene IP-Adresse.
Ein IP-Adresskonflikt als Ursache
Die Untersuchung ergab, dass dem betroffenen VPN-Client eine IP-Adresse zugeteilt wurde, die bereits für ein anderes Gerät im produktiven Netzwerk reserviert war.
Der VPN-Adresspool überschnitt sich also mit einer bestehenden DHCP-Reservierung.
Die Lösung war vergleichsweise einfach:
Der VPN-Adressbereich wurde angepasst und mit den vorhandenen DHCP-Reservierungen und Ausschlussbereichen abgeglichen. Außerdem wurden beide internen DNS-Server in der VPN-Konfiguration hinterlegt.
Nach dem erneuten Verbindungsaufbau funktionierte auch der Zugriff auf die internen Rechner.
Eine aktive VPN-Verbindung bedeutet noch lange nicht, dass die gesamte Netzwerkkommunikation korrekt funktioniert.
Was Unternehmen aus diesem Praxisfall lernen können
Der Fall zeigt, wie eng verschiedene Komponenten einer modernen IT-Infrastruktur miteinander verbunden sind.
Ein neuer Internetanschluss betrifft nicht nur die Geschwindigkeit der Verbindung. Er kann gleichzeitig Auswirkungen auf DNS, Active Directory, E-Mail-Kommunikation, Firewallregeln und VPN-Zugänge haben.
Aus unserer Sicht sind bei solchen Umstellungen besonders fünf Punkte wichtig:
- IPv6 bewusst planen. Die automatische Aktivierung neuer Netzwerkfunktionen sollte vorab auf ihre Auswirkungen geprüft werden.
- DNS konsequent kontrollieren. Gerade in Active-Directory-Umgebungen müssen interne Namen zuverlässig durch die vorgesehenen DNS-Server aufgelöst werden.
- Netzwerksegmente sauber trennen. Ein separates WLAN benötigt neben einem eigenen IP-Netz auch die richtige Schnittstellenzuordnung und wirksame Firewallregeln.
- VPN-Adressbereiche konfliktfrei halten. VPN-Adressen dürfen sich nicht mit bestehenden statischen Adressen oder DHCP-Reservierungen überschneiden.
- Jede Umstellung schrittweise überprüfen. Ein funktionierender Internetzugang allein sagt noch nichts über die Erreichbarkeit interner Dienste aus.
Fazit: Systematische Fehlersuche statt ungezielter Änderungen
Was zunächst wie mehrere voneinander unabhängige Störungen aussah, ließ sich durch eine strukturierte Vorgehensweise nachvollziehbar eingrenzen und beheben.
Die entscheidenden Werkzeuge waren dabei keine außergewöhnlichen Speziallösungen, sondern die gezielte Analyse von DNS-Abfragen, Exchange-Warteschlangen, DHCP-Konfigurationen, Routingtabellen und Firewall-Einstellungen.
Gerade in Unternehmen mit komplexen oder besonders sensiblen IT-Umgebungen ist eine sorgfältig geplante Netzwerkumstellung entscheidend, um Betriebsunterbrechungen möglichst gering zu halten.
IT-LAS unterstützt Unternehmen, Praxen und Labore bei der Planung, Migration und zuverlässigen Betreuung ihrer IT-Infrastruktur.
Ob Netzwerktechnik, Windows Server, Virtualisierung, Datensicherung oder IT-Sicherheit – wir betrachten nicht nur einzelne Komponenten, sondern das Zusammenspiel der gesamten Umgebung.
IT-LAS – IT, die funktioniert. Damit Sie arbeiten können.