Grundlegende Linux-Netzwerkbefehle

Unter modernem Linux stammen die grundlegenden Netzwerkbefehle aus der iproute2-Suite: ip untersucht Interfaces und Routen, ss listet Sockets und lauschende Ports auf, und ip neigh liest den ARP-Cache aus.

Wer sich schon einmal per Shell in einen frisch aufgesetzten Container verbunden, aus reiner Gewohnheit ifconfig eingetippt und dafür ein command not found erhalten hat, kennt den Grund. Das Muskelgedächtnis hat die Binaries um gut ein Jahrzehnt überlebt.

Diese Befehle ersetzen die älteren net-tools-Binaries (ifconfig, route, netstat, arp), die Red Hat zu den Befehlen zählt, nach denen man nicht mehr greifen sollte und die auf aktuellen Distributionen häufig überhaupt nicht installiert sind. Diese Referenz gruppiert die Befehle nach Aufgabenstellung (Interfaces prüfen, Routing, Konnektivität, DNS, Ports und Traffic) und schließt mit einem Troubleshooting-Ablauf vom Symptom zum Befehl, den Sie von Anfang bis Ende durchgehen können.

Was hat ifconfig, netstat und route unter Linux ersetzt?

net-tools gilt seit Anfang der 2000er als obsolet, mit iproute2 als aktiv weiterentwickeltem Ersatz. Das openSUSE-Paket net-tools-deprecated dokumentiert die kanonische 1:1-Zuordnung:

Verwenden Sie vorzugsweise die iproute2-Variante. Auf einem minimalen Container oder einem frisch installierten Server existieren die alten Binaries möglicherweise nicht, sodass Skripte, die ifconfig oder netstat aufrufen, mit command not found scheitern.

Interfaces und Adressen

ip addr (oder der Alias ip a) zeigt jedes Interface und die zugewiesenen IPv4-/IPv6-Adressen an – das moderne Äquivalent zu ifconfig. Mit ip link aktivieren oder deaktivieren Sie ein Interface, und hostname -I gibt ausschließlich die IP-Adressen des Rechners aus.

ip addr                       # all interfaces + addresses (alias: ip a)
ip addr show eth0             # one interface only
sudo ip link set eth0 down    # take an interface offline
sudo ip link set eth0 up      # bring it back online
hostname -I                   # print all IP addresses, space-separated

Ein einziges Binary, ip, deckt Adressen, Interfaces, Routing und Tunnel ab. hostname -I ist der schnellste Weg, um in einem Skript eine Adresse zu erfassen, ohne die Ausgabe von ip addr parsen zu müssen.

Routing

ip route zeigt und bearbeitet die Routing-Tabelle des Kernels und ersetzt damit das alte Kommando route. Ohne Argumente aufgerufen, sehen Sie, wohin der Traffic geht und welches Gateway das Standard-Gateway ist.

ip route                                      # view the routing table
ip route get 1.1.1.1                          # show which route a destination uses
sudo ip route add 10.0.0.0/24 via 192.168.1.1 # add a static route

ip route get ist der schnelle Weg, die Frage „Welches Interface und welches Gateway verwendet dieses Ziel?“ zu beantworten. Das hilft, wenn ein Host aus einem Netzwerk erreichbar ist, aus einem anderen jedoch nicht.

Konnektivität und Pfad

ping prüft, ob ein Host antwortet; traceroute und mtr zeigen, welchen Weg die Pakete nehmen und wo sie verloren gehen. Begrenzen Sie ping immer mit einer Paketanzahl: ping -c 5 example.com sendet fünf Pakete und beendet sich anschließend, statt endlos zu laufen.

ping -c 5 example.com     # send 5 ICMP echoes, then stop
traceroute example.com    # trace the hop-by-hop path
sudo traceroute -T -p 443 example.com  # trace using TCP to port 443
mtr example.com           # live ping + traceroute in one view

Ohne weitere Angaben bricht traceroute nach 30 Hops ab und bemisst jede Probe mit 60 Byte unter IPv4 bzw. 80 Byte unter IPv6. Mit -T werden die standardmäßigen UDP-Probes durch TCP-Probes ersetzt, die auch Firewalls passieren, welche den Standard verwerfen. mtr example.com kombiniert ping und traceroute in einer Live-Ansicht, sodass Sie den Paketverlust pro Hop in Echtzeit beobachten können. Beachten Sie, dass traceroute und mtr oft nicht vorinstalliert sind: Installieren Sie sie mit sudo apt install mtr traceroute (Debian/Ubuntu) oder sudo dnf install mtr traceroute (RHEL/Fedora).

