Проблем с ентропията ли е ниската пропусквателна способност на 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'

Първата команда показва състоянието на опашката и задръстването за един партньор. Втората и третата отчитат отхвърляния и повторни предавания в стека и на интерфейса, където причината обикновено се появява първа.

Изберете поправката за измереното тясно място

Ако доказателствата сочат към инициализация при ранно стартиране, погледнете поддържания от платформата път за зареждане, който на виртуална машина може да включва предоставено от хоста случайно устройство. Образ за зареждане, копиран непроменен в много гости, не заменя независимата инициализация.

Ако доказателствата сочат към пътя на данните, настройте това, което броячите сочат. Размерите на буферите помагат, когато опашките преливат, и не правят нищо, когато една нишка е наситена. Инсталирането на демон за ентропия, за да вдигне брояч, не е поправка на пропусквателната способност, а промяната на допусканията за зареждане, за да изглежда графиката по-добре, разменя свойство за сигурност срещу число.

Приемете промяната само когато същото измерване се подобри при същите условия. По-голям брояч не е резултат; по-кратко измерено чакане или по-бързо пренасяне с установена причина е резултат.