هل تشغّل عميل VPN عبر SSH؟ ثبّت مسارك الخاص أولًا

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

سجّل المسار قبل أن تبدأ

ip route show default يذكر البوابة والواجهة الحاليتين، في حين أن ip route get 203.0.113.9 يُظهر الواجهة وعنوان المصدر اللذين ستستخدمهما النواة لجلسةك. احفظ المخرجين كليهما. بعد أن يصعد النفق، يجب أن يظل هذان الأمران يصفان المسار الفيزيائي، وإذا وصفا النفق بدلًا من ذلك، فالجلسة تعيش أصلًا على وقت مستعار.

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

ثبّت العنوان في إعداد العميل نفسه

المسار المضاف يدويًا يختفي عند إعادة التشغيل ويسابق تحديثات الجدول التي يجريها العميل، لذا ضع الاستثناء حيث يُدار الجدول. في OpenVPN تُحلّ الكلمة المفتاحية net_gateway إلى البوابة التي كانت موجودة قبل النفق، لذا يُبقي route 203.0.113.9 255.255.255.255 net_gateway عنوانًا واحدًا بالضبط خارجها. ويحتاج WireGuard إلى أسلوب مختلف لأن wg-quick يدير المسارات بنفسه: اضبط Table = off وأضف الاستثناء في PostUp، مع PostDown مطابق يزيله. يعبّر الشكلان عن النية نفسها، وكلاهما يحصر الاستثناء في عنوان واحد بدلًا من إضعاف النفق لكل شيء.

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

أو أخرج الجدول الرئيسي من المعادلة

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

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

افترض أن التثبيت قد يفشل

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

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

تحقق بالترتيب الذي يهم

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

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