DNS-Abfragen

dig ist das wichtigste Werkzeug für DNS-Abfragen; +short reduziert die Ausgabe auf die Antwort, -x führt einen Reverse-Lookup durch, und @server richtet die Abfrage an einen bestimmten Resolver. nslookup und host decken dasselbe Terrain in knapperer Form ab.

dig +short example.com            # just the resolved A record(s)
dig -x 8.8.8.8                    # reverse lookup: IP -> hostname
dig +short example.com @8.8.8.8   # query Google's public resolver directly
host example.com                  # terse forward/reverse lookup
nslookup example.com              # interactive-capable lookup

Einen Resolver explizit abzufragen ist der entscheidende Schritt zur Fehlerisolierung: Um einen DNS-Ausfall von einem defekten lokalen Resolver zu unterscheiden, führen Sie dig +short example.com @8.8.8.8 aus; löst diese Abfrage auf, Ihr Standard-Resolver aber nicht, liegt das Problem beim Resolver und nicht bei der Domain.

Wie findet man heraus, welcher Prozess einen Port unter Linux belegt?

Um herauszufinden, welcher Prozess einen Port belegt, führen Sie ss -tulnp | grep :8080 aus. Das Flag -p gibt die PID und den Prozessnamen des Socket-Eigentümers aus. Das ist die Lösung für den Fehler „port already in use“, wenn ein Server oder Container sich nicht binden lässt.

ss -tlnp                    # all listening TCP sockets + owning process
ss -tulnp | grep :8080      # what's bound to port 8080 (TCP + UDP)

Die Flags stehen für t=TCP, u=UDP, l=listening (lauschend), n=numerisch (keine Namensauflösung), p=Prozess. Um Prozessnamen für Sockets zu sehen, die Ihnen nicht gehören, sind Root-Rechte erforderlich – stellen Sie also sudo voran. ss ist der moderne Ersatz für netstat, und die Manpage von netstat bezeichnet den Befehl selbst als größtenteils obsolet und verweist auf das netlink-basierte ss, wenn ein stark belasteter Server viele Sockets auflisten muss. Daher kommt auch der Geschwindigkeitsunterschied: ss fragt den Kernel über netlink ab, während netstat Textdateien unter /proc/net liest. Sobald Sie die PID kennen, beenden Sie den Prozess mit kill <pid>.

Traffic und Datenübertragung

tcpdump zeichnet Pakete live auf, während curl, wget und nc die Erreichbarkeit testen und Dateien übertragen. Verwenden Sie tcpdump, um genau zu sehen, was auf der Leitung passiert, wenn höherstufige Werkzeuge keine Antwort liefern.

sudo tcpdump -i eth0 port 80    # capture HTTP traffic on eth0
curl -v https://example.com     # verbose HTTP request, headers and TLS
wget -O out.html https://example.com  # download to a file
nc -zv example.com 443          # check if a port is open (no data sent)

Pakete mit tcpdump von einem Interface abzugreifen erfordert erhöhte Rechte, was in der Praxis bedeutet, es unter sudo auszuführen (oder dem Binary CAP_NET_RAW zu erteilen). nc -zv host port ist die schnellste Einzeiler-Portprüfung: -z scannt ohne Daten zu senden, -v gibt das Ergebnis aus. Unter Docker Desktop löst host.docker.internal von selbst auf, sodass nc -zv host.docker.internal 8080 den Host aus einem Container heraus erreicht. Bei Docker Engine für Linux müssen Sie das selbst einrichten, indem Sie den Container mit --add-host=host.docker.internal:host-gateway starten (unterstützt seit Docker Engine 20.10).

Troubleshooting-Ablauf: vom Symptom zum Befehl

Ordnen Sie das Symptom einem Entscheidungspfad zu und arbeiten Sie sich von Ihrem Rechner nach außen vor.

