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