Ali VPN zmanjka entropije? Kaj entropy_avail v resnici pokaže

Zmanjkanje naključnosti jedra je privlačna razlaga za počasen VPN in skoraj vedno napačna za simptom, ki ga ljudje prijavljajo. Gostitelj, ki čaka na naključni izhod, se ustavi v določenem trenutku, običajno zgodaj ob zagonu ali med obdelavo ključev. Tunel, ki se hitro poveže in nato počasi prenaša namesto tega opisuje prepustnost. Ločite ti dve opažanji, preden namestite demona, da popravite število, ki ga še niste prebrali do konca.

Zakaj mit preživi

Obe težavi sta resnični in od daleč izgledata enako. Zastoji ob zagonu na sveže zagnanem navideznem stroju se res dogajajo, počasen vzpostavljen tunel pa je prav tako resničen. Napaka je domnevati, da drugega povzroča prvi, ker se kriptografija pojavi nekje v obeh zgodbah. Nič v besedi šifriranje ne pomeni, da vsak preneseni bajt porabi svež bajt šuma okolja.

Ti generatorji ne delujejo tako. Kriptografska knjižnica hrani generator s semenom in črpa izhod iz njega, znova seje po svoji politiki, zato je drag trenutek sejanje in ne enakomeren prenos.

Kaj generator naredi na paket

V OpenSSL 3 se privzeta hierarhija generatorjev gradi iz instanc DRBG, ki sejejo in znova sejejo glede na konfiguracijo in stanje. V OpenVPN 2.6 podatkovna pot AEAD izpelje svoj nonce iz zaporedne številke paketa skupaj z implicitno vrednostjo na sejo, medtem ko starejša pot CBC črpa psevdonaključni IV na paket. Noben vzorec ne podpira pravila, da premik gigabajta porabi gigabajt svežega šuma jedra. Oba podpirata idejo, da sta ustvarjanje ključev in rokovanja tisto, kjer je sejanje pomembno.

Primer CBC velja imenovati, ker izgleda kot mit in ni: njegov IV na paket prihaja iz generatorja knjižnice po lastnem urniku ponovnega sejanja knjižnice, nikoli iz klica jedra na paket. Ko nekdo navaja strošek entropije na bajt, vprašajte, katero različico knjižnice in katero kodno pot so merili.

Kje se čakanje res pokaže

Časovne žige postavite okoli faz, ne okoli seje: zagon, preverjanje pristnosti, menjava ključa in prenos. Čakanje, preden je tunel uporaben, je druga pritožba kot nizka stalna hitrost, in le ena od njiju kaže na naključnost. V Linuxu lahko običajna zahteva getrandom() blokira, dokler ni inicializiran naključni vir jedra, zato je različica te težave ob zagonu resnična na navideznih strojih in vgrajenih ploščah, ki imajo zgodaj malo za hranjenje bazena.

Dva poceni ukaza spadata na začetek tega zbiranja in razrešita lahka vprašanja, preden je tabela sploh potrebna. Števec, ki ga bereta, je entropijsko knjigovodstvo in ne merilnik pasovne širine, in en posnetek ne more pokazati, da je proces blokiran, koliko je čakal ali kateri vmesnik kličejo njegove knjižnične funkcije. Vzorec, odvzet po obnovitvi, običajno popolnoma zgreši zastoj, zato imejte različico jedra ob odčitku.

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

Popravek uskladite z odčitkom

Če jedro res čaka na inicializacijo, poglejte podprto pot sejanja na platformi, ne tunela. Navideznemu stroju je mogoče dati naključno napravo, ki jo zagotovi gostitelj, na primer virtio-rng, in priprava slike je pomembna, ker seme, kopirano nespremenjeno v številne goste, ni neodvisna inicializacija. Če knjižnica po zagonu poroča o napakah sejanja, preglejte njen nastavljeni vir in vedenje ponudnika, namesto da spreminjate nastavitve jedra.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

Dokumentacija generatorja OpenSSL opisuje, kako ta hierarhija pridobi vhod in kdaj pride do ponovnega sejanja, kar je veliko ožja trditev kot mit in velja le za to izvedbo. Entropijski demon ni univerzalno popravilo hitrosti in njegova namestitev, da bi števec narasel, spremeni varnostno predpostavko, ne da bi dokazala zamik. Pri prepustnosti sledite podatkovni poti: ena nasičena nit, ponovni prenosi, zunanje izgube in odpadanje vrst zahtevajo vsak svoj popravek, velikosti medpomnilnikov pa naslavljajo medpomnjenje vtičnic z lastnimi dokazi iz vrst.