Malnova .ovpn-profilo malsukcesas sur Ubuntu 24.04: kiujn liniojn forigi

La profilo elŝutiĝas, importiĝas kaj tiam haltas ĉe linio 12 de la dosiero kun mesaĝo Unrecognized option kiu nomas keysize. Nenio pri la konto ŝanĝiĝis, kaj la servilo ankoraŭ akceptas aliajn klientojn. Tio, kio ŝanĝiĝis, estas la kliento mem: Ubuntu 24.04 instalas OpenVPN 2.6, dum la eksporto estis skribita por 2.4. La riparo estas mallonga serio de forigoj, kaj la ordo gravas ĉar ĉiu malnova opcio ĉesigas la analizon antaŭ ol la sekva eĉ legiĝos.

Legu la erarlinion antaŭ ol tuŝi la dosieron

OpenVPN nomas la dosieron kaj la linion kie la analizo haltis, do vi povas ripari nur unu problemon po rulo. Startigu la profilon el terminalo anstataŭ el surtabla aplikaĵeto, ĉar la aplikaĵeto kutime glutas stderr kaj la lininombro estas la sola fidinda indiko kiun vi ricevas: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Riparu tiun linion, rulu denove, kaj atendu ke la sekva malsukceso nomos alian opcion.

Analiza eraro ĉiam aperas antaŭ iu ajn TLS-manpremo, do mesaĝo kiu mencias atestilon jam pasis la sintaksan stadion. Tiu distingo malebligas al vi redakti dosieron kiu malsukcesas nur ĉe aŭtentikigo. Legu la unuan vorton de la mesaĝo, ne ĝian mezon.

Tri klasoj de malsukceso, tri malsamaj riparoj

Malnovaj eksportoj malsukcesas laŭ tri distingeblaj manieroj, kaj ĝuste kunfandi ilin en unu problemon igas homojn reinstali pakaĵojn kiuj neniam estis rompitaj. La vortigo de la mesaĝo diras al vi en kiu klaso vi estas antaŭ ol vi malfermas la dosieron.

• Analizaj eraroj nomas dosieron kaj linion kaj haltas antaŭ ol ekzistas ajna trafiko.
• Intertraktaj eraroj konektiĝas, poste raportas ke la du finoj ne povis interkonsenti pri komuna ĉifro aŭ akceptebla datumkanalo.
• Aŭtentikigaj eraroj iras plej malproksimen kaj nomas atestilon, uzanton aŭ malakceptitan akreditaĵon.

Redakto de la profilo riparas nur la unuan klason. Intertraktado bezonas decidon ĉe ambaŭ finoj de la tunelo, kaj malakceptita akreditaĵo tute ne estas sintaksa problemo. Se via mesaĝo mencias komunan ĉifron aŭ datumkanalon, la forigoj sube ŝanĝos nenion.

Forigu la opciojn kiujn 2.6 forigis, en ĉi tiu ordo

Ĉiu el ĉi tiuj linioj haltigas la analizon per si mem, do la kliento raportas ilin unu post la alia. Laboru malsupren laŭ la listo kaj rulu denove post ĉiu forigo.

Forigu keysize unue, ĉar ĝi havas neniun modernan ekvivalenton kaj ĝia ĉeesto kutime markas ĉifron kiun la nuna kliento rifuzas ĉiuokaze. Poste forigu ncp-disable, kiu regis la ĉifran intertraktadon, malrekomendiĝis en 2.5 kaj mankas en 2.6. Anstataŭigu ns-cert-type server per remote-cert-tls server, kiu esprimas la saman intencon per subtenata kontrolo. La 2.6-ŝanĝhistorio listigas la ceterajn forigojn apud iliaj anstataŭaĵoj, do ĉio kion la analizilo ankoraŭ rifuzas havas dokumentitan respondon.

Konservu kopion de la origina profilo antaŭ la unua redakto. Provizantoj regeneras eksportojn, kaj diff kontraŭ la netuŝita dosiero estas la plej rapida maniero apartigi viajn ŝanĝojn de iliaj. Se forigo lasas la klienton starti sed la tunelo ankoraŭ malsukcesas, vi transiris al la intertraktada klaso kaj la ceteraj linioj ne estas la kaŭzo. Metu la klientversion en la dosiernomon por ke la sekva persono sciu kiun eldonon la redaktoj celas.

Tenu BF-CBC funkcianta nur kiel limigita rezervo

Kelkaj provizantoj ankoraŭ finas la konekton per BF-CBC, kun kiu OpenVPN 2.6 ne intertraktos sen helpo, ĉar la ĉifro havas 64-bitan blokon. La mallarĝa riparo estas rezervolisto plus la malnova OpenSSL-provizanto, ne malaltigo de la tuta kliento.

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

La unua linio ŝargas la malnovan provizanton por ke OpenSSL ankoraŭ povu krei tiun ĉifron, la dua konservas modernan intertraktadon por kunuloj kiuj subtenas ĝin, kaj la tria aplikiĝas nur kiam la servilo proponas nenion pli bonan. Tio estas intenca malfortigo de la tunelo, do notu kial ĝi ekzistas apud la dosiero. Petu samtempe de la provizanto regeneritan eksporton, ĉar la rezervo estas ponto, ne celo.

Ne prenu --compat-mode kiel universalan respondon. Ĝi ŝanĝas plurajn kondutojn samtempe, inter ili la defaŭltojn de intertraktado kaj reintertraktado, do vi neniam lernos kiu ŝanĝo gravis. Preferu la tri eksplicitajn liniojn supre, ĉar ĉiu el ili deklaras sian propran efikon.

Kontrolu per la profilo kiun la kliento efektive ŝargas

Importitaj konektoj ofte kopiiĝas en sisteman dosierujon, do redakto de la dosiero en via elŝuta dosierujo povas ŝanĝi absolute nenion. Trovu la kopion kiu ruliĝas: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Poste startigu la tunelon kaj legu la protokollinion kiu raportas kiun ĉifron de la datumkanalo oni efektive elektis. Konekto kiu finas la manpremon per la rezervo diras al vi ke la servilo neniam proponis ion modernan.

Testu el reto kiu ne estas tiu kiun la provizanto atendas, por ke kaĝa portalo aŭ filtrita gastreto ne ŝajnigu profileraron. Notu la klientversion apud ĉiu subtenpeto.

Post kiam la tunelo staras, sendu unu peton kiu devas trapasi ĝin kaj unu kiu ne devas, poste konfirmu ke la respondo de la solvilo ŝanĝiĝis kiel vi atendas. Se la profilo nun analiziĝas sed la konekto ankoraŭ malsukcesas, vi lasis la sintaksan problemon malantaŭe kaj la erarteksto nomos la novan klason. Tenu la redaktitan dosieron en versikontrolo apud noto kiu nomas la OpenVPN-eldonon kiun ĝi celas.