Основи ip-адресації

Першим обов’язковим параметром у властивостях протоколу TCP/IP будь-якого комп’ютера є наявність його IP-адреси.

IP-адреса – це унікальна 32-розрядна послідовність двійкових цифр, за допомогою якої комп’ютер однозначно ідентифікується в IP-мережі. (Нагадаємо, що на канальному рівні в ролі таких же унікальних адрес комп’ютерів виступають МАС-адреси мережевих адаптерів, неможливість збігу яких контролюється виробниками на стадії виробництва.)

Ми будемо обговорювати найпоширенішу на сьогодні четверту версію протоколу IP – IPv4. Проте вже створена наступна версія протоколу – IP версії 6 (IPv6), у якій IP-адреса представляється у вигляді 128-бітної послідовності двійкових цифр. Ця версія протоколу IP поки що не отримала широкого розповсюдження, хоча і підтримується багатьма сучасними маршрутизаторами та операційними системами.

Багато країн, які активно розвиваються у технічному відношенні (Китай, Японія, Корея та ін.) починають відчувати дефіцит IP-адрес, що ідентифікують не тільки комп’ютери, але й інші пристрої з функціями доступу в Інтернет. Прийнятий зараз 32-бітовий стандарт забезпечує кількість IP-адрес, яка дорівнює майже 4,3 млрд, але їх більша частина закріплена за США (близько 70 %), Канадою та європейськими країнами, а от, наприклад, КНР отримала їх всього 22 млн., що для них є недостатнім. Нова, 128-розрядна версія протоколу IPv6, дозволить збільшити кількість IP-адрес до значної кількості.

Для зручності роботи з IP-адресами 32-розрядну послідовність зазвичай поділяють на 4 частини по 8 бітів (на октети), кожен октет переводять у десяткове число і при записі поділяють ці числа крапками. У такому вигляді (це подання називається “десяткові числа з крапками”, або, англійською, “dotted-decimal notation”) IP-адреси займають набагато менше місця і набагато легше запам’ятовуються (табл. 12.1).

Таблиця 12.1 Різні представлення IP-адреси

IP-адреса у 32-розрядному вигляді	1 1000000 10101000 00000101 11001000
IP-адреса, розбита на октети	1 1000000	1 0101000	0 0000101	1 1001000
Октети у десятковому вигляді	1 92	1 68	5	200
IP-адреса у вигляді десяткових чисел, розділених крапками	192.168.5.200

Проте однієї тільки IP-адреси комп’ютеру для роботи в мережі TCP/IP недостатньо. Другим обов’язковим параметром, без якого протокол TCP/IP працювати не буде, є наявність маски підмережі.

Маска підмережі – це 32-розрядне число, яке складається з одиниць, які йдуть спочатку, та з нулів, які йдуть наприкінці, наприклад (в десятковому поданні) 255.255.255.0 або 255.255.240.0.

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

Тут і використовується маска підмережі, за допомогою якої здійснюється поділ будь-якої IP-адреси на дві частини: ідентифікатор мережі (Net ID) та ідентифікатор вузла (Host ID). Такий поділ виконується дуже просто: там, де в масці підмережі стоять одиниці, знаходиться ідентифікатор мережі, а де стоять нулі – ідентифікатор вузла.

Наприклад, у IP-адресі 192.168.5.200 при використанні маски підмережі 255.255.255.0 ідентифікатором мережі буде число 192.168.5.0, а ідентифікатором вузла – число 200. Варто нам змінити маску підмережі, скажімо, на число 255.255.0.0, як і ідентифікатор вузла, і ідентифікатор мережі зміняться на 192.168.0.0 і 5.200, відповідно, і в залежності від цього інакше буде вести себе комп’ютер під час відправлення IP-пакетів.

Правила призначення IP-адрес мереж і вузлів

Тепер, коли ми знаємо, що таке IP-адреса, маска підмережі, ідентифікатори мережі і вузла, корисно запам’ятати правила, які слід застосовувати при призначенні цих параметрів:

1. Ідентифікатор мережі не може містити тільки двійкові нулі або тільки одиниці. Наприклад, адреса 0.0.0.0 не може бути ідентифікатором мережі.

2. Ідентифікатор вузла також не може містити тільки двійкові нулі або тільки одиниці – такі адреси зарезервовані для спеціальних цілей:

• усі нулі в ідентифікаторі вузла означають, що ця адреса є адресою мережі. Наприклад, 192.168.5.0 є правильною адресою мережі при використанні маски 255.255.255.0 і її не можна використовувати для адресації комп’ютерів;

• усі одиниці в ідентифікаторі вузла означають, що ця адреса є широкомовною адресою для даної мережі. Наприклад, 192.168.5.255 є адресою широкомовлення в мережі 192.168.5.0 при використанні маски 255.255.255.0 і її не можна використовувати для адресації комп’ютерів.

3. Ідентифікатор вузла в межах однієї і тієї ж підмережі повинен бути унікальним.

4. Діапазон адрес від 127.0.0.1 до 127.255.255.254 не можна використовувати як IP-адреси комп’ютерів. Уся мережа 127.0.0.0 з маскою 255.0.0.0 зарезервована під так звані “адреси заглушки” (loopback), що використовуються IP для звернення комп’ютера до самого себе.

Класова і безкласова IP-адресація

