Linux-Netzwerk-Grundlagen: Interfaces, Routing, DNS

1. Warum Netzwerk-Grundlagen für Admins unverzichtbar sind

Die Meldung „keine Internetverbindung“ auf einem Linux-Server ist selten ein einzelnes Problem, sondern das Symptom von vier möglichen Ursachen: das Interface ist nicht aktiv, es hat keine IP-Adresse, es fehlt eine passende Route, oder die DNS-Auflösung schlägt fehl. Wer diese vier Ebenen nicht sauber trennt, sucht oft am falschen Ende und verliert Zeit mit Vermutungen statt mit gezielter Diagnose. Ein solides Verständnis von Interfaces, Routing und Namensauflösung verwandelt Rätselraten in einen klaren, wiederholbaren Prüfprozess.

NetworkManager, systemd-networkd und Cloud-Init nehmen Admins heute viel Konfigurationsarbeit ab und abstrahieren die Details. Genau das wird zum Problem, sobald etwas nicht funktioniert: Wer nur die Abstraktionsschicht kennt, steht bei einem Fehlerbild ratlos da, das nur mit den darunterliegenden Kernel-Mechanismen zu verstehen ist. Gerade in minimalen Container-Images und auf frisch aufgesetzten Servern ohne grafische Tools bleibt das ip-Kommando aus dem iproute2-Paket die verlässlichste gemeinsame Basis für Diagnose und Konfiguration.

2. Netzwerk-Interfaces mit ip link und ip addr verstehen

Das Kommando ip link show listet alle Netzwerk-Interfaces des Systems mit ihrem aktuellen Zustand: UP oder DOWN, die MAC-Adresse, die MTU und ob ein physisches Trägersignal (Carrier) erkannt wird. Ein Interface im Zustand DOWN oder ohne LOWER_UP-Flag ist die häufigste, aber am leichtesten übersehene Ursache für ausbleibende Konnektivität, etwa wenn ein Netzwerkkabel nicht richtig gesteckt ist oder ein Switch-Port deaktiviert wurde. ip addr show ergänzt diese Ansicht um die tatsächlich zugewiesenen IP-Adressen samt Subnetzmaske je Interface.

Die Namensvergabe moderner Interfaces folgt dem Predictable Network Interface Names-Schema von systemd-udev, etwa enp3s0 oder eno1, statt der früher üblichen, aber nicht garantiert stabilen Namen wie eth0. Das Loopback-Interface lo mit der Adresse 127.0.0.1 dient als nützliche Baseline: Reagiert nicht einmal lo, liegt ein grundsätzliches Kernel- oder Netzwerk-Stack-Problem vor, das weit vor jeder physischen Verkabelung anzusiedeln ist.

# List all interfaces with state, MAC address and carrier status
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    link/ether 52:54:00:3a:1f:9c brd ff:ff:ff:ff:ff:ff

# Show assigned IPv4/IPv6 addresses per interface
$ ip -4 addr show enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    inet 192.168.10.42/24 brd 192.168.10.255 scope global enp3s0
       valid_lft forever preferred_lft forever

# Quick summary of all interfaces in brief form
$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8
enp3s0           UP             192.168.10.42/24

3. Interfaces konfigurieren: Adressen, MTU und Link-Status

Änderungen mit ip addr add und ip link set wirken sofort, sind aber flüchtig: Nach einem Neustart des Systems oder des Netzwerkdienstes sind sie wieder verschwunden. Das macht diese Kommandos ideal für schnelle Tests und Notfall-Diagnosen, aber ungeeignet für dauerhafte Konfiguration. Für persistente Einstellungen ist stattdessen der jeweilige Netzwerk-Manager zuständig: Netplan unter Ubuntu Server, NetworkManager-Keyfiles auf Desktop-nahen Distributionen oder .network-Dateien für systemd-networkd auf minimalen Systemen.

Netplan übersetzt eine deklarative YAML-Datei intern in NetworkManager- oder systemd-networkd-Konfiguration und ist auf Ubuntu-Servern der Standardweg für statische Adressen, DNS-Server und Routen. Nach jeder Änderung prüft netplan try die Konfiguration testweise und macht sie automatisch rückgängig, falls innerhalb eines Zeitfensters keine Bestätigung erfolgt, was einen Server-Lockout über eine fehlerhafte Netzwerkkonfiguration verhindert. Für DHCP-Interfaces zeigt ip addr show die vom DHCP-Server vergebene Lease inklusive Gültigkeitsdauer.

# /etc/netplan/01-static.yaml, persistent static IP config on Ubuntu Server
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      addresses:
        - 192.168.10.42/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses: [1.1.1.1, 9.9.9.9]
        search: [internal.mironsoft.de]

# Apply safely: reverts automatically if not confirmed within 120s
# netplan try
# netplan apply

4. Die Routing-Tabelle: ip route und das Default-Gateway

