Statische IP-Adresse einrichten unter Debian und Ubuntu

Vier Angaben, ohne die Sie nicht anfangen sollten

Eine statische Adresse ist schnell eingetragen. Der Grund, warum trotzdem so viele Server nach dem Neustart schweigen, liegt fast nie an der Syntax, sondern daran, dass eine der vier Grundangaben geraten statt abgelesen wurde: Name der Schnittstelle, Adresse samt Präfixlänge, Gateway und Nameserver. Lesen Sie diese Werte im laufenden Betrieb ab, solange die Maschine noch erreichbar ist.

ip -brief address show
ip -4 route show
ip -6 route show
cat /etc/resolv.conf

Die erste Zeile liefert den Namen der Schnittstelle. Auf virtuellen Servern heißt sie je nach Plattform ens3, enp1s0 oder eth0, auf Blech oft eno1. Schreiben Sie den Namen ab, raten Sie ihn nicht. Ein Tippfehler an dieser Stelle erzeugt eine syntaktisch einwandfreie Konfiguration, die schlicht auf keine vorhandene Karte passt.

Besonders wichtig ist die Präfixlänge. Viele Anbieter routen eine einzelne IPv4-Adresse mit /32 auf den Server, das Gateway liegt dann außerhalb des eigenen Subnetzes. Andere vergeben klassische /24-Netze. Welcher Fall vorliegt, verrät der tatsächlich genutzte Pfad:

ip route get 1.1.1.1

Legen Sie danach eine Sicherung an. Das kostet zehn Sekunden und ist der Unterschied zwischen einem Rollback und einem Ticket.

cp -a /etc/netplan /root/netplan.bak
cp -a /etc/network/interfaces /root/interfaces.bak

Welches System steuert Ihr Netzwerk gerade?

Debian und Ubuntu benutzen unterschiedliche Werkzeuge, und der häufigste Totalausfall entsteht, wenn zwei davon gleichzeitig dieselbe Karte konfigurieren. Verschaffen Sie sich zuerst Klarheit:

ls -l /etc/netplan/
ls -l /etc/network/interfaces /etc/network/interfaces.d/
ls -l /etc/systemd/network/

Die Faustregel für die vier aktuellen Versionen: Ubuntu 24.04 und Ubuntu 22.04 werden über netplan konfiguriert, das im Hintergrund systemd-networkd steuert. Debian 13 und Debian 12 kommen nach einer Standardinstallation mit ifupdown und der Datei /etc/network/interfaces. systemd-networkd ist auf Debian vorhanden, aber nicht aktiv, und netplan ist dort nachinstallierbar, jedoch nicht der vorgesehene Weg.

Auf Cloud-Abbildern kommt eine weitere Schicht dazu: cloud-init schreibt beim ersten Start eine eigene Datei, typischerweise /etc/netplan/50-cloud-init.yaml beziehungsweise unter Debian einen Block in /etc/network/interfaces.d/. Wer diese Datei bearbeitet, ohne cloud-init zu bremsen, findet nach dem nächsten Neustart die alte Konfiguration wieder vor.

Ubuntu 24.04 und 22.04: statische Adresse mit netplan

netplan liest alle Dateien in /etc/netplan/ in alphabetischer Reihenfolge und übersetzt sie in Konfiguration für systemd-networkd. Legen Sie keine zweite Datei mit derselben Schnittstelle an, sondern bearbeiten Sie die bestehende oder deaktivieren Sie die alte sauber. Eine vollständige Konfiguration mit IPv4 und IPv6 sieht so aus:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 203.0.113.10/24
        - "2001:db8:1234::2/64"
      routes:
        - to: default
          via: 203.0.113.1
        - to: default
          via: "2001:db8:1234::1"
      nameservers:
        addresses: [9.9.9.9, 149.112.112.112, 2620:fe::fe]

Drei Punkte daran sind es wert, einzeln erklärt zu werden.

Erstens stehen die Vorgabewege unter routes und nicht mehr unter gateway4 oder gateway6. Diese beiden Schlüssel sind seit netplan 0.103 abgekündigt. Sie funktionieren auf Ubuntu 22.04 und 24.04 noch, quittieren aber jeden Aufruf mit `gateway4` has been deprecated, use default routes instead. Wer neu schreibt, schreibt Routen.

Zweitens schaltet accept-ra: false die automatische IPv6-Konfiguration ab. Lassen Sie sie an, während Sie gleichzeitig eine feste Adresse vergeben, bekommt die Karte zwei Adressen und zwei Vorgabewege, und welcher gewinnt, entscheidet die Metrik, nicht Ihre Absicht.

