مقالات عن: ggRock

هذه المقالة متوفرة أيضًا على:

فشل إقلاع PXE مع PXE-E21 (إلغاء من الخادم البعيد)

🧩 فشل إقلاع PXE مع PXE-E21 (الخادم البعيد ألغى العملية)

سبب خادم DHCP وهمي أو خادم DHCP ثانوي

🔎 نظرة عامة

تحدث هذه المشكلة عندما يتم تكوين خادم ggRock لـ DHCP كامل + PXE، لكن جهازًا آخر على نفس قطاع الشبكة يرد أيضًا على طلبات DHCP.

خطأ العميل الشائع:

PXE-E21: Remote host cancelled

يحدث هذا دائمًا تقريبًا بسبب:

مساعد DHCP (IP helper-address)
خادم DHCP ثاني
مستجيب PXE (Acronis وWDS وغيره)
جهاز شبكة ينقل DHCP بدون قصد

🛠️ الأعراض

عملاء PXE يتلقون عنوان IP لكنهم يفشلون في الإقلاع
نجاح الإقلاع بشكل متقطع
DHCPNAK wrong server-ID يظهر في سجلات dnsmasq
خطأ PXE-E21 على العميل
tcpdump يظهر ردود من عناوين IP متعددة

مثال على التقاط:

tcpdump -ni vmbr0 port 67 or port 68

مثال على المخرجات المشكلة:

192.168.50.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply
192.168.50.10.67 > 255.255.255.255.68: BOOTP/DHCP, Reply

في هذا المثال:

192.168.50.10 = ggRock (متوقع)
192.168.50.1 = مستجيب غير متوقع (بوابة أو جهاز في اتجاه السير الأعلى)

إذا رد أكثر من جهاز واحد، يصبح سلوك PXE غير متوقع.

🧠 لماذا يحدث هذا

أثناء إقلاع PXE:

يرسل العميل DHCPDISCOVER
ترد عدة أجهزة
قد يختار العميل خادم DHCP مختلفًا عن ggRock
يرسل ggRock DHCPNAK (معرف الخادم خاطئ)
تتوقف عملية PXE
يعرض العميل PXE-E21

حتى مساعد DHCP يمكنه أن يسبب هذا إذا تم تكوينه بشكل خاطئ.

PXE حساس جدًا للمستجيبين المكررين.

✅ الحل

الخطوة 1 – التحقق من وجود مستجيبين متعددين

على خادم ggRock:

tcpdump -eni vmbr0 'port 67 or port 68'

أقلع عميلًا وراقب:

هل تأتي الردود من عناوين IP متعددة؟
ما عنوان MAC الخاص بالمستجيب غير المتوقع؟

الخطوة 2 – التحقق من مساعدات DHCP

على موجه الاتجاه السير الأعلى أو مفتاح Layer 3، تحقق من:

عدم تكوين ip helper-address
عدم تمكين إعادة توجيه DHCP على تلك الشبكة VLAN
عدم تمكين خدمات الإقلاع

مثال (بناء الجملة الشبيه بـ Cisco):

interface vlan 50
 no ip helper-address

الخطوة 3 – التحقق من مستجيبي PXE

تحقق من تعطيل هذه على أي أنظمة أخرى:

مستجيب Acronis PXE
خدمات نشر Windows (WDS)
نقطة خدمة SCCM PXE
منصات التصوير الأخرى

حتى لو تم تعطيل DHCP، يمكن لمستجيبي PXE أن يتداخلوا.

الخطوة 4 – تأكيد أن ggRock هو المستجيب الوحيد

قم بتشغيل:

tcpdump -ni vmbr0 port 67 or port 68

يجب أن تشاهد ردود من فقط:

192.168.50.10

إذا كان ggRock هو المستجيب الوحيد، يجب أن يعمل PXE بشكل طبيعي.

🏗️ هيكل التكوين الموصى به

لمنع ggrock-linux-configurator من الكتابة فوق تكوين DHCP الكامل:

1️⃣ تعيين دليل تكوين dnsmasq

تحقق من:

grep CONFIG_DIR /etc/default/dnsmasq

يجب أن يظهر:

CONFIG_DIR=/etc/dnsmasq.main.d

2️⃣ فصل تكوين DHCP وPXE

/etc/dnsmasq.main.d/10-dhcp.conf

يحتوي على:

dhcp-range
dhcp-option
dhcp-authoritative

مثال:

dhcp-range=192.168.50.20,192.168.50.100,255.255.255.0,12h
dhcp-option=option:router,192.168.50.1
dhcp-option=option:dns-server,8.8.8.8,8.8.4.4
dhcp-authoritative

/etc/dnsmasq.main.d/20-pxe.conf

يحتوي على:

enable-tftp
tftp-root
dhcp-boot
dhcp-vendorclass
منطق سلسلة iPXE

لا تستخدم ProxyDHCP (dhcp-range=...,proxy) عند تشغيل DHCP كامل.

🔒 أفضل ممارسة (موصى به)

إذا دعمها المفتاح الخاص بك:

فعّل DHCP snooping
اوسم منفذ ggRock فقط كموثوق
حظر جميع ردود DHCP الأخرى

هذا يمنع مستجيبي DHCP العرضيين في المستقبل.

📌 مثال على السبب الجذري

في إحدى الحالات:

كان مساعد PXE لا يزال مكونًا في اتجاه السير الأعلى
لقد استجاب جنبًا إلى جنب مع ggRock
تلقى العملاء عروض DHCP متعددة
حدثت PXE-E21
أزال المساعد على الفور المشكلة

🧾 ملخص

PXE-E21 أثناء نشر ggRock DHCP الكامل تحدث دائمًا تقريبًا بسبب:

خادم DHCP ثاني
مساعد DHCP
مستجيب PXE

يتطلب PXE خادم DHCP سلطة واحد فقط على القطاع.

عند استكشاف أخطاء DHCP:

التقاط الحزم هو مصدر الحقيقة.

تحديث في: 22/04/2026

هل كانت هذه المقالة مفيدة؟

شكرًا!