Android აპი VPN-ზე მუშაობას უარყოფს: რომელი ფენა წყვეტს

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

ნაბიჯი 1: გაარკვიეთ, როდის უარყოფს აპი

დრო პირველი გამმიჯნავია. გაასუფთავეთ ჟურნალის ბუფერი, გაამეორეთ ჩავარდნა და ნახეთ რა გააკეთა აპმა სანამ იჩივლებდა:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

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

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

ნაბიჯი 2: წაიკითხეთ თავად ტელეფონის ხედვა ქსელზე

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

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

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

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

ნაბიჯი 3: წაიკითხეთ რას ხედავს სერვერი სინამდვილეში

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

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

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

ნაბიჯი 4: შეუსაბამეთ მტკიცებულებები სამი განაჩენიდან ერთს

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

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

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

ნაბიჯი 5: აირჩიეთ მხარდაჭერილი გზა და გადაამოწმეთ ის

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

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

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