VPN que cau durant pujades grans: primer llegeix la cua

El túnel és estable tot el dia, però cau quan comença una pujada gran. Les peticions interactives s'encallen primer, el client informa d'un temps d'espera esgotat i la connexió torna quan acaba la transferència. Aquest patró apunta a la cua i al processament, no al fet que el servidor remot estigui caigut, perquè al servidor no se li va donar mai l'oportunitat de respondre a temps. La feina és reproduir-ho sota una càrrega controlada i llegir els comptadors correctes.

Canvia una variable per execució i mantén el punt final fix.

Construeix una comparació de càrrega reproduïble

Enregistra una línia base amb l'enllaç en repòs: temps d'anada i tornada, unes quantes peticions d'aplicacions i el registre d'esdeveniments del propi túnel. Després inicia una pujada de mida coneguda i repeteix exactament aquestes mesures mentre dura. Mantén sense canvis el punt final, el client i la destinació de la prova, perquè canviar-ne dos alhora no et diu res.

Fixeu-vos quin esdeveniment apareix primer. Un temps d'anada i tornada creixent abans de qualsevol error suggereix cua; un temps d'espera dur amb latència estable suggereix una altra cosa, com una rotació de claus o una acció al compte. Els dos patrons porten a passos següents diferents. Anota l'observació abans de canviar res.

Desa la sortida amb marques de temps perquè les execucions amb càrrega i en repòs es puguin comparar línia per línia.

Llegeix la cua, no la velocitat

Els enllaços de consumidor emmagatzemen paquets a l'equipament del proveïdor, i una cua de pujada plena endarrereix tot, inclosos els paquets de control petits que mantenen viu el túnel. Una prova de velocitat que dona una xifra alta diu poc sobre aquest retard, i per això una prova en repòs passa mentre un enllaç saturat falla.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Compara les xifres de latència amb càrrega amb les del repòs. Un salt de desenes de mil·lisegons a centenars, sense pèrdua de paquets, és cua; la pèrdua amb latència estable assenyala una altra avaria.

Comprova el dispositiu i el camí de control

El xifratge i el reenviament costen temps de processador, i un router petit o un portàtil limitat tèrmicament pot descartar paquets mentre està ocupat. Mira la càrrega global i no el percentatge d'un procés, perquè el reenviament del nucli i la gestió d'interrupcions no apareixen on la gent sol mirar.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Un temps d'espera del client també pot coincidir amb una rotació de claus programada o amb un esdeveniment de política de sessió. Llegeix el registre del propi client per l'ordre dels esdeveniments, no només el missatge d'error de l'aplicació.

Canvia una cosa i repeteix

On la plataforma ho permet, limita la taxa de pujada o classifica el trànsit massiu per sota del trànsit interactiu perquè la cua no s'ompli mai. Després repeteix la mateixa càrrega de treball i compara les mateixes tres xifres que abans. Un canvi que millora una prova de velocitat però deixa el temps d'espera no ha arreglat res.

Apujar els temps d'espera a tot arreu i debilitar el xifratge són els dos canvis que fan desaparèixer el símptoma sense identificar quina frontera va fallar. Cap dels dos no és una reparació. Tots dos mouen la fallada més endavant, on és més difícil d'atribuir.

Acaba provant una petició nova i el comportament de reconnexió en què l'usuari confia de debò. L'estabilitat sota la càrrega que va provocar la queixa és l'únic resultat que val la pena enregistrar.