Исчерпание случайности ядра — заманчивое объяснение медленного VPN и почти всегда неверное для симптома, о котором сообщают люди. Хост, ожидающий случайный вывод, встаёт в определённый момент, обычно в начале загрузки или при обработке ключей. Туннель, который быстро подключается и затем медленно передаёт описывает вместо этого пропускную способность. Разделите эти два наблюдения, прежде чем ставить демон, чтобы исправить число, которое вы не дочитали.

Почему миф выживает

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

Эти генераторы работают не так. Криптографическая библиотека держит генератор с семенем и берёт из него вывод, пересевая по собственной политике, поэтому дорогой момент — это засевание, а не равномерная передача.

Что генератор делает на каждый пакет

В OpenSSL 3 иерархия генераторов по умолчанию строится из экземпляров DRBG, которые засевают и пересевают согласно конфигурации и состоянию. В OpenVPN 2.6 путь данных AEAD выводит свой nonce из порядкового номера пакета вместе с неявным значением для сессии, тогда как более старый путь CBC берёт псевдослучайный IV на каждый пакет. Ни одна из схем не поддерживает правило, что перемещение гигабайта расходует гигабайт свежего шума ядра. Обе поддерживают мысль, что генерация ключей и рукопожатия — это место, где засевание имеет значение.

Случай CBC стоит назвать, потому что он похож на миф и им не является: его IV на каждый пакет приходит из генератора библиотеки по собственному графику пересева библиотеки, никогда из вызова ядра на каждый пакет. Когда кто-то приводит стоимость энтропии на байт, спросите, какую версию библиотеки и какой путь кода измеряли.

Где ожидание действительно видно

Ставьте отметки времени вокруг этапов, а не вокруг сессии: запуск, аутентификация, смена ключа и передача. Ожидание до того, как туннель станет пригодным, — это другая жалоба, чем низкая устойчивая скорость, и только одна из них указывает на случайность. В Linux обычный getrandom() запрос может блокироваться, пока случайный источник ядра не инициализирован, поэтому версия этой проблемы при загрузке реальна на виртуальных машинах и встраиваемых платах, которым вначале мало чем кормить пул.

ЭтапЧто запускатьПоказание, означающее ожиданиеПоказание, означающее пропускную способность
Загрузка, до любого туннеляsystemd-analyze critical-chainюнит, который стоит секунды до запуска туннеляне применимо, пока ничего не передаётся
Рукопожатиеjournalctl -u openvpn-server@server -bдлинный промежуток до завершения последовательности инициализациине применимо, туннель не поднят
Установленная передачаss -tin рядом с sar -n DEV 1заблокированный процесс с пустыми очередями сокетаполные очереди, повторные передачи и один занятый поток

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

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

Согласуйте исправление с показанием

Если ядро действительно ждёт инициализации, смотрите на поддерживаемый платформой путь засевания, а не на туннель. Виртуальной машине можно дать случайное устройство от хоста, например virtio-rng, и подготовка образа важна, потому что семя, скопированное без изменений во многих гостей, не является независимой инициализацией. Если библиотека сообщает об ошибках засевания после загрузки, изучайте её настроенный источник и поведение провайдера, а не меняйте настройки ядра.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

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

Похожие статьи