Да ли је низак VPN проток проблем ентропије? Обично није

Спор проток кроз тунел и машина заглављена у чекању случајних бројева дају веома различита искуства, али се ипак евидентирају под истом притужбом. Једно се појављује као пауза пре него што ишта ради. Друго се појављује као веза која ради и полако преноси податке док год је гледате. Утврдити које имате траје десет минута и штеди недељу нагађања.

Два симптома која изгледају исто

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

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

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

Прве две наредбе стављају рад при покретању на временску линију. Трећа исписује вредност књиговодства ентропије у кернелу, која је корисна као једна податковна тачка и бескорисна као мерач пропусности.

Како чекање на случајне бројеве заправо изгледа

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

Савремени генератори се засијавају једном и затим производе излаз из детерминистичке конструкције, поново се засијавајући по сопственом распореду. Скупни пренос не исцрпљује пул бајт по бајт, па ниска вредност пула током спорог преноса ништа не доказује о узроку.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

Прва наредба показује седи ли процес у позиву случајних бројева док гледате. Друга показује кернелове сопствене поруке иницијализације, и ту застој при раном подизању постаје видљив.

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

Како трајна спорост заправо изгледа

Тунел који све време полако преноси ограничен је податковним путем. Једна засићена нит, губитак спољних пакета, поновни преноси или пуни редови утичница сваки производе тај узорак, и сваки има своје решење. Збирни проценат CPU-а скрива једну заузету нит, што је најчешће погрешно читање. Погледајте време по нити пре него што погледате укупно оптерећење.

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

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

Прва наредба показује стање реда и загушења за једног партнера. Друга и трећа пријављују одбацивања и поновне преносе на стек-у и на интерфејсу, где се узрок обично појављује први.

Изаберите исправку за уско грло које сте измерили

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

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

Прихватите промену само када се исто мерење побољша под истим условима. Већи бројач није резултат; краће измерено чекање или бржи пренос са утврђеним узроком јесте.