ServerAliveInterval در SSH روی VPN: کدام سمت کاوش را می‌فرستد؟

بیشتر توصیه‌های مربوط به زنده نگه‌داشتن نشست SSH روی «ServerAliveInterval 30 را اضافه کن» متوقف می‌شود و بخش‌های مفید را جا می‌گذارد. کلیدواژه یک زمان‌سنج در سمت کلاینت است که فقط وقتی کانال ساکت بوده فعال می‌شود، کاوش‌های بی‌پاسخ را می‌شمارد نه ثانیه‌ها را، و در فایلی زندگی می‌کند که در آن اولین مقدار منطبق برنده است. اگر این سه ویژگی را اشتباه بگیرید، یک نشست VPN سالم هم قطع می‌شود و نشست مرده معلق می‌ماند.

دو جهت به دو دیمن متفاوت تعلق دارند

ServerAliveInterval را کلاینت ssh شما می‌خواند. ClientAliveInterval را sshd در سمت دور می‌خواند و در جهت مخالف، از سرور به کلاینت، کاوش می‌کند. این‌ها نام‌های جایگزین نیستند و با هم همکاری نمی‌کنند، پس تنظیم یکی هیچ اثری بر رفتار سمت دیگر ندارد. اشتباه گرفتن آن‌ها دلیل معمول این است که یک اصلاح روی یک میزبان جواب می‌دهد و روی میزبان بعدی نه.

هر دو صفر را می‌پذیرند. در صفر کلاینت هیچ چیزی نمی‌فرستد، و در سمت سرور مقدار صفر برای ClientAliveCountMax قطع اتصالی را که در غیر این صورت پس از بررسی‌های بی‌پاسخ رخ می‌داد غیرفعال می‌کند.

کاوش چه چیزی را ثابت می‌کند و چه چیزی را نه

پس از گذشت فاصله تنظیم‌شده بدون رسیدن داده‌ای از سرور، کلاینت درخواست کوچکی را از کانال رمزنگاری‌شده موجود می‌فرستد و منتظر پاسخ می‌ماند. ServerAliveCountMax تعیین می‌کند که چند تا از آن‌ها می‌توانند بی‌پاسخ بمانند تا نشست از هم بپاشد. با فاصله 60 و شمار 3 کلاینت حدود سه دقیقه سکوت بعد تسلیم می‌شود، و این عدد ویژگی پیکربندی شماست نه یک استاندارد شبکه. فاصله را روی مقدار پیش‌فرض 0 بگذارید و هیچ کاوشی هرگز فرستاده نمی‌شود، به همین دلیل یک کلاینت استاندارد می‌تواند بی‌پایان روی یک اتصال مرده بنشیند.

چون این تبادل درون انتقال SSH انجام می‌شود، پاسخ ثابت می‌کند که فرایند SSH طرف مقابل هنوز می‌خواند و می‌نویسد. اما درباره برنامه‌ای که درون آن نشست اجرا کرده‌اید چیزی نمی‌گوید: یک کلاینت پایگاه داده، یک درگاه فورواردشده یا یک اسکریپت طولانی می‌تواند گیر کرده باشد در حالی که انتقال با خوشحالی به کاوش‌ها پاسخ می‌دهد.

TCPKeepAlive سازوکاری جداست یک لایه پایین‌تر. هسته آن را اداره می‌کند، رمزنگاری نشده است، و طرف مقابلی که دیمن SSH‌اش گیر کرده باز هم می‌تواند آن را برآورده کند. به همین دلیل کاوش در سطح SSH سیگنال معنادارتری است وقتی نشست برایتان مهم است نه سوکت.

ترتیب تعیین می‌کند کدام مقدار زنده بماند

