نطاق VPN الخاص بك في dnsmasq ليس نقل منطقة

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

ما قبله العميل ليس ما عرضته البوابة

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

هذا التمييز يفسر معظم التقارير عن نطاق لم يصل قط. لقد عُرض، ولم يُطبق.

نوعان من إدخالات النطاق

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

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

localhost في resolv.conf ليس خطأ

عند استخدام resolver محلي للتخزين المؤقت، يشير ملف النظام إلى عنوان loopback ولا شيء غيره. هذا الإدخال يحدد المستمع المحلي، لا الخوادم الأعلى التي سلمها المدير إليه. سيكون عنوان الشركة غائبًا عن الملف بشكل مشروع.

استبدال ذلك الإدخال بـ resolver عام هو الإصلاح الخاطئ الكلاسيكي. يعيد حل الأسماء العام ويهمل السياسة الشرطية في التعديل نفسه.

لا تخلط بين الـ backends

نسخة dnsmasq المُدارة وresolver النظام برنامجان مختلفان بإعداد مختلف وطرق عرض حالة مختلفة. أمر الحالة لأحدهما لا يقول شيئًا مفيدًا عن الآخر.

حدد أي backend تم إعداد المدير لاستخدامه، ثم اقرأ الإعداد المُنشأ لذلك الـ backend بدلًا من ملف على مستوى التوزيعة يصادف وجوده. يكتب المدير إعداد النسخة الخاصة به ويدعم خيارات مخصصة لتلك النسخة، لذا فإن تعديل ملف عام غير ذي صلة لا يغير شيئًا ويبدو كتغيير بلا تأثير. تشغيل daemon ثانٍ على المنفذ 53 أسوأ من عديم الفائدة، لأن برنامجين الآن لا يتفقان على من يملك المنفذ. أثبت الملكية أولًا، ثم عدّل حيث يقرأ ذلك المالك.

اختبر مساحة الأسماء، ليس الإجابة فقط

استعلم عن اسم خاص واحد مسموح به واسم تحكم عام واحد عبر المسار المعتاد للتطبيق. الاستعلام المباشر من خادم الشركة يثبت وجود السجل؛ ولا يثبت أن العميل اختار ذلك الخادم. الاستعلام الثاني هو الذي يختبر السياسة.

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