Android 12 a IKEv1 VPN: verze při uvedení, IKEv2 a aplikace třetích stran

Dva telefony oba hlásí v Nastavení Android 12, ale jen jeden z nich ještě spouští starý profil IPsec XAuth, který vaše brána nabízí. Rozdíl není nastavení, ke kterému by se uživatel dostal: stráž, která řídí nativní cestu IKEv1, hledí na úroveň SDK, se kterou bylo zařízení dodáno, ne jen na verzi, která běží teď. Ten jediný detail rozhoduje, zda má srovnání flotily smysl, a také rozhoduje, kterou ze tří migračních cest vlastně potřebujete.

Dva telefony s Androidem 12 nejsou stejný testovací případ

Změna v AOSP, která zabránila novým zařízením spouštět staré profily IKEv1, porovnává DEVICE_INITIAL_SDK_INT s Android S, tedy API 31. V nativní spouštěcí cestě vyvolá vyhovující profil chybu nepodporované operace dřív, než existuje jakékoli užitečné spojení. Telefon dodaný s Android 11 a později aktualizovaný touto stráží stále projde; model uvedený s Android 12 ne.

Dvě čísla si přečtete na zařízení s povoleným laděním:

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

První hodnota je úroveň uvedení, na kterou stráž hledí, druhá je to, co telefon provozuje dnes. Kde vlastnost chybí, opřete se o dokumentaci podpory modelu místo hádání z marketingového názvu a nepředpokládejte, že build výrobce zachovává všechny cesty kompatibility základní verze.

Ještě jedno rozlišení ušetří hodinu ztraceného času podpory: uložený profil, který je stále v seznamu nastavení VPN, nic nedokazuje o tom, zda jej platforma spustí. Opětovné zadání PSK nebo úprava tras nemůže odstranit kontrolu podpory protokolu, která běží dřív, a selhání vypadá jako problém s přihlašovacími údaji, i když jím není.

Cesta jedna: ponechat nativní sadu tam, kde ještě běží

Starší sada je ta, která čte profily IPsec XAuth PSK, IPsec Hybrid RSA a L2TP/IPsec PSK ze systémové obrazovky VPN. Na zařízení dodaném pod API 31 zůstává životaschopnou cestou i po aktualizaci, proto pilot na starším přístroji může uspět, zatímco nový přístroj stejný profil nespustí.

Srovnání, na kterém záleží, je podle třídy zařízení, ne podle verze Androidu: vypište modely ve flotile, přečtěte jejich úrovně API při uvedení a rozdělte je na zařízení, která profil ještě spouští, a ta, která nemohou. Cokoli jiného vytvoří politiku podpory, která si odporuje ve chvíli, kdy si uživatel koupí nový telefon.

Cesta dvě: platformní profily IKEv2

Veřejný model zřizování Androidu pro IKEv2 je jiný objekt, ne přejmenovaný profil IKEv1. Platformní API pro profily IKEv2 přišlo s API 30 a očekává IKEv2 s metodou ověření, kterou brána nabízí, obvykle na bázi certifikátu nebo EAP. Neexistuje drátově kompatibilní upgrade z IKEv1 XAuth nebo Hybrid na IKEv2: brána musí být nakonfigurována pro nový protokol a profil musí nést odpovídající identitu.

To je cesta s nejdelším životem a také ta, která odhalí skutečnou práci. Ověření identity, autentizace uživatele, DNS, trasy rozděleného tunelu a autorizace prostředků musí migraci přežít; úspěšný pouhý handshake nechá uživatele připojené k tunelu, který nikam nedosáhne.

Nasazení obvykle jde přes MDM nebo spravovanou konfiguraci, místo aby uživatel vypisoval pole. Pokud tato infrastruktura ještě neexistuje, plán migrace ji musí zahrnout, protože znovu zadávat profil IKEv2 ručně na každém zařízení není operace, kterou helpdesk absorbuje.

Cesta tři: klientská aplikace třetí strany

Některé VPN aplikace dodávají vlastní implementaci protokolu a na nativní sadě vůbec nezávisí. To z nich dělá legitimní dočasné řešení pro flotilu, která nemůže rychle migrovat, ale otázka kompatibility se přesouvá na aplikaci: zda implementuje přesně ten režim IKEv1, kterým mluví vaše brána, s autentizací a šifrovacími sadami, které brána vyžaduje.

Berte vlastní matici podpory aplikace jako autoritu, ne popis v obchodě, a před doporučením otestujte jedno skutečné zařízení proti skutečné bráně. Rootování telefonu kvůli obnovení odstraněné platformní cesty také není udržované řešení; přesouvá problém do nepodporované konfigurace, kterou příští systémová aktualizace může tiše rozbít.

Vyberte podle toho, co brána může nabídnout

Rozhodnutí se zúží, jakmile víte dvě věci: která zařízení byla uvedena na API 31 nebo později a zda brána může nabídnout službu IKEv2 se stejným modelem registrace. Pokud může, migrujte a přestaňte investovat do starého profilu. Pokud ještě nemůže, ponechte IKEv1 pro zařízení, která jej ještě spouští, a novým zařízením dejte klienta třetí strany jako dokumentovanou, časově omezenou výjimku, ne jako nevyslovený obchvat.

Dvě věci dělají plán obhajitelným. Za prvé, zaznamenejte důvod každé výjimky s modelem a úrovní uvedení, aby auditor viděl, že hranice je platformní stráž, ne nevysvětlená preference. Za druhé, berte migraci jako plánovanou práci: IKEv1 je na standardní dráze zastaralý (RFC 9395), což znamená, že zbývající zařízení budou dál ubývat a výjimky by s nimi měly vypršet.