بروتوكول تكوين المضيف الديناميكي

بروتوكول التكوين الديناميكي للمضيف ( DHCP ) هو بروتوكول لإدارة الشبكة يُستخدم في شبكات بروتوكول الإنترنت (IP) لتخصيص عناوين IP تلقائيًا ، بالإضافة إلى معلمات اتصال أخرى، للأجهزة المتصلة بالشبكة باستخدام بنية العميل والخادم . ^{[ 1 ] : مقدمة}

تُغني هذه التقنية عن الحاجة إلى تهيئة أجهزة الشبكة يدويًا، وتتألف من عنصرين أساسيين: خادم DHCP مركزي، ونسخ عميل من حزمة البروتوكولات على كل جهاز كمبيوتر أو جهاز. عند الاتصال بالشبكة، وبشكل دوري بعد ذلك، يطلب العميل مجموعة من المعلمات من الخادم باستخدام بروتوكول DHCP.

يمكن تطبيق بروتوكول DHCP على شبكات متنوعة الأحجام، بدءًا من الشبكات المنزلية وصولًا إلى شبكات الجامعات الكبيرة وشبكات مزودي خدمة الإنترنت الإقليمية. ^{[ 2 ]} تتمتع العديد من أجهزة التوجيه وبوابات الإنترنت المنزلية بخاصية خادم DHCP. تحصل معظم أجهزة توجيه الشبكات المنزلية على عنوان IP فريد ضمن شبكة مزود خدمة الإنترنت. وفي الشبكة المحلية، يقوم خادم DHCP بتخصيص عنوان IP محلي لكل جهاز.

تتوفر خدمات DHCP للشبكات التي تعمل بنظام بروتوكول الإنترنت الإصدار 4 (IPv4)، وكذلك الإصدار 6 ( IPv6 ). ويُطلق على إصدار IPv6 من بروتوكول DHCP اسم DHCPv6 . ^{[ 3 ]}

تم تعريف بروتوكول تحليل العناوين العكسي (RARP) في عام 1984 لتهيئة الأجهزة البسيطة، مثل محطات العمل التي لا تحتوي على أقراص ، بعنوان IP مناسب . ^{[ 4 ]} ونظرًا لعمله في طبقة ربط البيانات ، فقد صعّب تطبيقه على العديد من منصات الخوادم. إذ كان يتطلب وجود خادم على كل وصلة شبكة على حدة. وقد تم استبدال RARP ببروتوكول التمهيد (BOOTP) الذي تم تعريفه في سبتمبر 1985. ^{[ 5 ]} وقد أدخل هذا البروتوكول مفهوم وكيل الترحيل، الذي سمح بإعادة توجيه حزم BOOTP عبر الشبكات، مما مكّن خادم BOOTP مركزيًا واحدًا من خدمة المضيفين على العديد من الشبكات الفرعية لبروتوكول الإنترنت.

تم تعريف بروتوكول DHCP لأول مرة في أكتوبر 1993. ^{[ 6 ] [ 7 ]} وهو يعتمد على بروتوكول BOOTP، ولكنه قادر على تخصيص عناوين IP ديناميكيًا من مجموعة عناوين واستعادة عناوين IP غير المستخدمة. كما يمكن استخدامه لتوفير مجموعة واسعة من معلمات التكوين الإضافية لعملاء IP، بما في ذلك المعلمات الخاصة بالمنصة. ^{[ 8 ]}

بعد أربع سنوات، أُضيف نوع رسالة DHCPINFORM (المستخدم في WPAD ) وتغييرات طفيفة أخرى. ولا يزال هذا التعريف، الصادر عام 1997، ^{[ 1 ]} يُشكّل جوهر معيار شبكات IPv4.

تم تعريف DHCPv6 في البداية في عام 2003. ^{[ 9 ]} بعد التحديثات التي أجرتها العديد من RFCs اللاحقة، تم استبدال تعريفه في عام 2018، ^{[ 10 ]} حيث تم دمج تفويض البادئة والتكوين التلقائي للعنوان بدون حالة .

