AWS Client VPN: cheti cha seva kinyume na jukumu la cheti cha mteja

Endpoint ya Client VPN kila wakati inahitaji cheti cha TLS cha seva. Hiyo ndiyo utambulisho ambao endpoint inayosimamiwa huwasilisha mteja anapounganishwa. Ni kitu tofauti na vyeti ambavyo wateja binafsi huwasilisha wakati uthibitishaji wa pande zote unatumika. Kuchanganya hivi viwili ndiyo sababu ya kawaida zaidi kwa nini usanidi wa ACM ulio sahihi kwa njia nyingine bado unashindikana kwenye muunganisho wa kwanza.

Huu ni mwongozo kutoka kwa konsoli kuelekea nje, kwa mpangilio ambao muunganisho hupitia kwa kweli.

Majukumu mawili, endpoint moja

Endpoint inamiliki utambulisho wa seva na, kwa hiari, njia ya kuthibitisha utambulisho wa wateja. Hivi husanidiwa tofauti. Kimoja huamua ikiwa mteja anaweza kuamini huduma; kingine huamua ikiwa huduma inamkubali mteja.

Soma jedwali kama mahitaji matatu huru badala ya cheti kimoja. Cheti cha seva na ufunguo wake wa faragha hubaki na huduma. Cheti cha mteja na ufunguo wa faragha unaolingana huishi kwenye kifaa. Nyenzo za CA ni kile kinachotumiwa na kithibitishaji kukagua mnyororo. Ni safu ya kati tu ambayo huwa ya kompyuta ya mkononi.

Cheti cha seva cha ACM hufanya nini

Unapounda endpoint, cheti cha seva lazima kipatikane katika ACM katika eneo lile lile la endpoint. Konsoli inaomba ARN, na ARN hiyo lazima itatulike hapo. ACM inaweza kuhifadhi cheti ulichokitoa kwa uthibitishaji wa kikoa, au kile ulichoagiza pamoja na ufunguo na mnyororo wake. Vyote viwili hufanya kazi katika jukumu hili; hutofautiana katika uboreshaji na nani anamiliki ufunguo wa faragha.

Chagua njia ya ugavi inayolingana na nani anaweza kuhuisha cheti, si ile iliyotokea kutoa faili inayoonekana halali.

Uthibitishaji wa pande zote huongeza nini

Kuchagua uthibitishaji wa mteja unaotegemea cheti huongeza swali la pili: wateja gani wanaweza kuunganishwa kabisa. Kila mteja huwasilisha cheti chake mwenyewe na huthibitisha umiliki wa ufunguo wa faragha unaolingana. Utambulisho tofauti ndiyo hufanya ubatilishaji wa kuchagua uwezekane baadaye. Kunakili ufunguo mmoja wa mteja kwenye kila kifaa hutupa sifa hiyo kimya kimya, hata cheti cha seva kilipopatikana kikamilifu.

Njia ya uthibitishaji ya endpoint ni chaguo, si sharti la jumla.

Active Directory na uthibitishaji shirikishi hujibu swali lile lile kwa njia nyingine. Mapishi ya cheti cha pande zote si lazima yawe mpango wa kuingia kwa usanidi huo, na uthibitishaji wa TLS wa seva hubaki mahali bila kujali jinsi mtumiaji anavyoruhusiwa.

Kwa nini ARN sawa ya CA si kushiriki funguo

AWS inaeleza kwamba wakati vyeti vya seva na mteja vinatolewa na CA moja, ARN ya cheti cha seva inaweza pia kutumika kwa uteuzi wa cheti cha mteja. Sentensi hiyo inahusu mnyororo ambao endpoint inauamini wakati wa uthibitishaji. Haisemi wateja watumie ufunguo wa faragha wa seva. Kompyuta ya mkononi bado inahitaji cheti chake cha mteja na ufunguo wake unaolingana.

Wakati CA ya mteja ni mtoaji tofauti, njia iliyoandikwa ni kuagiza CA hiyo kwenye ACM na kuichagua kwa jukumu la mteja.

Fuatilia hitilafu kurudi hatua

Baini hatua ipi inashindikana kabla ya kubadilisha chochote. Ikiwa mteja anakataa endpoint, ARN ya seva au mnyororo wake ndiye mtuhumiwa. Ikiwa endpoint inamkataa mteja, angalia cheti cha mteja, mtoaji wake na njia ya uthibitishaji iliyochaguliwa. Ikiwa handaki linapanda na trafiki bado inashindikana, umepita vyeti.

Badilisha kitu kimoja kwa wakati, kwa sababu kubadilisha ncha zote mbili kwa wakati mmoja huzalisha tena utata ulioanza nao.

Angalia pia algoriti za ufunguo zinazoungwa mkono na viendelezi vinavyohitajika vya huduma kwa jukumu mahususi. Cheti kinachokidhi tovuti ya umma si uthibitisho kwamba mahitaji yote ya utambulisho ya Client VPN yametimizwa.

Andika ni ARN ipi inayoshikiliwa na kila sehemu, ni CA ipi ilitoa cheti cha mteja na ni njia ipi ya uthibitishaji endpoint inatumia kwa kweli. Mistari mitatu ya kumbukumbu hufanya uboreshaji ujao kuwa kazi badala ya uchunguzi.