WireGuard dans un LXC ou une VM sur Proxmox : où doit-il tourner ?

WireGuard a besoin d’exactement un noyau pour posséder son interface, et ce fait règle la majeure partie du débat sur l’emplacement dans Proxmox avant même que la performance n’entre dans la pièce. Un conteneur LXC est une vue d’espace de noms du noyau de l’hôte, tandis qu’une VM démarre le sien. La question utile n’est donc pas quelle option est la plus légère, mais quel noyau vous êtes prêt à modifier et avec quel chemin de récupération vous pouvez vivre. Répondez à cela, et le choix entre hôte, conteneur ou VM se fait généralement de lui-même.

Un invité LXC travaille à l’intérieur du noyau de l’hôte

Installer wireguard-tools dans un conteneur vous donne le programme de contrôle, pas un noyau privé. L’interface wg0 que vous créez est enregistrée dans la pile réseau de l’hôte et apparaît dans sa liste de modules. C’est pourquoi un conteneur peut passer toutes les vérifications de paquets et échouer tout de même à la première commande wg quand le noyau de l’hôte manque le module. Et la référence des conteneurs Proxmox documente ce modèle de noyau partagé, ainsi que les limites d’espace de noms et de privilèges dans lesquelles vous travaillez.

L’autorité est la seconde contrainte. Lever une interface et y attacher des adresses exige des droits d’administration réseau dans l’espace de noms qui la possède, et un conteneur non privilégié mappe ces droits via son espace de noms utilisateur au lieu de les détenir directement. Ne cherchez jamais le privilège complet comme première réponse ; regardez ce qu’on demande réellement au conteneur, puis accordez-le.

Le noyau de l’hôte est aussi une dépendance partagée. Une mise à jour du noyau Proxmox change l’implémentation de WireGuard sous chaque conteneur à la fois, ce qui est pratique jusqu’à ce qu’une mise à jour et les attentes d’un conteneur ne s’accordent plus.

Hôte, conteneur, VM : ce que possède réellement chaque emplacement

L’emplacement sur l’hôte place le VPN dans le réseau propre de l’hyperviseur. Les routes, les règles de pare-feu et le tunnel font partie de la récupération de l’hôte, et une erreur là-bas peut emporter l’interface de gestion. C’est acceptable pour du routage d’infrastructure sur un hôte auquel vous accédez par console, et douloureux sur une machine distante sans accès hors bande.

Un conteneur garde le service empaqueté et redémarrable tout en empruntant le noyau de l’hôte. Il convient à un service délibérément à noyau partagé et vous donne une petite unité à reconstruire. Il ne vous donne pas de noyau indépendant, donc tout ce qui exige une compilation de module spécifique pointe loin de cette option.

Une VM coûte plus de mémoire et un système de plus à corriger, et en échange le tunnel obtient son propre noyau, sa propre table de routage et une frontière d’instantané. Quand le VPN est ce que vous restaurez après un mauvais changement, cet instantané vaut la surcharge.

Trois conditions qui choisissent pour vous

Si le tunnel a besoin d’une version de noyau ou d’une fonction WireGuard que l’hôte Proxmox ne fournit pas, arrêtez-vous ici et utilisez une VM. Vous ne pouvez pas installer un noyau plus récent dans un conteneur, et vous ne devriez pas remplacer le noyau de l’hyperviseur pour satisfaire un seul invité.

Si le tunnel est la passerelle du site pour de vrais préfixes LAN, demandez qui possède déjà la route de retour. Un conteneur peut router le trafic, mais ses interfaces se trouvent dans la pile de l’hôte, donc l’hôte finit par porter une partie de la configuration, que vous l’ayez prévu ou non. L’emplacement sur l’hôte est honnête là-dessus ; l’emplacement en conteneur ne l’est souvent pas.

Pesez ensuite le rayon d’impact d’une erreur. Redémarrer un conteneur est bon marché, restaurer un instantané de VM est prévisible, et réparer le réseau de l’hôte peut exiger un accès physique ou console. Le bon choix est celui dont vous pouvez réellement récupérer le pire cas à l’heure où il se produit.

Une quatrième question est rarement décisive mais vaut la peine d’être posée : quelque chose d’autre sur l’hôte doit-il voir l’interface du tunnel ? Si oui, l’emplacement sur l’hôte ou en conteneur garde cette visibilité locale, tandis qu’une VM vous force à router entre l’invité et l’hôte.

Prouvez l’emplacement avant d’y router du trafic

Une fois installé, confirmez quel noyau sert réellement l’interface et si le conteneur a reçu assez d’autorité pour la garder :

$ 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

Vérifiez ensuite le côté transfert depuis l’hôte, car une poignée de main seule prouve uniquement que le tunnel est monté. Utilisez ip route get pour une adresse client et confirmez que le prochain saut et l’interface correspondent au design, et que le chemin de retour existe de l’autre côté.

Laissez le déploiement avec un propriétaire écrit : quel noyau porte l’implémentation, quel espace de noms tient l’interface et quels préfixes la passerelle est autorisée à transférer. Cette phrase évite plus d’incidents que n’importe quelle comparaison de référence des trois emplacements.