Android 12 ja IKEv1 VPN: toimitusversio, IKEv2 ja kolmannen osapuolen sovellukset

Kaksi puhelinta näyttää molemmat Asetuksissa Android 12, ja vain toinen niistä käynnistää vielä vanhan IPsec XAuth -profiilin, jota yhdyskäytäväsi tarjoaa. Ero ei ole asetus, johon käyttäjä pääsisi: natiivin IKEv1-polutusta valvova vartija katsoo SDK-tasoa, jolla laite toimitettiin, ei vain versiota, joka siinä nyt pyörii. Tämä yksi yksityiskohta ratkaisee, onko laitekannan vertailussa mieltä, ja ratkaisee myös, minkä kolmesta migraatiopolusta todella tarvitset.

Kaksi Android 12 -puhelinta ei ole sama testitapaus

AOSP-muutos, joka esti uusia laitteita käynnistämästä vanhoja IKEv1-profiileja, vertaa DEVICE_INITIAL_SDK_INT Android S:ään eli API 31:een. Natiivilla käynnistyspolulla kelvollinen profiili aiheuttaa ei-tuetun toiminnon virheen ennen kuin mitään hyödyllistä yhteyttä on. Puhelin, joka toimitettiin Android 11:llä ja päivitettiin myöhemmin, läpäisee vartijan edelleen; malli, joka julkaistiin Android 12:lla, ei.

Voit lukea kaksi lukua laitteelta, jossa virheenjäljitys on käytössä:

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

Ensimmäinen arvo on toimituksen käynnistystaso, josta vartija välittää, toinen on se, mitä puhelin suorittaa tänään. Kun ominaisuus puuttuu, nojaa mallin tukidokumentaatioon äläkä arvaa markkinointinimestä, äläkä oleta, että valmistajan build säilyttää kaikki perusversion yhteensopivuuspolut.

Vielä yksi erottelu säästää tunnin hukattua tukiaikaa: VPN-asetuksissa yhä listattu tallennettu profiili ei todista mitään siitä, käynnistääkö alusta sen. PSK:n uudelleen syöttäminen tai reittien muokkaaminen ei voi poistaa aiemmin suoritettavaa protokollatuen tarkistusta, ja vika näyttää tunnistetieto-ongelmalta, vaikka ei ole.

Polku yksi: pidä natiivipino siellä, missä se vielä toimii

Vanha pino on se, joka lukee IPsec XAuth PSK-, IPsec Hybrid RSA- ja L2TP/IPsec PSK -profiilit järjestelmän VPN-näytöltä. Alle API 31:n toimitetussa laitteessa se pysyy päivityksen jälkeen käyttökelpoisena polkuna, siksi vanhemmalla puhelimella tehty kokeilu voi onnistua, kun uusi puhelin ei käynnistä samaa profiilia.

Merkitsevä vertailu tehdään laiteluokittain, ei Android-version mukaan: luettele laitekannan mallit, lue niiden toimitus-API-tasot ja jaa ne laitteisiin, jotka yhä käynnistävät profiilin, ja niihin, jotka eivät voi. Mikä tahansa muu tuottaa tukikäytännön, joka on itsensä kanssa ristiriidassa heti, kun käyttäjä ostaa uuden puhelimen.

Polku kaksi: alustan IKEv2-profiilit

Androidin julkinen IKEv2-provisionointimalli on eri objekti, ei uudelleennimetty IKEv1-profiili. IKEv2-profiilien alusta-API tuli API 30:n mukana ja odottaa IKEv2:ta yhdyskäytävän tarjoamalla todennusmenetelmällä, yleensä sertifikaattipohjaisella tai EAP:lla. Johdinyhteensopivaa päivitystä IKEv1 XAuthista tai Hybridistä IKEv2:een ei ole: yhdyskäytävä on konfiguroitava uudelle protokollalle ja profiilin on kannettava vastaava identiteetti.

Se on pisimmän elämän polku ja myös se, joka paljastaa todellisen työn. Identiteetin validointi, käyttäjän todennus, DNS, jaetun tunnelin reitit ja resurssien valtuutus kaikkien on selvittävä migraatiosta; vain kättelyn onnistuminen jättää käyttäjät tunnelissa, joka ei saavuta mitään.

Käyttöönotto kulkee yleensä MDM:n tai hallitun konfiguraation kautta sen sijaan, että käyttäjä kirjoittaisi kenttiä. Jos sitä infrastruktuuria ei vielä ole, migraatiosuunnitelman on sisällettävä se, koska IKEv2-profiilin syöttäminen käsin joka laitteeseen ei ole toimenpide, jonka tukipalvelu pystyy nielemään.

Polku kolme: kolmannen osapuolen asiakassovellus

Jotkin VPN-sovellukset tuovat oman protokollatoteutuksensa eivätkä riipu natiivipinosta lainkaan. Tämä tekee niistä laillisen väliaikaisratkaisun laitekannalle, joka ei voi migratoitua nopeasti, mutta yhteensopivuuskysymys siirtyy sovellukseen: toteuttaako se täsmälleen sen IKEv1-tilan, jota yhdyskäytäväsi puhuu, yhdyskäytävän vaatimalla todennuksella ja salauspaketeilla.

Ota sovelluksen oma tukimatriisi auktoriteetiksi, ei kaupan kuvausta, ja testaa yksi todellinen laite todellista yhdyskäytävää vastaan ennen sen suosittelemista. Puhelimen roottaaminen poistetun alustapolun palauttamiseksi ei ole ylläpidetty ratkaisu sekään; se siirtää ongelman tukemattomaan konfiguraatioon, jonka seuraava järjestelmäpäivitys voi rikkoa hiljaa.

Valitse sen mukaan, mitä yhdyskäytävä voi tarjota

Päätös kaventuu, kun tiedät kaksi asiaa: mitkä laitteet julkaistiin API 31:llä tai myöhemmin, ja voiko yhdyskäytävä tarjota IKEv2-palvelun samalla rekisteröintimallilla. Jos voi, migraa ja lopeta vanhaan profiiliin investoiminen. Jos ei vielä voi, pidä IKEv1 laitteille, jotka sen yhä käynnistävät, ja anna uusille laitteille kolmannen osapuolen asiakas dokumentoituna, aikarajattuna poikkeuksena, ei lausumattomana kiertotienä.

Kaksi seikkaa tekevät suunnitelmasta puolustettavan. Ensinnäkin, kirjaa jokaisen poikkeuksen syy mallin ja toimituskäynnistystason kanssa, jotta auditoija näkee, että raja on alustan vartija eikä selittämätön mieltymys. Toiseksi, kohtele migraatiota suunniteltuna työnä: IKEv1 on vanhentunut standardipolulla (RFC 9395), mikä tarkoittaa, että jäljellä olevat laitteet vähenevät edelleen ja poikkeusten pitäisi päättyä niiden mukana.