VPN qui coupe pendant les gros envois : lisez d’abord la file

Le tunnel est stable toute la journée, puis il coupe dès qu’un gros envoi démarre. Les requêtes interactives se bloquent en premier, le client signale un dépassement de délai, et la connexion revient quand le transfert se termine. Ce schéma désigne la mise en file et le traitement, non un serveur distant hors service, car le serveur n’a jamais eu la possibilité de répondre à temps. Le travail consiste à reproduire cela sous une charge maîtrisée et à lire les bons compteurs.

Ne changez qu’une variable par exécution et gardez le point de terminaison fixe.

Construire une comparaison de charge reproductible

Relevez une référence lien au repos : temps d’aller-retour, quelques requêtes applicatives et le journal d’événements du tunnel lui-même. Lancez ensuite un envoi de taille connue et répétez exactement ces mesures pendant qu’il tourne. Gardez le point de terminaison, le client et la destination du test inchangés, car modifier deux d’entre eux à la fois ne vous apprend rien.

Notez quel événement apparaît en premier. Un temps d’aller-retour qui monte avant toute erreur suggère une file d’attente ; un dépassement de délai net avec une latence stable suggère autre chose, comme un renouvellement de clés ou une action sur le compte. Les deux schémas mènent à des étapes suivantes différentes. Écrivez l’observation avant de changer quoi que ce soit.

Enregistrez la sortie avec des horodatages pour que les exécutions en charge et au repos se comparent ligne par ligne.

Lisez la file, pas le débit

Les liaisons grand public mettent les paquets en mémoire tampon dans l’équipement du fournisseur, et une file montante pleine retarde tout, y compris les petits paquets de contrôle qui maintiennent un tunnel en vie. Un test de débit qui affiche un chiffre élevé ne dit presque rien de ce retard, et c’est pourquoi un test au repos réussit alors qu’une liaison saturée échoue.

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'

Comparez les chiffres de latence en charge avec ceux au repos. Un saut de dizaines de millisecondes à des centaines, sans perte de paquets, est une mise en file ; une perte avec une latence stable désigne une autre panne.

Vérifier l’appareil et le chemin de contrôle

Le chiffrement et le transfert coûtent du temps processeur, et un petit routeur ou un portable bridé thermiquement peut perdre des paquets pendant qu’il travaille. Surveillez la charge globale plutôt que le pourcentage d’un processus, car le transfert dans le noyau et le traitement des interruptions n’apparaissent pas là où l’on regarde d’habitude.

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

Un dépassement de délai côté client peut aussi coïncider avec un renouvellement de clés planifié ou avec un événement de politique de session. Lisez le journal du client lui-même pour l’ordre des événements, pas seulement le message d’erreur de l’application.

Changez une seule chose et répétez

Là où la plateforme le permet, limitez le débit d’envoi ou classez le trafic massif sous le trafic interactif afin que la file ne se remplisse jamais. Répétez ensuite la charge de travail identique et comparez les trois mêmes chiffres qu’avant. Un changement qui améliore un test de débit mais laisse le dépassement de délai n’a rien réparé.

Relever les délais partout et affaiblir le chiffrement sont les deux changements qui font disparaître le symptôme sans identifier la limite qui a lâché. Ni l’un ni l’autre n’est une réparation. Les deux déplacent la panne plus loin, là où elle est plus difficile à imputer.

Terminez en testant une requête neuve et le comportement de reconnexion sur lequel l’utilisateur compte vraiment. La stabilité sous la charge qui a provoqué la plainte est le seul résultat qui vaille d’être consigné.