DHCP Lyskov

Вступ

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

Протокол DHCP був запропонований в 1993 р, його розвитком займається спеціальна робоча група (DHC WG), що входить до складу IETF. Найбільш повний сучасне опис DHCP міститься в документі RFC 2131 (березень 1997 г.), який прийшов на зміну більш раннім редакціям RFC 1531 і RFC 1541. В даний час DHCP має статус попереднього стандарту.

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

При розробці протоколу DHCP головною метою було усунути обидва обмеження. Був потрібен механізм, який дозволив би ліквідувати стадію ручного конфігурування комп'ютерів, підтримував багатосегментні мережі, не вимагаючи наявності DHCP-сервера в кожній підмережі, що не конфліктував би з існуючими мережевими протоколами і комп'ютерами, що мають статичну конфігурацію, був здатний взаємодіяти з ретранслюючими агентами протоколу BOOTP і обслуговувати BOOTP-клієнтів і, нарешті, допускав управління переданими параметрами конфігурації. Що стосується більш вузьких завдань, то DHCP повинен був забезпечувати унікальність мережевих адрес, використовуваних різними комп'ютерами мережі в даний момент, збереження колишньої конфігурації клієнтської станції після перезавантаження клієнта або сервера, автоматичне присвоєння параметрів конфігурації знову підключеним машинам.

Принципи архітектури і формат повідомлень

Робота протоколу DHCP базується на класичній схемі клієнт-сервер. У ролі клієнтів виступають комп'ютери мережі, які прагнуть отримати IP-адреси в так звану оренду (lease), а DHCP-сервери виконують функції диспетчерів, які видають адреси, контролюють їх використання і повідомляють клієнтів необхідні параметри конфігурації. Сервер підтримує пул вільних адрес і, крім того, веде власну реєстраційну базу даних. Взаємодія DHCP-серверів зі станціями-клієнтами здійснюється шляхом обміну повідомленнями.

Повідомлення DHCP (в дужках - розмір поля в байтах):

op (1)	htype (1)	hlen (1)	hops (1)
xld (4)
secs (2)		flags (2)
claddr (4)
yiaddr (4)
ciaddr (4)
giaddr (4)
chaddr (16)
sname (64)
file (128)
option (variable)

Опис полів повідомлення DHCP:

Поле	Опис
op	Тип повідомлення (1 = BOOTREQUEST, 2 = BOOTREPLY)
htype	Тип адреси обладнання
hlen	Довжина адреси обладнання
hops	Використовується ретранслюючим агентом
xid	Ідентифікатор транзакції між сервером і клієнтом
secs	Час з моменту видачі DHCPREQUEST або початку поновлення конфігурації
flags	Прапори (перший біт маркує широкомовні повідомлення)
ciaddr	IP-адреса клієнта
yiaddr	<Ваша> (клієнтська) IP-адреса
siaddr	IP-адреса наступного сервера, який бере участь у завантаженні
giaddr	IP-адреса ретранслююючого агента
chaddr	<Апаратна> адреса клієнта
sname	Хост-ім'я сервера (опція)
file	Ім'я завантажуваного файлу
options	Поле додаткових параметрів

Згадана вище вимога підтримки базових елементів протоколу BOOTP виникло не випадково. DHCP розроблявся як безпосереднє розширення BOOTP і саме в такій якості сприймається BOOTP-клієнтами. Цій обставині в першу чергу сприяє формат повідомлень DHCP, багато в чому збігається з форматом, який застосовується протоколом-попередником і визначено в документі RFC 951.

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

Зазначені відмінності зажадали часткового розширення формату повідомлень. Так, в ньому з'явилося окреме поле ідентифікатора клієнта, зроблена більш прозорою інтерпретація адреси сервера (поле siaddr), змінний розмір отримало поле options, що використовується, зокрема, для передачі параметрів конфінгурації (його довжина зазвичай знаходиться в діапазоні 312-576 байт, хоча можливо і додаткове розширення цього поля за рахунок полів sname і file).

У ролі транспортного протоколу для обміну DHCP-повідомленнями виступає UDP. При відправці повідомлення з клієнта на сервер використовується 67-й порт DHCP-сервера, при передачі в зворотному напрямку - 68-й. Ці номери портів, як і схожа структура повідомлень, забезпечують зворотню сумісність DHCP з BOOTP. Конкретні процедури взаємодії клієнтів і серверів BOOTP і DHCP регламентує документ RFC 1542.

Управління IP-адресами

