«Налаштування та параметри arp, dns, dhcp серверів»

Протокол ARP

Розглянемо те, як при пересиланні IP-пакета визначається Ethernet-адреса призначення. Для відображення IP-адрес в Ethernet-адреси використовується протокол ARP (Address Resolution Protocol – адресний протокол). Відображення виконується тільки для IP-пакетів, які відправляються, тому що тільки в момент відправлення створюються IP- і Ethernet- заголовки.

Перетворення адрес виконується шляхом пошуку відповідності в таблиці. Ця таблиця, називана ARP-таблицею, зберігається в пам'яті комп'ютера й містить рядки для кожного вузла мережі. У двох стовпцях утримуються IP- і Ethernet-адреси. Якщо потрібно перетворити IP-адресу на Ethernet-адресу, то відшукується запис у ARP-таблиці з відповідною IP-адресою. У таблиці 13.1 наведений приклад спрощеної ARP-таблиці.

Таблиця 13.1 - Приклад спрощеної ARP-таблиці

IP-адреса	Ethernet-адреса
223.1. 2.1	08:00:39:00:2F:C3
223.1. 2.3	08:00:5A:21:A7:22
223.1. 2.4	08:00:10:99:AC:54

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

У ході звичайної роботи мережна програма, така, як TELNET, відправляє прикладне повідомлення, користуючись транспортними послугами TCP. Модуль TCP посилає відповідне транспортне повідомлення через модуль IP. У результаті складається IP-пакет, що повинен бути переданий драйверу Ethernet. IP-адреса місця призначення відома прикладній програмі, модулю TCP і модулю IP. Необхідно на її основі знайти Ethernet-адресу місця призначення. Для визначення необхідної Ethernet-адреси використовується ARP-таблиця.

Як же заповнюється ARP-таблиця? Вона заповнюється автоматично модулем ARP, у міру необхідності. Коли за допомогою існуючої ARP-таблиці не вдається перетворити IP-адресу, то відбувається таке:

1) по мережі передається широкомовний ARP-запит;

2) вихідний IP-пакет ставиться в чергу.

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

IP-адреса відправника	223.1. 2.1
Ethernet-адреса відправника	08:00:39:00:2F:C3
Шукана IP-адреса	223.1. 2.2
Шукана Ethernet-адреса	<порожньо>

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

IP-адреса відправника	223.1. 2.1
Ethernet-адреса відправника	08:00:39:00:2F:C3
Шукана IP-адреса	223.1. 2.2
Шукана Ethernet-адреса	08:00:39:00:2F:C3

Цю відповідь одержує машина, що зробила ARP-запит. Драйвер цієї машини перевіряє поле типу в Ethernet-кадрі й передає ARP-пакет модулю ARP. Модуль ARP аналізує ARP-пакет і додає запис у свою ARP-таблицю. Оновлена таблиця має такий вигляд:

IP-адреса	Ethernet-адреса
223.1. 2.1	08:00:39:00:2F:C3
223.1. 2.2	08:00:28:00:38:A9
223.1. 2.3	08:00:5A:21:A7:22
223.1. 2.4	08:00:10:99:AC:54

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

1. По мережі передається широкомовний ARP-запит.

2. Вихідний IP-пакет ставиться в чергу.

3. Повертається ARP-відповідь, що містить інформацію про відповідність IP- і Ethernet-адрес. Ця інформація заноситься в ARP-таблицю.

4. Для перетворення IP-адреси в Ethernet-адресу IP-пакета, поставленого в чергу, використовується ARP-таблиця.

5. Ethernet-кадр передається по мережі Ethernet.

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

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

Деякі реалізації IP- й ARP- протоколів не ставлять у чергу IP-пакети на той час, поки вони чекають ARP-відповідей. Замість цього IP-пакет просто знищується, а його відновлення покладається на модуль TCP або прикладний процес, що працює через UDP. Таке відновлення виконується за допомогою таймаутів і повторних передач. Повторна передача повідомлення відбувається успішно, тому що перша спроба вже викликала заповнення ARP-таблиці.

Слід зазначити, що кожна машина має окрему ARP-таблицю для кожного свого мережного інтерфейсу.

DNS-сервера : поняття, типи, види

