النفق الكامل قتل جلسة SSH لديك: ثبّت مسار العودة

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

ما الذي يثبته redirect-gateway فعليًا

في صيغته def1، redirect-gateway يضيف 0.0.0.0/1 و 128.0.0.0/1 بدلًا من الكتابة فوق المسار الافتراضي. هذان النصفان يغطيان فضاء العناوين بأكمله مع بقاء كل منهما بادئة أطول من 0.0.0.0/0، لذا فإن أي وجهة بلا تطابق أكثر تحديدًا تدخل الآن النفق. هذا هو المبدأ الذي يجب التمسك به، لأن كل إصلاح أدناه يعمل عبر تثبيت تطابق أكثر تحديدًا.

عنوان الإدارة الخاص بك هو إحدى تلك الوجهات.

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

ip route show table main | head -n 20
ip route get 198.51.100.23

اعثر على عنوان المصدر لديك والمسار السابق للنفق

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

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

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

ثبّت مسار مضيف يتفوق على نصفي المسار الافتراضي

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

تحقق بالاستعلام بدلًا من فحص الجدول: يجب أن يذكر الجواب eth0 والبوابة، ولا يذكر أبدًا tun0.

يضيف OpenVPN بالفعل مسار مضيف إلى عنوان خادم VPN نفسه للسبب نفسه، فالنمط مألوف وعنوان الإدارة ليس سوى استثناء آخر. لا تلجأ إلى route-nopull لإصلاح هذا، لأنه يتخلى عن المسارات المدفوعة التي يحتاجها النفق، بما فيها الشبكة البعيدة وخيارات DNS.

اجعلها تصمد أمام إعادة الاتصال

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

سواء كان سكربت route-up أو خطاف pre-up لمدير الشبكة، كلاهما يعمل، والفحص الموثوق هو إعادة اتصال تتبعه نفس الاستعلام.

على Windows المكافئ هو مسار دائم يضاف باستخدام -p، يصمد أمام إعادة التشغيل لكنه يظل بحاجة إلى الإشارة إلى البوابة الصحيحة بعد تغيير الشبكة. أيا كانت المنصة، اكتب السبب بجانب المسار: المدير التالي يحتاج إلى معرفة أنه موجود لحماية جلسة إدارة، لا لأن تصميم الشبكة اقتضاه.

عندما لا يكفي مسار مثبت بعد

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

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

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