دليل بصري لكيفية استخدام أنفاق SSH

يشرح هذا المقال حالات استخدام أنفاق SSH مع أمثلة على ذلك، كما يوضح تدفق البيانات بصريًا. حيث يُبين الشكل أدناه مثلًا نفقًا عكسيًا يسمح لمستخدمي عنوان IP محدد (1.2.3.4) بالوصول إلى المنفذ 80 في عميل SSH عبر خادم SSH.

أنفاق SSH هي اتصالات مُعماة (خَفيَّة) تَستخدم بروتوكول TCP بين عميل SSH، وخوادم تسمح بدخول البيانات من جانب واحد من النفق، لتخرج بشفافية وموثوقية من المنفذ الآخر. لقد أُستخدم هذا المصطلح سابقًا لوصف التنفيق عبر واجهات شبكات TUN/TAP الافتراضية لكنه الآن يُشير إلى إعادة توجيه منفذ SSH أي SSH port forwarding، وتتضمن حالات استخدامه النقاط التالية:

توفير قنوات مُشفّرة لحماية البروتوكولات التي تستخدِم نصوصًا غير مُشفرة.
فتح أبواب خلفية إلى شبكات خاصة.
تجاوز الجدران النارية.

إعادة توجيه المنفذ

نقصد بمصطلح إعادة توجيه المنفذ Port forwarding، عملية توجيه حركة البيانات من منفذ ما إلى آخر سواءً كان المنفذ موجود على خادم محلي أو بعيد.

إعادة التوجيه إلى منفذ محلي

تتيح لك إعادة توجيه المنفذ المحلي، إمكانية التحكم في حركة البيانات في عميل SSH وتوجيهه إلى هدف ما من خلال خادم SSH. حيث يسمح لك ذلك بالوصول إلى الخدمات البعيدة باستخدام اتصالات مُشفرة كما لو كانت خدمات محلية. وفي مثال على تلك الحالات الآتية:

الوصول إلى خدمات بعيدة، مثل: redis، وmemcached وغيرها، والاستجابة لاتصالات IP الداخلية.
الوصول إلى الموارد المحلية والمتاحة في شبكة الاتصال الخاصة.
إنشاء توكيلات لطلبات اتصال إلى خدمة بعيدة بشفافية وموثوقية.

إعادة التوجيه إلى منفذ بعيد

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

إتاحة الوصول إلى خادم تطوير ما على شبكة عامة.
السماح لعنوان IP محدد بالوصول إلى الموارد البعيدة والموجودة على شبكة خاصة.

إعادة توجيه المنفذ الديناميكي

تعتمد عملية إعادة التوجيه الديناميكية على فتح وكيل بروكسي SOCKS في عميل SSH، وذلك للسماح بإعادة توجيه تدفق بيانات TCP عبر خادم SSH إلى خادم بعيد.

إعادة التوجيه من منافذ مميزة

إذا أردت فتح منفذ مميز (أي منفذ من 1 إلى 1023) لإعادة توجيه حركة البيانات، فستحتاج إلى تشغيل بروتوكول SSH مستخدمًا صلاحيات الجذر في النظام الذي تستعمله لفتح ذلك المنفذ كما يوضح المثال التالي:

sudo ssh -L 80:example.com:80 ssh-server

وسوم سطر أوامر SSH

هذه هي بعض رايات سطر أوامر SSH المُفيدة والتي يمكنك استخدامها عند إنشاء أنفاق SSH:

‎-f يُنشئ فرعًا من عملية SSH في الخلفية.
‎-n يمنع إمكانية القراءة من تيارات الإدخال المُوحّد STDIN.
‎-N يمنع تشغيل الأوامر البعيدة ويُستخدم فقط عند إعادة توجيه المنافذ.
‎-T يُعطل توزيع أوامر أنظمة يونكس TTY.

يوضح الاستعلام التالي كيفية إنشاء نفق SSH في الخلفية يعمل على إعادة توجيه منفذ محلي عبر خادم SSH:

ssh -fnNT -L 127.0.0.1:8080:example.org:80

سنتجاهل استخدام الرايات سابقة الذكر خلال الأمثلة التالية بهدف الإيجاز.

إعادة توجيه المنفذ المحلي

نعني بإعادة توجيه المنفذ المحلي، عملية إعادة توجيه الاتصالات من منفذ على نظام محلِّي إلى منفذ على خادم بعيد:

ssh -L 127.0.0.1:8080:example.org:80 ssh-server

يُعيد الاستعلام أعلاه توجيه الاتصالات لعنوان 127.0.0.1:8080 في نظامك المحلي إلى منفذ 80 الخاص بعنوان example.org، وذلك عبر خادم SSH. في هذا المثال سيُغلف نفق SSH تدفق البيانات بين نظامك المحلي وخادم SSH، لكن ذلك لا ينطبق على حركة البيانات بين خادم SSH وعنوان example.org. أي أنه من منظور example.org، فإن مصدر حركة البيانات الواردة هو خادم SSH.

ssh -L 8080:example.org:80 ssh-server

ssh -L *:8080:example.org:80 ssh-server

يُعيد هذا المثال توجيه الاتصالات إلى منفذ 8080 في جميع واجهات نظامك المحلي إلى example.org:80 عبر نفق إلى خادم SSH:

ssh -L 192.168.0.1:5432:127.0.0.1:5432 ssh-server

يُعيد المثال الموضح أعلاه توجيه الاتصالات الواردة إلى عنوان 192.168.0.1:5432 في نظامك المحلي، إلى عنوان 127.0.0.1:5432 في خادم SSH. لاحظ أن عنوان 127.0.0.1 هنا يمثل الخادم المحلي من وجهة نظر خادم SSH.

إعدادات خادم SSH

مع أن الإعدادات الافتراضية تكون مناسبةً عادةً، لكن تأكد من تفعيل تحويل اتصالات TCP في خادم SSH على كل حال.

AllowTcpForwarding yes

إذا كنت تُجرى عملية إعادة توجيه المنافذ في واجهات بخلاف 127.0.0.1، فستحتاج إلى تفعيل GatewayPorts على نظامك المحلي عبر تعديل ملف ssh_config، أو عبر خيارات سطر الأوامر.

GatewayPorts yes

حالات الاستخدام

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

إعادة توجيه المنفذ البعيد

يُقصد بإعادة توجيه المنفذ البعيد عملية إعادة توجيه منفذ على نظام بعيد إلى نظام آخر.

ssh -R 8080:localhost:80 ssh-server

يُعيد هذا المثال توجيه حركة البيانات من جميع الواجهات في منفذ 8080 على خادم SSH إلى المنفذ 80 لمُضيفك المحلي localhost على حاسبك المحلي. فإذا كانت إحدى تلك الواجهات متاحةً لشبكة الإنترنت العامة، فإن حركة البيانات المتوجهة إلى منفذ 8080 سيُعاد توجيهها إلى نظامك المحلي.

ssh -R 1.2.3.4:8080:localhost:80 ssh-server

يعمل الاستعلام أعلاه على إعادة توجيه حركة البيانات من منفذ 8080 الخاص بخادم SSH إلى منفذ 80 الخاص بالمُضيف المحلي في نظامك المحلي، بينما يسمح فقط لعنوان IP 1.2.3.4 بالوصول إلى مدخل نفق SSH في خادم SSH. استخدم خيار GatewayPorts clientspecified لإجراء هذه العملية على نحو سليم.

ssh -R 8080:example.org:80 ssh-server

يُعيد هذا الاستعلام توجيه حركة البيانات من جميع الواجهات في عنوان ssh-server:8080 إلى عنوان localhost:80 على نظامك المحلي. بحيث سيُعاد توجيه حركة البيانات تلك من نظامك المحلي إلى عنوان example.org:80. ومن وِجهة نظر example.org، فإن مصدر حركة البيانات هو نظامك المحلي.

