يشرح هذا المقال حالات استخدام أنفاق 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 إنشاء اتصال جديد.
المزيد من الأمثلة وحالات الاستخدام
وصول شفاف إلى موارد بعيدة في شبكة خاصة
لنفترض أن هناك مستودع git موجود في شبكة خاصة يمكن الوصول إليها فقط عبر خادم خاص على الشبكة ولا يمكن الوصول إلى هذا الخادم من خلال شبكة الإنترنت العامة. ومع أنك تمتلك وصولًا مباشرًا إلى الخادم، إلا أنك لا تمتلك وصول VPN إلى الشبكة الخاصة.
لنفترض أنك ترغب في الوصول إلى مستودع git الخاص كما لو كنت متصلًا به مباشرةً من نظامك المحلي، فإذا كان لديك وصول SSH إلى خادم آخر يمكن الوصول إليه من كلا نظامك المحلي وخادمك الخاص، فيمكنك الوصول إلى مستودع git الخاص عبر إنشاء نفق SSH واستخدام بعض إعدادات أوامر بروكسي.
ssh -L 127.0.0.1:22:127.0.0.1:2222 intermediate-host
سيعيد ذلك الاستعلام توجيه المنفذ 2222 في الخادم الوسيط إلى منفذ 22 في الخادم الخاص. والآن عند إنشاء اتصال SSH إلى منفذ 2222 من خادم وسيط، فستتصل بخادم SSH الموجود في الخادم الخاص رغم عدم القدرة على الوصول إلى الخادم الخاص عبر شبكة الإنترنت العامة.
ssh -p 2222 user@localhost
إذا رغبت في إنشاء باب خلفي بطريقة أسهل، فيمكنك إضافة بعض الاستعلامات إلى ملف ~/.ssh/config
المحلي.
Host git.private.network HostName git.private.network ForwardAgent yes ProxyCommand ssh private nc %h %p Host private HostName localhost Port 2222 User private-user ForwardAgent yes ProxyCommand ssh tunnel@intermediate-host nc %h %p
وبهذا يكون قد بات لديك وصول إلى مستودع git الخاص كما لو كنت موجودًا على نفس الشبكة الخاصة.
ترجمة -وبتصرف- للمقال A visual guide to SSH tunnels، لكاتبه Linmiao Xu.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.