• Host nicht erreichbar → ping -c 5 host, um die Erreichbarkeit zu prüfen, dann traceroute host oder mtr host, um zu finden, wo die Pakete verloren gehen, dann ip route, um zu bestätigen, dass eine gültige Route und ein gültiges Gateway vorhanden sind.
• „Port already in use“ → ss -tulnp | grep :<port>, um die zugehörige PID zu finden, dann kill <pid> ausführen oder einen anderen Port binden.
• DNS schlägt fehl → dig +short example.com über Ihren Resolver, dann dig +short example.com @8.8.8.8 über einen öffentlichen Resolver; löst nur die öffentliche Abfrage auf, liegt der Fehler bei Ihrem lokalen Resolver.
• Langsame oder ausgelastete Verbindung → sudo iftop oder bmon, um die Bandbreite pro Verbindung in Echtzeit zu sehen (Installation mit sudo apt install iftop bmon).

Jeder Befehl in diesen Ketten bestätigt oder schließt eine Schicht aus (Link, Route, Namensauflösung, Socket), sodass Sie die Fehlerursache eingrenzen, anstatt zu raten.

Greifen Sie zuerst zu den iproute2-Werkzeugen (ip, ss, ip neigh), weichen Sie nur auf Systemen, die es noch mitliefern, auf net-tools aus, und folgen Sie den oben beschriebenen Pfaden vom Symptom zum Befehl, wenn das nächste Mal ein Bind fehlschlägt oder ein Host nicht mehr antwortet.

FAQs

Was ist der Unterschied zwischen ss und netstat, und sind sie austauschbar?

Sie sind nicht austauschbar. ss ist der moderne Ersatz, und die Manpage von netstat beschreibt den Befehl selbst als größtenteils obsolet und verweist stattdessen auf ss. ss fragt Socket-Daten über netlink beim Kernel ab, während netstat Textdateien unter /proc/net liest – deshalb schlägt sich ss auf Servern mit vielen Sockets deutlich besser. Beide listen Verbindungen und lauschende Ports auf, doch Skripte sollten ss aufrufen, da netstat möglicherweise nicht installiert ist.

Wie finde und beende ich den Prozess, der einen bestimmten Port unter Linux belegt?

Führen Sie ss -tulnp | grep :8080 aus, um den an diesen Port gebundenen Socket zu finden; das Flag -p gibt die PID und den Prozessnamen des Eigentümers aus. Um Prozessnamen für Sockets zu sehen, die Ihnen nicht gehören, sind Root-Rechte erforderlich – stellen Sie also sudo voran. Sobald Sie die PID kennen, beenden Sie den Prozess mit kill gefolgt von der PID. Damit lässt sich der Fehler 'port already in use' beheben, wenn ein Server oder Container sich nicht binden lässt.

Warum gibt ifconfig auf meinem Server command not found zurück?

Weil ifconfig zum Paket net-tools gehört, das viele moderne Distributionen standardmäßig nicht mehr installieren. Red Hat führt ifconfig und route unter den Befehlen auf, die iproute2 ersetzt; RHEL verzichtet seit Version 7 in der Standardinstallation auf net-tools, und Debian tut dasselbe seit Debian 9. Verwenden Sie stattdessen ip addr, um Interfaces und Adressen anzuzeigen, oder installieren Sie net-tools manuell, wenn ein Altskript das alte Binary benötigt.

Wie erkenne ich, ob ein DNS-Problem an der Domain oder an meinem lokalen Resolver liegt?

Fragen Sie einen öffentlichen Resolver direkt mit dig +short example.com @8.8.8.8 ab und vergleichen Sie das Ergebnis mit dig +short example.com über Ihren Standard-Resolver. Löst die öffentliche Abfrage auf, Ihr Standard-Resolver aber nicht, liegt der Fehler bei Ihrem lokalen Resolver und nicht bei der Domain. Die @server-Syntax zwingt dig dazu, den konfigurierten Resolver zu umgehen, und isoliert so den Fehler auf einer Seite, ohne eine Systemkonfiguration zu ändern.

Warum sind traceroute oder mtr auf meinem System nicht installiert?

traceroute, mtr, whois, nmap und iftop sind in minimalen oder Standardinstallationen häufig nicht enthalten und geben daher command not found zurück. Installieren Sie sie mit sudo apt install mtr traceroute unter Debian und Ubuntu oder mit sudo dnf install mtr traceroute unter RHEL und Fedora. Anders als ip und ss, die standardmäßig mit iproute2 mitgeliefert werden, müssen diese Pfad- und Scanning-Werkzeuge in der Regel über den Paketmanager nachinstalliert werden.