Senas .ovpn profilis neveikia Ubuntu 24.04: kurias eilutes ištrinti

Profilis atsisiunčiamas, importuojamas ir tada sustoja 12-oje failo eilutėje su Unrecognized option pranešimu, kuriame nurodoma keysize. Paskyroje niekas nepasikeitė, o serveris vis dar priima kitus klientus. Pasikeitė pats klientas: Ubuntu 24.04 įdiegia OpenVPN 2.6, o eksportas buvo parašytas 2.4 versijai. Taisymas – trumpa trynimų seka, ir tvarka svarbi, nes kiekviena pasenusi parinktis nutraukia analizę dar prieš perskaitant kitą.

Perskaitykite klaidos eilutę prieš liesdami failą

OpenVPN nurodo failą ir eilutę, kurioje analizė sustojo, todėl per vieną paleidimą galite pataisyti tik vieną problemą. Paleiskite profilį iš terminalo, o ne iš darbalaukio programėlės, nes programėlė dažniausiai praryja stderr, o eilutės numeris yra vienintelė patikima užuomina, kurią gaunate: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Pataisykite tą eilutę, paleiskite dar kartą ir tikėkitės, kad kita klaida įvardys kitą parinktį.

Analizės klaida visada atsiranda prieš bet kokį TLS rankos paspaudimą, todėl pranešimas, kuriame minimas sertifikatas, jau praėjo sintaksės etapą. Šis skirtumas neleidžia jums redaguoti failo, kuris nepavyksta tik autentifikavimo metu. Skaitykite pirmąjį pranešimo žodį, o ne jo vidurį.

Trys gedimų klasės, trys skirtingi taisymai

Seni eksportai nepavyksta trimis atskiriamais būdais, ir būtent jų suplakimas į vieną problemą verčia žmones iš naujo diegti paketus, kurie niekada nebuvo sugedę. Pranešimo formuluotė pasako, kokioje klasėje esate, dar prieš atidarant failą.

• Analizės klaidos nurodo failą ir eilutę ir sustoja dar prieš atsirandant bet kokiam srautui.
• Derybų klaidos prisijungia ir tada praneša, kad du galai nesusitarė dėl bendro šifravimo ar priimtino duomenų kanalo.
• Autentifikavimo klaidos nueina toliausiai ir nurodo sertifikatą, vartotoją arba atmestus prisijungimo duomenis.

Profilio redagavimas pataiso tik pirmąją klasę. Deryboms reikia sprendimo abiejuose tunelio galuose, o atmesti prisijungimo duomenys visai nėra sintaksės problema. Jei jūsų pranešime minimas bendras šifravimas ar duomenų kanalas, žemiau esantys trynimai nieko nepakeis.

Ištrinkite parinktis, kurias 2.6 pašalino, šia tvarka

Kiekviena iš šių eilučių savarankiškai sustabdo analizę, todėl klientas jas praneša po vieną. Eikite sąrašu žemyn ir po kiekvieno trynimo paleiskite iš naujo.

Pirmiausia ištrinkite keysize, nes jis neturi modernaus atitikmens, o jo buvimas dažniausiai žymi šifravimą, kurį dabartinis klientas vis tiek atmeta. Tada ištrinkite ncp-disable, kuris valdė šifravimo derybas, tapo pasenęs 2.5 versijoje ir jo nebėra 2.6 versijoje. Pakeiskite ns-cert-type server į remote-cert-tls server, kuris išreiškia tą patį ketinimą per palaikomą patikrinimą. 2.6 pakeitimų istorija išvardija likusius pašalinimus šalia jų pakaitalų, todėl viskas, ką analizatorius vis dar atmeta, turi dokumentuotą atsakymą.

Prieš pirmąjį redagavimą pasidarykite originalaus profilio kopiją. Tiekėjai iš naujo generuoja eksportus, o diff su nepaliestu failu yra greičiausias būdas atskirti savo pakeitimus nuo jų. Jei trynimas leidžia klientui paleisti, bet tunelis vis tiek nepavyksta, jūs perėjote į derybų klasę ir likusios eilutės nėra priežastis. Įrašykite kliento versiją į failo pavadinimą, kad kitas žmogus žinotų, kuriai versijai skirti pakeitimai.

Išlaikykite BF-CBC veikiantį tik kaip ribotą atsarginį variantą

Kai kurie tiekėjai vis dar baigia BF-CBC, su kuriuo OpenVPN 2.6 be pagalbos nesiderės, nes šifravimo blokas yra 64 bitų. Siauras taisymas yra atsarginių sąrašas ir senas OpenSSL tiekėjas, o ne viso kliento versijos sumažinimas.

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

Pirmoji eilutė įkelia seną tiekėją, kad OpenSSL vis dar galėtų sukurti tą šifravimą, antroji išlaiko modernias derybas tiems partneriams, kurie jas palaiko, o trečioji taikoma tik tada, kai serveris nesiūlo nieko geresnio. Tai sąmoningas tunelio silpninimas, todėl šalia failo užsirašykite, kodėl jis egzistuoja. Tuo pačiu metu paprašykite tiekėjo iš naujo sugeneruoto eksporto, nes atsarginis variantas yra tiltas, o ne tikslas.

Nesinaudokite --compat-mode kaip universaliu atsakymu. Jis vienu metu keičia kelis veikimus, įskaitant numatytąsias derybų ir pakartotinių derybų reikšmes, todėl niekada nesužinosite, kuris pakeitimas buvo svarbus. Verčiau rinkitės tris aiškias eilutes aukščiau, nes kiekviena jų nurodo savo poveikį.

Patikrinkite su profiliu, kurį klientas iš tikrųjų įkelia

Importuoti ryšiai dažnai nukopijuojami į sistemos katalogą, todėl atsisiuntimų aplanke esančio failo redagavimas gali nieko nepakeisti. Raskite kopiją, kuri vykdoma: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Tada paleiskite tunelį ir perskaitykite žurnalo eilutę, kuri praneša, koks duomenų kanalo šifravimas iš tikrųjų pasirinktas. Ryšys, kuris užbaigia rankos paspaudimą su atsarginiu variantu, pasako, kad serveris niekada nesiūlė nieko modernaus.

Bandykite iš tinklo, kuris nėra tas, kurio tikisi tiekėjas, kad užkardytas portalas ar filtruojamas svečių tinklas neapsimestų profilio gedimu. Užsirašykite kliento versiją prie kiekvienos pagalbos užklausos.

Kai tunelis pakeltas, nusiųskite vieną užklausą, kuri turi jį pereiti, ir vieną, kuri neturi, o tada patvirtinkite, kad sprendėjo atsakymas pasikeitė taip, kaip tikėjotės. Jei profilis dabar analizuojamas, bet ryšys vis dar nepavyksta, sintaksės problemą palikote už nugaros ir klaidos tekstas įvardys naują klasę. Laikykite redaguotą failą versijų kontrolėje kartu su pastaba, nurodančia tikslinę OpenVPN versiją.