أين يجب أن يعيش جدار حماية Android عندما يكون VPN مشغلاً

لديك جملة سياسة واحدة: هذا التطبيق يستطيع الوصول إلى خدمة العمل، ولا شيء غيرها. السؤال التالي يبدو كخيار منتج، لكنه سؤال موضع، لأن كل نقطة تنفيذ محتملة ترى جزءاً مختلفاً من حركة الهاتف. البوابة ترى فقط ما يدخل النفق. والمرشح في جانب الهاتف يرى فقط ما يُسمح له بملاحظته. تمرير طلب واحد عبر الاثنين يجعل الجواب واضحاً.

ابدأ من الجملة لا من المنتج

وسّع المتطلب قبل أن تختار أي شيء. يعني ذلك الحزمة والملف الشخصي الذي تعمل فيه، لأن تطبيق ملف العمل مستخدم مختلف عن التطبيق نفسه في الملف الشخصي. ويعني الوجهة: المضيف والمنفذ والبروتوكول، لا اسم خدمة. ويعني مسار DNS الذي يحل ذلك الاسم، ويعني ما ينبغي أن يحدث عندما لا يكون النفق متاحاً.

مكتوبةً، سياسة المثال أربعة أسطر: تطبيق العمل يستطيع الوصول إلى خدمة العمل؛ تطبيق العمل لا يستطيع الوصول إلى أي شيء آخر؛ التطبيقات الأخرى تبقى دون تغيير؛ وبدون نفق يُرفض تطبيق العمل بدل أن يرتد إلى مسار مباشر. لكل سطر مالك، وليسوا المالك نفسه.

الخطوة 1: ما يستطيع الهاتف نفسه فرضه

جدار الحماية في Android بدون صلاحيات جذر هو VpnService يلتقط الحركة محلياً، حتى عندما لا يوجد نفق بعيد خلفه. يسمح Android بخدمة VPN نشطة واحدة لكل ملف مستخدم، لذلك لا يرتبط تطبيق جدار حماية ثانٍ خلف الأول. بل يحل محله، وتختفي الواجهة التي كان التطبيق الأول يرشّحها.

لهذا نادراً ما يعطي تثبيت جدار حماية بجانب عميل VPN التركيبة التي يتوقعها الناس. إذا بدأ جدار الحماية وانقطع VPN، فلم يُدمج شيء؛ بل تبادل الاثنان المكان. استبدال الواجهة ليس تعاوناً، والعارض نفق ينقطع باستمرار كلما فُتح التطبيق الآخر.

توجد ترتيبات مدعومة: ترشيح مدمج في عميل VPN الذي تستخدمه أصلاً، أو ضوابط منصة مُدارة عبر وحدة تحكم سياسة الجهاز أو ملف عمل، أو معمارية توثّقها الشركة المصنعة. وأي شيء آخر تجربة يجب إعادة التحقق منها بعد كل تحديث تطبيق.

الخطوة 2: ما تستطيع البوابة فرضه

بعد فك تشفير الحركة في الطرف البعيد، تستطيع البوابة تقييد الحزم المُمرَّرة بعناوين أو خدمات أو هويات VPN موثقة. هذا تنفيذ حقيقي لكل ما يخرج عبرها، وهو الموضع الصحيح لتقييد الوصول إلى الشبكات الفرعية الخاصة.

لكنها لا تتلقى هوية التطبيق في الهاتف ملحقةً بكل حزمة IP عادية. عدة تطبيقات تتشارك عنوان نفق واحد تكون كياناً واحداً بالنسبة للبوابة، ما لم يمنحها التصميم عناوين منفصلة أو هويات موثقة منفصلة. لذلك القاعدة لكل مستخدم عند البوابة ليست قاعدة لكل تطبيق في الهاتف، مهما سمتها لوحة الإدارة.

الخطوة 3: اسرد ما لا يصل أبداً

تطبيق مستبعد من VPN يتصل بجهاز قريب لا يصل أبداً إلى البوابة، لذلك لا يستطيع جدار حماية الخروج رفض حزمة لا يتلقاها أصلاً. وينطبق الشيء نفسه على مسار مباشر غير مقصود أثناء انقطاع، وعلى التعرّض الوارد في شبكة الوصول المحلية. هذه حدود محلية بالتعريف.

والعكس صحيح أيضاً: قاعدة محلية تسمح باتصال لا تمنح وصولاً عبر قائمة ACL للشبكة الخاصة في البوابة. قد يخضع طلب واحد للحدين معاً، وتلبية أحدهما لا تقول شيئاً عن الآخر.

الخطوة 4: أسند كل قاعدة إلى مسار

ضع القرار في جدول قبل تهيئة أي شيء، لأن الخلايا الفارغة هي حيث تفشل التصاميم.

الشكل العملي حدّان بمهمتين. حد محلي واعٍ بالتطبيقات يحكم سلوك الهاتف، بما في ذلك الارتداد المباشر، وحد بوابة يحكم الموارد البعيدة. يمكن لجانب البوابة أن يسمح بخدمة العمل ويرفض كل شبكة فرعية خاصة أخرى، بينما تتخذ سياسة جانب الهاتف قرارها الخاص بشأن مسار مباشر قد يسلكه التطبيق.

الخطوة 5: أبقِ النقل حياً ثم تحقق

أياً كانت السياسة المحلية التي تختارها، يجب أن تسمح بالنقل الذي ينشئ VPN ويبقيه. حجب ذلك النقل يترك الهاتف بلا نفق وبلا سياسة، وهذا لا يفرض شيئاً بتماسك ويصعب تشخيصه لأن التطبيق ببساطة بلا شبكة.

ثم تحقق من كل سطر في الجملة الأصلية بدل الانطباع العام: تطبيق العمل يصل إلى خدمة العمل، والتطبيق نفسه يُرفض في وجهة أخرى، وتطبيق غير تابع للعمل يتصرف كما كان، وعند إيقاف النفق لا يرتد تطبيق العمل إلى اتصال مباشر. افحص مسار DNS بصورة منفصلة، لأن DNS الخاص أو محللاً مشفراً قد يتجاوز مرشحاً يفحص العناوين فقط.

إذا تعذّر تحقيق أحد هذه الخطوات على الهاتف، فالمتطلب سؤال معمارية لا إعداد جدار حماية. وتقسيم السياسة بين جهاز تتحكم به وبوابة تتحكم بها هو عادة الجواب الصادق، ووثائق اتصال VPN في Android هي المكان الذي تؤكد فيه ما تسمح به المنصة لخدمة واحدة وما لا تسمح به.