Dynamic Host Configuration Protocol (DHCP) - мережевий протокол, призначений для автоматичної зміни властивостей мережі на мережевих вузлах. DHCP є однією з ключових служб мережевої інфраструктури і кожен, хто має відношення до комп'ютерних мереж, повинен хоча б у загальних рисах уявляти принципи його роботи.

Для початку давайте згадаємо, що потрібно комп'ютера для роботи в мережі. Наприклад, так виглядає консоль налаштувань мережі в Windows.

Як бачите, для початку роботи комп'ютера потрібен IP-адреса, маска підмережі і шлюз за замовчуванням, а також хоча-б один DNS-сервер. Сама процедура настройки нескладна, при наявності досвіду на один комп'ютер буде потрібно не більше хвилини.Але якщо налаштувати треба не один, а кілька сотень пристроїв, та ще й територіально розташованих в різних місцях? Вручну це зробити практично нереально, тому в корпоративних мережах для централізованого управління мережевими настройками використовуються DHCP-сервера.

За допомогою DHCP вирішуються дві основні проблеми:

• Автоматизація.При наявності в мережі DHCP-сервера не потрібно проводити налаштування на кожному новому клієнтові. Досить один раз налаштувати DHCP-сервер і подальша настройка IP-адрес і інших мережевих параметрів проводиться автоматично;
• Централізоване управління. DHCP-сервер здійснює контроль за виданими адресами, запобігає їх дублювання, а також своєчасно звільняє невикористовувані IP-адреси.

Детально протокол DHCP описаний в документі RFC 2131, ми ж не будемо вдаватися в деталі, а розглянемо тільки основні моменти. Почнемо з процедури отримання налаштувань.

Отримання установок

DHCP працює за схемою клієнт-сервер. Процес отримання налаштувань відбувається в кілька етапів і описується схемою DORA (Discover-Offer-Request-Acknowledge):

Discover (Виявлення)
Клієнт DHCP підключається до мережі і приступає до ініціалізації (стан INIT).Насамперед він шукає в мережі відповідний DHCP-сервер, для чого відправляє запит DHCPDISCOVER на широкомовна адресу 255.255.255.255. В як свою адресу клієнт вказує 0.0.0.0, оскільки свого адреси у нього ще немає. Також в запиті клієнт вказує свій MAC-адресу. Запит доставляється всім комп'ютерам, що знаходяться в даному сегменті мережі, але відповідають на нього тільки DHCP-сервера.

Offer (Пропозиція)
DHCP-сервер, який отримав запит DHCPDISCOVER, аналізує його вміст, вибирає потрібну конфігурацію мережі і відправляють її в повідомленні DHCPOFFER. Зазвичай DHCPOFFER відправляється на MAC-адресу клієнта, зазначений у DHCPDISCOVER, хоча іноді може використовуватися широкомовлення.Якщо в мережі знаходяться декілька DHCP-серверів, то клієнт отримує кілька відповідей DHCPOFFER і вибирає з них один, як правило отриманий першим.

Request (Запит)
Отримавши відповідь сервера, клієнт відповідає повідомленням DHCPREQUEST, в якому "офіційно" запитує у сервера надані настройки.У повідомленні DHCPREQUEST міститься та ж інформація, що і в DHCPDISCOVER, а також IP-адреса обраного DHCP-сервера. DHCPREQUEST відправляється на широкомовна адресу і ті DHCP-сервера, чию адресу відсутня в повідомленні, розуміють що їх пропозиція відкинуто.

Acknowledge (Підтвердження)
DHCP-сервер, адреса якого вказана в DHCPREQUEST, отримує повідомлення і розуміє, що його обрали.Він фіксує прив'язку для клієнта і відповідає повідомленням DHCPACK, підтверджуючи видані клієнту настройки. DHCPACK відправляється на MAC-адресу клієнта, зазначений у DHCPREQUEST. Клієнт отримує повідомлення DHCPACK, перевіряє настройки і застосовує конфігурацію (стан BOUND), яка була отримана в повідомленні DHCPOFFER.

Клієнт може перевірити отриманий від DHCP-сервера адреса, наприклад за допомогою широкомовного ARP-запиту. Якщо виявиться, що запропонований адреса вже використовується в мережі, то клієнт відправляє серверу повідомлення DHCPDECLINE і починає процедуру ініціалізації заново.Повідомлення DHCPDECLINE передається в широкомовному режимі, оскільки клієнт відкидає запропонований йому IP-адреса. DHCP-сервер, отримавши повідомлення DHCPDECLINE, повинен позначити IP-адреса як недоступний, а також повідомити адміністратора про можливі проблеми в конфігурації.

