2.3 Linux-Netzwerkbefehle

Zunächst muss geklärt werden, welche Distribution, welcher Kernel und welche Netzwerkwerkzeuge vorhanden sind.

Typische Paketnamen

Paketnamen unterscheiden sich zwischen Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, SUSE, Arch Linux und anderen Distributionen.

ip link zeigt Netzwerkschnittstellen unabhängig davon, ob bereits eine IP-Adresse konfiguriert wurde.

enp1s0 ist nur ein Beispiel. Der tatsächliche Name kann beispielsweise eth0, ens18, eno1, enp3s0, wlan0 oder wlp2s0 lauten.

Wichtige Angaben von ip link

Typische Fehlerbilder

Wichtige Angaben

Prüfpunkte

• Passt die IP-Adresse zum vorgesehenen Netz?
• Ist die Präfixlänge korrekt?
• Ist die Adresse an der richtigen Schnittstelle gebunden?
• Existieren unerwartete zusätzliche Adressen?
• Wird eine dynamische Adresse erwartet?
• Ist eine IPv6-Adresse noch tentative oder bereits deprecated?
• Befindet sich eine IPv4-Adresse im Bereich 169.254.0.0/16?
• Existiert nur eine Loopback-Adresse?

Eine Adresse aus 169.254.0.0/16 kann darauf hinweisen, dass keine reguläre IPv4-Konfiguration beziehungsweise keine erfolgreiche DHCP-Zuweisung vorhanden ist.

Wichtige Angaben

Beispielausgabe

default via 192.0.2.1 dev enp1s0 proto dhcp src 192.0.2.10 metric 100
192.0.2.0/24 dev enp1s0 proto kernel scope link src 192.0.2.10 metric 100

Interpretation

• Das Standardgateway ist 192.0.2.1.
• Die Schnittstelle enp1s0 wird verwendet.
• Die bevorzugte Quelladresse ist 192.0.2.10.
• Das Netz 192.0.2.0/24 ist direkt angeschlossen.
• Bei mehreren Routen können Präfixlänge, Policy-Regeln und Metriken die Auswahl beeinflussen.

Typische Fehlerbilder

• Keine Standardroute vorhanden.
• Standardroute verwendet die falsche Schnittstelle.
• VPN- oder Tunnelroute überschreibt den erwarteten Weg.
• Falsche Quelladresse wird ausgewählt.
• Eine spezifischere Route überschreibt die Standardroute.
• Policy Routing verwendet eine andere Routingtabelle.
• Mehrere Standardrouten führen zu einem unerwarteten Netzwerkweg.

ip neigh zeigt IPv4-ARP- und IPv6-Nachbareinträge.

Wichtige Zustände

Fehlerhinweise

• INCOMPLETE oder FAILED kann auf ein falsches VLAN, eine falsche Netzmaske, einen nicht erreichbaren Nachbarn oder ein Layer-2-Problem hinweisen.
• Unterschiedliche MAC-Adressen für dieselbe IP-Adresse können auf doppelte IP-Adressen, Hochverfügbarkeit oder einen Sicherheitsvorfall hinweisen.
• Ein fehlender Eintrag ist nicht automatisch ein Fehler. Das Ziel wurde möglicherweise noch nicht angesprochen oder liegt außerhalb des lokalen Netzes.

Wichtige Ergebnisse

Interpretation

Ein fehlgeschlagener Ping beweist nicht, dass ein Ziel vollständig unerreichbar ist. ICMP kann blockiert sein, während ein TCP-Dienst weiterhin funktioniert.

Unterschiede

Wichtige Hinweise zur Auswertung

• Ein einzelner nicht antwortender Hop beweist keinen Fehler.
• Router können Diagnosepakete begrenzen oder ignorieren und trotzdem Nutzdaten weiterleiten.
• Paketverlust ist besonders relevant, wenn er ab einem Hop beginnt und auch an allen folgenden Hops einschließlich des Ziels sichtbar bleibt.
• Unterschiedliche Pfade können durch Load Balancing entstehen.
• Ein erfolgreicher letzter Hop ist wichtiger als einzelne Sterne in der Mitte des Pfades.
• ICMP-, UDP- und TCP-Traceroute können unterschiedliche Ergebnisse liefern.

