Android 12 en IKEv1-VPN: bekendstellingsvlak, IKEv2 en derdeparty-toepassings

Twee telefone wys albei Android 12 in Instellings, en net een van hulle begin nog die ou IPsec XAuth-profiel wat jou poort aanbied. Die verskil is nie ’n instelling wat die gebruiker kan bereik nie: die wag voor die native legacy IKEv1-pad kyk na die SDK-vlak waarmee die toestel verskeep is, nie net na die weergawe wat dit tans hardloop nie. Daardie een besonderheid bepaal of ’n vlootvergelyking sinvol is, en dit bepaal ook watter van die drie migrasiepaaie jy werklik nodig het.

Twee Android 12-fone is nie dieselfde toetsgeval nie

Die AOSP-verandering wat verhoed het dat nuwe toestelle legacy IKEv1-profiele begin, vergelyk DEVICE_INITIAL_SDK_INT met Android S, wat API 31 is. In die native legacy-opstartpad veroorsaak ’n kwalifiserende profiel ’n fout van die tipe nie-ondersteunde bewerking voordat enige nuttige verbinding bestaan. ’n Foon wat met Android 11 verskeep is en later opgedateer is, slaag steeds daardie wag; ’n model wat op Android 12 bekendgestel is, slaag nie.

Jy kan die twee getalle op ’n toestel met ontfouting geaktiveer lees:

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

Die eerste waarde is die bekendstellingsvlak waaroor die wag gaan, die tweede is wat die foon vandag hardloop. Waar die eienskap ontbreek, val terug op die modelondersteuningsdokumentasie eerder as om uit die bemarkingsnaam te raai, en moenie aanneem dat ’n vervaardigerbou elke versoenbaarheidspad van sy basisvrystelling behou nie.

Nog een onderskeiding spaar ’n uur se vermorste ondersteuningstyd: ’n gestoorde profiel wat nog in die VPN-instellings gelys word, bewys niks daaroor of die platform dit sal begin nie. Om die PSK weer in te voer of roetes te wysig, kan nie ’n protokolondersteuningskontrole verwyder wat vroeër loop nie, en die mislukking lyk soos ’n aanmeldingsprobleem wanneer dit nie een is nie.

Pad een: hou die native legacy-stapel waar dit nog loop

Die legacy-stapel is die een wat IPsec XAuth PSK, IPsec Hybrid RSA en L2TP/IPsec PSK-profiele uit die stelsel se VPN-skerm lees. Op ’n toestel wat onder API 31 verskeep is, bly dit ’n lewensvatbare pad ná ’n opgradering, en daarom kan ’n loodsprojek op ’n ouer handstel slaag terwyl ’n nuwe handstel dieselfde profiel nie kan begin nie.

Die vergelyking wat saak maak, is per toestelklas, nie per Android-weergawe nie: lys die modelle in die vloot, lees hul bekendstellings-API-vlakke, en deel hulle in toestelle wat die profiel nog begin en toestelle wat dit nie kan nie. Enigiets anders lewer ’n ondersteuningsbeleid wat homself weerspreek sodra ’n gebruiker ’n nuwe foon koop.

Pad twee: platform-IKEv2-profiele

Android se openbare voorsieningsmodel vir IKEv2 is ’n ander objek, nie ’n hernoemde IKEv1-profiel nie. Die platform-API vir IKEv2-profiele het met API 30 gekom en verwag IKEv2 met die verifikasiemetode wat die poort aanbied, gewoonlik sertifikaatgebaseerd of EAP. Daar is geen draadversoenbare opgradering van IKEv1 XAuth of Hybrid na IKEv2 nie: die poort moet vir die nuwe protokol opgestel word, en die profiel moet die ooreenstemmende identiteit dra.

Dit is die pad met die langste lewe, en ook die een wat die werklike werk blootlê. Identiteitsvalidasie, gebruikerverifikasie, DNS, split-tunnel-roetes en hulpbronmagtiging moet almal die migrasie oorleef; om net die handdruk te laat slaag, laat gebruikers in ’n tonnel wat niks bereik nie.

Ontplooiing gaan gewoonlik deur ’n MDM of ’n bestuurde konfigurasie eerder as dat ’n gebruiker velde intik. As daardie infrastruktuur nog nie bestaan nie, moet die migrasieplan dit insluit, want om ’n IKEv2-profiel met die hand op elke toestel weer in te voer, is nie ’n operasie wat ’n helpdesk kan absorbeer nie.

Pad drie: ’n derdeparty-kliënttoepassing

Sommige VPN-toepassings lewer hul eie protokolimplementering en maak glad nie van die native legacy-stapel gebruik nie. Dit maak hulle ’n wettige noodoplossing vir ’n vloot wat nie vinnig kan migreer nie, maar die versoenbaarheidsvraag skuif na die toepassing: of dit die presiese IKEv1-modus implementeer wat jou poort praat, met die verifikasie en syferbundels wat die poort vereis.

Behandel die toepassing se eie ondersteuningsmatriks as die gesag eerder as die winkelbeskrywing, en toets een werklike toestel teen die werklike poort voordat jy dit aanbeveel. Om ’n foon te root om ’n verwyderde platformpad te herstel, is ook nie ’n onderhoude oplossing nie; dit skuif die probleem na ’n onondersteunde konfigurasie wat die volgende stelselopdatering stil kan breek.

Kies volgens wat die poort kan bied

Die besluit vernou sodra jy twee dinge weet: watter toestelle op of ná API 31 bekendgestel is, en of die poort ’n IKEv2-diens met dieselfde inskrywingsmodel kan bied. As die poort dit kan, migreer en stop om in die legacy-profiel te belê. As dit nog nie kan nie, hou IKEv1 vir die toestelle wat dit nog begin, en gee nuwe toestelle ’n derdeparty-kliënt as ’n gedokumenteerde, tydgebonde uitsondering eerder as ’n onuitgesproke omweg.

Twee punte maak die plan verdedigbaar. Eerstens, teken die rede vir elke uitsondering aan saam met die model en bekendstellingsvlak, sodat ’n ouditeur kan sien dat die grens ’n platformwag is eerder as ’n onverklaarde voorkeur. Tweedens, behandel die migrasie as beplande werk: IKEv1 is deur die standaardtrajek afgeskryf (RFC 9395), wat beteken die oorblywende toestelle sal aanhou krimp en die uitsonderings behoort saam met hulle te verstryk.