ifconfig-noexec لن ينقذ جلسة SSH: ما الذي يفعله
إنه يمنع OpenVPN من إعداد عنوان الواجهة الخاص به. وهو لا يحجز مسار رد لجلسة SSH، ولا يعطّل كل تغيير للمسارات، ولا يوفّر العنوان المفقود.
في مكان ما داخل موضوع على منتدى، يُطرح ifconfig-noexec كإصلاح يُبقي جلسة SSH حيّة عند صعود النفق. يبدو المنطق معقولًا حتى تتحقّق ممّا تمسّه الخيارات. فهو يمنع OpenVPN من تهيئة عنوان واجهة النفق ويُسلّم تلك القيم إلى السكربتات بدلًا من ذلك؛ وليس له علاقة بمكان ذهاب الردود على اتصال إدارتك. والاعتقاد بغير ذلك ينتج نفقًا بلا عنوان صالح وجلسة SSH لا تزال تموت.
ما الذي يفوّضه الخيار فعلًا
افتراضيًا، يُشغّل العميل جهاز النفق ويُسند العنوانين المحلي والبعيد اللذين سلّمهما الخادم. وعند تعيين ifconfig-noexec، تُتخطّى تلك الخطوة، وتُصدَّر القيم المتفاوض عليها إلى بيئة السكربت كي يطبّقها شيء آخر.
الملكية تنتقل. ولا يُبتكر شيء مكانها.
إذن فالسؤال الذي يجيب عنه الخيار هو مَن يهيّئ الواجهة، والسؤال الذي لا يجيب عنه هو كيف تجد الحزم طريقها عائدًا إليك. أبقِ هذين منفصلين وإلّا أمضيت ليلة في تحرير المسارات للتعويض عن واجهة بلا عنوان.
ثلاثة خيارات متشابهة بمهام مختلفة
يصعب الخلط بين هذه العائلة لأن الأسماء تختلف بكلمة واحدة والأعراض تتداخل. اقرأ ما يمنعه كل خيار قبل اختيار أيٍّ منها.
| الخيار | ما الذي يتوقف عن الحدوث |
|---|---|
ifconfig-noexec | تهيئة OpenVPN لعنوان النفق بنفسه؛ تذهب القيم إلى السكربتات بدلًا من ذلك |
route-noexec | إضافة المسارات وإزالتها تلقائيًا؛ تذهب تفاصيل المسار إلى سكربت |
route-nopull | تُرفض المسارات التي يدفعها الخادم والخيارات المرتبطة بها مثل DNS |
هذه بدائل تُفهم كلٌّ على حدة، لا مجموعة تُلصق معًا. فكبح إعداد العنوان لا يكبح تغييرات المسارات ولا قواعد الجدار الناري ولا الخيارات المدفوعة التي تحمل DNS. والسكربت المفوّض حرّ أيضًا في تغيير المسارات، وهذا قرار تسلّمه بدلًا من أن تتجنّبه.
إن كان عميل مورّد يغلّف المحرّك، فاستخدم تكامله المدعوم بدلًا من إسقاط توجيه منخفض المستوى في ملف تعريف والأمل بأن يحترمه الغلاف. فالأغلفة كثيرًا ما تعيد توليد ملف التعريف عند الاتصال، فيختفي التعديل اليدوي دون خطأ. تحقّق من مكان احتفاظ العميل بإعداداته قبل أن تمضي ليلة على الملف. وهذا ينطبق على كل صف في الجدول، لا على الصف الذي جئت من أجله فقط.
جلسة SSH التي أردت حمايتها
لاتصال SSH عنوان مصدر وعنوان وجهة ومسار رد. على خادم ثبّت للتوّ افتراضي نفق كامل، يطابق الرد على عنوانك العام النفق، فيُسقطه بوابة VPN.
لا شيء في إعداد عنوان واجهة النفق يغيّر ذلك.
الذي يصلحه هو مسار أكثر تخصيصًا لعنوان إدارتك عبر بوابة ما قبل النفق، أو قاعدة سياسة توجّه تلك الحركة، إضافة إلى إعدادات التصفية التي يطبّقها مضيفك. والمشكلتان تظهران معًا أحيانًا، وهكذا يُحسب إحداهما علاجًا للأخرى. اختبرهما منفصلين: أطلق النفق دون الخيار، وانظر إلى عنوان الواجهة ومسار الرد، ثم قرّر أيّهما معطوب فعلًا.
ما الذي يجب أن يتولاه السكربت المفوّض
إن أردت حقًا أن يهيّئ مالك آخر الواجهة، فعدّد العمل: طبّق العنوانين المحلي والبعيد، وأطلق الجهاز، واستعد العنونة أو أزلها عند الإغلاق، وافعل الأمر نفسه مرة أخرى بعد إعادة الاتصال. ويجب ألا تُثبَّت قيم جلسة ناجحة واحدة في الشيفرة، لأن الخادم قد يمنح زوجًا مختلفًا في المرة القادمة.
متغيرات البيئة التي يصدّرها العميل هي المدخل الوحيد المدعوم لهذا العمل.
env | grep -E '^ifconfig_|^route_'داخل سكربت route-up تكون تلك المتغيرات متاحة؛ أما من مهمة cron أو صدَفة يدوية فليست كذلك. تأكّد من أي خطاف دورة حياة تستخدمه نسختك، وتأكّد من أن الخطاف يعمل بامتياز كافٍ لتغيير الواجهة، إذ قد يكون العميل هبط بالفعل إلى مستخدم غير مميّز.
اختبر دورة الحياة كاملة، لا جلسة واحدة
أطلق النفق، وتحقق من العنوان على الجهاز، ثم أعد الاتصال وتحقق منه مرة أخرى. الإعداد الذي يعمل مرة ويفشل في المحاولة الثانية يعني عادة أن الخطوة المفوّضة تعمل عند الاتصال الأول فقط.
ثم اختبر معياري القبول معًا: اتصال SSH جديد عبر مسار الإدارة المقصود يعمل، وتطبيق مسموح يستخدم النفق بشكل صحيح.
جلسة SSH قديمة تصادف أنها صمدت بينما النفق بلا عنوان ليست نجاحًا، وهي بالضبط الحالة التي ينتجها هذا الخيار عندما لا يتولى أحد العمل. تحقق أولًا من عنوان الواجهة، ثم من مسار رد الإدارة، ثم من التطبيق. وإن كان اثنان من الثلاثة خطأً، فقد نقل الخيار العمل دون أن يمنحه مالكًا.