VPN داخل chroot على Android: لماذا يعمل النفق وتتجاهله التطبيقات
يغيّر chroot تحليل المسارات لا النواة ولا نطاق الشبكة ولا تسجيل VPN في Android. نتيجتان تترتبان على ذلك، وكلتاهما تفاجئ الناس.
تحصل على توزيعة لينكس تعمل داخل chroot على الهاتف، وتثبّت داخلها عميل VPN، فتعلن الصدفة أن النفق اكتمل. ثم تنتقل إلى المتصفح فتخرج الحركة عبر بيانات الهاتف وكأن شيئًا لم يحدث. أو العكس: تفقد كل تطبيقات الهاتف الاتصال لأن العميل أضاف مسارًا افتراضيًا في نطاق الشبكة الذي يستخدمه Android فعليًا. هذان العرَضان يأتيان من الجزء الناقص نفسه، وليس أي منهما خللًا في عميل VPN.
الصدفة تقول متصل، والتطبيقات لا توافق
النتيجة الأولى هي الشائعة. نفق في فضاء المستخدم يُفتح من chroot يستطيع إتمام مصافحته وطباعة إحصاءاته وحمل الحركة التي تولّدها الصدفة نفسها، بينما تبقى تطبيقات Android تستخدم شبكة الهاتف الافتراضية. لا شيء يعترضها، لأن شيئًا لم يخبر Android بوجود VPN.
النتيجة الثانية هي الخطرة. إذا شارك chroot نطاق شبكة Android، وهو ما يحدث افتراضيًا، تستطيع عملية ذات امتياز كافٍ إضافة مسارات وواجهة TUN تؤثر في الهاتف كله. عندئذ يعمل النفق لكل تطبيق، بما فيها ما لم تكن تنوي توجيهه، ويعتمد اتصال الهاتف الآن على خادم خفي بلا إدارة دورة حياة ولا مؤشر اتصال ولا سياسة دائم التشغيل.
أي النتيجتين حصلت عليها يمكن الإجابة عنه بأمر واحد. قارن ip route داخل chroot بالأمر نفسه من صدفة Android خارجه. الخرج المتطابق يعني أن chroot في نطاق المضيف: أي تغيير شبكي يحدثه يسري على الهاتف كله. والخرج المختلف يعني أن المشغّل أنشأ له نطاقًا، ونفقه غير مرئي لـ Android بحكم التصميم.
ما غيّره chroot وما لم يغيّره
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
استدعاء chroot النظامي يفعل شيئًا واحدًا: يغيّر المجلد المستخدم لتحليل المسارات. صفحة الدليل صريحة في أنه ليس حدًا أمنيًا، ولا تقول شيئًا عن الواجهات أو المسارات أو حالة VPN. كل ما يتوقعه الناس من حاوية لينكس — مكدس شبكة خاص، ونظام ملفات مُرشَّح، وحدود للموارد — يأتي من آليات أخرى ربما استخدمها المشغّل وربما لم يستخدمها.
لهذا فإن الادعاءات بأن chroot يعزل VPN تجيب عادة عن السؤال الخطأ. السؤال ذو الصلة هو في أي نطاق تعمل العملية وأي نطاق SELinux تُقيَّد فيه، وكلاهما خاصية لكيفية تشغيلها لا لكلمة chroot.
TUN يحتاج ثلاثة أشياء، وعقدة الجهاز واحد منها فقط
نفق فضاء المستخدم التقليدي يحتاج جهاز TUN يستطيع فتحه، ودعمًا من النواة لهذا الجهاز، وإذنًا بتهيئة الواجهة والمسارات. هذه متطلبات منفصلة، وإنشاء اسم مسار تحت /dev لا يحقق أيًا منها وحده:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunفي Android يكون دعم TUN عادة مُضمَّنًا في النواة، لأن خدمة VPN الخاصة بالمنصة تستخدمه، لكن هذا لا يعني أن عمليتك يجوز لها استخدامه. تهيئة الواجهة تحتاج قدرة إدارة الشبكة، وSELinux يقرر إن كانت العملية تستطيع الوصول إلى عقدة الجهاز أصلًا. الرفض يبدو كخطأ إذن بلا سبب ظاهر، ومسار التدقيق هو مكان الجواب:
dmesg | grep avc
logcat -d | grep "avc: denied"لا يحل root هذا. يقيّد SELinux العمليات العاملة بمعرّف uid 0 كما يقيّد غيرها، لذا قد يُمنع chroot بدأ من صدفة root من جهاز يراه. وتعطيل الإنفاذ لإنجاح مثبّت قديم قرار يشمل الهاتف كله بنتائج تتجاوز النفق بكثير، وليس إصلاحًا لبرنامج ثنائي قديم.
لماذا تتجاهل تطبيقات Android نفقه
نموذج Android المدعوم هو تطبيق VPN يسجّل عبر خدمة VPN في المنصة، ويطلب موافقة المستخدم مرة واحدة، ويتلقى واصف ملف لنفقه. ثم توجّه المنصة الحركة إلى ذلك الواصف وتفرض نطاق التطبيقات الذي اختاره المستخدم أو المسؤول، ولهذا يمكن أن يكون النطاق لكل تطبيق ولكل ملف تعريف ومدمجًا مع إعدادات دائم التشغيل والحجب بلا VPN. دليل تطوير VPN في Android يصف تلك المصافحة، والنقطة الأساسية أنها تسجيل لا حيلة توجيه.
الخادم الخفي داخل chroot لا يسجّل أبدًا. لا حوار موافقة، ولا أيقونة مفتاح في شريط الحالة، ولا قائمة تضمين أو استبعاد لكل تطبيق، ولا مشاركة في سياسة دائم التشغيل. لذلك تبقى التطبيقات على الشبكة الافتراضية، ولا يحمل النفق إلا ما ترسله الصدفة نفسها.
الاتجاه الآخر لا يساعد أيضًا. دفع المسارات إلى نطاق المضيف يلتقط كل شيء، بما فيه حركة كانت المنصة تتوقع إبقاءها محلية، ويفعل ذلك بلا تحكم لكل تطبيق وبلا طريقة للمستخدم لرؤيته أو إلغائه. لا يوجد إعداد وسيط يجعل خادمًا داخل chroot يوجّه حركة تطبيق واحد فقط.
التوافق الثنائي جدار منفصل
حتى عندما يكون الجانب الشبكي مثيرًا للاهتمام، للملف التنفيذي متطلباته: معمارية المعالج، والمحمّل الديناميكي، ومكتبة C، وقدرات النواة التي يتوقعها. يستخدم Android مكتبة bionic لا glibc، وقد يحتاج برنامج ثنائي قديم بُني لتوزيعة سطح مكتب إلى مكتبات لم تعد موجودة على الجهاز.
ربط اسم ملف مكتبة بإصدار أحدث لا يخلق توافقًا في ABI، ومكتبة تشفير مؤرشفة من حزمة عمرها عقد ليست مكوّنًا مدعومًا. وإذا كان الأمر يعتمد على ذلك، فالخطة هي تشغيل شيفرة غير مدعومة بامتيازات شبكية على هاتف.
أثبته في سياق Android ثم نظّف بعده
اختبر ما يهمك فعلًا من الجانب المهم: افتح التطبيق المحدد، وصل إلى الوجهة الخاصة المحددة، وتأكد أي محلل أجاب، ثم افصل النفق وتأكد من السلوك الموثّق. النتيجة من طرفية داخل chroot دليل على سياق تنفيذ تلك الطرفية لا أكثر.
إذا غيّرت مسارات المضيف أثناء التجربة، فأعدها وسجّل ما غيّرته. ثم تحقق إن كان الهاتف يضبط VPN دائم التشغيل، لأن تجربة قديمة تركت قاعدة وراءها قد تبدو كعطل في المنصة بعد أشهر.
لحاجة حقيقية إلى وصول عن بُعد، استخدم عميل الخدمة المدعوم أو تصميم بوابة معتمد. السؤال الجدير بالطرح ليس إن كان يمكن تشغيل مثبّت بصلاحيات root، بل إن كان تنفيذ مدعوم يحمل التطبيقات التي تحتاجها عبر الحد المقصود دون ترك تغييرات مميزة بلا مالك على الجهاز.