آشنایی تخصصی با DNS و DHCP | ساختار، RFC، فرآیند و کاربرد | قسمت 17 آموزش Embedded Ethernet

DNS چیست؟

در لایه های بالاتر از لایه چهارم؛ پروتکل های بسیار زیادی تعریف شده اند که تعدادی بر اساس UDP کار می کنند (یعنی روی UDP پیاده سازی شده ن). از میان این پروتکل ها؛ دو تاشون خیلی معروف هستند و کاربرد زیادی دارند. اولی به نام DNS (Domain Name Service) شناخته میشه و دومی به نام DHCP (Dynamic Host Control Protocol)

ضرورت استفاده از نام دامنه به‌جای آدرس IP

تا اینجا دیدیم که هنگام برقراری یک ارتباط، دونستن آدرس IP مقصد ضروری هست و فرض کردیم که این آدرس رو داریم. در ابتدای پیدایش شبکه ها؛ چون تعداد IP ها در یک شبکه داخلی کم بود؛ این وظیفه ادمین ها بود که IP ها رو به صورت دستی تنظیم کنند. با گسترش یک شبکه و در نتیجه گسترش فضای آدرس دهی و علاوه بر اون استفاده عمومی از شبکه ها توسط افراد غیرمتخصص؛ داشتن پروتکلی که بشه IP یک هاست رو به طور خودکار تنظیم کرد یا بدست آورد؛ ضروری به نظر می رسید. علاوه بر این، کار با اعداد (در آدرس IP) معمولا سخت تر و نامفهوم تر از به کار بردن اسامی هست. هدف این بود که به جای استفاده از اعداد برای آدرس دهی؛ از اسم یا متن استفاده بشود. واضحه که برای کاربر، استفاده از آدرس یا اسمی مثل google.com بسیار راحت تر و مفهوم تر هست نسبت به آدرسی به شکل14.151.6.17؛ حفظ کردنش هم ساده تره به علاوه تعداد آدرس ها که زیاد بشه؛ استفاده از روش آدرس دهی عددی برای کاربر، بسیار مشکل میشه.

عملکرد DNS و نقش سرورهای آن

 در دهه های قبل از اختراع کامپیوتر و شبکه، در موارد مشابه، مثلا در سیستم تلفن ثابت، راهکارهایی مثل چاپ کتابچه شماره تلفن ها یا استفاده از مرجع شماره تلفن ها (مثل شماره 118 در ایران) کار رو راه مینداخت. اما در دنیای کامپیوترها، این وظیفه هم به عهده خود کامپیوتر و پروتکل ها گذاشته شده. یک سیستمی (کامپیوتر، دیتابیس، سرور؛ سیستم خلاصه!) به اسم DNS سرور وجود داره که شما بهش اسم سایت رو میدید؛ سیستم موردنظر، آدرس IP متعلق به اون اسم رو بهتون میده. به عنوان مثال وقتی در جستجوگر اینترنت (Browser) مینویسید google.com ابتدا یک پیغام برای سرور DNS در شبکه ارسال میشه، اگر آدرس IP این سایت در جداول این سرور باشه؛ بهتون میده وگرنه این پیغام رو به یه DNS سرور دیگه میده تا اون بهتون جواب بده. بهرحال در نهایت شما IP اون سایت رو با این سرویس به دست خواهید آورد.

منابع بیشتر (RFC 882 و آپدیت‌ها)

ما بیشتر از این DNS رو توضیح نمیدیم و شما برای اطلاعات بیشتر میتونید به سند RFC 882 و بروزرسانی های اون مراجعه کنید.

DHCP یا Dunamic Host Configuration Protocol 

و اما DHCP. پروتکل دیگه ای که بر روی UDP کار میکنه؛ DHCP هست که وظیفه ش، دریافت و اعمال تنظیمات یک کلاینت هست. این تنظیمات میتونه شامل خیلی موارد باشه؛ از دریافت آدرس IP تا دریافت فایل بوت (boot) کلاینت، آدرس سرور DNS ، مقدار subnet mask ، آدرس gateway و …

جایگزینی BOOTP با DHCP و دلایل آن

