mDNS عبر WireGuard: ثلاث بوابات قبل أن يستجيب أحد الأقران
يحتاج Avahi إلى واجهة مؤهلة ومسار إلى المجموعة وقرين يملك الوجهة. ثلاث بوابات وثلاثة فحوص منفصلة، دون أي توزيع.
إن ضبط علم البث المتعدد على جهاز WireGuard يجعل الواجهة مؤهلة لبرامج الاكتشاف، وهذا كل ما يفعله العلم. فهو لا يخبر البروتوكول إلى أين يجب أن تذهب حزمة المجموعة، وعلى جهاز فيه عدة أقران لا توجد إجابة واحدة واضحة. وتقف ثلاث بوابات منفصلة بين دايمون يعمل وخدمة مكتشفة.
اختبرها بالترتيب، لأن اجتياز واحدة منها لا يخبرك بشيء عن التالية.
البوابة الأولى: العلم وسياسة الدايمون
يُنشأ جهاز WireGuard على لينكس كوصلة نقطة إلى نقطة دون ARP، ولا يحمل علم البث المتعدد افتراضيًا. وإضافة العلم تغيير محلي في الواجهة يقوم به أي شيء يدير الجهاز. ولدى Avahi رؤيته الخاصة للعالم فوق ذلك، وسياسته الافتراضية تتجاوز واجهات النقطة إلى النقطة كليًا. لذلك يُطبَّق فحصان مستقلان للأهلية قبل أن تتحرك حزمة واحدة.
لذا يحتاج الدايمون إلى قرار صريح، لا مجرد عملية قيد التشغيل. وتشمل أدوات التحكم الموثقة لديه allow-interfaces و deny-interfaces و allow-point-to-point، والإعداد الأخير هو ما يفوته الناس.
تُبلِّغ الفحوص أدناه عن أعلام الوصلة ومسار البث المتعدد وما إذا كانت تهيئة الدايمون تُحلَّل أصلًا:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkالدايمون الذي بدأ بنجاح لم يفتح بالضرورة مقابس على الواجهة التي تهمك. اقرأ تهيئته الفعلية بدلًا من افتراض أن حالة الخدمة تساوي التغطية.
البوابة الثانية: المسار إلى المجموعة
البوابة الثانية هي التوجيه العادي. فالحزمة الموجهة إلى 224.0.0.251 تتبع جدول التمرير كأي شيء آخر، وإذا أرسلها الجدول عبر واجهة الشبكة المحلية الفعلية فلن تغيّر أي تهيئة لـ WireGuard ذلك. أصلح المسار أولًا يصبح بقية التحقيق أقصر. وانظر فيما تبلّغ عنه النواة لعنوان المجموعة قبل لمس أي مفاتيح للأقران.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
بدون مسار محدد، ترتد النواة إلى معالجة البث المتعدد الخاصة بالوصلة، ولهذا يبدو الافتراضي صحيحًا على شبكة محلية مسطحة وخاطئًا بمجرد أن يُفترض خروج حركة المجموعة نفسها عبر نفق. والفشل صامت من جهة المرسل: الاستعلام يذهب إلى مكان ما، والجواب لا يصل أبدًا.
البوابة الثالثة: WireGuard يختار قرينًا واحدًا لكل حزمة
يختار WireGuard القرين الصادر بالبحث عن الوجهة في مجموعات العناوين المسموح بها، وينفّذ مسار الإرسال في لينكس ذلك البحث مرة واحدة لكل حزمة. هناك نتيجة واحدة، وتُشفَّر الحزمة لذلك القرين. وظهور البادئة نفسها للمجموعة في قوائم مسموح بها لدى عدة أقران لا ينشئ عضوية ولا نسخًا؛ بل ينشئ بحثًا ملتبسًا يُحسم لأحدهم.
على وصلة مخصصة بطرفين هذا بالضبط ما تريده، لأن هناك مستلمًا واحدًا مقصودًا لحركة المجموعة المحمولة عمدًا. أما على واجهة فيها خمسة أقران فهو قيد وليس ميزة، والإصلاح يقع في التصميم لا في تهيئة أي قرين بعينه.
يحتاج تصميم التوزيع إلى مُرحّل صريح أو وصلات منفصلة أو آلية اكتشاف مختلفة تمامًا. ونشر وصفة الطرفين كحل لحشد من العملاء لأن كل عميل يستطيع اختبار البوابة هو كيف يُنشر هذا بشكل خاطئ.
يُفحص الاتجاه الوارد بشكل مختلف: يجب أن يقع مصدر الحزمة المستلمة داخل القائمة المسموح بها للقرين الموثّق. وإضافة وجهة بث متعدد هناك لا تحل محل ملكية المصدر الحقيقية للمرسل.
الانعكاس حدّ لا جسر
يعيد عاكس Avahi إنتاج رسائل mDNS بين الواجهات التي يختارها، على طبقة التطبيق. إنه حدّ اكتشاف بين الشبكات، لا جسر إيثرنت ولا موجه بث متعدد عام. وعاكسان موصولان بالشبكات نفسها سينشئان بسهولة حلقة من الإعلانات المتكررة.
كما يسلّم الانعكاس أسماء الخدمات وبياناتها الوصفية إلى شبكة أخرى، وهو قرار خصوصية بقدر ما هو قرار توجيه. قيّد الواجهات المختارة، واستخدم مرشحات الخدمة حيث يدعمها الإصدار المثبت، حتى لا يعبر الحدّ إلا الإعلانات التي يحتاجها مستخدم مُخوَّل.
يبقى الاكتشاف والاستخدام نتيجتين منفصلتين. يمكن للعميل أن يرى إعلانًا لخدمة يكون عنوانها المعلن غير قابل للوصول من مكان العميل، أو ترفض سياسة وصوله منفذها. أكّد اتصال الخدمة بعد ظهور الإعلان، وإذا كان التطبيق يدعم اسم DNS ثابتًا أو عنوان خادم صريحًا ففضّل ذلك على توسيع الاكتشاف المحلي للوصلة. ويغطي وصف التوجيه بمفتاح التشفير اختيار القرين المبني على الوجهة الذي يعتمد عليه كل هذا.