SSID ugunsmūra noteikums pārstāja filtrēt pēc Wi-Fi maiņas
Ugunsmūris, kas balstīts uz SSID, atveras, kad Android atgriež nezināmu tīkla nosaukumu. Atdaliet identitāti no izpildes un piešķiriet nezināmajam savu politiku.
Noteikums bija vienkāršs: filtrēt datplūsmu tikai tad, kamēr tālrunis ir savienots ar biroja Wi-Fi. Tas darbojās mēnešiem, un tad kādu rītu tālrunis atradās tajā pašā SSID ar to pašu atslēgas ikonu, un filtrēšana bija apstājusies. Tīklā nekas nebija mainījies; mainījies bija tas, vai lietotne redz tīkla nosaukumu. Android vidē «kurā Wi-Fi es esmu» un «bloķē šo datplūsmu» ir divi atsevišķi darbi, un ugunsmūris, kas tos sajauc, atveras tieši tad, kad nosaukums kļūst nepieejams.
Simptoms: identitāte pazūd, un politika tai seko
SSID noteikums nolasa vērtību un pēc tam izvēlas zaru. Kad nolasīšana neatgriež neko lietderīgu, kodam kaut kas jādara, un ierastā noklusējuma atbilde ir «nav gaidītais tīkls, tāpēc nefiltrēt». Šis noklusējums pārvērš atļaujas problēmu datplūsmas noplūdē. Atslēgas ikona paliek redzama, jo VPN pakalpojums joprojām darbojas; tas vienkārši izpilda citu zaru.
Skatieties notikumu secību, nevis tīklu. Noraidīts atļaujas dialogs, sistēmas atjauninājums, kas pārvietoja SSID piekļuvi aiz citas atļaujas, izslēgti atrašanās vietas pakalpojumi vai darba profila politikas izmaiņas, visi var dot to pašu rezultātu, kamēr tālrunis paliek tajā pašā piekļuves punktā.
Kāpēc nosaukums var atgriezties nezināms
WifiInfo.getSSID() atgriež pašreizējā tīkla pakalpojumu kopas identifikatoru, un Android dokumentē, ka piekļuve atrašanās vietai jutīgiem laukiem ir atkarīga no atļaujas. Kad piekļuves nav, izsaukums atgriež UNKNOWN_SSID, nevis skaļi neizdodas. Tāpēc tukša vai nezināma vērtība nav pierādījums, ka tālrunis ir atstājis Wi-Fi; tas ir pierādījums, ka lietotne nevar klasificēt tīklu.
Divas pārbaudes šos gadījumus atdala. Pārliecinieties, ka tālrunis ir savienots, un apskatiet, ko ziņo sistēma, pēc tam pārliecinieties, ka lietotnei tiešām ir atļauja, kas tai nepieciešama šajā Android versijā:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Ja statusa rinda rāda savienotu tīklu, bet lietotne redz nezināmu nosaukumu, jums ir atļaujas vai API līmeņa problēma, nevis Wi-Fi problēma. Izlabojiet to pirms ugunsmūra noteikumu aiztikšanas, jo katrs nākamais noteikums tiek vērtēts pret vērtību, ko lietotne nevar nolasīt.
Kur filtrēšana patiešām notiek
Vietējais Android ugunsmūris parasti izmanto VpnService modeli, nesūtot datplūsmu uz attālinātu serveri: tas paņem virtuālo saskarni, piemēro savus noteikumus un pārsūta to, ko atļauj. Platforma atļauj vienu aktīvu VPN pakalpojumu uz lietotāja profilu, un otrais aizstāj pirmo, nevis uzslāņojas tam. Tāpēc atsevišķa ugunsmūra lietotne un atsevišķs darba VPN neveido divpakāpju ķēdi; viens no tiem uzvar.
Tas ir svarīgi SSID noteikumam, jo izpildes punkts un novērošanas punkts ir dažādi komponenti. VpnService izlemj, kas atstāj ierīci; Wi-Fi API tikai piegādā etiķeti. Lietotne var izpildīt pareizi un klasificēt nepareizi, un tieši tas ir šī raksta bojājums.
Piešķiriet nezināmajam savu politiku
Uzskatiet tīkla identitāti par trim stāvokļiem un pierakstiet politiku katram pirms noteikuma izlaišanas. Trešais stāvoklis ir tas, ko aizmirst, un tieši tajā jūs noliks uzbrucējs vai nepareiza konfigurācija.
| 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 |
Aizvērti neizdoties nozīmē, ka nezināmais stāvoklis manto visstingrāko saprātīgo politiku, nevis ērtāko. Ja tā dēļ tālrunis jaunā tīklā kļūst nelietojams, pareizais risinājums ir apzināts un redzams izņēmums, nevis kluss uzticēšanās lēmums, kas paslēpts tukšas vērtības pārbaudē.
Pazīstams SSID ir etiķete, nevis tīkla operatora pierādījums. Ikviens var palaist piekļuves punktu ar biroja nosaukumu, tāpēc nosaukuma sakritība nekad nedrīkstētu būt vienīgais, kas stāv starp jutīgu sesiju un neuzticamu segmentu.
Pārbaudiet pārejas, nevis stabilo stāvokli
Stabilā stāvokļa testi iztur tīklā, kurā jūs būvējāt noteikumu. Bojājumi dzīvo pārejās: noraidīta atļauja, Wi-Fi uz mobilo, viens SSID uz citu, VPN pakalpojuma restartēšana un cita VPN lietotne, kas pārņem saskarni. Katram izlemiet, vai esošie savienojumi tiek pārskatīti un vai aizsargātā datplūsma paliek bloķēta, kamēr stāvoklis ir nezināms.
Ierakstiet rezultātu trīs teikumos: novērotais nosacījums, lēmumu izpildošais komponents un apzinātā rezerves rīcība. Ja kāds no trim trūkst, noteikums vēl nav politika; tas ir minējums, kas biroja tīklā darbojas nejauši.