Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
АНАЛІЗ ПРОТОКОЛІВ ЗА ДОПОМОГОЮ АНАЛІЗАТОРА ETHEREAL
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Комп’ютеризовані системи
Кафедра:
Не вказано
Інформація про роботу
Рік:
2009
Тип роботи:
Інструкція до лабораторної роботи
Предмет:
Системи та мережі передавання даних
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ
«ЛЬВІВСЬКА ПОЛІТЕХНІКА»
АНАЛІЗ ПРОТОКОЛІВ ЗА ДОПОМОГОЮ АНАЛІЗАТОРА ETHEREAL
ІНСТРУКЦІЯ
ДО ЛАБОРАТОРНОЇ РОБОТИ № 5
З КУРСУ “СИСТЕМИ ТА МЕРЕЖІ ПЕРЕДАВАННЯ ДАНИХ”
для студентів базового напряму 6.0914
“Комп’ютеризовані системи, автоматика і управління” та базового напряму 050201 “Системна інженерія”
Затверджено
на засiданнi кафедри
"Комп’ютеризовані системи
автоматики"
Протокол N 10 вiд 5.03.2009p.
ЛЬВІВ 2009
Аналіз протоколів за допомогою аналізатора Ethereal: Інструкція до лабораторної роботи № 5 з курсу ”Системи та мережі передавання даних” для студентів базового напряму 6.0914 "Комп'ютеризовані системи, автоматика і управління" та базового напряму 050201 “Системна інженерія”/ Укл. Г.І. Влах, І.І. Лагун, П.В. Мокренко – Львiв : Львівська політехніка. – 2008. – 44 с.
Укладачі: Г.І. Влах, к.т.н. доцент,
І.І. Лагун, асистент,
П.В. Мокренко, к.т.н. доцент.
Вiдповiдальний за випуск:
А.Й. Наконечний, д.т.н., професор.
Рецензент: З.Р.Мичуда, д.т.н. професор Мета роботи – ознайомлення з роботою аналізатора протоколів Ethereal для мережі Ethernet під керівництвом ОС Windows 2000, та набуття практичних навичок спостереження, аналізу трафіка та вирішення мережевих проблем.
ТЕОРЕТИЧНІ ВІДОМОСТІ
Загальні положення
Аналізатори протоколів це програмні або апаратні системи, які виконують моніторинг та аналіз трафіка. Як правило, ці системи захоплюють і декодують пакети широкого спектру протоколів. Вони виконують повне декодування, тобто в зручній для фахівця формі показують вкладеність пакетів протоколів різних рівнів з розшифровкою вмісту окремих полів кожного пакета.
Аналізатор мережевих протоколів використовується для:
локалізації проблем при роботі мережі;
виявлення й ідентифікації несанкціонованого програмного забезпечення;
одержання такої інформації, як базові моделі трафіка (baseline traffic patterns);
ідентифікації невикористовуваних протоколів для видалення їх з мережі;
генерації трафіка з метою перевірки системи захисту;
виявлення вторгнень Intrusion Detection System (IDS);
вивчення роботи мережі.
Програмні аналізатори протоколів це - програмне забезпечення, що складається з ядра, яке підтримує роботу адаптера, і програмного забезпечення, що декодує протокол канального рівня, з яким працює мережний адаптер, а також найпоширеніші протоколи верхніх рівнів: ІP, TCP, FTP, Telnet, HTTP, ІPX, NCP, DECnet, NetBEUі й т.д. До складу деяких програмних аналізаторів може входити експертна система, що дозволяє користувачеві отримати рекомендації про те, які дії можна розпочати в даній ситуації, що можуть означати ті або інші несправності та як їх усунути.
Більшість аналізаторів мережевих протоколів працюють за схемою, представленої на рис.1.
Рис.1. Принцип роботи аналізаторів мережевих протоколів
Аналізатор працює на станції хоста. Коли аналізатор запускається в безладному режимі (promiscuous mode), драйвер мережного адаптера, NIC, перехоплює весь трафік, що проходить через нього. Аналізатор протоколів передає перехоплений трафік декодеру пакетів аналізатора (packet-decoder engine), що ідентифікує й розщеплює пакети по відповідних рівнях ієрархії. Програмне забезпечення протокольного аналізатора вивчає пакети й відображає інформацію про них на екрані хоста у вікні аналізатора.
Аналіз декодованих пакетів - основне завдання будь-якого аналізатора мережевих протоколів. Аналізатор організовує перехоплені пакети по рівнях і протоколам. Кращі аналізатори пакетів можуть розпізнати протокол по його найбільш характерному рівні - верхньому - і відобразити перехоплену інформацію. Цей тип інформації звичайно відображається в другій області вікна аналізатора. Наприклад, будь-який аналізатор протоколів може розпізнавати трафік TCP.
Аналізатор протоколів Ethereal.
Пакетний сніффер Ethereal 0.10.14 є одним з кращих безкоштовних пакетних аналізаторів. Цей сніффер спочатку був створений під Linux-платформи і будувався на базі утиліти Libpcap. Згодом з'явилася Windows-версія сніффера Ethereal, яка будувалася на базі утиліти WinPcap (Windows-версія Libpcap).
Утиліта WinPcap є стандартним інструментом, за допомогою якого Windows-додатки можуть безпосередньо діставати доступ до мережевого адаптера (NIC-рівня) і перехоплювати мережеві пакети. Крім того, драйвер WinPcap має додаткові функціональні можливості, що полягають у фільтрації пакетів, зборі мережевої статистики і підтримці можливості віддаленого перехоплення пакетів.
До складу утиліти WinPcap входить драйвер, що забезпечує взаємодію з NIC-рівнем, і бібліотека, що відповідає за взаємодію з інтерфейсом API.
Ethereal — один з небагатьох сніфферів, який підтримує як графічний інтерфейс, так і запуск з командного рядка, що зручно при складанні сценаріїв або активізації функцій перехоплення пакетів у разі виникнення в мережі певних подій.
У пакеті Ethereal 0.10.14 зустрічаються практично всі функції, які тільки можуть бути у аналізатора пакетів. Програма може декодувати 752 протоколи і підтримує роботу в Wi-Fi-мережах.
Графічний інтерфейс пакету Ethereal 0.10.14 цілком традиційний і містить три області: відображення перехоплених пакетів, відображення статистичної інформації про конкретний вибраний пакет та вміст конкретного пакету (рис. 2) .
Верхня область містить список захоплених пакетів з коротким описом, в середній – відкривається дерево протоколів, інкапсульованих в кадр. Гілки дерева можуть бути розкриті для підвищення рівня деталізації вибраного протоколу. Останнє вікно містить дамп пакету в шістнадцятковому і текстовому вигляді.
Рис.2. Загальний інтерфейс аналізатора пакетів Ethereal 0.10.14
Графічний інтерфейс Ethereal 0.10.14.
Робота з програмою Ethereal побудована на базі графічного інтерфейсу (GUI), показаного на рис.2. Режим захоплення і відображення пакетів задається за допомогою опцій командного рядка і описаних в подальших параграфах команд меню і діалогових вікон.
Головне вікно програми.
Головне вікно Ethereal розділене на три панелі. Розміри кожної з панелей можна міняти, використовуючи маркер в нижній правій частині відповідної панелі.
Верхня панель.
Верхня панель вікна Ethereal містить список пакетів. За замовчуванням в списку виводиться 6 колонок – номер пакету в списку зібраних, тимчасова мітка, адреси і номери портів відправника і одержувача, протокол і короткий опис пакету. Ви можете змінити набір колонок, що відображаються, за допомогою сторінки Columns діалогового вікна Preferences. Для активізації діалогового вікна можна використовувати команду меню Edit: Preferences або кнопку на панелі інструментів вікна Ethereal.
У верхній частині екрану розташована панель основних меню.
Меню File (рис.3) дозволяє відкривати (Open ...), закривати (Close), зберігати (Save і Save as ...), виводити на друк (Print ...) файли захоплених пакетів, виводити на друк вміст окремих пакетів (Print Packet), а також виходити з програми (Quit).
Рис.3. Меню File аналізатора пакетів Ethereal 0.10.14
Меню Edit (рис.4) дозволяє здійснювати пошук кадрів (Find Packet ...), маркувати кадри (Mark Packet, Unmark Packets і Mark All Packets ...), задавати необхідні параметри (Preferences).
Рис.4. Меню Edit аналізатора пакетів Ethereal 0.10.14
Меню Capture (рис.5) служить для включення (Start...) режиму захоплення кадрів і виходу з нього (Stop), відкриває діалогове вікно, яке показує, що відбувається в мережевих інтерфейсах (Interfaces...), налаштування елементів для збору даних та захоплення пакетів (Options...).
Рис.5. Меню Capture аналізатора пакетів Ethereal 0.10.14
Меню Analyze (рис.6) дозволяє створювати та проглядати фільтри (Display Filters ...), а також включати і відключати режим аналізу протоколів (Enabled Protocols...), відстежувати TCP-потік (Follow TCP Stream), отримувати дані про протоколи захоплених пакетів (Decode As ...).
Рис.6. Меню Analyze аналізатора пакетів Ethereal 0.10.14
Меню Staistics (рис.7) дозволяє побачити інформацію про захоплені дані (Summary ...), ієрархічне дерево статистики протоколу (Protocol Hierarchy), діалог між двома кінцевими точками (Conversation List), список кінцевих точок (Endpoint List), тривалість часу між запитом і відповіддю, а також виводити на екран статистику протоколів.
Замість роботи з графічним інтерфейсом, адміністратор може скористатися командним рядком. Інструмент роздруковує зведення проаналізованих пакетів — по аналогії з верхнім полем у варіанті з графічним інтерфейсом. За допомогою опції -V інструмент відображає вміст середнього поля, а при вказівці -х — роздруковує нижнє поле. Протокольний аналізатор включає також інші програми обробки файлів збору даних. До них відносяться Editcap — програма для видалення пакетів з файлу і перетворення формату файлів збору. Вона читає всі типи форматів і проводить запис у форматах libpcap snoop від Sun, Lanalyzer від Novell, Sniffer від NAI, Network Monitor від Microsoft і ін.. За допомогою Mergecap адміністратор може помістити декілька збережених файлів збору в єдиний вихідний файл і упорядкує в пакети за часом. Нарешті, Text2pcap прочитує ASCII або шістнадцятковий дамп збору і записує дані у файл libpcap. Програма в змозі сприйняти шістнадцятковий дамп з безліччю пакетів і скласти з них файл збору. Вона здатна читати шістнадцятковий дамп, де містяться дані виключно прикладного рівня.
Сеанс захоплення пакетів
Для запуску сеансу захоплення пакетів необхідно вибрати Start з меню Capture. з'явиться діалогове вікно (Capture Options) для вибору параметрів режиму захоплення пакетів (рис.8).
Рис.8. Діалогове вікно Capture Options аналізатора пакетів Ethereal 0.10.14
Поле Interface: дозволяє ввести інтерфейс, на якому потрібно аналізувати пакети. Можна задати тільки один інтерфейс, причому тільки з числа тих, які виявлені аналізатором.
Кнопка і поле Limit each packet to ____ bytes служить для завдання максимального об'єму даних, що фіксується аналізатором по кожному пакету. За замовчуванням це 65535 байт, що достатньо для більшості протоколів.
Кнопка Capture packets in promiscuous mode переводить інтерфейс аналізатора в режим "нерозбірливого" захоплення. Якщо цей режим не включений, аналізатор захоплюватиме тільки вхідні пакети адресовані комп'ютеру, на якому встановлений аналізатор, або вихідні.
Кнопка і поле Filter дозволяють задати фільтр пакетів. Порожнє значення означає захоплення без фільтрації. Якщо натиснути кнопку Filter, то з'явиться діалогове вікно для побудови або вибору готового фільтру.
Кнопка і поле File служать для введення імені файлу, в якому будуть збережені результати захоплення.
Кнопка Use ring buffer переводить буфер, що приймає пакети, в кільцевий режим. Поле Number of files__служить для числа файлів та збереження захоплених пакетів. Поле Rotate capture file every__seconds дозволяє задати в секундах період прокрутки файлу захоплених пакетів.
Ряд кнопок і полів служать для задання параметрів відображення. Кнопка Update list of packets in real time переводить вікно списку пакетів в режим реального часу. Кнопка Automatic scrolling in live capture переводить вікно списку пакетів в режим автоматичної прокрутки.
Ряд кнопок і полів служать для задання обмежень на число захоплених пакетів, на загальний об'єм захоплених пакетів і тривалість сеансу захоплення: Stop capture after__packets captured, Stop capture after__kilobyte(s) captured, Stop capture after__seconds. Незаповнене поле або нульовий вміст будь-якого з цих полів означає відсутність відповідного обмеження.
Кнопка Enable MAC name resolution встановлює режим трансляції перших трьох байт МАС-адреси в назву виробника мережевої карти. Кнопка Enable network name resolution встановлює режим переводу IP-адрес в доменні імена. Цей режим дає більше інформації, але уповільнює роботу аналізатора по захопленню пакетів. Кнопка Enable transport name resolution встановлює режим переводу номерів портів в протоколи.
Після установки параметрів можна натиснути Start для початку процесу захоплення або Cancel для його припинення. З'явиться вікно, в якому в реальному масштабі часу відображається статистика сеансу (рис.9). Якщо сеанс налаштований для показу пакетів в реальному часі, то їх можна спостерігати у вікні, в міру того як вони проходять по середовищу передачі.
Рис.9. Вікно статистики сеансу аналізатора пакетів Ethereal 0.10.14
Фільтрація в процесі захоплення пакетів
Для запису фільтру використовується послідовність простих виразів (примітивів), сполучених логічними зв'язками and або or, перед якими може бути присутнє заперечення not:
[not] <примітив> [and I or [not] <примітив> ...]
Наприклад, щоб захопити трафік, адресований до вузла з IP-адресою192.168.12.14 або від нього, використовується фільтр tcp port 23 and host 192.168.12.14. Якщо потрібно захопити весь трафік, окрім трафіку, адресованого вузлу 192.168.12.14 або вихідного, використовується фільтр tcp port 23 and not host 192.168.12.14.
Проглядання захоплених пакетів
«Клацнувши» по виділеному пакету у вікні захоплених пакетів, отримаємо дерево полів пакету в середньому вікні і байтове уявлення – в нижньому. Щоб розвернути елемент дерева полів, слід «клацнути» знак "+" зліва від відповідного елементу.
Визначення адреси призначення пакету. Шлюз по замовчуванню
Виконуючи відкрите перехоплення пакетів мережі й використовуючи потім статистичні звіти, можна зрозуміти, наскільки завантажена мережа й на який вид пакетів доводиться основна частина трафіка. Проаналізувавши ці дані, можна зробити висновок про те, чи прийшов час перейти на комутовану мережу 100 Мбіт/с або розділити на кілька підмереж замість однієї великої мережі. Можна також визначити, чи потрібно встановити сервер WINS (якщо занадто багато запитів імен SMB, переданих по мережі), або чи деякий сервер необхідно перенести в демілітаризовану зону або на окремий порт маршрутизатора, щоб видалити асоційований з ним трафік з мережі.
Вивчення роботи протоколів UDP, TCP, ICMP, ARP у мережі Ethernet.
Протокол UDP.
Протокол UDP (User Datagram Protocol, RFC-768) є одним з основних протоколів, розташованих безпосередньо над IP. Він надає прикладним процесам транспортні послуги, які відрізняються від послуг протоколу IP. Протокол UDP забезпечує доставку дейтаграм, але не вимагає підтвердження їхнього одержання. Протокол UDP не вимагає з'єднання з віддаленим модулем UDP ("нескладний" протокол). До заголовка IP-пакета UDP додає поля порт відправника й порт одержувача, які забезпечують мультиплексування інформації між різними прикладними процесами, а також поля довжина udp-дейтаграми й контрольна сума, що дозволяють підтримувати цілісність даних. Таким чином, якщо на рівні ІР для визначення місця доставки пакета використовується адреса, на рівні UDP - номер порту.
Прикладні процеси й модулі UDP взаємодіють через UDP-порти. Ці порти нумеруються, починаючи з нуля (таблиця 1 додатку). Прикладний процес, що надає деякі послуги (сервер), очікує повідомлень, спрямованих у порт, спеціально виділений для цих послуг. Програма-сервер чекає, коли яка-небудь програма-клієнт запросить послугу.
Дані, що відправляють прикладним процесом через модуль UDP, досягають місця призначення як єдине ціле. Наприклад, якщо процес-відправник робить 5 записів у порт, то процесс-отримувач повинен буде зробити 5 читань. Розмір кожного записаного повідомлення буде збігатися з розміром кожного прочитаного. Протокол UDP зберігає межі повідомлень, обумовлені прикладним процесом. Він ніколи не поєднує кілька повідомлень в одне й не ділить одне повідомлення на частини. Формат UDP-повідомлень представлений нижче на рис.10:
Рис.10. Формат UDP-дейтаграм
Довжина повідомлення дорівнює числу байт в UDP-дейтаграмі, включаючи заголовок. Поле UDP контрольна сума містить код, отриманий у результаті контрольного підсумовування UDP-заголовка й поля даних. Не важко побачити, що цей протокол використовує заголовок мінімального розміру (8 байт). Номера портів від 0 до 255 стандартизовані й використовувати їх у прикладних завданнях не рекомендується. Але й в інтервалі 255-1023 багато номерів портів зайняті, тому перш ніж використати якийсь порт у своїй програмі, варто заглянути в RFC-1700. У другій колонці таблиці міститься стандартне ім'я, прийняте в Internet, а в третій - записані імена, прийняті в UNIX. Зареєстровано ряд портів для стандартного застосування й у діапазоні 1024-65535.
Модуль IP передає вхідний IP-пакет модулю UDP, якщо в заголовку цього пакета зазначений код протоколу UDP. Коли модуль UDP одержує дейтаграму від модуля IP, він перевіряє контрольну суму, що міститься в її заголовку. Якщо контрольна сума дорівнює нулю, це означає, що відправник її не підрахував. ICMP, IGMP, UDP й TCP протоколи мають той самий алгоритм обчислення контрольної суми (RFC-1071). Але обчислення контрольної суми для UDP має деякі особливості. По-перше, довжина UDP-дейтаграми може містити непарне число байт, у цьому випадку до неї додається нульовий байт, що служить лише для уніфікації алгоритму й нікуди не пересилається. По-друге, при розрахунку контрольної суми для UDP й TCP додаються 12-байтні псевдозаголовки, що містять IP-адреси відправника й одержувача, код протоколу й довжину дейтаграми (див. рис.10). Як й у випадку IP-дейтаграми, якщо обчислена контрольна сума дорівнює нулю, у відповідне поле буде записаний код 65535.
Якщо контрольна сума правильна (або дорівнює 0), то перевіряється порт призначення, зазначений у заголовку дейтаграми. Якщо прикладний процес підключений до цього порту, то прикладне повідомлення, що міститься в дейтаграмі, стає в чергу до прикладного процесу для читання. В інших випадках дейтаграма відкидається. Якщо дейтаграми надходять швидше, ніж їх встигає обробляти прикладний процес, то при переповненні черги повідомлень дейтаграми відкидаються модулем UDP. Варто враховувати, що в багатьох посилках контрольне підсумовування не охоплює адреси відправника й місця призначення.
Протокол TCP
Протокол TCP (Transmission Control Protocol) на відміну від UDP здійснює доставку дейтаграм сегментами, у вигляді байтових потоків із встановленням з'єднання. Під байтовими потоками мається на увазі те, що будь-який примітив, наприклад, read або write може викликати посилку адресатові послідовності сегментів, які утворять деякий блок даних (повідомлення).
Протокол TCP застосовується в тих випадках, коли потрібна гарантована доставка повідомлень. Він використовує контрольні суми пакетів для перевірки їхньої цілісності й звільняє прикладні процеси від необхідності тайм-аутів і повторних передач для забезпечення надійності. Для відстеження підтвердження доставки в TCP реалізується алгоритм "ковзаючого" вікна. Найбільш типовими прикладними процесами, що використовують TCP, є FTP (file transfer protocol - протокол передачі файлів) і TELNET. Крім того, TCP використовують системи SMTP, HTTP, X-window, RCP (remote copy). Внутрішня структура модуля TCP набагато складніша ніж структура UDP. Подібно UDP прикладні процеси взаємодіють із модулем TCP через порти. Використання портів відкриває можливість здійснювати кілька з'єднань між двома мережними об'єктами (працювати з різними процесами).
Саме з номерів портів відправника й одержувача починається заголовок TCP-сегмента (рис.11). 32-бітове поле код позиції в повідомленні визначає порядковий номер першого октету в полі даних користувача. У додатках передавача й приймача цьому полю відповідають 32-розрядні лічильники числа байт, які при переповненні обнуляються. При значенні прапора syn=1 у цьому полі лежить код ISN (Initial Sequence Number), обраний для конкретного з'єднання.
32-бітове поле номер октету, що повинен прийти наступним містить код, що на одиницю більше номера останнього успішно доставленого (прийнятого) байта. Вміст цього поля інтерпретується одержувачем сегмента, тільки якщо є присутнім прапор ACK. У заголовках всіх сегментів, переданих після встановлення з'єднання це поле заповнюється, а прапор AСК=1.
Поле HLEN - визначає довжину заголовка сегмента, що вимірюється в 32-розрядних словах. Це поле потрібно тому, що в заголовку можуть утримуватися поля опцій змінної довжини. Наступне поле резерв, призначене для майбутнього використання, у цей час повинно обнулятися. Поле розмір вікна повідомляє, скільки октетів готовий прийняти одержувач (прапор ACK=1) вслід за байтом, зазначеним у полі номер октету, що повинен прийти наступним.
Поле контрольна сума призначене для забезпечення цілісності повідомлення. Контрольне підсумовування проводиться за модулем 1. Перед контрольним підсумовуванням до TCP-сегмента додається псевдозаголовок, як й у випадку протоколу UDP, який містить у собі адреси відправника й одержувача, код протоколу й довжину сегмента, крім псевдозаголовку. Поле покажчик важливої інформації являє собою покажчик останнього байта, що містить інформацію, яка вимагає негайного реагування. Поле має сенс лише при прапорі URG=1, що відзначає сегмент із першим байтом "важливої інформації". Значення розрядів в 6-бітовому коді прапора описані у додатку таблиця 1. Якщо прапор ACK=0, значення поля номер октету, що повинен прийти наступним, ігнорується. Прапор URG=1 встановлюється у випадку натискання користувачем клавіш Del або Ctrl-С.
Рис.11. Формат TCP-сегмента
Поле опції зарезервоване на майбутнє й у заголовку може бути відсутнім, його розмір змінний і доповнюється до кратного 32-бітного за допомогою поля заповнювач. Формат поля опції представлений на рис.12.
Рис.12. Формат опцій для TCP-сегментів
У цей час визначені опції:
0 – Кінець списку опцій.
1 – Ніяких операцій. Використовується для заповнення поля опції до числа октетів, кратного 4.
2 – Максимальний розмір сегмента (MSS).
У поле вигляд записується код опції, поле LEN містить число октетів в описі опції, включаючи поля вигляд й LEN. Визначені також опції зі значенням вигляд=4,5,6,7. У пропозиції T/TCP (RFC-1644) описані опції 11, 12 й 13. Поле дані може мати змінну довжину, верхня його границя задається значенням MSS (Maximum Segment Size). Значення MSS може бути задане при встановленні з'єднання кожної зі сторін незалежно. Для Ethernet MSS=1452 байта.
Розглянемо схему створення TCP-з’єднання (рис 13).
Рис.13. Схема створення TCP-з’єднання
Припустимо, що хосту А необхідно створити TCP-з’єднання з хостом В. Тоді А посилає на В наступне повідомлення: SYN, ISSa.
Це означає, що в переданому А повідомленні встановлений біт SYN. (Synchronize Sequence Number), а в поле Sequence Number установлено початкове 32-бітне значення ISSa (Initial Sequence Number).
Хост В відповідає: SYN, АСК, ISSb, ACK(ISSa+l).
У відповідь на отриманий від А запит В посилає повідомлення, у якому встановлені біт SYN і біт АСК; у поле Sequence Number хостом В задається своє початкове значення лічильника - ISSb; поле Acknowledgment Number містить значення ISSa, отримане в першому пакеті від хосту А і збільшене на одиницю.
Хост А, завершуючи рукостискання (handshake), посилає: АСК, ISSa+1, ACK(ISSb+l).
У цьому пакеті встановлений біт АСК; поле Sequence Number містить значення ISSa+1; поле Acknowledgment Number містить значення ISSb+1. Посилкою цього пакета на хост В закінчується триступінчастий handshake, і TCP-з'єднання між хостами А і В вважається встановленим.
Тепер хост А може посилати пакети з даними на хост В по тільки що створеному віртуальному ТСР-каналу; передається наступна інформація: АСК, ISSa+1, ACK(ISSb+l); DATA.
Протокол передачі команд і повідомлень про помилки (ICMP)
Протокол передачі команд і повідомлень про помилки ICMP (Internet Control Message Protocol) виконує багато діагностичних функцій в мережі. Саме цей протокол використовується програмним забезпеченням ЕОМ при взаємодії один з одним у рамках ідеології TCP/IP. Здійснення повторної передачі пакета, якщо попередня спроба була невдалою, лежить на TCP або прикладній програмі. При пересиланні пакетів проміжні вузли не інформуються про виниклі проблеми, тому помилка в маршрутній таблиці буде сприйматися як несправність у вузлі адресата й вірогідно діагностуватися не буде. ICMP-протокол повідомляє про помилки в IP-дейтаграмах, але не дає інформації про помилки в самих ICMP-повідомленнях. ICMP використовує IP, а IP-протокол повинен використовувати ICMP. У випадку ICMP-фрагментації повідомлення про помилку буде видано тільки один раз на дейтаграму, навіть якщо помилки були в декількох фрагментах. Підводячи підсумки, можна сказати, що ICMP-протокол здійснює:
передачу відгуку на пакет або ехо на відгук;
контроль часу життя дейтаграм у системі;
реалізує переадресацію пакета;
видає повідомлення про недосяжність адресата або про некоректність параметрів;
формує й пересилає тимчасові мітки;
видає запити й відгуки для адресних масок й іншої інформації.
ICMP-повідомлення про помилки ніколи не видаються у відповідь на:
ICMP-повідомлення про помилку.
При мультикастингу або широкомовній адресації.
Для фрагмента дейтаграми (крім першого).
Для дейтаграм, чия адреса відправника є нульовою, широкомовною або мультикастинговою.
Ці правила покликані блокувати потоки дейтаграм, що посилають у відгук на мультикастинг або широкомовні ICMP-повідомлення.
ICMP-повідомлення мають свій формат, а схема їхнього вкладення аналогічна UDP або TCP і представлена на рис.14.
Рис. 14. Схема вкладення ICMP-пакетів в Ethernet-кадр
Всі ICMP пакети (рис.15) починаються з 8-бітного поля типу ICMP і його коду (15 значень). Код уточнює функцію ICMP-повідомлення. Таблиця цих кодів наведена в додатку (символом * позначені повідомлення про помилки, інші - є запитами).
Рис. 15. Формат ICMP сегмента.
Процедура "відключення джерела" (quench, поле тип ICMP=4) дозволяє управляти потоками даних у каналах Інтернет. Не справляючись із обробкою дейтаграм, ЕОМ-адресат може надіслати запит "відключити джерело" відправникові, що може скоротити темп посилки пакетів або зовсім перервати їхню посилку. Спеціальної команди, що скасовує колишні заборони, не існує. Якщо повідомлення про відключення припиняються, джерело може відновити посилку пакетів або збільшити частоту їхнього відправлення. Нижче (на рис.16) представлений формат ехо-запиту (ping) і відгуку для протоколу ICMP.
Рис. 16. Формат ехо-запиту й відгуку ICMP
Поля ідентифікатор (звичайно це ідентифікатор процесу) і номер один по одному (збільшується на 1 при посилці кожного пакета) служать для того, щоб відправник міг зв'язати в пари запити й відгуки. Поле тип визначає, чи є цей пакет запитом (8) або відгуком (0). Поле контрольна сума являє собою 16-розрядне доповнення по модулю 1 контрольної суми всього ICMP-повідомлення, починаючи з поля тип. Поле дані служить для запису інформації, що повертається відправникові. При виконанні процедури ping ехо-запит з тимчасовою міткою в полі дані посилається адресатові. Якщо адресат активний, він приймає IP-пакет, змінює адресу відправника й одержувача місцями й посилає його назад. ЕОМ-відправник, сприйнявши цей відгук, може зрівняти тимчасову мітку, записану ним у пакет, з поточною вказівкою внутрішніх годин і визначити час поширення пакета (RTT - round trip time). Розмір поля дані не регламентоване й визначається граничним розміром IP-пакета.
Час поширення ICMP-запиту, загалом кажучи, не дорівнює часу поширення відгуку. Це зв'язано не тільки з можливими змінами в каналі. У загальному випадку маршрути їхнього руху можуть бути різними.
Коли маршрутизатор не може доставити дейтаграму по місцю призначення, він посилає відправникові повідомлення "адресат не досяжний" (destination unreachable). Формат такого повідомлення показаний нижче (рис.17).
Рис.17. Формат ICMP-повідомлення "адресат не досяжний".
Поле код містить ціле число. Перелік кодів таких повідомлень наведений в додатку (таблиця 3). Поле MTU на наступному етапі характеризує максимальну довжину пакетів на черговому кроці пересилання.
Тому що в повідомленні міститься Інтернет-заголовок і перші 64-біти дейтаграми, легко зрозуміти, яка адреса виявилася недосяжною. Цей тип ICMP-повідомлення посилає й у випадку, коли дейтаграма має прапор DF=1 ("не фрагментувати"), а фрагментація необхідна. У поле код у цьому випадку буде записане число 4.
Якщо буфер прийому повідомлення переповнений, ЕОМ посилає повідомлення типу 4 для кожного з не записаних у буфер повідомлень.
Тому що власні годинники різних ЕОМ мають своє подання про час, протокол ICMP, серед іншого, служить для синхронізації роботи різних вузлів, якщо це потрібно (запити тимчасових міток). Протокол синхронізації NTP (network time protocol) описаний в RFC-1119.
Коли дейтаграми надходять занадто часто й приймаюча сторона не справляється із цим потоком, відправникові може бути послане повідомлення з вимогою різко скоротити інформаційний потік (quench-запит), зниження потоку повинне тривати доти, поки не припиняться quench-запити. Формат такого повідомлення представлений на рис.18.
Рис.18. Формат ICMP-запиту зниження завантаження
В Internet таблиці маршрутизації залишаються без змін досить довгий час, але іноді таблиці все-таки змінюються. Якщо маршрутизатор виявить, що ЕОМ використовує неоптимальний маршрут, він може послати їй ICMP-запит переадресації. Формат такого повідомлення зображений на рис.19.
Рис.19. Формат ICMP-запиту переадресації
Поле Internet-адреса маршрутизатора містить адресу маршрутизатора, яку ЕОМ повинна використати, щоб послана дейтаграма досягла місця призначення, зазначеного в її заголовку. У полі internet-заголовок крім самого заголовка лежить 64 перших біта дейтаграми, що викликало це повідомлення. Поле код специфікує те, як потрібно інтерпретувати адресу місця призначення (див. табл.3 додатку).
Команди переадресації маршрутизатор посилає тільки ЕОМ і ніколи іншим маршрутизаторам.
Маршрутна таблиця може завантажуватися з файлу, формуватися адміністратором мережі, але може створюватися й у результаті запитів й оголошень, що посилають маршрутизаторами. Після завантаження системи маршрутизатор надсилає широкомовний запит. Один або більше маршрутизаторів посилають у відповідь повідомлення про наявну маршрутну інформацію. Крім того, маршрутизатори періодично (раз в 450-600 сек.) широкомовно повідомляють про свої маршрути, що дозволяє іншим маршрутизаторам скорегувати свої маршрутні таблиці. В RFC-1256 описані формати ICMP-повідомлень такого роду (рис.20).
Рис. 20. Формат ICMP-повідомлень про наявні маршрути
Поле число адрес характеризує кількість адресних записів у повідомленні. Поле довжина адреси містить число 32-бітних слів, необхідних для опису адреси маршрутизатора. Поле час життя призначений для запису тривалості життя оголошених маршрутів (адрес) у секундах. За замовчуванням час життя дорівнює 30 хв. Поля рівень пріоритету являють собою міру пріоритетності маршруту стосовно інших маршрутів даної підмережі. Чим більший цей код тим вищий пріоритет. Маршрут за замовчуванням має рівень пріоритету 0. Формат запиту маршрутної інформації зображено на рис.21.
Рис.21. Формат запиту маршрутної інформації
Тому що наступний прогін (hop) дейтаграми визначається на підставі локальної маршрутної таблиці, помилки в останній можуть привести до зациклення пакетів. Для придушення таких циркуляцій використовується контроль за часом життя пакета (TTL). При ліквідації пакета після закінчення TTL маршрутизатор посилає відправникові повідомлення "час минуло" (рис.22).
Рис.22. Формат повідомлення "час (ttl) минуло"
Значення поля код визначає природу тайм-ауту (див. табл. 3 додатку).
Коли маршрутизатор або ЕОМ виявили яку-небудь помилку, не з числа описаних вище (наприклад, нелегальний заголовок дейтаграми), посилається повідомлення "конфлікт параметрів". Це може відбутися при невірних параметрах опцій. При цьому посилається спеціальне повідомлення (рис.23):
Рис.23. Формат повідомлення типу "конфлікт параметрів"
Поле покажчик відзначає октет дейтаграми, що створив проблему. Код=1 використається для повідомлення про те, що відсутня необхідна опція (наприклад, опція безпеки при конфіденційних обмінах), поле покажчик при значенні поля код=1 не використовується.
У процесі трасування маршрутів виникає проблема синхронізації роботи годин у різних ЕОМ. На щастя синхронізація внутрішніх годин ЕОМ потрібна не так часто (наприклад, при виконанні синхронних вимірів), негативну роль тут можуть грати затримки в каналах зв'язку. Для запиту тимчасової мітки інша ЕОМ використовує повідомлення запит тимчасової мітки (рис. 24).
Рис.24. Формат ICMP-запиту тимчасової мітки
Поле тип=13 указує на те, що це запит, а тип=14 - на те, що це відгук. Поле ідентифікатор і номер один по одному використовуються відправником для зв'язку запиту й відгуку. Поле вихідна тимчасова мітка заповнюється відправником безпосередньо перед відправленням пакета. Поле тимчасова мітка на вході заповнюється маршрутизатором при одержанні цього пакета, а Тимчасова мітка на виході - безпосередньо перед його відправленням. Саме цей формат використовується в процедурах ping й traceroute. Ці процедури дозволяють не тільки діагностувати, але й оптимізувати маршрути.
При роботі із субмережею важливо знати маску цієї субмережі. Для одержання маски субмережі ЕОМ може послати "запит маски" у маршрутизатор й одержати відгук, що містить цю маску. ЕОМ може це зробити безпосередньо, якщо їй відома адреса маршрутизатора, або вдавшись до широкомовного запиту. Нижче описаний формат таких запитів-відгуків (рис. 25).
Рис.25. Формат запиту (відгуку) маски субмережі
Поле тип тут специфікує модифікацію повідомлення, тип=17 - це запит, а тип=18 - відгук. Поля ідентифікатор і номер один по одному, як звичайно, забезпечують взаємну прив'язку запиту й відгуку, а поле адресна маска містить 32-розрядну маску мережі.
Протокол перетворення адрес ARP.
Будь-який пристрій, підключений до локальної мережі (Ethernet, FDDI і т.д.), має унікальну фізичну мережну адресу, задану апаратно. 6-байтова Ethernet-адреса вибирає виробника мережного інтерфейсного обладнання з виділеного для нього по ліцензії адресного простору. Якщо в машини змінюється мережний адаптер, то змінюється і її Ethernet-адреса.
4-байтову IP-адресу задає адміністратор мережі з урахуванням положення машини в мережі Інтернет. Якщо машина переміщується в іншу частину мережі Інтернет, то її IP-адреса повинна бути змінена. Перетворення IP-адрес у мережеві виконується за допомогою ARP-таблиці. Кожна машина мережі має окрему ARP-таблицю для кожного свого мережного адаптера. Але існує проблема відображення фізичної адреси (6 байт для Ethernet) у простір мережевих IP-адрес (4 байти) і навпаки.
Протокол ARP (address resolution protocol) вирішує саме цю проблему - перетворює ARP- в Ethernet-адреси.
Для визначення Ethernet-адреси проглядається ARP-таблиця. Якщо для необхідної IP-адреси в ній є присутня Ethernet-адреса, то формується
24.01.2013 00:01-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора