Jinsi uthibitishaji mseto wa IKEv1 unahamia kwenye uthibitishaji wa watumiaji wa IKEv2

Kila wasifu wa zamani wa VPN unaoomba cheti cha seva kisha jina la mtumiaji hubeba matukio mawili ya uthibitishaji katika mabadilishano moja, na umbo hilo huishi muda mrefu kuliko itifaki iliyoanzisha. Hali mseto ya IKEv1 ilijengwa kwa ajili ya hili hasa: lango hujithibitisha kwa ufunguo wa umma huku mtumiaji akijithibitisha baadaye kupitia XAuth. IKEv2 huwasilisha wazo hilo la hatua mbili kwa utaratibu tofauti, na ni katika tofauti hizo ambapo uhamishaji hushindwa. Hakuna namba ya toleo inayobadilisha kimoja kuwa kingine, na kunakili majina ya zamani ya chaguo kwenye wasifu mpya huzalisha mteja anayejadiliana kisha asithibitishe chochote.

Hali mseto ilifanya nini ndani ya IKEv1

Katika wasifu mseto upande unaojibu hutia sahihi mabadilishano ya awamu ya kwanza kwa cheti chake huku mwanzilishi kwa makusudi hakitoi cheti chochote. Kwa hiyo uthibitisho wa utambulisho ni usio na usawa, na hilo ndilo lililomruhusu lango kuweka PKI yake iliyopo huku watumiaji wakihifadhi manenosiri yao ya saraka. Awamu ya kwanza ikikamilika, XAuth hufanya kazi kama ombi na jibu linalobeba sifa za jina la mtumiaji na nenosiri ndani ya kituo cha ISAKMP kilichosimbwa.

Angalia uaminifu unatua wapi. Cheti hujibu lango gani mteja alilofikia; XAuth hujibu mtumiaji gani anataka ufikiaji. Hakuna kinachochukua nafasi ya kingine, na mteja aliyewekwa kukubali cheti chochote cha seva ameutupa kimya jibu la kwanza. Lebo mseto pia hutumika kwa hali ya ukali yenye ufunguo ulioshirikiwa mapema pamoja na XAuth, mpangilio mwingine wenye uzoefu ule ule wa mtumiaji, kwa hiyo soma wasifu na si jina. Aina zote mbili zinatoka kwenye rasimu ambazo hazikuwa viwango kamwe, na ndiyo sababu wazalishaji wawili wanaweza kutekeleza hali mseto na wasioweza kuingiliana na yeyote.

IKEv2 hufikia uthibitisho huo huo wa pili vipi

IKEv2 hugawanya kazi kati ya IKE_SA_INIT na IKE_AUTH. Mabadilishano ya kwanza hukubaliana mapendekezo na funguo bila utambulisho wowote; ya pili hubeba IDi, IDr na mizigo ya AUTH. Chini ya EAP mzigo wa kwanza wa AUTH wa mwanzilishi hutoka mtupu, anayejibu hujithibitisha kwanza kwa cheti chake na sahihi yake, kisha mazungumzo ya EAP huendelea ndani ya ujumbe wa IKE_AUTH.

Utaratibu unaofanya hili kuwa salama ni nyenzo ya ufunguo. Mbinu ya EAP iliyofanikiwa hutoa ufunguo wa kipindi, na mzigo wa mwisho wa AUTH wa mwanzilishi huhesabiwa kutoka kwake, kwa hiyo uthibitisho wa mtumiaji na funguo za handaki hufungwa pamoja. XAuth haina kifani: sifa zake hufika baada ya awamu ya kwanza na hazichangii chochote kwenye funguo. Pengo hilo ndilo lililokusudiwa kuzibwa na mfumo wa IKEv2, na ndiyo sababu kuingia kwa IKEv2 kunakofanya kazi huthibitisha cheti cha seva kabla ya kuuliza chochote.

Mpangilio huu pia ni uchunguzi wenye manufaa. Mteja anapolalamika kuhusu vitambulisho kabla ya kukuonyesha cheti, hakuwa anafanya mabadilishano ya EAP ya IKEv2 hata kidogo.

Weka utambulisho watatu tofauti

Uhamishaji unaenda kombo wakati utambulisho watatu unaanguka kwenye uga mmoja. Kuna utambulisho wa lango ambao mteja huuthibitisha, kwa kawaida jina la DNS katika subject au SAN ya cheti. Kuna utambulisho wa mtumiaji unaowasilishwa katika EAP, labda kuingia kwa kikoa, anwani au mfuatano dhahiri wa utambulisho wa EAP. Na kuna chanzo cha idhini kinachohusisha mtumiaji huyo na mitandao na njia.

Sarufi ya swanctl ya strongSwan huonyesha mgawanyiko: muunganisho huweka remote { auth = pubkey } kwa lango na local { auth = eap-mschapv2 } kwa mtumiaji, huku utambulisho wa EAP ukibebwa kando.

Wakati utambulisho wa mtumiaji katika wasifu mpya unatofautiana na sifa za zamani za XAuth, kwa mfano UPN badala ya jina fupi, seva ya uthibitishaji huona mtumiaji asiyefahamika na hitilafu inaonekana kama nenosiri baya. Kagua mfuatano wa utambulisho kabla ya kukagua vitambulisho.

Panga chaguo kwenye ramani kisha tarajia mitego

Ramani ni fupi na kila safu ina mtego unaoonekana tu wakati wa uthibitishaji.

Hakuna safu kati ya hizo iliyo ubadilishaji wa jina tu. Mzigo wa usanidi huwasilisha anwani na vitatuzi kupitia orodha ya sifa zenye aina, wakati nafasi ya sifa ya XAuth ilikuwa uvumbuzi wake yenyewe; kuzichukulia kuwa zinabadilishana ndiyo njia ambayo wasifu huishia kuomba mpangilio ambao lango halitautuma kamwe.

Vichaguzi vya trafiki vinastahili onyo lake. IKEv1 iliwasilisha trafiki yenye riba kupitia vitambulisho vya proksi vilivyofungwa na mabadilishano ya quick mode, wakati IKEv2 hujadiliana vichaguzi wakati wa IKE_AUTH na anayejibu anaweza kuvibana. Kutokupatana huzalisha IKE SA iliyoanzishwa bila child SA, ambayo baadhi ya wateja huionyesha kwa furaha kama imeunganishwa.

Chukulia muunganisho wa zamani kama mpaka

RFC 9395 inatangaza IKEv1 kuwa imepitwa na wakati, kwa hiyo muunganisho wa zamani wa mseto ni mpaka wa upatanifu wenye tarehe, si msingi. Endesha wasifu wote wawili bega kwa bega wakati wa mabadiliko, kwa sababu jaribio la muhimu si kama wasifu mpya unainuka bali kama mtumiaji yule yule kwenye kifaa kile kile anafikia rasilimali zile zile.

Weka uthibitishaji wa cheti ukiwa mkali mwanzo hadi mwisho. Mteja anapoacha kuwasilisha cheti chake mwenyewe, jaribu huwa kulegeza ukaguzi wa seva hadi mkono uishe, na hilo hubadilisha uthibitisho pekee uliobaki na aikoni ya kijani.

Andika mambo manne kabla ya kustaafisha wasifu wa zamani: mbinu ya EAP, mfuatano wa utambulisho, chanzo cha idhini na tarehe ambayo msaada unaisha.