Votre Wi-Fi ralentit-il le VPN ? Vérifiez la liaison locale

La plupart des gens accusent le serveur des saccades causées par la radio, et le remède qu'ils choisissent rend le diagnostic suivant plus difficile. Une icône de signal pleine dit que le point d'accès parle fort, pas que le canal est calme ni que le temps d'antenne est libre. Les problèmes sans fil arrivent au tunnel sous forme de retard, de perte et de réordonnancement, et le client signale les trois comme un seul problème de connexion vague.

La question utile est de savoir si le même tunnel se comporte différemment sur une autre liaison locale. Tout le reste reste fixe pendant que vous y répondez.

Les barres de signal mesurent la puissance, pas le temps d'antenne disponible

Le niveau de signal reçu indique avec quelle force le client entend le point d'accès, et ce chiffre peut rester élevé alors que le débit s'effondre. Le temps d'antenne est partagé avec les réseaux voisins, avec d'autres clients de votre propre réseau et avec le trafic de gestion que la radio doit émettre au débit le plus lent que chaque participant comprend. Les murs, le métal et la position du corps changent le trajet, tout comme la disposition de l'antenne dans un portable. Rien de cela n'apparaît dans l'icône.

Les compteurs de réessai sont la preuve privée la plus claire, car une trame qui a demandé trois tentatives compte toujours comme livrée. Une liaison qui annonce un débit sain tout en réessayant fortement fera paraître un tunnel temps réel comme cassé.

Le choix de la bande est un compromis, pas un remède, quoi qu'ait affirmé la rubrique conseils. Un canal 5 GHz rencontre généralement moins d'interférences et couvre moins de distance, tandis que 2.4 GHz va plus loin dans un bâtiment et rencontre plus de voisins. Choisissez la bande pour la distance dont vous avez réellement besoin, et notez le réglage précédent pour qu'une expérience ratée puisse être annulée.

Changez une variable, puis regardez de nouveau

Gardez le profil VPN, le point de terminaison, la destination et l'heure de la journée fixes pendant que vous changez la liaison locale. Comparez la même tâche près du point d'accès, depuis la pièce éloignée et en Ethernet sur la même machine. Si le passage filaire est propre et que les deux passages sans fil ne le sont pas, le segment radio a gagné sa place en tête de liste.

Passer d'un point d'accès à l'autre est une expérience à part, et sur un maillage c'est celle que les gens sautent. L'itinérance peut suspendre un tunnel, forcer un nouvel échange de clés ou laisser une session vivante alors que les paquets cessent de circuler. Notez l'heure de chaque interruption et comparez-la à l'entrée du journal client pour le changement d'association. Une pause qui coïncide avec une itinérance n'est pas un serveur surchargé, même si elle en a tout l'air.

Un canal occupé se fait passer pour un serveur lent

D'autres appareils se disputent le même temps d'antenne, et votre gros envoi concurrence votre propre appel. Mettez en pause les transferts facultatifs et répétez la tâche avant de conclure quoi que ce soit sur le fournisseur. File d'attente sous charge produit exactement le symptôme que les gens appellent VPN qui ralentit : retard croissant, livraison en rafales et appels qui coupent pendant qu'un téléchargement continue. Si le schéma suit vos transferts plutôt que votre emplacement, le tunnel signale une liaison encombrée au lieu de la provoquer.

Le débit global et la qualité temps réel sont des mesures différentes, donc un téléchargement rapide ne prouve pas que la liaison est propre. La gigue et la perte comptent plus pour un appel que la vitesse moyenne.

Vérifiez par des mesures de temps avant de changer de serveur

Mesurez la liaison locale et le chemin du tunnel séparément, et conservez les deux sorties. Les commandes ci-dessous lisent l'association, échantillonnent le chemin pendant quelques minutes et montrent si la perte apparaît au premier saut ou plus loin. Lancez-les une fois près du point d'accès et une fois là où le problème se produit.

iw dev wlan0 link
ping -i 0.2 -c 200 203.0.113.5
mtr -r -c 50 203.0.113.5
ping -i 0.2 -c 200 198.51.100.9

Comparez les résumés de ping plutôt que les lignes individuelles, car le pourcentage de perte et la dispersion du retard séparent un problème radio d'un serveur lointain. Si la perte apparaît au premier saut vers la passerelle et que le point de terminaison du tunnel montre la même perte, le segment local est le facteur commun. Si la perte n'apparaît qu'au-delà du point de terminaison, la radio n'est pas l'explication.

Changez une chose ensuite, et relancez les mêmes quatre commandes. Un changement de serveur qui coïncide avec un passage à un canal plus calme semblera une réparation et ne vous apprendra rien.