SSID-ზე დაფუძნებულმა firewall-ის წესმა Wi-Fi-ის შეცვლის შემდეგ ფილტრაცია შეწყვიტა
SSID-ზე მიბმული firewall ღიად ვარდება, როცა Android უცნობ ქსელის სახელს აბრუნებს. გაყავით იდენტობა აღსრულებისგან და მიეცით უცნობ მდგომარეობას საკუთარი პოლიტიკა.
წესი მარტივი იყო: ტრაფიკი მხოლოდ მაშინ გაფილტრე, სანამ ტელეფონი ოფისის Wi-Fi-ზეა დაკავშირებული. თვეების განმავლობაში მუშაობდა, შემდეგ ერთ დილას ტელეფონი იმავე SSID-ზე იჯდა იმავე გასაღების ხატულათ და ფილტრაცია შეწყვეტილი იყო. ქსელში არაფერი შეცვლილა; შეიცვალა ის, ხედავს თუ არა აპი ქსელის სახელს. Android-ში „რომელ Wi-Fi-ზე ვარ“ და „დაბლოკე ეს ტრაფიკი“ ორი ცალკე საქმეა და firewall, რომელიც მათ ურევს, ღიად ვარდება ზუსტად მაშინ, როცა სახელი მიუწვდომელი ხდება.
სიმპტომი: იდენტობა ქრება და პოლიტიკა მიჰყვება
SSID-ის წესი კითხულობს მნიშვნელობას და შემდეგ ირჩევს ტოტს. როცა კითხვა სასარგებლოს არაფერს აბრუნებს, კოდმა რაღაც უნდა გააკეთოს და ჩვეული ნაგულისხმევია „ეს მოსალოდნელი ქსელი არ არის, ამიტომ ნუ გაფილტრავ“. ეს ნაგულისხმევი ნებართვის პრობლემას ტრაფიკის გაჟონვად აქცევს. გასაღების ხატულა ჩანს, რადგან VPN სერვისი ჯერ კიდევ მუშაობს; ის უბრალოდ სხვა ტოტს ასრულებს.
უყურეთ მოვლენების რიგითობას და არა ქსელს. უარყოფილი ნებართვის მოთხოვნა, სისტემის განახლება, რომელმაც SSID-ზე წვდომა სხვა ნებართვის უკან გადაიტანა, გამორთული ლოკაციის სერვისები ან სამუშაო პროფილის პოლიტიკის ცვლილება, ყველა მათგანს შეუძლია იგივე შედეგი მოგვცეს, სანამ ტელეფონი იმავე წვდომის წერტილზე რჩება.
რატომ შეიძლება სახელი უცნობად დაბრუნდეს
WifiInfo.getSSID() აბრუნებს მიმდინარე ქსელის სერვისების ნაკრების იდენტიფიკატორს და Android ადასტურებს, რომ ლოკაციაზე მგრძნობიარე ველებზე წვდომა ნებართვაზეა დამოკიდებული. როცა წვდომა არ არის, გამოძახება აბრუნებს UNKNOWN_SSID-ს ხმამაღლა ჩავარდნის ნაცვლად. ამიტომ ცარიელი ან უცნობი მნიშვნელობა არ არის მტკიცებულება, რომ ტელეფონმა Wi-Fi დატოვა; ეს არის მტკიცებულება, რომ აპი ქსელს ვერ აკლასიფიცირებს.
ორი შემოწმება ჰყოფს შემთხვევებს. დაადასტურეთ, რომ ტელეფონი დაკავშირებულია და ნახეთ, რას იუწყება სისტემა, შემდეგ დაადასტურეთ, რომ აპს ნამდვილად აქვს ის ნებართვა, რომელიც ამ Android გამოშვებაზე სჭირდება:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"თუ სტატუსის ხაზი დაკავშირებულ ქსელს აჩვენებს, სანამ აპი უცნობ სახელს ხედავს, თქვენ გაქვთ ნებართვის ან API დონის პრობლემა და არა Wi-Fi პრობლემა. გამოასწორეთ ის firewall-ის წესებზე შეხებამდე, რადგან ყოველი შემდგომი წესი ფასდება იმ მნიშვნელობის მიმართ, რომელსაც აპი ვერ კითხულობს.
სად მუშაობს ფილტრაცია სინამდვილეში
Android-ის ლოკალური firewall ჩვეულებრივ იყენებს VpnService მოდელს ტრაფიკის დისტანციურ სერვერზე გაუგზავნელად: იღებს ვირტუალურ ინტერფეისს, იყენებს საკუთარ წესებს და გადასცემს იმას, რასაც უშვებს. პლატფორმა ერთ აქტიურ VPN სერვისს უშვებს მომხმარებლის პროფილზე და მეორე პირველს ცვლის, ნაცვლად იმისა, რომ მასზე შრეებად დაჯდეს. ამიტომ ცალკე firewall აპი და ცალკე სამუშაო VPN ორსაფეხურ ჯაჭვს არ ქმნიან; ერთი მათგანი იმარჯვებს.
ეს მნიშვნელოვანია SSID-ის წესისთვის, რადგან აღსრულების წერტილი და დაკვირვების წერტილი სხვადასხვა კომპონენტია. VpnService წყვეტს, რა ტოვებს მოწყობილობას; Wi-Fi API მხოლოდ იარლიყს იძლევა. აპს შეუძლია სწორად აღასრულოს და არასწორად დააკლასიფიციროს და სწორედ ეს არის ამ სტატიის ჩავარდნა.
მიეცით უცნობს საკუთარი პოლიტიკა
განიხილეთ ქსელის იდენტობა როგორც სამი მდგომარეობა და ჩაწერეთ თითოეულის პოლიტიკა წესის გამოშვებამდე. მესამე მდგომარეობაა ის, რომელიც წავიწყდება და სწორედ მასში ჩაგაყენებთ თავდამსხმელი ან არასწორი კონფიგურაცია.
| Observation | Policy to specify |
|---|---|
| Expected SSID is readable | The explicit filtering policy you designed |
| A different SSID is readable | The default policy for untrusted networks |
| Unknown, changing or unreadable | Fail closed until classification is reliable |
დახურულად ჩავარდნა ნიშნავს, რომ უცნობი მდგომარეობა მემკვიდრეობით იღებს ყველაზე მკაცრ გონივრულ პოლიტიკას და არა ყველაზე მოხერხებულს. თუ ამის გამო ტელეფონი ახალ ქსელში უსარგებლო ხდება, სწორი გამოსავალი განზრახ და თვალსაჩინო გამონაკლისია და არა ცარიელი მნიშვნელობის შემოწმებაში დამალული ჩუმი ნდობის გადაწყვეტილება.
ნაცნობი SSID იარლიყია და არა ქსელის ოპერატორის მტკიცებულება. ნებისმიერს შეუძლია ოფისის სახელით წვდომის წერტილი გაუშვას, ამიტომ სახელის დამთხვევა არასოდეს უნდა იყოს ერთადერთი, რაც მგრძნობიარე სესიასა და არასანდო სეგმენტს შორის დგას.
გამოსცადეთ გადასვლები და არა მდგრადი მდგომარეობა
მდგრადი მდგომარეობის ტესტები გადის იმ ქსელში, სადაც წესი ააგეთ. ჩავარდნები გადასვლებში ცხოვრობს: უარყოფილი ნებართვა, Wi-Fi-იდან მობილურ ქსელზე, ერთი SSID-იდან მეორეზე, გადატვირთული VPN სერვისი და სხვა VPN აპი, რომელიც ინტერფეისს იკავებს. თითოეულისთვის გადაწყვიტეთ, გადაისინჯება თუ არა არსებული კავშირები და რჩება თუ არა დაცული ტრაფიკი დაბლოკილი, სანამ მდგომარეობა უცნობია.
დაწერეთ შედეგი სამი წინადადებით: დაკვირვებული პირობა, გადაწყვეტილების აღმასრულებელი კომპონენტი და განზრახ სარეზერვო ქცევა. თუ სამიდან რომელიმე აკლია, წესი ჯერ პოლიტიკა არ არის; ეს ვარაუდია, რომელიც ოფისის ქსელში შემთხვევით მუშაობს.