Miért hagyott fel az OpenVPN a csatlakozással egy Ubuntu-frissítés után?

A múlt héten még működő VPN-profilok egy Ubuntu-kiadásfrissítés után eltörnek, és a napló ritkán említi is a frissítést. Amit megnevez, az a réteg, amely meghiúsult: a TLS-kézfogás, az adatcsatornához egyeztetett titkosítás, a telepített csomag vagy az OpenSSL azon másolata, amelyet a bináris indításkor betölt. Minden rétegnek megvan a maga hibaformája és a maga javítása, ezért az osztályozás az első munka, a szerkesztés a második. Tekintse a profilt ártatlannak, amíg a napló meg nem nevezi.

Melyik réteg hibázott: kézfogás, titkosítás, csomag vagy könyvtár

Olvassa el az ügyfél naplóját, mielőtt hozzányúlna a profilhoz. A legkorábbi hiba a kimenetben az, amely azonosítja a réteget; minden utána nyomtatott általában az első hiba következménye. Ha az ügyfél egyáltalán nem indul el, a VPN-napló a rossz fájl a megnyitáshoz.

A tanúsítványokra és aláírásokra vonatkozó panaszok, vagy a kulcshosszról szóló üzenet a vezérlőcsatornából és az azt szabályozó könyvtár-szabályzatból származnak. A DEPRECATED OPTION kezdetű figyelmeztetés viszont az adatcsatorna egyeztetéséhez tartozik.

Az ilyen sor Unrecognized option harmadik kategória: az új bináris már nem fogad el olyan direktívát, amelyet a régi eltűrt, tehát a profilt kell újraírni, nem a könyvtárat lazítani. A csomaghibák megint másképp néznek ki, mert azok bármilyen alagútkód futása előtt történnek. Hiányzó bináris, be nem töltődő bővítmény vagy rossz kódnévre mutató tároló mind ezt a formát adja. Négy tünet, négy hely, ahol keresni kell, és szinte semmi átfedés a javítások között.

Amikor a kézfogás meghiúsul, a TLS-szabályzat elutasítja a tanúsítványt

Az Ubuntu 22.04 az OpenSSL 3-ra állította a rendszert, és ebben az ágban az alapértelmezett biztonsági szint szigorúbb a tanúsítvány-aláírások és kulcsméretek tekintetében, mint a 20.04-ben volt. A régebbi kivonattal aláírt CA-tanúsítvány vagy a jelenlegi küszöb alatti kulcs most a kézfogás alatt hiúsul meg. Mivel még semmi nem hitelesített, a hiba rossz jelszónak vagy halott kiszolgálónak tűnik.

A szűk javítás csak ehhez a kapcsolathoz fűz egy titkosítási karakterláncot. Az asztali szerkesztőben nyissa meg a profilt, lépjen a speciális beállításokra, és írja be a DEFAULT:@SECLEVEL=0 értéket a TLS-titkosítás mezőbe. A NetworkManager kulcsfájlja ugyanezt az értéket veszi fel a [vpn] alatt:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Indítsa újra a NetworkManager szolgáltatást, és csatlakozzon újra, mert a démon gyorsítótárazza az elemzett profilokat, és különben továbbra is a nála lévő másolatot használná. Tudja, mit tesz a sor, mielőtt megtartaná: ez a beállítás több tanúsítvány- és kulcsparaméterre vonatkozó küszöb, nem titkosítási név, ezért csökkentése kiterjeszti, mit fogad el az egyes profil. Jegyezze fel, melyik kiszolgáló igényelte, és dobja el a beállítást, amikor az üzemeltető újra kiadja az aktuális anyagot. A /etc/ssl/openssl.cnf módosítása viszont ugyanazt a küszöböt éri el minden programnál, amely azt a fájlt olvassa, ami messze túlmutat a VPN-en.

Az OpenVPN 2.6 megköveteli a titkosítás listázását az egyeztetéshez

Az Ubuntu 22.10 hozta az OpenVPN 2.6-ot, és ebben a kiadásban a --cipher felhagy az adatcsatorna önálló kiválasztásával. A titkosításnak az egyeztetett data-ciphers listán is szerepelnie kell, különben az ügyfél elavulási figyelmeztetést nyomtat, majd nem tudja felhozni az alagutat.

Az ugyanabból az időszakból származó NetworkManager-bővítmény még mindig csak a régi direktívát írta. Ez a részlet megosztja a diagnózist, mert a kézzel javított profil csatlakozhat héjból, és mégis meghiúsulhat az asztali appletből. Adja hozzá a listát a kapcsolatfájlhoz a [vpn] alatt:

