ServerAliveInterval في SSH عبر VPN: أي طرف يرسل الفحص؟

معظم النصائح حول إبقاء جلسة SSH حيّة تتوقف عند «أضف ServerAliveInterval 30» وتترك الأجزاء المفيدة خارجًا. الكلمة المفتاحية مؤقّت في جهة العميل لا ينطلق إلا عندما تكون القناة هادئة، وهو يعدّ الفحوصات غير المجابة لا الثواني، ويعيش في ملف يفوز فيه أول قيمة مطابقة. أخطئ في هذه الخصائص الثلاث وستسقط جلسة VPN سليمة رغم ذلك، بينما تظل جلسة ميتة معلّقة.

الاتجاهان يخصّان برنامجين خادمين مختلفين

ServerAliveInterval يقرأه عميل ssh لديك. ClientAliveInterval يقرأه sshd على الطرف البعيد ويفحص في الاتجاه المعاكس، من الخادم إلى العميل. ليسا اسمين بديلين ولا يتعاونان، لذا فإن ضبط أحدهما لا أثر له على سلوك الطرف الآخر. الخلط بينهما هو السبب المعتاد في أن يبدو إصلاح ناجحًا على مضيف ولا ينجح على التالي.

كلاهما يقبل الصفر. عند الصفر لا يرسل العميل شيئًا على الإطلاق، وعلى جهة الخادم فإن ClientAliveCountMax مساوٍ للصفر يعطّل قطع الاتصال الذي كان سيتبع الفحوصات غير المجابة.

ما يثبته الفحص وما لا يثبته

بعد مرور الفترة المضبوطة دون وصول أي بيانات من الخادم، يرسل العميل طلبًا صغيرًا عبر القناة المشفّرة القائمة وينتظر ردًا. ServerAliveCountMax يحدد عدد تلك الطلبات التي يجوز أن تبقى دون إجابة قبل أن تُنهى الجلسة. مع فترة 60 وعدد 3 يستسلم العميل بعد نحو ثلاث دقائق من الصمت، وهذا الرقم خاص بإعدادك لا بمعيار شبكي. اترك الفترة على قيمتها الافتراضية 0 فلن يُرسل أي فحص أبدًا، ولهذا يستطيع عميل قياسي أن يبقى على اتصال ميت إلى ما لا نهاية.

لأن التبادل يجري داخل ناقل SSH، فإن الرد يثبت أن عملية SSH عند الطرف الآخر ما زالت تقرأ وتكتب. وهو لا يقول شيئًا عن البرنامج الذي بدأته داخل تلك الجلسة: فقد يكون عميل قاعدة بيانات أو منفذًا معاد توجيهه أو نصًا برمجيًا طويل التشغيل متعطلًا بينما يجيب الناقل عن الفحوصات بارتياح.

TCPKeepAlive آلية منفصلة على طبقة أدنى. النواة تتولاها، وهي غير مشفّرة، ويمكن لطرف مقابل توقّف برنامج sshd لديه أن يلبيها مع ذلك. ولهذا يكون الفحص على مستوى 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 يكون الفحص ملكًا للاتصال الرئيسي، والجلسة الجديدة عبر رئيسي قائم ترث ما تفاوض عليه ذلك الرئيسي. وإذا تعطل رئيس المعدد، فلن يختبر فتح نافذة أخرى المسار من جديد.

تأكيد الإعداد من طرف إلى طرف

على الخادم، أخرج إعداد البرنامج الفعلي بدلًا من قراءة الملف والتخمين أي تضمين فاز:

sshd -T | grep -i clientalive

ثم راقب جلسة حقيقية مع تمكين خرج التصحيح. يطبع العميل سطر مهلة عندما ينفد العدد، وتُظهر الطوابع الزمنية حوله هل كان الصمت متواصلًا أم أن الفحوصات لم تُرسل أصلًا. الجلسة التي تموت دون أي حركة فحص تكون عادةً كلمتها المفتاحية في كتلة لم تطابق قط.

ثمة فحصان يستحقان الإضافة لأي مضيف لا تصل إليه إلا عبر نفق: تأكيد أن الفترة المحلولة هي التي قصدتها، وتأكيد أن تلك الفترة مضروبة في العدد أقصر من مهلة الخمول على بوابة VPN. عندما يكون الرقم الثاني أكبر، تُسقط البوابة التدفق أولًا بصمت فلا يحصل فحص SSH على فرصة للإبلاغ عن شيء.