يُحدد بروتوكول الإنترنت (IP) كيفية تواصل الأجهزة داخل الشبكات المحلية وعبرها على الإنترنت. يستطيع خادم DHCP إدارة إعدادات IP للأجهزة على شبكته المحلية، على سبيل المثال، عن طريق تخصيص عناوين IP ^{[ 8 ]} لتلك الأجهزة تلقائيًا وديناميكيًا. ^{[ 11 ]}

يعمل بروتوكول DHCP وفق نموذج العميل والخادم . عند اتصال جهاز كمبيوتر أو أي جهاز آخر بشبكة، يرسل برنامج عميل DHCP استعلام بث DHCP لطلب المعلومات اللازمة. يمكن لأي خادم DHCP على الشبكة تلبية هذا الطلب. يدير خادم DHCP مجموعة من عناوين IP ومعلومات حول معلمات تكوين العميل، مثل البوابة الافتراضية واسم النطاق وخوادم الأسماء وخوادم الوقت . عند استلام طلب DHCP، قد يستجيب خادم DHCP بمعلومات محددة لكل عميل، كما تم تكوينها مسبقًا من قِبل المسؤول، أو بعنوان محدد وأي معلومات أخرى صالحة للشبكة بأكملها وللفترة الزمنية التي يكون فيها التخصيص (الإيجار ) ساريًا. عادةً ما يستعلم عميل DHCP عن هذه المعلومات فور بدء التشغيل ، وبشكل دوري بعد ذلك قبل انتهاء صلاحية المعلومات. عندما يُحدّث عميل DHCP تخصيصًا، فإنه يطلب في البداية نفس قيم المعلمات، ولكن قد يُخصص خادم DHCP عنوانًا جديدًا بناءً على سياسات التخصيص التي حددها المسؤولون.

في الشبكات الكبيرة التي تتكون من روابط متعددة، قد يخدم خادم DHCP واحد الشبكة بأكملها بمساعدة وكلاء ترحيل DHCP الموجودين على أجهزة التوجيه المتصلة. يقوم هؤلاء الوكلاء بترحيل الرسائل بين عملاء DHCP وخوادم DHCP الموجودة على شبكات فرعية مختلفة.

Depending on implementation, the DHCP server may have three methods of allocating IP addresses:

Dynamic allocation

A network administrator reserves a range of IP addresses for DHCP, and each DHCP client on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim and then reallocate IP addresses that are not renewed.

Automatic allocation

The DHCP server permanently assigns an IP address to a requesting client from a range defined by an administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.

Manual allocation

This method is also variously called static DHCP allocation, fixed address allocation, reservation, and MAC/IP address binding. An administrator maps a unique identifier (a client id or MAC address) for each client to an IP address, which is offered to the requesting client. DHCP servers may be configured to fall back to other methods if this fails.

DHCP services are used for Internet Protocol version 4 (IPv4) and IPv6. The details of the protocol for IPv4 and IPv6 differ sufficiently that they may be considered separate protocols.^[12] For the IPv6 operation, devices may alternatively use stateless address autoconfiguration. IPv6 hosts may also use link-local addressing to achieve operations restricted to the local network link.

The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). The server listens on UDP port number 67, and the client listens on UDP port number 68.

DHCP operations fall into four phases: server discovery, IP lease offer, IP lease request, and IP lease acknowledgement. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgement.

تبدأ عملية DHCP بإرسال العملاء طلبًا عبر البث. إذا كان العميل والخادم في نطاقات بث مختلفة ، فقد يُستخدم مُساعد DHCP أو وكيل ترحيل DHCP . يمكن للعملاء الذين يطلبون تجديد عقد إيجار قائم التواصل مباشرةً عبر UDP أحادي البث ، نظرًا لأن العميل لديه بالفعل عنوان IP مُثبت في تلك المرحلة. بالإضافة إلى ذلك، توجد علامة BROADCAST (بت واحد في حقل علامات مكون من بايتين، حيث جميع البتات الأخرى محجوزة وبالتالي تُضبط على 0) يمكن للعميل استخدامها للإشارة إلى طريقة استقبال DHCPOFFER (بث أو أحادي البث): 0x8000 للبث، و0x0000 لأحادي البث. ^{[ 1 ]} عادةً، يُرسل DHCPOFFER عبر أحادي البث. بالنسبة للأجهزة المضيفة التي لا يمكنها قبول حزم أحادي البث قبل تكوين عناوين IP، يمكن استخدام هذه العلامة لتجاوز هذه المشكلة.

