Ĝusta VPN-pasvorto ne anstataŭigas mankantan atestilon

La akreditaĵoj ĝustas, la profilo importantas pure, kaj la konekto ankoraŭ malsukcesas antaŭ ol la aŭtentikigo finiĝas. En Windows la mesaĝo povas esti eraro 798, pri atestilo kiu ne troveblis por la EAP-metodo. Ĉe OpenVPN la klienta protokolo montras TLS-manpremadon kiu neniam kontentigas la servilon. Ambaŭ priskribas la saman mankantan objekton: klientan atestilon, kiun la kliento devis prezenti.

Pasvorto pruvas scion de sekreto; atestilo pruvas posedon de ŝlosilo, kaj unu ne anstataŭigas la alian.

La pasvorto neniam estis la problemo

Eraro 798 estas malsukcesa atestila serĉo. La kliento estis petita pri atestilo kongrua kun la agordita aŭtentikiga metodo, traserĉis sian stokon kaj trovis nenion uzeblan. Tio povas signifi, ke la atestilo mankas, ekzistas sen sia privata ŝlosilo, eksvalidiĝis aŭ estas konservita tie, kien la serĉo ne atingas. Ripeti la pasvorton ne povas ŝanĝi iun el tiuj kondiĉoj, tial la eraro revenas ankaŭ kun ĝustaj akreditaĵoj.

Legu la mesaĝon antaŭ ol agi laŭ ĝi. Rifuzo de akreditaĵoj, malsukcesa atestila serĉo kaj malsukcesa TLS-manpremado estas tri malsamaj trovoj, kaj nur unu el ili koncernas la pasvorton.

Kion la klienta stoko devas enhavi

Du objektoj partoprenas. La klienta atestilo devas esti instalita por la uzanto, kiu rulas la VPN-klienton, kune kun sia privata ŝlosilo, kaj la eldonanta radiko devas esti fidata. Dosiero .cer enhavas nur la publikan atestilon, do ĝi sola povas aŭtentikigi nenion. En la Windows-atestila administrilo, la klienta identeco apartenas al la persona stoko de la nuna uzanto, kaj la radiko al la stoko de fidindaj radikoj.

Instali la identecon en la maŝinan stokon, aŭ nur en la radikan stokon, ne plenumas serĉon celatan al la persona stoko de la uzanto. Kontrolu la stokon, la flagon de privata ŝlosilo kaj la validigajn datojn kune, poste restartigu la klienton por ke ĝi relengu la stokon.

Du produktoj, la sama mankanta akreditaĵo

OpenVPN-serviloj postulas klientan atestilon defaŭlte. Aldoni auth-user-pass al kliento sendas uzantnomon kaj pasvorton, kaj la TLS-manpremado ankoraŭ petas atestilon, do pasvorto sola ne povas fini la konekton sub verify-client-cert require. La servilo povas esti agordita por postuli neniun, kio faras la pasvorton la sola klienta akreditaĵo kaj estas reala malfortigo. Shell-skripto malantaŭ auth-user-pass-verify povas validigi akreditaĵojn, kaj ĝi postulas ŝaltitan skriptan plenumadon, kio igas ĝin pli riska dezajno ol taŭga aŭtentikiga dorsprogramo.

Profilo bazita nur sur pasvorto ankaŭ dependas de puŝitaj opcioj, kiuj siavice dependas de tio, ke la tirada mekanismo estas ŝaltita.

Ne riparu mankantan atestilon per malŝalto de kontroloj

La tento estas malstreĉi la kontroladon por ke la mesaĝo malaperu. Tio forigas la regadon, kiu faris sian laboron, kaj lasas konekton, kiu jam ne pruvas tion, kion ĝi asertas. Se la enirejo lastatempe ŝanĝis sian radikon, re-elŝutu la klientan pakaĵon anstataŭ redakti la profilon, ĉar la malnova pakaĵo eble ankoraŭ portas la antaŭan radikon. Se la opcio pri atestila aŭtentikigo mankas en la profila redaktilo, la instalita Windows-versio eble ne elmetas tiun metodon; ĝisdatigu la sistemon anstataŭ permane redakti XML.

Notu, kiu stoko tenis la atestilon, kiu uzanto rulis la klienton kaj ĉu la privata ŝlosilo ĉeestis. Tiuj tri klarigas preskaŭ ĉiun okazon de ĉi tiu malsukceso.

La pasvorto estis en ordo. La akreditaĵo, kiun la metodo efektive bezonis, estis aliloke.