إعادة وصل نفق SSH SOCKS باستخدام autossh
استخدم autossh مع فحوص حيوية SSH مع إدراك أن إعادة وصل النفق لا تستعيد اتصالات التطبيقات القديمة.
يختفي وكيل SSH SOCKS عند انتهاء اتصال SSH الخاص به. ويمكن لمشرف أن يعيد تشغيل ذلك الاتصال، لكنه لا يستطيع استئناف كل طلب موقع كان يستخدم التدفق القديم.
لإعداد SSH عامل بالفعل، يستطيع autossh الإشراف على تحويل ديناميكي بينما يكتشف OpenSSH خادمًا لا يستجيب:
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]
يعطّل -M 0 آلية منفذ المراقبة المنفصلة في autossh. فهو يعتمد على خروج SSH كي يتمكن المشرف من التفاعل. وتوفّر خيارات بقاء الخادم حيًّا فحصًا للحيوية على مستوى SSH؛ وهي لا تطلب صفحة من كل وجهة تستخدمها.
أبقِ الإعداد الأولي مرئيًا حتى يعمل التوثيق والتحويل. يختلف سلوك autossh في الخلفية عن -f في SSH العادي: فالإطلاق غير المراقب لا يستطيع التوقف لطلب كلمة مرور أو عبارة مرور لمفتاح. كما أن بوابته الموثّقة للبدء تميّز بين فشل إعداد فوري وجلسة معطوبة لاحقًا.
بعد إعادة الوصل، قد يصبح المستمع المحلي متاحًا مرة أخرى. وقد تحتاج التطبيقات إلى إعادة محاولة عملياتها الفاشلة بنفسها. أما الرفع الذي انقطع قبل تلقي ردّ فله نتيجة على مستوى التطبيق يجب حلها، وليس مجرد نفق مفقود يعاد تشغيله.
أخيرًا، لا يثبت النقل السليم لـSSH أن البوابة تستطيع الوصول إلى موقع معيّن. افصل الإشراف على النفق عن مراقبة المهمة التي تستخدمه.