Чому 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 сертифікат, чи узгоджується шифр в обидва боки, чи справді встановилися пакет і його плагін і яку бібліотеку завантажує процес. Лише коли всі п'ять повертаються чистими, зниження версії має сенс.