Drittens die Dateirechte. Seit netplan 0.106 warnt jeder Aufruf, wenn die YAML-Datei für andere Benutzer lesbar ist: Permissions for /etc/netplan/01-static.yaml are too open. Netplan configuration should NOT be accessible by others. Das ist keine Kosmetik, denn in solchen Dateien stehen auch WLAN-Schlüssel und Tunneldaten.

chmod 600 /etc/netplan/*.yaml

Wenn das Gateway außerhalb des eigenen Subnetzes liegt

Bei einer einzeln gerouteten Adresse mit /32 kennt der Kernel keinen direkten Weg zum Gateway und lehnt die Route ab. Im Journal steht dann Could not set route: Network is unreachable, beim manuellen Versuch mit ip route add lautet die Antwort RTNETLINK answers: Network is unreachable. Die Lösung heißt on-link:

      addresses:
        - 203.0.113.10/32
      routes:
        - to: default
          via: 192.0.2.1
          on-link: true

Für IPv6 ist der Sonderfall der Regelfall: Viele Netze geben als Gateway die Link-Local-Adresse fe80::1 an. Da netplan Routen immer einer Schnittstelle zuordnet, genügt via: "fe80::1" im Block der jeweiligen Karte.

cloud-init ruhigstellen

Wenn im Verzeichnis eine 50-cloud-init.yaml liegt, hinterlegen Sie zusätzlich eine Sperre, sonst wird Ihre Arbeit beim nächsten Start überschrieben:

echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

netplan try: der Befehl, der Sie nicht aussperrt

Die Reihenfolge lautet prüfen, testen, festschreiben. netplan generate übersetzt die YAML-Dateien, ohne etwas zu aktivieren, und meldet Syntaxfehler sofort. Erst danach folgt der eigentliche Test.

netplan generate
netplan try --timeout 120
netplan apply

netplan try wendet die neue Konfiguration an und stellt die alte automatisch wieder her, wenn Sie nicht innerhalb der Frist die Eingabetaste drücken. Der Vorgabewert liegt bei 120 Sekunden. Genau das ist der Grund, warum man auf einem entfernten Server nie mit netplan apply anfängt: Ein Tippfehler in der Gateway-Adresse beendet die SSH-Sitzung, und ohne Rückfallebene endet die Sache in der Konsole oder in einer Neuinstallation.

Verlassen Sie sich nicht blind auf die Rücknahme. Es sind Fälle dokumentiert, in denen netplan try nach einem Zeitablauf die Verbindung nicht wiederhergestellt hat, insbesondere beim Bearbeiten der von cloud-init erzeugten Datei. Prüfen Sie nach einem Rücklauf immer, ob die Datei auf der Platte wirklich wieder im alten Zustand ist.

Für alles, was netplan try nicht abdeckt (und für Debian mit ifupdown, wo es diesen Befehl gar nicht gibt), hat sich ein zweiter Sicherheitsgurt bewährt: ein Aufräumauftrag, der die Sicherung zurückspielt, falls Sie sich nicht rechtzeitig melden.

nohup sh -c 'sleep 300; cp -a /root/netplan.bak/. /etc/netplan/; netplan apply' >/dev/null 2>&1 &

Merken Sie sich die Prozessnummer aus der Ausgabe. Funktioniert alles, beenden Sie den Auftrag mit kill. Kommen Sie nicht mehr rein, repariert er sich in fünf Minuten selbst. Arbeiten Sie zusätzlich in tmux oder screen, damit eine abbrechende SSH-Sitzung nicht mitten in der Umstellung Ihren Editor mitreißt.

Bei KVM-Rootservern bleibt als letzte Instanz die Konsole im Kundenbereich, über die Sie auch ohne funktionierendes Netzwerk auf das System kommen. Bei dedizierten Maschinen ist der Weg zurück deutlich aufwendiger, dort zählt die Vorsichtsroutine doppelt.

Debian 13 und 12 mit /etc/network/interfaces

Nach einer Standardinstallation steuert ifupdown das Netzwerk. Die Konfiguration ist zeilenorientiert und kennt getrennte Blöcke je Adressfamilie:

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1

iface ens3 inet6 static
    address 2001:db8:1234::2/64
    gateway 2001:db8:1234::1
    accept_ra 0

Das auto ens3 gilt für beide Blöcke, eine zweite auto-Zeile brauchen Sie nicht. Liegt das Gateway außerhalb des Subnetzes, hilft dieselbe Idee wie bei netplan, nur von Hand formuliert:

iface ens3 inet static
    address 203.0.113.10/32
    post-up ip route add 192.0.2.1 dev ens3
    post-up ip route add default via 192.0.2.1
    pre-down ip route del default via 192.0.2.1

Die größte Stolperfalle unter Debian ist nicht die Syntax, sondern das Aktivieren. systemctl restart networking nimmt die Karte kurz herunter, und wenn die neue Konfiguration nicht trägt, ist die Sitzung weg. ifdown ens3 && ifup ens3 ist noch heikler, weil das ifup nie ausgeführt wird, sobald die Verbindung schon beim ifdown reißt. Legen Sie also vorher den oben beschriebenen Aufräumauftrag an, und rufen Sie dann auf:

systemctl restart networking
systemctl status networking

Zwei Meldungen begegnen Ihnen hier regelmäßig. ifup: interface ens3 already configured bedeutet, dass ifupdown die Karte noch als aktiv verbucht, obwohl sie es vielleicht nicht mehr ist; der Zustand steht in /run/network/ifstate. Und Job for networking.service failed because the control process exited with error code ist nur die Hülle, der eigentliche Grund steht in journalctl -xeu networking, meist ein doppelt vergebener Vorgabeweg mit RTNETLINK answers: File exists.

DNS unter ifupdown

Die naheliegende Zeile dns-nameservers 9.9.9.9 in der Datei wirkt nur, wenn ein Vermittler installiert ist, der sie in /etc/resolv.conf überträgt, klassisch das Paket resolvconf. Ohne diesen Vermittler bleibt der Eintrag folgenlos, und das fällt erst auf, wenn Namen nicht mehr auflösen: Temporary failure in name resolution. Wer nichts nachinstallieren möchte, pflegt /etc/resolv.conf direkt und prüft mit ls -l /etc/resolv.conf, ob die Datei ein Symlink ist, also von einem anderen Dienst verwaltet wird.

Debian mit systemd-networkd betreiben

Wer auf einem Debian-Server ohnehin systemd-Werkzeuge nutzt oder viele Schnittstellen und Tunnel verwaltet, fährt mit systemd-networkd konsistenter. Der Umstieg besteht aus drei Schritten: Konfiguration anlegen, neuen Dienst aktivieren, alten stilllegen.

[Match]
Name=ens3

[Network]
Address=203.0.113.10/24
Address=2001:db8:1234::2/64
Gateway=203.0.113.1
Gateway=2001:db8:1234::1
DNS=9.9.9.9
DNS=2620:fe::fe
IPv6AcceptRA=no

Diese Datei gehört nach /etc/systemd/network/10-ens3.network. Für ein Gateway außerhalb des Subnetzes hängen Sie einen eigenen Routenblock an:

[Route]
Gateway=192.0.2.1
GatewayOnLink=yes

Danach die Umschaltung, am besten wieder mit Aufräumauftrag im Rücken:

systemctl enable --now systemd-networkd
systemctl disable networking
networkctl status ens3

Die Ausgabe von networkctl status ist die ehrlichste Rückmeldung, die dieses Thema zu bieten hat. Steht dort State: routable (configured), hat der Dienst die Datei akzeptiert und umgesetzt. Steht dort configuring oder degraded, hat er es versucht und ist gescheitert, unabhängig davon, dass der Startbefehl ohne Fehler zurückkam.

Der DNS-Teil ist unter Debian eigenständig: systemd-networkd trägt Nameserver nur dann in die Auflösung ein, wenn systemd-resolved läuft und /etc/resolv.conf auf dessen Datei zeigt.

apt-cache policy systemd-resolved

Diese Abfrage ist versionsabhängig, und sie täuscht auf eine unauffällige Weise. Ein eigenständiges Paket systemd-resolved gibt es erst ab Debian 12 und Ubuntu 24.04, dort nennt der Befehl eine Version. Auf Ubuntu 22.04 steckt der Dienst dagegen noch im Paket systemd selbst, und dort läuft der Befehl zwar ohne Fehler durch, gibt aber überhaupt nichts aus. Eine Installation schlägt entsprechend mit Unable to locate package systemd-resolved fehl. Die leere Ausgabe heißt also nicht, dass der Resolver fehlt, sondern dass es das Paket auf dieser Version nicht gibt. Auf älteren Systemen wie Debian 11 verhält es sich genauso. Prüfen Sie auf diesen Versionen stattdessen:

apt-cache policy systemd
systemctl status systemd-resolved

Aktiviert wird der Dienst mit systemctl enable --now systemd-resolved, anschließend zeigt der übliche Symlink auf /run/systemd/resolve/stub-resolv.conf. Wer das nicht möchte, lässt systemd-resolved weg und schreibt die Nameserver statisch in /etc/resolv.conf. Was Sie nicht tun sollten: beides halb.

Zusätzliche IP-Adressen einbinden

Zusatzadressen sind kein Sonderfall, sondern schlicht ein weiterer Eintrag. Unter netplan wächst die Liste:

      addresses:
        - 203.0.113.10/24
        - 203.0.113.11/24
        - 203.0.113.12/24
        - "2001:db8:1234::2/64"
        - "2001:db8:1234::3/64"

Unter systemd-networkd schreiben Sie mehrere Address=-Zeilen untereinander. Unter ifupdown ergänzen Sie die vorhandene Definition, statt eine zweite anzulegen:

iface ens3 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    post-up ip addr add 203.0.113.11/24 dev ens3
    post-up ip addr add 203.0.113.12/24 dev ens3
    pre-down ip addr del 203.0.113.11/24 dev ens3
    pre-down ip addr del 203.0.113.12/24 dev ens3

Die alte Schreibweise mit ens3:0 funktioniert weiterhin, ist aber ein Relikt aus der Zeit vor dem Werkzeug ip. Sie erzeugt keine echten zusätzlichen Geräte, nur Bezeichnungen, und stiftet in Firewallregeln mehr Verwirrung, als sie nützt.

Drei Dinge gehen bei Zusatzadressen typischerweise schief. Erstens ist die Adresse serverseitig nicht zugewiesen; keine Betriebssystemkonfiguration der Welt bringt eine IP zum Laufen, die nicht auf Ihren Server geroutet ist, deshalb ist der Blick in den Kundenbereich der erste Schritt und nicht der letzte. Zweitens gehört zu einer zweiten Adresse aus demselben Netz kein zweiter Vorgabeweg; ein zweiter Standardgateway-Eintrag beschert Ihnen RTNETLINK answers: File exists oder, schlimmer, wechselnde Antwortpfade. Drittens gilt bei IPv6 fast immer, dass das gesamte /64 auf den Server geroutet ist, Sie also frei aus dem Bereich wählen können, aber nur die vom Anbieter benannte Adresse tatsächlich als konfigurierte Schnittstellenadresse gebraucht wird.

Ob eine Zusatzadresse wirklich nach außen trägt, prüfen Sie gezielt über den Quellpunkt:

ping -c 3 -I 203.0.113.11 1.1.1.1

Woran Sie erkennen, dass es wirklich sitzt

Dass ein Befehl ohne Fehlermeldung durchgelaufen ist, sagt über den Zustand des Netzwerks wenig aus. Diese fünf Prüfungen sagen etwas:

1. Die Adresse ist an der richtigen Karte: ip -brief address show zeigt genau die gewünschten Adressen und keine Reste der alten Konfiguration.
2. Der Weg nach draußen stimmt inklusive Quelladresse: ip route get 1.1.1.1 nennt das erwartete Gateway und das erwartete src.
3. IPv6 hat einen eigenen Vorgabeweg: ip -6 route show default darf nicht leer sein, sonst läuft alles still über IPv4.
4. Namensauflösung funktioniert unabhängig von der Erreichbarkeit: getent hosts deb.debian.org liefert eine Adresse, nicht nur Stille.
5. Der einzige echte Test ist ein Neustart. Erst danach wissen Sie, ob die Konfiguration aus der Datei kommt oder noch aus dem Arbeitsspeicher.

Unter Ubuntu gibt netplan status --all zusätzlich eine kompakte Zusammenfassung aus, unter systemd-networkd leistet networkctl status dasselbe. Beide zeigen im Zweifel, dass eine Adresse zwar in der Datei steht, aber nie übernommen wurde.

Fehlermeldungen im Wortlaut

Die vier Distributionen im direkten Vergleich

Wenn Sie unmittelbar nach der Netzwerkkonfiguration die Firewall in Betrieb nehmen, achten Sie darauf, dass Regeln für die neue Adresse und für IPv6 getrennt gelten. Wie das sauber aufgesetzt wird, steht in unserer Anleitung zu UFW unter Debian und Ubuntu, und wie Sie den Zugang danach absichern, in SSH-Server absichern.

Kurzfassung für den nächsten Server

Werte ablesen statt raten, Sicherung anlegen, Konfiguration schreiben, mit netplan try oder einem eigenen Aufräumauftrag testen, festschreiben, neu starten und dann erst abhaken. Wer diese Reihenfolge einhält, verliert im schlimmsten Fall fünf Minuten. Wer sie abkürzt, verliert im schlimmsten Fall den Server, bis jemand an der Konsole sitzt.