Jedes Datenpaket, das den lokalen Rechner verlässt, wird anhand der Kernel-Routing-Tabelle einem Interface zugeordnet. ip route show listet alle bekannten Routen, wobei der Kernel bei mehreren passenden Einträgen immer die spezifischste Route wählt, das sogenannte Longest-Prefix-Match-Prinzip. Der Eintrag default via 192.168.10.1 dev enp3s0 definiert das Standard-Gateway: das Ziel für den gesamten Datenverkehr, für den keine spezifischere Route existiert, also praktisch der gesamte Verkehr ins Internet.

Fehlt die Default-Route oder zeigt sie auf ein nicht erreichbares Gateway, scheitert jede externe Verbindung, obwohl das Interface selbst korrekt konfiguriert ist. Das Kommando ip route get <ziel> ist dabei besonders wertvoll, weil es zeigt, welche konkrete Route der Kernel für eine bestimmte Zieladresse tatsächlich verwenden würde, inklusive Quelladresse und ausgehendem Interface, ohne dass ein einziges Paket verschickt wird.

# Show the full kernel routing table
$ ip route show
default via 192.168.10.1 dev enp3s0 proto dhcp metric 100
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.42

# Add a temporary default route (lost after reboot)
$ sudo ip route add default via 192.168.10.1 dev enp3s0

# Ask the kernel which route it would actually pick for a target
$ ip route get 8.8.8.8
8.8.8.8 via 192.168.10.1 dev enp3s0 src 192.168.10.42 uid 1000

# Add a specific route to a remote subnet via a different gateway
$ sudo ip route add 10.20.0.0/16 via 192.168.10.254 dev enp3s0

5. Mehrere Routen, Metriken und Policy-Based Routing

Server mit mehreren Netzwerkschnittstellen, etwa einem produktiven Uplink und einer separaten Schnittstelle fürs Backup-Netz, benötigen häufig mehr als eine einzige Default-Route. Der metric-Wert einer Route entscheidet über die Priorität: Existieren zwei Default-Routen über unterschiedliche Interfaces, wählt der Kernel bei gleicher Präfixlänge stets die mit dem niedrigeren Metric-Wert. Das erlaubt, ein primäres Interface zu bevorzugen und ein zweites nur als Fallback bereitzuhalten, ohne die Routen manuell umschalten zu müssen.

Reicht eine einfache Metric-Priorisierung nicht aus, kommt Policy-Based Routing mit ip rule ins Spiel: Damit lassen sich eigene Routing-Tabellen definieren und abhängig von Quelladresse, Zielport oder Firewall-Markierung auswählen, etwa um Antwortpakete konsequent über dasselbe Interface zurückzuschicken, über das die Anfrage hereinkam. Genau das verhindert asymmetrisches Routing, das bei aktivem rp_filter (Reverse Path Filtering) sonst dazu führt, dass der Kernel legitime Antwortpakete stillschweigend verwirft, weil sie über ein „falsches“ Interface eintreffen.

6. DNS-Auflösung unter Linux: resolv.conf und nsswitch.conf

Sobald Interface, IP-Adresse und Route stimmen, kommt die Namensauflösung ins Spiel. Der Standard-Resolver der glibc liest dafür /etc/resolv.conf, das die Nameserver-Adressen und optionale Suchdomains für unqualifizierte Hostnamen enthält. Auf modernen Systemen mit systemd-resolved ist diese Datei oft nur ein Symlink auf /run/systemd/resolve/stub-resolv.conf und zeigt als einzigen Nameserver 127.0.0.53, den lokalen Stub-Resolver, der Anfragen intern zwischenspeichert und an die tatsächlich konfigurierten Upstream-Server weiterleitet.

Welche Quellen bei der Namensauflösung überhaupt befragt werden und in welcher Reihenfolge, steuert die hosts-Zeile in /etc/nsswitch.conf. Der typische Eintrag hosts: files dns bedeutet: Erst wird /etc/hosts geprüft, danach erst DNS. Das erklärt, warum ein falscher Eintrag in /etc/hosts eine korrekte DNS-Antwort vollständig überschreiben kann, ein häufig übersehener Fallstrick beim Debugging vermeintlicher DNS-Probleme.

# /etc/resolv.conf, typical systemd-resolved stub configuration
nameserver 127.0.0.53
options edns0 trust-ad
search internal.mironsoft.de

# /etc/nsswitch.conf, relevant line for hostname resolution order
# "files" checked before "dns": /etc/hosts entries win over DNS answers
hosts: files dns myhostname

# /etc/systemd/resolved.conf, actual upstream DNS servers behind the stub
[Resolve]
DNS=1.1.1.1 9.9.9.9
FallbackDNS=8.8.8.8
Domains=internal.mironsoft.de

7. DNS-Tools im Alltag: dig, resolvectl, getent