Це стандартна схема отримання налаштувань, але можливі ще кілька варіантів розвитку подій.

У клієнта вже є призначений раніше за адресою

Якщо у клієнта є виданий раніше мережеву адресу і він хоче його використовувати, то можна пропустити деякі етапи. У цьому випадку клієнт передає широковещательное повідомлення DHCPREQUEST, вказуючи в повідомленні наявний у нього адресу.DHCP-cервер, який отримав запит, перевіряє коректність мережі і адреси і в разі успішної перевірки посилає клієнту підтвердження DHCPACK. Клієнт отримує підтвердження і застосовує настройки.

Якщо DHCP-сервер виявляє, що клієнт знаходиться в невідповідному мережі, він відмовляє DHCPNACK.Якщо мережа коректна, то перевіряється наявність запису для цього клієнта і доступність запитаного адреси. Якщо адреса з якої-небудь причини не підходить (наприклад зайнятий), то сервер відмовляє DHCPNACK. Отримавши відмову, клієнт не може користуватися збереженим мережевою адресою і повинен запросити нову адресу, почавши повну процедуру ініціалізації.

Якщо ж на сервері немає запису для цього клієнта, то він вважає, що адреса був виданий іншим DHCP-сервером і просто залишає запит без відповіді. Така поведінка дозволяє перебувати в одній мережі кільком незалежним DHCP-серверів.

У клієнта є адреса, отриманий іншим способом

Якщо у клієнта вже є адреса, призначений будь-яким іншим способом (наприклад вручну) , то він може вимагати від DHCP-сервера тільки конкретні параметри конфігурації (наприклад адреси DNS-серверів) за допомогою повідомлення DHCPINFORM.Повідомлення передається на адресу сервера (якщо він відомий) або Широкомовлення на адресу 255.255.255.255. DHCP-сервер, який отримав повідомлення DHCPINFORM, відповідає повідомленням DHCPACK з необхідними параметрами конфігурації, але без перевірки оренди і виділення мережевої адреси. Повідомлення передається клієнту безпосередньо.Клієнт приймає відповідь і застосовує отримані настройки.

Якщо клієнт не отримує від сервера повідомлення DHCPACK протягом розумного строку очікування, то він повинен видати користувачеві повідомлення про проблему і приступити до роботи в мережі, використовуючи параметри, рекомендовані в RFC тисячу сто двадцять два.

Примітка. Взагалі процедура отримання адреси може кардинально відрізнятися в залежності від налаштувань DHCP-сервера. Наприклад сервер може видати клієнту адресу, що відрізняється від запитаного, запропонувати адреса з іншої підмережі і навіть взагалі відмовити в наданні адреси.Більш того, DHCP-сервер зовсім не повинен відповідати на кожен надійшов до нього запит. Це дозволяє контролювати доступ до мережі, наприклад можна видавати адреси тільки клієнтам, які пройшли певну перевірку.

Оновлення адреси

IP-адреса видається клієнту на певний час, яке називається часом оренди (lease time ).Час оренди залежить від налаштувань сервера і може варіюватися від декількох хвилин до тижнів і навіть місяців. Через половину терміну клієнт пробує відновити оренду. Якщо відразу оновити оренду не вдається, то клієнт буде намагатися зробити це знову аж до закінчення терміну.У тому випадку, якщо всі спроби виявляться невдалими, після закінчення терміну клієнт буде шукати інший DHCP-сервер.

В процесі оновлення клієнт проходить два стану - оновлення адреси (RENEWING) і оновлення конфігурації (REBINDING). Перше стан настає на приблизно половині терміну оренди адреси (T1), друге - після закінчення 87.5% (або 7/8) повного терміну оренди (T2). Для запобігання синхронізації різних клієнтів при розрахунку значень T1 і T2 до них додається випадкове відхилення.

Оновлення адреси (RENEWING)

Цей стан означає, що клієнт може почати процес оновлення оренди. Для поновлення клієнт посилає запит DHCPREQUEST, але не широкомовна, а адресований своєму DHCP-сервера.Сервер отримує запит, після чого можливі два варіанти:

