SSH ينقطع على VPN كل دقيقة؟ المشكلة ليست في keepalive

يتصل SSH، ويعمل نحو دقيقة، ثم يتجمّد على الفاصل نفسه تقريبًا في كل مرة. التفسير الشائع هو مهلة خمول، فيخفّض الناس MTU ويضبطون نبضات بقاء العميل. رابط WireGuard عملت عليه كان قد مرّ بكل ذلك: MTU نفق أصغر، وإعدادات بقاء العميل، ونبض بقاء نفق مُهيّأ. استمرت الانقطاعات دون تغيير. تبيّن أن السبب مسار LAN غير متناظر، والنمط يستحق التعرّف عليه لأنه يهزم كل إصلاح قائم على المؤقتات.

نبض البقاء يثبت أن مضيفك ما زال راغبًا في الإرسال. وهو لا يستطيع أن يجعل جهازًا يحتفظ بالحالة يرى ردًّا لا يعبره أبدًا.

الأسطورة: نبضات البقاء تصلح انقطاعًا صامتًا

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

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

العلامة هي الانتظام مع بقاء الجلسة صالحة للاستخدام داخل ذلك الفاصل. مهلات الخمول تضرب حين لا يحدث شيء؛ وهذه تضرب وأنت تكتب.

ما تفعله البوابة الإضافية فعليًا

ضع الحاسوب المحمول وبوابة VPN على الشبكة المحلية نفسها، مع جدار حماية LAN منفصل كبوابة افتراضية. يرسل الحاسوب حركة VPN إلى جدار الحماية، ويمرّرها جدار الحماية إلى البوابة، ثم تعود ردود البوابة مباشرة عبر الشبكة المحلية إلى الحاسوب. ذلك الجزء الثاني لا يمرّ بجدار الحماية أبدًا، لذا يحتفظ جدول حالته بنصف اتصال.

العناوين أدناه تعكس ذلك الترتيب:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

تحوّل إعادة التوجيه ومعالجة الحالة بعد ذلك مصافحة عاملة إلى اتصال يموت لاحقًا بدل أن يموت فورًا. التأخير هو انتهاء صلاحية قيد الحالة أو فشل فحص أكثر صرامة، ولهذا يبدو الفاصل آليًا إلى هذا الحد.

لا شيء من هذا يظهر في إعداد العميل، ولهذا يبدأ البحث عنه عادةً في الملف الخطأ.

اختر مسارًا واحدًا متعمَّدًا

بالنسبة للتخطيط أعلاه، فإن توجيه الشبكة الفرعية البعيدة مباشرة إلى بوابة VPN يزيل نصف الاتصال:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

هذه عناوين أمثلة. يجب أن تكون القفزة التالية قابلة للوصول على شبكتك المحلية، وأن تكون البادئة هي الشبكة البعيدة المقصودة، ويعرض الأمر الثاني النتيجة قبل أن تعتمد عليها. إذا لم تكن البوابة على شبكتك الفرعية، فهذا المسار ليس الإصلاح الذي تريده.

إذا كان جدار الحماية مقصودًا لمراقبة الحركة بين تلك الأنظمة، فالتفاف المسار حوله تصميم خاطئ. اجعل الاتجاهين يعبران الحدود بدلًا من ذلك، واضبط المسارات على كل جانب بحيث يتطابق مسار العودة. الهدف مسار واحد متعمَّد، لا فحص حالة أقل.

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

اختبره من الطرفين

اقرأ مسار الحاسوب نحو الوجهة ومسار الوجهة عائدًا نحو الحاسوب؛ فهما قراران منفصلان، وواحد فقط منهما هو الخاطئ على الأرجح. ping ينجح من البوابة نفسها يمكن أن يخفي المشكلة تمامًا، لأنه ينشأ على الجهاز الذي مساره صحيح أصلًا. تحتاج إلى الاتجاهين كما يراهما طرفا الجلسة الفعلية.

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

متى يكون اللا تناظر مقبولًا

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

الجواب الدائم يسمّي المسارين، والجهاز الذي يجب أن يرى كليهما، والمسار الذي يجعل ذلك ممكنًا. إذا لم تستطع تسمية الجهاز، فلم تجد السبب بعد.