Android VPN ექსპორტი: რა გადადის რეალურად ახალ ტელეფონზე

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

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

რას შეიცავს რეალურად ექსპორტირებული პროფილი

გახსენით ფაილი ტექსტურ რედაქტორში სანამ ენდობით. OpenVPN პროფილი პატარა კონფიგურაციის ენაა: remote, proto, data-ciphers, და ხშირად ჩაშენებული <ca>, <cert>, <key> ან <tls-crypt> ბლოკები, რომლებსაც კლიენტი თავის TLS სტეკს გადასცემს. WireGuard კონფიგურაცია უფრო ბრტყელია: [Interface] შეიცავს PrivateKey და Address, შემდეგ თითო [Peer] ყოველი ბოლო წერტილისთვის PublicKey, AllowedIPs და Endpoint-ით. IKEv2 მოდის როგორც .mobileconfig დატვირთვის ლექსიკონებით გასაღების ბლოკების ნაცვლად.

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

სად ცხოვრობს გასაღები რეალურად Android-ში

Android ინახავს აპის მონაცემებს /data/data/<package>-ის ქვეშ, რომელსაც მხოლოდ ამ აპის UID კითხულობს. root-ის გარეშე ტელეფონიდან სხვა აპის პირადი საქაღალდის კოპირების მხარდაჭერილი გზა არ არსებობს, და adb backup შეწყვიტა ზოგადი პასუხი იყოს მას შემდეგ, რაც Android 12-მა ის გააუქმა და კლიენტებმა allowBackup="false"-ის გამოცხადება დაიწყეს. ასე რომ, Android კლიენტიდან ექსპორტი ნიშნავს იმას, თუ რას ახორციელებს ეს კლიენტი, და არა ფაილური სისტემის ასლს.

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

ეს გატეხილი ექსპორტი არ არის. ეს ის თვისებაა, რაც პლატფორმას სთხოვეს.

რას ვერ გადაიტანს პროფილი

შეადარეთ ობიექტები იმას, რასაც დანიშნულება მიიღებს:

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

იმპორტი გარჩევაა, შემდეგ თანხმობის მოთხოვნა

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

შემდეგ მოდის ავტორიზაციის ნაბიჯი, რომელსაც ვერც ერთი ფაილი ვერ გამოტოვებს. Android მოითხოვს, რომ აპმა გამოიძახოს VpnService.prepare() და მიიღოს თქვენი თანხმობა სანამ გვირაბს შექმნის, ამიტომ ახლახან იმპორტირებული პროფილი მაინც ერთხელ აჩვენებს სისტემურ დიალოგს. შემდეგ გვირაბი ცხადად იგება addAddress, addRoute, addDnsServer და addAllowedApplication ან addDisallowedApplication-ის მეშვეობით თითო აპის მარშრუტიზაციისთვის. აქედან არც ერთი არ გამომდინარეობს ბოლო წერტილიდან, ამიტომ ერთი და იგივე პროფილი ორ კლიენტში სხვადასხვა ეფექტურ მარშრუტებს წარმოქმნის.

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

შეამოწმეთ ახალი მოწყობილობა სანამ ძველს პენსიაზე გაუშვებთ

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

ერთი შემოწმება წყვეტს გასასვლელ მისამართს. გახსენით https://ifconfig.me ტელეფონის ბრაუზერში, შემდეგ გაუშვით curl -s https://ifconfig.me ლეპტოპიდან იმავე Wi-Fi-ზე და შეადარეთ ორივე პასუხი იმ მისამართს, რომელიც თქვენმა პროვაიდერმა მოგანიჭათ.

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

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

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