Forigi key-method el OpenVPN-profilo nenion ŝanĝas

Profilo, kiu funkciis dum jaroj, subite rifuzas ekstarti, kaj la mesaĝo nomas direktivon, kiun neniu memoras esti aldoninta: key-method. La sekva serĉrezulto proponas aldoni key-method 2 por kongrueco, sed tio estas konsilo el alia epoko. La analizilo, kiu rifuzis la linion, estas nuna, kaj ĝi tute ne havas tiun opcion. Forigi la linion riparas la ekstarton, kaj ĝi ŝanĝas nenion pri tio, kiel la du partneroj protektas la seancon.

Ĝuste tiu breĉo inter tio, kion enhavas profilo, kaj tio, kion la protokolo efektive faras, estas la tuta temo ĉi tie, kaj ĝi klarigas plurajn aliajn redaktojn, kiujn homoj faras samtempe. Ĝi ankaŭ klarigas, kial tiuj redaktoj kutime alvenas en pako.

La simptomo estas analiza eraro, ne malsukceso de manpremo

Opcion oni legas antaŭ ol sendi ajnan paketon. Profilo kun nekonata direktivo malsukcesas en tiu stadio, do la procezo neniam atingas la reton kaj neniam produktas manpreman eraron. La vortigo kutime identigas la opcion kaj la dosieron, kio faras ĉi tion unu el la plej facile atribueblaj malsukcesoj. Neniu paketo, neniu itinero kaj neniu fajroŝirmilo partoprenas en ĝi.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Se la mesaĝo nomas la direktivon, la diagnozo estas finita: la dosiero enhavas ion, kion ĉi tiu konstruo ne akceptas. Se la mesaĝo anstataŭe nomas dosiervojon, la problemo estas mankanta inkludo aŭ ŝlosilo, kio estas alia sekcio de la sama ekstarta stadio.

Kion vi ne devus konkludi, estas ke la kliento aŭ servilo bezonas pli malnovan protokolan reĝimon. Analiza malsukceso estas vortproviza problemo inter via dosiero kaj la binara dosiero, kaj la binara dosiero en ĉi tiu kazo simple faligis vorton el sia vortprovizo.

Direktivo kaj transmisformato estas du malsamaj aferoj

La malnova opcio key-method elektis, kiel la TLS-ŝlosilinterŝanĝo estas kadrigita, kaj la moderna interŝanĝo estas la plurbaketa metodo, kiun tiu opcio iam petis. La opcio malaperis, ĉar ĝi jam elektis nenion; la formato, kiun ĝi nomis, fariĝis la sola. Forigi la linion do lasas la seancon kun la sama kadrigo kiel antaŭe. Teksta redakto ne povas ŝanĝi tion en iu ajn direkto.

Tial reenkonduki malnovan binaran dosieron por «restarigi» metodon 2 estas la malbona riparo. Ĝi restarigas nenion krom pli malnova analizilo kun pli malnovaj defaŭltoj, kaj ĝi kostas al vi la korektojn, kiuj venis post ĝi. La sama rezonado validas por malfortigi atestilan kontrolon aŭ ĉifrarliston esperante, ke la konekto revenos.

Utila kontrolo estas la versio kaj la analizita agordo, ne la ĉeesto de la vorto en la dosiero:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Kion forigi, kaj el kiu dosiero

Redaktu la dosieron, kiun la kuranta procezo efektive legas, kaj nur tiun dosieron. Sur pakitaj sistemoj tio kutime estas la profilo en la klienta aŭ servila dosierujo nomita de la unuo, ne kopio en via hejma dosierujo, kiun vi tenas por referenco. Generita profilo ankaŭ povas esti rekonstruita el ŝablono, do ŝanĝo farita nur en la disdonita kopio revenos post la sekva provizrulado.

Forigu la malnoviĝintan linion kaj lasu la finpunkton, atestilojn, ĉifran politikon kaj agordojn de la regkanalo trankvile. Tiuj estas subtenataj opcioj, kiujn la procezo bezonas, kaj ili ne estas implikitaj en la analiza eraro. Se la sama profilo enhavas aliajn direktivojn, kiujn vi ne rekonas, kontrolu ĉiun kontraŭ la versio, kiun vi rulas, anstataŭ forigi grupon da ili ĝis la procezo ekstartos.

Poste ekstartigu la celitan instancon kaj legu ĝian ekstartan eligon. Pura ekstarto kun ĉeestanta aŭskultanto estas la konfirmo, ke ĉi tiu stadio finiĝis; klienta testo poste respondas al alia demando.

Rifuzita profilo kaj rifuzita kliento aspektas simile

Du malsukcesoj produktas similajn subtenajn fadenojn kaj bezonas malsamajn pruvojn. Servilo, kiu rifuzas sian propran agordon, neniam ekstartas, do neniu kliento povas konektiĝi al ĝi. Servilo, kiu bone ekstartas kaj rifuzas unu klienton, funkcias, kaj ĝia protokolo enhavas la kialon: atestila problemo, puŝita opcio, kiun la kliento ne akceptas, ĉifra malkongruo.

La forigita opcio ne estas diagnozo por la dua kazo, kaj kapti ĝin malŝparas la saman horon dufoje. Se la klienta protokolo montras la rifuzon de la servilo, legu tiun rifuzon; se ĝi montras lokan eraron, la klienta profilo estas la dosiero kontrolenda. Kapti direktivon, kiu ne plu ekzistas, prokrastas ambaŭ esplorojn same multe.

Kongruecaj demandoj, kiujn la linio neniam respondis

Profiloj, kiuj cirkulas kun ĉi tiu direktivo, kutime portas rakonton pri specifa platformo, kaj la rakonto postvivas la teknikan kialon. Movebla aŭ labortabla kliento ankoraŭ bezonas kompletan subtenatan profilon: fidindan atestilan ĉenon, datuman ĉifron, kiun ambaŭ flankoj akceptas, regkanalan reĝimon, kiun ambaŭ flankoj realigas, kaj neniujn direktivojn, kiujn la konstruo de la kliento rifuzas. Nenion el tio decidas la ĉeesto aŭ foresto de la malnova key-method-linio.

Kunpremado estas aparta politika demando de la sama formo. Forigi key-method-linion diras nenion pri tio, ĉu kunprema direktivo estas subtenata aŭ akceptebla en via disdonado, kaj la du decidoj devus esti faritaj sendepende. Forigi plurajn sekurec-rilatajn agordojn samtempe ĝis io konektiĝos estas la maniero, per kiu funkcianta profilo fariĝas neklarigita.

Tenu mallongan registron pri tio, kion vi forigis kaj kial: la opcion, la version, kiu ĝin rifuzis, kaj la komandon, kiu montris la eraron. La venonta persono, kiu heredos la profilon, bezonos ĝuste tiujn tri faktojn, kaj pli malmultekostas skribi ilin nun ol rekonstrui ilin poste.