مسارك الافتراضي القديم يبقى بعد OpenVPN عمدًا

تتصل بالنفق وتشغّل ip route، فلا تزال البوابة الافتراضية الأصلية موجودة. أول ما يخطر لك أن العميل فشل في الاستيلاء على المسار، فتحذف الافتراضي يدويًا وتفقد الاتصال بالكامل. من المفترض أن يبقى ذلك السطر. مع redirect-gateway def1، يثبّت OpenVPN مسارين أكثر تخصيصًا يتقدّمان على الافتراضي العادي بدلًا من استبداله. تبقى البوابة القديمة وتتوقف عن حمل حركة المرور التي كنت تختبرها.

ما الذي يفعله def1 فعلاً

يضيف العلم 0.0.0.0/1 و128.0.0.0/1، وكلاهما يشير إلى النفق. يغطي 0.0.0.0/1 كل عنوان يكون ثمنه الأول من 0 إلى 127، ويغطي 128.0.0.0/1 من 128 إلى 255، أي أن لكل وجهة IPv4 تطابقًا أكثر تخصيصًا من الافتراضي القديم. طول البادئة، لا المقياس، هو ما يحدد المسار الفائز.

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

لماذا /1 وليس /0

يختار التوجيه أطول بادئة مطابقة، لا أدنى مقياس، لذا يتفوق /1 على /0 مهما كان مقياس الافتراضي. يوجد النصفان معًا لأن /1 واحدًا يغطي نصف الفضاء فقط؛ فمع وجود 0.0.0.0/1 وحده، يظل كل ما فوق 128.0.0.0 يتبع الافتراضي القديم، وهذا ينتج العرض المحيّر حيث تعمل بعض المواقع ولا تعمل أخرى.

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

اقرأ جدول توجيه فعليًا

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

المهم هو العلاقة: نصفان محدّدان فوق افتراضي عام واحد. يبقى سطر البوابة القديمة لأن شيئًا لم يستبدله.

تحقّق من المسار الذي تأخذه الحزمة فعليًا

قد تفوز مسارات أكثر تخصيصًا رغم ذلك: فمسار لنطاق خاص أو شبكة فرعية محلية أو عنوان خادم VPN نفسه أطول من /1. يحتاج النفق إلى مسار خارجي إلى خادمه، وإعادة إرسال ذلك الاتصال إلى النفق ستحطمه فورًا. على Linux، اسأل النواة بدل قراءة الجدول بالعين: ip route get مع الوجهة التي تهمك يطبع المسار المختار والواجهة والمصدر. إذا كان التوجيه بالسياسات مُعدًّا، فافحص القواعد أيضًا، لأن القاعدة قد تختار جدولًا آخر قبل الرجوع إلى الجدول الرئيسي.

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

ما لا يغطيه def1

مدخلان لـIPv4 لا يقولان شيئًا عن IPv6: فالمضيف المتصل بـIPv6 يظل يستخدم افتراضيه حتى يعيد شيء توجيه تلك العائلة بشكل منفصل، ولهذا يبدو أن بعض الحركة تتجاوز النفق على شبكة ثنائية الحزمة. العملاء ومديرو الشبكات الآخرون ينفّذون توجيه النفق الكامل بطريقة مختلفة، ولن تتطابق جداولهم. سلوك def1 الموصوف هنا يخص علم OpenVPN الموثّق، لا كل VPN على الجهاز.

مفتاح الإيقاف يجيب عن سؤال مختلف: ماذا تفعل الآلة عند سقوط النفق. أسبقية التوجيه تحدد إلى أين تذهب الحركة أثناء عمل النفق؛ ولا تحدد ما يفعله جدار الحماية بعد ذلك. ترتيب العمل: اقرأ الجدول، تأكد من وجود النصفين، شغّل ip route get للوجهة الفاشلة، افحص قواعد السياسات، ثم انظر إلى IPv6 بشكل منفصل. اترك الافتراضي القديم حيث هو.