Er lav VPN-gennemstrømning et entropiproblem? Normalt ikke

Lav gennemstrømning gennem en tunnel og en maskine, der hænger i venten på tilfældige tal, giver meget forskellige oplevelser, men de bliver alligevel registreret under den samme klage. Det ene viser sig som en pause, før noget virker. Det andet viser sig som en forbindelse, der virker og flytter data langsomt, så længe du kigger på den. At afgøre, hvilken du har, tager ti minutter og sparer en uges gætteri.

To symptomer, der ligner hinanden

En tjeneste, der hænger efter en frisk opstart, før den accepterer en eneste forbindelse, venter på noget. En tunnel, der etableres hurtigt og derefter overfører med en brøkdel af den forventede hastighed, er begrænset af noget andet. Ordet kryptering optræder i begge historier, og derfor bliver de slået sammen. Adskil dem, før du rører en konfigurationsfil.

Sæt tidsstempler omkring opstart, godkendelse, genforhandling af nøgler og selve overførslen. En lang forsinkelse, før tunnelen kan bruges, er ikke en lav stabil hastighed, og at gennemsnitlige de to til ét tal ødelægger beviset.

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

De to første kommandoer sætter opstartsarbejdet på en tidslinje. Den tredje udskriver kernens entropiregnskabsværdi, som er nyttig som et enkelt datapunkt og ubrugelig som båndbreddemåler.

Hvordan en venten på tilfældige tal faktisk ser ud

En anmodning om sikre tilfældige bytes kan blokere, indtil kernen har initialiseret sin tilfældige kilde. Det betyder mest på virtuelle maskiner og små indlejrede kort tidligt i opstarten, når der er samlet lidt miljøstøj. Det følger ikke, at hver krypteret byte forbruger frisk entropi.

Moderne generatorer seeder én gang og producerer derefter output fra en deterministisk konstruktion og reseeder efter deres eget skema. Bulkoverførsel tømmer ikke en pulje byte for byte, så en lav puljeværdi under en langsom overførsel beviser intet om årsagen.

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

Den første kommando viser, om processen sidder i et tilfældigtal-kald, mens du ser på. Den anden viser kernens egne initialiseringsmeddelelser, og det er der, et tidligt opstartsstop bliver synligt.

Noter kernelversionen og det bibliotek, tjenesten faktisk linker til, fordi adfærden afviger mellem implementeringer og mellem udgivelser. Et trace taget efter genopretning misser normalt pausen helt.

Hvordan vedvarende langsomhed faktisk ser ud

En tunnel, der overfører langsomt hele tiden, er begrænset af datastien. Én mættet tråd, tab af ydre pakker, gentransmissioner eller fulde socketkøer producerer hver det mønster, og hver har sin egen rettelse. Samlet CPU-procent skjuler én travl tråd, hvilket er den mest almindelige fejllæsning. Se på tiden for hver tråd, før du ser på den samlede belastning.

Mål i begge retninger med en sammenlignelig baseline, og hold øje med grænsefladens tællere i stedet for applikationens egen rapport.

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

Den første kommando viser kø- og trængselsstatus for én peer. Den anden og tredje rapporterer drops og gentransmissioner i stakken og på grænsefladen, hvor årsagen normalt viser sig først.

Vælg rettelsen til den flaskehals, du målte

Hvis beviserne peger på tidlig opstartsinitialisering, så se på platformens understøttede seedingsti, som på en virtuel maskine kan omfatte en værtsleveret tilfældig enhed. Et seed-image, der kopieres uændret til mange gæster, er ikke en erstatning for uafhængig initialisering.

Hvis beviserne peger på datastien, så juster det, tællerne peger på. Bufferstørrelser hjælper, når køer flyder over, og gør intet, når én tråd er mættet. At installere en entropi-dæmon for at hæve en tæller er ingen gennemstrømningsreparation, og at ændre seedingantagelser for at få en graf til at se bedre ud bytter en sikkerhedsegenskab for et tal.

Accepter kun ændringen, når den samme måling forbedres under de samme betingelser. En større tæller er ikke et resultat; en kortere målt ventetid eller en hurtigere overførsel med en identificeret årsag er.