Ein Gerät kann tagelang problemlos laufen und seine geleaste Adresse verlieren, wenn Verlängerung und Rebinding scheitern und der Lease abläuft. Dein Laptop verbindet sich vielleicht mit einer anderen IP-Adresse, oder ein Drucker ist über eine Verknüpfung nicht mehr erreichbar, weil dort noch seine alte Adresse hinterlegt ist. Wenn Namen nicht mehr wie erwartet aufgelöst werden, gerät schnell der lokale DNS-Dienst unter Verdacht. Diese Symptome können zusammenhängen. Sie sind aber nicht dasselbe Problem.
Das Dynamic Host Configuration Protocol, kurz DHCP, weist einem Netzwerkclient für eine begrenzte Zeit eine Adresse und weitere Einstellungen zu. DNS löst einen Namen in eine Adresse auf. Anschließend muss eine Anwendung den Dienst unter dieser Adresse erreichen können. Wenn ein Lease nicht verlängert wird und du zuerst DNS änderst, können nützliche Hinweise verloren gehen. Außerdem musst du dann eine weitere Änderung im Blick behalten. Die folgenden Prüfungen haben eine klare Reihenfolge und sind für ein Netzwerk gedacht, das dir gehört oder das du verwalten darfst.
Die Symptome vor einem Neustart
Fang beim betroffenen Gerät an. Notiere die Uhrzeit, den verwendeten Netzwerknamen oder kabelgebundenen Port, die aktuelle IP-Adresse, falls eine angezeigt wird, und die Adresse oder den Hostnamen, unter dem ein anderer Dienst das Gerät erwartet hat. Halte fest, ob das Gerät gar keine Netzwerkverbindung hat, einen bestimmten lokalen Dienst nicht erreicht oder einfach unter einer neuen Adresse auftaucht.
Jeder dieser Fälle wirft eine andere Frage auf. Ohne Adresse kann ein Gerät die üblichen IPv4-Netzwerkdienste nicht nutzen. Mit einer neuen Adresse hat es DHCP möglicherweise erfolgreich abgeschlossen, während eine alte Verknüpfung, Firewall-Regel oder ein lokaler Eintrag noch auf eine andere Adresse zeigt. Wenn es eine Adresse erreicht, einen Hostnamen aber nicht auflösen kann, liegt möglicherweise ein DNS-Problem vor, obwohl der Lease in Ordnung ist. Fass das nicht alles als „das Netzwerk ist kaputt“ zusammen.
Vermeide es, in einem einzigen Versuch Leases zu löschen, den Router neu zu starten und eine DNS-Einstellung zu ändern. Ein Neustart kann einen vorübergehenden Fehler beheben, aber auch flüchtige Logs und Hinweise auf den zeitlichen Ablauf löschen. Wenn du neu starten musst, um den Betrieb aufrechtzuerhalten, notiere vorher deine Beobachtungen und betrachte den Zustand danach als neue Beobachtung.
Getrennte Prüfungen für DHCP, DNS und die Anwendung
DHCP liefert normalerweise mehr als eine IP-Adresse. Dazu können auch eine Subnetzmaske, ein Standardgateway, DNS-Serveradressen und eine Lease-Dauer gehören. RFC 2131, die DHCP-Protokollspezifikation, beschreibt die Nachrichten, mit denen Clients und Server einen Lease anfordern und verlängern. Die zugehörigen Optionsdefinitionen, darunter die Angaben zu DNS-Servern, stehen in RFC 2132.
Daraus ergibt sich eine sinnvolle Reihenfolge für die Prüfung:
- Hat der Client eine Adresse und Netzwerkeinstellungen aus dem erwarteten Netzwerk?
- Zeigt der DHCP-Server einen aktuellen Lease oder einen kürzlich erfolgten Versuch der Lease-Anforderung für diesen Client?
- Wenn der Client eine Adresse hat: Erreicht er eine bekannte lokale Adresse im selben Netzwerk, auf das er zugreifen darf?
- Wenn das geprüft ist: Wird der gewünschte Name in die erwartete aktuelle Adresse aufgelöst?
- Nimmt der betreffende Dienst tatsächlich Verbindungen an, und ist diese Verbindung erlaubt?
Die Menübezeichnungen unterscheiden sich je nach Router, Firewall und eigenständigem DHCP-Server. Such nach einer Seite oder einem Log mit einer Bezeichnung wie DHCP-Leases, Clients, Adresszuweisungen oder DHCP-Ereignisse. Die Anzeige „bekannte Geräte“ eines Routers kann alte und aktuelle Informationen vermischen. Nutze stattdessen den Lease-Status, die Ablaufzeit oder den Zeitstempel des Ereignisses, sofern diese Angaben verfügbar sind.
Der Netzwerkpfad zwischen Client und Server
Bevor du eine ausgebliebene Verlängerung als Serverfehler einstufst, prüfe, in welchem Netzwerk der Client ist und welcher DHCP-Server dafür zuständig sein soll. Gäste-WLAN, ein IoT-VLAN, die Backhaul-Verbindung eines Mesh-Knotens und ein nachgeschalteter Router können jeweils eigene Broadcast-Domänen bilden. Die Serversuche per Broadcast und das Rebinding benötigen entweder einen Server in derselben Broadcast-Domäne oder einen eingerichteten DHCP-Relay. Die Verlängerung erfolgt normalerweise per Unicast und benötigt einen funktionierenden Netzwerkpfad zum ursprünglichen Server; normales Routing kann diese Anfrage ohne DHCP-Relay über Subnetzgrenzen hinweg transportieren. Für ein Gerät hinter einem zweiten Router ist die Lease-Tabelle des Hauptrouters nicht unbedingt maßgeblich.
Schau in der Verwaltungsoberfläche oder auf der Netzwerkstatusseite des Geräts nach, mit welchem Netzwerk es aktuell verbunden ist. Prüfe dann den zuständigen Router, Access Point oder DHCP-Server, statt große Adressbereiche zu scannen oder Netzwerke zu untersuchen, die du nicht verwaltest. Bei einem Gerät im verwalteten Firmennetz frag den zuständigen Administrator nach den Lease- und Ereignisinformationen.
Prüfe auch, ob mehrere DHCP-Dienste aktiv sind. Ein zusätzlicher Router, der als Router statt als Access Point angeschlossen ist, kann eigene Einstellungen verteilen. Dasselbe gilt für eine Appliance im Testnetz oder einen falsch eingerichteten Dienst für virtuelle Netzwerke. Bei zwei Servern können die Probleme scheinbar nur gelegentlich auftreten: Ein Client bekommt von einem Server einen brauchbaren Lease, während ein anderer vom zweiten Server abweichende DNS- oder Gateway-Einstellungen erhält. Deaktiviere einen verdächtigen Dienst erst, wenn du seine Aufgabe kennst und weißt, mit welchem Segment er verbunden ist. Sonst könnten andere Geräte ihre Verbindung verlieren.
Client-Identität und Lease-Status
Such den passenden Lease und vergleiche die aktuelle IP-Adresse, die Client-Kennung oder MAC-Adresse, den Hostnamen, falls angezeigt, den Beginn oder Verlängerungszeitpunkt und die Ablaufzeit. Eine MAC-Adresse hilft dir, eine Netzwerkschnittstelle zuzuordnen. Sie ist aber nicht immer eine dauerhafte Gerätekennung. Smartphones und Laptops können private WLAN-Adressen verwenden. Ein Computer mit mehreren Schnittstellen hat unterschiedliche MAC-Adressen für Ethernet und WLAN. Eine Reservierung für die falsche Schnittstelle passt deshalb möglicherweise nie zu dem Client, der einen Lease anfordert.
Ein abgelaufener Lease ist nicht automatisch ein Fehler. Ein Gerät, das im Ruhezustand, ausgeschaltet oder außerhalb der WLAN-Reichweite war, kann später zurückkehren und eine andere gültige Adresse bekommen. DHCP weist Adressen zeitlich begrenzt zu. Eine Adresse gehört einem Gerät dadurch nicht dauerhaft. Entscheidend ist, ob sich die erwartete Adresse nach einer normalen Neuvergabe geändert hat oder ob der Client wiederholt keine brauchbare Konfiguration bekommen hat.
Wenn der DHCP-Server Logs führt, grenze die Suche auf den kleinstmöglichen relevanten Zeitraum ein. Such nach der Anfrage des Clients, einem Angebot oder einer Bestätigung des Servers und einer möglichen Fehlermeldung. Ein Logeintrag sagt etwas über dieses Ereignis aus. Er beweist nicht, dass die Anwendung auf dem Gerät funktioniert. Ein fehlender Eintrag kann wiederum bedeuten, dass du beim falschen DHCP-Server oder im falschen Netzwerksegment nachsiehst. Er bedeutet nicht zwangsläufig, dass der Client nichts getan hat.
Ein rückgängig machbarer Test nach dem anderen
Wenn du den zuständigen DHCP-Server gefunden hast, wähle einen Test, der zum Gerät und seiner aktuellen Aufgabe passt und den Betrieb möglichst wenig stört. Einen unkritischen Client nach einem dokumentierten Verfahren erneut mit demselben Netzwerk, für dessen Nutzung du berechtigt bist, zu verbinden, kann dazu führen, dass er seine Konfiguration neu anfordert. Bei einem Server, NAS oder Gerät mit laufendem Backup wartest du auf ein Wartungsfenster und hältst dich an das vom Hersteller vorgesehene Vorgehen für Netzwerkänderungen. Verlängere nicht ständig den Lease, starte das Gerät nicht immer wieder neu und setze es nicht auf Werkseinstellungen zurück, nur damit sich die Lease-Tabelle aktualisiert.
Führe einen Test durch und vergleiche das Ergebnis anschließend mit deinen bisherigen Notizen:
- Hat das Gerät eine Adresse im erwarteten Subnetz bekommen?
- Passt der Lease-Eintrag zu der Schnittstelle, über die sich das Gerät tatsächlich verbunden hat?
- Entsprechen Gateway und DNS-Server den vorgesehenen Einstellungen für dieses Netzwerk?
- Ist in einer Verknüpfung auf einem Client, einer Integration oder einer Zugriffsregel noch eine alte IP-Adresse oder ein alter Hostname hinterlegt?
- Liegt das verbleibende Problem bei der DNS-Auflösung, oder funktioniert die Auflösung und das Problem betrifft den Dienst selbst?
Wenn ein Gerät eine verlässlich gleichbleibende Adresse braucht, kann eine DHCP-Reservierung sinnvoll sein, sobald du den richtigen DHCP-Server und die richtige Netzwerkschnittstelle bestätigt hast. Eine Reservierung legt fest, welche Adresse dieser Server dem Client künftig anbieten soll. Sie behebt normalerweise keine fehlende Route, kein schwaches WLAN, keinen gestoppten DNS-Dienst und keine nicht erreichbare Anwendung. Notiere bei jeder Reservierung kurz das Gerät und die Schnittstelle, damit du spätere Änderungen nachvollziehen kannst.
Schlussfolgerungen auf Grundlage der Beobachtungen
Eine hilfreiche Schlussfolgerung ist konkret: „Der Client hat vom erwarteten Server einen neuen Lease bekommen“, „der erwartete Hostname zeigte noch auf die alte Adresse“ oder „der Client tauchte in diesem Zeitraum auf dem DHCP-Server für sein VLAN nicht auf“. Jede dieser Aussagen führt zur nächsten Prüfung, ohne zu behaupten, dass das gesamte Netzwerk einwandfrei funktioniert.
Wenn du für Vergleiche Aufzeichnungen über einen längeren Zeitraum brauchst, kann DeviceShelf lokale Beobachtungen aus den Netzwerken liefern, die du verwaltest. Vergleiche die dort erfassten Geräteinformationen mit den Angaben des zuständigen DHCP-Servers und des betroffenen Dienstes. Ein Geräteeintrag allein belegt weder eine DHCP-Verlängerung noch ein DNS-Ergebnis oder eine Antwort der Anwendung.
Prüfe zuerst, ob der Client eine gültige Konfiguration hat, bevor du die Namensauflösung änderst. Wenn du DHCP, DNS und die Anwendung getrennt prüfst, kannst du ein erneutes Auftreten leichter erklären und vermeidest, dass aus einem unklaren Lease-Ereignis mehrere Konfigurationsänderungen werden.