لماذا لا يمكن لحرف بدل في توجيه المسار في OpenVPN أن يعمل

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

ما الذي يثبّته المسار، وما الذي لا يقرأه أبدًا

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

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

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

عندما تكون الوجهة بادئة فعلًا

إذا كان الهدف شبكة خاصة معروفة، فاكتب البادئة. على سبيل المثال من مساحة التوثيق، يبدو مضيف واحد وشبكة فرعية هكذا:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

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

عندما تكون وحدة العمل اسم مضيف

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

يمكن لملف إعداد الوكيل التعبير عن ذلك الاختيار. القواعد التوضيحية أدناه ترسل نطاقًا واحدًا ونطاقاته الفرعية إلى وكيل وكل ما عدا ذلك مباشرة:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

ما لا يغطيه خيار الوكيل

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

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

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

اختبار المسارين، لا المسار السعيد فقط

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

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