پروژه آتی من شامل راهاندازی سرور homelab با بوت شبکه PXE است. این یعنی باید روی DHCP برای خیلی چیزهای بیشتر از فقط تخصیص آدرس IP حساب کنم — نه فقط تخصیص IP.
با وجود اینکه قبلاً روترهای OpenWRT، سرورهای خانگی و شبکههای مجازی راهاندازی کردهام، همچنان DHCP را به خدماتی تقلیل میدادم که فقط آدرس IP به دستگاهها میدهد و از تداخل IP در زیرشبکهها جلوگیری میکند.
قبل از شروع پروژه اصلی، یک شبکه کوچک در VMware Workstation ساختم. یک ماشین مجازی OpenWRT با آدرس ۱۹۲.۱۶۸.۲۴.۲۵۴ به عنوان روتر و سرور DHCP عمل میکرد و یک ماشین مجازی Windows ۱۱ به عنوان کلاینت آزمایشی بود. این دو را از طریق یک شبکه host-only ایزوله به هم متصل کردم و از Wireshark برای ضبط تمام ترافیک استفاده کردم.
همانطور که متوجه شدم، آدرس IP فقط یک بخش کوچک از یک تحویل پیکربندی بسیار بزرگتر بود.
یک تبادل DHCP نیمی از شبکه من را پیکربندی کرد
آدرس IP فقط یک فیلد در پاسخ بزرگتر بود
وقتی ماشین مجازی Windows را مجبور کردم آدرس IP جدیدی با ipconfig /release و ipconfig /renew دریافت کند، Wireshark چهار بسته را ضبط کرد. این چهار بسته با هم فرآیند DHCP را تشکیل میدهند که به اختصار DORA نامیده میشود:
- Windows یک DHCPDiscover广播 میکند تا سرور را پیدا کند.
- سرور DHCP اوپنورت با یک Offer حاوی آدرس موجود و پیکربندی آن پاسخ داد.
- Windows یک Request广播 میکند که تأیید میکند آن پیشنهاد را پذیرفته است.
- سرور DHCP اجاره و تنظیمات آن را با یک Acknowledgment یا به اختصار “ACK” ثبت میکند.
گزینههای DHCP فیلدهای شمارهگذاری شدهای هستند که جزئیات پیکربندی اضافی را همراه با اجاره حمل میکنند. من انتظار داشتم آدرس تخصیص داده شده 192.168.24.138 نیز یکی از این گزینهها باشد. در عوض، سرور آن را در فیلد اختصاصی به نام yiaddr قرار داد که به معنای واقعی کلمه فقط به معنای «آدرس IP شما» است. گزینههای شمارهگذاری شده که بیشتر بسته را پر میکردند، دستورات جداگانهای برای پیکربندی کلاینت حمل میکردند.
از آنجایی که کلاینت Windows قبلاً با سرور DHCP اوپنورت ارتباط برقرار کرده بود، این آدرس را برای اولین بار دریافت نمیکرد. کشف (Discover) آن شامل گزینه ۵۰، یعنی گزینه آدرس IP درخواستی، بود که از اوپنورت میخواست 192.168.24.138 را برگرداند چون آن را از اجاره قبلی به یاد داشت. اوپنورت به سادگی آدرس را بررسی کرد و آن را مستقیماً برگرداند.
ACK نهایی سپس بقیه پیکربندی شبکه را به کلاینت تحویل داد:
- گزینه ۱ ماسک زیرشبکه را روی
255.255.255.0تنظیم میکند. - گزینه ۳
192.168.24.254را به عنوان دروازه تنظیم میکند. - گزینه ۶ درخواستهای DNS را به اوپنورت ارسال میکند که سرورهای DNS بالادستی را تأمین میکند.
- گزینه ۱۵ دامنه LAN را تأمین میکند.
- گزینه ۲۸ آدرس broadcast را تأمین میکند.
- گزینه ۵۴ مشخص میکند سرور DHCP کجاست (در این مورد
192.168.24.254). - گزینههای ۵۱، ۵۸ و ۵۹ مشخص میکنند آدرس IP اجاره شده چقدر دوام دارد.
اجارهای که سرور DHCP اوپنورت تعیین کرده عمر ۱۲ ساعته دارد. همچنین زمان تمدید T1 را پس از ۶ ساعت برنامهریزی میکند که در آن زمان Windows معمولاً با سرور اصلی تماس میگیرد. اگر اجاره تا T2 در ۱۰.۵ ساعت تمدید نشده باشد، Windows مجاز است درخواستی را به هر سرور DHCP موجود广播 کند.
Windows دقیقاً به سرور DHCP گفت چه میخواهد
گزینه ۵۵ یک لیست خرید شگفتانگیز قدیمی را فاش کرد
دومین کشف بزرگ درباره ماهیت DHCP از سمت کلاینت به جای سرور به دست آمد. Windows فقط منفعلانه منتظر نبود سرور DHCP چه چیزی بخواهد بفرستد. کشف (Discover) آن شامل گزینه ۵۵، یعنی لیست درخواست پارامترها، بود. این لیست نوعی مثل یک لیست خرید بزرگ از تنظیماتی است که کلاینت درک میکرد و میخواست سرور آنها را برگرداند.
تحلیل بستههای Wireshark من درخواستهایی از پیکربندی ضروری تا تنظیمات سازگاری قدیمی از اوایل دهه ۹۰ را نشان داد — زمانی که WINS و مسیریابی کلاسی A/B/C هنوز رایج بود:
| دسته | گزینه | آنچه Windows درخواست کرد |
|---|---|---|
| ضروری | 1 | ماسک زیرشبکه |
| ضروری | 3 | روتر |
| ضروری | 6 | سرورهای DNS |
| ضروری | 15 | نام دامنه |
| پیشرفته | 43 | دادههای فروشنده |
| پیشرفته | 114 | اطلاعات پورتال اسیر |
| پیشرفته | 119 | لیست جستجوی دامنه |
| پیشرفته | ۱۲۱، ۲۴۹ | مسیرهای کلاسبندی استاندارد و مایکروسافت |
| پیشرفته | 252 | کشف پراکسی WPAD |
| قدیمی | ۳۱، ۳۳ | کشف روتر و مسیرهای ایستای قدیمی |
| قدیمی | ۴۴، ۴۶، ۴۷ | سرور نام NetBIOS، نوع گره، محدوده |
جالب اینکه Windows ۱۱ همچنین خود را از طریق گزینه ۶۰ با نام MSFT 5.0 معرفی کرد. پس در حالی که سیستم عامل جدید بود، بخشهایی از معرفی DHCP آن شبیه زمانسنج بود.
دو درخواست مسیر جالب بودند. گزینه ۱۲۱ گزینه استاندارد «مسیر CIDR» یا کلاسبندیناپذیر است، در حالی که گزینه ۲۴۹ نسخه مایکروسافت آن است. کلاینت واقعاً هر دو را درخواست کرد، احتمالاً برای دلایل سازگاری. جالب اینکه Windows گزینه ۴۲ را که برای سرورهای Network Time Protocol (NTP) رزرو شده درخواست نکرد.
این نشان میدهد ثبت نام IANA گزینههای DHCP بیشتر شبیه یک منوی سلفسرویس است تا یک چکلیست که هر کلاینتی باید درخواست کند. در این مورد، گزینه ۵۵ هم پاسخ سرور DHCP را ننوشت. سرور همچنان آدرس broadcast را از طریق گزینه ۲۸ تأمین کرد، حتی با اینکه Windows هرگز درخواست نکرده بود.
به نظر میرسد کلاینت حق رأی دارد، اما سرور همیشه حرف آخر را میزند.
چهار گزینه را تغییر دادم و Windows خودش را بازسیمکشی کرد
سرورهای DNS، دامنههای جستجو و یک مسیر ایستا با یک اجاره جدید آمدند
میدانم بخش زیادی از پیکربندی شبکه، مانند DNS، را میتوان به صورت دستی در Windows تغییر داد، اما میخواستم ببینم بدون لمس Windows چقدر میتوانم پیکربندی کنم. پس چهار رشته گزینه DHCP سفارشی جدید به محدوده LAN در اوپنورت اضافه کردم تا سرور DHCP آنها را ارسال کند:
6,9.9.9.9,1.1.1.1به Windows گفت ازQuad9وCloudflareبه عنوان سرورهای DNS IPv4 استفاده کند.15,lab.home.arpaدامنه اختصاصی اتصال را تغییر داد.119,lab.home.arpa,services.home.arpaدو دامنه جستجوی DNS به کلاینت تأمین کرد.121,0.0.0.0/0,192.168.24.254,198.51.100.0/24,192.168.24.254دو مسیر متفاوت تأمین کرد.
پس از انتظار طولانی برای بازگشت سرویس dnsmasq اوپنورت، دومین انتشار و تمدید آدرس IP Windows نشان داد سرور DHCP مقادیر جدید را تحویل داده است:
- رزolverهای IPv4 به
9.9.9.9و1.1.1.1تبدیل شدند. - دامنه اختصاصی اتصال به
lab.home.arpaتغییر کرد. - لیستهای جستجو اکنون شامل هر دو دامنه تأمین شده بودند.
- PowerShell نشان داد
198.51.100.0/24اکنون از طریق اوپنورت مسیریابی میشود. - پروتکل مسیر به صورت Dhcp ظاهر شد.
بررسیهای مستقیم تأیید کرد هر دو رزولور عمومی به درستی پاسخ میدهند. من عملاً یک محدوده DHCP را تغییر دادم و اجاره را تمدید کردم، و حالا Windows بدون نیاز به ویرایش دستی، سرورهای DNS، نامگذاری و پیکربندی مسیریابی داشت.
استفاده از آدرسهای IP فقط مستنداتی در محدودههای IPv4 192.0.2.0/24، 198.51.100.0/24 و 203.0.113.0/24 برای مسیریابی آزمایشی بهترین روش است. آدرسهای IP در این محدودهها برای اهداف مستنداتی رزرو شدهاند و بهترین راه برای جلوگیری از تصادفی هدایت ترافیکی هستند که در غیر این صورت به یک شبکه واقعی عمومی ختم میشود.
DHCP میتواند چیزهای زیادی ارائه دهد، اما نمیتواند همه چیز را کنترل کند
تغییر محدوده IPv4 فقط نیمی از یک کلاینت دو پشتهای را پیکربندی کرد
چندین شکست کوچک از طرف من مانع از آن شد که DHCP را سروری بنامم که بر تمام پیکربندی شبکه حکمرانی میکند. واضحترین محدودیت زمانی ظاهر شد که nslookup را اجرا کردم. اگرچه گزینه ۶ رزولورهای IPv4 Windows را به Quad9 و Cloudflare تغییر داده بود، دستور همچنان اوپنورت را از طریق آدرس IPv6 آن انتخاب میکرد.
نتیجه IPv6 درس ارزشمندی به من داد و در مورد پروژه PXE آتیام فکر کردم. من فقط DHCPv4 را تغییر داده بودم، پس اوپنورت فقط به تبلیغ آدرس IPv6 (fd25:b0d6:47f::1) به عنوان رزولور از طریق پیکربندی IPv6 جداگانه خود ادامه میداد.
البته میتوانم آن را با تأمین سرورهای DNS IPv6 از طریق تنظیمات تبلیغ DHCPv6 اوپنورت رفع کنم. این یک محدودیت غیرقابل حل نیست، اما مسیر دیگری بود که باید بررسی میکردم. هیچکدام از اینها گزینههای DHCP را در هیچ معنایی آرایشی نمیکرد. اوپنورت تمام تنظیمات IPv4 پشتیبانی شدهای را که آزمایش کردم تغییر داد، از جمله مسیری که مستقیماً در Windows نصب شد.
پس از آزمایش، دیگر DHCP را ماشین فروش آدرس IP نمینامم. این بیشتر شبیه سرویس ورود خودکار شبکه است، با آدرس فقط به عنوان اولین آیتم در منو. در نهایت، برای یک اجاره IP آمدم و یک فایل پیکربندی کامل شبکه را داخل آن پیدا کردم.
منبع: این مطلب یک بومیسازی و بازنویسی تحریریهای بر اساس مقالهای از MakeUseOf نوشته Gregory Gibson است: مشاهده مقاله اصلی.