حلّ المجتمع

إصلاح تعارض المنفذ 67 في Pi-hole مع DHCP في ZVM على ZimaOS

A ZimaOS 1.3.2-beta2 user could not assign UDP port 67 to Pi-hole. IceWhale confirmed that dnsmasq was already using the port to provide DHCP for ZVM virtual-machine networking.

إذا رفض ZimaOS تخصيص منفذ UDP 67 لـ Pi-hole، فحدّد أولًا ما إذا كان Pi-hole يحتاج فعلًا إلى العمل خادمًا لـ DHCP لديك. المنفذ 67 هو منفذ خادم DHCP القياسي، لكن تصفية DNS الأساسية في Pi-hole لا تتطلبه.

في نقاش المجتمع في فبراير 2025، أكدت IceWhale أن dnsmasq كان يستمع بالفعل على المنفذ 67 لأن ZimaOS كان يستخدمه لشبكات أجهزة ZVM الافتراضية. كان من شأن الأمر الفوري المُشارَك في ذلك النقاش تحرير المنفذ، لكنه كان سيعطل أيضًا شبكة ZVM. بالنسبة إلى معظم الشبكات المنزلية، الحل الأنظف هو إبقاء DHCP على جهاز التوجيه وتشغيل Pi-hole لتصفية DNS فقط.

خطأ المنفذ 67 الأصلي في ZimaOS

حاول المستخدم الأصلي تثبيت Pi-hole على ZimaOS 1.3.2-beta2، ووجد أن المنفذ 67 غير متاح.

تثبيت Pi-hole على ZimaOS مع ظهور منفذ UDP 67 غير متاح لأن DHCP يستخدمه بالفعل
تعذر على التثبيت المخصص لـ Pi-hole الاستيلاء على منفذ خادم DHCP 67.

وجد المستخدم نفسه أيضًا أن عناصر التحكم المتعلقة بـ DHCP الظاهرة في واجهة ZimaOS لم تكن قابلة للنقر في ذلك الإصدار التجريبي.

إعدادات شبكة ZimaOS التاريخية مع عدم توفر عناصر التحكم في DHCP في واجهة الإصدار التجريبي 1.3.2
تعكس لقطة الشاشة هذه الإصدار ZimaOS 1.3.2-beta2، ولا ينبغي التعامل معها باعتبارها واجهة الشبكات الحالية بالضبط.

ما الذي كان يستخدم المنفذ 67؟

حدّد رد IceWhale ما يلي:

dnsmasq

باعتبارها العملية التي تستمع على المنفذ 67. في بنية ZimaOS تلك، كانت الخدمة تُستخدم لتعيين عناوين لأجهزة ZVM الافتراضية.

يمكنك تحديد العملية الحالية باستخدام:

sudo ss -ulnp | grep :67

أو، على الأنظمة التي يتوفر فيها:

netstat -tulnp | grep :67

لا يحتاج Pi-hole إلى المنفذ 67 لتصفية DNS

تربط وثائق Pi-hole الحالية الخاصة بـ Docker المنفذ 67/udp عند استخدام Pi-hole خادمًا لـ DHCP. إذ تستخدم خدمة DNS الخاصة به المنفذ 53 بدلًا من ذلك.

الدور الوظيفي الأدنى هو:

53/tcp ← DNS
53/udp ← DNS
منفذ واجهة الويب ← إدارة Pi-hole

ويظل منفذ DHCP 67 غير مستخدم من قِبل Pi-hole.

وثائق Pi-hole الخاصة بـ Docker

إذا كان جهاز التوجيه لديك يوفر DHCP بالفعل، فإن أبسط بنية لـ ZimaOS هي:

جهاز التوجيه
  └─ خادم DHCP

ZimaOS
  ├─ ‏dnsmasq الخاص بـ ZVM / الشبكات الافتراضية
  └─ Pi-hole
       └─ تصفية DNS فقط

اضبط خدمة DHCP في جهاز التوجيه لتوزيع عنوان IP الخاص بـ Pi-hole باعتباره خادم DNS، أو اضبط DNS وفقًا لإمكانات جهاز التوجيه لديك.

يؤدي هذا إلى تجنب التنافس على UDP 67 والحفاظ على شبكة ZVM.

الإصلاح التاريخي للمصدر: إيقاف dnsmasq

اقترح رد عام 2025 تحديد dnsmasq ثم تشغيل:

killall -9 dnsmasq

تضمن الرد تحذيرًا صريحًا: إيقاف هذه الخدمة يجعل شبكة ZVM غير متاحة.

لذلك، لا يُعد هذا الأمر خطوة محايدة لإعداد Pi-hole، بل هو مفاضلة تعطل وظيفة أخرى في ZimaOS، وقد يُعاد تشغيل خدمة نظام خاضعة للإشراف لاحقًا.

لا تزال وثائق Pi-hole الحالية على ZimaOS تتعامل مع المنفذ 67 باعتباره تعارضًا يجب حله عمدًا

يوصي دليل نشر Pi-hole الحالي على ZimaOS بالتحقق من العملية التي تستخدم UDP 67:

sudo ss -ulnp | grep :67

