# Netplan Masterclass: YAML-Networking im Enterprise-Einsatz

TL;DR / Management Summary Netplan ist weit mehr als nur ein Ersatz für /etc/network/interfaces. Es ist eine deklarative Sprache für den gesamten Netzwerk-Stack. In diesem Deep Dive verlassen wir die Grundlagen und schauen uns an, wie man mehrere IP-Netze auf einem Interface verwaltet, Policy-Based Routing (PBR) implementiert und komplexe YAML-Strukturen für Automatisierung (Ansible/Terraform) vorbereitet.

# 1. Einführung & Architektur

YAML als Single Source of Truth.

Netplan agiert als Translator. Es validiert das YAML und schreibt Konfigurationsdateien für die Backends (/run/systemd/network/ für networkd).

# Renderer-Unterschiede

• networkd: Standard für Server. Schneller Boot, stabil, ideal für Headless-Systeme.
• NetworkManager: Standard für Desktops und Laptops (WLAN-Handling).

# 2. Die YAML-Syntax im Detail

Präzision in jeder Zeile.

# Mehrere IP-Adressen auf einem Interface

Früher brauchte man Interface-Aliase (eth0:1). In Netplan ist es eine einfache Liste:

network:
  version: 2
  ethernets:
    enp0s1:
      addresses:
        - 192.168.1.10/24    # Primäre IP
        - 10.0.0.10/8        # Management IP
        - "2001:db8::10/64" # IPv6

# 3. Fortgeschrittenes Routing

Policy-Based Routing & Metriken.

In Enterprise-Umgebungen hat ein Server oft zwei Gateways (z.B. Backup-Netz und Internet). Hier helfen Metriken und Routing-Tabellen.

# Beispiel: Zwei Gateways mit Metrik

network:
  version: 2
  ethernets:
    enp0s1: # Internet
      addresses: [192.168.1.10/24]
      routes:
        - to: default
          via: 192.168.1.1
          metric: 100
    enp0s2: # Internes Backup-Netz
      addresses: [10.0.0.10/24]
      routes:
        - to: 10.0.0.0/8
          via: 10.0.0.1
          metric: 200

# Policy-Based Routing (Routing Tables)

Wenn Traffic, der auf Interface B reinkommt, auch zwingend über Interface B antworten muss:

network:
  version: 2
  ethernets:
    enp0s2:
      addresses: [10.0.0.10/24]
      routing-policy:
        - from: 10.0.0.10
          table: 101
      routes:
        - to: default
          via: 10.0.0.1
          table: 101

# 4. Day-2 Operations: Validierung & Debugging

Keine Angst vor Syntax-Fehlern.

# Den Generator verstehen

Bevor Sie apply machen, schauen Sie sich an, was Netplan plant:

sudo netplan generate
# Prüfen der generierten Files
ls -R /run/systemd/network/

# Syntax-Check via Script

Wenn Sie Netplan-Files via CI/CD verteilen, nutzen Sie:

netplan set --root-dir=/tmp/test-env network.ethernets.eth0.dhcp4=true

Dies validiert die Syntax gegen das Schema, ohne das laufende System zu stören.

# 5. Troubleshooting & “War Stories”

Wenn das YAML nicht passt.

# Story 1: “Tab-Zeichen Albtraum”

Symptom: netplan apply bricht mit einer kryptischen Fehlermeldung in Zeile X ab. Ursache: Ein unbemerkter TAB statt Leerzeichen (oft durch Copy-Paste aus Webseiten). Lösung: Nutzen Sie einen Linter oder cat -A /etc/netplan/config.yaml. Tabulatoren erscheinen dort als ^I.

# Story 2: “MTU-Mismatch im VLAN”

Symptom: SSH geht, aber scp oder große HTTP-Requests hängen (Paketverlust). Ursache: Das VLAN-Tagging benötigt 4 Bytes. Wenn die physikalische Karte auf 1500 steht, ist das VLAN effektiv kleiner. Lösung: Setzen Sie die MTU explizit auf dem physikalischen Link hoch:

ethernets:
  enp0s1:
    mtu: 1504
vlans:
  vlan10:
    link: enp0s1
    id: 10
    mtu: 1500

# 6. Fazit & Empfehlung

• Versionierung: Speichern Sie Ihre Netplan-YAMLs in Git.
• Modularität: Nutzen Sie mehrere Dateien (z.B. 01-base.yaml, 99-custom-routes.yaml).
• Proxmox: In Proxmox-VMs ist Netplan ideal, um Cloud-Init Netzwerkdaten sauber abzubilden.

# Anhang: Cheatsheet