Vitesse des protocoles VPN : architecture et performances

La vitesse d’un protocole VPN n’est pas une question de “rapidité” affichée dans une interface, mais de structure interne :

  • niveau d’exécution (kernel ou userspace),
  • overhead d’encapsulation,
  • modèle cryptographique,
  • coût du handshake.

Ces éléments conditionnent également la fiabilité globale d’un VPN : un protocole inefficace génère mécaniquement plus de latence, des débits faibles et une stabilité réduite, même avec une infrastructure optimale.

 

Illustration : Vitesse des protocoles VPN expliquée

Deux protocoles peuvent utiliser la même connexion réseau et pourtant présenter des débits radicalement différents. Comprendre pourquoi WireGuard, IKEv2/IPsec ou OpenVPN n’offrent pas les mêmes résultats demande d’analyser leur architecture, pas des speedtests isolés.

La frontière kernel/userspace est un déterminant majeur : un protocole exécuté en espace utilisateur doit copier les données à chaque étape, ce qui ralentit mécaniquement le traitement des paquets.

Cette page détaille les mécanismes structurels qui déterminent la vitesse d’un protocole, puis les compare un par un.

Les facteurs structurels qui déterminent la vitesse d’un protocole VPN

1.1. Encapsulation et overhead

Chaque protocole encapsule les données en ajoutant des en-têtes, métadonnées ou informations cryptographiques. Cette surcharge, l’overhead, influence directement :

  • la taille des paquets,
  • la bande passante utile,
  • la fragmentation (si la MTU est dépassée),
  • la charge CPU associée.

Illustrations :

  • L2TP/IPsec : double encapsulation → overhead important (100+ octets).
  • OpenVPN : encapsulation TLS + métadonnées crypto → 70–90 octets typiques.
  • WireGuard : encapsulation unique → 32 à ~64 octets selon IPv4/IPv6.

Un protocole rapide est généralement un protocole dont l’encapsulation est courte, stable et prévisible.

1.2. Modèle cryptographique

Chiffrer et authentifier des paquets consomme du CPU. Le choix des algorithmes et leur mode d’intégration ont un impact direct.

Modèle flexible (OpenVPN, IPsec)

  • Large choix d’algorithmes.
  • Plus lourd : bibliothèques comme OpenSSL, négociations, multiples modes.
  • Risque de paramètres sous-optimaux (modes CBC, SHA1, négociations multiples).
  • Même avec AES-GCM et AES-NI, la flexibilité structurelle implique davantage de couches logicielles qu’un protocole minimaliste.

Modèle fixe et moderne (WireGuard®)

  • Suite unique : ChaCha20, Poly1305, Curve25519.
  • Optimisée pour CPU modernes et ARM.
  • Aucun coût de négociation.

Conséquence structurante : Les protocoles minimalistes saturent plus facilement un lien Gigabit ; les protocoles flexibles plafonnent plus bas, même avec un matériel puissant.

1.3. Handshake et mode d’exécution

Le temps d’établissement du tunnel influence la réactivité.

Un handshake rapide implique :

  • peu d’échanges (WireGuard, IKEv2),
  • dérivation simple des clés,
  • gestion explicite de la mobilité (MOBIKE) pour IKEv2 ; reconnexion rapide pour WireGuard.

Un handshake lent implique :

  • plusieurs allers-retours (IKEv1),
  • cryptographie lourde,
  • exécution en userspace, avec copies mémoire et transitions kernel ↔ application.

Analyse protocole par protocole : pourquoi les performances varient

2.1. WireGuard® : architecture nouvelle génération, latence minimale

WireGuard® a été conçu pour être simple, rapide et stable.

Caractéristiques clés

  • ~4 000 lignes de code (OpenVPN : 100k+).
  • Exécution dans le kernel : traitement direct sans copies mémoire.
  • Suite cryptographique fixe.
  • Encapsulation unique, overhead minimal.

Performances

  • Overhead : 32–64 octets (selon IPv4/IPv6).
  • Débit observé en conditions optimales : 700–950 Mbps.
  • Latence ajoutée : souvent <1 ms.

Limite structurelle : état persistant

WireGuard® stocke pour chaque pair :

  • sa clé publique,
  • son adresse IP interne,
  • son timestamp d’activité,

dans l’interface réseau du serveur.

Sans gestion active (rotation des clés, IP éphémères, NAT dynamique), cet état persistant peut permettre une corrélation d’activité. Lorsqu’elle est gérée correctement, cette particularité architecturale ne constitue pas un risque de sécurité.

2.2. IKEv2/IPsec : rapide, robuste, idéal en mobilité

IKEv2 est un protocole de négociation utilisé avec IPsec pour le chiffrement.