Первинна система IP-адресації в Інтернеті була наступна. Весь простір можливих IP-адрес (а це більше чотирьох мільярдів, точніше 4294967296 адрес) було розбито на п’ять класів, причому належність IP-адреси до певного класу визначалася бітами першого октету (табл. 12.2). Зауважимо, що для адресації мереж і вузлів використовувалися тільки класи А, В та С. Крім того, для цих мереж були визначені фіксовані маски підмережі за замовчуванням, рівні, відповідно, 255.0.0.0, 255.255.0.0 і 255.255.255.0, які не тільки жорстко визначали діапазон можливих IP-адрес вузлів у таких мережах, але й механізм маршрутизації.

Таблиця 12.2 Класи адрес в первинній схемі IP-адресації

Клас	Перші біти / в октеті	Можливі значення першого октету	Можлива кількість мереж	Можлива кількість вузлів у мережі
А	0	1-126	126	16777214
В	10	128-191	16384	65534
С	110	192-223	2097152	254
D	1110	224-239	Використовується для багатоадресного розсилання (multicast)
Е	1111	240-254	Зарезервований як експериментальний

Адреси класу А призначені для використання у великих мережах масштабу регіону або країни, число таких мереж досить обмежене. Мережі класу В мають середні розміри та зазвичай використовуються в університетах і великих компаніях. Адреси класу C використовуються в малих мережах, які мають невелику кількість вузлів. IP-адреси класу D використовують для звертання до груп комп’ютерів. Адреси класу Е зарезервовані для майбутнього використання.

Щоб розрахувати максимально можливу кількість вузлів у будь-якій IP-мережі, досить знати, скільки бітів міститься в ідентифікаторі вузла, або, інакше, скільки нулів є у масці підмережі. Це число використовується як показник ступеня двійки, а потім від результату віднімаються дві зарезервовані адреси (мережі і широкомовлення). Аналогічним способом легко обчислити і можливу кількість мереж класів А, В або С, якщо врахувати, що перші біти в октеті вже зарезервовані, а в класі А не можна використовувати IP-адреси 0.0.0.0 і 127.0.0.0 для адресації мережі.

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

Спочатку дана схема добре працювала, оскільки кількість мереж була невеликою. Однак з розвитком Інтернету такий підхід до розподілу IP-адрес став викликати проблеми, особливо гострі виникли для мереж класу В. Дійсно, організаціям, у яких число комп’ютерів не перевищувало кількох сотень (скажімо, 500), доводилося реєструвати для себе цілу мережу класу В. Тому кількість доступних мереж класу В стала на очах “танути”, але при цьому величезні діапазони IP-адрес (у нашому прикладі – понад 65000) не використовувалися.

Щоб вирішити цю проблему, була розроблена безкласова схема IP-адресації (Classless InterDomain Routing – CIDR), у якій не лише відсутня прив’язка IP-адреси до класу мережі і до маски підмережі за замовчуванням, але й допускається застосування так званих масок підмережі зі змінною довжиною (Variable Length Subnet Mask – VLSM). Наприклад, якщо при виділенні мережі для вищевказаної організації з 500 комп’ютерами замість фіксованої маски 255.255.0.0 використовувати маску 255.255.254.0, то вийде діапазон з 512 можливих IP-адрес, чого буде цілком достатньо. 65000 адрес, які залишилися невикористаними, можна зарезервувати на майбутнє або роздати іншим бажаючим підключитися до Інтернету.

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

IP-адреси для локальних мереж

Розподілом IP-адрес у світі займається приватна некомерційна корпорація ICANN (Internet Corporation for Assigned Names and Numbers), а точніше організація IANA (Internet Assigned Numbers Authority), яка працює під її патронажем.

Усі використовувані в Інтернеті адреси повинні реєструватися в IANA, яка гарантує їх унікальність у масштабі всієї планети. Такі адреси називають реальними, або публічними (public) IP-адресами.

Для локальних мереж, не підключених до Інтернету, реєстрація IP-адрес не потрібна, тому, в принципі, тут можна використовувати будь-які можливі адреси. Однак, щоб не допускати можливих конфліктів при подальшому підключенні таких мереж до Інтернету, RFC 1918 рекомендує застосовувати в локальних мережах тільки наступні діапазони так званих приватних (private) IP-адрес (в Інтернеті ці адреси не існують і використовувати їх там немає можливості):

10.0.0.0-10.255.255.255;

172.16.0.0-172.31.255.255;

192.168.0.0-192.168.255.255.

Призначення IP-адрес

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

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

Якщо сервер DHCP недоступний (відсутній або не працює), то починаючи з версії Windows 98, комп’ютери самостійно призначають собі IP-адресу. При цьому використовується механізм автоматичної особистої IP-адресації (Automatic Private IP Addressing – APIPA), для якого корпорацією Microsoft в IANA був зареєстрований діапазон адрес 169.254.0.0-169.254.255.255.

Планування адресації мережі

Розподіл адрес мережевого рівня усередині корпоративної мережі повинен бути добре продуманим. Мережеві адміністратори використовують у своїх мережах адреси не випадковим чином. Адреси в мережі не повинні бути випадковими.

Розподіл мережевих адрес всередині мережі повинен плануватися і документуватися з метою:

• запобігання дублюванню адрес;

• забезпечення і контроль доступу;

• моніторинг забезпечення безпеки і продуктивності.

Запобігання дублюванню адрес

