# Moderne Netzwerk-Konfiguration: Netplan & systemd-networkd

TL;DR / Management Summary Ubuntu hat die klassische /etc/network/interfaces durch Netplan ersetzt. Netplan ist ein Abstraktions-Layer, der YAML-Konfigurationen liest und diese für Backends wie systemd-networkd (Standard auf Servern) oder NetworkManager (Desktop) übersetzt. Vorteil: Deklarative Konfiguration, einfache Validierung und Unterstützung komplexer Topologien wie Bonding und Bridges ohne kryptische Syntax.

# 1. Einführung & Architektur

Warum YAML für das Netzwerk?

# Der Netplan Stack

Früher kochte jede Distribution ihr eigenes Süppchen bei der Netzwerkkonfiguration. Netplan vereinheitlicht dies für Ubuntu-basierte Systeme.

• Netplan: Der “Renderer”. Er generiert Konfigurationsdateien für die tieferliegenden Dämons.
• systemd-networkd: Der schlanke, performante Backend-Dämon, der die IP-Adressen, Routen und Links tatsächlich verwaltet.

graph TD
    A[YAML Files in /etc/netplan/*.yaml] --> B[Netplan Generator]
    B -->|Generates| C[systemd-networkd Config]
    B -->|Generates| D[NetworkManager Config]
    C --> E[Linux Kernel / Network Stack]

# 2. Grundkonfiguration

Einfache Setups schnell umgesetzt.

Netplan-Dateien liegen in /etc/netplan/. Meist heißt die Datei 00-installer-config.yaml oder 50-cloud-init.yaml.

# Beispiel: Statische IP-Adresse

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: no
      addresses:
        - 192.168.10.50/24
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      routes:
        - to: default
          via: 192.168.10.1

# 3. Fortgeschrittene Szenarien (Enterprise)

Bridges, Bonding und VLANs.

In Rechenzentren und Proxmox-Umgebungen reichen einfache IPs oft nicht aus.

# Beispiel: Network Bonding (LACP) & VLAN

Wenn wir zwei Netzwerkkarten für Redundanz bündeln und darauf VLANs legen wollen:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0: {}
    enp2s0: {}
  bonds:
    bond0:
      interfaces: [enp1s0, enp2s0]
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        transmit-hash-policy: layer3+4
  vlans:
    vlan10:
      id: 10
      link: bond0
      addresses: [10.10.10.5/24]

# Beispiel: Linux Bridge (für Virtualisierung)

Wenn der Server selbst LXC oder Docker-Container hostet und diese im gleichen Netz liegen sollen:

network:
  version: 2
  renderer: networkd
  bridges:
    br0:
      interfaces: [enp0s1]
      dhcp4: yes
      parameters:
        stp: false

# 4. Day-2 Operations: Änderungen anwenden

Die Angst vor dem Aussperren.

Netplan hat einen eingebauten Sicherheitsmechanismus, der Änderungen automatisch rückgängig macht, wenn man sie nicht bestätigt.

# Der “Try” Mechanismus

# Versuche die Konfiguration anzuwenden
sudo netplan try

Netplan wartet 120 Sekunden. Wenn Sie in dieser Zeit nicht ENTER drücken (z.B. weil Sie die Verbindung verloren haben), wird die alte Konfiguration wiederhergestellt. Nutzen Sie dies immer bei Remote-Arbeiten!

# Dauerhaft anwenden

sudo netplan apply

# Debugging & Status

# Aktuellen Status von systemd-networkd prüfen
networkctl status

# Details zu einem Interface
networkctl status enp0s1

# Generierte Dateien ansehen
ls /run/systemd/network/

# 5. Troubleshooting & “War Stories”

Wenn das Netzwerk schweigt.

# Story 1: “Default Route fehlt”

Symptom: Der Server kann lokale IPs pingen, kommt aber nicht ins Internet. Ursache: In Netplan wurde gateway4 benutzt (deprecated) oder die routes Sektion ist falsch eingerückt. Lösung: Nutzen Sie die moderne routes Syntax (wie im Beispiel unter Punkt 2). Prüfen Sie mit ip route, ob eine default via ... Zeile existiert.

# Story 2: “Netplan apply macht nichts”

Symptom: Die YAML-Datei wurde geändert, aber ip a zeigt noch die alten Daten. Ursache: Netplan überschreibt keine händisch mit ip addr add gesetzten Adressen. Oder es gibt einen Syntaxfehler, den apply verschluckt (selten). Lösung: sudo netplan --debug apply nutzen, um detaillierte Fehlermeldungen zu sehen. Manchmal hilft nur ein systemctl restart systemd-networkd.

# 6. Monitoring & Best Practices

• Validierung: Nutzen Sie netplan generate vor apply, um nur die Konfig zu erstellen ohne sie zu aktivieren. Wenn dies Fehler wirft, ist das YAML ungültig.
• Monitoring: Überwachen Sie den Status von systemd-networkd via Prometheus Node-Exporter. Suchen Sie nach “carrier drops” oder Fehlern in journalctl -u systemd-networkd.
• DNS: Denken Sie daran, dass systemd-resolved oft die DNS-Anfragen übernimmt. Wenn DNS nicht geht, prüfen Sie /etc/resolv.conf (sollte ein Symlink auf /run/systemd/resolve/stub-resolv.conf sein).

# Anhang: Cheatsheet