Android 12 a IKEv1 VPN: fersiwn lansio, IKEv2 ac apiau trydydd parti

Mae dau ffôn yn dangos Android 12 yn y Gosodiadau, ond dim ond un ohonynt sy’n dal i lansio’r hen broffil IPsec XAuth y mae eich porth yn ei gynnig. Nid gosodiad y gall y defnyddiwr ei gyrraedd yw’r gwahaniaeth: mae’r gwarchodwr sy’n rheoli’r llwybr IKEv1 brodorol yn edrych ar y lefel SDK y cafodd y ddyfais ei chludo â hi, nid yn unig ar y fersiwn sy’n rhedeg nawr. Mae’r un manylyn hwnnw yn penderfynu a yw cymhariaeth fflyd yn ystyrlon, ac mae hefyd yn penderfynu pa un o’r tair llwybr mudo sydd ei angen arnoch.

Nid yw dau ffôn Android 12 yr un achos prawf

Mae’r newid yn AOSP a ataliodd ddyfeisiau newydd rhag lansio hen broffiliau IKEv1 yn cymharu DEVICE_INITIAL_SDK_INT ag Android S, sef API 31. Ar y llwybr cychwyn brodorol, mae proffil cymwys yn codi methiant gweithrediad heb gefnogaeth cyn bod unrhyw gysylltiad defnyddiol yn bodoli. Mae ffôn a gludwyd gyda Android 11 ac a ddiweddarwyd wedyn yn dal i basio’r gwarchodwr hwnnw; nid yw model a lansiwyd gydag Android 12 yn pasio.

Gallwch ddarllen y ddau rif ar ddyfais gyda dadfygio wedi’i alluogi:

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

Y gwerth cyntaf yw’r lefel lansio y mae’r gwarchodwr yn poeni amdani, a’r ail yw’r hyn y mae’r ffôn yn ei redeg heddiw. Lle mae’r eiddo ar goll, dibynnwch ar ddogfennaeth cymorth y model yn hytrach na dyfalu o’r enw marchnata, ac na thybiwch fod adeiladwaith y gwneuthurwr yn cadw pob llwybr cydnawsedd o’r fersiwn sylfaen.

Mae un gwahaniaeth arall yn arbed awr o amser cymorth wedi’i wastraffu: nid yw proffil wedi’i gadw sydd dal ar y rhestr yng ngosodiadau VPN yn profi dim am a fydd y platfform yn ei lansio. Ni all ail’roi’r PSK na golygu llwybrau ddileu gwiriad cymorth protocol sy’n rhedeg yn gynharach, ac mae’r methiant yn edrych fel problem gredydu pan nad yw.

Llwybr un: cadw’r stôr brodorol lle mae’n dal i redeg

Yr hen stôr yw’r un sy’n darllen proffiliau IPsec XAuth PSK, IPsec Hybrid RSA a L2TP/IPsec PSK o sgrin VPN y system. Ar ddyfais a gludwyd o dan API 31 mae’n parhau’n llwybr hyfyw ar ôl uwchraddiad, a dyna pam y gall peilot ar hen set law lwyddo tra bo set law newydd yn methu’r un proffil.

Y gymhariaeth sy’n bwysig yw fesul dosbarth dyfais, nid fesul fersiwn Android: rhestrwch y modelau yn y fflyd, darllenwch eu lefelau API lansio, a’u rhannu’n ddyfeisiau sy’n dal i lansio’r proffil a rhai na allant. Mae unrhyw beth arall yn cynhyrchu polisi cymorth sy’n gwrthddweud ei hun yr eiliad y mae defnyddiwr yn prynu ffôn newydd.

Llwybr dau: proffiliau IKEv2 y platfform

Model darparu cyhoeddus Android ar gyfer IKEv2 yw gwrthrych gwahanol, nid proffil IKEv1 wedi’i ailenwi. Daeth API’r platfform ar gyfer proffiliau IKEv2 gydag API 30 ac mae’n disgwyl IKEv2 gyda’r dull dilysu y mae’r porth yn ei gynnig, fel arfer yn seiliedig ar dystysgrif neu EAP. Nid oes uwchraddiad cydnaws â gwifren o IKEv1 XAuth neu Hybrid i IKEv2: rhaid ffurfweddu’r porth ar gyfer y protocol newydd, a rhaid i’r proffil gario’r hunaniaeth gyfatebol.

Dyma’r llwybr hiraf ei oes, a hefyd yr un sy’n datgelu’r gwaith gwirioneddol. Rhaid i ddilysu hunaniaeth, dilysu defnyddiwr, DNS, llwybrau twnnel hollt ac awdurdodi adnoddau i gyd oroesi’r mudo; mae gwneud i’r ysgwyd llaw yn unig lwyddo yn gadael defnyddwyr wedi’u cysylltu â thwnnel nad yw’n cyrraedd unrhyw le.

Mae’r defnydd fel arfer yn mynd drwy MDM neu ffurfweddiad a reolir yn hytrach na bod y defnyddiwr yn teipio meysydd. Os nad yw’r seilwaith hwnnw’n bodoli eto, rhaid i’r cynllun mudo ei gynnwys, oherwydd nid yw ail’roi proffil IKEv2 â llaw ar bob dyfais yn weithrediad y gall desg gymorth ei amsugno.

Llwybr tri: cymhwysiad cleient trydydd parti

Mae rhai cymwysiadau VPN yn cludo eu gweithrediad protocol eu hunain ac nid ydynt yn dibynnu ar y stôr brodorol o gwbl. Mae hynny’n eu gwneud yn ateb dros dro dilys i fflyd na all fudo’n gyflym, ond mae’r cwestiwn cydnawsedd yn symud i’r ap: a yw’n gweithredu’r union fodd IKEv1 y mae eich porth yn ei siarad, gyda’r dilysu a’r setiau seiffr y mae’r porth yn eu gofyn.

Cymerwch fatrics cymorth yr ap ei hun fel yr awdurdod, nid disgrifiad y siop, a phrofwch un ddyfais wirioneddol yn erbyn y porth go iawn cyn ei argymell. Nid yw gwreiddio ffôn i adfer llwybr platfform a dynnwyd yn ateb a gynhelir chwaith; mae’n symud y broblem i ffurfweddiad heb gefnogaeth y gall y diweddariad system nesaf ei dorri’n dawel.

Dewiswch yn ôl yr hyn y gall y porth ei gynnig

Mae’r penderfyniad yn culhau unwaith y gwyddoch ddau beth: pa ddyfeisiau a lansiwyd ar API 31 neu wedyn, ac a all y porth gynnig gwasanaeth IKEv2 gyda’r un model cofrestru. Os gall, mudwch a rhowch y gorau i fuddsoddi yn yr hen broffil. Os na all eto, cadwch IKEv1 ar gyfer y dyfeisiau sy’n dal i’i lansio, a rhowch gleient trydydd parti i ddyfeisiau newydd fel eithriad wedi’i ddogfennu ac wedi’i gyfyngu mewn amser, nid fel cylchdaith heb ei datgan.

Mae dau beth yn gwneud y cynllun yn amddiffynadwy. Yn gyntaf, cofnodwch reswm pob eithriad gyda’r model a’r lefel lansio, fel y gall archwilydd weld mai gwarchodwr platfform yw’r ffin, nid hoffter heb ei esbonio. Yn ail, triniwch y mudo fel gwaith wedi’i gynllunio: mae IKEv1 wedi darfod ar y trywydd safonau (RFC 9395), sy’n golygu y bydd y dyfeisiau sy’n weddill yn parhau i leihau ac y dylai’r eithriadau ddod i ben gyda hwy.