قد يبقى systemd-socket-proxyd أطول من نفق SSH SOCKS
وائم دورة حياة مساعد تمرير المقبس مع اعتماده على SSH حتى لا يترك نفق ميت واجهة تبدو سليمة.
إذا كان منفذ الواجهة لا يزال يقبل الاتصالات بعد خروج SSH، فافحص الوحدات الثلاث كلها. فمقبس التنشيط ومساعد systemd-socket-proxyd ومستمع SOCKS الذي ينشئه SSH لها أعمار مختلفة:
| المقبس | المساعد | SSH | التفسير |
|---|---|---|---|
| يستمع | غير نشط | غير نشط | قد ينتظر الطلب على نحو طبيعي |
| يستمع | نشط | نشط | العمليات موجودة؛ لكن سلامة الوجهة النهائية غير مثبتة |
| يستمع | نشط | غير نشط | يمكن للواجهة قبول العمل دون خلفيتها |
تشغيل المساعد وSSH معًا لا يحدد انتقال التوقف اللاحق. وبالنسبة إلى مساعد يجب ألا يبقى نشطًا دون نفقه، توثّق systemd العلاقة الأقوى:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceطبّقها على الوحدة المناسبة في التصميم الفعلي. فـRequires= والترتيب لا يعالجان إلا جزءًا من العلاقة. وقد لا تحفّز واجهة نشطة سلفًا التنشيط مرة أخرى أبدًا بعد اختفاء خلفيتها. افحص أيضًا حالة الوحدات الفاشلة وحدود معدل البدء؛ فالاعتماديات لا تتجاوز تلك الحدود.
ثم أثبت جاهزية البدء. فـAfter= يرتّب المهام لا جاهزية مستمع SSH من النوع Type=simple. وقد يفشل انتظار ثابت أثناء مصادقة بطيئة. استخدم عقد بدء ينشئ المستمع المطلوب؛ وExitOnForwardFailure=yes يلتقط فشل إعداد التمرير لا إمكانية الوصول إلى الوجهة لاحقًا.
أخيرًا حدّد الخروج عند الخمول وإعادة التنشيط. فخيار الخروج عند الخمول في عفريت التمرير يتعلق بغياب الاتصالات النشطة لا بغياب البايتات على اتصال مفتوح. وقد تُبقي جلسة هادئة المساعد نشطًا. وينبغي أن ينشّط الطلب التالي الخدمات المطلوبة، وأن تبقى حلقات إعادة التشغيل محدودة ومرئية. إعادة إنشاء المستمع تسمح باتصالات جديدة؛ ولا تعيد جلسات TCP القديمة الممرَّرة.