Anmelden

Netzwerkfehler systematisch analysieren

Lektion 5 von 6

Ports, Dienste und typische Fehlersymptome

Ordne TCP-/UDP-Endpunkte, Timeouts, Ablehnungen und Anwendungsantworten diagnostisch ein.

Lernziele

Nach Abschluss dieser Lektion kannst du:

  • Portnummern als Transportendpunkte erklären
  • IP-Adresse und Port unterscheiden
  • TCP und UDP konzeptionell unterscheiden
  • Listener, Prozess und Dienst einordnen
  • Connection Refused vorsichtig interpretieren
  • Timeout vorsichtig interpretieren
  • TCP-Erfolg von Anwendungszustand trennen
  • DNS-, Transport- und Anwendungsfehler unterscheiden
  • lokale Listener lesend untersuchen
  • einen bekannten TCP-Dienst sicher testen
  • Portkonventionen korrekt einordnen
  • die nächste Diagnoseschicht auswählen

IP-Adresse, Port und Transport

Die IP-Adresse adressiert eine Schnittstelle beziehungsweise einen Endpunkt im IP-Netz. Ein Port bezeichnet einen Kommunikationsendpunkt im TCP-/UDP-Kontext eines Hosts. Bei 192.168.10.20:443 ist 192.168.10.20 die IP und 443 der Port.

Ein Port identifiziert nicht in jeder Architektur dauerhaft genau ein Programm: Proxies, NAT, Multiplexing und andere Bindungsmodelle können dazwischenliegen. TCP bietet verbindungsorientierte, UDP datagrammorientierte Transportsemantik. Das macht UDP nicht „schlecht“ und TCP garantiert keinen Anwendungserfolg.

Portkonventionen sind Hinweise

53 UDP/TCP

DNS

67/68 UDP

DHCP

80 TCP

HTTP, häufig HTTP/1.x/2 unverschlüsselt

443 TCP

HTTPS, häufig HTTP/1.1/2 über TLS

443 UDP

HTTP/3 über QUIC, häufig

22 TCP

SSH

3389 TCP/UDP

RDP je nach Funktion/Nutzung

445 TCP

SMB, häufig

Dienste können anders konfiguriert sein; eine Portnummer beweist nicht, welches Anwendungsprotokoll tatsächlich läuft.

Listener und lokaler Endpunkt

Ein Serverprozess oder Dienst kann einen lokalen Transportendpunkt binden und dort lauschen, etwa 0.0.0.0:443 auf relevanten lokalen Interfaces oder 192.168.10.20:443 auf einer bestimmten Adresse. LISTENING belegt einen Listener – nicht die fachliche Gesundheit der Anwendung oder ihrer Backends.

A · lesend

netstat -ano

Windows: lokale/entfernte Adressen, Zustände und PID je nach Zeile.

A · lesend, optional

Get-NetTCPConnection

PowerShell: TCP-Endpunkte; nicht in jeder Minimalumgebung verfügbar.

A · lesend

ss -ltn

Linux: -l listening, -t TCP, -n numerisch. Prozessbesitz kann zusätzliche Rechte/Optionen brauchen.

A · lesend

Test-NetConnection server.firma.test -Port 443

PowerShell: bekannten, autorisierten TCP-Endpunkt testen. Erfolg belegt weder Zertifikat noch HTTP, Login oder Backend.

Bis zur HTTP-Schicht testen

A · lesend

curl -I https://server.firma.test/

Fordert mit HEAD-Verhalten Header an, soweit Server und Werkzeug dies sinnvoll unterstützen.

A · lesend

curl -i http://server.firma.test/

Zeigt HTTP-Header und Inhalt einer bekannten, autorisierten Ressource. Keine Zugangsdaten verwenden.

404 bedeutet Ressource nicht gefunden, 500 serverseitige Verarbeitung fehlgeschlagen, 502 Gateway/Proxy erhielt keine brauchbare Upstream-Antwort, 503 Dienst nicht verfügbar und 504 Upstream-Timeout. In allen Fällen fand HTTP-Kommunikation statt; dies sind keine reinen Netzwerkschichtfehler.

Vom Namen bis zur Anwendung

  1. Name

    DNS-Fehler

  2. IP

    Zieladresse

  3. Route

    Timeout möglich

  4. TCP/UDP-Endpunkt

    refused oder Timeout

  5. Dienst

    Listener/Prozess

  6. Anwendung/Backend

    HTTP 404/503

Eine spätere Antwort belegt, dass frühere Schichten ausreichend funktionierten – nicht, dass jede Komponente vollständig gesund ist.

Fehlersymptom ist nicht Grundursache

Namensauflösungsfehler

Keine erwartete IP-/Namensantwort

Nächster Bereich

DNS und Resolverpfad

Connection refused

TCP-Verbindung aktiv abgelehnt

Nächster Bereich

Endpunkt, Listener, Port oder ablehnende Policy

Timeout

Keine rechtzeitige erwartete Antwort

Nächster Bereich

Pfad, Drop, Host, Rückweg oder Auslastung

HTTP-Fehler

