Un VPN peut-il manquer d'entropie ? Ce que montre vraiment entropy_avail
Un blocage au démarrage et un tunnel établi lent sont deux pannes différentes. Lisez l'étape, le vrai sens du compteur et la file avant d'accuser le hasard.
La pénurie d'aléa du noyau est une explication séduisante pour un VPN lent, et presque toujours la mauvaise pour le symptôme que les gens rapportent. Un hôte qui attend une sortie aléatoire se bloque à un moment précis, généralement au début du démarrage ou pendant la gestion des clés. Un tunnel qui se connecte vite puis transfère lentement décrit en réalité le débit. Séparez ces deux observations avant d'installer un démon pour corriger un chiffre que vous n'avez pas fini de lire.
Pourquoi le mythe survit
Les deux problèmes sont réels et se ressemblent de loin. Les blocages au démarrage sur une machine virtuelle fraîchement démarrée arrivent vraiment, et un tunnel établi lent est tout aussi réel. L'erreur est de supposer que le second est causé par le premier parce que la cryptographie apparaît quelque part dans les deux histoires. Rien dans le mot chiffrement n'implique que chaque octet transféré consomme un octet frais de bruit environnemental.
Ce n'est pas ainsi que fonctionnent ces générateurs. Une bibliothèque cryptographique garde un générateur amorcé et en tire de la sortie, en le réamorçant selon sa propre politique, si bien que le moment coûteux est l'amorçage et non le transfert régulier.
Ce qu'un générateur fait par paquet
Dans OpenSSL 3, la hiérarchie de générateurs par défaut est construite à partir d'instances DRBG qui s'amorcent et se réamorcent selon la configuration et l'état. Dans OpenVPN 2.6, le chemin de données AEAD dérive son nonce du numéro de séquence du paquet combiné à une valeur implicite par session, tandis que l'ancien chemin CBC tire un IV pseudo-aléatoire par paquet. Aucun des deux schémas ne soutient la règle selon laquelle déplacer un gigaoctet consomme un gigaoctet de bruit de noyau frais. Les deux soutiennent l'idée que la génération de clés et les poignées de main sont là où l'amorçage compte.
Le cas CBC mérite d'être nommé car il ressemble au mythe sans en être un : son IV par paquet vient du générateur de la bibliothèque selon le calendrier de réamorçage propre à celle-ci, jamais d'un appel au noyau par paquet. Quand quelqu'un cite un coût d'entropie par octet, demandez quelle version de bibliothèque et quel chemin de code ont été mesurés.
Où l'attente se voit réellement
Placez des horodatages autour des étapes plutôt qu'autour de la session : démarrage, authentification, changement de clé et transfert. Une attente avant que le tunnel soit utilisable est une plainte différente d'un débit stable faible, et une seule des deux pointe vers l'aléa. Sous Linux, une requête getrandom() normale peut bloquer jusqu'à ce que la source aléatoire du noyau soit initialisée, et c'est pourquoi la version au démarrage de ce problème est réelle sur les machines virtuelles et les cartes embarquées qui ont peu pour alimenter la réserve au début.
| Étape | Quoi exécuter | Lecture qui signifie attente | Lecture qui signifie débit |
|---|---|---|---|
| Démarrage, avant tout tunnel | systemd-analyze critical-chain | une unité qui reste des secondes avant que le tunnel démarre | non applicable, rien ne se transfère encore |
| Poignée de main | journalctl -u openvpn-server@server -b | un long intervalle avant que la séquence d'initialisation se termine | non applicable, le tunnel n'est pas monté |
| Transfert établi | ss -tin à côté de sar -n DEV 1 | un processus bloqué avec des files de socket vides | files pleines, retransmissions et un seul thread occupé |
Deux commandes bon marché appartiennent au début de ce relevé, et elles règlent les questions faciles avant même que le tableau soit nécessaire. Le compteur qu'elles lisent est de la comptabilité d'entropie et non un débitmètre, et un instantané unique ne peut pas montrer qu'un processus est bloqué, combien de temps il a attendu ou quelle interface ses appels de bibliothèque utilisent. Un échantillon pris après le rétablissement rate généralement le blocage en entier, gardez donc la version du noyau à côté de la lecture.
cat /proc/sys/kernel/random/entropy_avail
uname -rFaites correspondre la correction à la lecture
Si le noyau attend vraiment l'initialisation, regardez le chemin d'amorçage pris en charge par la plateforme plutôt que le tunnel. Une machine virtuelle peut recevoir un périphérique aléatoire fourni par l'hôte, comme virtio-rng, et la préparation de l'image compte car une graine copiée sans changement dans de nombreux invités n'est pas une initialisation indépendante. Si une bibliothèque signale des échecs d'amorçage après le démarrage, examinez sa source configurée et le comportement du fournisseur au lieu de modifier les réglages du noyau.
ss -tin dst 203.0.113.7
sar -n DEV 1 5La documentation du générateur OpenSSL décrit comment cette hiérarchie obtient ses entrées et quand le réamorçage a lieu, ce qui est une affirmation bien plus étroite que le mythe et qui ne vaut que pour cette implémentation. Un démon d'entropie n'est pas une réparation universelle de vitesse, et l'installer pour faire monter un compteur modifie une hypothèse de sécurité sans démontrer de retard. Pour le débit, suivez le chemin des données : un thread saturé, les retransmissions, la perte externe et les abandons de file demandent chacun une correction différente, et les tailles de tampon traitent la mise en tampon des sockets avec leurs propres preuves de file.