Yadda tabbatarwar haɗe-haɗe ta IKEv1 ke komawa tabbatarwar mai amfani ta IKEv2

Kowane tsohon bayanin VPN da ke neman takardar shaidar uwar garke sannan sunan mai amfani yana ɗauke da abubuwan tabbatarwa biyu a cikin musanya ɗaya, kuma wannan siffa tana rayuwa fiye da yarjejeniyar da ta kawo ta. An gina yanayin haɗe-haɗe na IKEv1 don wannan: ƙofa tana tabbatar da kanta da maɓallin jama'a yayin da mai amfani ke tabbatar da kansa daga baya ta XAuth. IKEv2 yana bayyana wannan tunanin mataki biyu da wata hanya dabam, kuma a cikin waɗannan bambance-bambance ne ƙaura ke gazawa. Babu lambar siga da ke juya ɗaya zuwa ɗayan, kuma kwafin tsoffin sunayen zaɓi cikin sabon bayani yana haifar da abokin ciniki da ke yin shawara sannan bai tabbatar da komai ba.

Abin da yanayin haɗe-haɗe ya yi a cikin IKEv1

A cikin bayanin haɗe-haɗe, ɓangaren da ke amsawa yana sanya hannu kan musayar mataki na farko da takardar shaidarsa yayin da mai farawa ba ya gabatar da ko ɗaya da gangan. Don haka hujjar asali ba daidai take, kuma wannan ne ya ba ƙofa damar kiyaye PKI da take da shi yayin da masu amfani suka kiyaye kalmomin sirrinsu na jagorar. Da zarar mataki na farko ya kammala, XAuth yana aiki a matsayin buƙata da amsa waɗanda ke ɗauke da sifofin sunan mai amfani da kalmar sirri a cikin tashar ISAKMP da aka riga aka ɓoye.

Lura inda amana take sauka. Takardar shaida tana amsa wace ƙofa abokin ciniki ya isa; XAuth yana amsa wane mai amfani yake son shiga. Babu ɗayan da ke maye gurbin ɗayan, kuma abokin ciniki da aka saita ya karɓi kowace takardar shaidar uwar garke ya watsar da amsar farko a shiru. Ana kuma amfani da alamar haɗe-haɗe ga yanayin tashin hankali da maɓallin da aka riga aka raba tare da XAuth, wani tsari dabam da irin wannan ƙwarewar mai amfani, don haka karanta bayanin ba sunan ba. Dukansu biyu sun fito daga daftari waɗanda ba su taɓa zama ma'auni ba, kuma shi ya sa masana'antun biyu za su iya aiwatar da yanayin haɗe-haɗe kuma ba za su iya yin aiki tare da kowa ba.

Yadda IKEv2 ke isa ga waɗannan hujjoji biyu

IKEv2 yana raba aikin tsakanin IKE_SA_INIT da IKE_AUTH. Musayar farko tana amincewa da shawarwari da maɓallai ba tare da wani asali ba; ta biyu tana ɗauke da IDi, IDr da kayan AUTH. A ƙarƙashin EAP kayan AUTH na farko na mai farawa yana fita fanko, mai amsawa yana tabbatar da kansa da farko da takardar shaidarsa da sa hannunsa, sannan tattaunawar EAP tana gudana cikin saƙonnin IKE_AUTH.

Hanyar da ke sa wannan amintacce ita ce kayan maɓalli. Ingantacciyar hanyar EAP tana fitar da maɓallin zama, kuma ana lissafta kayan AUTH na ƙarshe na mai farawa daga gare shi, don haka hujjar mai amfani da maɓallan rami suna haɗe. XAuth ba ta da makamancin haka: sifofinta suna zuwa bayan mataki na farko kuma ba su ba da gudummawa ga maɓallan. Wannan rata ita ce aka tsara tsarin IKEv2 ya rufe, kuma shi ya sa shiga IKEv2 mai aiki ke tabbatar da takardar shaidar uwar garke kafin ya nemi komai.

Wannan tsari kuma bincike ne mai amfani. Lokacin da abokin ciniki ya koka game da bayanan shiga kafin ya nuna maka takardar shaida, ba ya yin musayar EAP ta IKEv2 kwata-kwata.

Ka raba asali uku daban

Ƙaura tana lalacewa lokacin da asali uku suka faɗi cikin fili ɗaya. Akwai asalin ƙofa da abokin ciniki ke tabbatarwa, yawanci sunan DNS a cikin subject ko SAN na takardar shaida. Akwai asalin mai amfani da aka gabatar a cikin EAP, wataƙila shiga yanki, adireshi ko bayyanannen igiyar asalin EAP. Kuma akwai tushen izini wanda ke haɗa wannan mai amfani da cibiyoyin sadarwa da hanyoyi.

Tsarin swanctl na strongSwan yana nuna rabuwar: haɗin yana saita remote { auth = pubkey } ga ƙofa da local { auth = eap-mschapv2 } ga mai amfani, tare da ɗaukar asalin EAP daban.

Lokacin da asalin mai amfani a cikin sabon bayani ya bambanta da tsoffin sifofin XAuth, misali UPN maimakon gajeren suna, uwar garken tabbatarwa tana ganin wanda ba a sani ba kuma gazawar tana kama da kalmar sirri mara kyau. Bincika igiyar asali kafin bincika bayanan shiga.

Yi taswirar zaɓuɓɓukan sannan ka yi tsammanin tarko

Taswirar gajera ce kuma kowane layi yana da tarko da ke bayyana kawai a lokacin tabbatarwa.

Babu wani layi cikin waɗannan da ya zama kawai canza suna. Kayan saitin yana isar da adireshi da masu warwarewa ta jerin sifofi masu nau'i, yayin da filin sifofin XAuth nasa ne na asali; ɗaukar su a matsayin masu musanya ita ce hanyar da bayani ke ƙarewa yana neman saitin da ƙofa ba za ta taɓa aikawa ba.

Masu zaɓen zirga-zirga sun cancanci faɗakarwarsu. IKEv1 yana bayyana zirga-zirgar da ake so ta ID na wakili da ke daure da musayar quick mode, yayin da IKEv2 ke yin shawara kan masu zaɓe a lokacin IKE_AUTH kuma mai amsawa na iya ƙuntata su. Rashin daidaito yana haifar da IKE SA da aka kafa ba tare da child SA ba, wanda wasu abokan ciniki ke nuna cikin farin ciki a matsayin haɗe.

Ɗauki tsohuwar haɗin a matsayin iyaka

RFC 9395 ya ayyana IKEv1 a matsayin wanda ya tsufa, don haka tsohuwar haɗin haɗe-haɗe iyaka ce ta jituwa mai kwanan wata, ba tushe ba. Gudanar da duka bayanan biyu tare a lokacin canjin, domin gwajin da ke da muhimmanci ba shine ko sabon bayanin ya tashi ba, amma ko wannan mai amfani a wannan na'urar ya isa ga waɗannan albarkatu.

Ka riƙe tabbatar da takardar shaida da tsanani daga farko zuwa ƙarshe. Da zarar abokin ciniki ya daina gabatar da takardar shaidarsa, jarabar ita ce a sassauta binciken uwar garke har sai musafaha ya kammala, kuma hakan yana musanya hujjar da ta rage da wata alama mai kore.

Rubuta abubuwa huɗu kafin ka yi ritaya da tsohon bayanin: hanyar EAP, igiyar asali, tushen izini da ranar da tallafi ke ƙarewa.