Android 12 і IKEv1 VPN: версія запуску, IKEv2 і староннія праграмы

Два тэлефоны абодва паказваюць Android 12 у Наладах, але толькі адзін з іх яшчэ запускае стары профіль IPsec XAuth, які прапануе ваш шлюз. Розніца не ў наладзе, да якой можа дабрацца карыстальнік: ахова, якая кіруе натыўным шляхам IKEv1, глядзіць на ўзровень SDK, з якім прылада была пастаўлена, а не толькі на версію, якая працуе цяпер. Гэтая адна дэталь вырашае, ці мае сэнс параўнанне парку, і яна ж вырашае, які з трох шляхоў міграцыі вам сапраўды патрэбны.

Два тэлефоны Android 12 — не адзін і той жа тэставы выпадак

Змена ў AOSP, якая забараніла новым прыладам запускаць старыя профілі IKEv1, параўноўвае DEVICE_INITIAL_SDK_INT з Android S, гэта значыць API 31. У натыўным шляху запуску адпаведны профіль выдае памылку непадтрыманай аперацыі яшчэ да таго, як з’явіцца хоць якое карыснае злучэнне. Тэлефон, пастаўлены з Android 11 і потым абноўлены, усё яшчэ праходзіць гэтую ахову; мадэль, якая выйшла з Android 12, не праходзіць.

Вы можаце прачытаць два лікі на прыладзе з уключанай адладкай:

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

Першае значэнне — гэта ўзровень запуску, які цікавіць ахову, другое — тое, што тэлефон выконвае сёння. Калі ўласцівасць адсутнічае, абапірайцеся на дакументацыю падтрымкі мадэлі, а не на здагадку з маркетынгавай назвы, і не мяркуйце, што зборка вытворцы захоўвае ўсе шляхі сумяшчальнасці базавай версіі.

Яшчэ адно адрозненне зэканоміць гадзіну марна выдаткаванага часу падтрымкі: захаваны профіль, які ўсё яшчэ ёсць у наладах VPN, нічога не даказвае пра тое, ці запусціць яго платформа. Паўторны ўвод PSK або змена маршрутаў не могуць прыбраць праверку падтрымкі пратакола, якая выконваецца раней, і збой выглядае як праблема з уліковымі данымі, хоць ёю не з’яўляецца.

Шлях першы: пакінуць натыўны стек там, дзе ён яшчэ працуе

Стары стек — гэта той, што чытае профілі IPsec XAuth PSK, IPsec Hybrid RSA і L2TP/IPsec PSK з сістэмнага экрана VPN. На прыладзе, пастаўленай ніжэй за API 31, ён застаецца працаздольным шляхам пасля абнаўлення, таму пілот на старэйшым апараце можа ўдацца, а новы апарат не запускае той жа профіль.

Важнае параўнанне — па класе прылад, а не па версіі Android: пералічыце мадэлі ў парку, прачытайце іх узроўні API запуску і падзяліце на прылады, якія яшчэ запускаюць профіль, і тыя, што не могуць. Любое іншае дае палітыку падтрымкі, якая супярэчыць сабе ў момант, калі карыстальнік купляе новы тэлефон.

Шлях другі: платформенныя профілі IKEv2

Публічная мадэль прадастаўлення Android для IKEv2 — гэта іншы аб’ект, а не перайменаваны профіль IKEv1. API платформы для профіляў IKEv2 з’явіўся з API 30 і чакае IKEv2 з метадам аўтэнтыфікацыі, які прапануе шлюз, звычайна на аснове сертыфікатаў або EAP. Сумяшчальнага па дроце абнаўлення з IKEv1 XAuth або Hybrid на IKEv2 няма: шлюз трэба наладзіць на новы пратакол, а профіль павінен несці адпаведную ідэнтычнасць.

Гэта шлях з самым доўгім жыццём, і менавіта ён выкрывае сапраўдную працу. Праверка ідэнтычнасці, аўтэнтыфікацыя карыстальніка, DNS, маршруты split-tunnel і аўтарызацыя рэсурсаў — усё павінна перажыць міграцыю; калі ўдаецца толькі рукапоціск, карыстальнікі застаюцца ў тунелі, які нікуды не даходзіць.

Разгортванне звычайна ідзе праз MDM або кіраваную канфігурацыю, а не праз увод палёў карыстальнікам. Калі такой інфраструктуры яшчэ няма, план міграцыі павінен яе ўключыць, бо паўторны ўвод профілю IKEv2 уручную на кожнай прыладзе — не тая аперацыя, якую можа вытрымаць служба падтрымкі.

Шлях трэці: старонняя кліенцкая праграма

Некаторыя VPN-праграмы пастаўляюць уласную рэалізацыю пратакола і зусім не залежаць ад натыўнага стэка. Гэта робіць іх законным часовым рашэннем для парку, які не можа хутка міграваць, але пытанне сумяшчальнасці пераходзіць да праграмы: ці рэалізуе яна менавіта той рэжым IKEv1, на якім размаўляе ваш шлюз, з той аўтэнтыфікацыяй і тымі наборамі шыфраў, якія патрабуе шлюз.

Лічыце ўласную матрыцу падтрымкі праграмы аўтарытэтам, а не апісанне ў краме, і праверце адну рэальную прыладу супраць рэальнага шлюза, перш чым рэкамендаваць яе. Ратаванне тэлефона, каб вярнуць выдалены шлях платформы, таксама не падтрымліванае рашэнне; яно пераносіць праблему ў непадтрыманую канфігурацыю, якую наступнае абнаўленне сістэмы можа ціха зламаць.

Выбірайце па тым, што можа прапанаваць шлюз

Рашэнне звужаецца, калі вы ведаеце дзве рэчы: якія прылады выйшлі на API 31 або пазней і ці можа шлюз прапанаваць службу IKEv2 з той жа мадэллю рэгістрацыі. Калі можа, мігруйце і спыніце ўкладаць у стары профіль. Калі яшчэ не, пакіньце IKEv1 для прылад, якія яго яшчэ запускаюць, і дайце новым прыладам старонні кліент як дакументаваны, абмежаваны ў часе вынятак, а не неабвешчаны абыход.

Дзве рэчы робяць план абараняльным. Па-першае, запішыце прычыну кожнага вынятку разам з мадэллю і ўзроўнем запуску, каб аўдытар бачыў, што мяжа — гэта ахова платформы, а не нерастлумачаная перавага. Па-другое, стаўцеся да міграцыі як да планаванай працы: IKEv1 састарэў у трэку стандартаў (RFC 9395), а значыць, прылад, што засталіся, будзе ўсё менш, і выняткі павінны скончыцца разам з імі.