Ist niedriger VPN-Durchsatz ein Entropieproblem? Meistens nicht
Ein Startstillstand, der auf Zufallszahlen wartet, und ein langsamer Tunnel sind verschiedene Fehler. Messen Sie, welchen Sie haben, bevor Sie Seeding oder Puffer ändern.
Geringer Durchsatz durch einen Tunnel und eine Maschine, die beim Warten auf Zufallszahlen hängt, erzeugen sehr unterschiedliche Erfahrungen, werden aber unter derselben Beschwerde abgelegt. Das eine zeigt sich als Pause, bevor irgendetwas funktioniert. Das andere zeigt sich als Verbindung, die funktioniert und Daten langsam bewegt, solange man hinsieht. Festzustellen, welches man hat, dauert zehn Minuten und spart eine Woche Rätselraten.
Zwei Symptome, die gleich aussehen
Ein Dienst, der nach einem frischen Start hängt, bevor er eine einzige Verbindung annimmt, wartet auf etwas. Ein Tunnel, der sich schnell aufbaut und dann mit einem Bruchteil der erwarteten Rate überträgt, wird durch etwas anderes begrenzt. Das Wort Verschlüsselung taucht in beiden Geschichten auf, deshalb werden sie zusammengelegt. Trennen Sie sie, bevor Sie eine Konfigurationsdatei anfassen.
Setzen Sie Zeitstempel um Start, Authentifizierung, Schlüsselaushandlung und die Übertragung selbst. Eine lange Verzögerung, bevor der Tunnel nutzbar ist, ist keine niedrige stetige Rate, und beide zu einem Wert zu mitteln zerstört den Beweis.
systemd-analyze blame | head -10 journalctl -u [email protected] -o short-precise | head -40 cat /proc/sys/kernel/random/entropy_avail
Die ersten beiden Befehle legen die Startarbeit auf eine Zeitachse. Der dritte druckt den Entropie-Buchwert des Kernels aus, der als einzelner Datenpunkt nützlich und als Bandbreitenmesser nutzlos ist.
Wie ein Warten auf Zufallszahlen tatsächlich aussieht
Eine Anfrage nach sicheren Zufallsbytes kann blockieren, bis der Kernel seine Zufallsquelle initialisiert hat. Das zählt vor allem auf virtuellen Maschinen und kleinen eingebetteten Boards früh beim Booten, wenn wenig Umgebungsrauschen gesammelt wurde. Daraus folgt nicht, dass jedes verschlüsselte Byte frische Entropie verbraucht.
Moderne Generatoren werden einmal geseedet und erzeugen dann Ausgabe aus einer deterministischen Konstruktion, wobei sie nach ihrem eigenen Zeitplan neu seeden. Massenübertragung leert keinen Pool Byte für Byte, ein niedriger Poolwert während einer langsamen Übertragung beweist also nichts über die Ursache.
strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20 dmesg | grep -i 'random\|crng'
Der erste Befehl zeigt, ob der Prozess in einem Zufallszahlenaufruf steckt, während Sie zusehen. Der zweite zeigt die Initialisierungsmeldungen des Kernels selbst, und dort wird ein früher Startstillstand sichtbar.
Notieren Sie die Kernelversion und die Bibliothek, gegen die der Dienst tatsächlich linkt, denn das Verhalten unterscheidet sich zwischen Implementierungen und zwischen Versionen. Ein Trace nach der Wiederherstellung verpasst die Pause meist völlig.
Wie anhaltende Langsamkeit tatsächlich aussieht
Ein Tunnel, der durchgehend langsam überträgt, wird durch den Datenpfad begrenzt. Ein gesättigter Thread, Verlust äußerer Pakete, Neuübertragungen oder volle Socket-Warteschlangen erzeugen jeweils dieses Muster, und jedes hat seine eigene Korrektur. Aggregierter CPU-Prozentsatz verbirgt einen einzelnen beschäftigten Thread, und das ist die häufigste Fehldeutung. Sehen Sie sich die Zeit pro Thread an, bevor Sie die Gesamtlast ansehen.
Messen Sie in beide Richtungen mit einer vergleichbaren Basislinie und beobachten Sie die Schnittstellenzähler statt des Berichts der Anwendung selbst.
ss -tin dst 203.0.113.10 nstat -az | grep -i 'drop\|retrans' ethtool -S eth0 | grep -i 'drop\|error'
Der erste Befehl zeigt Warteschlangen- und Stauzustand für einen Peer. Der zweite und dritte melden Drops und Neuübertragungen im Stack und an der Schnittstelle, wo die Ursache meist zuerst auftaucht.
Wählen Sie die Korrektur für den gemessenen Engpass
Deuten die Belege auf eine frühe Startinitialisierung, sehen Sie sich den unterstützten Seeding-Pfad der Plattform an, der auf einer virtuellen Maschine ein vom Host bereitgestelltes Zufallsgerät umfassen kann. Ein unverändert in viele Gäste kopiertes Seed-Image ist kein Ersatz für eine unabhängige Initialisierung.
Deuten die Belege auf den Datenpfad, stellen Sie das ein, worauf die Zähler hinweisen. Puffergrößen helfen, wenn Warteschlangen überlaufen, und bewirken nichts, wenn ein Thread gesättigt ist. Einen Entropie-Daemon zu installieren, um einen Zähler zu erhöhen, ist keine Durchsatzreparatur, und Seeding-Annahmen zu ändern, damit ein Diagramm besser aussieht, tauscht eine Sicherheitseigenschaft gegen eine Zahl.
Akzeptieren Sie die Änderung nur, wenn dieselbe Messung unter denselben Bedingungen besser wird. Ein größerer Zähler ist kein Ergebnis; eine kürzere gemessene Wartezeit oder eine schnellere Übertragung mit identifizierter Ursache ist es.