
- •Адресація в ip-мережах. Типи адрес стека tcp/ip
- •Протоколи та їх призначення
- •Протокол ір. Присвоєння ір-адрес. Структура заголовку ір-пакету
- •Класова адресація в ір-мережах
- •Поняття маршруту, динамічного і статичного маршруту, default gateway, routing, forwarding
- •Принципи маршрутизації. Поняття маршруту, default gateway, routing
- •Протоколи дозволу адрес: arp, dns
- •Система доменних імен dns
- •Контрольні запитання:
Протоколи дозволу адрес: arp, dns
Відображення IP-адрес на локальні адреси
Однієї з головних задач, що ставилася при створенні протоколу IP, було забезпечення спільної погодженої роботи в мережі, що складається з підмереж, у загальному випадку різні мережні технології, що використовують. Безпосередньо з рішенням цієї задачі зв'язаний рівень міжмережевих інтерфейсів стека TCP/IP. На цьому рівні визначаються вже розглянуті вище специфікації упакування (інкапсуляції) IP-пакетів у кадри локальних технологій. Крім цього, рівень міжмережевих інтерфейсів повинний займатися також украй важливою задачею відображення IP-адрес у локальні адреси.
Для визначення локальної адреси по IP-адресі використовується протокол дозволу адреси (Address Resolution Protocol, ARP). Протокол ARP працює різним чином у залежності від того, який протокол канального рівня працює в даній мережі - протокол локальної мережі (Ethernet, Token Ring, FDDI) з можливістю широкомовного доступу одночасно до усіх вузлів чи мережі ж протокол глобальної мережі (Х.25, frame relay), як правило не підтримує широкомовний доступ. Існує також протокол, що вирішує зворотну задачу - перебування IP-адреси по відомій локальній адресі. Він називається реверсивним ARP (Reverse Address Resolution Protocol, RARP) і використовується при старті бездискових станцій, що не знають у початковий момент своєї IP-адреси, але знаючих адресу свого мережного адаптера.
Необхідність у звертанні до протоколу ARP виникає щораз, коли модуль IP передає пакет на рівень мережних інтерфейсів, наприклад драйверу Ethernet. IP-адреса вузла призначення відомий модулю IP. Потрібно на його основі знайти МАС - адресу вузла призначення.
Робота протоколу ARP починається з перегляду так називаної ARP-таблиці (табл. 6.3). Кожен рядок таблиці установлює відповідність між IP-адресою і МАС - адресою. Для кожної мережі, підключеної до мережного адаптера чи комп'ютера до порту маршрутизатора, будується окрема ARP-таблиця.
Таблиця 6.3 - Приклад ARP-таблиці
Поле «Тип запису» може містити одне з двох значень - «динамічний» чи «статичний». Статичні записи створюються вручну за допомогою утиліти аrр і існують доти, поки чи комп'ютер маршрутизатор не будуть виключені. Динамічні ж записи створюються модулем протоколу ARP, що використовує широкомовні можливості локальних мережних технологій. Динамічні записи повинні періодично обновлятися. Якщо запис не обновлявся протягом визначеного часу (порядку декількох хвилин), то вона виключається з таблиці. Таким чином, у ARP - таблиці містяться записи не про усі вузли мережі, а тільки про тих, котрі активно беруть участь у мережних операціях. Оскільки такий спосіб збереження інформації називають кешуванням, ARP-таблиці іноді називають ARP-кеш.
Система доменних імен dns
Відповідність між доменними іменами і IP-адресами може встановлюватися як засобами локального хоста, так і засобами централізованої служби. На ранньому етапі розвитку Internet на кожнім хості вручну створювався текстовий файл із відомим ім'ям hosts. Цей файл складався з деякої кількості рядків, кожна з який містила одну пару «IP-адреса - доменне ім'я», наприклад 102.54.94.97 - rhino.acme.com.
В міру росту Internet файли hosts також росли, і створення масштабованого рішення для дозволу імен стало необхідністю.
Таким рішенням стала спеціальна служба - система доменних імен (Domain Name System, DNS). DNS - це централізована служба, заснована на розподіленій базі відображень «доменне ім'я - IP-адреса». Служба DNS використовує у своїй роботі протокол типу «клієнт-сервер». У ньому визначені DNS-сервери і DNS-клієнти. DNS-сервери підтримують розподілену базу відображень, а DNS-клієнти звертаються до серверів із запитами про дозвіл доменного імені в IP-адресу.
Служба DNS використовує текстові файли майже такого формату, як і файл hosts, і ці файли адміністратор також підготовляє вручну. Однак служба DNS спирається на ієрархію доменів, і кожен сервер служби DNS зберігає тільки частина імен мережі, а не усі імена, як це відбувається при використанні файлів hosts. При росту кількості вузлів у мережі проблема масштабування зважується створенням нових доменів і піддоменів імен і додаванням у службу DNS нових серверів.
Для кожного домена імен створюється свій DNS-сервер. Цей сервер може зберігати відображення «доменне ім'я - IP-адреса» для усього домена, включаючи всі його піддомени. Однак при цьому рішення виявляється погано масштабуємим, тому що при додаванні нових піддоменів навантаження на цей сервер може перевищити його можливості. Частіше сервер домена зберігає тільки імена, що закінчуються на наступному нижче рівні ієрархії в порівнянні з ім'ям домена. (Аналогічно каталогу файлової системи, що містить запису про файли і підкаталоги, безпосередньо в нього «вхідних».) Саме при такій організації служби DNS навантаження з дозволу імен розподіляється більш-менш рівномірно між усіма DNS-серверами мережі. Наприклад, у першому випадку DNS-сервер домена mmtru буде зберігати відображення для всіх імен, що закінчуються на mmt.ru: wwwl.zil.mmt.ru, ftp.zil.mmt.ru, mail.mmt.ru і т.д. У другому випадку цей сервер зберігає відображення тільки імен типу mail.mmt.ru, www.mmt.ru, а всі інші відображення повинні зберігатися на DNS-сервері піддомена zil.
Кожен DNS-сервер крім таблиці відображень імен містить посилання на DNS-сервери своїх піддоменів. Ці посилання зв'язують окремі DNS-сервери в єдину службу DNS. Посилання являють собою IP-адреси відповідних серверів. Для обслуговування кореневого домена виділено трохи дублюючих один одного DNS-серверів, IP-адреси яких є широко відомими (їхній можна довідатися, наприклад, у InterNIC).
Процедура дозволу DNS-імені багато в чому аналогічна процедурі пошуку файловою системою адреси файлу по його символьному імені. Дійсно, в обох випадках складене ім'я відбиває ієрархічну структуру організації відповідних довідників - каталогів чи файлів таблиць DNS. Тут домен і доменний DNS-сервер є аналогом каталогу файлової системи. Для доменних імен, так само як і для символьних імен файлів, характерна незалежність іменування від фізичного місця розташування.
Процедура пошуку адреси файлу по символьному імені полягає в послідовному перегляді каталогів, починаючи з кореневого. При цьому попередньо перевіряється кеш і поточний каталог. Для визначення IP-адреси по доменному імені також необхідно переглянути всі DNS-сервери, що обслуговують ланцюжок піддоменів, що входять в ім'я хоста, починаючи з кореневого домена. Істотною же відмінністю є те, що файлова система розташована на одному комп'ютері, а служба DNS по своїй природі є розподіленої.
Існують дві основні схеми дозволу DNS-імен. У першому варіанті роботу з пошуку IP-адреси координує DNS-клієнт:
DNS-клієнт звертається до кореневого DNS-сервера з указівкою повного доменного імені;
DNS-сервер відповідає, вказуючи адресу наступного DNS-сервера, що обслуговує домен верхнього рівня, задана в старшій частині запитаного імені;
DNS-клієнт робить запит наступного DNS-сервера, що відсилає його до DNS-сервера потрібного піддомена, і т.д., поки не буде знайдений DNS-сервер, у якому зберігається відповідність запитаного імені IP-адресі. Цей сервер дає остаточна відповідь клієнту.
Така схема взаємодії називається не рекурсивною чи ітеративною, коли клієнт сам ітеративно виконує послідовність запитів до різних серверів імен. Тому що ця схема завантажує клієнта досить складною роботою, то вона застосовується рідко.
В другому варіанті реалізується рекурсивна процедура:
DNS-клієнт запитує локальний DNS-сервер, тобто той сервер, що обслуговує піддомен, до якого належить ім'я клієнта;
якщо локальний DNS-сервер знає відповідь, то він відразу ж повертає його клієнту; це може відповідати випадку, коли запитане ім'я входить у той же піддомен, що й ім'я клієнта, а також може відповідати випадку, коли сервер уже дізнавався дану відповідність для іншого клієнта і зберіг його у своєму кеші;
якщо ж локальний сервер не знає відповідь, то він виконує ітеративні запити до кореневого сервера і т.д. точно так само, як це робив клієнт у першому варіанті; одержавши відповідь, вона передає його клієнту, що усе це час простий чекав його від свого локального DNS-сервера.
У цій схемі клієнт передоручає роботу своєму серверу, тому схема називається непрямої чи рекурсивний. Практично всі DNS-клієнти використовують рекурсивну процедуру.
Для прискорення пошуку IP-адрес DNS-сервери широко застосовують процедуру кешування відповідей, що проходять через них. Щоб служба DNS могла оперативно відпрацьовувати зміни, що відбуваються в мережі, відповіді кешуються на визначений час - звичайно від декількох годин до декількох днів.