LF3 · Planen
LF3.9 – Client-Netzparameter, Gateway, DNS und DHCP einordnen
Client-IP, Präfix, Standardgateway, DNS und DHCP funktional unterscheiden, gemeinsam prüfen und für die Client-Integration plausibel planen.
Lernfeld 3 · Clients in Netzwerke einbinden
Curriculum-Faden
Diese Teilkompetenz bauen Sie hier auf
Handlungsphase: Planen
IP-Adresse, Präfix beziehungsweise Subnetzmaske, Standardgateway, DNS und DHCP aus Client-Sicht zusammenhängend planen und ihre Funktionen unterscheiden.
LF3.8 hat Netzzugehörigkeit und IPv4-Subnetze bestimmt.
LF3.10 führt die technischen Ergebnisse zu einem Integrationskonzept zusammen.
Bewusste Abgrenzung dieser Lektion
Clientseitige Nutzung und Einordnung von DHCP und DNS; keine Bereitstellung oder Administration entsprechender Serverdienste.
Curriculumquelle: KMK-Rahmenlehrplan Fachinformatiker, Lernfeld 3
Berufliche Ausgangssituation
Im fiktiven K-27 Medienbüro wurde in LF3.8 für einen Clientbereich das Netz 192.0.2.64/27 geplant.
Für Client A stehen nun folgende Werte in der Integrationsdokumentation:
| IPv4-Adresse | 192.0.2.77 |
|---|---|
| Präfix | /27 |
| Subnetzmaske | 255.255.255.224 |
| Standardgateway | 192.0.2.65 |
| DNS-Resolver | 198.51.100.53 |
| Parameterbezug | DHCPv4 |
Clientparameter haben unterschiedliche Aufgaben
IP-Adresse
Identifiziert die IP-Schnittstelle des Clients im betrachteten Netzkontext.
Präfix / Subnetzmaske
Bestimmt aus Client-Sicht, welcher IPv4-Adressbereich zum eigenen Subnetz gehört.
Standardgateway
Ist im einfachen Clientfall der nächste Router, der für Ziele außerhalb des eigenen Subnetzes verwendet werden kann, wenn keine spezifischere Route greift.
DNS-Resolver
Ist der konfigurierte DNS-Dienst, an den der Client typischerweise Anfragen zur Namensauflösung richtet.
DHCP
Ist ein Verfahren, über das ein Client Adress- und weitere Konfigurationsparameter automatisiert beziehen kann.
IP-Adresse und Präfix zuerst prüfen
Client A besitzt:
Aus LF3.8 ist bekannt:
- Netzadresse: 192.0.2.64,
- erster klassisch nutzbarer Host: 192.0.2.65,
- letzter klassisch nutzbarer Host: 192.0.2.94,
- Broadcastadresse: 192.0.2.95.
192.0.2.77 ist damit eine plausible Hostadresse für dieses geplante Clientnetz.
Lokales oder entferntes Ziel?
Der Client verwendet sein Präfix, um ein Ziel zunächst aus IP-Sicht einzuordnen.
Lokales Beispiel
Client: 192.0.2.77/27
Ziel: 192.0.2.70
Beide liegen im Netz 192.0.2.64/27.
Im hier betrachteten einfachen Clientfall ist dafür kein Standardgateway erforderlich.
Entferntes Beispiel
Client: 192.0.2.77/27
Ziel: 198.51.100.53
Das Ziel liegt nicht im Netz 192.0.2.64/27.
Ohne spezifischere Route wird für dieses entfernte Ziel das Standardgateway relevant.
Was macht das Standardgateway?
Ein Client kann nicht jedes entfernte IP-Netz direkt auf seinem lokalen Link erreichen.
Im hier betrachteten einfachen Clientnetz wird deshalb eine Routeradresse als Standardgateway verwendet:
Diese Adresse liegt innerhalb des geplanten Netzes 192.0.2.64/27 und ist damit für das K-27-Szenario als lokale Routeradresse plausibel.
Lokale Ziele im eigenen Subnetz werden im hier betrachteten einfachen Fall lokal erreicht. Für entfernte Ziele kann das Standardgateway als nächster Router verwendet werden.
Routingtabellen, statische Routen, Routingprotokolle und Routerkonfiguration werden hier nicht administriert.
Ein unplausibles Gateway erkennen
Angenommen, für Client A mit 192.0.2.77/27 wäre eingetragen:
192.0.2.130 liegt nicht im geplanten Netz 192.0.2.64/27.
Für das hier geplante Ethernet-Clientnetz wäre dieser Wert daher kein plausibles direkt erreichbares Standardgateway.
Das ist ein Parameterfehler, der bereits durch Prüfung von IP-Adresse und Präfix erkannt werden kann.
DNS aus Client-Sicht
Das Domain Name System ist ein verteiltes Namenssystem.
Für einen Client ist besonders wichtig: Anwendungen verwenden häufig Namen, während die Netzkommunikation IP-Adressen benötigt.
Ein Client richtet DNS-Anfragen typischerweise an einen konfigurierten Resolver beziehungsweise DNS-Dienst.
Im K-27-Lernfall lautet dessen Dokumentationsadresse:
Dieser DNS-Resolver liegt nicht im lokalen Netz 192.0.2.64/27.
Das ist grundsätzlich kein Widerspruch: Ein DNS-Resolver darf aus Client-Sicht auch in einem entfernten IP-Netz liegen, wenn er über die vorhandene IP-Konnektivität erreichbar ist.
DNS ist nicht das Standardgateway
Standardgateway
Hilft dem Client im einfachen Fall, entfernte IP-Netze über einen Router zu erreichen.
DNS-Resolver
Bearbeitet DNS-Anfragen beziehungsweise liefert DNS-Antworten für die Namensauflösung.
Ein funktionierender DNS-Resolver ersetzt keine IP-Konnektivität. Umgekehrt garantiert ein funktionierendes Gateway noch keine erfolgreiche DNS-Namensauflösung.
Resolver und autoritativer DNS-Server sind nicht dasselbe
Für LF3.9 reicht eine grundlegende Unterscheidung:
Resolver
Bearbeitet aus Sicht des Clients die Anfrage zur Namensauflösung und beschafft die benötigte Antwort.
Autoritativer DNS-Server
Hält autoritative DNS-Daten für einen bestimmten Namensbereich.
Die Administration von DNS-Zonen, Delegationen, DNSSEC oder autoritativen Servern gehört nicht in LF3.9.
DHCP ist mehr als eine IP-Adresse
DHCPv4 kann einem Client eine IPv4-Adresse bereitstellen und weitere Parameter übermitteln.
Für LF3.9 sind besonders relevant:
| DHCPv4-Option | Bedeutung im Clientkontext |
|---|---|
| Option 1 | Subnet Mask |
| Option 3 | Router |
| Option 6 | Domain Name Server |
DHCP ist das Konfigurationsverfahren; die IPv4-Adresse ist nur einer der Werte, die ein Client dabei erhalten kann.
Der DHCPv4-Grundablauf
Für die erstmalige Adressbeschaffung wird häufig folgende didaktische Kurzform verwendet:
-
DHCPDISCOVER
Der Client sucht verfügbare DHCP-Server. -
DHCPOFFER
Ein Server bietet Konfigurationsinformationen an. -
DHCPREQUEST
Der Client fordert das ausgewählte Angebot beziehungsweise die gewählte Konfiguration an. -
DHCPACK
Der Server bestätigt die Konfiguration.
Diese vier Schritte sind ein nützliches Grundmodell für die initiale DHCPv4-Zuweisung. Sie ersetzen nicht die vollständige Beschreibung aller DHCP-Zustände, Verlängerungen und Sonderfälle.
Manuell oder automatisch?
Die Funktion eines Parameters ist von seiner Bezugsart zu unterscheiden.
Manuelle Konfiguration
IP-Adresse, Präfix beziehungsweise Maske, Gateway und DNS-Werte werden gezielt am Client eingetragen.
DHCPv4
Der Client bezieht seine Konfigurationswerte automatisiert über DHCPv4.
Ein per DHCP erhaltener DNS-Wert bleibt funktional ein DNS-Parameter. Ein manuell eingetragenes Standardgateway bleibt funktional ein Standardgateway.
Clientkonfiguration als Ganzes prüfen
Für K-27 wird geprüft:
| Parameter | Wert | Plausibilitätsfrage |
|---|---|---|
| IP-Adresse | 192.0.2.77 | Ist es eine nutzbare Adresse im geplanten Netz? |
| Präfix | /27 | Passt es zum geplanten Netz 192.0.2.64/27? |
| Maske | 255.255.255.224 | Entspricht sie /27? |
| Gateway | 192.0.2.65 | Ist es im geplanten lokalen Netz plausibel? |
| DNS | 198.51.100.53 | Ist der Resolver über die IP-Konnektivität erreichbar? |
| Bezugsart | DHCPv4 | Sind die bezogenen Werte vollständig und plausibel? |
Fehlerbild 1: Lokale IP-Kommunikation funktioniert, Namen nicht
Angenommen:
- der Client erreicht andere IP-Adressen im lokalen Netz,
- entfernte IP-Ziele sind grundsätzlich erreichbar,
- ein Dienst über seinen Namen aber nicht.
Dann ist es fachlich sinnvoll, unter anderem die DNS-Konfiguration und Namensauflösung gezielt zu prüfen.
Fehlerbild 2: Lokales Netz funktioniert, entfernte Netze nicht
Wenn lokale Ziele im eigenen Subnetz erreichbar sind, entfernte IP-Ziele aber nicht, gehört im hier betrachteten Clientfall das Standardgateway zu den relevanten Prüfparametern.
Dabei wird geprüft:
- ist ein Gateway eingetragen,
- ist seine Adresse im geplanten Clientnetz plausibel,
- passt die Präfixinformation des Clients,
- ist der Wert möglicherweise falsch oder unvollständig bezogen worden?
Die Konfiguration des Routers selbst ist nicht Teil dieser Lernetappe.
Fehlerbild 3: DHCP-Client erhält unplausible Parameter
Wenn ein Client per DHCPv4 Werte erhält, werden nicht nur die Existenz, sondern auch die fachliche Plausibilität geprüft.
Beispiel:
- IP: 192.0.2.77,
- Präfix: /27,
- Gateway: 192.0.2.130.
Der DHCP-Bezug macht eine Konfiguration nicht automatisch korrekt.
Prüfreihenfolge für Clientparameter
- IPv4-Adresse erfassen.
- Präfix beziehungsweise Subnetzmaske erfassen.
- Eigenes Subnetz bestimmen.
- Prüfen, ob die eigene Adresse als Hostadresse plausibel ist.
- Standardgateway prüfen.
- Lokale und entfernte Testziele unterscheiden.
- DNS-Resolveradresse prüfen.
- Bei automatischer Konfiguration: DHCP-Bezug und erhaltene Parameter einordnen.
- Erst danach gezielt die Fehlerursache weiter eingrenzen.
IPv6: wichtige Abgrenzung
LF3.9 konzentriert sich beim DHCP-Grundablauf auf DHCPv4.
Eine fachlich wichtige Übertragung darf jedoch nicht gemacht werden:
Bei IPv6 werden Default-Router über Router Advertisements im Rahmen von Neighbor Discovery bekannt gemacht.
DHCPv6 kann Adressen und weitere Konfigurationsinformationen bereitstellen, ist aber nicht als direkte Entsprechung der DHCPv4 Router Option zu verstehen.
Die aktuelle DHCPv6-Spezifikation ist RFC 9915. RFC 9915 ersetzt RFC 8415.
Eine vertiefte IPv6-Autokonfiguration oder DHCPv6-Administration ist nicht Gegenstand von LF3.9.
Typische Denkfehler
Gateway für jedes Paket
Zu pauschal. Lokale Ziele im eigenen Subnetz benötigen im hier betrachteten einfachen Fall nicht das Standardgateway.
DNS liefert Internetzugang
Falsch. DNS löst Namen beziehungsweise DNS-Daten auf; IP-Konnektivität und Routing sind davon zu unterscheiden.
DHCP = IP-Adresse
Falsch. DHCP ist ein Konfigurationsprotokoll und kann mehrere Parameter bereitstellen.
Gateway muss immer .1 sein
Falsch. Entscheidend ist die konkrete Netzplanung, nicht eine bestimmte Endziffer.
DNS muss lokal sein
Falsch. Ein Resolver kann auch in einem entfernten IP-Netz liegen, wenn er erreichbar ist.
Bewusste curriculare Grenze
LF3.9 behandelt nicht:
- DHCP-Serverinstallation,
- DHCP-Scope-Administration,
- DHCP-Reservations,
- DHCP-Relay-Konfiguration,
- DNS-Zonenadministration,
- Betrieb autoritativer DNS-Server,
- Router-CLI,
- Routingprotokolle,
- NAT-Konfiguration,
- umfangreiche DHCPv6-Administration.
LF3.10 = daraus ein anforderungsgerechtes Integrationskonzept entwickeln.
PRAXISAUFGABE
Praktische Lernaufgabe
Bewerten Sie folgende fiktiven Clientkonfigurationen.
| Fall | IP / Präfix | Gateway | DNS | Bezugsart |
|---|---|---|---|---|
| A | 192.0.2.77/27 | 192.0.2.65 | 198.51.100.53 | DHCPv4 |
| B | 192.0.2.110/27 | 192.0.2.65 | 198.51.100.53 | manuell |
| C | 192.0.2.78/27 | 192.0.2.130 | 198.51.100.53 | DHCPv4 |
| D | 192.0.2.79/27 | 192.0.2.65 | nicht eingetragen | manuell |
Das geplante Clientnetz lautet: 192.0.2.64/27.
Prüfen Sie für jeden Fall:
- Passt die Client-IP zum vorgesehenen Subnetz?
- Ist das Gateway aus Client-Sicht plausibel?
- Ist DNS konfiguriert?
- Welche lokale Kommunikation könnte funktionieren?
- Welche entfernte Kommunikation könnte betroffen sein?
- Welche Namensauflösung könnte betroffen sein?
- Welche Aussage ist sicher, welche wäre ohne weitere Diagnose nur eine Vermutung?
Selbsttest LF3.9 – Client-Netzparameter, Gateway, DNS und DHCP
Prüfen Sie, ob Sie Client-IP, Präfix beziehungsweise Subnetzmaske, Standardgateway, DNS und DHCP funktional unterscheiden und gemeinsam beurteilen können.
Alle Fragen und Antwortmöglichkeiten dieses Selbsttests wurden für SemaTrain eigenständig entwickelt.
Praxisauftrag
Selbsttraining – keine Abgabe erforderlich.
Erstellen Sie für das fiktive Netz 192.0.2.64/27 eine vollständige Client-Parameterkarte.
Dokumentieren Sie:
- eine plausible Client-IP,
- Präfix und Subnetzmaske,
- eine plausible Gatewayadresse,
- eine lokale Testzieladresse,
- eine entfernte Testzieladresse,
- eine DNS-Resolveradresse,
- Bezugsart manuell oder DHCPv4,
- bei DHCPv4 die Bedeutung der Optionen 1, 3 und 6,
- eine systematische Prüfreihenfolge.
Erstellen Sie zusätzlich drei fehlerhafte Varianten:
- falsche Subnetzzugehörigkeit,
- unplausibles Gateway,
- fehlende oder falsche DNS-Konfiguration.
Führen Sie keine Router-, DHCP-Server- oder DNS-Serverkonfiguration durch.
SELBSTKONTROLLE
Selbstkontrolle
- Kann ich Client-IP und Präfix gemeinsam prüfen?
- Kann ich ein lokales von einem entfernten Ziel unterscheiden?
- Kann ich erklären, wann das Standardgateway relevant wird?
- Kann ich Gateway und DNS funktional unterscheiden?
- Kann ich DNS aus Client-Sicht einordnen?
- Kann ich DHCP von einer einzelnen IP-Adresse unterscheiden?
- Kenne ich DHCPv4 Option 1, Option 3 und Option 6?
- Kann ich DHCPDISCOVER, DHCPOFFER, DHCPREQUEST und DHCPACK einordnen?
- Kann ich manuelle und per DHCP bezogene Parameter unterscheiden?
- Kann ich eine unplausible Gatewayadresse erkennen?
- Kann ich erklären, warum IPv6-Default-Router nicht einfach über die DHCPv4 Router Option modelliert werden?
- Habe ich Serveradministration und Routerkonfiguration aus LF3.9 herausgehalten?
REFLEXION
Reflexion
- Warum müssen IP-Adresse und Präfix zuerst gemeinsam betrachtet werden?
- Warum ist ein Standardgateway nicht für jedes Ziel nötig?
- Warum kann ein entfernter DNS-Resolver trotzdem eine gültige Clientkonfiguration sein?
- Warum ist DHCP mehr als eine automatische IP-Adresse?
- Warum ist eine automatisch bezogene Konfiguration nicht automatisch fachlich korrekt?
- Welche Clientparameter und Abhängigkeiten übergibt LF3.9 an LF3.10?
Quellen & Einordnung
Curriculum-Grundlage:
KMK-Rahmenlehrplan für Fachinformatikerinnen und
Fachinformatiker,
Lernfeld 3.
Technische Grundlagendokumente:
- RFC 1122 – Requirements for Internet Hosts: Communication Layers
- RFC 2131 – Dynamic Host Configuration Protocol
- RFC 2132 – DHCP Options and BOOTP Vendor Extensions
- RFC 1034 – Domain Names: Concepts and Facilities
- RFC 1035 – Domain Names: Implementation and Specification
- RFC 9499 – DNS Terminology
- RFC 5737 – IPv4 Address Blocks Reserved for Documentation
IPv6-Abgrenzung:
- RFC 4861 – Neighbor Discovery for IP version 6
- RFC 9915 – Dynamic Host Configuration Protocol for IPv6
Versions- und Terminologiebezug:
RFC 9499 wird für aktuelle DNS-Terminologie verwendet.
RFC 1034 und RFC 1035 bilden weiterhin wesentliche
Grundlagen der DNS-Architektur und des Protokolls.
Für die kurze DHCPv6-Abgrenzung wird RFC 9915 verwendet;
RFC 9915 ersetzt RFC 8415.
Dokumentationsadressräume:
Die Beispiele verwenden ausschließlich Adressen aus
den nach RFC 5737 für Dokumentation vorgesehenen
IPv4-Bereichen,
insbesondere 192.0.2.0/24 und 198.51.100.0/24.
Clean Room:
Alle Erklärungen,
K-27-Fälle,
Tabellen,
Prüfschritte,
Aufgaben,
MC-Fragen,
Antwortoptionen und Lösungen wurden eigenständig
für SemaTrain formuliert.
RFC-Texte werden nicht kopiert.
Für LF3.9 ist keine zusätzliche Rechtsquelle erforderlich.
Curriculare Abgrenzung:
DHCP und DNS werden ausschließlich aus Client-Sicht
eingeordnet.
Die Bereitstellung und Administration entsprechender
Serverdienste,
Routerkonfiguration,
Routingprotokolle und NAT
sind nicht Gegenstand von LF3.9.