Netplan-Crashkurs für Ubuntu Dedicated Server

Was Netplan ist, und ob Sie es nutzen

Netplan ist die Netzwerkkonfigurationsschicht, die Ubuntu seit 17.10 standardmäßig mitliefert. Sie schreiben Ihre Interfaces, Adressen, Routen und DNS als YAML in /etc/netplan/, und ein Generator wandelt diese eine Beschreibung in Konfiguration für das jeweilige Backend um, das darunter das Netzwerk steuert: systemd-networkd auf Ubuntu Server, NetworkManager auf Ubuntu Desktop. Sie bearbeiten ein einziges Dateiformat; Netplan rendert darunter die backend-spezifische Konfiguration.

Wenn Sie einen Dedicated Server gemietet und Ubuntu darauf installiert haben, haben Sie Netplan. Diese Anleitung ist für genau diese Maschine geschrieben: ein Server, eine statische öffentliche IPv4-Adresse (und oft auch eine IPv6-Zuweisung), kein WLAN, und SSH als einziger Zugang. Dieses letzte Detail bestimmt den Ton des gesamten Artikels, denn ein Netzwerkfehler auf einem Remote-Server ist genau der Weg, sich selbst auszusperren. Netplan hat dafür ein eigenes Werkzeug, um genau das zu verhindern, und darauf verlassen wir uns jedes Mal, wenn wir live etwas ändern.

Der Crashkurs behandelt:

• wo die Konfigurationsdateien liegen, und die Berechtigungsregel, über die viele stolpern
• das Zwei-Backend-Modell, und was sich ändert, wenn Sie Konfiguration aus einem Tutorial für das jeweils andere übernehmen
• eine vollständige statische IPv4- und IPv6-Konfiguration, die Sie Zeile für Zeile anpassen können
• die Befehle, die Sie im Alltag nutzen: generate, try, apply und status
• VLANs, LACP-Bonds, und eine Bridge für VM-Hosts
• warum Ihre Änderungen manchmal nach einem Neustart verschwinden, und die cloud-init-Einstellung, die das behebt

Kurz eine Anmerkung zu den Versionen. Ubuntu 26.04 LTS „Resolute Raccoon", veröffentlicht am 23. April 2026, liefert die Netplan-1.2-Reihe. Die vorherige LTS, 24.04 „Noble Numbat", lieferte Netplan 1.0, die erste stabile Version, datiert auf den 29. Februar 2024. Die Upstream-Reihe ist zum Zeitpunkt der Erstellung 1.2.x; die aktuelle Version finden Sie auf der Releases-Seite. Alles hier gilt für beide, mit Unterschieden dort vermerkt, wo sie auftreten. Wenn Sie noch unentschlossen sind, welche Version Sie einsetzen sollen, behandelt der Ubuntu Server LTS-Leitfaden die Support-Zeiträume.

Wo die Konfiguration liegt

Jede *.yaml-Datei in /etc/netplan/ zählt mit. Zwei weitere Verzeichnisse fließen ebenfalls ein: /run/netplan/ für Laufzeitkonfiguration und /lib/netplan/ für Vendor-Standardwerte. Dateien werden in lexikografischer Reihenfolge nach Namen gelesen und zu einem Modell zusammengeführt. Wird derselbe Schlüssel zweimal gesetzt, gewinnt die später gelesene Datei. Existiert eine Datei gleichen Namens in mehr als einem Verzeichnis, hat die Kopie in /run/netplan/ Vorrang vor /etc/netplan/, das wiederum Vorrang vor /lib/netplan/ hat.

Diese Reihenfolge ist der Grund, warum eine Datei namens 50-cloud-init.yaml eine Rolle spielt. Auf den meisten Cloud- und Dedicated-Server-Images schreibt cloud-init Ihre anfänglichen Netzwerkeinstellungen genau in diese Datei, und ihr 50--Präfix liegt früh in der Sortierreihenfolge. Legen Sie Ihre eigene 90-static.yaml daneben, gewinnt diese beim Zusammenführen, aber cloud-init kann seine eigene Datei beim nächsten Start neu schreiben und damit Ihre Annahmen zunichtemachen. Die saubere Lösung folgt weiter unten, bei der Fehlerbehebung. Wissen Sie für den Moment, dass 50-cloud-init.yaml generiert und nicht von Hand geschrieben ist, und behandeln Sie sie entsprechend.