Кожен хост в мережі повинен мати унікальну адресу. Без належного планування та документації призначення мережевих адрес можна легко призначати однакові адреси більш ніж одному хосту.

Забезпечення і контроль доступу

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

Моніторинг безпеки та продуктивності

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

Призначення адрес у мережі

У мережі існують різні типи хостів:

• кінцеві пристрої користувачів;

• сервери та периферійні пристрої;

• хости, які доступні з Інтернету;

• проміжні пристрої.

Кожен з цих різних типів пристроїв повинен бути виділений до логічного блоку адрес в межах діапазону адрес у мережі, для того щоб було легше контролювати доступ до них та безпеку. Також можна виділяти в окремі логічні блоки пристрої за географічною ознакою або, наприклад, за професійною ознакою (наприклад, можна виділити в окремий логічний блок пристрої відділу продажів, в окремий – відділу маркетингу тощо).

Також при плануванні схеми IP-адресації обов’язково необхідно вирішити, для яких пристроїв використовувати приватні, а для яких – публічні адреси.

Для цього необхідно розглянути наступні фактори:

• чи буде використовуватися пристроїв, підключених до мережі, більше ніж публічних адрес, виділених провайдером мережі;

• чи необхідно забезпечити зовнішній доступ до пристроїв локальної мережі;

• якщо є пристрої, яким можуть бути присвоєні приватні адреси і яким потрібен доступ до Інтернету, то можна чи ні забезпечити трансляцію мережевих адрес (Network Address Translation – NAT).

Якщо таких пристроїв більше, ніж доступно публічних адрес, тільки ті пристрої, які будуть мати прямий доступ до Інтернету – такі, як веб-сервер –вимагають публічну адресу. Служба NAT дозволяє заощадити IP-адреси, транслюючи декілька приватних IP-адрес в одну зовнішню публічну IP-адресу (або в декілька, але меншої кількості, ніж внутрішні). За таким принципом побудована більшість мереж у світі: на невеликий район домашньої мережі місцевого провайдера або на офіс виділяється одна публічна IP-адреса, за якою працюють і отримують доступ в Інтернет приватні IP-адреси.

Відображення IP-адрес на локальні адреси

Щоб визначити фізичну адресу вузла за мережевою адресою, використовується протокол дозволу адрес ARP (Address Resolution Protocol). У локальних мережах для визначення потрібної адреси ARP використовує розсилання широкомовних запитів. Протокол дозволу адрес формує запит, указуючи в ньому мережеву адресу, для якої потрібно визначити відповідну фізичну адресу вузла, інкапсулює цей запит у кадр протоколу канального рівня, який використовується в даній мережі, і робить широкомовне розсилання отриманого кадру.

Вузол мережі, що одержав такий запит, порівнює зазначену у запиті мережеву адресу зі своєю мережевою адресою. У випадку, якщо адреси співпадають, вузол формує відповідь, що містить обидві адреси вузла – фізичну і мережеву – і відправляє її відправникові ARP-запиту.

Пакети, що містять ARP-запити й ARP-відповіді, мають однаковий формат.

Для рішення зворотного завдання, тобто визначення IP-адреси за відомою фізичною адресою, використовується протокол зворотного дозволу адрес RARP (Reverse Address Resolution Protocol). Необхідність використання протоколу зворотного дозволу адрес зазвичай обумовлюється використанням бездискових робочих станцій, завантаження операційної системи яких проводиться з єдиного сервера.

Застосування RARP можливе при наявності в мережі спеціального сервера, який відповідає на RARP-запити, ґрунтуючись на інформації, яка зберігається в його ARP-таблиці та дозволяє провести відповідність фізичних адрес мережевим (табл. 12.3).

Таблиця 12.3 Приклад ARP-таблиці

IP-адpecа	MAC-адреса
101.0.10.3	08:00:F0:00:2F:D1
101.0.10.10	08:00:5A:19:BA:15
101.0.10.17	08:00:11:56:А4:76

У відповідь на запит такий сервер відсилає пакет, що містить обидві адреси запитуючого вузла – мережеву і фізичну.

Відображення доменних імен на IP-адреси

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

Однак символьні адреси мають змінний формат досить великої максимально можливої довжини, тому зберігання й передача мережею таких адрес викликають ряд складностей і є не дуже економічними.

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

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

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

Прикладом такої системи адресації може служити доменна система імен (Domain Name System – DNS), яка застосовується в Інтернеті і має ієрархічну деревоподібну структуру, що і допускає більший ступінь вкладеності, тобто більшу кількість ієрархічних підрівнів.

Доменне ім’я може складатися з декількох частин, відділених один від одного крапками, наприклад, images.yandex.ru. Кожна з таких частин називається доменом.

Під доменом можна мати на увазі якусь сукупність комп’ютерів, які мають деякі схожі властивості.

Доменне ім’я записується таким чином: ліворуч знаходиться ім’я вузла, який входить у домен самого низького рівня в ієрархії, а праворуч – домен найвищого ієрархічного рівня (рис. 12.1). Тому крайній праворуч домен називається доменом верхнього або першого рівня. Наступний домен, що ліворуч, відділений крапкою, є дочірнім доменом стосовно домену першого рівня, тобто входить у нього як його складова частина. Цей домен називається доменом другого рівня. Домени, які є дочірніми для домену другого рівня, називаються доменами третього рівня і т.д.

Рис. 12.1. Система ієрархії доменів

