Tar entropin slut i en VPN? Vad entropy_avail egentligen visar
Ett stopp vid start och en långsam etablerad tunnel är två olika fel. Läs fasen, räknarens verkliga betydelse och kön innan du skyller på slumpen.
Att kärnans slump tar slut är en lockande förklaring till en långsam VPN, och nästan alltid den felaktiga för det symptom folk rapporterar. En värd som väntar på slumpmässig utdata stannar vid en viss tidpunkt, oftast tidigt i starten eller under nyckelhantering. En tunnel som ansluter snabbt och sedan överför långsamt beskriver i stället genomströmning. Separera de två observationerna innan du installerar en daemon för att fixa ett tal du inte läst färdigt.
Varför myten överlever
Båda problemen är verkliga och de ser likadana ut på avstånd. Startstopp på en nyöppnad virtuell maskin händer verkligen, och en långsam etablerad tunnel är lika verklig. Felet är att anta att det andra orsakas av det första eftersom kryptografi dyker upp någonstans i båda berättelserna. Inget i ordet kryptering antyder att varje överförd byte förbrukar en färsk byte miljöbrus.
Så fungerar inte de här generatorerna. Ett kryptografiskt bibliotek håller en seedad generator och hämtar utdata ur den, och seedar om enligt sin egen policy, så det dyra ögonblicket är seedningen och inte den jämna överföringen.
Vad en generator gör per paket
I OpenSSL 3 byggs den förvalda generatorhierarkin av DRBG-instanser som seedar och seedar om enligt konfiguration och tillstånd. I OpenVPN 2.6 härleder AEAD-datavägen sin nonce från paketets sekvensnummer kombinerat med ett implicit värde per session, medan den äldre CBC-vägen tar en pseudoslumpmässig IV per paket. Ingen av modellerna stöder regeln att flytt av en gigabyte förbrukar en gigabyte färskt kärnbrus. Båda stöder idén att nyckelgenerering och handskakningar är där seedning spelar roll.
CBC-fallet förtjänar ett namn eftersom det ser ut som myten och inte är det: dess IV per paket kommer från bibliotekets generator enligt bibliotekets eget omsseedningsschema, aldrig från ett kärnanrop per paket. När någon citerar en entropikostnad per byte, fråga vilken biblioteksversion och vilken kodväg de mätte.
Var väntan faktiskt syns
Sätt tidsstämplar runt faserna i stället för runt sessionen: start, autentisering, nyckelbyte och överföring. Väntan innan tunneln blir användbar är ett annat klagomål än låg jämn hastighet, och bara en av dem pekar på slumpen. På Linux kan en normal getrandom() förfrågan blockera tills kärnans slumpkälla är initierad, och därför är startversionen av det här problemet verklig på virtuella maskiner och inbäddade kort som tidigt har lite att mata poolen med.
| Fas | Vad som ska köras | Avläsning som betyder väntan | Avläsning som betyder genomströmning |
|---|---|---|---|
| Start, före någon tunnel | systemd-analyze critical-chain | en enhet som sitter i sekunder innan tunneln startar | inte tillämpligt, inget överförs ännu |
| Handskakning | journalctl -u openvpn-server@server -b | en lång lucka innan initieringssekvensen är klar | inte tillämpligt, tunneln är inte uppe |
| Etablerad överföring | ss -tin bredvid sar -n DEV 1 | en blockerad process med tomma socketköer | fulla köer, omsändningar och en upptagen tråd |
Två billiga kommandon hör hemma i början av den insamlingen, och de avgör de enkla frågorna innan tabellen ens behövs. Räknaren de läser är entropiredovisning och inte en bandbreddsmätare, och en enda ögonblicksbild kan inte visa att en process är blockerad, hur länge den väntade eller vilket gränssnitt dess biblioteksanrop använder. Ett prov som tas efter återhämtningen missar oftast stoppet helt, så håll kärnversionen bredvid avläsningen.
cat /proc/sys/kernel/random/entropy_avail
uname -rAnpassa åtgärden till avläsningen
Om kärnan verkligen väntar på initiering, titta på plattformens stödda seedningsväg i stället för tunneln. En virtuell maskin kan få en värds tillhandahållen slumpenhet, till exempel virtio-rng, och förberedelsen av avbilden spelar roll eftersom ett seed som kopieras oförändrat till många gäster inte är oberoende initiering. Om ett bibliotek rapporterar seedningsfel efter start, undersök den konfigurerade källan och leverantörens beteende i stället för att ändra kärninställningar.
ss -tin dst 203.0.113.7
sar -n DEV 1 5OpenSSL:s generatordokumentation beskriver hur den hierarkin får indata och när omsseedning sker, vilket är ett mycket snävare påstående än myten och bara gäller för den implementationen. En entropidaemon är ingen universell hastighetsreparation, och att installera en för att få en räknare att stiga ändrar en säkerhetsantagande utan att visa en fördröjning. För genomströmning, följ datavägen: en mättad tråd, omsändningar, yttre förlust och köfall kräver var sin åtgärd, och buffertstorlekar hanterar socketbuffring med sitt eget köbevis.