Philosophie de design : deux approches opposées

WireGuard est construit sur la philosophie "cryptographic opinionated design" — les algorithmes cryptographiques sont fixés dans le protocole, sans négociation. Curve25519, ChaCha20-Poly1305, BLAKE2s, SipHash24 : pas de choix, pas de configuration. L'avantage est l'élimination des attaques par downgrade et des erreurs de configuration cryptographique. L'inconvénient est l'absence d'agilité cryptographique — si l'un de ces algorithmes est cassé, le protocole entier doit être remplacé.

OpenVPN délègue la cryptographie à OpenSSL, ce qui donne accès à l'ensemble des suites TLS disponibles — des plus sécurisées aux plus dépréciées. Cette flexibilité permet des configurations très solides, mais aussi des déploiements avec des suites faibles si l'administrateur ne fait pas attention. La validation formelle d'une configuration OpenVPN nécessite un audit de la configuration spécifique — pas seulement du protocole en général.

Couche d'implémentation : kernel vs user space

WireGuard est implémenté dans le kernel Linux depuis la version 5.6 (mars 2020). Le traitement des paquets se fait en espace noyau, sans copie vers l'espace utilisateur — ce qui élimine le surcoût de context switch et réduit la latence. Sur un serveur Linux moderne, WireGuard peut traiter plusieurs Gbps de trafic VPN avec une utilisation CPU significativement plus faible qu'OpenVPN.

OpenVPN tourne en espace utilisateur — chaque paquet doit traverser la frontière kernel/userspace deux fois (réception et envoi). Ce surcoût est mesurable et devient significatif à haut débit. Cependant, pour la majorité des déploiements (connexions résidentielles ou mobiles avec des débits inférieurs à 500 Mbps), la différence est imperceptible en usage réel.

Benchmark approximatif — flux de données
# Sur un serveur moderne (8 cœurs, 2.5 GHz, Linux 6.x)
# Chiffrement AES-NI activé pour les deux

WireGuard (kernel)  : ~3-4 Gbps  throughput, ~1-2%  CPU @ 1 Gbps
OpenVPN (userspace) : ~0.5-1 Gbps throughput, ~10-15% CPU @ 500 Mbps

# Ces chiffres varient fortement selon le matériel
# Pour des usages < 100 Mbps : différence négligeable

# Latence handshake initial :
WireGuard  : 1 RTT  # 2 messages
OpenVPN    : 2 RTT  # TLS 1.3 : 4 messages

Gestion des connexions mobiles

WireGuard est stateless par design côté serveur — un client peut changer d'adresse IP source et continuer d'envoyer des paquets sans renégocier le tunnel. Quand vous passez de Wi-Fi à 4G sur votre smartphone, WireGuard reprend immédiatement sans reconnexion visible. OpenVPN nécessite une reconnexion complète lors d'un changement d'IP, ce qui cause une interruption de quelques secondes.

Cette propriété rend WireGuard supérieur pour les usages mobiles. Sur les appareils desktop avec une connexion stable, la différence est inexistante.

Contournement de filtres réseau

OpenVPN sur TCP/443 est indiscernable du trafic HTTPS ordinaire pour un pare-feu stateless. Avec du traffic shaping ou une obfuscation supplémentaire (obfs4, Shadowsocks), il peut traverser des DPI (Deep Packet Inspection) sophistiqués. WireGuard sur UDP est détectable par fingerprinting — sa structure de paquet est distinctive. Certains fournisseurs ajoutent une couche d'obfuscation UDP (comme le protocole Stealth de Mullvad) mais ce n'est pas standard.

Pour un usage dans un environnement qui filtre activement les VPN, OpenVPN reste le choix robuste. Pour un usage standard, WireGuard est préférable.

Schéma — Comparaison de la pile réseau

WIREGUARD OPENVPN Application (navigateur, app...) Kernel network stack (IP, TCP/UDP) WireGuard (KERNEL MODULE) Curve25519 + ChaCha20-Poly1305 + BLAKE2s ~4000 lignes — intégré Linux 5.6+ Interface réseau physique (UDP) ✓ Traitement en kernel — pas de context switch ✓ 1 RTT handshake ⚠ UDP uniquement — filtrable ⚠ IPs clients dans kernel table Application (navigateur, app...) Kernel network stack (IP, TCP/UDP) Interface TUN/TAP (userspace ↔ kernel) OpenVPN DAEMON (USER SPACE) OpenSSL — suites négociées ~70 000 lignes — configurable Interface réseau physique (UDP ou TCP) ✓ TCP/443 — contournement filtres réseau ⚠ Context switch kernel/userspace à chaque paquet

Verdict selon le cas d'usage

Pour un déploiement personnel sur serveur Linux récent : WireGuard. Configuration plus simple, performances meilleures, surface d'attaque réduite. La limitation sur les logs kernel est gérée par la rotation régulière des clés si la confidentialité est critique. Pour un environnement derrière un pare-feu ou DPI qui filtre UDP : OpenVPN sur TCP/443. Pour une intégration enterprise avec des équipements réseau existants Cisco/Juniper : IKEv2/IPsec. Pour un service commercial grand public qui doit fonctionner partout : WireGuard par défaut avec fallback OpenVPN automatique.

Ces deux protocoles ont coexisté dans l'écosystème VPN depuis l'intégration de WireGuard dans le kernel. OpenVPN n'est pas obsolète — sa flexibilité et sa maturité en font un outil irremplaçable dans certains contextes. WireGuard n'est pas parfait — ses limitations sur les logs kernel et l'obfuscation UDP sont des contraintes réelles pour certains déploiements. Le choix dépend du contexte, pas d'un ranking absolu.