У адресі images.yandex.ru доменом першого рівня є домен “ru”, доменом другого рівня – “yandex”, слово “images” є ім’ям хоста.

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

Таблиця 12.4 Приклади доменів першого рівня

Домени першого рівня
	Загальні1		Регіональні2
Ім’я	Значення	Ім’я	Значення
.com	Комерційні	.ru	Російська Федерація
.edu	Освітні	.ua	Україна
.gov	Урядові	.us	США
.int	Міжнародні	.jp	Японія
.mil	Військові	.de	Німеччина
.info	Інформаційні	.fr	Франція
.net	Мережеві	.au	Австралія
.org	Некомерційні	.it	Італія
1 Призначені для позначення типів організацій. 2 Призначені для позначення країн і регіонів.

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

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

Встановлення відповідності доменних імен мережевим адресам здійснюється централізовано за допомогою сервісу DNS.

Сервіс DNS – система забезпечення перетворення символічних імен і псевдонімів локальних мереж і вузлів у мережі Інтернет в IP-адреси, і навпаки.

Принцип роботи сервісу DNS заснований на використанні так званих DNS-серверів. Кожний домен повинен мати свій DNS-сервер, який зберігає таблицю відповідностей доменних імен і IP-адрес даного домену, а також доменів, які є для нього дочірніми. У таблиці також присутній запис, що належить до батьківського домену. Таким чином, будь-який вузол може одержати відомості про шукану IP-адресу будь-якого вузла мережі. Припустимо, що ми набрали в браузері адресу uabs.edu.ua. Браузер запитує у сервера DNS: “яка IP-адреса у uabs.edu.ua”? Однак, DNS-сервер може нічого не знати не тільки про це ім’я, але навіть про всі домени .edu.ua. У цьому випадку сервер звертається до кореневого сервера – наприклад, 198.41.0.4. Цей сервер повідомляє: “У мене немає інформації про дану адресу, але я знаю, що 204.74.112.1 є відповідальним за зону .ua.” Тоді DNS-сервер направляє свій запит до 204.74.112.1, але той відповідає: “У мене немає інформації про даний сервер, але я знаю, що 207.142.131.234 є відповідальним за зону .edu.ua.”. Нарешті, той самий запит відправляється до третього DNS-сервера і отримує відповідь про IP-адресу, яка і передається клієнтові – браузеру.

ЛК.13 – ОГЛЯД ПРОТОКОЛІВ ARP, RARP, DHCP, IPV4

Анотація. Протокол дозволу адрес ARP. Протокол зворотного дозволу адрес RARP. Відображення доменних імен на IP-адреси. Сервіс DNS. Алгоритм роботи протоколу динамічної конфігурації вузлів в мережі DHCP. 

Головною ЕОМ будь-якої системи є та, на якій працюєте ви. Але крім цієї машини і маршрутизатора локальної мережі, не останню роль грає сервер імен (DNS-система, RFC-4032, -4034, -4035, -2137, -2052, -2136, -1996, -1918, -1793, -171 213 , -1706, -1664, -161 112, -153 637, -1401, -1383, -1183, -1101, -103 435).

Сервер імен - це програма управління розподіленою базою даних, в якій зберігаються символьні імена мереж, різних мережевих об'єктів і ЕОМ разом з їх IP-адресами.

Найбільш поширеним програмним продуктом, вирішальним дану задачу є BIND (Berkeley Internet Name Domain). Іноді для цієї мети виділяють спеціальну машину. Завдання DNS - перетворення символьного імені в IP-адресу і, навпаки, в умовах, коли число вузлів Internet зростає експоненціально, зовсім не проста. Сама ієрархічна система імен (DNS) налаштована на спрощення вирішення цієї проблеми. Схема взаємодії програми користувача з локальним і віддаленими DNSсерверамі показана нижче на малюнку 13.1.

Рис. 13.1.  Структура взаимодействия с серверами имен

База імен є розподіленою, так як немає такої ЕОМ, де б зберігалася вся ця інформація. Ім'я містить кілька полів (довжиною не більше 63 символів), розділених крапками, а його повна довжина не повинна перевищувати 255 октетів, включаючи байт довжини. Аналіз імені проводиться справа наліво. Сама права секція імені характеризує країну або характер організації: освітня, комерційна, урядова і т.д.

Наступні символьні коди в кінці Internet-імені означають функціональну належність вузла (таблиця 13.1.).

Таблиця 13.1. Стандартизовані суфікси імен

