كيف تقرأ توجيه VPN DNS لكل وصلة من مخرجات resolvectl

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

ما تخبرك به كل كتلة خاصة بوصلة

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

عنوان مموّه مثل 127.0.0.53 في /etc/resolv.conf لا يقول إلا إن المموّه في المقدمة. وهو لا يسمّي المنبع الذي أجاب، ولهذا يتوقف التشخيص القائم على resolv.conf وحده.

اقرأ أنواع إدخالات النطاق الثلاثة قراءة صحيحة

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

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

استعلم عن اسم وانظر أي وصلة أجابت

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

resolvectl status
resolvectl query host.corp.example

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

افصل توجيه الأسماء عن توجيه الحزم

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

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

سجّل العنوان الذي حُلّ إليه الاسم إلى جانب الوصلة. الاسم الصحيح الذي يشير إلى عنوان خاطئ مشكلة سجل لا مشكلة توجيه.

أعد التحقق بعد تغيّر الوصلة

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

شارك فقط الأسماء وسياق الخوادم التي يحتاجها التقرير، لأن اللواحق الداخلية تكشف الطوبولوجيا. توثيق systemd-resolved حول توجيه النطاقات يغطي قاعدة أطول مطابقة وسلوك التلدة، وقراءته مرة واحدة تمنع معظم أخطاء الجدول أعلاه: توجيه استعلامات systemd-resolved.