LF3.12 – Clients konfigurieren und in das Netzwerk einbinden

Durchführen beginnt nicht mit blindem Ändern

Vor jeder Änderung müssen mindestens drei Dinge eindeutig sein:

1. Zielgerät: Welcher Client wird bearbeitet?
2. Zielinterface: Welche Netzwerkschnittstelle ist für die Integration vorgesehen?
3. Zielzustand: Welche Werte beziehungsweise welcher Konfigurationsmodus wurden freigegeben?

Ausgangszustand und Zielzustand trennen

Die beiden Zustände werden nicht vermischt. Eine alte vorhandene Einstellung ist nicht automatisch die richtige Einstellung für den neuen Auftrag.

K-27: freigegebener Zielzustand

192.0.2.78/27, 192.0.2.65 und 198.51.100.53 werden hier ausschließlich als fiktive Dokumentationsadressen verwendet.

Den richtigen Client identifizieren

Vor einer Änderung wird die Gerätekennung mit dem Auftrag beziehungsweise der Arbeitsgrundlage abgeglichen.

Beispielsweise:

• Gerätekennung K27-CL-12,
• zugeordneter Arbeitsplatz,
• vorgesehene Netzwerkschnittstelle,
• freigegebener Zielzustand.

Die richtige Netzwerkschnittstelle auswählen

Ein Client kann mehrere Netzwerkschnittstellen besitzen, beispielsweise:

• kabelgebundene Ethernet-Schnittstelle,
• drahtlose Schnittstelle,
• virtuelle Schnittstellen,
• temporär angeschlossene Adapter.

LF3.12 verändert deshalb nicht irgendein Interface, sondern das im Zielzustand vorgesehene.

Im K-27-Fall ist dies:

Ausgangskonfiguration erfassen

Vor der Änderung wird der unmittelbar sichtbare clientseitige Zustand der vorgesehenen Schnittstelle festgehalten.

Mindestens:

• aktueller Konfigurationsmodus,
• vorhandene IPv4-Adresse,
• Präfix beziehungsweise Subnetzmaske,
• Standardgateway,
• DNS-Resolveradresse.

Dadurch bleibt nachvollziehbar, was tatsächlich geändert wurde.

Physische Clientanbindung herstellen

Im K-27-Fall ist ein kabelgebundener Clientzugang vorgesehen.

Die Durchführung umfasst auf Clientseite:

• vorgesehenen Arbeitsplatzanschluss verwenden,
• geeignetes Verbindungskabel verwenden,
• vorgesehene Client-Schnittstelle verbinden,
• offensichtliche Fehlzuordnungen vermeiden.

Die Konfiguration des Zugangsswitches ist nicht Bestandteil dieser Lernetappe.

OS-neutraler Konfigurationsworkflow

Betriebssysteme unterscheiden sich bei Menübezeichnungen, Dialogen und Bedienoberflächen.

Der fachliche Ablauf bleibt jedoch gleich:

1. Client und Interface identifizieren.
2. Ausgangszustand erfassen.
3. freigegebenen Zielzustand bereitlegen.
4. Konfigurationsmodus auswählen.
5. vorgesehene Parameter eintragen beziehungsweise beziehen.
6. Konfiguration anwenden.
7. Übernahmekontrolle am selben Interface durchführen.

Manuelle IPv4-Konfiguration

Ist laut Zielzustand eine manuelle Konfiguration vorgesehen, werden die Parameter gezielt am Client eingetragen.

Für K27-CL-12:

Präfix oder Subnetzmaske

Je nach Clientoberfläche kann die Netzgröße unterschiedlich dargestellt beziehungsweise eingegeben werden.

Im K-27-Fall sind:

Diese beiden Angaben beschreiben für das IPv4-Beispiel dieselbe Netzmaskierung.

Sie dürfen nicht als zwei voneinander unabhängige Planungswerte behandelt werden.

Standardgateway eintragen

Der freigegebene Zielzustand nennt:

LF3.12 trägt diesen geplanten Wert am Client ein.

Die Konfiguration des Routers, der diese Adresse verwendet, ist ausdrücklich nicht Gegenstand der Lernetappe.

