Pourquoi mon VPN est-il si lent ? Testez ces quatre segments

Un appel qui saccade, un téléchargement qui rampe et un envoi qui se fige à mi-chemin sont trois plaintes différentes sous une même étiquette. Décider laquelle vous poursuivez avant de mesurer quoi que ce soit épargne le reste de l’enquête. Changez ensuite un segment du chemin à la fois et répétez la même tâche ensuite.

L’ordre ci-dessous part de la tâche vers l’extérieur, car le tunnel ne peut pas fournir une bande passante qui manque en dessous.

Décidez ce que lent veut dire avant de mesurer

Un débit faible et régulier, une latence élevée avec des pics nets et un transfert qui s’arrête net à une taille fixe ne sont pas des variantes d’une même panne. Chacun pointe vers un segment différent : le débit, le chemin lui-même ou une limite de taille de paquet. Choisissez la tâche qui vous gêne vraiment et servez-vous en comme référence, car un test de débit mesure un transfert massif qui peut se comporter très différemment d’un appel vidéo. Notez le point de terminaison, le protocole, l’heure de la journée et le nombre qui compte pour vous.

Sans ce relevé, chaque comparaison ultérieure devient une discussion sur des impressions.

Vérifiez d’abord le réseau d’accès

Mettez en pause vos propres transferts volumineux, puis mesurez la liaison locale avant que le tunnel n’intervienne. Comparez avec une tâche inoffensive et suivez la procédure de kill switch du client au lieu de désactiver plusieurs protections à la fois, et gardez la même destination pour les deux exécutions. Un fournisseur de test de débit peut vous attribuer un autre serveur de mesure dès que votre position visible change, ce qui transforme la comparaison en test de deux serveurs différents.

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

Si la ligne de base est déjà mauvaise, le travail revient au Wi-Fi, à la demande du routeur ou au service d’accès. Un test filaire ou une position fixe près du point d’accès sépare une liaison radio faible d’un lien montant encombré. Rien de ce que fait le tunnel n’ajoutera de capacité que la ligne d’accès ne fournit pas.

Changez la sortie, puis le transport

Gardez l’appareil, le réseau et le protocole fixes et testez un second point de terminaison. Choisissez une ville plausible dans la liste des emplacements, mais ne supposez pas que l’étiquette la plus proche signifie la meilleure route. Si une sortie est lente et que les autres vont bien, son hôte ou son chemin mérite l’enquête ; si toutes les sorties sont lentes sur un appareil alors qu’un autre appareil va bien, le client est le meilleur suspect.

Là où le service fournit les deux profils, comparez OpenVPN en UDP avec OpenVPN en TCP. L’UDP est le point de départ habituel pour le travail interactif, tandis que le TCP peut aider sur un réseau d’accès qui ne fait pas du tout passer le trafic UDP. Un tunnel TCP récupère les pertes en retransmettant à l’intérieur du flux, ce qui explique qu’il puisse sembler plus lent sur une liaison qui perd des paquets, et les notes de dépannage des performances OpenVPN couvrent le même compromis avant que vous ne régliez autre chose. Remplacer le mot « udp » par « tcp » dans un profil ne peut pas créer un écouteur que le serveur n’a jamais ouvert.

Enregistrez le profil qui aide avant d’essayer le changement suivant. Sinon, une régression ultérieure vous laisse deviner quelle modification a produit l’amélioration.

Lisez l’appareil et le symptôme ensemble

Surveillez la charge du processeur pendant le transfert plutôt qu’après, car le coût du chiffrement augmente avec le trafic et un petit routeur au service d’un foyer est une autre machine qu’un ordinateur portable exécutant son propre client. Un autre VPN, une machine virtuelle ou un filtre réseau peuvent se trouver sur le même chemin et prendre une part du trafic. Gardez le logiciel à jour sans supprimer les contrôles d’authentification ni un kill switch pour faire paraître un banc d’essai meilleur. Si les petites requêtes réussissent et que les gros envois s’arrêtent à une taille constante, le contrôle du MTU est l’étape suivante.

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

Lorsque le tunnel se réinitialise à répétition, corrigez les déconnexions avant d’interpréter le moindre chiffre de débit, car un tunnel qui se reconnecte mesure la poignée de main et non le chemin. Répétez la tâche d’origine après chaque changement et conservez le résultat. Un test de débit plus rapide qui casse encore l’appel n’a pas résolu la plainte avec laquelle vous avez commencé.