Kodėl OpenVPN vis dar prašo privataus rakto failo, kai yra tokenas

Įstatote tokeną, paties teikėjo įrankis jį mato, o VPN klientas vis tiek prašo privataus rakto failo. Šis prašymas neįrodo, kad tokenas nepalaikomas. Dažniausiai tai reiškia, kad profilis niekada nepasakė klientui naudoti tokeno, todėl jis grįžo prie sertifikato ir rakto įvesčių, kurių tikisi pagal numatytuosius nustatymus.

Du atskiri dydžiai turi būti teisingi, kad tas grįžimas sustotų: teikėjas, kuris atskleidžia tokeną, ir sertifikato tapatybė jame. Jie pateikiami skirtingomis parinktimis ir juos lengva supainioti.

Klientas prašo failo, nes profilis taip nurodo

Numatytasis profilis tikisi sertifikato failo ir privataus rakto failo arba vieno PKCS#12 paketo. Kai šių įvesčių nėra, klientas neturi ko įkelti ir elgiasi beveik kaip trūkstant failo, todėl simptomas skaitomas kaip sulaužytas kelias, o ne kaip trūkstamas mechanizmas. PKCS#11 kelias pakeičia šias įvesčių, o ne papildo jas, todėl profilis, kuris vis dar nurodo rakto failą, toliau naudos failą. Sąmoningai pašalinkite failų įvesčių ir leiskite tokenui pateikti abi puses.

Teikėjo parinktis nurodo tarpinės programinės įrangos biblioteką, o ne įrenginį ir ne sertifikatą. Ar supakuotas klientas gali įkelti tą biblioteką, priklauso nuo to, kaip jis buvo sukurtas, įskaitant neprivalomą p11-kit palaikymą, kurį vieni kūrimai įjungia, o kiti praleidžia. Bendras vadovas negali pasakyti, kokią sąrangą turi jūsų paketas.

Serializuota tapatybė yra kitas dydis

Sertifikato tapatybė yra ilga serializuota eilutė, kurią sukuria aptikimo procesas, ir tai nėra bibliotekos kelias, nei tokeno PIN, nei VPN paskyros pavadinimas. Ji dažnai turi simbolių, kuriems reikia kabučių, o reikšmė be kabučių gali būti nukirpta arba neteisingai perskaityta be aiškios klaidos. Naudokite paties kliento parinktį tapatybės aptikimas, kad išvardytumėte, ką atskleidžia tokenas, tada tiksliai nukopijuokite norimą įrašą. Pirmojo sąrašo objekto pasirinkimas yra būdas, kuriuo įrenginys galiausiai pateikia netinkamą sertifikatą.

Aptikimo išvestis atsako ir į ankstesnį klausimą: ar tokenas apskritai matomas per tą teikėją. Jei ji nieko neišvardija, problema yra aukščiau VPN kliento ir priklauso tarpinei programinei įrangai.

Procesas, kuris prisijungia, turi pasiekti tokeną

Tokeno operacija, kuri veikia jūsų darbalaukio sesijoje, nieko neįrodo apie sistemos tarnybą. Tarnyba gali veikti kaip kitas naudotojas, kitame prijungimo vardų sraute, su modulių keliu, kuris praleidžia teikėjo biblioteką, arba be leidimo atidaryti įrenginio mazgą. Nustatykite, kuris procesas iš tikrųjų laiko ryšį, ir tikrinkite iš tos aplinkos.

PIN tvarkymas nusipelno atskiro sprendimo. Etaloninė realizacija siūlo PIN podėlį ir apsaugotą autentifikavimo kelią, ir abu egzistuoja tam, kad operatorius galėtų pasirinkti darbo eigą, o ne ją išrasti. Neverskite neprižiūrimo reikalavimo į atviro teksto PIN bendrame profilyje, nes tai iškeičia tokeno apsaugą į patogumą. Ten, kur tokenas draudžia rakto eksportą, pasirašymas vyksta įrenginyje, o PIN yra vienintelė vietinė paslaptis. Elkitės su juo atsargiai, kaip tai reikalauja.

Ko tokenas nepakeičia

Tokenas autentifikuoja klientą pagal įdiegtą politiką ir nepakeičia kliento patikrų serveryje. Sėkmingai pasirinktas sertifikatas nėra leidimas priimti netikėtą tinklų sietuvos sertifikatą, ir abi patikros saugo priešingas kryptis.

Registracija vis dar turi įvykti pas išdavėją, o tinklų sietuvė vis dar turi įgalioti tapatybę.

Dėl priėmimo atskirkite etapus: teikėjas įkeliamas, numatytas sertifikatas randamas, privatus raktas naudojamas su vietine autorizacija, VPN autentifikuojasi ir ištekliaus operacija pavyksta. Sustokite pirmame nepavykusiame etape, o ne perrinkinėkite slaptažodžių ir iš naujo diegkite kriptografijos krūvą.

Užrašykite versijas, modulių nuosavybę, pasirinktą viešąjį identifikatorių ir išvalytas klaidas, o PIN ir prisijungimo duomenų paketus palikite už to įrašo ribų.