DNS-Resolveradresse eintragen

Der Zielzustand nennt als DNS-Resolver:

LF3.12 trägt die Resolveradresse in der vorgesehenen Clientkonfiguration ein.

DHCPv4 als alternative Bezugsart

Nicht jeder Client erhält seine IPv4-Parameter manuell.

Für einen zweiten fiktiven Client K27-CL-13 sei als Zielzustand vorgegeben:

Dann werden am vorgesehenen Client-Interface keine frei erfundenen statischen Werte eingetragen.

Stattdessen wird die Schnittstelle auf den vorgesehenen automatischen IPv4-Parameterbezug eingestellt.

Die Bereitstellung, Konfiguration oder Änderung des DHCP-Servers ist nicht Bestandteil von LF3.12.

Manuell und DHCPv4 nicht vermischen

Konfiguration kontrolliert anwenden

Vor dem Anwenden wird der eingetragene Parametersatz noch einmal gegen den Zielzustand gelesen.

Für K27-CL-12:

• 192.0.2.78,
• /27 beziehungsweise 255.255.255.224,
• 192.0.2.65,
• 198.51.100.53.

Erst danach wird die Änderung übernommen.

Unmittelbare Übernahmekontrolle

Nach dem Anwenden wird kontrolliert, ob die vorgesehene Konfiguration am richtigen Interface tatsächlich übernommen wurde.

Die Übernahmekontrolle fragt:

• Betrachte ich weiterhin ETH-01?
• Ist der vorgesehene Konfigurationsmodus aktiv?
• Wird die geplante IPv4-Adresse angezeigt?
• Stimmt Präfix beziehungsweise Subnetzmaske?
• Stimmt das Standardgateway?
• Stimmt die DNS-Resolveradresse?

Beispiel für eine erkannte Abweichung

Der Zielzustand verlangt:

Nach dem Anwenden zeigt die lokale Clientkonfiguration jedoch:

Die Abweichung ist bereits durch den Soll-Ist-Vergleich der Konfigurationswerte sichtbar.

Sie wird korrigiert beziehungsweise geklärt, bevor der Client an LF3.13 übergeben wird.

Typische Eingabefehler

• falsches Client-Interface ausgewählt,
• Zahlendreher in der IPv4-Adresse,
• falsches Präfix beziehungsweise falsche Subnetzmaske,
• Gateway und DNS vertauscht,
• veralteten Ausgangswert übernommen,
• manuellen und automatischen Parameterbezug verwechselt,
• Änderung am falschen Client vorgenommen.

Diese Fehler können teilweise bereits bei der unmittelbaren Übernahmekontrolle erkannt werden, ohne die systematische Funktionsprüfung vorwegzunehmen.

Was gehört noch nicht zur Übernahmekontrolle?

LF3.12 führt bewusst keine systematische Funktionsprüfung der Netzwerkkommunikation durch.

Noch nicht Gegenstand sind:

• strukturierte Erreichbarkeitsprüfungen,
• systematische Gatewaytests,
• systematische DNS-Funktionstests,
• mehrstufige Fehlerdiagnose,
• Testmatrix,
• Testprotokoll,
• abschließende Funktionsbewertung.

Diese Tätigkeiten bilden den Kern von LF3.13.

Warum diese Grenze wichtig ist

Keine Infrastrukturadministration

LF3.12 konfiguriert den Client, nicht die zentrale Netzwerkinfrastruktur.

Nicht Bestandteil sind:

• Switch-CLI,
• Router-CLI,
• Routingkonfiguration,
• DHCP-Serveradministration,
• DHCP-Scopes oder Reservierungen,
• DHCP-Relay-Konfiguration,
• DNS-Zonenverwaltung,
• DNS-Serveradministration.

Produktive Systeme nicht ungeplant verändern

Die praktischen SemaTrain-Aufgaben verwenden fiktive beziehungsweise isolierte Übungsszenarien.

In realen betrieblichen Umgebungen gelten:

• betriebliche Freigaben,
• Änderungsprozesse,
• Dokumentationsvorgaben,
• zuständige Rollen und Verantwortlichkeiten.

K-27: sichere Durchführungsreihenfolge

