Migration d'OpenVPN — De l'Access Server vers la version communautaire sur Proxmox
Après plusieurs années sous OpenVPN Access Server, j'ai décidé de simplifier mon infrastructure en migrant vers la version Communautaire sur une base Debian 13 (Trixie). L'objectif : plus de légèreté, une gestion totale des certificats et s'affranchir des limitations de licence, le tout dans un conteneur LXC sur Proxmox. C'était également l'occasion de me débarasser de mon seul conteneur sous ubuntu et homogénéiser le parc.
Voici le retour d'expérience et le guide technique pour réussir cette transition, notamment pour résoudre les erreurs de permissions spécifiques aux conteneurs non-privilégiés.
Pourquoi basculer ?
| Critère | Access Server | Communautaire |
|---|---|---|
| 🧠 RAM | ~500 Mo | < 100 Mo |
| 📦 Paquets | Propriétaires | 100% Open Source (Debian) |
| 🔒 Sécurité | Standard | Isolation renforcée, chiffrement granulaire |
| 📜 Licence | Limitée (2 connexions gratuites) | Aucune limite |
1. Préparation du terrain (Hôte Proxmox)
Pour faire tourner OpenVPN dans un conteneur LXC non-privilégié, il faut autoriser l'accès au périphérique TUN. Sur l'hôte Proxmox, éditez le fichier /etc/pve/lxc/ID.conf :
# Autoriser le périphérique TUN
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file 0 0
lxc.autodev: 1
Astuce cruciale
Sur les versions récentes de Proxmox, si vous obtenez une erreur Permission denied (errno=13), vérifiez les droits sur l'hôte :
2. Installation et Correctifs "Modernes"
L'installation a été réalisée avec le script de référence d'Angristan. Cependant, Debian 13 et OpenVPN 2.6+ introduisent des nouveautés qui peuvent bloquer la connexion dans un environnement virtualisé.
Désactivation du DCO (Data Channel Offload)
Le DCO tente d'accélérer le trafic via le noyau, mais il échoue souvent dans un conteneur LXC sans privilèges, provoquant une erreur AUTH_FAILED.
Dans /etc/openvpn/server.conf, ajoutez :
Ajustement des privilèges Systemd
Debian 13 renforce le sandboxing des services. Pour permettre à OpenVPN de manipuler l'interface réseau, créez un override du service :
systemctl edit [email protected]
[Service]
LimitNPROC=infinity
DeviceAllow=/dev/net/tun rw
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_NET_BIND_SERVICE
3. Accès au Réseau Local (LAN)
Pour que vos clients VPN voient vos serveurs internes, ajoutez la route dans la configuration serveur :
Et activez le forwarding IPv4 sur Debian :
Conclusion
La version communautaire demande un peu plus de configuration initiale que la version Access Server, mais elle offre une stabilité et une légèreté inégalées. Une fois les problématiques de permissions TUN et de DCO réglées, le tunnel est d'une fiabilité redoutable.
Conseils de débogage
- Testez toujours en 4G/5G pour éviter les problèmes de loopback de votre box internet.
- Surveillez vos logs en temps réel pour diagnostiquer les erreurs de négociation TLS :