UDP n’est pas toujours plus rapide : choisir le transport OpenVPN

Tous les guides affirment qu’UDP bat TCP pour OpenVPN, et ce conseil est un choix par défaut, pas une mesure. Le transport change la façon dont les paquets sont livrés et ce qui se passe quand le chemin les perd, pas la façon dont le tunnel est chiffré. Derrière un portail captif ou un proxy qui n’autorise que le port 443, l’option la plus lente est celle qui se connecte tout court. Ce qui suit sépare ce que fait le protocole de ce que permet votre réseau d’accès.

Ce que le transport change réellement

TCP fournit un flux d’octets fiable et ordonné et retransmet tout ce qui est perdu, comme le spécifie la RFC 9293. UDP remet des datagrammes au réseau, et OpenVPN exécute sa propre couche de fiabilité par-dessus ce socket. Encapsuler TCP dans TCP empile deux boucles de récupération, si bien qu’un seul segment perdu peut retenir le flux interne jusqu’à l’arrivée de la retransmission externe. Cette interaction est le véritable argument en faveur d’UDP, et elle se manifeste comme latence plutôt que comme débit.

L’effet croît avec les pertes et le temps d’aller-retour. Sur un chemin local propre, les deux transports semblent identiques, ce qui explique pourquoi un test en laboratoire reproduit rarement la plainte. Sur une liaison mobile congestionnée, la différence apparaît dans les sessions interactives bien avant qu’un gros transfert ne remarque quoi que ce soit.

Rien de tout cela ne touche la confidentialité ni l’intégrité. La poignée de main TLS et le chiffrement du canal de données sont les mêmes pour les deux transports, donc changer ne peut pas sauver une suite de chiffrement faible.

Là où TCP gagne sa place

Les réseaux d’accès sont la raison habituelle de choisir TCP. Un hôtel, un aéroport ou un réseau invité peut autoriser le 443 sortant et rejeter tout le reste, et un écouteur TCP sur ce port est le seul profil qui fonctionne. C’est de l’accessibilité, pas de la performance, et c’est une raison suffisamment bonne en soi.

TCP aide aussi lorsque le chemin est stable mais que les équipements intermédiaires sont hostiles. Certains réseaux réinitialisent les flux UDP de longue durée tout en tolérant des sessions TCP qui ressemblent à du trafic web ordinaire. Que cette ressemblance réussisse est une propriété du réseau concerné, et aucun guide ne peut le promettre pour tous. Testez à l’intérieur du réseau qui échoue avant d’accuser le protocole.

Une connexion refusée n’est pas un problème de transport. Désactiver la vérification du certificat pour forcer une connexion est un autre changement au résultat bien pire.

Garder un profil TCP prêt est le compromis pratique. La plupart des clients stockent les deux et vous laissent basculer quand un réseau refuse le chemin UDP, ce qui ne coûte rien tant que vous n’en avez pas besoin. Ce qu’il ne faut pas faire, c’est livrer deux profils pointant vers des points de terminaison différents, car votre comparaison mesure alors les serveurs.

Vérifiez quel écouteur vous avez réellement

Avant de comparer les performances, confirmez que les deux extrémités s’accordent sur le transport et le port. Remplacer proto udp par proto tcp dans un fichier client ne crée pas d’écouteur côté serveur. Le serveur doit être configuré pour ce protocole, et le profil doit y correspondre.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep affiche ce qu’on a dit au serveur d’utiliser, tandis que les deux listes de sockets montrent à quoi il est lié. Un écouteur UDP n’apparaît que dans la première liste et un écouteur TCP que dans la seconde, donc une ligne absente est le moyen le plus rapide de trouver un profil qui n’a jamais été appliqué. Comparez aussi le port, car un profil TCP sur 1194 se comporte différemment d’un profil sur 443 dans la plupart des réseaux d’accès. Redémarrez le service après la modification et lisez la ligne de journal qui signale la liaison.

La confirmation côté client est bon marché : lancez la connexion avec --verb 4 et lisez la ligne de transport dans le journal. Si le client annonce UDP alors que le serveur écoute en TCP, la poignée de main ne démarre jamais et aucun réglage n’aidera.

Comparez la charge de travail, pas l’étiquette du transport

Une comparaison équitable garde tout constant sauf le transport. Même appareil, même réseau d’accès, même hôte de destination, même application et idéalement même serveur. Si les deux profils pointent vers des hôtes différents, vous mesurez aussi ces hôtes.

Notez trois résultats par exécution : si le tunnel s’établit, s’il reste actif et si la tâche s’achève. Les petites requêtes qui fonctionnent alors que les gros transferts calent pointent vers la taille des paquets et le MTU, pas vers le transport. Les reconnexions répétées pointent vers le chemin ou un délai d’expiration d’un équipement intermédiaire.

Gardez le profil qui fonctionne dans les conditions que vous rencontrez réellement, et conservez l’autre. Le choix appartient au réseau, pas à la personne, et c’est pourquoi toute réponse par défaut unique est fausse quelque part.