جهت برآورده کردن این منظور؛ در ابتدا از پروتکلی بنام BOOTP (BOOT Protocol ) استفاده میشد اما در نهایت BOOTP با DHCP جایگزین شد. یکی از اصلیترین دلایل تعریف استانداردهای BOOTP و DHCP این موضوع بود که تخصیص آدرس IP به کلاینت ها، کاملا خودکار (اما با اعمال نظر ادمین شبکه) باشه تا احیانا تداخل آدرس (دو یا چند سیستم با یک آیپی) در شبکه نداشته باشیم. تا اینجای کار، ما (برنامه نویس) آدرس IP رو داخل کد به صورت ثابت نوشته بودیم؛ اما واضحه که این روش، روش درستی برای این کار نیست. فرض کنید در یک شبکه صدها سیستم وجود داشته باشه؛ آیا میخواهیم به صورت دستی، تک تک اون ها رو آدرس دهی کنیم؟ به علاوه، از امکانات یک شبکه، ممکنه تعداد بسیار زیادی سیستم، بخواهند استفاده کنند و ما با محدودیت آدرس مواجه باشیم. لذا در DHCP، تمهید لازم برای اختصاص موقت یک آدرس IP به یک هاست هم دیده شده.

مشکل آدرس‌دهی دستی و ضرورت تخصیص خودکار

اگر قرار بود هر سیستمی یک آیپی دایمی داشته باشه؛ به سرعت با کمبود آدرس مواجه می شدیم. وقتی یک ارتباط قطع میشه یا مهلت اجاره آدرس تموم میشه؛ سرور DHCP، از اون آیپی برای دستگاه های دیگه استفاده خواهد کرد.

مفهوم اجاره موقت آدرس IP (Lease Time)

در یک ارتباط اینترنتی نیز اگر دقت کرده باشید؛ احتمالا متوجه این موضوع شده اید که گاهی در حین ارتباط، آدرس IP شما تغییر میکنه. به این مفهوم اصطلاحا lease Time  یا زمان اجاره گفته میشه. قبل از سرآمدن مهلت اجاره؛ هاست میهمان (کلاینت) باید تقاضای تمدید مهلت رو بکنه که ممکنه پذیرفته نشه؛ یا اگر پذیرفته بشه؛ یک آدرس جدید به هاست اختصاص داده بشه.

یک سوال؛ الان میدونیم که DHCP از UDP استفاده میکنه. خود UDP هم بر روی پروتکل IP بنا شده ؛ این سیستم که هنوز IP نداره، پس چطوری کار میکنه ؟! (سیستمی که هنوز آدرس IP نداره؛ از پروتکل IP استفاده میکنه تا آدرس IP خودشو بدست بیاره!)

در پروتکل IP هم مثل استاندارد Ethernet ii ؛ یک آدرس خاص داریم که تمام قسمت های اون با بیت های ‘1’ پر شده؛ پس مقدار این IP خاص هست 255.255.255.255 به این آدرس اصطلاحا آدرس عمومی در لایه سوم گفته میشه. در پیاده سازی پروتکل IP و برای برقراری یک ارتباط DHCP ؛ سخت افزار شما (میکروکنترلر) ؛ باید بتونه بسته هایی با آدرس عمومی رو دریافت و پردازش کنه تا بتونه با استفاده از این پروتکل، آدرس IP خودش رو از DHCP server بگیره.

فرآیند کلی ارتباط DHCP (DORA)

فرآیند یک ارتباط مبتنی بر DHCP و اختصاص آدرس IP و تنظیمات دیگه، در چهار مرحله اجرا میشه:

• اکتشاف Discovery (از طرف كلاينت)
• پیشنهاد Offer (از طرف سرور)
• درخواست Request (از طرف كلاينت)
• پذیرش Acknowledge يا عدم پذيرش NACK (از طرف سرور)

به این چهار مرحله اصطلاحا DORA گفته میشه که سرنام چهار مرحله فوق هست. این فرآیند با یک سوال از طرف کلاینت شروع میشه:

“کسی هست بتونه بمن IP بده؟ ترجیح من آیپی فلان هست!” ترجیح یک آدرس خاص؛ مال وقتیه که دستگاه از قبل در شبکه بوده و مدت زمان اجاره ش (Lease Time) تموم شده.

در جواب DHCP server میگه که “فلان آیپی رو دارم، میخوای؟”  البته قبلش ممکنه سرور با یک عملیات خاص مثلا ping يا ARP بررسی کنه که در شبکه دستگاهی با آیپی پیشنهادی وجود نداشته باشه! كلاينت هم ممكنه قبل از درخواست خودش، همين كار رو بكنه.

یک نکته مهم هم اینکه در یک شبکه ممکنه چند DHCP server داشته باشیم و حتا ممکنه این سرورها با هم، همپوشانی آدرس داشته باشند؛ یعنی بخشی از محدوده آدرس دهی آنها یکسان باشه. در نتیجه، کلاینت ممکنه بعد از درخواست اولیه، چندین پیشنهاد دریافت کنه!

