strongSwan send_cert: ni lini cheti cha IKE kinatumwa

Lango hurekodi hitilafu za uthibitishaji zinazohusiana na vyeti, na wazo la kwanza ni kuongeza CA nyingine kwa mpokeaji. Hilo huchukulia kwamba cheti kilifika na kilikataliwa. Uwezekano mwingine ni kwamba hakikutumwa kamwe, na sera ya muunganisho ya mtumaji huamua hilo. Baini ni ipi kati ya hizo mbili ilitokea kabla ya kubadilisha imani.

send_cert hudhibiti nini hasa

Uthibitishaji wa cheti unahitaji cheti cha huluki ya mwisho cha peer kufika upande mwingine kupitia mabadilishano ya IKE au kupitia maandalizi ya awali. Katika swanctl, mpangilio wa muunganisho send_cert huamua kama kituo hiki cha mwisho kinajumuisha mzigo wake wa cheti: kamwe, kila wakati au ifasked. Thamani chaguo-msingi ifasked hukituma kama jibu la ombi la cheti kutoka kwa peer. Kuomba cheti ni mpangilio tofauti, kwa sababu kumwomba upande mwingine cheti chake si sawa na kutoa chako mwenyewe.

Usanidi wa zamani wa ipsec.conf ulitumia leftsendcert na rightsendcert, na majina hayo yanahusiana na majukumu ya ndani na ya mbali, si moja kwa moja na swanctl.

Soma jaribio moja kabla ya kubadilisha muunganisho

Fanya uchunguzi kutokana na jaribio moja lililodhibitiwa, si kutokana na hisia ya jumla kwamba vyeti vinahusika. Sera na muungano unaoendelea vyote vinaweza kukaguliwa.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Orodha ya miunganisho huonyesha thamani iliyowekwa ya send_cert, na orodha ya SA huonyesha miunganisho ipi iliyofunguka kwa kweli. Kumbukumbu huongeza maelezo ya mazungumzo: kama ombi la cheti lilipokelewa na kama mzigo wa cheti ulitoka. Hitilafu ya jumla ya uthibitishaji haionyeshi tatizo la uwasilishaji, kwa hivyo tafuta mabadilishano mahususi kabla ya kuhitimisha chochote. Rekodi muhuri wa muda wa jaribio ili dirisha la kumbukumbu lifunike mshikamano wote wa mikono.

Imani ya mpokeaji ni uamuzi tofauti

Uwasilishaji na imani ni sifa tofauti, na kurekebisha moja hakurekebishi nyingine. Mpokeaji lazima awe na nanga ya imani iliyokusudiwa, apokee mnyororo unaoweza kutumika na alingane na utambulisho wa peer unaotarajiwa. Cheti cha huluki ya mwisho kinachofika bila cheti chake cha kati bado kinashindwa katika ukaguzi mkali wa mnyororo. Kinyume chake, kusakinisha CA hakumlazimishi peer kutuma cheti chake hata kidogo.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Ukaguzi huonyesha ni mtoaji gani alisaini cheti na lini kinaisha, na nanga ya mpokeaji lazima ilingane na hilo. Iamini CA inayotoa inayomilikiwa na usanidi, si kila cheti cha kati katika mnyororo, kwa sababu kupandisha kila cheti cha kati hadi mzizi hupanua imani mbali zaidi ya peer mmoja. Weka uthibitishaji wa utambulisho ukiwa hai, kwa sababu muunganisho unaofanikiwa tu uthibitishaji ukiwa umezimwa si urekebishaji. Palipo na mnyororo usiokamilika, rekebisha maandalizi badala ya sera ya mtumaji.

Badilisha mtumaji tu ukiwa na ushahidi

Kumbukumbu inapoonyesha cheti hakikutumwa kamwe na mpokeaji aliomba kwa kweli, kuweka send_cert kuwa always ni mabadiliko yenye sababu kwa muunganisho huo. Tumia katika usanidi wa swanctl, pakia upya miunganisho na anzisha kikao kipya badala ya kutumia tena SA iliyopo. Thibitisha kwamba mzigo wa cheti sasa unaonekana na kwamba mpokeaji unaukubali dhidi ya nanga iliyokusudiwa. Ikiwa hakuna kinachobadilika, hitilafu ilikuwa upande wa imani na mpangilio wa mtumaji haukuwa sababu.

Andika mabadilishano yaliyoonekana, nanga na uthibitishaji unaotokana na hayo katika kumbukumbu ya mabadiliko. Urekebishaji wa cheti ambao hauwezi kuelezewa kwa maneno hayo ni bahati mbaya.