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