إعادة توجيه محلية عبر SSH إلى وكيل HTTP قائم: عنوانان محليان

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

حدّد ما إذا كان هناك وكيل ثابت موجود بالفعل

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

التأكد من ذلك أولًا يوفّر عليك تصحيح خطأ نفق لم يكن متصلًا بأي شيء قط.

ابنِ إعادة التوجيه واقرأ الأمر

الصيغة التي تريدها تربط منفذ loopback على حاسوبك المحمول وتوصله، من جانب الخادم، بعنوان الوكيل كما يراه الخادم.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

الخيار -N يمنع تنفيذ أمر بعيد، وأما -T فيمنع تخصيص termios، لأنك تريد نفقًا لا صدفة. عنوان loopback الأول هو حيث يستمع الحاسوب المحمول؛ أما الثاني فيُحلّ من خادم SSH، لذا فإن 127.0.0.1 هناك يعني الوكيل على ذلك الجهاز. يجعل ExitOnForwardFailure الأمر يفشل بصوت عالٍ إذا كان المنفذ المحلي مشغولًا، بدلًا من بدء جلسة لا تعيد توجيه شيئًا. اكتب العنوان الهدف كما يحلّه الخادم، لأن اسمًا لا يستطيع حاسوبك المحمول وحده حلّه سيفشل على الجانب الآخر.

سياسة الخادم نفسها تُطبَّق قبل أن يعمل أي من هذا. يجب أن يسمح AllowTcpForwarding بذلك، وقد يقيّد PermitOpen الوجهات والمنافذ التي يمكن للجلسة الوصول إليها، لذا فإن إعادة توجيه يقبلها العميل قد يرفضها الخادم مع ذلك. يظهر الرفض كخطأ في إعادة التوجيه أو في القناة على العميل، وقراءة تلك الرسالة أسرع من تعديل الأمر.

وجّه تطبيقًا واحدًا إلى إعادة التوجيه

اضبط التطبيق ليستخدم وكيل HTTP على http://127.0.0.1:13128، مع بيانات الاعتماد إذا كان الوكيل البعيد يتطلبها. أبقِ التحقق من الشهادات داخل التطبيق نفسه للوجهات التي تستخدم HTTPS، لأن نفق الوكيل لا يحل محله. هذه إعادة توجيه ثابتة لخدمة واحدة، لذا يجب إخبار التطبيق بوجود وكيل بدلًا من تركه ليكتشفه.

فحص سريع قبل ضبط أي شيء دائم: curl -x http://127.0.0.1:13128 -I https://example.com، وهو يجرّب طريقة HTTP CONNECT التي يجب أن يدعمها الوكيل.

أبقِ السلطة حيث كانت

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

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

تحقق من الطرفين ثم نظّف

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

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