الوصول إلى موقع HTTPS مخصص لشبكة VPN عبر تمرير SSH

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

الخطوة الأولى: تأكيد الشروط المسبقة الثلاثة

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

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

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

الخطوة الثانية: ربط منفذ loopback وإبقاء الجلسة حيّة

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

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

الخطوة الثالثة: الحفاظ على اسم HTTPS عندما يكون المقبس محلياً

التصفح إلى https://127.0.0.1:9443/ يغيّر اسم خادم TLS وسلطة التطبيق. الشهادة الصادرة لـ portal.lab.example لن تتحقق مقابل عنوان loopback، ويبدو الخطأ الناتج كشهادة معطوبة بدلاً من اختصار تمرير. لاختبار من سطر الأوامر، احتفظ بعنوان URL الحقيقي وغيّر وجهة المقبس فقط. هذا ما يفعله --connect-to، ويوثّق دليل curl الصيغة الرباعية الحقول المستخدمة أدناه.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

يبقى الاسم في عنوان URL وفي مصافحة TLS وفي ترويسة Host، بينما يذهب اتصال TCP إلى المستمع المحلي. خيار منع الوسيط يبقي الاختبار على هذا التمرير بدلاً من ترك وسيط HTTP مُهيّأ يعترضه، وإبقاء التحقق من الشهادة مفعّلاً هو ما يجعل النتيجة ذات معنى.

الخطوة الرابعة: معرفة ما لا يستطيع تمرير واحد تغطيته

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

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

الخطوة الخامسة: التنظيف وتسجيل الأمر

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

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