
- •Тема 1. Мережеві операційні системи, ос FreeBsd
- •Контрольні питання
- •Література
- •Тема 2. Ядро ос FreeBsd і управління програмним забезпеченням
- •Література
- •Тема 3. Мережева підсистема FreeBsd
- •Література
- •Тема 4. Маршрутизація трафіку в ос FreeBsd
- •Література
- •Тема 5. Динамічне налаштування мережевих інтерфейсів
- •Література
- •Тема 6. Засоби фільтрації трафіку
- •Література
- •Тема 7. Трансляція мережевих адрес
- •Література
- •Тема 8. Служба доменних імен
- •Література
- •Тема 9. Поштові служби. Протоколи smtp, pop3
- •Література
- •Тема 10. Протокол imap
- •Література
- •Тема 11. Обмін файлами у мережах. Протокол ftp
- •Література
- •Тема 12. Обмін файлами у мережах. Nfs, smb, BitTorrent
- •Література
- •Тема 13. Веб-сервер на основі ос FreeBsd
- •Література
- •Тема 14. Проксі –сервер. Сервіси моніторингу
- •Література
- •Тема 15. Захищені віртуальні канали. Стек протоколів ipSec
- •Література
Література
Джо Брокмайер, Ди-Анн Лебланк, Рональд Маккарти, мл. Маршрутизация в Linux = Linux Routing. — М.: «Вильямс», 2002. — С. 240. — ISBN 1-57870-267-4
Аллан Леинванд, Брюс Пински Конфигурирование маршрутизаторов Cisco = Cisco Router Configuration. — 2-е изд. — М.: «Вильямс», 2001. — С. 368. — ISBN 1-57870-241-0
Тема 5. Динамічне налаштування мережевих інтерфейсів
Основи роботи протоколу DHCP
Термін протокол DHCP перекладається з англійської, як Dynamic Host Configuration Protocol і являє собою Інтернет протокол, що дає можливість вузлам отримувати IP адресу автоматично в мережі TCP/IP.
Окрім IP адреси через протокол DHCP клієнт, іншими словами вузол, або комп'ютер в мережі отримує також такі додаткові параметри, як: IP-адреса маршрутизатора по замовчуванню; маска підмережі; адреса DNS сервера.
Сам протокол DHCP є клієнт-серверним. Тобто ПК в мережі отримують автоматичні налаштування від DHCP сервера.
Рисунок 5.1 – Процедура отримання адреси по DHCP
Процес взаємодії сервера і клієнта відбувається в наступному порядку (див. рисунок 5.1). Сервер отримує запит і відгукується з пропозицією про оренду (lease), що містить конфігураційні дані для хоста; ресурс, що міститься у пропозиції, тимчасово блокується для пропозиції іншим хостам до отримання відповіді від хоста або закінчення тайм-ауту. Хост може отримати пропозиції від декількох DHCP-серверів, що працюють в його мережі. Хост, на підставі налаштувань свого DHCP-клієнта, вирішує прийняти пропозицію певного сервера (або прийняти перше пропозицію, що поступила, якщо ніяких налаштувань немає). Хост відповідає вибраного сервера сполученням "вибір". Сервер підтверджує видачу оренди; після отримання підтвердження хост конфігурує себе відповідно з отриманими даними. IP-адреса, присвоюється робочої станції, може братися сервером з простору спеціально для цього виділених адрес (береться перший вільний адреса). У цьому випадку у робочої станції немає постійного IP-адреси. Робоча станція тільки від випадку до випадку потребує TCP/IP – для доступу до даних на віддаленій мережі. Користувач може працювати на портативному комп'ютері, який у різний час буде з'єднуватися з різними частинами мережі, і нічого не буде знати про те, що використовуваний їм адресу змінюється. Питання "оренди адреси" вирішує сам комп'ютер, у фоновому режимі взаємодіючи з DHCP-сервером. Тривалість володіння адресою змінна, її встановлює адміністратор мережі. Коли відведений відрізок часу вичерпується, пристрій повідомить про необхідність оновити адресу – все це знову відбувається за лаштунками. Весь цикл оновлення повторюється без втручання користувача або адміністратора. Коли термін оренди вичерпується остаточно, IP-адреса стає доступний для інших користувачів в локальній мережі. Система надання адрес в DHCP дає можливість мати в локальній мережі IP-клієнтів більше, ніж доступно реальних адрес, що дозволяє використовувати IP як вторинного протоколу, який бере участь тільки в обмінах з глобальною мережею.
IP-адреса, присвоюється конкретної робочої станції, може бути і фіксованим, для цього треба знати MAC-адресу (Ethernet-адреса) робочої станції і відповідним чином налаштувати сервер.
Формат повідомлень DHCP
Сімейство протоколів ТСР/ІР має безліч переваг, але в той же час його основним недоліком є складність управління адресами: потрібно чимало зусиль щоб підтримувати мережу ТСР/ІР в робочому стані. Проблема пов'язана з необхідністю коректної ІР адреси для кожного пристрою в мережі. Згідно з п'ятьма основними правилами присвоєння ІР адрес це може бути досить не просто реалізувати. Наприклад, необхідно забезпечити унікальність кожної адреси в мережі; якщо хост переносять з однієї підмережі в іншу, то частину адреси з номером підмережі потрібно змінити згідно з номером нової підмережі.
Протокол DHCP впроваджує динамічну настройку параметрів конфігурації Інтернет хостів. Він складається з двох компонентів: протоколу для видачі спеціальної хост конфігурації параметрів з DHCP серверу вузлам і механізму розповсюдження мережних адрес вузлам. DHCP побудовано на моделі клієнт-сервер, в якій обладнаний DHCP сервер розподіляє мережні адреси і видає конфігураційні параметри динамічно обладнаним хостам. Тут термін "сервер" відносять до хоста , який впроваджує ініціалізацію параметрів через DHCP, а термін "клієнт" означає хост, що отримує ці параметри від DHCP сервера. Хост не може працювати як DHCP сервер поки не буде спеціально зконфігурований системним адміністратором.
DHCP підтримує три механізми ІР адресного розміщення: "автоматичний", "динамічний" та "ручний". В "автоматичному розміщенні" DHCP оголошує постійну (перманентну) ІР адресу хосту. В "динамічному розміщенні" DHCP оголошує ІР адресу хоста на певний обмежений проміжок часу (або поки хост явно не відмовиться від адреси). В "ручному розміщенні" ІР адреса повідомляється мережним адміністратором, а DHCP використовується лише для транспортування(передачі) цієї адреси хосту. Типова мережа звичайно може використовувати один або декілька цих механізмів, в залежності від бажання мережного адміністратора.
Динамічне розташування єдине з трьох механізмів дозволяє автоматично переприсвоювати (перевикористовувати) ІР адресу, яка більше не потрібна попередньому власнику-хоста. Отже, динамічне розташування корисне для присвоєння адреси хосту, який буде під'єднано до мережі тимчасово або для розподілення обмеженої кількості ІР адрес між групою хостів яким не потрібна перманентна ІР адреса. Динамічне розташування є гарним вибором при оголошенні ІР адреси хосту, який раніше був перманентно приєднаний до мережі, в якій з причини нестачі ІР адрес є необхідність їх відновлення коли старий хост відключається. Ручне розташування дозволяє уникнути error-phone процес в документально зконфігурованих хостах. Основою формату DHCP повідомлень є формат BOOTP повідомлень.
Механізм DHCP зберігає мережні параметри клієнтів в базі даних. Записи цієї бази даних складаються з: унікального ідентифікатора клієнта (він може, наприклад, складатись з номера мережі і ідентифікатора хоста в мережі) і значень конфігураційних параметрів клієнтів. Будь-який DHCP-клієнт може запросити свої конфігураційні параметри, використовуючи механізм повідомлень (запит/відповідь).
База даних DHCP містить список доступних ІР адрес і може містити додаткову адресну інформацію про різноманітні мережні ресурси і сервіси. Як тільки комп'ютер, який є клієнтом DHCP сервера, увійшов в мережу і запросив ІР адресу, йому призначається унікальна ІР адреса, котра потім разом з адресами ресурсів передається на цей комп'ютер.
Налагодження параметрів DHCP сервера, а точніше бази даних допустимих адрес здійснюється засобами певного інструментарія. Протокол DHCP в якості транспорта використовує UDP. Повідомлення від DHCP клієнта на DHCP сервер передаються на порт 67, повідомлення від DHCP сервера DHCP клієнту – на прот 68. Формат DHCP пакета показаний на рисунку 5.2 (довжину полів вказано в байтах).
0 |
1 |
2 |
3 |
||||||||||||||||||||||||||||
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
op(1) |
htype(1) |
hlen(1) |
hops(1) |
||||||||||||||||||||||||||||
xid(4) |
|||||||||||||||||||||||||||||||
secs(2) |
flags(2) |
||||||||||||||||||||||||||||||
ciaddr(4) |
|||||||||||||||||||||||||||||||
yiaddr(4) |
|||||||||||||||||||||||||||||||
siaddr(4) |
|||||||||||||||||||||||||||||||
giaddr(4) |
|||||||||||||||||||||||||||||||
chaddr(16) |
|||||||||||||||||||||||||||||||
sname(64) |
|||||||||||||||||||||||||||||||
file(128) |
|||||||||||||||||||||||||||||||
options(312) |
Рисунок 5.2 – Формат повідомлення DHCP
Пояснення:
op - код операції (1 якщо запит, 2 якщо відповідь);
htype - тип машинної адреси (1 для 10Mb Ethernet);
hlen - довжина машинного коду (6 для Ethernet);
hops - поле використовується boot-relay агентом при початковому завантаженні через агента. На машині клієнта встановлюється в значення 0;
xid - ідентифікатор транзакції - випадкове число, що вибирається клієнтом. Використовується для ідентифікації сесії обміну повідомленнями між клієнтом і сервером;
secs - кількість секунд, що пройшла з моменту початку завантаження мережного модуля клієнта (встановлюється клієнтом і використовується для контролю різних часових параметрів);
flags - лівий біт поля (1000000) використовується в якості "широкомовного" повідомлення, інші біти не використовуються і повинні дорівнювати 0;
ciaddr - клієнтська ІР адреса. Поле заповнюється на машині клієнта при передачі повідомлення запиту перевірки відповідності параметрів хоста бази даних DHCP;
yiaddr - клієнтська ІР адреса. Поле заповнюється на DHCP сервері по запиту DHCPOFFER на отримання ІР адреси;
siaddr - ІР адреса наступного DHCP сервера, що опитується при початковому завантаженні мережевого модуля клієнта;
giaddr - ІР адреса relay агента, що використовується при завантаженні через relay агента;
chaddr - машинна адреса клієнта;
sname - строка, що містить ім'я хоста сервера (факультативний параметр);
file - ім'я файла завантаження, ім'я групи завантаження або nul. Поле використовується для ідентифікації тієї частини мережевого забезпечення клієнта, що завантажується;
options - додаткові параметри.
Використання механізмів DHCP призначення ІР адрес має свої переваги:
Користувачам не треба вводити ІР адреси, маски адрес підмереж або іншу інформацію. Вони позбавлені можливості призначити собі будь-яку ІР адресу чи копіювати адресу у сусіда (його комп'ютер з такою адресою працює і мій буде працювати).
Процес ручного розподілення ІР адрес, масок підмереж та іншої конфігураційної інформації містить потенційні помилки навіть якщо користувач достатньо обізнаний з цього приводу. В цьому процесі присутні дуже багато чисел і налагоджень, які надто складно правильно встановити.
DHCP дозволяє користувачам налагоджувати власні комп'ютери без звернення до системного адміністратора за отриманням правильної ІР адреси. Це позбавляє від зайвих помилок і затримки часу.
Коли користувач переміщає комп'ютер на нове місце або, наприклад, працює з ноутбуком в дорозі (що містить PCMCIA Ethernet адаптеро-подібний пристрій) при роботі з вашою мережею комп'ютер буде автоматично отримувати правильну ІР адресу.
Але э також і недоліки. DHCP - відносно новий протокол: перший RFC з'явився в 1993 р. Деякі виробники, тим не менше, вже прийняли його і широко використовують. Найбільш відомий з них, звичайно, Microsoft. Так Windows NT 3.5 і вище мають вмонтовану підтримку DHCP. Windows for Workgroups 3.11 i Windows 95 можуть виступати в якості клієнтів DHCP. Не дивлячись на те , що порівняно з усіма попередніми спробами автоматичного призначення адрес DHCP без сумніву є досягненням, він також має свої недоліки.
Так як DHCP використовує клієнт-серверну модель, клієнт не може працювати якщо сервер DHCP не функціонує. Встановлення довготривалого строку аренди для усунення надто частих запросів на продовження, а також встановлення декількох DHCP серверів для обслуговування нових запросів дозволяє зробити цю модель більш стійкою. Якщо один сервер вийде з ладу, то при 24-годинній аренді у адміністратора буде достатньо часу для переобладнання системи чи встановлення нового хоста з тим самим пулом адрес.
Крім того DHCP сервери не можуть обмінюватись повідомленнями для узгодження бази даних адрес. Ось чому адміністраторам, що мають декілька серверів, необхідно задати діапазон адрес для кожного сервера. Інакше різні клієнти можуть одночасно отримати однакові ІР адреси.
Є декілька Інтернет протоколів і механізмів яким адресується деяка частина проблем динамічної конфігурації хостів.The Reverse Address Resolution Protocol (RARP) вирішує проблему знаходження мережної адреси і включає в себе автоматичний механізм оголошення ІР адреси. The Trivial File Transfer Protocol (TFTP) використовується для транспортування boot image з boot сервера. The Internet Control Message Protocol (ICMP) впроваджений для інформування хостів про додаткові маршрути за допомогою "ICMP redirect" повідомлення, впроваджувати subnet mask інформацію через "ICMP mask request" повідомлення і іншу інформацію через "ICMP information request" повідомлення.
BOOTP це трансформуючий механізм для зберігання інформації про конфігурацію. Він в свою чергу має підрозділи. Їх запропонував Морган для динамічної ІР адресації. The Network Information Protocol (NIP) використовується Athena проектом в МІТ і є розповсюдженим механізмом для оголошення динамічної ІР адресації. The Resource Location Protocol (RLP) впроваджений для розташування сервісів вищого рівня.
Взаємодія клієнта і сервера
Механізм динамічного призначення адрес полягає в наступному (див. рисунок 5.1):
Клієнт подає запит на адресу на певний період часу. Механізм призначення гарантує, що ця адреса не буде використовуватись жодним іншим хостом протягом цього часу, так як клієнт може при необхідності збільшити цей період. По закінченні роботи клієнт повертає цю адресу для подальшого використання. Клієнт також може запросити адресу "назавжди". Тоді сервер видає йому адресу на довготривале, але все ж таки не на постійне використання.
Механізм запиту отримання адреси базується на обміні DHCP повідомленнями між DHCP клієнтом і сервером:
Машина клієнта завантажує обмежену версію ТСР/ІР і відправляє запит DHCPDISCOVER на отримання ІР адреси в даній мережі. Запит містить машинну адресу комп'ютера відправника.
Всі DHCP сервери, які мають можливість призначити новому клієнту адресу, відсилають новому клієнту повідомлення (DHCPOFFER), яке містить клієнтську машинну адресу, надану клієнту ІР адресу, маску адреси підмережі, протяжність строку призначення адреси та ІР адресу сервера, що відправив повідомлення. При відправленні цього повідомлення сервер повинен зарезервувати запропоновану клієнту ІР адресу на той випадок, якщо клієнт погодиться її прийняти.
Клієнт обирає першу отриману адресу. Після цього він розсилає повідомлення DHCPREQUEST всім DHCP серверам, які мають ІР адресу сервера, пропозицію якого було прийнято. Інші сервери звільняють зарезервовану адресу для подальшого використання.
Сервер, адреса якого була прийнята, відправляє повідомлення "подяки" DHCPACK з ІР адресою , маскою адреси підмережі і, можливо, іншою інформацією. Отримавши це повідомлення, клієнт встановлює в себе повну версію ТСР/ІР і може з'єднуватися з іншими хостами на LAN чи WAN. У випадку якщо сервер не може прийняти конфігурацію, він посилає пакет DHCPNAK (відмова в підтвердженні) і клієнт повинен почати процес знову.
Механізм продовження строку використання ІР адреси також працює на основі обміну повідомленнями між клієнтом і сервером.
Якщо клієнтська машина повинна мати завжди одну і ту ж ІР адресу , тоді зручно використовувати механізм "ручного призначення".
Параметри, що можуть бути встановлені
Формат DHCP-повідомлення практично збігається з форматом ВООТР-повідомлення, який описаний в документі RFC 951. Основна відмінність полягає в полі опцій, яке замінило 64-байтное полі "Венд" BOOTP-повідомлення. Поле опцій DHCP-повідомлення являє собою контейнер, розроблений для передачі всіляких параметрів (крім IP-адреси), необхідних для конфігурування стека TCP/IP-системи клієнта. Так як сервер DHCP може бути налаштований для доставки клієнтським системам дуже багатьох різних опцій, опис окремих полів для кожної опції було б вкрай непрактичним.
Поле опцій завжди починається з так званого магічного сигналу (магія Cookie), який інформує сервер про характер вмісту решти частини полів повідомлення. Магія Cookie являє собою 4-байтное підполе, що включає в себе значення в точковій десяткового нотації 99.130.83.99.
Індивідуальні опції в полі опцій містять різні типи і обсяги даних, але більшість з них використовують одну і ту ж базову структуру, яка складається з трьох підполів:
Код (1 байт). Конкретизує функцію опції, як описано в документі RFC 2132.
Довжина (1 байт). Визначає довжину поля даних, асоційованого з даною опцією, дозволяючи системам, які не підтримують конкретну опцію, перейти відразу до наступної.
Дані (змінний розмір). Безпосередньо інформація, яка використовується клієнтом різними способами, залежно від значення підполя коду і типу повідомлення.
Наприклад, в опції Маска підмережі значення підполя коду дорівнює 1, значення підполя довжини становить 4, а підполі даних містить 4-байтную маску, асоційовану з IP-адресою, призначеним клієнту.
Опція DHCP під назвою тип повідомлення ідентифікує сумарну функцію всього DHCP-повідомлення і присутній у всіх пакетах DHCP. Значення в підполях коду і довжини для даної опції рівні, відповідно 53 і 1. Підполе даних розміщує в собі один з кодів, перелічених нижче:
DHCPIDSCOVER. Використовується DHCP-клієнтами для виявлення сервера DHCP і запиту IP-адреси.
DHCPOFFER. Використовується серверами для пропозиції IP-адрес клієнтам.
DHCPREQUEST. Використовується клієнтами DHCP для запиту специфічного IP-адреси або оновлення часу оренди адреси.
DHCPDECLINE. Використовується клієнтами для відхилення DHCP IP-адреси, пропонованого сервером DHCP.
DHCPACK. Використовується серверами DHCP для підтвердження згоди клієнта із запропонованим IP-адресою.
DHCPNACK. Використовується серверами DHCP для відхилення згоди клієнта із запропонованим IP-адресою.
DHCPRELEASE. Використовується клієнтами DHCP для припинення оренди IP-адреси.
DHCPINFORM. Використовується клієнтами DHCP, вже отримали IP-адреси, для запиту додаткових конфігураційних параметрів.
Опціональний елемент DHCP-повідомлення Pad (заповнення) насправді зовсім не опція, а заповнювач, який застосовується для того, щоб кордони полів проходили точно між октетами байтів. На відміну від інших опцій, вона не має підполя, їх довжини і даних, і складається тільки з поля коду із значенням 0.
У силу того, що DHCP-повідомлення переносяться дейтаграммами UDP, пакети обмежені за своїм розміром 576 байтами, і включення в пакет великої кількості опцій може перевищити цю межу. Оскільки поля "Ім'я сервера" і "Ім'я завантажувального файлу" DHCP-повідомлення є спадщиною протоколу ВООТР і в даний час практично незначущі, DHCP стандарт допускає використання цих полів для розміщення інформації опцій, не вміщається в стандартне поле опцій.
Для збереження таких опцій в полі "Ім'я сервера" і/або "Ім'я завантажувального файлу", поле "Опції" пакету має включати в себе код опції Опція Перевантаження, тобто значення 52 в підполі коду і значення 1 в підполі довжини. Підполе даних визначає, в якому з додаткових полів містяться надлишкові опції, задіюючи наступні коди:
додані опції розташовані в полі "Ім'я завантажувального файлу";
додані опції знаходяться в полі "Ім'я сервера";
поля "Ім'я завантажувального файлу" і "Ім'я сервера" обидва містять додаткові опції.
Опція виробника спеціальних інформацій зіставлено стандартом з кодом 43, і призначена для службового використання розробниками з метою постачання інформацією, необхідної для експлуатації їх продуктів. Опція виробника конкретної інформації (залежна від розробника інформація) може містити в собі безліч опцій, задіяних продуктами даного розробника. Для ідентифікації розробника продукту служить опція класу постачальників ідентифікатора (Ідентифікатор класу розробника), що має значення поля коду, що дорівнює 60 і змінну довжину мінімум в 1 байт.
Опція виробника конкретної інформації може містити інкапсульовані опції, що залежать від розробника, що є по суті опціями всередині опції. Структура інкапсульованих опцій аналогічна структурі стандартних опцій DHCP з їх полями "Код", "Довжина" і "Дані". Відмінності полягають у тому, що опція Магія Cookie (Магічний сигнал) не застосовується, і присутність опції End (Кінець) (код 255) означає закінчення лише вкладених опцій, а не всього поля "Опції". Коди, що встановлюються розробниками, не визначаються стандартом, так як їх потрібно розуміти тільки системам, що використовують продукти даного розробника.
Опція End (Кінець) сигналізує про закінчення поля опцій. Будь байт, розміщений в полі "Опції" після опції End, не може містити нічого крім значення 0 (опція Pad). Як і опція Pad, дана опція складається тільки з 1-байтного поля коду із значенням 255 і не має полів довжини і даних.
Додаткових опцій які можна встановити досить багато, і велика кількість з них майже ніколи не використовується, їхній опис легко знайти в Інтернеті.
Налаштування DHCP-клієнта
Коли dhclient, клієнт DHCP, оформлюється на клієнт машині він починає розповсюджувати запроси на конфігураційну інформацію. Ці запроси надходять на UDP порт 68. Сервер відповідає на UDP 67, і дає клієнту ІР адресу та іншу інформацію. Вона надається у вигляді DHCP "оренди" і лише на певний час.
FreeBSD повністю інтегрує ISC DHCP клієнта, dhclient. Підтримку DHCP клієнта забезпечує як installer так і base system, позбавляючи потреби детального знання мережних конфігурацій. dhclient включено у всі FreeBSD дистрибуції починаючи з 3.2. DHCP підтримує sysinstall і bsdinstall. Коли мережний інтерфейс конфігурується sysinstall(ом), перше що вас запитають буде: "Чи ви хочете спробувати DHCP конфігурацію інтерфейсу?" Якщо ви відповісте – так, то буде запущений dhclient.
Якщо ви хочете використовувати DHCP, відредагуйте /etc/rc.conf таким чином:
ifconfig_fxp0="DHCP"
Якщо ви використовуєте різні location для dhclient включіть також наступне:
dhcp_program="/sbin/dhclient"
dhcp_flags=""
DHCP сервер, dhcpd, включено як частину ics-dhcp2 порту в колекції портів. Цей порт містить повний ISC DHCP distribution, що складається з клієнта, сервера, relay агента та документації.
Встановлення і налаштування демона DHCP
Серверна частина пакету не поставляється як частина FreeBSD, так що вам буде потрібно встановити порт net/isc-dhcp42-server для отримання цього сервісу:
# cd /usr/ports/net/isc-dhcp42-server
# make install clean
Для того, щоб налаштувати систему FreeBSD на роботу в якості сервера DHCP, вам необхідно забезпечити присутність пристрою bpf, вкомпільовані в ядро. Для цього додайте рядок device bpf у файл конфігурації вашого ядра.
Пристрій bpf вже входить до складу ядра GENERIC , що поставляється з FreeBSD, так що вам не потрібно створювати власне ядро для забезпечення роботи DHCP.
Ті, хто звертає особливу увагу на питання безпеки, повинні помітити, що bpf є тим пристроєм, що дозволяє нормально працювати Сніффер пакетів (хоча таким програмам потрібні привілейований доступ). Наявність пристрою bpf обов'язково для використання DHCP, але якщо ви дуже стурбовані безпекою, напевно, вам не потрібно включати bpf у ваше ядро тільки тому, що у віддаленому майбутньому ви збираєтеся використовувати DHCP.
Наступним дією, яка вам потрібно виконати редагування зразкового dhcpd.conf, який встановлюється в складі порту net/isc-dhcp42-server. За умовчанням це файл /usr/local/etc/dhcpd.conf.sample, і ви повинні скопіювати його у файл /usr/local/etc/dhcpd.conf перед тим, як його редагувати.
dhcpd.conf складається з декларацій щодо підмереж і хостів, і найпростіше описується на прикладі:
option domain-name "example.com";
option domain-name-servers 192.168.4.100;
option subnet-mask 255.255.255.0;
default-lease-time 3600;
max-lease-time 86400;
ddns-update-style none;
subnet 192.168.4.0 netmask 255.255.255.0 {
range 192.168.4.129 192.168.4.254;
option routers 192.168.4.1;
}
host mailhost {
hardware ethernet 02:03:04:05:06:07;
fixed-address mailhost.example.com;
Опишемо кожен параметр построчно:
Цей параметр задає домен, який буде видаватися клієнтам в якості домену, який використовується за умовчанням при пошуку. Зверніться до сторінок довідкової системи по resolv.conf для отримання додаткової інформації про те, що це означає.
Цей параметр задає список розділених комами серверів DNS, які повинен використовувати клієнт.
Маска мережі, яка буде видаватися клієнтам.
Клієнт може запросити певний час, який буде діяти видана інформація. В іншому випадку сервер видасть налаштування з цим терміном (у секундах).
Це максимальний час, на яке сервер видаватиме конфігурацію. Якщо клієнт запросить більший термін, він буде підтверджений, але буде діяти тільки max-lease-time секунд.
Цей параметр задає – чи буде сервер DHCP намагатися оновити DNS при видачі або звільнення конфігураційної інформації. У реалізації ISC цей параметр є обов'язковим.
Це визначення того, які IP-адреси повинні використовуватися в якості резерву для видачі клієнтам. IP-адреси між і включаючи межі, будуть видаватися клієнтам.
Оголошення маршрутизатора, використовуваного за замовчуванням, який буде видаватися клієнтам.
Апаратний MAC-адресу хоста (щоб сервер DHCP міг розпізнати хост, коли той робить запит).
Визначення того, що хосту завжди буде видаватися один і той же IP-адресу. Зауважте, що вказівка тут імені хоста коректно, оскільки сервер DHCP буде дозволяти ім'я хоста самостійно до того, як видати конфігураційну інформацію.
Коли ви закінчите налаштовувати свій dhcpd.conf , потрібно дозволити запуск сервера DHCP у файлі /etc/rc.conf, додавши в нього рядки:
dhcpd_enable = "YES"
dhcpd_ifaces = "dc0"
Замініть dc0 ім'ям інтерфейсу (або іменами інтерфейсів, розділяючи їх пробілами), на якому(їх) сервер DHCP повинен приймати запити від клієнтів.
Потім ви можете стартувати сервер DHCP за допомогою команди:
# /usr/local/etc/rc.d/isc-dhcpd start
Якщо в майбутньому вам знадобиться зробити зміни в налаштуванні вашого сервера, то важливо зауважити, що посилка сигналу SIGHUP додатком DHCPD не приведе до перезавантаження налаштувань, як це буває для більшості демонів. Вам потрібно послати сигнал SIGTERM для зупинки процесу, а потім перезапустити його за допомогою вищенаведеної команди.
/usr/local/sbin/dhcpd - DHCPD скомпонований статично і розташований в каталозі /usr/local/sbin. Сторінки довідкової системи DHCPD, що встановлюються портом, містять більш повну інформацію про DHCPD.
/usr/local/etc/dhcpd.conf – DHCPD вимагає наявності конфігураційного файлу, /usr/local/etc/dhcpd.conf, до того, як він буде запущений і почне надавати сервіс клієнтам. Необхідно, щоб цей файл містив всі дані, яка видаватиметься які обслуговує клієнтам, а також інформацію про роботу сервера. Цей конфігураційний файл описується на сторінках довідкової системи dhcpd.conf, які встановлюються портом.
/var/db/dhcpd.leases – сервер DHCP веде базу даних виданої інформації в цьому файлі, який записується у вигляді протоколу. Сторінки довідкової системи dhcpd.leases, установлювані портом, дають набагато більш докладний опис.
/usr/local/sbin/dhcrelay – використовується в складних ситуаціях, коли сервер DHCP пересилає запити від клієнта іншого сервера DHCP в окремій мережі. Якщо вам потрібна така функціональність, то встановіть порт net/isc-dhcp42-relay. На сторінках довідкової системи dhcrelay, які встановлюються портом, дається більш повний опис.