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-ის ხელახლა შეყვანა ან მარშრუტების რედაქტირება ვერ მოხსნის ადრე მოქმედ პროტოკოლის მხარდაჭერის შემოწმებას, და ჩავარდნა სერტიფიკატის პრობლემას ჰგავს, როცა ასე არ არის.

გზა პირველი: ნატიური სტეკის შენარჩუნება იქ, სადაც ჯერ კიდევ მუშაობს

ძველი სტეკი არის ის, რომელიც სისტემის VPN ეკრანიდან კითხულობს IPsec XAuth PSK, IPsec Hybrid RSA და L2TP/IPsec PSK პროფილებს. API 31-ზე დაბლა მიწოდებულ მოწყობილობაზე ის განახლების შემდეგაც რჩება სამუშაო გზად, ამიტომ ძველ ტელეფონზე ცდა შეიძლება წარმატებული იყოს, მაშინ როცა ახალი ტელეფონი იმავე პროფილს არ უშვებს.

მნიშვნელოვანი შედარება მოწყობილობის კლასის მიხედვითაა, არა Android ვერსიის მიხედვით: ჩამოთვალეთ ფლოტის მოდელები, წაიკითხეთ მათი გაშვების API დონეები და დაყავით ისინი მოწყობილობებად, რომლებიც ჯერ კიდევ უშვებენ პროფილს, და მათ, ვინც ვერ უშვებს. ნებისმიერი სხვა მიდგომა ქმნის მხარდაჭერის პოლიტიკას, რომელიც ეწინააღმდეგება საკუთარ თავს იმ მომენტში, როცა მომხმარებელი ახალ ტელეფონს ყიდულობს.

გზა მეორე: პლატფორმის IKEv2 პროფილები

Android-ის საჯარო მიწოდების მოდელი IKEv2-ისთვის სხვა ობიექტია, და არა გადარქმეული IKEv1 პროფილი. პლატფორმის API IKEv2 პროფილებისთვის API 30-თან ერთად მოვიდა და მოელის IKEv2-ს კარიბჭის მიერ შემოთავაზებული იდენტიფიკაციის მეთოდით, ჩვეულებრივ სერტიფიკატზე დაფუძნებული ან EAP. არ არსებობს მავთულით თავსებადი განახლება IKEv1 XAuth-იდან ან Hybrid-იდან IKEv2-ზე: კარიბჭე უნდა დაკონფიგურირდეს ახალი პროტოკოლისთვის, და პროფილმა უნდა ატაროს შესაბამისი იდენტობა.

ეს არის ყველაზე ხანგრძლივი სიცოცხლის გზა, და ასევე ის, რომელიც ამჟღავნებს ნამდვილ სამუშაოს. იდენტობის ვალიდაცია, მომხმარებლის ავთენტიფიკაცია, DNS, გაყოფილი გვირაბის მარშრუტები და რესურსების ავტორიზაცია ყველამ უნდა გადაიტანოს მიგრაცია; მხოლოდ ხელის ჩამორთმევის წარმატება ტოვებს მომხმარებლებს გვირაბში, რომელიც არსად აღწევს.

განლაგება ჩვეულებრივ გადის MDM-ის ან მართული კონფიგურაციის გავლით, და არა მომხმარებლის მიერ ველების აკრეფით. თუ ეს ინფრასტრუქტურა ჯერ არ არსებობს, მიგრაციის გეგმამ უნდა შეიცავდეს მას, რადგან IKEv2 პროფილის ხელით ხელახლა შეყვანა ყველა მოწყობილობაზე არ არის ოპერაცია, რომლის შთანთქმაც დახმარების სამსახურს შეუძლია.

გზა მესამე: მესამე მხარის კლიენტური აპი

ზოგიერთი VPN აპი მოაქვს საკუთარი პროტოკოლის იმპლემენტაცია და საერთოდ არ არის დამოკიდებული ნატიურ სტეკზე. ეს მათ ხდის ლეგიტიმურ დროებით გადაწყვეტად ფლოტისთვის, რომელსაც სწრაფად მიგრაცია არ შეუძლია, მაგრამ თავსებადობის კითხვა გადადის აპზე: ახორციელებს თუ არა ის ზუსტად იმ IKEv1 რეჟიმს, რომელზეც თქვენი კარიბჭე ლაპარაკობს, კარიბჭის მოთხოვნილი ავთენტიფიკაციითა და შიფრების ნაკრებებით.

აპის საკუთარი მხარდაჭერის მატრიცა მიიღეთ ავტორიტეტად და არა მაღაზიის აღწერა, და სანამ რეკომენდაციას გაუწევთ, გამოსცადეთ ერთი რეალური მოწყობილობა რეალური კარიბჭის წინააღმდეგ. ტელეფონის root-ად ქცევა წაშლილი პლატფორმის გზის აღსადგენად ასევე არ არის შენარჩუნებული გადაწყვეტა; ის პრობლემას გადააქვს არამხარდაჭერილ კონფიგურაციაში, რომელიც შემდეგმა სისტემურმა განახლებამ შეიძლება ჩუმად გატეხოს.

აირჩიეთ იმის მიხედვით, რისი შეთავაზებაც კარიბჭეს შეუძლია

გადაწყვეტილება ვიწროვდება, როცა იცით ორი რამ: რომელი მოწყობილობები გამოვიდა API 31-ზე ან შემდეგ, და შეუძლია თუ არა კარიბჭეს IKEv2 სერვისის შეთავაზება იმავე რეგისტრაციის მოდელით. თუ შეუძლია, მიგრაცია გააკეთეთ და შეწყვიტეთ ძველ პროფილში ინვესტიცია. თუ ჯერ არ შეუძლია, შეინარჩუნეთ IKEv1 იმ მოწყობილობებისთვის, რომლებიც ჯერ კიდევ უშვებენ მას, და ახალ მოწყობილობებს მიეცით მესამე მხარის კლიენტი როგორც დოკუმენტირებული, დროში შეზღუდული გამონაკლისი, და არა როგორც გაუცხადებელი შემოვლითი გზა.

ორი რამ ხდის გეგმას დასაცავად. პირველი, ჩაწერეთ ყოველი გამონაკლისის მიზეზი მოდელთან და მიწოდების დონესთან ერთად, რათა აუდიტორმა დაინახოს, რომ საზღვარი პლატფორმის დამცველია და არა აუხსნელი უპირატესობა. მეორე, მიგრაციას მოეპყარით როგორც დაგეგმილ სამუშაოს: IKEv1 მოძველებულია სტანდარტების გზაზე (RFC 9395), რაც ნიშნავს, რომ დარჩენილი მოწყობილობები განაგრძობენ შემცირებას და გამონაკლისებიც მათთან ერთად უნდა დასრულდეს.