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

مقالات مرتبط