Anwendungsprotokoll antwortet mit Status

Nächster Bereich

Ressource, Anwendung oder Backend

Erwartete Funktion

Anwendung verhält sich wie vorgesehen

Nächster Bereich

Ende-zu-Ende-Test bestanden

Refused, Timeout und erfolgreicher TCP-Aufbau

Connection refused

Der Versuch erreichte einen Punkt, der die TCP-Verbindung aktiv ablehnen konnte. Untersuche falschen Port, fehlenden Listener, gestoppten Dienst, Bindung an eine andere Adresse oder eine ablehnende Policy. Das bedeutet weder „DNS kaputt“ noch zwingend „Server aus“.

Timeout

Innerhalb der Wartezeit kam kein erwarteter Verbindungs-/Antwortausgang. Drop/Filterung, Routing oder Rückweg, Hostausfall, Zwischenpfad, Überlastung und bei UDP fehlende Antwortsemantik bleiben möglich. Timeout beweist keine Firewall.

TCP erfolgreich, HTTP 503

IP-Pfad und TCP-Endpunkt funktionieren ausreichend. Jetzt sind Frontend-Dienst, Anwendung, Wartungs-/Lastzustand und Backend-Abhängigkeiten sinnvoll. Eine zufällige Änderung der Clientmaske wäre nicht begründet.

Dienste haben Abhängigkeiten

Ein realistischer Pfad lautet: Client → DNS → IP-Routing → TCP-Endpunkt → Frontend-Dienst → Backend. Ein Proxy kann auf 443 lauschen, während Datenbank oder Anwendung fehlen; der Client erhält dann möglicherweise 502, 503 oder 504. Das ist nicht automatisch ein Clientnetzfehler.

Wissenscheck

TCP erfolgreich, HTTP 503

DNS liefert 192.168.10.20, Test-NetConnection auf 443 ist erfolgreich, der Browser erhält 503 Service Unavailable. Welcher Bereich folgt?

Wissenscheck

TCP-Verbindung abgelehnt

DNS löst korrekt auf, aber TCP 443 meldet Connection refused. Was untersuchst du als Nächstes?

Wissenscheck

Name nicht aufgelöst

Für den beabsichtigten Server liegt keine Namensauflösung und keine dokumentierte Ziel-IP vor. Solltest du mit HTTP-Statuscodes beginnen?

Sichere Werkzeugwahl

DNS-Ergebnis
nslookup, optional dig oder getent
Bekannter Windows-TCP-Endpunkt
Test-NetConnection -Port
HTTP-Antwort
curl auf bekannte URL
Linux-Listener
ss -ltn
Windows-Endpunkte/PIDs
netstat -ano oder optional Get-NetTCPConnection

Typische Fehlvorstellungen

Falsch: „Port 443 beweist HTTPS.“
Korrektur: 443 ist eine Konvention; der tatsächliche Dienst muss geprüft werden.
Falsch: „LISTENING bedeutet Anwendung funktioniert.“
Korrektur: Ein Listener belegt weder fachliche Antwort noch Backendgesundheit.
Falsch: „TCP-Verbindung erfolgreich = Website komplett gesund.“
Korrektur: TLS, HTTP, Login, Anwendung und Backend bleiben offen.
Falsch: „Connection refused bedeutet DNS kaputt.“
Korrektur: Refused ist ein TCP-Endpunktsymptom nach erfolgter Zielbestimmung.
Falsch: „Timeout beweist Firewall.“
Korrektur: Mehrere Pfad-, Host-, Drop- und Lastursachen sind möglich.
Falsch: „HTTP 404 bedeutet Server nicht erreichbar.“
Korrektur: Der Server hat per HTTP geantwortet; Ressource oder Routing fehlen.
Falsch: „Ping erfolgreich bedeutet Port 443 offen.“
Korrektur: ICMP und TCP-Port sind getrennte Tests.
Falsch: „Firewall zum Testen einfach komplett deaktivieren.“
Korrektur: Das ist sicherheitsrelevant und ohne Evidenz nicht gerechtfertigt.

Befehlssicherheit

A · lesend / diagnostisch
Erforderlich sind nur bekannte Zieltests und Abfragen wie ipconfig /all, ip addr, ip route, nslookup, dig, getent, Test-NetConnection, netstat -ano, ss -ltn und curl.
B · zustandsändernd, nur konzeptionell
Lease Release/Renew, DNS-Flush, Adapterreset, Route oder Konfiguration ändern und Dienstneustart werden nicht ausgeführt.
C · privilegiert/administrativ, nur konzeptionell
DHCP-/DNS-Server, Relay, Firewall, Dienstbindung oder Serveranwendung ändern erfordert Befund, Freigabe und passende Zuständigkeit.

Nächste Lektion

Praxis: Netzwerkfehler vollständig analysieren

Zum Abschluss führst du die Schichten in einer Diagnose vom Benutzerbericht bis zur dokumentierten Hypothese zusammen.

Dein Lernstand

Lektion in Bearbeitung

Das Öffnen startet die Lektion. Als erledigt zählt sie erst nach deiner ausdrücklichen Bestätigung.