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

حذف إعادة التوجيه ليس إلا نصف التغيير

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

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

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

pull-filter مطابقة، لا مفتاح

تزيل توجيهات pull-filter الخيارات المدفوعة التي تطابق أسماؤها بادئة، وهذا كل ما تفعله. تجاهل إعادة التوجيه يترك كل خيار مدفوع آخر في مكانه، وهو ما تريده عادةً: المسارات وإعدادات DNS وقيمة بوابة المسار تصل جميعاً. ولا تستطيع أيضاً إزالة توجيه مكتوب في الملف الشخصي المحلي، لأن التصفية تنطبق على ما يدفعه الخادم.

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

route-nopull قرار أوسع مما يبدو. فهو يمنع العميل من قبول المسارات المدفوعة والخيارات على غرار DHCP كمجموعة، وهو ما يختلف عن تصفية خيار واحد.

اكتب قائمة المسارات من التطبيق إلى الخارج

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

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

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

DestinationIntended path
10.60.0.0/16Tunnel, for the approved application services
10.61.0.53/32Tunnel, to reach the internal resolver
corp.example queriesInternal resolver, selected per namespace
Everything elseLocal path and local resolver

اجعل DNS يتبع المسار نفسه

المسار إلى الخادم ليس سياسة خادم. على عميل systemd-resolved تكون النتيجة الدلالية نطاق توجيه لمساحة الأسماء الخاصة يشير إلى الخادم الداخلي، وهذا ما يجعل تلك الأسماء وحدها تستخدمه. أما عميل Windows فيحتاج إلى آلية سياسة نطاقات خاصة به. وسطر خادم DNS في الملف الشخصي لا يثبّت أياً منهما بمفرده.

افحص ما اختاره نظام التشغيل لا ما طلبه الملف الشخصي. على Linux يعرض resolvectl status النطاق والخادم لكل وصلة؛ وعلى Windows يكون جدول سياسة نطاقات الأسماء هو الدليل المكافئ.

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

تحقّق من النصفين عند إعادة الاتصال

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

سجّل السياسة النهائية في جملة واحدة: هذه البادئات والأسماء تستخدم هذا الاتصال، وكل ما عداها يتبع المسار المحلي. ثم احتفظ بها في الملف الشخصي بدلاً من إصلاح إعدادات المحول بعد كل تسجيل دخول.

مقالات ذات صلة