يمكن لخادم DHCP تزويد العميل بمعلمات تكوين اختيارية. يصف RFC 2132 خيارات DHCP المتاحة التي حددتها هيئة أرقام الإنترنت المخصصة (IANA) - معلمات DHCP وBOOTP. ^{[ 13 ]}

يستطيع عميل DHCP اختيار المعلمات التي يوفرها خادم DHCP ومعالجتها واستبدالها. في الأنظمة الشبيهة بنظام Unix، تتم هذه التعديلات على مستوى العميل عادةً وفقًا للقيم الموجودة في ملف التكوين /etc/dhclient.conf .

الخيارات عبارة عن سلاسل ثمانية بتات بأطوال مختلفة. يُطلق على هذا ترميز النوع-الطول-القيمة . يمثل البايت الأول رمز الخيار، ويمثل البايت الثاني عدد البايتات التالية، أما البايتات المتبقية فتعتمد على الرمز. على سبيل المثال، يظهر خيار نوع رسالة DHCP لعرض ما على النحو التالي: 0x35، 0x01، 0x02، حيث يمثل 0x35 الرمز 53 لـ "نوع رسالة DHCP"، ويعني 0x01 وجود بايت واحد متبقٍ، بينما يمثل 0x02 قيمة "عرض".

تُدرج الجداول التالية خيارات DHCP المتاحة. ^{[ 14 ] [ 13 ]}

في الشبكات الصغيرة، حيث تُدار شبكة فرعية واحدة فقط من عناوين IP، تتواصل عملاء DHCP مباشرةً مع خوادم DHCP. مع ذلك، يمكن لخوادم DHCP أيضًا توفير عناوين IP لشبكات فرعية متعددة. في هذه الحالة، لا يستطيع عميل DHCP الذي لم يحصل بعد على عنوان IP التواصل مباشرةً مع خادم DHCP ليس على نفس الشبكة الفرعية، لأن بث العميل لا يُستقبل إلا على شبكته الفرعية.

لتمكين عملاء DHCP على الشبكات الفرعية غير المُخدَّمة مباشرةً من خوادم DHCP من التواصل مع هذه الخوادم، يُمكن تثبيت وكلاء ترحيل DHCP على هذه الشبكات الفرعية. يعمل وكيل ترحيل DHCP على جهاز شبكة، قادر على توجيه البيانات بين الشبكة الفرعية للعميل والشبكة الفرعية لخادم DHCP. يبث عميل DHCP عبر الرابط المحلي؛ يستقبل وكيل الترحيل البث ويرسله إلى خادم DHCP واحد أو أكثر باستخدام البث الأحادي . يتم تكوين عناوين IP لخوادم DHCP يدويًا في وكيل الترحيل. يخزن وكيل الترحيل عنوان IP الخاص به، من الواجهة التي استقبل عليها بث العميل، في حقل GIADDR لحزمة DHCP. يستخدم خادم DHCP قيمة GIADDR لتحديد الشبكة الفرعية، ومن ثم مجموعة العناوين المناسبة، لتخصيص عنوان IP منها. عندما يرد خادم DHCP على العميل، يرسل الرد إلى عنوان GIADDR، باستخدام البث الأحادي أيضًا. يقوم وكيل الترحيل بإعادة إرسال الاستجابة على الشبكة المحلية، باستخدام البث الأحادي (في معظم الحالات) إلى عنوان IP المحجوز حديثًا، في إطار إيثرنت موجه إلى عنوان MAC الخاص بالعميل. يجب على العميل قبول الحزمة كحزمة خاصة به، حتى لو لم يتم تعيين عنوان IP هذا على الواجهة بعد. ^{[ 1 ] : 25} مباشرةً بعد معالجة الحزمة، يقوم العميل بتعيين عنوان IP على واجهته ويكون جاهزًا للاتصال عبر بروتوكول الإنترنت (IP) بشكل منتظم، مباشرةً بعد ذلك.

