Dochádza pri VPN entropia? Čo entropy_avail naozaj ukazuje

Vyčerpanie náhodnosti jadra je lákavé vysvetlenie pomalého VPN a takmer vždy nesprávne pre príznak, ktorý ľudia hlásia. Hostiteľ čakajúci na náhodný výstup sa v určitom okamihu zablokuje, zvyčajne skoro pri štarte alebo počas spracovania kľúčov. Tunel, ktorý sa rýchlo pripojí a potom pomaly prenáša namiesto toho opisuje priepustnosť. Oddeľte tieto dve pozorovania, skôr než nainštalujete démona, aby ste opravili číslo, ktoré ste nedocítali.

Prečo mýtus prežíva

Oba problémy sú skutočné a zdiaľky vyzerajú rovnako. Zdržania pri štarte na čerstvo spustenom virtuálnom stroji sa naozaj dejú a pomalý nadviazaný tunel je rovnako skutočný. Chyba je predpokladať, že druhý je spôsobený prvým, pretože sa v oboch príbehoch niekde objavuje kryptografia. Nič v slove šifrovanie nenaznačuje, že každý prenesený bajt spotrebuje čerstvý bajt šumu prostredia.

Tieto generátory tak nefungujú. Kryptografická knižnica drží generátor s počiatkom a čerpá z neho výstup, znova ho nasýpa podľa vlastnej politiky, takže drahým okamihom je nasypanie, nie stály prenos.

Čo generátor robí pre každý paket

V OpenSSL 3 sa predvolená hierarchia generátorov stavia z inštancií DRBG, ktoré nasýpajú a znovu nasýpajú podľa konfigurácie a stavu. V OpenVPN 2.6 odvodzuje dátová cesta AEAD svoj nonce z poradového čísla paketu spolu s implicitnou hodnotou pre reláciu, zatiaľ čo staršia cesta CBC čerpá pseudonáhodný IV pre každý paket. Ani jeden vzor nepodporuje pravidlo, že presun gigabajtu spotrebuje gigabajt čerstvého šumu jadra. Oba podporujú myšlienku, že generovanie kľúčov a podávanie rúk sú miestom, kde záleží na nasypaní.

Prípad CBC stojí za pomenovanie, pretože vyzerá ako mýtus a nie je: jeho IV pre každý paket pochádza z generátora knižnice podľa vlastného plánu opätovného nasypania knižnice, nikdy z volania jadra pre každý paket. Keď niekto uvádza cenu entropie na bajt, spýtajte sa, ktorú verziu knižnice a ktorú kódovú cestu merali.

Kde sa čakanie naozaj prejaví

Umiestnite časové pečiatky okolo fáz, nie okolo relácie: štart, overovanie, zmena kľúča a prenos. Čakanie predtým, než je tunel použiteľný, je iná sťažnosť ako nízka stála rýchlosť, a iba jedno z nich ukazuje na náhodnosť. V Linuxe môže normálna požiadavka getrandom() blokovať, kým nie je inicializovaný náhodný zdroj jadra, preto je verzia tohto problému pri štarte skutočná na virtuálnych strojoch a vstavaných doskách, ktoré majú na začiatku málo čím kŕmiť bazén.

Dva lacné príkazy patria na začiatok tohto zberu a vyriešia ľahké otázky skôr, než je tabuľka vôbec potrebná. Počítadlo, ktoré čítajú, je entropické účtovníctvo, nie merač šírky pásma, a jediná snímka nemôže ukázať, že proces je zablokovaný, ako dlho čakal ani ktoré rozhranie volajú jeho knižničné funkcie. Vzorka odobratá po obnovení zvyčajne zdržanie úplne minie, preto držte verziu jadra vedľa odčítania.

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

Zlaďte opravu s odčítaním

Ak jadro naozaj čaká na inicializáciu, pozrite sa na podporovanú cestu nasypania na platforme, nie na tunel. Virtuálnemu stroju možno dať náhodné zariadenie poskytnuté hostiteľom, napríklad virtio-rng, a príprava obrazu je dôležitá, pretože semeno skopírované bez zmeny do mnohých hostí nie je nezávislá inicializácia. Ak knižnica po štarte hlási zlyhania nasypania, preskúmajte jej nakonfigurovaný zdroj a správanie poskytovateľa, namiesto zmeny nastavení jadra.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

Dokumentácia generátora OpenSSL opisuje, ako táto hierarchia získava vstup a kedy dochádza k opätovnému nasypaniu, čo je omnoho užšie tvrdenie ako mýtus a platí len pre túto implementáciu. Entropický démon nie je univerzálna oprava rýchlosti a jeho inštalácia, aby počítadlo stúplo, mení bezpečnostný predpoklad bez preukázania zdržania. Pri priepustnosti sledujte dátovú cestu: jedno nasýtené vlákno, opakované prenosy, vonkajšie straty a zahadzovanie frontov potrebujú každé inú opravu a veľkosti bufferov riešia bufferovanie socketu s vlastnými dôkazmi z frontov.