در مرحله سوم؛ کلاینت باید از بین جواب های رسیده از سرورهای احتمالی، یکی رو انتخاب کنه و به اون سرور جواب بده که “من فلان آیپی رو برمیدارم” ( مابقی سرورها بدون جواب بمونن، داستان رو فراموش میکنند )

در مرحله آخر (چهارم) هم سرور یک پیغام به کلاینت میفرسته که بگه درخواست پذيرفته يا رد شده؛ هر جای این مراحل، عملیات دچار خطا بشه؛ باید از ابتدا شروع بشه. در نهایت هم، معمولا سرور، آدرس اختصاص یافته رو در جدولی ذخیره میکنه تا از اختصاص مجدد اون به یه سیستم دیگه جلوگیری کنه. کلاینت هم میتونه برای استفاده های بعدی آدرس سرور رو نگه داره.

در ابتدای فرآیند؛ كلاينت فقط مك آدرس خودش رو داره. خودش كه آدرس آيپي نداره، هيچ! مك آدرس و آيپي آدرس سرور رو هم نداره پس پیغام مرحله اول یک پیغام عمومی (هم آیپی آدرس در لایه سوم و هم مک آدرس در لایه دوم) هست، اما در مراحل بعدی که کلاینت و سرور؛ آیپی و مک آدرس های هم رو دارند، ميتونند پیغام ها رو بصورت خصوصی ارسال کنند. البته در حالت خاصي كه كلاينت از قبل، آدرسي رو اجاره كرده باشه؛ داستان فرق ميكنه و چون اون ها همديگه رو ميشناسند، ميتونن از ابتدا پيغام خصوصي (unicast) بفرستن.

حالت‌های مختلف تخصیص IP در DHCP

تا الان مقدار آدرس IP رو بطور مستقیم در کد تعریف کرده بودیم، به این وضعیت اصطلاحا Static IP میگن. با استفاده از پروتکل DHCP قادریم به سه گونه یا روش، مقدار آدرس IP كلاينت رو تعیین کنیم. در اولین حالت بنام Automatic Allocation یک آدرس دایمی به کلاینت داده میشه.

در حالت دوم، سرور یک آدرس IP موقتی (برای مدت زمان مشخص) به کلاینت اختصاص میده. در این حالت، کلاینت میتونه قبل از سر اومدن زمان اجاره؛ این آدرس رو رها (Release) کنه یا اینکه درخواست تمدید بکنه. این حالت رو Dynamic Allocation میگن.

در حالت سوم به نام Manual Allocation؛ اختصاص آدرس بطور مستقیم توسط ادمین شبکه تعیین میشه. این حالت رو با حالت استاتیک نباید اشتباه گرفت. در این حالت، درخواست آدرس IP همچنان توسط پروتکل DHCP انجام میشه؛ اما آدرس، بطور خودکار توسط سرور اختصاص داده نمیشه؛ بلکه ادمین خودش آدرس رو مشخص میکنه.

در دو حالت دیگه هم، بازه ی آدرسی (range) که توسط سرور میتونه اختصاص پیدا کنه؛ عموما توسط ادمین مشخص میشه. مثلا ادمین مشخص میکنه که آدرس اختصاص یافته از 192.168.1.5 تا 192.168.1.150 انتخاب و پیشنهاد بشه. به این بازه در زبان شبکه، مخزن ( pool ) آدرس گفته میشه. در شبکه جهانی اینترنت، از نوع دوم یعنی Dynamic Allocation یا اختصاص پویا استفاده میشه.

پورت‌های اختصاصی DHCP

از آنجاییکه پروتکل DHCP در لایه چهارم کار میکنه؛ دو پورت، 68 برای کلاینت و 67 برای سرور، جهت استفاده در این پروتکل اختصاص یافته اند.

منابع استاندارد RFC 1541

اطلاعات کاملتری از پیاده سازی ؛ روش ها ، مفاهیم و الزامات پروتکل DHCP رو میتونید در سند RFC 1541 و ارجاعات اون پیدا کنید.

و اما پیاده سازی در میکروکنترلر. ابتدا بریم هدر DHCP رو بررسی کنیم.

فرمت هدر DHCP

در شکل زیر فرمت یک پیام DHCP رو مشاهده میکنید، توجه داشته باشید که فرمت هدر در پروتکل های BOOTP, DHCP یکسان هست. اعداد داخل پرانتز تعداد بایت های هر بخش رو مشخص کرده:

توضیح فیلدهای هدر و کاربرد هر کدام

