Android-ის IKEv2 VPN პროფილები მომხმარებლის მიხედვითაა, არა მოწყობილობის

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

რას აშენებს პლატფორმა თქვენთვის

Android 11-დან პლატფორმა VPN-ის შექმნას VpnManager-ის მეშვეობით ამჟღავნებს. დამტკიცებული აპი აღწერს IKEv2 პროფილს, და პლატფორმა თავად ასრულებს IPsec და IKE გაცვლას, ამიტომ აპი პაკეტებს არასოდეს ეხება. ეს არსებითი განსხვავებაა საკუთარი VPN აპისგან, რომელიც ახორციელებს VpnService-ს და გვირაბს საკუთარ პროცესში აშენებს.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

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

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

მფლობელი მომხმარებელია, შემდეგ პაკეტი

Android-ის მრავალმომხმარებლიანი რეჟიმი რეალური გამიჯვნაა, არა იარლიყი. სამუშაო პროფილი ცალკე მომხმარებელია თავისი დაყენებული პაკეტებით, აპების მონაცემებით, გასაღებების საცავით და ნდობის ღუზებით. იგივე პროდუქტი ორივე ადგილას ორი ეგზემპლარია სხვადასხვა მომხმარებლის იდენტიფიკატორით, მაშინაც კი როცა ხატულები და სახელები იდენტურია.

შექმნა რეგისტრირდება ამ მომხმარებლის გამომძახებელ პაკეტზე. ამიტომ პირად პროფილში მომუშავე შემქმნელი აპი პირად გვირაბს ქმნის, და სამუშაო პროფილის სამუშაო აპები მისგან არაფერს ხედავენ. პირიქითაც მართალია, ამიტომ სამუშაო პროფილის გვირაბი უხილავია პირადი აპებისთვის ცხადი პოლიტიკის გარეშე.

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

სამი კარიბჭე პაკეტის მოძრაობამდე

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

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

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

რატომ არ ფარავს პირადი კავშირი სამუშაო აპებს

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

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

შეამოწმეთ რეალურ რეგისტრაციაზე, არა ლაბორატორიულ ტელეფონზე

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

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

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

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