DNS (Domain Name System,) — розподілена система перетворення імені хоста (комп'ютера або іншого мережевого пристрою) в IP-адресу.

Кожен комп'ютер в Інтернеті має свою власну унікальну адресу — число, яке складається з чотирьох байтів. Оскільки запам'ятовування десятків чи навіть сотень — не досить приємна процедура, то всі (чи майже всі) машини мають імена, запам'ятати які (особливо якщо знати правила утворення імен) значно легше.

Уся система імен в Інтернеті — ієрархічна. Це зроблено для того, щоб не підтримувати одне централізоване джерело, а роздати владу на місця.

За виконуваними функціями DNS-сервери поділяються на декілька груп. Залежно від конфігурації, конкретний сервер може відноситися до декількох типів – авторитативний DNS-сервер — сервер, що відповідає за будь-яку зону.

Мастер або первинний сервер (в термінології BIND) — сервер, що має право на внесення змін в дані зони. Зазвичай для зони буває тільки один мастер-сервер. У випадку Microsoft DNS-сервера і його інтеграції з Active Directory, мастер-серверів може бути декілька (так як реплікація змін здійснюється не засобами DNS-сервера, а засобами Active Directory, за рахунок чого забезпечується рівноправність серверів і актуальність даних);

Слейв або вторинний сервер, що не має права на внесення змін в дані зони і отримує повідомлення про зміни від мастер-сервера. На відміну від мастер-сервера їх може бути (практично) необмежена кількість. Слейв так само є авторитативним сервером (і користувач не може розрізнити мастер і слейв, різниця з'являється тільки на етапі конфігурування/внесення змін до налаштувань зони);

Кешуючий DNS-сервер — сервер, який обслуговує запити клієнтів, (отримує рекурсивний запит, виконує його за допомогою нерекурсивних запитів до авторитативних серверів, або передає рекурсивний запит DNS-серверу, що стоїть вище у ієрархії);

Локальний DNS-сервер; використовується для обслуговування DNS-клієнтів, які працюють на локальній машині. Фактично, це різновид кешуючого DNS-сервера, сконфігурованого для обслуговування локальних додатків;

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

Кореневий DNS-сервер — сервер, який є авторитативним у кореневій зоні. Загальновживаних кореневих серверів у світі всього 13 штук, їх доменні імена знаходяться в зоні root-servers.net і називаються a.root-servers.net, b.root-servers.net, …, m.root-servers.net. У певних конфігураціях локальної мережі можлива ситуація налаштування локальних кореневих серверів;

Реєструючий DNS-сервер. Сервер, що приймає динамічні оновлення від користувачів. Часто поєднується з DHCP-сервером. У Microsoft DNS-сервер при роботі на контролері домену сервер працює в режимі реєструючого DNS-сервера, приймаючи від комп'ютерів домену інформацію про відповідність імені та IP комп'ютера і оновлюючи відповідно до неї дані зони домену;

DNSBL-сервер (сервер з чорними списками адрес та імен). Формально, такий сервер не входить в ієрархію DNS, однак використовує той же механізм і протокол для роботи, що і DNS-сервери.

DNS-сервер — додаток, призначений для відповідей на DNS-запити за відповідним протоколом.

Види DNS-запитів

Прямий (forward) запит — запит на перетворення імені (символьної адреси) хоста в числову IP-адресу.

Зворотний (reverse) запит — запит на перетворення IP-адреси в ім'я хоста.

Деякі сервери підтримують можливість роботи в різних режимах для різних сегментів мережі. У Bind цей режим називається «view». Наприклад, сервер може для локальних адрес (наприклад, 10.0.0.0/8) віддавати локальні адреси серверів, для користувачів зовнішньої мережі — зовнішні адреси. Також сервер може бути авторитативним для заданої зони тільки для вказаного діапазону адрес (наприклад, у мережі 10.0.0.0/8 сервер оголошує себе авторитативним для зони internal, при цьому для зовнішніх адрес у відповідь на запит імені із зони internal буде віддаватися відповідь «невідомий»).

Усі DNS-сервера за стандартом RFC 1035 працюють на 53 порту TCP і UDP. При відправленні запитів ранні версії BIND використовували 53 порт, новіші поводять себе як DNS-клієнти, використовуючи вільні незареєстровані адреси.

Правила формування імен

Повне доменне (від англ. domain) ім'я машини (FQDN, Fully Qualified Domain Name) можна розбити на дві частини — ім'я області-домена та власне ім'я машини. Наприклад, m30.ziet.zhitomir.ua — повна доменне ім'я машини m30, яка знаходиться у домені ziet.zhitomir.ua.

За порядок у доменах, як правило, відповідає певний комп'ютер, користувачі-адміністратори якого слідкують за тим, щоб не було, наприклад, різних машин з однаковими ІР-адресами. Наприклад, відповідальність за область-домен ziet.zhitomir.ua покладається на машину alpha.ziet.zhitomir.ua Ця влада делегується зверху вниз від машини ns.lucky.net, яка відповідає за домен zhitomir.ua. В свою чергу, відповідальність за область ua делегована машині зверху від так званих кореневих серверів (root server).

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

Необхідно розрізняти доменне ім'я, та поштову адресу. В поштовій адресі повинен бути знак «@», якій розділяє поштову адресу на доменне ім'я та ім'я поштової скриньки.

Коли мережа Інтернет була молода та невелика, таблиці відповідності імен та адрес зберігалися у звичайному текстовому файлі, який періодично просто розсилався всім учасникам електронною поштою. Після того, які кількість машин значно збільшилася, така схема перестала ефективно працювати і програмісти університету штату Каліфорнія в Берклі спроектували і написали програму BIND (Berkeley Internet Name Domain), яка відповідає на запити машин користувачів, які стосувалися імен та ІР-адресу.

Служба імен DNS — це розподілена база даних доволі простої структури. Для початкового знайомства можна вважати, що це кілька таблиць, у яких записано:

• яку ІР-адресу має машина з певним іменем;

• яке ім'я має машина з визначеною адресою;

• що це за комп'ютер і яка операційна система встановлена на ньому;

• куди потрібно направляти електронну пошту для користувачів цієї машини;

• які псевдоніми є у даної машини.

Для прикладу розглянемо випадок, коли користувач посилає пошту з машини polesye.zhitomir.ua користувачу за адресою rozhik@ziet.zhitomir.ua (знак «@» носить назву commercial «at» sign). При встановленні на машину протоколів TCP/IP системний адміністратор вказує ІР-адресу комп'ютера — найближчого серверу імен. Поштова програма подає цьому найближчому серверу запит: «Куди посилати пошту для ziet.zhitomir.ua» Якщо найближчий сервер не може відповісти, то він, в свою чергу, посилає запит до більш «старшого» серверу. Нарешті, стає зрозумілим, що всю пошту для області ziet.zhitomir.ua необхідно відправляти на машину alpha.ziet.zhitomir.ua або relay2.lucky.net. Разом з цим відповіді містять ще адресу цієї машини. Поштова програма зв'язується з цим комп'ютером (використовуючи не ім'я, а адресу) та передає йому пошту. Всі ці переговори та відправка пошти, як правило, відбувається протягом кількох секунд і користувач не помічає цього. Якщо машина ziet.zhitomir.ua недоступна то тоді пошта на час, в якій неможливо зв'язатися з машиною ziet.zhitomir.ua (наприклад під час профілактики каналу зв'язку) чекає своєї черги на пересилку на машині relay2.lucky.net.

