لماذا لا يُثبت مرور تصحيح الأخطاء اللاسلكي وجود تسريب في VPN

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

لقد واجهت هذا الفهم الخاطئ مرتين: مرة والحاسوب والهاتف على شبكة Wi-Fi نفسها، ومرة بعد إعادة تشغيل بقيت فيها المقارنة. وفي الحالتين كان VPN يفعل بالضبط ما أُعدّ له.

سمِّ الملاحظة قبل أن تسمي الخلل

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

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

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

لماذا لا يلتقي المساران أبداً

تصحيح الأخطاء اللاسلكي اتصال وارد إلى الجهاز. يستمع adbd على منفذ مرتبط بواجهة Wi-Fi، وتتصل به محطة العمل بعد الاقتران. الاتجاه مهم: حاسوبك يصل إلى الهاتف، لا العكس. وهذا عكس تسريب الخروج.

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

يفرض وضع الإغلاق النفق على التطبيقات المشمولة. لكنه لا يحوّل مقبس استماع إلى مسار خروج.

لهذا تتعايش جلسة ADB العاملة ومفتاح الإيقاف العامل دون تناقض. ولإثبات تسريب، عليك مراقبة الاتجاه الذي يُفترض أن يُحجب.

كيف يبدو اختبار الخروج فعلاً

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

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

الطلب المحجوب في تلك الظروف دليل. أما جلسة ADB الناجحة فليست دليلاً، وكذلك بينغ واحد من تطبيق طرفية.

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

الاقتران يعيش أطول من الجلسة

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

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

على شبكة مشتركة أو غير موثوقة، أبقِه معطّلاً. فتصريح دائم على شبكة لا تتحكم بها مشكلة أكبر من تجاوز TUN افتراضي.

قبل أن تبلّغ عن ذلك الخلل

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

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

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