النفق قائم، فلماذا يفشل الاسم الخاص مع ذلك؟
وجود نفق يعمل لا يعني أن العميل سأل المُحلِّل الصحيح. تحقّق من الجهة التي أجابت، ثم مرّر النطاق الذي يحتاج ذلك فقط.
كل شيء في الاتصال يبدو سليمًا: النفق قائم ووحدة التحكم تعرض نقطة النهاية الخاصة، ومع ذلك يفشل كل طلب في تصفية الأسماء. الخطوة الطبيعية هي إلقاء اللوم على النفق، لكنه غالبًا يظهر بريئًا. يُرسَل الاستعلام إلى خادم لا يعرف شيئًا عن المنطقة الخاصة. لن يغيّر أي تعديل في التوجيه تلك الإجابة، لأن المشكلة في الجهة التي سُئلت.
أي مُحلِّل وصل إليه الاستعلام؟
ابحث عن المُحلِّل المرتبط بكل وصلة قبل أن تنظر إلى النفق أصلًا. يعرض Linux خوادم كل وصلة عبر أمر حالة المُحلِّل، ويعرض macOS المُحلِّلات محددة النطاق في تفريغ إعداد DNS. إذا كانت الإجابة لا تزال تأتي من موجه المنزل، فلن تكون وصلة النفق قد استُشيرت قط.
resolvectl status
scutil --dns | head -40
dig +short internal.example.comتُخلط هنا مرحلتان: خادم يدفع عنوان مُحلِّل، وعميل يثبّته على الوصلة النشطة. قد يحتوي الملف الشخصي على الخيار، وقد يُظهر السجل وصوله، بينما يبقى نظام التشغيل يستخدم الخادم القديم. قارن السجل بما تبلغ عنه الوصلة، وثق بالوصلة.
استخدم عنوانًا تجيب عليه شبكة السحابة فعليًا
عادةً تجيب شبكات السحابة عن الأسماء الخاصة عبر عنوان محجوز يبعد اثنين عن قاعدة النطاق، فالشبكة التي تبدأ عند 10.0.0.0 تجيب عند 10.0.0.2. كما تنشر بعض مقدمي الخدمة مُحلِّلًا محليًا للوصلة يعمل دون معرفة النطاق، وهذا يساعد عندما يبني الشبكة شخص آخر. استعلم العنوان المرشح مباشرة قبل أن تدفعه إلى أي شخص. العنوان الذي ليس مُحلِّلًا يبدو تمامًا مثل إسقاط جدار حماية، لأن الاستعلام ببساطة لا يتلقى إجابة أبدًا.
إذا أجاب الاستعلام المباشر من داخل الشبكة وليس عبر النفق، فالمُحلِّل سليم والمسار بين النقطتين ليس كذلك. ينقل ذلك النتيجة إلى المسارات وإعادة التوجيه وقواعد الوصول بدلًا من ملف العميل.
النفق لا يحمل مساحة الأسماء
الحزم تعبر؛ الأسماء لا تعبر. يجب إبلاغ كل جانب بمساحة الأسماء التي تخص الجانب الآخر، وهي كائن منفصل يملكه من يملك المنطقة. الشكل المعتاد هو تمرير لمساحة أسماء واحدة، موجّه إلى مُحلِّل يمكن الوصول إليه عبر النفق.
عمليًا يحتاج كل اتجاه إلى قاعدته الخاصة، لأن الجانب الذي يملك المنطقة هو الذي عليه إرسال الاستعلام. يحتاج الاتجاهان إلى توجيه مصدر الاستعلام والسماح به، وعلى الجانب المجيب إرجاع الردود عبر النفق بدلًا من الإنترنت. أبقِ التمرير ضيقًا، بحيث تعتمد مساحة الأسماء الخاصة وحدها على الوصلة. إرسال كل استعلام عبرها يحوّل اعتمادًا صغيرًا إلى انقطاع كامل لحظة سقوط النفق.
امشِ على الحدود بالترتيب
اختبر المُحلِّل المثبّت على الوصلة النشطة، ثم استعلامًا مباشرًا إلى ذلك المُحلِّل، ثم الاستعلام نفسه من الجانب الآخر، وأخيرًا التطبيق الذي يستخدم الاسم نفسه. كل خطوة تعزل حدًا واحدًا، فالفشل يخبرك أين تنظر بدلًا من إعادة التحقيق من البداية. الإجابة التي تنجح بينما يفشل التطبيق تشير إلى ثقة الشهادة أو سياسة API بدلًا من DNS. تلك الأعطال حقيقية، ولن يصلحها أي تغيير في المُحلِّل.
اكتب أي خطوة فشلت. ذلك السطر الواحد هو ما يحتاجه الشخص التالي، ويستغرق تسجيله عشر ثوانٍ.
احفظ السلسلة حيث يجدها الشخص التالي
سجّل المُحلِّل المدفوع وقاعدة التمرير ومصدر الاستعلام المسموح به ونقطة النهاية المجيبة في مكان واحد. عندما يفشل الاسم الخاص مرة أخرى، يُظهر السجل ما إذا كان النفق قد تحرك، أو تغيّر عنوان المُحلِّل، أو ضُيّقت قاعدة. من دونه، يبدأ كل حادث من الصفر وينتهي بالتخمينات الثلاثة نفسها.
أبقِ السجل قصيرًا بما يكفي ليبقى دقيقًا: أربعة أسطر وتاريخ واسم من يملك كل جزء. السجل القديم أسوأ من عدمه، لأنه يبدو موثوقًا بينما هو خاطئ.