АДРЕСАЦІЯ КОМП'ЮТЕРІВ

DNS — не розкіш, об необхідність

Протокол, що визначав порядок обміну інформацією в Інтернеті, описував у тому числі і систему адресації комп'ютерів, об'єднаних в цю Мережу. Згідно цій системі, кожному комп'ютеру привласнювалася унікальна чотирьохбайтова адреса, яку почали називати IP-адрес. Стандарт нового протоколу і, відповідно, системи адресації були прийняті в 1982 році.

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

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

Із зростанням числа комп'ютерів в мережі коректувати ці файли уручну стало неможливо. З'явилася необхідність в глобальній базі імен, що дозволяє проводити перетворення імен в IP-адреса без зберігання списку відповідності на кожному комп'ютері. Такою базою стала DNS (Domain Name System) — система іменування доменів, яка почала роботу в 1987 році.

Структура DNS

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

Друга особливість системи — це організація DNS-серверов у вигляді ієрархічної структури. Наприклад, запит від клієнта про ім'я ftp.microsoft.com може пройти через декілька DNS-серверов, від глобального, такого, що містить інформацію про домени верхнього рівня, до конкретного сервера компанії Microsoft, в чиїх списках перераховані піддомени вигляду *. miсrosoft.com, у числі яких ми і знаходимо потрібний нам ftp.microsoft.com. При цьому безліч DNS-серверов організовується в зони, що мають права і дозволи, делеговані вищестоящим сервером. Таким чином, при додаванні нового піддомена на місцевому сервері повідомлення решти серверів в Глобальній мережі не проводяться, але інформація про нові сервери виявляється доступною за запитом.

Зони, домени і піддомени

Із зростанням числа доменних імен робота між серверами була розподілена за принципом єдиноначальності. Ідея проста. Якщо організація володіє власним доменним ім'ям (наприклад microsoft.com або white-house, gov), то іменування усередині свого домена вона проводить самостійно. Єдина складність при такій роботі — надання вищестоящими серверами цих прав нижчестоячим серверам.

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

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

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

Інтеграція DNS в Active Directory

Компанія Microsoft рекомендує використовувати DNS-серверы в корпоративних мережах для організації роботи комп'ютерів у складі домена. Річ у тому, що технологія DNS більш універсальна і ефективна, чим що використовуються на старих системах WINS і NETBIOS. Клієнти тільки посилають запити серверу і отримують відповіді без звернення до яких-небудь іншим вузлам мережі.

З погляду продуктивності краще всього інтегрувати DNS в Active Directory, що можливо на серверних ОС компанії Microsoft починаючи з Windows 2000 Server. Поєднання ролей DNS-сервера і контроллера домена спрощує адміністрування мережі, особливо якщо розміри її достатньо великі.

Що нам стоїть DNS побудувати

DNS реалізуються відповідно до єдиного стандарту, основи якого викладені в RFC 1011,1034 і 1035. У Windows Server 2003 процес розгортання і управління DNS зроблений простішим, ніж в попередніх версіях операційних систем, завдяки майстрам настройки ролей сервера. У Windows Server 2003 додані і нові функції управління Active Directory, яка може бути інтегрована з DNS воєдино

При створенні контроллера домена, тобто сервера, керівника роботою Active Directory, майстер пропонує створити і набудувати DNS-сервер. Для цього досить в настройках відзначити пункт «Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server». В цьому випадку запускається DNS-сервер і створюється зона, однойменна з вашим доменом.

Для імені домена краще використовувати два слова, розділених крапкою (виду гпу-domen.ru). Технічно можливо включити комп'ютери вашої мережі і в домен верхнього рівня, але Microsoft не рекомендує використовувати для домена ім'я, що складається з одного слова, оскільки в цьому випадку виникають складнощі з організацією пересилки запитів (forwarding) і динамічних оновлень.

Настройка DNS

Після перезапуску системи у вікні «Manage Your Server» (управління сервером) і на панелі «Адміністрування» з'являться нові елементи — посилання на консолі управління Active Directory (три ікони) і DNS (одна ікона). Зупинимося докладніше на консолі управління DNS-сервером.

Дерево DNS містить список ONS-серве-ров, в нашому випадку список складатиметься з одного пункту — імені нашого сервера. Розкривши його, ми побачимо три теки — «Forward Lookup Zones» (зони прямого перегляду), «Reverse Lookup Zones» (зони зворотного перегляду, порожня тека) і «Event Viewer» .