وعند تعطيل الخدمة المتعارضة عمدًا، إنهاء معرّف العملية (PID) ذي الصلة.

دليل نشر Pi-hole على ZimaOS

قبل القيام بذلك، حدّد ما توفّره العملية. في نظام يستخدم ZVM، قد يؤدي إيقاف خدمة DHCP إلى إزالة وظائف شبكة الأجهزة الافتراضية.

إذا كان يجب أن يكون Pi-hole خادم DHCP لديك

لا تسمح بعض أجهزة التوجيه بتعيين DNS مخصّص، لذا قد يكون DHCP في Pi-hole مفيدًا. في هذه الحالة، لا يمكنك تشغيل خادمي DHCP يتنافسان على الدور نفسه في الشبكة المحلية دون تقسيم مقصود.

قبل تحرير المنفذ 67:

  1. أكّد ما إذا كنت تستخدم ZVM؛
  2. أكّد أي عملية تملك UDP 67؛
  3. افهم ما إذا كانت تلك الخدمة ستُعاد تشغيلها تلقائيًا؛
  4. تأكّد من أن خادم DHCP واحدًا فقط سيستجيب للعملاء على شبكة LAN المستهدفة؛
  5. سجّل إعدادات DHCP الحالية في جهاز التوجيه قبل تعطيلها؛
  6. جهّز طريقة استرداد في حال توقف العملاء عن تلقي العناوين.

لا تشغّل خادمي DHCP بالخطأ على شبكة البث نفسها

إذا استجاب كل من جهاز التوجيه وPi-hole لطلبات DHCP على شبكة LAN نفسها، فقد يتلقى العملاء بوابات أو خوادم DNS أو نطاقات تأجير غير متسقة.

عند نقل مسؤولية DHCP إلى Pi-hole، عطّل خادم DHCP القديم فقط بعد أن يصبح إعداد Pi-hole جاهزًا ويمكن الوصول إليه.

لماذا يغيّر ZVM القرار

تحتاج الأجهزة الافتراضية في ZVM إلى إعداد شبكة منفصل عن تعيين المنافذ لتطبيق Docker عادي. وقد ربط الخيط المصدر عملية ZimaOS الخاصة بـ dnsmasq العملية مباشرةً بتعيين عناوين ZVM.

إذا كنت تعتمد على ZVM، فعادةً ما يكون استخدام Pi-hole لنظام DNS فقط هو البنية الأقل مخاطرة.

إعدادات الشبكة الحالية في ZimaOS تختلف عن لقطة شاشة الإصدار التجريبي لعام 2025

تُظهر وثائق ZimaOS الحالية صفحة الشبكات ضمن:

الإعدادات → الشبكة

وتوثّق التعيين اليدوي للعناوين وDHCP للواجهات الفعلية. لذلك فإن القائمة غير القابلة للنقر الظاهرة في التقرير الأصلي للإصدار التجريبي 1.3.2 تمثل سلوكًا تاريخيًا لواجهة المستخدم.

وثائق الشبكات الحالية في ZimaOS

قائمة التحقّق من المنفذ 67 في Pi-hole على ZimaOS

  1. حدّد ما إذا كان Pi-hole يحتاج إلى DHCP أصلًا.
  2. إذا كان جهاز التوجيه يستطيع التعامل مع DHCP، فاترك DHCP في Pi-hole معطّلًا.
  3. اربط منافذ Pi-hole الخاصة بـ DNS، وهما TCP 53 وUDP 53.
  4. تحقّق من UDP 67 باستخدام sudo ss -ulnp | grep :67.
  5. إذا dnsmasq يملك المنفذ، وتذكّر أنه قد يكون يوفّر شبكة ZVM.
  6. لا توقف خدمات DHCP النظامية بشكل عشوائي.
  7. إذا كان يجب أن يصبح Pi-hole خادم DHCP، فخطّط لتبعات ذلك على جهاز التوجيه وZVM قبل تغيير أي شيء.
  8. بعد إجراء التغييرات، تحقّق من أن عملاء LAN يتلقون عنوان IP والبوابة وإعدادات DNS صالحة.

الأسئلة الشائعة حول المنفذ 67 في ZimaOS

لماذا المنفذ 67 مشغول بالفعل على ZimaOS؟

في الخيط المصدر، كان ZimaOS dnsmasq استخدم UDP 67 لتعيين العناوين للأجهزة الافتراضية في ZVM.

هل يحتاج Pi-hole إلى المنفذ 67 لحظر الإعلانات؟

لا. يحتاج Pi-hole إلى المنفذ 67 فقط عندما يعمل خادم DHCP. أما تصفية DNS فتستخدم المنفذ 53.

هل يمكنني إيقاف dnsmasq لتثبيت Pi-hole؟

ناقش الخيط القديم ذلك كحل بديل، لكن IceWhale حذّرت من أن شبكة ZVM ستتوقف. اعتبره مفاضلة مقصودة في النظام، وليس الإعداد الافتراضي.

ما الإعداد الأبسط؟

دع جهاز التوجيه يوفّر DHCP واستخدم Pi-hole لتصفية DNS، ما لم تتطلب شبكتك تحديدًا أن يصبح Pi-hole خادم DHCP.