إذا كان تطبيق بروتوكول الإنترنت (IP) الخاص بالعميل لا يقبل حزم البيانات أحادية البث عندما لا يكون لديه عنوان IP بعد، فيمكن للعميل ضبط بت البث في حقل FLAGS عند إرسال حزمة DHCPDISCOVER. سيستخدم وكيل الترحيل عنوان IP للبث 255.255.255.255 (وعنوان MAC الخاص بالعميل) لإبلاغ العميل بعرض DHCP الخاص بالخادم.

تستخدم عملية الاتصال بين وكيل الترحيل وخادم DHCP عادةً منفذ UDP المصدر والوجهة رقم 67.

يمكن لعميل DHCP استقبال هذه الرسائل من الخادم: ^{[ 1 ] : §4.4}

• عرض دي إتش سي
• حزمة DHCPACK
• DHCPNAK

ينتقل العميل عبر حالات DHCP اعتمادًا على كيفية استجابة الخادم للرسائل التي يرسلها العميل.

يضمن بروتوكول DHCP الموثوقية بعدة طرق: التجديد الدوري، وإعادة الربط، ^{[ 1 ] : §4.4.5} ، والتحويل التلقائي في حالة الفشل. تُخصص لعملاء DHCP فترات تأجير تدوم لفترة زمنية محددة. يبدأ العملاء بمحاولة تجديد فترات تأجيرهم بمجرد انقضاء نصف مدة التأجير. ^{[ 1 ] : §4.4.5 الفقرة 3.} يتم ذلك عن طريق إرسال رسالة DHCPREQUEST أحادية البث إلى خادم DHCP الذي منح التأجير الأصلي. إذا كان هذا الخادم معطلاً أو غير قابل للوصول، فلن يستجيب لرسالة DHCPREQUEST . مع ذلك، في هذه الحالة، يُكرر العميل رسالة DHCPREQUEST من حين لآخر، ^{[ 1 ] : §4.4.5 الفقرة 8 [ ب ]،} لذا إذا عاد خادم DHCP للعمل أو أصبح قابلاً للوصول مرة أخرى، سينجح عميل DHCP في الاتصال به وتجديد التأجير.

إذا تعذر الوصول إلى خادم DHCP لفترة طويلة، ^{[ 1 ] : الفقرة 5 من القسم 4.4.5،} سيحاول عميل DHCP إعادة الربط عن طريق بث رسالة DHCPREQUEST بدلاً من إرسالها بشكل منفرد. ولأنها تُبث ، ستصل رسالة DHCPREQUEST إلى جميع خوادم DHCP المتاحة. وإذا تمكن خادم DHCP آخر من تجديد عقد الإيجار، فسيفعل ذلك في هذه الحالة.

لكي تعمل عملية إعادة الربط، عندما يتصل العميل بنجاح بخادم DHCP احتياطي، يجب أن يمتلك هذا الخادم معلومات دقيقة حول ربط العميل. يُعدّ الحفاظ على دقة معلومات الربط بين خادمين مشكلة معقدة؛ فإذا كان بإمكان كلا الخادمين تحديث قاعدة بيانات التأجير نفسها، فلا بد من وجود آلية لتجنب تعارض التحديثات بين الخوادم المستقلة. وقد قُدِّم اقتراح لتنفيذ خوادم DHCP مقاومة للأعطال إلى فريق عمل هندسة الإنترنت، لكنه لم يُعتمد رسميًا. ^{[ 31 ] [ ج ]}

في حال فشل إعادة ربط عنوان IP، سينتهي عقد الإيجار في نهاية المطاف. عند انتهاء عقد الإيجار، يجب على العميل التوقف عن استخدام عنوان IP الممنوح له بموجب عقد الإيجار. ^{[ 1 ] : §4.4.5 الفقرة 9.} عندئذٍ، سيعيد تشغيل عملية DHCP من البداية عن طريق بث DHCPDISCOVERرسالة. وبما أن عقد الإيجار قد انتهى، فسيقبل أي عنوان IP يُعرض عليه. بمجرد حصوله على عنوان IP جديد (يُفترض أنه من خادم DHCP مختلف)، سيتمكن من استخدام الشبكة مرة أخرى. ومع ذلك، نظرًا لتغير عنوان IP الخاص به، ستنقطع أي اتصالات جارية.

