SSID güvenlik duvarı kuralı Wi-Fi değişiminden sonra filtrelemeyi bıraktı
SSID'ye bağlı bir güvenlik duvarı, Android bilinmeyen bir ağ adı döndürdüğünde açık biçimde başarısız olur. Kimliği uygulamadan ayırın ve bilinmeyene kendi politikasını verin.
Kural basitti: yalnızca telefon ofis Wi-Fi'sine bağlıyken trafiği filtrele. Aylarca dayandı, sonra bir sabah telefon aynı SSID'de aynı anahtar simgesiyle duruyordu ve filtreleme durmuştu. Ağda hiçbir şey değişmemişti; değişen, uygulamanın ağın adını görüp görememesiydi. Android'de «hangi Wi-Fi'deyim» ve «bu trafiği engelle» iki ayrı iştir ve ikisini birbirine karıştıran bir güvenlik duvarı tam da ad elde edilemez olduğunda açık biçimde başarısız olur.
Belirti: kimlik kaybolur ve politika onu izler
Bir SSID kuralı bir değer okur ve sonra bir dal seçer. Okuma işe yarar bir şey döndürmediğinde kod bir şey yapmak zorundadır ve yaygın varsayılan «beklenen ağ değil, o hâlde filtreleme»dir. Bu varsayılan bir izin sorununu trafik sızıntısına dönüştürür. Anahtar simgesi görünür kalır çünkü VPN hizmeti hâlâ çalışmaktadır; yalnızca başka bir dalı uygulamaktadır.
Ağa değil, olayların sırasına bakın. Reddedilen bir izin iletişim kutusu, SSID erişimini başka bir iznin arkasına taşıyan bir sistem güncellemesi, kapatılmış konum hizmetleri veya iş profili politikası değişikliği, telefon aynı erişim noktasında kalırken aynı sonucu verebilir.
Ad neden bilinmeyen olarak dönebilir
WifiInfo.getSSID() geçerli ağın hizmet kümesi tanımlayıcısını döndürür ve Android, konuma duyarlı alanlara erişimin izne bağlı olduğunu belgeler. Erişim yoksa çağrı yüksek sesle başarısız olmak yerine UNKNOWN_SSID döndürür. Bu nedenle boş veya bilinmeyen bir değer telefonun Wi-Fi'den ayrıldığının kanıtı değildir; uygulamanın ağı sınıflandıramadığının kanıtıdır.
İki kontrol durumları ayırır. Telefonun bağlı olduğunu doğrulayın ve sistemin ne bildirdiğine bakın, ardından uygulamanın bu Android sürümünde gereken izne gerçekten sahip olduğunu doğrulayın:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Durum satırı bağlı bir ağ gösterirken uygulama bilinmeyen bir ad görüyorsa sorununuz izin veya API düzeyindedir, Wi-Fi sorunu değildir. Güvenlik duvarı kurallarına dokunmadan önce bunu düzeltin, çünkü sonraki her kural uygulamanın okuyamadığı bir değere göre değerlendirilir.
Filtreleme gerçekte nerede çalışır
Yerel Android güvenlik duvarı genellikle trafiği uzak bir sunucuya göndermeden VpnService modelini kullanır: sanal arayüzü alır, kendi kurallarını uygular ve izin verdiğini iletir. Platform, kullanıcı profili başına bir etkin VPN hizmetine izin verir ve ikincisi birincinin üzerine katmanlanmak yerine onu değiştirir. Bu nedenle ayrı bir güvenlik duvarı uygulaması ve ayrı bir iş VPN'i iki aşamalı bir zincir oluşturmaz; biri kazanır.
Bu bir SSID kuralı için önemlidir çünkü uygulama noktası ile gözlem noktası farklı bileşenlerdir. VpnService cihazdan neyin çıkacağına karar verir; Wi-Fi API'si yalnızca bir etiket sağlar. Bir uygulama doğru uygulayıp yanlış sınıflandırabilir ve bu makaledeki arıza tam olarak budur.
Bilinmeyene kendi politikasını verin
Ağ kimliğini üç durum olarak ele alın ve kuralı yayınlamadan önce her biri için politikayı yazın. Üçüncü durum unutulandır ve bir saldırgan ya da yanlış yapılandırma sizi tam oraya koyar.
| 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 |
Kapalı başarısız olmak, bilinmeyen durumun en rahat değil en katı makul politikayı devralması demektir. Bu telefonu yeni bir ağda kullanılamaz hâle getiriyorsa doğru çözüm, boş değer denetimine gizlenmiş sessiz bir güven kararı değil, bilinçli ve görünür bir istisnadır.
Tanıdık bir SSID bir etikettir, ağ işletmecisinin kanıtı değildir. Herkes ofisin adıyla bir erişim noktası çalıştırabilir, bu yüzden ad eşleşmesi hassas bir oturum ile güvenilmeyen bir kesim arasındaki tek şey olmamalıdır.
Kararlı durumu değil geçişleri test edin
Kararlı durum testleri kuralı kurduğunuz ağda geçer. Arızalar geçişlerde yaşar: reddedilen izin, Wi-Fi'den mobil veriye, bir SSID'den diğerine, VPN hizmetinin yeniden başlaması ve başka bir VPN uygulamasının arayüzü devralması. Her biri için mevcut bağlantıların yeniden değerlendirilip değerlendirilmediğine ve durum bilinmezken korunan trafiğin bloke kalıp kalmadığına karar verin.
Sonucu üç cümle olarak yazın: gözlenen koşul, kararı uygulayan bileşen ve bilinçli geri dönüş. Üçünden biri eksikse kural henüz politika değildir; ofis ağında tesadüfen çalışan bir tahmindir.