Charge d’un serveur VPN expliquée : utilisateurs, CPU ou liaison montante ?

Une passerelle à 0.4 de charge peut encore ramper pour chaque utilisateur derrière elle. La charge moyenne compte les tâches exécutables ou bloquées dans un sommeil ininterruptible, et sur un hôte à quatre cœurs un seul processus saturé suffit à la pousser vers 1.0 pendant que trois cœurs s’ennuient. Lire ce chiffre comme une marge disponible est l’erreur la plus courante dans le choix d’un point de terminaison. Ce qui limite réellement un tunnel est généralement l’une de quatre choses : un cœur occupé, la liaison montante, la file qui la précède ou une politique par session que personne n’a documentée.

La charge moyenne compte des tâches, pas un débit

Le noyau échantillonne la file d’exécution et le nombre de tâches en attente d’entrées-sorties, puis lisse les deux sur une, cinq et quinze minutes. Rien dans cette définition ne mentionne d’octets, de paquets ou de tunnels. Un hôte dont le stockage est bloqué peut signaler une charge élevée avec presque aucun trafic, et un hôte qui pousse un gigabit dans un chemin de données du noyau peut en signaler une confortable.

Corréler la charge avec les performances du tunnel exige donc une vue par cœur. Si un cœur est saturé, le pourcentage agrégé d’un tableau de bord semblera toujours correct :

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

La troisième commande est celle qui compte le plus sur les hôtes VPN. Le traitement des paquets en espace utilisateur dans OpenVPN 2.x est en grande partie sérialisé par processus, si bien qu’un seul fil occupé peut devenir le plafond alors que le tableau de bord signale une grande capacité disponible. Si un fil retient l’essentiel d’un cœur pendant votre période lente, l’hôte n’est pas sous-dimensionné dans l’ensemble ; il est contraint dans la dimension qui se trouve compter.

Notez aussi le moment. Les moyennes sur quinze minutes masquent le pic qui a ruiné un appel, donc une capture d’écran prise après la plainte est une preuve faible. Échantillonnez pendant le problème et conservez l’horodatage avec la sortie.

La liaison montante et la file qui la précède

Les compteurs d’interface répondent à la question du débit que les chiffres du CPU ne peuvent pas. Ils séparent aussi la capacité de la perte, qui sont des défaillances différentes avec des correctifs différents :

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Une liaison proche de son débit provisionné pendant votre test est l’explication, et aucune quantité de CPU libre ne la change. La ligne qdisc ajoute le détail qui compte pour le trafic interactif : l’engorgement et les pertes indiquent si les paquets attendent dans une file avant de partir. Une file qui se remplit sous un envoi massif produit exactement le symptôme que les gens imputent au serveur distant, des appels poussifs sur une connexion qui reste bonne dans les benchmarks.

Les compteurs de retransmission attrapent le cas où les paquets partent mais n’arrivent jamais proprement. Si les retransmissions montent pendant la fenêtre lente et que l’interface est loin de sa capacité, le problème est dans le chemin et non sur l’hôte, et passer à un autre point de terminaison dans la même ville n’aidera pas.

Le nombre de sessions décrit la demande, pas la marge

Chaque annuaire public affiche un certain nombre d’utilisateurs connectés, et presque aucun ne vous dit ce que font ces utilisateurs. Vingt sessions faisant un travail interactif et quatre sessions tirant de gros fichiers produisent des charges très différentes sur le même matériel. Le second schéma est invisible dans un nombre d’utilisateurs, et c’est lui qui gâche une soirée. Un nombre de sessions se lit donc au mieux comme un indice sur la demande, jamais comme une affirmation sur la capacité disponible.

Sur un hôte que vous contrôlez, le fichier d’état donne la dimension manquante. OpenVPN écrit un instantané périodique qui inclut des compteurs d’octets par client, ce qui suffit pour voir si une seule session est responsable de toute la liaison montante :

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Deux échantillons espacés de dix secondes transforment ces compteurs cumulés en un débit par client. C’est la mesure qu’un nombre d’utilisateurs remplace, et c’est aussi ainsi que vous découvrez qu’un seul client mal configuré sature la liaison chaque nuit à la même heure.

Les limites par session se cachent dans la politique

Un serveur peut être inactif et refuser quand même de vous donner de la bande passante. Les limites de débit, les plafonds de bande passante par client et la mise en forme du trafic s’appliquent souvent par nom commun ou par pool, si bien que deux utilisateurs sur la même passerelle peuvent obtenir des résultats très différents. Le mécanisme n’est pas subtil, mais il est invisible de l’extérieur parce que le tunnel monte normalement dans les deux cas.

Cherchez la mise en forme sur l’interface du tunnel plutôt que sur la physique. Vérifiez si la limite suit l’utilisateur, le certificat ou le pool d’adresses. Si votre compte de test atterrit dans le pool sans plafond, vous conclurez que le serveur va bien et que l’utilisateur qui se plaint a tort. Cette conclusion est pire qu’aucune conclusion, car elle ferme le ticket.

Comparez deux points de terminaison avec une tâche fixe

L’expérience côté client vaut encore la peine d’être menée, mais seulement si les variables sont figées. Utilisez le même appareil, le même réseau d’accès, le même protocole et le même fichier de destination, puis répétez face à un second point de terminaison à une distance similaire. Tout ce qui change entre les passes, y compris l’heure de la journée, contamine le résultat.

Consignez les échecs avec autant de soin que les succès. Une série où trois points de terminaison fonctionnent et où un expire est plus instructive que quatre chiffres de vitesse, car elle pointe un problème de chemin ou de politique plutôt que de capacité. Lancez chaque cas au moins deux fois ; un seul échantillon lent ne prouve rien sur un réseau partagé.

Enfin, gardez les chiffres que vous avez recueillis avec l’affirmation qu’ils étayent. "Ce point de terminaison a assuré le transfert dans la même fenêtre où l’autre s’est bloqué" est défendable, tandis que "ce point de terminaison est plus rapide" invite à une dispute que vous ne gagnerez pas avec un score de page d’accueil. Le manuel OpenVPN 2.6 documente le fichier d’état et les options de mise en forme si vous avez besoin des directives exactes côté hôte.