Протокол DHCP підтримує три механізми виділення адрес: автоматичний, динамічний і ручний. У першому випадку клієнт отримує постійну IP-адресу, в останньому DHCP використовується тільки для повідомлення клієнта про адресу, який адміністратор присвоїв йому вручну. Обидва ці варіанту не таять в собі чогось принципово нового, а ось динамічний механізм заслуговує детального розгляду.

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

Видача нової адреси

Послідовність дій в цьому випадку така:

1. Клієнт надсилає у власну фізичну підмережу широкомовне повідомлення DHCPDISCOVER, в якому можуть зазначатися IP-адреса і термін його оренди, які влаштовують клієнта. Якщо в даній підмережі DHCP-сервер відсутній, повідомлення буде передано в інші підмережі ретранслюючими агентами протоколу BOOTP (вони ж повернуть клієнту відповідні повідомлення сервера).
2. Будь-який з DHCP-серверів може відповісти на повідомлення DHCPDISCOVER, що надійшло, повідомленням DHCPOFFER, включивши в нього доступну IP-адресу (yiaddr) і, якщо потрібно, параметри конфігурації клієнта. На цій стадії сервер не зобов'язаний резервувати вказану адресу. В принципі, він має право запропонувати його іншим клієнтам, також відправивши запит DHCPDISCOVER. Проте специфікації RFC 2131 рекомендують серверам без необхідності не застосовувати подібну тактику, а крім того, переконатися (наприклад, видавши echo-запит ICMP) в тому, що запропонована адреса в поточний момент не використовується будь-яким з комп'ютерів мережі.
3. Клієнт не зобов'язаний реагувати на першу ж пропозицію, що поступила. Допускається, щоб він дочекався відгуків від декількох серверів і, зупинившись на одному з пропозицій, відправив в мережу широкомовне повідомлення DHCPREQUEST. У ньому містяться ідентифікатор обраного сервера і, можливо, бажані значення запитуваних параметрів конфігурації. Не виключено, що клієнта не влаштує жодна з серверних пропозицій. Тоді замість DHCPREQUEST він знову видасть в мережу запит DHCPDISCOVER, а сервери так і не дізнаються, що їх пропозиції відхилені. Саме з цієї причини сервер не зобов'язаний резервувати поміщену в DHCPOFFER адресу. Якщо в процесі очікування серверних відгуків на DHCPDISCOVER досягнутий тайм-аут, клієнт видає дане повідомлення повторно.
4. Присутній в повідомленні DHCPREQUEST ідентифікатор дозволяє відповідному DHCP-серверу переконатися в тому, що клієнт прийняв саме його пропозиція. У відповідь сервер відправляє підтвердження DHCPACK, що містить значення необхідних параметрів конфігурації, і робить відповідний запис в базу даних. Якщо до моменту надходження повідомлення DHCPREQUEST запропонована адреса вже <пішла> до іншого клієнта (наприклад, перша станція занадто довго <міркувала> над пропозиціями, що надійшли), сервер відповідає повідомленням DHCPNACK.
5. Отримавши повідомлення DHCPACK, клієнт зобов'язаний переконатися в унікальності IP-адреси (засобами протоколу ARP) і зафіксувати сумарний термін його оренди. Останній розраховується як час, що минув між відправкою повідомлення DHCPREQUEST і прийомом відповідного повідомлення DHCPACK, плюс термін оренди, зазначений в DHCPACK. Виявивши, що адреса вже використовується іншою станцією, клієнт зобов'язаний відправити серверу повідомлення DHCPDECLINE і не раніше ніж через 10с почати всю процедуру знову. Процес конфігурації відновлюється і при отриманні серверного повідомлення DHCPNACK. При досягненні тайм-ауту в процесі очікування серверних відгуків на повідомлення DHCPREQUEST клієнт видає його повторно.
6. Для дострокового припинення оренди адреси клієнт відправляє серверу повідомлення DHCPRELEASE.

Наведена послідовність дій помітно спрощується, якщо станція-клієнт бажає повторно працювати з IP-адресою, яка колись уже була їй виділена. В цьому випадку першим повідомленням є DHCPREQUEST, в якому клієнт вказує адресу, якою вже користувався. У відповідь він може отримати повідомлення DHCPACK або DHCPNACK (якщо адреса зайнята або клієнтський запит є некоректним, наприклад через переміщення клієнта в іншу підмережа). Обов'язок перевірити унікальність IP-адреси знову-таки покладається на клієнта.

Вибір адреси DHCP-сервером

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

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

