Kial OpenVPN daŭre petas privatan ŝlosilan dosieron kiam estas ĵetono

Vi enmetas la ĵetonon, la propra ilo de la provizanto vidas ĝin, kaj la VPN-kliento daŭre petas privatan ŝlosilan dosieron. Tiu peto ne pruvas, ke la ĵetono ne estas subtenata. Ĝi kutime signifas, ke la profilo neniam diris al la kliento uzi la ĵetonon, do ĝi refalis al la atestilaj kaj ŝlosilaj enigoj, kiujn ĝi atendus defaŭlte.

Du apartaj valoroj devas esti ĝustaj antaŭ ol tiu refalo ĉesos: la provizanto, kiu elmontras la ĵetonon, kaj la identeco de la atestilo interne. Ili estas provizataj per malsamaj opcioj kaj facile konfuzeblaj.

La kliento petas dosieron ĉar la profilo tion diras

Defaŭlta profilo atendas atestilan dosieron kaj privatan ŝlosilan dosieron, aŭ unu PKCS#12-pakaĵon. Kiam tiuj enigoj mankas, la kliento havas nenion por ŝargi kaj kondutas preskaŭ kiel ĉe mankanta dosiero, kaj tial la simptomo legeblas kiel rompita vojo anstataŭ mankanta mekanismo. La vojo PKCS#11 anstataŭigas tiujn enigojn anstataŭ ilin kompletigi, do profilo, kiu ankoraŭ nomas ŝlosilan dosieron, daŭre uzos la dosieron. Forigu la dosierajn enigojn intence kaj lasu la ĵetonon provizi ambaŭ duonojn.

La provizanta opcio nomas mezaĵan bibliotekon, ne aparaton kaj ne atestilon. Ĉu pakaĵigita kliento povas ŝargi tiun bibliotekon dependas de tio, kiel ĝi estis konstruita, inkluzive de la laŭvola subteno pri p11-kit, kiun iuj konstruoj ebligas kaj aliaj preterlasas. Ĝenerala lernilo ne povas diri al vi, kiun aranĝon havas via pakaĵo.

La seria identeco estas alia valoro

La atestila identeco estas longa seria ĉeno produktita de la eltrovprocezo, kaj ĝi ne estas la biblioteka vojo, la PIN de la ĵetono aŭ la nomo de la VPN-konto. Ĝi ofte enhavas signojn, kiujn oni devas citi, kaj valoro sen citiloj povas esti tranĉita aŭ mislegita sen klara eraro. Uzu la propran opcion eltrovo de identeco de la kliento por listigi, kion la ĵetono elmontras, poste kopiu la celatan eron ekzakte. Elekti la unuan objekton en la listo estas la maniero, per kiu aparato finfine prezentas la malĝustan atestilon.

La eltrova eligo ankaŭ respondas pli frue starigitan demandon: ĉu la ĵetono tute videblas tra tiu provizanto. Se ĝi listigas nenion, la problemo sidas pli supre ol la VPN-kliento kaj apartenas al la mezaĵo.

La procezo, kiu konektiĝas, devas atingi la ĵetonon

Ĵetona operacio, kiu funkcias en via labortabla seanco, pruvas nenion pri sistema servo. La servo povas ruliĝi kiel alia uzanto, en alia muntada nomspaco, kun modula vojo, kiu preterlasas la bibliotekon de la provizanto, aŭ sen permeso malfermi la aparatan nodon. Identigu, kiu procezo efektive tenas la konekton, kaj testu el tiu kunteksto.

Traktado de PIN meritas propran decidon. La referenca efektivigo proponas PIN-kaŝmemoron kaj protektitan aŭtentigan vojon, kaj ambaŭ ekzistas por ke operatoro povu elekti laborfluon anstataŭ elpensi ĝin. Ne konvertu senprizorgan postulon en klartekstan PIN ene de komuna profilo, ĉar tio interŝanĝas la protekton de la ĵetono kontraŭ komforto. Kie la ĵetono malpermesas elportadon de ŝlosilo, la subskribo okazas sur la aparato kaj la PIN estas la sola loka sekreto. Traktu ĝin kun la zorgemo, kiun tio implicas.

Kion la ĵetono ne anstataŭigas

La ĵetono aŭtentigas la klienton laŭ la deplojita politiko, kaj ĝi ne anstataŭigas la kontrolojn de la kliento pri la servilo. Sukcese elektita atestilo ne estas permeso akcepti neatenditan pordegan atestilon, kaj la du kontroloj protektas kontraŭajn direktojn.

Aliĝo ankoraŭ devas okazi ĉe la eldonanto, kaj la pordego ankoraŭ devas rajtigi la identecon.

Por akcepto, apartigu la etapojn: la provizanto ŝargiĝas, la celata atestilo troviĝas, la privata ŝlosilo uziĝas kun loka rajtigo, la VPN aŭtentigas, kaj la operacio pri la rimedo sukcesas. Haltu ĉe la unua etapo, kiu malsukcesas, anstataŭ cikli tra pasvortoj kaj reinstali la kriptografian stakon.

Registru versiojn, modulan posedrajton, la elektitan publikan identigilon kaj purigitajn erarojn, kaj lasu PIN-ojn kaj akreditaĵajn pakaĵojn ekster tiu registro.