Android 12 na IKEv1 VPN: toleo la uzinduzi, IKEv2, programu za wahusika wengine

Simu mbili zote zinaonyesha Android 12 kwenye Mipangilio, na ni moja tu kati yao inayoendelea kuanzisha profaili ya zamani ya IPsec XAuth ambayo lango lako hutoa. Tofauti si mpangilio ambao mtumiaji anaweza kufikia: ulinzi unaozuia njia ya asili ya zamani ya IKEv1 huangalia kiwango cha SDK ambacho kifaa kilitolewa nacho, sio tu toleo ambalo linaendesha sasa. Tofauti hiyo moja huamua kama ulinganishaji wa kundi una maana, na pia huamua ni njia ipi kati ya tatu za uhamishaji unayoihitaji kweli.

Simu mbili za Android 12 si kesi moja ya mtihani

Mabadiliko ya AOSP yaliyozuia vifaa vipya kuanzisha profaili za IKEv1 za zamani hulinganisha DEVICE_INITIAL_SDK_INT na Android S, ambayo ni API 31. Katika njia ya asili ya zamani ya kuanzisha, profaili inayostahili huleta hitilafu ya operesheni isiyotumika kabla ya muunganisho wowote wa maana kuwepo. Simu iliyotolewa na Android 11 na kusasishwa baadaye bado inapita ulinzi huo; modeli iliyozinduliwa na Android 12 haipiti.

Unaweza kusoma namba hizo mbili kwenye kifaa kilicho na utatuzi umewashwa:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

Thamani ya kwanza ni kiwango cha uzinduzi ambacho ulinzi unajali, ya pili ni kile simu inaendesha leo. Pale sifa haipo, tegemea nyaraka za usaidizi za modeli badala ya kukisia kutoka jina la masoko, na usidhani kuwa ujenzi wa muuzaji huhifadhi kila njia ya uoanifu ambayo toleo la msingi lilikuwa nayo.

Tofauti moja zaidi huokoa saa moja ya muda wa usaidizi uliopotea: profaili iliyohifadhiwa ambayo bado imeorodheshwa kwenye mipangilio ya VPN haithibitishi chochote kuhusu kama jukwaa litaianzisha. Kuingiza PSK tena au kuhariri njia hakuwezi kuondoa ukaguzi wa usaidizi wa itifaki unaoendeshwa mapema, na hitilafu hiyo inaonekana kama tatizo la vitambulisho wakati sivyo.

Njia ya kwanza: weka msururu wa asili wa zamani pale bado unafanya kazi

Msururu wa zamani ni ule unaosoma profaili za IPsec XAuth PSK, IPsec Hybrid RSA na L2TP/IPsec PSK kutoka skrini ya VPN ya mfumo. Kwenye kifaa kilichotolewa chini ya API 31 unabaki kuwa njia inayowezekana baada ya uboreshaji, ndiyo sababu jaribio kwenye simu ya zamani linaweza kufanikiwa wakati simu mpya inakataa profaili hiyo hiyo.

Ulinganisho unaojaliza ni kwa darasa la kifaa, sio kwa toleo la Android: orodhesha modeli zilizo kwenye kundi, soma viwango vyao vya API vya uzinduzi, na uzigawanye kuwa vifaa ambavyo bado vinaanzisha profaili na vifaa ambavyo haviwezi. Kitu kingine chochote hutoa sera ya usaidizi inayojipinga yenyewe wakati mtumiaji anaponunua simu mpya.

Njia ya pili: profaili za IKEv2 za jukwaa

Modeli ya umma ya utoaji ya Android kwa IKEv2 ni kitu kingine, sio profaili ya IKEv1 iliyopewa jina jipya. API ya jukwaa kwa profaili za IKEv2 ilikuja na API 30 na inatarajia IKEv2 na mbinu ya uthibitishaji ambayo lango hutoa, kwa kawaida ya cheti au EAP. Hakuna uboreshaji unaoendana kwa waya kutoka IKEv1 XAuth au Hybrid hadi IKEv2: lango lazima lisanidiwe kwa itifaki mpya, na profaili lazima ibebe utambulisho unaolingana.

Hii ni njia yenye maisha marefu zaidi, na pia ile inayofichua kazi halisi. Uthibitishaji wa utambulisho, uthibitishaji wa mtumiaji, DNS, njia za handaki zilizogawanywa na idhini ya rasilimali zote lazima zistahimili uhamishaji; ikiwa ni kupeana mkono tu kunafanikiwa, watumiaji wanabaki wameunganishwa na handaki isiyofikia chochote.

Usambazaji kwa kawaida hupitia MDM au usanidi unaosimamiwa, sio mtumiaji anayeandika sehemu. Ikiwa miundombinu hiyo bado haipo, mpango wa uhamishaji lazima uijumuishe, kwa sababu kuingiza profaili ya IKEv2 kwa mkono kwenye kila kifaa si operesheni ambayo dawati la msaada linaweza kuimudu.

Njia ya tatu: programu ya mteja wa mhusika mwingine

Baadhi ya programu za VPN huleta utekelezaji wao wenyewe wa itifaki na hazitegemei msururu wa asili wa zamani kabisa. Hiyo huwafanya kuwa suluhisho la muda halali kwa kundi lisiloweza kuhamia haraka, lakini swali la uoanifu linahamia kwenye programu: ikiwa inatekeleza hali halisi ya IKEv1 ambayo lango lako linazungumza, pamoja na uthibitishaji na seti za misimbo ambazo lango linahitaji.

Chukulia matriki ya usaidizi ya programu yenyewe kama mamlaka na sio maelezo ya duka, na jaribu kifaa kimoja halisi dhidi ya lango halisi kabla ya kuipendekeza. Kufanya root ya simu ili kurejesha njia ya jukwaa iliyoondolewa pia si suluhisho linalodumishwa; huhamishia tatizo kwenye usanidi usioungwa mkono ambao sasisho la mfumo lijalo linaweza kuuvunja kwa kimya.

Chagua kwa kile lango linaweza kutoa

Uamuzi hupungua ukiwa unajua mambo mawili: ni vifaa vipi vilivyozinduliwa kwa API 31 au baadaye, na kama lango linaweza kuwasilisha huduma ya IKEv2 na modeli hiyo hiyo ya uandikishaji. Ikiwa linaweza, hamia na uache kuwekeza kwenye profaili ya zamani. Ikiwa bado haliwezi, weka IKEv1 kwa vifaa ambavyo bado vinaianzisha, na vifaa vipya vipe mteja wa mhusika mwingine kama msamaha ulioandikwa na wenye kikomo cha muda, sio njia ya kuzunguka isiyoelezwa.

Mambo mawili hufanya mpango uweze kutetewa. Kwanza, rekodi sababu ya kila msamaha pamoja na modeli na kiwango cha uzinduzi, ili mkaguzi aweze kuona kuwa mpaka ni ulinzi wa jukwaa na sio upendeleo usioelezwa. Pili, chukulia uhamishaji kama kazi iliyopangwa: IKEv1 imepitwa na wakati kwenye njia ya viwango (RFC 9395), ambayo inamaanisha vifaa vilivyobaki vitaendelea kupungua na misamaha inapaswa kuisha pamoja navyo.