A régi .ovpn profil nem működik Ubuntu 24.04-en: mely sorokat törölje

A profil letöltődik, importálódik, majd megáll a fájl 12-es soránál egy Unrecognized option üzenettel, amely a keysize nevet említi. A fiókon semmi sem változott, és a szerver továbbra is fogad más klienseket. Ami változott, az maga a kliens: az Ubuntu 24.04 az OpenVPN 2.6-ot telepíti, míg az export a 2.4-hez készült. A javítás rövid törléssorozat, és a sorrend számít, mert minden elavult opció megszakítja az elemzést, mielőtt a következőt egyáltalán beolvasnák.

Előbb olvassa el a hiba sorát, csak aztán nyúljon a fájlhoz

Az OpenVPN megnevezi a fájlt és a sort, ahol az elemzés megállt, így futásonként csak egy problémát tud kijavítani. Terminálból indítsa a profilt, ne asztali kisalkalmazásból, mert a kisalkalmazás általában elnyeli az stderr-t, és a sorszám az egyetlen megbízható támpont, amit kap: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Javítsa ki azt a sort, futtassa újra, és számítson rá, hogy a következő hiba más opciót nevez meg.

Az elemzési hiba mindig minden TLS-kézfogás előtt jelenik meg, tehát a tanúsítványt említő üzenet már túljutott a szintaktikai szakaszon. Ez a különbség tartja vissza attól, hogy olyan fájlt szerkesszen, amely csak a hitelesítésnél hibázik. Az üzenet első szavát olvassa, ne a közepét.

Három hibaosztály, három különböző javítás

A régi exportok három megkülönböztethető módon hibáznak, és éppen az, hogy egyetlen problémába vonják őket, készteti az embereket olyan csomagok újratelepítésére, amelyek soha nem voltak hibásak. Az üzenet megfogalmazása megmondja, melyik osztályban van, mielőtt kinyitná a fájlt.

• Az elemzési hibák fájlt és sort neveznek meg, és még azelőtt megállnak, hogy bármilyen forgalom létrejönne.
• A tárgyalási hibák csatlakoznak, majd jelentik, hogy a két végpont nem tudott megegyezni közös titkosításban vagy elfogadható adatcsatornában.
• A hitelesítési hibák jutnak a legmesszebbre, és tanúsítványt, felhasználót vagy elutasított hitelesítő adatot neveznek meg.

A profil szerkesztése csak az első osztályt javítja. A tárgyaláshoz döntés kell az alagút mindkét végén, az elutasított hitelesítő adat pedig egyáltalán nem szintaktikai probléma. Ha az üzenete közös titkosítást vagy adatcsatornát említ, az alábbi törlések semmit sem változtatnak.

Törölje a 2.6 által eltávolított opciókat, ebben a sorrendben

Ezek a sorok külön-külön megállítják az elemzést, ezért a kliens egyenként jelenti őket. Haladjon végig a listán, és minden törlés után futtassa újra.

Először törölje a keysize sort, mert nincs modern megfelelője, és jelenléte általában olyan titkosítást jelez, amelyet a jelenlegi kliens amúgy is elutasít. Aztán törölje a ncp-disable sort, amely a titkosítási tárgyalást vezérelte, a 2.5-ben elavult, a 2.6-ban pedig már nincs. Cserélje a ns-cert-type server sort a remote-cert-tls server sorra, amely ugyanazt a szándékot fejezi ki támogatott ellenőrzéssel. A 2.6 változástörténete a fennmaradó eltávolításokat a helyettesítéseik mellett sorolja fel, így mindennek, amit az elemző még elutasít, dokumentált válasza van.

Az első szerkesztés előtt őrizzen másolatot az eredeti profilról. A szolgáltatók újragenerálják az exportokat, és a sértetlen fájlhoz készített diff a leggyorsabb módja annak, hogy elválassza a saját változtatásait az övéiktől. Ha egy törlés elindítja a klienst, de az alagút még mindig meghiúsul, átkerült a tárgyalási osztályba, és a fennmaradó sorok nem az okok. Tegye a kliens verzióját a fájlnévbe, hogy a következő ember tudja, melyik kiadásra irányulnak a szerkesztések.

Csak szűk tartalékként tartsa működésben a BF-CBC-t

Egyes szolgáltatók még mindig BF-CBC-n fejezik be, amiben az OpenVPN 2.6 segítség nélkül nem tárgyal, mert a titkosításnak 64 bites blokkja van. A szűk javítás egy tartaléklista és a régi OpenSSL-szolgáltató, nem a teljes kliens visszaminősítése.

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

Az első sor betölti a régi szolgáltatót, hogy az OpenSSL még létre tudja hozni azt a titkosítást, a második megtartja a modern tárgyalást az azt támogató partnereknek, a harmadik pedig csak akkor érvényes, ha a szerver nem kínál jobbat. Ez az alagút szándékos gyengítése, ezért jegyezze fel a fájl mellé, miért létezik. Kérjen a szolgáltatótól egyidejűleg újragenerált exportot, mert a tartalék híd, nem cél.

Ne nyúljon a --compat-mode kapcsolóhoz általános válaszként. Egyszerre több viselkedést változtat meg, köztük a tárgyalás és az újratárgyalás alapértékeit, így soha nem tudja meg, melyik változtatás számított. Inkább a fenti három kifejezett sort válassza, mert mindegyik a saját hatását mondja ki.

Azzal a profillal ellenőrizze, amelyet a kliens valóban betölt

Az importált kapcsolatokat gyakran rendszerkönyvtárba másolják, ezért a letöltési mappában lévő fájl szerkesztése semmit sem változtathat. Keresse meg a futó példányt: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Aztán indítsa el az alagutat, és olvassa el a napló azon sorát, amely jelenti, melyik adatcsatorna-titkosítást választották valóban. Az a kapcsolat, amely a tartalékon fejezi be a kézfogást, azt mondja, hogy a szerver soha nem kínált semmi modernt.

Olyan hálózatról teszteljen, amely nem az, amelyet a szolgáltató elvár, hogy egy captive portal vagy egy szűrt vendéghálózat ne tűnjön profilhibának. Minden támogatási kérelem mellé jegyezze fel a kliens verzióját.

Amikor az alagút áll, küldjön egy kérést, amelynek át kell haladnia rajta, és egyet, amelynek nem, majd erősítse meg, hogy a feloldó válasza az elvárásai szerint változott. Ha a profil most már elemezhető, de a kapcsolat továbbra is meghiúsul, maga mögött hagyta a szintaktikai problémát, és a hibaüzenet az új osztályt fogja megnevezni. Tartsa a szerkesztett fájlt verziókezelésben, mellette egy feljegyzéssel, amely megnevezi a célzott OpenVPN-kiadást.