Поле адреси	Тип мережі
.aero	Фірма чи організація, що відноситься до сфери авіації
.arpa	Спеціальний домен, який використовується для перетворення IP-адреси в ім'я
.arts	Культура та дозвілля
.biz	Організація, що відноситься до сфери бізнесу
.com	Комерційна організація
.coop	Кооперативна організація
.edu	Навчальний заклад
.firm	Комерційне підприємство
.gov	Державна установа (США)
.info	Відкрита TLD-структура (реєстрація імен доменів)
.int	Міжнародна організація
.org	Неприбуткова організація
.mil	Військове підприємство або організація (США)
.museum	Ім'я домену музею
.name	Ім'я домену приватної особи
.net	Велика мережа
.pro	Професіонал, гідний довіри. Управляється RegistryPro (http://www.nic.pro/)
.rec	Розваги
.shop	Торгівля
.tv	Телебачення
.web	Організація, залучена в WEB-активність

Секції. mil і gov належать виключно американським мереж (хоча і багато інших трехсімвольние секції адреси, наприклад. Edu, частіше, але не завжди, належать американським університетам та іншим навчальним організаціям). Структура імен зазвичай відображає структуру організації, якій належать мережі або ЕОМ, але не архітектуру мережі в цій організації. Так ім'я itep.ru - це ім'я домену itepnet (Інститут теоретичної та експериментальної фізики, Москва). cl.itep.ru - ім'я mvax-кластера в ІТЕФ, а suncom.itep.ru - ім'я однієї з ЕОМ SUN в тій же мережі. На ім'я, як правило, не можна визначити, чи є воно ім'ям мережі, маршрутизатора або конкретної ЕОМ. Для запису символьних імен використовується виключно латинський алфавіт.

Маленький фрагмент інтернетівської ієрархії імен показаний на рис. 13.2. Число рівнів реально більше, але зазвичай не перевищує 5.

Рис. 13.2.  Ієрархія імен в Інтернет - DNS

(I - домен першого рівня; II - другого рівня)

Кожному вузлу (прямокутнику на малюнку) відповідає ім'я, яке може містити до 63 символів. Тільки самий верхній, кореневий вузол не має імені. При написанні імені вузла рядкові і прописні символи еквівалентні. Ім'я домену, що завершується крапкою, називається абсолютним або повним ім'ям домену (наприклад, itep.ru.). В деяких країнах створена структура імен, подібна до com / edu / org. Так, в Англії можна зустріти адреси. Ac.uk для академічних установ і. Co.uk - для комерційних. Якщо ім'я домену не завершено символом точки, DNS може спробувати його доповнити, наприклад, ім'я ns може бути перетворено в ns.itep.ru. На наведеній схемі кожному об'єкту трьох верхніх рівнів відповідають сервери імен, які можуть взаємодіяти один з одним при вирішенні задачі перетворення імені в IP-адресу. Можна було б побудувати схему, при якій в будь-якому сервері імен були адреси серверів. Com,. Edu,. Ru і т.д. і при необхідності він міг би послати туди запит. Реальна схема серверів не настільки ідеальна і струнка - існують сервери nsf.gov, oakland.edu і т.д., які безпосередньо пов'язані з базовим сервером імен. Кожен сервер містить лише частина дерева імен. Ця частина називається зоною відповідальності сервера. DNSсервер може делегувати відповідальність за частину зони інших серверів, створюючи Субзони. Коли в зоні з'являється нова ЕОМ або субдомен, адміністратор зони записує її ім'я та IP-адреси в базу даних сервера. Адміністратор зони визначає, який з DNSсерверов імен є для даної зони первинним. Число вторинних серверів не лімітовано. Первинний і вторинний сервери повинні бути незалежними і працювати на різних ЕОМ, так, щоб відмова одного із серверів не виводив з ладу систему в цілому. Відмінність первинного сервера імен від вторинного полягає в тому, що первинний завантажує інформацію про зону з файлів на диску, а вторинний отримує її від первинного сервера. Адміністратор вносить будь-які зміни у відповідні файли первинного сервера, а вторинні сер віри отримують цю інформацію, періодично (раз в 3:00) запрошуючи первинний сервер. Пересилання інформації з первинного у вторинні сервери імен називається зонним обміном. Як буде вести себе сервер, якщо він не має запитуваної інформації? Він повинен взаємодіяти з кореневими серверами. Таких серверів налічується близько десяти і їх IP-адреса повинні міститися в конфігураційних файлах.

Список кореневих серверів ви можете отримати за допомогою анонімного FTP за адресами: nic.ddn.mil або ftp.rs.internic.net. Кореневі сервери зберігають інформацію про імена й адреси всіх серверів доменів другого рівня. Існує два види запитів: рекурсивні та ітеративні. Перший вид передбачає отримання клієнтом IP-адреси, а другий - адреси сервера, який може повідомити адресу. Перший вид повільніше, але дає відразу IP-адресу, другий ефективніше - у вашому сервері накопичується інформація про адреси серверів імен. Одним із способів підвищення ефективності трансляції імен в адреси є кешування, тобто зберігання в оперативній пам'яті іменадресов, які використовувалися останнім часом особливо часто. Розгляд процесу обміну між ЕВМкліентом і сервером імен може прояснити роботу системи в цілому. Перш ніж використовувати протоколи UDP або TCP, прикладна програма повинна дізнатися IP-адреса об'єкту, куди вона хоче послати дейтограмму. Для вирішення цього завдання програма посилає запит в локальний сервер імен. В Unix-системах є спеціальні бібліотечні процедури gethostbyname і gethostbyaddr, які дозволяють визначити IP-адресу на ім'я ЕОМ і навпаки. В одному запиті може міститися декілька питань. Якщо сервер не зможе відповісти на питання, він надішле відгук, де містяться адреси інших серверів, здатних вирішити цю задачу. Нижче на малюнку 13.3 представлений формат таких повідомлень (в якості транспорту використовується UDP або TCP, порт 53).

Рис. 13.3.  Формат DNS-повідомлень

Кожне повідомлення починається із заголовка, який містить поле ідентифікація, що дозволяє зв'язати в пару запит і відгук. Поле прапори визначає характер запитуваної процедури, а також кодування відгуку. Поля число ... визначають кількість записів відповідного типу, що містяться в повідомленні. Так, число запитів задає число записів в секції запитів, що вимагають відповідей. Кожне питання складається з символьного імені домену, за яким слід тип запиту і клас запиту. Значення бітів поля прапори в повідомленні сервера імен відображено в таблиці 13.2. Розряди пронумеровані зліва направо, починаючи з нуля рис. 13.4.

Рис. 13.4. Призначення бітів поля прапори

Нижче описаний формат секції запитів в DNSсообщеніі. Поле символьне ім'я домена має змінну довжину, містить одне або більше субполів, що починаються з байта довжини (0-63). Поле завершується 0. Наприклад, для ns.itep.ru (цифри являють собою октети довжини).

Рис. 13.5. Формат секції питань DNS-запиту

У реальної нотації байти довжини субполя можуть мати два старших біта, рівні 1, що перетворить інтервал значень з 0-63 в 192-255. Такий байт в поле означає, що це не міра довжини секції, а 16-бітний покажчик, 14 біт якого є зміщенням від початку DNS-повідомлення, що вказує на місце продовження секції. Зсув для першого байта поля ідентифікації дорівнює нулю. Ці хитрощі придумані для скорочення довжини повідомлень, так як один і той же ім'я домену у відгуку може повторюватися багато разів. Поле тип запиту характеризує різновид запиту.

Таблиця 13.2. Коди поля флаги

Код поля	Флагі	Опис
0 (QR)	Операція:	0 запит 1 отклік
1…4	Тіп запросу (opcode):	0 стандартний 1 інверсний 2 запит стану сервера
5 (AA)	Дорівнює 1 при відгуку від сервера (RR), у віданні якого знаходиться домен, згаданий в запиті
6 (TC)	Дорівнює 1 при вкороченні повідомлення. Для UDP це означає, що відповідь містив більше 512 октетів, але прислано тільки перші 512
7 (RD)	Дорівнює 1, якщо для отримання відповіді бажана рекурсія
8 (RA)	Дорівнює 1, якщо рекурсія для запитуваної сервера доступна
9…11	Зарезервовано на майбутнє. Мають дорівнювати нулю
12…15	Тип відгуку (rcode):	0 немає помилки 1 помилка в форматі запиту 2 збій в сервері 3 імені не існує

Таблиця 13.2. Коди поля флагіПоследніе два рядки в таблиці 13.3 відносяться тільки до запитів. Поле клас запиту дозволяє використовувати імена доменів для довільних об'єктів (всі офіційні імена Інтернет відносяться до одного класу [IN] - 1). У повідомленні DNS-сервера кожна з секцій (додаткової інформації, відповідей або вузлових серверів імен) складається з набору ресурсних записів, які описують імена доменів і деяку іншу інформацію (наприклад, їх адреси). Поява ресурсних полів в DNS базі даних надають їй нової якості. Кожен запис описує тільки одне ім'я, формат цих записів відображений на рис. 13.6.

Рис. 13.6. Формат ресурсних записів в DNS (RR)

Таблиця 13.3. Різновиди полів тип запиту і їх коди (пропущені коди є застарілими або експериментальними).

Тип запиту	Код запиту	Опис
A	1	IP-адреса
NS	2	сервер імен
CNAME	5	канонічне ім'я
SOA	6	Початок списку серверів. Велике число полів, що визначають частину ієрархії імен, яку використовує сервер
MB	7	Ім'я домену поштового ящика
WKS	11	well-known service - стандартна послуга
PTR	12	запис покажчика
HINFO	13	Інформація про ЕОМ
MINFO	14	Інформація про поштовій скриньці або списку почтових адрес
MX	15	Запис про поштовому сервері. Включає в себе пріоритет обробника пошти
TXT	16	Чи не интерпретируемая рядок ASCII-символів
ISDN		Пов'язує ім'я ЕОМ з адресою ISDN
AXFR	252	Запит зонного обміну
* или ANY	255	Запит всіх записів

Всього існує 20 різних типів RR-записів. Ім'я домену в такого запису може мати довільну довжину. Поля тип і клас характеризують тип і клас даних, включених до запису (аналогічні використовуваним в запитах). Поле час життя (TTL) містить час (в секундах), протягом якого запис про ресурси може зберігатися в буферній пам'яті (в кеші). Зазвичай цей час відповідає двом дням. Формат інформації про ресурси залежить від коду в поле тип, так, для тип = 1 - це 4 байта IP-адреси. Сервер імен може обслуговувати і інші запити, наприклад, по IP-адресою визначати символьне ім'я домена або перетворити ім'я домену на адресу поштового сервера. Коли організація приєднується до Інтернет, вона отримує в своє розпорядження не тільки певну DNSобласть, а й частина простору в inaddr.arpa, відповідну її IP-адресами. Домен inaddr.arpa призначений для визначення імен по їх IP-адресами. Така схема виключає процес перебору серверів при подібному перетворенні.

Імена в домені INADDR.ARPA можуть мати до чотирьох субполів крім суфікса INADDR.ARPA. Кожне субполів являє собою октет IP-адреси та містить послідовність символів, що відображає коди в діапазоні 0-255. Так, ім'я для IP-адреси 192.148.166.137 (якщо воно існує) міститься в домені з ім'ям 137.166.148.192.INADDR.ARPA. Запис адреси задом наперед диктується загальними принципами записи імен доменів (коренева частина імені знаходиться справа). Направивши в домен INADDR.ARPA кілька запитів щодо імен об'єктів з важливими вас IP-адресами, можна отримати наступний результат (таблиця 13.1.), Де в лівій колонці записано IP-адреси, імена яких розшукуються, у другій записані апаратні адреси інтерфейсів, через які доступні шукані об'єкти. Оскільки перша і третя рядки належать до зовнішніх по відношенню до вузла ITEP об'єктах, тут записаний адреса інтерфейсу прикордонного маршрутизатора. У третій колонці міститься значення RTT в мсек, а в останній - імена об'єктів. IP-адресою 192.148.166.102 не відповідає ніякого імені.

Затримка при виконанні команди telnet між видачею команди і появою на екрані IP-адреси пов'язана з доступом і роботою DNSсервера. Пауза між появою написи Trying і Connected to визначається часом встановлення TCP-зв'язку між клієнтом і сервером. База даних імен може містити й іншу інформацію. Типи такої інформації представлені в таблиці 13.3. Для витягання інформації з цієї розподіленої бази даних можна скористатися програмою host (SUN або інша ЕОМ, яка працює під UNIX). Останнім часом поширюється технологія DDNS - динамічного оновлення ресурсних записів зони DNS зовнішніми ЕОМ або процесами (Dynamic DNS; RFC-2136). Клієнти з можливостями DDNS можуть самі оновлювати записи локальних серверів імен. Ще більш цікаве рішення базується на інтеграції служб DHCP і DNS. У цьому варіанті сервери DHCP, що підтримують DDNS, посилають відповідного серверу DNS дані для оновлення записів, включаючи імена NetBIOS клієнтів DHCP. Запис оновлюється після виділення IP-адреси. При реалізації DDNS виникають проблеми безпеки. Частина цих проблем може бути вирішена шляхом використання цифрових підписів (RFC-2137). Ще однією проблемою, пов'язаною зі службою імен, є атаки, які пов'язані з імітацією DNS. Для подолання таких атак розроблений метод транзакційних підписів TSIG (Transaction SIGnature).

Протокол перетворення адрес ARP

Будь-який пристрій, підключений до локальної мережі (Ethernet, FDDI і т.д.), має унікальний фізичний мережеву адресу, заданий апаратним чином. 6байтовий Ethernet-адресу вибирає виробник мережного інтерфейсного обладнання з виділеного для нього за ліцензією адресного простору. Якщо у машини змінюється мережний адаптер, то міняється і її Ethernet-адресу. 4-байтовий IP-адреса задає менеджер мережі з урахуванням положення машини в мережі Інтернет. Якщо машина переміщається в іншу частину мережі Інтернет, то її IP-адреса має бути змінений. Перетворення IP-адрес в мережеві виконується за допомогою ARP-таблиці. Кожна машина мережі має окрему ARP-таблицю для кожного свого мережевого адаптера. Неважко бачити, що існує проблема відображення фізичної адреси (6 байт для Ethernet) в простір мережевих IP-адрес (4 байта) і навпаки. Протокол ARP (address resolution protocol, RFC-826) вирішує саме цю проблему – перетворить IP в Ethernetадреса.

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

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

2. Усім машинам в мережі надсилається пакет з ARP-запитом (з широкомовним Ethernet-адресою місця призначення);

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

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

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

Функціонально, ARP ділиться на дві частини. Одна визначає фізичну адресу при посилці пакета, інша відповідає на запити інших машин. ARP-таблиці мають динамічний характер, кожна запис у ній "живе" певний час, після чого видаляється. Менеджер мережі може здійснити запис в ARP-таблицю, яка там буде зберігатися "вічно". ARP-пакети вкладаються безпосередньо в Ethernetкадри. Формат ARP-пакета показаний на рис. 13.9.

Рис. 13.9. Формат пакета ARP

HALen - довжина апаратного адреси; PALen - довжина протокольного адреси (довжина в байтах, наприклад, для IP-адреси PALen = 4). Тип оборудования - це тип інтерфейсу, для якого відправник шукає адресу; код містить 1 для Ethernet. Нижче представлена ​​таблиця 13.4 кодів обладнання.

Поле код операції визначає, чи є даний пакет ARP-запитом (код = 1), ARP-відгуком (2), RARP-запитом (3), або RARP-відгуком (4).

ARP-таблиці будуються згідно з документом RFC-1213 і для кожного IP-адреси містить чотири коду (таблиця 13.4.).

В SUN і деяких інших ЕОМ є програма arp, яка дозволяє відобразити ARP-таблицю на екрані. З прапором a команда відображає всю таблицю, прапор d дозволяє стерти запис, а s служить для внесення записів до таблиці (останні два прапори доступні для операторів з системними привілеями). Команда ARP без прапорів з адресою або ім'ям ЕОМ видасть відповідний рядок таблиці.

Таблиця 13.4. Коди обладнання

Код типу обладнання	Опис
1	Ethernet (10 Мбит/с)
2	експериментальний Ethernet (3 Мбит/с)
3	Радіоаматорська зв'язок через X.25
4	Proteon ProNET маркерна кільцева мережа (Token Ring)
5	Chaos
6	Мережі IEEE 802
7	ARCNET

arp 192.148.166.129

Name: semenov.itep.ru

Address: 192.148.166.129

Aliases: yas

А команда

arp nb

надаст запис

nb (193.124.224.60) at 0:80:ad:2:24:b7 (запис для NetBlazer ИТЭФ)

ARP запити можуть вирішувати й інші завдання. Так при завантаженні мережевого забезпечення ЕОМ такий запит може з'ясувати, а не присвоєно чи ідентичний IP-адреса какомуто ще об'єкту в мережі. При зміні фізичного інтерфейсу такий запит може ініціювати зміну запису в ARP-таблиці.

Таблиця 13.5. Коды типів протоколів (для IP это 0800H)

Код типу протоколів		Опис
Десятичне значения	Hex
512	0200	XEROX PUP
513	0201	PUP трансляція адреси
1536	0600	XEROX NS IDP
2048	0800	DOD Internet протокол (IP)
2049	0801	X.75 Internet
2050	0802	NBS Internet
2051	0803	ECMA Internet
2052	0804	Chaosnet
2053	0805	X.25 рівень 3
2054	0806	Протокол трансляції адреси (ARP)
2055	0807	XNS сумісність
2560	0A00	Xerox IEEE-802.3 PUP
4096	1000	Bercley Trailer
21000	5208	BBN Simnet
24577	6001	DEC MOP Dump/Load
24578	6002	DEC MOP віддалений термінал
24579	6003	DEC DECnet фаза IV
24580	6004	DEC LAT
24582	6005	DEC
24583	6006	DEC
32773	8005	HP Probe
32784	8010	Excelan
32821	8035	Реверсивний протокол ARP (RARP)
32824	8038	DEC LANbridge
32923	8098	Appletalk
33100	814C	SNMP

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

Таблица 13.6

ifindex	Физический порт (интерфейс), соответствующий данному адресу
Физический адрес	MAC-адрес, например Ethernet-адрес
IP-адрес	IP-адрес, соответствующий физическому адресу
Тип адресного соответствия	Это поле может принимать 4 значения: 1 – вариант нестандартный и не подходит ни к одному из описанных ниже типов; 2 – данная запись уже не соответствует действительности; 3 – постоянная привязка; 4 – динамическая привязка

Самозверненням запит дозволяє ЕОМ вирішити дві проблеми. По-перше, визначити, чи немає в мережі об'єкта, що має той же IРадрес. Якщо на такий запит прийде відгук, то ЕОМ видасть на консоль повідомлення Duplicate IP address sent from Ethernet address <...>. Під ¬ друге, в разі зміни мережевої карти здійснюється коректування запису в АRP-таблицях ЕОМ, які містили старий МАС-адресу ініціатора. Машина, яка отримує ARP-запит c адресою, яка міститься в її таблиці, повинна відновити цей запис.

Друга особливість такого запиту дозволяє резервному файловому серверу замінити основний, пославши самозверненням запит зі своїм МАС-адресою, але з IP вийшов з ладу сервера. Цей запит змусить перенаправляти кадри, адресовані основному серверу, на резервний. Клієнти сервера при цьому можуть і не знати про вихід основного сервера з ладу. При цьому можливі й невдачі, якщо програмні реалізації в ЕОМ не повною мірою дотримуються регламентаціям протоколу ARP.

Протокол зворотного адресного перетворення RARP

Зазвичай IP-адреси зберігаються на диску (в конфігураційних файлах), звідки вони зчитуються при завантаженні системи. Проблема виникає тоді, коли необхідно ініціалізувати робочу станцію, яка не має диска. Бездискові системи часто використовують операції типу TFTP для перенесення з сервера в пам'ять образу операційної системи, а це не можна зробити, не знаючи IP-адрес сервера і ЕОМ-клієнта. Записувати ці адреси в ПЗУ не представляється доцільним, так як їх значення залежать від точки підключення ЕОМ і можуть змінюватися. Для вирішення даної проблеми був розроблений протокол зворотного трансляції адрес (RARP - Reverse Address Resolution Protocol, RFC-0903, дивись також нижче опис протоколу BOOTP). Формати повідомлень RARP схожі з ARP (див. рис. 13.10), хоча самі протоколи принципово різні. Протокол RARP припускає наявність спеціального сервера, обслуговуючого RARPзапроси і зберігає базу даних про відповідність апаратних адрес протокольним. Цей протокол працює з будь-транспортної середовищем, в разі ж кадру Ethernet в поле тип буде записаний код 803516 (дивись таблицю 13.5).

Тут позначення ті ж, що і в описі ARP-формату. Значення n визначається числом, записаним в поле HA-Len, а m - числом з поля PALen. Для Internet PA-Len = 4 і тип протоколу = 2048, а для Ethernet одно HA-Len = 6 і тип обладнання = 1. В RARP використовується два коди операції. Код операції = 3 використовується для RARP-запитів, а код операції = 4 - для RARP-відгуків. У першому випадку поле адреса протоколу відправника та адреса протоколу адресата не визначені. Зазвичай локальна мережа має кілька RARP-серверів, що дозволяє завантажитися бездискових машинам, навіть якщо який ¬ то з серверів вимкнений або не справний.

Рис. 13.10. Формат RARP-повідомлення

ЛК.14 – ПРИНЦИПИ МАРШРУТИЗАЦІЇ В IP - МЕРЕЖАХ

Анотація. Основи маршрутизації. Принципи роботи засобів маршрутизації. Статична маршрутизація. Динамічна маршрутизація. Порівняння статичної та динамічної маршрутизації. Протоколи маршрутизації та маршрутні протоколи. Протоколи маршрутизації.