როგორ ჩავტვირთოთ VPN სერტიფიკატი Android-ზე და შევამოწმოთ გასაღები

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

ნაბიჯი 1: წაიკითხეთ P12, სანამ ის თქვენს მანქანას დატოვებს

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

PKCS#12 პაკეტი ჩვეულებრივ ატარებს კლიენტის სერტიფიკატს, მის პირად გასაღებს და გამომცემლის ჯაჭვს. openssl pkcs12 -in client.p12 -info -noout ბეჭდავს MAC-ს და დაშიფვრის ალგორითმებს გასაღების მასალის გამოტანის გარეშე, ასე რომ ხედავთ, დაცულია თუ არა პაკეტი პაროლით და რომელი შიფრით. შემდეგ გაუშვით keytool -list -v -keystore client.p12 -storetype PKCS12, რომ მიიღოთ ფსევდონიმი, SHA-256 ანაბეჭდი და ვალიდობის ფანჯარა, რომელსაც ტელეფონს შეადარებთ.

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

ნაბიჯი 2: დააინსტალირეთ იმ სლოტში, რომელსაც VPN აპი რეალურად კითხულობს

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

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

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

ნაბიჯი 3: დაამტკიცეთ, რომელი პროვაიდერი ფლობს გასაღებს

იმპორტი ადასტურებს ანალიზს და არა აპარატულ მხარდაჭერას. Android 12-დან KeyInfo.getSecurityLevel() აცხადებს, არის თუ არა გასაღები სანდო შესრულების გარემოში, StrongBox-ში თუ პროგრამულ უზრუნველყოფაში, და ის ცვლის ძველ isInsideSecureHardware() გამოძახებას. თუ VPN კლიენტი ამ მნიშვნელობას არ აჩვენებს, ნაბიჯ 1-ის ანაბეჭდი თქვენი შემცვლელია. იმპორტის დროს ხელახლა დაშიფრული სერტიფიკატი ბაიტობრივად არ დაემთხვევა, მაგრამ საჯარო გასაღები და სუბიექტი მაინც დაემთხვევა.

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

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

ნაბიჯი 4: გაარკვიეთ, ვის ეკუთვნის ეკრანის ბლოკირების მოთხოვნა

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

როცა მოწყობილობის ადმინისტრატორი ან მართული პროფილის პოლიტიკა ითხოვს ბლოკს, მოთხოვნა ეკუთვნის ამ პოლიტიკას და არა სერტიფიკატს. adb shell dumpsys device_policy ჩამოთვლის აქტიურ ადმინისტრატორებს და მათ მიერ დაწესებულ პაროლის ხარისხს, რაც ყველაზე სწრაფი გზაა იმის სანახავად, MDM აგენტია თქვენი PIN წესების შეცვლის მიზეზი თუ არა. სერტიფიკატის მოხსნა პოლიტიკას არ შეასუსტებს, ხოლო პოლიტიკის მოხსნა ადმინისტრაციული გადაწყვეტილებაა და არა პარამეტრის შესწორება.

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

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

ნაბიჯი 5: გააუქმეთ იდენტობა და გადაამოწმეთ უარი

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

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

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