• Сервер погоджується продовжити оренду. Для підтвердження продовження оренди він посилає клієнту повідомлення DHCPACK із зазначенням нового терміну оренди і тих параметрів, які могли змінитися з моменту створення або останнього продовження оренди;
• Сервер відмовляється продовжувати оренду.У цьому випадку він шле клієнту повідомлення про відмову DHCPNACK.

В залежності від отриманого відповіді клієнт:

• У разі позитивної відповіді DHCPACK зазначає новий термін закінчення оренди і всі змінені параметри, отримані від сервера, скидає таймери T1 і T2 і переходить в нормальний (BOUND) стан.
• Отримавши негативну відповідь DHCPNACK негайно переходить в стан ініціалізації (INIT) і починає процедуру отримання оренди заново.

Оновлення конфігурації (REBINDING)

Якщо клієнт відразу не отримує відповідь від сервера на запит поновлення оренди, то він очікує відповідь протягом часу (T2 - t)/2 сек (але не менше 60 сек), де t - час відправки останнього повідомлення DHCPREQUEST, потім відправляє повідомлення повторно.Поки сервер не відповість, клієнт залишається в стані RENEWING і регулярно шле запит DHCPREQUEST на сервер. Протягом цього часу він зберігає свій поточний адресу і продовжує нормально працювати.

Якщо відповідь від сервера не надійшов до моменту T2, клієнт переходить в стан REBINDING і передає уже широковещательное повідомлення DHCPREQUEST зі своїм поточним адресою.У цьому випадку термін повтору запитів DHCPREQUEST розраховується аналогічно попередньому випадку, тільки замість T2 використовується повний час закінчення терміну оренди.

В тому випадку, якщо термін оренди завершується до отримання клієнтом відповіді від сервера, клієнт повинен припинити всі мережеві операції і перейти в стан ініціалізації (INIT).Якщо DHCP-сервер все-таки відповість після завершення оренди, то клієнт може відновити роботу з колишнім адресою.

Звільнення адреси

Клієнт може явно відмовитися від оренди мережевого адреси, передавши сервера повідомлення DHCPRELEASE . Після отримання цього повідомлення сервер позначає адресу як вільний, але зберігає запис з параметрами клієнта в базі на той випадок, якщо клієнт захоче використовувати адресу повторно.Варто уточнити, що клієнт не звільняє оренду при звичайному виключенні, всі налаштування зберігаються локально. Клієнт передає DHCPRELEASE тільки при явної необхідності відмовитися від оренди, наприклад, переходите до іншої подсеть. Також звільнити оренду можна вручну, наприклад за допомогою команди ipconfig/release.

Ще з важливого

Для своєї роботи DHCP використовує протокол UDP. Повідомлення від клієнта до сервера передаються по порту 67 UDP, а повідомлення від сервера клієнту - на порт UDP 68.

Також треба знати, що за замовчуванням повідомлення DHCP обмежені поточної підмережею. Справа в тому, що для своєї роботи DHCP використовує широкомовлення (broadcast), а маршрутизатори не пропускають широкомовний трафік за межі широковещательного домену.

Примітка. Широкомовний домен (broadcast domain) - область мережі, в якій всі вузли можуть спілкуватися між собою за допомогою широкомовлення, без участі маршрутизатора. Зазвичай широковещательному домену відповідає фізична або логічна підмережа.

Так ось, якщо DHCP-сервер і клієнти знаходяться в різних широкомовних доменах і не можуть спілкуватися безпосередньо, то для їх взаємодії потрібен спеціальний DHCP ретранслятор (DHCP relay agent).Ретранслятор є ніби посередником між клієнтом і сервером, він обробляє стандартний широкомовний DHCP-запит і відправляє його на сервер у вигляді адресного (unicast) пакета, а отриманий від сервера відповідь переправляє DHCP-клієнта. У ролі ретранслятора можуть виступати як маршрутизатори, так і спеціальні сервери.Наприклад в Windows Server для цього є спеціальна серверна роль.

Для коректної роботи DHCP необхідно перевірити, що брандмауер не блокує потрібні порти, а якщо DHCP-сервер і клієнти знаходяться в різних підмережах, то переконатися в наявності DHCP relay.

На цьому мабуть закінчимо теоретичну частину.У наступній статті мова піде про налаштування DHCP-сервера на базі Windows Server 2016.