طُوِّرت المنهجية الأساسية لبروتوكول DHCP للشبكات القائمة على بروتوكول الإنترنت الإصدار الرابع (IPv4). ومنذ تطوير ونشر شبكات IPv6 ، استُخدم بروتوكول DHCP أيضًا لتخصيص المعلمات في هذه الشبكات، على الرغم من الميزات المتأصلة في IPv6 لتكوين العناوين تلقائيًا دون الحاجة إلى حالة . ويُشار إلى إصدار IPv6 من البروتوكول باسم DHCPv6 . ^{[ 32 ]}

لا يتضمن بروتوكول DHCP الأساسي أي آلية للتحقق من الهوية. ^{[ 22 ] : §7} ولهذا السبب، فهو عرضة لمجموعة متنوعة من الهجمات. تندرج هذه الهجمات ضمن ثلاث فئات رئيسية: ^{[ 1 ] : §7}

• خوادم DHCP غير المصرح بها تقدم معلومات خاطئة للعملاء.
• عملاء غير مصرح لهم بالوصول إلى الموارد.
• هجمات استنزاف الموارد من عملاء DHCP خبيثين.

نظرًا لعدم وجود آلية لدى العميل للتحقق من هوية خادم DHCP، يمكن تشغيل خوادم DHCP غير مصرح بها (تُعرف عادةً باسم " خوادم DHCP المارقة ") على الشبكات، مما يُزوّد ​​عملاء DHCP بمعلومات خاطئة. ^{[ 33 ]} قد يُستخدم هذا إما كهجوم حجب الخدمة ، مما يمنع العميل من الوصول إلى اتصال الشبكة، ^{[ 34 ]} أو كهجوم وسيط . ^{[ 35 ]} ولأن خادم DHCP يُزوّد ​​عميل DHCP بعناوين IP للخوادم، مثل عنوان IP لخادم DNS واحد أو أكثر، ^{[ 1 ] : القسم 7،} يستطيع المهاجم إقناع عميل DHCP بإجراء عمليات بحث DNS من خلال خادم DNS الخاص به، وبالتالي تقديم إجاباته الخاصة لاستعلامات DNS من العميل. ^{[ 36 ]} وهذا بدوره يسمح للمهاجم بإعادة توجيه حركة مرور الشبكة عبر خادمه، مما يُتيح له التجسس على الاتصالات بين العميل وخوادم الشبكة التي يتصل بها، أو ببساطة استبدال خوادم الشبكة تلك بخوادمه الخاصة. ^{[ 36 ]}

نظرًا لعدم وجود آلية آمنة لدى خادم DHCP للتحقق من هوية العميل، يمكن للعملاء الوصول غير المصرح به إلى عناوين IP من خلال تقديم بيانات اعتماد، مثل معرّفات العملاء، التي تخص عملاء DHCP آخرين. ^{[ 33 ]} كما يسمح هذا لعملاء DHCP باستنفاد مخزون عناوين IP لدى خادم DHCP؛ فمن خلال تقديم بيانات اعتماد جديدة في كل مرة يطلب فيها العميل عنوانًا، يمكنه استهلاك جميع عناوين IP المتاحة على رابط شبكة معين، مما يمنع عملاء DHCP الآخرين من الحصول على الخدمة. ^{[ 33 ]}

يوفر بروتوكول DHCP بعض الآليات للتخفيف من هذه المشكلات. يسمح امتداد بروتوكول خيار معلومات وكيل الترحيل ^{[ 22 ]} (والذي يُشار إليه عادةً في هذا المجال برقم الخيار 82 ^{[ 37 ] [ 38 ]} ) لمشغلي الشبكات بإضافة علامات إلى رسائل DHCP عند وصولها إلى شبكة المشغل الموثوقة. تُستخدم هذه العلامة كرمز ترخيص للتحكم في وصول العميل إلى موارد الشبكة. ولأن العميل لا يملك صلاحية الوصول إلى الشبكة قبل وكيل الترحيل، فإن عدم وجود مصادقة لا يمنع مشغل خادم DHCP من الاعتماد على رمز الترخيص. ^{[ 22 ] : القسم 7}

