DNS في منارة Nebula: من يمكنه الاستعلام عن أي السجلات؟
المستمع الاختياري يجيب من بيانات المضيفين التي تحتفظ بها المنارة. تختلف استعلامات سجلات A وTXT في إمكانية الوصول والجمهور، لذا اربطه عن قصد.
دور المنارة في Nebula يؤدي عملًا كبيرًا يفترض الناس أنه تلقائي، والإجابة عن DNS ليست واحدة من تلك الأعمال. خدمة الأسماء مستمع اختياري يبدأ معطّلًا، ولهذا قد لا يجد مضيف يحل الأسماء جيدًا داخل الشبكة التراكبية شيئًا ليحل به حاسوب زميل على الإطلاق. قبل تشغيله، حدّد من ينبغي أن يصل إليه وأي أنواع السجلات تقبل الإجابة عنها، لأن هذين الجوابين مختلفان.
المستمع اختياري ومعطّل افتراضيًا
الاكتشاف وDNS خدمتان منفصلتان. تساعد المنارة الأقران على العثور على بعضهم بعضًا، ويمكنها إضافة إلى ذلك الإجابة عن استعلامات الأسماء الخاصة بالمضيفين الذين تعرفهم، لكن هذا الجزء الثاني يجب تشغيله صراحة في الإعدادات.
حدّد الواجهات والشبكات التي ينبغي أن تصل إلى المستمع قبل أن تفعّل أي شيء. خدمة DNS تجيب على واجهة لم تقصدها تصبح تسريبًا صغيرًا للمعلومات دون أي سجل تدقيق يقرأه أحد. اتخاذ القرار الآن أرخص بكثير من تضييقه لاحقًا، بعد أن يعتمد شيء ما على الجواب الخطأ. سطران من الإعدادات أسهل في التبرير من مذكرة حادث بعد ستة أشهر.
سجلات A وTXT لا تشترك في جمهور واحد
يُجاب عن نوعي السجلات هذين في ظروف مختلفة، والتعامل معهما كخدمة واحدة هو الخطأ الذي وُجد هذا المقال لمنعه.
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
هذا التفاوت مقصود وليس سهوًا. ربط الاسم بالعنوان منخفض القيمة بالنسبة لشخص خارجي، أما بيانات الشهادة الوصفية فتصف الهويات في شبكتك التراكبية. لا تنقل افتراضًا من صف إلى الآخر لمجرد أن العملية نفسها تجيب عن الاثنين.
إنه يجيب فقط عن مضيفي المنارة نفسها
هذا ليس مُحلّلًا عامًا لمكتبك أو شبكتك السحابية أو الإنترنت العام. تجيب المنارة من معلومات المضيفين التي أُعطيت لها، ولهذا أيضًا تعيش هذه الميزة على عقد المنارة لا على كل قرين.
عندما يفشل اسم لا علاقة له بالشبكة التراكبية، ابحث عن المنطقة والمحلل الذين يملكانه فعليًا. خلط محلل تراكبي في إعدادات DNS العامة لمضيف ينتج أعطالًا تبدو عشوائية، لأن بعض الأسماء تُحل وأخرى لا يجيب عنها شيء على الإطلاق.
راقب أيضًا نقطة تمهيد bootstrap. يجب أن يُحل اسم المضيف المستخدم للوصول إلى أول منارة عبر مسار عادي قبل أن يعتمد الاكتشاف عليه، لذا تبدو مشكلة البيضة والدجاجة هنا تمامًا كشبكة تراكبية معطوبة. بل تُبلّغ بالطريقة نفسها: قرين لا يظهر أبدًا ولا سبب واضح لذلك. تحقق من حل الأسماء قبل أن تلمس الشهادات، لأن هذا الترتيب يكشف من بدأ بالنصف الأصعب.
افحص عنوان الربط ثم اختبر من الخارج
lighthouse.dns.host و lighthouse.dns.port يحددان أين تصغي الخدمة الاختيارية. راجع هاتين القيمتين مع جدار حماية المضيف وسياسة الشبكة، لأن عنوان الربط بيان نية وليس ضابطًا أمنيًا بحد ذاته.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortاستعلم من الشبكات التي تنوي السماح لها، لا من المنارة نفسها. البحث الناجح على المنارة يثبت أن العملية تعمل ولا يقول لك شيئًا عما يمكن لمضيف خارجي أن يسأل عنه، وهو السؤال المهم فعليًا.
اكشفه عن قصد
الأسماء وبيانات الشهادة الوصفية معلومات تشغيلية مفيدة، والفائدة تقطع في الاتجاهين. قرر ما إذا كان المستمع للشبكة التراكبية فقط، وأي أنواع السجلات تُسمح، ومن يراجع الإعدادات عندما تتغير.
ثم اكتب ذلك بجوار إعدادات المنارة. الشخص التالي الذي يعالج عطل حل أسماء سيفترض وإلا أن الخدمة كانت موجودة دائمًا. وسيفترض أيضًا أنها كانت متاحة دائمًا من أي مكان يصادف أنه يختبر منه. فقرة واحدة تسجل عنوان الربط والشبكات المسموح بها وأنواع السجلات توفر على ذلك الشخص بعد ظهر كاملًا وتوفر عليك رسالة تسأل لماذا تغير شيء.