• OP : نوع عملیات (Operation) رو مشخص میکنه. در پیام های ارسالی از کلاینت، این بخش دارای مقدار 0x01 به معناي “درخواست” و در بازگشت داراي مقدار 0x02 به معناي “پاسخ” خواهد بود. همچنين در بخش Options نيز گزینه ای برای مشخص کردن مراحل چهارگانه ای که گفته شد؛ وجود دارد.
• HType : Hardware Type یا نوع سخت افزار؛ برای اترنت 10Mb عدد 0x01 است.
• HLen : Hardware Address Length یا طول آدرس سخت افزاری که برای مک آدرس عدد 0x06 است.
• Hops : تعداد hop ها یا همان روترهاي بين كلاينت و سرور را مشخص ميكند و یادگار پروتکل BOOTP است. اين بخش در DHCP همواره 0x00 است.
• XID : یا شماره شناسایی کلاینت؛ شامل یک عدد تصادفی 4 بایتی است که در مرحله Discovery  توسط کلاینت انتخاب و ارسال میشود. بعد از آن سرور و خود کلاینت از این عدد برای شناسایی همدیگه استفاده میکنند. یادمون هست که گفتیم، ممکنه چندین سرور پاسخ بدهند یا همزمان چندین کلاینت در حال درخواست باشند.
• SECs : در این بخش که از سمت کلاینت نوشته میشود، ثانیه هایی که از شروع بوت کلاینت گذشته است، قرار میگیرد. از این بخش استفاده ای نمیکنیم و عدد 0x0000 را قرار میدهیم.
• Flags : تنها یک بیت ( پر ارزشترین بیت ) از این بخش 16 بیتی، تعریف و استفاده شده است. مابقی بیت ها رزرو شده و همواره صفر هستند. پرارزشترین بیت، به نام بیت B یا همان Broadcast تنها توسط کلاینت، در دو پیام discovery یا Request میتواند ست بشود که به سرور این پیغام را میدهد که پاسخ پیام های کلاینت را به صورت Broadcast یا همگانی (مک آدرس و آیپی آدرس با بیت های ‘1’ ) ارسال کند و بدین معنی است که در حال حاضر کلاینت نمیتواند پیام های خصوصی (unicast) را پردازش کند. فلسفه وجود این بیت هم بنظر واضحه دیگه؛ کلاینت هنوز آدرس نداره،پس از سرور میخواد که فعلا پاسخ پیام ها رو به صورت Broadcast برگردونه. اما خود کلاینت از اونجاییکه مک آدرس و آیپی آدرس سرور رو، در مرحله Offer دریافت کرده؛ از اون ها استفاده میکنه و جواب خودش در مرحله سوم (Request) رو بصورت unicast ارسال میکنه. نتیجه اینکه بخش Flags از طرف کلاینت با مقدار 0x8000 و از طرف سرور با مقدار 0x0000 ارسال میشود.
• CIAddr : یا Client Ip Address شامل 4 بایت برای آدرس آیپی کلاینت. این آدرس در واقع آدرس فعلی(قبلی) کلاینت هست و نه آدرس آیپی جدید. در مرحله اول و دوم مقدار این بخش 0x00000000 خواهد بود (مگر اینکه کلاینت از قبل در شبکه بوده و آدرسی داشته است). در مرحله سوم و چهارم، در این بخش مقدار آیپی اختصاص یافته قرار میگیره. توجه داشته باشد چنانچه بیت B از بخش Flags در مرحله یک توسط کلاینت ست نشده باشه؛ سرور میتونه در مرحله دوم و در هدر پروتکل IP خودش از این آدرس استفاده کنه و پیغام رو unicast بفرسته. شاید گیج کننده باشه. بهرحال ممکنه کلاینت از قبل تو شبکه بوده و آدرس داشته و مدت زمان اجاره ش تموم شده و الان درخواست آیپی جدید یا تمدید آدرس فعلی رو داره؛ از طرفی پیام ها خودشون روی پروتکل IP سوار هستند؛ لذا سرور (اگر بیت B ست نشود) میتونه پیغام رو مستقیم به آیپی فعلی بفرسته. ما حالت ساده رو در نظر میگیرم و فرض میکنیم در ابتدای کار، بردمون میخواد آیپی بگیره؛ لذا این بخش رو با 0x00 پر میکنیم و بیت B رو هم ست میکنیم، خلاص! به جاش باید آدرس آيپي عمومی 255.255.255.255 رو هم تو برنامه ميكرومون پردازش کنیم.
• YIAddr : Your(client) Ip Address در مرحله دوم و چهارم، سرور در اين قسمت آدرس آيپي پيشنهادي رو مينويسه. در مرحله اول و سوم اين قسمت توسط كلاينت با 0x00 پر ميشه.
• SIAddr : Server Ip Address در مرحله اول اين قسمت با 0x00 پر ميشه؛ اما در مراحل دو تا چهار در اين قسمت، آدرس آيپي سرور نوشته ميشه (در مرحله سوم كلاينت ممكنه چند پيشنهاد دريافت كنه و آدرس سرور انتخاب شده رو اينجا مينويسه؛ توجه داشته باشيد كه همزمان در لايه سوم هم آدرس آيپي گيرنده همين هست).
• GIAddr : aGent Ip Addr يا Gateway Ip Addr ؛ آدرس عامل (agnet ، نماينده) باقيمانده از پروتكل BOOTP‌ و در تمام مراحل با 0x00‌ پر ميشه. توجه داشته باشيد كه براي سازگاري با پروتكل BOOTP‌؛ هدر تغيير خاصي نكرده تا سرورهاي DHCP قادر به راه اندازي دستگاه هايي كه هنوز با BOOTP كار ميكنند؛ باشند.
• CHAddr‌ : Client Hardware Address در تمامي مراحل چهارگانه، در 6 بايت ابتدايي اين قسمت مك آدرس كلاينت نوشته ميشه؛ مابقي بايت ها (Octet) با 0x00 پر ميشن. توجه داشته باشيد كه اين يه پروتكل عموميه كه ممكنه در شبكه هايي با آدرس هاي سخت افزاري با تعداد بايت متفاوت استفاده بشه لذا 16 بايت براي اين قسمت در نظر گرفته شده.
• SName يا Server Host Name يك رشته خاتمه يافته با null (رشته هاي متني به فرمت زبان C) در اينجا ممكنه اسم هاست سرور نوشته بشه؛ اما عموما اين قسمت و قسمت بعدي (با هم 192 بايت) با 0x00 پر ميشن مگر اينكه در قسمت Options جا کم بیاد و نياز به بايت هاي اضافي باشه كه از اين فضا استفاده ميشه ( در جاي خودش ميگيم )
• File : در اين قسمت آدرس و نام فايل بوت كلاينت قرار ميگيره (نام فايل و نه خود فايل!). نام فايل ها هم رشته هاي خاتمه يافته با null‌ هستند. ممكنه كلاينت هايي از اين پروتكل استفاده بكنند كه علاوه بر تقاضاي آدرس آيپي و تنطيمات ديگه، نياز به دانلود فايلي براي بوت هم داشته باشند. اين قسمت هم معمولا با 0x00 پر ميشه.
• Options‌ : گزينه هاي اختياري كه ممكنه در اين ارتباط مورد نياز باشند؛ در اين قسمت و به فرم TLV‌ نوع دوم ثبت ميشن (یک بایت برای نوع گزینه، یک بایت برای تعداد داده های گزینه بغیر از دو بایت نوع و طول؛ و در ادامه داده های گزینه قرار می گیرند). اگر تعداد 312 بايت براي كل گزينه ها كافي نباشه؛ كاربر ميتونه از قسمتهاي sname و file هم استفاده بكنه. بدين ترتيب كه از ابتداي بخش گزينه ها شروع ميكنه به نوشتن. وقتي اين قسمت پر شد از ابتداي sname مابقي گزينه ها رو مينويسه مياد پايين. از اونجاييكه ما فقط نياز به داشتن IP‌ داريم، از اين قابليت استفاده اي نميكنيم؛ ولي يك پياده سازي كامل از اين پروتكل، بايد تمامي اين موارد رو رعايت بكنه. تعداد آپشن هاي تعريف شده براي اين پروتكل فهرست بلندی داره كه چنتاش رو در ادامه بررسي مي كنيم. جهت بررسي فهرست كامل گزینه ها به RFC‌ مربوطه يا نت مراجعه كنيد.

در صورتيكه تعداد بايت مورد نياز، كمتر از 312 بایت باشه ، انتهاي اون رو با آپشن 0xFF‌ به عنوان انتهاي بخش گزينه ها پر مي كنيم ؛ همچنین بین گزینه ها میتوان با آپشن 0x00 عملیات pad رو انجام داد. توجه داشته باشید که در پروتکل DHCP گزینه 0xFF بعنوان end of option list است و نه 0x00. معمول هم اینه که افزودن 0x00 طوری صورت میگیره که گزینه ها در مرزهایی با مضرب 4 قرار بگیرند تا پردازش آنها در سمت گیرنده راحت تر باشه.