أي حركة تطبيق تحملها حقاً إعادة توجيه SSH؟

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

سمِّ الواجهة قبل أن تقارن أي شيء

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

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

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

تختلف إعادة التوجيه المحلية والبعيدة والديناميكية في من يستمع

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

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

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

وضع جهاز النفق هو الاستثناء الشبكي الحقيقي الوحيد

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

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

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

اختبر أن تطبيقك يستخدم الواجهة التي بنيتها

التحقق لكل تطبيق لا لكل جلسة. إعادة توجيه عاملة تثبت أن المنفذ مربوط وأن الجانب البعيد يستطيع الاتصال؛ لكنها لا تثبت أن البرنامج الذي يهمك اتصل عبرها.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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