امنح جهاز Pi بعيدًا وكيل SOCKS عبر عميل SSH لديك

أنت تفترض أن وكيل SOCKS يجب أن يعمل حيث يوجد الوصول إلى الشبكة أصلًا. يستطيع OpenSSH أن يضع المستمع في مكان آخر تمامًا. يفتح التمرير الديناميكي البعيد منفذ SOCKS على مضيف بعيد ويبدأ كل اتصال من عميل SSH المحلي لديك، وهو العميل الذي يحمل مسار VPN المعتمد لحاسوبك المحمول. يحصل جهاز Pi على وكيل محدود النطاق؛ فهو لا يرث نفقك ولا امتيازاتك.

يمكن أن يختلف المستمع عن الجانب الذي ينشأ منه الاتصال

يشغّل الأمر العادي ssh -D 1080 المستمع على جهازك ويرسل الاتصالات من هناك. يعكس التمرير الديناميكي البعيد ذلك: يظهر المستمع على المضيف البعيد، ويُفتح كل اتصال يقبله من الجانب المحلي. ويذكر دليل عميل OpenSSH أن -R بلا وجهة ثابتة هو بالضبط ترتيب SOCKS4/5 هذا.

يبدو الأمر المدعوم من الحاسوب المحمول هكذا، مع اعتبار الحساب والمضيفين والمنفذ عناصر نائبة:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

ثلاثة تفاصيل تؤدي عملًا مفيدًا هناك. يُبقي -S none الجلسة بعيدًا عن سيد تحكم مشترك، ويُفشل ExitOnForwardFailure بسرعة بدلًا من تركك بجلسة نصف مفتوحة، ويحدّ PermitRemoteOpen مما قد يصل إليه المستمع البعيد. استخدم حساب Pi مصرّحًا به وتحقق من مفتاح المضيف قبل أن تضيف أيًا من ذلك.

ما يعرضه المستمع البعيد فعلًا

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

كما أن loopback ليس حدًا يفصل بين المستخدمين. يستطيع أي عملية أخرى على جهاز Pi الاتصال بـ 127.0.0.1:1080 إذا عرفت المنفذ، لذا فإن الحسابات المحلية على الجهاز وكل ما يعمل عليه جزء من تصميم وصولك. هذا سبب لإبقاء قائمة الوجهات ضيقة، وليس سببًا لتخطي فحص السياسة.

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

مرّر تطبيقًا واحدًا عبر الوكيل

يمكن لعميل على جهاز Pi يتعامل مع الوكيل أن يرسل الطلب عندئذ. تسلّم بادئة socks5h اسم الوجهة إلى الوكيل، فيحدث البحث والاتصال كلاهما على جانب الحاسوب المحمول، وهي تطابق الوجهة المسمّاة في PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

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

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

أثبت المسار ثم أغلقه

تأكد من وجود المستمع حيث تتوقع، ومن أن الوجهة المقصودة وحدها هي التي تجيب:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

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

هذا الترتيب يحمل TCP فقط. تبقى UDP وICMP والبرامج التي تتجاهل إعدادات الوكيل خارجه، وينتهي التمرير في اللحظة التي تنتهي فيها جلسة SSH. أوقف تلك الجلسة عند الانتهاء وأزل إعداد الوكيل الذي أضفته إلى التطبيق.

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