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

Первая команда показывает состояние очереди и перегрузки для одного партнёра. Вторая и третья сообщают о сбросах и повторных передачах на уровне стека и интерфейса, где причина обычно появляется первой.

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

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

Если доказательства указывают на путь данных, настройте то, на что указывают счётчики. Размеры буферов помогают, когда очереди переполняются, и ничего не делают, когда один поток насыщен. Установка демона энтропии ради поднятия счётчика — не ремонт пропускной способности, а изменение допущений инициализации, чтобы график выглядел лучше, меняет свойство безопасности на число.

Принимайте изменение только тогда, когда то же измерение улучшается при тех же условиях. Больший счётчик — не результат; более короткое измеренное ожидание или более быстрая передача с установленной причиной — результат.