OpenSSH اولین مقداری را که برای هر پارامتر به دست می‌آورد اعمال می‌کند، پس یک بلوک Host مشخص باید پیش از هر بلوک گسترده‌تری بیاید که آن هم منطبق می‌شود. مقادیر پیش‌فرض با نویسه عام را در پایین فایل بگذارید نه بالا، و به یاد داشته باشید که یک بلوک Match پایین‌تر نمی‌تواند مقداری را که قبلاً تنظیم شده نادیده بگیرد. مرجع پیکربندی کلاینت OpenSSH قاعده اولین مقدار را صریح بیان می‌کند و ارزش یک بار خواندن را دارد پیش از بازآرایی یک پیکربندی مشترک.

گزینه‌های خط فرمان بر فایل پیروز می‌شوند، که یک آزمایش موقت را ارزان می‌کند:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

برای دیدن آنچه کلاینت واقعاً حل کرده، نه آنچه فکر می‌کنید نوشته‌اید، از آن بخواهید پیکربندی مؤثر را بیرون بریزد. خروجی مقادیر ادغام‌شده برای آن نام میزبان را دارد و سریع‌ترین راه گرفتن یک بلوک سرگردان پیشین است:

ssh -G office-shell | grep -i alive

نگه‌دارنده‌ها روی یک تونل چه می‌کنند

ترافیک دوره‌ای مانع انقضای نگاشت یک NAT یا دیوار آتش حالت‌دار می‌شود، که در VPN‌ای که دروازه‌اش جریان‌های بی‌کار را بعد از چند دقیقه دور می‌ریزد مزیت واقعی است. کاوش‌هایی که هر 60 ثانیه می‌رسند آن نگاشت را بدون حمل هیچ داده کاربردی تازه می‌کنند.

آن‌ها نمی‌توانند مسیری را که رفته بازسازی کنند. وقتی رابط تونل ناپدید می‌شود کاوش‌ها هم مثل همه چیز شکست می‌خورند و نشست با ته کشیدن شمار به پایان می‌رسد. تشخیص زنده‌بودن و بازیابی مسیر دو مسئله متفاوت‌اند و تنها اولی در ssh_config قابل تنظیم است. آنچه فاصله و شمار واقعاً برایتان می‌خرند سرعت متوجه شدن کلاینت است، و همین بخشی است که کاربر آن را به‌صورت هنگ تجربه می‌کند.

اتصالات چندگانه یک چین اضافه می‌کنند. با ControlMaster در کار، کاوش‌ها متعلق به اتصال اصلی‌اند و نشست جدید روی یک اصلی موجود هرچه آن اصلی مذاکره کرده به ارث می‌برد. اگر اصلی mux گیر کرده باشد، باز کردن پنجره دیگر مسیر را دوباره آزمایش نمی‌کند.

تأیید تنظیم از ابتدا تا انتها

روی سرور، پیکربندی مؤثر دیمن را بیرون بریزید نه اینکه فایل را بخوانید و حدس بزنید کدام include برده است:

sshd -T | grep -i clientalive

سپس یک نشست واقعی را با خروجی اشکال‌زدایی روشن تماشا کنید. کلاینت وقتی شمار ته می‌کشد یک خط مهلت چاپ می‌کند و برچسب‌های زمانی اطراف آن نشان می‌دهند که سکوت پیوسته بود یا کاوش‌ها اصلاً فرستاده نشدند. نشستی که بدون هیچ ترافیک کاوشی می‌میرد معمولاً کلیدواژه را در بلوکی دارد که هرگز منطبق نشده است.

دو بررسی برای هر میزبانی که فقط از راه تونل به آن می‌رسید ارزش افزودن دارد: تأیید کنید که فاصله حل‌شده همانی است که قصد داشتید، و تأیید کنید که آن فاصله ضربدر شمار از مهلت بی‌کاری روی دروازه VPN کوتاه‌تر است. وقتی عدد دوم بزرگ‌تر است، دروازه اول جریان را بی‌صدا دور می‌ریزد و کاوش SSH هرگز فرصت گزارش چیزی را پیدا نمی‌کند.