Das lernst du
- Adresse, Maske, Gateway, DNS und Suffix getrennt prüfen.
- Eine erfolgreiche Vergabe von funktionierender Kommunikation unterscheiden.
Voraussetzungen: G02 · IPv4 und Subnetze berechnen
Unser Büro-PC hat 192.168.10.120/24. Das ist erst ein Teil seiner Konfiguration. Unterschiedliche Fehler in den übrigen Parametern erzeugen unterschiedliche Symptome.
- Standardgateway
- Der nächste Router für Ziele, für die keine spezifischere Route passt. Seine Adresse ist eine Konfigurationsangabe; ob er Pakete weiterleiten kann, muss getrennt geprüft werden.
Der Konfigurationspass eines Büro-PCs
Grafik vergrößern
Welcher Parameter löst welches Problem?
Die IPv4-Adresse identifiziert eine Netzwerkschnittstelle. Die Maske legt fest, welche Ziele direkt erreichbar erscheinen. Das Standardgateway ist ein nächster Hop für Ziele ohne speziellere Route. Es muss für den Client über den vorgesehenen Link erreichbar sein; im üblichen Ethernet-LAN liegt es deshalb im eigenen Subnetz.
Der DNS-Server beantwortet Namensanfragen. Er darf in einem entfernten Subnetz stehen, wenn der Client ihn über Routing erreicht. Das DNS-Suffix ergänzt kurze Namen: aus dateien kann beispielsweise dateien.nordlicht.test werden. Option 15 liefert einen Domain-Namen; Suchlisten und das Verhalten des Clients sind davon zu unterscheiden.
| Parameter | Nordlicht | Bei einem Fehler |
|---|---|---|
| Adresse/Maske | 192.168.10.120/24 | Konflikt oder falsche Entscheidung lokal/geroutet |
| Gateway | 192.168.10.1 | Lokale Ziele gehen, entfernte möglicherweise nicht |
| DNS | 192.168.20.10 | IP-Zugriff möglich, Namen scheitern |
| Suffix | nordlicht.test | Kurzer Name scheitert trotz gültigem vollständigem Namen |
Fehler durch getrennte Tests eingrenzen
Prüfe zunächst empfangene Werte. Teste dann ein bekanntes lokales Ziel, ein bekanntes entferntes IP-Ziel und schließlich einen vollständigen DNS-Namen. Ein fehlgeschlagener Ping allein beweist keine unterbrochene Verbindung: ICMP kann gefiltert sein. Prüfe gegebenenfalls den konkreten TCP-Dienst.
Auch eine erfolgreiche DNS-Abfrage beweist nicht, dass der aufgelöste Dienst erreichbar ist. Vergleiche die erhaltene Zieladresse mit der Planung und teste anschließend dessen Port. Im Browserlabor repräsentieren IP- und Namenstests diese getrennten Prüfungen vereinfacht.
Ein Aufruf des Intranets Schritt für Schritt
Der Büro-PC 192.168.10.120/24 möchte intranet.nordlicht.test öffnen. Zuerst benötigt er die zugehörige IP-Adresse. Er sendet seine DNS-Anfrage an den konfigurierten Resolver 192.168.20.10. Weil dieser außerhalb von .10.0/24 liegt, wird schon die DNS-Anfrage über das lokale Gateway 192.168.10.1 zugestellt. Ein richtig eingetragener DNS-Server hilft deshalb wenig, wenn das Gateway fehlt oder der Weg zum Resolver gesperrt ist.
Antwortet DNS beispielsweise mit 192.168.20.30, prüft der Client erneut den Weg zu diesem Ziel. Erst dann beginnt der eigentliche Verbindungsaufbau zur Anwendung. DHCP ist an diesen laufenden Anfragen nicht beteiligt. Die DNS-Serveradresse, die Adresse des Webservers und die Gatewayadresse dürfen verschieden sein; sie lösen unterschiedliche Aufgaben.
Was aus einem Befund wirklich folgt
Ist eine entfernte IP-Adresse erreichbar, ein Name jedoch nicht, sind Namensauflösung und Suchsuffix naheliegende Prüfpunkte. Scheitert bereits der Zugriff auf den DNS-Server, muss zuerst dessen Netzpfad untersucht werden. Antwortet DNS korrekt, kann die Anwendung trotzdem wegen eines geschlossenen Ports oder eines eigenen Fehlers scheitern. Aus einem einzigen gescheiterten Browseraufruf lässt sich keine bestimmte falsche DHCP-Option ableiten.
Vergleiche immer drei Ebenen: den Sollwert im Adressplan, den tatsächlich im ACK übertragenen Wert und den aktiven Wert am Client. Lokale Einstellungen können abweichen, und ein bereits laufender Client hat eine Änderung am Server möglicherweise noch nicht übernommen. Erst dieser Vergleich zeigt, an welcher Stelle die falsche Konfiguration entsteht.
ACK erhalten, Intranet trotzdem nicht erreichbar
- ipconfig /all zeigt Adresse .120, Maske /24, Gateway .1 und DNS 192.168.20.99.
- Ein Test zum bekannten Intranet-IP-Ziel gelingt. Der Test des Namens intranet.nordlicht.test scheitert. Das grenzt die Ursache ein: Vergabe und dieser IP-Weg funktionieren.
- DNS-Option auf 192.168.20.10 korrigieren. Konfiguration neu beziehen, empfangene Option kontrollieren, vollständigen Namen erneut auflösen.
- Funktioniert der vollständige Name, aber intranet nicht, anschließend Suffix und Suchliste untersuchen.
Ergebnis: Die Reparatur betrifft die DNS-Option, nicht den Pool. Der erfolgreiche Neubezug allein wäre noch keine Abnahme.
Typische Fehler
- DNS muss nicht im Clientnetz stehen; das Gateway normalerweise schon.
- Ein Suffix ist kein DNS-Server.
- DHCP verteilt keine Garantie für Erreichbarkeit.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- RFC 2132 · DHCP-Optionen ↗Optionen 1, 3, 6, 15, 50–61; März 1997
- Microsoft · Set-DhcpServerv4OptionValue ↗Windows Server 2025 PowerShell
- Microsoft · ipconfig ↗Windows 11 / Windows Server 2025