SSID-fajroŝirmila regulo ĉesis filtri post ŝanĝo de Wi-Fi
Fajroŝirmilo ligita al SSID malsukcesas malferme kiam Android resendas nekonatan retan nomon. Apartigu identecon de plenumado kaj donu al la nekonato propran politikon.
La regulo estis simpla: filtri trafikon nur dum la telefono estas konektita al la oficeja Wi-Fi. Ĝi teniĝis monatojn, kaj poste unu matenon la telefono sidis sur la sama SSID kun la sama ŝlosila ikono kaj la filtrado estis ĉesinta. Nenio en la reto estis ŝanĝiĝinta; ŝanĝiĝis tio, ĉu la aplikaĵo povas vidi la nomon de la reto. En Android, «sur kiu Wi-Fi mi estas» kaj «bloku ĉi tiun trafikon» estas du apartaj taskoj, kaj fajroŝirmilo, kiu konfuzas ilin, malsukcesas malferme ĝuste kiam la nomo ne plu disponeblas.
La simptomo: identeco malaperas kaj la politiko sekvas
SSID-regulo legas valoron kaj poste elektas branĉon. Kiam la legado resendas nenion utilan, la kodo devas fari ion, kaj la kutima defaŭlto estas «ne la atendita reto, do ne filtru». Tiu defaŭlto igas permesan problemon trafika liko. La ŝlosila ikono restas videbla ĉar la VPN-servo ankoraŭ funkcias; ĝi nur plenumas alian branĉon.
Rigardu la ordon de la eventoj, ne la reton. Rifuzita permesa demando, sistema ĝisdatigo kiu movis SSID-aliron malantaŭ alian permeson, malŝaltitaj lokaj servoj aŭ ŝanĝita politiko de labora profilo povas ĉiuj doni la saman rezulton dum la telefono restas ĉe la sama alirpunkto.
Kial la nomo povas reveni nekonata
WifiInfo.getSSID() resendas la servokompletan identigilon de la nuna reto, kaj Android dokumentas ke aliro al loko-sentemaj kampoj dependas de permeso. Kiam aliro ne disponeblas, la voko resendas UNKNOWN_SSID anstataŭ malsukcesi laŭte. Malplena aŭ nekonata valoro do ne estas pruvo ke la telefono forlasis Wi-Fi; ĝi estas pruvo ke la aplikaĵo ne povas klasifiki la reton.
Du kontroloj apartigas la kazojn. Konfirmu ke la telefono estas asociita kaj vidu kion la sistemo raportas, poste konfirmu ke la aplikaĵo vere havas la permeson kiun ĝi bezonas en ĉi tiu Android-eldono:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Se la statuslinio montras konektitan reton dum la aplikaĵo vidas nekonatan nomon, vi havas permesan aŭ API-nivelan problemon, ne Wi-Fi-problemon. Riparu tion antaŭ ol tuŝi la fajroŝirmilajn regulojn, ĉar ĉiu malsupra regulo estas taksata kontraŭ valoro kiun la aplikaĵo ne povas legi.
Kie la filtrado efektive funkcias
Loka Android-fajroŝirmilo kutime uzas la modelon VpnService sen sendi trafikon al fora servilo: ĝi prenas la virtualan interfacon, aplikas siajn proprajn regulojn kaj plusendas tion kion ĝi permesas. La platformo permesas unu aktivan VPN-servon por uzantprofilo, kaj dua anstataŭas la unuan anstataŭ stakiĝi sur ĝi. Aparta fajroŝirmila aplikaĵo kaj aparta labora VPN do ne formas duŝtupan ĉenon; unu el ili venkas.
Tio gravas por SSID-regulo ĉar la plenum-punkto kaj la observ-punkto estas malsamaj komponantoj. La VpnService decidas kio forlasas la aparaton; la Wi-Fi-API nur donas etikedon. Aplikaĵo povas plenumi ĝuste kaj klasifiki malĝuste, kaj ĝuste tio estas la fiasko en ĉi tiu artikolo.
Donu al la nekonato propran politikon
Traktu la retan identecon kiel tri statojn, kaj skribu la politikon por ĉiu antaŭ ol publikigi la regulon. La tria stato estas la forgesata, kaj ĝuste en ĝin metos vin atakanto aŭ malĝusta agordo.
| 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 |
Malsukcesi fermite signifas ke la nekonata stato heredas la plej striktan prudentan politikon anstataŭ la plej oportunan. Se tio igas la telefonon neuzebla en nova reto, la ĝusta solvo estas intenca, videbla escepto, ne silenta konfida decido kaŝita en kontrolo de malplena valoro.
Konata SSID estas etikedo, ne pruvo de la reta operatoro. Iu ajn povas funkciigi alirpunkton kun la nomo de la oficejo, do nomkongruo neniam devus esti la sola afero inter sentema sesio kaj nefidinda segmento.
Testu la transirojn, ne la stabilan staton
Testado en stabila stato pasas en la reto kie vi konstruis la regulon. La fiaskoj vivas en transiroj: rifuzita permeso, Wi-Fi al poŝtelefona reto, unu SSID al alia, restartigita VPN-servo kaj alia VPN-aplikaĵo kiu prenas la interfacon. Por ĉiu, decidu ĉu ekzistantaj konektoj estas rekonsiderataj kaj ĉu protektita trafiko restas blokita dum la stato estas nekonata.
Skribu la rezulton kiel tri frazojn: la observita kondiĉo, la komponanto kiu plenumas la decidon, kaj la intenca rezerva konduto. Se iu el la tri mankas, la regulo ankoraŭ ne estas politiko; ĝi estas konjekto kiu hazarde funkcias en la oficeja reto.