OpenVPN ou WireGuard ? Décider à partir de l'identité et du transport

Comparer ces deux protocoles n'a d'intérêt que si la comparaison porte sur ce que vous allez réellement exploiter. WireGuard identifie les pairs par clé publique et transporte son protocole sur UDP, tandis que OpenVPN offre un ensemble plus large de modes d'authentification et peut fonctionner sur UDP ou TCP lorsque le serveur propose les deux. Ces différences façonnent le provisionnement et la solution de repli bien avant de façonner le débit. Effectuez les quatre vérifications ci-dessous dans l'ordre ; les deux premières décident généralement du choix, et les deux dernières indiquent si la décision était juste.

Commencez par l'identité, pas par la liste des chiffrements

Un pair WireGuard stocke une clé privée et énumère les clés publiques qu'il peut joindre. Un fournisseur peut envelopper cela dans un portail de compte, mais le protocole lui-même n'échange ni nom d'utilisateur ni mot de passe, donc le cycle de vie du compte vit dans ce qui distribue les clés. OpenVPN peut utiliser des certificats, un greffon face à un annuaire existant ou un script de vérification, et c'est pourquoi les organisations disposant d'un système d'identité le préfèrent souvent. Aucune des deux conceptions n'élimine la question de savoir comment retirer un appareil perdu.

Une configuration courte n'est pas la même chose qu'un provisionnement simple. Confier une clé privée à plusieurs personnes rend le retrait ultérieur ambigu, car la révoquer les retire toutes à la fois. Écrivez la correspondance entre personne et clé ou certificat avant de choisir, et la décision sur le protocole devient nettement plus simple.

Regardez ensuite ce que le transport autorise

Le protocole de WireGuard utilise UDP. Les services OpenVPN peuvent proposer des profils UDP et TCP, et sur un réseau qui bloque ou dégrade UDP cette seconde option est une solution de repli pratique et non théorique. Le serveur doit prendre en charge le profil que vous choisissez, et changer un numéro de port ne transforme pas le tunnel en HTTPS ni ne convainc un pare-feu de l'autoriser.

Faire passer du TCP dans du TCP change aussi le comportement en cas de perte, car les deux couches réessaient et réordonnent indépendamment. Un profil TCP qui fonctionne sur un réseau restrictif peut rester médiocre sur un réseau avec pertes, et c'est une raison de garder les deux profils disponibles plutôt que de déclarer l'un supérieur.

Vérifiez ensuite le routage et la résolution de noms

AllowedIPs de WireGuard associe des plages d'adresses aux pairs et agit comme une décision de routage à l'intérieur du protocole, et les outils environnants utilisent ces plages lorsqu'ils installent des routes. OpenVPN pousse les routes et les options DNS depuis le serveur. Dans les deux cas, le client peut monter alors que la politique prévue n'est appliquée qu'à moitié.

ip route show
ip -6 route show
resolvectl status
wg show

Lisez la sortie avant de faire confiance à l'indicateur de connexion. ip route show énumère ce que le client a installé pour IPv4, et la variante IPv6 détecte un tunnel qui ne transporte qu'une seule famille. resolvectl status montre quel résolveur le client interrogera réellement, et wg show imprime les AllowedIPs que WireGuard croit posséder. Si le résolveur pointe encore vers le réseau local alors que les routes revendiquent une couverture complète, le DNS sort du tunnel.

Mesurez ensuite la tâche qui vous importe

Gardez l'appareil, le réseau et la destination fixes, et notez les clients et les points de terminaison utilisés. Si les deux services sortent dans des villes différentes ou tournent sur du matériel différent, dites-le, car le résultat décrit alors ces services et non les protocoles.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

Exécutez les deux commandes deux fois, une fois par paire de profils, sur le même réseau et le même appareil. iperf3 donne un chiffre de débit, et mtr donne le chemin et l'endroit où les pertes apparaissent, ce qu'un simple chiffre de téléchargement ne peut pas montrer. Un chiffre de téléchargement manque aussi ce qu'un appel remarque : la latence ajoutée, la gigue et la durée d'une reconnexion. Notez-les séparément, car un protocole qui gagne en débit peut encore perdre sur la tâche que vous exécutez réellement.

Pour une connexion gérée, la compatibilité, le support et l'effort de renouvellement peuvent peser plus qu'un petit écart de mesure. Pour une sortie personnelle, la journalisation et la juridiction de l'opérateur comptent plus que l'étiquette du protocole. Les deux protocoles peuvent porter une bonne connexion ; le service et sa configuration décident de ce que vous obtenez.

Notez la paire de profils avant de tester

Choisissez un profil par protocole avant de mesurer et notez ce que chacun est censé faire : sous-réseaux privés uniquement, ou tout le trafic avec une sortie précise. Un test qui compare un profil à tunnel divisé avec un profil à tunnel complet mesure les profils, pas les protocoles. Mettez le nom du client, la version du client et l'emplacement de sortie dans la même note.

Exécutez ensuite la même tâche sur les deux, sur le même réseau, dans la même session. Si l'un échoue totalement à se connecter, cet échec est le résultat et appartient au compte rendu avec la raison. Conservez le compte rendu avec la documentation du service afin que la personne suivante compare la même paire plutôt que de repartir de zéro.