Un débit lent à travers un tunnel et une machine bloquée en attente de nombres aléatoires produisent des expériences très différentes, mais ils sont classés sous la même plainte. L’un se manifeste par une pause avant que quoi que ce soit fonctionne. L’autre se manifeste par une connexion qui fonctionne et déplace les données lentement tant que vous la regardez. Déterminer lequel vous avez prend dix minutes et en économise une semaine de suppositions.

Deux symptômes qui se ressemblent

Un service qui se bloque après un démarrage récent, avant d’accepter la moindre connexion, attend quelque chose. Un tunnel qui s’établit rapidement puis transfère à une fraction du débit attendu est limité par autre chose. Le mot chiffrement apparaît dans les deux histoires, c’est pourquoi elles sont fusionnées. Séparez-les avant de toucher un fichier de configuration.

Placez des horodatages autour du démarrage, de l’authentification, de la renégociation des clés et du transfert lui-même. Un long délai avant que le tunnel soit utilisable n’est pas un débit bas et stable, et faire la moyenne des deux en un seul chiffre détruit la preuve.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

Les deux premières commandes placent le travail de démarrage sur une chronologie. La troisième affiche la valeur comptable de l’entropie du noyau, utile comme point de données unique et inutile comme indicateur de bande passante.

À quoi ressemble vraiment une attente de nombres aléatoires

Une demande d’octets aléatoires sécurisés peut se bloquer jusqu’à ce que le noyau ait initialisé sa source aléatoire. Cela compte surtout sur les machines virtuelles et les petites cartes embarquées au début du démarrage, quand peu de bruit environnemental a été collecté. Il ne s’ensuit pas que chaque octet chiffré consomme de l’entropie fraîche.

Les générateurs modernes s’ensemencent une fois puis produisent une sortie à partir d’une construction déterministe, se réensemençant selon leur propre calendrier. Le transfert en masse ne vide pas une réserve octet par octet, donc une valeur de réserve basse pendant un transfert lent ne prouve rien sur la cause.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

La première commande montre si le processus est bloqué dans un appel de nombres aléatoires pendant que vous regardez. La seconde montre les messages d’initialisation du noyau lui-même, et c’est là qu’un blocage de démarrage précoce devient visible.

Notez la version du noyau et la bibliothèque à laquelle le service est réellement lié, car le comportement diffère entre implémentations et entre versions. Une trace prise après la reprise rate généralement la pause entièrement.

À quoi ressemble vraiment une lenteur persistante

Un tunnel qui transfère lentement en permanence est limité par le chemin de données. Un seul thread saturé, la perte de paquets externes, les retransmissions ou des files de sockets pleines produisent chacun ce schéma, et chacun a sa propre correction. Le pourcentage CPU agrégé masque un seul thread occupé, ce qui est la mauvaise lecture la plus courante. Regardez le temps par thread avant de regarder la charge totale.

Mesurez dans les deux sens avec une base comparable, et surveillez les compteurs de l’interface plutôt que le rapport de l’application elle-même.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

La première commande montre l’état de file et de congestion pour un pair. La deuxième et la troisième signalent les abandons et les retransmissions au niveau de la pile et de l’interface, où la cause apparaît généralement en premier.

Choisissez la correction pour le goulot d’étranglement que vous avez mesuré

Si les preuves pointent vers l’initialisation au démarrage précoce, examinez le chemin d’ensemencement pris en charge par la plateforme, qui sur une machine virtuelle peut inclure un périphérique aléatoire fourni par l’hôte. Une image de graine copiée sans modification dans de nombreux invités ne remplace pas une initialisation indépendante.

Si les preuves pointent vers le chemin de données, ajustez ce que les compteurs désignent. Les tailles de tampon aident quand les files débordent et ne font rien quand un thread est saturé. Installer un démon d’entropie pour faire monter un compteur n’est pas une réparation de débit, et changer les hypothèses d’ensemencement pour faire paraître un graphique meilleur échange une propriété de sécurité contre un nombre.

N’acceptez le changement que lorsque la même mesure s’améliore dans les mêmes conditions. Un compteur plus grand n’est pas un résultat ; une attente mesurée plus courte ou un transfert plus rapide avec une cause identifiée en est un.

Articles similaires