1. Client K27-CL-12 eindeutig identifizieren.
2. Zielinterface ETH-01 bestätigen.
3. Ausgangskonfiguration erfassen.
4. vorgesehenen physischen Netzwerkanschluss herstellen.
5. manuelle IPv4-Konfiguration auswählen.
6. 192.0.2.78 eintragen.
7. /27 beziehungsweise 255.255.255.224 eintragen.
8. 192.0.2.65 als Standardgateway eintragen.
9. 198.51.100.53 als DNS-Resolveradresse eintragen.
10. Konfiguration anwenden.
11. lokal kontrollieren, ob alle Werte am richtigen Interface übernommen wurden.
12. Client für LF3.13 kennzeichnen: Konfiguration durchgeführt, systematische Funktionsprüfung noch offen.

Übergabestatus an LF3.13

PRAXISAUFGABE

Praktische Lernaufgabe

Für den fiktiven Client K27-CL-14 gilt folgender Zielzustand:

• Interface: ETH-01,
• manuelle IPv4-Konfiguration,
• IPv4-Adresse: 192.0.2.79,
• Präfix: /27,
• Subnetzmaske: 255.255.255.224,
• Standardgateway: 192.0.2.65,
• DNS-Resolver: 198.51.100.53.

Erstellen Sie einen OS-neutralen Durchführungsplan.

Der Plan muss enthalten:

1. Zielgerät identifizieren,
2. richtiges Interface bestimmen,
3. Ausgangszustand erfassen,
4. Zielwerte eintragen,
5. Änderung anwenden,
6. Übernahmekontrolle durchführen,
7. Übergabestatus für LF3.13 festhalten.

Führen Sie noch keine systematische Netzwerkfunktionsprüfung durch.

Praxisauftrag

Selbsttraining – keine Abgabe erforderlich.

Entwerfen Sie zwei vollständig fiktive Client-Konfigurationsfälle:

• einen Client mit manueller IPv4-Konfiguration,
• einen Client mit automatischem DHCPv4-Parameterbezug.

Dokumentieren Sie für beide:

• Gerätekennung,
• Zielinterface,
• Ausgangszustand,
• Zielzustand,
• physische Anbindung,
• Bezugsart,
• erforderliche clientseitige Konfigurationsschritte,
• unmittelbare Übernahmekontrolle,
• mögliche Eingabefehler,
• Übergabestatus an LF3.13.

Konfigurieren Sie keine Switches, Router, DHCP-Server oder DNS-Server.

Erstellen Sie noch kein Testprotokoll und führen Sie noch keine vollständige systematische Netzwerkfunktionsprüfung durch.

SELBSTKONTROLLE

Selbstkontrolle

• Ist der richtige Client eindeutig identifiziert?
• Bearbeite ich die richtige Netzwerkschnittstelle?
• Habe ich den Ausgangszustand vor der Änderung erfasst?
• Stammt jeder neue Wert aus einem freigegebenen Zielzustand?
• Unterscheide ich manuelle Konfiguration und DHCPv4?
• Trage ich IP-Adresse, Präfix beziehungsweise Maske, Gateway und DNS in die richtigen Felder ein?
• Kontrolliere ich nach der Übernahme dieselbe Schnittstelle?
• Vergleiche ich die übernommenen Werte mit dem Zielzustand?
• Vermeide ich ungeplante Änderungen an produktiver Infrastruktur?
• Habe ich Server- und Routeradministration offengelassen?
• Habe ich die systematische Funktionsprüfung für LF3.13 offengelassen?

REFLEXION

Reflexion

• Warum ist der Zielzustand vor der Änderung wichtiger als eine vorhandene Alt-Konfiguration?
• Warum muss das richtige Interface eindeutig bestimmt werden?
• Warum ist DHCPv4-Nutzung am Client etwas anderes als DHCP-Serveradministration?
• Warum sollte der Ausgangszustand dokumentiert werden?
• Warum genügt die Übernahmekontrolle noch nicht für eine Funktionsabnahme?
• Warum trennt die Handlungskette Durchführen und systematisches Prüfen?
• Welchen Zustand übergibt LF3.12 an LF3.13?