أيقونة VPN في أندرويد مضاءة، فلماذا لا يمرّ الاتجاه عبر النفق؟

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

الأيقونة تعني أن خدمة VPN تملك الواجهة

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

adb shell dumpsys connectivity | grep -i vpn
adb shell settings get global always_on_vpn_app

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

الملف الشخصي الأصلي أو VPN التطبيق: ليسا قابلين للتبادل

ملف IKEv2 الذي توفّره المنصّة وتطبيق ينفّذ OpenVPN أو WireGuard منتجان مختلفان بقوائم مختلفة. واجهة المنصّة لـ IKEv2 موجودة من إصدار أندرويد محدّد، وبناءات المصنّعين لا تعرض كلها الخيارات نفسها في المكان نفسه. لقطة شاشة من هاتف آخر ليست وثيقة توافق.

adb shell getprop ro.build.version.sdk
adb shell dumpsys package com.example.vpn | head -40

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

قواعد كل تطبيق وملفات العمل تغيّر النطاق

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

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

توقّف إذا كان التطبيق الذي تختبره خارج نطاق النفق. هذا اختيار سياسة، لا عطل.

اختبر ما غادر الهاتف فعلًا

اختبر وجهات عامة وخاصة، وعائلتي العناوين وشبكتي الوصول. ثم قارن النتيجة بنطاق التطبيق نفسه، لأن نجاح تحميل صفحة في تطبيق لا يقول شيئًا عن الآخر. أعد ذلك بعد التبديل من Wi-Fi إلى بيانات الهاتف، لأن إعادة الاتصال قد تهبط على مسار مختلف.

adb shell ip rule
adb shell dumpsys netpolicy | grep -i vpn

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

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