Старий профіль .ovpn не працює на Ubuntu 24.04: які рядки видалити

Ubuntu 24.04 постачається з OpenVPN 2.6, і профіль, експортований для 2.4, падає на вилучених опціях. Видаліть keysize і ncp-disable, потім виправте ns-cert-type.

Профіль завантажується, імпортується, а потім зупиняється на 12-му рядку файлу з повідомленням Unrecognized option, у якому названо keysize. В обліковому записі нічого не змінилося, і сервер досі приймає інших клієнтів. Змінився сам клієнт: Ubuntu 24.04 встановлює OpenVPN 2.6, тоді як експорт було написано для 2.4. Виправлення — це коротка серія видалень, і порядок важливий, бо кожна застаріла опція обриває розбір ще до того, як наступна взагалі буде прочитана.

Прочитайте рядок помилки, перш ніж торкатися файлу

OpenVPN називає файл і рядок, на якому розбір зупинився, тож за один запуск можна виправити лише одну проблему. Запускайте профіль із термінала, а не з аплета робочого столу, бо аплет зазвичай ковтає stderr, а номер рядка — єдина надійна підказка, яку ви отримаєте: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Виправте цей рядок, запустіть знову і чекайте, що наступна помилка назве іншу опцію.

Помилка розбору завжди з'являється до будь-якого рукостискання TLS, тож повідомлення зі згадкою сертифіката вже пройшло етап синтаксису. Ця відмінність не дає редагувати файл, який падає лише на автентифікації. Читайте перше слово повідомлення, а не його середину.

Три класи збоїв, три різні виправлення

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

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

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

Видаліть опції, які прибрали в 2.6, у такому порядку

Кожен із цих рядків сам зупиняє розбір, тож клієнт повідомляє про них по одному. Ідіть списком донизу й запускайте знову після кожного видалення.

Спершу видаліть keysize, бо вона не має сучасного еквівалента, а її наявність зазвичай указує на шифр, від якого поточний клієнт усе одно відмовляється. Потім видаліть ncp-disable, яка керувала узгодженням шифрів, була оголошена застарілою в 2.5 і зникла в 2.6. Замініть ns-cert-type server на remote-cert-tls server, яка виражає той самий намір через підтримувану перевірку.Історія змін 2.6 перелічує решту видалень поруч із їхніми замінами, тож усе, що парсер ще відкидає, має задокументовану відповідь.

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

Тримайте BF-CBC робочим лише як обмежений запасний варіант

Деякі провайдери досі завершують на BF-CBC, який OpenVPN 2.6 не стане узгоджувати без допомоги, бо цей шифр має 64-бітний блок. Вузьке виправлення — це список запасних варіантів плюс legacy-провайдер OpenSSL, а не зниження версії всього клієнта.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

Перший рядок завантажує legacy-провайдер, щоб OpenSSL усе ще міг створити цей шифр, другий зберігає сучасне узгодження для пірів, які його підтримують, а третій застосовується лише тоді, коли сервер не пропонує нічого кращого. Це свідоме послаблення тунелю, тож запишіть поруч із файлом, чому воно існує. Одночасно попросіть у провайдера перестворений експорт, адже запасний варіант — це міст, а не кінцева мета.

Не хапайтеся за --compat-mode як за універсальну відповідь. Він змінює кілька поведінок одразу, зокрема усталені параметри узгодження та повторного узгодження, тож ви так і не дізнаєтеся, яка зміна мала значення. Надавайте перевагу трьом явним рядкам вище, бо кожен заявляє власний ефект.

Перевіряйте за тим профілем, який клієнт справді завантажує

Імпортовані підключення часто копіюються в системний каталог, тож правка файлу в папці завантажень може взагалі нічого не змінити. Знайдіть копію, яка працює: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Потім запустіть тунель і прочитайте рядок журналу, де вказано фактично вибраний шифр каналу даних. Підключення, яке завершує рукостискання на запасному варіанті, говорить, що сервер так і не запропонував нічого сучасного.

Перевіряйте з мережі, яка не та, що очікує провайдер, щоб captive-портал або відфільтрована гостьова мережа не видавали себе за несправність профілю. Записуйте версію клієнта разом із будь-яким запитом до підтримки.

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

Схожі статті