data-ciphers=AES-256-CBC

Azt az értéket használja, amelyet a kiszolgáló hirdet, ne azt, amelyre emlékszik; az AES-256-GCM-et kínáló kiszolgáló nem egyeztet olyan ügyféllistával, amely csak CBC-t nevez meg. Indítsa újra a kezelőt, és csatlakozzon újra, majd ismételje meg a kísérletet héjból, a titkosítást kifejezetten átadva az egyeztetéshez és a tartalékhoz is:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Ha ez a parancs felhozza az alagutat, a kiszolgáló, a tanúsítványok és a hitelesítő adatok mind rendben vannak, és az egyetlen fennmaradó hiba a kezelő tárolt beállítása. A keysize direktívára vonatkozó figyelmeztetés ugyanahhoz a tisztításhoz tartozik: kommentelje ki, és tartsa az eredeti fájlt a profil mellett.

A csomag- és bővítményhibák VPN-hibának látszanak

Nem minden frissítés utáni hiba kriptográfiai. Az olyan kódnév alatt hozzáadott OpenVPN-tároló, amelyet a kiadás nem használ, olyan csomagot ad, amely soha nem települ, ezért hasonlítsa össze, mit jelent a lsb_release -a, a hozzáadott listafájllal. A hiányzó universe összetevő vagy biztonsági zseb olyan csomagot ad, amely egyáltalán nem található meg. Mindkét eset érintetlenül hagyja a profilt, és lehetetlenné teszi az alagutat.

A csomagkezelő hibáját olvassa el a VPN-napló előtt. Ha az ügyfelet soha nem telepítették, a profil szerkesztésének semmilyen mennyisége nem ad kézfogást.

A kérdezést abbahagyó kétfaktoros profilok ugyanennek a történetnek a bővítményváltozata. A kihívás egy hitelesítési bővítménytől jön, és az azt elhagyó vagy lecserélő frissítés érintetlenül hagyja a profilt, miközben a kérés eltűnik. Telepítse újra a támogatott bővítményt ahelyett, hogy törölné a második tényezőt, hogy a kapcsolat működjön.

Egy szállítói könyvtár elrejtőzhet egy szabályzathiba mögé

Egy minta figyelmet érdemel, mert legyőzi az összes szabályzatjavítást. Egy hardvergyártói konfiguráló eszköz telepítheti a saját OpenSSL-könyvtárait, és a betöltő keresési útvonalán a rendszerpéldányok elé helyezheti azokat. Az ügyfél ekkor olyan könyvtárral szemben indul, amelyet senki nem frissített, és az indítási hiba pontosan elutasított tanúsítványnak látszik.

A VPN-csomag újratelepítése nem változtatja meg, melyik könyvtár található meg előbb, és a TLS-szint csökkentése nem ér el olyan könyvtárat, amely soha nem a rendszerből jött. Kérdezze meg a betöltőt, mely kriptoobjektumokat old fel a bináris valójában:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Távolítsa el vagy irányítsa át a szállítói példányt, majd futtassa újra ugyanazt az ellenőrzést. A várt verzió az kell legyen, amely használatban van, mielőtt visszatér a profilhoz.

Egy régebbi ügyfél kitűzése időt vásárol, nem megoldást

Az előző ügyfélverzió megtartása helyreállítja az alagutat, ameddig a megtartás tart. Befagyasztja a csomag biztonsági frissítéseit is, és ugyanezt a törést ütemezi a következő frissítésre, ezért datált átmeneti megoldásként kezelje, nem megoldásként.

Ha mégis kitűzi, tartsa a csomagot kifejezetten, hogy egy felügyelet nélküli frissítés ne vonhassa vissza a kitűzést, írja le az okot és a felülvizsgálat dátumát, és állítson emlékeztetőt a szolgáltató következő profilkiadására. A figyelmet érdemlő feltétel egy olyan kiszolgálóprofil, amely aktuális titkosítást egyeztet; amint ez létezik, a kitűzésnek nincs több indoka. A nem dokumentált kitűzés viszont olyan kieséssé válik, amelyet fél év múlva senki nem tud megmagyarázni, mert az alkalmazója továbbállt, és a fájl semmit nem rögzít.

Ha legközelebb egy VPN meghal egy kiadásfrissítés után, tegyen fel öt kérdést sorban: melyik réteg adta az első hibát, elutasította-e a TLS-szabályzat a tanúsítványt, egyeztethető-e a titkosítás mindkét irányban, valóban települt-e a csomag és a bővítménye, és melyik könyvtárat tölti be a folyamat. Csak ha mind az öt tisztán tér vissza, van értelme a visszaminősítésnek.