Netzwerkbefehle Linux: ip, ss, ping, traceroute, dig und curl für die Diagnose

Netzwerkbefehle unter Linux decken fast die gesamte alltägliche Diagnose ab: ip zeigt Adressen und Routen, ss offene Ports und Verbindungen, ping und traceroute prüfen die Erreichbarkeit eines Rechners, dig das DNS und curl die Antwort eines Webdienstes. Im Folgenden finden Sie einen Spickzettel mit den wichtigsten Optionen und eine schrittweise Reihenfolge, mit der Sie die Ursache finden, wenn „das Netz nicht funktioniert“.

Spickzettel: Netzwerkbefehle Linux auf einen Blick

ip: Adressen, Schnittstellen und Routen

Der Befehl ip aus dem Paket iproute2 hat die veralteten Werkzeuge ifconfig und route ersetzt. Unterbefehle lassen sich abkürzen: ip a entspricht ip addr, ip r entspricht ip route. Die Option -br liefert eine kurze Ausgabe, -c färbt sie ein.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

Hat eine Schnittstelle keine Adresse aus dem benötigten Netz oder steht sie auf DOWN, müssen Sie nicht weitersuchen: Das Problem liegt auf dieser Ebene.

IP-Adresse hinzufügen und Schnittstelle aktivieren

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

Änderungen mit ip gelten bis zum Neustart. Dauerhafte Einstellungen legen Sie in der Systemkonfiguration fest: netplan unter Ubuntu, NetworkManager (nmcli) unter Fedora und RHEL, systemd-networkd auf Servern.

Routen und Standard-Gateway

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

Die Zeile default via nennt das Gateway, über das alles läuft, was keiner genaueren Route entspricht. Fehlt sie, gibt es kein Internet, obwohl das lokale Netz funktioniert. Eine Route ergänzen Sie so: sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss: welche Ports offen sind und wer sie abhört

ss hat netstat abgelöst und arbeitet schneller. Die häufigste Kombination ist ss -tulpn:

$ sudo ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

Achten Sie auf die Adresse: 0.0.0.0 bedeutet, der Dienst nimmt Verbindungen von allen Schnittstellen an, 127.0.0.1 nur lokale. Das ist ein häufiger Grund, warum eine Datenbank von einem anderen Rechner aus „nicht antwortet“.

Wer belegt einen Port?

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # Verbindungen zu einer bestimmten Adresse
ss -tan state time-wait | wc -l   # wie viele Sockets im Status TIME-WAIT sind

ping: ist der Rechner erreichbar?

ping sendet ICMP-Echo-Anfragen und zeigt Antwortzeit und Paketverlust. Unter Linux läuft ping endlos, deshalb geben Sie mit -c die Anzahl der Pakete an.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

Nützliche Optionen: -i 0.2 für das Intervall, -W 2 für das Antwort-Timeout, -4 / -6 für die Protokollversion, -s 1472 -M do, um die MTU ohne Fragmentierung zu prüfen. Beachten Sie, dass viele Server und Cloud-Anbieter ICMP blockieren: Fehlt die Antwort auf ping, heißt das noch nicht, dass der Rechner nicht erreichbar ist.

traceroute und mtr: wo Pakete verloren gehen

traceroute zeigt die Stationen auf dem Weg zum Ziel. Sternchen bei einzelnen Hops sind normal, weil ein Zwischenrouter möglicherweise nicht antwortet. Ein Alarmzeichen ist es, wenn ab einem bestimmten Hop nur noch Sternchen bis zum Ende folgen.

traceroute -n example.com        # ohne DNS-Namen, schneller
sudo traceroute -T -p 443 example.com   # TCP statt UDP, kommt durch Firewalls
tracepath example.com            # ohne root, zeigt außerdem die MTU

mtr kombiniert ping und traceroute und aktualisiert die Verluststatistik jedes Hops in Echtzeit. Für einen Bericht: mtr -rwc 50 example.com.

dig: DNS prüfen

dig aus dem Paket dnsutils (in RHEL bind-utils) ist das wichtigste Werkzeug für die DNS-Prüfung. Die Kurzform liefert nur die Antwort:

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # einen bestimmten Server abfragen
$ dig -x 8.8.8.8 +short            # Rückwärtseintrag (PTR)
$ dig +trace example.com           # die Kette von den Root-Servern durchlaufen

In der vollständigen Ausgabe achten Sie auf status: NOERROR bedeutet, der Eintrag wurde gefunden, NXDOMAIN bedeutet, die Domain existiert nicht, SERVFAIL bedeutet, der Server konnte nicht antworten (oft ein DNSSEC-Problem oder ein nicht erreichbarer autoritativer Server). Antwortet dig @8.8.8.8, ein normales dig aber nicht, ist der lokale Resolver schuld: Prüfen Sie /etc/resolv.conf und resolvectl status.

Beachten Sie, dass dig die Datei /etc/hosts nicht liest. Um die Namensauflösung so zu prüfen, wie sie eine Anwendung erlebt, verwenden Sie getent hosts example.com.

curl: HTTP und APIs prüfen

curl beantwortet die letzte Frage: Antwortet der Dienst, und was liefert er zurück?

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

Fehlermeldungen von curl verraten die betroffene Ebene: Could not resolve host bedeutet DNS, Connection refused bedeutet, der Port ist geschlossen oder niemand lauscht darauf, Connection timed out bedeutet, eine Firewall verwirft die Pakete oder es gibt keine Route, SSL certificate problem bedeutet ein Problem mit dem Zertifikat.

Reihenfolge der Diagnose: wenn „das Netz nicht funktioniert“

1. Schnittstelle und Adresse: ip -br addr — die Schnittstelle ist UP, eine Adresse ist vorhanden.
2. Gateway: ip route — es gibt eine Zeile default via; danach ping -c 3 <Gateway>.
3. Externes Netz per IP: ping -c 3 1.1.1.1. Funktioniert das, ist das Routing in Ordnung.
4. DNS: dig +short example.com. Ist die Antwort leer oder fehlerhaft, obwohl ping per IP funktioniert, liegt das Problem beim Resolver.
5. Port: nc -zv host 443 oder curl -v. Auf dem Server: ss -tulpn, ob der Dienst lauscht und auf welcher Adresse.
6. Firewall: sudo nft list ruleset, sudo iptables -L -n, sudo ufw status.
7. Anwendung: curl -I und die Logs des Dienstes (journalctl -u nginx).

Gehen Sie von unten nach oben vor und überspringen Sie keine Schritte. So finden Sie in ein paar Minuten die Ebene, auf der das Problem liegt, und starten nicht wahllos alles neu.

Alte und neue Befehle

In aktuellen Distributionen ist net-tools oft gar nicht installiert, deshalb sollten Sie sich an die neuen Befehle gewöhnen.

Fazit

Für die tägliche Diagnose reichen sechs Netzwerkbefehle unter Linux: ip, ss, ping, traceroute, dig und curl. Prüfen Sie schichtweise — Adresse, Route, DNS, Port, Anwendung — dann finden Sie den Fehler schnell. Netzwerkbefehle und typische Störungen werden im Kurs zu Linux praxisnah behandelt.