Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Netzwerke und Systemintegration – Verbindungsfehler systematisch eingrenzen

QR-Code

Netzwerke und Systemintegration – Verbindungsfehler systematisch eingrenzen

Einleitung

Zielgruppe: Ausbildung Fachinformatik/Systemintegration. Dauer: 75–90 Minuten, fünf kurze Lerneinheiten und zwei lokale Labore. Leitfrage: Wo bricht die Verbindung ab – bei Physik, Adresse, Route, Namensauflösung oder Dienst?

Sicherheitsregel: Arbeite ausschließlich in einer eigenen, isolierten Übungsumgebung oder mit ausdrücklicher Freigabe. Die Adressen 192.0.2.0/24 und 198.51.100.0/24 sind Dokumentationsnetze; service.test ist ein fiktiver Name. Dorthin werden keine Pakete gesendet. Die Python-Labore simulieren Daten beziehungsweise verwenden ausschließlich 127.0.0.1. Keine fremden Netze, Produktivsysteme, Kundendaten oder Zugangsdaten verwenden.

Orientierung: Das OSI-Modell hilft beim schrittweisen Eingrenzen, ohne alle Schichten einzeln abprüfen zu müssen.

Ausbildungsfall: Arbeitsplatz W-07

Im Übungsszenario meldet W-07: „Die interne Testanwendung öffnet sich nicht.“ Der Link ist aktiv. Der DNS-Name und die Netze sind ausschließlich erfunden.

W-07                 Switch          Gateway            Testdienst
192.0.2.20/27  ------ [S] -------- 192.0.2.65 ------ 198.51.100.10
                                         Name: service.test

Beobachtung	Ist	Soll im simulierten Ausbildungsfall
Adapterlink	aktiv	aktiv
IPv4-Adresse	192.0.2.20	192.0.2.20
Präfix	/27	/24
Standardgateway	192.0.2.65	192.0.2.65
Ziel	service.test / 198.51.100.10	Testdienst erreichbar

Dein Auftrag: Formuliere eine Hypothese, prüfe zuerst das günstigste passende Indiz und begründe Deine Diagnose. Ändere keine echte Netzwerkkonfiguration.

Lerneinheit 1 – Physik und Link (10 Minuten)

Prüffrage: Besteht überhaupt ein Link? Sichtprüfung von Kabel, Steckverbinder, Port, Adapterstatus und Link-LED. Eine LED ist ein Indiz, kein Beweis für fehlerfreie Übertragung.

Medienimpuls: Erkläre, warum ein gestecktes Kabel allein die Verbindung noch nicht garantiert.

In einer Sternstruktur kann der Fehler an genau einer Anschlussstrecke liegen.

Mini-Aufgabe (Basis): Ein Adapter meldet „Medien getrennt“. Wo prüfst Du zuerst? Feedback: Physik/Link; ohne Link liefern Tests höherer Ebenen keine sichere Ursachenklärung.

Lerneinheit 2 – Adresse und Netz (10 Minuten)

Prüffrage: Passen IP-Adresse, Netzmaske und Standardgateway zusammen? Bei 192.0.2.20/27 umfasst das lokale Netz 192.0.2.0 bis 192.0.2.31. Das Gateway 192.0.2.65 liegt außerhalb. Mit dem vorgesehenen /24 wäre es im lokalen Netz.

Computerphile: IPv4-Adressen (englisch).

PowerCert Animated Videos: Subnetzmasken (englisch).

Mini-Aufgabe (Basis): Warum tauschst Du im Fall W-07 nicht sofort das Kabel? Feedback: Der Link ist aktiv; die nachweislich widersprüchliche Adresskonfiguration ist die stärkere Hypothese.

Lerneinheit 3 – Route und Weiterleitung (10 Minuten)

Prüffrage: Ist das Ziel lokal oder braucht es einen Router? Eine Routingtabelle wählt die spezifischste passende Route; sonst kommt bei vorhandener Standardroute das Gateway infrage. Kein passender Weg bedeutet: Routing prüfen, nicht DNS raten.

PowerCert Animated Videos: Traceroute (englisch); nur ansehen, nicht gegen fremde Ziele ausführen.

PowerCert Animated Videos: Ping als Diagnosewerkzeug (englisch).

Wichtige Grenze: Ein ausbleibender Ping kann auch durch ICMP-Filter entstehen und beweist nicht, dass ein Webdienst ausgefallen ist.

Lerneinheit 4 – DNS, Port und Dienst (10 Minuten)

