Linux-Tutorial / Netzwerkverbindung Schritt für Schritt diagnostizieren

Diagnostizieren Sie die Linux-Konnektivität, indem Sie Schnittstellen und Adressen, Routen, Namensauflösung, Transportverbindungen und Anwendungsantworten in dieser Reihenfolge überprüfen. Ein einzelnes Ping-Ergebnis zeigt nicht, ob ein gesamtes Netzwerk oder Webdienst funktioniert.

Für Adressen und Standardrouten siehe IP-Adressen, DNS und Ports. Bei einem reinen SSH-Fehler überprüfen Sie auch den Host, den Port und die Schlüssel in SSH und Dateitransfer.

Systemkonfigurationsübungen verwenden eine herkömmliche Ubuntu 26.04 LTS oder Rocky Linux 9 VM als Referenzumgebung. Container, WSL und andere Versionen können sich in Dienst- und Paketkonfiguration unterscheiden. Bereiten Sie die Konsolenwiederherstellung vor und zeichnen Sie Ihre Versionen mit der virtuellen Maschinen-Einrichtungslektion auf.

Notieren Sie den Umfang, bevor Sie Änderungen vornehmen

Notieren Sie die Quellmaschine, den Zielnamen, den Port, die Startzeit und den genauen Fehler. Vergleichen Sie eine Site mit mehreren Sites, einen Client mit einem anderen und IPv4 mit IPv6, wo relevant. Beachten Sie VPN- und Proxy-Unterschiede sowie jüngste Änderungen. Bevor Sie das Netzwerk auf einem Remote-Server neu starten, stellen Sie Zugriff auf die Konsole oder einen anderen Verwaltungspfad sicher.

Überprüfen Sie Schnittstellen, Adressen und Routen

ip -brief link
ip -brief address
ip route
ip -6 route

Administrative UP-Status beweist nicht die Erreichbarkeit des Ziels. Untersuchen Sie Verbindungsinformationen wie LOWER_UP, die erwarteten Adressen und die zutreffende Route. In einer VM prüfen Sie, dass die virtuelle Netzwerkkarte verbunden ist und dass NAT- oder bridged-Netzwerk den Plan entspricht. Gehen Sie nicht davon aus, dass die Schnittstelle eth0 heißt.

Nach der Auflösung des Ziels zeigt ip route get ACTUAL_IPV4_ADDRESS das ausgewählte Interface, den nächsten Hop und die Quelladresse an. „Netzwerk ist nicht erreichbar“ deutet eher auf Routing als auf DNS hin. Eine ausgewählte Route beweist nicht, dass der nächste Hop oder das Ziel antwortet.

Ping als Erreichbarkeitssignal einordnen

ping -c 3 127.0.0.1
ping -c 3 example.com

Der erste Befehl testet einen Loopback-ICMP-Echo; der zweite löst einen Namen auf und sendet Echo-Anfragen an dieses Ziel. ICMP kann gefiltert werden, während der Webzugriff weiterhin funktioniert. Umgekehrt validiert eine Antwort keinen Webport, kein Zertifikat und keine HTTP-Antwort. Verwenden Sie eine geringe Anzahl von Anfragen an ein genehmigtes Laborziel.

Namensauflösung und Verbindungsaufbau getrennt prüfen

getent ahosts example.com
curl -I -v --connect-timeout 5 --max-time 15 https://example.com/
printf "exit=%s\n" "$?"

Wenn getent keine Adresse zurückgibt, überprüfen Sie die Namensdienstkonfiguration. Die ausführliche Ausgabe von Curl trennt die Adressauswahl, Verbindung, TLS und die Verarbeitung der Antwort. Exit-Codes beinhalten häufig 6 für Namensauflösungsfehler, 7 für Verbindungsfehler, 28 für Zeitüberschreitung und 60 für Zertifikatsvalidierungsfehler. Das Deaktivieren der Zertifikatsprüfung mit -k ist keine Reparatur.

Standardmäßig kann curl erfolgreich beenden, nachdem eine HTTP-404- oder 500-Antwort übertragen wurde. Verwenden Sie --fail-with-body in einer unterstützten Version oder --fail, wenn HTTP-Fehler einen Fehlerstatus erzeugen sollen. Lesen Sie sowohl den HTTP-Status als auch den Prozess-Exit-Status. Redigieren Sie Cookies, Header und private Adressen, bevor Sie die ausführliche Ausgabe teilen.

Überprüfen Sie die Listening-Adresse auf dem Server

ss -lnt
ss -lnu
sudo ss -lntp

Ein Listener auf 127.0.0.1:8080 akzeptiert direkte Verbindungen nur lokal. 0.0.0.0:8080 deckt IPv4-Schnittstellen ab; ob [::]:8080 ebenfalls IPv4 behandelt, hängt von den Socket- und Systemeinstellungen ab. Prozessdetails können Berechtigungen erfordern. Ein gebundener UDP-Socket ist nicht gleichbedeutend mit einem validierten Anfrage-Antwort-Austausch.

Führen Sie eine Änderung durch, die durch die Beweise unterstützt wird

Notieren Sie die ursprüngliche Einstellung, ändern Sie einen Punkt und wiederholen Sie denselben Test vom selben Client zum selben Ziel. Stellen Sie eine unwirksame Änderung wieder her, bevor Sie eine andere Hypothese testen. Dies bewahrt Beweise und hilft, die Erstellung eines zweiten Fehlers zu vermeiden.

Um einen HTTP-Fehler ohne eine externe Website zu unterscheiden, stellen Sie sicher, dass python3 und curl in der Übungs-VM installiert sind und installieren Sie sie bei Bedarf über den Paketmanager. Führen Sie den folgenden Server in einem Terminal aus. Wenn der Port 18080 belegt ist, wählen Sie einen anderen freien Port und ändern Sie ihn in beiden Befehlen.

lab=$(mktemp -d "$HOME/linux-http-check.XXXXXX") &&
python3 -m http.server 18080 --bind 127.0.0.1 --directory "$lab"

Nachdem der Server gestartet ist, führen Sie dies in einem anderen Terminal in derselben VM aus. Erwarten Sie HTTP 404 und den Curl-Status 22: eine TCP-Verbindung und eine HTTP-Antwort wurden empfangen, aber die angeforderte Datei fehlt. Stoppen Sie den Server mit Strg+C und wiederholen Sie den Vorgang. Ohne Listener meldet Curl normalerweise einen Verbindungsfehler (7); eine Umgebung, die bis zum Verbindungs-Timeout wartet, kann stattdessen 28 melden. Lesen Sie den Status sofort und prüfen Sie, dass kein anderer Server den Port übernommen hat.

curl --fail --show-error --connect-timeout 2 --max-time 5 http://127.0.0.1:18080/missing-file
printf "exit=%s\n" "$?"

Offizielle Referenzen

• Offizielle curl-Optionen und Rückgabecodes
• Kernel-Netzwerkkonfigurationsreferenz