Android 12 ба IKEv1 VPN: хувилбар, IKEv2, гуравдагч талын аппууд

Хоёр утас Тохиргоонд Android 12 гэж харуулдаг ч зөвхөн нэг нь таны гарцын санал болгодог хуучин IPsec XAuth профайлыг ажиллуулж байна. Ялгаа нь хэрэглэгч хүрч чадах тохиргоо биш: төрөлх хуучин IKEv1 замыг хамгаалдаг хамгаалалт нь төхөөрөмжийг борлуулсан SDK түвшинг хардаг, зөвхөн одоо ажиллаж буй хувилбарыг биш. Энэ ганц дэлгэрэнгүй зүйл нь флотын харьцуулалт утга учиртай эсэхийг шийддэг бөгөөд гурван шилжилтийн замаас аль нь танд үнэхээр хэрэгтэйг ч шийддэг.

Хоёр Android 12 утас нэг тестийн тохиолдол биш

Шинэ төхөөрөмжүүдийг хуучин IKEv1 профайл ажиллуулахаас зогсоосон AOSP-ийн өөрчлөлт нь 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

Эхний утга нь хамгаалалтад чухал эхлэлийн түвшин, хоёр дахь нь утас өнөөдөр ажиллуулж буй хувилбар юм. Проперт байхгүй газарт маркетингийн нэрнээс таамаглахын оронд загварын дэмжлэгийн баримт бичигт найдаж, борлуулагчийн build нь үндсэн хувилбарын бүх нийцлийн замыг хадгалдаг гэж бүү бодоорой.

Бас нэг ялгаа нь нэг цаг үрэгдсэн дэмжлэгийн цагийг хэмнэдэг: VPN тохиргоонд хараахан жагсаагдсан хадгалагдсан профайл нь платформ үүнийг эхлүүлэх эсэхийг юу ч нотолдоггүй. PSK-г дахин оруулах эсвэл маршрутыг засах нь эрт ажилладаг протоколын дэмжлэгийн шалгалтыг арилгаж чадахгүй бөгөөд алдаа нь бүртгэлийн мэдээллийн асуудал мэт харагддаг ч тийм биш юм.

Нэгдүгээр зам: төрөлх хуучин стекийг ажиллаж байгаа газарт нь үлдээх

Хуучин стек бол системийн VPN дэлгэцээс IPsec XAuth PSK, IPsec Hybrid RSA болон L2TP/IPsec PSK профайлуудыг уншдаг стек юм. API 31-ээс доош борлуулагдсан төхөөрөмжид шинэчлэлтийн дараа ч энэ нь боломжит зам хэвээр байдаг тул хуучин гар утсан дээрх туршилт амжилттай болж, шинэ утас ижил профайлыг няцаадаг.

Чухал харьцуулалт нь Android хувилбараар биш, төхөөрөмжийн ангилалаар хийгддэг: флот дахь загваруудыг жагсааж, тэдгээрийн эхлэлийн API түвшинг уншиж, профайлыг ажиллуулж чадах ба чадахгүй төхөөрөмжүүдэд хуваа. Бусад бүх зүйл хэрэглэгч шинэ утас авах тэр мөчид өөртэйгөө зөрчилдөх дэмжлэгийн бодлого үүсгэдэг.

Хоёрдугаар зам: платформын IKEv2 профайлууд

IKEv2-ийн Android-ын нийтийн provisioning загвар нь өөр объект, IKEv1 профайлын нэр солигдсон хувилбар биш. IKEv2 профайлын платформын API нь API 30-тай хамт ирсэн бөгөөд гарцын санал болгодог баталгаажуулах аргатай IKEv2-ыг хүлээж байдаг, ихэвчлэн сертификат эсвэл EAP. IKEv1 XAuth эсвэл Hybrid-аас IKEv2 руу утсаар нийцэх шинэчлэл байхгүй: гарц нь шинэ протоколд тохируулагдсан байх ёстой, профайл нь тохирох идентитийг агуулсан байх ёстой.

Энэ бол хамгийн урт насалсан зам бөгөөд жинхэнэ ажлыг илчилдэг зам юм. Идентитийн баталгаажуулалт, хэрэглэгчийн нэвтрүүлэлт, DNS, split-tunnel маршрут болон нөөцийн зөвшөөрөл бүгд шилжилтийг давах ёстой; зөвхөн handshake амжилттай болбол хэрэглэгчид юунд ч хүрэхгүй туннелд холбогдсон хэвээр үлддэг.

Байршуулалт нь ихэвчлэн хэрэглэгч талбар бичихээс илүү MDM эсвэл удирдлагатай тохиргоогоор явагддаг. Хэрэв тэр дэд бүтэц хараахан байхгүй бол шилжилтийн төлөвлөгөөнд үүнийг оруулах ёстой, учир нь IKEv2 профайлыг төхөөрөмж бүр дээр гараар дахин оруулах нь тусламжийн алба хүлээж авах боломжгүй үйлдэл юм.

Гуравдугаар зам: гуравдагч талын клиент апп

Зарим VPN апп өөрийн протоколын хэрэгжүүлэлтийг нийлүүлдэг бөгөөд төрөлх хуучин стекаас огт хамааралгүй. Энэ нь хурдан шилжиж чадахгүй флотын хувьд тэдгээрийг хууль ёсны түр шийдэл болгодог ч нийцлийн асуулт апп руу шилждэг: таны гарц ярьдаг яг IKEv1 горимыг гарцын шаарддаг баталгаажуулалт, шифрийн багцтай хэрэгжүүлж байгаа эсэх.

Дэлгүүрийн тайлбараас илүү аппын өөрийн дэмжлэгийн матрицыг эрх мэдэл гэж үзэж, санал болгохын өмнө нэг бодит төхөөрөмжийг бодит гарцтай туршиж үзээрэй. Хасагдсан платформын замыг сэргээхийн тулд утсыг root хийх нь ч арчилгаатай шийдэл биш; энэ нь асуудлыг дараагийн системийн шинэчлэлт чимээгүй эвдэж болох дэмжлэггүй тохиргоо руу шилжүүлдэг.

Гарц юу санал болгож чадахаар нь сонгоорой

Хоёр зүйлийг мэдсэний дараа шийдвэр нарийсдаг: ямар төхөөрөмжүүд API 31 эсвэл түүнээс хойш гарсан, мөн гарц ижил бүртгэлийн загвартай IKEv2 үйлчилгээг үзүүлж чадах эсэх. Чадах бол шилжиж, хуучин профайлд хөрөнгө оруулахаа зогсоо. Хараахан чадахгүй бол үүнийг ажиллуулж байгаа төхөөрөмжүүдэд IKEv1-ийг үлдээж, шинэ төхөөрөмжүүдэд гуравдагч талын клиентийг баримтжуулсан, хугацаатай үл хамаарах зүйл болгон өг, хэлээгүй арга хэмжээ биш.

Хоёр зүйл төлөвлөгөөг хамгаалах боломжтой болгодог. Нэгд, үл хамаарах зүйл бүрийн шалтгааныг загвар, эхлэлийн түвшинтэй хамт тэмдэглэ, ингэснээр аудитор хил нь тайлбарлаагүй сонголт биш платформын хамгаалалт гэдгийг харна. Хоёрт, шилжилтийг төлөвлөсөн ажил гэж үз: IKEv1 нь стандартын чиглэлээр хуучирсан (RFC 9395), энэ нь үлдсэн төхөөрөмжүүд улам цөөрч, үл хамаарах зүйлс тэдэнтэй хамт дуусах ёстой гэсэн үг.