Zum gezielten Testen der DNS-Auflösung eignet sich dig am besten, weil es den lokalen Resolver komplett umgehen und direkt einen bestimmten Nameserver befragen kann: dig @1.1.1.1 mironsoft.de zeigt, ob das Problem beim Upstream-Server liegt oder erst lokal entsteht. dig +short liefert eine knappe, skriptfreundliche Ausgabe nur mit der aufgelösten IP-Adresse, ideal für Health-Checks und Monitoring-Skripte.

Auf Systemen mit systemd-resolved liefert resolvectl status einen vollständigen Überblick über die pro Interface konfigurierten DNS-Server, Suchdomains und den aktuellen DNSSEC-Status. resolvectl query nutzt dabei denselben Auflösungspfad wie eine echte Anwendung. Noch näher an der Anwendungsrealität liegt getent hosts mironsoft.de: Dieses Kommando durchläuft exakt die in nsswitch.conf konfigurierte Kette und zeigt damit zuverlässig, was ein beliebiges Programm auf dem System tatsächlich als Antwort erhalten würde, inklusive etwaiger /etc/hosts-Überschreibungen.

8. Die richtige Troubleshooting-Reihenfolge: Link, IP, Route, DNS

Netzwerkfehler lassen sich fast immer effizient eingrenzen, wenn man konsequent von unten nach oben prüft, statt wahllos zu testen. Schritt eins: ip link show, ist das Interface UP und wird ein Carrier erkannt. Schritt zwei: ip addr show, hat das Interface überhaupt eine IP-Adresse im erwarteten Subnetz. Schritt drei: ip route show gefolgt von ping auf das Gateway, existiert eine Route und ist das Gateway erreichbar. Erst danach, Schritt vier, folgt die DNS-Prüfung mit dig oder resolvectl query.

Diese Reihenfolge spart massiv Zeit, weil jede höhere Ebene von der darunterliegenden abhängt: Eine DNS-Fehlermeldung auf einem Interface ohne Route ist irreführend, denn das eigentliche Problem liegt schon zwei Ebenen tiefer. Automatisierte Health-Check-Skripte bilden diese vier Schritte häufig als strukturierten Statusbericht ab, den Monitoring-Systeme wie Icinga oder Prometheus-Exporter direkt weiterverarbeiten können.

{
  "host": "web-01.internal.mironsoft.de",
  "checked_at": "2026-07-12T09:14:02Z",
  "checks": {
    "link": { "interface": "enp3s0", "state": "UP", "carrier": true },
    "address": { "ipv4": "192.168.10.42/24", "assigned": true },
    "route": { "default_gateway": "192.168.10.1", "reachable": true, "rtt_ms": 0.4 },
    "dns": { "resolver": "127.0.0.53", "query": "mironsoft.de", "resolved": true, "rtt_ms": 12.7 }
  },
  "status": "ok"
}

9. Netzwerk-Tools im Vergleich: klassisch gegen iproute2

Viele ältere Anleitungen und Skripte setzen noch auf die Kommandos aus dem net-tools-Paket, die seit über zwei Jahrzehnten offiziell als veraltet gelten und in minimalen Distributionen oft gar nicht mehr vorinstalliert sind. Die folgende Übersicht zeigt die direkten Nachfolger aus iproute2 und den DNS-Werkzeugen von systemd-resolved.

Der Umstieg lohnt sich nicht nur wegen der Aktualität: iproute2-Kommandos liefern strukturiertere Ausgaben, unterstützen Namespaces und Policy-Routing nativ und lassen sich mit der Option -j direkt als JSON ausgeben, was die Integration in eigene Monitoring- und Automatisierungsskripte erheblich vereinfacht, ganz ohne fragiles Parsen von Textausgaben.

10. Zusammenfassung

Die Linux-Netzwerk-Grundlagen lassen sich auf vier klar getrennte Ebenen herunterbrechen: Ist das Interface aktiv (ip link), hat es eine passende IP-Adresse (ip addr), existiert eine funktionierende Route zum Ziel (ip route), und löst DNS den benötigten Namen korrekt auf (resolv.conf, nsswitch.conf, dig). Wer diese Reihenfolge konsequent einhält, findet die tatsächliche Fehlerursache in der Regel innerhalb weniger Minuten, statt Symptome auf der falschen Ebene zu bekämpfen.

Das iproute2-Paket mit ip und ss hat die klassischen net-tools-Kommandos wie ifconfig, route und netstat längst abgelöst und liefert strukturiertere, teils JSON-fähige Ausgaben. Wer zusätzlich versteht, wie systemd-resolved als Stub-Resolver zwischen glibc und den eigentlichen Upstream-DNS-Servern vermittelt, kann auch vermeintlich mysteriöse DNS-Probleme gezielt statt zufällig lösen.

11. FAQ: Linux-Netzwerk-Grundlagen