Prüffrage: Funktioniert die IP-Verbindung, aber nicht der Name? Dann untersuche DNS. Ist der Name aufgelöst, prüfe den vorgesehenen TCP-Port und anschließend die Antwort der Anwendung. Ein offener TCP-Port allein beweist noch keine fehlerfreie Anwendung.

Computerphile: DNS (englisch).

TCP-Verbindungsaufbau und HTTP-Antwort sind unterschiedliche Prüfschritte.

Lerneinheit 5 – Messbild statt Bauchgefühl (10 Minuten)

Simulierte Diagnosematrix: OK = beobachtet, X = Abweichung, – = noch nicht geprüft
Fehlerfall	Physik	Adresse	Route	DNS	Dienst
Kabel gelöst	X	–	–	–	–
Präfix falsch	OK	X	–	–	–
Route fehlt	OK	OK	X	–	–
Name fehlerhaft	OK	OK	OK	X	–
Dienst gestoppt	OK	OK	OK	OK	X
Alles funktioniert	OK	OK	OK	OK	OK

Diagnoseprotokoll: Symptom → Messung → Hypothese → lokaler Gegencheck → Schlussfolgerung → dokumentierte Maßnahme. Im Betrieb wäre jede Änderung genehmigungspflichtig.

Gestufte Hilfen zum Ausbildungsfall

Hilfe 1 – Leitfrage: Liegt die Gateway-Adresse im Netz des Clients?

Hilfe 2 – Rechenhilfe: /27 bedeutet 32 Adressen je Netzblock. Für 192.0.2.20 liegt der Block bei 192.0.2.0–192.0.2.31.

Hilfe 3 – begründete Auflösung: 192.0.2.65 ist außerhalb dieses /27-Netzes. Die vorgegebene Soll-Konfiguration nutzt /24; dann gehören Client und Gateway zum selben lokalen Subnetz. Nur in der Simulation korrigieren und erneut bewerten. Weitere Fehler wären damit noch nicht grundsätzlich ausgeschlossen.

Isoliertes Labor A – Diagnose-Simulator

Start: Kopiere das Beispiel in diagnose.py und führe es mit python3 diagnose.py beziehungsweise unter Windows mit py diagnose.py aus. Python 3 genügt. Vollständig offline: Keine Netzwerkschnittstelle wird abgefragt und kein Paket gesendet.

from ipaddress import ip_interface, ip_address

faelle = {
    "1": ("Link aus; Adapter meldet 'getrennt'.", "Physik",
          "Zuerst Kabel, Port und Adapter prüfen."),
    "2": ("Link an; Host 192.0.2.20/27, Gateway 192.0.2.65.",
          "Adresse", "Das Gateway liegt nicht im lokalen /27-Netz."),
    "3": ("Link und Adresse OK; Zielroute fehlt.", "Route",
          "Ein passender Weiterleitungsweg fehlt."),
    "4": ("IP-Ziel simuliert erreichbar; service.test nicht auflösbar.",
          "DNS", "IP geht, Namensauflösung ist zu prüfen."),
    "5": ("Name aufgelöst; Ziel erreichbar; TCP-Dienst antwortet nicht.",
          "Dienst", "Erreichbarkeit ersetzt keinen Diensttest."),
    "6": ("Link, Adresse, Route, DNS, HTTP-Status 200 OK.",
          "OK", "Alle simulierten Prüfungen bestehen.")
}
print("OFFLINE-LABOR: keine echten Netzwerkzugriffe")
wahl = input("Fall 1-6 auswählen [2]: ").strip() or "2"
if wahl not in faelle:
    raise SystemExit("Bitte eine Zahl von 1 bis 6 wählen.")
messung, ursache, grund = faelle[wahl]
print("Befund:", messung)
if wahl == "2":
    netz = ip_interface("192.0.2.20/27").network
    print("Gateway im lokalen Netz?",
          ip_address("192.0.2.65") in netz)
phasen = ["Physik", "Adresse", "Route", "DNS", "Dienst", "OK"]
for nr, phase in enumerate(phasen, 1):
    print(nr, phase)
tipp = input("Erster Eingrenzungsschritt [1-6]: ").strip()
richtig = tipp.isdigit() and 1 <= int(tipp) <= 6 \
    and phasen[int(tipp)-1] == ursache
print("RICHTIG:" if richtig else "PRÜFE ERNEUT:", grund)

Beispielausgabe für Fall 2: Gateway im lokalen Netz? False; richtige Auswahl 2 Adresse. Feedback: Die Adressprüfung liefert einen konkreten Widerspruch; ein fehlender Ping wäre dagegen mehrdeutig.

Isoliertes Labor B – Lokaler HTTP-Dienst

