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

ნაბიჯი 1: დაამტკიცეთ, რომელ ქსელშია აპი

წაიკითხეთ აპის საკუთარი ხედი და არა სტატუსის ზოლი. ConnectivityManager-დან მიიღეთ აქტიური ქსელი, მისი LinkProperties, DNS სერვერების სია და კერძო DNS-ის პარამეტრი. თუ სიაში VPN-ის გადამწყვეტია, აპს მისკენ გზა აქვს; თუ მასში Wi-Fi-ის გადამწყვეტია, გვირაბი ამ პროცესის ნაგულისხმევი ქსელი არ არის.

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

ნაბიჯი 2: მოითხოვეთ VPN ტრანსპორტი და მიაბით პროცესი

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

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

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

ნაბიჯი 3: შემოიფარგლეთ მიბმა მხოლოდ იმით, რასაც ეს სჭირდება

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

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

ნაბიჯი 4: ნუ ენდობით CONNECTED შეზღუდვას

WorkManager-ის NetworkType.CONNECTED ნიშნავს, რომ ქსელი დაკავშირებულია, და VPN ტრანსპორტი ამას აკმაყოფილებს მაშინაც, როცა ქვეშ მდებარე Wi-Fi ან ფიჭური კავშირი გაქრა. დავალება მუშაობს, ყოველი მოთხოვნა ჩავარდება, და ხელახლა ცდის პოლიტიკა მას ქარიშხალად აქცევს, რომელიც დაგეგმვის შეცდომას ჰგავს. გვირაბი ქსელია; შეზღუდვა არასოდეს ყოფილა ინტერნეტის შემოწმება.

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

ნაბიჯი 5: დააფიქსირეთ მტკიცებულებები და ხელახლა შეამოწმეთ დიაპაზონი

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

გაიმეორეთ ყველაზე ძველ Android ვერსიაზე, რომელსაც მხარს უჭერთ, და ერთ მიმდინარე გამოშვებაზე. გადამწყვეტის ის ქცევა, რომელიც ნაგულისხმევ გზას სწორად აჩვენებს, ზუსტად ის ადგილია, სადაც მოწყობილობები და ვერსიები განსხვავდებიან, და ნაშენი, რომელიც მხოლოდ უახლეს სატესტო მოწყობილობაზე გადის, არ არის დადასტურებული იმ დიაპაზონისთვის, რომელსაც აწვდით. adb shell dumpsys connectivity სწრაფი გზაა დაადასტუროთ, რომელ ქსელებსა და შესაძლებლობებს აცნობებს მოწყობილობა, სანამ ავარიას ამრავლებთ.

დაკავშირებული სტატიები