Er lítil VPN-afkastageta entropívandamál? Yfirleitt ekki

Hæg afkastageta gegnum göng og vél sem stendur kyrr í bið eftir slembitölum gefa mjög mismunandi upplifun, en samt eru þau skráð undir sömu kvörtun. Annað birtist sem hlé áður en nokkuð virkar. Hitt birtist sem tenging sem virkar og færir gögn hægt svo lengi sem þú fylgist með. Að ákvarða hvort þú hefur tekur tíu mínútur og sparar viku af getgátum.

Einkenni tvö sem líta eins út

Þjónusta sem hangir eftir nýja ræsingu, áður en hún tekur við einni tengingu, bíður eftir einhverju. Göng sem myndast hratt og flytja síðan með broti af væntanlegum hraða eru takmörkuð af einhverju öðru. Orðið dulkóðun kemur fyrir í báðum sögum, þess vegna eru þær sameinaðar. Aðskildu þær áður en þú snertir stillingaskrá.

Setjið tímastimpla í kringum ræsingu, auðkenningu, endursamning lykla og flutninginn sjálfan. Löng töf áður en hægt er að nota göngin er ekki lágur stöðugur hraði, og að taka meðaltal af hvoru tveggja í eina tölu eyðileggur sönnunargögnin.

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

Fyrstu tvær skipanirnar setja ræsingarvinnuna á tímalínu. Sú þriðja prentar entropíubókhaldsgildi kjarnans, sem er gagnlegt sem einn gagnapunktur og gagnslaust sem bandvíddarmælir.

Hvernig bið eftir slembitölum lítur í raun út

Beiðni um örugg slembibæti getur stöðvast þar til kjarninn hefur frumstillt slembiuppsprettu sína. Það skiptir mestu máli á sýndarvélum og litlum innfelldum borðum snemma í ræsingu, þegar litlum umhverfishávaða hefur verið safnað. Af því leiðir ekki að hvert dulkóðað bæti eyði fersku entropíu.

Nútímastafar framleiða úttak úr ákvarðandi smíði eftir að hafa verið sáð einu sinni, og sá sjálfum sér aftur samkvæmt eigin áætlun. Magnflutningur tæmir ekki laug bæti fyrir bæti, svo lágt lauggildi í hægum flutningi sannar ekkert um orsökina.

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

Fyrsta skipunin sýnir hvort ferlið situr í slembitöluákalli meðan þú fylgist með. Önnur sýnir frumstillingarskilaboð kjarnans sjálfs, og þar verður snemmbúið ræsingarstopp sýnilegt.

Skráðu kjarnaversjónina og bókasafnið sem þjónustan tengist í raun, því hegðunin er mismunandi milli útfærslna og milli útgáfa. Slóð sem tekin er eftir endurheimt missir yfirleitt hléið algjörlega.

Hvernig viðvarandi hægð lítur í raun út

Göng sem flytja hægt allan tímann eru takmörkuð af gagnaleiðinni. Einn mettaður þráður, tap á ytri pakkum, endursendingar eða fullar sokkabíðraðir framleiða hvert um sig þetta mynstur, og hvert hefur sína eigin lagfæringu. Samantekin CPU prósenta hylur einn upptekinn þráð, og það er algengasta ranglesturinn. Horfðu á tíma á hvern þráð áður en þú horfir á heildarálagið.

Mældu í báðar áttir með sambærilegum grunnlínu, og fylgstu með teljurum viðmótsins frekar en skýrslu forritsins sjálfs.

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

Fyrsta skipunin sýnir biðraðar- og þrengslaástand fyrir einn jafningja. Önnur og þriðja tilkynna fráföll og endursendingar í staflanum og viðmótinu, þar sem orsökin birtist yfirleitt fyrst.

Veldu lagfæringuna fyrir flöskuhálsinn sem þú mældir

Ef sönnunargögnin benda til frumstillingar snemma í ræsingu, skoðaðu studda sáningaleið kerfisins, sem á sýndarvél getur falið í sér slembitæki frá hýsilnum. Sáningarmynd sem er afrituð óbreytt í marga gesti kemur ekki í stað sjálfstæðrar frumstillingar.

Ef sönnunargögnin benda til gagnaleiðarinnar, stilltu það sem teljarnir benda á. Biðminnisstærðir hjálpa þegar biðraðir flæða yfir og gera ekkert þegar einn þráður er mettaður. Að setja upp entropídupp til að hækka teljara er ekki afkastaviðgerð, og að breyta sáningarforsendum til að láta graf líta betur út skiptir öryggiseiginleika fyrir tölu.

Samþykktu breytinguna aðeins þegar sama mæling batnar við sömu skilyrði. Stærri teljari er ekki niðurstaða; styttri mæld bið eða hraðari flutningur með auðkenndri orsök er það.