Це характерна для Internet-програм поведінка. Як правило, поштові програми подають доволі багато запитів службі DNS, і ці питання доволі складні. У більшості випадків у програмах користувачів намагаються дізнатися лише одне — яка ІР-адреса у машини з відповідним іменем. Зрозуміло, що всередині цієї системи імен існує маса нюансів, правил та хитрощів. Більш докладніше з ними можна ознайомитися в описах стандартів Internet або в спеціальних книгах.

Dynamic Host Configuration Protocol

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

Даний протокол працює за моделлю «клієнт-сервер». Для автоматичної конфігурації комп'ютер-клієнт на етапі конфігурації мережевого пр истрою звертається до так званого сер веру DHCP, і отримує від нього потрібні параметри. Мережний адміністратор може задати діапазон адрес, що розподіляють сервером серед комп'ютерів. Це дозволяє уникнути ручного настро ювання комп'ютерів мережі й зменшує кількість помилок.

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

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

Автоматичний ро зподіл. При даному способі кожному комп'ютеру на постійне використання виділяється довільна вільна IP-адреса з визначеного адміністратором діапазону. Динамічний розподіл. Цей спосіб аналогічний автоматичному розподілу, за винятком того, що адреса видається комп'ютеру не на постійне користування, а на певний термін. Це називається орендою адреси. Після закінчення терміну оренди IP-адреса знову вважається вільною, і клієнт зобов'язаний запросити нову (вона, втім, може виявитися тією самою).