Start: Speichere als localhost_dienst.py und starte lokal mit Python 3. Der Server bindet ausschließlich 127.0.0.1 auf einen vom Betriebssystem vergebenen freien Port; keine fremden Adressen, keine Dateiübertragung.

from http.server import BaseHTTPRequestHandler, HTTPServer
from http.client import HTTPConnection
from threading import Thread
from socket import socket, AF_INET, SOCK_STREAM

class Demo(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path != "/status":
            self.send_error(404)
            return
        daten = b"OK: lokaler Testdienst"
        self.send_response(200)
        self.send_header("Content-Type", "text/plain; charset=utf-8")
        self.send_header("Content-Length", str(len(daten)))
        self.end_headers()
        self.wfile.write(daten)

    def log_message(self, *args):
        pass

server = HTTPServer(("127.0.0.1", 0), Demo)
port = server.server_port
thread = Thread(target=server.serve_forever, daemon=True)
thread.start()
verbindung = HTTPConnection("127.0.0.1", port, timeout=2)
try:
    verbindung.request("GET", "/status")
    antwort = verbindung.getresponse()
    print("Dienst aktiv:", antwort.status, antwort.read().decode())
finally:
    verbindung.close()
    server.shutdown()
    server.server_close()
    thread.join(timeout=2)

with socket(AF_INET, SOCK_STREAM) as probe:
    probe.settimeout(1)
    status = probe.connect_ex(("127.0.0.1", port))
    print("Nach Stopp:",
          "Port nicht erreichbar" if status else "noch erreichbar")

Erwartung: Dienst aktiv: 200 OK: lokaler Testdienst und danach Port nicht erreichbar. Begründetes Feedback: HTTP 200 belegt hier die Antwort dieses lokalen Endpunkts. Nach dem Stopp scheitert die TCP-Verbindung; daraus folgt keine Aussage über andere Systeme.

Basis-, Anwendungs- und Transferaufgaben

Basis

Netzwerkadapter: Ordne „Link aus“ einer Diagnosephase zu. Feedback: Physik ist zuerst zu prüfen, weil der Adapter keinen Link meldet.
Subnetzmaske: Berechne den Netzblock von 192.0.2.20/27. Feedback: 192.0.2.0–192.0.2.31; die Blockgröße beträgt 32.
DNS: Unterscheide IP-Ziel und Namen. Feedback: Eine erfolgreiche IP-Verbindung bei fehlendem Namen legt eine Prüfung der Namensauflösung nahe, beweist den Grund aber noch nicht.

Anwendung

Fehleranalyse: Bearbeite Fall 2 im Simulator und dokumentiere Hypothese und Messbeleg. Feedback: Die Gateway-Adresse .65 ist außerhalb des /27-Netzes.
Routing: Bearbeite Fall 3 und begründe die nächste Prüfung. Feedback: Eine fehlende Route erklärt, warum ein fremdes Zielnetz nicht erreicht wird.
HTTP: Führe Labor B aus und erkläre den Unterschied zwischen TCP-Erreichbarkeit und HTTP-Antwort. Feedback: Erst die HTTP-Antwort prüft den konkreten Anwendungsendpunkt.

Transfer

Systemintegration: Entwirf für einen fiktiven zweiten Client einen Prüfplan mit fünf Stationen. Feedback: Trenne Beobachtung, Hypothese und Gegenprobe; vermeide Sprünge zum Dienst.
Fehlersuche: Erkläre, warum ein Ping-Timeout trotz funktionierendem Dienst möglich ist. Feedback: ICMP kann gefiltert sein; prüfe das freigegebene Zielprotokoll im Labor.
IT-Dokumentation: Schreibe einen Änderungsantrag für die simulierte Präfixkorrektur. Feedback: Sollwert, Beleg, Risiko, Freigabe und Rückfallplan gehören hinein.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was prüfst Du bei einem fehlenden Link zuerst? (Kabel und Adapterstatus) (!DNS Cache) (!HTTP Status) (!Routingprotokoll)

Welche Diagnose passt zu 192.0.2.20/27 mit Gateway 192.0.2.65? (Gateway außerhalb des lokalen Subnetzes) (!Kabeldefekt ist nachgewiesen) (!Webdienst wurde abgeschaltet) (!DNS Eintrag wurde gelöscht)

Welcher Netzblock gehört zu 192.0.2.20/27? (192.0.2.0 bis 192.0.2.31) (!192.0.2.32 bis 192.0.2.63) (!192.0.2.64 bis 192.0.2.95) (!192.0.2.128 bis 192.0.2.159)

Wann wird typischerweise das Standardgateway benötigt? (Bei Zielen außerhalb des lokalen Netzes) (!Bei jeder lokalen Datei) (!Nur bei defektem Kabel) (!Nur zur Vergabe einer MAC Adresse)

Weshalb ist Ping allein kein ausreichender Diensttest? (Weil ICMP und Anwendungsprotokolle verschieden sind) (!Weil Ping immer DNS verändert) (!Weil HTTP niemals TCP verwendet) (!Weil Ping ein Kabel automatisch repariert)

Die Ziel IP ist im Labor erreichbar aber der Name nicht. Was prüfst Du? (Namensauflösung) (!Steckerfarbe) (!Bildschirmauflösung) (!Tastaturlayout)

Was bedeutet ein erfolgreich aufgebauter TCP Kontakt? (Der TCP Verbindungsaufbau war möglich) (!Der gesamte Webdienst arbeitet fehlerfrei) (!Alle Webseiteninhalte sind richtig) (!Die DNS Konfiguration ist sicher korrekt)

Was zeigt HTTP Status 200 im lokalen Labor? (Der Testendpunkt hat erfolgreich geantwortet) (!Der gesamte Netzwerkverbund ist fehlerfrei) (!Alle künftigen Anfragen werden gelingen) (!Es wurde ein externer Server erreicht)

Welcher Adressbereich ist für IPv4 Dokumentation reserviert? (192.0.2.0/24) (!8.8.8.0/24) (!1.1.1.0/24) (!9.9.9.0/24)

Welche Testumgebung ist hier zulässig? (Isoliertes lokales Labor mit fiktiven Daten) (!Ungefragter Scan eines fremden Netzes) (!Test eines Kundensystems ohne Freigabe) (!Weitergabe echter Zugangsdaten an einen Dienst)

Begründungscheck zum Quiz: Die Reihenfolge folgt der ersten belastbaren Abweichung: Link → Adressbereich → Route → Namensauflösung → konkreter Dienst. Ping ist nur ein ICMP-Indiz, HTTP 200 nur die Antwort eines geprüften Endpunkts. Dokumentationsadressen dürfen im Beispiel stehen, werden aber nicht als Testziele kontaktiert.

Memory

Link-LED	Indiz für eine physische Verbindung
Netzmaske	Kennzeichnet den lokalen Netzanteil
Standardgateway	Nächster Router für fremde Netze
Routingtabelle	Auswahl eines Weiterleitungswegs
DNS-Resolver	Ermittelt Adressen zu Namen
TCP-Port	Endpunkt eines Transportdienstes
HTTP-Status	Antwortcode einer Webanfrage

Drag and Drop

Ordne die passenden Prüfphasen zu.	Beobachtung
Physik	Kein Link am Adapter
Adresse	Gateway außerhalb des lokalen Subnetzes
Route	Kein Eintrag für das Zielnetz
DNS	Name nicht auflösbar
Dienst	HTTP-Endpunkt antwortet nicht

Kreuzworträtsel

Ethernet	Wie heißt die verbreitete kabelgebundene LAN-Technik?
Netzmaske	Was trennt bei IPv4 den Netz- vom Hostanteil?
Gateway	Wohin sendet ein Client Pakete für andere Netze?
Routing	Wie heißt die Auswahl des Weiterleitungswegs?
Resolver	Welche Komponente fragt Namen im DNS ab?
Dienst	Was muss zusätzlich zum Netzwerkpfad funktionieren?

LearningApps

Lückentext

Eine ausbleibende Linkanzeige führt zuerst zur Prüfung der

am Arbeitsplatz.

Die IPv4-Adresse wird zusammen mit der

ausgewertet.

Bei 192.0.2.20/27 gehört die Hostadresse zum Netz

im Beispiel.

Für andere Netze nutzt der Client ein

als nächsten Router.

Die passende Weiterleitung steht in der

des Systems.

Ein Rechnername benötigt häufig die

durch DNS.

Ein erfolgreicher Ping verwendet das Protokoll

für Echo-Nachrichten.

Ein TCP-Verbindungsaufbau allein beweist keinen funktionierenden

am Ziel.

Der lokale HTTP-Test liefert als Erfolgsantwort den Status

zurück.

Alle aktiven Versuche bleiben auf die Adresse

des eigenen Computers begrenzt.

Offene Aufgaben

Leicht

Ethernet: Zeichne eine sichere Sichtprüfliste für Kabel, Adapter und Linkstatus.
OSI-Modell: Erstelle vier Piktogramme zu Physik, Adresse, Route und Dienst.
IP-Adresse: Male die Netzgrenzen des fiktiven /27-Falls auf einem Zahlenstrahl.
Dokumentation: Formuliere drei sachliche Messnotizen ohne Vermutungen.

Standard

Fehleranalyse: Erstelle ein kurzes Screencast-Drehbuch mit fiktiven Messwerten aus Labor A.
DNS: Vergleiche anhand einer selbst gezeichneten Skizze IP-Zugriff und Namenszugriff.
Netzwerkdiagnose: Führe beide lokalen Python-Labore aus und protokolliere die Ergebnisse.
IT-Support: Übe ein Rollenspiel „Auszubildende/r und Lehrkraft“ zur Fehleraufnahme ohne Kundendaten.

Schwer

Python: Erweitere den Offline-Simulator um einen zweiten fiktiven Adressfehler.
Systemintegration: Entwickle eine Entscheidungsgrafik mit alternativen Diagnosewegen und Rückfragen.
IT-Sicherheit: Verfasse ein Freigabeformular für Tests in einem ausdrücklich autorisierten Labornetz.
Qualitätssicherung: Erstelle einen lokalen Prüfbericht mit Ursache, Gegenprobe, Wiederholungstest und Rollback-Plan.

Lernkontrolle

Ursachenanalyse: Zwei Clients haben identische Symptome, aber bei einem fehlt der Link und beim anderen liegt das Gateway außerhalb des Subnetzes. Begründe unterschiedliche Prüfreihenfolgen.
Netzwerkdiagnose: Bewerte den Schluss „Ping scheitert, also ist der Webserver aus“ und entwerfe eine sicherere Gegenprobe im lokalen Labor.
Routing: Erkläre, warum die Korrektur des Clientpräfixes in W-07 den Gateway-Zugriff plausibel macht, aber noch keinen HTTP-Erfolg garantiert.
DNS: Entwickle zwei konkurrierende Hypothesen, wenn eine IP-Verbindung funktioniert, ein Name aber scheitert, und beschreibe je einen Offline-Nachweis.
TCP: Interpretiere den Unterschied zwischen „TCP-Verbindung möglich“, „HTTP 200“ und „inhaltlich korrekte Anwendungsantwort“.
Datenschutz: Überarbeite einen unsicheren Testplan so, dass ausschließlich lokale Adressen und fiktive Daten verwendet werden.

Bewertung: Volle Leistung erfordert für jede Lösung Beobachtung, technische Begründung, alternative Ursache und sichere Gegenprobe; reine Fachwortlisten reichen nicht.

Lernnachweis

Diagnoseprotokoll: Abgabe eines fiktiven Fehlerprotokolls mit Symptom, Soll/Ist, Hypothese und Messbeleg.
Netzplanung: Korrekte Berechnung von Netzblock und Gateway-Lage bei W-07.
Python: Dokumentierte Ausgaben beider lokalen Labore und kurze Interpretation.
Transfer: Begründete Unterscheidung von physischem, logischem, Routing-, DNS- und Dienstfehler.
IT-Sicherheit: Nachweis, dass keine fremden Ziele, Zugangsdaten oder Kundendaten verwendet wurden.

Fachquellen und Medienrechte

Geprüfte Fachquellen: RFC 5737: IPv4-Dokumentationsnetze; RFC 6761: besondere Domainnamen; RFC 792: ICMP; Microsoft Learn: TCP/IP-Fehlersuche. Die Abbildungen sind frei lizenzierte Wikimedia-Commons-Dateien; die Urheberangaben und Lizenzbedingungen stehen zusätzlich auf den verlinkten Dateiseiten.

Mediennachweis	Urheberangabe	Lizenz laut Commons
ISO OSI-Modell.svg	Michael von Brandenburg	CC BY-SA 4.0
RJ45-Stecker-Netzwerk.jpg	Uwe Schwöbel	CC BY-SA 3.0
U-UTP twisted pair cable shielding.svg	Age Bosma	CC BY-SA 4.0
NetzwerkTopologien.svg	Foobaz, Parzi, Predatorix	CC BY-SA 4.0
IP-Paket Routing über Netzwerke.svg	Tango-Projekt, George Shuklin u. a.	CC BY-SA 3.0
Dns-abfrage.svg	Hank van Helvete	CC BY-SA 2.5
TCP Three-Way Handshake.svg	Fleshgrinder	gemeinfrei

Videos: Computerphile und PowerCert Animated Videos, verifizierte YouTube-Originalseiten; die Einbettung bedeutet keine freie Nachnutzungslizenz. Externe Videos und LearningApps können beim Öffnen Browserdaten an die jeweiligen Plattformen übertragen. Sie sind freiwillig; für die lokalen Labore ist keine externe Plattform erforderlich. Keine fiktiven Laborwerte oder personenbezogenen Daten in externe Dienste eingeben.