Почему OpenVPN перестал подключаться после обновления Ubuntu?

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

Какой слой отказал: рукопожатие, шифр, пакет или библиотека

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

Жалобы на сертификаты и подписи или сообщение о длине ключа приходят из канала управления и политики библиотеки, которая им управляет. А предупреждение, начинающееся с DEPRECATED OPTION, относится вместо этого к согласованию канала данных.

Строка вида Unrecognized option — третья категория: новый двоичный файл больше не принимает директиву, которую терпел старый, поэтому профиль нужно переписать, а не ослаблять библиотеку. Сбои пакетов выглядят иначе, потому что происходят до запуска любого кода туннеля. Отсутствующий двоичный файл, плагин, который не загружается, или репозиторий с неверным кодовым именем дают одну и ту же форму. Четыре симптома, четыре места для проверки и почти никакого пересечения между исправлениями.

Когда рукопожатие не удаётся, политика TLS отклоняет сертификат

Ubuntu 22.04 перевёл систему на OpenSSL 3, и уровень безопасности по умолчанию в этой ветке строже к подписям сертификатов и размерам ключей, чем был в 20.04. Сертификат CA, подписанный старым дайджестом, или ключ ниже текущего порога теперь не проходят во время рукопожатия. Поскольку ещё ничего не аутентифицировано, ошибка читается как неверный пароль или мёртвый сервер.

Узкое исправление привязывает строку шифра только к этому соединению. В настольном редакторе откройте профиль, перейдите в дополнительные настройки и впишите DEFAULT:@SECLEVEL=0 в поле шифра TLS. Файл ключей NetworkManager принимает то же значение в разделе [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Перезапустите NetworkManager и подключитесь заново, потому что демон кэширует разобранные профили и иначе продолжит использовать уже имеющуюся копию. Знайте, что делает строка, прежде чем её оставить: этот параметр — порог по нескольким параметрам сертификатов и ключей, а не имя шифра, поэтому его снижение расширяет то, что принимает отдельный профиль. Запишите, какой сервер этого потребовал, и снимите настройку, когда оператор перевыпустит актуальный материал. Изменение /etc/ssl/openssl.cnf достигает того же порога для каждой программы, читающей этот файл, что выходит далеко за пределы VPN.

OpenVPN 2.6 требует, чтобы шифр был указан для согласования

Ubuntu 22.10 принёс OpenVPN 2.6, и в этом выпуске --cipher перестаёт сам выбирать канал данных. Шифр также должен присутствовать в согласованном списке data-ciphers, иначе клиент печатает предупреждение об устаревании и затем не может поднять туннель.

Плагин NetworkManager того же периода по-прежнему писал только старую директиву. Эта деталь разделяет диагностику, потому что профиль, исправленный вручную, может подключиться из оболочки и всё равно сбоить из настольного апплета. Добавьте список в файл соединения в разделе [vpn]:

data-ciphers=AES-256-CBC

Используйте значение, которое объявляет сервер, а не то, что вы помните; сервер, предлагающий AES-256-GCM, не будет согласовывать с клиентским списком, где указан только CBC. Перезапустите менеджер и подключитесь снова, затем повторите попытку из оболочки, явно передав шифр и для согласования, и для резерва:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Если эта команда поднимет туннель, сервер, сертификаты и учётные данные в порядке, и единственная оставшаяся неисправность — сохранённый параметр менеджера. Предупреждение о директиве keysize относится к той же уборке: закомментируйте её и держите исходный файл рядом с профилем.

Сбои пакетов и плагинов выглядят как сбои VPN

Не каждый сбой после обновления криптографический. Репозиторий OpenVPN, добавленный под кодовым именем, которое выпуск не использует, даёт пакет, который никогда не установится, поэтому сравните, что сообщает lsb_release -a, с добавленным файлом списка. Отсутствующий компонент universe или карман безопасности дают пакет, который вообще невозможно найти. Оба случая оставляют профиль нетронутым, а туннель — невозможным.

Прочитайте ошибку менеджера пакетов раньше журнала VPN. Если клиент так и не был установлен, никакое редактирование профиля не даст рукопожатия.

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

Библиотека поставщика может скрываться за ошибкой политики

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

Переустановка пакета VPN не меняет того, какая библиотека будет найдена первой, а снижение уровня TLS не достаёт до библиотеки, которая никогда не приходила из системы. Спросите загрузчик, какие криптообъекты двоичный файл действительно разрешает:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

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

Закрепление старого клиента покупает время, а не решение

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

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

В следующий раз, когда VPN умирает после обновления выпуска, задайте пять вопросов по порядку: какой слой дал первую ошибку, отклонила ли политика TLS сертификат, согласуется ли шифр в обе стороны, действительно ли установились пакет и его плагин и какую библиотеку загружает процесс. Только когда все пять возвращаются чистыми, понижение версии имеет смысл.