تسجّل الدخول عبر SSH، وتضيف -D 1080، فينجح الأمر. الآن يوجد مستمع SOCKS على الهاتف، ومع ذلك يخرج نصف التطبيقات عبر بيانات الهاتف المحمول. هذه هي النتيجة الطبيعية، وليست نفقًا معطوبًا: ssh -D ينشئ نقطة نهاية وكيل، وتطبيقات Android لا تستخدم وكيلًا إلا إذا أجبرها شيء على ذلك. تتبّع السلسلة خطوة بخطوة يُظهر أين يقع كل جزء من المهمة فعليًا.

ابدأ من حيث تبدأ حركة المرور

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

قبل إقحام أي شيء آخر، أثبت أن المستمع يعمل من صدفة الهاتف نفسها عبر عميل يتحدث SOCKS مباشرة:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

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

أضف القطعة التي يحتاجها Android

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

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

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

أبقِ نقل SSH خارج الالتقاط

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

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

تحقق من الاستثناء من الخارج: أعد توصيل المحوّل، ثم تأكد من بقاء جلسة SSH ومن أن الطلب عبر الوكيل ما زال يبلّغ عنوان الخادم. الجلسة التي تعمل حتى يبدأ المحوّل ثم تتجمد هي الحلقة.

تابع DNS وUDP إلى نهاية السلسلة

التمرير الديناميكي في OpenSSH يحمل اتصالات TCP. وهو ليس نقل UDP أو ICMP، ولا يمكن للمحوّل أن يخترع تمرير UDP بقبول حزم UDP. كل ما يصرّ على UDP، بما في ذلك QUIC ووسائط WebRTC، سيفشل أو يعود إلى TCP بحسب التطبيق.

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

أبقِ مستمع SOCKS مربوطًا بواجهة loopback، وتحقق من مفتاح مضيف خادم SSH عند أول استخدام، واترك التحقق العادي من HTTPS قائمًا للموقع النهائي. SSH يحمي المقطع من الهاتف إلى الخادم، ولا يشفّر ما يفعله الخادم بعد ذلك.

افحص العمريْن وقرّر

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

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

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

مقالات ذات صلة