Старият .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 изброява останалите премахвания до техните замени, така че всичко, което разборът все още отхвърля, има документиран отговор.

Пазете копие на оригиналния профил преди първата редакция. Доставчиците прегенерират експорти и diff срещу недокоснатия файл е най-бързият начин да отделите вашите промени от техните. Ако изтриване позволи на клиента да стартира, но тунелът пак се проваля, влезли сте в класа на договарянето и останалите редове не са причината. Сложете версията на клиента в името на файла, за да знае следващият човек към коя версия са насочени редакциите.

Пазете BF-CBC работещ само като ограничен резервен вариант

Някои доставчици все още прекратяват на BF-CBC, с който OpenVPN 2.6 няма да се договори без помощ, защото шифърът има 64-битов блок. Тясната поправка е резервен списък плюс стария доставчик на OpenSSL, а не понижаване на целия клиент.

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

Първият ред зарежда стария доставчик, за да може OpenSSL все още да създаде този шифър, вторият запазва модерното договаряне за партньори, които го поддържат, а третият се прилага само когато сървърът не предложи нищо по-добро. Това е умишлено отслабване на тунела, затова запишете защо съществува до файла. Помолете доставчика едновременно за прегенериран експорт, защото резервният вариант е мост, а не дестинация.

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

Проверете с профила, който клиентът наистина зарежда

Импортираните връзки често се копират в системна директория, така че редактирането на файла в папката за изтегляния може да не промени нищо. Намерете копието, което работи: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. После стартирайте тунела и прочетете реда в журнала, който съобщава кой шифър на канала за данни е избран действително. Връзка, която завършва ръкостискането на резервния вариант, ви казва, че сървърът не е предложил нищо модерно.

Тествайте от мрежа, която не е тази, която доставчикът очаква, за да не се представя captive portal или филтрирана гостуваща мрежа като дефект в профила. Записвайте версията на клиента заедно с всяка заявка до поддръжката.

Щом тунелът е вдигнат, изпратете една заявка, която трябва да мине през него, и една, която не трябва, после потвърдете, че отговорът на резолвера се е променил както очаквахте. Ако профилът вече се разбира, но връзката пак се проваля, оставили сте синтактичния проблем зад себе си и текстът на грешката ще посочи новия клас. Дръжте редактирания файл в система за контрол на версиите до бележка, която посочва версията на OpenVPN, за която е предназначен.

Подобни статии