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 که از پروکسی میگذشتند را بازنمیگرداند.