ما الذي يضيفه bypass-dhcp فعلاً إلى خطة توجيه OpenVPN

يجمع ملف التعريف الذي يحمل redirect-gateway def1 bypass-dhcp بين تجاوز افتراضي لـ IPv4 واستثناء واحد ضيق. يقرأ الناس الكلمة الأخيرة ويتوقعون حلاً عاماً لاتصالات الهاتف المحمول، ثم يقضون بعد ظهر كاملاً في نظرية DHCP لم يدعمها هذا العلم قط. كل جزء يفعل شيئاً واحداً، والاستثناء أصغر بكثير من سمعته.

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

علمان، ومهمتان غير مترابطتين

مع def1، يضيف العميل نصفين افتراضيين لـ IPv4 بدلاً من استبدال المسار الافتراضي الموجود أصلاً. يغطي 0.0.0.0/1 النصف الأدنى من فضاء العناوين ويغطي 128.0.0.0/1 النصف الأعلى، فيصلان معاً إلى كل وجهة بينما يبقى كل منهما أكثر تحديداً من 0.0.0.0/0. لذلك يبقى المسار الافتراضي الأصلي في الجدول دون أن يفوز بتلك العمليات البحثية، ما يُبقي البوابة القديمة قابلة للوصول إلى أي شيء يوجّهه العميل صراحة. كما يترك مسارين افتراضيين متداخلين في الجدول، ولهذا قد يبدو تفريغ جدول التوجيه أغرب مما يوحي به ملف التعريف.

bypass-dhcp منفصل، ولا يمس المسار الافتراضي إطلاقاً. يوثّق دليل OpenVPN 2.6 أنه يضيف مساراً مباشراً إلى خادم DHCP غير موجود على الشبكة الفرعية المحلية، فتمر حركة تجديد الإيجار خارج النفق، ويشير إلى أن هذا السلوك مطبّق في عملاء Windows وقد لا يتوفر في مكان آخر.

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

ما الذي يغطيه الاستثناء فعلاً

يُظهر جدول توضيحي بعد اتصال ناجح الشكل: نصفان افتراضيان عبر النفق، ومسار مضيف واحد لخادم DHCP عبر البوابة الفيزيائية. اقرأه كشكل، لا كعناوينك الخاصة.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

تحقق مما ثبّته العميل حقاً

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

أبقِ المسار إلى نقطة نهاية VPN قابلاً للاستخدام في الوقت نفسه. استثناء نقطة النهاية هذا مطلب مختلف عن استثناء DHCP، وبدونه قد يلتقط النفق النقل الذي يبقيه عاملاً.

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

بقية المسار ليست في هذا العلم

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

يحتاج تحليل الأسماء و IPv6 كلٌّ منهما إلى سياسته الخاصة. تجاوز IPv4 لا يوجّه المحلّل إلى خادم على جانب النفق ولا ينشئ تغطية IPv6، والعميل الذي يعيد توجيه v4 فقط يترك مسار v6 دون مساس.

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