Dochází u VPN entropie? Co entropy_avail skutečně ukazuje

Vyčerpání náhodnosti v jádře je lákavé vysvětlení pomalé VPN a téměř vždy nesprávné pro příznak, který lidé hlásí. Host, který čeká na náhodný výstup, se v určitém okamžiku zablokuje, obvykle brzy při startu nebo během zpracování klíčů. Tunel, který se rychle připojí a pak pomalu přenáší místo toho popisuje propustnost. Oddělte tato dvě pozorování, než nainstalujete démona, abyste opravili číslo, které jste nedočetli.

Proč mýtus přežívá

Oba problémy jsou skutečné a zdálky vypadají stejně. Zpoždění při startu na čerstvě spuštěném virtuálním stroji se opravdu dějí a pomalý navázaný tunel je stejně skutečný. Chyba je předpokládat, že druhý je způsoben prvním, protože se v obou příbězích někde objevuje kryptografie. Nic ve slově šifrování nenaznačuje, že každý přenesený bajt spotřebuje čerstvý bajt šumu prostředí.

Tyto generátory tak nefungují. Kryptografická knihovna drží generátor s počáteční hodnotou a čerpá z něj výstup, znovu jej zasévá podle vlastní politiky, takže drahým okamžikem je zasetí, nikoli stálý přenos.

Co generátor dělá pro každý paket

V OpenSSL 3 se výchozí hierarchie generátorů staví z instancí DRBG, které zasévají a znovu zasévají podle konfigurace a stavu. V OpenVPN 2.6 odvozuje datová cesta AEAD svůj nonce z pořadového čísla paketu v kombinaci s implicitní hodnotou pro relaci, zatímco starší cesta CBC čerpá pseudonáhodný IV pro každý paket. Ani jeden vzor nepodporuje pravidlo, že přesun gigabajtu spotřebuje gigabajt čerstvého šumu jádra. Oba však podporují myšlenku, že generování klíčů a handshaky jsou místem, kde záleží na zasetí.

Případ CBC stojí za pojmenování, protože vypadá jako mýtus a není: jeho IV pro každý paket pochází z generátoru knihovny podle vlastního plánu opětovného zasetí, nikdy z volání jádra pro každý paket. Když někdo uvede cenu entropie na bajt, zeptejte se, kterou verzi knihovny a kterou kódovou cestu měřili.

Kde se čekání skutečně projeví

Umístěte časová razítka kolem fází, ne kolem relace: start, ověřování, změna klíče a přenos. Čekání předtím, než je tunel použitelný, je jiná stížnost než nízká stálá rychlost a jen jedno z nich ukazuje na náhodnost. V Linuxu může normální požadavek getrandom() blokovat, dokud není inicializován náhodný zdroj jádra, a proto je verze tohoto problému při startu skutečná na virtuálních strojích a vestavěných deskách, které mají brzy málo čím krmit pool.

Dva levné příkazy patří na začátek tohoto sběru a vyřeší snadné otázky dřív, než je tabulka vůbec potřeba. Čítač, který čtou, je entropické účetnictví, nikoli měřák šířky pásma, a jediný snímek nemůže ukázat, že je proces blokovaný, jak dlouho čekal ani které rozhraní jeho knihovní funkce volají. Vzorek odebraný po obnovení obvykle zpoždění úplně mine, proto držte verzi jádra vedle odečtu.

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

Slaďte opravu s odečtem

Pokud jádro opravdu čeká na inicializaci, dívejte se na podporovanou cestu zasetí na platformě, ne na tunel. Virtuálnímu stroji lze dát náhodné zařízení poskytnuté hostitelem, například virtio-rng, a příprava obrazu je důležitá, protože semeno zkopírované beze změny do mnoha hostů není nezávislá inicializace. Pokud knihovna po startu hlásí selhání zasetí, prozkoumejte její nakonfigurovaný zdroj a chování poskytovatele, místo abyste měnili nastavení jádra.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

Dokumentace generátoru OpenSSL popisuje, jak tato hierarchie získává vstup a kdy dochází k opětovnému zasetí, což je mnohem užší tvrzení než mýtus a platí jen pro tuto implementaci. Entropický démon není univerzální oprava rychlosti a jeho instalace, aby čítač stoupl, mění bezpečnostní předpoklad, aniž by prokázala zpoždění. Pro propustnost sledujte datovou cestu: jedno nasycené vlákno, opakované přenosy, vnější ztráty a zahazování front potřebují každé jinou opravu a velikosti bufferů řeší bufferování socketu s vlastními důkazy z front.