Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Інформаційна безпека
Кафедра:
Не вказано
Інформація про роботу
Рік:
2009
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Мережеві операційні системи
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
Національний університет
“ЛЬВІВСЬКА ПОЛІТЕХНІКА”
РЕАЛІЗАЦІЯ СПОСОБІВ ВИРІШЕННЯ ІМЕН
МЕТОДИЧНІ ВКАЗІВКИ ДО ЛАБОРАТОРНОЇ РОБОТИ № 3
З ДИСЦИПЛІНИ “МЕРЕЖЕВІ ОПЕРАЦІЙНІ СИСТЕМИ”
для студентів базових напрямів
“Інформаційна безпека”
Затверджено
на засіданні кафедри
"Автоматика та телемеханіка"
Протокол № 11 від “01”лютого 2009 р.
Львів 2009
Реалізація способів вирішення імен. Методичні вказівки до лабораторної роботи № 3 з дисципліни “Мережеві операційні системи” для студентів базових напрямів “Інформаційна безпека” / Укл.: І.Я.Тишик, – Львів: НУЛП, 2009 - 10 с.
Укладачі: І.Я.Тишик, ст. викладач
Відповідальний за випуск:
1. КОРОТКІ ТЕОРЕТИЧНІ ВІДОМОСТІ
В операційних системах, котрі початково розроблялися для локальних мереж, таких як Novell NetWare, Microsoft Windows або IBM OS/2, користовачі завжди працювали зі символьними іменами комп’ютерів. Оскільки локальні мережі складалися з невеликого числа комп’ютерів, застосовувалися для їх ідентифікації так звані “плоскі” імена, які складалися з послідовності символів, не розділених на частини (наприклад: NW_1, mail2, WS212_1, і т.д). Для встановлення відповідності між символьними іменами комп’ютерів і MAC-адресами у цих операційних системах застосовувався механізм широкомовних запитів. Так, широкомовний спосіб вирішення імен реалізований у протоколі NetBIOS (Network Basic Input/Output System), на якому було побудовано більшість локальних ОС. Для стеку TCP/IP, розрахованому в загальному випадку на роботу у великих територіально розподілених мережах, подібний підхід виявився неефективним (хоча, з метою вирішення проблеми об’єднання в один цих двох протоколів, Internet Engineering Task Force (IETF) випустила серію стандартизуючих документів під назвою RFC 1001 і 1102, які описують роботу NetBIOS над TCP/IP. З тих пір пакет цих документів є відомий під іменем NetBIOS над TCP/IP або NBT (У цьому випадку існує метод прив’язки імені NetBIOS до конкретної IP-адреси. Цей процес називається визначенням імені і може вирішуватися двома способами: а) кожен комп’ютер повинен передати запросившому свою IP-адресу, після одержання широкомовного запиту на своє NetBIOS ім’я; б) використовувати NBNS (NetBIOS Name Server) для розпізнавання імен NetBIOS в IP-адрес).
У великих мережах (які складаються з великої кількості мереж та підмереж) можливість всезагальної широкомовних запитів не підтримується, тому потрібен інший спосіб вирішення символьних імен. Доброю альтернативою широкомовних посилань є застосування централізованої служби, яка б підтримувала відповідність між різними типами адрес усіх комп’ютерів мережі. Наприклад, компанія Microsoft для своїх корпоративних ОС розробила централізовану службу WINS (Windows Internet Name Service), які підтримує базу даних NetBIOS імен і відповідних їм IP-адрес.
У процесі розростання INTERNET і, відповідно, збільшення кількості вузлів виникла необхідність масштабованого рішення для вирішення імен. Таким рішенням стала централізована служба DNS (Domain Name System – Система Доменних Імен), яка базується на розподіленній базі відображення “доменне ім’я – IP-адреса”. Служба DNS використовує у своїй роботі DNS-сервери і DNS-клієнти. DNS-сервери підтримують розподільну базу відображень, а DNS-клієнти звертаються до серверів зі запитами щодо вирішення доменного імені в IP-адресу.
У доменній системі імен розрізняють короткі імена, відносні імена і повні доменні імена. Коротке ім’я – це ім’я кінцевого вузла мережі (хоста чи порта маршрутизатора). Відносне ім’я – це складене ім’я, яке починається з деякого рівня ієрархії, но не найвищого. Повне доменне ім’я включає складові усіх рівнів їєрархії.
Пошук адреси по доменному імені
Коли Ви користуєтеся ім'ям, наприклад, mx.ihep.su, комп'ютер повинний перетворити його на адресу. Для цього він починає запитувати поміч у DNS-серверів. Це вузли, робітники машини, що володіють відповідною базою даних, у число обов'язків яких входить обслуговування такого роду запитів. DNS-сервер починає опрацювання імені з правого його кінця і рухається по ньому вліво, тобто спочатку провадиться пошук адреси в найбільшій групі (домене), потім поступово звужує пошук. Але для початку опитується на предмет наявності в нього потрібної інформації місцевий вузол. Тут можливі три випадки:
Місцевий сервер знає адресу, тому, що ця адреса утримується в його частині всесвітньої бази даних. Наприклад, якщо Ви під’єднані до локальної мережі якоїсь корпорації то ваш місцевий сервер повинний мати інформацію про всі комп'ютери локальної мережі цієї корпорації (mx, desert, ixwin і т.д.);
Місцевий сервер знає адреси, тому, що хтось нещодавно вже запитував таку ж адресу. Коли запитується адреса, сервер DNS притримує її у себе в пам'яті якийсь час, саме на випадок, якщо хтось ще захоче пізніше скористатися тією ж адресою - це підвищує ефективність системи;
Місцевий сервер адреси не знає, але знає як його з'ясувати.
Місцевий сервер може дізнатися запитану адресу наступним чином. У його прикладному або системному програмному забезпеченні є інформація про те, як зв'язатися з кореневим сервером. Це сервер, що знає адреси серверів імен вищого рівня (самих правих в імені), тут це рівень держав (рангу домена ua, uk). У нього запитується адреса комп'ютера, відповідального за зону ua. Місцевий DNS-сервер зв'язується з цим більш загальним сервером і запитує в нього адресу сервера, відповідального за домен ihep.ua. Тепер уже запитується цей сервер і в нього запитується адреса робочої машини mx.
Насправді, для підвищення ефективності, пошук починається не із самого верху, а з найменшого домена, у який входите і Ви, і комп'ютер, ім'я якого Ви запросили. Наприклад, якщо ваш комп'ютер має ім'я nonlin.mipt.su, то опитування почнеться (якщо ім'я не з'ясується відразу) не з усесвітнього серверу, щоб дізнатися адресу серверу групи ua, а відразу з групи mipt.ua, що скорочує пошук і за обсягом, і за часом.
Цей пошук адреси цілком аналогічний пошуку шляху листа без надписаного поштового індексу. Як визначається цей індекс? Всі регіони пронумеровані - це перші цифри індексу. Лист пересилається на центральний поштамт цього регіону, де є довідник із нумерацією районів цього регіону - це такі цифри індексу. Тепер лист йде на центральний поштамт відповідного району, де вже знають усі поштові відділенни в підопічному районі. У такий спосіб по географічній адресі визначається поштовий індекс, йому відповідний. Також визначається й адреса комп'ютера в Internet, але подорожує не послання, а запит вашого комп'ютера про цю адресу. І на відміну від випадку з поштою, інформація про адресу доходить до вас, як якби районний поштамт місця призначення відправляв вам лист, павідомляючи Вас на майбутнє про індекс.
Коли Ви бачите посилання на DNS-сервер, мається на увазі, що ми просто звертаємось до сервера імен. Імена хостів в Інтернеті складаються з частин, розділених крапками. Домен – це сукупність машин що розділяють один і то й же суфікс імені. Домен може знаходитись всередині іншого домену. Наприклад, машина www.tldp.org знаходиться в під домені tldp.org домену .org.
Кожен домен визначається первинним сервером імен, що знає ІР адреси інших машин домену. Первинний сервер може мати резервні копії на випадок, якщо він вийде з ладу. Якщо ви бачите звернення до вторинного доменного сервера, то це говорить саме про те. Вторинні сервери обновлюють свою інформацію з первинних кожних кілька годин, отож зміни, зроблені у відображенні імен у ІР адреси на первинному сервері будуть автоматично продубльовані.
Сервери імен уявлення не мають про розташування всіх машин у інших доменах (включаючи власні піддомени); вони знають лише про місцезнаходження інших серверів імен. В нашому прикладі первинний сервер імен домену .org знає ІР адреси серверів імен tldp.org, але не адреси інших машин домену tldp.org.
Домени у системі DNS нагадують дуже розлоге дерево. У основі є кореневі сервери. Кожен знає ІР адреси кореневих серверів; вони є вшитими у ваші DNS програми. Кореневі сервери знають адреси серверів імен доменів верхнього рівня на кшталт .com чи .org. Кожен сервер верхнього рівня знає адреси доменних серверів дочірнього рівня і так далі. Система доменних імен спроектована дуже акуратно, так що кожен комп’ютер володіє необхідним мінімумом знань про вузли дерева і дуже легко вносити локальні зміни без необхідності перебудовувати всю існуючу базу даних відображення імен у ІР адреси.
Коли Ви робите запит на отримання ІР адреси сайту www.tldp.org, ось що насправді відбувається: перш за все ваш сервер імен запитує кореневий сервер адресу сервера імен домену .org. Після цього він запитує у сервера імен домену .org адресу сервера імен домену .tldp.org. Ну а вже у цього сервера ваш сервер запитує адресу сайту www.tldp.org. Пакети та маршрутизатори
Нехай броузер хоче відправити командний рядок до веб-сервера на www.tldp.org, що виглядає приблизно ось так:
GET /HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html HTTP/1.0
Подивимось, що ж відбувається насправді. Команда вкладається у пакет, блок бітів, подібних до телеграми, що доповнюється трьома важливими речами: адресою джерела (ІР адресою вашої машини), адресою одержувача (152.19.254.81) та номером послуги або номером порта (80 в даному випадку, що позначає запит тенет).
Далі Ваш хост відправляє пакет (до вашого провайдера чи по локальній мережі) поки він не дістанеться до маршрутизатора. Маршутизатор має карту Інтернету у своїй пам’яті – не повну, звісно, але вона повністю описує ваше мережеве оточення та знає як дістатись до інших маршрутизаторів у Інтернеті. Ваш пакет може пройти крізь декілька маршрутизаторів на своєму шляху до цілі. Маршрутизатори є швидкими. Вони дивляться, скільки часу пакет йтиме до інших маршрутизаторів і використовують цю інформацію щоб відправляти пакети по найшвидших з’єднаннях. Вони також спостерігають коли інший маршрутизатор чи кабель виходять з ладу і стараються знайти обхідний маршрут для пакетів.
ТСР та ІР
Щоб зрозуміти, як підтримуються передачі кількох пакетів, ви повинні знати, що Інтернет вживає два протоколи, розташовані один над одним.
Нижчий рівень, ІР (Internet Protocol) відповідає за позначення індивідуальних пакетів з адресами відправника й одержувача двох комп’ютерів, що обмінюються інформацією у мережі. Наприклад, якщо ви звертаєтесь до http://www.tldp.org, пакети, що ви їх відправляєте, будуть мати ІР адресу вашого комп’ютера, скажімо, 192.168.1.101, ну а ІР адреса www.tldp.org 152.2.210.81. Ці адреси працюють точно таким чином, як у випадку, коли вам хтось відправляє листа. На пошті можуть прочитати адресу та визначити яким чином найкраще відправити вам листа, точно так само як маршрутизатор у Інтернеті робить з Інтернет-трафіком.
На верхньому рівні, TCP (Transmission Control Protocol – Протокол контролю передачі) ви отримуєте надійність. Коли дві машини узгоджують ТСР з’єднання (за допомогою ІР), одержувач знає, що він повинен відіслати підтверджувальні пакети відправнику. Якщо відправник не бачить підтверджувального пакету на протязі певного часу, він відсилає пакет повторно. До того ж, відправник присвоює кожному пакету послідовний номер, за допомогою котрих одержувач може відсортувати пакети у правильному порядку (пакети запросто можуть помінятись місцями наприклад якщо мережеве з’єднання пропало на деякий час, а потім знову появилось).
ТСР/ІР пакети містять також контрольні суми для того, щоб мати змогу перевірити правильність даних у пакетах (контрольна сума вираховується таким чином що у випадку якщо пакет чи контрольна сума пошкоджені, повторне їх вирахування на боці одержувача дуже легко виявить помилку). Отож, з точки зору будь-кого, хто використовує ТСР/ІР та сервери імен, це надійний шлях обміну потоків байтів між хостом/номером послуги. Люди, котрі пишуть мережеві протоколи, майже ніколи не повинні задумуватись над поділом на пакети, зворотною збіркою пакетів, перевіркою помилок та контрольних сум, та повторною передачею – це все робиться на нижчих рівнях.
НТТР, прикладний протокол
У попередньому прикладі Веб-броузер та сервер спілкуються по прикладному протоколу, що запускається поверх ТСР/ІР, використовуючи його як простий метод передачі даних туди й назад. Цей протокол називається НТТР (Hyper-Text Transfer Protocol, протокол передачі гіпертексту) і ми вже бачили одну його команду – GET у попередньому прикладі.
Коли команда GET потрапляє до веб-сервера www.tldp.org на порт 80, вона буде перенаправлена демону, що слухає відповідний порт. Більшість Інтернет-послуг реалізовані на основі демонів, котрі нічого не роблять, а лише слухають порти в очікуванні на вхідні команди.
Якщо б структуру Інтернету описувалась одним правилом, воно б звучало так: всі частини мають бути настільки простими й зрозумілими, наскільки це взагалі можливо. НТТР та його родичі (як, наприклад, простий протокол передачі поштових повідомлень, SMTP) прагнуть використовувати прості текстові команди, що завершуються символом нового рядка. Це максимально неефективно; в деяких випадках ви можете отримати значно більшу швидкість, використовуючи щільно закодований бінарний протокол. Але досвід показує, що вигода від команд, котрі людина може легко зрозуміти, значно більша, аніж якщо б ми робили щось швидко й незрозуміло.
Таким чином, відповідь демона вам також буде простим текстом, переданим через ТСР/ІР. Початок відповіді виглядатиме приблизно ось так (кілька заголовків було викинуто):
HTTP/1.1 200 OK
Date: Sat, 10 Oct 1998 18:43:35 GMT
Server: Apache/1.2.6 Red Hat
Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT
Content-Length: 2982
Content-Type: text/html
Після них буде порожній рядок, а далі – текст веб-сторінки, після чого з’єднання обірветься. Ваш броузер просто відобразить сторінку. Заголовки скажуть йому, як саме (зокрема, заголовок Content-Type скаже, що це справді HTML).
3. Приклад реалізації вирішення імен
1. Вибрати з поля загальних пристроїв середовища Packet Tracer Server-PT.
2. Вказати в області Config і у полі Settings цього сервера адресу Gateway (адресу порта маршрутизатора за замовчуванням) (Наприклад: див рис.1)
3. У полі FastEthernet вкажіть IP-адресу порта Вашого сервера (Наприклад: див рис.2).
4. У полі DNS встановіть відповідність “символьна адреса – IP-адреса” для вузлів Вашої мережі та забезпечте доступ до служби заданого сервера (для цього потрібно вказати IP-адресу цього сервера (Наприклад: див рис.3).
5. За допомогою утиліт ping і tracert (задаючи лише символьну адресу того, чи іншого вузла) переконайтесь у працездатності системи вирішення імен.
Додатки
DNS - Система Доменних Імен [RFC1034, RFC1035].
Доменне ім'я - це ім'я, використовуване для адресації комп'ютерів і ресурсів в Internet за допомогою звернення до глобальної системи доменних імен (DNS). Доменне ім'я складається з компонентів, розділених знаками "." (наприклад, www.lviv.ukrtelecom.ua).
Домен - це автоматизована система, що складається з доменного імені, всіх його піддоменів і сукупності організаційного, технічного, програмного, документального і інших видів забезпечення, призначених для підтримки її функціонування.
Рівень домена - це кількість компонентів в доменному імені, розділених знаками ".". Домен першого рівня .ua містить в собі всі делеговані в нім домени другого рівня - com.ua, net.ua, ukrtelecom.ua і ін. - і всі їх піддомени.
Делегування домена - це виконання адміністратором охоплюючого домена дій по включенню домена, що делегується, в глобальну систему доменних імен, унаслідок яких регистрант домена, що делегується, дістає можливість використовувати його для адресації в мережі Internet.
Реєстрація доменного імені - внесення до центральної офіційної публічно доступну базу даних інформації про факт і суб'єкта делегування домена.
Адміністратор домена - це особа, що володіє правами по використанню доменного імені (зокрема, винятковим правом делегування піддоменів), а також певними обов'язками. Реєстратор - це особа, що надає регістрантам послуги, необхідні для делегування їм домена і підтримки його функціонування.
Зона - це частина дерева, за яку відповідає той або інший DNS-сервер. Наприклад, в домені ukrtel.net є піддомен dc. Адміністрація DNS-сервера домена ukrtel.net делегувала домен donetsk серверам соотвествующего підрозділу. Таким чином, в домені ukrtel.net утворилися 2 зони: одна зона, співпадаюча з доменам dc.ukrtel.net і друга зона, що складається з частини домена ukrtel, що залишилася.net.
Пряма Зона - зона, що містить дані об відображенні імен в адреси вузлів, точки прийому пошти і ін.
Зворотна Зона - зона, що містить дані, використовувані для відображення адреси в ім'я.
Сервер DNS - машина або програма, що працює відповідно до DNS протоколами, здатний давати відповіді на запити. Відповіді можуть містити інформацію, відому даному серверу, або інформацію, отриману від іншого сервера.
Авторитетний сервер - сервер, якому відомий вміст DNS зони з локального джерела, і таким чином, він може відповідати на запити по цій зоні без необхідності звертатися до інших серверів.
Первинний сервер - авторитетний сервер, для якого інформація про зону описана локально. Іноді його ще називають майстер-сервер.
Вторинний сервер - авторитетний сервер, який отримує інформацію про зону від Первинного Сервера через механізм пересилки зони (zone transfer). Іноді його називають підлеглий сервер.
Резолвер (разрешитель) - клієнт системи DNS, який за допомогою DNS протоколів шукає інформацію, що міститься в зоні.
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора