Kial aldoni opt-verify ne riparos vian OpenVPN-ĉifran eraron

Vi trovas sugeston aldoni opt-verify, aldonas la linion, kaj la ĉifra eraro restas ĝuste tie, kie ĝi estis. Tiu rezulto estas antaŭvidebla, ĉar la opcio neniam negocis ĉifron. Ĝi estis kontrolo de opcia konsisto, malrekomendita en 2.6 kaj forigita en 2.7, kaj profilo, kiu kun ĝi ankoraŭ analiziĝas, per tio ne trudis ion ajn.

Utile estas scii, kion la linio antaŭe faris, antaŭ ol konkludi, ke ĝi estas la mankanta peco. La historio ankaŭ klarigas, kial ĝi nun ne povas helpi.

Kion la opcio antaŭe trudis

La manlibro por 2.6 markas opt-verify kiel malrekomendita kaj priskribas la antaŭan konduton: la servilo forĵetas klientojn, kies deklaritaj opcioj ne kongruas kun ĝiaj propraj, komparante aferojn kiel aparattipo kaj MTU. Tiu kontrolo ankaŭ dependas de tio, ke la kontrolo de opcia konsisto restu ŝaltita, do servilo funkcianta kun disable-occ neniam havis ĝin. Rimarku, el kio la komparo estas konstruita: teksto priskribanta la agordon de la kontraŭulo. Ĝi diras nenion pri tio, kiun ĉifron la datena kanalo uzos.

Tio estas la unua kialo, kial la flago ne povas ripari ĉifran eraron. Ĉifra elekto estas regata de la politiko data-ciphers kaj de tio, kion ambaŭ flankoj subtenas, kaj teksta konsisto-kontrolo nek etendas tiun liston nek plenumas la negocadon. Dua kialo estas la amplekso: la kontrolo temas pri tio, ĉu la deklaritaj opcioj aspektas kongruaj, ne pri la kvalito de la rezulta vojo.

Kion 2.7 faras, kiam ĝi vidas la linion

En 2.7 la opcio ne plu ekzistas. La analizilo ankoraŭ rekonas la nomon, pro kio malnova profilo ŝargiĝas sen sintaksa eraro, kaj ĝi raportas, ke la opcio estis forigita, anstataŭ silente preterpasi ĝin. Rekoni nomon kaj trudi konduton estas malsamaj aferoj, kaj nur la unua ankoraŭ okazas. La forigaj notoj donas la kialon: post kiam parametroj povas esti negocataj, du flankoj rajtas laŭleĝe havi malsamajn opciajn signoĉenojn dum ili konsentas pri la konekto.

Profilo, kiu analiziĝas, do ne estas pruvo, ke iu ajn akcepta kontrolo okazis. Se via sola signalo estas, ke la kliento konektiĝis, vi lernis, ke la sintakso estis akceptita.

Kie la malsukceso fakte loĝas

Konservu la unuan konkretan eraron antaŭ ol ŝanĝi ion, ĉar postaj mesaĝoj kutime estas ĝiaj sekvoj. Malsukceso de negocado de la datena kanalo apartenas al la aprobita ĉifra politiko kaj al la kapabloj, kiujn ambaŭ flankoj efektive anoncas. Malsukceso de TLS-versio aŭ -aro apartenas al la rega kanalo. Atestila rifuzo bezonas la identecon kaj la fidoĉenon, ne kongruecan flagon.

Identigu ankaŭ la maŝinon ĉe ambaŭ finoj. Labortabla aplikaĵo povas enhavi alian konstruon ol la komandlinia binara dosiero, per kiu vi testis, kaj opcia subteno diferencas inter ili. Kontrolu la dokumentaron de tiu maŝino anstataŭ supozi, ke ĉiu programo importanta profilon kondutas same.

Anstataŭigu la intencon, ne nur la linion

Se pli malnova administrata servilo vere dependis de la konsisto-kontrolo, notu, kiun limigon ĝi trudis antaŭ la ĝisdatigo. Konservi ignoratan opcion en pli nova profilo ne povas konservi tiun politikon, kaj senorda forigado de linioj ankaŭ ne.

Ne respondu al malnova sugesto, ke ĉiuj ĉifroj estas malŝaltitaj, per ŝaltado de ĉiu historia algoritmo.

Post aprobita korekto, inspektu la negocitajn rezultojn sur freŝa konekto kaj testu la aplikaĵon, kiun la uzanto efektive bezonas. Tenu la servilan version kaj la efektivan politikon apud tiu rezulto, por ke la sekva persono vidu, kio estis interkonsentita, ne nur kio estis akceptita.

La celo estas subtenata limigo kaj funkcianta aŭtentikigita vojo, ne malnova flago, kiu ankoraŭ analiziĝas.