Welche DNS-Werkzeuge funktionieren, hängt vom verwendeten Resolver und den installierten Paketen ab.

Warum können die Ergebnisse unterschiedlich sein?

Zusätzliche Prüfungen

Typische Fehlerbilder

• Falscher DNS-Server ist eingetragen.
• /etc/resolv.conf zeigt auf eine nicht erreichbare Adresse.
• /etc/resolv.conf ist ein Symlink auf eine unerwartete Datei.
• Split-DNS oder VPN weist bestimmten Domänen andere Resolver zu.
• /etc/hosts überschreibt das erwartete DNS-Ergebnis.
• dig funktioniert, eine Anwendung jedoch nicht.
• Interne Namen werden fälschlicherweise an einen öffentlichen DNS-Server gesendet.
• IPv4- und IPv6-Auflösung liefern unterschiedliche Ergebnisse.

Interne Hostnamen und DNS-Zonen können sensible Unternehmensinformationen darstellen. Sie sollten nicht unüberlegt an öffentliche Resolver gesendet werden.

nmcli ist das Kommandozeilenwerkzeug für NetworkManager.

Für Skripte sollten die vollständigen Befehlsnamen statt möglicherweise mehrdeutiger Abkürzungen verwendet werden.

Wichtige Gerätezustände

Wichtiger Unterschied

• Device: Tatsächliche physische oder virtuelle Netzwerkschnittstelle.
• Connection: Gespeichertes NetworkManager-Verbindungsprofil.
• Ein Gerät kann mehrere passende Profile besitzen, aber normalerweise nur ein aktives Profil gleichzeitig verwenden.

networkctl zeigt den Zustand von Schnittstellen, wenn systemd-networkd verwendet wird.

Typische Fehlerbilder

• Eine Schnittstelle ist unmanaged.
• Keine passende .network-Datei trifft auf die Schnittstelle zu.
• Mehrere Konfigurationsdateien konkurrieren miteinander.
• NetworkManager und systemd-networkd sollen dieselbe Schnittstelle verwalten.
• DHCP läuft nicht oder liefert keine Adresse.
• Die Schnittstelle befindet sich im Zustand configuring oder failed.

Nicht gleichzeitig davon ausgehen, dass NetworkManager und systemd-networkd dieselbe Schnittstelle verwalten. Zuerst muss festgestellt werden, welcher Dienst tatsächlich zuständig ist.

ethtool liefert Informationen über Ethernet-Schnittstellen, Treiber und Aushandlung.

Wichtige Angaben

Typische Fehlerbilder

• Link detected: no
• Unerwartet niedrige Geschwindigkeit
• Half-Duplex statt Full-Duplex
• Unterschiedliche feste Einstellungen an beiden Link-Enden
• Steigende CRC-, Frame-, Drop- oder Timeout-Zähler
• Falscher oder sehr alter Treiber
• Treiber- oder Firmwarefehler im Kernelprotokoll

ss ist das zentrale moderne Werkzeug zur Untersuchung von Sockets und ersetzt viele frühere netstat-Anwendungsfälle.

Häufig verwendete Kurzform

sudo ss -lntup

Die Optionen bedeuten:

Interpretation

Bei fehlenden Root-Rechten werden möglicherweise nicht alle Prozessinformationen angezeigt.

Häufig verwendete Kurzform

nc -vz -w 3 example.com 443

Mögliche Ergebnisse

Ein UDP-Test mit nc kann ohne Antwort nicht zuverlässig beweisen, ob der UDP-Port offen oder geschlossen ist. UDP besitzt keinen TCP-Verbindungsaufbau.

Linux-Systeme können unterschiedliche Werkzeuge zur Firewallverwaltung einsetzen. Zuerst muss festgestellt werden, welches System tatsächlich aktiv ist.

Prüfpunkte

• Welches Firewall-Frontend wird tatsächlich verwendet?
• Welches Regelwerk ist im Kernel aktiv?
• Welche Eingangs- und Ausgangsregeln gelten?
• Auf welche Schnittstelle oder Zone bezieht sich eine Regel?
• Stimmen IPv4- und IPv6-Regeln überein?
• Erhöhen sich die Paket- oder Bytezähler einer relevanten Regel?
• Wird ein Port lokal geöffnet, aber durch die Firewall blockiert?

