Стары профіль .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, на якую ён накіраваны.

Падобныя артыкулы