Да ли VPN остаје без ентропије? Шта entropy_avail заиста показује

Нестајање случајности у језгру привлачно је објашњење за спор VPN и готово увек погрешно за симптом који људи пријављују. Домаћин који чека на случајан излаз застане у одређеном тренутку, обично рано при подизању или током обраде кључева. Тунел који се брзо повеже и затим споро преноси заправо описује пропусност. Раздвојте та два запажања пре него што инсталирате демон да поправите број који нисте до краја прочитали.

Зашто мит опстаје

Оба проблема су стварна и издалека изгледају исто. Застоји при покретању на тек подигнутој виртуелној машини заиста се догађају, а спор успостављени тунел једнако је стваран. Грешка је претпоставити да други узрокује први јер се криптографија појављује негде у обе приче. Ништа у речи енкрипција не имплицира да сваки пренесени бајт троши свеж бајт шума из окружења.

Ови генератори не раде тако. Криптографска библиотека држи генератор са семеном и црпи излаз из њега, поново га засејавајући по сопственој политици, па је скуп тренутак засејавање, а не сталан пренос.

Шта генератор ради по пакету

У OpenSSL 3 подразумевана хијерархија генератора гради се од DRBG инстанци које засејавају и поново засејавају према конфигурацији и стању. У OpenVPN 2.6 AEAD путања података изводи свој nonce из редног броја пакета у комбинацији са имплицитном вредношћу по сесији, док старија CBC путања црпи псеудослучајни IV по пакету. Ниједан образац не подржава правило да премештање гигабајта троши гигабајт свежег шума језгра. Оба подржавају идеју да су генерисање кључева и руковања место где је засејавање важно.

Случај CBC вреди именовати јер изгледа као мит а није: његов IV по пакету долази из генератора библиотеке по сопственом распореду поновног засејавања, никада из позива језгра по пакету. Када неко наведе цену ентропије по бајту, питајте које су верзије библиотеке и које кодне путање мерили.

Где се чекање заправо види

Поставите временске ознаке око фаза, а не око сесије: покретање, провера идентитета, промена кључа и пренос. Чекање пре него тунел постане употребљив другачија је жалба од ниске сталне брзине, и само једна од њих указује на случајност. На Linux-у нормалан захтев getrandom() може блокирати док се случајни извор језгра не иницијализује, зато је верзија овог проблема при подизању стварна на виртуелним машинама и уграђеним плочама које рано имају мало чиме да хране базен.

Две јефтине команде припадају на почетак те збирке и решавају лака питања пре него што табела уопште затреба. Бројач који читају је ентропијско књиговодство, а не мерач пропусности, и један снимак не може показати да је процес блокиран, колико је чекао ни које интерфејсе позивају његове библиотечке функције. Узорак узет након опоравка обично потпуно промаши застој, па држите верзију језгра уз очитавање.

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

Ускладите исправку са очитавањем

Ако језгро заиста чека иницијализацију, гледајте подржану путању засејавања на платформи, а не тунел. Виртуелној машини може се дати од домаћина обезбеђен случајни уређај, попут virtio-rng, а припрема слике је важна јер семе копирано непромењено у многе госте није независна иницијализација. Ако библиотека пријави неуспехе засејавања након подизања, прегледајте њен конфигурисани извор и понашање добављача уместо да мењате поставке језгра.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

Документација OpenSSL генератора описује како та хијерархија добија улаз и када се поновно засејавање догађа, што је далеко ужа тврдња од мита и важи само за ту имплементацију. Ентропијски демон није универзална брзинска поправка, а инсталирање да би бројач порастао мења сигурносну претпоставку без доказивања кашњења. За пропусност следите путању података: једна засићена нит, поновна слања, спољни губици и одбацивања редова захтевају сваки своју исправку, а величине међуспремника решавају међуспремање утичница са сопственим доказима из редова.