متطلبات عميل وخادم DHCP في Linux المضمن
يحتاج الجهاز المضمن إلى عميل DHCP عندما يحصل على إعدادات IPv4 الخاصة به من شبكة أخرى. ويحتاج إلى خادم DHCP عندما يوزع الإعدادات على أجهزة تابعة أو هاتف يستخدم للإعداد الأولي. وقد تحتاج البوابة إلى الدورين على واجهات منفصلة ومحددة. ينبغي أن تسمي متطلبات المنتج هذه الواجهات، والجهة المسؤولة عن إعدادها، وسلوكها عند الفشل، قبل اختيار الخدمة أو إضافة حزم إلى صورة Linux.
يتناول هذا الدليل DHCP الخاص بـIPv4 في منتجات Linux المضمنة. أما إعلانات موجه IPv6 وDHCPv6 فتحتاج إلى تصميم مستقل. الإعدادات واختبارات القبول التالية أمثلة هندسية مقترحة وليست نتائج نشر لدى Obeita.
ابدأ بطوبولوجيا التركيب
قد تحمل عبارة «دعم DHCP» تفسيرات مختلفة لا تتوافق مع بعضها. يعمل المستشعر المتصل بمبدل المصنع عادة كعميل. وقد تمنح نقطة وصول الصيانة عناوين لهاتف الفني فقط. ويمكن لبوابة التوجيه الحصول على عنوان WAN مع خدمة شبكة LAN منفصلة. أما الجسر فقد يمرر بث العملاء إلى خادم موجود؛ وإضافة خادم آخر إلى هذا الجسر تؤثر في نطاق البث بأكمله.
| دور المنتج | توزيع العناوين | القرار المطلوب توثيقه |
|---|---|---|
| طرف في شبكة المصنع | عميل على الوصلة الصاعدة | قسم تقنية المعلومات يدير الشبكة الفرعية والتأجير وDNS |
| نقطة وصول للإعداد المحلي | خادم على واجهة الإعداد | وصول محلي فقط أم تمرير إلى الإنترنت |
| بوابة أجهزة موجهة | عميل WAN وخادم LAN | شبكات فرعية منفصلة وسياسة تمرير صريحة |
| جسر شفاف | خادم الشبكة الموجود يخدم العملاء المتصلين | عنوان الإدارة وحدود البث |
ضع تسميات للمنافذ الفعلية إلى جانب أسماء Linux. قد يغير تعديل اللوحة أو محول USB أو تحديث برنامج التشغيل ترتيب تعداد الواجهات. احفظ في وثائق الإصدار العلاقة المقصودة بين الموصل وعنوان MAC وعضوية الجسر أو VLAN والدور الشبكي.
حدد سلوك العميل بعد أول تأجير
يشمل التخصيص الأول عادة الاكتشاف والعرض والطلب والإقرار. ثم يصبح للعنوان المؤجر عمر محدد وسلوك تجديد وإعادة ارتباط؛ ويجب ألا يستمر الجهاز في اعتبار تأجير منتهي الصلاحية صالحًا. تحدد RFC 2131 هذه الانتقالات. ينبغي لاختبار القبول أن يغطي الانتقالات اللاحقة، لا أن يتوقف عند نجاح إقلاع بارد.
عرّف حالات تظهر للتطبيق: الوصلة غير متاحة، الحصول على الإعدادات، عنوان صالح، الشبكة المحلية قابلة للوصول، ووجهة التطبيق قابلة للوصول. إقرار DHCP يثبت الحصول على إعدادات، لكنه لا يتحقق من DNS أو الإنترنت أو خدمة MQTT. امنح الواجهة وسجل التشخيص تفاصيل تميز هذه الحالات.
على مسؤول الشبكة أن يقرر قبول المسار الافتراضي وإعدادات DNS، والهوية التي يرسلها العميل، ودعم حجز عنوان. وثق الخيارات المتوقعة، مثل قناع الشبكة والموجه وخادم DNS، بالرجوع إلى RFC 2132. تجنب اعتماد المنتج على عنوان بعينه ما لم يُنسق ذلك مع تقنية المعلومات في الموقع.
في الأجهزة متعددة الواجهات حدد أولوية المسارات ومسؤولية DNS. قد يكتب مديرا شبكة على الواجهة نفسها فوق إعدادات بعضهما. وحتى تأجيران صالحان على واجهتين مختلفتين قد يضيفان مسارًا افتراضيًا غير مقصود. اختر جهة إعداد واحدة لكل واجهة، واختبرها مع مدير الاتصال الخلوي ومنفذ الخدمة الثابت وجسر الحاويات.
احصر الخادم داخل مقطعه المصرح به
ينبغي تشغيل خادم الإعداد بعد حصول واجهته على العنوان المحلي المطلوب. قيد واجهات الاستماع وتحقق من عدم خروج عروضه إلى وصلة المصنع الصاعدة. الاستماع إلى جميع الواجهات مع جسر غير مقصود قد ينشئ خادم DHCP غير مصرح به. قواعد الجدار الناري حد إضافي وليست بديلًا عن الإدارة الصحيحة للواجهات.
افصل توزيع العناوين عن التوجيه وتمرير DNS وNAT. حصول الهاتف على عنوان لا يعني أن البوابة توفر إنترنت. للإعداد المحلي فقط، حدد كيف يصل التطبيق إلى الجهاز إذا وصف الهاتف شبكة Wi-Fi بأنها بلا إنترنت. اختبر طريقة الوصول اليدوية الموثقة حتى إن توفرت بوابة مقيدة.
يخدم مثال dnsmasq التالي مقطع إعداد مخصصًا دون إعلان موجه افتراضي أو خادم DNS. يفترض ضبط br-setup مستقلًا على 192.168.77.1/24، وعدم اتصاله بمقطع آخر يخدمه DHCP، ووجود دليل تأجير قابل للكتابة. راجع الخيارات في دليل dnsmasq للإصدار المثبت. إنه نقطة بداية مخبرية وليس إعداد شبكة وأمن كاملًا.
# Dedicated local commissioning interface only
interface=br-setup
bind-interfaces
port=0
dhcp-range=192.168.77.20,192.168.77.60,255.255.255.0,10m
dhcp-option=3
dhcp-option=6
dhcp-leasefile=/data/dhcp/setup.leasesإذا كان المنتج سيوجه حركة الإنترنت، فحدد ذلك بشكل مستقل ووفر خيارات الموجه وDNS الصحيحة. إذا أُنشئت الواجهات ديناميكيًا، اختبر بدء الخدمة وإعادة تشغيلها بدل افتراض بقاء الربط صحيحًا. تأكد من عدم تداخل الشبكة الفرعية التابعة مع الشبكة الصاعدة، ووفر إجراء تغيير منضبطًا إذا حدث تداخل.
حدد التعارض ونفاد المجموعة واستمرارية الهوية
يجب أن يشمل حجم مجموعة العناوين العملاء المتزامنين والتأجيرات القديمة غير المنتهية والتبدلات أثناء الإعداد. قد تستخدم الهواتف عناوين Wi-Fi خاصة؛ لذلك ليس مضمونًا أن يحتفظ الهاتف نفسه بهوية MAC واحدة دائمًا. حدد معدل الطلبات المسيئة، وعرّف الرسالة التي يراها الفني عند امتلاء المجموعة.
قرر هل تبقى تأجيرات الخادم بعد إعادة التشغيل. فقدان قاعدة التأجير لا يعني بالضرورة تعارضًا فوريًا، لكنه يغير المعلومات المتاحة لإعادة استخدام العناوين بأمان. خزّنها وفق سياسة الاستمرارية المقصودة واختبر إعادة التشغيل والعملاء الحاليون ما زالوا متصلين. لا تمسح جميع إعدادات الجهاز لمجرد إصلاح مشكلة DHCP واحدة.
تكرار عنوان IPv4 يحتاج إلى عطل ظاهر وسياسة استعادة. تصف RFC 5227 كشف التعارض باستخدام ARP. تحقق مما تنفذه حزمة العميل والخادم الفعلية وسجل الحركة المتعارضة. نجاح ping من جهاز قد يخفي أن مضيفًا آخر يجيب أحيانًا عن العنوان نفسه.
استخدم مصفوفة قبول تركز على الأعطال
| الحقن | الملاحظة | شرط نجاح مقترح |
|---|---|---|
| الخادم غائب عند الإقلاع ثم يعود | توقيت المحاولات والمعالج وحالة التطبيق | استهلاك موارد محدود وحصول تلقائي ضمن مهلة الاستعادة المتفق عليها |
| تأجير اختبار قصير؛ حجب التجديد ثم جميع الردود | التجديد وإعادة الارتباط والانتهاء | لا يستخدم التطبيق تأجيرًا منتهيًا؛ ولا يحتاج الجهاز لإعادة إقلاع بعد عودة الخدمة |
| تغيير الموجه أو DNS عبر DHCP | المسارات والمحلل والاتصالات القائمة | تطبيق الإعدادات الجديدة وإعادة الاتصال وفق سياسة التطبيق |
| إعادة تشغيل الخادم والعملاء نشطون | قاعدة التأجير والتخصيص المكرر | لا تخصيص مكرر في مجموعة الاختبار |
| نفاد المجموعة أو تعارض مضيف ثابت | السجلات واستجابة واجهة الفني | بلاغ محدد واستعادة معروفة دون إتلاف إعدادات غير مرتبطة |
| تشغيل WAN ونقطة الإعداد معًا | التقاط على الواجهتين | عروض الإعداد محصورة في المقطع المقصود |
اختر الحدود الزمنية وفق احتياجات التركيب وقيم التأجير المدعومة. سجّل مع كل نتيجة مدة التأجير وإصدار البرنامج الثابت وإعداد الخدمة وطراز الموجه ونظام العميل. كرر اختبارات الخادم مع عائلات الهواتف والحواسيب المدعومة؛ نجاح حاسوب واحد دليل ضعيف على سير إعداد يعتمد على الهاتف.
شخّص أول انتقال مفقود
التقط واجهة واحدة في كل مرة داخل مختبر مصرح به. الأوامر التالية أمثلة تشخيصية؛ أسماء الواجهات والأدوات المتاحة تختلف باختلاف الصورة:
ip -br link
ip -4 address show dev eth0
ip -4 route show
tcpdump -ni eth0 -vv 'udp port 67 or udp port 68 or arp'غياب Discover يرجح مشكلة واجهة أو عملية أو جهة إدارة الإعداد. وجود Discover دون Offer يوجه إلى VLAN أو الخادم أو المرحل أو الترشيح. إقرار دون عنوان قابل للاستخدام يرجح مشكلة سكربت العميل أو تكامل مدير الشبكة. عنوان صالح مع فشل أسماء المضيفين يستدعي فحص DNS؛ نجاح DNS مع تعطل الخدمة يستدعي تشخيص التطبيق. احتفظ بالطوابع الزمنية ومعرفات المعاملات، وأخفِ معرفات العملاء قبل مشاركة الالتقاط خارج المشروع.
حوّل الطوبولوجيا إلى نطاق تسليم
تساعد خدمة اتصال الأجهزة من Obeita في تحديد أدوار الواجهات وقبول الشبكة. يعرض مشروع بوابة RK3528 المُسلَّم مسارات Ethernet منفصلة وأدوار LAN/WAN مقترحة، لكنه لا يثبت سلوك DHCP مختبرًا على شبكتك.
للتقييم، قدم مخطط الموصلات وVLAN، وعدد العملاء، وقيود DHCP في الموقع، ومتطلبات الإعداد المحلي، والصورة الحالية. اتفق على مسؤول الإعداد ورسائل الأعطال وإجراء الالتقاط ومصفوفة الاختبار قبل أن تصبح «دعم DHCP» خانة في التسليم.