Закінчення строку оренди

У міру того як термін оренди добігає кінця, клієнт може завершити роботу з даною адресою, відправивши на DHCP-сервер повідомлення DHCPRELEASE, або завчасно запросити продовження терміну оренди. У першому випадку повернення в мережу буде вимагати виконання всієї процедури ініціалізації заново. У другому - станція продовжить функціонувати в мережі без видимого уповільнення роботи користувальницьких додатків.

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

У момент T1 клієнт відправляє DHCP-серверу, який видав адресу, повідомлення DHCPREQUEST з проханням продовжити термін оренди. Отримавши позитивну відповідь (DHCPACK), клієнт перераховує термін оренди і продовжує роботу в звичайному режимі. Клієнт очікує приходу відповіді від сервера протягом (T2 - t) / 2 с (за умови, що це значення не менш 60 с), де t - час відсилання останнього повідомлення DHCPREQUEST, після чого відправляє дане повідомлення повторно.

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

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

Недоліки DHCP

Звільняючи мережевих адміністраторів від безлічі рутинних операцій, DHCP залишає невирішеними ряд проблем, які рано чи пізно можуть виникнути в реальному мережевому середовищі.

До недоліків цього протоколу насамперед слід віднести вкрай низький рівень інформаційної безпеки, що обумовлено безпосереднім використанням протоколів UDP і IP. В даний час не існує практично ніякого захисту від появи в мережі несанкціонованих DHCP-серверів, здатних розсилати клієнтам помилкову або потенційно небезпечну інформацію - некоректні або вже задіяні IP-адреси, невірні відомості про маршрутизації і т.д. І навпаки, клієнти, запущені з поганими цілями, можуть отримувати конфігураційні відомості, призначені для <законних> комп'ютерів мережі, і тим самим відтягувати на себе значну частину наявних ресурсів. Зрозуміло, що можливості адміністративного обмеження доступу, про які говорилося вище, не здатні закрити цю діру в системі інформаційної безпеки.

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

Питання до статті

1. Які існують інші варіанти розподілення адрес в мережі? (Бас)

BOOTP, DRARP, TFTP, ICMP, NIP - ймовірно, це ще не повний перелік протоколів, що в тій чи іншій мірі претендують на вирішення завдання управління IP-адресами і конфігурацією в мережевому середовищі. Не виключено, що після стандартизації DHCP досить швидко витіснить їх зі сцени, проте на сьогоднішній день багато хто з названих протоколів нерідко згадуються в літературі і використовуються в готових продуктах.

Подібно DHCP, протокол Bootstrap Protocol (BOOTP) сьогодні також має статус попереднього стандарту і рекомендований до застосування консорціумом IETF. Саме його слід вважати безпосереднім попередником DHCP. Доповнення, що з'явилися в 1993 р, розширили перелік конфігураційних параметрів, які охоплюються протоколом BOOTP. Більш того, до теперішнього часу навіть запропонована модифікація BOOTP, що підтримує динамічне призначення IP-адрес.

Протокол Reverse Address Resolution Protocol (RARP), вперше описаний в червні 1984 (RFC 903), використовується компанією Sun Microsystems і рядом інших виробників, зокрема, для запуску бездискових робочих станцій. Основний принцип його роботи зводиться до того, що клієнт повинен самостійно відшукати свою IP-адресу, а не прийняти адресу, виділену сервером. Порівняно недавно з'явився динамічний варіант цього протоколу (Dynamic RARP, DRARP), який реалізує алгоритм автоматичного присвоєння IP-адрес.

Спрощений варіант FTP - протокол Trivial File Transfer Protocol (TFTP) - побачив світ близько 20 років тому, його друга версія описана в документі RFC 783. Фактично TFTP надає транспортний механізм для передачі з сервера завантажувального образу клієнтської системи.

Протокол Internet Control Message Protocol (ICMP) сьогодні також можна віднести до покоління ветеранів Всесвітньої мережі. Він дозволяє інформувати комп'ютери про наявність в мережі додаткових маршрутизаторів (є спеціальний механізм для виявлення цих пристроїв), передбачає спеціальні типи повідомлень для передачі маски підмережі та інших службових відомостей.

Нарешті, протокол Network Information Protocol (NIP) був розроблений в кінці 80-х рр. співробітниками Массачусетського технологічного інституту в якості розподіленого механізму для динамічного присвоєння IP-адрес в мережах Ethernet.

2. Що спільного між DHCP та VLAN? (Носко)

3.