Die Firewall nicht pauschal deaktivieren. Zuerst müssen Dienstbindung, Route, verwendete Schnittstelle und passende Regeln geprüft werden.

Typische Protokollhinweise

• link is down
• link becomes ready
• carrier lost
• renamed from eth0
• DHCP timeout
• no lease
• firmware failed to load
• authentication failed
• activation failed
• DNSSEC validation failed
• network unreachable

Protokolle müssen immer mit Zeitstempel, betroffener Schnittstelle und vorhergehenden Ereignissen ausgewertet werden. Eine einzelne Meldung ohne Kontext reicht selten zur Ursachenbestimmung.

Zwei Messzeitpunkte vergleichen

ip -brief address show > addresses-vorher.txt
ip route show table all > routes-vorher.txt

# Messung oder freigegebene Änderung durchführen

ip -brief address show > addresses-nachher.txt
ip route show table all > routes-nachher.txt

diff -u addresses-vorher.txt addresses-nachher.txt
diff -u routes-vorher.txt routes-nachher.txt

Hinweise

• Diagnoseausgaben können interne IP-Adressen, DNS-Namen, MAC-Adressen, Benutzer, Prozesse und Netzstrukturen enthalten.
• Dateien müssen entsprechend den betrieblichen Datenschutz- und Sicherheitsvorgaben behandelt werden.
• Vor einer Weitergabe müssen vertrauliche Inhalte geprüft und gegebenenfalls redigiert werden.
• Passwörter, private Schlüssel, Tokens und vollständige VPN-Konfigurationen gehören nicht in ein allgemeines Diagnoselog.

Die folgenden Befehle verändern den Systemzustand und können insbesondere über SSH die eigene Verbindung unterbrechen.

Vor einem Eingriff prüfen

• Erfolgt der Zugriff lokal oder über SSH?
• Betrifft die Maßnahme die Schnittstelle der eigenen Sitzung?
• Ist die aktuelle Konfiguration dokumentiert?
• Ist bekannt, welcher Netzwerkdienst die Schnittstelle verwaltet?
• Besteht Konsolen-, Out-of-Band- oder Hypervisorzugriff?
• Gibt es eine Rückfallmöglichkeit?
• Sind Auswirkungen auf Container, virtuelle Maschinen, Bridges, Bonds oder VLANs bekannt?
• Ist eine betriebliche Freigabe erforderlich?

Auf einem entfernten System darf die aktive Managementschnittstelle nicht ohne gesicherten Rückfallweg deaktiviert oder neu gestartet werden.

Schritt 1 – System und Netzwerkverwaltung identifizieren

cat /etc/os-release
systemctl is-active NetworkManager
systemctl is-active systemd-networkd

Schritt 2 – Linkstatus prüfen

ip -brief link show
ip -statistics link show

Schritt 3 – IP-Adressen prüfen

ip -brief address show

Schritt 4 – Standardroute und Routenauswahl prüfen

ip route show default
ip route get 1.1.1.1
ip rule show

Schritt 5 – Nachbartabelle prüfen

ip neighbour show

Schritt 6 – Standardgateway testen

ping -c 4 192.0.2.1

Schritt 7 – Externe IP-Adresse testen

ping -c 4 1.1.1.1

Schritt 8 – DNS-Konfiguration prüfen

cat /etc/resolv.conf
resolvectl status

Schritt 9 – DNS-Auflösung testen

getent hosts example.com
dig example.com

Schritt 10 – Zielport testen

nc -vz -w 3 example.com 443

Schritt 11 – Lokale Ports und Prozesse prüfen

sudo ss -lntup

Schritt 12 – Netzwerkpfad untersuchen

tracepath example.com
mtr --report --numeric --report-cycles 20 example.com

Schritt 13 – Firewallstatus prüfen

sudo nft list ruleset

Schritt 14 – Netzwerkprotokolle prüfen

sudo journalctl -u NetworkManager --since "30 minutes ago"
sudo journalctl -kernel --since "30 minutes ago"

Diagnoselogik