Forces structurelles

  • Handshake très court : 4 messages.
  • MOBIKE (Mobility and Multihoming) : reconnexion rapide lors d’un changement réseau.
  • Support natif sur Windows, iOS, Android, macOS.

Performances

  • Overhead : 50–70 octets.
  • Débits typiques :
    • 400–700 Mbps sur desktop,
    • 150–400 Mbps sur mobile (ARM sans AES-NI).

Limites

  • Sensible à la MTU avec NAT-T (UDP 4500).
  • Forte variabilité des implémentations (strongSwan, Windows, Cisco…).

2.3. OpenVPN : robuste mais structurellement limité

Pourquoi la vitesse est limitée

  • Exécution en userspace → copies mémoire constantes.
  • Dépendance à TLS/SSL → overhead élevé.
  • Flexibilité crypto → surcharge potentielle.
  • En mode TCP : double gestion de congestion (TCP-over-TCP) → meltdown.

Performances

UDP (recommandé)

  • Overhead : 70–90 octets.
  • Débits : 200–600 Mbps selon CPU et ciphers.

TCP (à éviter hors censure)

  • Avec 2 % de perte et 100 ms de latence, OpenVPN TCP peut descendre sous 50 Mbps.
  • Les deux couches TCP interprètent la perte comme une congestion, réduisent la fenêtre et retransmettent — provoquant une dégradation exponentielle.

Pourquoi il reste utilisé

  • Compatibilité exceptionnelle.
  • Audits publics nombreux.
  • Contrôle fin pour environnements complexes.

2.4. IPsec “pur” (ESP) : performant, mais complexe

IPsec est une suite modulaire :

  • ESP : chiffrement + authentification.
  • AH : authentification seule, ne traverse pas le NAT et n’est presque jamais utilisé dans les VPN commerciaux.

Performances

  • Overhead : 50–80 octets.
  • Débits : 400–600 Mbps sur matériel généraliste.
  • Les appliances spécialisées atteignent plusieurs Gbps grâce à l’offload matériel (ASICs, accélération AES-GCM).

Limites

  • Sensible à la MTU.
  • Configuration complexe → incohérences fréquentes.

2.5. L2TP/IPsec : double encapsulation, performances réduites

L2TP n’assure aucun chiffrement. Associé à IPsec, il produit :

  • une encapsulation L2TP,
  • une encapsulation + chiffrement IPsec.

Conséquences

  • Overhead très élevé : 100+ octets.
  • Fragmentation fréquente.
  • Débits réels souvent <150–300 Mbps.
  • Ports 500/1701/4500 souvent filtrés.

Usage aujourd’hui : compatibilité legacy uniquement.

Tableau comparatif technique

Protocole Overhead Espace Débit (conditions optimales) Points forts Limites structurelles
WireGuard 32–64 o Kernel 700–950 Mbps Minimalisme, faible latence État persistant (rotation clés/IP requise)
IKEv2/IPsec 50–70 o Kernel 400–700 Mbps / 150–400 mobile Mobilité, stabilité Implémentations hétérogènes, MTU sensible
OpenVPN UDP 70–90 o Userspace 200–600 Mbps Compatibilité, audits Copies mémoire, overhead TLS
OpenVPN TCP 90+ o Userspace Sous 50 Mbps en conditions dégradées Passage en HTTPS Congestion TCP-over-TCP (meltdown)
IPsec (ESP) 50–80 o Kernel 400–600 Mbps Offload matériel Complexité, MTU sensible
L2TP/IPsec 100+ o Mixte 150–300 Mbps Compatibilité legacy Double encapsulation, ports filtrés
Note : valeurs mesurées en conditions contrôlées (CPU récent, Gigabit, MTU intacte, serveur non saturé). Les performances réelles dépendent de l’infrastructure du fournisseur et de la qualité du réseau.

Conclusion

En termes de performance structurelle :

  • WireGuard est le plus rapide grâce au kernel, à l’overhead minimal et à sa crypto moderne.
  • IKEv2/IPsec offre un excellent compromis, surtout en mobilité.
  • OpenVPN UDP demeure robuste mais limité par son architecture userspace.
  • IPsec (ESP) peut offrir d’excellents débits avec offload matériel, mais reste complexe.
  • L2TP/IPsec est un protocole legacy pénalisé par la double encapsulation.

Ce classement reflète exclusivement les propriétés structurelles des protocoles, indépendamment des variations introduites par les infrastructures VPN ou les conditions réseau réelles.

Un protocole rapide est un prérequis structurel ; la performance finale dépendra toujours de l’implémentation logicielle et de l’architecture réseau du fournisseur.

Pages associées

Share This