Android 12 és IKEv1 VPN: szállítási verzió, IKEv2 és harmadik féltől származó alkalmazások

Két telefon is Android 12-t mutat a Beállításokban, és közülük csak az egyik indítja még el a régi IPsec XAuth profilt, amelyet az átjárója kínál. A különbség nem a felhasználó számára elérhető beállítás: a natív IKEv1 útvonalat vezérlő őr azzal az SDK-szinttel foglalkozik, amellyel az eszközt szállították, nem csak a most futó verzióval. Ez az egyetlen részlet dönti el, van-e értelme flotta-összehasonlításnak, és azt is eldönti, melyik három migrációs útvonalra van valóban szüksége.

Két Android 12-es telefon nem ugyanaz a teszteset

Az AOSP módosítása, amely megakadályozta, hogy az új eszközök régi IKEv1 profilokat indítsanak, a DEVICE_INITIAL_SDK_INT értéket az Android S-hez hasonlítja, azaz API 31-hez. A natív indítási útvonalon a megfelelő profil nem támogatott művelet hibát vált ki, mielőtt bármilyen hasznos kapcsolat létrejönne. Az Android 11-gyel szállított, majd frissített telefon még átmegy ezen az őrön; az Android 12-vel indult modell nem.

A két számot egy hibakereséssel rendelkező eszközön olvashatja ki:

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

Az első érték az a szállítási szint, amely az őrt érdekli, a második az, amit a telefon ma futtat. Ahol a tulajdonság hiányzik, a modell támogatási dokumentációjára támaszkodjon a marketingnév alapján való találgatás helyett, és ne feltételezze, hogy a gyártó buildje megőrzi az alapverzió összes kompatibilitási útvonalát.

Még egy megkülönböztetés megspórol egy óra elvesztegetett támogatási időt: a VPN-beállításokban még szereplő mentett profil semmit nem bizonyít arról, hogy a platform elindítja-e. A PSK újrabeírása vagy az útvonalak szerkesztése nem távolíthat el egy korábban futó protokolltámogatási ellenőrzést, és a hiba hitelesítőadat-problémának látszik, amikor nem az.

Első útvonal: tartsa meg a natív vermet ott, ahol még fut

A régi verem az, amely az IPsec XAuth PSK, IPsec Hybrid RSA és L2TP/IPsec PSK profilokat a rendszer VPN-képernyőjéről olvassa. Az API 31 alatt szállított eszközön frissítés után is járható útvonal marad, ezért sikerülhet egy próba egy régebbi készüléken, miközben egy új készülék nem indítja el ugyanazt a profilt.

A fontos összehasonlítás eszközosztály szerint történik, nem Android-verzió szerint: listázza a flotta modelljeit, olvassa ki a szállítási API-szintjeiket, és ossza őket azokra, amelyek még elindítják a profilt, és azokra, amelyek nem tudják. Bármi más olyan támogatási szabályzatot eredményez, amely abban a pillanatban ellentmond önmagának, amikor a felhasználó új telefont vásárol.

Második útvonal: a platform IKEv2-profiljai

Az Android nyilvános IKEv2-es provisioning modellje más objektum, nem átnevezett IKEv1 profil. Az IKEv2 profilok platform API-ja az API 30-cal érkezett, és az IKEv2-t az átjáró által kínált hitelesítési módszerrel várja, általában tanúsítványalapú vagy EAP. Nincs vezetékesen kompatibilis frissítés az IKEv1 XAuth vagy Hybrid felől az IKEv2-re: az átjárót az új protokollra kell konfigurálni, és a profilnak a megfelelő identitást kell hordoznia.

Ez a leghosszabb életű útvonal, és ez tárja fel az igazi munkát. Az identitás ellenőrzése, a felhasználói hitelesítés, a DNS, a megosztott alagút útvonalai és az erőforrás-engedélyezés mind át kell hogy éljék a migrációt; ha csak a kézfogás sikerül, a felhasználók olyan alagúthoz kapcsolódnak, amely semmit nem ér el.

A bevezetés általában MDM-en vagy felügyelt konfiguráción keresztül történik, nem úgy, hogy a felhasználó mezőket ír be. Ha ez az infrastruktúra még nem létezik, a migrációs tervnek tartalmaznia kell, mert az IKEv2 profil kézi újrabeírása minden eszközön nem olyan művelet, amelyet egy ügyfélszolgálat el tud viselni.

Harmadik útvonal: harmadik féltől származó kliensalkalmazás

Egyes VPN-alkalmazások saját protokoll-implementációt hoznak, és egyáltalán nem függnek a natív veremtől. Ez legitim ideiglenes megoldássá teszi őket egy olyan flotta számára, amely nem tud gyorsan migrálni, de a kompatibilitási kérdés az alkalmazásra száll: pontosan azt az IKEv1 módot valósítja-e meg, amelyet az átjárója beszél, az átjáró által megkövetelt hitelesítéssel és titkosítási csomagokkal.

Tekintse az alkalmazás saját támogatási mátrixát mérvadónak, ne az áruházi leírást, és teszteljen egy valódi eszközt a valódi átjáróval szemben, mielőtt ajánlaná. A telefon rootolása egy eltávolított platformútvonal helyreállításához szintén nem karbantartott megoldás; a problémát olyan nem támogatott konfigurációba helyezi, amelyet a következő rendszerfrissítés csendben eltörhet.

Aszerint válasszon, mit kínálhat az átjáró

A döntés szűkül, ha két dolgot tud: mely eszközök indultak API 31-gyel vagy később, és tud-e az átjáró IKEv2 szolgáltatást nyújtani ugyanazzal a regisztrációs modellel. Ha tud, migráljon, és hagyjon fel a régi profilba való befektetéssel. Ha még nem tud, tartsa meg az IKEv1-et azoknak az eszközöknek, amelyek még elindítják, és adjon az új eszközöknek harmadik féltől származó klienst dokumentált, időben korlátozott kivételként, nem kimondatlan kerülőútként.

Két dolog teszi védhetővé a tervet. Először is rögzítse minden kivétel okát a modell és a szállítási szint mellett, hogy egy auditor lássa: a határ platformőr, nem pedig megmagyarázatlan preferencia. Másodszor kezelje a migrációt tervezett munkaként: az IKEv1 elavult a szabványos útvonalon (RFC 9395), ami azt jelenti, hogy a megmaradó eszközök tovább csökkennek, és a kivételeknek velük együtt le kell járniuk.