يوفر امتداد آخر، وهو مصادقة رسائل DHCP ^{[ 39 ]} (RFC 3118)، آلية لمصادقة رسائل DHCP. وحتى عام 2002، لم يشهد هذا الامتداد انتشارًا واسعًا بسبب مشاكل إدارة المفاتيح لعدد كبير من عملاء DHCP. ^{[ 40 ]} وقد أشار كتاب صدر عام 2007 حول تقنيات DSL إلى ما يلي:

[T] تم تحديد العديد من الثغرات الأمنية في التدابير الأمنية المقترحة في RFC 3118. وقد أدى هذا الأمر، بالإضافة إلى إدخال معيار 802.1X ، إلى إبطاء نشر بروتوكول DHCP الموثق ومعدل استخدامه، ولم يتم نشره على نطاق واسع قط. ^{[ 41 ]}

يشير كتاب صدر عام 2010 إلى ما يلي:

[T] لم تُطبَّق مصادقة DHCP إلا في عدد قليل جدًا من التطبيقات. وقد اعتُبرت تحديات إدارة المفاتيح وتأخيرات المعالجة الناتجة عن حساب التجزئة ثمنًا باهظًا جدًا مقارنةً بالفوائد المتوقعة. ^{[ 42 ]}

تتضمن المقترحات المعمارية من عام 2008 توثيق طلبات DHCP باستخدام 802.1X أو PANA (وكلاهما ينقل بروتوكول EAP ). ^{[ 43 ]} وقُدِّم اقتراح من قِبل فريق هندسة الإنترنت (IETF) لإدراج بروتوكول EAP في بروتوكول DHCP نفسه، وهو ما يُعرف باسم EAPoDHCP ؛ ^{[ 44 ]} ويبدو أن هذا الاقتراح لم يتجاوز مرحلة مسودة IETF، والتي يعود تاريخ آخر مسودة لها إلى عام 2010. ^{[ 45 ]}

• RFC 2131 – " بروتوكول تكوين المضيف الديناميكي، " ^{[ 1 ]} مسودة المعيار. 
• RFC 2132 – " خيارات DHCP وامتدادات بائع BOOTP، " ^{[ 14 ]} مسودة معيار. 
• RFC 3046 – " خيار معلومات وكيل ترحيل DHCP، " ^{[ 22 ]} معيار مقترح. 
• RFC 3203 – " امتداد إعادة تكوين DHCP، " ^{[ 16 ]} معيار مقترح. 
• RFC 3397 – " خيار البحث عن مجال بروتوكول تكوين المضيف الديناميكي (DHCP) " ، ^{[ 26 ]} معيار مقترح. 
• RFC 3442 – " خيار المسار الثابت بدون فئات لبروتوكول تكوين المضيف الديناميكي (DHCP) الإصدار 4، " ^{[ 27 ]} معيار مقترح. 
• RFC 3942 – " إعادة تصنيف خيارات بروتوكول تكوين المضيف الديناميكي الإصدار 4 (DHCPv4) " ، ^{[ 46 ]} المعيار المقترح. 
• RFC 4361 – " معرفات العميل الخاصة بالعقدة لبروتوكول تكوين المضيف الديناميكي الإصدار الرابع (DHCPv4) " ، ^{[ 47 ]} معيار مقترح. 
• RFC 4388 – " بروتوكول تكوين المضيف الديناميكي (DHCP) استعلام التأجير، " ^{[ 17 ]} معيار مقترح. 
• RFC 4436 – " الكشف عن اتصال الشبكة في IPv4 (DNAv4) " ، ^{[ 48 ]} المعيار المقترح. 
• RFC 6926 – " DHCPv4 Bulk Leasequery, " ^{[ 18 ]} معيار مقترح. 
• RFC 7724 – " استعلام تأجير DHCPv4 النشط، " ^{[ 19 ]} معيار مقترح. 
• RFC 8415 – " بروتوكول تكوين المضيف الديناميكي لـ IPv6 (DHCPv6) " ، ^{[ 10 ]} معيار مقترح. 

• الوسائط المتعلقة ببروتوكول التكوين الديناميكي للمضيف (DHCP) على ويكيميديا ​​كومنز