Nenosiri sahihi la VPN haliwezi kuchukua nafasi ya cheti kinachokosekana

Vitambulisho ni sahihi, profaili huagizwa bila matatizo, na muunganisho bado unashindikana kabla uthibitishaji kukamilika. Kwenye Windows ujumbe unaweza kuwa hitilafu 798, kuhusu cheti ambacho hakikupatikana kwa mbinu ya EAP. Kwenye OpenVPN kumbukumbu ya mteja inaonyesha kupeana mkono kwa TLS ambako hakuridhishi seva kamwe. Zote mbili zinaeleza kitu kimoja kinachokosekana: cheti cha mteja ambacho mteja alipaswa kuwasilisha.

Nenosiri huthibitisha ujuzi wa siri; cheti huthibitisha umiliki wa ufunguo, na kimoja hakichukui nafasi ya kingine.

Nenosiri halikuwa tatizo kamwe

Hitilafu 798 ni kushindwa kwa utafutaji wa cheti. Mteja aliombwa cheti kinacholingana na mbinu ya uthibitishaji iliyowekwa, alitafuta katika hifadhi yake na hakupata kitu chochote cha kutumika. Hiyo inaweza kumaanisha kuwa cheti hakipo, kipo bila ufunguo wake wa faragha, kimeisha muda, au kimehifadhiwa mahali ambapo utafutaji haufikii. Kujaribu nenosiri tena hakuwezi kubadilisha hali yoyote ya hizo, ndiyo sababu hitilafu inarudi hata kwa vitambulisho sahihi.

Soma ujumbe kabla ya kuchukua hatua. Kukataliwa kwa vitambulisho, kushindwa kwa utafutaji wa cheti na kushindwa kwa kupeana mkono kwa TLS ni matokeo matatu tofauti, na moja tu linahusisha nenosiri.

Hifadhi ya mteja inapaswa kuwa na nini

Vitu viwili vinahusika. Cheti cha mteja kinapaswa kusakinishwa kwa mtumiaji anayeendesha mteja wa VPN, pamoja na ufunguo wake wa faragha, na mzizi unaotoa lazima uaminiwe. Faili ya .cer ina cheti cha umma tu, kwa hiyo yenyewe haiwezi kuthibitisha chochote. Katika msimamizi wa vyeti vya Windows, utambulisho wa mteja ni wa hifadhi ya kibinafsi ya mtumiaji wa sasa, na mzizi ni wa hifadhi ya mizizi inayoaminika.

Kusakinisha utambulisho katika hifadhi ya mashine, au katika hifadhi ya mizizi pekee, hakukidhi utafutaji unaoelekezwa kwenye hifadhi ya kibinafsi ya mtumiaji. Angalia hifadhi, alama ya ufunguo wa faragha na tarehe za uhalali kwa pamoja, kisha uanzishe upya mteja ili asome hifadhi tena.

Bidhaa mbili, kitambulisho kimoja kinachokosekana

Seva za OpenVPN zinahitaji cheti cha mteja kwa chaguo-msingi. Kuongeza auth-user-pass kwa mteja hutuma jina la mtumiaji na nenosiri, na kupeana mkono kwa TLS bado kunaomba cheti, kwa hiyo nenosiri pekee haliwezi kukamilisha muunganisho chini ya verify-client-cert require. Seva inaweza kuwekwa kutohitaji chochote, jambo ambalo hufanya nenosiri kuwa kitambulisho pekee cha mteja na ni upungufu wa kweli wa nguvu. Skripti ya shell nyuma ya auth-user-pass-verify inaweza kuthibitisha vitambulisho, na inahitaji utekelezaji wa skripti uwe umewezeshwa, jambo ambalo huifanya kuwa muundo hatari zaidi kuliko backend sahihi ya uthibitishaji.

Profaili inayotegemea nenosiri pekee pia inategemea chaguo zinazosukumwa, ambazo kwa upande wake zinategemea utaratibu wa kuvuta uwe umewezeshwa.

Usirekebishe cheti kinachokosekana kwa kuzima ukaguzi

Kishawishi ni kulegeza uthibitishaji ili ujumbe utoweke. Hilo huondoa udhibiti uliokuwa ukifanya kazi yake na kuacha muunganisho ambao hautii thibitisha tena kile kinachodai. Iwapo lango limebadilisha mzizi wake hivi karibuni, pakua upya kifurushi cha mteja badala ya kuhariri profaili, kwa sababu kifurushi cha zamani kinaweza bado kubeba mzizi uliopita. Iwapo chaguo la uthibitishaji kwa cheti halipo kwenye kihariri cha profaili, huenda toleo la Windows lililosakinishwa haliwasilishi mbinu hiyo; sasisha mfumo badala ya kuhariri XML kwa mkono.

Andika ni hifadhi ipi iliyokuwa na cheti, mtumiaji gani aliendesha mteja na kama ufunguo wa faragha ulikuwepo. Hayo matatu yanaeleza karibu kila kisa cha kushindwa huku.

Nenosiri lilikuwa sawa. Kitambulisho ambacho mbinu ilihitaji kwa kweli kilikuwa mahali pengine.