A VPN cae nas subidas grandes: le primeiro a cola

O túnel é estable todo o día e logo cae cada vez que comeza unha subida grande. As peticións interactivas atascan primeiro, o cliente informa dun tempo de espera esgotado e a conexión volve cando remata a transferencia. Ese patrón apunta á cola e ao procesamento, non a que o servidor remoto estea caído, porque ao servidor nunca se lle deu a oportunidade de responder a tempo. O traballo é reproducilo baixo unha carga controlada e ler os contadores correctos.

Cambia unha variable por execución e mantén fixo o extremo.

Constrúe unha comparación de carga repetible

Rexistra unha liña base coa ligazón en repouso: tempo de ida e volta, unhas cantas peticións de aplicacións e o rexistro de eventos do propio túnel. Logo inicia unha subida de tamaño coñecido e repite exactamente esas medicións mentres corre. Mantén sen cambios o extremo, o cliente e o destino da proba, porque cambiar dous deles á vez non che di nada.

Fíxate en que evento aparece primeiro. Un tempo de ida e volta crecente antes de calquera erro suxire cola; un tempo de espera esgotado duro con latencia estable suxire outra cousa, como unha rotación de chaves ou unha acción na conta. Os dous patróns levan a pasos seguintes distintos. Anota a observación antes de cambiar nada.

Garda a saída con marcas de tempo para que as execucións con carga e en repouso se poidan comparar liña por liña.

Le a cola, non a velocidade

As ligazóns de consumidor almacenan paquetes no equipo do provedor, e unha cola de subida chea atrasa todo, incluídos os pequenos paquetes de control que manteñen vivo o túnel. Unha proba de velocidade que dá unha cifra alta di pouco sobre ese atraso, e por iso unha proba en repouso pasa mentres unha ligazón saturada 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 as cifras de latencia con carga coas do repouso. Un salto de decenas de milisegundos a centos, sen perda de paquetes, é cola; a perda con latencia estable sinala outra avaría.

Comproba o dispositivo e a ruta de control

O cifrado e o reenvío custan tempo de procesador, e un router pequeno ou un portátil limitado termicamente pode descartar paquetes mentres está ocupado. Vixía a carga global e non a porcentaxe dun proceso, porque o reenvío no núcleo e o manexo de interrupcións non aparecen onde a xente adoita 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 tempo de espera do cliente tamén pode coincidir con unha rotación de chaves programada ou cun evento de política de sesión. Le o rexistro do propio cliente para ver a orde dos eventos, non só a mensaxe de erro da aplicación.

Cambia unha cousa e repite

Onde a plataforma o permita, limita a taxa de subida ou clasifica o tráfico masivo por baixo do interactivo para que a cola nunca se encha. Logo repite a mesma carga de traballo e compara as mesmas tres cifras que antes. Un cambio que mellora unha proba de velocidade pero deixa o tempo de espera non arranxou nada.

Subir os tempos de espera en xeral e debilitar o cifrado son os dous cambios que fan desaparecer o síntoma sen identificar que límite fallou. Ningún dos dous é unha reparación. Ambos trasladan o fallo máis adiante, onde é máis difícil atribuílo.

Remata probando unha petición nova e o comportamento de reconexión do que o usuario depende de verdade. A estabilidade baixo a carga que provocou a queixa é o único resultado que merece rexistrarse.