El teu Wi-Fi fa que la VPN vagi lenta? Comprova l'enllaç local
Les barres de senyal mesuren potència, no temps d'aire. Compara la mateixa tasca per Wi-Fi i Ethernet, observa les retransmissions i les pèrdues, i després repeteix les mesures abans de culpar un servidor.
La majoria de la gent culpa el servidor dels talls que ha causat la ràdio, i la solució a què recorren fa més difícil el diagnòstic següent. Una icona de senyal ple diu que el punt d'accés sona fort, no que el canal estigui tranquil ni que el temps d'aire sigui lliure. Els problemes sense fil arriben al túnel com a retard, pèrdua i reordenació, i el client informa dels tres com un únic problema vague de connexió.
La pregunta útil és si el mateix túnel es comporta diferent en un altre enllaç local. Tota la resta es manté fixa mentre hi responeu.
Les barres de senyal mesuren potència, no temps d'aire disponible
El nivell de senyal rebut indica amb quina força el client sent el punt d'accés, i aquesta xifra pot romandre alta mentre la capacitat s'enfonsa. El temps d'aire es comparteix amb les xarxes veïnes, amb altres clients de la vostra xarxa i amb el trànsit de gestió que la ràdio ha de transmetre a la velocitat més lenta que entén cada participant. Les parets, el metall i la posició del cos canvien el camí, i també la disposició de l'antena dins d'un portàtil. Res d'això no apareix a la icona.
Els comptadors de reintents són l'evidència privada més clara, perquè una trama que ha necessitat tres intents encara compta com a lliurada. Un enllaç que informa d'una velocitat saludable mentre reintenta molt farà que un túnel en temps real sembli trencat.
Triar banda és un intercanvi, no una cura, digui el que digui la columna de consells. Un canal de 5 GHz sol trobar menys interferència i cobrir menys distància, mentre que 2.4 GHz arriba més endins d'un edifici i troba més veïns. Trieu la banda per a la distància que realment necessiteu, i anoteu la configuració anterior perquè un experiment fallit es pugui desfer.
Canvieu una variable i torneu a mirar
Manteniu fixos el perfil de la VPN, el punt final, la destinació i l'hora del dia mentre canvieu l'enllaç local. Compareu la mateixa tasca a prop del punt d'accés, des de l'habitació llunyana i per Ethernet al mateix equip. Si la prova per cable és neta i les dues sense fil no ho són, el segment de ràdio s'ha guanyat el lloc al capdamunt de la llista.
Moure's entre punts d'accés és un experiment a part, i en una malla és el que la gent s'estalvia. L'itinerància pot aturar un túnel, forçar un canvi de claus o deixar una sessió viva mentre els paquets deixen de fluir. Anoteu l'hora de cada interrupció i compareu-la amb l'entrada del registre del client per al canvi d'associació. Una pausa que coincideix amb una itinerància no és un servidor sobrecarregat, per molt que ho sembli.
Un canal ocupat s'assembla a un servidor lent
Altres dispositius competeixen pel mateix temps d'aire, i la vostra gran pujada competeix amb la vostra pròpia trucada. Atureu les transferències opcionals i repetiu la tasca abans de concloure res sobre el proveïdor. Cua sota càrrega produeix exactament el símptoma que la gent anomena VPN lenta: retard creixent, lliurament a ràfegues i trucades que es tallen mentre continua una baixada. Si el patró segueix les vostres transferències i no la vostra ubicació, el túnel informa d'un enllaç congestionat i no el causa.
La capacitat global i la qualitat en temps real són mesures diferents, així que una baixada ràpida no demostra que l'enllaç estigui net. El jitter i la pèrdua importen més per a una trucada que la velocitat mitjana.
Verifiqueu amb mesures de temps abans de canviar de servidor
Mesureu l'enllaç local i el camí del túnel per separat, i guardeu les dues sortides. Les ordres següents llegeixen l'associació, mostregen el camí durant uns minuts i mostren si la pèrdua apareix al primer salt o més enllà. Executeu-les una vegada a prop del punt d'accés i una altra on passa el problema.
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
Compareu els resums de ping i no les línies individuals, perquè el percentatge de pèrdua i la dispersió del retard separen un problema de ràdio d'un servidor llunyà. Si la pèrdua apareix al primer salt cap a la porta d'enllaç i el punt final del túnel mostra la mateixa pèrdua, el segment local és el factor comú. Si la pèrdua apareix només més enllà del punt final, la ràdio no n'és l'explicació.
Canvieu una cosa després d'això i torneu a executar les mateixes quatre ordres. Un canvi de servidor que coincideixi amb el pas a un canal més tranquil semblarà una solució i no us ensenyarà res.