ما الذي يوقفه route-nopull في OpenVPN فعلاً من دفع الخادم
يُسقط route-nopull المسارات وخيارات DHCP المدفوعة، لا المصافحة. اختر بينه وبين pull-filter أو لا شيء، ثم أضف المسارات بنفسك.
تضع route-nopull في ملف تعريف العميل لتوقف النفق عن ابتلاع مسارك الافتراضي، والآن أصبحت شبكة المكتب الفرعية غير قابلة للوصول بينما لا يزال العميل يقول إنه متصل. الملاحظتان صحيحتان، ولم يفشل شيء. يطلب العلم من العميل تخطي المسارات وإدخالات DHCP التي يدفعها الخادم، وهو تعليم أضيق مما يتوقعه معظم الناس عند إضافته. ما يبقى هو نفق عامل لا رأي له في الوجهات التي ينبغي أن يستخدمها.
هذه الفجوة هي القرار كله الذي يتناوله هذا المقال. إما أن يصف الخادم الشبكة، وإما أن يصفها العميل، والعلم يسلّم تلك المهمة إلى العميل دون أن يفعل أي شيء منها نيابة عنك.
ما الذي يطفئه العلم وقت الاتصال
عميل OpenVPN الذي يسحب عادةً يأخذ حزمة من الخادم بعد المصادقة: المسارات، وإعادة توجيه البوابة الافتراضية، وخوادم DNS، وبعض توجيهات الضبط. مع route-nopull ساريًا يظل العميل يقبل الجلسة، ويظل يتحقق من الشهادات، ويظل يتفاوض على الأصفار ورسائل الإبقاء، ويظل يرفع الواجهة. ما يُسقطه هو تطبيق سطور route المدفوعة وسطور dhcp-option المدفوعة، بما فيها DNS.
يأتي الالتباس من مؤشر أخضر يجاور تطبيقًا ميتًا. النفق موجود؛ وأما ربط الوجهات بذلك النفق فغير موجود. لا شيء في لوحة حالة العميل يميّز «متصل ويوجّه» عن «متصل وخامل»، لأن الحالتين متطابقتان من وجهة نظر النفق.
لماذا قد لا يوجّه نفق حيّ شيئًا
تظهر الواجهة بعنوانها الخاص، وعلى وصلة نقطة إلى نقطة غالبًا لا شيء أكثر تحديدًا من مسار مضيف إلى النظير. لا تصبح الشبكة الفرعية الخاصة قابلة للوصول إلا عندما يشير مسار ما إلى تلك الواجهة بالبادئة الصحيحة، ومع تعطيل الدفع لا يصل ذلك المسار أبدًا. ولا يستطيع ملف التعريف المُنزّل المساعدة عادةً، لأنه كُتب على افتراض أن الخادم سيزوّد هذه المعلومات بالضبط. لهذا يمكن أن تبدو الواجهة سليمة بينما تبقى الشبكة الفرعية معتمة.
قراءة ملف التعريف تثبت القليل جدًا إذن. اقرأ الحالة الجارية بدلًا من ذلك، على الجهاز المتصل:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10عنوان بلا مسار شبكة فرعية في الأمر الثاني هو بصمة هذه المشكلة. الأمر الثالث يجيب بعد ذلك عن السؤال الذي يهم المستخدمين فعلاً، لأنه يبلّغ عن الواجهة التي ستختارها النواة لوجهة معينة بدلًا من القائمة التي كنت تأمل أن يستخدمها. وإذا أجاب عبر وصلة الشبكة الفعلية، فالنفق ليس في المسار إطلاقًا.
يفشل حل الأسماء لسبب متعلق بالأمر لا لسبب منفصل. تُتخطى إدخالات dhcp-option DNS المدفوعة بالعلم نفسه، فتذهب الاستعلامات عن المضيفات الداخلية إلى أي محلل وفّرته الشبكة المحلية. لا يملك ذلك المحلل منطقة للمكتب، فيفشل الاستعلام أو يعيد إجابة عامة، ويبدو الفشل مشكلة خادم بينما هو مشكلة إعداد عميل. اختبار عنوان قبل اسم هو ما يفصل بين الاثنين.
الاختيار بين العلم ومرشح البادئات
يحل الخياران شكلين مختلفين من الشكوى نفسها، والاختيار السيئ هو ما ينتج حالة «متصل بلا فائدة». أحدهما يستبدل السياسة المدفوعة بالكامل، والآخر يعدّلها بالبادئة. يعطي الجدول النسخة القصيرة، والفقرة بعده تغطي الجزء الذي يفاجئ الناس.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter مطابق بادئات بثلاثة أفعال، فيمكنه قبول عائلة من السطور، أو تجاهلها بصمت، أو رفض الاتصال كليًا عند ظهور بادئة. هذا السلوك الأخير هو الجدير بالمعرفة: قاعدة الرفض تحوّل خلافًا في السياسة إلى مصافحة فاشلة بدلًا من إغفال هادئ. يسرد دليل OpenVPN 2.6 البادئات المقبولة والمعنى الدقيق لكل فعل.
المسار الوسطي الشائع هو رفض redirect-gateway وحده وترك مسارات المكتب وDNS تصل كما هو مقصود. هذا يُبقي الدفع عاملًا للأجزاء التي يفهمها الخادم أفضل منك، مع منع السطر الوحيد الذي سيستولي على مسارك الافتراضي.
إضافة المسارات ومحلل أسماء يدويًا
إن أبقيت العلم، فعلى ملف التعريف أن يقول ما كان الخادم سيقوله. تُطبّق توجيهات route على جانب العميل بعد إنشاء الاتصال، فتعمل إلى جانب العلم بدلًا من أن يحجبها. ضعها في ملف التعريف لا في سطر أوامر تفاعلي، وإلا فلن يعيد الاتصال التالي إنتاج الحالة العاملة.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53سطر DNS في موضع غير مريح: هو توجيه على جانب العميل، لكن بعض العملاء يطبّقونه فقط عبر تكامل DNS في النظام الأساسي، وقد يكتب فوقه عندما تتغير الوصلة. على مضيف systemd، ضبط المحلل على واجهة النفق مباشرة أكثر توقعًا من الأمل في أن يفوز العميل بمسابقة الأولوية:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comنطاق التوجيه يهم بقدر ما يهم العنوان. بدونه قد تُرسل الاستعلامات عن الأسماء العامة إلى المحلل الداخلي أيضًا، وأي محلل داخلي يرفض الاستعلامات العودية سيكسر التصفح مع ترك المنطقة الخاصة تعمل. ومعه تُوجَّه الأسماء الواقعة تحت تلك اللاحقة فقط إلى محلل النفق ويتبع كل شيء آخر الوصلة الفعلية.
التحقق من النتيجة: العنوان والاسم والمسار الخارجي
ثلاثة اختبارات تفصل الإخفاقات المحتملة. اجلب العنوان الخاص عبر IP، ثم المضيف نفسه بالاسم، ثم موقعًا عامًا عاديًا. IP يعمل مع اسم فاشل يشير إلى المحلل؛ وIP فاشل مع اسم يعمل يشير إلى التوجيه؛ وفشل الاثنين يعني عادةً أن النفق ليس في المسار.
ثم انظر إلى الخارج لا إلى الداخل. على مسار نقطة النهاية للنفق أن ينجو من التغيير، وأي حجب فاشل يجب أن يُقصر على النفق دون أن يلتقط نقطة النهاية. العميل الذي يواصل التصفح بعد سقوط النفق مشكلة سياسة لا مشكلة توجيه، ولن تظهر في أي من الاختبارات الثلاثة أعلاه.
اكتب القائمة النهائية في توثيق ملف التعريف: المسارات، والمحلل، والنطاقات، وسبب وجود كل منها. إعادة اتصال تعيد إنتاج الجدول نفسه هي الدليل الوحيد على أن السياسة المحلية مكتملة. إن ظلت التطبيقات تفشل والنفق قائم والاختبارات الثلاثة كلها ناجحة، فالمكان التالي الذي يجب النظر فيه هو فئة مشاكل «متصل لكن غير متصل» لا الشهادات التي تحققت بالفعل.