Тека зон прямого перегляду міститиме два записи. Зона, чиє ім'я починається з _msdcs, відноситься до організації роботи системи (DC розшифровується як Domain Controller, контроллер домена), поки що нам її чіпати не потрібно, так само як і теку _msdcs в другій зоні. Вибравши другу зону, в списку справа ми побачимо її вміст — власне кажучи, всі комп'ютери, чиї імена зберігаються на нашому сервері, будуть перераховані саме там.

Додавання нових хостов відбуватиметься автоматично. Всі операційні системи Windows, починаючи з Windows 2000 Professional, підтримують коректне оновлення бази DNS-сервера в своїй локальній мережі. Нові пункти в список імен хостов на DNS-сервере можуть додаватися і за допомогою служби «Computer Browser». Уручну ж додавання нових доменів і хостов, так само як і видалення тих, що існують, походить з меню консолі «Action» або з контекстного меню правої клавіші миші.

Після запуску контроллера можна приступити до введення в домен клієнтських машин. Повторимо, що коректна робота у складі домена можлива тільки для систем рангу Professional, починаючи з Windows 2000 Professional, тобто в домені відмовляться працювати комп'ютери під управлінням операційних систем Windows 98, Windows Me або Windows XP Home Edition.

Коли ж ви додаєте в домен комп'ютер зі встановленою ОС Windows 2000 Professional або Windows XP Professional, система автоматично пошле запит DNS- серверу, а той у свою чергу додасть нову IP-адрес в список.

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

Втім, щоб набудувати DNS і DHCP на спільну роботу, не вимагається особливих зусиль. Досить відкрити «Scope Options» в консолі управління DHCP-сервером і вказати ім'я вашого DNS-сервера в параметрі «DNS Domain Name».

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

DNS-сервер може проводити очищення списку, видаляючи з нього дані про ті хостах, які видалені з мережі. Щоб набудувати очищення списку хостов, натисніть кнопку «Aging» («Очищення») на вкладці «General» у властивостях зони — за умовчанням видалення «прострочених» імен вимкнене (потрібно поставити відповідну галочку). Крім того, там же указується параметр автоматичного оновлення («Dynamic Updates») — за умовчанням він перемкнутий в «Secure Only» і дозволяє проводити оновлення бази на основі запитів тільки від безпечних джерел.

Підключаємося до Інтернету

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

Інше завдання, що виникає перед адміністраторами, — це настройка доступу в Інтернет через локальну мережу. Доступ може бути організований по-різному, і, якщо всі клієнти підключаються через проксі-сервер, настроювати DNS для роботи в Інтернеті необхідності немає. Інша справа, якщо ви використовуєте Iр-маськарадінг за допомогою NAT. В цьому випадку клієнтські комп'ютери у вашій мережі повинні будуть мати можливість отримувати відповіді від DNS-серверов в Інтернеті, щоб підключатися до веб-серверам по їх IP-адресам.

Реалізувати це просто. Вам потрібно набудувати пересилку запитів з вашого DNS-сервера на сервер інтернет-провайдера {так званий форвардінг). Краще всього організувати це в два етапи. Спочатку ваш DNS-сервер відправляє запит на маршрутизатор, а той вже пересилає його провайдерові.

Можна обійтися і одним кроком, адже якщо маршрутизатор надає сервіс NAT для виходу в Інтернет, то сам DNS-сервер може звертатися безпосередньо до провайдера. Проте такий метод менш грамотний. Наприклад, якщо ви поміняєте провайдера, вам доведеться правити настройки вже на декількох комп'ютерах. Крім того, підключення до Інтернету через NAT менш безпечно, чим перенаправлення запитів за допомогою проксі-сервера. Також з міркувань безпеки не рекомендується суміщати роль DNS-сервера і маршрутизатора на одному комп'ютері, особливо якщо він же є і контроллером домена у вашій мережі.

Настройка форвардінга відбувається у властивостях DNS-сервера з консолі управління. Натискаємо правою кнопкою на значку сервера, потім «Properties -> Forwarders», де і указуємо ім'я вищестоящого домена або перераховуємо DNS-серверы, до яких звертатиметься наш сервер. На вкладці «Root Hints» перераховуються адреси DNS-серверов мережі (не обов'язково вищестоящих). Список «Root Hints» може бути заповнений автоматично за допомогою майстра Configure DNS Server з меню «Action».

