Низька пропускна здатність 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'

Перша команда показує стан черги й перевантаження для одного партнера. Друга й третя повідомляють про відкидання й повторні передачі на рівні стека та інтерфейсу, де причина зазвичай з'являється першою.

Виберіть виправлення для виміряного вузького місця

Якщо докази вказують на ініціалізацію під час раннього завантаження, подивіться на підтримуваний платформою шлях ініціалізації, який на віртуальній машині може включати наданий хостом випадковий пристрій. Образ насіння, скопійований без змін у багатьох гостей, не замінює незалежної ініціалізації.

Якщо докази вказують на шлях даних, налаштуйте те, на що вказують лічильники. Розміри буферів допомагають, коли черги переповнюються, і нічого не роблять, коли один потік насичений. Встановлення демона ентропії, щоб підняти лічильник, не є ремонтом пропускної здатності, а зміна припущень ініціалізації, щоб графік виглядав краще, міняє властивість безпеки на число.

Приймайте зміну лише тоді, коли те саме вимірювання покращується за тих самих умов. Більший лічильник — не результат; коротше виміряне очікування або швидше передавання з установленою причиною — результат.