Ifupdown2 in der Praxis: Unterschied zwischen den Versionen
Neuer Artikel: ifupdown2, SDN-Praxisfall |
Praxisfall korrigiert: Eintrag war in interfaces, Apply hat ihn entfernt |
||
| Zeile 73: | Zeile 73: | ||
== Praxisfall: eine Adresse fehlt in der Konfiguration == | == Praxisfall: eine Adresse fehlt in der Konfiguration == | ||
Auf einem Proxmox-Host lief eine IPv6-Adresse auf einer SDN-verwalteten VLAN-Bridge, die aber | Auf einem Proxmox-Host lief eine IPv6-Adresse auf einer SDN-verwalteten VLAN-Bridge, die aber in keiner Konfigurationsdatei mehr auftauchte. Sie war ursprünglich ordentlich in <code>/etc/network/interfaces</code> eingetragen worden – stand dort aber irgendwann nicht mehr drin, lief auf dem Interface selbst jedoch munter weiter. Proxmox zeigte darum in der Weboberfläche für die ganze SDN-Zone einen roten Fehler. | ||
Die wahrscheinlichste Erklärung für das Verschwinden: Unter ''Node → Network'' schreibt Proxmox bei jedem Klick auf "Apply Configuration" die Datei <code>/etc/network/interfaces</code> komplett neu – und zwar nur aus seiner eigenen Liste bekannter Interfaces (die physischen NICs, Bonds, die Haupt-Bridge). Eine von SDN zur Laufzeit erzeugte VLAN-Bridge wie <code>vmbr0vXXXX</code> gehört nicht zu dieser Liste. Ein von Hand ergänzter Eintrag für so eine Bridge übersteht darum das nächste "Apply" in diesem Dialog nicht, selbst wenn er vorher jahrelang anstandslos funktioniert hat. | |||
Der Befund mit <code>ifquery --check</code>: | Der Befund mit <code>ifquery --check</code>: | ||
| Zeile 91: | Zeile 93: | ||
=== Die Lösung: eine eigene Datei, nicht die verwaltete === | === Die Lösung: eine eigene Datei, nicht die verwaltete === | ||
Proxmox | Zwei Proxmox-Dialoge schreiben Netzwerkdateien komplett neu und sind damit als Ablageort für eigene Einträge ungeeignet: ''Node → Network'' mit "Apply Configuration" erzeugt <code>/etc/network/interfaces</code> neu (nur aus seiner eigenen Geräteliste), und die SDN-Oberfläche erzeugt bei ihrem "Apply" <code>/etc/network/interfaces.d/sdn</code> neu. Ein Eintrag von Hand in einer der beiden Dateien übersteht den nächsten Klick auf "Apply" im jeweiligen Dialog nicht – ganz gleich, wie lange er vorher anstandslos lief. | ||
Die Hauptdatei <code>/etc/network/interfaces</code> liest aber alle Dateien in <code>/etc/network/interfaces.d/</code> ein: | Die Hauptdatei <code>/etc/network/interfaces</code> liest aber alle Dateien in <code>/etc/network/interfaces.d/</code> ein: | ||
Aktuelle Version vom 25. Oktober 2026, 17:48 Uhr
ifupdown2 ist das Werkzeug, mit dem Debian und Proxmox VE die Netzwerkschnittstellen aus /etc/network/interfaces aufbauen. Es ist der Nachfolger des klassischen ifupdown-Pakets und bringt zwei Dinge mit, die im Praxisbetrieb viel wert sind: Teiländerungen am Netz ohne Verbindungsabbruch, und eine Prüfung, ob die laufende Konfiguration noch zu dem passt, was in den Dateien steht.
Woher es kommt
Debian bringt standardmäßig weiter das alte ifupdown mit. ifupdown2 liegt seit Debian 10 als eigenes Paket in den Repos, ist aber nicht vorinstalliert:
apt install ifupdown2
Dabei wird das klassische ifupdown automatisch entfernt, denn beide vertragen sich nicht parallel.
Proxmox VE setzt ifupdown2 dagegen von Haus aus ein, mit einem eigenen Fork (Paketname ifupdown2, Versionszusatz +pmxNN). Der Grund: Proxmox baut darauf seine SDN-Funktion (Software Defined Networking) auf, die VLANs und virtuelle Netze live über die Oberfläche verwaltet.
Installation auf einem normalen Debian
Vor der Installation prüfen, was gerade läuft:
dpkg -l | grep -E "ifupdown2?\b"
systemctl status networking
Die Installation selbst ist ein einziger Befehl:
apt update
apt install ifupdown2
Dabei entfernt apt automatisch das alte ifupdown-Paket (die beiden können nicht gleichzeitig installiert sein) und übernimmt die bestehende /etc/network/interfaces unverändert – die Syntax ist weitgehend kompatibel.
Vorsicht bei einem entfernten Server (SSH): Der Wechsel selbst reißt die Verbindung normalerweise nicht ab, weil ifupdown2 beim Einrichten die aktuell aktiven Schnittstellen übernimmt, statt sie neu aufzubauen. Trotzdem gilt wie bei jeder Netzwerkänderung aus der Ferne: vorher eine Konsole bereithalten (IPMI, Hypervisor-Konsole, physischer Zugang), falls /etc/network/interfaces Fehler enthält, die erst beim nächsten ifreload oder Neustart auffallen.
Nach der Installation die Probe aufs Exempel:
ifquery --check -a # alle Schnittstellen auf einen Blick
ifreload -a # übernimmt Änderungen, ohne unveränderte Schnittstellen anzufassen
Wer ganz sichergehen will, plant den ersten ifreload -a in einem Wartungsfenster und hat eine zweite Zugangsmöglichkeit parat.
Auf Proxmox VE ist ifupdown2 schon Teil der Standardinstallation, dort ist nichts weiter zu tun.
Die wichtigsten Befehle
| Befehl | Zweck |
|---|---|
ifup / ifdown |
einzelne Schnittstelle hoch- bzw. herunterfahren |
ifreload -a |
alle Schnittstellen neu einlesen, nur das anwenden, was sich geändert hat – kein harter Netz-Neustart |
ifquery <iface> |
zeigt, was für diese Schnittstelle konfiguriert ist |
ifquery --check <iface> |
vergleicht Konfiguration gegen den tatsächlich laufenden Zustand |
Der letzte Befehl ist im Alltag der nützlichste. Ein Beispiel von einem funktionierenden Proxmox-Bridge-Interface:
# ifquery --check vmbr0v3233
auto vmbr0v3233
iface vmbr0v3233 [pass]
bridge-ports bond0.3233 pr_vlan3233 (tap5008i9) [pass]
bridge-fd 0 [pass]
bridge-stp no [pass]
Jede Zeile wird einzeln geprüft und mit [pass] oder [fail] markiert. Das ist weit genauer als ein bloßes "Interface ist up".
Praxisfall: eine Adresse fehlt in der Konfiguration
Auf einem Proxmox-Host lief eine IPv6-Adresse auf einer SDN-verwalteten VLAN-Bridge, die aber in keiner Konfigurationsdatei mehr auftauchte. Sie war ursprünglich ordentlich in /etc/network/interfaces eingetragen worden – stand dort aber irgendwann nicht mehr drin, lief auf dem Interface selbst jedoch munter weiter. Proxmox zeigte darum in der Weboberfläche für die ganze SDN-Zone einen roten Fehler.
Die wahrscheinlichste Erklärung für das Verschwinden: Unter Node → Network schreibt Proxmox bei jedem Klick auf "Apply Configuration" die Datei /etc/network/interfaces komplett neu – und zwar nur aus seiner eigenen Liste bekannter Interfaces (die physischen NICs, Bonds, die Haupt-Bridge). Eine von SDN zur Laufzeit erzeugte VLAN-Bridge wie vmbr0vXXXX gehört nicht zu dieser Liste. Ein von Hand ergänzter Eintrag für so eine Bridge übersteht darum das nächste "Apply" in diesem Dialog nicht, selbst wenn er vorher jahrelang anstandslos funktioniert hat.
Der Befund mit ifquery --check:
# ifquery --check vmbr0v3240
auto vmbr0v3240
iface vmbr0v3240 [fail]
bridge-ports bond0.3240 pr_vlan3240 (tap5008i1) [pass]
bridge-fd 0 [pass]
bridge-stp no [pass]
address 2001:db8:f240::aaaa/64 [fail]
Die Adresse lief, war aber nicht deklariert – ifquery hat genau das aufgedeckt, Zeile für Zeile.
Die Lösung: eine eigene Datei, nicht die verwaltete
Zwei Proxmox-Dialoge schreiben Netzwerkdateien komplett neu und sind damit als Ablageort für eigene Einträge ungeeignet: Node → Network mit "Apply Configuration" erzeugt /etc/network/interfaces neu (nur aus seiner eigenen Geräteliste), und die SDN-Oberfläche erzeugt bei ihrem "Apply" /etc/network/interfaces.d/sdn neu. Ein Eintrag von Hand in einer der beiden Dateien übersteht den nächsten Klick auf "Apply" im jeweiligen Dialog nicht – ganz gleich, wie lange er vorher anstandslos lief.
Die Hauptdatei /etc/network/interfaces liest aber alle Dateien in /etc/network/interfaces.d/ ein:
source /etc/network/interfaces.d/*
Eine zusätzliche, eigene Datei mit anderem Namen bleibt von SDN unberührt und ergänzt dieselbe Schnittstelle nur um eine weitere Adressfamilie:
# /etc/network/interfaces.d/custom-vmbr0v3240
iface vmbr0v3240 inet6 static
address 2001:db8:f240::aaaa/64
Kein ifreload nötig, um das zu prüfen – ifquery --check liest die Dateien einfach neu ein:
# ifquery --check vmbr0v3240
iface vmbr0v3240 inet6 static [pass]
address 2001:db8:f240::aaaa/64 [pass]
auto vmbr0v3240
iface vmbr0v3240 [pass]
bridge-ports bond0.3240 pr_vlan3240 (tap5008i1) [pass]
bridge-fd 0 [pass]
bridge-stp no [pass]
Alles auf [pass], und die Adresse übersteht jetzt auch einen Neustart des Hosts, ohne dass ein künftiges SDN-"Apply" sie wieder löscht.
Merksatz
Wer auf einem Proxmox- oder Debian-System mit ifupdown2 eine Schnittstelle von Hand ergänzen will, die auch von einem automatischen System (SDN, einem Konfigurationswerkzeug, einem Skript) verwaltet wird: niemals in die verwaltete Datei schreiben, sondern eine eigene Datei danebenlegen. ifquery --check zeigt zuverlässig, ob am Ende alles zusammenpasst.