Деякі реалізації служби DHCP здатні автоматично о новлювати записи DNS, що відповідають клієнтським комп'ютерам, при виділенні їм нових адрес. Це здійснюється за до помогою протоколу оновлення DNS.

Протокол DHCP є клієнт-серверним, тобто в його роботі беруть участь клієнт DHCP і сервер DHCP. Передача даних здійснюється за допомогою протоколу UDP, при цьому сервер приймає повідомлення від клієнтів на порт 67 і відправляє повідо млення клієнтам на пор т 68. Спочатку клієнт виконує широкомовний запит по всій фізичної мережі з метою виявити доступні DHCP-сервер и. Він відправляє повідомлення типу DHCPDISCOVER, при цьому в якості IP-адреси джерела вказується 0.0.0.0 (так як комп'ютер ще не має власної IP-адреси), а в якості адреси призначення - широкомовна адреса 255.255.255.255.

Клієнт заповнює кілька полів повідомлення початковими значеннями: – в полі xid поміщається унікальний ідентифікатор транзакції, який дозволяє відрізняти даний процес отримання IP-адреси від інших, що протікають в той же час. – в полі chaddr поміщається апаратна адреса (MAC-адреса) клієнта. – по цій опцій вказується остання відома клієнту IP-адреса. Це необов'язково і може бути проігноровано сервером.

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

Отримавши повідомлення від клієнта, сервер визначає необхідну конфігурацію клієнта відповідно до зазначених мережевим адміністратором настройками. Сервер відправляє йому відповідь (DHCPOFFER), в якому пропонує конфігурацію. Пропонована клієнту IP-адреса вказується в полі yiaddr. Інші параметри (такі, як адреси маршрутизатор ів і DNS-серверів) вказуються у вигляді опцій у відповідному полі. Це повідомлення DHCP-сервер відправляє хосту, що послав DHCPDISCOVER, на його MAC, за певних обставин повідомлення може поширюватися як широ комовна розсилка. Клієнт може отримати кілька р ізних пропозицій DHCP від різних серверів; з них він повинен вибрати те, що його «влашто вує». Обравши одну з конфігурацій, запропонованих DHCP-серверами, клієнт відправляє запит DHCP (DHCPREQUEST). Він розсилається широкомовно; при цьому до опцій, зазначених клієнтом у повідомленні DHCPDISCOVER, додається спеціальна опція – ідентифікато р сервера – вказує адресу DHCP-сервера, обраного клієнтом (у даному випадку – 192.16 8.1.1).

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

Якщо після отримання підтвердження (DHCPACK) від сервера клієнт виявляє, що вказана сер вером адреса вже використовується в мережі, він розсилає широкомовні повідомлення відмови DHCP (DHCPDECLINE), після чого процедура отримання IP-адреси повторюється. Використання IP-адреси іншим клієнтом можна виявити, виконавши запит ARP.

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

Для цього він відправляє повідомлення звільнення DHCP (DHCPRELEASE) тому серверу, який надав йому адресу в оренду. На відміну від інших повідомлень DHCP, DHCPRELEASE не розсилається широкомовно. Повідомлення інформації DHCP (DHCPINFORM) пр изначено для визначення додаткових параметрів TCP / IP (наприклад, адреси маршр утизатора за замовчуванням, DNS-серверів і т. п.) тими клієнтами, яким не по трібна динамічна IP-адреса (тобто адреса яких налаштована вручну). Сервери відпо відають на такий запит повідомленням підтвердження (DHCPACK) без виділення IP-адреси.

Компанія Microsoft вперше включила сер вер DHCP в постачання сервер ної версії Windows NT 3.5, випущеної в 1994 році. Починаючи з Windows 2000 Server реалізація DHCP-сервера від Microsoft дозволяє динамічно оновлювати записи DNS, що використовується в Active Directory. Internet Systems Consortium випустив першу версію ISC DHCP Server (для Unix-подібних систем) 6 грудня 1997 року. 22 червня 1999 вийшла версія 2.0, більш точно відповідає стандарту. Компанія Cisco включила сервер DHCP в Cisco IOS 12.0 в лютому 1999 року. Sun додала DHCP-сервер в Solaris 8 в липні 2001 року.