Eine Regel erwischt fast jeden mindestens einmal. Jede Datei unter /etc/netplan/ sollte root gehören und nur für root lesbar sein, Modus 600. Netplan speichert in diesen Dateien Zugangsdaten wie WLAN-Passwörter und Tunnel-Keys, weshalb eine für alle lesbare Konfiguration Geheimnisse offenlegt. Seit Version 0.106 gibt das Tool eine Warnung aus, sobald es eine Datei findet, die außer root noch jemand lesen kann:

** (generate:1234): WARNING **: Permissions for /etc/netplan/50-cloud-init.yaml
are too open. Netplan configuration should NOT be accessible by others.

Beheben Sie es mit einem einzigen Befehl:

chmod 600 /etc/netplan/*.yaml

Diese Warnung lässt sich leicht ignorieren, weil das Netzwerk trotzdem weiterläuft, aber die Berechtigungen zu verschärfen gehört zu jedem Server-Hardening-Durchgang dazu und kostet nichts.

Eine YAML-Quelle, zwei Backends

Netplan selbst verwaltet keine einzige Schnittstelle. Es erzeugt Konfiguration für einen Renderer, und der Renderer erledigt die Arbeit. Es gibt zwei davon, und welcher standardmäßig läuft, hängt davon ab, wie Ubuntu installiert wurde:

Auf einem Server ändern Sie das selten. systemd-networkd startet früh beim Boot, hat keine GUI-Abhängigkeiten und ist das richtige Backend für eine Maschine, die Sie über SSH erreichen. Sie können es oben in der Datei mit renderer: networkd explizit benennen, auch wenn das auf Ubuntu Server ohnehin schon der Standard ist.

Warum diese Unterscheidung wichtig ist: Konfiguration, die Sie aus einem auf Desktops ausgerichteten Tutorial übernehmen, setzt womöglich renderer: NetworkManager oder verlässt sich auf Schlüssel, die nur für NetworkManager gelten, und verhält sich auf einem networkd-Server anders oder lässt sich gar nicht erst anwenden. Prüfen Sie bei einem übernommenen Snippet, welches Backend es voraussetzt, bevor Sie es einfügen.

Eine vollständige statische Konfiguration

Hier ist ein vollständiges statisches Setup für eine einzelne Schnittstelle mit sowohl IPv4 als auch IPv6. Es weist die Adressen zu, legt die Standardrouten fest und konfiguriert DNS. Interface-Namen folgen auf modernem Ubuntu dem vorhersagbaren Schema, Ihre heißt also wahrscheinlich enp1s0, eno1 oder ähnlich; führen Sie ip -br link aus, um zu sehen, wie Ihr Kernel sie nennt.

# /etc/netplan/90-static.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.0.2.10/24
        - "2001:db8::10/64"
      routes:
        - to: default
          via: 192.0.2.1
        - to: default
          via: "2001:db8::1"
      nameservers:
        addresses:
          - 192.0.2.53
          - 2001:db8::53
        search:
          - example.com

version: 2 ist die Netplan-Formatversion und ist erforderlich. dhcp4: false ist bereits der Standard, sobald Sie statische Adressen angeben, aber die explizite Angabe macht Ihre Absicht für den nächsten Leser klar. Jede Adresse trägt ihre Präfixlänge in CIDR-Form. Der routes-Block ist der Teil, den zu lesen sich zweimal lohnt.

Sie finden ältere Tutorials, die das Gateway so setzen:

      gateway4: 192.0.2.1

Dieser Schlüssel ist deprecated. Netplan warnt seit Version 0.103 vor gateway4 und gateway6, und die Meldung ist unmissverständlich:

gateway4 has been deprecated, use default routes instead.

Der Ersatz ist der routes-Eintrag mit to: default, genau wie im vollständigen Beispiel oben. Er erledigt dieselbe Aufgabe, funktioniert für IPv4 und IPv6 über einen einzigen Mechanismus und lässt Sie später Nicht-Standard-Routen hinzufügen, ohne den Stil zu wechseln. Verwenden Sie ihn, und lassen Sie gateway4 weg, auch wenn es noch funktioniert.

Verwenden Sie die hier gezeigten IPs und Interface-Namen nicht unverändert weiter. Die Adressen stammen aus den für Beispiele reservierten TEST-NET- und Dokumentationsbereichen; setzen Sie die Werte ein, die Ihnen Ihr Provider gegeben hat.

Die Befehle: generate, try, apply

Netplan verändert Ihr laufendes Netzwerk erst, wenn Sie einen von drei Befehlen ausführen. Den Unterschied zwischen ihnen zu kennen ist das, was eine Remote-Sitzung am Leben hält.

netplan generate rendert Ihr YAML in Backend-Konfiguration unter /run/systemd/network/ (für networkd), ohne das laufende Netzwerk anzufassen. Es dient nebenbei als Validator: Hat Ihr YAML einen Syntaxfehler oder einen unbekannten Schlüssel, schlägt generate fehl und sagt Ihnen wo, und bis dahin hat sich noch nichts geändert. Führen Sie es zuerst aus, sobald Sie unsicher sind.

Der Befehl, der das laufende System verändert, ist netplan apply. Er erzeugt die Konfiguration neu und wendet sie dann sofort an, wobei die Schnittstelle bei einer Änderung der statischen Adresse direkt neu konfiguriert wird. Auf einer Remote-Maschine ist die Gefahr unmittelbar: Ist die neue Konfiguration falsch, haben Sie gerade Ihre eigene SSH-Sitzung gekappt, und von dort, wo Sie sitzen, gibt es kein Zurück.

netplan try ist die Antwort auf diese Gefahr, und auf einem Remote-Server ist es der Befehl, zu dem Sie standardmäßig greifen sollten. Es wendet die Konfiguration an und startet dann einen Countdown; bestätigen Sie nicht innerhalb der Zeitspanne, macht es die Änderung rückgängig und stellt den vorherigen Zustand wieder her. Die Standard-Zeitspanne beträgt 120 Sekunden, anpassbar mit --timeout:

netplan try --timeout 90

Drücken Sie Enter, um die Änderung zu behalten, oder warten Sie und lassen Sie sie zurückrollen. Bricht Ihre neue Konfiguration die Verbindung ab, verlieren Sie die Sitzung, bestätigen nie, und zwei Minuten später hat der Server die funktionierende Konfiguration wiederhergestellt und Ihr SSH ist wieder erreichbar. Dieses automatische Zurückrollen ist der ganze Sinn des Befehls. Perfekt ist es nicht: Manche Änderungen mit Interface-Umbenennungen oder bestimmten Backend-Übergängen rollen nicht sauber zurück, und genau da zahlt sich ein Dedicated Server mit IPMI- oder iKVM-Konsole aus. Out-of-Band-Konsolenzugriff ist die Absicherung für den Tag, an dem try Sie nicht retten kann, und es lohnt sich, zu prüfen, dass Sie ihn haben, bevor Sie ihn brauchen.

Sobald das Netzwerk läuft, zeigt Ihnen netplan status, was das Backend mit Ihrer Konfiguration gemacht hat:

     Online state: online
    DNS Addresses: 192.0.2.53
       DNS Search: example.com

●  2: enp1s0 ethernet UP (networkd: enp1s0)
      MAC Address: 52:54:00:11:22:33
        Addresses: 192.0.2.10/24
                   2001:db8::10/64
           Routes: default via 192.0.2.1 (static)
                   default via 2001:db8::1 (static)

(Die Ausgabe ist ein Beispiel.) netplan status kam mit Version 0.106 hinzu. Ab 1.0 zeigt netplan status --diff zusätzlich, wo der laufende Zustand von Ihrem YAML abweicht, was der schnellste Weg ist, eine Konfiguration zu erwischen, die zwar generiert, aber nicht vollständig angewendet wurde.

Zwei weitere Befehle lesen und schreiben das zusammengeführte Modell, ohne dass Sie einen Editor öffnen müssen. netplan get gibt die aktuelle Konfiguration als YAML aus, und netplan set ändert einen einzelnen Wert über einen Punkt-Pfad:

netplan get ethernets.enp1s0.addresses
netplan set ethernets.enp1s0.dhcp4=false

netplan set schreibt standardmäßig nach /etc/netplan/90-netplan-set.yaml, was praktisch für Skripte ist und verwirrend, wenn Sie das vergessen; schauen Sie in diese Datei, wenn ein Wert aus dem Nichts auftaucht.

Spickzettel

Die Aufgaben, die immer wiederkehren, und das YAML-Fragment oder der Befehl für jede davon:

VLANs, Bonds und Bridges

Drei Konstrukte kommen auf Servern oft genug vor, um sie griffbereit zu haben. Jedes baut auf derselben Datei auf; die Interface-Typen bekommen jeweils ihren eigenen Top-Level-Block.

Ein tagged VLAN auf einem Uplink

Wenn Ihr Provider Ihnen ein tagged VLAN für ein privates Netzwerk bereitstellt, definieren Sie es als vlans-Eintrag, der über sein link auf die physische Schnittstelle verweist:

network:
  version: 2
  ethernets:
    enp1s0: {}
  vlans:
    enp1s0.100:
      id: 100
      link: enp1s0
      addresses:
        - 198.51.100.10/24

Die id ist der 802.1Q-Tag, und link benennt die übergeordnete Schnittstelle, die definiert bleibt (hier mit einem leeren {}), damit Netplan sie hochfährt. Untagged-Traffic nutzt weiterhin die übergeordnete Schnittstelle; tagged Frames für VLAN 100 laufen über die neue logische Schnittstelle.

Zwei NICs im LACP-Bond

Ein Bond fasst mehrere Links zu einer logischen Schnittstelle zusammen, für Bandbreite oder Redundanz. Modus 802.3ad ist LACP, und das erfordert eine passend konfigurierte Switch-Seite:

network:
  version: 2
  ethernets:
    eno1: {}
    eno2: {}
  bonds:
    bond0:
      interfaces: [eno1, eno2]
      addresses:
        - 192.0.2.20/24
      routes:
        - to: default
          via: 192.0.2.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100

LACP ist eine Vereinbarung zwischen zwei Seiten. Stecken die vorgelagerten Switch-Ports nicht in einer passenden LACP-Gruppe, kommt der Bond nicht hoch. Stimmen Sie sich also mit der Person ab, die den Switch verwaltet, bevor Sie das anwenden.

Eine Bridge für virtuelle Maschinen

Ist der Server ein KVM- oder LXD-Host, lässt eine Bridge die Guests die physische NIC teilen, als wären sie an einen Switch angeschlossen. Die Host-Adresse wandert auf die Bridge, und die physische Schnittstelle wird zu einem Bridge-Port ohne eigene Adresse:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp1s0]
      addresses:
        - 192.0.2.30/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.53]
      parameters:
        stp: false
        forward-delay: 0

Das ist dieselbe Idee, die Proxmox mit seinem vmbr0 umsetzt, falls Sie dem schon begegnet sind. Spanning-Tree und die Forward-Delay abzuschalten passt zu einer Host-Bridge mit einem einzelnen Uplink; lassen Sie beides nur an, wenn die Bridge mehrere physische Ports hat, die eine Schleife bilden könnten.

Wenn die Konfiguration nicht greift: Fehlerbehebung

Die meisten Netplan-Probleme lassen sich in wenige Kategorien einteilen.

YAML-Einrückung. Das YAML von Netplan nutzt Leerzeichen zur Einrückung und lehnt Tabs rundweg ab. Ein verirrter Tab oder eine uneinheitliche Einrückung erzeugt einen Parse-Fehler. Führen Sie nach jeder Änderung netplan generate aus: Es ist der günstigste Validator, den Sie haben, und es weigert sich, kaputte Konfiguration zu schreiben, statt sie anzuwenden.

Die Änderung wurde generiert, aber die Schnittstelle sieht falsch aus. Fragen Sie das Backend, was es getan hat, statt dem YAML zu vertrauen. ip addr und ip route zeigen die auf dem Link installierten Adressen und Routen; networkctl status enp1s0 zeigt die Sicht von systemd-networkd; resolvectl status zeigt die aktiven DNS-Server. Meldet netplan status --diff eine Lücke zwischen Ihrer Datei und dem laufenden Zustand, ist das Apply nicht vollständig durchgekommen, und einer dieser Befehle zeigt Ihnen, wo.

Ihre Änderungen verschwinden nach einem Neustart. Das ist das cloud-init-Überschreiben, die häufigste Überraschung auf einem Dedicated Server oder Cloud-Server. cloud-init erzeugt /etc/netplan/50-cloud-init.yaml beim Start aus seiner eigenen Datenquelle neu und überschreibt dabei alles, was es für sein Eigentum hält. Die unterstützte Lösung besteht darin, cloud-init einmalig mitzuteilen, die Netzwerkverwaltung einzustellen:

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

Danach lässt cloud-init /etc/netplan/ in Ruhe, und Ihre eigene Datei wird zur einzigen verbindlichen Quelle. Sie können 50-cloud-init.yaml anschließend löschen oder neu schreiben, und es bleibt so. Tun Sie das, bevor Sie Zeit in eine handgeschriebene Konfiguration investieren, nicht nachdem Sie zweimal denselben Neustart durchgekämpft haben.

Wenn Sie kein Netplan haben

Netplan ist ein Ubuntu-Standard, kein Linux-weiter. Bei der RHEL-Familie (RHEL, AlmaLinux, Rocky) und bei den meisten Desktop-Distributionen gibt es keine Netplan-Schicht: NetworkManager verwaltet Schnittstellen direkt, und Sie konfigurieren es mit nmcli, nmtui oder Connection-Dateien. Ist Ihr Bestand gemischt, behandelt der begleitende NetworkManager-Crashkurs diese Seite mit demselben Fokus auf Server.

Debian ist der Beinahe-Treffer. Das Paket netplan.io liegt in Debians Repositories, Sie können es also installieren und nutzen, aber Debian setzt es nicht standardmäßig ein; ein unveränderter Debian-Server konfiguriert das Netzwerk weiterhin über ifupdown und /etc/network/interfaces, oder über NetworkManager auf dem Desktop. Wenn Sie zwischen beiden abwägen, behandelt der Vergleich zwischen Ubuntu und Debian, wofür sich welches eignet, und der breitere Leitfaden zur Distributionswahl stellt Netplan-als-Standard den Alternativen gegenüber.

Bereitstellung auf Serverside

Netplan ist nur so nützlich wie das Netzwerk darunter. Ein Serverside Dedicated Server läuft auf unserem eigenen Netzwerk (AS55285), sodass die statischen IPv4- und IPv6-Adressen, die Sie in dieses YAML schreiben, hinter Routing liegen, das wir kontrollieren, mit permanenter DDoS-Mitigation vor der öffentlichen Schnittstelle. Die Bereitstellung dauert weniger als eine Minute: Ein frischer Ubuntu-Server steht in unter einer Minute, ein LTS-Image mit bereits vorhandenem Netplan, fertig, bevor Sie mit dem Entwurf der Konfiguration fertig sind, die darauf laufen soll.

Häufig gestellte Fragen

Was ist der Unterschied zwischen netplan apply und netplan try?

netplan apply erzeugt die Backend-Konfiguration neu und wendet sie sofort auf das laufende System an, ohne Rückweg, falls es dabei Ihre Verbindung kappt. netplan try wendet dieselbe Konfiguration an, startet aber einen 120-Sekunden-Countdown und macht die Änderung automatisch rückgängig, wenn Sie nicht mit Enter bestätigen. Greifen Sie auf einem Remote-Server zu try, sobald Sie etwas ändern, das die Verbindung betreffen könnte, über die Sie gerade verbunden sind, und heben Sie apply für Änderungen auf, bei denen Sie sich sicher sind oder die Sie von der Konsole aus vornehmen.

Warum verschwinden meine Netzwerkänderungen nach einem Neustart?

Fast immer cloud-init. Auf Cloud- und Dedicated-Server-Images erzeugt cloud-init /etc/netplan/50-cloud-init.yaml bei jedem Start neu aus seiner eigenen Datenquelle und überschreibt Änderungen, die es für sein Eigentum hält. Stoppen Sie das, indem Sie /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg mit dem Inhalt network: {config: disabled} anlegen und /etc/netplan/ danach selbst verwalten. Danach bleiben Ihre Dateien über Neustarts hinweg erhalten.

Wie lege ich DNS-Server in Netplan fest?

Fügen Sie der Schnittstelle einen nameservers-Block hinzu, mit einer addresses-Liste und optional einer search-Liste für Domains. Die Resolver greifen, sobald Sie netplan apply oder netplan try ausführen, und Sie können sie mit resolvectl status bestätigen. Auf systemd-networkd-Systemen übernimmt systemd-resolved die DNS-Auflösung, weshalb die von Ihnen gesetzten Server dort erscheinen und nicht direkt in /etc/resolv.conf.

Ist Netplan dasselbe wie NetworkManager?

Nein. Netplan ist eine Konfigurationsschicht, die Konfiguration für ein Backend erzeugt; NetworkManager ist eines der beiden Backends, die es ansteuern kann, das andere ist systemd-networkd. Ubuntu Server nutzt standardmäßig das networkd-Backend, Ubuntu Desktop nutzt NetworkManager, und beide werden über dieselbe Netplan-YAML gesteuert. Auf Systemen ohne Netplan, etwa Servern aus der RHEL-Familie, konfigurieren Sie NetworkManager stattdessen direkt.

Ich migriere von /etc/network/interfaces. Ersetzt Netplan das?

Ja, unter Ubuntu. Den alten ifupdown-Stack und seine Datei /etc/network/interfaces hat Netplan ersetzt, als Ubuntu es in 17.10 einführte. Sie bearbeiten nicht beides: Übertragen Sie jede iface-Stanza in den entsprechenden Netplan-ethernets-Eintrag mit Adresse, Routen und Nameservern, und lassen Sie Netplan die Backend-Konfiguration rendern. Debian nutzt standardmäßig weiterhin /etc/network/interfaces, ein Unterschied, mit dem Sie beim Wechsel zwischen beiden rechnen sollten.