إعدادات خادم SSH

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

GatewayPorts yes

أو يمكنك تحديد أيّ من العملاء يُسمح بوصولهم عن طريق استخدام الاستعلام التالي في ملف sshd_config عوضًا عن السابق.

GatewayPorts clientspecified

إعادة توجيه المنفذ الديناميكي

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

ssh -D 3000 ssh-server

يفتح الاستعلام السابق وكيل بروتوكول SOCKS على منفذ 3000 لجميع واجهات نظامك المحلي، ليسمح لك ذلك بتوجيه البيانات المُرسلة عبر الوكيل proxy إلى خادم SSH في أي منفذ أو إلى خادم مستهدف. ومن الناحية الافتراضية، فإن بروتوكول SSH سيستخدم بروتوكول SOCKS5 الذي يمكنه توجيه كلا من حركة بيانات TCP وUDP.

ssh -D 127.0.0.1:3000 ssh-server

يفتح الاستعلام السابق وكيل SOCKS على عنوان 127.0.0.1:3000 في نظامك المحلي.

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

يمكنك اختبار وكيل SOCKS قيد العمل عبر استخدام الاستعلام التالي:

curl -x socks5://127.0.0.1:12345 https://example.org

إعدادات عميل SSH

إذا أردت أن يكون وكيل SOCKS متاحًا لمزيد من الواجهات وليس فقط الخادم المحلي، فعليك التأكد من تفعيل خيار GatewayPorts على نظامك المحلي:

GatewayPorts yes

بما أن خيار GatewayPorts قد أُعِدّ في عميل SSH سابقًا، فيمكنك أيضًا إعداده باستخدام خيارات سطر الأوامر عوضًا عن ملف ssh_config.

ssh -o GatewayPorts=yes -D 3000 ssh-server

القفز بين الخوادم وأوامر الوكيل

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

ssh -J user1@jump-host user2@remote-host

ssh -o "ProxyJump user1@jump-host" user2@remote-host

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

ssh -J jump-host1,jump-host2 ssh-server

يمكنك أيضًا استخدام فواصل متعددة (٫) للفصل بين خوادم القفز.

ssh -o ProxyCommand="nc -X 5 -x localhost:3000 %h %p" user@remote-host

يوضح الاستعلام السابق كيفية الاتصال بخادم بعيد عبر وكيل SOCKS5 مستخدمًا أوامر netcat. ومن وجهة نظر الخادم، فإن عنوان IP قد صدر من خادم وكيل proxy-host، ومع ذلك فإن اتصال SSH بحدّ ذاته مشفر بتقنية طرف لطرف end-to-end، لذلك فإن ذلك الخادم الوكيل لا يرى سوى تدفق من البيانات المشفرة بين النظام المحلي والخادم البعيد.

إعدادات عميل SSH

يمكنك استخدام خيار ssh-add لإضافة هوية SSH المحلية إلى وكيل SSH المحلي وتفعيل إمكانية توجيه الوكيل.

ssh-add

أنفاق SSH الموثوقة

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

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

ClientAliveInterval 15
ClientAliveCountMax 4

يمكنك أيضًا إعداد العميل ليُرسل تلك النبضات.

ServerAliveInterval 15
ServerAliveCountMax 4

كيفية استخدام برنامج AutoSSH

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

autossh -R 2222:localhost:22 ssh-server

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

autossh -R 2222:localhost:22 \
-M 0 \
-o "ServerAliveInterval 10" -o "ServerAliveCountMax 3" \
remote-host

يُعطل استخدام راية M 0- تشغيل منافذ فحص الحالة، ويُسمح لعميل SSH بتولي أمر تلك الفحوصات. في هذا المثال التالي، فإن عميل SSH يتوقع من الخادم إرسال نبضة كل 10 ثوان، وإذا فشل الخادم في إرسال 3 نبضات متتالية، فسيُغلق عميل SSH النفق وسيُعيد برنامج AutoSSH إنشاء اتصال جديد.