Hitilafu ya uaminifu ya Android IKEv2: tuma CA ya kati, si mzizi

Simu inakataa kuunganishwa na kuchapisha No trusted RSA public key found for vpn.example.net, wakati cheti kilekile cha lango kinafanya kazi kutoka kwa kompyuta ya mkononi kwenye mtandao huo huo. Hatua ya kuvutia ni kutoa cheti upya. Kabla ya kufanya hivyo, tambua ni hitilafu ipi kati ya tatu uliyo nayo, kwa sababu moja tu kati yao inahusu maudhui ya cheti. Ujumbe unashughulikia mnyororo usiokamilika, kutolingana kwa utambulisho, na ufunguo au sahihi isiyotumika, na kila moja ina matengenezo tofauti.

Hitilafu tatu nyuma ya ujumbe mmoja

Android hujenga mnyororo kutoka cheti cha lango hadi CA iliyochaguliwa katika wasifu wa VPN, kisha hulinganisha jina la seva na wasifu. Arifa huripoti matokeo, si hatua. Hitilafu ya uaminifu inamaanisha mnyororo haukuweza kukamilishwa kutoka vyeti vilivyotolewa katika mabadilishano; hitilafu ya utambulisho inamaanisha mnyororo ulithibitishwa lakini jina halikulingana; hitilafu ya algoriti inamaanisha kifaa au wasifu haukubali aina ya ufunguo au sahihi.

Amua kwa ushahidi badala ya kujaribu matengenezo kwa mpangilio. Jaribio moja katika kiwango cha kumbukumbu 2 dhidi ya daemon hukuambia uko kwenye mstari gani, na hugharimu kidogo kuliko kutoa upya cheti ambacho hakikuwa kikosa kamwe.

Amua kwanza: mnyororo wote ulifika?

strongSwan hutuma cheti kilichosanidiwa kwa muunganisho huo, na vyeti vya kati ni vitambulisho tofauti. Lazima vipakiwe kama vyeti vya CA kabla daemon haijaweza kuviweka kwenye mzigo, kwa hivyo mpangilio ambapo cheti cha seva kinasainiwa na cha kati, mzizi ni nanga ya uaminifu, na cha kati kinapatikana tu katika saraka ya ujenzi ya CA huzalisha hitilafu hii hasa: jani pekee kwenye waya, mnyororo unaishia mapema kwenye simu.

Angalia kile daemon inacho kwa swanctl --list-certs kwenye usanidi wa swanctl, au ipsec listcerts na starter ya zamani. Cha kati kinapaswa kuonekana kama cheti cha CA na mzizi juu yake. Ikiwa hakipo, hakuna chaguo la mteja litasaidia; ikiwa kipo, nenda kwenye swali linalofuata.

Kisha angalia ikiwa kitatumwa. Rejea ya swanctl.conf inaeleza send_cert, ambayo chaguo-msingi ifasked hutuma vyeti tu wakati mwenzake ameomba; always hutuma kila wakati. Kilinganishi cha zamani ni leftsendcert=always ndani ya ipsec.conf. Mpangilio huo hudhibiti utumaji, si upatikanaji, kwa hivyo hauwezi kufidia cha kati ambacho daemon haikupakia kamwe.

Ikiwa mnyororo ni mfupi, pakia cha kati mahali daemon inapotafuta

Weka cha kati kwenye saraka ya CA na si kando ya jani: /etc/ipsec.d/cacerts kwa usanidi wa ipsec.conf, /etc/swanctl/x509ca kwa swanctl, au njia ambayo kifurushi chako hubadilisha. Pakia upya usanidi na uorodheshe vyeti tena. Toleo zingine pia hutuma kifurushi kilicho na mnyororo ndani ya faili ya jani, lakini saraka ya CA ni mpangilio unaobebeka katika matoleo na vifurushi.

Thibitisha pia kutoka upande wa mteja. Simu inaona tu kile mabadilishano yalichobeba, kwa hivyo kumbukumbu ya daemon katika kiwango cha 2 inapaswa kuonyesha cha kati kati ya vyeti vilivyotumwa. Ikiwa kumbukumbu inaonyesha na simu bado inashindwa, uko kwenye mstari mwingine wa jedwali, na kuendelea kurekebisha faili za CA hakutabadilisha matokeo.

Ikiwa mnyororo umekamilika, acha kuhariri vyeti

Hitilafu ya utambulisho ni kutolingana kati ya jina katika wasifu wa VPN na jina katika cheti. Android hulinganisha utambulisho wa seva uliouweka na cheti kilichothibitisha, kwa hivyo wasifu unaoelekeza kwenye anwani wakati cheti kinataja jina la mwenyeji, au wasifu unaotaja jina la mwenyeji ambalo cheti hakijashughulikia, hushindwa baada ya uthibitishaji wa mnyororo kufanikiwa. Rekebisha upande usio sahihi, na uweke wasifu na cheti sawia wakati wowote kati yao unabadilika.

Hitilafu ya algoriti inaonekana na mnyororo halali na jina linalolingana. Matoleo ya Android hutofautiana katika aina za funguo na mifumo ya sahihi wanayokubali, na aina ya wasifu yenyewe hupunguza chaguo. Ikiwa lango linatumia mchanganyiko wa zamani au usio wa kawaida, linganisha na kile kifaa kinachosaidia kabla ya kudhani cheti kimeharibika. Kumbukumbu ya daemon itaonyesha mazungumzo ya mkono yakiendelea mbali zaidi kuliko kwenye kesi ya uaminifu, na hiyo ni ishara kwamba mnyororo si tatizo tena.

Usisakinishe cha kati kama mzizi wa mtumiaji kwenye simu

Kusakinisha cha kati kinachokosekana kama cheti cha mtumiaji kwenye simu hufanya onyo litoweke na hubadilisha mfumo wa uaminifu wa simu kwa kila programu inayokubali mizizi iliyosakinishwa na mtumiaji. Pia huficha hitilafu ya uwasilishaji itakayogusa mteja anayefuata, na huacha lango likituma mnyororo usiokamilika kwa kila kifaa cha baadaye. Matengenezo ya kudumu ni kwenye seva, mara moja, kwa wateja wote.

Weka maamuzi matatu tofauti kwenye kumbukumbu ya mabadiliko: ni vyeti vipi vilitumwa, ni utambulisho upi ulilinganishwa, na ni algoriti ipi ilijadiliwa. Lango linalotuma mnyororo wake kamili kila wakati, wasifu unaotaja cheti kwa usahihi, na aina ya ufunguo inayosaidiwa na kundi ni mambo matatu madogo, na ndiyo hitilafu hii yote.