Android 12 dhe IKEv1 VPN: versioni i nisjes, IKEv2, aplikacione të palëve të treta

Dy telefona të dy tregojnë Android 12 në Cilësimet, dhe vetëm njëri prej tyre nis ende profilin e vjetër IPsec XAuth që ofron portali juaj. Diferenca nuk është një cilësim që përdoruesi mund ta arrijë: mbrojtja që bllokon rrugën vendore të trashëguar IKEv1 shikon nivelin SDK me të cilin pajisja u dërgua, jo vetëm versionin që ekzekuton tani. Ky detaj i vetëm vendos nëse një krahasim i flotës ka kuptim, dhe vendos gjithashtu cilën nga tri rrugët e migrimit ju nevojitet vërtet.

Dy telefona Android 12 nuk janë i njëjti rast testimi

Ndryshimi në AOSP që ndaloi pajisjet e reja të nisin profile IKEv1 të trashëguara krahason DEVICE_INITIAL_SDK_INT me Android S, që është API 31. Në rrugën vendore të trashëguar të nisjes, një profil i kualifikuar shkakton një dështim operacioni të pambështetur përpara se të ekzistojë ndonjë lidhje e dobishme. Një telefon i dërguar me Android 11 dhe i përditësuar më vonë kalon ende atë mbrojtje; një model i nisur me Android 12 nuk kalon.

Të dy numrat mund t'i lexoni në një pajisje me korrigjim të aktivizuar:

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

Vlera e parë është niveli i nisjes për të cilin interesohet mbrojtja, e dyta është ajo që telefoni ekzekuton sot. Aty ku vetia mungon, mbështetuni në dokumentacionin e mbështetjes së modelit në vend që të hamendësoni nga emri i marketingut, dhe mos supozoni se një ndërtim i furnizuesit ruan çdo rrugë përputhshmërie që kishte versioni bazë.

Edhe një dallim kursen një orë kohë mbështetjeje të humbur: një profil i ruajtur që ende shfaqet në cilësimet e VPN nuk provon asgjë për atë nëse platforma do ta nisë. Rihedhja e PSK-së ose redaktimi i rrugëve nuk mund të heqë një kontroll mbështetjeje protokolli që ekzekutohet më herët, dhe dështimi duket si problem kredencialesh kur nuk është.

Rruga e parë: mbani stivën vendore të trashëguar aty ku ende funksionon

Stiva e trashëguar është ajo që lexon profile IPsec XAuth PSK, IPsec Hybrid RSA dhe L2TP/IPsec PSK nga ekrani i VPN-së së sistemit. Në një pajisje të dërguar nën API 31 ajo mbetet një rrugë e zbatueshme pas përditësimit, prandaj një provë në një aparat më të vjetër mund të ketë sukses ndërsa një aparat i ri dështon në të njëjtin profil.

Krahasimi që ka rëndësi është sipas klasës së pajisjes, jo sipas versionit të Android: renditni modelet në flotë, lexoni nivelet e tyre API të nisjes dhe ndajini në pajisje që ende e nisin profilin dhe pajisje që nuk munden. Çdo gjë tjetër prodhon një politikë mbështetjeje që kundërshton vetveten në momentin që përdoruesi blen një telefon të ri.

Rruga e dytë: profile IKEv2 të platformës

Modeli publik i provizionimit të Android për IKEv2 është një objekt tjetër, jo një profil IKEv1 i riemërtuar. API-ja e platformës për profile IKEv2 erdhi me API 30 dhe pret IKEv2 me metodën e vërtetimit që ofron portali, zakonisht me certifikatë ose EAP. Nuk ka përditësim të përputhshëm në tel nga IKEv1 XAuth ose Hybrid në IKEv2: portali duhet të konfigurohet për protokollin e ri, dhe profili duhet të mbajë identitetin përkatës.

Kjo është rruga me jetëgjatësinë më të gjatë, dhe gjithashtu ajo që zbulon punën e vërtetë. Vërtetimi i identitetit, vërtetimi i përdoruesit, DNS, rrugët e tunelit të ndarë dhe autorizimi i burimeve duhet të gjitha t'i mbijetojnë migrimit; nëse ka sukses vetëm shtrëngimi i duarve, përdoruesit mbeten të lidhur me një tunel që nuk arrin asgjë.

Vendosja zakonisht kalon përmes një MDM ose konfigurimi të menaxhuar, jo përmes një përdoruesi që shkruan fusha. Nëse ajo infrastrukturë nuk ekziston ende, plani i migrimit duhet ta përfshijë, sepse rihedhja me dorë e një profili IKEv2 në çdo pajisje nuk është operacion që tavolina e ndihmës mund ta përballojë.

Rruga e tretë: një aplikacion klient i palës së tretë

Disa aplikacione VPN sjellin implementimin e tyre të protokollit dhe nuk varen fare nga stiva vendore e trashëguar. Kjo i bën ata një zgjidhje të përkohshme legjitime për një flotë që nuk mund të migrojë shpejt, por çështja e përputhshmërisë kalon te aplikacioni: nëse zbaton saktësisht atë modalitet IKEv1 që flet portali juaj, me vërtetimin dhe grupet e shifrave që kërkon portali.

Trajtojeni matricën e mbështetjes së vetë aplikacionit si autoritet dhe jo përshkrimin e dyqanit, dhe provoni një pajisje reale kundër portalit real përpara se ta rekomandoni. Rootimi i një telefoni për të rivendosur një rrugë platforme të hequr nuk është as zgjidhje e mirëmbajtur; e zhvendos problemin në një konfigurim të pambështetur që përditësimi i ardhshëm i sistemit mund ta thyejë në heshtje.

Zgjidhni sipas asaj që portali mund të ofrojë

Vendimi ngushtohet kur dini dy gjëra: cilat pajisje u nisën në API 31 ose më vonë, dhe nëse portali mund të paraqesë një shërbim IKEv2 me të njëjtin model regjistrimi. Nëse mundet, migroni dhe ndaloni investimin në profilin e trashëguar. Nëse ende nuk mundet, mbani IKEv1 për pajisjet që ende e nisin, dhe pajisjeve të reja jepuni një klient të palës së tretë si përjashtim të dokumentuar dhe me afat, jo si një zgjidhje anësore të padeklaruar.

Dy pika e bëjnë planin të mbrojtshëm. Së pari, shënoni arsyen e çdo përjashtimi bashkë me modelin dhe nivelin e nisjes, që një auditor të shohë se kufiri është mbrojtje platforme dhe jo një preferencë e pashpjeguar. Së dyti, trajtojeni migrimin si punë të planifikuar: IKEv1 është vjetruar sipas rrugës së standardeve (RFC 9395), që do të thotë se pajisjet e mbetura do të vazhdojnë të pakësohen dhe përjashtimet duhet të skadojnë bashkë me to.