Vai VPN izsīkst entropija? Ko patiesībā rāda entropy_avail

Kodola nejaušības izsīkšana ir vilinošs skaidrojums lēnam VPN un gandrīz vienmēr nepareizs simptomam, par kuru cilvēki ziņo. Resursdators, kas gaida nejaušu izvadi, apstājas noteiktā brīdī, parasti agri startēšanas laikā vai atslēgu apstrādes laikā. Tunelis, kas ātri pieslēdzas un pēc tam lēni pārraida drīzāk raksturo caurlaidspēju. Atdaliet šos divus novērojumus, pirms instalējat dēmonu, lai salabotu skaitli, kuru vēl neesat beiguši lasīt.

Kāpēc mīts izdzīvo

Abas problēmas ir reālas, un no attāluma tās izskatās vienādas. Startēšanas aizķeršanās tikko palaistā virtuālajā mašīnā patiešām notiek, un lēns izveidots tunelis ir tikpat reāls. Kļūda ir pieņemt, ka otro izraisa pirmais, jo kriptogrāfija kaut kur parādās abos stāstos. Nekas vārdā šifrēšana nenozīmē, ka katrs pārsūtītais baits patērē jaunu vides trokšņa baitu.

Šie ģeneratori tā nestrādā. Kriptogrāfijas bibliotēka tur sēklotu ģeneratoru un ņem no tā izvadi, pārseklējot pēc savas politikas, tāpēc dārgais mirklis ir sēklošana, nevis vienmērīga pārsūtīšana.

Ko ģenerators dara katram pakešu

OpenSSL 3 noklusējuma ģeneratoru hierarhija tiek veidota no DRBG instancēm, kas sēklē un pārseklē atbilstoši konfigurācijai un stāvoklim. OpenVPN 2.6 AEAD datu ceļš atvasina savu nonce no paketes secības numura kopā ar netiešu vērtību katrai sesijai, bet vecākais CBC ceļš katram paketei ņem pseidogadījuma IV. Neviens modelis neatbalsta noteikumu, ka gigabaita pārvietošana patērē gigabaitu svaiga kodola trokšņa. Abi atbalsta ideju, ka atslēgu ģenerēšana un rokas paspiešana ir vieta, kur sēklošana ir svarīga.

CBC gadījums ir pelnījis nosaukumu, jo tas izskatās kā mīts un nav: tā IV katram paketei nāk no bibliotēkas ģeneratora pēc bibliotēkas pašas pārseklēšanas grafika, nekad no kodola izsaukuma katram paketei. Kad kāds citē entropijas izmaksas uz baitu, jautājiet, kuru bibliotēkas versiju un kuru koda ceļu viņi mērīja.

Kur gaidīšana patiešām parādās

Lieciet laika zīmogus ap posmiem, nevis ap sesiju: startēšana, autentifikācija, atslēgas maiņa un pārsūtīšana. Gaidīšana pirms tuneļa kļūst lietojams ir cits sūdzības veids nekā zems vienmērīgs ātrums, un tikai viens no tiem norāda uz nejaušību. Linux vidē parasts getrandom() pieprasījums var bloķēties, līdz kodola nejaušības avots tiek inicializēts, tāpēc šīs problēmas startēšanas versija ir reāla virtuālajās mašīnās un iegultajās platēs, kurām agri ir maz ar ko barot baseinu.

Divi lēti komandas pieder šīs kolekcijas sākumam, un tie atrisina vieglos jautājumus, pirms tabula vispār ir vajadzīga. Skaitītājs, ko tie lasa, ir entropijas uzskaite, nevis joslas platuma mērītājs, un viens momentuzņēmums nevar parādīt, ka process ir bloķēts, cik ilgi tas gaidīja vai kuru saskarni izsauc tā bibliotēkas funkcijas. Pēc atveseļošanās ņemts paraugs parasti pilnībā palaiž garām aizķeršanos, tāpēc turiet kodola versiju blakus nolasījumam.

cat /proc/sys/kernel/random/entropy_avail
uname -r

Saskaņojiet labojumu ar nolasījumu

Ja kodols patiešām gaida inicializāciju, skatieties uz platformas atbalstīto sēklošanas ceļu, nevis uz tuneli. Virtuālajai mašīnai var dot resursdatora nodrošinātu nejaušu ierīci, piemēram, virtio-rng, un attēla sagatavošana ir svarīga, jo nemainīgi daudzos viesos iekopēta sēkla nav neatkarīga inicializācija. Ja bibliotēka pēc startēšanas ziņo par sēklošanas neveiksmēm, pārbaudiet tās konfigurēto avotu un pakalpojumu sniedzēja uzvedību, nevis mainiet kodola iestatījumus.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

OpenSSL ģeneratora dokumentācija apraksta, kā šī hierarhija iegūst ievadi un kad notiek pārseklēšana, kas ir daudz šaurāks apgalvojums par mītu un attiecas tikai uz šo ieviešanu. Entropijas dēmons nav universāls ātruma labojums, un tā instalēšana, lai skaitītājs celtos, maina drošības pieņēmumu, nepierādot kavēšanos. Attiecībā uz caurlaidspēju sekojiet datu ceļam: viens piesātināts pavediens, atkārtotas sūtīšanas, ārējie zudumi un rindu nomešana katrs prasa citu labojumu, un buferu izmēri risina ligzdas buferēšanu ar saviem rindu pierādījumiem.