Geht einem VPN die Entropie aus? Was entropy_avail wirklich zeigt
Ein Stillstand beim Booten und ein langsamer etablierter Tunnel sind verschiedene Fehler. Lesen Sie die Phase, die wahre Bedeutung des Zählers und die Warteschlange, bevor Sie die Zufälligkeit beschuldigen.
Ausgehende Kernel-Zufälligkeit ist eine verlockende Erklärung für ein langsames VPN und fast immer die falsche für das Symptom, das Nutzer melden. Ein Host, der auf Zufallsausgabe wartet, bleibt zu einem bestimmten Zeitpunkt hängen, meist früh beim Booten oder während der Schlüsselverarbeitung. Ein Tunnel, der schnell Verbindung aufnimmt und dann langsam überträgt beschreibt stattdessen den Durchsatz. Trennen Sie diese beiden Beobachtungen, bevor Sie einen Daemon installieren, um eine Zahl zu reparieren, die Sie noch nicht fertig gelesen haben.
Warum der Mythos überlebt
Beide Probleme sind real, und aus der Ferne sehen sie gleich aus. Startverzögerungen auf einer frisch gebooteten virtuellen Maschine kommen tatsächlich vor, und ein langsamer etablierter Tunnel ist genauso real. Der Fehler ist anzunehmen, das zweite werde vom ersten verursacht, weil in beiden Geschichten irgendwo Kryptografie auftaucht. Nichts am Wort Verschlüsselung legt nahe, dass jedes übertragene Byte ein frisches Byte Umgebungsrauschen verbraucht.
So funktionieren diese Generatoren nicht. Eine Kryptobibliothek hält einen gesetzten Generator und entnimmt ihm Ausgabe, wobei sie nach eigener Richtlinie neu setzt, sodass der teure Moment das Setzen ist und nicht der gleichmäßige Transfer.
Was ein Generator pro Paket tut
In OpenSSL 3 baut sich die Standard-Generatorhierarchie aus DRBG-Instanzen auf, die je nach Konfiguration und Zustand setzen und neu setzen. In OpenVPN 2.6 leitet der AEAD-Datenpfad seine Nonce aus der Sequenznummer des Pakets in Kombination mit einem impliziten Wert pro Sitzung ab, während der ältere CBC-Pfad pro Paket einen pseudozufälligen IV zieht. Keines der Muster stützt die Regel, dass das Bewegen eines Gigabytes ein Gigabyte frisches Kernelrauschen verbraucht. Beide stützen die Idee, dass Schlüsselerzeugung und Handshakes der Ort sind, an dem Setzen zählt.
Der CBC-Fall verdient einen Namen, weil er wie der Mythos aussieht und keiner ist: Sein IV pro Paket kommt aus dem Generator der Bibliothek nach dem eigenen Neu-Setz-Plan der Bibliothek, nie aus einem Kernelaufruf pro Paket. Wenn jemand Entropiekosten pro Byte zitiert, fragen Sie, welche Bibliotheksversion und welcher Codepfad gemessen wurde.
Wo sich das Warten tatsächlich zeigt
Setzen Sie Zeitstempel um die Phasen statt um die Sitzung: Start, Authentifizierung, Schlüsselwechsel und Übertragung. Ein Warten, bevor der Tunnel nutzbar wird, ist eine andere Beschwerde als eine niedrige stetige Rate, und nur eine von beiden deutet auf Zufälligkeit. Unter Linux kann eine normale getrandom() Anfrage blockieren, bis die Zufallsquelle des Kernels initialisiert ist, weshalb die Boot-Variante dieses Problems auf virtuellen Maschinen und eingebetteten Boards real ist, die früh wenig zum Füttern des Pools haben.
| Phase | Was auszuführen ist | Ablesung, die Warten bedeutet | Ablesung, die Durchsatz bedeutet |
|---|---|---|---|
| Boot, vor jedem Tunnel | systemd-analyze critical-chain | eine Unit, die Sekunden sitzt, bevor der Tunnel startet | nicht zutreffend, es wird noch nichts übertragen |
| Handshake | journalctl -u openvpn-server@server -b | eine lange Lücke, bevor die Initialisierungssequenz abgeschlossen ist | nicht zutreffend, der Tunnel steht nicht |
| Etablierte Übertragung | ss -tin neben sar -n DEV 1 | ein blockierter Prozess mit leeren Socket-Warteschlangen | volle Warteschlangen, Neuübertragungen und ein beschäftigter Thread |
Zwei billige Befehle gehören an den Anfang dieser Sammlung, und sie klären die leichten Fragen, bevor die Tabelle überhaupt nötig ist. Der Zähler, den sie lesen, ist Entropie-Buchhaltung und kein Bandbreitenmesser, und eine einzelne Momentaufnahme kann nicht zeigen, dass ein Prozess blockiert ist, wie lange er gewartet hat oder welche Schnittstelle seine Bibliotheksaufrufe nutzen. Eine nach der Erholung genommene Probe verpasst den Stillstand meist völlig, also halten Sie die Kernelversion neben der Ablesung.
cat /proc/sys/kernel/random/entropy_avail
uname -rPassen Sie die Korrektur zur Ablesung
Wenn der Kernel wirklich auf die Initialisierung wartet, schauen Sie auf den unterstützten Seed-Pfad der Plattform statt auf den Tunnel. Einer virtuellen Maschine kann ein vom Host bereitgestelltes Zufallsgerät wie virtio-rng gegeben werden, und die Image-Vorbereitung zählt, weil ein unverändert in viele Gäste kopierter Seed keine unabhängige Initialisierung ist. Wenn eine Bibliothek nach dem Booten Seed-Fehler meldet, untersuchen Sie ihre konfigurierte Quelle und das Anbieterverhalten, statt Kernel-Einstellungen zu ändern.
ss -tin dst 203.0.113.7
sar -n DEV 1 5Die OpenSSL-Generatordokumentation beschreibt, wie diese Hierarchie Eingaben bezieht und wann neu gesetzt wird, was eine weit engere Aussage als der Mythos ist und nur für diese Implementierung gilt. Ein Entropie-Daemon ist keine universelle Geschwindigkeitsreparatur, und ihn zu installieren, damit ein Zähler steigt, ändert eine Sicherheitsannahme, ohne eine Verzögerung zu belegen. Für den Durchsatz folgen Sie dem Datenpfad: ein gesättigter Thread, Neuübertragungen, äußerer Verlust und Queue-Drops brauchen jeweils eine andere Korrektur, und Puffergrößen adressieren Socket-Pufferung mit ihrem eigenen Queue-Beleg.