WireGuard in LXC oder einer VM auf Proxmox: Wo soll es laufen?

WireGuard braucht genau einen Kernel, dem seine Schnittstelle gehört, und diese Tatsache entscheidet den größten Teil der Proxmox-Platzierungsdebatte, bevor Performance überhaupt ins Spiel kommt. Ein LXC-Container ist eine Namespace-Sicht des Host-Kernels, während eine VM ihren eigenen bootet. Die nützliche Frage ist also nicht, welche Option leichter ist, sondern welchen Kernel man bereit ist zu verändern und mit welchem Wiederherstellungsweg man leben kann. Beantwortet man das, entscheidet sich die Wahl zwischen Host, Container und VM meist von selbst.

Ein LXC-Gast arbeitet innerhalb des Host-Kernels

Die Installation von wireguard-tools in einem Container liefert das Steuerprogramm, keinen privaten Kernel. Die Schnittstelle wg0, die man anlegt, wird im Netzwerk-Stack des Hosts registriert und erscheint in dessen Modulliste. Deshalb kann ein Container jede Paketprüfung bestehen und trotzdem beim ersten Befehl wg scheitern, wenn dem Host-Kernel das Modul fehlt. Und die Proxmox-Container-Referenz dokumentiert dieses Modell des geteilten Kernels samt den Namespace- und Rechtegrenzen, innerhalb derer man arbeitet.

Die zweite Einschränkung ist die Befugnis. Eine Schnittstelle hochzubringen und Adressen anzuhängen erfordert Netzwerkadministrationsrechte innerhalb des Namespace, dem sie gehört, und ein unprivilegierter Container bildet diese Rechte über seinen User-Namespace ab, statt sie direkt zu halten. Greife nie als erstes nach vollen Rechten; schau, was dem Container tatsächlich abverlangt wird, und gewähre genau das.

Der Host-Kernel ist zudem eine gemeinsame Abhängigkeit. Ein Proxmox-Kernel-Update ändert die WireGuard-Implementierung unter jedem Container gleichzeitig, was praktisch ist, bis ein Update und die Erwartungen eines Containers nicht mehr zusammenpassen.

Host, Container, VM: was jede Platzierung wirklich besitzt

Die Platzierung auf dem Host legt das VPN in das eigene Netzwerk des Hypervisors. Routen, Firewall-Regeln und der Tunnel werden Teil der Host-Wiederherstellung, und ein Fehler dort kann die Management-Schnittstelle mitnehmen. Das ist vertretbar für Infrastruktur-Routing auf einem Host, den man über eine Konsole erreicht, und schmerzhaft auf einer entfernten Maschine ohne Out-of-Band-Zugang.

Ein Container hält den Dienst paketiert und neu startbar, während er weiterhin den Host-Kernel ausleiht. Er passt zu einem bewusst geteilten Kernel-Dienst und gibt eine kleine Einheit zum Neuaufbau. Einen unabhängigen Kernel gibt er nicht, daher deutet alles, was einen bestimmten Modul-Build braucht, weg von dieser Option.

Eine VM kostet mehr Speicher und ein weiteres zu patchendes System, und dafür bekommt der Tunnel einen eigenen Kernel, eine eigene Routing-Tabelle und eine Snapshot-Grenze. Wenn das VPN das ist, was man nach einer schlechten Änderung zurückrollt, ist dieser Snapshot den Aufwand wert.

Drei Bedingungen, die für einen wählen

Braucht der Tunnel eine Kernel-Version oder eine WireGuard-Funktion, die der Proxmox-Host nicht mitbringt, ist hier Schluss, dann eine VM. Einen neueren Kernel kann man nicht in einen Container installieren, und man sollte den Hypervisor-Kernel nicht ersetzen, um einen einzelnen Gast zufriedenzustellen.

Ist der Tunnel das Gateway des Standorts für echte LAN-Präfixe, fragt man, wer die Rückroute bereits besitzt. Ein Container kann Verkehr routen, aber seine Schnittstellen liegen im Stack des Hosts, also trägt der Host am Ende einen Teil der Konfiguration, ob geplant oder nicht. Die Platzierung auf dem Host ist darin ehrlich; die Platzierung im Container oft nicht.

Dann den Sprengradius eines Fehlers abwägen. Einen Container neu zu starten ist billig, einen VM-Snapshot zurückzuholen ist vorhersehbar, und die Reparatur des Host-Netzwerks kann physischen oder Konsolenzugang verlangen. Die richtige Wahl ist jene, deren schlimmsten Fall man zu der Stunde, in der er eintritt, wirklich wiederherstellen kann.

Eine vierte Frage ist selten entscheidend, aber erwähnenswert: Muss etwas anderes auf dem Host die Tunnelschnittstelle sehen? Wenn ja, hält die Platzierung auf dem Host oder im Container diese Sichtbarkeit lokal, während eine VM einen zwingt, zwischen Gast und Host zu routen.

Beweise die Platzierung, bevor du Verkehr hindurchleitest

Nach der Installation prüfe, welcher Kernel die Schnittstelle tatsächlich bedient und ob dem Container genug Befugnis gegeben wurde, sie zu behalten:

$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
  listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0

Dann prüfe die Weiterleitungsseite vom Host aus, denn ein Handshake allein beweist nur, dass der Tunnel steht. Nimm ip route get für eine Client-Adresse und bestätige, dass nächster Hop und Schnittstelle dem Entwurf entsprechen und der Rückweg auf der Gegenseite existiert.

Hinterlasse das Deployment mit einem schriftlichen Eigentümer: welcher Kernel die Implementierung trägt, welcher Namespace die Schnittstelle hält und welche Präfixe das Gateway weiterleiten darf. Dieser Satz verhindert mehr Vorfälle als jeder Benchmark-Vergleich der drei Platzierungen.