قاعدة جدار الحماية حسب SSID توقفت عن التصفية بعد تبديل شبكة Wi-Fi
يفشل جدار حماية يعتمد على SSID مفتوحًا عندما يعيد Android اسم شبكة غير معروف. افصل الهوية عن التنفيذ وامنح الحالة المجهولة سياستها الخاصة.
كانت القاعدة بسيطة: لا تُصفَّى حركة المرور إلا أثناء الاتصال بشبكة Wi-Fi الخاصة بالمكتب. صمدت القاعدة شهورًا، ثم في صباح أحد الأيام كان الهاتف على الشبكة نفسها وبأيقونة المفتاح نفسها، لكن التصفية توقفت. لم يتغير شيء في الشبكة؛ ما تغير هو ما إذا كان التطبيق يستطيع رؤية اسم الشبكة. في Android، السؤال «أي شبكة Wi-Fi أنا عليها» و«احجب هذه الحركة» مهمتان منفصلتان، وجدار الحماية الذي يخلط بينهما يفشل مفتوحًا تمامًا عندما يصبح الاسم غير متاح.
العَرَض: الهوية تختفي فتتبعها السياسة
تقرأ قاعدة 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. أصلح ذلك قبل أن تمس قواعد جدار الحماية، لأن كل قاعدة تالية تُقيَّم مقابل قيمة لا يستطيع التطبيق قراءتها.
أين تجري التصفية فعليًا
يستخدم جدار الحماية المحلي في Android عادةً نموذج VpnService دون إرسال الحركة إلى خادم بعيد: يأخذ الواجهة الافتراضية ويطبّق قواعده ويمرّر ما يسمح به. تسمح المنصة بخدمة VPN نشطة واحدة لكل ملف مستخدم، والثانية تحل محل الأولى بدلًا من أن تتراكب معها. لذا لا يشكّل تطبيق جدار حماية منفصل وVPN عمل منفصل سلسلة من مرحلتين؛ أحدهما يفوز.
هذا مهم لقاعدة SSID لأن نقطة التنفيذ ونقطة المراقبة مكوّنان مختلفان. تقرر VpnService ما يغادر الجهاز؛ بينما توفّر واجهة Wi-Fi تسمية فقط. يمكن للتطبيق أن ينفّذ بشكل صحيح ويصنّف بشكل خاطئ، وهذا بالضبط الفشل في هذا المقال.
امنح الحالة المجهولة سياستها الخاصة
اعتبر هوية الشبكة ثلاث حالات، واكتب السياسة لكل منها قبل أن تُطلق القاعدة. الحالة الثالثة هي التي تُنسى، وهي التي يضعك فيها مهاجم أو إعداد خاطئ.
| 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 آخر يستولي على الواجهة. لكل حالة، قرّر ما إذا كانت الاتصالات القائمة تُعاد دراستها وما إذا كانت الحركة المحمية تبقى محجوبة أثناء بقاء الحالة مجهولة.
اكتب النتيجة في ثلاث جمل: الشرط الملاحَظ، والمكوّن الذي ينفّذ القرار، والتراجع المتعمّد. وإذا غاب أحد الثلاثة، فالقاعدة لم تصبح سياسة بعد؛ بل تخمين يعمل بالمصادفة على شبكة المكتب.