რატომ ჯერ კიდევ აჩვენებს დაბლოკილი Android აპი ქსელურ მოხმარებას

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

მთვლელი ბაიტებს ზომავს და არა მიწოდებას

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

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

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

მიკუთვნება UID-ს მიჰყვება და არა ხატულას

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

როცა რიცხვები არასწორად გამოიყურება, შეადარეთ UID და არა ეტიკეტი. მოხმარების API UID-ით იკითხება და adb shell dumpsys package <package> | grep userId= ბეჭდავს იმ რიცხვს, რომელსაც უნდა შეადაროთ, ამიტომ ერთი და იმავე UID-ის ორი ჩანაწერი მთვლელის თვალსაზრისით ერთი იდენტობაა.

დროის ფანჯარა შეიძლება თქვენს წესზე ადრეული იყოს

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

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

შესაძლოა VPN სერვისი ის არ არის, რაც თქვენ დააყენეთ

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

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

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

გამოსცადეთ ერთი ახალი მოთხოვნა და ჩაწერეთ ოთხი ფაქტი

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

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