Помилкою є створення зони з ім'ям «.». В цьому випадку наш DNS-сервер почне вважати себе кореневим, тобто верхнім в глобальному дереві DNS. Зрозуміло, ніякі пересилки вищестоящим серверам працювати не будуть. При створенні зони, чиє ім'я співпадає з частиною імені вже існуючих зон після крапки (наприклад, у нас є зона trading.office, а ми створюємо зону office), всі зони, що належать нею, і домени виявляються вкладеними в неї.

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

Розібратися в ситуації допоможе «Event Viewer». У разі коректної роботи DNS-сервера в журналі повинен з'явитися запис про старт сервера. Також нові записи з'являтимуться у міру додавання нових імен хостов або при ручному управлінні зонами і доменами.

Для того, щоб детектувати несправності з боку клієнта, найпростіше скористатися консольною утилітою nslookup, яка поставляється разом з операційною системою. Після введення nslookup в командному рядку на екрані повинні з'явитися ім'я і IP-адрес вашого DNS-сервера, а після цього вам буде надана можливість протестувати сервер шляхом відправлення запитів на перетворення імені в IP-адрес. Щоб побачити довідку по параметрах команди nslookup, введіть в командному рядку nslookup help.

Інша інформація!!!

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

Схема призначення адрес повинна зводити до мінімума ручну працю адміністратора та ймовірність дублювання адрес.

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

Адреса повинна бути зручною для користувачів мережі, а це значить, що вона повинна мати символьне представлення наприклад, Server3 або www.cisco.com.

Адреса повинна мати по можливості компактне зображення, щоб не перевантажувати пам'ять комунікаційної апаратури - мережних адаптерів, маршрутизаторів і т. ін.

Так як всі перелічені вимоги важко поєднати у рамках однієї схеми адресації, то на практиці звичайно використовуються водночас декілька схем адресації, так що комп'ютер одночасно має декілька адрес-імен. Кожна адреса використовується у тій ситуації, коли відповідний вид адресації найзручніший. А щоб не виникало путанини і комп'ютер завжди однозначно визначався своєю адресою, використовуються спеціальні допоміжні протоколи, які по адресі одного типу визначають адреси інших типів. Найбільшого розповсюдження отримали три схеми адресації вузлів. Апаратна (hardware) адреса. Ці адреси призначені для мережі невеликого або середнього розміру, тому вони не мають ієрархічної структури. Така адреса звичайно використовується тільки апаратурою, наприклад, у мережні адаптери вбудовують шестибайтну, так звану МАС-адресу, під час виготовлення. При установці у комп'ютер декількох адаптерів, він матиме декілька апаратних адрес. Отже апаратна адреса адресує певний інтерфейс підключення до мережі, яка змінюється при заміні мережного адаптера. Символьні адреси або імена. Ці адреси призначені для запам'ятовування людьми і тому звичайно несуть змістове навантаження. Символьні імена легко використовувати як у невеликих, так і у великих мережах. Для роботи у великих мережах символьне ім'я може мати складну ієрархічну структуру, напрклад, www.cisco.com. Числові складені адреси. Символьні імена зручні для людей, але з-за змінного формату і потенціально великої довжини їх передача по мережі не дуже економна. Тому у багатьох випадках для роботи у великих мережах в якості адрес вузлів використовують числові складені адреси фіксованого і компактного форматів. Типовими представниками адрес цього типу є ІР- та ІРХ-адреси. В них підтримується двохрівнева ієрархія, адреса поділяється на старшу частину - номер мережі та молодшу - номер вузла. Такий поділ дозволяє передавати повідомлення між мережами тільки на підставі номера мережі, а номер вузла використовується тільки після доставки повідомлення у потрібну мережу. В останній час, щоб зробити маршрутизацію у крупних мережах більш ефективною, пропонується більш складні варіанти числової адресації, у відповідності з якими адреса має три і більше складових. Такий підхід реалізований у новій версії протоколу IPv6, призначеного для роботи у мережі Internet. У сучасних мережах для адресації вузлів застосовуються, як правило, одночасно всі три схеми адресації. Користувачі адресують комп'ютери символьними іменами, які автоматично замінюються у повідомленнях, що передаються по мережі, на числові номери. За допомогою цих числових номерів повідомлення передаються з однієї мережі до іншої, а після доставки повідомлення у мережу призначення замість числового номера використовується апаратна адреса комп'ютера. Сьогодні така схема характерна даже для невеликих автономних мереж, де, здавалося б, вона явно зайва - це робиться для того, щоб при під'єднанні цієї мережі до великої мережі не треба було б змінювати склад операційної системи.