Net Labs PDF

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
Н А Ц І О Н А Л ЬН И Й ТЕХНІЧНИЙ УНІВЕРСИТЕТ
«ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ»
М. В. МЕЗЕНЦЕВ, М. Й. ЗАПОЛОВСЬКИЙ, В. І. ПАНЧЕНКО
КОМП’ЮТЕРНІ МЕРЕЖІ
Лабораторний практикум
для студентів денної та заочної форм навчання
за спеціальністю «Комп’ютерна інженерія»
Затверджено
редакційно-видавничою
радою університету НТУ «ХПІ»,
протокол № 2 від 17.05.2019
Харків
НТУ «ХПІ»
2019
УДК 004.7
М44
Рецензенти: Г. Ф. Кривуля, д-р. техн. наук, професор, Харківський

національний університет радіоелектроніки;
О. О. Можаєв, д-р. техн. наук, професор, Харківський

національний університет внутрішніх справ.
Мезенцев М. В. Комп’ютерні мережі: лабораторний практикум /

М44 М.В. Мезенцев, М.Й. Заполовський, В.І. Панченко. –
Харків: ФОП Панов А.М., 2019. – 358 с.
ISBN 978-617-7771-78-3
Розглянуто використання технологій віртуалізації для практичної роботи з

комп’ютерними мережами. Лабораторний практикум реалізовано за допомогою
віртуальних машин Qemu в середовищі GNS3 з використанням операційної системи
RouterOS фірми Mikrotik та IOS фірми Cisco. Матеріал лабораторного практикуму може
використовуваться для отримання навичок практичного застосування наступних
мережних технологій: маршрутизація, безпровідні мости, виртуальні приватні мережі,
віртуальні локальні мережі.
Призначено для студентів денної та заочної форм навчання за спеціальністю
«Комп’ютерна інженерія», а також може бути корисно як для початківців, так і для
досвідчених спеціалістів, які займаються проектуванням та налаштуванням
комп’ютерних мереж.
Іл. 146. Табл. 29. Бібліогр. 10 назв.
УДК 004.7
 М. В. Мезенцев,
ISBN 978-617-7771-78-3 М.Й. Заполовський,
В. І. Панченко, 2019
ЗМІСТ
Вступ ................................................................................................................ 4
Лабораторна робота 1. Знайомство з середовищем GNS3. IP-адресація ... 5
Лабораторна робота 2. Ознайомлення з мережною операційною
системою IOS компанії Cisco ....................................................................... 16
Лабораторна робота 3.Ознайомлення з мережною операційною системою
RouterOS фірми Mikrotik ............................................................................... 38
Лабораторна робота 4. Статична маршрутизація....................................... 56
Лабораторна робота 5. Організація об’єднання мереж за допомогою
протоколу ІР ................................................................................................... 67
Лабораторна робота 6. Динамічна маршрутизація .................................... 88
Лабораторна робота 7. Безкласова адресація і маски змінної довжини . 101
Лабораторна робота 8. Балансування каналів.......................................... 113
Лабораторна робота 9. Передача на канальному рівні. Протокол STP .. 123
Лабораторна робота 10. Віртуальні локальні мережі .............................. 142
Лабораторна робота 11. Протоколи транспортного рівня ТСР/ІР.
Протоколи ICMP та DHCP. Служба DNS................................................... 155
Лабораторна робота 12. Списки управління доступом. Захист мереж... 176
Лабораторна робота 13. Трансляція мережних адрес.............................. 194
Лабораторна робота 14. Технологія Проксі-сервер ................................. 203
Лабораторна робота 15. Віртуальні приватні мережі .............................. 216
Лабораторна робота 16. Технологія IPSec................................................ 236
Лабораторна робота 17. Технології бездротових мереж ......................... 251
Лабораторна робота 18. Технологія MPLS ............................................. 267
Лабораторна робота 19. Технологія MPLS L2VPN ................................ 281
Лабораторна робота 20. Технологія MPLS L3VPN ................................ 304
Лабораторна робота 21 Додаткові функції маршрутизаторів. Скрипти. 316
Лабораторна робота 22. Основи мережного програмування................... 335
Список літератури ..................................................................................... 357
3
ВСТУП
GNS3 – це графічний симулятор, що дозволяє емулювати складні

мережі. Для створення мережних топологій в GNS3 використовується
технологія Drug-and-Drop. GNS3 підтримує три віртуальні машини:
Dynamips, VirtualBox та Qemu.
Віртуальна машина Dynamips дозволяє запустити реальну операційну
систему IOS широкого класу пристроїв компанії Cisco. Однак для роботи з
Dynamips необхідно добирати параметри для зменшення завантаження на
центральний процесор. Тому без необхідних налаштувань навіть для
топології з трьох маршрутизаторів Dynamips буде використовувати всі
ресурси процесора.
Під Qemu працюють багато мережних, вбудованих та мобільних
систем: Juniper JunOS, Openwrt, Vyatta, Google Android, Mikrotik RouterOs,
Cisco IDS та інші. VirtualBox також підтримує широкий клас операційних
систем. Однак при роботі в контейнері GNS3 для VirtualBox необхідно
виконувати налаштування кожної операційної системи для кожного
пристрою в топології мережі. Qemu для всіх пристроїв з однаковою ОС
використовує ті самі налаштування.
GNS3 може працювати під керуванням систем сімейства Windows і
Linux. Qemu під Linux підтримує апаратну віртуалізацію KVM. Qemu під
Windows не підтримує KVM, та при запуску декількох екземплярів Qemu
буде використовувати тільки одне ядро центрального процесора, що значно
сповільнює роботу з великими мережними топологіями.
Таким чином, в курсі лабораторного практикуму буде розглянута
робота з основними мережними технологіями в контейнері GNS3 на базі
пристроїв фірми Cisco та Mikrotik.
4
Лабораторна робота 1
ЗНАЙОМСТВО З СЕРЕДОВИЩЕМ GNS3. IP-АДРЕСАЦІЯ
1.1. Мета лабораторної роботи
Набуття практичних навичок у створенні простих топологій мереж у

середовищі GNS3 та закріплення теоретичних знань IP-адресації.
1.2. Теоретична частина
Масштабована мережа вимагає застосування такої схеми адресації, яка

допускає зростання. Проте внаслідок неконтрольованого зростання мережі
може виникнути ряд непередбачених наслідків. У міру додавання вузлів і
підмереж в мережу підприємства може виникати нестача вільних адрес і
тому буде потрібно зміну схеми існуючих адрес. Цього можна уникнути
шляхом ретельного планування масштабованої адресної системи мережі
підприємства.
На жаль, архітектори TCP/IP не могли передбачити експоненціального
зростання Інтернет, і нині гостро стоїть проблема розподілу адрес.
Коли в 80-х роках впроваджувався TCP/IP, він базувався на дворівневій
адресній схемі. Старша частина 32-бітової IP-адреси визначала номер
(адресу) мережі, а молодша – номер вузла (хоста). Адреса мережі потрібна
для взаємодії мереж. Маршрутизатори використовують мережну частину
адреси для організації зв'язку між хостами з різних мереж.
Для зручності людського сприйняття IP-адреса записується у вигляді
чотирьох десяткових чисел (для протоколу 4 версії IPv4), розділених
точками; 32-бітова адреса ділиться на чотири групи по вісім біт, званих
октетами. Кожен октет записується в десятковому вигляді і розділяється
точками. Наприклад
10101100000111101000000000010001 <-> 10101100 00011110 10000000
00010001 <-> 172 30 128 17 <-> 172.30.128.17
5
Виникає питання, як в будь-якій IP-адресі виділити адресу мережі і
адресу хоста? На початку використання TCP/IP для вирішення цього питання
використовувалася класова система адресації. IP-адреси були розбиті на п'ять
класів, що не перетиналися. Розбиття було здійснене згідно зі значеннями
декількох перших біт у першому октеті.
Якщо перший біт у першому октеті дорівнює нулю, то це адреса класу
А. Адреси класу В починаються з бінарних «10». Адреси класу С – з
бінарних «110».
У адресах класу А адреса мережі розташовується в першому октеті. У
класі В для адресації мережі використовується перший і другий октети. У
класі С для адресації мережі використовується перший, другий і третій
октети. Використання класів D і E специфічне і тут не розглядається.
У сучасних мережах класи часто ігноруються, а використовується
безкласова IP-схема, заснована на масках підмереж.
Тут і далі ми використовуватимемо маски у вигляді послідовності
бінарних одиниць, що переходить в послідовність бінарних нулів загальною
довжиною в 32 біти. Маски прийнято записувати в десятковій формі подібно
до IP-адрес
111111111111111100000000000000 <->11111111 1111111 0000000 0000000
<->255 255 0 0 <-> 255.255.0.0
Маска підмережі є необхідним доповненням до ІР-адреси. Якщо біт в
ІР-адресі відповідає одиничному біту в масці, то цей біт в ІР-адресі
представляє номер мережі, а якщо біт в ІР-адресі відповідає нульовому біту в
масці, то цей біт в ІР-адресі представляє номер хоста. Так, для маски
255.255.0.0 і адреси 172.24.100.45 номер мережі буде 172.24.0.0, а для маски
255.255.255.0 номер мережі буде 172.24.100.0.
Інша форма запису маски – /N, де N – число одиниць в масці. Ця форма
використовується тільки у поєднанні з ІР-адресою. Наприклад, для маски
255.255.0.0 і адреси 172.24.100.45 пишуть 172.24.100.45/16.
Усі адреси класу А мають маску 255.0.0.0, адреси класу В – маску
255.255.0.0, а адреси класу С – маску 255.255.255.0. Зворотне твердження
неправомірне, оскільки при визначенні класу використовуються перші біти в
першому октеті адреси.
6
Якщо число нулів в масці дорівнює М, то число доступних адрес хостів
в підмережі дорівнює 2М-2. Тобто дві адреси в підмережі для адресації не
використовуються, вони мають специфічне значення. Одна з цих адрес, у
якої останні М біт дорівнюють нулю, називається адресою підмережі, а друга
з цих адрес, у якої останні М біт дорівнюють одиниці, – широкомовною
адресою. Так, для адреси 172.24.100.45/24 адреса підмережі дорівнює
172.24.100.0, а широкомовна адреса дорівнює 172.24.100.255. Число адрес в
підмережі становить 28-2 =254.
Адреси класу А і В складають близько 75 відсотків адресного простору.
Кількість мереж класів А і В приблизно дорівнює 17000. Придбання мережі
класу В, а тим більше класу А нині неможливо. Адреси класу С складають
близько 12,5 відсотків адресного простору. Кількість мереж класу С
приблизно складає 2,1 мільйона. На жаль, мережа класу С обмежена 254
адресами, що не відповідає потребам великих організацій, які не можуть
придбати адреси класу А або В.
1.3. Практична частина
Останню версію GNS3 можна скачати з сайта http://www.gns3.net/ з

розділу Download. Для запуску GNS3 необхідно викликати виконуваний
файл gns3.exe. Загальний вигляд програми наведено побачити на рис. 1.1.
Рисунок 1.1 – Загальний вигляд програми GNS3
7
Для побудови топології треба, використовуючи метод Drag-n-Drop
(обираємо об’єкт і утримуючи ліву кнопку миші перетягуємо його в потрібне
вікно), додати необхідні елементи з розділу All Devices в праве поле
головного вікна програми (рис. 1.2).
Рисунок 1.2 – Додавання елементів мережі
При додаванні кожного елемента можна дати йому ім’я та встановити

параметри, обравши відповідні пункти меню, що з’являється при натисканні
правої кнопки миші над пристроєм.
Додавши елементи, треба їх зв’язати за допомогою з’єднувальних
зв'язків. З’єднання виконується послідовно за топологією «точка-точка». Це
можна зробити двома способами:
1) натиснути на кнопку Add а Link (остання зліва після кнопки All
Devices) та послідовно обрати вільний інтерфейс першого пристрою і
з’єднати його з вільним інтерфейсом другого пристрою;
2) натиснути праву кнопку миші на будь-якому пристрою та обрати
пункт меню Add а Link.
Але перш за все необхідно виконати налаштування пристроїв. Для
цього треба двічі натиснути мишкою або вибрати правою кнопкою
8
контекстне меню Configure на елементі РC1. Далі у вікні, що з’явиться,
необхідно перейти у закладку NIO UDP, та видалити всі рядки записів, крім
першого, у розділі NIOs (рис. 1.3).
Рисунок 1.3 – Конфігурація пристрою РС1
Так само треба виконати налаштування для пристроїв РС2, РС3 та РС4.
При цьому слід залишити тільки відповідно 2, 3 та 4 рядки у розділі NIOs.
Справа в том, що GNS3 емулює роботу з кінцевими пристроями
(хостами) за допомогою VPCS за протоколом UDP.
Тепер необхідно виконати з’єднання всіх пристроїв в топології. Для
цього слід обрати вільний інтерфейс nio_udp пристрою РС1 (він повинен
мати червоний колір) та з’єднати його з вільним інтерфейсом комутатора
SW1 (наприклад 1). Якщо все зроблено правильно, GNS3 покаже з’єднання
зеленим кольором. Дплі виконанується з’єднання пристроїв, як показано на
рис. 1.4.
9
Рисунок 1.4 – Топологія
Тепер необхідно виконати налаштування VPCS, а саме задати ІР-
адреси для кожного хоста. Для цього слід обрати пункт меню Tools\VPCS.
Утиліта VPCS має інтерфейс командного рядка. Зовнішній вигляд вікна
VPCS наведено на рис. 1.5.
Рисунок 1.5 – Зовнішній вигляд вікна VPCS
Утиліта VPCS підтримує емуляцію 9 хостів. Для переключення на

відповідний хост необхідно у командному рядку обрати відповідний номер.
За замовченням виконується налаштування 1 хоста. Після цього виконується
команда ір у командному рядку (рис. 1.6.).
10
Рисунок 1.6 – Команда ір у VPCS
Як видно з рис. 1.6, для завдання ІР-адреси необхідно виконати

команду ір з відповідними параметрами:
<address> – задає ІР-адресу у вигляді десяткових чисел, розділених
крапкою;
/<mask> – задає маску підмережі у вигляді кількості послідовних
одиниць, починаючи зі старшого розряду. Маска також може бути задана у
вигляді десяткових чисел, розділених крапкою. Наприклад, /26 та
255.255.255.192 задають ту саму маску;
<gateway> – задає ІР-адресу маршрутизатора, на який будуть
відправлятися пакети, ІР-адреса утримувача яких знаходяться не в тій
мережі, що і відповідний вузол.
Далі виконується команда show:
VPCS[1]>show
Ця команда показує налаштування всіх віртуальних хостів. Як видно з
результату виконання цієї команди, віртуальний хост VPCS1 налаштований
на ІР-адресу 0.0.0.0/0 GATEWAY=0.0.0.0, має МАС-адресу 00:50:79:66:68:00,
використовує локальний UDP порт = 20000 та віддалений хост 127.0.0.1 з
портом 30000 (рис. 1.7). Тобто VPCS1 відповідає хосту С1 в GNS3 (див.
рис. 1.3).
11
Рисунок 1.7 – Команда show в VPCS
Lля VPCS1 IP-адреса 192.168.0.2 з маскою 255.255.255.0 задається

після виконання команди
VPCS[1]>ip 192.168.0.2 255.255.255.0
Якщо все було зроблено вірно, VPCS поверне строку вводу команд
VPCS[1]>.
(!) Для переключення між хостами в VPCS використовується команда
вигляду
VPCS[1]> «номер хоста»
Наприклад,для переходу на хост № 2 КОМАНДА
VPCS[1]> 2
іншим віртуальним хостам ІР-адреси задаються згідно з табл. 1.1.
Таблиця 1.1 – ІР-адреси хостів

Хост IP-адреса Маска
PC1 192.168.0.2 255.255.255.0
PC2 192.168.0.3 255.255.255.0
PC3 192.168.0.4 255.255.255.0
PC4 192.168.0.5 255.255.255.0
Якщо все зроблено правильно, то можна пропінгувати будь-який хост з

будь-якого хоста. Команда ping використовується для перевірки
12
працездатності мережі між двома вузлами. Наприклад, необхідно зайти на
хост 4 і пропінгувати хост 1. Для цього треба виконайти команду
VPCS[4]>ping 192.168.0.2
Результат виконання цієї команди зображено на рис. 1.8.
Рисунок 1.8 – Команда ping від хоста 4 до хоста 1
У VPCS для кожної команди можна отримати довідку про параметри

команди. Для цього необхідно набрати у командному рядку відповідну
команду та після неї знак питання «?» або ж слово «help». Наприклад, для
команди ping довідка виглядає наступним чином (рис. 1.9.).
Рисунок 1.9 –Довідка про параметри команди ping
1.4. Контрольні питання
1. Для чого використовується GNS3?

2. Як виконується емуляція роботи пристроїв в GNS3?
13
3. Що являє собою ІР-адреса (IPv4)?
4. Для чого використовується маска?
5. Які класи ІР-адрес існують і як їх розрізнити?
6. Як отримати ІР-адресу мережі та хоста (показати на прикладі)?
7. Як задати ІР-адресу у VPCS?
8. Як встановити відповідність між хостами у GNS3 та VPCS?
9. Для чого використовується команда ping?
10. Для чого використовується параметр –t команди ping?
1.5. Порядок виконання і здачі роботи
– Вивчити теоретичну і практичну частини.

– Здати викладачеві теорію роботи, відповівши на контрольні питання.
– Виконати практичну частину.
– Отримати свій варіант (1 – 12) і виконати завдання для самостійної
роботи.
– Подати викладачеві результат виконання завдання для самостійної
роботи. Продемонструвати йому, що будь-який комп’ютер пінгується з будь-
якого комп’ютера (на вибір викладача).
– Оформити звіт.
– Захистити звіт.
1.6. Завдання для самостійної роботи
1. Створити топологію (рис. 1.10)
Рисунок 1.10 – Топологія для самостійного завдання
14
2. Призначити хостам ІР-адреси згідно з одержаним варіантом (v = 1 –
12). ІР-адреси для хостів, що наведені на рис. 1.10, подані в табл. 1.2.
Таблиця 1.2 – Варіанти завдань

Хост IP-адреса Маска
PC1 v.n.m.1 255.255.255.0
PC2 v.n.m.2 255.255.255.0
PC3 v.n.m.3 255.255.255.0
PC4 v.n.m.4 255.255.255.0
PC5 v.n.m.5 255.255.255.0
PC6 v.n.m.6 255.255.255.0
PC7 v.n.m.7 255.255.255.0
PC8 v.n.m.8 255.255.255.0
тут n – день народження студента; m – місяць народження студента.

Наприклад, якщо студент народився 1 січня то для варіанту 8 (v=8) ІР-адреса
хоста PC1 буде 8.1.1.1.
3. Призначити хостам різні імена.
4. Виконати команду ping з параметрами на вибір студента (не менше
ніж 3 будь-яких параметри: /t, /n та інш.).
1.7. Зміст звіту
Звіт готується в електронному вигляді і роздруковується. Звіт містить:

1. Виконану практичну частину лабораторної роботи із скріншотами.
2. Виконану самостійну частину лабораторної роботи із скріншотами.
3. Конфігурації кожного хоста у вигляді скріншота.
4. Скріншот виконання команди ping (не меньше ніж з трьома різними
параметрами) згідно з обраним варіантом.
15
ОЗНАЙОМЛЕННЯ З МЕРЕЖНОЮ ОПЕРАЦІЙНОЮ СИСТЕМОЮ IOS

КОМПАНІЇ CISCO
Набуття практичних навичок у конфігуруванні мережних пристроїв, що

працюють під керуванням операційної системи IOS компанії Cisco.
При першому вході в мережний пристрій користувач бачить командний

рядок призначеного для користувача режиму вигляду
Router>
Команди, доступні на користувацькому рівні, є підмножиною команд,
доступних в привілейованому режимі. Ці команди дозволяють виводити на
екран інформацію без зміни установок мережного пристрою.
Щоб дістати доступ до повного набору команд, необхідно спочатку
активізувати привілейований режим:
Press ENTER tostart.
Router>
Router>enable
Router#
Router#disable
Router>
Тут і далі виведення мережного пристрою даватиметься звичайним
шрифтом, а введення користувача жирним шрифтом.
Про перехід в цей режим свідчитиме поява в командному рядку
запрошення у вигляді знака #. З привілейованого рівня можна отримати
інформацію про налаштування системи і дістати доступ до режиму
глобальної конфігурації та до інших спеціальних режимів конфігурації,
включаючи режими конфігурації інтерфейсу, підінтерфейсу, лінії, мережного
пристрою, карти маршрутів і таке інше. Для виходу з системи IOS необхідно
набрати на клавіатурі команду exit (вихід):
Router>exit
16
Незалежно від того, як звертаються до мережного пристрою – через
консоль термінальної програми, приєднаної через нуль-модем до
COM- порту мережного пристрою, або у рамках сеансу протоколу Telnet –
цей пристрій можна перевести в один з таких режимів:
• Призначений для користувача – це режим перегляду, в якому
користувач може тільки переглядати певну інформацію про мережний
пристрій, але не може нічого змінювати. У цьому режимі запрошення має
вигляд типу Router>.
• Привілейований – підтримує команди налаштування і тестування,
детальну перевірку мережного пристрою, маніпуляцію з конфігураційними
файлами і доступ в режим конфігурації. У цьому режимі запрошення має
вигляд типу Router#.
• Режим глобальної конфігурації – реалізує потужні однорядкові
команди, які вирішують завдання конфігурації. У цьому режимі запрошення
має вигляд типу Router(config) #.
Команди в будь-якому режимі IOS розпізнає по перших унікальних
символах. При натисненні клавіши «TAB» IOS сам доповнить команду до
повного імені.
При введенні в командному рядку будь-якого режиму імені команди і
знака питання «?» на екран виводяться коментарі до команди. При введенні
одного знака «?» результатом буде список усіх команд режиму. На екран
може виводитися багато екранів рядків команд, тому іноді внизу екрану
з’являтиметься підказка – «More –». Для продовження слід натиснути «Enter»
або пробіл.
Команди режиму глобальної конфігурації визначають поведінку
системи в цілому. Окрім того, команди режиму глобальної конфігурації
включають команди переходу в інші режими конфігурації, які
використовуються для створення конфігурацій, що вимагають
багаторядкових команд. Для входу в режим глобальної конфігурації
використовується команда привілейованого режиму configure. При введенні
цієї команди слід вказати джерело команд конфігурації: terminal (термінал),
memory (незалежна пам’ять або файл), network (сервер tftp (Trivialftp-
17
зпрощений ftp) в мережі). За умовчанням команди вводяться з терміналу
консолі.
Наприклад:
Router#configure terminal
Router(config)#(commands)
Router(config)#exit
Router#
Команди для активізації приватного виду конфігурації повинні
передувати командами глобальної конфігурації. Так, для конфігурації
інтерфейсу, на можливість якої вказує запрошення Router(config-if)#,
спочатку вводиться глобальна команда для визначення типу інтерфейсу і
номера його порту :
Router#conf t
Router(config)#interface type port
Router(config-if)#(commands)
Router(config-if)#exit
Router(config)#exit
Для обмеження доступу до системи використовуються паролі. Команда
lineconsole встановлює пароль на вхід на термінал консолі:
Router(config)#lineconsole 0
Router(config-line)#login
Router(config-line)#password cisco
Команда linevty 0 4 встановлює парольний захист на вхід по протоколу
Telnet:
Router(config)#linevty 0 4
Router(config-line)#login
Router(config-line)#password сisco
Команда enable password обмежує доступ до привілейованого режиму:
Router#conf t
Router(config)#enable password пароль
Далі
Ctrl-Z
Router#ex
…
Press RETURN to get started.
Router>en
Password: пароль
Router#
Тут «пароль» – послідовність латинських символів.
18
Для встановлення на мережному інтерфейсі IP-адреси
використовується команда
Router(config-if)#ip address [ip-address] [subnet-mask]
Важливо мати можливість контролю правильності функціонування та
стану мережного пристрою в будь-який момент часу. Для цього служать
певні команди (табл. 2.1).
Таблиця 2.1 – Show-команди

Команда Опис
Виводить на екран дані про конфігурацію апаратної
show version частини системи, версію програмного забезпечення,
імена і джерела конфігураційних файлів і
завантажені образи
show running-config Показує зміст активної конфігурації
show interfaces Показує дані про усі інтерфейси на пристрої
show protocols Виводить дані про протоколи третього мережного
рівня
Cisco Discovery Protocol (CDP)
CDP дозволяє пристроям обмінюватися основною конфігураційною

інформацією. CDP працюватиме без налаштування будь-якого протоколу. За
замовчанням CDP включений на усіх інтерфейсах. CDP працює на другому
(канальному) рівні моделі OSI. Тому CDP не є протоколом, що
маршрутизується, і працює тільки з безпосередньо підключеними
пристроями. Протокол CDP зв’язує фізичне середовище передачі даних
нижчого рівня з протоколами вищого мережного рівня. Тому пристрої, які
підтримують різні протоколи третього рівня, можуть дізнаватися один про
одного.
При запуску пристрою протокол CDP запускається автоматично. Після
цього він може автоматично визначити сусідні пристрої, на яких також
виконується протокол CDP. Серед знайдених пристроїв будуть не лише ті,
які працюють з протоколом IP.
CDP дозволяє адміністраторам мати доступ до даних про інший
мережний пристрій, до якого є безпосереднє з’єднання.
19
Для виводу інформації про сусідні пристрої, виявлені по протоколу
CDP, використовується сімейство команд show cdp. Вони виводять наступні
дані по кожному порту і по кожному приєднаному до нього пристрою:
ідентифікатори пристроїв, список адрес, ідентифікатор порту, перелік
функціональних можливостей, апаратна платформа пристроїв.
Команди ping і traceroute
Для діагностики можливості встановлення зв’язку в мережах

використовуються протоколи типу запит-відповідь або протокол ехо-пакетів.
Результати роботи такого протоколу можуть допомогти в оцінці надійності
шляху до іншого пристрою, величин затримок в цілому і між проміжними
пристроями. Для того щоб така команда працювала, необхідно, щоб не лише
локальний мережний пристрій знав, як потрапити в пункт призначення, але і
щоб пристрій в пункті призначення знав, як дістатися до джерела.
Команда ping посилає ICMP (Internet Control Message Protocol) ехо-
пакети для верифікації з’єднання (табл. 2.2). У наведеному нижче прикладі
час проходження одного ехо-пакета перевищив задане, про що свідчить точка
«.» у виведеній інформації, а чотири пакети пройшли успішно, про що
говорить знак оклику «!»:
Router>ping 172.16.101.1
Type escape sequence to abort.
Sending 5 100-byte ICMP echoes to 172.16.10.1 timeout is 2 seconds:
.!!!!
Success rate is 80 percent, round-trip min/avg/max = 6/6/6ms
Таблиця 2.2 – Результати команди ping

Символ Значення
! Успішний прийом ехо-відповіді
. Перевищено час очікування
U Пункт призначення недосяжний
C Перевантаження мережі
I Виконання команди перервано адміністратором
? Невідомий тип пакета
& Пакет перевищів значення параметра часу життя ТТL пакета
20
Команда traceroute показує адреси проміжних інтерфейсів (хопів) на
шляху пакетів в пункт призначення:
Router>traceroute 172.16.101.1
Розширена версія команди ping підтримується тільки в
привілейованому режимі. Для того щоб увійти до розширеного режиму,
необхідно в рядку підказки Extended commands ввести букву «y» (Yes).
Команда в режимі діалогу опитує значення параметрів. Важливо
відмітити, що ця команда дозволяє, знаходячись на одному пристрої,
перевіряти зв’язок між мережними інтерфейсами на інших пристроях:
Router#ping
Protocol [ip]:
Target IP address:2.2.2.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:y (вхід в розширений режим)
Source address:1.1.1.1 (адрес з якого йде ping)
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data [no]:
Data pattern [OxABCD]:
Loose, Strict, Record, Timestamp, Verbose [none]:
Sweep range of sizes [n]:
Параметри в квадратних скобках є параметрами за замовчуванням.
Якщо влаштовує такий параметр – то необхідно лише підтвердити команду,
натиснувши «Еnter»; вводити текст в скобках не потрібно.
Команда telnet
Протокол віртуального терміналу telnet, що входить до складу

протоколів TCP/IP, дозволяє встановити з’єднання між мережним пристроєм
telnet-клієнта і мережним пристроєм telnet-сервера, що забезпечує
можливість роботи в режимі віртуального терміналу. Telnet
використовується для віддаленого управління мережним пристроєм або для
перевірки зв’язку на рівні додатків. Успішне застосування Telnet-з’єднання
дозволяє управляти віддаленим пристроєм так, як ніби ви знаходитеся за
21
його консоллю. Мережні пристрої Cisco здатні підтримувати одночасно до
п’яти вхідних сеансів протоколу Telnet.
Налаштування GNS3
Для поточного користувача GNS3 створює свій каталог, куди будуть

розміщуватися всі файли при роботі з GNS3. Скопіюйте у каталог
%CurrentUser%\GNS\Images\ файл, що містить образ операційної системи
IOS. Оберіть пункт меню Edit\IOS images and hypervisors або натисніть
комбінацію Ctrl+Shift+I. Оберіть файл з образом операційної системи,
платформу та модель в розділі Settings, а потім натисніть кнопку Save
(рис. 2.1).
Рисунок 2.1 – Налаштування образу операційної системи IOS
Якщо все зроблено вірно, в списку роутерів повинен з’явитися Router

c3600. Додайте створений роутер та натисніть кнопку Start/Resume all devices
. Натисніть на роутері праву кнопку миші та оберіть пункт Idle PC. GNS3
розрахує найбільш прийнятне значення Idle PC для даного пристрою.
Натисніть на кнопку Stop all devices .
Додайте ще 2 роутери с3600. Назвіть пристрої так, як ви бачите на
рис. 2.2.
22
Рисунок 2.2 – Топологія мережі
Сконфігуруйте роутери. Для цього для кожного роутера послідовно

оберіть наступні адаптери в розділі Slots:
Роутер Адаптери
Router1 slot0 = NM-1E
Router2 slot0 = NM-1E; slot1 = NM-4T
Router3 slot0 = NM-4T
NM-1E – 1 Ethernet порт (інтерфейс);

NM-4Т – 4 Serial порта (інтерфейса).
Оберіть пункт меню View\Show/Hide interface labels та виконайте

з’єднання роутерів, як показано на рис. 2.2. Чорна пряма лінія означає
Ethernet-з’єднання. Червона ламана означає послідовне з’єднання.
Робота з мережним пристроєм Cisco

Запустіть поточну топологію, натиснувши на кнопку Start/Resume all
devices. Червоні точки з’єднання повинні стати зеленими.
1. Оберіть Routerl, натиснувши на ньому двічі лівою кнопкою миші або
обравши з меню, що з’являється при натисканні правої кнопки миші над
пристроєм, пункт Console. Ви побачите таке:
23
Тепер ви підключені до мережного пристрою і знаходитеся в
командному рядку в даному випадку в привілейованому режимі. Тут
«Router1» – це ім’я мережного пристрою, а «#» означає, що ви знаходитеся в
привілейованому режимі.
2. Увійдіть команду disable, щоб потрапити в режим користувача:
Router#disable
Router>
3. Щоб повернутися в привілейований режим, просто надрукуйте
enable. З режиму користувача введіть logout або exit, щоб покинути
мережний пристрій:
Router#disable
Router>exit
Router1 con0 is now available
Press RETURN to get started.
Основні команди мережного пристрою
1. Увійдіть на мережному пристрої Router1 в режим користувача:

Router1>
2. Щоб побачити список усіх доступних команд в цьому режимі,
введіть команду, яка використовується для перегляду усіх доступних команд:
Router1>?
Клавішу Enter натискати не потрібно.
3. Тепер увійдіть у привілейований режим
Router1>enable
Router1#
4. Продивіться список доступних команд в привілейованому режимі:
Router1#?
5. Перейдіть в режим конфігурації
Router#configure terminal
Enter configuration commands, one per line. End with
CNTL/Z.
Router(config)#
6. Ім’я хоста мережного пристрою використовується для локальної
ідентифікації. Коли ви входите в мережний пристрій, ви бачите ім’я хоста
перед символом режиму («>» чи «#»). Це ім’я може бути використане для
24
визначення місця знаходження. Встановіть «Rl» як ім’я вашого мережного
пристрою:
Router(config)#hostname R1
R1(config)#
7. Пароль доступу дозволяє вам контролювати доступ в
привілейований режим. Це дуже важливий пароль, тому що в
привілейованому режимі можна вносити конфігураційні зміни. Встановіть
пароль доступу «cisco»:
R1(config)#enable password cisco
8. Давайте випробуємо цей пароль. Вийдіть з мережного пристрою і
спробуйте зайти в привілейований режим.
R1>en
Password:*****
R1#
Тут знаки ***** – це ваш ввід пароля. Ці знаки на екрані невидимі.
Основні Show-команди
Перейдіть в призначений для користувача режим командою disable.

Введіть команду для перегляду усіх доступних show-команд.
R1>show ?
1. Команда show version використовується для отримання типу
платформи мережного пристрою, версії операційної системи, імені файлу
образу операційної системи, часу роботи системи, обсягу пам’яті, кількості
інтерфейсів і конфігураційного регістра.
2. Можна побачити годинник
R1>show clock
3. У флеш-пам’яті мережного пристрою зберігається файл-образ
операційної системи Cisco IOS. На відміну від оперативної пам’яті, в
реальних пристроях флеш-пам’ять зберігає файл-образ навіть при збою
живлення:
R1>show flash
4. Командний інтерпретатор мережного пристрою за замовчуванням
зберігає 10 останніх введених команд
R1>show history
25
5. Дві команди дозволять вам повернутися до команд, введених раніше.
Натисніть на стрілку вгору або на <ctrl>+р.
6. Дві команди дозволять вам перейти до наступної команди,
збереженої в буфері. Натисніть на стрілку вниз або на <ctrl>+n.
7. Можна побачити список хостів і IP-адреси усіх їх інтерфейсів
R1>show hosts
8. Наступна команда виведе детальну інформацію про кожен інтерфейс
R1>show interfaces
9. Команда
R1>show sessions
виведе інформацію про кожну telnet-сесію.
10. Команда
R1>show terminal
показує конфігураційні параметри терміналу.
11. Можна побачити список усіх користувачів, приєднаних до
пристрою по термінальних лініях,
R1>show users
12. Команда
R1>show controllers
показує стан контролерів інтерфейсів.
13. Перейдіть в привілейований режим.
R1>en
14. Введіть команду для перегляду усіх доступних show-команд.
R1#show ?
Привілейований режим включає усі show-команди призначеного для
користувача режиму і ряд нових.
15. Подивіться активну конфігурацію в пам’яті мережного пристрою.
Потрібний привілейований режим. Активна конфігурація автоматично
зберігається і буде втрачена у разі збою електроживлення:
R1#show running-config
У рядку --More-- натисніть на клавішу enter для перегляду наступної
сторінки інформації.
16. Наступна команда дозволить вам побачити поточний стан
протоколів третього рівня
R1#show protocols
26
Введення в конфігурацію інтерфейсів
Постараємося зрозуміти, як включати (піднімати) інтерфейси

мережного пристрою і що потрібно, щоб перевести інтерфейс в стан UP.
1. На мережному пристрої R1 увійдіть до режиму конфігурації
R1#conf t
R1(config)#
2. Тепер необхідно настроїти Ethernet-інтерфейс. Для цього зайдіть в
режим конфігурації інтерфейсу:
R1(config)#interface ethernet 0/0
R1(config-if)#
3. Подивіться всі доступні в цьому режимі команди
R1(config-if)#?
Для виходу в режим глобальної конфігурації наберіть exit. Знову
увійдіть до режиму конфігурації інтерфейсу
R1(config)#interface e0/0
Тут використовували скорочене ім’я інтерфейсу.
4. Для кожної команди можна виконати протилежну команду,
поставивши перед нею слово no. Так команда
R1(config-if)#no shutdown
включає цей інтерфейс:
R1(config-if)#
00:36:34: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
00:36:35: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Ethernet0/0, changed state to up
5. Додайте до інтерфейсу опис
R1(config-if)#description Ethernet interface on Router 1
Щоб побачити опис цього інтерфейсу, перейдіть в привілейований
режим і виконаєте команду show interface.
R1(config-if)#end
R1#show interface
6. Тепер приєднайтеся до мережного пристрою Router2 і поміняйте ім’я
його хоста на R2:
R2#conf t
R2(config)#hostname R2
Увійдіть на інтерфейс Ethernet 0/0.
R2(config)#int e0/0
27
Ввімкніть інтерфейс.
R2(config-if)#no shutdown
Тепер, коли інтерфейси на двох кінцях Ethernet-з’єднання ввімкнені, на
екрані з’явиться повідомлення про зміну стану інтерфейсу на активний.
7. Перейдіть до конфігурації послідовних інтерфейсів. Зайдіть на R2.
R2#conf t
R2(config)#int s1/0
R2(config-if)#clock rate ?
Оберіть частоту 64000:
R2(config-if)#clock rate 64000
та підійміть інтерфейс
Router1(config-if)#no shut
7. Перейдіть до маршрутизатора Router3 и змініть йому так саме ім’я на
R3. Підійміть на ньому інтерфейс Serial0/0. Тепер, коли інтерфейси на обох
кінцях послідовного з’єднання включені, на екрані з’явиться повідомлення
про зміну стану інтерфейсу на активне.
8. Перевірте на кожному пристрої, що конфігуровані нами інтерфейси
знаходяться в стані UP:
R1#sh int e0/0
R2#sh int e0/0
R2#sh int s1/0
R3#sh int s0/0
CDP
1. На маршрутизаторі R2 введіть команду для виведення стану усіх

інтерфейсів, на яких працює CDP:
R2#show cdp interface
Ви повинні побачити, що обидва інтерфейси піднято і що вони
посилають CDP-пакети.
2. Переконавшись, що мережний пристрій посилає і приймає CDP-
оновлення, можна використовувати CDP для отримання інформації про
безпосередньо підключені пристрої. Введіть команду
R2#show cdp neighbors
28
Можнп побачити, що маршрутизатор R2 сполучений з інтерфейсом
Ser 0/0 (Port ID) маршрутизатора R (Capability) R3 (Device ID) серії 3640
(Platform) через інтерфейс Ser 1/0 (Local Intrfce) і з інтерфейсом Eth 0/0
маршрутизатора R1 серії 3640 через інтерфейс Eth 0/0.
3. На R2 введіть команду для детальнішої інформації про сусідів
R2#show cdp neighbors detail
Ця команда показує по одному пристрою за раз. Вона використовується
для відображення адресної інформації мережного рівня. На даний момент
цей рівень не налагоджений, тому поле Entry address(es) порожнє. Команда
також виводить інформацію про версію IOS.
4. На R2 введіть команду, щоб дізнатися інформацію про пристрій
Router3:
R2#show cdp entry R3
Ця команда дає ту ж інформацію, як і show cdp neighbor detail, але для
одного конкретного пристрою. Пам’ятайте, що імена хостів чутливі до
регістра.
5. На пристрої R2 введіть команду, щоб побачити, як часто R2 посилає
сусідам оновлення CDP і як довго у сусідів вони повинні зберігатися:
R2#show cdp
6. На пристрої R2 введіть команди для установки часу оновлення CDP

45 секунд і для установлення збереження CDP 60 секунд:
R2(config)#cdp timer 45
R2(config)#cdp holdtime 60
R2(config)#(Ctrl + Z)
R2#show cdp
Для економії смуги пропускання низькошвидкісних пристроїв
CDP-дані можна відключити:
R2(config)#no cdp run
29
і знову включити для усього пристрою:
R2(config)#cdp run
7. Іноді необхідно відключити CDP для певного інтерфейсу, наприклад,
при його вузькій смузі пропускання або з метою безпеки. На пристрої R2
відключіть CDP на інтерфейсі Ethernet0/0.
R2(config)#interface Ethernet 0/0
R2(config-if)#no cdp enable
R2(config)#(Ctrl+Z)
R2#show cdp interface
У отриманому вікні ми не побачими відомостей про Ethernet 0/0.
Налаштування IP-адрес інтерфейсів
1. Підключіться до пристрою R2 і встановіть IP-адресу Ethernet-

інтерфейсу (Не забудьте перед налаштуванням включити інтерфейс
командою no shutdown):
R2(config)#interface ethernet 0/0
R2(config-if)#ip address 10.1.1.1 255.255.255.0
2. Тепер призначте інтерфейсу S1/0 IP-адресу 172.17.72.1 255.255.255.0,
не виходячи з конфігурації інтерфейсу:
R2(config-if)#int s1/0
R2(config-if)#ip ad 172.17.72.1 255.255.255.0
Відмітимо, що на послідовне з’єднання точка-точка завжди виділяється
ціла підмережа.
3. Перемкніться до пристрою R1 і призначте інтерфейсу Ethernet 0/0 IP-
адресу 10.1.1.2 255.255.255.0:
R1(config)#interface Ethernet 0/0
4. Підключіться до пристрою R3 і встановіть IP-адресу
Serial-інтерфейсу Serial 0/0:
R3(config-if)#int s0/0
5. На кожному пристрої подивиться активну конфігурацію і
переконаєтеся, що там з’явилися призначені IP адреси:
30
6. Подивіться детальну IP-інформацію про кожен інтерфейс і
переконайтеся, що відконфігуровані інтерфейси перейшли в стан UP:
R1#show ip interface
7. Коротку інформацію можна отримати командою show ip interface
brief, наприклад:
R2#show ip in bri
8. Підключіться до пристрою R2. Тепер можна успішно пропінгувати

безпосередньо приєднаний Ethernet 0/0 інтерфейс на пристрої R1:
R2#ping 10.1.1.2
Спробуйте пропінгувати інтерфейс Serial0/0 на пристрої R3:

R2#ping 172.17.72.2
Успішно.
9. Поверніться на R1. З нього можна успішно пропінгувати адресу
10.1.1.1 безпосередньо приєднаного інтерфейсу Ethernet 0/0 на пристрої R2. З
R3 можна успішно пропінгувати адресу 172.17.72.1 безпосередньо
приєднаного інтерфейсу Serial 1/0 на пристрої R2. Спробуйте пропінгувати
інтерфейс Ethernet 0/0 на пристрої R2:
R3#ping 10.1.1.1
Невдача. Спробуйте пропінгувати адресу 10.1.1.2 інтерфейсу

Ethernet 0/0 на пристрої R1. Невдача.
31
10. Поверніться на R1. Спробуйте пропінгувати адресу 172.17.72.1
інтерфейсу Serial1/0 на пристрої R2. Невдача. Спробуйте пропінгувати
адресу 172.17.72.2 інтерфейсу Serial 0/0 на пристрої R3. Невдача.
Невдачі виникли тому, що на маршрутизаторах не налаштована
маршрутизація.
11. Зайдіть на пристрій R2. Визначите шляхи проходження пакетів на
Router2
R2#traceroute 10.1.1.2
і R3
R2#traceroute 172.17.72.2
Можна побачити по одному хопу.
12. Виконайте команду розширеного пінгу від адреси 10.1.1.2 до адреси
172.17.72.2:
R2#ping
…
Target IP address: 172.17.72.2
…
Extended commands [n]: y
Source address or interface: 10.1.1.1
Telnet
1. Увійдіть на пристрій R2. Необхідно, щоб мережний пристрій

приймав telnet-сесії і був захищений паролем. Кожна так звана лінія в
мережному пристрої потенційно є активною telnet-сесію, яку пристрій може
підтримувати. Наші мережні пристрої підтримують до 5 ліній, що призначені
на віртуальні термінали vty. Ми використовуємо усі 5 ліній:
R2(config)#line vty 0 4
R2(config-line)#
2. Тепер повідомте мережному пристрою, що знадобиться пароль входу
в систему:
R2(config-line)#password cisco
R2(config-line)#login
3. Увійдіть на пристрій R1 і встановіть telnet-з’єднання з пристроєм R2.
Для цього ми використовуємо IP-адресу його інтерфейсу Ethernet 1/0
R1#telnet 10.1.1.1
32
4. Можна побачити прохання ввести пароль. Введіть пароль cisco і
натисніть <enter>. При цьму ім’я мережного пристрою поміняється на «R2»,
тому, що було встановлено telnet-з’єднання з R2. Команда
R2>show user
покаже, що з’єднання здійснене від адреси 10.1.1.2 пристрою R1.

5. Тепер на секунду натисніть одночасно клавіші Ctrl+Shift+6, потім
відпустіть і відразу натисніть клавішу x. Ім’я мережного пристрою зміниться
назад на «R1». Тепер ми знову на пристрої R1:
R2><Control> + <Shift> + <6> потім <x>
R1#
6. Введіть команду show sessions. Це дозволить побачити усі активні
telnet-сесії. Щоб відновити telnet-сесію, визначите номер сесії, яку ви хочете
відновити (у нашому випадку є тільки одна з номером 1) і введіть команду
resume 1:
R1#show sessions
R1#resume 1
R2#
7. Тепер ім’я хоста знову помінялося на R2. Натисніть комбінацію
Ctrl+Shift+6 і клавішу x, щоб повернутися назад на R1.
8. Закрийте сесію
R1#disconnect 1
(!) Важливо. Зберігання проекту та конфігурацій пристроїв

Для зберігання проекту в цілому і конфігурацію кожного пристрою
зокрема оберіть пункт меню File\Save Project As… та у вікні, що з’явиться,
обов’язково виберіть пункт «Save nvrams and …» (рис. 2.3).
33
Рисунок 2.3 – Зберігання проекту
Після цього на кожному пристрої виконайте команду в

привілейованому режимі
R1#copy running-config startup-config
Всі параметри команди залиште за замовчуванням. Лише підтвердіть іх
натисканням enter.
Після цього натисніть кнопку Save project або натисніть Ctrl+S. Тепер
можна подивитися стартову конфігурацію пристрою шляхом обрання пункту
меню Startup-config, що з’являється при натисканні правої кнопки миші над
пристроєм.
1. Які є режими введення команд в командному рядку?

2. Як перемикатися між режимами введення команд в командному
рядку?
3. Яку роль відіграє клавіша табуляції при введенні команд?
4. Як увійти до режимів глобальної конфігурації, активізувати
приватний вигляд конфігурації і вийти з цих режимів?
5. Як орієнтуватися в раніше введених командах і повторювати їх?
6. Що таке CDP, для чого він служить і як їм користуватися?
7. Яку інформацію повертає команда ping?
8. Для чого служить команда traceroute?
9. Для чого служить команда протокол telnet?
10. Як задати ім’я хоста?
34
11. Яку інформацію можна подивитися командами show в
призначеному для користувача режимі?
12. Яку інформацію можна подивитися командами show в
привілейованому режимі, але не можна подивитися в призначеному для
користувача режимі?
13. Як підняти інтерфейс і визначити його стан?
14. Як призначити IP-адресу на інтерфейс і переконатися, що вона
призначена?
15. Чому можуть не проходити пінги між пристроями?
16. Як припинити і відновити telnet-сесію. Як закрити telnet-з’єднання?
1. Вивчити теоретичну і практичну частини.

2. Здати викладачеві теорію роботи, відповівши на контрольні питання.
3. Виконати в GNS3 практичну частину.
4. Виконати в GNS3 завдання для самостійної роботи
5. Подати викладачеві результат виконання завдання для самостійної
роботи. Продемонструвати йому, що вузли пінгуються згідно з табл. 2.6.
6. Продемонструвати роботу telnet.
7. Оформити звіт (зміст звіту див. нижче).
Варіанти обираються за номером по списку у журналі групи.

1. Зберіть топологію рис. 2.4.
Рисунок 2.4 – Топологія для виконання самостійної роботи
35
Тип зв’язків між вузлами мережі оберіть відповідно з варіантом, наданим
у табл. 2.3
Таблиця 2.3 – Варіанти з’єднання мережних пристроїв

Варіант і13-і31 і12-і21 і23-і32
1, 9 Ethernet Ehernet Ethernet
2, 10 Ethernet Ehernet Serial
3, 11 Ethernet Serial Ethernet
4, 12 Ethernet Serial Serial
5, 13 Serial Ehernet Ethernet
6, 14 Serial Ehernet Serial
7, 15 Serial Serial Ethernet
8, 16 Serial Serial Serial
Настройте відповідні пристрої (оберіть необхідні адаптери у

настройках пристроїв) і створіть топологію, зображену на рис. 2.4. Самі
призначте пристроям імена. Підніміть на кожному пристрої потрібні
інтерфейси. Перевірте їх стани. На кожному пристрої, використовуючи
команди CDP show cdp neighbors, отримайте інформацію про сусідні
пристрої. Збережіть скріншоти команд CDP.
2. Призначте інтерфейсам адреси згідно з варіантом (v=1–16) з
табл. 2.4. Усі маски дорівнюють 255.255.255.0.
Таблиця 2.4 – IP-адреси для самостійної роботи

Варіант i13, i31 i12, i21 i23, i32
1–16 v.d.m.1, v.d.m.2 v.d.m+1.1, v.d+100.m.1,v.d+1
v.d.m+1.2 00.m.2
тут n – день студента; m – місяць народження студента.
Наприклад, якщо студент народився 1 січня то для варіанта 1 (v=1)
маємо адреси з табл. 2.5.
36
Таблиця 2.5 – Приклад визначення адрес
Пристрій Інтерфейс Адреса
R1 i13 1.1.1.1
R1 i12 1.1.2.1
R2 i21 1.1.2.2
R2 i23 1.101.1.1
R3 i31 1.1.1.2
R3 i32 1.101.1.2
3. Перевірте, що адреси призначені. На кожному пристрої виконайте

команду show ip interface brief . Збережіть скріншоти.
4. Якщо зроблено усе правильно, ви зможете пропінгувати з будь-якого
роутера певні (але не усі) адреси інтерфейсів інших роутерів. Зробіть це.
Збережіть скріншоти для пінгів з’єднань, відмічених у табл. 2.6 знаком *.
Таблиця 2.6 – Варіанти виконання команди ping.

З\На il2 i13 i21 i23 i31 i32
Rl Так Так* Так Ні* Так Ні
R2 Так Ні* Так Так Ні Так*
R3 Ні* Так Ні Так Так* Так
5. Виконайте на R1 розширений пінг. Збережіть 3 скріншоти для пінгів:
від i12 до i21, від i13 до i31 і від i12 до i31.
6. Налаштуйте на R1 Telnet. Задайте пароль.
7. Зайдіть по Telnet з R2 на R1. Виконайте команду show user.
Припиніть сесію. Відновіть сесію. Закрийте сесію. Збережіть скріншот
консолі R2.

1. Усі пункти практичної роботи зі скріншотами.
2. Скріншот топології з рис. 2.3.
3. Усі скріншоти, вказані в завданні для самостійної роботи.
4. Конфігурації трьох маршрутизаторів після їх налаштування при
виконанні самостійної роботи (приберіть порожні рядки і зайві коментарі).
37
ОЗНАЙОМЛЕННЯ З МЕРЕЖНОЮ ОПЕРАЦІЙНОЮ СИСТЕМОЮ

ROUTEROS ФІРМИ MIKROTIK
Набуття практичних навичок у конфігуруванні мережних пристроїв, що

працюють під керуванням операційної системи RouterOS фірми Mikrotik.
Після встановлення програмного забезпечення RouterOS або

включення маршрутизатора вперше існують різні способи, як підключитися
до нього :
1. Доступ через інтерфейс командного рядка (Command Line Interface –
CLI) через Telnet, SSH, послідовний кабель або навіть клавіатуру і монітор,
якщо маршрутизатор має VGA-карту;
2. Доступ через веб-інтерфейс управління (WebFig);
3. Використаня утиліти конфігурування WinBox.
На кожному маршрутизаторі на заводі попередньо налаштовано IP-

адресу 192.168.88.1/24 на порту ether1. За замовчуванням ім’я користувача
встановлено на admin з порожнім паролем.
CLI
Інтерфейс командного рядка дозволяє конфігурувати налаштування

маршрутизатора за допомогою текстових команд. Оскільки існує багато
доступних команд, вони розбиті на групи та організовані у вигляді
ієрархічного меню. В консолі CLI є можливість отримати керівництво по
синтаксису і командам. Є кілька способів отримати доступ до CLI:
1. Winbox-термінал;
2. Telnet;
3. SSH;
4. послідовний кабель і т. д.
38
Кожну команду можна виконати, задавши повний шлях до неї у
командному рядку. Для цього перед командою ставиться знак «/».
Наприклад: /ip route print. Замість набору кожного разу шляху ip route для
виконання команди в цьому меню можна просто перейти в це меню.
Наприклад
[admin@MikroTik] >ip route
[admin@MikroTik] ip route>print
Для переходу на одну команду вверх необхідно виконати «..». Для
переходу у корінь необхідно виконати «/».
Також можна використовувати «/» та «..» для виконання команд з
другого рівня меню без зміни поточного рівня.
Списки та назви елементів
Багаторівневі команди оперують масивами списків: interfaces, routes,

users та інш. Деякі масиви відображаються як списки, що переглядаються. Всі
елементи списку мають порядковий номер згідно з їх значенням. При зміні
параметра елемента необхідно вказувати його номер для прийняття команди.
У деяких списках містяться елементи, яким присвоєні специфічні
імена. Наприклад, рівні interface або user. Працюючи з такими елементами, є
можливість використовувати назви замість порядкового номера. Ви не
можете використовувати команду print для отримання доступу до елемента
за ім’ям. На відміну від номерів, назви не призначаються консоллю, але вони
є однією з властивостей пункту. Таким чином, вони можуть змінюватися
самостійно. Однак є ймовірність того, що в один момент часу кілька
користувачів змінять один той самий параметр. Головне те, що іменовані
списки більш стійкі, ніж нумеровані, а також більш інформативні. Отже
краще віддати перевагу іменованим спискам, ніж нумерованим при
написанні сценаріїв.
Швидкий набір
Існує дві консольні особливості, що допомагають при уведенні команд

набагато швидше й спрощують за допомогою [Tab] набір ключових фраз.
Завершення виконання команд подібне до bash shell в UNIX. Якщо ви
натиснете клавішу [Tab] після набору частини команди, консоль спробує
39
знайти команду, що починається із частини набраного слова. Якщо знайдено
тільки один збіг, то частина команди, що залишилася, буде автоматично
додана:
[admin@MikroTik] > /inte[Tab] /interface _
Якщо знайдено більше одного збігу та всі вони починаються з набраної
частини, то буде виведена максимально можлива довжина, потім слово
відрізається й нічого не додається у кінець:
[admin@MikroTik] > /interface set e[Tab]/interface set
ether_
Якщо ви набрали тільки основну частину й один раз натиснули клавішу
[Tab], це не буде мати ефекту. Однак, натиснувши [Tab] другий раз, вам
будуть відображені усі можливі варіанти:
[admin@MikroTik] > interface set e[Tab]_
[admin@MikroTik] > interface set ether[Tab]_
[admin@MikroTik] > interface set ether[Tab]_
ether1 ether5
Клавіша [Tab] може бути використана в іншому контексті, де консоль
може знайти ключі до можливих значень – імен команд, імен аргументів,
аргументів, що мають кілька можливих значень (назви елементів списків або
назви протоколів в firewall- і NAT-правилах). Ви не можете прискорювати
набір номерів, IP-адрес і інших подібних значень.
Інший шлях зменшення натискання клавіш – це скорочення команд і
аргументів. Ви можете набирати тільки початок команди, і, якщо воно (ім’я
команди) не повне, консоль прийме її як повне ім’я команди.
Вбудована допомога
У консолі існує вбудована допомога, доступ до якої можна одержати

,натиснувши ?. Головне правило – ця допомога показує те, що можна ввести
в позиції, де була натиснута клавіша ? (на зразок подвійного натискання
клавіші [Tab], але в більш розгорнутому вигляді).
Основні команди
Нижче описані деякі команди, що зазвичай використовуються на всіх

рівнях меню, а саме: print, set, remove, add, find, get, export, enable, disable,
comment, move. Ці команди поводяться однаково на всіх рівнях меню.
40
Опис команд
Команда print показує всю інформацію, яка доступна в поточному

рівні меню. Так, /system clock print показує системну дату й час, ip route
print – всі маршрути та інше. Якщо в команді використовується список
елементів поточного меню й вони мають властивість ні «read-only», то є
можливість змінювати/видаляти їх. Також команда print застосовується до
нумерованих елементів і може працювати з усіма командами, які оперують
елементами в цьому списку.
Вхідні параметри команди print:
1) from – застосовується тільки до списку елементів. Використовується
з усіма командами, які працюють із елементами в цьому списку;
2) brief – змушує команду print використовувати табличну форму
виводу;
3) detail – змушує команду print використовувати форму виводу
property=value;
4) count-only – показує тільки номери елементів;
5) file – перенаправляє контенти обраного підміню у файл. Даний файл
буде доступний на ftp маршрутизатора;
6) interval – показує вивід команди print кожну секунду інтервалу;
7) oid – друкує значення oid, що використовується для SNMP;
8) without-paging – друкує вивід команди без відображення. Для
перегляду виконання команди необхідно використати комбінацію клавіш
[Shift]+[Tab].
Команда set – застосовується для зміни значень головних параметрів
або параметрів елементів. Команда set має аргументи й передається з ім’ям,
значення якого змінюється. Якщо команда застосовується до списку
елементів, то вона має один аргумент – номер елемента (або список номерів),
який змінюються. Ця команда нічого не повертає (не виводить на екран
результат свого виконання).
Команда add – ця команда зазвичай має ті ж аргументи, що й set, крім
дії, де як аргумент передається номер. Ця команда додає новий елемент зі
значенням, зазвичай в кінець списку. Інші значення встановлюються за
замовченням, якщо вони не були задані.
41
Вхідні параметри команди set:
1) copy-from – скопіювати існуючий елемент. Ця дія встановлює
значення за замовчуванням властивостей нових елементів, узятих з інших
елементів;
2) place-before – помістити новий елемент перед існуючим елементом.
Положення попереднього елемента необхідно вказати. У противному разі
необхідно використовувати команду move після додавання елемента в
список;
3) disabled – керування станом відключено/включено нового доданого
елемента;
4) comment – вставити коментар для нового створеного елемента.
Команда add виводить внутрішній номер елемента, якщо він доданий,
команда remove – видаляє елемент(и) із списку. Вхідні параметри команди
remove – це номер(и) або ім’я(імена) елемента(ів) для видалення.
Команда move – змінює порядок проходження елементів у списку.
Послідовна нумерація елементів після виконання команди move змінюється,
тому краще перешикувати список, використовуючи команду print щораз
після використання команди move.
Вхідні параметри команди move:
1) перший аргумент визначає за номером елемент, що пересувається;
2) другий аргумент визначає, перед яким елементом буде розміщений
переміщуваний.
Команда find має аргументи, як і команда set, і доповнюється
аргументами, отриманими в результаті виконання команди print.
Команда edit застосовується скрізь, де працює команда set; вона
використовується для редагування властивостей елемента.
Безпечний режим
Цей режим не дозволяє змінити конфігурацію маршрутизатора, крім як з

термінальної консолі. Як правило, це відбувається випадково, але не існує
можливості відміни останньої зміни після того, як видалені з’єднання вже
скинуті.
42
Зазвичай безпечний режим використовується для мінімізації ризиків
при настроюванні. Перехід у безпечний режим здійснюється натисканням
клавіш [Ctrl]+[X]. Для виходу з безпечного режиму слід повторно натисніть
[Ctrl]+[X].
Повідомлення безпечного режиму відображається й зміни негайно
застосовуються, щоб показати, що ви перебуваєте в безпечному режимі. Всі
зміни конфігурації, які зроблені (також з інших сеансів) поки маршрутизатор
перебуває у безпечному режимі, автоматично скидаються, якщо безпечний
режим завершується некоректно.
Якщо під час безпечного режиму було зроблено занадто багато змін і
якщо немає можливості тримати їх в історії (поточна історія може містити до
100 нових записів), то сеанс автоматично переходить у безпечний режим, без
автоматичного скасування змін. У такий спосіб краще змінювати
конфігурацію поступово (маленькими кроками), поки ви перебуваєте в
безпечному режимі.
WebFig
IP-адреса маршрутизатора може бути використана для підключення до

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

маршрутизатора через протоколи 2-го та 3-го рівня мережної моделі OSI, а
саме за MAC- або IP-адресою маршрутизатора. Утиліту Winbox можна
скачати з самого маршрутизатора.
Консоль Winbox використовується для конфігурації і доступу до
особливостей управління за допомогою графічного інтерфейсу (GUI). Всі
функції Winbox зроблені максимально наближеними до функцій традиційної
консолі: всі функції Winbox розташовані в тій же ієрархії, як і функції
термінальної консолі, і навпаки (крім функцій які не реалізовані у Winbox).
Саме з цих причин у документації немає опису функцій Wіnbox.
43
Налаштування GNS3
Останню версію образу RouterOS Mikrotik для PC-платформи можна

отримати з сайту http://www.mikrotik.com/download. (Нижче описані команди
роботи з образом mikrotik-5.26.iso).
Зайдіть у каталог, у який встановлено GNS3 (наприклад, С:\Program
Files\GNS3\). Працюйте у командному рядку операційної системи (cmd). Для
переходу в каталог виконайте команду
cd c:\program files\gns3
Створіть пустий образ віртуального диска формату qcow2 розміром

128mb:
qemu-img create -f qcow2 images\mikrotik-5.26.img 128M
В Qemu під Windows при старті маршрутизатора стартує і VNC-клиент.

В віртуальній машині Qemu з CD-образа mikrotik-5.26.iso встановіть
RouterOS на образ віртуального диска mikrotik-5.26.img:
qemu images\mikrotik-5.26.img -cdrom images\mikrotik-5.26.iso -boot d
Після запуску Qemu в інсталяторі оберіть пакети, що будуть

встановлені (рис. 3.1).
Рисунок 3.1 – Встановлення Mikrotik RouterOS
44
Після натискання клавіші «і» необхідно дати згоду на їх встановлення
(двічі натиснути клавішу «y»). Після закінчення встановленя слід закрити
вікно з Qemu (тому що програма переходить знову на встановлення ОС).
Протестуйте запуск RouterOS, для цього у командному рядку з
каталогу GNS оберіть команду:
qemu images\mikrotik-5.26.img
Ви повинні побачити повідомлення з необхідністю вводу логіну.

Введіть admin, на пропозицію ввести пароль – натисніть Enter. Ви повинні
побачити вікно терміналу з надписом Mikrotik. Закрийте Qemu.
Перейдіть у GNS3 Edit\Preferences\Qemu\Qemu Guest та додайте
створений образ mikrotik-5.26.img (оберіть необхідні пункти рис. 3.2 та
натисніть Save, а потім ОК).
Рисунок 3.2 – Настроювання Qemu в GNS3
Перейдіть у меню Edit\Symbol Manager. У вікні, що з’явиться, оберіть у

розділі Available Symbols зображення з надписом Router та натисніть кнопку
45
«>». Далі оберіть Type = Qemu Guest та у полі Name введіть Mikrotik.
Натисніть на кнопку Apply та потім на OK (рис. 3.3).
Рисунок 3.3 – Налаштування бібліотеки символів
Якщо все зроблено вірно, в списку All devices повинен з’явитися новий
елемент – Mikrotik.
Встановіть OpenVPN-клієнт (є в комплекті програм, що видає
викладач). При встановленні клієнта програма установки встановить також
один віртуальний мережний адаптер «TAP-Win32 Adapter V9». Встановіть
ще 2 віртуальних адаптери. Для цього виконайте з каталогу OpenVPN\BIN
двічі файл addtap.bat. Задайте встановленим адаптерам ім’я відповідно tap0,
tap1, tap2. (Перейдіть у налаштування мережних адаптерів: Панель
керування – Центр керування мережами та загальним доступом –
Змінення параметрів адаптерів. З контекстного меню кожного адаптера
«TAP-Win32 Adapter V9» оберіть пункт «Перейменувати». Ці адаптери
будуть використовуватися для доступу до маршрутизаторів Mikroitk.
Створіть новий проект (при створенні потрібно обрати два пункти:
Save nvrams… та Unbase images…) (рис. 3.4).
46
Рисунок 3.4 – Налаштування проекту
Створіть топологію мережі з маршрутизаторів Mikrotik (рис. 3.5).
Рисунок 3.5 – Топологія мережі
Перевірте значення консольного порту для кожного маршрутизатора

(Оберіть правою кнопкою миші над кожним маршрутизатором пункт Change
console port). Значення портів повинні бути різними для кожного
маршрутизатора. Сконфігуруйте маршрутизатори (натисніть двічі на кожний
маршрутизатор). Для цього для кожного маршрутизатора введіть у полі
Qemu option наступні значення:
Маршрутизатор Qemu option

Router1 -net nic,vlan=6 -net tap,vlan=6,ifname=tap0
Ця команда додає до маршрутизатора ще один мережний адаптер, який

зв’язується з мережним tap-інтерфейсом. Tap-інтерфейсу в GNS не видно.
47
При необхідності додавайте ще tap-інтерфейси для нових маршрутизаторів
через addtap.bat
Робота з мережним пристроєм Mikrotik
1. Запустіть поточну топологію, для цього натисніть на кнопку

Start/Resume all devices. Червоні точки з’єднання повинні стати зеленими.
При цьому повинні завантажитися три копії Qemu. Дочекайтеся
завантаження. При цьому вікна Qemu не закривайте, в них також можна
вводити команди, однак краще це виконувати у консолі.
2. Оберіть Routerl, натиснувши на ньому двічі ліву кнопку миші або
обравши з меню, що з’являється при натисканні правої кнопки миші над
пристроєм, пункт Console. Введіть логін admin, пароль залиште пустим.
Тепер Ви підключені до мережного пристрою і знаходитися в
командному рядку, в даному випадку в звичайному режимі.
3. Натисніть [Ctrl+X]. При цьому маршрутизатор переходить у
безпечний режим.
[admin@MikroTik] >[Ctrl+X]
[Safe Mode taken]
[admin@MikroTik] <SAFE>
4. Щоб повернутися в звичайний режим, просто натисніть [Ctrl+X] ще
раз.
5. Для виходу з пристрою введіть quit.
Основні команди мережного пристрою
1. Увійдіть на мережний пристрій Router1:

[admin@MikroTik] >
2. Для отримання списку усіх доступних команд можна скористатися
командою ? або натиснути двічі клавішу <TAB> Введіть команду, яка
використовується для перегляду усіх доступних команд:
[admin@MikroTik] > ?
Клавішу Enter натискати не потрібно.
3. Перейдіть в режим системної конфігурації
[admin@MikroTik] > system
48
[admin@MikroTik] /system>
Натисніть <TAB> для перегляду доступних команд.
Командний процесор використовує кольорове зораження інформації:
пункти меню, що мають підменю, виділяються блакитним кольором, кінцеві
команди – пурпурним.
4. Ім’я хоста мережного пристрою використовується для локальної
ідентифікації. Коли ви входите в мережний пристрій, ви бачите ім’я хоста
після імені користувача та символа @. Це ім’я може бути використане для
визначення місця знаходження. Встановіть «Rl» як ім’я вашого мережного
пристрою.
[admin@MikroTik] /system> identity set name=R1
[admin@R1] /system>
Отримайте інформацію про час роботи системи, про встановлені
пакети, ресурсах апаратного забезпечення, на якому працює RouterOS.
Наведіть історію виконаних команд. Задайте маршрутизатору Router2 ім’я
R2, а Router3 – ім’я R3.
5. Для роботи з маршрутизатором за замовчуванням використовується
користувач admin без паролю. Для роботи з користувачами є команда user.
Пароль доступу дозволяє вам контролювати доступ на маршрутизатор:
[admin@R1] > user
[admin@R1] /user>
Додайте користувача з ім’ям, яке дорівнює вашому імені. Задайте
пароль та права повного доступу. Вийдіть з системи. Зайдіть на
маршрутизатор за допомогою створеного користувача. Тимчасово забороніть
вхід користувачу за замовченням (admin). Спробуйте зайти на
маршрутизатор в якості користувача admin. Поверніть налаштування у
вихідний стан.
Введення в конфігурацію інтерфейсів
1. На мережному пристрої R1 введіть interface

[admin@R1] > interface
За допомогою <TAB> отримайте інформацію про всі інтерфейси, а за
допомогою print – про інтерфейси, що на поточний час використовуються
маршрутизатором.
49
Отримайте скорочену та детальну інформацію про інтерфейси Ethernet:
[admin@R1] /interface> ethernet print
[admin@R1] /interface> ethernet print detail
Визначити який інтерфейс відповідає tар-інтерфейсу.
2. За допомогою команди monitor-traffic продивіться статистику
передачі інформації по інтерфейсу ether1.
Налаштування IP-адрес інтерфейсів
1. Введіть команду ip^

[admin@R1] > ip
[admin@R1] /ip>
2. Для отримання інформації про сусідні пристрої використайте
команду neighbor:
[admin@R1] /ip> neighbor print
Отримайте детальну інформацію про підключені пристрої.
3. Тепер призначте інтерфейсу e0 (у маршрутизаторі відповідає
інтерфейсу ether1) IP-адресу 10.1.1.2 255.255.255.0. Для цього використайте
команду address:
[admin@R1] /ip> address add address=10.1.1.2/24
interface=ether1
За замовчуванням нумерація інтерфейсів в програмі GNS3 починається

з 0, а нумерація в маршрутизаторі – з 1, тому інтерфейс e0 в GNS відповідно
є ether1 в маршрутизаторі.
Побачити призначені адреси можна використавши команду
[admin@R1] > ip address print
4. Перемкніться до пристрою R2 і призначте інтерфейсам е0 (ether1) та
е1 (ether2) відповідно IP-адреси 10.1.1.1/24 та 172.17.72.1/24
[admin@R2] > ip
interface=ether1
interface=ether2
5. Підключіться до пристрою R3 і встановіть IP-адресу iнтерфейсу e1
(ether2) 172.17.72.2/24:
[admin@R3] > ip
50
interface=ether2
6. На кожному пристрої побачьте інформацію про сусідів та зрівняйте її
з інформацією, яку ви отримали, виконуючи п. 2.
7. Підключіться до пристрою R2. Ви повинні успішно пропінгувати
безпосередньо приєднаний інтерфейс е0 на пристрої R1 та інтерфейс е1
пристрою R3:
[admin@R2] > ping 10.1.1.2
(Ctrl+C)
[admin@R2] > ping 172.17.72.2

(Ctrl+C)
Успішно.
8. Поверніться на R1. Ви повинні успішно пропінгувати адресу 10.1.1.1
безпосередньо приєднаного інтерфейсу e0 на пристрої R2. Поверніться на R3.
Ви повинні успішно пропінгувати адресу 172.17.72.1 безпосередньо
приєднаного інтерфейсу e1 на пристрої R2. Спробуйте пропінгувати
інтерфейс e0 на пристрої R2:
[admin@R3] > ping 10.1.1.1
Невдача. Спробуйте пропінгувати адресу 10.1.1.2 інтерфейсу e0 на

пристрої R1. Невдача.
9. Поверніться на Router1. Спробуйте пропінгувати адресу 172.17.72.1
інтерфейсу e1 на пристрої R2. Невдача. Спробуйте пропінгувати адресу
172.17.72.2 інтерфейсу e1 на пристрої R3. Невдача.
Невдачі вас спіткали тому, що ви не настроїли на маршрутизаторах
маршрутизацію.
10. Зайдіть на пристрій R2. Визначте шляхи проходження пакетів на
Router2:
[admin@R2] > tool
[admin@R2] /tool> traceroute 10.1.1.2
і R3:
[admin@R2] /tool> traceroute 172.17.72.2
Ви повинні побачити по одному хопу.
51
11. Виконайте команду розширеного пінгу від адреси 10.1.1.2 до адреси
172.17.72.2:
[admin@R2] > ping 172.17.72.2 src-address=10.1.1.1
Telnet
1. Увійдіть на пристрій R1 і встановіть telnet-з’єднання з пристроєм R2.

Для цього використайте IP-адресу його інтерфейсу е1:
[admin@R1] > system telnet 10.1.1.1
2. Помітьте, що ім’я мережного пристрою помінялося на «R2», тому що
ми встановили telnet-з’єднання з R2. Команда
[admin@R2] > user active print
покаже, що з’єднання здійснене від адреси 10.1.1.2.
3. Закрийте сесію
[admin@R2] > quit
4. МАС-telnet використовується для з’єднання за МАС-адресою
пристрою (наприклад, якщо ІР-адреси не задані).
Визначте на маршрутизаторі R2 MAC-адресу еther1-інтерфейсу. Тепер
можна виконати підключення до маршрутизатора R2 з маршрутизатора R1,
використовуючи цю адресу. Наприклад, якщо МАС-адреса еther1-
інтерфейсу= 00:AB:4A:53:2B:00, то команда підключення буде мати вигляд
[admin@R1]> tool mac-telnet 00:AB:4A:53:2B:00
Робота з маршрутизатором через Web-інтерфейс
Виконайте команди в командному рядку операційної системи(cmd):

1. netsh interface ip set address name="tap0" static 192.168.0.2 255.255.255.0
Переконайтесь у призначенні ІР-адрес відповідним taр-адаптерам. Для

цього виконайте команду ipconfig /all.
Після цього для кожного інтерфейсу, який пов’язаний з tap-адаптером
(зазвичай це останні ethernet-адаптери), на кожному маршрутизаторі задайте
відповідні ІР-адреси, а саме: для R1 (ether7) – 192.168.0.1/24, для R2 (ether7) –
192.168.1.1/24 та для R3 (ether7) – 192.168.2.1/24. Переконайтеся, що пінг між
52
маршрутизаторами та робочою станцією є можливим. Для цього виконайте
пінг з командного рядка операційної системи на ІР-адреси 192.168.0.1,
192.168.1.1 та 192.168.2.1.
Зайдіть у будь-який браузер та у рядку з адресою введіть
http://192.168.0.1. Ви повинні потрапити у Web-інтерфейс налаштування
маршрутизатора R1. Структура команд у Web-інтерфейсі аналогічна
структурі команд при роботі з консоллю (рис. 3.6).
Рисунок 3.6 – Web-інтерфейс налаштування маршрутизатора
З Web-інтерфейсу також можливий запуск терміналу. Для цього

натисніть відповідну кнопку.
Рисунок 3.7 – Вікно терміналу у Web-інтерфейсі маршрутизатора
53
Робота з маршрутизатором через утиліту WinBox
Знаходячись у Web-інтерфейсі будь-якого маршрутизатора, виконайте

завантаження утиліти WinBox (натиснувши відповідну клавішу).
Після запуску в стартовому вікні необхідно обрати ІР-адресу
маршрутизатора, або натиснути на кнопку «…», і утиліта сама знайде
маршрутизатори, що знаходяться у мережі (рис. 3.8). Крім того, утиліта вміє
знаходити маршрутизатори Mikrotik і за MAC-адресами.
Рисунок 3.8 – Запуск утиліти WinBox
Утиліта реалізована за технологією MDI (Multiply Document Interface).

Усі вікна, які можуть бути відкритими, знаходяться на головному вікні
програми (рис. 3.9).
Рисунок 3.9 – Загальний вигляд утілити WinBox
Структура меню у WinBox така сама, як і у Web-інтерфейсі та консолі.
54
1. Які є режими введення команд в командному рядку?

2. Як перемикатися між режимами введення команд в командному
рядку?
3. Яку роль відіграє клавіша табуляції при введенні команд?
4. Як орієнтуватися в раніше введених командах і повторювати їх?
5. Яку інформацію повертає команда ping?
6. Для чого служить команда traceroute?
7. Для чого служить команда telnet?
8. Як задати ім’я хоста?
9. Перелічити способи, якими можна звернутися до маршрутизатора
Mikrotik.
10. Як призначити IP-адресу на інтерфейс і переконатися, що він
призначений?
11. Як дізнатися інформацію про сусідні маршрутизатори?
12. Чому можуть не проходити пінги між пристроями?
13. Для чого використовується команда mac-telnet?
14. Який механізм доступу до маршрутизатора Mikrotik зручніший?
Поясніть чому?

2. Здати викладачеві теорію роботи шляхом відповіді на контрольні
питання.
3. Виконати в GNS3 практичну частину та завдання для самостійної
роботи
4. Подати викладачеві результат виконання завдання для самостійної
роботи. Продемонструвати йому, що комп’ютери пінгуюються згідно з табл.
3.1.
5. Продемонструвати роботу telnet.
6. Оформити звіт. Зміст звіту дивиться нижче.
55
3.6 Завдання для самостійної роботи
Варіанти обираються за номером по списку у журналі групи .

2 Самі призначте пристроям імена. На кожному пристрої отримайте
інформацію про сусідні пристрої.
3. Призначте інтерфейсам адреси, згідно з варіантом (v=1–16) з
4. Перевірте, що адреси призначені. Наведіть інформацію про
призначення адрес на кожному пристрої. Збережіть скріншоти.
5. Збережіть скріншоти для пінгів з’єднань, відмічених у табл. 2.6
знаком *.
(!)Увага. Рис. 2.3, 2.4 , 2.6 ви знайдете в методичних вказівках до
лабораторної роботи 2.
6. Виконайте на R1 розширений пінг. Збережіть 3 скріншоти для пінгів:
від i12 до i21, від i13 до i31 і від i12 до i31.
7. Зайдіть по Telnet з R2 на R1.
8. За допомогою Web-інтерфейсу змініть в ІР-адресах на інтерфейсах
і12, i21 останній октет на значення new = 255 – N, N – номер по списку;
9. За допомогою утілити WinBox змініть в ІР-адресах на інтерфейсах
і13, i31 та і23, i32 останній октет на значення new = 255 – N, N – номер по
списку;
10. Додайте до топології ще один маршрутизатор фірми Cisco
(Router4), який приєднайте до маршрутизатора Router3. Задайте ІР-адреси
для нового з’єднання. Отримайте на маршрутизаторах Router3 та Router4
інформацію про сусідів.

1. Усі виконані пункти практичної роботи зі скріншотами.
2. Скріншот топології з рис. 2.3 з зазначенням на ньому ІР-адрес згідно
з обраним варіантом.
56
СТАТИЧНА МАРШРУТИЗАЦІЯ
Ознайомлення з принципами маршрутизації та набуття практичних

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

найкращого шляху до заданого адресата. Маршрутизатор визначає шляхи
(маршрути) до адресатів або із статичної конфігурації, введеної
адміністратором, або динамічно на підставі маршрутної інформації,
отриманої від інших маршрутизаторів. Маршрутизатори обмінюються
маршрутною інформацією за допомогою протоколів маршрутизації.
Маршрутизатор зберігає таблиці маршрутів в оперативній пам’яті.
Таблиця маршрутів – це список найкращих відомих доступних
маршрутів. Маршрутизатор використовує цю таблицю для прийняття
рішення, куди направляти пакет. Навіть якщо на деякому маршрутизаторі не
задавалися ніякі команди маршрутизації, він все одно будує таблицю
маршрутів для безпосередньо приєднаних до нього мереж. Маршрут на
безпосередньо приєднані мережі відображується на інтерфейс
маршрутизатора, до якого вони приєднані.
Таблиця маршрутів відображує мережні префікси (адреси мереж) на
вихідні інтерфейси. Крім того, в таблиці маршрутизації є поле метрики –
характеристики відповідного маршруту. Це поле використовується
динамічними протоколами маршрутизації для визначення більш якісного
маршруту.
57
Приклад таблиці маршрутизації:
Мережа Маска Інтерфейс Метрика
10.1.1.0 255.255.255.0 Ethernet0 0
172.17.72.0 255.255.255.0 Ethernet1 0
Коли маршрутизатор отримує пакет, він за допомогою маски, що

вказана для кожного запису у таблиці маршрутизації, отримує адресу мережі
та порівнює її з адресою мережі, вказаною у цьому ж запису у таблиці. Таким
чином пакет буде направлений на той інтерфейс, де адреси мережі збіжаться.
Однак якщо є декілька варіантів, то обирається та мережа, де кількість
збіжних розрядів більша. Так, пакет з адресою призначення 172.17.72.15 буде
направлений на інтерфейс Ethernet0.
Маршрутизатор відкидає усі пакети, що направляються до мереж, не
вказаних в таблиці маршрутів. Для спрямування пакетів до інших адресатів
необхідно в таблицю включити додаткові маршрути. Нові маршрути можуть
бути додані методами:
1) статичної маршрутизації – адміністратор вручну визначає маршрути
до мереж призначення;
2) динамічної маршрутизації – маршрутизатори наслідують правила,
що визначені протоколами маршрутизації для обміну інформацією про
маршрути і для вибору кращого шляху.
Статичні маршрути не змінюються самим маршрутизатором. Динамічні
маршрути змінюються самим маршрутизатором автоматично при отриманні
інформації про зміну маршрутів від сусідніх маршрутизаторів. Статична
маршрутизація споживає мало обчислювальних ресурсів і корисна в
мережах, які не мають декількох шляхів до адресата призначення. Якщо від
маршрутизатора до маршрутизатора є тільки один шлях, то часто
використовують статичну маршрутизацію.
Маршрутизація за замовчуванням
Зовсім не обов’язково, щоб кожен маршрутизатор обслуговував

маршрути до усіх можливих мереж призначення. Замість цього
маршрутизатор зберігає маршрут за замовчуванням або шлюз останнього
58
притулку (last resort). Маршрути за замовчуванням використовуються, коли
маршрутизатор не може поставити у відповідність до мережі призначення
рядок в таблиці маршрутів. Маршрутизатор повинен використовувати
маршрут за замовчанням для відсилання пакетів іншому маршрутизатору.
Наступний маршрутизатор матиме маршрут до цієї мережі призначення або
матиме свій маршрут за замовчанням до третього маршрутизатора і так далі.
Наприкінці пакет буде відправлений на маршрутизатор, що має маршрут до
мережі призначення.
Маршрут за замовчанням може бути статично введений
адміністратором або динамічно отриманий з протоколу маршрутизації.
Оскільки усі IP-адреси належать мережі 0.0.0.0 з маскою 0.0.0.0, то
чином додавання запису у таблицю маршрутизації про мережу 0.0.0.0 з
маскою 0.0.0.0 є маршрутом за замовчуванням.
Ручне завдання маршруту за замовчанням на кожному маршрутизаторі
підходить для простих мереж. У складних мережах необхідно організувати
динамічний обмін маршрутами за замовчуванням.
Інтерфейс-петля
На мережних пристроях Cisco можна створювати мережні інтерфейси,

не пов’язані з реальними каналами для передачі даних, і призначати на них
IP-адреси з масками. Такі інтерфейси називають петлями (loopback). Петлі
корисні при поетапному проектуванні мереж. Якщо до якогось реального
мережного інтерфейсу маршрутизатора надалі буде приєднана підмережа, то
на початку на маршрутизаторі створюється петля, яка настроюється в плані
взаємодії з іншими ділянками мережі і лише потім замінюється на реальний
інтерфейс. Інтерфейс-петля з’являється після команди interface loopbackN
або скорочено int lN, де N – ціле додатне число (номер петлі). Наприклад:
Router(conf)>int l0
Команда trace
Команда trace єя ідеальним способом для з’ясування того, куди

вирушають дані в мережі. Ця команда використовує ту ж технологію
протоколу ICMP, що і команда ping, тільки замість перевірки крізного
59
зв’язку між відправником і одержувачем, вона перевіряє кожен крок на
шляху. Команда trace використовує здатність маршрутизаторів генерувати
повідомлення про помилку при перевищенні пакетом свого встановленого
часу життя (Time To Live, TTL). Ця команда посилає декілька пакетів і
виводить на екран дані про час проходження туди і назад для кожного з них.
Перевага команди trace полягає в тому, що вона показує черговий досягнутий
маршрутизатор на шляху до пункту призначення. Це дуже потужний засіб
для локалізації відмов на шляху від відправника до одержувача. Варіанти
відповідей утиліти trace для пристроїв Cisco:
Символ Значення
!H Зондуючий пакет був прийнятий маршрутизатором, але не
переадресований, що зазвичай буває із-за списку доступу
P Протокол недосяжний
N Мережа недосяжна
U Порт недосяжний
* Перевищення часу очікування
Створіть топологію, що наведена на рис. 4.1.
Рисунок 4.1 – Топологія для виконання практичної частини
Тут Router1 – маршрутизатор фірми Cisco; Router2, Router3 –

маршрутизатори Mikrotik.
60
Призначте для інтерфейсів відповідних маршрутизаторів наступні
ІР-адреси:
Пристрій – Інтерфейс ІР-адреса

Router1 – e0/0 172.17.72.1/24
Router1 – e0/1 192.168.0.1/24
Router2 – e0 172.17.72.2/24
Router2 – e1 10.1.1.2/24
Router3 – e1 10.1.1.1/24
C1 (VPCS) 192.168.0.33/24
Статичні маршрути
В лабораторних роботах 2 та 3 не всі інтерфейси маршрутизаторів

могли бути пропінговані з інших маршрутизаторів, тому що не була
налаштована маршрутизація. Виправимо це становище.
Для отримання таблиці маршрутизації використовуються такі команди:
для Cisco IOS:
Router1#show ip route
для Mikrotik RouterOS:
[admin@MikroTik] > ip route print
Router2:
61
Router3:
Бачите безпосередньо приєднані мережі.

Спробуйте пропінгувати ІР-адреси 172.172.72.2, 172.17.72.1,
192.168.0.1. Невдача. Тому що на Router3 немає маршруту до мереж
192.168.0.1/24 та 172.17.72.0/24. Додайте ці маршрути. Для цього
використайте команду:
[admin@MikroTik] >
ip route add dst-address=ХХ.ХХ.ХХ.ХХ/24 gateway=XX.XX.XX.XX
dst-address – адреса мережі призначення;
gateway – адреса наступного маршрутизатора, який підключений до
поточного та знаходиться на шляху до мережі призначення.
[admin@Router3] > ip route add dst-address=172.17.72.0/24
gateway=10.1.1.2
[admin@Router3] > ip route add dst-address=192.168.0.0/24
gateway=10.1.1.2
Спробуйте пропінгувати ІР-адресу 172.172.72.2. Успішно. Спробуйте
пропінгувати ІР-адресу 172.172.72.1 – невдача, тому що на маршрутизаторі
Router1 не налаштована маршрутизація на мережу 10.1.1.0/24 у якій
знаходиться маршрутизатор Router3. Додайте цей маршрут. Для цього
використайте команди:
1) (config)ip route АдресаМережі МаскаМережі Інтерфейс
Ця команда вказує маршрутизатору, що усі пакети, призначені для
АдресаМережі-МаскаМережі слід направляти на свій Інтерфейс.
2) (config)ip route АдресаМережі МаскаМережі Адреса
Ця команда вказує маршрутизатору, що усі пакети, призначені для
АдресаМережі–МаскаМережі, слід направляти на той свій інтерфейс, з якого
досяжна IP-адреса Адреса. Як правило, Адреса – це адреса наступного
маршрутизатора по дорозі до АдресаМережі:
Router1(config)#ip route 10.1.1.0 255.255.255.0 172.17.72.2
Додайте на Router2 інформацію про мережу 192.168.0.0/24.
62
Налаштуйте ІР-адресу хоста С1. Для цього в консолі VPCS виконайте
команду:
VPCS[1]> ip 192.168.0.33/24 192.168.0.1
Адреса 192.168.0.1 – це адреса маршрутизатора, до якого підключений
хост. Якщо з хоста відсилається пакет з ІР-адресою мережі, яка не дорівнює
192.168.0.0/24, то цей пакет за замовчуванням буде відісланий
маршрутизатору (192.168.0.1), який повинен визначити шлях для цього
пакета.
Тепер усі пристрої попарно пінгуються. Перевірте це.
Маршрутизація за замовчуванням
Мережні пристрої Router3 і Router1 мають тільки по одному виходу в

зовнішній світ: через інтерфейси з адресами 10.1.1.1 і 172.17.72.1 відповідно.
Тому можна не визначати, на які підмережі буде виконуватися
маршрутизація. Для цього використовується маршрутизація за
замовчуванням:
1. Спочатку видаліть старі маршрути:
Router1(config)#no ip route 10.1.1.0 255.255.255.0

172.17.72.2
[admin@Router3] > ip route remove numbers=1,2
2. призначте маршрути за замовчуванням:

Router1(config)#ip route 0.0.0.0 0.0.0.0 172.17.72.2
[admin@Router3] > ip route add gateway=10.1.1.2
Зверніть увагу на те, що dst-address можна не вказувати. Спробуйте

виконати пінг від Router3 до хоста С1.
Loopback
1. Створіть інтерфейс-петлю на пристрої Router1:

Router1(conf)#int loopback 0
63
2. Задайте ІР-адресу для створеного інтерфейсу
Router1(config-if)#ip address 15.0.0.1 255.0.0.0
3. З Router3 спробуйте пропінгувати створену петлю.
1. Що таке таблиця маршрутизації?

2. Якщо адміністратор не настроював ніяких маршрутів, то що буде
містити таблиця маршрутизації?
3. Чим статична маршрутизація відрізняється від динамічної?
4. Які дві форми завдання статичної маршрутизації ви знаєте?
5. Як в команді маршрутизації визначається мережа призначення?
6. Поясніть значення полів в командах маршрутизації.
7. Коли використовується маршрутизація за замовчуванням?
8. Коли використовують інтерфейс-петлю?
9. Як працює команда трасування?

2. Здати викладачеві теорію роботи шляхом відповівши на контрольні
питання.
3. Виконати в GNS практичну частину.
4. Виконати в GNS самостійну частину.
5. Оформити звіт. Зміст звіту дивіться нижче.
6. Захистити звіт.
64
2. Тип маршрутизатора оберіть виходячи з табл. 4.1. Зверніть увагу,
що підключення робочої станції до маршрутизатора Mikrotik
виконується через комутатор:
3. Для налаштування маршрутизаторів Mikrotik скористайтеся

наступними способами налаштування:
N%3 0 1 2
Спосіб CLI WebFig WinBox
Таблиця 4.1 – Варіанти мережних пристроїв

Варіант Router1 Router2 Router3
1 Cisco Cisco Mikrotik
2 Cisco Mikrotik Cisco
3 Cisco Mikrotik Mikrotik
4 Mikrotik Cisco Cisco
5 Mikrotik Cisco Mikrotik
6 Mikrotik Mikrotik Cisco
65
4. Призначте інтерфейсам адреси, згідно з варіантом (v=1–16) з
Таблиця 4.2 – Варіанти ІР-адрес мереж між пристроями

Мережа ІР-адреса Мережа ІР-адреса
Net1 v.d.m+10.0 Net4 v.d+10.m.0
Net2 v.d.m+19.0 Net5 v.d+19.m.0
Net3 v.d.m+30.0 Net6 v.d+30.m.0
де n – день народження студента; m – місяць народження студента.
5. Налаштуйте маршрутизацію у мережі. Наведіть таблиці
маршрутизації кожного маршрутизатора.
6. Використайте маршрути за замовчуванням. Наведіть відповідні
команди та кінцеві таблиці маршрутизації для кожного маршрутизатора.
7. Виконайте попарно команду ping між С1 і С2, С1 і С3 та С2 і С3.
Наведіть скріншоти виконання.
8. Налаштуйте на маршрутизаторі Cisco інтерфейс-петлю. Налаштуйте
маршрутизацію. Зробіть команду ping між хостами С1, С2, С3 та
інтерфейсом-петлею.
9. Виконайте попарно команди трасування trace хостів С1 і С2, С1 і С3
та С2 і С3. Наведіть результати виконання.

2. Скріншот топології з рис. 4.2 з зазначенням на ньому ІР-адрес усіх
інтерфейсів згідно з обраним варіантом.
66
ОРГАНІЗАЦІЯ ОБ’ЄДНАННЯ МЕРЕЖ ЗА ДОПОМОГОЮ

ПРОТОКОЛУ ІР
Ознайомлення з принципами роботи протоколу ІР, зі структурою ІР-

дейтаграм та набуття практичних навичок аналізу мережного трафіку.
Технологія Ethernet
Ethernet (езернет) – базова технологія локальних обчислювальних

(комп’ютерних) мереж з комутацією пакетів, що використовує протокол
CSMA/CD (множинний доступ з контролем несучої та з виявленням колізій).
Цей протокол дозволяє в кожний момент часу здійснити лише один сеанс
передачі в логічному сегменті мережі. При появі двох і більше сеансів
передачі одночасно виникає колізія, яка фіксується станцією, що ініціює
передачу. Станція аварійно зупиняє процес і очікує закінчення поточного
сеансу передачі, а потім знову намагається повторити передачу.
У мережах Ethernet можуть застосовуватися кадри чотирьох форматів:
1. Ethernet II (Ethernet DIX).
2. Ethernet 802.2.
3. Ethernet 802.3.
4. Ethernet SNAP.
На рис. 5.1 наведено формати кадрів (перший рядок – позначення
полів, другий рядок – розміри полів у байтах).
67
Кадр Ethernet II
P DA SA Type Data FCS
8 6 6 2 46 – 1500 4
Кадр Ethernet 802.2/LLC

P SFD DA SA Length DSAP SSAP Control Data FCS
43/42 – 4
7 1 6 6 2 1 1 1/2
1497/1496
Кадр Ethernet 802.3 («Raw»)

P SFD DA SA Length Data FCS
7 1 6 6 2 46 – 1500 4
Кадр Ethernet SNAP

P SFD DA SA Length DSAP SSAP Control ProtID Data FCS
(0xAA) (0xAA) (0x03)
38 – 4
7 1 6 6 2 1 1 1 5
1492
Рисунок 5.1 – Формати кадрів Ethernet
Формати кадрів містять такі поля:

1) поле P (Preamble, преамбула) – складається із семи байт 10101010 і
використовується для синхронізації. Преамбула кадру Ethernet II містить
також поле SFD;
2) поле SFD (Start of Frame Delimiter, роздільник початку кадру) – має
значення 10101011 і вказує на те, що наступний байт належить заголовку
кадру;
3) поле DA (Destination Address, адреса призначення) – містить адресу
одного із трьох типів:
а) індивідуальну (unicast) адресу (перший біт старшого байта дорівнює
0) – вказує на єдиного одержувача (являє собою його MAC-адресу);
унікальність адреси забезпечують виробники мережного устаткування: у
другому і третьому байті зберігається номер фірми-виготовлювача, а інші
68
заповнюються виготовлювачем; деякі мережні адаптери дозволяють
встановлювати для них довільну MAC-адресу;
б) широкомовну (broadcast) адресу – складається із усіх одиниць
(0xFFFFFFFFFFFF), вказує на те, що даний кадр повинен бути отриманий
всіма вузлами мережі;
в) групову (multicast) адресу – перший біт старшого байта дорівнює 1, в
інших бітах зберігається номер групи вузлів, для яких призначений даний
кадр.
4) поле SA (Source Address, адреса джерела) – містить MAC-адресу
відправника кадру (завжди є індивідуальною адресою);
5) поле Type (тип) – вказує на протокол верхнього рівня, чиї дані
передаються в кадрі (фактично, виконує функції полів DSAP і SSAP із
заголовка кадру LLC);
6) поле Length (довжина) – містить розмір поля Data (у байтах);
7) поле Data (дані) – містить дані, передані протоколом верхнього
рівня;
8) поле FCS (Frame Check Sequence, контрольна послідовність кадру) –
містить контрольну суму кадру, обчислену за алгоритмом CRC-32;
9) поля DSAP, SSAP і Control становлять заголовок LLC-Кадру;
10) поле ProtID (ідентифікатор протоколу) – дозволяє використовувати
кадри Ethernet для передачі даних більш широкої множини протоколів
верхнього рівня. Це поле складається із двох підполів: OUI та Type.
Трибайтове підполе OUI (Organizationally Unique Identifier, організаційно-
унікальний ідентифікатор), зберігає номер організації, що контролює коди
протоколів у двобайтовому підполі Type (тип). IEEE присвоєний OUI =
0x00000.
Протокол ARP
ARP (англ. Address Resolution Protocol – протокол вирішення адрес) –

мережний протокол, призначений для перетворення IP-адрес (адрес
мережного рівня) в MAC-адреси (адреси канального рівня) у мережах
TCP/IP. Він визначений в RFC 826.
69
Даний протокол дуже розповсюджений і надзвичайно важливий.
Кожний вузол мережі має як мінімум дві адреси: фізичну й логічну. У мережі
Ethernet для ідентифікації джерела й одержувача інформації
використовуються обидві адреси. Інформація, що пересилається від одного
комп’ютера іншому по мережі, містить у собі фізичну адресу відправника,
IP-адресу відправника, фізичну адресу одержувача й IP-адресу одержувача.
ARP-протокол забезпечує зв’язок між цими двома адресами. Існує чотири
типи ARP-повідомлень: ARP-запит (ARP request), ARP-відповідь (ARP reply),
RARP-запит (RARP-request) і RARP-відповідь (RARP-reply). Локальний хост
за допомогою ARP-запиту запитує фізичну адресу хоста-одержувача.
Відповідь (фізична адреса хоста-одержувача) приходить у вигляді ARP-
відповіді.
Перед тим як створити підключення до якого-небудь пристрою в
мережі, IP-протокол перевіряє свій ARP-кеш щоб з’ясувати, чи не
зареєстрована в ньому вже потрібна для підключення інформація про хост-
одержувача. Якщо такого запису в ARP-кеші немає, то виконується
широкомовний ARP-запит. Цей запит для пристроїв у мережі має такий
зміст: «Хто-небудь знає фізичну адресу пристрою, що володіє наступною IP-
адресою?» Коли одержувач прийме цей пакет, то він відповідає: «Так, це моя
IP-адреса». Після цього відправник обновить свій ARP-кеш і буде здатний
передати інформацію одержувачеві.
RARP (англ. Reverse Address Resolution Protocol – зворотний протокол
перетворення адрес) – виконує зворотне відображення адрес, тобто
перетворює апаратну адресу в IP-адресу.
Протокол застосовується під час завантаження вузла (наприклад
комп’ютера), коли він посилає групове повідомлення-запит зі своєю
фізичною адресою. Сервер приймає це повідомлення й переглядає свої
таблиці (або перенаправляє запит) у пошуках відповідної IP-адреси. Після її
виявлення знайдена адреса відсилається назад на вузол, що її запросив. Інші
станції також можуть «чути» цей діалог і локально зберегти цю інформацію у
своїх ARP-таблицях.
Для перегляду ARP-кеша можна використовувати однойменну утиліту
arp з параметром «–a».
70
Після того як IP-адреса пройшла процедуру вирішення адреси, вона
залишається в кеші протягом 2-х хвилин. Якщо протягом цих двох хвилин
відбулася повторна передача даних за цією адресою, то час зберігання запису
в кеші продовжується ще на 2 хвилини. Ця процедура може повторюватися
доти, поки запис у кеші проіснує до 10 хвилин. Після цього запис буде
вилучений з кеша й буде відправлений повторний ARP-запит.
Протокол IP
Протокол IP (Internet Protocol, протокол міжмережної взаємодії)

описаний в RFC 791. Основна функція протоколу IP – передача пакетів між
вузлами, які належать до різних мереж, через проміжні мережі. Кожний пакет
(дейтаграма – datagram, у термінології TCP/IP) обробляється незалежно від
інших. Доставка дейтаграм не гарантується. Можливі втрати дейтаграм,
доставка з помилками, дублювання і порушення порядку проходження.
Друга функція протоколу IP – виконання фрагментації пакетів при передачі
їх між мережами з різним максимально допустимим розміром поля даних
кадру (MTU).
Істотна властивість протоколу IP полягає в нетрадиційному порядку
передачі бітів: байт передається, починаючи зі старшого біта. Крім того,
нумерація бітів у байті також починається зі старшого: найстарший біт має
номер 0, наймолодший – номер 7. Дейтаграма (IP-пакет) складається із
заголовка і поля даних. Формат заголовка (IPv4) наведено на рис. 5.2.
Номер Довжина
Тип сервісу Загальна довжина
версії заголовка
Ідентифікатор «великого пакета» Прапори Зсув фрагмента
Час життя Протокол Контрольна сума заголовка
Адреса відправника
Адреса одержувача
Опції Вирівнювання до 32-бітної границі
(змінна довжина) (заповнення нулями)
Рисунок 5.2 – Формат заголовка IP-пакета (IPv4)
71
1. Номер версії (Version) [4 біти] – визначає використовуваний формат
заголовка. У цей час основна використовувана версія має номер 4 (IPv4).
2. Довжина заголовка (Internet Header Length) [4 біти] – довжина
заголовка в 32-бітних словах; мінімальне допустиме значення – 5 (відповідає
довжині заголовка в 20 байт). Максимальна довжина заголовка – 60 байт.
3. Тип сервісу (Type of Service) [8 біт] – вказує на бажані параметри
якості обслуговування. Формат байта типу сервісу наведено на рис. 10.3.
4. Поле Пріоритету (Precedence) для звичайних пакетів дорівнює 0,
інші значення (від 1 до 7) використовуються для службових цілей; чим
більше значення, тим вище пріоритет (Рис. 5.3).
0 1 2 3 4 5 6 7
Пріоритет D T R ECN
Рисунок 5.3 – Структура поля «Тип сервісу» заголовка IP-пакета
5. Поля D (Delay – затримка), T (Throughput – пропускна здатність) і R

(Reliability – надійність) використовуються для зазначення найбільш
важливого для передавального вузла параметра якості. Вибір відбувається
між малою затримкою, великою пропускною здатністю і високою
надійністю. Відповідний біт (біти) встановлюється в 1, інші – в 0. Як
правило, поліпшення одного з параметрів пов’язане з погіршенням інших.
6. ECN – повідомлення про затримку (керування IP-потоком).
7. Загальна довжина (Total Length) [16 біт] – довжина дейтаграми
(заголовка і даних) у байтах. Хоча розмір поля дозволяє створювати
дейтаграми довжиною до 65535 байт, стандарт вимагає, щоб будь-який вузол
міг приймати як мінімум 576-байтні дейтаграми, а відправляти дейтаграми
більшої довжини тільки, будучи впевненим, що одержувач може їх прийняти.
8. Ідентифікатор «великого пакета» (Identification) [16 біт] – значення,
однакове для всіх дейтаграм, що містять фрагменти одного пакета («великого
пакета»).
9. Прапори (Flags) [3 біти] – прапори, що керують фрагментуванням:
0 біт – зарезервований, повинен бути 0; 1 біт (DF, Don’t Fragment) – «0» =
72
можна фрагментувати, «1» = не можна фрагментувати; 2 біт (MF, More
Fragments) – «0» = останній фрагмент, «1» = ще будуть фрагменти.
10. Зсув фрагмента (Fragment Offset) [13 біт] – указує на місце у
«великому пакеті», з якого починаються дані поточної дейтаграми.
Вимірюється в 64-бітних словах. Наприклад, зсув фрагмента, що дорівнює 2,
означає, що дані поточної дейтаграми повинні перебувати у «великому
пакеті», починаючи з 16-го байта. Перший фрагмент має нульовий зсув.
11. Час життя (Time to Live, TTL) [8 біт] – максимальний час
перебування дейтаграми в мережі. Кожний маршрутизатор повинен
зменшувати це значення на одиницю і відкидати дейтаграми зі значенням
TTL = 0 (сповістивши про це відправникові). Наявність цього поля
забезпечує знищення дейтаграми, «яка зациклилися» або «заблудилася».
Поле TTL також дозволяє обмежити дальність поширення дейтаграми (це
зручно, наприклад, при одночасній передачі безлічі абонентів) і є основою
для роботи утиліти traceroute.
12. Протокол (Protocol) [8 біт] – вказує, дані якого протоколу верхнього
рівня передаються в дейтаграмі. Можливі значення цього поля
стандартизовані (RFC «Assigned Numbers»), деякі з них такі: 1 – ICMP, 4 –
IP, 6 – TCP, 17 – UDP, 89 – OSPF.
13. Контрольна сума заголовка (Header Checksum) [16 біт] – контрольна
сума всіх полів заголовка, яка обчислюється як доповнення суми всіх 16-
бітових слів заголовка (з нульовими бітами в полі контрольної суми).
Оскільки деякі поля заголовка (наприклад, час життя) змінюються при
передачі дейтаграми через мережу, контрольна сума перераховується кожним
маршрутизатором. Якщо отримано дейтаграму з неправильною контрольною
сумою, така дейтаграма відкидається.
14. Адреса відправника (Source Address) [32 біта] – IP-адреса
відправника дейтаграми.
15. Адреса одержувача (Destination Address) [32 біта] – IP-адреса
одержувача дейтаграми.
16. Опції (Options) [змінна довжина] – необов’язкове поле, яке може
містити дані про безпеку, маршрут дейтаграми (при маршрутизації від
джерела) і т. д. В одній дейтаграмі може бути кілька опцій, кожна з яких
73
складається з коду опції (1 байт), довжини опції (1 байт) і байтів даних опції.
Якщо для опції не потрібні додаткові дані, вона складається з одного байта –
коду опції.
Код опції складається з трьох полів:
0 біт («Копіювати») – «0» = копіювати опції в усі фрагменти, «1» =
копіювати опції тільки в перший фрагмент
1 – 2 біти («Клас опції») – 0 = керування дейтаграмами/мережею, 2 =
налагодження мережі, 1 і 3 = зарезервовані.
3 – 7 біти («Номер опції») – номер опції усередині класу; так, для класу
0 визначено 7 номерів опцій, які несуть маршрути і дані про безпеку, а для
класу 2 – тільки один номер опції 4, що несе тимчасові мітки, які
використовуються при протоколюванні проходження дейтаграми за
маршрутом.
Фрагментація IP-пакетів
На шляху пакета від відправника до одержувача можуть зустрічатися

локальні і глобальні мережі різних типів з різними допустимими розмірами
полів даних кадрів канального рівня (Maximum Transfer Unit – MTU). Так,
мережі Ethernet можуть передавати кадри, що несуть до 1500 байт даних. Для
мереж X.25 характерний розмір поля даних кадру в 128 байт. Мережі FDDI
можуть передавати кадри розміром в 4500 байт. В інших мережах діють свої
обмеження. Протокол IP вміє передавати дейтаграми, довжина яких більша
за MTU проміжної мережі, за рахунок фрагментування – розбивання
«великого пакета» на деяку кількість частин (фрагментів), розмір кожної з
яких задовольняє проміжну мережу. Після того як всі фрагменти будуть
передані через проміжну мережу, вони будуть зібрані на вузлі-одержувачі
модулем протоколу IP назад у «великий пакет». Відзначимо, що складання
пакета із фрагментів здійснює тільки одержувач, а не який-небудь із проміж-
них маршрутизаторів. Маршрутизатори можуть тільки фрагментувати
пакети, але не збирати їх. Це пов’язано з тим, що різні фрагменти одного
пакета не обов’язково будуть проходити через ті самі маршрутизатори.
Для того щоб не переплутати фрагменти різних пакетів, використо-
вується поле ідентифікації, значення якого повинне бути однаковим для всіх
74
фрагментів одного пакета і не повторюватися для різних пакетів, поки в обох
пакетів не минув час життя.
При розподілі даних пакета розмір усіх фрагментів, крім останнього,
повинен бути кратний 8 байтам. Це дозволяє приділити менше місця в
заголовку під поле «Зсув фрагмента».
Другий біт поля Прапори (More fragments), якщо він дорівнює одиниці,
вказує на те, що даний фрагмент не є останнім у пакеті.
Якщо пакет відправляється без фрагментації, прапор «More fragments»
встановлюється в 0, а поле Зсув фрагмента заповнюється нульовими бітами.
Якщо перший біт поля Прапори (Don’t fragment) дорівнює одиниці, то
фрагментація пакета заборонена. Якщо цей пакет повинен бути переданий
через мережу з недостатнім MTU, то маршрутизатор змушений буде його
відкинути (і сповістити про це відправникові за допомогою протоколу
ICMP). Цей прапор використовується у випадках, коли відправникові відомо,
що в одержувача немає досить ресурсів з відновлення пакетів із фрагментів.
Аналіз мережного трафіку з використанням сніфера
Sniffer (від англ. to sniff – нюхати) – це мережний аналізатор трафіку,

програма або програмно-апаратний пристрій, призначений для перехоплення
й наступного аналізу трафіку, призначеного для інших вузлів.
Аналіз трафіку дозволяє:
1) відслідковувати мережну активність додатків;
2) налагоджувати протоколи мережних додатків;
3) локалізувати несправність або помилку конфігурації;
4) виявляти паразитний, вірусний і закільцьований трафік, наявність
якого збільшує навантаження мережного устаткування й каналів зв’язку;
5) виявляти в мережі шкідливе й несанкціоноване ПЗ, наприклад,
мережні сканери, флудери, троянські програми і інші;
6) перехоплювати будь-який незашифрований (а часом і
зашифрований) трафік користувача з метою дізнавання паролів і іншої
інформації.
З інструментів, призначених тільки для діагностики, сніфери поступово
перетворилися в засоби для досліджень і навчання. Наприклад, вони постійно
75
використовуються для вивчення динаміки й взаємодії у мережах. Зокрема,
вони дозволяють легко й наочно вивчати тонкості мережних протоколів.
Спостерігаючи за даними, які посилає протокол, ви можете глибше зрозуміти
його функціонування на практиці, а також побачити, коли деяка конкретна
реалізація працює не у відповідності до специфікації.
У стандартному режимі вікно сніфера WireShark ділиться на 3 панелі:
список захоплених кадрів, «аналізатор» протоколів та вихідні дані кадрів.
Розмір кожної панелі можна змінювати.
Розглянемо ці панелі докладніше.
Верхня панель містить список кадрів, захоплених на відповідних
мережних інтерфейсах. Список можна відсортувати по будь-якому полю (у
прямому або зворотному порядку) – для цього необхідно натиснути на
заголовок відповідного поля.
Кожний рядок містить такі поля (за замовчанням):
1) порядковий номер кадру (No);
2) час надходження кадру (Time);
3) адреса джерела кадру (Source);
4) адреса призначення кадру (Destination);
5) протокол (Protocol);
6) довжина кадру у байтах (Length);
7) інформаційне поле (Info).
Список відображуваних полів настроюється в Edit/Perferencis/Columns.
Для того, щоб зміни набули ефекту, необхідно хнову запустити програму,
попередньо натиснувши кнопку Save. При натисканні правої кнопки миші на
тому або іншому кадрі з’явиться контекстне меню.
Середня панель містить так зване «дерево протоколів» для обраного у
верхньому вікні кадру. У цій панелі в ієрархічному вигляді для обраного у
верхньому вікні захопленого кадру відображається вкладеність протоколів
відповідно до моделі взаємодії відкритих систем OSI. При натисканні на
праву кнопку миші викликається контекстне меню. При «розкритті» кожного
із протоколу натисканням на ліворуч, виводяться поля даних відповідних
протоколів.
76
Нижня панель містить подання обраного кадру у 16-річній системі
числення та у символьному вигляді. При виборі того або іншого поля в
середній панелі автоматично буде підсвічуватися відповідна ділянка
16-річного подання. Також є можливість подання у двійковій системі
числення.
Фільтрація пакетів
Якщо запустити сніфер без додаткових настроювань, він буде

«захоплювати» всі кадри, що проходять через мережні інтерфейси. Взагалі
для загального ознайомлення із процесами, що відбуваються в мережі, дуже
корисно проаналізувати активність мережних протоколів у реальних умовах
роботи системи в мережі.
При цілеспрямованому використанні сніфера дуже часто необхідно
вибірково відображати або захоплювати кадри за деякими заданими
критеріями. Для цих цілей служать фільтри відображення й захоплення
відповідно.
Існує два варіанти фільтрації кадрів: на етапі захоплення й на етапі
відображення користувачеві. У першому випадку ефективність роботи
сніфера й споживані ним системні ресурси значно нижчі, ніж у другому
випадку. Це обґрунтовується тим, що при досить інтенсивному мережному
трафіку й тривалому часі захоплення всі кадри повинні бути захоплені й
збережені або в пам’яті, або на дисковому пристрої. Найпростіші підрахунки
можуть показати, що навіть для 100-мегабітної мережі системних ресурсів
вистачить на нетривалий час. Фільтрація захоплення вже на момент
одержання кадрів набагато ефективніше, однак у такому випадку вона
повинна бути реалізована на рівні самих драйверів захоплення. Даний факт,
природно, ускладнює реалізацію сніфера. Wireshark підтримує обидва
варіанти фільтрації.
Фільтри відображення
Фільтри відображення являють собою досить потужний засіб

відображення трафіку. Фільтри задаються в рядку, що розташовується вгорі
77
основного екрана («Filter:»). Найпростіший фільтр відображення дозволяє
відібрати кадри за тим або іншим протоколом. Для цього в рядку потрібно
вказати назву протоколу (наприклад ARP) і нажати кнопку «Apply». Після
цього у верхньому вікні залишаться кадри, що належать цьому протоколу.
Кнопкою «Cleart» дія фільтра відміняється. Для роботи з фільтрами можна
викликати вікно «Analyze/Display Filters». Можна зберігати створені вирази
під певними іменами для наступного використання й т. д. За допомогою
логічних операцій (синтаксис мови С) можна складати логічні вирази.
Наприклад: tcp.port == 80. Майстер побудови фільтрів відображення
доступний через кнопку «Expression…».
Фільтри захоплення
За допомогою даних фільтрів можна захоплювати з мережі тільки ті

кадри, які підходять під критерій відбору. Якщо не задано ніякого фільтра (за
замовчуванням), то будуть захоплюватися всі кадри. У противному разі –
тільки кадри, для яких зазначений вираз буде істиною. Синтаксис фільтрів
захоплення трохи відрізняється від синтаксису фільтрів відображення. Вираз
складається з одного або більше примітивів, розділених пробілами.
Наприклад, фільтр для захоплення кадрів, адресованих на 80-й порт (http)
вузла з ІР-адресою 192.168.19.1, має вигляд tcp port 80 && ip dst 192.168.19.1.
Існує три різних типи примітивів: type, dir, proto.
Специфікатор type визначає тип параметра. Можливі параметри: host;
net; port. Наприклад: host linux; net 192.168.128; port 80. Якщо не зазначено
ніякого типу, то передбачається, що це параметр host. Специфікатор dir
визначає напрямок передачі. Можливі напрямки: src; dst; src or dst; src and
dst. Якщо не визначений напрямок, то передбачається напрямок "src or dst".
Для протоколів типу point-to-point використовуються специфікатори inbound
і outbound.
Специфікатор proto визначає тип протоколу, якому належить кадр.
Можливі протоколи: ether; fddi; tr; ip/ipv6; arp/rarp; decent; tcp; udp.
Наприклад: ether src linux; arp net 192.168.128; tcp port 80.
78
Якщо протокол не визначений, то будуть захоплюватися кадри всіх
протоколів. Тобто: «src linux» означає «(ip or arp or rarp) src linux»; «net ctam»
означає «(ip or arp or rarp) net ctam»; «port 53» означає «(tcp or udp) port 53».
Також існує кілька спеціальних специфікаторів, які не попадають в
описані вище випадки: gateway; broadcast; less; greater; арифметичні
вирази.
Складні фільтри захоплення будуються з використанням логічних
виразів.
Наприклад:
• Захоплення всіх IP-пакетів між хостом host1 і кожним хостом за
винятком hostX: ip host host1 and not hostX;
• Захоплення IP-пакетів розміром більше ніж 576 байт, що проходять
через шлюз snup: gateway snup and ip[2:2] > 576;
• Захоплення всіх ICMP-пакетів, за винятком пакетів ping: icmp[0] !=
8 and icmp[0] != 0.
Статистична обробка мережного трафіку
Сніфер Wireshark дозволяє виконувати різну статистичну обробку

отриманих даних. Всі доступні операції перебувають у меню «Statistics».
Загальна статистика: кількість отриманих/переданих пакетів, середня
швидкість передачі й т. д. доступні через пункт «Statistics/Summary».
Одержати інформацію зі статистики оброблених протоколів в отриманих
пакетах можна через пункт «Statistics/Protocol Hierarchy».
Однією з найцікавіших можливостей є генерація діаграми взаємодії
між вузлами, що доступна через меню «FlowGraph…». У результаті можна
спостерігати в досить наочній формі процес взаємодії на рівні протоколів.
Створіть топологію, що наведена на рис. 5.3.
79
Для кожного маршрутизатора додайте в налаштуваннях адаптери, які

пов’язані з tap-інтерфейсами відповідно tap0, tap1, tap2:
Маршрутизатор Qemu option

Mikrotik -net nic,vlan=6 -net tap,vlan=6,ifname=tap0
Mikrotik_2 -net nic,vlan=6 -net tap,vlan=6,ifname=tap1
Mikrotik_3 -net nic,vlan=6 -net tap,vlan=6,ifname=tap2
Призначте для інтерфейсів наступні ІР-адреси:
Пристрій – Інтерфейс ІР-адреса

Mikrotik – e0 10.1.1.2/24
Mikrotik – (tap0) 192.168.10.1/24
Mikrotik _2 – e0 10.1.1.1/24
Mikrotik _2 – (tap1) 192.168.19.1/24
Mikrotik _2 – e1 172.17.72.1/24
Mikrotik _3 – e1 172.17.72.2/24
Mikrotik _3 – (tap2) 192.168.30.1/24
tap0 192.168.10.2/24
tap1 192.168.19.2/24
tap2 192.168.30.2/24
Налаштуйте маршрутизацію на кожному пристрою.
Аналіз роботи протоколу ARP
Виконайте з командної строки операційної системи команду

arp –a
80
Ви повинні побачити наступну інформацію про tap-інтерфейси
(рис. 5.4).
Рисунок 5.4 – Результат виконання утиліти arp
Виконайте команду пінгування ІР-адреси 192.168.10.1 (Mikrotik). А

потім ще раз виконайте arp –a. Для інтерфейсу tap0 повинен додатися ще
один запис у ARP-таблиці, а саме інформація про інтерфейс маршрутизатора
Mikrotik (відповідність між ІР- та MAC-адресами), який пов’язаний з tap0.
Тепер з’ясуємо, як це сталося. Для цього запустить аналізатор трафіку
WireShark.
Зайдіть на маршрутизатор Mikrotik_2 та виконайте команду
[admin@MikroTik] > ip arp print
Ви повинні побачити порожню таблицю. Якщо в таблиці є записи, то
видаліть їх командою ip arp remove N, де N – номер запису.
У програмі WireShark оберіть пункт меню Capture/Interfaces. У вікні,
що з’явиться, оберіть інтерфейс tap1 та натисніть кнопку Start.
Виконайте в маршрутизаторі Mikrotik_2 команду
[admin@MikroTik] > ping 192.168.19.2 count=1
У програмі WireShark натисніть на кнопку Stop (Ctrl+E). Ви повинні
побачити чергу з захоплених кадрів, що проходили через інтерфейс tap1
(рис. 5.5).
81
Список захоплених кадрів
"Розшифровка" обраного
кадра по протоколам
Вміст кадру у 16-річній

системі числення
Рисунок 5.5 – Загальний вигляд програми WireShark
Оскільки на момент початку роботи утиліти ping в ARP-кеші не було

інформації про MAC-адресу відповідного вузла, то спочатку система повинна
визначити цю MAC-адресу, виконавши генерування ARP-запиту і відіславши
його в мережу широкомовним кадром. Після цього вона буде очікувати
відповіді від заданого вузла.
Проаналізуємо отримані кадри. Спочатку розглянемо ARP-запит (кадр
№1). Виділивши кадр курсором, одержуємо його розкладку за протоколами
(Ethernet+ARP) у середньому вікні. Wireshark дуже наочно «розкладає»
заголовок протоколу по полях. Вкладення даних протоколів верхніх рівнів у
поля даних протоколів нижніх рівнів називається інкапсуляцією.
Можна побачити, що в кадрі зазначені MAC- і IP-адреси відправника
(«Sender MAC address» і «Sender IP address» відповідно). Це параметри вузла,
з якого виконується запит (Mikrotik_2). У цьому випадку запит спрямований
на одержання («Opcode: request» – запит) MAC-адреси вузла, у якої його IP-
адреса («Рrotocol type: IP») 192.168.19.2 («Target IP address»). При цьому поле
«Target MAC address» заповнено нулями. Через те що одержувач ARP-запиту
на момент запиту не відомий, Ethernet-кадр відправляється всім вузлам у
даному локальному сегменті, про що сигналізує MAC-адреса Ethernet-кадру
«f:ff:ff:ff:ff:ff» (рис. 5.6).
82
ping
ARP запит та відповідь
ARP протокол
МАС- та ІР-адреси відправника
ІР-адреса одержувача
МАС-адреса порожня
Широкомовна адреса
Рисунок 5.6 – Аналіз ARP-запиту
Всі працюючі в мережі машини одержують кадр з ARP-запитом,

аналізують його, а відповідь відсилає тільки та машина, чия IP-адреса
відповідає IP-адресі в запиті. Таким чином маємо другий отриманий кадр є
ARP-відповіддю. Це видно з параметра поля «Opcode: reply». Зверніть увагу,
що даний кадр був відправлений саме тією машиною, чия MAC-адреса нас і
цікавила («Sender IP address: 192.168.19.2»). При цьому поле «Sender MAC
address» заповнено значенням «00:ff:60:8a:43:4c» (рис. 5.7).
Зверніть увагу на поле «Info» у списку захоплених пакетів.
Після визначення адрес вузол-відправник може виконати відсилання
запитів, вказаних в утилиті ping. Оскільки в параметрах утілити ping було
вказано відправити один пакет, то тому після вирішення адрес маємо ще два
кадри в переліку захоплених кадрів в WireShark: це Echo-запит та Echo-
відповідь.
83
Рисунок 5.7 – Аналіз ARP-відповіді
Проаналізуйте самостійно поля у відповідних запитах утиліти ping

відповідно до рис. 5.2 (виконайте аналіз заголовка ІР-пакета та отримайте
інформацію про кожне поле заголовка у запиті та відповіді).
1. Яку структуру має кадр Ethernet?

2. Як працює протокол АRP?
3. В яких випадках використовується протокол RARP?
4. Яка структура заголовка ІР-пакета (ІРv4)?
5. В якому випадку використовується фрагментація ІР-пакетів та хто її
виконує?
6. Які поля в заголовку ІР-пакету використовуються при фрагментації
пакетів?
7. Яке значення поля TTL в заголовку ІР-пакета та хто його змінює?
8. Що таке інкапсуляція?
9. Для чого використовуються сніфери?
10. Які основні функції виконують сніфери?
84
11. Навіщо використовуються фільтри відображення та фільтри
захоплення сніфера Wireshark? У чому їх відмінність?
12. Які базові функції статистичної обробки захоплених пакетів має
сніфер Wireshark?

3. Виконати в GNS практичну та самостійну частини.

2. Тип маршрутизатора оберіть виходячи з табл. 4.1:
3. Для налаштування маршрутизаторів Mikrotik скористайтеся
N%3 0 1 2
Рисунок 5.8 - Топологія для виконання самостійної роботи
85
4. Призначте інтерфейсам адреси згідно з варіантом (v=1–16) з
табл. 5.2. Усі маски дорівнюють 255.255.255.0. Для tap-інтерфейсів адреси
оберіть самостійно. Для робочих станцій обов’язково задайте gateway – ІР-
адресу маршрутизатора, до якого станція підключена.

Net1 v.d.m+10.0 Net3 v.d.m+30.0
Net2 v.d.m+19.0 Net4 v.d.m+40.0
тут n – день народження студента; m – місяць народження студента.

5. Налаштуйте маршрутизацію у мережі.
6. Виконайте команду ping між вузлами С1 та С2. Наведіть ARP-
таблицю для Router1. (Для Cisco виконайте команду show arp у
привілейованому режимі).
Наведіть скріншоти захоплених в WireShark ARP-запитів та відповідей.
Для цього в GNS3 натисніть на відповідну ділянку мережі лівою кнопкою
миші, а потім натисніть правою кнопкою миші, та у меню, що з’явиться,
оберіть пункт «Start capturing». Після цього знову натисніть праву клавішу
миші та оберіть пункт «Start WireShark».
7. Виконайте команду ping для одного пакета, вказавши наступний
розмір пакета: 1550+500*(N%4+1) (байт), де N – номер по списку в журналі
групи; % – операція отримання остачі після ділення. Наприклад, для 10-го
варіанта маємо: 1550+500*(10%4+1)=1500+500*(2+1)=3050. Опишіть
відповідні запити та відповіді у вигляді структури заголовків відповідних ІР-
пакетів. Усю інформацію отримайте з WireShark. Наведіть структури
фрагментів. Обґрунтуйте відповідні поля. Побачте справку за командою ping
в VPCS (ping ?) для перегляду всіх параметрів команди (кількість пакетів та
розмір).
8. Проаналізуйте команду трасування trace хостів С1 і С2 та С2 і С1 з
значенням TTL=2+N%3. Наведіть скріншоти WireShark з відповідним описом
кожного пакета, що був згенерований командою trace. Обґрунтуйте
успішність чи невдачу трасування. Побачте справку за командою trace в
VPCS (trace ?).
86

2. Скріншот топології з рис. 5.8 з зазначенням на ньому ІР-адрес усіх
інтерфейсів згідно з варіантом.
87
ДИНАМІЧНА МАРШРУТИЗАЦІЯ
Ознайомлення з принципами маршрутизації та надбання практичних

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

тому що зазвичай мережі включають надлишкові зв’язки, багато протоколів і
змішані топології. Маршрутизатори в складних мережах повинні швидко
адаптуватися до змін топології і обирати кращий маршрут з багатьох
кандидатів.
IP-мережі мають ієрархічну структуру. З точки зору маршрутизації
мережа розглядається як сукупність автономних систем. Автономна система
(autonomous system, AS) – набір маршрутизаторів, що мають єдині правила
маршрутизації, керованих одною технічною адміністрацією й працюючих на
одному із протоколів IGP (interior gateway protocols) (для внутрішньої
маршрутизації AS може використовувати й декілька IGP).
У автономних підсистемах великих мереж для маршрутизації на інші
автономні системи широко використовуються маршрути за замовчуванням.
Динамічна маршрутизація може бути здійснена з використанням
одного і більш протоколів. Ці протоколи часто групуються згідно з тим, де
вони використовуються. Протоколи для роботи усередині АS називають
внутрішніми протоколами шлюзів (IGP), а протоколи для роботи між АS –
зовнішніми протоколами шлюзів (exterior gateway protocols (EGP)). До
протоколів IGP відносяться RIP, IGRP, EIGRP, OSPF і IS-IS. Протоколи EGP
і BGP належать до EGP. Усі ці протоколи можуть бути розділені на два
класи: дистанційно-векторні протоколи і протоколи стану зв’язку.
88
Маршрутизатори використовують метрики для оцінки або виміру
маршрутів. Коли від маршрутизатора до мережі призначення існує багато
маршрутів і усі вони використовують один протокол маршрутизації, то
маршрут з найменшою метрикою розглядається як кращий. Якщо
використовуються різні протоколи маршрутизації, то для вибору маршруту
використовуються адміністративні відстані, які призначаються маршрутам
операційною системою маршрутизатора.
Результати роботи маршрутизуючих протоколів заносяться в таблицю
маршрутів, яка постійно змінюється при зміні ситуації в мережі.
Для того щоб динамічні протоколи маршрутизації обмінювалися
інформацією про статичні маршрути, слід здійснювати додаткову
конфігурацію.
Дистанційно-векторна маршрутизація
Ця маршрутизація базується на алгоритмі Белмана – Форда. Через

певні моменти часу маршрутизатор передає сусіднім маршрутизаторам усю
свою таблицю маршрутизації. Такі прості протоколи, як RIP і IGRP, просто
поширюють інформацію про таблиці маршрутів через усі інтерфейси
маршрутизатора в широкомовному режимі без уточнення точної адреси
конкретного сусіднього маршрутизатора.
Сусідній маршрутизатор, отримуючи широкомовлення, порівнює
інформацію зі своєю поточною таблицею маршрутів. У неї додаються
маршрути до нових мереж або маршрути до відомих мереж з кращою
метрикою. Відбувається видалення неіснуючих маршрутів. Маршрутизатор
додає свої власні значення до метрик отриманих маршрутів. Нова таблиця
маршрутизації знову поширюється по сусідніх маршрутизаторах (рис. 6.1).
89
Рисунок 6.1 – Дистанційно-векторна маршрутизація
Протокол RIP
Ключові характеристики протоколу RIP (Routing Information Protocol):

• маршрутизація на підставі вектора відстані;
• метрика при виборі шляху у вигляді кількості переходів (хопів);
• максимально допустима кількость хопів – 15;
• за замовчанням пакети актуалізації маршрутної інформації
посилаються в режимі широкомовлення кожні 30 секунд.
Протокол BGP
BGP (Border Gateway Protocol) – це основний протокол зовнішньої

динамічної маршрутизації, який використовується в Інтернеті.
Маршрутизатори, що використовують протокол BGP, обмінюються
інформацією про доступність мереж. Разом з інформацією по мережах
передаються різні атрибути цих мереж, за допомогою яких BGP обирає
кращий маршрут, і настроюються політики маршрутизації.
90
Один з основних атрибутів, який передається з інформацією про
маршрут – це список автономних систем, через які пройшла ця інформація.
Ця інформація дозволяє BGP визначати де знаходиться мережа відносно
автономних систем, виключати петлі маршрутизації, а також може бути
використана при налаштуванні політик.
Маршрутизація здійснюється покроково від однієї автономної системи
до іншої. Всі політики BGP налаштовуються, в основному, по відношенню до
зовнішніх / сусідніх автономних систем. Тобто описуються правила взаємодії
між ними.
Оскільки BGP оперує великими обсягами даних (поточний розмір
таблиці для IPv4 більш 450 тисяч маршрутів), то принципи його
налаштування і роботи відрізняються від внутрішніх протоколів динамічної
Протоколи стану зв’язку
Ці протоколи пропонують кращу масштабованість і збіжність в

порівнянні з дистанційно-векторними протоколами. Вони базуються на
алгоритмі Дейкстри, який часто називають алгоритмом «найкоротший шлях,
– перший» (shortest path first (SPF)). Найбільш типовим представником є
протокол OSPF (Open Shortest Path First).
Маршрутизатор бере до розгляду стан зв’язку інтерфейсів інших
маршрутизаторів в мережі. Маршрутизатор будує повну базу даних усіх
станів зв’язку у своїй області, тобто має досить інформації для створення
свого відображення мережі. Кожен маршрутизатор потім самостійно виконує
SPF-алгоритм на своєму власному відображенні мережі (граф мережі) або на
базі цих станів зв’язку для визначення кращого шляху, який заноситься в
таблицю маршрутів. Ці шляхи до інших мереж формують дерево з вершиною
у вигляді локального маршрутизатора.
Маршрутизатори сповіщають про стан своїх зв’язків усім
маршрутизаторам в області. Таке сповіщення називають LSA (link – state
advertisements).
91
На відміну від дистанційно-векторних маршрутизаторів,
маршрутизатори стану зв’язку можуть формувати спеціальні стосунки зі
своїми сусідами.
Має місце початковий наплив LSA-пакетів для побудови бази цих
станів зв’язку. Далі оновлення маршрутів проводиться тільки при зміні станів
зв’язку або якщо стан не змінився протягом певного інтервалу часу. Якщо
стан зв’язку змінився, то часткове оновлення пересилається негайно. Воно
містить тільки стани зв’язків, які змінилися, а не усю таблицю маршрутів.
Адміністратор, що піклується про використання ліній зв’язку,
знаходить ці часткові і рідкісні оновлення ефективною альтернативою
дистанційно-векторної маршрутизації, яка передає усю таблицю маршрутів
через регулярні проміжки часу.
Протоколи стану зв’язку мають швидшу збіжність і краще
використання смуги пропускання в порівнянні з дистанційно-векторними
протоколами.
Вони перевершують дистанційно-векторні протоколи для мереж будь-
яких розмірів, проте мають два головні недоліки: підвищені вимоги до
обчислювальної потужності маршрутизаторів і складне адміністрування.
Збіжність
Цей процес одночасно і спільний і індивідуальний. Маршрутизатори

розділяють між собою інформацію, але самостійно перераховують свої
таблиці маршрутизації. Для того щоб індивідуальні таблиці маршрутизації
були точними, усі маршрутизатори повинні мати однакове уявлення про
топологію мережі. Якщо маршрутизатори домовилися про топологію мережі,
то має місце їх збіжність. Швидка збіжність означає швидке відновлення
після обриву зв’язків і інших змін в мережі. Про протоколи маршрутизації і
про якість проектування мережі судять головним чином по збіжності.
Коли маршрутизатори знаходяться в процесі збіжності, мережа
сприйнятлива до проблем маршрутизації. Якщо деякі маршрутизатори
визначили, що деякий зв’язок відсутній, то інші помилково вважають цей
зв’язок присутнім. Якщо це станеться, то окрема таблиця маршрутів буде
92
суперечлива, що може призвести до відкидання пакетів і петель
Неможливо, щоб усі маршрутизатори в мережі одночасно виявили
зміни в топології. Залежно від використаного протоколу, може пройти багато
часу доки усі процеси маршрутизації в мережі зійдуться. На це впливають
такі чинники:
• Відстань в хопах до точки зміни топології.
• Число маршрутизаторів, що використовують динамічні протоколи.
• Смуга пропускання і завантаження каналів зв’язку.
• Завантаження маршрутизаторів.
Ефект деяких чинників може бути зменшений при ретельному
проектуванні мережі.
Протокол OSPF
OSPF (Open Shortest Path First) – це динамічний, ієрархічний протокол

стану зв’язку, використовуваний для маршрутизації усередині автономних
систем. Він базується на відкритих стандартах і був спроектований як заміна
протоколу RIP. Він є розвитком ранніх версій протоколу маршрутизації IS -
IS. OSPF – стійкий протокол, що підтримує маршрутизацію з найменшою
вагою і з балансуванням навантаження. Найкоротший шлях в мережі
обчислюється за алгоритмом Дейкстри.
Як тільки маршрутизатор налаштований на роботу з OSPF, він починає
процес вивчення оточення, проходячи декілька фаз ініціалізації. На початку
маршрутизатор використовує Hello для визначення своїх сусідів і для
створення стосунків для обміну оновленням маршрутною інформацією з
ними. Потім маршрутизатор починає фазу ExStart початкового обміну між
базами маршрутів. Наступною є фаза обміну, в якій призначений
маршрутизатор посилає маршрутну інформацію і отримує підтвердження від
нашого нового маршрутизатора. Протягом стадії завантаження новий
маршрутизатор компілює таблицю маршрутів. Після закінчення обчислень
маршрутизатор переходить в повний стан, в якому він є активним членом
мережі.
93
Створіть топологію, що наведена на рис. 4.1, та задайте ІР-адреси

пристроїв відповідно до таблиці з практичної частини ЛР 4.
Налаштування протоколу RIP
На маршрутизаторі Router1 виконайте команди

Router1(config)#router rip
Router1(config-router)#version 2
Router1(config-router)#network 172.17.72.0
Router1(config-router)#network 192.168.0.0
Тобто включіть роботу протоколу RIP 2-ї версії (підтримує роботу з

масками підмереж) та додайте інформацію про мережі, які будуть включені в
роботу протоколу (зазвичай це мережі, які підключені безпосередньо до
маршрутизатора).
[admin@Router2]>routing rip network add network=172.17.72.0/24

Продивіться на кожному маршрутизаторі таблиці маршрутизації. Ви

повинні побачити інформацію про усі мережі, що є у топології. Виконайте
команду ping з маршрутизатора Router3 на ІР-адресу робочої станції
192.168.0.33. Пінг повинен працювати.
На маршрутизаторі Router1 виконайте команду

Router1#debug ip rip

[admin@Router3] > sys logging add topics=route action=memory
[admin@Router3] > log print follow-only
94
Ви повинні побачити обмін повідомленнями протоколу RIP.
На маршрутизаторі Router1 виключіть інтерфейс е0/1 (команда

shutdown з меню інтерфейса). Прослідкуйте за обміном повідомленнями на
маршрутизаторах Router1 та Router3. Продивіться таблиці маршрутизації
кожного маршрутизатора.
Вимкніть маршрутизацію за протоколом RIP:
Router1(config)#no router rip
[admin@Router2]>routing rip network remove numbers=0,1
[admin@Router3]>routing rip network remove 0
Налаштування протоколу OSPF

Router1(config)#router ospf 100
Router1(config-router)#network 172.17.72.0 0.0.0.255 area 0
Router1(config-router)#network 192.168.0.0 0.0.0.255 area 0
Зверніть увагу на те, що значення маски мережі вказується у

інверсному вигляді.
[admin@Router2]>routing ospf network add network=172.17.72.0/24 area=backbone


Продивіться на кожному маршрутизаторі таблиці маршрутизації. Ви
повинні побачити інформацію про усі мережі, що є у топології. Виконайте
команду ping з маршрутизатора Router3 на ІР-адресу робочої станції
192.168.0.33. Пінг повинен працювати.
Прослідкуйте за обміном повідомленнями на маршрутизаторах Router1
та Router3.
95
Налаштування протоколу BGP
Рисунок 6.2 – Топологія для дослідження BGP
Зберіть топологію, що зображено на рис 6.2 (усі маршрутизатори –

Mikrotik). Виконайте налаштування ІР-адрес відповідно до топології. На
кожному маршрутизаторі додайте пустий міст та відповідну ІР-адресу на
нього (рис. 6.2). Так для маршрутизатора R1 призначення ІР-адрес
виконується наступним чином:
[admin@R1] > ip address add address=100.1.1.1/24 interface=ether1
[admin@R1] > ip address add address=100.2.2.2/24 interface=ether2
[admin@R1] > interface bridge add
[admin@R1] > ip address add address=100.0.0.3/32 interface=bridge1
Налаштуйте у кожній автономній системі маршрутизацію за

протоколом OSPF. При цьому на граничних маршрутизаторах не додавайте в
процес OSPF мережі, які використовуються для зв’язку автономних систем
(на рис. 6.2 це мережа 1.1.1.0/30). Наприклад, налаштування протоколу OSPF
на маршрутизаторі R2 виконується наступним чином:
[admin@R2] > routing ospf network add network=100.1.1.0/24 area=backbone
Додайте маршрут за замовченням на граничних маршрутизаторах та

дозвольте протоколу OSPF розповсюджувати статичні маршрути:
[admin@R2] > ip route add gateway=1.1.1.2
96
[admin@R2] > routing ospf instance set 0 distribute-default=always-as-type-1
[admin@R4] > routing ospf instance set 0 distribute-default=always-as-type-1
Після цього можна побачити маршрути, отримані на кожному з
маршрутизаторів у мережі. Наприклад на маршрутизаторі R1:
[admin@R1] > ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r -
rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 0.0.0.0/0 100.1.1.2 110
1 ADo 100.0.0.1/32 100.1.1.2 110
2 ADo 100.0.0.2/32 100.1.1.2 110
3 ADC 100.0.0.3/32 100.0.0.3 bridge1 0
4 ADC 100.1.1.0/24 100.1.1.1 ether1 0
5 ADC 100.2.2.0/24 100.2.2.2 ether2 0
6 ADo 100.3.3.0/24 100.1.1.2 110
Налаштуйте BGP для зв’язку автономних систем. Задайте номера

автономних систем:
[admin@R2] > routing bgp instance set 0 as=100 router-id=100.0.0.1
[admin@R4] > routing bgp instance set 0 as=200 router-id=200.0.0.1
Рекомендується налаштовувати BGP-сесію між інтерфейсами-петлями,

які в нашому випадку є пустими мостами. Але необхідно також налаштувати
маршрут між адресами мостів 100.0.0.1 та 200.0.0.1:
[admin@R2] > ip route add dst-address=200.0.0.1/32 gateway=1.1.1.2
[admin@R4] > ip route add dst-address=100.0.0.1/32 gateway=1.1.1.1
Встановіть BGP-сесію:
[admin@R2] > routing bgp peer add remote-address=200.0.0.1 remote-as=200
multihop=yes update-source=bridge1
[admin@R4] > routing bgp peer add remote-address=100.0.0.1 remote-as=100
multihop=yes update-source=bridge1
В якості джерела BGP-оновлень обрано міст bridge1. Про встановлення

BGP-сесій можна дізнатися виконавши команду:
[admin@R2] > routing bgp peer print detail
Flags: X - disabled, E - established
0 E name="peer1" instance=default remote-address=200.0.0.1 remote-as=200
tcp-md5-key="" nexthop-choice=default multihop=yes route-reflect=no
hold-time=3m ttl=255 in-filter="" out-filter="" address-families=ip
update-source=bridge1 default-originate=never remove-private-as=no as-
override=no passive=no use-bfd=no
Подивіться таблиці маршрутів на кожному роутері. Вони не змінилися.
97
Для того, щоб маршрутизатори змогли побачити мережі з інших
автономних систем необхідно їх анонсувати шляхом налаштування BGP. При
цьому можна вказувати їх або статично заданими, або шляхом перерозподілу
з протоколу внутрішньої маршрутизації (чого робити не бажано).
Для статичного анонсування мереж виконайте наступні команди:
[admin@R2] > routing bgp network add network=100.1.1.0/24
Після виконання цих команд на граничних маршрутизаторах з’являться

маршрути на мережі сусідніх автономних систем. Наприклад на
маршрутизаторі R2:
[admin@R3] > ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r -
rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 1.1.1.2 1
1 ADC 1.1.1.0/30 1.1.1.1 ether3 0
2 ADC 100.0.0.1/32 100.0.0.1 bridge1 0
3 ADo 100.0.0.2/32 100.3.3.1 110
4 ADo 100.0.0.3/32 100.1.1.1 110
5 ADC 100.1.1.0/24 100.1.1.2 ether2 0
6 ADo 100.2.2.0/24 100.3.3.1 110
100.1.1.1
7 ADC 100.3.3.0/24 100.3.3.2 ether1 0
8 A S 200.0.0.1/32 1.1.1.2 1
9 ADb 200.1.1.0/24 200.0.0.1 20
10 ADb 200.2.2.0/24 200.0.0.1 20
11 ADb 200.3.3.0/24 200.0.0.1 20
При цьому на інших маршрутизаторах таблиці не змінилися. Але

можна виконати ping з однієї автономної системи на іншу:
[admin@R3] > ping 200.3.3.1
Спробуйте виконати перерозподіл маршрутів з протоколу внутрішньої

маршрутизації в BGP. Це виконується командою:
[admin@R2] > routing bgp instance set 0 redistribute-ospf=yes
[admin@R4] > routing bgp instance set 0 redistribute-ospf=yes
Опишіть зміни, які відбулися при цьому.
98
Також можна виконати перерозподіл BGP-маршрутів в протокол
внутрішньої маршрутизації. Зазначемо, що в реальності це робити небажано,
тому що розміри BGP-таблиць включають маршрути для всього світу та
містять сотні тисяч строк. В корпоративній мережі ці маршрути зовсім не
потрібні. Перерозподіл виконується наступною командою (її необхідно
виконати на кожному маршрутизаторі автономної системи):
routing ospf instance set 0 redistribute-bgp=as-type-1
Виконайте цю команду на кожному маршрутизаторі та опишіть, що

змінилося.
1. Що таке автономна система?

2. Що таке метрика?
3. Які існують класи протоколів динамічної маршрутизації?
4. Поясніть роботу дистанційно-векторних протоколів.
5. Поясніть роботу протоколів стану зв’язку.
6. У чому переваги і недоліки дистанційно-векторних протоколів і
протоколів стану зв’язку?
7. Що таке збіжність протоколів маршрутизації?
8. Які параметри впливають на швидкість збіжності?
9. Як на маршрутизаторі запустити і настроїти протокол маршрутизації
RIP?
10. Як на маршрутизаторі запустити і настроїти протокол
маршрутизації OSPF?
11. Як подивитися зміст пакетів актуалізації маршрутної інформації
протоколу RIP?
12. Для чого використовується протокол BGP?

99

1. Виконайте пункти 1 – 4 самостійної роботи з ЛР 4.
2. Налаштуйте на маршрутизаторах маршрутизацію за протоколом RIP.
2.1 Наведіть таблиці маршрутизації для кожного маршрутизатора.
2.2 На маршрутизаторі Cisco виконайте відключення одного
інтерфейсу, через який виконується з’єднання з іншим маршрутизатором
(виконайте команду shutdown з меню налаштування інтерфейсу).
2.3 Наведіть оновлені таблиці маршрутизації для кожного
маршрутизатора.
2.4 За допомогою WireShark відслідкуйте процес побудови таблиці
маршрутизації на маршрутизаторі Router1. Наведіть відповідні скріншоти.
3. Налаштуйте на маршрутизаторах маршрутизацію за протоколом
OSPF.
Виконайте пункти 2.1 – 2.4.
4. Приведіть таблиці маршрутизації маршрутизаторів R3, R2 для
топології рис. 6.2 без виконання перерозподілу маршрутів, з перерозподілом
з OSPF в BGP та перерозподілом з BGP в OSPF.

2. Скріншот топології з рис. 4.2 із зазначенням на ньому ІР-адрес усіх
100
БЕЗКЛАСОВА АДРЕСАЦІЯ І МАСКИ ЗМІННОЇ ДОВЖИНИ
Ознайомлення з принципами безкласової маршрутизації та набуття

практичних навичок розбиття мереж за допомогою масок змінної довжини.
Класова ІР-адресація, навіть з використанням підмереж, не може

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

називається безклассовою міждоменною маршрутизацією CIDR (Classless
Interdomain Routing), яка ігнорує класи. У системах, що використовують
класи, маршрутизатор визначає клас адреси і потім розділяє адресу на октети
мережі і октети хоста, базуючись на цьому класі. CIDR-маршрутизатор
використовує біти маски для визначення в адресі мережної частини і номера
хоста. Межа розподілу адреси може проходити посеред октету.
CIDR значно покращує масштабованість і ефективність IP за такими
пунктами:
• гнучкість;
• економічне використання адрес у виділеному діапазоні;
• поліпшена агрегація маршрутів.
101
CIDR дозволяє маршрутизаторам агрегувати або підсумовувати
інформацію про маршрути. Вони роблять це шляхом використання маски
замість класів адрес для визначення мережної частини IP-адреси. Це
скорочує розміри таблиць маршрутів, оскільки використовується лише одна
адреса і маска для представлення маршрутів до багатьох підмереж.
Без CIDR і агрегації маршрутів маршрутизатор повинен містити
індивідуальну інформацію для усіх підмереж.
Наприклад розглянемо мережу класу А 85.0.0.0/8, в якій виділяється 8
підмереж:
Мережний Перший Другий Третій Четвертий
номер октет октет октет октет
85.24.0.0/16 01010101 00011000 00000000 00000000
85.25.0.0/16 01010101 00011001 00000000 00000000
85.26.0.0/16 01010101 00011010 00000000 00000000
85.27.0.0/16 01010101 00011011 00000000 00000000
85.28.0.0/16 01010101 00011100 00000000 00000000
85.29.0.0/16 01010101 00011101 00000000 00000000
85.30.0.0/16 01010101 00011110 00000000 00000000
85.31.0.0/16 01010101 00011111 00000000 00000000
Перші два октети (16 біт) є адресою підмережі. Оскільки перші 16 біт
адреси кожної з цих восьми підмереж унікальні, то класовий маршрутизатор
бачить вісім унікальних мереж і повинен створити рядок в таблиці маршрутів
для кожної з цих підмереж.
Проте ці вісім адрес підмереж мають загальну частину: перші 13 біт
однакові. CIDR-сумісний маршрутизатор може підсумовувати маршрути до
цих восьми підмереж, використовуючи загальний 13-бітовий префікс в
адресах: 0101010100011. Для зображення цього префікса в десятковій формі
доповнимо його справа нулями:
01010101 00011000 00000000 00000000 = 85.24.0.0;
13-бітова маска підмережі має вигляд
11111111 11111000 00000000 00000000 = 255.248.0.0.
Отже, одна адреса і одна маска визначають безкласовий префікс, який
підсумовує маршрути до восьми підмереж : 85.24.0.0/13.
102
Supernetting та subnetting
Supernetting – це практика використання бітової маски для групування

декількох класових мереж у вигляді однієї мережної адреси. Supernetting і
агрегація маршрутів є різними іменами одного процесу. Проте термін
supernetting частіше застосовується, коли мережі, що агрегуються,
знаходяться під загальним адміністративним управлінням. Supernetting бере
біти з мережної порції маски, а subnetting – з порції маски, що відноситься до
хоста. Supernetting і агрегація маршрутів є інверсним поняттям по
відношенню до subnetting.
Оскільки мережі класів А і В вичерпані, то організації вимушені
запрошувати у провайдерів декілька мереж класу С. Якщо компанія отримує
блок безперервних адрес в мережах класу С, то можна використовувати
supernetting, і усі адреси в компанії лежатимуть в одній більшій мережі або
надмережі.
Розглянемо компанію, яка потребує адреси для 400 хостів. При
класовій адресації компанія повинна запитати у центральної Інтернет-служби
InterNic – мережу класу В. Якщо компанія отримає таку мережу, то десятки
тисяч адрес в ній не використовуватимуться. Альтернативою є отримання
двох мереж класу С, що дає 254*2= 504 адреси для хостів. Недолік цього
підходу полягає в необхідності підтримки маршрутизації для двох мереж.
При безкласовій адресній системі supernetting дозволяє компанії
отримати необхідний адресний простір з мінімальною кількістю невживаних
адрес і без збільшення розміру таблиць маршрутизації. Використовуючи
CIDR, компанія запрошує блок адрес у свого Інтернет-провайдера, а не у
центральної Інтернет-служби InterNic. Провайдер визначає потреби компанії
і виділяє адресний простір зі свого адресного простору. Провайдер бере на
себе управління адресним простором у своїй внутрішній безкласовій системі.
Усі зовнішні Інтернет-маршрутизатори містять маршрути, що тільки
підсумовують адресні простори до мережі провайдера. Провайдер сам
підтримує маршрути, більш специфічні для своїх клієнтів, включаючи
компанію. Цей підхід істотно зменшує розміри таблиць маршрутів для усіх
маршрутизаторів в Інтернет.
103
Нехай компанія отримала у провайдера дві мережі класу C, адреси в
яких безперервні: 207.21.54.0 і 207.21.55.0.
207.21.54.0 110001111 00010101 00110110 00000000

207.21.55.0 110001111 00010101 00110111 00000000
З цієї таблиці видно, що адреси мають загальний 23-бітовий префікс

11001111 00010101 0011011. Доповнюючи префікс справа нулями 11001111
00010101 00110110 00000000, отримаємо надмережу з 23-бітовою маскою
207.21.54.0/23.
Провайдер надає мережу компанії зовнішньому світу як мережу
207.21.54.0/23.
CIDR дозволяє провайдерам ефективно розподіляти і підсумовувати
безперервні простори IP-адрес.
VLSM
Маска змінної довжини VLSM (Variable Length Subnet Mask) дозволяє

організації використовувати більш ніж одну маску підмережі усередині того
самого мережного адресного простору. Реалізацію VLSM часто називають
«підмережі на підмережі».
Розглянемо підмережі, створені шляхом запозичення трьох перших біт
з хостової порції адреси класу С 207.21.24.0.
Підмережа Адреса Підмережа Адреса

підмережі підмережі
0 207.21.24.0/27 4 207.21.24.128/27
1 207.21.24.32/27 5 207.21.24.160/27
2 207.21.24.64/27 6 207.21.24.192/27
3 207.21.24.96/27 7 207.21.24.224/27
Ми отримали вісім підмереж, кожна з який може містити не більше 30

хостів.
Кожне з’єднання через послідовний інтерфейс вимагає для себе дві
адреси із окремої підмережі. Використання для цього будь-якої з підмереж
104
/27 призведе до втрати адрес. Для створення підмережі з двох адрес краще за
все підходить 30-бітова маска. Це якраз те, що потрібно для послідовного
з’єднання. Розіб’ємо одну з підмереж 207.21.24.192/27 на вісім підмереж,
використовуючи 30-бітову маску.
Підмережа Адреса Підмережа Адреса

підмережі підмережі
0 207.21.24.192/30 4 207.21.24.208/30
1 207.21.24.196/30 5 207.21.24.212/30
2 207.21.24.200/30 6 207.21.24.220/30
3 207.21.24.204/30 7 207.21.24.224/30
Тобто кожну з тих семи підмереж /27, що залишилися, можна

використовувати для адресації хостів в семи локальних мережах. Ці локальні
мережі можна зв’язати в глобальну мережу з допомогою не більше ніж
восьми послідовних з’єднань з наших восьми мереж.
Щоб в мережах з VLSM правильно здійснювалася маршрутизація
маршрутизатори повинні обмінюватися інформацією про маски в
підмережах.
Використання CIDR і VLSM не лише запобігає марній траті адрес, але і
сприяє агрегації маршрутів або підсумовуванню. Без підсумовування
маршрутів Інтернет перестав би розвиватися вже наприкінці 90-х років. Для
правильної роботи підсумовування маршрутів слід ретельно підходити до
призначення адрес: адреси, що підсумовуються, повинні мати однакові
префікси.
Нехай провайдер виділив підприємству мережу класу С

192.168.18.0/24. Топологія мережі підприємства наведена на рис. 7.1.
Потрібно розділити дану мережу на три підмережі з кількістю вузлів в
кожній, відповідно 100, 60, 30 хостів (див. рис. 7.1).
Для підтримки 100 хостів в підмережі необхідні мінімум сім біт у
восьмибітовій хостовій частині адреси (27 = 128).
105
Таким чином за допомогою маски /25 маємо дві підмережі:
192.168.18.0 та 192.168.18.128, кожна з яких містить по 27 – 2 = 126 адрес
хостів. Друга підмережа може бути використана для адресації в мережі, що
потребує 100 хостів.
Далі з підмережі 192.168.18.0/25 за допомогою маски /26 можна
отримати ще дві підмережі: 192.168.18.0/26 та 192.168.18.64/26. Кожна
підмережа містить 26 – 2 = 62 адреси хостів. Мережа 192.168.18.64/26
використовується для адресації мережі з 60 хостами.
Підмережа 192.168.18.0/26 знову за допомогою маски /27 розбивається
на дві підмережі: 192.168.18.0/27 та 192.168.18.32/27. Кожна з підмереж
містить 25 – 2 = 30 адрес хостів. Тобто підмережа 192.168.18.32/27
використовується для адресації в мережі з 30 хостами.
Тепер необхідно організувати зв’язок між маршрутизаторами. Для
цього також необхідні ІР-адреси. Після розбиття залишилася підмережа
192.168.18.0/27, що має 30 адрес хостів. Для зв’язку маршрутизаторів
достатньо мати три підмережі, кожна з яких містить 2 реальні адреси (тобто
повинні мати маску /30) (див. рис. 7.1). Таким чином можна розділити
підмережу 192.168.18.0/27 на дві підмережі, а потім одну з підмереж
розділити на 4. Отже маємо такі адреси мереж:
№ ІР-адреса мережі Мережа

1 192.168.18.128/25 Cisco2 – C3
2 192.168.18.64/26 Mikrotik1 – C1
3 192.168.18.32/27 Mikrotik2 – C2
4 192.168.18.16/28 не використовується
5 192.168.18.0/30 Cisco2 (s0/0)
5 192.168.18.4/30 Cisco2 – Mikrotik1
6 192.168.18.8/30 Cisco2 – Mikrotik2
7 192.168.18.12/30 не використовується
106
Після розбиття отримуємо дві підмережі (4 та 7), що можуть бути

використані в майбутньому.
Задаємо ІР-адреси для відповідних пристроїв на топології 7.1.
На маршрутизаторі Cisco1:
Cisco1>en
Cisco1#conf t
Cisco1(config)#int s0/0
Cisco1(config-if)#ip address 192.168.18.1 255.255.255.0
Cisco1(config-if)#no sh
На маршрутизаторі Cisco2:
Cisco2>en
Cisco2#conf t
Cisco2(config)#int s0/0
Cisco2(config-if)#ip ad 192.168.18.2 255.255.255.252
Cisco2(config-if)#int e1/2
107
Cisco2(config)#ip route 0.0.0.0 0.0.0.0 192.168.18.1
Налаштування протоколу RIPv2:

Cisco2(config)#router rip
Cisco2(config-router)#no auto-summary
Cisco2(config-router)#version 2
Cisco2(config-router)#network 192.168.18.4
Cisco2(config-router)#
На маршрутизаторі Mikrotik1:
[admin@MikroTik] > ip ad add address=192.168.18.6/30 interface=ether1

[admin@MikroTik] > ip ad add address=192.168.18.65/26 interface=ether2
[admin@MikroTik] > ip route ad gateway=192.168.18.5
[admin@MikroTik] > routing rip network add network=192.168.18.4/30

[admin@MikroTik] > routing rip network add network=192.168.18.64/26
На маршрутизаторі Mikrotik2:
[admin@MikroTik] > ip ad ad ad=192.168.18.10/30 interface=ether2

[admin@MikroTik] > ip ad ad ad=192.168.18.33/27 interface=ether3
[admin@MikroTik] > routing rip

[admin@MikroTik] /routing rip> network add network=192.168.18.8
[admin@MikroTik] /routing rip> network add network=192.168.18.32
Налаштування ІР-адрес в VPCS:

VPCS[1]> ip 192.168.18.66/26 192.168.18.65
VPCS[1]> 2
VPCS[2]> ip 192.168.18.34/27 192.168.18.33
VPCS[2]> 3
VPCS[3]> ip 192.168.18.130/25 192.168.18.129
108
Таблиці маршрутизації:
на Cisco2:
на Mikrotik1
на Mikrotik2
109
Команда ping між C2 і С1, С2 і С3 та С2 і Cisco1:
1. Навіщо потрібна маска?

2. Що таке CIDR?
3. Що таке VLSM?
4. Як без використання класів IP-адрес в IP-адресі виділяють адресу
хоста і адресу підмережі?
5. Чому дорівнює число доступних адрес в підмережі?
6. За заданим викладачем числом хостів в підмережі визначте
мінімальну маску.
7. Які форми запису маски ви знаєте?
8. Яку маску рекомендують використовувати для мережі послідовного
з’єднання і чому?
9. Як CIDR і VLSM сприяють економному використанню адресного
простору?
10. Що таке supernetting та subnetting?
11. Що таке агрегація маршрутів і як вона сприяє зменшенню таблиць
маршрутів на маршрутизаторах?

2. Здати викладачеві теорію роботи, відовівши на контрольні питання.
5. Захистити звіт .
110

1. Згідно з отриманим варіантом оберіть топологію (рис. 7.2, рис. 7.3)
та виконайте розбиття мережі на підмережі. Локальна мережа подається у
вигляді комутатора з одним комп’ютером.
2. Наведіть скріншоти таблиць маршрутизації кожного
маршрутизатора.
3. Наведіть скріншоти виконання команди ping між пристроями, що
знаходяться в різних локальних мережах.
Рисунок 7.2 - Варіант топології №1
Рисунок 7.3 – Варіант топології №2
111

2. Скріншот топології згідно з завданням з зазначенням на ньому ІР-
адрес усіх інтерфейсів відповідно до отриманого варіанта.
112
БАЛАНСУВАННЯ КАНАЛІВ
Ознайомлення з принципами балансування каналів та набуття

практичних навичок налаштування на маршрутизаторах функцій розподілу
мережного трафіку.
Агрегування каналів (агрегація каналів, англ. – link aggregation) –

технологія, що дозволяє об’єднати кілька фізичних каналів в один логічний.
Таке об’єднання дозволяє збільшувати пропускну здатність і надійність
каналу. Агрегування каналів може бути настроєне між двома комутаторами,
між комутатором і маршрутизатором, між комутатором і хостом.
Засоби mangle дозволяють маркувати IP-пакети спеціальними мітками.
Ці мітки використовуються для ідентифікації пакетів різним устаткуванням
маршрутизатора. На додаток, слід зазначити, що засоби mangle
використовуються для зміни деяких полів у заголовку IP, таких як, TOS
(DSCP) і TTL.
Рівень меню: /ip firewall mangle
Mangle – це «маркер», що маркує пакети спеціальними мітками для
подальшої обробки. Багато інших засобів в RouterOS використовують ці
маркери. Наприклад, дерева черг і NAT. Вони ідентифікують пакети за
їхними маркерами і відповідно обробляють їх. Маркери mangle
використовуються тільки маршрутизатором, вони не передаються мережею.
Опис властивостей засобу Mangle:

action (accept | add-dst-to-address-list | add-src-to-address-list | change-
dscp | change-mss |change-ttl | jump | log | mark-connection | mark-packet | mark-
routing | passthrough | return | set -priority | strip-ipv4-options; за
113
замовчуванням: accept) – дія, що виконується, якщо пакет відповідає
правилу:
• accept – прийняти пакет. Нічого не робити. Пакет проїде через
маршрутизатор і жодне правило не буде застосоване до нього;
• add-dst-to-address-list – додати адресу призначення IP-пакета в список
адрес;
• add-src-to-address-list – додати адресу джерела IP-пакета в список
адрес;
• change-ttl – зміна значення поля часу життя пакета на значення, що
відповідає параметру new-ttl;
• jump – перехід у ланцюжок, що відповідає значенню параметра jump-
target;
• log – кожна відповідність цій дії буде додавати повідомлення в
системний журнал;
• mark-connection – маркування, яке відповідає параметру new-
connection на всьому з'єднанні, що відповідає правилу;
• mark-packet – маркування, яке відповідає параметру new-packet-mark
на пакеті, що відповідає правилу;
• mark-routing – маркування пакета відповідно до параметра new-
routing-mark. Цей вид маркування використовується тільки для політики
маршрутизації;
• passthrough – ігнорувати це правило й перейти до наступного;
• return – ігнорувати це (поточне) правило й перейти до наступного.
address-list (name) – ім’я зі списку адрес, у якому зібрані IP-адреси за
правилом action=add-dst-to-address або action=add-src-to-address-list. Цей
список адрес згодом може бути використаний для узгодження пакетів;
address-list-timeout (time; за замовчуванням: 00:00:00) – інтервал,
після закінчення якого адреса буде вилучена зі списку адрес з параметром
address-list. Використовується сукупно з дією add-dst-to-address-list або add-
src-to-addresslist:
• 00:00:00 – залишає адресу в списку адрес назавжди;
chain (forward | input | output | postrouting | prerouting) – ланцюжок для
додавання в нього певного правила. Якщо певний трафік йде через певні
114
ланцюжки, то будьте обережні у виборі ланцюжка для нового правила. Якщо
при введенні ім’я не відповідає вже існуючому ланцюжку, буде створений
новий ланцюжок.
connection-bytes (integer-integer) – відповідність пакетів у випадку,
якщо певна кількість байт була передана через певне з’єднання:
• 0 – нескінченність. Наприклад, connection-bytes=2000000-0;
використовується це правило, якщо більш ніж 2Мб було передано через
обране з’єднання.
connection-limit (integernet-mask) – обмежити кількість з’єднань за
адресою або за блоком адрес.
content (text) – текст, що повинні містити пакети для відповідності
правилу.
dst-address (IP/netmask | IP range) – певний діапазон адрес, яким може
бути призначений IP-пакет.
dst-address-list (name) – відповідність призначеної адреси пакета
списку адрес, визначених користувачем.
dst-address-type (unicast | local | broadcast | multicast) – відповідність
адреси призначення IP-пакета одному з типів:
• unicast – IP-адреси для передачі типу точка-точка. У цьому випадку
існує тільки один відправник і один одержувач;
• local – відповідність адрес, заданих інтерфейсам маршрутизатора;
• broadcast – IP-пакет, що посилається від однієї точки до інших точок
IP-підмережі;
• multicast – даний тип IP-адресації призначений для передачі від однієї
або більше точок до інших точок.
limit (integer-time-integer) – обмежує інтенсивність пакетів відповідно
до заданого ліміту. Використовується для зменшення кількості записів у
системному журналі:
• count – максимальна середня інтенсивність пакетів, яка виміряється в
пакетах за секунду (pps), якщо не супроводжується опцією Time;
• time – визначає часовий інтервал, протягом якого буде відбуватися
вимір інтенсивності пакетів;
• burst – кількість пакетів, що відповідають піку.
115
new-ttl (decrement | increment | setinteger) – визначення нового значення
поля TTL, використовується в парі з action=change-ttl:
• decrement – значення поля TTL буде декрементоване на зазначене
значення;
• increment – значення поля TTL буде інкрементоване на зазначене
значення;
• set: – значення поля TTL буде встановлене в зазначене значення.
nth (integer, integer) – певний Nth пакет, отриманий відповідно до
правила.
out-interface (name) – інтерфейс, через який пакет залишає
маршрутизатор.
packet-size(integer: 0..65535 - integer: 0..65535) – відповідність пакета
певному розміру або діапазону розмірів, зазначених у байтах:
• min – значення, що визначає нижню границю діапазону або конкретне
значення;
• max – значення, що визначає верхню границю діапазону.
passthrough(yes | no; за замовчуванням: yes) – чи дозволено пакету
проходити далі, після маркування заданою міткою.
protocol (ddp | egp | encap | ggp | gre | hmp | icmp | idrp -cmtp | igmp |
ipencap | ipip | ipsec -ah |ipsec-esp | iso-tp4 | ospf | pup | rdp | rspf | st | tcp | udp |
vmtp | xns -idp | xtp | integer) – відповідність частці IP-протоколу,
обумовленому за ім’ям або за номером. Для визначення портів необхідно
визначити протокол.
routing-mark (name) – відповідності пакетів, відзначених специфічною
міткою маршруту.
src-address (IP-addressnetmask-IP-address-IP-address) – визначає
діапазон адрес, від яких прийшов IP-пакет. Примітка: консоль конвертує
уведення значення address/netmask у дійсну адресу, тобто 1.1.1.1/24
конвертується в 1.1.1.0/24.
src-address-list (name) – відповідність адреси джерела пакета списку
адрес, визначеному користувачем.
src-mac-address (MAC-address) – MAC-адреса джерела.
116
time (timetimesat | fri | thu | wed | tue | mon | sun) – дозволяє створити
фільтр, заснований на даті й часі надходження пакета або на даті й часі
відправлення для локально згенерованих пакетів.
Створіть топологію, зображену на рис. 8.1. Усі маршрутизатори фірми

Mikrotik.
Рисунок 8.1 - Топологія практичної частини
1. Налаштуйте ІР-адреси відповідно до топології рис. 10.1.

[admin@MikroTik] > system identity set name=R1
[admin@R1] > ip ad ad address=1.1.2.1/24 interface=ether1
Балансування пакетів
На маршрутизаторах R1, R3 та R4 задайте маршрути за замовченням на

маршрутизатор R2.
117
[admin@R3] > ip route add gateway=1.2.3.2,2.2.3.2
Додайте правила брандмауера, в яких поставте різне маркери для
кожного першого та другого з двох пакетів. (Параметр passthrough=no вказує
на те, що пакет буде виключений з подальшої обробки за правилами
брандмауера):
[admin@R2] >ip firewall mangle add chain=prerouting action= \
mark-routing new-routing-mark=gw1 passthrough=no nth=2,1
[admin@R2] >ip firewall mangle add chain=prerouting action= \
mark-routing new-routing-mark=gw2 passthrough=no nth=2,2
Пакети отримують номери 1, 2, 1, 2, 1, 2. Кожен перший отримує
маркер gw1 (nth=2,1 – тобто з 2 пакетів перший), кожен другий – gw2
(nth=2,2 – тобто з 2 пакетів другий).
Додайте маршрутизацію:
[admin@R2] > ip route add gateway=2.2.3.3 routing-mark=gw1
[admin@R2] > ip route add gateway=1.2.3.3 routing-mark=gw2
Тобто якщо у пакета маркування gw1, то він повинен
маршрутизуватися на шлюз 2.2.3.3, в іншому випадку – на шлюз 1.2.3.3.
Запустіть на R1 або R4 тест на ширину смуги пропускання убік адреси
1.2.3.3 або 2.2.3.3:
[admin@R1] > tool bandwidth-test address=2.2.3.3
На R2 запускаємо моніторинг використання інтерфейсів:
[admin@R2] > int monitor-traf interf=ether1,ether2,ether3,ether5
Рисунок 8.2 – Моніторинг трафіку на інтерфейсах
118
Балансування з’єднань
Наступним кроком буде організація балансування трафіку між

зовнішніми каналами шляхом балансування з’єднань. Для цього необхідно
видалити мангли та створити нові, що будуть маркувати пакети у парних і
непарних за порядком з’єднання:
[admin@R2] >ip firewall mangle rem 0,1
[admin@R2] >ip firewall mangle add chain=prerouting \
action=mark-connection new-connection-mark=1con \
per-connection-classifier= src-address-and-port:2/0
action=mark-connection new-connection-mark=2con \
per-connection-classifier= src-address-and-port:2/1
Також необхідно видалити маршрути убік R3 та додати нові, що будуть
відправляти всі пакети з непарних з’єднань по першому каналу, а з парних –
по другому:
[admin@R2] >ip route rem 0,1
[admin@R2] >ip route add gateway=1.2.3.3 routing-mark=1con
[admin@R2] >ip route add gateway=2.2.3.3 routing-mark=2con
Таблиця маршрутизації на R3 така сама, як у попередньому варіанті
балансування.
Таким чином виконується розподіл трафіку по каналах від різних
джерел.
Балансування каналів
Для відправки трафіку від R1 крізь перший канал, а від R4 – через

другий, необхідно виконати такі дії: видаліть мангли на R2 та створіть нові:
[admin@R2] >ip firewall mangle rem 0,1
action=mark-routing new-routingmark=1.1.2.0in src-address=1.1.2.0/24
action=mark-routing new-routingmark=1.4.2.0in src-address=1.4.2.0/24
Також необхідно видалити існуючі статичні маршрути у бік R3 (ті, що
з позначкою routing-mark) та додайте нові. Пакети будуть відправлятися на
той чи інший інтерфейс, залежно від отриманої позначки:
[admin@R2] > ip ro rem 0,1
[admin@R2] > ip ro add gateway=1.2.3.3%ether1 routing-mark=1.1.2.0in
[admin@R2] > ip ro add gateway=2.2.3.3%ether2 routing-mark=1.4.2.0in
119
На маршрутизаторі R3 слід видалити існуючий маршрут убік R2 та
створити 2 нових:
[admin@R3] > ip ro rem 0
[admin@R3] > ip ro add dst-address=1.1.2.0/24 gateway=1.2.3.2
[admin@R3] > ip ro add dst-address=1.4.2.0/24 gateway=2.2.3.2
Правильність налаштувань перевіряється шляхом запуску тесту на
ширину смуги пропускання по черзі на R1 і на R4 на адрес 1.2.3.3 та
моніторингу навантаження інтерфейсів на R2.
Обмеження полоси пропускання для R1:
[admin@R2]> queue simple add name=private1 target-addresses=1.1.2.0/24
max-limit=256K/512K interface=ether2
[admin@R2]> queue simple add name=private2 dst-address=1.1.2.0/24 max-
limit=256K/512K interface=ether2
[admin@R2]> queue simple add name=private3 target-addresses=1.1.2.0/24
max-limit=256K/512K interface=ether1
[admin@R2]> queue simple add name=private4 dst-address=1.1.2.0/24 max-
limit=256K/512K interface=ether1
1. Які завдання вирішує агрегація каналів?

2. Для чого використовується параметр chain?
3 Як виконується балансування пакетів?
4. Як виконується балансування з’єднань?
5. Як виконується балансування каналів?
6. Що означає параметр nth?
7. Як протестувати полосу пропускання каналу?
8. Як виконати обмеження полоси пропускання?

120
Варіанти топологій (рис. 8.3) обираються за номером по списку у

журналі групи як остача ділення на 3.
Для налаштування маршрутизатора Gateway скористайтеся наступними
способами налаштування:
N%3 0 1 2
1. Виконайте налаштування відповідного способу балансування для

заданої топології (табл. 8.1).
Рисунок 8.3 – Топології для індивідуального завдання
121
Таблиця 8.1 – Варіанти для індивідуального завдання
Топологія
№1 №2 №3
Розподіл зовн. каналів
Балансування каналів 1 2 3
Балансування пакетів 4 5 6
Балансування з’єднань 7 8 9

Net1 N.m.d.0/24 Net4 N.m*2.d.0/24
Net2 N+1.m.d.0/24 Net5 N.m*2.d+1.0/24
Net3 N+2.m.d.0/24 Net6 N.m*2.d+2.0/24
Тут N, m, d – відповідно номер по списку, місяць та день народження

студента.
2. Виконайте обмеження смуги пропускання для першої мережі на
рівні N*128Кб/N*64Кб.
3. Наведіть скріншоти з WinBox для Gateway, які підтверджують
працездатність відповідного способу балансування та обмеження смуги
пропускання.

2. Скріншот топології рис. 8.3 з зазначенням на ньому ІР-адрес усіх
3. Команди налаштування кожного маршрутизатора.
4. Скріншоти, які підтверджують працездатність відповідного способу
балансування та обмеження смуги пропускання.
122
ПЕРЕДАЧА НА КАНАЛЬНОМУ РІВНІ. ПРОТОКОЛ STP
Ознайомлення з принципами роботи мережних пристроїв на

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

пристроєм. Всі мережні пристрої можна віднести до таких груп:
• пристрої кінцевого користувача (кінцеві вузли, станції) – це при-
строї, що зв’язують користувачів з мережею, фізично під’єднуючись до неї за
допомогою мережного адаптера або плати мережного інтерфейсу (Network
Interface Card, NIC). До цієї групи входять комп’ютери, принтери, сканери та
інші пристрої, які виконують функції, безпосередньо призначені для
користувача мережі;
• мережні пристрої – це пристрої, що приєднані до пристроїв
кінцевих користувачів і що дозволяють їм здійснювати зв’язок. Вони
забезпечують транспортування даних між пристроями кінцевих користувачів,
продовжують і об’єднують кабельні з’єднання, перетворюють дані з одного
формату в іншій та керують передаванням даних. Прикладами таких
пристроїв є повторювачі, концентратори, мости, комутатори і
маршрутизатори.
Повторювачі
Локальні комп’ютерні мережі об’єднують між собою багато пристроїв

різних типів. Існує багато різних середовищ передавання даних, кожне з яких
має свої переваги і недоліки. Наприклад, одним з недоліків кабелю категорії
5 UTP (який на сьогоднішній день є найчастіше використовуваним) є
123
обмеження на його довжину. Так, максимальна довжина кабелю UTP для
одного сегмента мережі складає 100 м. Якщо потрібна більша відстань, то
слід використовувати повторювачі. У більшості сучасних мереж Ethernet
замість повторювачів використовуються комутатори, іноді ще можна
зустріти і концентратори (багатопортові повторювачі).
Призначення повторювачів полягає в регенерації і ресинхронізації
мережних сигналів на бітовому рівні для того, щоб вони могли пройти
більшу відстань по середовищу, в якому виконується передавання.
Повторювачі зазвичай використовуються в тих випадках, коли в мережі
є дуже багато вузлів або коли довжини наявного кабелю недостатньо для
досягнення віддалених робочих станцій.
Функції, призначення та класифікація концентраторів
Концентратори (hub) – це багатопортові повторювачі. Використання

концентратора перетворює мережну топологію з шинної в зіркоподібну
(мається на увазі фізична топологія, логічна залишається шиною).
Концентратори належать до одного з таких типів:
• активний концентратор – повинен бути під’єднаний до джерела
зовнішнього живлення, оскільки йому потрібна енергія для посилення
вхідного сигналу перед передаванням його на зовнішні порти;
• інтелектуальний концентратор (smart hubs) – функціонує як
звичайний концентратор, однак він має вбудований мікропроцесор і має
можливості діагностики. Він дорожчий за звичайний концентратор, проте
корисний в аварійних ситуаціях;
• пасивний концентратор – виступає виключно як точка фізичного
з’єднання пристроїв. Такий концентратор не перевіряє трафік, що проходить
через нього, і не виконує ніяких дій з потоками даних; він не підсилює і не
очищає сигнал, а лише надає доступ до загальної шини.
Основи функціонування мостів
Велику ЛКМ часто потрібно поділяти на менші, легкокеровані

сегменти. При цьому пристроями використовуваними для з’єднання
мережних сегментів, можуть бути мости, комутатори, маршрутизатори і
124
шлюзи. Мости і комутатори функціонують на канальному рівні моделі OSI.
Функція моста полягає у визначенні того, чи потрібно відправляти сигнали,
що надійшли на один з його портів, в інший сегмент мережі. Мости можуть
також бути використані для з’єднання мереж, що використовують різні
протоколи або різні середовища передавання.
Під час роботи міст використовує метод прозорого перенаправлення.
Цей метод описаний у специфікації ІЕЕЕ 802.1d, яка визначає п’ять процесів
оброблення кадру (frame) при проходженні через міст (рис. 9.1):
1. Перенаправлення кадрів (forwarding).
2. Лавинне передавання кадрів (flooding).
3. Фільтрування кадрів (filtering).
4. Комутація з вивченням топології або з самонавчанням (learning).
5. Застарівання таблиці МАС-адрес (aging).
Рисунок 9.1 – Кроки методу прозорого мостового перенаправлення
125
Коли міст отримує фрейм, він порівнює MAC-адресу відправника з
адресною таблицею, що є в нього, для визначення того, чи слід цей кадр
відфільтрувати (відкинути), надіслати його лавинним способом або у
визначений сегмент мережі.
Прийняття цього рішення відбувається таким чином:
• якщо пристрій-одержувач знаходиться в тому ж сегменті, з якого
цей кадр був отриманий, то міст запобігає його передаванню в інші сегменти.
Цей процес називається фільтруванням (filtering);
• якщо пристрій-одержувач знаходиться в іншому сегменті і його
адреса присутня в адресній таблиці, то міст пересилає кадр у відповідний
сегмент;
• якщо пристрій-одержувач відсутній в таблиці адрес (тобто
"невідомий" мосту) або кадр є широкомовний чи багатоадресний, то міст
розсилає кадр у всі сегменти, за винятком того, звідки був отриманий кадр.
Таку поведінку називають лавинним розсиланням.
Стратегічно правильно встановлений міст може значно збільшити
продуктивність мережі.
Режими комутації
Під час роботи мостів передбачається кілька режимів комутації. Вони

відрізняються моментом, коли слід комутувати кадр. Найчастіше
використовуються три режими комутації:
• з проміжним зберіганням (Store-and-Forward);
• наскрізий (Cut-through);
• з контролем фрагментів (Fragment free).
Моменти часу, в які відбувається комутація для цих режимів, наведені
на рис. 9.2. Кожен з цих режимів має свої переваги та недоліки. Наприклад,
наскрізна комутація характеризується максимальною швидкодією, але
неможливістю аналізу фактів викривлень кадрів. Комутація з проміжним
зберіганням, навпаки, характеризується меншою швидкістю, проте
можливістю аналізу кадрів. При цьому, якщо кадр викривлений, то він
відкидається комутатором, а отже, заощадливіше використовується
пропускна спроможність каналів. Комутація з контролем фрагментів займає
126
проміжне місце за рівнем контролю і швидкістю і дозволяє відкидати лише ті
кадри, розмір яких менше 64 байтів і які виникають внаслідок колізій. Ряд
мостів підтримують усі ці режими і дозволяють автоматично вибирати їх
залежно від особливостей роботи мережі.
Рисунок 9.2 – Режими комутації
Проблеми у роботі мережі на основі мостів/комутаторів
У мережах на основі комутаторів з надлишковими елементами, які

використовуються для підвищення надійності мережі (без застосування
протоколу STP) можливе виникнення таких проблем:
• широкомовні шторми;
• викривлення інформації у таблицях МАС-адрес комутаторів.
Розглянемо детальніше ці проблеми.
Широкомовний шторм – це процес нескінченного циркулювання
широкомовних кадрів у петлях мережі на основі комутаторів. Такі шторми
обумовлені тим, що комутатори надсилають широкомовні повідомлення в усі
порти, за виключенням того, від якого це повідомлення було отримане. Так,
коли станція А надсилає широкомовний кадр у мережу, він потрапляє до
портів 1 обох комутаторів (рис. 9.3). Далі ці комутатори надсилають цей кадр
один одному через порти 2. І так далі. Отже, у мережі будуть нескінченно
циркулювати широкомовні кадри в обох напрямках (за та проти
годинникової стрілки). Широкомовні кадри значно знижують пропускну
спроможність мережі, а в ряді випадків роблять її взагалі непрацездатною.
Викривлення інформації у таблицях МАС-адрес комутаторів – це
процес нескінченного циркулювання одноадресних повідомлень у петлях
мережі на основі комутаторів.
127
Припустимо, наприклад, що станція А має запис про станцію В в
таблиці ARP і надсилає одноадресний пакет ping до станції В. Станція В
тимчасово від’єднана від мережі, і відповідний запис в таблиці комутатора
був вилучений. Припустимо, що обидва комутатори не використовують
протокол STP. Тоді кадр надходить на порти 1 обох комутаторів. Розглянемо
ситуацію щодо моста SW1. Оскільки станція B знаходиться в несправному
стані, то в таблиці моста SW1 немає записів про МАС-адресу ВВ-ВВ-ВВ-ВВ-
ВВ-ВВ, і тому SW1 пропускає одержаний кадр далі в мережу. SW2 через
порт 2 одержує фрейм відправлений SW1. Це призводить до виникнення
двох таких ситуацій:
Рисунок 9.3 – Мережа на основі комутаторів з елементами надлишковості
1. У таблиці SW2 немає запису з МАС-адресою ВВ-ВВ-ВВ-ВВ-ВВ-ВВ і

кадр надсилається далі на порт 1, що створює зворотну петлю і призводить
до непрацездатності мережі.
2. Комутатор SW2 одержує через порт 2 кадри з МАС-адресою
відправника АА-АА-АА-АА-АА-АА, а потім змінює запис в своїй таблиці
про МАС-адресу станції А з порту 1 на порт 2.
Оскільки кадри циркулюють у зворотному напрямі (як було показано
вище, петлі циркуляції фреймів існують в обох напрямах), то відбувається
циклічне змінення даних про МАС-адресу станції А з порту 1 комутатора
SW2 на порт 2.
128
Отже, одноадресні повідомлення не лише насичують мережу, а й
викривляють інформацію в МАС-таблицях комутаторів, що призводить до
порушення працездатності такої мережі. Для уникнення вище вказаних
проблем у мережах на основі мостів/комутаторів використовується протокол
зв’язуючого дерева.
Протокол зв’язуючого дерева STP та його модифікації
Протокол зв’язуючого дерева (Spanning Tree Protocol – STP) – це

протокол канального рівня, який використовується для підтримки такого
стану мережі, у якому в ній немає петель. STP засновано на одноіменному
алгоритмі, який розробила Радія Перлман (Radia Perlman). Потім комітет
IEEE 802 модернізував його та опублікував у вигляді специфікації IEEE
802.1d (в цій специфікації описується і сам алгоритм роботи прозорого
моста).
Для того щоб мережа була вільна від петель, комутатор при виявленні
петель автоматично здійснює логічне блокування одного або кількох
надлишкових портів. При цьому фізично у мережі петлі є, а логічно – немає.
Основні терміни протоколу STP
Ідентифікатор моста (BID - Bridge ID) – це восьмибайтове число, шість

молодших байтів якого – це МАС-адреса блоку керування моста, а два
старших байти – пріоритет моста.
Ідентифікатор порту (Port ID) моста – це двобайтове число, молодший
байт якого містить порядковий номер даного порту у комутаторі, а старший
задається вручну.
Кореневий міст (Root Bridge) – міст, що виконує функцію кореня
дерева.
Кореневий порт (Root Port) моста – порт, який має мінімальну відстань
до кореневого моста.
Призначений порт (Designated Port) моста – порт, який серед усіх
портів усіх мостів даного сегмента має мінімальну відстань до кореневого
моста.
129
Призначений міст (Designated Bridge) – це міст, якому належить
призначений порт даного сегмента.
Протокольні одиниці даних моста (BPDU - Bridge Protocol Data Unit) –
спеціальні пакети, якими періодично обмінюються мости для автоматичного
визначення конфігурації зв’язуючого дерева. Такі пакети несуть інформацію,
наприклад, про ідентифікатори мостів та портів, відстань до кореневого
моста тощо.
Функціонування STP
Після конвергенції мережі, тобто після закінчення роботи STP мережа

має одне зв’язуюче дерево, тобто виконуються такі умови:
• у мережі існує один кореневий міст;
• у кожного некореневого моста є один кореневий порт;
• у кожному сегменті є один призначений порт;
• усі інші порти (непризначені і некореневі) не використовуються.
Для пересилання даних використовуються лише кореневі та призначені
порти.
Алгоритм роботи протоколу STP має 3 етапи.
1. Вибір кореневого комутатора (Root Bridge - RB)
Зразу після завантаження кожен міст вважається кореневим. Всі мости

починають обмінюватись BPDU (за замовчуванням кожні 2 секунди). Під час
такого обміну міст з найменшим значенням ідентифікатора комутатора
призначається кореневим. Зазначимо, що усі мости за замовчуванням мають
ідентифікатори 32768.МАС, а отже, найменший ідентифікатор матиме міст з
мінімальною МАС-адресою. При цьому як кореневий може бути вибрано
будь-який міст, який може не бути «центром» мережі. Для раціонального
вибору кореневого моста варто змінити (зменшити) пріоритет (значення
старших двох байтів ВID) в того моста, який за бажанням адміністратора
повинен стати кореневим.
Кожен кадр BPDU (Bridge Protocol Data Unit) має такі поля:
1. Ідентифікатор протоколу (Protocol Identifier) – двобайтове поле,
яке завжди дорівнює нулю.
130
2. Версія STP протоколу (Protocol Version Identifier) – поле розміром
в 1 байт.
3. Тип BPDU (BPDU type) – поле розміром 1 байт, яке набуває
значення «0», якщо це конфігураційний BPDU (CBPDU), або «1», якщо це
TCN BPDU.
• CBPDU (Configuration Bridge Protocol Data Unit) – кадр, який
використовується для обчислення зв’язуючого дерева. Тобто, коли значення
дорівнює 0.
• TCNBPDU (Topology Change Notification Bridge Protocol Data
Unit) – кадр, який використовується, щоб повідомити інших про зміни в
топології. Тобто, коли значення дорівнює 1.
Простіше кажучи, якщо комутатор бачить, що сталася якась зміна в
топології (лінк відвалився, «помер» сусід і т.д.), він пускає BPDU зі
значенням «1» в поле BPDU Type. А далі працюють кадри зі значенням «0»,
щоб заново перебудувати дерево.
4. Прапори (Flags) – в цьому полі використовується тільки 1 байт. Ці
прапори застосовуються при зміні топології (біт «1») і при підтвердженні
топології (біт «8»).
5. Ідентифікатор кореневого моста (Root Identifier) – в цьому полі
міститься інформація про кореневий комутатор, а саме про його пріоритет і
MAC-адресу.
6. Відстань до кореневого моста (Root Path Cost) – тут міститься
сумарна вартість до кореневого комутатора.
7. Ідентифікатор моста (Bridge Identifier) – сюди комутатор-
відправник записує свої дані (пріоритет + MAC-адресу).
8. Ідентифікатор порту (Port Identifier) – сюди комутатор-відправник
записує ідентифікатор порту (тобто той, з якого цей BPDU вийде).
9. Час життя повідомлення (Message Age) – тут міститься часовий
інтервал (в секундах). Він потрібен для того, щоб розпізнати застарілі кадри і
відкинути іх. Його формує кореневий комутатор і встановлює в початкове
значення «0». Далі кожен наступний комутатор збільшує це значення на час
затримки. Як тільки це значення перевищить максимальне порогове
значення, воно буде відкинуте.
131
10. Максимальний час життя повідомлення (Max Age) – це поле
відповідає саме за максимальний час життя. Перевищивши його, комутатор
відкидає кадр.
11. Час вітання (Hello Time) – часовий інтервал, через який комутатор
посилає BPDU кадри. За замовчуванням це 2 секунди.
12. Затримка зміни станів (Forward Delay) – часовий інтервал, який
вказує, скільки секунд порт комутатора буде перебувати в стані
прослуховування і навчання.
Всі BPDU розсилаються кожним комутатором на спеціальну
мультикастову МАС-адресу 01:80:С2:00:00:00.
2. Вибір кореневих портів (Root Port - RP)
Кожен некореневий міст повинен мати кореневий порт. Як кореневий

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

спроможностей каналів
Якщо кілька портів мають однакову кореневу вартість, то вибирається

порт з найменшим значенням ідентифікатора.
3. Вибір призначених портів (Designated Port – DP)
Для кожного сегмента протокол STP вибирає один призначений порт.

Призначеним портом стає той, який має найменшу оцінку маршруту до
132
кореневого комутатора. Комутатор, у якого вибрано призначений порт для
даного сегмента, називається призначеним комутатором.
У кореневого комутатора усі порти є призначеними (винятком є лише
ситуація, коли деякі порти кореневого комутатора утворюють фізичні петлі).
Порти, які не стали кореневими та призначеними, блокуються і
здійснюють логічне розірвання петель у мережі.
Математично доведено, що в результаті функціонування даного
алгоритму для мережі отримуємо покривне дерево.
Приклад роботи протоколу STP
Розглянемо покроково роботу протоколу STP на прикладі простої

мережі, наведеної на рис. 10.4.
1. Вибір кореневого комутатора. Оскільки пріоритети трьох
комутаторів однакові (32768), то кореневим стає комутатор з найменшою
МАС-адресою, тобто комутатор SW1.
Рисунок 9.4 – Приклад роботи протоколу STP
2. Вибір кореневих портів. Оскільки кожен некореневий комутатор

повинен вибрати кореневий порт, який має найменшу кореневу вартість, то
такими кореневими портами стануть порти 1 комутаторів SW2 та SW3,
оскільки коренева вартість кожного з них дорівнює 19 (кореневі вартості
портів 2 комутаторів SW2 та SW3 19 + 19 = 38).
133
3. Вибір призначених портів. Оскільки кожен сегмент у мережі
повинен мати один призначений порт, то такими портами для лівого і
правого сегментів мережі стають відповідно порти 1 і 2 комутатора SW1
(оскільки мають найменшу кореневу вартість). Для нижнього сегмента
призначеним було обрано порт 2 комутатора SW2. Це пояснюється тим, що
кореневі вартості портів 2 комутаторів SW1 та SW2 мають однакове
значення 19. У такому випадку вирішальним фактором стає значення
ідентифікатора відправника, а ідентифікатор комутатора SW2 менший, ніж
моста SW3. Порт, що залишився (порт 2 комутатора SW3), стає
непризначеним і переходить у стан блокування. Отже, тепер у мережі логічно
розірвано петлю.
Послідовність станів портів для STP
Є п’ять основних станів портів.

1. Стан блокування (Blocking) – кадри користувачів не пересилаються;
прослуховуються модулі BPDU.
2. Стан прослуховування (Listening) – кадри користувачів не
пересилаються, але прослуховуються. У цьому стані відбувається вибір
кореневого коммутатора, кореневих та призначених портів. Стан Listening не
переходить в наступний, навіть якщо Root Bridge визначено. Даний стан
порту триває протягом Forward delay timer, який, за замовчуванням,
дорівнює 15. Чому завжди треба чекати 15 секунд? Це викликано
обережністю протоколу STP, щоб випадково не був вибраний некоректний
Root Bridge. Після закінчення цього періоду порт переходить в наступний
стан.
3. Стан вивчення топології (Learning) – кадри користувачів не
пересилаються, але вивчаються адреси інших пристроїв та заповнюється
таблиця МАС-адрес. Перехід в наступний стан також займає Forward delay
timer.
4. Стан пересилання (Forwarding) – кадри користувачів пересилаються,
а також вивчаються адреси інших пристроїв та заповнюється таблиця МАС-
адрес.
5. Стан від’єднання – фрейми користувачів та BPDU не пересилаються.
134
На рис. 9.5 наведено послідовність станів портів, на яких працює
протокол STP.
Рисунок 9.5 – Послідовність станів портів для протоколу STP
Спочатку усі порти комутатора знаходяться у стані блокування. Для

переходу у стан пересилання потрібен час від 30 до 50 с.
Якщо порт під’єднано до кінцевих вузлів (не зв’язаний з іншими ко-
мутаторами), то для прискорення часу його переведення у стан пересилання
на порту слід включити функцію швидкого порту (portfast). Тоді, при
активізації порту, він автоматично переходить зі стану блокування у стан
пересилання. Це стає можливим завдяки тому, що такі порти не можуть
спричинити виникнення петель.
Розширення протоколу STP
Протокол STP має ряд обмежень та недоліків, а саме: повільний час

конвергенції мережі, необхідність перерахування дерева при кожній зміні
топології мережі тощо. З метою усунення цих недоліків було розроблено ряд
інших протоколів.
135
Rapid Spanning Tree Protocol (RSTP)
Rapid STP (RSTP) – це суттєво вдосконалений STP, описаний у

стандарті IEEE 802.1w (вподальшому включений у 802.1D-2004). Якщо в
класичному STP було чотири стани (Blocking, Listening, Learning,
Forwarding), то в RSTP їх стало менше – три (Discarding, Listening і
Forwarding). Тобто комутатор відкидає, вивчає або пересилає. Але швидше
він сходиться не через це. Швидку збіжність протокол забезпечує тим, що
заздалегідь прораховує, який порт включити, якщо відмовить працюючий.
Тим самим, при відмові порту, він не починає знову вивчати топологію і
переходити по різних станах, а просто переключається на заздалегідь
прорахований.
Швидку збіжність і реакцію на відмови в RSTP забезпечують:
• генерація BPDU-повідомлень кожним пристроєм, незалежно від
кореневого комутатора;
• механізм proposal / agreement, при активації каналу точка-точка,
для швидкого переходу портів в стан «Forwarding»
• механізм використання альтернативного порту, при втраті зв’язку
через кореневий порт (на зразок технології UplinkFast);
• механізм негайної реакції на отримання BPDU з «найгіршим»
кореневим комутатором від сусіда, що має designated-порти для даного
сегмента мережі (на зразок технології backbonefast);
• більш оптимальна схема розсилки і обробки повідомлень TCN
BPDU про зміни в мережі.
Per-VLAN Spanning Tree (PVST)
Per-VLAN STP (PVSTP) розширює функціональність STP у мережах з

VLAN. Тут у кожному VLAN працює окремий екземпляр STP. Спершу цей
протокол працював лише через ISL-транки, потім було розроблено
розширення PVST+, яке дозволяло працювати через 802.1Q-транки, котрі
використвуються набагато частіше, ніж ISL.
Є реалізації rapid-pvst. Вони об’єднують властивості PVST+ і RSTP.
136
Multiple Spanning Tree Protocol (MSTP)
Multiple STP (MSTP) є найсучаснішою стандартною реалізацією STP,

що враховує усі переваги та недоліки попередніх рішень. MSTP описаний у
стандарті IEEE 802.1s (в подальшому включений у стандарт IEEE 802.1Q-
2003).
На відміну від PVST+ (в якому число екземплярів зв’язуючого дерева
дорівнює числу VLAN), MSTP передбачає конфігурування необхідної
кількості екземплярів незалежно від числа VLAN на комутаторі. В один
екземпляр MST можуть входити декілька VLAN. Проте усі комутатори, що
беруть участь в MST, повинні мати однаково сконфігуровані групи VLAN,
що обмежують гнучкість при зміненні конфігурації мережі.
1. Створіть топологію, зображену на рис. 9.6. Задайте ІР-адреси

пристроїв у VPCS відповідно до рис. 9.6.
Застосуйте можливість роботи маршрутизатора у якості мосту. Це

виконується за допомогою додавання в кожний маршрутизатор мосту та
додавання в цей міст відповідних портів маршрутизатора.
137
На маршрутизаторі Mikrotik виконайте такі команди:
[admin@MikroTik] > interface bridge add

[admin@MikroTik] > interface bridge port add bridge=bridge1 interface=ether1
[admin@MikroTik] > interface bridge port add bridge=bridge1 interface=ether2
Вимкніть роботу протоколу визначення сусідів на створеному мості:

[admin@MikroTik] > ip neighbor discovery disable bridge1
Спробуйте виконати пінг з С1 на С2:

VPCS[1]> ping 192.168.0.2
Пінги мають пройти успішно.
Подивіться таблицю комутації на пристрої Mikrotik та на пристрої SW2

(рис. 9.7). Для SW2 натисніть на пристрої правою кнопкою миші та оберіть
«MAC Address Table»
Рисунок 9.7 – Таблиці комутації на Mikrotik та SW2
Проаналізуйте ці таблиці та надайте опис, як вони були отримані.
138
Тепер створіть мости на маршрутизаторах Mikrotik_2 та Mikrotik_3 і
додайте у них відповідні інтерфейси. Відключить протокол визначення
сусідів на створених мостах.
Запустіть аналізатор трафіку Wireshark на інтерфейсі e1
маршрутизатора Mikrotik.
Спробуйте ще раз виконати пінг з С1 на С2.
При цьому пінги не йдуть. Це пов’язано з виникненням петлі на
канальному рівні. Якщо подивитися в аналізаторі трафіку захоплені кадри, то
можна побачити, що там є багато широкомовних кадрів, які «затоплюють»
мережу (рис. 9.8).
Рисунок 9.8 – Захоплені кадри у Wireshark
Застосуйте протокол STP для вирішення цієї проблеми. При цьому

можлива ситуація, коли маршрутизатори не відкликаються на команди (це
як-раз пов’язано з петлею на канальному рівні). В цьому разі їх необхідно
вимкнути (обираючи їх правою кнопкою миші та натискаючі «Stop») і знову
ввімкнути.
Для застосування протоколу STP виконайте на кожному
маршрутизаторі таку команду:
interface bridge set bridge1 protocol-mode=stp
За допомогою Wireshark прослідкуйте процес побудови топології та

визначте, який маршрутизатор обрано у якості кореневого мосту та які ролі
отримали кожні з портів.
Подивитися на стан мосту можна командою
interface bridge print detail
139
Спробуйте замінити пріоритет некореневого мосту на нижчий ніж
пріоритет кореневого, та опишіть, що при цьому відбулося. Наведіть
відповідні скріншоти.
Зміна пріоритету виконується командою
int bridge set bridge1 priority=
На кожному мості заменіть протокол STP на RSTP:

interface bridge set bridge1 protocol-mode=rstp
Продемонструйте роботу протоколу RSTP у вигляді відповідних

скріншотів у Wireshark.
1. Чому вважають за краще будувати локальні мережі за допомогою

комутаторів, а не концентраторів?
2. Які існують методи для відправки кадру через комутатор?
3. Як комутатор дізнається МАС-адреси підключених пристроїв?
4. Де і як в комутаторі зберігаються адреси підключених пристроїв?
5. Що є головною перешкодою для створення великих локальних
мереж за допомогою одних тільки комутаторів?
6. Що таке домен широкомовлення?
7. Що таке BPDU та яка його структура?
8. Які існують стани портів у протоколі STP?
9. Яки етапи побудови топології у протоколі STP?
10. Як визначається кореневий комутатор у протоколі STP?
11. Які ролі мають порти комутатора у протоколі STP?
12. Як визначається вартість шляху при побудові топології за
протоколом STP?
13. Чим відрізняється протокол RSTP від STP?

140
Звіт готується в електронному вигляді і роздруковується. Він містить

усі виконані пункти практичної роботи зі скріншотами.
141
ВІРТУАЛЬНІ ЛОКАЛЬНІ МЕРЕЖІ
Ознайомлення з принципами обмеження широкомовного трафіку в

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

комутованого Ethernet, зокрема мінімізувати число концентраторів (хабів,
hub) і використовувати переважно комутатори (свічі, switch). У комутаторі
між приймачем і передавачем на час з’єднання утворюється віртуальний
канал (virtual circuit) точка-точка. Така мережа може бути розглянута як
сукупність незалежних пар приймач-передавач, кожна з яких використовує
усю смугу пропускання. Комутатор дозволяє здійснювати паралельну
передачу інформації. Комутація зменшує вірогідність переповнювання в
мережах Ethernet.
Якщо комутатору необхідно передати пакет на якийсь вихідний порт, і
цей порт зайнятий, то пакет поміщається в буферну пам’ять. Це дозволяє
погоджувати швидкості передавачів і приймачів кадрів.
Для відправки кадру через комутатор використовуються два методи:
1) Метод відправки з проміжним зберіганням (store-and-forward). Кадр
має бути прийнятий повністю до того, як буде почата його відправка.
2) Крізний метод (cut-through). Комутатор приймає початок кадру,
визначає в ньому адресу пункту призначення і починає відправляти кадр ще
до його повного отримання
Ethernet-комутатор дізнається МАС-адреси пристроїв в мережі шляхом
читання адрес джерел в кадрах, що приймаються. Комутатор запам’ятовує у
своїх внутрішніх таблицях інформацію, на які порти і з яких МАС-адрес
142
приходять кадри. При підключенні до одного порту декількох пристроїв
через концентратор (hub) в таблиці одному порту відповідатиме декілька
MAC-адрес. Таблиці зберігаються в пам’яті. Якщо адреса відправника
відсутня в таблиці, то вона туди заноситься. Разом з парами адреса-порт в
таблиці зберігається і мітка часу. Мітка часу в рядку таблиці змінюється або
при приході на комутатор кадру з такою ж адресою, або при зверненні
комутатора за цією адресою. Якщо рядок таблиці не використовувався
певний період часу, то він видаляється. Це дозволяє комутатору
підтримувати правильний список адрес пристроїв для передачі кадрів.
Використовуючи таблицю адрес і адресу одержувача, що міститься в
кадрі, що прийшов, комутатор організовує віртуальне з’єднання порту
відправника з портом одержувача і передає кадр через це з’єднання.
Віртуальне з’єднання між портами комутатора зберігається протягом
передачі одного кадру, тобто для кожного кадру віртуальне з’єднання
організовується наново на основі адреси одержувача, що міститься в цьому
кадрі.
Оскільки кадр передається тільки в той порт, до якого підключений
адресат, інші пристрої, підключені до комутатора, не отримають цей кадр.
У комутаторах Ethernet передача даних між будь-якими парами портів
відбувається незалежно, і, отже, для кожного віртуального з’єднання
виділяється уся смуга каналу.
При передачі широкомовного кадру в комутаторі утворюється
об’єднання каналів за принципом один до багатьох. Прикладами джерел
широкомовного трафіку є ARP і протоколи маршрутизації.
Комутатори можна сполучати один з одним. При цьому група попарно
прямо або побічно пов’язаних комутаторів утворює один логічний комутатор
з теоретично довільним числом портів. Тобто комутатори дозволяють
створювати теоретично скільки завгодно велику локальну мережу.
Правильне з’єднання комутаторів, тобто вибір топології мережі, складає
одне з найважливіших завдань проектування локальних мереж.
Рекомендується здійснювати з’єднання комутаторів по таких шарах
(рис. 10.1): серверному, шару розподілу (distribution) і шару доступу (access).
143
Рядові комп’ютери підключаються до шару доступу, а сервери – серверного
шару.
Рисунок 10.1 – Принцип об’єднання комутаторів
Головною перешкодою для створення великих локальних мереж за

допомогою одних тільки комутаторів є нелінійне зростання обсягу
широкомовного трафіку із зростанням числа пристроїв в мережі. При числі
пристроїв в мережі більше, ніж 2000 (за іншими оцінками 500, а за третіми
4000 – усе залежить від топології мережі і від класу задач, що розв’язуються)
обсяг широкомовного трафіку різко зростає. Додавання нових пристроїв
різко знижує продуктивність мережі.
Наприклад, якщо в мережі з декількох тисяч пристроїв один з
комп’ютерів A уперше здійснює IP-з’єднання з іншим комп’ютером B в цій
мережі, то він повинен заздалегідь послати до усіх пристроїв мережі
широкомовний ARP-запит для визначення MAC-адреси комп’ютера B.
Локальна мережа, створена за допомогою одних тільки комутаторів,
представляє один домен широкомовлення. Зменшити домен широкомовлення
можна, фізично розділивши локальну мережу на незалежні підмережі
(незалежні групи попарно пов’язаних комутаторів) і з’єднати їх в єдине ціле з
використанням маршрутизаторів. Таке завдання можна вирішити тільки на
етапі побудови мережі, але не у момент її експлуатації. Тут на допомогу
приходять віртуальні локальні мережі VLAN (Virtual Local Area Network).
144
Віртуальні локальні мережі VLAN є сукупністю портів одного або
більше комутаторів.
VLAN дозволяють логічно розбити початкову локальну мережу на
декілька незалежних локальних мереж без фізичного обриву мережних
з’єднань. Для цього адміністратор мережі повинен на кожному комутаторі
визначити, які з його портів відносяться до відповідних VLAN. За
замовчуванням усі порти комутатора відносяться до одної VLAN з
номером 1. Максимальне число VLAN в комутаторі дорівнює загальному
числу його портів. Правильне розбиття локальної мережі на VLAN складає
одне з найважливіших завдань проектування.
VLAN поводяться так само, як і фізично розділені локальні мережі.
Тобто після розбиття мережі на VLAN ми отримаємо декілька локальних
мереж, які далі необхідно об’єднати в єдине ціле за допомогою
маршрутизації на третьому мережному рівні.
Концепція VLAN, окрім вирішення проблеми з широкомовним
трафіком, дає також ряд додаткових переваг: формування локальних мереж
не за місцем розташування найближчого комутатора, а за приналежністю
комп’ютерів до розв’язання тієї або іншої виробничої задачі; створення
мережі за типом споживаного обчислювального ресурсу і необхідної
серверної послуги (файл-сервер, сервер баз даних). VLAN дозволяє вести
різну політику безпеки для різних віртуальних мереж; переводити комп’ютер
з однієї мережі в іншу без здійснення фізичного переміщення або нового
підключення.
Для обміну інформацією про VLAN комутатори використовують
магістральний (транковий) протокол. Для здійснення обміну інформацією
про VLAN між комутаторами необхідно створити магістральні порти.
Магістральний порт – це порт, що використовується для передачі інформації
про VLAN в інші мережні пристрої, приєднані до цього порту. Звичайні
порти не рекламують інформацію про VLAN, але будь-який порт може бути
налагоджений для прийому/передачі інформації про VLAN. Тому слід
активізувати магістральний протокол на потрібних портах, оскільки він
вимкнений за замовчуванням.
145
Порт комутатора працює або в режимі доступу або в магістральному
режимі. Відповідно зв’язок, приєднаний до порту є або зв’язком доступу або
магістральним зв’язком. У режимі доступу порт належить тільки одній
VLAN. Порт доступу приєднується до крайового пристрою: робочої станції,
сервера, хаба. Кадри, що проходять через порт доступу, є звичайними
Ethernet-кадрами.
Магістральні зв’язки здатні підтримувати декілька VLAN. VLAN на
різних комутаторах зв’язуються через магістральний протокол. Магістральні
порти не залежать від певної VLAN і використовуються для під’єднання до
інших комутаторів, маршрутизаторів або серверів, що мають мережні
адаптери з можливістю для підключення до багатьох VLAN.
Магістралі можуть розширити VLAN по усій мережі. Для
магістральних цілей призначають високошвидкісні порти комутаторів:
Gigabit Ethernet і 10Gigabit .
Для мультиплексування трафіку VLAN існують спеціальні протоколи,
що дозволяють приймальним портам визначити, якому VLAN належить кадр.
Для зв’язку між пристроями Cisco використовується протокол Inter – Switch
Link (ISL). За наявності в мережі устаткування декількох виробників
застосовується протокол IEEE 802.1Q
Без магістральних зв’язків для підтримки VLAN необхідно
організувати по одному зв’язку доступу для кожної VLAN. Такий підхід
дорогий і неефективний, тому магістральні зв’язки абсолютно потрібні при
проектуванні локальних мереж.
На рис. 11.2 порти А і В на комутаторі Y визначені як зв’язки доступу
на тій самій VLAN 200. За визначенням вони можуть належати тільки одній
VLAN і не можуть отримувати Еthernet-кадри, що містять ідентифікатор
VLAN. Наприклад, коли Y отримує трафік від порту А до порту В, то він не
додає ISL заголовок в Еthernet-кадри.
Порт С на комутаторі Z також є портом доступу і також належить до
VLAN 200. Якщо порт А пересилає кадр в порт С, то відбувається таке:
1. Комутатор Y отримує кадр і, зіставляючи номер порту призначення
з номером VLAN, визначає його як трафік, спрямований до VLAN 200 на
іншому комутаторі.
146
2. Комутатор Y додає до кадру ISL-заголовок з номером VLAN і
пересилає кадр через проміжний комутатор на магістральний зв’язок.
3. Цей процес повторюється на кожному комутаторі по шляху кадру
до кінцевого порту С.
4. Комутатор Z отримує кадр, видаляє ISL-заголовок і направляє кадр
на порт С.
Якщо порт знаходиться в магістральному режимі, то він може бути
налагоджений для транспорту або усіх VLAN, або обмеженої множини
VLAN. Магістральні зв’язки використовуються для зв’язку комутаторів з
іншими комутаторами, маршрутизаторами або з серверами, що мають
підтримку VLAN.
Рисунок 10.2 – Принцип організації магістральних портів
Згідно з базовою термінологією магістраль – це зв’язок точка-точка, що

підтримує декілька VLAN. Метою магістралі є збереження номерів портів
при створенні зв’язку між двома пристроями VLAN.
Верхня фігура на рис. 10.3 показує спосіб створення VLAN шляхом
використання двох фізичних зв’язків між комутаторами (по одному на кожну
VLAN). Це рішення погано масштабується: при додаванні третього VLAN
потрібно пожертвувати ще двома портами. Це рішення є неефективним і в
147
сенсі розподілу навантаження: малий трафік на деяких зв’язках може не
коштувати того, що цей зв’язок є пучком віртуальних зв’язків через один
фізичний зв’язок. На нижній фігурі один фізичний зв’язок здатний нести
трафік для будь-якої VLAN. Для досягнення цього комутатор Sa так
оформлює кадри, що Sb знає, на яку VLAN вони прямують. Для такого
оформлення пакетів використовуються або стандарт IEEE 802.1Q, або Cisco-
протокол ISL.
Рисунок 10.3 – Організація передачі інформації про VLAN
Для великих мереж ручна конфігурація VLAN стає дуже трудомістким

завданням. Cisco VLAN Trunk Protocol (VTP) служить для автоматичного
обміну інформацією про VLAN через магістральні порти. Перевагою
використання VTP є те, що ви можете контролювати додавання, видалення
або зміну мереж VLAN з комутаторів на якому створені VTP сервера. Після
налаштування ваших комутаторів як VTP-серверів, інші комутатори вашої
мережі можуть бути налагоджені як клієнти, які тільки отримують VLAN-
інформацію. Недоліком є непотрібний трафік, що створюється на
магістральний портах для пристроїв, яким, можливо, не потрібна ця
інформація.
Якщо мережа міститиме багато комутаторів, що містять багато
віртуальних мереж, розташованих в різних комутаторах, то, можливо, має
сенс використовувати VTP. Якщо мережа залишиться досить статичною, і
VLAN не додаватимуться або не змінюватимуться по відношенню до
148
початкової конфігурації, то краще використовувати статичне визначення
віртуальних мереж.
У топології локальних мереж можливі цикли (петлі). Наприклад, вже
три комутатори сполучених один з одним по колу утворюють цикл в
топології. Петлі призводять до неоднозначності при визначенні шляху від
джерела кадрів до приймача. Для вирішення цієї серйозної проблеми був
розроблений протокол покривного дерева STP (Spanning Tree Protocol). Для
графа топології кожній VLAN, яка визначена в мережі, будується мінімальне
покривне дерево (граф без циклів) з вершиною в деякому комутаторі. Для
фізичної реалізації таких дерев STP переводить надлишкові порти в стан
блокування. Розрахунок дерев проводиться паралельно на усіх комутаторах.
Далі пакети у VLAN йдуть тільки по шляхах, визначених в побудованих
покривних деревах. При зміні топології, активації/зупинці портів
відбувається перерахунок покривних дерев. Для створення топології
єднального дерева існують спеціальні кадри, звані модулями даних
мостового протоколу (Bridge Protocol Data Units, BPDU). Ці кадри
вирушають і приймаються усіма комутаторами в мережі через рівні
проміжки часу.
1. Створіть топологію, зображену на рис. 10.4. Задайте ІР-адреси

пристроїв у VPCS відповідно до табл. 10.1.
Таблиця 10.1 – ІР-адреси пристроїв

Пристрій ІР-адреса Пристрій ІР-адреса
С1_20 172.16.19.1/16 С4_30 172.16.19.4/16
С2_20 172.16.19.2/16 С5_30 172.16.30.5/16
С3_20 172.16.30.3/16
149
Рисунок 10.4 – Топологія практичної частини
Налаштуйте порти комутаторів таким чином:
Комутатор Порт VLAN Type Комутатор Порт VLAN Type

SW1 1 20 access SW2 1 20 access
Для цього перейдіть в налаштування комутатора (двічі натисніть ліву

клавішу миші). На рис. 10.5 наведено вікно налаштування SW1.
Рисунок 10.5 – Налаштування комутатора SW1
150
Виконайте попарно команду ping між пристроями. Тільки станції, що
знаходяться у тій самій VLAN, повинні побачити одна одну. Тобто в даному
випадку для зв’язку комутаторів між собою для передачі інформації про
номери VLAN задіяні дві лінії (по одній на кожний номер VLAN). Таке
рішення дуже погано масштабується.
Подивіться таблицю комутації на комутаторах. Для цього з меню, що
з’являється при натисканні на праву кнопку миші над комутатором, оберіть
пункт «MAC Аddress Тable».
Рисунок 10.6 – Таблиця комутації комутатора SW1
2. Виконайте з’єднання комутаторів за допомогою магістральних

(транкових) портів. Для цього видаліть на топології рис. 10.4 одну з ліній
зв’язку між комутаторами. Після цього налаштуйте ті порти, що залишилися
підключеними, на роботу в режимі dot1q (оберіть type = dot1q). Перевірте
працездатніть топології за допомогою ping. Так само повинні бачити одна
одну тільки ті станції, що знаходяться у одній VLAN.
3. Замініть маски підмереж на кожній станції на /24. Спробуйте
виконати команду ping між станціями, що знаходяться в однакових VLAN.
Тільки С1_20 та С2_20 бачать одна іншу. Це пов’язане з тим, що до цього усі
станції були в одній ІР-мережі 172.16.0.0/16, а тепер вони знаходяться у
різних мережах: 172.16.19.0/24 та 172.16.30.0/24. Для об’єднання станцій
необхідно скористатися пристроєм, який працює на мережному рівні, тобто
маршрутизатором. Додайте до топології маршрутизатор Mikrotik (рис. 10.7).
151
Рисунок 10.7 – Об’єднання пристроїв в різних VLAN на мережному рівні
Задайте ІР-адреси інтерфейсів маршрутизатора:
[admin@MikroTik] > ip ad add addr=172.16.19.20/24 inter=ether1

[admin@MikroTik] > ip ad add addr=172.16.30.30/24 inter=ether2
Налаштуйте режим access на порту 4 комутатора SW1 на номер

VLAN=20, а порт 4 комутатора SW2 – на номер VLAN=30.
На кожній станції додайте інформацію про шлюз за замовчуванням: на
станціях, що знаходяться у VLAN 20, шлюз дорівнює 172.16.19.20, у інших
(VLAN 30) – 172.16.30.30.
Побудуйте таблицю наявності зв’язку між кожними станціями в
мережі. Поясніть цю таблицю.
1. Чому вважають за краще будувати локальні мережі за допомогою

комутаторів, а не концентраторів?
2. Які існують методи для відправки кадру через комутатор?
3. Як комутатор дізнається МАС-адреси підключених пристроїв?
4. Де і як в комутаторі зберігаються адреси підключених пристроїв?
5. Що таке віртуальне з’єднання і як довго воно існує?
152
6. Наскільки велику локальну мережу можна створити за допомогою
комутаторів?
7. Як прийнято будувати великі локальні мережі?
8. Що є головною перешкодою для створення великих локальних
мереж за допомогою одних тільки комутаторів?
9. Що таке домен широкомовлення?
10. Як зменшити домен широкомовлення?
11. Що таке VLAN?
12. Які проблеми локальних мереж вирішує VLAN?
13. Як в локальній мережі організувати обмін інформацією про VLAN?
14. У яких режимах працюють порти комутатора?
15. Який VLAN належить до магістрального порту?
16. Як розповсюдити одну VLAN на декілька комутаторів?
17. Чи можна організувати декілька VLAN на декількох комутаторах
без використання магістралей?
18. Навіщо потрібні протоколи ISL і IEEE 802.1Q?
19. Навіщо потрібні магістралі в локальній мережі?
19. Які завдання вирішує VTP?
21. Які завдання вирішує STP?
25. У локальній мережі є одинадцять VLAN. Скільки маршрутизаторів
потрібно для об’єднання усіх 11 VLAN в єдине ціле?

4. Оформити звіт (зміст звіту дивися нижче).
153
Повторити усі пункти практичної частини для IP-мережі підприємства
= N.M.0.0/16, де N та M відповідно номер по списку та місяць народження
студента. Практична частина виконана для мережі 172.16.0.0/16.

2. Скріншоти топології рис. 10.4 та 10.7 з зазначенням на них ІР-адрес
усіх інтерфейсів згідно з варіантом.
3. Виконану самостійну роботу.
154
ПРОТОКОЛИ ТРАНСПОРТНОГО РІВНЯ ТСР/ІР. ПРОТОКОЛИ ICMP

ТА DHCP. СЛУЖБА DNS
Ознайомлення з принципами роботи протоколів транспортного рівня

стека ТСР/ІР та протоколів ICMP і DHCP. Набуття практичних навичок
налаштування DHCP- та DNS-серверів на мережному обладнанні.
Відправником і одержувачем даних, переданих через мережу, з погляду

транспортного рівня, є застосунок (процес). Як будь-яка програма, процеси
створюються і знищуються; на кожному вузлі може виконуватися кілька
процесів, а кожний процес може мати кілька точок підключення до мережі.
Такі логічні точки (що програмно організуються, як правило, у вигляді черг
повідомлень) називаються портами (port). Номер порту однозначно
ідентифікує процес. Коли вузол одержує дейтаграму транспортного рівня, він
направляє її до прикладного процесу, використовуючи номер порту, заданий
при встановленні зв’язку.
Порти нумеруються позитивними цілими 16-бітовими числами. Різні
протоколи транспортного рівня нумерують свої порти незалежно, тобто,
наприклад, порт 223 протоколу TCP і порт 223 протоколу UDP зовсім не
зв’язані один з одним.
Деякі номери портів задані стандартами. Ці номери виділяються
організацією IANA (Internet Assigned Numbers Authority). У цей час під
стандартні порти відведений діапазон від 0 до 1023 (раніше – до 255). Інші
порти можуть вільно використовуватися прикладними процесами. Порти в
діапазоні від 1024 до 5000 називаються тимчасовими (ephemeral).
Призначення цих портів не стандартизоване, але IANA підтримує
інформацію про їх використання.
155
Пара «порт – IP-адреса» називається (у термінології TCP/IP) гніздом
або сокетом (socket) і однозначно вказує на процес у мережі.
Протокол UDP
Протокол UDP (User Datagram Protocol, Протокол користувальницьких

дейтаграм) описаний в RFC 768. Він надає прикладним процесам
найпростіші послуги транспортного рівня. Дві основні функції UDP –
розподіл дейтаграм між процесами (на підставі номерів портів) і контроль
передачі даних користувача (не тільки заголовка, як у протоколі IP). Як і IP,
UDP не гарантує доставку і не підтримує установлення з’єднань.
UDP використовує просту модель передачі, без неявних
«рукостискань» для забезпечення надійності, упорядкування або цілісності
даних. Таким чином, UDP надає ненадійний сервіс, і дейтаграми можуть
прийти не одна за одною, дублюватися або зовсім зникнути без сліду. UDP
має на увазі, що перевірка помилок і виправлення або не потрібні, або
повинні виконуватися в додатку. Чутливі до часу додатки часто
використовують UDP, тому що переважніше скинути пакети, ніж чекати
пакети, що затрималися, що може виявитися неможливим в системах
реального часу.
Повідомлення протоколу UDP називається дейтаграмою користувача
(User datagram) і складається із заголовка і користувальницьких даних.
Заголовок складається із чотирьох 16-бітових полів:
1) порту відправника (може заповнюватися нулями, якщо не викорис-
товується);
2) порту одержувача;
3) довжини повідомлення (у байтах);
4) контрольної суми.
Відразу за заголовком ідуть користувальницькі дані.
Нульове значення в полі «Контрольна сума» означає, що контрольна
сума не обчислювалася. Для розрахунку контрольної суми до початку
дейтаграми приписується псевдозаголовок, який складається з п’яти полів:
1) IP-адреси відправника;
2) IP-адреси одержувача;
156
3) нулів (8 біт);
4) протоколу (8 біт);
5) довжини дейтаграми (16 біт).
Крім того, до кінця дейтаграми, можливо, додають нульовий байт, щоб
його довжина (разом із псевдозаголовком) була кратна 16 бітам. Потім
обчислюється контрольна сума (як у протоколі IP), і псевдозаголовок
відкидається.
Численні ключові Інтернет-додатки використовують UDP, у тому
числі: DNS (де запити повинні бути швидкими й складатися тільки з одного
запиту, за яким потрібен один пакет відповіді); простий протокол керування
мережами (SNMP); протокол маршрутизації (RIP); протокол динамічної
конфігурації вузла (DHCP).
Голосовий і відеотрафік зазвичай передається за допомогою UDP.
Протоколи потокового відео й аудіо в реальному часі розроблені для обробки
випадкових втрат пакетів таким чином, що якість відео/аудіо лише незначно
зменшується. Це краще, ніж збільшення затримок при повторній передачі
загублених пакетів.
Протокол TCP
Протокол TCP (Transmission Control Protocol, Протокол керування

передачею) описаний в RFC 793. Він забезпечує надійну передачу потоку
даних, використовуючи сервіс передачі дейтаграм протоколу IP. Пакети, що
передаються протоколом TCP, називаються сегментами. Надійність передачі
забезпечується за допомогою нумерації байтів потоку і підтверджень
прийому. Всі байти вихідного потоку даних нумеруються (цей номер
називається номером у послідовності (sequence number), і з кожним
сегментом передається номер у послідовності його першого байта.
Оскільки два вузли можуть передавати два потоки даних за одним TCP-
з’єднанням, то для передачі підтверджень одного потоку використовуються
сегменти зустрічного потоку. У кожному сегменті передається номер байта у
послідовності байтів, який очікує даний вузол.
Після того як модуль TCP передасть сегмент модулю IP, він записує
його копію в чергу на повторну передачу і запускає таймер для цього
157
сегмента. Коли надійде підтвердження прийому сегмента (тобто буде
прийнятий сегмент, у якому буде заявлено, що та сторона готова прийняти
байт із номером, більшим за всі номери байтів сегмента, що чекає повторної
передачі), сегмент видаляється із черги. Якщо підтвердження не надходить
до спрацювання таймера, сегмент відправляється повторно. Сегмент
складається із заголовка і поля даних.
Формат заголовка сегмента TCP наведений на рис. 11.1.
Порт відправника [16 біт] Порт одержувача [16 біт]

Номер у послідовності [32 біти]
Номер підтвердження [32 біти]
Зсув даних Резерв Біти керування Вікно
[4 біти] [6 біт] [6 біт] [16 біт]
Контрольна сума [16 біт] Покажчик терміновості [16 біт]
Опції Вирівнювання
[змінна довжина] [доповнення до 32 біт]
Рисунок 11.1 – Формат заголовка сегмента TCP
Формат заголовка сегмента TCP містить:

1) порт відправника (Source port) і порт одержувача (Destination port)
[16 біт] – номери портів на вузлах;
2) номер у послідовності (Sequence Number) [32 біти] – номер у потоці
першого байта даних цього сегмента. Якщо встановлено керуючий біт SYN,
то в цьому полі утримується початковий номер у послідовності (Initial
Sequence Number, ISN), і перший байт даних сегмента має номер у потоці
ISN+1;
3) номер підтвердження (Acknowledgement number) [32 біти] – номер
байта в потоці, очікуваного відправником даного сегмента. При цьому
повинен бути встановлений керуючий біт ACK;
4) зсув даних (Data offset) [4 біти] – кількість 32-бітових слів у
заголовку TCP-сегмента. Мінімальне значення поля – 5 (20-ти байтовий
заголовок) ;
5) резерв (Reserved) [6 біт] – повинен бути заповнений нулями;
158
6) біти керування (Control bits) [6 біт] – від старшого до молодшого:
URG (Urgent Pointer field significant) – брати до уваги поле Покажчик
терміновості; ACK (Acknowledgement field significant) – брати до уваги поле
Номер підтвердження; PSH (Push function) – сегмент містить «проштовхнуті»
дані; RST (Reset the connection) – перервати зв’язок; SYN (Synchronize
sequence numbers) – синхронізувати номери байтів у потоці; FIN (No more
data from sender) – відправник більше не буде передавати дані;
7) вікно (Window) [16 біт] – розмір вікна – кількість байтів даних,
починаючи із зазначеного в полі Номер підтвердження, які відправник
даного сегмента готовий прийняти;
8) контрольна сума (Checksum) [16 біт] – контрольна сума всього
сегмента (заголовка і даних), обчислюється за алгоритмом протоколу IP. Як і
в UDP, перед обчисленням контрольної суми до сегмента приписується
псевдозаголовок (тієї ж структури, що і в UDP) ;
9) покажчик терміновості (Urgent Pointer) [16 біт] – містить номер
першого байта, що має звичайний статус терміновості. При цьому повинен
бути встановлений керуючий біт URG;
10) опції (Options) [змінний розмір] – додаткова службова інформація.
Подібно до опції заголовка, IP-дейтаграми мають змінну довжину і можуть
бути взагалі відсутніми;
11) вирівнювання (Padding) – поле, що використовується для доведення
розміру заголовка до цілого числа 32-бітових слів.
Щоразу при встановленні з’єднання модуль TCP створює структуру
даних – Блок керування передачею (Transmission Control Block, TCB), що
зберігає постійну інформацію про з’єднання (IP-адреси, номери портів,
покажчики на вхідний і вихідний буфери, черга повторного відправлення і
т. д.) і поточні значення змінних, що описують поточний стан з’єднання.
На відміну від традиційної альтернативи – UDP, що може відразу ж
почати передачу пакетів, TCP установлює з’єднання, яке повинно бути
створене перед передачею даних. TCP з’єднання можна розділити на 3 стадії:
• Установлення з’єднання.
• Передача даних.
• Завершення з’єднання.
159
Стан сеансу TCP
CLOSED Початковий стан вузла. Фактично фіктивний
LISTEN Сервер очікує запитів установлення з’єднання від клієнта
Клієнт відправив запит серверу на встановлення з’єднання й

SYN-SENT
очікує відповіді
SYN- Сервер одержав запит на з’єднання, відправив відповідний
RECEIVED запит і очікує підтвердження
ESTABLISHED З’єднання встановлене, іде передача даних
Одна зі сторін (назвемо її вузол 1) завершує з’єднання,
FIN-WAIT-1
відправивши сегмент із прапором FIN
Інша сторона (вузол 2) переходить у цей стан, відправивши у
CLOSE-WAIT
свою чергу сегмент ACK, і продовжує однобічну передачу
Вузол 1 одержує ACK, продовжує читання й чекає
FIN-WAIT-2
одержання сегмента із прапором FIN
Вузол 2 закінчує передачу й відправляє сегмент із прапором
LAST-ACK
FIN
Вузол 1 одержав сегмент із прапором FIN, відправив сегмент
TIME-WAIT із прапором ACK і чекає 2*MSL секунд, перед остаточним
закриттям з’єднання
Обидві сторони ініціювали закриття з’єднання одночасно:
після відправлення сегмента із прапором FIN вузол 1 також
CLOSING одержує сегмент FIN, відправляє ACK і перебуває в
очікуванні сегмента ACK (підтвердження на свій запит про
роз’єднання)
Установлення з’єднання
Процес початку сеансу TCP визначається як «рукостискання»

(handshake) і складається з 3 кроків.
160
1) Клієнт, що має намір установити з’єднання, посилає серверу сегмент
із номером послідовності й прапором SYN.
• Сервер одержує сегмент, запам’ятовує номер послідовності й
намагається створити сокет (буфери й керуючі структури пам’яті) для
обслуговування нового клієнта.
• У випадку успіху сервер посилає клієнтові сегмент із номером
послідовності й прапорами SYN і ACK і переходить у стан SYN-RECEIVED.
• У випадку невдачі сервер посилає клієнтові сегмент із прапором
RST.
2) Якщо клієнт одержує сегмент із прапором SYN, то він запам’ятовує
номер послідовності й посилає сегмент із прапором ACK.
• Якщо він одночасно одержує й прапор ACK (що звичайно й
відбувається), то він переходить у стан ESTABLISHED.
• Якщо клієнт одержує сегмент із прапором RST, то він припиняє
спроби з’єднатися.
• Якщо клієнт не одержує відповіді протягом 10 секунд, то він
повторює процес з’єднання заново.
3) Якщо сервер у стані SYN-RECEIVED одержує сегмент із прапором
ACK, то він переходить у стан ESTABLISHED.
• У противному разі після тайм-ауту він закриває сокет і переходить у
стан CLOSED.
Процес називається триетапним узгодженням (three way handshake),
оскільки незважаючи на те, що можливий процес установлення з’єднання з
використанням 4 сегментів (SYN убік сервера, ACK убік клієнта, SYN убік
клієнта, ACK убік сервера), на практиці для економії часу використовується
3 сегменти.
Приклад базового 3-етапного узгодження:
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT → <SEQ=100><CTL=SYN> → SYN-RECEIVED
3. ESTABLISHED ← <SEQ=300><ACK=101><CTL=SYN,ACK> ← SYN-RECEIVED
4. ESTABLISHED → <SEQ=101><ACK=301><CTL=ACK> → ESTABLISHED
5. ESTABLISHED ← <SEQ=301><ACK=101><CTL=ACK> ← ESTABLISHED
161
У рядку 2 TCP A починає передачу сегмента SYN, що говорить про
використання номерів послідовності, починаючи з 100. У рядку 3 TCP B
передає SYN і підтвердження для прийнятого SYN на адресу TCP A. Треба
відзначити, що поле підтвердження показує очікування TCP B прийому
номера послідовності 101, що підтверджує SYN з номером 100.
У рядку 4 TCP A відповідає порожнім сегментом з підтвердженням
ACK для сегмента SYN від TCP B; у рядку 5 TCP B передає деякі дані.
Відзначимо, що номер послідовності сегмента в рядку 5 збігається з номером
у рядку 4, оскільки ACK не займає простори номерів послідовності (якщо це
зробити, доведеться підтверджувати підтвердження – ACK для ACK!).
Передача даних
При обміні даними приймач використовує номер послідовності, що

міститься в одержуваних сегментах, для відновлення їхнього вихідного
порядку. Приймач повідомляє передавальну сторону про номер
послідовності байт, до якої він успішно одержав дані, включаючи його в поле
«номер підтвердження». Всі одержувані дані, що ставляться до проміжку
підтверджених послідовностей, ігноруються. Якщо отриманий сегмент
містить номер послідовності більший, ніж очікуваний, то дані із сегмента
запам’ятовуються, але номер підтвердженої послідовності не змінюється.
Якщо згодом буде прийнятий сегмент, що ставиться до очікуваного номера
послідовності, то порядок даних буде автоматично відновлений виходячи з
номерів послідовностей у сегментах.
Для того щоб передавальна сторона не відправляла дані інтенсивніше,
ніж їх може обробити приймач, TCP містить засіб керування потоком. Для
цього використовується поле «вікно». У сегментах, що направляються від
приймача передавальній стороні в поле «вікно», вказується поточний розмір
приймального буфера. Передавальна сторона зберігає розмір вікна й
відправляє даних не більш, ніж указав приймач. Якщо приймач указав
нульовий розмір вікна, то передача даних у напрямку цього вузла не
відбувається доти, поки приймач не повідомить про більший розмір вікна.
У деяких випадках передавальний додаток може явно зажадати
проштовхнути дані до деякої послідовності приймальному додатку, не
162
запам’ятовуючи їх у буфері. Для цього використовується прапор PSH. Якщо
в отриманому сегменті виявляється прапор PSH, то реалізація TCP віддає всі
буферизовані на поточний момент дані приймальному додатку.
«Проштовхування» використовується, наприклад, в інтерактивних додатках.
У мережних терміналах нема рації очікувати введення користувача після
того, як він закінчив набирати команду. Тому останній сегмент, що містить
команду, зобов’язаний містити прапор PSH, щоб додаток на приймальній
стороні зміг почати її виконання.
Завершення з’єднання
Завершення з’єднання можна розглянути в три етапи:

1. Посилка серверу від клієнта прапорів FIN і ACK на завершення
з’єднання.
2. Сервер посилає клієнтові прапори відповіді ACK, FIN, що з’єднання
закрите.
3. Після одержання цих прапорів клієнт закриває з’єднання й на
підтвердження відправляє серверу ACK , що з’єднання закрите.
Протокол ICMP
Протокол ICMP (Internet Control Message Protocol, Протокол керуючих

повідомлень інтернет) описаний в RFC 792.
Він використовується для повідомлень про помилки або позаштатні
ситуації, що передаються вузлу-відправникові дейтаграми вузлом-
одержувачем або проміжним маршрутизатором.
Хоча повідомлення ICMP вкладаються в поле даних IP-дейтаграми,
тобто ICMP нібито є протоколом більш високого рівня, ніж IP, модуль
обробки ICMP-повідомлень входить у модуль, що реалізує протокол IP.
Тип (8 біт) Код (8 біт) Контрольна сума (16

біт)
Дані (Формат залежить від значення полів тип та код)
Рисунок 11.2 – Формат ICMP-повідомлення
163
ICMP-повідомлення (тип 12) генеруються при знаходженні помилок у
заголовку IP-IP-пакета (за винятком самих ICMP-пакетів, щоб не привести до
нескінченно зростаючого потоку ICMP-повідомлень про ICMP-
повідомлення).
ICMP-повідомлення (тип 3) генеруються маршрутизатором при
відсутності маршруту до адресата.
Утиліта Ping, що служить для перевірки можливості доставки IP-IP-
пакетів, використовує ICMP-повідомлення з типом 8 (ехо-запит) і 0 (ехо-
відповідь).
Утиліта Traceroute, що відображає шлях проходження IP-пакетів,
використовує ICMP-повідомлення з типом 11.
Протокол DHCP
DHCP (Dynamic Host Configuration Protocol – протокол динамічного

настроювання вузла) – мережний протокол, що дозволяє комп’ютерам
автоматично одержувати IP-адресу й інші параметри, необхідні для роботи в
мережі TCP/IP. Даний протокол працює за моделлю «клієнт-сервер». Для
автоматичної конфігурації комп’ютер-клієнт на етапі конфігурації мережного
пристрою звертається до так званого сервера DHCP і одержує від нього
потрібні параметри. Мережний адміністратор може задати діапазон адрес, що
розподіляються сервером серед комп’ютерів. Це дозволяє уникнути ручного
настроювання комп’ютерів в мережі й зменшує кількість помилок. Протокол
DHCP використовується в більшості мереж TCP/IP.
Передача даних виконується за допомогою протоколу UDP, при цьому
сервер приймає повідомлення від клієнтів на порт 67 і відправляє
повідомлення клієнтам на порт 68.
Структура повідомлень DHCP
Всі повідомлення протоколу DHCP розбиваються на поля, кожне з яких

містить певну інформацію. Всі поля, крім останнього (поля опцій DHCP),
мають фіксовану довжину (табл. 12.1).
164
Таблиця 11.1 – Опис полів протоколу DHCP
Довжина
Поле Опис
(у байтах)
Тип повідомлення. Наприклад може приймати такі значення:
op BOOTREQUEST (1, запит від клієнта до сервера) і BOOTREPLY 1
(2, відповідь від сервера до клієнта)
Тип апаратної адреси. Припустимі значення цього поля визначені
htype в RFC1700 «Assigned Numbers». Наприклад, для MAC-адреси 1
Ethernet 10 Мбит це поле набуває значення 1
hlen Довжина апаратної адреси в байтах. Для MAC-адреси Ethernet = 6 1
Кількість проміжних маршрутизаторів (так званих агентів
hops ретрансляції DHCP), через які пройшло повідомлення. Клієнт 1
установлює це поле в 0
Унікальний ідентифікатор транзакції. Генерується клієнтом на
xid 4
початку процесу одержання адреси
Час у секундах з початку процесу одержання адреси. Може не
secs 2
використовуватися (у цьому випадку він встановлюється в 0)
flags Поле для прапорів – спеціальних параметрів протоколу DHCP 2
IP-адреса клієнта. Заповнюється тільки в тому випадку, якщо
клієнт вже має власну IP-адресу й здатен відповідати на запити
ciaddr 4
ARP (це можливо, якщо клієнт виконує процедуру відновлення
адреси після закінчення строку оренди)
yiaddr Нова IP-адреса клієнта, запропонована сервером 4
siaddr IP-адреса сервера. Вертається в пропозиції DHCP 4
IP-адреса агента ретрансляції, якщо такий брав участь у процесі
giaddr 4
доставки повідомлення DHCP до сервера
chaddr Апаратна адреса (зазвичай MAC-адреса) клієнта 16
sname Необов’язкове ім’я сервера у вигляді нуль-терминованого рядка 64
Необов’язкове ім’я файла на сервері, що використовується
file бездисковими робочими станціями при віддаленному 128
завантаженні
options Поле опцій DHCP змінна
165
Процес отримання ІР-адреси складається із чотирьох етапів:
1) Виявлення DHCP. Спочатку клієнт виконує широкомовний запит
по всій фізичній мережі з метою виявити доступні DHCP-сервери. Він
відправляє повідомлення типу DHCPDISCOVER, при цьому IP-адреса
джерела вказується 0.0.0.0 (тому що комп’ютер ще не має власної IP-адреси),
а як адреса призначення – широкомовна адреса 255.255.255.255.
Клієнт заповнює кілька полів повідомлення початковими значеннями:
• У полі xid міститься унікальний ідентифікатор транзакції, що
дозволяє відрізняти даний процес одержання IP-адреси від інших, що

перебігають у той же час.
• У полі chaddr міститься апаратна адреса (MAC-адреса) клієнта.
• У полі опцій вказується остання відома клієнтові IP-адреса.
Повідомлення DHCPDISCOVER може бути поширене за межі

локальної фізичної мережі за допомогою спеціально настроєних агентів
ретрансляції DHCP, що перенаправляють повідомлення, які надходять від
клієнтів DHCP- серверам в інших підмережах.
2) Пропозиція DHCP. Одержавши повідомлення від клієнта, сервер
визначає необхідну конфігурацію клієнта відповідно до зазначеного
мережним адміністратором настроювання. Сервер відправляє йому відповідь
(DHCPOFFER), у якій пропонує конфігурацію. Пропонована клієнтові IP-
адреса вказується в полі yiaddr. Інші параметри (такі, як адреси
маршрутизаторів і DNS-серверів) вказуються у вигляді опцій у відповідному
полі. Це повідомлення DHCP-сервер відправляє хосту, що послав
DHCPDISCOVER, на його MAC; за певних обставин повідомлення може
поширюватися як широкомовне розсилання. Клієнт може одержати кілька
різних пропозицій DHCP від різних серверів; з них він повинен вибрати ті,
що його «влаштовують».
3) Запит DHCP. Вибравши одну з конфігурацій, запропонованих
DHCP-серверами, клієнт відправляє запит DHCP (DHCPREQUEST). Він
розсилається широкомовно; при цьому до опцій, зазначених клієнтом у
повідомленні DHCPDISCOVER, додається спеціальна опція – ідентифікатор
сервера, що вказує адресу DHCP-сервера, обраного клієнтом.
166
4) Підтвердження DHCP. Нарешті, сервер підтверджує запит і
направляє це підтвердження (DHCPACK) клієнтові. Після цього клієнт
повинен настроїти свій мережний інтерфейс, використовуючи надані опції.
Система DNS
DNS (Domain Name System – система доменних імен) – комп’ютерна

розподілена система для одержання інформації про домени. Найчастіше
використовується для одержання IP-адреси за іменем хоста (комп’ютера або
пристрою). Розподілена база даних DNS підтримується за допомогою ієрархії
DNS-серверів, що взаємодіють за певним протоколом.
Система DNS містить ієрархію DNS-серверів, що відповідає ієрархії
зон. Кожна зона підтримується як мінімум одним авторитетним сервером
DNS, на якому розташована інформація про домен.
Ім’я й IP-адреса не тотожні – одна IP-адреса може мати безліч імен, що
дозволяє підтримувати на одному комп’ютері безліч веб-сайтів (це
називається віртуальний хостинг). Зворотне теж справедливе – одне ім’я
може бути зіставлене з безліччю IP-адрес: це дозволяє створювати
балансування навантаження.
Для підвищення стійкості системи використовується безліч серверів,
що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють
підтримувати синхронність інформації, розташованої на різних серверах.
Існує 13 кореневих серверів, їхні адреси практично не змінюються. Основні
кореневі сервери DNS розміщені в домені root-servers.net і позначаються
латинськими буквами від A до М.
Протокол DNS використовує для роботи TCP- або UDP-порт 53 для
відповідей на запити. Традиційно запити й відповіді відправляються у
вигляді однієї UDP-дейтаграми.
DNS-запит може бути рекурсивним – таким, що потребує повного
пошуку, і нерекурсивним (або ітеративним) – таким, що не потребує повного
пошуку.
При відповіді на нерекурсивний запит DNS-сервер або повертає дані
про зону, за яку він відповідальний, або повертає помилку. Настроювання
нерекурсивного сервера, коли при відповіді видаються адреси серверів, які
167
мають більший обсяг інформації про запитану зону, ніж сервер, що
відповідає (найчастіше – адреси кореневих серверів), є некоректними.
У випадку рекурсивного запиту DNS-сервер опитує сервери (у порядку
убування рівня).
Зворотний DNS-запит
DNS використовується в першу чергу для перетворення символьних

імен в IP-адреси, але він також може виконувати зворотний процес. Для
цього використовуються вже наявні засоби DNS. Справа в тому, що із
записом DNS можуть бути зіставлені різні дані, у тому числі і яке-небудь
символьне ім’я. Існує спеціальний домен in-addr.arpa, записи в якому
використовуються для перетворення IP-адрес у символьні імена. Наприклад,
для одержання DNS-імені для адреси 11.22.33.44 можна запросити в DNS-
сервера запис 44.33.22.11.in-addr.arpa, і той поверне відповідне символьне
ім’я. Зворотний порядок запису частин IP-адреси пояснюється тим, що в IP-
адресах старші біти розташовані на початку, а в символьних DNS-іменах
старші (що перебувають ближче до кореня) частини розташовані наприкінці.
Створіть топологію, зображену на рис. 11.3 (усі маршрутизатори –

Mikrotik).
168
Перевірка роботи служби DNS
Налаштуйте маршрутизатори відповідним чином
Для маршрутизатора DNS:

[admin@DNS] > ip ad ad ad=10.1.1.1/24 int=ether3
[admin@DNS] > ip route add ga=10.1.1.2
[admin@DNS] /ip dns> static add name=mikrotik1.com ad=192.168.1.1
[admin@DNS] /ip dns> static add name=mikrotik2.com ad=192.168.2.2
[admin@DNS /ip dns> set servers=150.1.1.1 allow-remote-requests=yes
Для маршрутизатора M2:

[admin@M2] > ip ad ad ad=192.168.2.2/24 int=ether2
[admin@M2] > ip route ad gateway=192.168.2.1
Для маршрутизатора M1:

У параметрах адаптеру MSLoopBack встановіть значення, відповідно

до рис. 11.4 (! Як додати MSLoopBack-адаптер див. ЛР №12, стор. 187).
Рисунок 11.4 – Налаштування MSLoopBack-адаптера
Запустіть WireShark на інтерфейсі е2 маршрутизатора DNS. Потім у

командному рядку операційної системи виконайте комаду
С:\ipconfig /flushdns
169
Після цього спробуйте виконати команду ping спочатку на адресу
mikrotik1.com, а потім на mikrotik2.com. Команди повинні пройти успішно. За
допомогою WireShark знайдіть відповідні кадри.
(! Якщо кадри не відображаються спробуйте замінити в топології
комутатор SW1 на концентратор HUB).
На рис. 11.5 наведено кадр запиту до DNS при вирішенні адреси
mikrotik1.com.
Рисунок 11.5 – Структура DNS-запиту
Проаналізуйте DNS-відповідь. Після цього знову спробуйте

пропінгувати адресу mikrotik1.com. У WireShark не будуть відображатися
запити до DNS-серверу, тому що попередній запит був збережений у кеші на
робочій станції. Для перегляду DNS-кешу скористайтеся командою з рядка
операційної системи:
С:\ipconfig /displaydns
Налаштування протоколу DHCP

На маршрутизаторі М1 виконайте налаштування DHCP-сервера:
[admin@M1] ip dhcp-server setup
Select interface to run DHCP server on
170
dhcp server interface: ether1
Select network for DHCP addresses
dhcp address space: 192.168.1.0/24

Select gateway for given network
gateway for dhcp network: 192.168.1.1

Select pool of ip addresses given out by DHCP server
addresses to give out: 192.168.1.3-192.168.1.254

Select DNS servers
dns servers: 10.1.1.1

Select lease time
lease time: 3d
Підключить WireShark до інтерфейсу е0 маршрутизатора М1. В

командному рядку VPCS виконайте команду
VPCS[1]> ip dhcp -d
Ця команда дозволяє отримати ІР-адресу автоматично, якщо в мережі є
DHCP-сервер, при цьому вона виводить етапи отримання цієї адреси
(рис. 12.7). За допомогою WireShark знайдіть відповідні запити та відповіді.
Проаналізуйте їх. Отримайте інформацію про налаштування командою
PCS[1]> sh ip
Спробуйте пропінгувати адресу mikrotik1.com (рис. 11.6).
Рисунок 11.6 – Перевірка отриманих налаштувань
171
Рисунок 11.7 – Етапи отримання ІР-адреси від DHCP-сервера
Аналіз роботи протоколів ICMP, UDP та TCP
Створіть топологію рис. 11.8. У якості маршрутизатора оберіть

маршрутизатор Cisco. Налаштуйте ІР-адреси відповідно до топології
рис. 11.8.
Рисунок 11.8 – Топологія для аналізу роботи протоколів ICMP, UDP та TCP
172
Підключіть WireShark до інтерфейсу е0/0. Виконайте з командного
рядка VPCS такі команди:
VPCS[2]> ping 192.168.1.2 -c 1 -l 100
VPCS[2]> ping 192.168.1.2 -2 -c 1 -l 100
VPCS[2]> ping 192.168.1.2 -3 -c 1 -l 100
Перша, друга і третя команди виконують тест зв’язку між 192.168.2.2

та 192.168.1.2 за допомогою протоколів ICMP, UDP і TCP.
На рис. 11.9. наведено кадри, що захоплені за допомогою WireShark.
Проаналізуйте ці кадри та опишіть етапи та відповідні поля протоколів
взаємодії двух вузлів.
Рисунок 11.9 – Тест зв’язку за допомогою різних протоколів
У WireShark взаємодію вузлів за протоколом ТСР можна отримати у

графічному вигляді. Для цього з меню Statistics оберіть «Flow Graph»
(рис. 11.10).
173
Рисунок 11.10 – Взаємодія між вузлами за протоколом ТСР
1. Що таке сокет?
2. Для чого використовується протокол UDP?
3. Які додатки використовуються для взаємодії за протоколом UDP?
4. Який формат заголовка UDP-дейтаграми?
5. Для чого використовується протокол ІСМР і який формат має
заголовок ІСМР?
6. Для чого використовується протокол ТСР і які поля є у заголовку
ТСР-сегменту?
7. Назвіть основні етапи взаємодії за протоколом ТСР.
8. Назвіть стани сеансу ТСР.
9. Для чого використовується прапор PSH при зв’язку за протоколом
ТСР?
10. Для чого використовується протокол DHCP?
11. Які етапи отримання інформації клієнтом за протоколом DHCР?
12. Яка основна і додаткова інформація може бути отримана за
протоколом DHCР?
13. Для чого використовується DNS?
14. Чим відрізняється рекурсивний DNS-запит від нерекурсивного?
174
1. Вивчити теоретичну і практичну частину.

2. Здати викладачеві теорію, відповівши на контрольні питання.

2. Скріншоти топології рис. 11.3 та 11.8 з зазначенням на них ІР-адрес
усіх інтерфейсів.
175
СПИСКИ УПРАВЛІННЯ ДОСТУПОМ. ЗАХИСТ МЕРЕЖ.
Ознайомлення з принципами управління доступом та набуття

практичних навичок налаштування на маршрутизаторах функцій мережного
екрану.
Список управління доступом (Аccess Сontrol List – ACL) – це

послідовний список правил, які використовуються для дозволу або заборони
потоку пакетів усередині мережі на підставі інформації, наведеної усередині
списку. Без списку доступу усі пакети усередині мережі дозволяються без
обмежень для усіх частин мережі. Список доступу може бути використаний
для контролю поширення і отримання інформації про зміну таблиць
маршрутів і, головне, для забезпечення безпеки. Політика безпеки зокрема
включає захист від зовнішніх атак, обмеження доступу між відділами
організації і розподіл завантаження мережі.
Список доступу дозволяє використовувати маршрутизатор як
міжмережний екран (файервол або брандмауер) для заборони або обмеження
доступу до внутрішньої мережі із зовнішньої мережі, наприклад, з Інтернет.
Брандмауер, як правило, поміщається в точках з’єднання між двома
мережами.
Cisco IOS
Стандартний ACL
При використанні стандартних ACL, єдиним критерієм для визначення
того, що пакет дозволений або заборонений є IP-адреса джерела цього
пакета. Формат елемента списку доступу такий:
Router(config)#access-list # permit | deny source-address source-mask,
176
де # (ціле число) – номер списку доступу, source-address – адреса джерела
пакету, source-mask – маска в інверсній формі, що накладається на адресу;
permit – дозволити проходження пакета, deny – заборонити проходження
пакета. Число # визначає приналежність елемента списку доступу до певного
списку доступу з номером #. Перша команда access-list визначає перший
елемент списку доступу, друга команда визначає другий елемент списку
доступу і так далі. Маршрутизатор обробляє кожен визначений в ньому
список доступу по елементах зверху вниз. Тобто якщо адреса source-address
пакета з урахуванням маски задовольняє умову елемента списку, то подальші
елементи списку маршрутизатор не обробляє. Отже, для уникнення зайвої
обробки, елементи, що визначають загальніші умови, слід поміщати на
початку списку. Усередині маршрутизатора можуть бути визначені декілька
списків доступу. Номер стандартного списку повинен лежати в діапазоні 1 –
99. Маска в списку доступу задається в інверсній формі. Наприклад маска
255.255.0.0 виглядає як 0.0.255.255.
Маршрутизатори Cisco припускають, що усі адреси, не згадані в списку
доступу в явному вигляді, заборонені. Тобто у кінці списку доступу
присутній невидимий елемент
Router(config)#access-list # deny 0.0.0.0 255.255.255.255
Так, якщо ми хочемо дозволити тільки трафік від адреси 1.1.1.1 і
заборонити увесь інший трафік, то достатньо в список доступу помістити
один елемент
Router(config)#access-list 77 permit 1.1.1.1 0.0.0.0.
Тут передбачається, що ми організували список доступу з номером 77.
Розглянемо можливість застосування стандартних списків доступу для
діапазону адрес. Візьмемо, приміром, діапазон 10.3.16.0 – 10.3.31.255. Для
отримання інверсної маски можна відняти із старшої адреси молодшу і
отримати 0.0.15.255. Тоді приклад елемента списку можна задати командою
Router(config)#access-list 100 permit 10.3.16.0 0.0.15.255
Для того щоб список доступу почав виконувати свою роботу, він має
бути застосований до інтерфейсу за допомогою команди
Router(config-if)#ip access-group номер-списка-доступа in або out
Список доступу може бути застосований або як вхідний (in), або як
вихідний (out). Коли ви застосовуєте список доступу як вхідний, то
маршрутизатор отримує вхідний пакет і звіряє його вхідну адресу з
177
елементами списку. Маршрутизатор дозволяє пакету маршрутизуватися на
інтерфейс призначення, якщо пакет задовольняє елементам списку або
відкидає пакет, якщо він відповідає умовам заборонних елементів списку.
Якщо ви застосовуєте список доступу як вихідний, то роутер отримує
вхідний пакет, маршрутизує його на інтерфейс призначення і тільки тоді
обробляє вхідну адресу пакета згідно з елементами списку доступу цього
інтерфейсу. Далі маршрутизатор або дозволяє пакету покинути інтерфейс,
або відкидає його згідно з дозвільними елементами списку або з заборонними
відповідно. Так, створений раніше список з номером 77 застосовується до
інтерфейсу Ethernet 0 маршрутизатора як вхідний список шляхом виконання
команди
Router(config-if)#ip access-group 77 in
Цей же список застосовується до інтерфейсу Ethernet 0 маршрутизатора
як вихідний список за допомогою команди
Router(config - if)#ip access-group 77 out
Відміняється список на інтерфейсі за допомогою команди no:
Router(config - if)#no ip access-group 77 out
Послідовність дій для втілення списку доступу:
1) Визначити критерії і обмеження для доступу.
2. Утілити їх за допомогою команд аccess-list, створивши список
доступу з певним номером.
3. Застосувати список до певного інтерфейсу або як такий, що входить,
або як такий, що виходить.
Зупинимося на останньому пункті. У загальному випадку стандартний
список доступу слід поміщати як можна ближче до точки призначення, а не
до джерела пакетів. Хоча можуть бути виключення. Оскільки стандартний
список доступу працює тільки з початковими адресами, то не завжди
можлива детальна конфігурація. Вимагається докласти зусиль, щоб уникнути
виникнення небажаних конфігурацій доступу. Якщо список поміщений
поблизу джерела пакетів, то дуже ймовірно, що доступ до пристроїв, на яких
не здійснюється ніяка конфігурація доступу, буде ускладнений.
178
Розширені ACL
Із стандартним ACL ви можете вказувати тільки адресу джерела, а
маска не обов’язкова. У розширених ACL ви повинні вказати і адресу
приймача, і адресу джерела з масками. Можете додати додаткову
протокольну інформацію для джерела і призначення. Наприклад, для TCP і
UDP дозволено вказувати номер порту, а для ICMP – тип повідомлення.
Загальна форма команди для формування рядка списку розширеного
списку доступу
access-list ACL-number {permit | deny} protocol source source-wildcard
[operator source - port] destination destination-wildcard [operator
destination - port] [precedence precedence-number] [tos tos] [established]
[log | log-input], де ACL-number – 100 – 199|2000 – 2699, protocol – ip, icmp,
tcp, gre, udp, igrp, eigrp, igmp, ipinip, nos і ospf. Для порту source-port або
destination-port можна використовувати номер порту або його позначення
bgp, chargen, daytime, discard, domain, echo, finger, ftp, ftp - data, gopher,
hostname, irc, klogin, kshell, lpd, nntp, pop2, pop3, smtp, sunrpc, syslog, tacacs-
ds, talk, telnet, time, uucp, whois і www. Operator це eq (дорівнює), neq (не
дорівнює), gt (більше ніж), lt (менше ніж), range (вказується два порти для
визначення діапазону).
Як і для стандартних ACL, розширений ACL слід застосувати до
інтерфейсу. До трафіку, що входить на інтерфейс
Router(config-if)#ip access-group #ACL in
або до трафіку, що виходить з інтерфейсу
Router(config-if)#ip access-group #ACL out
Тут #ACL – номер списку.
Приклади елементів розширеного ACL:
• Дозволити SMTP звідусіль на хост
Router(config)#access-list 111 permit tcp any host 172.17.11.19 eq 25
• Дозволити телнет звідусіль на хост
Router(config)#access-list 111 permit tcp any host 172.17.11.19 eq 23
Розширений ACL дозволяє дуже тонко настроїти права доступу.
Іменовані ACL
До іменованих ACL звертаються за ім’ям, а не за номеру, що дає
наочність і зручність для звернення. Для створення іменованого ACL є
команда
179
Router(config)#ip access-list extended ACL_name
і далі команди для створення елементів списку саме цього іменованого
списку
Router(config-ext-nacl)#permit|deny IP_protocol source_IP_address
wildcard_mask [protocol_information] destination_IP_address
wildcard_mask [protocol_information] [log]
Для завершення створення списку слід дати команду exit.
Ім’я іменованого списку чутливе до регістра. Команди для створення
іменованого списку аналогічні командам для створення елементів
нумерованого списку, але сам процес створення відмінний. Ви повинні
використовувати ключове слово ip перед головним ACL-оператором і тим
самим увійти до режиму конфігурації саме для цього іменованого списку. У
цьому режимі ви починаєте з ключових слів permit або deny і не повинні
вводити access-list на початку кожного рядка. Прив’язка іменованих ACL до
інтерфейсу здійснюється командою
Router(config)#interface type [slot_#]port_#
Router(config-if)#ip access-group ACL_name in|out
ACL обробляються зверху вниз. Трафік, що найбільш часто
повторюється, має бути оброблений на початку списку. Як тільки
оброблюваний списком пакет задовольняє елемент списку, обробка цього
пакета припиняється. Стандартні ACL слід поміщати ближче до точки
призначення, де трафік повинен фільтруватися. Вихідні (out) розширені ACL
слід поміщати як можна ближче до джерела фільтрованих пакетів, а вхідні
слід – до точки призначення, де трафік повинен фільтруватися.
Іменований ACLs дозволяє вам себе редагувати. Для цього потрібно
набрати команду, яка була використана для його створення
Router(config)#ip access-list extended ACL_name
За допомогою клавіш з вертикальними стрілками знайти рядок списку,
який ви хочете змінити. Змінити його, використовуючи горизонтальні
стрілки. Натиснути введення. Новий рядок додасться в кінець списку. Старий
не знищиться. Для його знищення слід ввести no на початку рядка.
MikroTik RouterOS
В MikroTik RouterOS реалізований потужний брандмауер з такими

особливостями:
180
1) повна фільтрація пакетів;
2) фільтрація за протоколом peer-to-peer;
3) класифікація трафіку за:
• вихідною MAC-адресою;
• IP-адресою (мережі або списки) і типами адрес (broadcast, local,
multicast, unicast);
• портами або діапазонами портів;
• IP-протоколами;
• опціями протоколів (ICMP-типи й кодові поля, прапори TCP, IP
опції й MSS);
• вхідним і вихідним трафіком;
• внутрішнім потоком й маркуванням з’єднань;
• ToS(DSCP)-байтом;
• умістом пакету;
• лімітуванням, кількістю пакетів (за станом лічильника).
• розміром пакета;
• кількістю пакетів, отриманих за певний час.
Основні принципи фільтрації
Операції брандмауера виконуються за допомогою правил брандмауера.

Правила мають строгий синтаксис, який дозволяє пояснити маршрутизатору,
що зробити з поточним IP-пакетом. Кожне правило складається із двох
частин: зразока, що використовується для зіставлення правила із трафіком, і
дії, яка визначає, що необхідно зробити у випадку, якщо пакет відповідає
зразку. Для більш зручного керування правила організовані в ланцюжки.
Засіб фільтр постачається за замовчуванням трьома ланцюжками:
input, forward і output. Ці ланцюжки відповідають за вхідний, транзитний і
вихідний трафіки відповідно.
Нові ланцюжки користувача можуть бути додані, як обов’язкові. Зі
старту ці ланцюжки не мають зразків для зіставлення їх із трафіком; правила,
що містять action=jump і jump-target, можуть бути додані в один або більше
ланцюжків за замовчуванням.
181
Фільтруючі ланцюжки
Як згадувалося раніше, правила фільтрації брандмауера групуються

разом у ланцюжки. Ця можливість дозволяє зіставити пакет зразка в одному
ланцюжку й після цього передати його на обробку іншому ланцюжку.
Наприклад, пакет повинен бути зіставлений з парою IP-address:port. Звичайно
це може бути досягнуте шляхом додавання великої кількості правил з
зразком IP-address:port як критерій для ланцюжка forward, але кращим
способом буде додати одне правило для зіставлення з поточною IP-адресою,
тобто /ip firewall filter add src-address=1.1.1.2/32 jump-target=mychain і у
випадку збігу передати керування IP-пакетом деякому іншому ланцюжку,
тобто mychain у даному прикладі. Потім правила зможуть продовжити
зіставлення зі зразком по порту в mychain без перевірки IP-адреси.
Опис трьох ланцюжків, які не можуть бути вилучені:
1) input – використовується для фільтрації трафіку, що входить на
маршрутизатор через один з інтерфейсів з IP-адресою призначення одного із
цих інтерфейсів. Транзитний пакет (пакет, що проходить через
маршрутизатор) не проходить через правила ланцюжка input.
2) forward – використовується для фільтрації транзитних пакетів.
3) output – використовується для фільтрації пакетів, породжених
маршрутизатором і таких, що виходять з одного з інтерфейсів. Транзитний
трафік не попадає в правила ланцюжка output.
Правила, описані при проходженні ланцюжка, розглядаються зверху
вниз. Якщо пакет відповідає критерію правила, то до нього застосовується
певна дія, і пакет припиняє свій рух по ланцюжку, тобто до нього більше не
застосовується жодне правило із цього ланцюжка (виключення становить дія
passthrough). Якщо для пакета не знайдено збігів у ланцюжку, то він
приймається.
Опис властивостей
Усі правила задаються у розділі /ip firewall filter командою add

Основні параметри такі:
182
action(accept | add-dst-to-address-list | add-src-to-address-list | drop |
jump | log | passthrough | reject | return | tarpit; за замовчуванням: accept)
– дія що застосовується до пакета, якщо знайдено відповідність у правилі.
accept – прийняти пакет. Не вживати ніяких дій, тобто пакет прийнятий
і ніякі правила до нього більше не застосовуються.
add-dst-to-address-list – додати адресу призначення IP-пакета в список
адрес, що задано у параметрі address-list.
add-src-to-address-list – додати адресу джерела IP-пакета в список
адрес, що задано у параметрі address-list.
drop – тихо скинути пакет (без посилки ICMP-повідомлення про
відхилення пакета).
jump – стрибнути в ланцюжок, що задано значенням у параметрі jump-
target.
log – кожна відповідність із цієї дії буде додана в системний журнал.
passthrough – ігнорувати це правило й перейти до наступного.
reject – відхилити пакет і послати ICMP-повідомлення про відхилення.
return – повернути контроль у те місце ланцюжка, звідки був
зроблений стрибок.
tarpit – захоплення і втримання вхідних TCP-з’єднань (застосовується
із прапорами SYN/ACK у вхідному TCP SYN-пакеті).
chain (forward | input | output | name) – визначений ланцюжок, у який
вставляється правило. Оскільки різний трафік проходить через різні правила,
то будьте обережні при виборі ланцюжка для визначеного правила. Якщо
уведене значення не буде відповідати назві вже існуючого ланцюжка, то буде
створений новий ланцюжок. Це обов’язкова команда. Зазвичай більша
частина стосується forward трафіку, тобто трафіку, що проходить через
comment(text) – коментар до правила. Коментар, який може
бути використаний для опису правил.
dst-address(IP address/netmask | IP address-IP address) – певний
діапазон IP-адрес призначення. Примітка: консоль конвертує значення
address/netmask у валідну мережну адресу, тобто 1.1.1.1/24 буде конвертовано
в 1.1.1.0/24.
183
dst-address-list(name) – відповідність пакета адресі призначення, взятої
з заданого користувачем списку адрес.
dst-address-type (unicast | local | broadcast | multicast) – відповідність
адрес призначення одному з типів IP-пакетів:
unicast – IP-адреса використана для з’єднання точка-точка. У цьому
випадку цей пакет тільки один посилає й один приймає пакет.
local – відповідність адресам маршрутизатора.
broadcast – пакет посланий від однієї точки всім точкам IP-підмережі.
multicast – цей тип IP-адресації призначений для передачі від однієї або
декількох точок до інших точок.
dst-limit – (integer/time{0,1},integer,dst -address | dst-port | src-
address{+},time{0,1}) – обмеження кількості пакетів за секунду. Лімітується
за IP-адресою призначення або за портом призначення. На відміну від
загального лімітування кожна IP-адреса/порт призначення має свій ліміт.
dst-port (integer: 0..65535-integer: 0..65535{*}) – порт призначення або
діапазон портів.
icmp-options (integer:integer) – відповідність ICMP Type:Code-полям.
in-interface (name) – інтерфейс, на який заходить пакет, що входить в
ipv4-options (any | loose-source-routing | no-record-route | no-router-
alert | no-source-routing | no-timestamp | none | record -route | router-alert |
strict-source-routing | timestamp) – відповідність заголовка опціям ipv4.
out-interface (name) – інтерфейс, через який пакет залишає
packet-size (integer: 0..65535-integer: 0..65535{0,1}) – відповідність
пакета визначеному розміру або розміру в заданому діапазоні (в байтах). Min
– нижня границя розміру діапазону або окремо взятого значення. Max –
верхня границя розміру діапазону.
protocol (ddp | egp | encap | ggp | gre | hmp | icmp | idrp -cmtp | igmp |
ipencap | ipip | ipsec -ah | ipsec-esp | iso-tp4 | ospf | pup | rdp | rspf | st | tcp |
udp | vmtp | xns -idp | xtp | integer) – відповідність визначеному IP-протоколу
за назвою або номером. Вам необхідно використовувати цю можливість,
якщо ви хочете визначати в правилах порти.
184
src-address (IP address/netmask | IP address -IP address) – певний
діапазон IP-пакетів джерела.
src-mac-address (MAC address) – вихідна MAC-адреса (джерела).
src-port (integer: 0..65535-integer: 0..65535{*}) – порт джерела або
діапазон портів.
Перед числовими значеннями може використовуватися заперечення
«!». Наприклад, для завдання в списку розміра пакету більше ніж 100 байт,
можна вказати параметр packet-size наступним чином: packet-size = !0-100.
Створіть топологію, зображену на рис. 8.1. Router1 – маршрутизатор

фірми Cisco; Router2 – Mikrotik. Налаштуйте ІР-адреси відповідно до
топології рис. 8.1. На кожному маршрутизаторі налаштуйте динамічну
маршрутизацію за протоколом RIP.
Прості списки
За допомогою простих списків виконайте наступне обмеження

доступу:
1) Для мереж 10.0.0.0/8 та 192.1.1.0/25:
• забороніть усі пакети з мережі 192.1.1.128/25;
• забороніть пакети з мережі 172.17.0.0/16, крім пакетів від хоста
172.17.0.5.
2) Для мережі 192.1.1.128/25 забороніть усі пакети з мережі
172.17.0.0/16, крім пакетів хоста 172.17.0.2.
185
Для реалізація відповідних пунктів обмеження доступу виконайте

наступні дії:
1) На Router1 виконайте такі команди:
Router1(config)#access-list 2 deny 192.1.1.128 0.0.0.127
Router1(config)#access-list 2 permit host 172.17.0.5
Router1(config)#access-list 2 deny 172.17.0.0 0.0.255.255
Router1(config)#access-list 2 permit 0.0.0.0 255.255.255.255
Router1(config)#interface е0/2
Router1(config-if)#ip access-group 2 in
2) На Router2 виконайте такі команди:
[admin@MikroTik]> ip firewall filter
[admin@MikroTik] /ip firewall filter> add action=accept \
src-ddress=172.17.0.2 chain=forward
[admin@MikroTik] /ip firewall filter> add action=drop \
src-address=172.17.0.0/16 chain=forward
[admin@MikroTik] /ip firewall filter> add action=accept \
src-address=172.17.0.2 chain=input
[admin@MikroTik] /ip firewall filter> add action=drop \
src-address=172.17.0.0/16 chain=input
186
Спробуйте пропінгувати попарно усі хости між собою. Відмітьте
вірність застосування правил брандмауера.
Розширені списки
Видаліть створені прості списки. Для цього на маршрутизаторі Cisco
виконайте команду
Router1(config-if)#no ip access-group 2 in
Router1(config)#no access-list 2
На маршрутизаторі Mikrotik – команду

[admin@MikroTik] /ip firewall filter>remove 0,1,2,3
Для перевірки роботи списку необхідно встановити LoopBack-адаптер.
Для цього з командного рядка операційної системи виконайте команду
hdwwiz. Оберіть встановлення обладнання з списку вручну. Далі знайдіть
розділ «Мережні адаптери» у полі «Стандартні типи адаптерів:». У списку,
що відкриється, оберіть «Адаптер Microsoft замкнення на себе» (рис. 12.2).
Рисунок 12.2 – Встановлення мережного адаптера
Далі перейменуйте встановлений адаптер на MSLoopBack. Задайте IP-

адресу адаптеру за допомогою команди з командного рядка операційної
системи:
netsh interface ip set address name="MSLoopBack" static 172.17.0.3
255.255.0.0 172.17.0.1
187
Додайте до топології ще один хост, та в його налаштуваннях у розділі
NIO Ethernet оберіть створений адаптер та натисніть Add (рис. 12.3.).
Рисунок 12.3 – Налаштування хоста
Підключіть хост через доданий адаптер до комутатора в мережі

172.17.0.0/16. Тепер ви маєте можливість пінгувати будь-який інтерфейс в
віртуальній топології з командного рядка операційної системи (рис. 12.4.).
Рисунок 12.4 – Перевірка зв’язку між MSLoopBack та C1
Наприклад, створіть списки доступу, що виконують наступну задачу: з

мережі 10.0.0.0/8 можливий доступ тільки по telnet на маршрутизатор
188
Router2, а на маршрутизатор Router1 можливий доступ з мережі 172.17.0.0/16
також тільки по telnet. Інший трафік в мережі не заборонений.
Дозвольте заходити на Router1 телнетом з паролем cisco:
Router1(config)#line vty 0 4
Router1(config-line)#login
Router1(config-line)#password cisco
Router1(conf)#access-list 101 permit tcp 172.17.0.0 0.0.255.255 any eq telnet
log
Router1(config)#access-list 101 deny ip 172.17.0.0 0.0.255.255 any
Router1(config)#access-list 101 permit ip any any
Router1(config)#int e0/2
Router1(config-if)#ip access-group 101 in
Тепер з мережі 172.17.0.0 пінг не проходить через маршрутизатор
Router1
Але по telnet доступ є.

Наберіть з командного рядка операційної ситеми команду
C:\telnet 192.1.1.1
Про спрацювання відповідних записів в списку можна подивитися

командою
Router1#sh access-lists
Extended IP access list 101

permit tcp 172.17.0.0 0.0.255.255 any eq telnet (297 matches)
deny ip 172.17.0.0 0.0.255.255 any (28 matches)
permit ip any any (83 matches)
189
На маршрутизаторі Mikrotik необхідно виконати наступні команди:
[admin@MikroTik] /ip firewall filter> add chain=input src-add=10.0.0.0/8 \
protocol=tcp port=23 action=accept
[admin@MikroTik] /ip firewall filter> add chain=input src-add=10.0.0.0/8 \
action=drop
[admin@MikroTik] /ip firewall filter> add chain=forward src-add=10.0.0.0/8 \
action=drop
Переконайтеся, що список працює.
1. Що таке ACL?
2. Яка адреса є критерієм для дозволу/заборони пакета?
3. Де застосовуються ACL?
4. Як задати елемент ACL і що таке інверсна маска?
5. Як роутер обробляє елементи ACL?
6. Який елемент завжди неявно присутній в списках на Cisco, Mikrotik?
7. Чим відрізняється вхідний, вихідний та транзитний трафіку?
8. Де в мережі рекомендується розміщувати ACL?
9. Що фільтрують розширені ACL?
10. Яку додаткову функціональність мають розширені ACL в
порівнянні із стандартними?

\

Створіть топологію, наведену на рис. 8.4.
190
Для налаштування маршрутизаторів Mikrotik скористайтеся
наступними такими способами налаштування:
N%3 0 1 2

Варіант R1 R2 R3
1 Cisco Cisco Mikrotik
3 Cisco Mikrotik Mikrotik
5 Mikrotik Cisco Mikrotik
6 Mikrotik Mikrotik Cisco

net1 v.d.m+10.0 net4 v.d+10.m.0
net2 v.d.m+19.0 net5 v.d+19.m.0
net3 v.d.m+30.0 net6 v.d+30.m.0
Тут d – день народження студента; m – місяць народження студента.
191
Створіть списки доступу, що виконують наступні дії:
1) Забороняють мережний трафік між мережами:
Варіант Мережі Варіант Мережі

1 net1 – net2 3 net3 – net4
2) Дозволяють доступ тільки з відповідного вузла мережі (інші вузли не

мають жодного доступу) по телнет до відповідного маршрутизатора:
Вузол – Вузол –
Варіант Варіант
маршрутизатор маршрутизатор
1 С1 – R1 6 С5 – R2
2 С1 – R2 7 С6 – R1
3 С2 – R3 8 С4 – R3
4 С3 – R1 9 С5 – R3
5 С4 – R2 10 С6 – R2
3) Забороняють пінг між відповідними вузлами:
Варіант Вузол –вузол Варіант Вузол –вузол

1 С1 – С3 6 С3 – С6
2 С1 – С4 7 С4 – С2
3 С2 – С5 8 С4 – С5
4 С2 – С6 9 С4 – С6
5 С3 – С5 10 С1 – С5
4. Забороняють на маршрутизаторах Mikrotik пакети розміром більш

ніж 500+N*10 байт. N – номер по списку.
192

3. Команди, що задають відповідні списки доступу на
маршрутизаторах.
4. Скріншоти, що підтверджують вірність виконання списків доступу.
193
ТРАНСЛЯЦІЯ МЕРЕЖНИХ АДРЕС
Ознайомлення з принципами трансляції мережних адрес та надбання

практичних навичок налаштування на маршрутизаторах функцій NAT.
Network Address Translation (NAT – трансляція мережних адрес)

створена для спрощення і приховання IP-адресації. NAT дозволяє
представити зовнішньому світу внутрішню структуру IP-адресації
підприємства інакше, ніж вона насправді виглядає. Це дозволяє організації
з’єднуватися з Інтернетом, не маючи усередині себе глобальної унікальної
IP-адресації. Це дає можливість виходу в Інтернет для корпоративних
внутрішніх IP-мереж з внутрішніми IP-адресами (intranet), які глобально не
унікальні і тому не можуть маршрутизуватися в Інтернеті. NAT
застосовується також для зв’язку територіально розподілених підрозділів
організації через Інтернет.
Світовою спільнотою для Інтранет адресації виділені такі діапазони
адрес:
Class A : 10.0.0.0 – 10.255.255.255 (маска /8)
Class B : 172.16.0.0 – 172.31.255.255 (маска /12)
Class C : 192.168.0.0 – 192.168.255.255 (маска /16)
NAT переводить внутрішню IP-адресу з внутрішнього адресного
простору в IP-адресу в зовнішньому адресному просторі. Коли NAT отримує
пакет з intranet, він змінює в ньому адресу джерела, перераховує контрольну
суму і відправляє його в Інтернет.
NAT перетворює та відображує адреси з однієї області в іншу. Це
забезпечує прозору маршрутизацію від вузла до вузла. У NAT існує декілька
способів трансляції адрес, використовуваних в різних окремих випадках.
194
Cisco використовує для NAT специфічну термінологію для вузлів в intranet і
Інтернет як до, так і після перетворення адрес. Це такі адреси:
• Внутрішня (inside) – адреса, використовувана в організації. Різні
організації можуть мати однакові внутрішні адреси.
• Зовнішня (outside) – адреса, визначена де-небудь поза цією
організацією. Зовнішня адреса іншої організації може збігатися з
внутрішньою адресою цієї організації.
• Глобальна – зареєстрована і законна адреса IP, яка може проходити
через Інтернет.
• Локальна – адреса, що використовується внутрішньо в іntranet. Ці
адреси не перетинають Інтернет-адреси і тому розглядаються як локальні.
• Внутрішня локальна (inside local) – адреса, що використовується в
організації та не перетинає Інтернет-адреси.
• Внутрішня глобальна (inside global) – адреса, що використовується в
організації та є Інтернет-адресою.
• Зовнішня локальна (outside local) – адреса, визначена де-небудь поза
цією організацією та така, що не є Інтернет-адресою.
• Зовнішня глобальна (outside global) – адреса, визначена де-небудь
поза цією організацією та така, що є Інтернет-адресою.
При відправці пакетів від інтерфейсу внутрішнього хоста NAT замінює
в ньому адресу джерела на деяку глобальну адресу. При прийомі пакета у
відповідь NAT замінює в ньому глобальну адресу приймача (адресу
зовнішнього інтерфейсу локального маршрутизатора) на адресу інтерфейсу
внутрішнього хоста. Для такої заміни маршрутизатор підтримує спеціальні
таблиці перетворень адрес, які постійно оновлюються.
Розрізняють три способи перетворення адрес:
1) статичний;
2) динамічний;
3) перевантаження (overload, PAT, masquerading).
При статичному NAT в явному вигляді є пари внутрішня_адреса =
глобальна_адреса. При динамічному перетворенні глобальні адреси беруться
з певного пулу адрес. При перевантаженні усі внутрішні адреси, що
195
підлягають перетворенню, замінюються на єдину глобальну адресу
зовнішнього інтерфейсу маршрутизатора.
Для конфігурації NAT слід визначити на маршрутизаторі внутрішні і
зовнішні мережі за допомогою команд ip nat inside | outside. Ця команда
визначається на рівні інтерфейсів, тобто в контексті команди interface.
Додаткові команди залежать від використовуваного типу NAT. Це або
завдання статичного NAT, або визначення пулу зовнішніх адрес або завдання
команди для перевантаження. Як правило, слід також задати список
управління доступом ACL для визначення внутрішнього трафіку, який
перетворюватиметься. Сам по собі ACL не здійснює ніякого NAT-
перетворення.
Зупинимося додатково на перевантаженні, яке, як правило, називають
PAT (Port Address Translation – перетворення адрес за допомогою портів або
masquerading). PAT дозволяє декільком внутрішнім хостам використовувати
одну глобальну адресу. Один з варіантів реалізації PAT базується на
використанні послідовності вільних TCP і UDP портів і полягає в такому:
служба NAT знаходиться на маршрутизаторі М з внутрішньою глобальною
адресою X. Нехай є пакет П від внутрішньої локальної адреси Yi і порту Pi до
зовнішньої адреси G і порту p. Пакет проходить через маршрутизатор М.
NAT замінює в ньому адресу Yi джерела і порт джерела Pi внутрішнього
хоста на унікальну пару X : Pinew, де Pinew – черговий вільний номер порту.
Рядок (Yi: Pi, X: Pinew, G: p) заноситься в таблицю NAT маршрутизатора М.
Пакет у відповідь в полі адреси приймача міститиме X, а в полі порту
приймача – Pinew. У полі адреси – порт джерела буде G: p. Маршрутизатор
М за значеннями X, Pinew, G, p знаходить у своїй NAT-таблиці рядок (Yi: Pi,
X: Pinew, G: p) і замінює в пакеті адресу приймача X на Yi, а порт
призначення Pinew – на Pi. Пакет у відповідь прийде за потрібною адресою
Yi з потрібним номером порту призначення Pi. Порт Pinew повертається в
список вільних портів.
Процес NAT прозорий для внутрішніх адрес. Так, хост з внутрішньою
адресою Yi, що відправив пакет в зовнішній світ і отримав відповідь, «не
здогадується», що пакет пройшов NAT-перетворення на маршрутизаторі як
196
при відправці, так і при прийомі. Внутрішньому хосту здається, що він має
безпосередній вихід в зовнішній світ.
Створіть топологію, зображену на рис. 13.1. R1, R2, R3 –

маршрутизатори фірми Cisco. Налаштуйте ІР-адреси відповідно до топології
рис. 13.1. На маршрутизаторах R2 та R3 задайте маршрути за замовчуванням
відповідно на маршрутизатори R1 та Mikrotik.
На R1 дозвольте вхід по telnet з паролем R1:

R1(config)#line vty 0 4
R1(config-line)#password R1
R1(config-line)#login
Необхідно настроїти NAT/PAT на маршрутизаторі R1 та Mikrotik
(Source NAT).
Треба настроїти три форми перетворення адрес: статистичне
перетворення мережних адрес, динамічне перетворення і перевантаження
(перетворення адрес портів).
Припустіть, що мережі 192.168.0.0/24 – це внутрішні мережі intranet,
які з’єднуються із зовнішнім світом (мережа 175.15.0.0/16) через R1 та
Mikrotik.
1.1. На маршрутизаторі R1 настройте NAT на статистичне
перетворення внутрішньої локальної адреси маршрутизатора R2 192.168.0.2 в
адресу 175.15.0.1 (маршрутизатора R1):
R1(config)#ip nat inside source static 192.168.0.2 175.15.0.1
Визначте мережу ethernet0/0 інтерфейсу як внутрішню:

R1(config)#interface ethernet0/0
197
R1(config-if)#ip nat inside
Визначте мережу ethernet0/1 інтерфейсу як зовнішню:

R1(config-if)#interface ethernet0/1
R1(config-if)#ip nat outside

Для виведення таблиці переведень адрес введіть команду на
маршрутизаторі
Rl#show ip nat translations
Перевірте перетворення, створивши telnet-з’єднання з R2 до Mikrotik.
Увійшовши по telnet на Mikrotik, введіть команду user active print. Ви
повинні побачити перетворену IP-адресу 175.15.0.1:
R2#telnet 175.15.0.2
[admin@MikroTik] > user active print
Flags: R - radius
# WHEN NAME ADDRESS
0 nov/04/2013 09:29:25 admin
1 nov/04/2013 09:53:27 admin 175.15.0.1
1.2. На маршрутизаторі Mikrotik виконачте аналогічні дії: настройте
NAT на статистичне перетворення внутрішньої локальної адреси
маршрутизатора R3 192.168.0.2 в адресу 175.15.0.2 (маршрутизатора
Mikrotik):
[admin@MikroTik]> ip firewall nat add chain=srcnat action=src-nat \
src-address=192.168.0.2 to-addresses=175.15.0.2
Перевірте перетворення, створивши telnet-з’єднання з R3 до R1:
R3#telnet 175.15.0.1
Trying 175.15.0.1 ... Open
User Access Verification
Password:
R1>show users
Line User Host(s) Idle Location
0 con 0 175.15.0.2 00:07:53
*130 vty 0 idle 00:00:00 175.15.0.2
2.1. На маршрутизаторі R1 видаліть попередню NAT-команду
статистичного перетворення
R1(config)#no ip nat inside source static 192.168.0.2 175.15.0.1
і настройте NAT для динамічного перетворення адреси маршрутизатора R2.
Використайте область адрес в діапазоні: 175.15.0.50 – 175.15.0.100. Визначте
пул адрес pool1
198
R1(config)#ip nat pool pool1 175.15.0.50 175.15.0.100 netmask
255.255.0.0
Задайте NAT-перетворення адрес із списку 1 в пул адрес pool1:
R1(config)#ip nat inside source list 1 pool pool1
Настройте і перевірте список доступу 1 для внутрішніх адрес, які
перетворюватимуться:
R1(config)#access-list 1 permit 192.168.0.0 0.0.0.255
Перевірте перетворення:
R2#telnet 175.15.0.2
[admin@MikroTik] > user active print
Flags: R - radius
# WHEN NAME ADDRESS
0 nov/04/2013 09:29:25 admin
1 nov/04/2013 10:31:16 admin 175.15.0.50
2.2. На маршрутизаторі Mikrotik видаліть попередню NAT-команду

статистичного перетворення:
[admin@MikroTik]> ip firewall nat remove 0
Та задайте динамічне перетворення:
[admin@MikroTik]> ip firewall nat add chain=srcnat action=netmap \
src-address=192.168.0.0/24 to-addresses=175.15.0.0/24
! При цьму необхідно додати усі ІР-ареси, що входять до пулу, на

інтерфейс Ether1 маршрутизатора Mikrotik. Крім того, останній октет ІР-
адрес хостів, що знаходяться за NAT, повинні мати те ж саме значення, що і
останній октет пулу.
3.1. На маршрутизаторі R1 видаліть попередні NAT-команди

динамічного перетворення:
R1(config)#no ip nat pool pool1 175.15.0.50 175.15.0.100 netmask
255.255.0.0
R1(config)#no ip nat inside source list 1 pool pool1
Налаштуйте перевантаження (перетворення адрес портів) адреси

маршрутизатора R2 (192.168.0.2) на адресу інтерфейсу Ethernet 0/1
(175.15.0.1) на маршрутизаторі R1:
R1(config)#ip nat inside source list 1 interface e0/1 overload
Перевірте перетворення:
R2#telnet 175.15.0.2
199
R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 175.15.0.1:11000 92.168.0.2:11000 175.15.0.2:23 175.15.0.2:23
3.2. На маршрутизаторі Mikrotik видаліть попередню NAT-команду
динамічного перетворення:
[admin@MikroTik]> ip firewall nat remove 0
Та задайте динамічне перевантаження:
[admin@MikroTik]> ip firewall nat add chain=srcnat action=masquerade \
out-interface=ether1
Перевірте перетворення.
Виконаємо перевірку механізму Destination NAT. Для цього додайте в

топологію хост, що зв’язаний з адаптером MSLoopBack та ще один
маршрутизатор Mikrotik_2. Припустимо, що маршрутизатор Mikrotik_2
виконує роль Web-серверу та знаходиться у внутрішній мережі. В такому
випадку необхідно надати доступ до цього маршрутизатора з зовнішньої
мережі, тобто використати механізм DstNAT (рис. 13.2).
Рисунок 13.2 – Топологія практичної частини для дослідження DstNAT
На маршрутизаторі Mikrotik додайте команду, що буде виконувати

перетворення зовнішньої адреси на внутрішню адресу для протоколу ТСР
порт 80 (за замовченням використовується протоколом HTTP Web-серверу).
[admin@MikroTik] > ip firewall nat add chain=dstnat dst-port=80 \
protocol=tcp to-addresses=192.168.0.200 to-ports=80 action=dst-nat
200
Спробуйте зайти з браузеру на ІР-адресу 175.15.0.2. Ви повинні
потрапити в Web-інтерфейс маршрутизатору Mikrotik_2 (На маршрутизаторі
Mikrotik_2 повинен бути налаштован маршрут за замовченням на адресу
192.168.0.1).
1. Які завдання вирішує NAT?

2. Як пов’язана проблема нестачі IP-адрес і NAT?
3 Які ви знаєте діапазони для Інтранет-адресації?
4. Що таке внутрішня адреса?
5. Що таке зовнішня адреса?
6. Що таке глобальна адреса?
7. Що таке локальна адреса?
8. Що таке внутрішня локальна адреса?
9. Що таке внутрішня глобальна адреса?
10. Що таке зовнішня глобальна адреса?
11. Що таке зовнішня локальна адреса?
12. Назвіть три способи перетворення адрес. Чим вони відрізняються?
13. Поясніть, як працює PAT.
14. Яка функціональність втрачається у хоста з внутрішньою
локальною адресою в мережі, що має зв’язок із зовнішнім світом через NAT,
в порівнянні з хостом з глобальною адресою?

4. Оформити звіт (зміст звіту дивиться нижче).
201

Створіть топологію, наведену на рис. 13.3.
Для налаштування маршрутизаторів Mikrotik скористайтеся
N%3 0 1 2

Варіант R1 R2 R3- R6
Виконайте усі пункти завдання практичної частини.

3. Скріншоти, що підтверджують спрацювання NAT (виконати для
кожного маршрутизатора R3 – R6).
202
ТЕХНОЛОГІЯ ПРОКСІ-СЕРВЕР
Ознайомлення з принципами організації проксі-серверів. Набуття

практичних навичок налаштування на мережному обладнанні функцій
проксі-серверу.
Проксі-сервер (від англ. proxy – представник, уповноважений) – сервер

(комп’ютерна система або програма), який дозволяє клієнтам виконувати
непрямі (через посередництво проксі-сервера) запити до мережних сервісів.
Спочатку клієнт з’єднується з проксі-сервером і запитує який-небудь ресурс,
розташований на іншому сервері. Потім проксі-сервер або підключається до
вказаного сервера і отримує ресурс у нього, або повертає ресурс з власного
кешу (у випадках, якщо проксі має свій кеш). У деяких випадках запит
клієнта або відповідь сервера може бути змінена проксі-сервером з певною
метою. Також проксі-сервер дозволяє захищати клієнтський комп’ютер від
деяких мережних атак і допомагає зберігати анонімність клієнта.
Найчастіше проксі-сервери застосовуються з метою:
• Забезпечення доступу з комп’ютерів локальної мережі до
Інтернету.
• Кешування даних: якщо часто відбуваються звернення до тих
самих зовнішніх ресурсів, то можна тримати їх копію на проксі-сервері та
видавати за запитом, знижуючи тим самим навантаження на канал у
зовнішню мережу і прискорюючи отримання клієнтом шуканої інформації .
203
• Стиснення даних: проксі-сервер завантажує інформацію з
Інтернету і передає її кінцевому користувачеві в стислому вигляді. Такі
проксі-сервери використовуються в основному з метою економії зовнішнього
трафіка.
• Захисту локальної мережі від зовнішнього доступу: наприклад,
можна налаштувати проксі-сервер так, що локальні комп’ютери будуть
звертатися до зовнішніх ресурсів тільки через нього, а зовнішні комп’ютери
не зможуть звертатися до локальних взагалі, тому що вони бачать тільки
проксі-сервер (чимось схоже на техологію NAT).
• Обмеження доступу з локальної мережі до зовнішньої: наприклад,
можна заборонити доступ до певних веб-сайтів, обмежити використання
Інтернету якимось локальним користувачам, встановлювати квоти на трафік
або смугу пропускання, фільтрувати рекламу і віруси.
• Анонімізації доступу до різних ресурсів. Проксі-сервер може
приховувати відомості про джерело запиту або користувача. У такому разі
цільовий сервер бачить лише інформацію про проксі-сервер, наприклад, IP-
адресу, але не має можливості визначити дійсне джерело запиту. Існують
також спотворюючі проксі-сервери, які передають цільовим серверам
неправдиву інформацію про справжнього користувача.
Проксі-сервер, до якого може отримати доступ будь-який користувач
мережі Інтернет, називається відкритим.
Крім звичайних проксі-серверів, можуть бути ще такі:
1. Прозорий проксі – схема зв’язку, при якій трафік, або його частина,
перенаправляється на проксі-сервер неявно (засобами маршрутизатора). При
цьому клієнт може використовувати всі переваги проксі-сервера без
додаткових налаштувань, алеу той же час він не має можливості вибору.
2. Зворотний проксі – на відміну від прямого, він ретранслює запити
клієнтів із зовнішньої мережі на один або декілька серверів, логічно
розташованих у внутрішній мережі. Часто використовується для
204
балансування мережного навантаження між декількома веб-серверами і для
підвищення їх безпеки, відіграючи при цьому роль міжмережного екрана на
прикладному рівні.
Рисунок 14.1 – Типова схема роботи проксі-сервера
Принцип роботи проксі-сервера
Клієнтський комп’ютер має налаштування (конкретної програми або

операційної системи), відповідно до якої всі мережні з’єднання за деяким
протоколом здійснюються не на IP-адресу сервера (ресурсу), а на IP-адресу (і
інший порт) проксі-сервера.
За необхідності звернення до будь-якого ресурсу за цим протоколом,
клієнтський комп’ютер відкриває мережy з’єднання з проксі-сервером (на
потрібному порті) і здійснює звичайний запит, начибто він звертався
безпосередньо до ресурсу.
205
Розпізнавши дані запиту, перевіривши його коректність і дозвіл для
клієнтського комп’ютера, проксі-сервер, не розриваючи з’єднання, сам
відкриває нове з’єднання безпосередньо з ресурсом і робить той же самий
запит. Отримавши дані (або повідомлення про помилку), проксі-сервер
передає їх клієнтському комп’ютеру.
З цього випливають два основні обмеження звичайного проксі-сервера:
1. Проксі-сервер повинен бути повнофункціональним сервером і
клієнтом для кожного підтримуваного протоколу.
2. Проксі-сервер може обслуговувати тільки ті мережні протоколи, у
запиті яких передається ім’я або IP-адреса ресурсу (не відноситься до
прозорих проксі – вони отримують IP-адресу безпосередньо з перехопленого
з’єднання).
У часи становлення Інтернету проксі-сервери були найпопулярнішим
способом виходу в Інтернет з локальних мереж. Цьому сприяли такі
обставини:
– Використання основного протоколу – http, який легко просіюється.
– Підтримка проксі більшістю браузерів і/або операційних систем.
– Контроль доступу та облік трафіку щодо користувачів.
– Проксі-сервер – це звичайна програма (а не системна), яка може
працювати з мінімальними правами на будь-якій ОС з підтримкою мережі
(стека TCP/IP);
– Відсутність доступу в Інтернет за іншими протоколами часто ставала
скоріше перевагою, ніж недоліком.
У зв’язку із зростаннямролі інших мережних протоколів, переходом до
тарифікації послуг Інтернету за швидкістю доступу, а також появою дешевих
апаратних маршрутизаторів з функцією NAT, використання звичайних
проксі-серверів для виходу користувачів до Інтернету застосовується вкрай
рідко. Однак великого поширення набули прозорі проксі-сервери (протоколу
http, іноді деяких інших), в тому числі і ті, що входять до складу багатьох
206
апаратних маршрутизаторів для доступу до Інтернету, з метою збору
статистики та контролю доступу до сайтів. Інші порти (протоколи) при цьому
проходять через NAT.
Конфігурація Proxy в Mikrotik RouterOS

Конфігурація здійснюється через підменю /ip proxy згідно табл. 14.1.
Таблиця 14.1 – Конфігурація проксі в Mikrotik RouterOS
Властивість Опис
cache-administrator (string; Default: Електронна пошта адміністратора, яка
webmaster) відображається на сторінці помилки проксі-
сервера
cache-on-disk (yes | no; Default: no) Виконувати кешування на диск, чи
оперативну пам’ять
max-cache-size (none | unlimited | integer: Визначає максимальний розмір кешу,
0..4294967295; Default: none) виміряний у кілобайтах
max-client-connections (integer: Dynamic; Максимальна кількість підключень,
Default: 600) прийнятих від клієнтів (будь-які подальші
з'єднання будуть відхилені)
max-fresh-time (time; Default: 3d) Максимальний час для зберігання
кешованого об’єкта. Період дійсності
об’єкта, як правило, визначається самим
об’єктом, але у випадку, якщо він
встановлений занадто великим, можна
перевизначити максимальне значення
max-server-connections (integer: Dynamic; Максимальна кількість підключень до
Default: 600) серверів (будь-які подальші з’єднання з
клієнтами будуть призупинені, доки деякі
з’єднання з сервером не припиняться)
parent-proxy (Ip4 | ip6; Default: 0.0.0.0) IP-адреса та порт іншого HTTP-проксі для
переадресації всіх запитів. Якщо
встановлено значення 0.0.0.0, батьківський
проксі не використовується
parent-proxy-port (integer: 0..65535; Default: Порт, який прослуховує батьківський
0) проксі
207
Продовження табл. 14.1
TCP порт, який проксі-сервер буде слухати.
port (integer: 0..65535; Default: 8080)
Цей порт повинен бути вказаний для всіх
клієнтів, які хочуть використовувати сервер
як HTTP-проксі. Прозоре (з нульовою
конфігурацією для клієнтів) налаштування
проксі-сервера може бути зроблено шляхом
перенаправлення HTTP-запитів до цього
порту в брандмауері IP за допомогою
функції destination NAT
Підменю /ip proxy access дає можливість створення списку доступу до

ресурсів, які запитує клієнт. Список доступу налаштовується як звичайні
правила брандмауера. Правила обробляються зверху вниз. Перше правило
відповідності визначає, що робити з цим з’єднанням. Існує 6 класифікаторів,
які задають відповідні обмеження. Якщо жоден з цих класифікаторів не
вказаний, конкретне правило буде відповідати кожному з них. Якщо
з’єднання добирається правилом, властивість дії цього правила вказує, чи
буде дозволено з’єднання. Якщо конкретне з’єднання не відповідає жодному
правилу, воно буде дозволено.
Fetch
Fetch – один з консольних інструментів в Mikrotik RouterOS. Він

використовується для копіювання файлів з будь-якого мережного пристрою
на маршрутизатор Mikrotik через HTTP або FTP. В останніх версіях RouterOS
можна також завантажувати файли в віддалені місця розташування. Опис
властивостей Fetch RouterOS наведено у табл. 14.2.
Таблиця 14.2 – Властивості Fetch RouterOS

address (string; Default: ) IP-адреса пристрою для копіювання файлу
check-certificate (yes | no; Вмикає перевірку надійності мережі довіри з
Default: no) місцевого магазину сертифікатів
208
dst-path (string; Default: )
Назва файлу та шлях призначення
host (string; Default: )
Доменне ім’я або віртуальне доменне ім’я (якщо
використовується на веб-сайті, з якого ви хочете
копіювати інформацію). Наприклад,
address=wiki.mikrotik.com host=forum.mikrotik.com
У цьому прикладі отримана IP-адреса однакова
(66.228.113.27), але хости є різними
keep-result (yes | no; Default: yes)
Якщо так, створюється вхідний файл.
mode (ftp|http|tftp {!} https;
Протокол підключення - http, https, ftp або tftp
Default: http)
password (string;
Пароль, який потрібен для автентифікації на
Default: anonymous)
віддаленому пристрої
port (integer; Default: )
Порт з'єднання
src-path (string; Default: )
Назва дистанційного файлу, який потрібно
скопіювати
upload (yes | no; Default: no)
Якщо ввімкнено, то завантаження буде використано
для завантаження файлу на віддалений сервер
Потрібно встановити параметри src-path та dst-path
url (string; Default: )
URL, що вказує на файл. Можна використовувати
замість параметрів адреси та src-шляху
user (string; Default: anonymous)
Ім’я користувача, яке потрібне для автентифікації на
віддаленому пристрої
Створіть топологію, зображену на рис. 14.2 (необхідні маршрутизатори

вказано на рисунку). Налаштуйте ІР-адреси відповідно до топології рис. 14.2.
На маршрутизаторі Client задайте маршрут за замовчуванням на
маршрутизатор Proxy.
209
Рисунок 14.2 – Топологія для практичної частини роботи
Налаштування звичайного проксі-серверу
Створіть простий html-документ за допомогою будь-якого текстового

редактора. Помістіть у нього наступний код:
<!DOCTYPE html>
<html>
<body>
<h1>Welcome!</h1>
<h2>Testing proxy!</h2>
<p>This page on Cisco HTTP-Server!</p>
</body>
</html>
Збережіть файл з ім’ям «test.html». Завантажте цей файл на

маршрутизатор Proxy. Для цього підключіться до маршрутизатора за
допомогою Winbox. Зайдіть у розділ Files та за допомогою звичайного
перетаскування перетащіть створений файл у Winbox. Ви маєте побачити цей
файл у списку (рис. 14.3).
Рисунок 14.3 – Копіювання файлу на маршрутизатор
Надайте можливість маршрутизатору WebServer виступати у ролі Web-

сервера шляхом виконання наступних команд:
WebServer(config)#ip http server
WebServer(config)#ip http path flash
210
WebServer(config)#ip http port 80
Скопіюйте файл з ім’ям «test.html» з маршрутизатора Proxy на

маршрутизатор WebServer:
WebServer#copy ftp://admin:@1.1.1.2/test.html flash:test.html

Destination filename [test.html]?
Accessing ftp://admin@1.1.1.2/test.html...
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Loading test.html
[OK - 133/4096 bytes]
Verifying checksum... OK (0x29F4)

133 bytes copied in 0.532 secs
Перейдіть у Winbox маршрутизатора Proxy у розділ «IP->Web Proxy» та

налаштуйте звичайний проксі відповідно до рис. 14.4.
Рисунок 14.4 – Налаштування звичайного проксі
Крім того, забороніть будь-які пакети, що йдуть через маршрутизатор

Proxy (без використання функції проксування), тобто, щоб клієнти не змогли
отримати доступ до мережі без проксі:
[admin@Proxy] > ip firewall filter add chain=forward action=reject \
211
reject-with=icmp-network-unreachable
Тепер для роботи з зовнішними вузлами клієнтам необхідно

налаштувати можливість отримання доступу через проксі-сервер. Наприклад,
у браузері Firefox налаштування проксі виконується в розділі
«Налаштування» (рис. 14.5).
Рисунок 14.5 – Налаштування проксі-сервера для клієнта
Спробуйте зайти на сайт Web-сервера. В рядку адреси браузера введіть

запит:
Ви маєте отримати раніш завантажений на Web-сервер файл «test.html»

(рис. 14.6).
Рисунок 14.6 – Результат завантаження файлу через проксі-сервер
При аналізі трафіка, отриманого за допомогою WireShark на інтерфейсі

e0/0 маршрутизатора WebServer, можна переконатися, що весь обмін з Web-
сервером виконує проксі-сервер (ІР-адреса відправника 1.1.1.2) (рис. 14.7).
212
Рисунок 14.7 – Процес отримання файлу проксі-сервером
Налаштування «прозорого» проксі-сервера
Для налаштування функцій «прозорого» проксі-сервера необхідно

виконувати перенаправлення трафіку, який йде через маршрутизатор, на
внутрішній проксі-сервер. Це виконується за допомогою механізму
Destination NAT.
Додайте правило перенаправлення трафіку:
[admin@Proxy] > ip firewall nat add chain=dstnat \
src-address=192.168.3.0/24 protocol=tcp dst-port=80 action=redirect \
to-ports=3128
Вимкніть у браузері підключення через проксі-сервер та спробуйте

знову завантажити файл «test.html». Завантаження повинне здійснитися
успішно.
Спробуйте зробити завантаження файлу «test.html» з маршрутизатора
Client. Для емуляції завантаження за протоколом HTTP скористайтеся
утилітою fetch:
[admin@Client]> tool fetch url="http://1.1.1.1/test.html"
status: finished
При аналізі трафіку за допомогою WireShark на інтерфейсі e0/0
маршрутизатора WebServer так само можна переконатися, що обмін з Web-
сервером виконує проксі-сервер (рис. 14.8).
Рисунок 14.8 – Процес отримання файлу з маршрутизатора Client
213
Блокування сайту за DNS
Трапляються випадки, коли потрібно заблокувати доступ до сайту.

Блокувати можна за IP-адресою, але у деяких сайтів їх багато, тоді легше
всього заборонити доступ до сайту, заблокувавши його за DNS. Проксі-
сервер може виконувати таку функцію.
Видаліть правило перенаправлення трафіку та в налаштуванні браузера
застосуйте підключення через проксі-сервер.
Налаштуйте блокування усіх сайтів DNS, які мають фразу «vk» в DNS-
імені:
[admin@Proxy] > ip proxy access add dst-host=*vk* action=deny
Спробуйте зайти на будь-яку адресу, що має в своєму складі фразу

«vk». Наприклад, при спробі зайти на сайт «vk1.com» ви повинні отримати
повідомлення про заборону доступу (рис. 14.9).
Рисунок 14.9 – Повідомлення про заборону доступу на відповідний сайт
214
1. Для чого використовуються проксі-сервери?

2. Що таке «прозорий» проксі-сервер?
3. Для чого використовується зворотний проксі-сервер?
4. Як налаштувати маршрутизатор Mikrotik на фунцію проксі-сервера?
5. Як налаштовуються функції «прозорого» проксі на маршрутизаторі
Mikrotik?
6. Для чого використовується утиліта Fetch?
7. Як виконати блокування сайту за DNS-адресою?


інтерфейсів.
215
ВІРТУАЛЬНІ ПРИВАТНІ МЕРЕЖІ
Ознайомлення з принципами організації віртуальних приватних мереж

VPN. Набуття практичних навичок налаштування протоколів, що реалізують
функції VPN на мережному обладнанні.
VPN (Virtual Private Network – віртуальна приватна мережа) являє

собою об’єднання окремих машин або локальних мереж у віртуальній
мережі, що забезпечує цілісність і безпеку переданих даних. Вона має
властивості виділеної приватної мережі й дозволяє передавати дані між
двома комп’ютерами через проміжну мережу (internetwork), наприклад
Internet.
VPN відрізняється рядом економічних переваг у порівнянні з іншими
методами віддаленого доступу. По-перше, користувачі можуть звертатися до
корпоративної мережі, не встановлюючи з нею комутуючого з’єднання.
Таким чином, відпадає потреба у використанні модемів. По-друге, можна
обійтися без виділених ліній.
Маючи доступ в Інтернет, будь-який користувач може без проблем
підключитися до мережі офісу своєї фірми. Варто помітити, що
загальнодоступність даних зовсім не означає їхню незахищеність. Система
безпеки VPN – це броня, що захищає всю корпоративну інформацію від
несанкціонованого доступу. Насамперед, інформація передається в
зашифрованому вигляді. Прочитати отримані дані може лише власник ключа
до шифру.
Підтвердження справжності містить у собі перевірку цілісності даних і
ідентифікацію користувачів, задіяних у VPN. Перша гарантує, що дані
дійшли до адресата саме в тому вигляді, у якому вони були послані. Самі
216
популярні алгоритми перевірки цілісності даних – MD5 і SHA1. Далі система
перевіряє, чи не були змінені дані під час руху по мережах помилково або
зловмисно. Таким чином, побудова VPN припускає створення захищених від
стороннього доступу тунелів між декількома локальними мережами або
віддаленими користувачами.
Для побудови VPN необхідно мати на обох кінцях лінії зв’язку
програми шифрування вихідного й дешифрування вхідного трафіків. Вони
можуть працювати як на спеціалізованих апаратних пристроях, так і на ПК.
Керування доступом, аутентифікація й шифрування – найважливіші
елементи захищеного з’єднання.
Основи тунелювання
Тунелювання (tunneling) – це спосіб передачі корисної інформації через

проміжну мережу. Такою інформацією можуть бути кадри (або пакети)
іншого протоколу. При інкапсуляції кадр не передається в згенерованому
вузлом-відправником вигляді, а забезпечується додатковим заголовком, що
містить інформацію про маршрут, що дозволяє інкапсульованим пакетам
проходити через проміжну мережу (Internet). На кінці тунелю кадри
деінкапсулюються й передаються одержувачеві. Цей процес (що включає
інкапсуляцію й передачу пакетів) і є тунелювання. Логічний шлях
пересування інкапсульованих пакетів у транзитній мережі називається
тунелем.
VPN працює на основі протоколу PPP.
PPP (англ. Point-to-Point Protocol) – двоточковий протокол канального
рівня мережної моделі OSI. Зазвичай використовується для встановлення
прямого зв’язку між двома вузлами мережі, причому він може забезпечити
аутентифікацию з’єднання, шифрування й стискання даних.
Використовується на багатьох типах фізичних мереж:на нуль-модемному
кабелі, телефонній лінії, стільниковому зв’язоку, послідовних каналах зв’язку
й т. д. PPP являє собою ціле сімейство протоколів: протокол керування
лінією зв’язку (LCP – Link Control Protocol), протокол керування мережею
(NCP – Network Control Protocol), протоколи аутентифікації (PAP, CHAP),
217
багатоканальний протокол PPP (MLPPP), протокол стиску CCP (compression
control protocol), протокол шифрування ECP (encryption control protocol) і т. д.
PPP-протокол був розроблений на основі протоколу HDLC і
доповнений деякими можливостями, які до цього зустрічалися тільки в
комерційних протоколах. PPP дозволяє працювати декільком протоколам
мережного рівня на одному каналі зв’язку. Інакше кажучи, усередині
одного PPP-з’єднання можуть передаватися потоки даних різних мережних
протоколів (IP, Novell IPX і т. д.), а також дані протоколів канального рівня
локальної мережі. Після встановлення з’єднання для настроювання
кожного мережного протоколу використовується протокол NCP. Він
використовується для узгодження й визначення настроювань мережного
рівня, таких як мережна адреса або настроювання стискання.
Кожний кадр PPP завжди починається й завершується прапором 0x7E.
Потім йде байт адреси й байт керування, які теж завжди дорівнюють 0xFF і
0x03 відповідно. У зв’язку з імовірністю збігу байтів усередині блоку
даних із зарезервованими прапорами, існує система автоматичного
коректування «проблемних» даних з наступним відновленням.
Фази PPP
– Link Dead. Ця фаза настає, коли зв’язок порушений, або коли одній зі
сторін вказали не підключатися (наприклад, користувач завершив модемне
з’єднання.)
– Установлення зв’язку (Link Establishment Phase). У даній фазі
проводиться настроювання лінії за допомогою протоколу LCP. Якщо
настроювання було успішне, керування переходить у фазу аутентифікації або
у фазу Network-Layer Protocol, залежно від того, чи потрібна аутентифікація.
– Аутентифікація (Authentication Phase). Дана фаза є необов’язковою.
Вона дозволяє сторонам перевірити одна одну перед установленням
з’єднання. Якщо перевірка успішна, керування переходить у фазу Network-
Layer Protocol.
– Протокол мережного рівня (Network-Layer Protocol Phase). У даній
фазі викликається NCP для бажаного протоколу. Наприклад, IPCP
використовується для встановлення IP-сервісів. Передача даних також
218
проходить у цій фазі. Закриття мережних протоколів теж включається в дану
фазу.
– Link Termination Phase. Ця фаза закриває з’єднання. Вона
викликається у випадку помилок аутентифікації: якщо було настільки багато
помилок контрольних сум, що обидві сторони вирішили закрити з’єднання;
якщо з’єднання раптом обірвалося; якщо користувач відключився. Дана фаза
намагається закрити все настільки акуратно, наскільки це можливо в даних
обставинах.
Протоколи PPTP, SSTP і L2TP
Протоколи PPTP (Point-to-Point Tunneling Protocol) – тунельний

протокол типу точка-точка, L2TP (Layer 2 Tunneling Protocol – протокол
тунелювання другого рівня, SSTP (Secure Socket Tunneling Protocol –
протокол безпечного тунелювання сокетів) ґрунтуються на протоколі PPP,
включають його в себе повністю й відрізняються від нього лише способом
організації каналу зв’язку. У всіх трьох випадках для організації каналу
використовується вже існуючий зв’язок між клієнтом і сервером за
протоколом IP. У протоколі PPTP для організації каналу використовується
протокол GRE (Generic Routing Encapsulation – загальна інкапсуляція
маршрутів), кадри якого містяться в полях даних протоколу IP. Далі кадри
протоколу PPP інкапсулюються в кадри GRE. PPTP-сервер слухає порт 1723.
У самій початковій стадії PPTP-клієнт домовляється із сервером про
параметри GRE PPP-тунелю. Далі все бере на себе PPP.
Після організації зв’язку й установлення TCP-з’єднання поверх PPTP-
тунелю має місце наступна інкапсуляція протоколів: IP[GRE[PPP[IP[TCP]]]]
(якщо не використовується шифрування й стиснення).
Протокол L2TP і для організації зв’язку, і для передачі даних
використовує UDP-протокол. Для установлення зв’язку використовується
UDP-порт 1701. Далі все бере на себе PPP.
Після організації зв’язку й встановлення TCP-з’єднання поверх L2TP-
тунелю має місце наступна інкапсуляція протоколів: IP[UDP[L2TP[IP[TCP]]]]
(якщо не використовується шифрування й стиснення).
219
У протоколі SSTP для організації каналу використовується
шифрування за протоколом SSL. У SSTP установлення з’єднання й обмін
даними відбувається в зашифрованому вигляді. Як правило, для
установлення зв’язку за SSL-протоколом клієнт і сервер використовують
сертифікати. Ключі із сертифікатів застосовуються для аутентифікації й
шифрування трафіку.
OpenVPN
OpenVPN не використовує PPP. OpenVPN для організації зв’язку й для

передачі даних використовує протокол UDP або TCP. Далі в поля даних цих
протоколів поміщаються кадри протоколів IP (інтерфейс tun) або Ethernet
(інтерфейс tap), які шифруються за допомогою OpenSSL. Процедура
установлення зв’язку й підтримка протоколу мережного рівня є
оригінальними розробками. Для встановлення зв’язку за OpenVPN-
протоколом клієнт і сервер використовують сертифікати й/або паролі. Ключі
із сертифікатів застосовуються для аутентифікації й шифрування трафіку. В
OpenVPN встановлення з’єднання й обмін даними відбувається в
зашифрованому вигляді.
Протокол ЕоІР
Ethernet через IP (EoIP) – це протокол MikroTik RouterOS, що створює

тунель Ethernet між двома маршрутизаторами за допомогою IP-з’єднання.
Інтерфейс EoIP з’являється в якості інтерфейсу Ethernet. Це дає можливість
об’єднати різні точки в один домен широкомовлення, виконуючи створення
тунелю через IP-мережі.
Налаштування протоколу EoIP.

Створіть топологію, зображену на рис. 15.1 (усі маршрутизатори –
Mikrotik).
220
Налаштуйте маршрутизатори відповідним чином
Для маршрутизатора Mikrotik:

[admin@R1] > ip ad ad ad=10.1.1.1/24 int=ether1
[admin@R1] > ip route add ga=1.1.1.1
[admin@R1] > int eoip add remote-address=1.1.2.2 tunnel-id=1 \
disabled=no
[admin@R1] > int bridge add
[admin@R1] > int bridge port add bridge=bridge1 interface=eoip-tunnel1
[admin@R1] > int bridge port add bridge=bridge1 interface=ether1
Для маршрутизатора Mikrotik_2:

Для маршрутизатора Mikrotik_3:

[admin@R3] > ip route add ga=1.1.2.1
[admin@R3] > int eoip add remote-address=1.1.1.2 tunnel-id=1 \
disabled=no
[admin@R3] > int bridge add
[admin@R3] > int bridge port add bridge=bridge1 interface=eoip-tunnel1
[admin@R3] > int bridge port add bridge=bridge1 interface=ether1
221
Налаштування VPCS:
VPCS[1]> ip 10.1.1.3/24 10.1.1.1
VPCS[2]> ip 10.1.1.4/24 10.1.1.2
Спробуйте виконати команду ping:

VPCS[2]> ping 10.1.1.3 -c 1
Команда повинна виконатися успішно.
На Mikrotik_3 виконайте команду
[admin@R3] > int bridge host pr
На Mikrotik виконайте команду

[admin@R1] > int bridge host pr
За допомогою WireShark, отримайте захоплення пакетів на інтерфейсі

е1 маршрутизатора Mikrotik_3. Виконайте ще раз команду
VPCS[2]> ping 10.1.1.3 -c 1
Проаналізуйте відповідні пакети. На рис. 15.2 наведено пакет ехо-
запиту.
Рисунок 15.2 – Аналіз пакета ехо-запиту
222
Зупиніть топологію. Додайте в налаштуванні qemu маршрутизаторів
наступні параметри:
для Mikrotik:
-net nic,vlan=6 -net tap,vlan=6,ifname=tap0
для Mikrotik_3:
-net nic,vlan=6 -net tap,vlan=6,ifname=tap1
Запустіть топологію. Видаліть попередні налаштування на
маршрутизаторах Mikrotik та Mikrotik_3, а саме:
[admin@R1] > int bridge re 0
[admin@R1] > int eoip re 0
[admin@R3] > int bridge re 0
[admin@R3] > int eoip re 0
Додайте ІР-адреси для зв’язку з маршрутизаторами по Winbox:
В налаштуваннях tap-інтерфейсів задайте ІР-адреси: відповідно
192.168.10.2/24 – для tap0; 192.168.11.2/24 – для tap1.
Запустіть два екземпляри Winbox та підключіться до маршрутизаторів
за допомогою ІР-адрес: 192.168.10.1 – до Mikrotik; 192.168.11.1 – до
Mikrotik_3.
Для реалізації PPTP, SSTP, L2TP та OpenVPN каналу між
маршрутизаторами Mikrotik та Mikrotik_3 в топології необхідно мати IP-
канал (він у нас вже налаштований).
У Winbox Mikrotik додайте PPP-користувача user з паролем «pas» (PPP-
>Secrets+).
Отже між маршрутизаторами Mikrotik та Mikrotik_3 встановлений
зв’язок за IP. Виконайте з’єднання через цей канал маршрутизаторів за
протоколом PPTP. Нехай Mikrotik буде PPTP-сервером, а Mikrotik_3 – PPTP-
клієнтом.
Налаштування РРТР
У Winbox Mikrotik додайте PPТP-сервер (PPP->Interfaces + PPТР-server)
(рис. 15.3).
223
Рисунок 15.3 – Налаштування РРTР-сервера
Після цього обов’язково оберіть кнопку PPТР-server (див. рис.15.3) та

встановіть прапорець навпроти поля Enabled.
Аналогічно у Winbox Mikrotik_3 додайте PPTP-клієнт (PPP->Interfaces
+ PPTP-client ->Dial Out), вказавши адресу PPTP-сервера 1.1.1.2 та додавши
раніш створеного PPP-користувача user з паролем pas (рис. 15.4). У клієнта
та сервера повинні побачити статус connected (з’єднано). З’єднано, але без IP-
протоколу.
Рисунок 15.4 – Налаштування РРTР-клієнта
224
Налаштування L2TP
Виконайте аналогічні дії, як і для протоколу РРTР, але заміть РРTР
обиріть L2TP.
RSA-сертифікати
Механізм сертифікатів заснований на технології несиметричного
шифрування, що здійснюється парою ключів – відкритим та закритим. Якщо
повідомлення зашифроване відкритим ключем, то воно може бути
розшифроване тільки закритим ключем, а якщо повідомлення зашифроване
закритим ключем, то воно може бути розшифровано тільки відкритим
ключем. Обмінюються тільки відкритими ключами. Можна запропонувати
такий механізм аутентифікації, що заснований на несиметричному
шифруванні, а саме:
1) Б шле А запит на аутентифікацію.
2) А у відповідь шле Б випадкову послідовність.
3) Б шифрує її закритим ключем і відправляє зашифроване А.
4) А розшифровує прийняте й порівнює з відісланим. Якщо збіглося, то
Б – це Б.
5) А аутентифіціює Б й повідомляє його про це.
Роздачею сертифікатів управляє центр сертифікації. Сертифікат
містить «паспортні» дані одержувача сертифіката, відкритий ключ і
цифровий підпис центру сертифікації (зашифрованим відкритим ключем
центру, що засвідчує паспортні дані й відкритий ключ із цього сертифіката).
Обмін сертифікатами рівносильний обміну відкритими ключами. Два
кореспонденти, одержавши сертифікати, можуть ними обмінятися й потім
перевірити їх на справжніть, якщо в них є сертифікат центру сертифікації.
Для цього вони повинні зашифрувати дані цього сертифіката відкритим
ключем сертифікаційного центру й порівняти їх із цифровим підписом
сертифіката, що перевіряється.
Для роботи з протоколами SSTP та OpenVPN необхідні сертифікати.
Для цього створіть на диску С: каталог С:\openssl\ssl\ та скопіюйте в нього
файл OpenVPN\bin\openssl.exe (він знаходиться у каталозі з OpenVPN).
Також у цей каталог скопіюйте файл openssl.cnf. Далі працюйте в
командному рядку з каталогу С:\openssl\ssl\ та виконайте наступні команди:
225
1) openssl genrsa -des3 -out ca.key 1024
Enter pass phrase for ca.key: pass
Verifying - Enter pass phrase for ca.key: pass
2) openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
………………………..
Country Name (2 letter code) [AU]:ua
Locality Name (eg, city) []:kha
Organizational Unit Name (eg, section) []:khpi
Common Name (eg, YOUR name) []:stud
Email Address []:stud@khpi.ua
3) openssl genrsa -des3 -out server.key 1024

4) openssl req -new -key server.key -out server.csr

Enter pass phrase for server.key: pass
………………………..
Common Name (eg, YOUR name) []:server
Email Address []:server@khpi.ua
………………………..
A challenge password []:pass
5) openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey
ca.key -set_serial 01 -out server.crt
………………………..
6) openssl genrsa -des3 -out client.key 1024
7) openssl req -new -key client.key -out client.csr

Enter pass phrase for client.key: pass
………………………..
226
Common Name (eg, YOUR name) []:client
Email Address []:client@khpi.ua
………………………..
A challenge password []:pass
8) openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey
ca.key -set_serial 01 -out client.crt
………………………..
Далі за допомогою FTP завантажте створені сертифікати на сервер та
клієнт.
Для сервера (тобто Mikrotik), працюючи з командного рядка з каталогу
С:\openssl\ssl\:
ftp 192.168.10.1
Пользователь: admin
Пароль: (натисніть Enter)
ftp>bin
ftp>put ca.crt
ftp>put server.crt
ftp>put server.key
ftp>quit
Для клієнта (тобто Mikrotik_3), працюючи з командного рядка з

каталогу С:\openssl\ssl\:
ftp 192.168.11.1
Пользователь: admin
Пароль: (натисніть Enter)
ftp>bin
ftp>put ca.crt
ftp>put client.crt
ftp>put client.key
ftp>quit
У консолі Mikrotik виконайте наступні команди (на запит passphrase:
оберіть pass):
[admin@R1] > certificate import file-name=ca.crt
[admin@R1] > certificate import file-name=server.crt
[admin@R1] > certificate import file-name=server.key
Аналогічно для Mikrotik_3:
[admin@R3] > certificate import file-name=ca.crt
227
[admin@R3] > certificate import file-name=client.crt
[admin@R3] > certificate import file-name=client.key
Перейдіть у Winbox на маршрутизаторі Mikrotik у розділ System-
>Certificates та перейменуйте сертифікат, що помічений KR, в значення ser
(рис. 15.5).
Рисунок 15.5 – Встановлення сертифікатів для серверу
Виконайте аналогічні дії для клієнта (перейменуйте сертифікат на cli).
Налаштування SSTP
У Winbox сервера додайте SSTP-сервер (PPP->Interfaces + SSTP-server),
оберіть ім’я серверного сертифіката svr без перевірки сертифіката клієнта
(рис. 15.6). Для клієнта вкажіть адресу SSTP-сервера 1.1.1.2, додайте PPP-
користувача user з паролем pas та вкажіть ім’я сертифіката клієнта cli без
перевірки сертифіката сервера (рис. 15.7).
228
Рисунок 15.6 – Налаштування SSTP-сервера
Рисунок 15.7 – Налаштування SSTP-клієнта
Налаштування OpenVPN
У Winbox Mikrotik додайте OpenVPN-сервер (PPP->Interfaces +
OpenVPN-server). Натисніть на кнопку OVPN-server, вказавши в ньому ім’я
серверного сертифіката srv без перевірки сертифіката клієнта й режим
Ethernet, який знадобиться для організації моста (рис. 15.8).
229
Рисунок 15.8 – Налаштування OpenVPN-серверу
Додайте мост на Mikrotik (Bridge+).

У протоколі OpenVPN у сервера необхідно задати локальну та
віддалену адреси, навіть якщо вони не будуть використовуватися. Відмітьте,
що OpenVPN-сервер використовує профіль default. Відкрийте його (PPP-
>profiles->default) та вкажіть в ньому мост та довільні локальні та віддалені
адреси 192.168.100.1 та 192.168.200.1 (рис. 15.9).
Рисунок 15.9 – Налаштування профілю default
230
У Winbox Mikrotik_3 додайте також міст (Bridge+). Відмітьте, що
OpenVPN-клієнт використовує профіль default. Оберіть в цьому профілі
(PPP->profiles->default) також створений міст bridge1. Настройте клієнт
відповідним чином (рис. 15.10).
Рисунок 15.10 – Налаштування OpenVPN-клієнта
Вивчіть організацію VPN рівня 2 за допомогою мостів. Оскільки

використовується один користувач user та два профілі (default і default
encryption) для увсіх з’єднань, то побудуйте мости по черзі для кожного типу
PPP-з’єднання, а інші з’єднання залиште неактивними.
Деактивуйте усі клієнти, натискаючі у Winbox Mikrotik_3->PPP значок
X на кажному клієнті. Деактивуйте сервери (Winbox Mikrotik->PPP),
знімаючи галочку enable в їх налаштуваннях.
На клієнті та на сервері додайте в раніше створений міст bridge1
інтерфейс ether1. (У Winbox це Bridge->ports +). Перевірте, щоб цей міст
фігурував в налаштуваннях профілю default і на клієнті, і на сервері (PPP-
>profiles->default). В настроюваннях за замовчуванням використовується
також профіль default-encryption. Зробіть так, щоб міст bridge1 фігурував
також і в налаштуваннях цього профілю й на клієнті, і на сервері (PPP-
>profiles->default encryption).
231
PPTP
Активуйте сервер PPTP (Winbox Mikrotik->PPP): встановіть галочку

enable у його налаштуваннях. За замовчуванням PPTP-клієнт і сервер
використовує профіль default encryption. Активуйте клієнт PPTP (Winbox
Mikrotik_3 ->PPP): оберіть зі списку рядок pptp правою кнопкою й виберіть
enable. І на клієнті і на сервері в PPTP-інтерфейсах повинна з’явитися мітка
R, а ці інтерфейси автоматично додадуться у міст bridge1.
VPCS[2]> ping 10.1.1.3 -c 1
За допомогою WireShark отримайте захоплення пакетів на інтерфейсі
VPCS[2]> ping 10.1.1.3 -c 1
Стек протоколів при включеному шифруванні наведено на рис. 15.11.
Рисунок 15.11 – Стек протоколів для PPTP-з’єднання при включеному шифруванні
Оберіть на стороні сервера і на клієнті профіль default та ще раз

VPCS[2]> ping 10.1.1.3 -c 1
Стек протоколів при виключеному шифруванні наведено на рис. 15.12.
232
Рисунок 15.12 – Стек протоколів для PPTP-з’єднання при виключеному
шифруванні
L2TP
Деактивуйте сервер та клієнт PPTP. Активуйте сервер та клієнт L2TP.

За замовченням вoни використовують профіль default encryption.
VPCS[2]> ping 10.1.1.3 -c 1
За допомогою WireShark отримайте захоплення пакетів на інтерфейсі
VPCS[2]> ping 10.1.1.3 -c 1
Стек протоколів при включеному шифруванні наведено на рис. 15.13.
Рисунок 15.13 – Стек протоколів для L2TP-з’єднання при включеному шифруванні
Оберіть на стороні сервера і на клієнті профіль default та ще раз

VPCS[2]> ping 10.1.1.3 -c 1
Стек протоколів при виключеному шифруванні наведено на рис. 15.14.
233
Рисунок 15.14 – Стек протоколів для L2TP-з’єднання при виключеному
шифруванні
SSTP
Деактивуйте сервер та клієнт L2TP. Активуйте сервер та клієнт SSTP.

За замовчуванням вoни використовують профіль default encryption.
VPCS[2]> ping 10.1.1.3 -c 1
У SSTP встановлення з’єднання та обмін даними виконується в
зашифрованому вигляді, а тому в Wireshark нічого не можна побачити.
Рисунок 15.15 – Стек протоколів для SSTP-з’єднання
OpenVPN
Деактивуйте сервер та клієнт SSTP. Активуйте сервер та клієнт

OpenVPN. За замовчуванням вoни використовують профіль default.
234
VPCS[2]> ping 10.1.1.3 -c 1
1. Що таке VPN?
2. Які задачі вирішує VPN?
3. Які функції виконує протокол РРР?
4. Що таке тунель?
6. Які фази протоколу РРР?
7. Для чого використовується протокол РРТР та як він працює?
8. Для чого використовується протокол L2ТР та як він працює?
9. Для чого використовується протокол SSТР та як він працює?
10. Для чого використовується протокол OpenVPN?
11. Для чого використовуються сертифікати та які протоколи їх
використовують?
12. Для чого використовується протокол ЕоІР та як він працює?

4. Оформити звіт (зміст звіту дивиться нижче).

235
ТЕХНОЛОГІЯ ІРSEC
Ознайомлення з принципами організації стека протоколів IPSec для

захищеного обміну між вузлами в ІР-мережах. Набуття практичних навичок
налаштування IPSec для реалізації функції VPN на мережному обладнанні.
Склад IPSec
IPSec (Internet Protocol Security) – це конструктор, набір протоколів,

фреймворк, що дозволяє забезпечити потрібну безпеку передачі (табл. 16.1).
Таблиця 16.1 – Фреймворк IPSec

IPSec-протокол AH ESP, ESP+AH
Конфіденційніть DES, 3DES, AES, SEAL
та ін.
Цілісність MD5, SHA
Аутентифікація PSK, RSA
Алгоритм Діффі – Геллмана Група Діффі – Геллмана (сила
шифру)
IKE – Протокол обміну Інтернет-ключей
Конфіденційність забезпечується протоколами шифрування DES,

3DES, AES, SEAL. Ці протоколи наведені в порядку зростання безпеки. Чим
безпечніший протокол, тим більших обчислювальних потужностей він
вимагає.
Цілісність – гарантія того, що дані не були змінені під час передачі.
Для цього за алгоритмом MD5 або SHA обчислюють хеш даних, про
236
цілісність яких турбуються. Хеш разом з даними передаються по мережі. Для
аутентифікації учасників мережного обміну застосовується або заздалегідь
відомий обом сторонам ключ (PSK – PreShared Keys) або цифрові
сертифікати RSA.
Алгоритм Діффі – Геллмана пропонує процедуру обміну даними між
двома сторонам через небезпечне з’єднання, що приводить до генерації
загального секретного ключа для шифрування. Самі ключі не передається.
Є два варіанти IРSec-протоколу: AH і ESP. Протокол AH
(Authentication Header – заголовок аутентификации) забезпечує перевірку
дійсності змісту IP-дейтаграми шляхом додавання в дейтаграму
контрольного хеш-значення, що розраховується на основі цієї дейтаграми.
Які частини дейтаграми використовуються для розрахунку, а також
розміщення полів дейтаграми, залежить від того, який режим
використовується: тунельний або транспортний.
У транспортному режимі AH-заголовок вставляється після заголовка
IP. AH-заголовок містить контрольне хеш-значення. Для його розрахунку
використовуються IP-дані та заголовки. IP-поля, які можуть мінятися під час
транзиту, само як TTL, приводяться до нульових значень до аутентифікації.
У тунельному режимі вихідний ІР-пакет інкапсулюється в новий ІР-
пакет. Весь вихідний ІР-пакет проходить перевірку дійсності. AH-заголовок
вставляється після нового ІР-заголовка.
AH – це протокол, що не шифрує дейтаграму. Для шифрування
використовується інший протокол – ESP. Основним і єдиним призначенням
AH є забезпечення захисту від атак, пов’язаних з несанкціонованою зміною
вмісту пакета, і від підміни вихідної адреси мережного рівня.
Протокол ESP (Encapsulating Security Payload – інкапсуляція
зашифрованих даних) використовує загальний ключ шифрування для
забезпечення конфіденційності даних. ESP також підтримує свою власну
схему аутентифікації, подібну тієї, котра використовується в AH або котра
може бути використана сумісно з АH.
У транспортному режимі IP-заголовки не піддаються аутентифікації й
шифруванню, а IP-дані піддаються.
237
У тунельному режимі вихідний ІР-пакет інкапсулюється в новий ІР-
пакет, забезпечуючи шифрування IP-даних і IP-заголовка.
Апаратне шифрування дозволяє значно прискорити процес
шифрування за допомогою вбудованого всередині процесора пристрою
шифрування.
Для порівняння маршрутизатор RB1100AH з використанням алгоритму
AES-128 може обробити 550 Мбіт/с зашифрованого трафіку. Без апаратної
підтримки він може обробити тільки 150 Мбіт/с зашифрованого трафіку.
Протокол IKE (Internet Key Exchange) використовується для побудови
та захищеного узгодження параметрів IPSec-тунелю. Для створення
загальних ключів IKE використовує протокол Oakely і алгоритм Діффі –
Геллмана .
SA (Security Association)
Гарантії цілісності й конфіденційності даних у специфікації IPSec

забезпечуються за рахунок використання механізмів аутентифікації та
шифрування відповідно. Останнє, у свою чергу, засноване на попередньому
узгодженні сторонами інформаційного обміну застосовуваних
криптографічних алгоритмів, алгоритмів керування ключовою інформацією і
їхніми параметрами. Після узгодження виникає асоціація безпеки SA
(Security Association). В SA зберігається протокол, алгоритми та ключі, які
будуть використані для шифрування або підпису переданих даних. Кожний
SA використовується тільки в одному напрямку. Для двонаправленого
зв’язку потрібно два SA. Кожний SA реалізує один IPSec-протокол. Якщо для
одного пакета необхідно використовувати два протоколи (наприклад AH і
ESP), то потрібні два SA. SA динамічно створюється за допомогою IKE до
початку обміну даними між двома пірами. SA міститься в базі SAD (Security
Association Database).
Кожна SA звичайно визначається трьома параметрами:
• Security Parameter Index (SPI) – 32-бітовим числом, що
призначається SA і що має тільки локальне значення. SPI
включається в заголовки AH і ESP, щоб одержувач зміг вибрати
коректний SA для обробки одержуваного пакета.
238
• IP-адресою одержувача – адресою протилежної сторони, з якої
встановлена асоціація безпеки.
• Security Protocol Identifier – вказує, який протокол IPSec
використовується на SA (AH або ESP).
Політики IPSec
Політики визначають, що робити із групою пакетів, що задовольняють

якусь умову. Політики зберігаються в SPD (Security Policy Database – базі
даних політики безпеки) і базі SAD. Політика може вказати для пакета даних
одну із трьох дій: відкинути пакет, не обробляти пакет за допомогою IPSec;
обробити пакет за допомогою IPSec. В останньому випадку політика також
вказує, який SA необхідно використовувати (якщо звичайно вже було
створено SA) або з якими параметрами має бути створена нова SA. IPSec
погоджує з іншою стороною за протоколом IKE створення нової SA і її
параметрів.
Пристрій перевіряє базу даних SPD для визначення, що робити з
конкретною дейтаграмою. SPD може посилатися на конкретну SA в SAD.
Якщо це так, то пристрій буде шукати цю SA і використовувати її для
обробки дейтаграми.
SPD є дуже гнучким механізмом керування, що допускає дуже гарне
керування обробкою кожного пакета. Пакети класифікуються за великою
кількістю полів, і SPD може перевіряти деякі або всі поля для того, щоб
визначити відповідну дію. Це може привести до того, що весь трафик між
двома машинами буде передаватися за допомогою одного SA, або окремі SA
будуть використовуватися для кожного застосунку, або навіть для кожного
з’єднання.
Фази IKE
Основний час служба IKE нічого не робить. Якщо є якийсь трафик, що

відповідає правилу політики і що має потребу в шифруванні або
аутентифікації, але політика не має ніякої SA, то політика сповіщає про це
239
службу IKE і вона ініціює зв’язок до віддаленого хосту. IKE виконує дві
фази.
Фаза 1. Виконується аутентифікація сторін та узгоджуються їх IPSec-
політики. За допомогою алгоритму Діффі – Геллмана розраховуються
загальні ключі для SA. Створюється слабкий тунель, що дозволяє почати
обмін IKE для фази 2. Є два режими фази 1: звичайний і агресивний (за три
пакети).
Фаза 2. Виконується узгодження параметрів SA з метою створення
тунелю IPSec. Встановлюється односпрямований SA для кожної комбінації
алгоритму й протоколу. Створюється сильний тунель.
Всі SA, встановлені службою IKE, мають значення часу життя. Є два
значення часу життя: тверде та м’яке. Коли SA досягає свого м’якого порога,
служба IKE одержує повідомлення й запускає ще одну фазу 2 обміну для
відновлення SA. Якщо SA досягли твердого часу життя, то вони
відкидаються.
Генерація ключів вимагає значних обчислювальних витрат. Це
зазвичай має місце один раз протягом фази 1.
Конфігурація IPSec в Mikrotik RouterOS
Конфігурація пірів здійснюється через підменю /ip ipsec peer згідно з

табл. 16.2. Конфігурації використовуються для встановлення з’єднання між
службами IKE (1-ша фаза). Це з’єднання далі використовується в процесі
узгодження ключів і алгоритмів для SA.
Таблиця 16.2 – Конфігурація пірів

address (IP[/Netmask]:port; Default: Адресний префікс. Якщо адреса
0.0.0.0/32:500) віддаленого піра підпадає під цей префікс,
то така конфігурація використовується при
аутентифікації та встановленні фази 1
auth-method (pre-shared-key | rsa- Метод аутентифікації:
signature; Default: pre-shared-key) pre-shared-key – аутентифікація за
загальним для пірів парольним рядком;
rsa-signature – аутентифікація за допомогою
пари RSA-сертифікатів.
240
certificate (string; Default: ) Им’я локального сертифікату. Він повинен
мати закритий ключ. Використовується при
аутентифікації RSA-signature
h-group (ec2n155 | ec2n185 | modp1024 | Група Diffie-Hellman (сила шифру)
modp1536 | modp768; Default: modp1024)
dpd-interval (disable-dpd | time; Default: Інтервал виявлення відсутності піра. При
disable-dpd disable-dpd виявлення не виконується
dpd-maximum-failures (integer: 1..100; Максимальна кількість збоїв до визначення
Default: 5) піра як відсутнього
enc-algorithm (3des | aes-128 | aes-192 | aes- Алгоритм шифрування
256 | des | blowfish | camellia-128 | camellia-
192 | camellia-256; Default: 3des)
exchange-mode (aggressive | base | Режим обміну у фазі 1
main; Default: main)
generate-policy (;yes | no Default: no) Дозволяє піру встановити SA для
неіснуючої політики. Політика створюється
динамично під час життя SA. Цей спосіб
корисен, коли адреса віддаленого піра
невідома
hash-algorithm (md5 | sha1; Default: Алгоритм хешування. SHA сильніший, але
md5) повільніший
lifebytes (Integer: 0..4294967295; Час життя першої фази. Визначає, скільки
Default: 0) байт може бути передано до того як SA
буде відкинута. Якщо вказано 0, то SA не
відкидається
lifetime (time; Default: 1d) Час житя фази 1: визначає час дії SA
nat-traversal (yes | no; Default: no) Використання механізму Linux NAT-
traversal для вирішення несумісності
IPsec та NAT
proposal-check (claim | exact | obey Логіка перевірки часу життя фази 2:
strict; Default: obey) claim – узяти саме короткий час з
запропонованих варіантів та сповістити
ініціатора про це; exact – вимагати, щоб час
життя був такий самий; obey – приймати
все, що надішле ініціатор; strict – якщо
запропонований час більший, ніж час за
замовчуванням, то відкинути його. Інакше
прийняти пропозицію
241
Продовження таблиці 16.2
remote-certificate (string; Default: ) Им’я сертифіката для аутентифікації
віддаленої сторони. Закритий ключ
непотрібен. Застосовується при
аутентифікації RSA-signature
secret (string; Default: "") Парольний рядок. Застосовується при
аутентифікації pre-shared key. Якщо
починається з 0x, то розглядаеться як 16-не
число
send-initial-contact (yes | no; Default: Визначає, чи відсилати початкову IKE-
yes) інформацію, чи чекати віддалену сторону
При зміні цієї конфігурації інформація про фази IPSec видаляється,

однак пакети продовжують шифруватися та дешифруватися відповідно до
встановленої SA.
Політика IPSec налаштовується в підменю /ip ipsec policy відповідно до
табл. 16.3. Таблиця політик призначена для визначення того, які
налаштування безпеки будуть застосовані до пакета.
Таблица 16.3 – Конфігурація політик

action (discard | encrypt | none; Визначає, що робити з пакетом, який
Default: encrypt) задовольняє політику. none – пропустити
пакет без змін; discard – відкинути пакет;
encrypt – застосувати перетворення, що
визначене в цій політиці та SA
dst-address (IP/Mask:Port; Default: Адресний префікс та порт призначення
0.0.0.0/32:any)
ipsec-protocols (ah|esp; Default: esp) Визначає, яка комбінація протоколів AH та
ESP буде застосована до трафіку, який
відповідає політиці
level (require | unique | use; Default: Визначає, що робити, якщо деякі SA для
require) цієї політики не можуть бути знайдені: use –
пропустити це перетворення, не відкидати
пакет і не одержувати SA від IKE-служби;
require – відкинути пакет і одержати SA;
unique – відкинути пакет і отримати
унікальну SA, яка тільки й
використовується для цієї конкретної
політики
242
Продовження таблиці 16.3
priority (Integer: Класифікатор порядку політики (ціле з
-2147483646..2147483647; Default: 0) знаком). Більше число означає більший
пріоритет
proposal (string; Default: default) Ім’я пропонованої інформації, що буде
передане IKE-службою для встановлення
SA для цієї політики
protocol (all | egp | ggp | icmp | igmp Для яких протоколів використовувати
| ...; Default: all)
sa-dst-address (IP; Default: 0.0.0.0) Віддалена IP-адреса SA (віддалений пір)
sa-src-address (IP; Default: 0.0.0.0) Локальна IP-адреса SA (локальний пір)
src-address (IP/Mask:Port; Default: Адресний префікс та порт джерела
0.0.0.0/32:any)
tunnel (yes | no; Default: no) Визначає, чи використовувати тунельний
режим
У транспортному режимі необхідно вказати dst-address = sa-dst-

address і src-address = sa-dst-address. Для шифрування трафіку між
мережами необхідно використовувати тунель. Пакет з мережі src-address у
мережу dst-address буде поміщений у новий пакет з адресою джерела sa-src-
address і адресою приймача sa-dst-address.
Встановлення пропонованої інформації виконується в підменю /ip ipsec
proposal згідно з табл. 16.4. Пропонована інформація відсилається службою
IKE для встановлення SA для політики. Ім’я пропонованої інформації
встановлюється в політику.
Таблиця 16.4 – Встановлення пропонованої інформації

аuth-algorithms (md5|sha1|null; Дозволені алгоритми перевірки дійсності
Default: sha1)
enc-algorithms (null|des|3des|aes-128| Дозволені алгоритми шифрування
aes-192|aes-256|blowfish|camellia-128
| camellia-192 | camellia-256 | twofish;
Default: 3des)
lifetime (time; Default: 30m) Час життя SA
pfs-group (ec2n155 | ec2n185 | Група Diffie-Helman для Perfect Forward
modp1024 | modp1536 | modp768 | ...; Secrecy
Default: modp1024)
243
Підменю /ip ipsec installed-sa надає інформацію про встановлений SA і
їхні ключі. За допомогою команди /ip ipsec installed-sa flush можна вручну
скинути SA, які некоректно встановлені IKE.
Підменю /ip ipsec remote-peers містить інформацію тільки для читання
про активні віддалені піри.
Зберіть топологию, яка зображена на рис. 16.1 (усі маршрутизатори –

Mikrotik).
Рисунок 16.1 – Топологія для практичної частини IPSec
Призначте адреси відповідно до рис. 16.1. На R0 задайте маршрут за

замовчуванням на 10.0.0.2. На R1 задайте маршрут за замовчуванням на
10.0.0.1.
Ми не знаємо, хто ініціює шифрування. Тому зробіть симетричну
конфігурацію пірів, вказавши адресу співрозмовника та пароль (рис. 16.2 і
16.3).
244
Рисунок 16.2 – Налаштування піра на R0
Рисунок 16.3 – Налаштування піра на R1
245
Визначте на R0 політику, що задає шифрування від мережі Src.Address:
10.1.200.0/24 до мережі Dst.Address: 10.1.100.0/24 (рис. 16.4). Для SA як
адресу джерела SA Src.Address візьміть зовнішню адресу 10.0.0.1 R0, а як
адресу приймача SA Dst.Address – зовнішню адресу 10.0.0.2 R1. Обмін
здійснюється в тунельному режимі (рис. 16.5).
Визначте на R1 політику, що задає шифрування від мережі Src.Address:
10.1.100.0/24 до мережі Dst.Address 10.1.200.0/24 (рис. 16.6). Для SA як
адресу джерела візьміть зовнішню адресу SA Src.Address 10.0.0.2 R1, а як
адресу приймача SA Dst.Address – зовнішню адресу 10.0.0.1 R0. Обмін
здійснюється в тунельному режимі (рис. 16.7).
Переконайтеся, що за допомогою IPSec створено VPN типу сайт-сайт
між мережами 10.1.100.0/24 і 10.1.200.0/24. Для цього протрасуйте пакети з
мережі 10.1.100.0/24 у мережу 10.1.200.0/24. Наберіть команду
VPCS[3]> trace 10.1.200.2
trace to 10.1.200.2, 8 hops max, press Ctrl+C to stop
1 10.1.100.1 4.000 ms 2.000 ms 2.001 ms
2 *10.0.0.1 26.001 ms 4.001 ms
3 *10.1.200.2 19.001 ms (ICMP type:3, code:3, Destination port
unreachable)
Рисунок 16.4 – Політика на R0
246
Рисунок 16.5 – Політика на R0. SA
Рисунок 16.6 – Політика на R1.
Рисунок 16.7 – Політика на R1. SA
247
При використанні протоколів AH+ESP за допомогою Wireshark можна
побачити інкапсуляцію при передачі пакетів по сформованому тунелю
(рис. 16.8).
Рисунок 16.8 – Wireshark показує шифруваня пакетів AH+ESP
Якщо використовувати тільки протокол AH, то можна побачити

інкапсуляцію вихідного пакета в тунель IPSec (рис. 16.9).
Рисунок 16.9 – Інкапсуляція без використання ESP
Перевірте, що R0 та R1 побачили віддаленого співрозмовника (IP-

>IPsec->Remote Peers) та на R0 і на R1 інсталювалися SA (IP->IPsec-
>Installed SAs).
1. Для чого використовується IPSec?

2. Які протоколи входять до складу IPSec?
3. Як забезпечується конфіденційніть даних в IPSec?
4. Що таке тунель?
248
6. Як забезпечується цілісніть в IPSec?
7. Як виконується аутентифікація в IPSec?
8. Для чого використовується алгоритм Діффі – Геллмана?
9. Що таке IKE і як він працює?
10. Що таке SA?
11. Для чого використовуються політики в IPSec і де вони
зберігаються?

1. Організуйте VPN типу сайт-сайт за допомогою IPSec для топології

(рис. 16.10).

N, M, D – відповідно номер за списком, місяць та день народження
студента.
249
2. Наведіть структури кадрів в Wireshark з використанням протоколів
AH, ESP та AH+ESP при виконанні пінгів між вузлами С1 та С4, С3 та С5, С2
та С6.

2. Усі виконані пункти практичної та самостійної роботи зі
скріншотами.
250
ТЕХНОЛОГІЇ БЕЗДРОТОВИХ МЕРЕЖ
Ознайомлення з принципами організації бездротових мереж. Набуття

практичних навичок налаштування параметрів бездротових мереж на
мережному обладнанні.
Бездротові комп’ютерні мережі – це технологія, що дозволяє

створювати обчислювальні мережі, які повністю відповідають стандартам
для звичайних провідних мереж (наприклад, Ethernet), без використання
кабельної проводки. Як носії інформації в таких мережах виступають
радіохвилі НВЧ-діапазону.
Існує два основних напрямки застосування бездротових комп’ютерних
мереж:
1. Робота в замкнутому просторі (офіс, різні приміщення і т. ін.);
2. З’єднання віддалених локальних мереж (або віддалених сегментів
локальної мережі).
Для організації бездротової мережі в замкнутому просторі
застосовуються передавачі із всеспрямованими антенами. Стандарт IEEE
802.11 визначає два режими роботи мережі: Ad-hoc і клієнт – клієнт-сервер.
Режим Ad-hoc (інакше називаний «точка-точка») – це проста мережа, у якій
зв’язок між станціями (клієнтами) встановлюється прямо, без використання
спеціального пристрою. У режимі клієнт-сервер бездротова мережа
складається, як мінімум, з однієї точки доступу, підключеної до провідної
мережі, і деякого набору бездротових клієнтських станцій. Варто мати на
увазі, що через стіни з більшим вмістом металевих арматур (у залізобетонних
будинках такими є несучі стіни) радіохвилі діапазону 2,4 Ггц іноді можуть
взагалі не проходити.
251
Для з’єднання віддалених локальних мереж (або вилучених сегментів
локальної мережі) використовується обладнання зі спрямованими антенами,
що дозволяє збільшити дальність зв’язку до 20 км (а при використанні
спеціальних підсилювачів і великій висоті розміщення антен – до 50 км).
Комплекси для об’єднання локальних мереж по топології діляться на «точка-
точка» та «зірка». При топології «точка-точка» (режим Ad-hoc в IEEE 802.11)
організується радіоміст між двома віддаленими сегментами мережі. При
топології «зірка» одна зі станцій є центральною й взаємодіє з іншими
віддаленими станціями. При цьому центральна станція має всеспрямовану
антену, а інші віддалені станції – односпрямовані антени. Застосування
всеспрямованої антени в центральній станції обмежує дальність зв’язку
дистанцією приблизно 7 км. Тому, якщо потрібно з’єднати між собою
сегменти локальної мережі, які віддалені один від іншого на відстань більше
7 км, доводиться з’єднувати їх за принципом «точка-точка». При цьому
організується бездротова мережа з кільцевою або іншою, більш складною
топологією.
Стандарт IEEE 802.11
Стандарт IEEE 802.11 – набір стандартів для комунікації в бездротовій

локальній мережній зоні (WLAN) частотних діапазонів 2,4; 3,6 і 5 ГГц. Ці
стандарти забезпечують основи бездротових мережних продуктів, які
користуються брендом Wi-Fi.
Перелік основних стандартів:
1. IEEE 802.11 – початковий стандарт бездротових локальних мереж,
заснований на бездротовій передачі даних в діапазоні 2,4 ГГц. Підтримує
обмін даними з швидкістю до 1 – 2 Мбіт/с. Прийнятий в 1997 році.
2. IEEE 802.11а – стандарт бездротових локальних мереж, заснований
на бездротовій передачі даних в діапазоні 5 ГГц. Діапазон розділений на три
непересічні піддіапазони. Максимальна швидкість обміну даними становить
54 Мбіт/с, при цьому доступні також швидкості 48, 36, 24, 18, 12, 9 і 6 Мбіт/с.
3. IEEE 802.11b – стандарт бездротових локальних мереж, заснований
на бездротовій передачі даних в діапазоні 2,4 ГГц. У всьому діапазоні існує
252
три непересічні канали, тобто на одній території, не впливаючи одна на одну,
можуть працювати три різні бездротові мережі. У стандарті передбачено два
типи модуляції: DSSS і FHSS. Максимальна швидкість роботи становить 11
Мбіт/с, при цьому доступні також швидкості 5,5; 2 і 1 Мбіт/с.
Стандарт IEEE 802.11b був прийнятий в 1999 році в розвиток
прийнятого раніше стандарту IEEE 802.11. Він також передбачає
використання діапазону частот 2,4 ГГц, але тільки з модуляцією DSSS.
Продукти стандарту IEEE 802.11b, що поставляються різними фірмами,
тестуються на сумісність і сертифікуються організацією Wireless Ethernet
Compatibility Alliance (WECA), яка в наш час більш відома під назвою «Wi-Fi
Alliance». Сумісні бездротові продукти, що пройшли випробування за
програмою «Wi-Fi альянс», можуть бути маркіровані знаком Wi-Fi.
4. IEEE 802.11g – стандарт бездротових локальних мереж, заснований
на бездротовій передачі даних в діапазоні 2,4 ГГц. Діапазон розділений на
три непересічні канали, тобто на одній території, не впливаючи одна на одну,
можуть працювати три різні бездротові мережі. Для збільшення швидкості
обміну даними при ширині каналу, схожій з 802.11b, застосовано метод
модуляції з ортогональним частотним мультиплексуванням (OFDM,
Ortogonal Frequency Division Multiplexing), а також метод двійкового
пакетного згорткового кодування PBCC (Packet Binary Convolutional Coding).
5. IEEE 802.11n – сучасний стандарт бездротових локальних мереж,
заснований на бездротовій передачі даних в діапазоні 2,4 ГГц та 5 ГГц.
Стандарт 802.11n значно перевищує за швидкістю обміну даними попередні
стандарти 802.11b і 802.11g, забезпечуючи швидкість на рівні Fast Ethernet;
зворотно сумісний з 802.11b і 802.11g. Основна відмінність від попередніх
версій Wi-Fi – додавання до фізичного рівня (PHY) підтримки протоколу
MIMO (multiple-input multiple-output) до рівня 4х4 (4 передавача й 4
приймача). При цьому мінімум 2 передавача на точку доступу та 1 передавач
на пристрій користувача. Теоретична швидкість може складати 600 Мбіт/с.
Приклади можливих MCS (Modulation & Coding Scheme) для 802.11n, а також
максимальні теоретичні швидкості передачі даних в радіоканалі наведені у
наступній таблиці:
253
Spatial Streams – це кількість просторових потоків. Type – тип модуляції. Data
Rate – максимальна теоретична швидкість передачі даних в радіоканалі в
Mбіт/сек.
Частотні полоси та канали в 2,4 GHz
Канал Нижня частота Центральна частота Верхня частота

1 2,401 2,412 2,423
2 2,406 2,417 2,428
3 2,411 2,422 2,433
4 2,416 2,427 2,438
5 2,421 2,432 2,443
6 2,426 2,437 2,448
7 2,431 2,442 2,453
8 2,436 2,447 2,458
9 2,441 2,452 2,463
10 2,446 2,457 2,468
11 2,451 2,462 2,473
12 2,456 2,467 2,478
13 2,461 2,472 2,483
254
Рисунок 17. 1 – Загальна діаграма перекриття частотних каналів в 2,4GHz
Метод доступу CSMA/CA
CSMA/CA – Carrier Sense Multiple Access With Collision Avoidance або

Carrier sensing multiple access with collision avoidance – «множинний доступ з
контролем несучої й уникненням колізій» або «багатостанційний доступ з
контролем несучої й уникненням конфліктів». Це метод доступу, у якому:
1) використовується схема прослуховування несучої хвилі;
2) станція, що збирається почати передачу, посилає jam signal (сигнал
затору);
3) після тривалого очікування всіх станцій, які можуть послати jam
signal, станція починає передачу кадру;
4) якщо під час передачі станція виявляє jam signal від іншої станції,
вона зупиняє передачу на відрізок часу випадкової довжини й потім
повторює спробу;
CSMA/CA відрізняється від CSMA/CD тим, що колізіям піддаються не
пакети даних, а тільки jam-сигнали. Звідси й назва «Collision Avoidance» –
запобігання колізіям (саме пакетам даних).
Запобігання колізіям використовується для того, щоб поліпшити
продуктивність CSMA, віддавши мережу єдиному передавальному
пристрою. Ця функція покладається на «jamming signal» в CSMA/CA.
Поліпшення продуктивності досягається за рахунок зниження ймовірності
колізій і повторних спроб передачі.
255
Безпека, шифрування й авторизація користувачів у бездротових
мережах
Для забезпечення безпеки в мережах 802.11 застосовувався алгоритм

WEP (Wired Equivalent Privacy), що включав у себе алгоритм шифрування
RC4 з 40-бітним або 104-бітним ключем і алгоритм засобу розподілу ключів
між користувачами, однак в 2001 році в ньому була знайдена принципова
уразливість, що дозволила одержати повний доступ до мережі за кінцевий (і
досить невеликий час) поза залежністю від довжини ключа. Категорично не
рекомендується до використання в цей час.
У 2003 році була прийнята програма сертифікації засобів бездротового
зв’язку за назвою WPA (Wi-Fi Protected Access), що усувала недоліки
попереднього алгоритму. З 2006 року всі WiFi-пристрої зобов’язані
підтримувати новий стандарт WPA2, що відрізняється від WPA підтримкою
більш сучасного алгоритму шифрування AES з 256-бітним ключем. Також в
WPA з’явився механізм захисту переданих пакетів з даними від
перехоплення й фальсифікації. Саме таке сполучення (WPA2/AES)
рекомендується зараз до використання у всіх закритих мережах.
У WPA є два режими авторизації користувачів у бездротовій мережі:
за допомогою RADIUS-сервера авторизації (орієнтований на корпоративних
користувачів і на великі мережі) і WPA-PSK (Pre Shared Key), що
пропонується використовувати в домашніх мережах, а також у невеликих
офісах. У цьому режимі авторизація за паролем (довжиною від 8 до 64
символів) виконується на кожному вузлі мережі. Також у багатьох сучасних
побутових Wi-Fi-пристроях застосовується режим Wi-Fi Protected Setup
(WPS), також іменований Wi-Fi Easy Setup, де авторизація клієнтів
здійснюється за допомогою спеціальної кнопки або pin-коду, унікального для
пристрою.
Для випадків, коли в мережі експлуатується фіксований набір
пристроїв, найбільш надійним способом є обмеження доступу за MAC-
адресою за допомогою прописування в меню пристрою списку MAC-адрес
«своїх» пристроїв і вибір дозволу доступу в мережу тільки пристроям з
адресами із цього списку.
256
Також у будь-якої бездротової мережі є унікальний ідентифікатор –
SSID (Service Set IDentifier), що відображається як ім’я мережі при перегляді
списку доступних мереж. Він задається при настроюванні пристрою.
Для виконання практичної частини знадобляться маршрутизатори

RB751G-2HnD фірми Mikrotik (видає викладач). Специфікація:
Чипсет/контролер Atheros AR7242 (400 МГц) + AR5008 + AR8327

Пам’ять 64 Мбайт
5 x IEEE 802.3u 10/100/1000 Мбіт/c;
Порти
1 x USB 2.0
Wi-Fi 802.11b/g/n до 300 Мбіт/c
Антенна 2x2 MIMO PIF 2,5 dBi + конектор MMCX
Налаштування RB751G-2HnD в режимі бездротового

маршрутизатора з підключенням до мережі Інтернет
Топологія відповідає реальній мережі (без використання GNS). Для

реалізації топології рис. 17.2 виконайте наступне.
Рисунок 17.2 – Топологія для виконання 1 частини ЛР
257
З’єднайте маршрутизатор через порт е2 з комутатором за допомогою
UTP кабелю. Запустіть на робочій станції утиліту Winbox та виконайте
підключення до маршрутизатора. Додайте мост (Bridge->Bridge+). Для цього
натисніть на червоний + та у вікні, що відкриється, натисніть Ok. У розділі
Ports, натискаючи на + додайте порти в міст. У вікні, що відкриється в
розділі Interface, оберіть потрібний інтерфейс, в пункті Bridge оберіть
створений раніше міст. Додавати інтерфейси можна тільки по одному. Тому
5 раз виконайте додавання портів – Ether2, Ether3, Ether4, Ether5 та Wlan1
– бездротовий адаптер. Порт Ether1 додавати не треба – він буде
використовуватися для підключення до мережі інституту (для доступу в
Інтернет) (рис. 17.3).
Рисунок 17.3 – Додавання портів у міст
Додайте ІР-адресу на створений міст (рис. 17.4).
Рисунок 17.4 – Додавання ІР-адреси
258
Щоб маршрутизатор зміг працювати як DNS-сервер та відповідати на
запити клієнтів, в меню IP->DNS оберіть пункт Allow Remote Requests.
Налаштуйте DHCP-сервер на створений міст (мережа 192.168.88.0/24).
Налаштуйте NAT-masquerade з мережі 192.168.88.0/24 на інтерфейс ether1.
Налаштуйте бездротовий адаптер. Для цього в меню Wireless в розділі
Security Profiles необхідно зайти в налаштування профілю default та
виконати наступні налаштування:
Mode – dynamic keys
Authentication Types – встановити пункти напроти WPA PSK та
WPA2 PSK для включення відповідних шифрувань.
Unicast Ciphers та Group Ciphers – відмітьте типи шифрувань, tkip
та/або aes ccm. Зазвичай встановлюють обидва, щоб усі бездротові пристрої
змогли отримати доступ до мережі.
WPA Pre-Shared Key та WPA2 Pre-Shares Key – в цих полях
вводиться пароль для бездротової мережі; введіть – Mikrotik1.
Рисунок 17.5 – Налаштування шифрування бездротового з’єднання
259
Перейдіть у розділ Interfaces та зайдіть у налаштування бездротового
адаптера. Відразу натисніть на кнопку Advanced справа для включення
розширених налаштувань.
Перейдіть на вкладку Wireless та виконайте зміну наступних полів

(рис. 17.6):
Mode – ap bridge – режим роботи в якості точки доступу.
Band – 2GHz-B/G/N – частота та режим роботи.
Frequency – 2412 – частота роботи бездротової мережі.
SSID – Mikrotik1 – ім’я бездротової мережі.
Wireless Protocol – 802.11 – режим роботи Wi-Fi для можливості
підключення будь-яких пристроїв.
Frequency Mode – regulatory domain – діапазон частот, який
дозволяеться використовувати у відповідній країні.
Channel Width – встановлення 20/40MHz НТ Above.
Default Forward – обмін даними, здійснюваний клієнтами бездротової
мережі між собою.
Рисунок 17.6 – Налаштування бездротового адаптера
260
На вкладці HT виконується керування антенами пристрою.
Зверніть увагу на те, що галочки стоять навпроти chain0, а друга
антена вимкнена, що не дозволяє працювати на максимальних швидкостях.
Необхідно поставить галочки навпроти chain1.
Задайте ІР-адресу для інтерфейсу ether1: 172.17.72.52/24 та маршрут за
замовчуванням на маршрутизатор 172.17.72.1. Після цього задайте IР-адресу
DNS-сервера 8.8.8.8 в налаштуваннях DNS (IP->DNS->Servers). Спробуйте
підключитися до маршрутизатора по Wi-Fi та зайти на будь-який сайт.
Розширення зони покриття W-Fi-мережі.

Розглянемо такий випадок: коли необхідна мережа з високою
пропускною здатністю та коли в місцях розташування бездротових
маршрутизаторів (точок доступу) є дротова мережа, то додаткові
маршрутизатори також необхідно настроювати у режимі точки доступу
(рис. 17.7).
Рисунок 17.7 – Розширення зони покриття Wi-Fi
261
Обидва пристрої повинні мати однаковий SSID та одинакові параметри
шифрування, але вони повинні працювати на різних каналах, краще
незалежних. Взаємне розташування пристроїв слід підібрати таким чином,
щоб зони покриття перетиналися без значного послаблення сигналу. Клієнти
бездротової мережі будуть приймати рішення про підключення до тієї або
іншої точки доступу автоматично, залежно від рівня сигналу. Таким чином,
мобільні користувачі можуть вільно пересуватися по всій зоні покриття без
обриву зв’язку. Якщо необхідно використовувати більше трьох точок, то
незалежні канали слід використовувати таким чином, щоб зони їх покриття
не перетиналися.
Виконайте налаштування пристроїв відповідно до топології рис. 17.7 та
протестуйте цей варіант.
Налаштування бездротового мосту

Виконайте налаштування у відповідності до рис. 17.8.
Wireless bridge
Рисунок 17.8 – Топологія з бездротовим мостом
Налаштування маршрутизатору Mikrotik

Налаштування інтерфейсів залиште тикими, якими вони були у
попередній топології. Перейдіть на вкладку Wireless в налаштуванні
бездротового адаптера. Та виконайте налаштування відповідно до рис. 17.9.
262
Рисунок 17.9 – Налаштування бездротового інтерфейсу
У розділі WDS: WDS mode – dynamic; WDS Default Bridge – bridge1.

У розділі NV2 встановіть параметри відповідно до рис. 17.10.
Рисунок 17.10 – Налаштування протоколу NV2
Міст буде організовуватися в приміщенні, тому необхідно налаштувати

потужніcть передавача. У розділі ТхPower виконайте налаштування
відповідно до рис. 17.11.
Рисунок 17.11 – Налаштування потужності передавача
263
Налаштування маршрутизатору Mikrotik_2
Відкрийте налаштування бездротового адаптера. Створіть новий

профіль шифрування для бездротового адаптера та налаштуйте його
відповідно до рис. 17.12.
Рисунок 17.12 – Налаштування профілю шифрування
Перейдіть у розділ Wireless та виконайте налаштування відповідно до

рис. 17.13.
Рисунок 17.13 – Налаштування параметрів адаптера
264
Перевірте у розділі НТ наявність використання обох антен (chain0,
chain1 повинні бути обрані). У розділі NV2 встановіть Security та Preshared
Key = 1234567.
Додайте міст та для нього ІР-адресу 192.168.88.2/24. Додайте маршрут
за замовчуванням на ІР=192.168.88.1. Після цього у розділі Status можна
спостерігати наявність та параметри з’єднання (рис. 17.14).
Рисунок 17.14 – Інформація про з’єднання
Підключіть робочу станцію до будь-якого порту маршрутизатора

Mikrotik_2, встановіть отримання ІР-адреси за протоколом DHCP. Спробуйте
зайти на будь-який сайт.
1. Які стандарти ІЕЕЕ802.11 ви знаєте?

2. Які є канали в смузі частот 2,4 ГГц і які з них є незалежними?
3. Які є режими роботи точки доступу?
4. Яке шифрування використовується для бездротових мереж?
5. Що таке SSID?
6. Як виконати побудову бездротової мережі з високою пропускною
здатністю, якщо є можливість дротового підключення?
265
7. Для чого використовується бездротовий міст?

2. Здати викладачеві теорію, відповівши на контрольні питання.
3. Виконати практичну частину.
Звіт готується в електронному вигляді і роздруковується. Звіт містить

266
ТЕХНОЛОГІЯ MPLS
Ознайомлення з принципами організації MPLS-мереж. Набуття

практичних навичок налаштування параметрів MPLS-мереж на мережному
обладнанні.
MPLS – це багатопротокольна комутація за мітками (MultiProtocol

Label Switching). Вона частково заміняє IP-маршрутизацію – рішення про
пересилання пакета (вихідний інтерфейс і наступний хоп маршруту);
приймається не на основі адреси призначення цього пакета й таблиці
маршрутизації, а на основі мітки, яка прикріплена до пакета. Такий підхід
прискорює процес пересилання, тому що пошук наступного хопа стає значно
простішим в порівнянні з пошуком самого довгого відповідного префікса в
таблиці маршрутів.
Ефективність пересилання – це не основна перевага MPLS. MPLS
вносить у мережні технології якісно нові можливості, наприклад
маршрутизацію за адресою джерела.
MPLS-мітка IP-пакета є цілим числом і розташовується в резервному
полі його заголовка другого рівня (рис. 18.1) Як правило, другим рівнем для
локальних мереж є Ethernet.
Рисунок 18.1 – IP-пакет у складі Ethernet-кадру, що містить MPLS-мітку 18
267
У найпростішій формі MPLS можна розглядати як поліпшення
маршрутизації – позначений пакет проходить той же шлях, який він би
пройшов, якщо б він не був маркований. Цей шлях комутації за міткою (LSP
– label switching path) забезпечує передачу даних на вихід хмари MPLS.
Маршрутизатор усередині хмари MPLS, що здійснює комутацію пакетів за
мітками, називають LSR (label switch router). Коли LSR одержує пакет, він
використовує мітку пакета для визначення наступного хопа в LSP. При цьому
LSR міняє в пакеті мітку перед його відправленням.
LSR-маршрутизатори, що зв’язують MPLS-хмару із зовнішнім світом
називають граничними маршрутизаторами.
Мітки усередині хмари MPLS розподіляються за допомогою протоколу
розподілу міток LDP (Label Distribution Protocol). Інший спосіб установлення
шляху LSP для проходження пакетів забезпечують TE-тунелі (traffic
engineering – инжиніринг трафіку), що використовують модифікацію
протоколу резервування ресурсів RSVP (Resource Reservation Protocol)
RSVP TE. TE-тунелі дозволяють явно визначити шляхи LSP при обмеженнях
у вигляді обмеженої смуги пропускання інтерфейсів.
LDP
Розглянемо спочатку протокол LDP. У результаті LDP-сесій між LSR-

маршрутизаторами в MPLS-хмарі встановлюється погоджена система міток,
яка будується з використанням існуючих активних маршрутів.
MPLS працює із класами еквівалентності при пересиланні (forwarding
equivalence class – FEC). Приклади класів FEC:
• Безліч пакетів з однаковою мережею призначення.
• Безліч пакетів з однаковою мережею призначення й однаковою
мережею джерела.
• Безліч пакетів з однаковими портами призначення тa ін.
Для пакета при вході в MPLS-хмару завжди визначається його клас
FEC. В MPLS-хмарі для пакетів з кожного класу FEC за допомогою
протоколу LDP призначається своя система міток. Пакети з мітками з одного
268
FEC обробляються однаковим чином. Де б пакет не перебував в MPLS-
мережі, мітка визначає, до якому класу FEC пакет ставиться. Тобто пакет
пам’ятає своє походження. Саме цією властивістю MPLS вносить
принципово нову якість в сучасні мережні технології. Розглянемо мережу на
рис. 18.2.
Рисунок 18.2 – Топологія для виконання практичної частини (MPLS-мережа)
Виконайте налаштування ІР-адрес відповідно до топології рис. 18.2.

Хоча це й не строга вимога, бажано в LSR-маршрутизаторах
призначати IP-адреси на інтерфейс петлі Loopback і використовувати цю
адресу для установлення LDP-сесій. Оскільки може бути тільки одна LDP-
сесія між двома маршрутизаторами поза залежністю від того, скільки зв’язків
їх з’єднує, використання IP-адреси на інтерфейс Loopback гарантує, що
робота LDP не буде залежати від зміни стану й адрес цих зв’язків.
Інтерфейс-петля не пов’язаний з якимось реальним пристроєм. У якості
такого інтерфейсу в RouterOS може служити порожній міст. Створіть такі
інтерфейси й призначте на них адреси відповідно до рис. 18.2. Наприклад,
для LSR1
[admin@LSR1] > interface bridge add name=loopback
[admin@LSR1] > ip address add address=9.9.9.1/32 interface=loopback
Адреси й маски можна брати довільні. Маска /32 узята, щоб
підкреслити ізольованість інтерфейсу. Аналогічно виконайте створення
інтерфейсів Loopback на інших LSR-маршрутизаторах. Адреси на інтерфейси
269
Loopback задайте відповідно до топології рис. 18.2.
Оскільки LDP розподіляє мітки по активних маршрутах, важливою
вимогою є правильне настроювання IP-маршрутизації. Використовуємо
протокол маршрутизації OSPF, анонсуючи на кожному LSR-маршрутизаторі
всі приєднані мережі. Наприклад, на LSR1 OSPF може бути настроєний за
допомогою наступних команд:
[admin@LSR1] > routing ospf network add area=backbone network=172.16.0.0/16
Аналогічним чином виконайте настроювання OSPF на LSR-
маршрутизаторах. На зовнішніх відносно хмари MPLS-маршрутизаторах
призначте маршрут за замовчуванням:
Перевірте правильність настроювання маршрутизації, виконавши
команду ping від маршрутизатора R1 (172.16.0.2) до маршрутизатора R2:
[admin@R1] > ping 172.17.0.2
На кожному LSR-маршрутизаторі подивіться маршрути убік мережі
172.17.0.0/16 маршрутизатора R2.
[admin@LSR1] > ip route print detail where dst-address=172.17.0.0/16
У параметрі gateway показані всі можливі адреси наступного переходу

у напрямку до мережі призначення. Параметр gateway-status указує на
активну адресу наступного переходу в напрямку до мережі призначення.
Після фрази «reachable via» можна побачити через який інтерфейс досяжна
мережа призначення.
Результати введення команд зведіть у таблицю 18.1.
270
Таблица 18.1 – Маршрути на мережу 172.17.0.0/24
IP-адреса та хост Вихідний інтерфейс в
Хост
наступного переходу RouterOS (GNS3)
LSR1 1.1.1.1 – LSR2 ether1 (e0)
LSR2 2.2.2.2 – LSR3 ether2 (e1)
LSR3 3.3.3.2 – LSR6 ether2 (e1)
LSR4 5.5.5.1 – LSR5 ether2 (e1)
LSR5 6.6.6.2 – LSR6 ether2 (e1)
LSR6 Локально ether3 (e2)
Для розподілу міток активуйте на кожному LSR-маршрутизаторі

протокол LDP. Транспортну адресу встановіть як адресу інтерфейсу
Loopback. Це змушує маршрутизатор рекламувати сусідам по LDP цю адресу
як транспортну адресу. Оголосіть інтерфейси, що дивляться усередину
MPLS-мережі, як інтерфейси, що беруть участь в обміні міток.
В LSR1 і LSR6 інтерфейс ether3 не бере участь у роботі протоколу
LDP. Наприклад, для LSR1 виконайте команди
[admin@LSR1] > mpls ldp set enabled=yes transport-add=9.9.9.1 lsr-id=9.9.9.1
[admin@LSR1] > mpls ldp interface add interface=ether1
Для LSR2 це виконується командами

[admin@LSR2] > mpls ldp set enabled=yes transport-add=9.9.9.2 lsr-id=9.9.9.2
Інші маршрутизатори настроюються подібним чином. LDP активується

на інтерфейсах, що йдуть убік MPLS-хмари, й не активується на інтерфейсах,
що йдуть убік маршрутизаторів R1 та R2.
Після встановлення LDP-сесії й відпрацьовування LDP-протоколу в
LSR-маршрутизаторах з’являються LDP-сусіди. Наприклад, на LSR1:
[admin@LSR1] > mpls ldp neighbor print
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-
hello, V - vpls
# TRANSPORT LOCAL-TRANSPORT PEER SEND-TARGETED ADDRESSES
0 DO 9.9.9.2 9.9.9.1 9.9.9.2:0 no 1.1.1.1 2.2.2.1 7.7.7.1 9.9.9.2
1 DO 9.9.9.4 9.9.9.1 9.9.9.4:0 no 4.4.4.1 5.5.5.2 7.7.7.2 9.9.9.4
271
LSR1 має два сусіди LSR2 (9.9.9.2) та LSR4 (9.9.9.4). Також можна
побачити усі адреси цих сусідів. В якості класу FEC оберіть пакети, що
прямують в мережу 172.17.0.0./24. LDP на кожному LSR встановить для
цього класу вхідні мітки, які можна подивитися командою
mpls local-bindings print where dst-address=172.17.0.0/16
Результати введення цих команд зведіть у табл. 18.2.
Таблица 18.2 – Вхідні мітки пакетів в мережу 172.17.0.0/24

Хост Вхідні мітки Ідентифікатори сусідів
LSR1 18 9.9.9.2 9.9.9.4
LSR2 25 9.9.9.1 9.9.9.3 9.9.9.4
LSR3 35 9.9.9.2 9.9.9.6 9.9.9.5
LSR4 21 9.9.9.1 9.9.9.5 9.9.9.2
LSR5 29 9.9.9.4 9.9.9.6 9.9.9.3
LSR6 Impl-null 9.9.9.3 9.9.9.5
На LSR6 мітка не призначається (Impl-null), тому що мережа

172.17.0.0/16 приєднана до LSR6 безпосередньо.
LSR-маршрутизатор одержує від LDP-сусідів мітки. Подивіться ці

мітки для нашого класу FEC:
[admin@LSR1] > mpls remote-bindings print where dst-address=172.17.0.0/16
# DST-ADDRESS NEXTHOP LABEL PEER
2 AD 172.17.0.0/16 1.1.1.1 25 9.9.9.2:0
3 D 172.17.0.0/16 21 9.9.9.4:0
Побачте, що LSR1 одержав мітку 25 від LDP-сусіда LSR2 і мітку 21 від
LDР-сусіда LSR4. Саме ці мітки призначені на цих маршрутизаторах для
нашого класу FEC як вхідні (див. табл. 18.2). Згідно з табл. 18.1 IP-адресою
наступного переходу (NEXTHOP) убік мережі 172.17.0.0/16 буде адреса
1.1.1.1 маршрутизатору LSR2. Тому мітка 25 від хоста LSR2 оголошується
активною (прапор A ліворуч).
Для інших LSR маємо
272
[admin@LSR2] > mpls remote-bindings print where dst-address =172.17.0.0/16
3 D 172.17.0.0/16 18 9.9.9.1:0
4 AD 172.17.0.0/16 2.2.2.2 35 9.9.9.3:0
5 D 172.17.0.0/16 21 9.9.9.4:0

0 D 172.17.0.0/16 25 9.9.9.2:0
1 AD 172.17.0.0/16 3.3.3.2 impl-null 9.9.9.6:0
2 D 172.17.0.0/16 29 9.9.9.5:0

0 D 172.17.0.0/16 18 9.9.9.1:0
1 AD 172.17.0.0/16 5.5.5.1 29 9.9.9.5:0
2 D 172.17.0.0/16 25 9.9.9.2:0
0 D 172.17.0.0/16 21 9.9.9.4:0
1 AD 172.17.0.0/16 6.6.6.2 impl-null 9.9.9.6:0
2 D 172.17.0.0/16 35 9.9.9.3:0
0 D 172.17.0.0/16 35 9.9.9.3:0
1 D 172.17.0.0/16 29 9.9.9.5:0
Зведіть результат у табл. 18.3. Мітка обирається активною (показана

жирним), якщо вона прийшла від NEXTHOP (показаний у дужках). Активна
мітка стає новою міткою пакета убік мережі 172.17.0.0/16. Адреса, з якого
прийшла активна мітка, стає адресою переходу (NEXTHOP).
Таблиця 18.3 – Мітки, що отримуються

Від хосту
До
LSR1 LSR2 LSR3 LSR4 LSR5 LSR6
хосту
LSR1 25 (1.1.1.1) 21
LSR2 18 35(2.2.2.2) 21
LSR3 25 29 impl-null(3.3.3.2)
LSR4 18 25 29 (5.5.5.1)
LSR5 35 21 impl-null(6.6.6.2)
LSR6 35 29
273
Кожен LSR-маршрутизатор за отриманими від інших LSR мітками
будує базу пересилання за мітками LFIB (label forward information base). На
кожному LSR фрагмент LFIB для нашого FIB (пакети убік мережі
172.17.0.0/16) можна подивитися командою
mpls forwarding-table print where destination=172.17.0.0/16
Результат введення цих команд зведіть в таблицю 18.4.
Таблиця 18.4 – Таблиця пересилання за мітками

Хост IN-label OUT-label Interface NEXTHOP
LSR1 18 25 ether1 1.1.1.1 (LSR2)
LSR2 25 35 ether2 2.2.2.2 (LSR3)
LSR3 35 impl-null ether2 3.3.3.2 (LSR6)
LSR4 21 29 ether2 5.5.5.1 (LSR5)
LSR5 29 impl-null ether2 6.6.6.2 (LSR6)
Колонка IN-label визначається з табл. 18.2. Колонки OUT-label і

NEXTHOP визначаються за активними мітками, що прийшли від LDP-сусідів
(табл. 18.3). Колонка Interface береться з таблиці маршрутів (табл. 18.1).
Перевірте зміну міток, прослідкувавши маршрут адреси 172.16.0.2 (R1)
убік 172.17.0.2 (R2):
[admin@R1] > tool traceroute 172.17.0.2
# ADDRESS RT1 RT2 RT3 STATUS
1 172.16.0.1 10ms 1ms 1ms
2 1.1.1.1 3ms 2ms 2ms <MPLS:L=25,E=0>
3 2.2.2.2 3ms 2ms 2ms <MPLS:L=35,E=0>
4 3.3.3.2 2ms 2ms 6ms
5 172.17.0.2 8ms 3ms 3ms
Потрапляючи на LSR1 (172.16.0.1) пакет одержить мітку 18

(табл. 18.2). В LSR1, згідно з табл. 15.4, він одержить нову мітку 25 і буде
спрямований на LSR2 (1.1.1.1). В LSR2, згідно з табл. 18.4, він одержить нову
мітку 35 і буде спрямований на LSR3 (2.2.2.2). В LSR3, згідно з табл. 18.4, він
буде спрямований на LSR6 (3.3.3.2). При цьому йому не потрібна нова мітка,
тому що мережа 172.17.0.0/16 приєднана до LSR6 безпосередньо.
274
Фізично IP-маршрутизація в Ethernet-мережах здійснюється шляхом
належної заміни в IP-пакетах їх Ethernet-заголовків. Нові Ethernet-заголовки
визначаються за допомогою протоколу ARP. MPLS у цьому процесі участі не
бере.
Фільтрація міток
Не всі прив’язки міток до IP-підмереж можуть бути потрібні. Для

вибіркової прив’язки передбачена фільтрація міток, які LSR-маршрутизатори
можуть видавати або приймати.
Забороніть обмінюватися мітками між маршрутизаторами LSR2 і LSR4
у мережі на рис. 18.2.
[admin@LSR2]>mpls ldp advertise-filter add neighbor=9.9.9.4 advertise=no
і роутерами LSR3 і LSR5
Нехай у мережі на рис. 18.2 треба забезпечити комутацію за допомогою
міток тільки для IP-пакетів убік мережі 172.17.0.0/16. Дозвольте
маршрутизаторам видавати LDP-сусідам інформацію про мітки тільки для
пакетів із префіксом адреси приймача 172.17.0.0/16:
mpls ldp advertise-filter add prefix= 172.17.0.0/16 advertise=yes
і забороніть видавати інформацію про інші мітки
mpls ldp advertise-filter add prefix=0.0.0.0/0 advertise=no
На всіх маршрутизаторах м’яко перевантажте MPLS, убивши LDP-
сусідів:
mpls ldp neighbor remove [find]
Інформація про мітки, що отримується LSR значно скоротиться.
Наприклад, для LSR2:
[admin@LSR2]> mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
0 D 172.17.0.0/16 52 9.9.9.1:0
1 AD 172.17.0.0/16 2.2.2.2 46 9.9.9.3:0
Побачте, що LSR2 отримує інформацію про мітки тільки для мережі
172.17.0.0/16 и тільки від двох сусідів: LSR1 и LSR3.
275
RSVP TE
За допомогою протоколу RSVP TE в MPLS-хмарі встановлюється

односпрямований TE-тунель. Цей тунель визначає для пакетів шлях LSP.
Протокол RSVP TE виконує аналогічні функції із протоколом LDP –
забезпечення гарантованої доставки пакетів між граничними
маршрутизаторами в MPLS-хмарі. Однак протокол RSVP TE вносить у
процес установлення шляхів LSP додаткові можливості:
1) установлення LSP з явним визначенням частини шляху проходження
пакетів;
2) шлях LSP прокладається тільки через інтерфейси, що мають смугу
пропускання не меншу, ніж задана смуга пропускання тунелю.
Слід зазначити, що смуга пропускання інтерфейсу задається
адміністратором у ручному режимі при настроюванні RSVP TE-тунелю і
явно не пов’язана з фізичною смугою пропускання. Аналогічно, смуга
пропускання тунелю встановлюється адміністратором і не призводить до
обмеження на трафік через тунель.
RSVP TE-тунель має вхідний і вихідний LSR-маршрутизатори, що
розташовані в MPLS-хмарі. Ці маршрутизатори є граничними. Розглянемо, як
протокол RSVP визначає маршрутизатори, через які буде встановлюватися
шлях від вхідного до вихідного маршрутизатора тунелю. Цей шлях може
бути визначений декількома способами.
1. Як шлях береться маршрут, прокладений протоколами
маршрутизації як від вхідного маршрутизатора до вихідного, так і навпаки.
Якщо мережні інтерфейси маршрутизаторів, через які проходять маршрути,
не мають заданої смуги пропускання, то тунель не може бути створений.
2. Використання протоколу CSPF (Constrained Shortest Path First –
обмежений найкоротший шлях у першу чергу). CSPF реалізований у складі
протоколу маршрутизації OSPF. OSPF для реалізації CSPF поширює
мережею інформацію про пропускну здатність інтерфейсів. Далі OSPF будує
маршрути з урахуванням обмежень на смугу пропускання. Вхідний
маршрутизатор, використовуючи CSPF, обчислює шлях до вихідного
маршрутизатора з урахуванням обмежень на смугу пропускання.
276
3. Явно вказуються адреси інтерфейсів маршрутизаторів, через які буде
проходити тунель. Адреси вказуються в прямому й зворотному напрямках.
Вказується або весь шлях, або тільки його частина. В останньому випадку
інша частина шляху визначається протоколами маршрутизації або
протоколом CSPF. Тунель не створюється, якщо уздовж шляху знайдуться
інтерфейси з недостатньою пропускною здатністю.
Створення тунелю ініціюється вхідним маршрутизатором. Він відсилає
вихідному маршрутизатору повідомлення Path, що містить інформацію про
параметри й обмеження на смугу пропускання тунелю, що встановлюється.
Якщо маршрутизатор, що перебуває на шляху проходження повідомлення
Path, задовольняє обмеження на смугу пропускання, то він проштовхує
повідомлення Path наступному маршрутизатору по шляху до вихідного
маршрутизатора. У підсумку повідомлення Path досягне вихідного
маршрутизатора тунелю. Вихідний маршрутизатор відсилає відповідне
повідомлення Resv в зворотному напрямку. Якщо маршрутизатор, що
перебуває на шляху проходження повідомлення Resv, задовольняє
обмеження на смугу пропускання, то він проштовхує повідомлення Resv
наступному маршрутизатору по шляху до вхідного маршрутизатора.
У підсумку повідомлення Resv досягне вхідного маршрутизатора
тунелю. Тунель вважається встановленим. У противному разі тунель
встановитися не може. Вхідний і вихідний маршрутизатори тунелю
періодично обмінюються повідомленнями Path для підтримки тунелю в
робочому стані.
Знову розгляньте мережу на рис. 18.2. Виберіть в ній підтримку
протоколу LDP. Для цього на всіх LSR-маршрутизаторах виконайте команди:
mpls ldp set enabled=no transport-address=0.0.0.0 lsr-id=0.0.0.0
mpls ldp interface remove [find]
Для всіх LSR-маршрутизаторів включіть в настроюваннях протоколу
OSPF підтримку CSPF
routing ospf instance set mpls-te-area=backbone mpls-te-router-id=loopback
Для того щоб маршрутизатор міг брати участь у тунелі (або як вхідний,
або як проміжний, або як вихідний), у ньому треба настроїти підтримку
протоколу RSVP TE. Для цього треба вказати інтерфейси маршрутизатора,
277
які будуть задіяні у роботі RSVP TE, і їх пропускні здатності, що
заявляються:
[admin@LSR1] > mpls traffic-eng inter add interface=ether1 bandwidth=100000
Після цих налаштувань протокол OSPF-маршрутизаторів стане
розповсюджувати RSVP-інформацію мережею:
[admin@LSR1] > routing ospf lsa print
Створіть тунель від LSR1 до LSR6. Шлях dyn для майбутнього тунелю
визначте динамічно за допомогою протоколу CSPF.
[admin@LSR1] > mpls traffic-eng tunnel-path add use-cspf=yes name=dyn
Створіть тунель від LSR1 (9.9.9.1) до LSR6 (9.9.9.6) шириною в
1000 біт/сек з динамічним шляхом dyn. Вхідна сторона тунелю надана в
RouterOS у вигляді мережного інтерфейсу спеціального типу:
[admin@LSR1]>interface traffic-eng add from-address=9.9.9.1 to-
address=9.9.9.6 bandwidth=1000 primary-path=dyn disabled=no record-route=yes
Опція record-route=yes дозволить маршрутизатору LSR1 отримувати
інформацію про те, через які маршрутизатори пройде шлях тунелю.
Отримайте моніторинг стану тунелю:
[admin@LSR1] >> interface traffic-eng monitor numbers=0
tunnel-id: 2ye
primary-path-state: established
primary-path: dyn
secondary-path-state: not-necessary
active-path: dyn
active-lspid: 1
active-label: 16
explicit-route:
S:1.1.1.1/32,S:2.2.2.1/32,S:2.2.2.2/32,S:3.3.3.1/32,S:3.3.3.2/32
recorded-route: 2.2.2.1[18],3.3.3.1[18],3.3.3.2[0]
reserved-bandwidth: 1000bps
reserved-bandwidth: 1000bps
278
Побачьте, що шлях тунелю пройшов через маршрутизатори LSR2
(2.2.2.1) та LSR3 (3.3.3.1), і йому призначена мітка 16. Можна бачити, як
резервується частина полоси інтерфейсів під тунель, наприклад:
[admin@LSR2] > mpls traffic-eng interface print
Flags: X - disabled, I - invalid
# INTERFACE BANDWIDTH TE-METRIC REMAINING-BW
0 ether1 100kbps 1 100.0kbps
Щоб почати користуватися створеним тунелем, треба створити тунель
в зворотному напрямку від LSR6 до LSR1. Шлях dyn для тунелю визначте
динамічно за допомогою протоколу CSPF:
[admin@LSR6] > mpls traffic-eng tunnel-path add use-cspf=yes name=dyn
Створіть тунель від LSR6 (9.9.9.6) до LSR1 (9.9.9.1) шириною в
1000 біт/сек з динамічним шляхом dyn:
[admin@LSR6]>interface traffic-eng add from-address=9.9.9.6 to-
address=9.9.9.1 bandwidth=1000 primary-path=dyn disabled=no record-route=yes
Опція record-route=yes дозволить маршрутизатору LSR6 одержувати
інформацію про те, через які маршрутизатори пройде шлях тунелю.
Виконайте моніторинг стану тунелю:
[admin@LSR6] > interface traffic-еng monitor numbers=0
Подивіться LFIB для класу FEC, що визначається адресами 9.9.9.1 та
9.9.9.6 кінців тунелю. Подивіться, як переключення міток забезпечує
організацію тунелю:
[admin@LSR2] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS DESTINATION INTERFACE NEXTHOP
0 expl-null
1 T 16 16 9.9.9.1:1->9.9.9.6:1 ether2 2.2.2.2
2 T 17 expl-null 9.9.9.6:1->9.9.9.1:1 ether1 1.1.1.2
[admin@LSR3] > mpls forwarding-table pr
0 expl-null
1 T 16 expl-null 9.9.9.1:1->9.9.9.6:1 ether2 3.3.3.2
2 T 17 17 9.9.9.6:1->9.9.9.1:1 ether1 2.2.2.1
Призначте адреси на обидва кінці тунелю:
[admin@LSR1] > ip address add address=10.11.1.1/24 interface=traffic-eng
[admin@LSR6] > ip address add address=10.11.1.2/24 interface=traffic-eng
Перевірте зв’язок:
[admin@LSR6] > ping 10.11.1.1
279
1. Для чого використовується технологія MPLS?

2. Що таке MPLS-хмара?
3. Для чого використовується протокол LDP?
4. Які існують класи еквівалентності (FEC)?
5. Для чого використовується фільтрація міток?
6. Що таке ТЕ-тунель?
7. Які способи використовуються для визначення шляху від вхідного
до вихідного маршрутизатора тунелю?
8. Для чого використовується протокол CSPF і як він працює?

18.6 Зміст звіту

280
ТЕХНОЛОГІЯ MPLS L2VPN
Ознайомлення з принципами побудови VPN рівня 2 на основі MPLS-

мереж. Набуття практичних навичок налаштування параметрів VPN рівня 2
для MPLS-мереж на мережному обладнанні.
Протокол MPLS дозволяє мережному провайдеру робити своїм

замовникам послуги віртуальних приватних мереж VPN. Розглянемо
(рис. 19.1) провайдера мережних послуг, що з’єднує три віддалених сайти
(А1, А2 і А3) замовника А і три віддалених сайти (В1, В2 і В3) замовника В,
використовуючи свою мережу MPLS. Прийнято виділяти машрутизатори
провайдера, що граничать із сайтами замовників, і позначати їх з
використанням символів PE (provider edge – границя провайдера). На
рис. 19.1 бачимо три граничних маршрутизатори: PE1, PE2 і PE3.
Рисунок 19.1 – Мережа провайдера мережних послуг
281
VPN організуються на другому та третьму рівнях моделі OSI.
Розглянемо організацію VPN рівня 2 за допомогою протоколів VPLS.
Організація MPLS VPN рівня 2 за допомогою VPLS

VPLS – це служба віртуальних приватних локальних мереж (Virtual
Private LAN Service). Служить для забезпечення широкомовної
функціональності Ethernet-мереж поверх мереж MPLS. Дозволяє об’єднати
територіально віддалені локальні мережі в один домен широкомовлення
через віртуальні псевдокабелі Ethernet. Таке об’єднання може бути зроблене
й за допомогою EoIP-тунелів. VPLS, на відміну від EoIP:
• не вимагає інкапсуляції кадрів Ethernet в IP-пакети й уникає
накладних витрат, пов’язаних з обробкою IP-заголовків;
• має більшу гнучкість і функціональність та підтримується більшим
числом виробників мережного обладнання;
• є більш ефективним рішенням для створення VPN рівня 2.
Як віртуальний псевдокабель Ethernet виступає VPLS-тунель. Для
організації тунелю використовуються дві мітки: тунельна і транспортна.
Переговори про організацію VPLS-тунелю здійснюються з
використанням або протоколу LDP, або протоколу BGP.
Розглянемо настроювання VPLS VPN на прикладі топології на

рис. 19.2. Замовники A і B вимагають прозорого Ethernet-з’єднання між
сайтами й хочуть самі призначати IP-адреси. З рис. 19.2 бачимо, що
замовники вибрали однакові адреси 172.16.1.1 – 172.16.1.3 для своїх філій
А1, А2, А3 і В1, В2, В3.
Зберіть топологію в GNS3. Призначте адреси згідно з рис. 19.2. На
кожному маршрутизаторі провайдера створіть міст із ім’ям lobridge і
призначте на нього адресу 9.9.9.*/32, згідно з рис. 19.2.
282
Рисунок 19.2 – Топологія для виконання практичної частини (MPLS-мережа)
На маршрутизаторах PE1, PE2 і PE3 створіть по два мости з ім’ям A та

B.
Помістіть в ці мости Ethernet-інтерфейс, що йде в сторону замовника.
Наприклад, на PE1:
[admin@PE1]>interface bridge add name=А
[admin@PE1]>interface bridge port add bridge=А interface=ether3
[admin@PE1]>interface bridge add name=B
[admin@PE1]>interface bridge port add bridge=B interface=ether5
Усередині хмари MPLS шляхи комутації пакетів за міткою (LSP-label

switching path) організовуються за допомогою або протоколу LDP, або
протоколу RSVP. Маємо чотири способи організації VPLS VPN:
№
Организація VPLS-тунелю Организація LSP
п/п
1 LDP LDP
2 LDP RSVP
3 BGP LDP
4 BGP RSVP
283
1. Налаштування LDP VPLS
Розглянемо організацію VPLS-тунелю за допомогою протоколу LDP.
LSP організовуються або за допомогою протоколу LDP або за допомогою
протоколу RSVP.
1.1. LDP VPLS з організацією LSP за допомогою LDP

Для розподілу міток і організації шляхів комутації пакетів за міткою
активуємо на кожному LSR-маршрутизаторі протокол LDP. Транспортну
адресу встановимо як адресу інтерфейсу Loopback з ім’ям lobridge. Це
змушує маршрутизатор рекламувати сусідам по LDP цю адресу як
транспортну.
Оголосимо інтерфейси, що дивляться усередину MPLS-мережі, як
інтерфейси, що беруть участь в обміні міток. Наприклад для PE1 це
виконується командами
[admin@PE1]>mpls ldp set enabled=yes transport-address=9.9.9.1 lsr-id=9.9.9.1

[admin@PE1]>mpls ldp interface add interface=ether1
[admin@PE1]>mpls ldp interface add interface=ether2
Для P4 – командами:
[admin@P4]>mpls ldp set enabled=yes transport-address=9.9.9.5 lsr-id=9.9.9.5
[admin@P4]>mpls ldp interface add interface=ether1
Інші маршрутизатори настроюються подібним чином. LDP активується

на інтерфейсах, що йдуть убік MPLS-хмари, й не активується на інтерфейсах
маршрутизаторів, що йдуть убік замовників.
Для досягнення прозорого Ethernet-з’єднання між сайтами замовника
варто організувати наступні VPLS-тунелі, що утворять повнозв’язну
топологію кожного з кожним: PE1 – PE2, PE1 – PE3 і PE2 – PE3.
Кожен тунель вимагає створення VPLS-інтерфейсів на обох своїх
кінцях.
VPLS-тунелі настроюються в меню /interface vpls. Параметр vpls-id
ідентифікує тунель і повинен бути унікальним для кожного тунелю між
284
двома пірами. Рекомендується призначити MAC-адресу. Необхідні
налаштування для замовника A (vpls-id=0:10):
[admin@PE1]>interface vpls add name=A1toA2 remote-peer=9.9.9.6 \

mac-address=00:00:00:00:A1:A2 vpls-id=0:10 disabled=no
Необхідні налаштування для замовника B (vpls-id=0:20):

[admin@PE1]>interface vpls add name=B1toB2 remote-peer=9.9.9.6 \
mac-address=00:00:00:00:B1:B2 vpls-id=0:20 disabled=no
Налаштування VPLS-тунелю призводить до створення динамічного
LDP-сусіда та встановлення цільової LDP-сесії. Цільова LDP-сесія – це сесія,
що встановлюється між маршрутизаторами, які не є прямими сусідами.
Наприклад:
[admin@PE1] > mpls ldp neighbor pr
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello, V - vpls
# TRANSPORT LOCAL-TRANSPORT PEER SEND-TARGETED ADDRESSES
0 DO 9.9.9.2 9.9.9.1 9.9.9.2:0 no 1.1.1.1
2.2.2.1
7.7.7.1
9.9.9.2
1 DO 9.9.9.4 9.9.9.1 9.9.9.4:0 no 4.4.4.1
5.5.5.2
7.7.7.2
9.9.9.4
10.10.10.1
2 DOTV 9.9.9.6 9.9.9.1 9.9.9.6:0 yes 3.3.3.2
6.6.6.2
9.9.9.6
3 DOTV 9.9.9.7 9.9.9.1 9.9.9.7:0 yes 9.9.9.7
10.10.10.2
11.11.11.2
285
VPLS-тунель надає віртуальний Ethernet-зв’язок між
маршрутизаторами. Для прозорого з’єднання фізичних Ethernet-сегментів
вони повинні бути об’єднані в міст із VPLS-тунелем.
У нашому прикладі Ethernet-сегменти мають повнозв’язну топологію.
Якщо використовувати мости без протоколу (R)STP, то можуть виникнути
петлі трафіку. Наприклад, якщо від PE1 виходить широкомовний кадр, то він
досягне через VPLS-тунелі й PE2 і PE3. PE3, одержавши такий кадр, відішле
його PE2. PE2 одержить дві копії одного кадру, що є петлею. Уникнути
петель можна так: дозволити (R)STP, використовувати файєрвол,
використовувати властивість horizon. Останнє рішення найпростіше й
ефективне.
Базова ідея розщепленого обрію (split horizon) – не пересилати трафік,
що виникає на порту, на деяку безліч портів. Для VPLS це значить не
пересилати кадри, що з’явилися на одному тунелі в інший тунель, тому що
для цього є прямий зв’язок.
Для організації віртуальної мережі замовника А мости на PE1
організувати можна так:
[admin@PE1]>interface bridge port add bridge=A interface=A1toA2 horizon=1
[admin@PE1]>interface bridge port add bridge=A interface=A1toA3 horizon=1
Для організації віртуальної мережі замовника А мости на PE1
організувати можна так:
[admin@PE1]>interface bridge port add bridge=B interface=B1toB2 horizon=1
[admin@PE1]>interface bridge port add bridge=B interface=B1toB3 horizon=1
Аналогічним чином виконайте конфігурацію на PE2 та PE3.
Переконайтеся, що отримано VPN рівня 2. Для замовника А:

[admin@A1] > ip neighbor pr
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1 00:AB:F6:D2:C3:02 PE2 5.26 x86
1 ether1 00:AB:98:83:24:02 PE3 5.26 x86
2 ether1 00:AB:F8:16:AE:02 PE1 5.26 x86
3 ether1 172.16.1.2 00:AB:BD:F6:F6:00 A2 5.26 x86
4 ether1 172.16.1.3 00:AB:93:D7:B1:00 A3 5.26 x86
A1 побачив A2 та A3 на другому рівні. В цьому можна переконатися,
використовуючи утиліту ping на другому рівні:
[admin@A1] >ping 00:AB:BD:F6:F6:00
[admin@A1] >ping 00:AB:93:D7:B1:00
Тут використовуються MAC-адреси інтерфейсів ether1
маршрутизаторів A2 та A3:
286
[admin@A2] > ip neighbor pr

0 ether1 172.16.1.1 00:AB:F2:37:E6:00 A1 5.26 x86
1 ether1 00:AB:F6:D2:C3:02 PE2 5.26 x86
2 ether1 00:AB:98:83:24:02 PE3 5.26 x86
3 ether1 00:AB:F8:16:AE:02 PE1 5.26 x86
4 ether1 172.16.1.3 00:AB:93:D7:B1:00 A3 5.26 x86
A2 побачив A1 та A3 на другому рівні. В цьому можна переконатися,
використовуючи утиліту ping на другому рівні:
[admin@A3] > ip neighbor print
0 ether1 00:AB:F6:D2:C3:02 PE2 5.26 x86
1 ether1 00:AB:F8:16:AE:02 PE1 5.26 x86
2 ether1 00:AB:98:83:24:02 PE3 5.26 x86
3 ether1 172.16.1.2 00:AB:BD:F6:F6:00 A2 5.26 x86
4 ether1 172.16.1.1 00:AB:F2:37:E6:00 A1 5.26 x86
A3 побачив A1 та A2 на другому рівні.
Аналогічні результати отримаємо і для сайтів змовника B.
Вивчіть, як MPLS-мітки допомагають організувати VPN. Виконайте
звичайні пінги з сайта A1 вбік сайта A2:
[admin@ A1]> ping 172.16.1.2
Спочатку подивіться інформацію про стан VPLS-інтерфейсів:

[admin@PE1] > int vpls monitor numbers=A1toA2
remote-label: 42
local-label: 32
remote-status:
transport: 9.9.9.6/32
transport-nexthop: 4.4.4.1
imposed-labels: 16,42
[admin@PE2] > int vpls monitor numbers=A2toA1

remote-label: 32
local-label: 42
remote-status:
Як видно зі стану інтерфейсу A1toA2, передача здійснюється через Р3.

Тобто у цьому випадку для аналізу трафіку необхідно запускати аналізатор
пакетів Wireshark на інтерфейсах e1 маршрутизатора PE1, e1 маршрутизатора
P3 і e1 маршрутизатора P4 (рис. 19.3 – 19.5).
287
Рисунок 19.3 – Структура ICMP-пакета на інтерфейсі e1 маршрутизатора PE1
Рисунок 19.4 – Структура ICMP-пакета на інтерфесі e1 маршрутизатора P3
Рисунок 19.5 – Структура ICMP-пакета на інтерфесе e1 маршрутизатора P4
Пояснимо отримане. На всіх трьох рисунках у частині Ethernet II

бачимо інкапсульований Ethernet-кадр від MAC-адреси 00:AB:F2:37:E6:00
інтерфейсу ether1 сайта A1 до MAC-адреси 00:AB:BD:F6:F6:00 інтерфейсу
ether1 сайта A2.
[admin@A1] > interface ethernet print where name=ether1
Flags: X - disabled, R - running, S - slave
# NAME MTU MAC-ADDRESS ARP
0 R ether1 1500 00:AB:F2:37:E6:00 enabled
[admin@A2] > int ethernet print brief where name=ether1

Flags: X - disabled, R - running, S - slave
# NAME MTU MAC-ADDRESS ARP
0 R ether1 1500 00:AB:BD:F6:F6:00 enabled
Бачимо, що VPLS на PE1 призначив мітку 32 для тунелю між A1 і A2.

Віддаленій стороні призначена мітка 42. Цю мітку можна побачити на всіх
трьох рисунках. Для транспорту Ehernet-кадрів від A1 до A2
використовується мітка 16. Цю мітку можна побачити на рис. 19.3 і 19.4.
Таблиця пробросів MPLS на PE1 показує, що пакети з міткою 16 будуть
спрямовані на адресу 4.4.4.1 маршрутизатора P3:
[admin@PE1] > mpls forwarding-table print
14 L 29 16 9.9.9.6/32 ether2 4.4.4.1
288
Таблиця пробросів MPLS на P3 показує, що пакети з вхідною міткой 16
отримають таку ж вихідну мітку та будуть спрямовані на адресу 5.5.5.1
маршрутизатора P4. Цю мітку можна побачити на рис. 19.4.
[admin@P3] > mpls forwarding-table pr

1 L 16 16 9.9.9.6/32 ether2 5.5.5.1
1.2. LDP VPLS з організацією LSP за допомогою RSVP

Розглянемо мережу на рис. 19.2. Видаліть в ній підтримку протоколу
LDP на маршрутизаторах P1, P2, P3 і P4, які не є граничними:

Бачимо, що VPLS-Інтерфейси перейшли в неробочий стан.

Підтримка протоколу LDP на граничних маршрутизаторах необхідна
для організації VPLS-тунелю.
Для всіх LSR-маршрутизаторів включіть в настроюваннях протоколу
OSPF підтримку CSPF:
routing ospf instance set 0 mpls-te-area=backbone mpls-te-router-id=lobridge
Вкажіть, що всі інтерфейси граничних маршрутизаторів, що йдуть убік

мережі провайдера, будуть брати участь у роботі RSVP TE і заявіть
пропускні здатності. Наприклад, інтерфейс ether1 граничного
маршрутизатора PE1 іде убік MPLS-хмари
[admin@PE1]>mpls traffic-eng inter add interface=ether1 bandwidth=100000
Аналогічним чином налаштуйте усі інтерфейси маршрутизаторів, що

знаходяться в MPLS-мережі.
На граничних маршрутизаторах для майбутніх RSVP TE-туннелей
визначте динамичний шлях dyn за допомогою CSPF:
mpls traffic-eng tunnel-path add use-cspf=yes name=dyn
289
Створіть RSVP TE-тунелі, утворюючи повнозв’язну топологію для
граничних маршрутизаторів:
[admin@PE1]>interface traffic-eng add from-address=9.9.9.1 \

to-address=9.9.9.6 bandwidth=100000 primary-path=dyn disabled=no \
record-route=yes name = 1to2
Почекайте, поки підіймуться RSVP TE-інтерфейси. Побачте, що VPLS-
інтерфейси також перейшли в робочий стан. Переконайтеся, що VPN рівня 2,
як і раніше, функціонує:
[admin@A1] > ip neighbor print

0 ether1 00:AB:F8:16:AE:02 PE1 5.26 x86
1 ether1 172.16.1.2 00:AB:BD:F6:F6:00 A2 5.26 x86
2 ether1 00:AB:F6:D2:C3:02 PE2 5.26 x86
3 ether1 172.16.1.3 00:AB:93:D7:B1:00 A3 5.26 x86
4 ether1 00:AB:98:83:24:02 PE3 5.26 x86
пінг з сайта A1 в сторону сайта A2:
[admin@A1]> ping 172.16.1.2
Подивіться на інформацію про стан VPLS-интерфейсу:

[admin@PE1] > interface vpls monitor numbers=A1toA2
remote-label: 78
local-label: 29
remote-status:
transport: 1to2
290
Як бачимо, в цьому разі тунель організовано через маршрутизатор Р1
(transport-nexthop: 1.1.1.1). Тому аналізатор трафіку необхідно запускати на
інтерфейсах e0 маршрутизатора PE1, e1 маршрутизатора P1 і e1
маршрутизатора P2 . На рис 19.6 – 19.8 наведено відповідні кадри.
Рисунок 19.7 – Структура ICMP-пакета на інтерфейсі e1 маршрутизатора P1
Пояснимо отримане. На всіх трьох рисунках у частині Ethernet II,

бачимо інкапсульований Ethernet-кадр від MAC-адреси 00:AB:F2:37:E6:00
інтерфейсу ether1 маршрутизатора A1 до MAC-адреси 00:AB:BD:F6:F6:00
інтерфейсу ether1 маршрутизатора A2.
трьох рисунках. Для транспорту Ethernet-кадрів від A1 до A2
використовується RSVP TE-Інтерфейс 1to2 і мітка 17. Ця мітка є на рис. 19.6.
Можна побачити інформацію про стан RSVP TE-інтерфейсу:
[admin@PE1] > int traffic-eng monitor numbers="1to2"

tunnel-id: 1
tunnel-id: 1
primary-path: dyn
291
active-path: dyn
active-lspid: 1
active-label: 17
explicit-route: S:1.1.1.1/32,S:2.2.2.1/32,S:2.2.2.2/32,S:3.3.3.1/32,
S:3.3.3.2/32
recorded-route: 2.2.2.1[17],3.3.3.1[17],3.3.3.2[0]
reserved-bandwidth: 10.0kbps
Таблиця пробросів MPLS на P1 показує, що пакети з вхідною міткою
17 отримують таку ж вихідну мітку та будуть передані на адресу 2.2.2.2

# IN-LABEL OUT-LABELS DESTINATION INT NEXTHOP
0 expl-null
1 T 16 expl-null 9.9.9.6:1->9.9.9.1:3 eth 1.1.1.2
2 T 17 17 9.9.9.1:1->9.9.9.6:1 eth 2.2.2.2
3 T 18 18 9.9.9.1:1->9.9.9.7:2 eth 2.2.2.2
2. Налаштування BGP VPLS

Розглянемо організацію VPLS-тунелю за допомогою протоколу BGP.
Завдяки своїй статичній природі, VPLS-тунелі, засновані на LDP,
мають проблеми масштабованості, які зростають при збільшенні числа
сайтів, підключених по VPLS. Однією із проблем є вимога збереження
повнозв’язної топології LDP-тунелів між сайтами, що формують VPLS. У
випадку, якщо число вузлів в VPLS високе, додавання нового сайта до
існуючої VPLS-мережі може стати обтяжним для адміністратора мережі.
Додавання нового вузла потребує створення необхідної кількості VPLS-
тунелів на маршрутизаторі, до якого приєднаний новий вузол, що потребує
настроювання маршрутизаторів на інших кінцях тунелів.
Загалом, VPLS, засновані на BGP, служать двом цілям:
• автоматичного виявлення: немає необхідності налаштовувати VPLS-
зв’язок кожного нового граничного маршрутизатора з усіма віддаленими
кінцевими точками тунелів VPLS;
• сигналізації: мітки, що використовуються для тунелів VPLS на
віддалених кінцевих точках, поширюються в тому самому відновленні BGP.
Це означає, що немає необхідності у цільових сесіях LDP між
кінцевими точками тунелю, як у випадку VPLS на основі LDP.
292
Правильне настроювання VPLS, заснованих на BGP, дозволяє
уникнути конфігурації маршрутизаторів, які не підключені до нового вузла.
Для організації VPLS BGP маршрутизатори обмінюються
повідомленнями NLRI (Network Layer Reachability Information), що містять
якусь інформацію про VPLS.
BGP VPLS – це лише метод обміну мітками для тунелів VPLS, а не
метод обміну трафиком між кінцевими точками тунелів VPLS. Тому варто
забезпечити поширення кадрів MPLS між кінцевими точками тунелів VPLS.
Кадри MPLS поширюються по шляхах LSP. LSP організовуються або за
допомогою протоколу LDP, або за допомогою протоколу RSVP.
2.1. Конфігурація сесій BGP. Відбивач маршрутів

Для забезпечення поширення повідомлень VPLS NLRI по BGP повинна
бути використана багатопротокольна можливість BGP. Це здійснюється
установленням в BGP-пірі для властивості address-families значення l2vpn.
Для організації BGP VPLS необхідно забезпечити доставку
багатопротокольної NLRI між VPLS-маршрутизаторами. Це можна зробити
або шляхом встановлення BGP-сесій між всіма парами VPLS-
маршрутизаторів, або шляхом використання відбивача маршрутів. У
першому випадку перевага BGP VPLS над LDP VPLS сумнівна: при
додаванні нового сайта в VPLS необхідно настроїти BGP-піри на всіх
маршрутизаторах, що формують VPLS.
При використанні відбивача маршрутів додавання нового сайта до
VPLS стає більш простим – маршрутизатор, до якого приєднаний новий сайт,
повинен тільки встановити BGP-сесію з відбивачем маршрутів. На інших
маршрутизаторах (крім відбивача маршрутів) настроювання не потрібні. Сам
маршрутизатор – відбивач маршрутів – може також брати участь у
формуванні VPLS.
У найпростішому випадку відбивач маршрутів передає отриманий
BGP-маршрут без зміни атрибута NextHop для маршруту. Ця властивість
дозволяє уникнути BGP-з’єднань типу кожен з кожним. Для того щоб
маршрутизатор був відбивачем маршрутів для проходження повідомлень
293
VPLS NLRI, він не зобов’язаний брати участь в VPLS і навіть може не
підтримувати MPLS.
Є кілька зауважень про конфігурацію пірів BGP:
1. Для обміну повідомленнями VPLS NLRI немає потреби поширювати
IP- або IРv6-маршрути, досить визначити address-families=l2vpn ;
2. Для адресації пірів використовуються адреси мостів, тобто
інтерфейсу lobridge (локальна адреса визначається установленням update-
source). BGP-пір, починаючи передавати повідомлення VPLS NLRI,
призначає свою локальну адресу як BGP NextHop. Приймальний VPLS-
маршрутизатор використовує отриману адресу BGP NextHop, як адресу
кінцевої точки тунелю.
Зробимо маршрутизатор P1 відбивачем маршрутів. Екземпляр BGP для
відбивача маршрутів повинен мати властивість client-to-client-reflection=yes,
що є налаштуванням за замовчуванням.
Для забезпечення належного поширення повідомлень VPLS NLRI BGP-
піри убік маршрутизаторів PE1, PE2 і PE3 повинні бути обов’язково
налаштовані з установленням route-reflect=yes:
[admin@P1]>routing bgp peer add remote-address=9.9.9.1 remote-as=65530 \
route-reflect=yes address-families=l2vpn update-source=lobridge
У налаштуваннях BGP-пірів у PE1, PE2 та PE3 вбік відбивача P1
(9.9.9.2) залишаємо для route-reflect значення за замовчуванням no.
routing bgp peer add remote-address=9.9.9.2 remote-as=65530 \

address-families=l2vpn update-source=lobridge
Має бути встановлено три BGP-з’єднання. У цьому можна
переконатися, переглянувши час uptime існування з’єднання командою
routing bgp peer print status.
Якщо треба додати новий сайт в VPLS-мережу, приєднуючи його до

маршрутизатора P2, необхідно лише настроїти BGP-пір на відбивачі P1 убік
P2 і BGP-пір на P2 убік відбивача P1. Причому на P1 з установленням route-
reflect=yes.
294
2.2. BGP VPLS з організацією LSP за допомогою RSVP
Підготуйте топологію для подальшої роботи. Спочатку видаліть VPLS-
інтерфейси з мостів, а потім видаліть і самі VPLS-інтерфейси. Пам’ятаємо,
що на даний момент LSP організовані за допомогою протоколу RSVP.
VPLS-тунелі створюються динамічно при одержанні за допомогою
BGP-сигналізації правильного повідомлення BGP NLRI. Отже, не треба
створювати VPLS-інтерфейси.
Для прозорої доставки Ethernet-сегментів крізь VPLS-мережу повинні
бути настроєні мости. Мости вже створені (для LDP VPLS). Залиште в них
тільки фізичні Ethernet-інтерфейси.
Активація VPLS на основі BGP-сигналізації змушує маршрутизатор
розсилати інформацію VPLS BGP NLRI, а це що вказує на те, що він
належить до деякої VPLS. Одержавши таку інформацію, інші члени тієї ж
VPLS будуть знати, як установити VPLS-тунель із цим маршрутизатором.
Для налаштування двох VPLS для замовників A і B на граничних
маршрутизаторах треба виконати команди для активації VPLS на основі
BGP-сигналізації:
[admin@PE1]>interface vpls bgp-vpls add bridge=A bridge-horizon=1 \
route-distinguisher=9.9.9.1:1 site-id=1 export-route-targets=1:1 \
import-route-targets=6:1,7:1
[admin@PE1]>interface vpls bgp-vpls add bridge=B bridge-horizon=1 \


Тут маємо такі параметри:
• site-id – значення, яке має бути унікальним для кожного
маршрутизатора в межах конкретної VPLS. Для підвищення ефективності
варто брати це значення з вузького діапазону цілих чисел.
295
• Bridge – визначає міст, до якого додадуться динамічно
створювані VPLS-тунелі.
• Bridge-horizon – служить для запобігання утворенню петель.
• route-distinguisher – визначає значення, що прикріплюється до
VPLS NLRI; маршрутизатори використовують це значення для утворення
тунелю. Щоб приймальні маршрутизатори розрізняли інформацію від різних
VPLS, це значення повинне бути різним для різних VPLS на одному
пристрої. Route-distinguisher не використовується одержаним
маршрутизатором, для визначення належності передавального
маршрутизатора конкретної VPLS. Для цього використовується route-targets.
• export-route-targets – це свого роду мітка (синонім) для route-
distinguisher.
• import-route-targets – це список із зовнішніх export-route-
targets, який використовується для визначення сукупності маршрутизаторів,
що утворюють конкретну VPLS.
• route-distinguisher, export-route-targets і import-route-targets –
параметри, що мають вигляд A:B, де A – або IP-адреса (будь-яка), або ціле
число (іноді номер автономної системи); B – ціле число. У призначенні цих
параметрів має місце певне свавілля. У принципі route-distinguisher і export-
route-targets можуть бути будь-якою (унікальною для роутера) парою цілих
чисел або парою адреса – число.
Після налаштування маршрутизатори обміняються BGP-пакетами (рис.
19.9).
У підсумку створюються динамічні VPLS-інтерфейси на PE1, PE2 і PE3.
Наприклад, на PE1:
[admin@PE1]>interface vpls print
296
Рисунок 19.9 – BGP-повідомлення Update від PE2 до PE1.
На рис. 19.9 можна побачити в розділі NLRI route-targets 6:1 і route-

distinguisher 9.9.9.6:1 у вигляді 6.9.9.9:1.
Динамічні VPLS-інтерфейси автоматчно додаються у міст, що можна
переглянути на PE1, PE2 і PE3 командою interface bridge port print,
наприклад:
[admin@PE1] > interface bridge port print

Flags: X - disabled, I - inactive, D - dynamic
# INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0 ether3 A 0x80 10 none
1 ether5 B 0x80 10 none
2 D vpls1 B 0x80 50 1
3 D vpls2 A 0x80 50 1
4 D vpls3 A 0x80 50 1
5 D vpls4 B 0x80 50 1
Тут ми також отримали підтвердження, що працює відбиття маршруту

на P1, тому що немає BGP-пірів між PE1 і PE2, PE1 і PE3, PE2 і PE3.
Встановлена повнозв’язна топологія VPLS-тунелів. Подивіться на
сусідів на сайтах замовника А і B. Переконайтеся, що наша VPN рівня 2, як і
раніше, функціонує.
пінг з сайта A1 убік сайта A2:
[admin@A1]> ping 172.16.1.2
297
На рис. 19.10 – 19.12 наведено структури кадрів, захоплені на
інтерфейсі e0 маршрутизатора PE1, інтерфейсі e1 маршрутизатора P1 та
інтерфейсі e1 маршрутизатора P1 при виконанні пінгу з сайта A1 убік сайта
A2.
Пояснимо отримане. На всіх трьох рисунках у частині Ethernet II

бачимо інкапсульований Ethernet-кадр від інтерфейсу ether1 сайта A1 до
інтерфейсу ether1 сайта A2.
Можна побачити інформацію про стан VPLS-інтерфейсу:
[admin@PE1] > interface vpls monitor numbers=2

remote-label: 17
local-label: 22
remote-status:
transport: 1to2

298
трьох рисунках. Для транспорту Ehernet-кадрів від A1 до A2
використовується RSVP TE-Інтерфейс 1to2 і мітка 17. Ця мітка є на рис.
19.10.
Можна побачити інформацію про стан RSVP TE-інтерфейсу:
[admin@PE1] > interface traffic-eng monitor numbers="1to2"

tunnel-id: 1
primary-path: dyn
active-path: dyn
active-lspid: 1
active-label: 17
explicit-route:
S:1.1.1.1/32,S:2.2.2.1/32,S:2.2.2.2/32,S:3.3.3.1/32,S:3.3.3.2/32
recorded-route: 2.2.2.1[17],3.3.3.1[17],3.3.3.2[0]
reserved-bandwidth: 10.0kbps
Таблиця пробросів MPLS на P1 показує, що пакети із вхідною міткою

17 отримують таку ж вихідну мітку й будуть спрямовані на адресу 2.2.2.2
[admin@P1]> mpls forwarding-table print

0 expl-null
1 T 16 expl-null 9.9.9.6:1->9.9.9.1:1 ether1 1.1.1.2
2 T 17 17 9.9.9.1:1->9.9.9.6:1 ether2 2.2.2.2
2.3. BGP VPLS з організацією LSP за допомогою LDP
Пам’ятаємо, що на даний момент LSP організовані за допомогою

протоколу RSVP. Замінимо RSVP на LDP. Для цього на всіх граничних
маршрутизаторах видалимо RSVP TE-інтерфейси
interface traffic-eng rem [find]
Для всіх LSR-маршрутизаторів відключіть в налаштуваннях протоколу

OSPF підтримку CSPF:
routing ospf instance set 0 mpls-te-area=
routing ospf instance set 0 mpls-te-router-id=
299
Видаліть інтерфейси mpls traffic-eng в маршрутизаторах PE1, PE2 та
PE3, які беруть участь в роботі RSVP TE:
mpls traffic-eng interface rem [find]
Для організації шляхів LSP-комутації пакетів за міткою активуйте на

кожному LSR-маршрутизаторі протокол LDP відповідно до розділу 1.1.
Транспортну адресу встановіть як адресу інтерфейсу Loopback з ім’ям
lobridge. Оголосіть інтерфейси, що дивляться усередину MPLS-мережі, як
інтерфейси, що беруть участь в обміні міток.
Автоматично утворяться динамічні VPLS-інтерфейси на PE1, PE2 і
PE3. Наприклад, на PE1:
[admin@PE1] > interface vpls print
Динамічні VPLS-інтерфейси автоматично додадуться у міст, що можна

побачити на PE1, PE2 і PE3 командою interface bridge port print, наприклад:

2 D vpls1 A 0x80 50 1
3 D vpls2 A 0x80 50 1
4 D vpls3 B 0x80 50 1
5 D vpls4 B 0x80 50 1
Встановлена повнозв’язна топологія VPLS-тунелів. Подивіться на

сусідів на сайтах замовника А і B. Переконайтеся, що VPN рівня 2, як і
раніше, функціонує.
пінг з сайта A1 убік сайта A2.
[admin@A1]> ping 172.16.1.2
300
За допомогою аналізатора пакетів Wireshark отримайте структуру
ICMP-пакетів на інтерфесах e0 маршрутизатора PE1, e1 маршрутизатора P1 і
e1 маршрутизатора P2, яка повністю аналогічна структурі для випадку п. 1.1
(рис. 19.13).
Рисунок 19.13 – Структура ICMP-пакетів при виконанні пінгу від A1 до A2
Можна побачити інформацію про стан VPLS-інтерфейсів:

[admin@PE1] > interface vpls monitor numbers=2
remote-label: 17
local-label: 22
remote-status:

Віддаленій стороні призначена мітка 17. Для транспорту Ehernet-кадрів
від A1 до A2 використовується мітка 33. Таблиця пробросів MPLS на PE1
показує, що пакети з міткою 33 будуть направлені на адресу 1.1.1.1
маршрутизатора P1:

0 expl-null
1 V 22 vpls2
15 L 90 33 9.9.9.6/32 ether1 1.1.1.1
301
33 отримують вихідну мітку 16 та будуть направлені на адресу 2.2.2.2
маршрутизатора P2:
[admin@P1] > mpls forwarding-table print
0 expl-null
10 L 33 16 9.9.9.6/32 ether2 2.2.2.2

16 не отримують вихідну мітку (тобто P2 виконує операцію pop label) та
будуть направлені на адресу 3.3.3.2 маршрутизатора P3:

0 expl-null
1 L 16 9.9.9.6/32 ether2 3.3.3.2
Таблиця пробросів MPLS на PE2 показує, что пакети з вхідною міткою

17 не отримують вихідну мітку (тобто PE2 виконує операцію pop label) та
будуть направлені на інтерфейс vpls4:

0 expl-null
1 L 17 vpls4
Інформацію про vpls-інтерфейси можна переглянути командою
[admin@PE2] > interface vpls print
А які порти знаходяться в яких мостах – командою

2 D vpls1 A 0x80 50 1
302
3 D vpls2 B 0x80 50 1
4 D vpls3 B 0x80 50 1
5 D vpls4 A 0x80 50 1
Прослідкуйте призначення міток при передачі пакетів у зворотному
напрямку (від А2 до А1).
! Збережіть топологію, вона буде використовуватися в ЛР № 20.
1. Для чого використовується технологія MPLS L2VPN2?

2. Що таке VPLS та для чого він використовується?
3. Які переваги дає VPLS у порівнянні з іншими L2VPN?
4. Як організується VPLS-тунель за допомогою LDP з LSP на основі
LDP?
5. Як організується VPLS-тунель за допомогою LDP з LSP на основі
RSVP?
6. Як організується VPLS-тунель за допомогою BGP з LSP на основі
LDP?
7. Як організується VPLS-тунель за допомогою BGP з LSP на основі
RSVP?
7. Для чого використовується split horizon при організації мосту?
8. Для чого використовується стек міток і як він обробляється?


303
ТЕХНОЛОГІЯ MPLS L3VPN
Ознайомлення з принципами побудови VPN рівня 3 на основі MPLS-

мереж. Набуття практичних навичок налаштування параметрів VPN рівня 3
для MPLS-мереж на мережному обладнанні.
Цей тип VPN ґрунтується на технології VRF (Virtual Routing and

Forwarding – віртуальна маршрутизація й пересилання), що дозволяє
одночасне існування на пристрої декількох таблиць маршрутизації. RouterOS
підтримує VRF, що дозволяє створювати багато екземплярів таблиць для
віртуальної маршрутизації й пересилання. Це корисно для MPLS VPN,
заснованих на BGP. На відміну від BGP VPLS, що працює на 2-му рівні OSI,
VRF VPN працюють на 3-му рівні й обмінюється IP-префіксами між
маршрутизаторами. VRF вирішує проблему перетинання однакових IP-
префіксів і забезпечує конфіденційність за допомогою роздільної
маршрутизації для різних VPN.
VRF ініціалізується в меню /ip route vrf. Для визначення таблиці
маршрутизації VRF варто задати атрибут routing-mark, інтерфейс, route
distinguisher і списки експорту й імпорту. Приєднаний маршрут, що
відповідає цьому інтерфейсу, автоматично додається в VRF-таблицю
маршрутизації. Список експорту повинен містити хоча б один елемент для
цього VRF. Зазвичай використовують співвідношення 1:1 між route
distinguisher і окремою таблицею маршрутизації VRF, але це не обов’язково.
Додавати маршрут у таблицю маршрутизації VRF можна, визначаючи
атрибут routing-mark.
Для поширення між маршрутизаторами маршрутів з таблиці маршрутів
VRF використовується багатопротокольний BGP з адресним сімейством
304
VPNv4. Для кожного екземпляра BGP, що бере участь в VRF-маршрутизації,
варто задати список VRF. VRF визначається атрибутом routing-mark.
Додавання маршруту в таблицю VRF управляється атрибутами BGP.
Як тільки VRF для BGP настроєні, створюються активні маршрути сімейства
адрес VPNv4. Ці маршрути встановлюються в окрему таблицю маршрутів і їх
можна побачити з меню /routing bgp vpnv4-route. Через BGP можна
поширювати однакові префікси IРv4 для різних мереж. Як правило,
маршрути VPNv4 з однаковими префіксами будуть поширюватися тільки
після належного налаштування MPLS.
VRF-маршрутизація використовує так звані VPNv4-маршрути, що
працюють із префіксами, які складаються з route-distinguisher і префікса IPv4.
Тим самим на одному маршрутизаторі можна по-різному маршрутизувати
пакети з однаковими префіксами IPv4, що приходять від різних джерел. Як
правило VRF-маршрутизація функціонує тільки після належного
настроювання MPLS.
1. MPLS VPN 3-го рівня з організацією LSP за допомогою LDP
Розглянемо налаштування MPLS VPN 3-го рівня на прикладі топології

(рис. 20.1), що є копією топології, наведеної на рис. 19.2 і що відрізняється
від неї лише налаштуванням адрес пристроїв A1, A2, A3, B1, B2, B3
замовників (скористайтеся топологією ЛР № 19).
Замовники A і B вимагають зв’язати в єдиний адресний простір свої
три ІР-мережі. Причому ці мережі в них виявилися однаковими:
172.16.1.0/24, 172.16.2.0/24, 172.16.3.0/24.
Усередині хмари MPLS шляхи комутації пакетів за міткою LSP
організовуються або за допомогою протоколу LDP, або за допомогою
протоколу RSVP. На теперішній момент топологія використовує LDP
(останнє налаштування в ЛР № 19).
305
Рисунок 20.1 – Топологія для MPLS VPN 3-го рівня
Видаліть з топології існуючу там підтримку BGP VPLS і інших

настроювань, що стосуються VPN рівня 2.
На всіх граничних маршрутизаторах провайдера видаліть підтримку
BGP VPLS:
interface vpls bgp-vpls remove [find]
Видаліть інтерфейси з мостів:

interface bridge port remove [find]
Видаліть мости A і B:
interface bridge remove A,B
Призначте відповідно до рис. 20.1 адреси для мереж 172.16.1.0/24,

172.16.2.0/24, 172.16.3.0/24 замовників A та B. На комп’ютерах
(маршрутизаторах) замовників визначте маршрути за замовчуванням вбік
мережі провайдера, наприклад для A1:
[admin@A1] > ip route add gateway=172.16.1.1
На граничних маршрутизаторах провайдера для BGP-пірів встановіть

підтримку сімейства адрес VPNv4. Для PE1, PE2 і PE3:
306
routing bgp peer set 0 address-families=vpn4
Для відбивача маршрутів P1 є три BGP-піра:

routing bgp peer set 0,1,2 address-families=vpn4
Про встановлення BGP-з’єднань можна переконатися, переглянувши

час існування з’єднання uptime у виведенні команди routing bgp peer print
status.
Інтерфейси граничних маршрутизвторів, які йдуть в сторону
маршрутизаторів замовників, помістіть в дві VRF. Для VRF замовника А (В)
призначте маркер маршрутів А (В).
[admin@PE1]>ip route vrf add routing-mark=A interfaces=ether3 \
route-distinguisher=9.9.9.1:1 export-route-targets=1:1 \
import-route-argets=6:1,7:1
[admin@PE1]>ip route vrf add routing-mark=B interfaces=ether4 \


Тут маємо такі параметри:
• route-distinguisher – визначає значення, що прикріплюється до
BGP-пакета; маршрутизатори, використовують це значення для заповнення
таблиць VPNv4-маршрутизації й організації VPN. Щоб приймальні
маршрутизатори розрізняли інформацію від різних VPN, це значення
повинне бути різне для різних VPN на одному пристрої. Route-distinguisher
не використовується маршрутизатором для визначення належності
передавального роутера конкретної VPN. Для цього використовується route-
targets.
• export-route-targets – це свого роду мітка (синонім) для route-
distinguisher.
307
• import-route-targets – це список із зовнішніх export-route-targets,
який використовується для визначення сукупності маршрутизаторів, що
утворять конкретну VPN.
Вкажіть BGP, що VRF, обумовлені маркерами маршрутів A і B, будуть
брати участь у маршрутизації для сімейства адрес vpnv4:
[admin@PE1] > routing bgp instance vrf add routing-mark=A \
redistribute-connected=yes
[admin@PE1] > routing bgp instance vrf add routing-mark=B \
Додайте IP-адреси на інтерфейси маршрутизаторів PE1, PE2, PE3, які

направлені в сторону замовників.
Маршрутизатор PE1 отримає от маршрутизатора PE2 BGP-
повідомлення Update (рис. 20.2), в якому для організації маршрутизації
пакетів замовника A вбік мережі 172.16.2.0/24 призначається мітка 17.
Зазначте, що route-distinguisher 9.9.9.6:1 для VPN замовника A в
маршрутизаторі PE2 надано в повідомленні у вигляді 6.9.9.9:1. У
повідомленні можна також побачити route-targets 6:1 VPN замовника A в
маршрутизаторі PE2.
Рисунок 20.2 – BGP-повідомлення Update
308
Аналогічні повідомлення отримають інші PE-маршрутизатори.
Подивіться на граничному маршрутизаторі PE1 маршрути з маркером
A:
[admin@PE1] > ip route print detail where routing-mark=A
Побачте наявність маршрутів в сторону всіх мереж 172.16.1.0/24,

172.16.2.0/24 та 172.16.3.0/24 комп’ютерів A1, A2 і A3 замовника A.
Подивіться на граничному маршрутизаторі PE1 маршрути з маркером
B
[admin@PE1] > ip route print detail where routing-mark=B
Побачте наявність маршрутів в сторону всіх мереж 172.16.1.0/24,

172.16.2.0/24 і 172.16.3.0/24 комп’ютерів B1, B2 та B3 замовника B.
Маршрут убік безпосередньо приєднаних мереж з однаковим
префіксом 172.16.1.0/24 різний для різних замовників. Для замовника A він
іде через інтерфейс ether3, а для замовника B – через інтерфейс ether5.
Перегляд на граничних маршрутизаторах PE2 і PE3 маршрутів з маркерами A
або B дасть аналогічний результат.
Ви одержали два незалежні VPN третього рівня для замовників А та В,
у яких однакові адресні простори. Переконайтеся в цьому за допомогою
команди /tool telnet. Наприклад, зайдіть із A1 в A2, з А1 в А3, з А2 в А3, з B1
в B2, з B1 в А3 і з B2 в B3. Вихід із сесії telnet здійснюється за допомогою
комбінації клавіш «Ctrl+D».
пінги з сайта A1 убік сайта A2:
[admin@A1]> ping 172.16.2.2
309
За допомогою аналізатора пакетів Wireshark вивчимо структуру ICMP-
пакетів на інтерфейсах e0 маршрутизатора PE1, e1 маршрутизатора P1 і e1
маршрутизатора P2 (рис. 20.3 – 20.5).
Роз’яснемо отримане. Таблиця VPNv4-маршрутів на граничному

маршрутизаторі PE1
[admin@PE1] > routing bgp vpnv4-route print

Flags: L - label-present
# ROUTE-DISTINGUISHER DST-ADDRESS GATEWAY INTERFACE IN-LABEL OUT-LABEL
0 L 9.9.9.6:1 172.16.2.0/24 9.9.9.6 ether2 17 17
1 L 9.9.9.7:1 172.16.3.0/24 9.9.9.7 ether2 17 17
2 L 9.9.9.6:2 172.16.2.0/24 9.9.9.6 ether2 16 16
3 L 9.9.9.7:2 172.16.3.0/24 9.9.9.7 ether2 16 16
4 L 9.9.9.1:1 172.16.1.0/24 ether3 17
5 L 9.9.9.1:2 172.16.1.0/24 ether5 16
показує, що для організації правильної маршрутизації пакетів замовника A

(route-distinguisher = 9.9.9.6:1) убік мережі 172.16.2.0/24 їм призначена мітка
17. Цю мітку можна побачити на всіх трьох рисунках. Для транспорту
пакетів від A1 до A2 використовується мітка 16. Цю мітку можна побачити
на рис. 20.3. і 20.4. Таблиця пробросів MPLS на PE1 показує, що пакети з
міткою 17 будуть спрямовані на адресу 1.1.1.1 маршрутизатора P1:

4 L 19 16 9.9.9.6/32 ether1 1.1.1.1
310
16 отримують вихідну мітку 16 та будуть направлені на адресу 2.2.2.2
маршрутизатора P2. Цю мітку можно побачити на рис. 20.4.

1 L 16 16 9.9.9.6/32 ether2 2.2.2.2
Таблиця VPNv4 маршрутів на граничному маршрутизаторі PE2
[admin@PE1] > routing bgp vpnv4-route print detail

Flags: L - label-present
4 L route-distinguisher=9.9.9.6:1 dst-address=172.16.2.0/24 interface=ether3
in-label=17 bgp-ext-communities="RT:6:1"
та таблиця пробросів MPLS

# IN-LABEL OUT-LABELS DESTINATION
2 17 172.16.2.0/24@A
показує, що пакети з міткою 17 попадуть в мережу 172.16.2.0/24 через

інтерфейс ether3. Це означає, що вони попадуть на комп’ютер A2.
2. MPLS VPN 3-го рівня з організацією LSP за допомогою RSVP
Видаліть підтримку протоколу LDP для всіх маршрутизаторів

провайдера

Для всіх LSR-маршрутизаторів застосуйте в налаштуванні протоколу

OSPF підтримку CSPF
routing ospf instance set 0 mpls-te-area=backbone mpls-te-router-id=lobridge
Вкажіть, що всі інтерфейси граничних маршрутизаторів, які направлені

вбік мережі провайдера, будуть брати участь в роботі RSVP TE та заявіть
311
пропускні здатності. Наприклад, інтерфейс ether1 граничного
маршрутизатора PE1 йде вбік MPLS-хмари:
[admin@PE1]>mpls traffic-eng inter add interface=ether1 bandwidth=100000
Аналогічним чином налаштуйте усі інтерфейси маршрутизаторів, що

знаходяться в MPLS-мережі.
На граничних маршрутизаторах для майбутніх RSVP TE-тунелей
визначте динамичний шлях dyn за допомогою протоколу CSPF:
mpls traffic-eng tunnel-path add use-cspf=yes name=dyn
Створіть RSVP TE-тунелі, формуючи повнозв’язну топологію для

граничних маршрутизаторів:

to-address=9.9.9.6 bandwidth=100000 primary-path=dyn \
disabled=no record-route=yes name = 3to2

пінг з сайта A1 в бік сайта A2:
[admin@ A1]> ping 172.16.2.2
За допомогою аналізатора пакетів Wireshark проаналізуйте структуру

ICMP-пакетів на інтерфесах e0 маршрутизатора PE1, e1 маршрутизатора P1
та e1 маршрутизатора P2 (рис 20.6 – 20.8).
312
Пояснемо отримане. Таблиця VPNv4-маршрутів на граничному
маршрутизаторі PE1
[admin@PE1] > routing bgp vpnv4-route print
# ROUTE-DISTINGUISHER DST-ADDRESS GATEWAY INTERFACE IN-LABEL OUT-LABEL
0 L 9.9.9.6:1 172.16.2.0/24 9.9.9.6 ether2 16 16
2 L 9.9.9.6:2 172.16.2.0/24 9.9.9.6 ether2 17 17
показує, що для организації правильної маршрутизації пакетів замовника A
(route-distinguisher = 9.9.9.6:1) вбік мережі 172.16.2.0/24 їм призначена
мітка 16. Цю мітку можна побачити на всіх трьох рисунках. Для транспорту
пакетів від A1 до A2 використовується мітка 16. Цю мітку можна побачити
на рис. 20.6 і на рис. 20.7.

16 отримують таку ж вихідну мітку та будуть направлені на адресу 2.2.2.2

0 expl-null
1 T 16 16 9.9.9.1:1->9.9.9.6:1 ether2 2.2.2.2
2 T 17 expl-null 9.9.9.6:1->9.9.9.1:1 ether1 1.1.1.2
Таблиця пробросів MPLS на P2 показує, що пакет з вхідною міткою 16
отримують вихідну мітку 0 та будуть направлені на адресу 3.3.3.2
313
0 expl-null
1 T 16 expl-null 9.9.9.1:1->9.9.9.6:1 ether2 3.3.3.2
2 T 17 17 9.9.9.6:1->9.9.9.1:1 ether1 2.2.2.1
Таблиця VPNv4 маршрутів на граничному маршрутизаторі PE2

[admin@PE2] > routing bgp vpnv4-route print detail
та таблиця пробросів MPLS

0 expl-null
1 16 172.16.2.0/24@A
2 17 172.16.2.0/24@B
показують, що пакети з міткою 16 потрапляють в мережу 172.16.2.0/24 через
інтерфейс ether3. Це означає, що вони попадуть на комп’ютер A2, а пакети з
міткою 17 попадуть в мережу 172.16.2.0/24 через інтерфейс ether5, тобто на
комп’ютер В2.
На рис. 20.9 – 20.11 наведено структури ICMP-пакетів на інтерфесах e0
маршрутизатора PE1, e1 маршрутизатора P1 та e1 маршрутизатора P2 при
виконанні команди
[admin@B1]> ping 172.16.2.2
Рисунок 20.9 – Структура ICMP-пакета на інтерфейсі e0 маршрутизатора PE1.
314
Як видно з рис. 20.9 – 20.11, структура пакетів відрізняється тільки
внутрішньою міткою (=17) для правильної маршрутизації трафіку між
вузлами В1 та В2.
1. Для чого використовується технологія MPLS L3VPN?

2. Що таке VRF та для чого вона використовується?
3. Яку опцію необхідно застосувати в налаштуванні BPG для підтримки
VRF?
4. Для чого використовується route-distinguisher?
5. Як організується MPLS L3VPN з LSP на основі LDP?
6. Як організується MPLS L3VPN з LSP на основі RSVP?


315
ДОДАТКОВІ ФУНКЦІЇ МАРШРУТИЗАТОРІВ. СКРИПТИ
Ознайомлення з додатковими функціями маршрутизаторів. Набуття

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

Mikrotik автоматизувати деякі завдання з обслуговування маршрутизаторів за
допомогою виконання скриптів, визначених користувачем та обмежених
певними подіями та умовами.
Сценарії можуть зберігатися в сховищі сценаріїв. Також їх можна
писати та виконувати безпосередньо в консолі. Події, які використовуються
для запуску сценаріїв, можуть створюватися:
• системним планувальником задач;
• інструментами моніторингу трафіку та подій;
• інструментами Netwatch та ін.
Скрипти (сценарії) RouterOS поділені командними рядками. Кожен
командний рядок виконуються один за одним до кінця скрипту або до
виникнення помилки виконання.
Використання змінних у скриптах
У Mikrotik Router OS є два типи змінних:

• глобальні (global) – досяжні з усіх існуючих сценаріїв
користувачів;
316
• локальні (local) – досяжні лише у межах поточної області, яка
визначається місцевими ключовими словами.
Приклад:
Створимо локальну змінну у Mikrotik RouterOS:

:local localVar;
У данному прикладі local – тип змінної, localVar – її назва

Тепер створимо глобальну змінну:
:global globalVar;
В данному прикладі global – тип змінної, globalVar – її назва.

Змінні створені, проте вони не мають значення, вони порожні. Для того
щоб у цьому переконатися, виведемо їх значення на екран.
За допомогою команди :put та оператора повернення значення змінної $:
:put $globalVar;
в термінал повинен вивестися порожній рядок.

Якщо написати аналогічний вираз для локальної змінної, то виникне
помилка, адже її вже немає у даному командному рядку:
:put $localVar;
Локальні змінні можна використовувати лише у місці їх визначення

(командному рядку або командному блоці). Для виведення на екран значення
локальної змінної скористаємося наступним кодом:
:local $localVar; :put $var;
На екрані з’явився порожній рядок.

Для того щоб скористатися змінною, їй треба задати певне значення. У
середовищі RouterOS значення може бути текстовим або чисельним.
Розглянемо це твердження на простому прикладі, створивши дві змінні з
різними типами даних:
:global digit "321";
:global line "simple line";
317
Побачте, що створення змінних проходить так само, як і у прикладі
вище, проте з однією відмінністю – у лапках вказується потрібне значення.
Для змінної $digit було задано значення 321, а для $line – ‘simple line’.
Завдяки тому, що створені змінні глобальні, їх значення можна вивести
у термінал у будь-який момент після створення:
:put $digit;
:put $line;
На екрані у терміналі з’являється для кожної змінної відповідно її

значення – 321 та simple line.
Використання циклів у скриптах
Цикл do… while можна використати двома способами: з попередньою

перевіркою умови та з перевіркою після виконання його тіла. Синтаксис
циклу з передумовою передбачає, що дія виконується лише тоді, коли задана
умова викнується. Таким чином тіло може взагалі жодного разу не
виконатися.
Приклад:
:local a 1; while ($a!=10) do={:set a (a+1); };
($a!=10) – перевірка умови: змінна а не має дорівнювати 10. Якщо а не

дорівнює 10, то виконується дія set a (a+1);.
Синтаксис циклу з післяумовою передбачає, що спочатку виконується
дія set a (a+1); а лише потім перевіряється умова, через що тіло циклу
виконується хоча б один раз завжди:
:local a 1; :do {:set a (a+1); } while=($a!=10);
Цикл з післяумовою спочатку виконає один раз дію (збільшить

значення змінної а), а лише потім перевірить виконання умови. Якщо
початкове значення а дорівнює 11, то умова виявиться невиконуваною, а
цикл стане нескінченним:
:local a 10; :do {:set a (a+1); :put $a;} while=($a!=10);
318
Нескінченний цикл також можна отримати, вказавши як умову true:
while (true) do={:put "work"; delay 2};
delay 2 – затримка виконання сценарію на час, що задається у секундах

цілим число (у даному випадку на 2 секунди).
Цикл for виконує команди впродовж певної кількості ітерацій
(повторень певної дії):
:for x from=0 to=20 do={:put $x;}
Можна скористатися необов’язковим параметром step (крок), який

задається наступним чином:
step=”Величина кроку”
:for x from=0 to=20 step=2 do={:put $x;}
Цикл foreach дозволяє виконувати певні команди для кожного

елемента списку. За допомогою foreach, наприклад, можна перебрати
елементи масиву для пошуку. Створимо масив mas, який складається з п’яти
елементів.
:global mas [:toarray "a1,a2,a3,a4,a5"];
Розглянемо стркутуру циклу foreach:

:foreach x in=$mas do={:put $x;};
Після ключового слова foreach необхідно створити змінну, яка буде

зберігати черговий елемент послідовності (наприклад, х). До неї на кожному
кроці записується поточне значення елемента колекції або масиву (in=$mas).
Далі з кожним елементом виконується дія (do={:put $x;}).
Використання вбудованих команд. Умовні оператори
Під час створення сценаріїв можна використовувати ті самі стандартні

команди, що й при налаштуванні маршрутизатора. Так, наприклад, можна
записувати результати виконання певних утиліт у змінні для подальшого
аналізу:
319
:local pingTotalCount [ping count=5 192.168.0.1]
У результаті виконання даної команди у змінну pingTotalCount буде

записана кількість разів успішного виконання утиліти ping. Таким чином,
можна перевіряти досяжність певної адреси, а якщо вона виявляється
недосяжною – виконувати певні дії. Для цього треба розглянути умовну
конструкцію if-else:
if ([/interface get ether1 disabled] = no) do={/interface disable

ether1}
У цьому прикладі виконується перевірка, чи ввімкнений інтерфейс

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

їх значень. Команди find, get, set. Коментарі
Одна з найбільш популярних задач при адмініструванні

маршрутизатора – налаштування та встановлення визначених полів для
потрібних параметрів. Автоматизація цих процесів дозволяє скоротити час та
зробити мережу, у якій працює роутер, більш динамічною, підвищивши її
реакцію на події, що виникають. У подібних ситуаціях спочатку необхідно
знайти потрібний розділ налаштувань, а також необхідний запис для
редагування, якщо конфігурація вже виконувалася раніше. Для цих задач
використовуються команди find, get, set (табл. 21.1).
320
Таблиця 21.1 – Використання find, get, set
Команда Синтаксис Опис з прикладом
find find <expression> Повертає список елементів, які задовольняють певний
вираз (певну умову)
:put [/interface find name~"ether"]
set set <id> Змінює значення обраного параметра (одночасно

<param>=<value> можна вибрати декілька параметрів). Є можливість
виконати зворотну операцію, використавши перед
параметром знак «!».
:local com "newRule"
/ip firewall mangle enable [find comment=$com];
get get <id> Повертає значення обраного параметра

<param>=<value> :put [/ip route get [find gateway=1.1.1.1]];
Найпопулярніший прийом, що використовується для пошуку, – робота

з коментарями. Коментарі можна додавати до усіх налаштувань у RouterOS.
Додаються вони так само, як і інші параметри (<param>=<value>
comment=<commentValue>, або за допомогою команди set:
/ip route add gateway=1.1.2.1 comment=”toPC”
/ip route set [find gateway=1.1.2.1] comment=”newComment”
Завдяки коментарям одразу вирішуються дві задачі: пояснюються певні

записи у списках та специфічні налаштування (наприклад, обмеження смуги
пропускання або встановлення певного маршруту за замовчуванням), а також
з’являється можливість задати для певного запису у системі зрозумілий
людині ідентифікатор у вигляді рядка, за яким у подальшому можна буде
здійснювати пошук. Наприклад, для динамічної зміни маршруту можна
використати наступний код:
/ip route add gateway=1.1.2.1 comment=”toPC”

/ip route set [find comment="toPC"] gateway=1.1.3.2
321
Робота з рядками
При розробці сценаріїв для RouterOS дуже часто необхідно працювати

зі змінними, наведеними у вигляді рядків. Їх можна створити за допомогою
літерала (константи), або отримати у результаті виконання певної команди.
Якщо необхідно працювати з результатами виконання певних команд,
то можна використати функцію tostr. Вона повертає рядкове зображення
певного об’єкта. Окрім цього для роботи з рядками використовуються
функції, наведені в табл. 21.2.
Таблиця 21.2 – Робота з рядками
Команда Синтаксис Опис з прикладом
len :len <expression> Повертає довжину рядка або кількість елементів
колекції
:put [:len "length=8"];
pick :pick <var> Повертає певну кількість елементів колекції або
<start>[<end>] підрядок. Якщо кінцева позиція не задана, то буде
повернено лише один елемент з масиву:
:put [:pick "abcde" 1 3]
find :find <arg> <arg> Повертає позицію певного рядка у більшому рядку або
<start> положення елемента масиву:
:put [:find "abc" "a" -1];
parse :parse <expression> Перетворює рядок та повертає консольні команди, які
потім можна буде виконати:
:global myFunc [:parse ":put hello!"];
$myFunc;
“.” Поєднує два рядки (виконує конкатенацію):

:put ("concatenate" . " " . "string");
“,” Поєднує дві колекції або додає елементи до масиву:

:put ({1;2;3} , 5);
За допомогою наведених функцій можна, наприклад, оперувати

результатами виконання вбудованих команд. Таким чином, можна виконати
виокремлення значень певних параметрів. Нижче розглянемо приклад роботи
з датою та часом на маршрутизаторі (форматоване виведення у термінал):
:global curDate [/system clock get date]

:global day [:pick $curDate 4 6]
322
:global month [:pick $curDate 0 3]
:global year [:pick $curDate 7 11]
:log info "date format: $day $month $year"
:global fileName "/myfile_$year_$month_$day.txt"
:put $fileName;
Збереження скриптів у пам’яті. Створення задач у планувальнику

задач
Основний інтерес при написанні скриптів для RouterOS становлять не

одноразові скрипти, а ті, що можна зберегти у пам’яті та виконувати декілька
разів, наприклад, при виконанні певних подій або за розкладом.
Щоб зберегти скрипт, необхідно зайти у розділ /system script та за
допомогою команди add додати новий запис, вказавши параметри name та
source. Розглянемо декілька прикладів скриптів:
[admin@MikroTik]> system script add name=log-test source={:log info
message=test}
[admin@MikroTik]> system script print

Flags: I - invalid
0 name="log-test" owner="admin"
policy=ftp,reboot,read,write,policy,test,winbox,password,sniff,sensiti
ve,api
run-count=0 source=:log info message=test
[admin@MikroTik]> system script add name=e-backup source={
/system backup save name=email;
/tool e-mail send to="root@host.com" \
subject=([/system identity get name]."Backup") \
file=email.backup
}
Щоб створити задачу в планувальнику, необхідно перейти у розділ

/ system scheduler, додати елемент до списку за допомогою команди add, а
також вказати параметри interval, on-event, name, start-date та start-time
(останні два – необов’язкові). Розглянемо приклад з раніше створеними
скриптами:
[admin@MikroTik]> system scheduler add name=run-1m interval=1m on-
event=log-test
[admin@MikroTik]> system scheduler add interval=7d name="email-backup"
on-event=e-backup
323
Якщо після однієї хвилини переглянути інформацію про активні
завдання, то можна побачити, що перше завдання вже виконувалося 1 раз, а в
логах можна побачити відповідне повідомлення:
[admin@MikroTik]> system scheduler print
Flags: X - disabled
# NAME START-DATE START-TIME INTERVAL ON-EVENT RUN-COUNT
0 run-1m jan/14/2019 15:34:06 1m log-test 1
1 email-backup jan/14/2019 15:34:11 1w e-backup 0
[admin@MikroTik]> log print
...
15:34:06 system,info new script scheduled by admin
15:34:11 system,info new script scheduled by admin
15:35:06 script,info test
Створіть топологію, зображену на рис. 21.1. Налаштуйте ІР-адреси

відповідно до топології рис. 21.1. На кожному маршрутизаторі налаштуйте
динамічну маршрутизацію за протоколом RIP.
Рисунок 21.1 – Топологія для практичної частини
Налаштування FTP-сервера на роутері та на комп’ютері
Раніше розглядалися приклади сценаріїв, які виконують збереження

резервних копій налаштувань маршрутизатора. Проте існує два важливих
нюанси: по-перше, пам’ять роутера обмежена та її розмір досить невеликий.
По-друге, якщо зберігати бекапи на самому пристрої, то потрібно
передбачити періодичне очищення, або врахувати, що у разі певних проблем
324
або пошкоджень обладнання вони можуть бути втрачені. Саме тому
найкращий спосіб вирішити ці питання – відправляти бекапи на сторонній
FTP-сервер, де б вони зберігалися увесь необхідний час. FTP-сервер на
маршрутизаторі Mikrotik за замовчуванням вімкнений. Це можна подивитися
командою ip services print. Підключення з іншого пристрою буде
виконуватися за допомогою IP-адреси доступного інтерфейсу, а авторизація
– за допомогою стандартного логіна та пароля користувача системи.
Створення скриптів, що викликаються за певної події
Скрипти у RouterOS дозволяють автоматизувати велику кількість

процесів, пов’язаних з безпекою, резервним копіюванням, адаптацією
пристрою до змін у топології.
Щоб попередити можливі наслідки збоїв у роботі маршрутизатора,
необхідно з певною періодичністю виконувати резервне копіювання
конфігурації системи. Це дозволить у разі виникнення проблем швидко
відновити роботу з необхідними налаштуваннями. Для створення бекапу
використаємо команду
[admin@Mikrotik]> system backup save name="settingsFile"
Щоб не втратити резервні копії, їх краще за все відправляти за

допомогою FTP на сторонні роутери або на окремі серверу, де вони можуть
безпечно зберігатися та у разі необхідності допоможуть відновити
налаштування маршрутизатора. Для відправки файлу використовується
команда
[admin@Mikrotik] tool fetch address=1.1.4.2 src-
path="settingsFile.backup" \ user=admin mode=ftp password="" dst-
path="settingsFile.backup " upload=yes
Після її виконання раніше створений файл з бекапом буде відправлено

з маршрутизатора Mikrotik на маршрутизатор FTP_router. Далі, у разі
325
необхідності, цей файл може бути завантажений назад. Для прикладу
спочатку видалимо його з маршрутизатора Mikrotik, а потім завантажимо.
[admin@Mikrotik]> file remove [find name="settingsFile.backup"]
Перевіряємо, що файл видалено, а потім починаємо завантаження з

маршрутизатора FTP_router:
[admin@Mikrotik]> tool fetch address=1.1.4.2 \
src-path="settingsFile.backup" user=admin password=”” mode=ftp \
dst-path="settingsFile.backup" port=21 keep-result=yes
Для того щоб відновити конфігурацію з резервної копії використаємо
наступну команду:
[admin@Mikrotik] system backup load name="settingsFile"
Щоб автоматизувати цей процес, необхідно створити скрипт, а також

задачу у планувальнику з певним інтервалом. Для отримання можливості
зручного введення та редагування тексту, потрібно підключатися через
утиліту Winbox. Далі необхідно зайти у розділ System -> Scripts, натиснути +,
та ввести дані, які наведені на рис. 21.2. Потім треба обрати Apply та OK.
Рисунок 21.2 – Створення скрипту у Winbox
326
Далі створюємо задачу у планувальнику задач. Для цього переходимо у
розділ System -> Scheduler та натискаємо “+”, вводимо дані, наведені
на рис. 21.3 з коректним часом старту, який має бути пізнішим за поточний з
невеликим проміжком. Далі натискаємо Apply та OK. Треба пам’ятати, що
внутрішній час маршрутизатора може відрізнятися від часу системи, а отже
щоб задати коректний час старту завдання, необхідно дізнатися поточний час
маршрутизатора у розділі System -> Clock.
Рисунок 21.3 – Створення скрипту у Winbox
У результаті можна побачити, що на маршрутизаторі FTP_router файл з

резервною копією конфігурації маршрутизатора Mikrotik оновлюється
приблизно кожні 30 секунд відповідно до заданого інтервалу з урахуванням
часу, потрібного на передачу:
327
[admin@FTP_router] > file print
# NAME TYPE SIZE CREATION-TIME
0 skins directory jan/19/2019 09:35:27
1 um-before-migration.tar .tar file 15 360 jan/19/2019 09:38:49
2 settingsFile.backup backup 10 241 jan/19/2019 11:18:47
[admin@FTP_router] > file print
# NAME TYPE SIZE CREATION-TIME
0 skins directory jan/19/2019 09:35:27
1 um-before-migration.tar .tar file 15 360 jan/19/2019 09:38:49
2 settingsFile.backup backup 10 241 jan/19/2019 11:19:17
Створюємо сценарій backupIncrement, який буде відправляти на FTP-

сервер резервні копії з різними номерами, та створюємо задачу в
планувальнику задач. При цьому змінюємо формат дати, скориставшись
теоретичними відомостями, наведеними на початку лабораторної роботи:
:local curDate [/system clock get date]
:local day [:pick $curDate 4 6 ]
:local month [:pick $curDate 0 3 ]
:local year [:pick $curDate 7 11 ]
:local ds ($year."_".$month."_".$day)
:global counter
set counter ($counter + 1)
:global fileName ("bac$($counter)-".$ds)
sys back save name=$fileName;
:global fileNameBack ($fileName.".backup")
tool fetch address=1.1.4.2 src-path=$fileNameBack user=admin mode=ftp
Не треба забувати, що пам’ять маршрутизатора обмежена, тому одразу

після відправки резервної копії обом адресатам (FTP-маршрутизатору та
локальному FTP-серверу) необхідно видаляти непотрібний файл. У даному
випадку знадобиться оператор "~", за допомогою якого можна виконувати
пошук певного слова в рядках, наприклад, розширення файлу з повного
імені. Фактично, оператор "~" підтримує звичайні регулярні вирази
(наприклад, /ip route print where gateway~"^[0-9 \\.]*202\$"). Додаємо до
раніше створеного скрипту команду для видалення щойно створеного та
відправленого файлу з резервною копією конфігурації маршрутизатора:
file remove $fileNameBack
328
Якщо необхідно, пам’ять можна очищати, наприклад, 1 раз за 24
години, створивши нове завдання з наступною командою:
file remove [find name ~"bac]"
Виконавши цю команду, перевіряємо, що всі раніше створені резервні
копії були видалені.
Обмеження пропускної здатності за допомогою скриптів
Дуже часто перед мережними адміністраторами стоїть задача

обмежити полосу пропускання залежно від часу протягом дня. Так,
наприклад, вдень, кожен користувач хоче отримати доступ до Інтернету, а
тому треба полосу пропускання зменшити та зафіксувати для всіх, щоб
рівномірно її розподілити, а вночі, коли користувачів мало, – збільшити.
Скористуємося раніше розробленою топологією та напишемо скрипти для
роутера Mikrotik:
/queue simple add comment="FTP" direction=both disabled=no \
dst-address=1.1.4.2/32 max-limit=512000/512000 name="to_FTP_router" \
parent=none priority=8 queue=default-small/default-small
/queue simple add comment="MK2" direction=both disabled=no \
dst-address=1.1.2.2/32 max-limit=256000/256000 name="to_Mikrotik_2" \
/queue simple add comment="MK3" direction=both disabled=no \
dst-address=1.1.3.2/32 max-limit=256000/256000 name="to_Mikrotik_3" \
Сценарії для завдань можна розробляти безпосередньо при створенні

нових задач у планувальнику:
/system scheduler add comment="" disabled=no interval=1d name="Day" \
start-time=06:00:00 on-event={\
[/queue simple set [find comment=FTP] max-limit=512000/512000] \
[/queue simple set [find comment=MK2] max-limit=256000/256000] \
[/queue simple set [find comment=MK3] max-limit=256000/256000]}
/system scheduler add comment="" disabled=no interval=1d name="Night" \
start-time=18:00:00 on-event={\
[/queue simple set [find comment=FTP] max-limit=2048000/1048000] \
[/queue simple set [find comment=MK2] max-limit=1024000/1024000] \
[/queue simple set [find comment=MK3] max-limit=512000/512000]}
329
Таким чином, 1 раз на день будуть змінюватися обмеження. Зменшимо
інтервал до 30 секунд та продемонструємо зміну правил смуги пропускання
та виконання тесту смуги пропускання.
Смугу пропускання також можна обмежувати і за інших умов,
наприклад, коли завантаження на одному з інтерфейсів перевищує певний
ліміт. Розглянемо приклад, у якому при досягненні швидкості завантаження
відмітки 512 kbps створюється обмеження:
:foreach i in=[/interface find] do={
/interface monitor-traffic $i once do={
:if ($"rx-bits-per-second" > 512000 ) do={
/queue simple add name=$i max-limit=256000/256000 \
interface=$i;
}
}
}
}
Застосуйте цей скрипт в планувальнику завдань та перевірте його

працездатність.
Динамічна зміна маршрутів
Досить часто при підключенні до мережі Інтернет можна

використовувати декілька провайдерів. При цьому виникає задача вибору
маршруту через відповідних провайдерів. Якщо немає зв’вязку через один з
провайдерів – виконується переключення на іншого. Розглянемо раніше
створену топологію та припустимо, що необхідно виконати передачу пакетів
від маршрутизатора Mikrotik до мережі Інтернет. При цьому підключення
виконується через маршрутизатори ISP1 та ISP2. Встановимо на
маршрутизаторі Mikrotik маршрут за замовчуванням (на провайдера ISP1):
ip route add gateway=1.1.2.2 comment="toInternet"
У даному випадку створюється маршрут за замовчуванням через

маршрутизатор з інтерфейсом 1.1.2.2 (ISP1) та коментарем «toInternet».
Коментар знадобиться нам у подальшому для пошуку. Тепер виконаємо
330
команду ping на маршрутизаторі Mikrotik до хоста 8.8.8.8. Він має пройти
успішно.
Вимкнемо маршрутизатор ISP1 (натиснемо на ньому правою кнопкою
миші та виберемо з контекстного меню Stop). Перевіремо досяжність хоста
8.8.8.8 за допомогою команди ping. Він має бути недосяжним, адже вимкнено
маршрутизатор, який мав інтерфейс з адресою 1.1.2.2 та який виступав
маршрутом за замовчуванням для Mikrotik. Змінимо маршрут за
замовчуванням на цьому маршрутизаторі за допомогою наступного скрипту:
ip route set [find comment="toInternet"] gateway=1.1.3.2
Тепер хост 8.8.8.8 має бути досяжним. Якщо вимкнути зараз

маршрутизатор ISP2, виконання команди ping зазнає невдачі. Навіть після
ввімкнення ISP1 хост 8.8.8.8 залишається недосяжним. Необхідно знову
змінити маршрут за замовчуванням. Для автоматизації цього процесу треба
скористатися вбудованою командою tools netwatch, вказавши адресу хоста,
можливість досягнення якого слід перевіряти з певною періодичністю
(вказуємо інтервал – 10 секунд та хост 8.8.8.8). При цьому необхідно вказати
скрипт, що буде виконуватися у разі коли потрібний хост стає доступним або
недоступним. Створюємо наступний скрипт, що у подальшому буде
використаний як downScript.
:global route [tostr [/ip ro get [find comment="toInternet"]]];
:global substr1 [:pick $route [find $route "gateway=" 0] 100];
:global substr2 [:pick $substr1 0 [find $substr1 ","]];
:global ind [find $substr2 "="];
:set ind ($ind+1);
:global gateway [pick $substr2 $ind 20];
:if ($gateway="1.1.3.2") do={
/ip ro set [find comment="toInternet"] gateway=1.1.2.2
} else={/ip ro set [find comment="toInternet"] gateway=1.1.3.2}
Блокування доступу до певних ресурсів за доменним ім’ям
Іноді виникає потреба заблокувати доступ до певного веб-сайту для

користувачів мережі. При цьому слід мати на увазі, що можна врахувати
певну адресу, однак якщо вона зміниться, доступ буде знову поновлено,
через те що DNS-сервери почнуть повертати нову адресу, для якої нема
331
заборони. Щоб вирішити цю проблему можна скористатися двома
очевидними шляхами. Перший передбачає створення проксі-сервера на
маршрутизаторі, який відділяє хости та мережу з забороненим ресурсом.
Другий варіант потребує створення спеціального сценарію. У даному
прикладі розглянуто блокування доступу веб-сайтів youtube та vk. Скрипт
постійно проглядає актуальні адреси за доменними іменами та додає нові до
свого кешованого списку restricted (заборонені). Спочатку необхідно змусити
роутер кешувати (зберігати для подальшого аналізу) усі DNS-запити:
/ip firewall nat add action=redirect chain=dstnat comment=DNS dst-port=53 \

protocol=tcp to-ports=53
/ip firewall nat add action=redirect chain=dstnat dst-port=53 protocol=udp
to-ports=53
Далі треба додати фільтр firewall’у:
/ip firewall filter add chain=forward dst-address-list=restricted action=drop
Тепер створіть скрипт, для якого треба буде створити завдання, яке
виконується кожні 30 секунд:
:foreach i in=[/ip dns cache find] do={
:local bNew "true";
:local cacheName [/ip dns cache all get $i name] ;
# :put $cacheName;
:if (([:find $cacheName "vk.com"] >= 0) || ([:find $cacheName
"youtube.com"] >= 0)) do={
:local tmpAddress [/ip dns cache get $i address] ;
# :put $tmpAddress;
# if address list is empty do not check
:if ( [/ip firewall address-list find list="restricted" ] = "") do={
:log info ("added entry: $[/ip dns cache get $i name] IP
$tmpAddress");
/ip firewall address-list add address=$tmpAddress list=restricted
comment=$cacheName;
} else={
:foreach j in=[/ip firewall address-list find list="restricted"]
do={
:if ( [/ip firewall address-list get $j address] =
$tmpAddress ) do={
:set bNew "false";
}
}
:if ( $bNew = "true" ) do={
:log info ("added entry: $[/ip dns cache get $i name] IP $tmpAddress");
/ip firewall address-list add address=$tmpAddress list=restricted
comment=$cacheName;
}
}
}
}
332
Розроблений сценарій переглядає кеш DNS-запитів та при знаходженні
записів про потрібні ресурси (vk.com та youtube.com) у разі їх відсутності
додає їх до забороненого списку раніше створеного фільтру. Для перевірки
роботи цього сценарію необхідно створити завдання для планувальника
задач та виконати спробу доступу до одного з зазначених ресурсів. Для цього
можна створити окремий роутер, що буде виступати DNS-сервером, та
прописати його у роутері Mikrotik. Призначивши роутерам ISP1 та ISP2 імена
youtube.com та vk.com, спробуйте до них відправити запити. Вони мають
бути недосяжними. Далі можна змінити адреси інтерфейсів убік
маршрутизатора Mikrotik перевірити їх досяжність, оновити інформацію у
DNS-сервері та перевірити, що маршрутизатори ISP1 та ISP2 стали
недосяжними. Продемонструйте список заборонених адрес у фільтрі
firewall’у.
1. Що являють собою скрипти у RouterOS? З чого вони складаються?

2. Які типи змінних існують у скриптах, що створюються для
обладнання Mikrotik? У чому особливості їх створення та використання?
3. Як призначити певне значення змінній? Як використати його у
сценаріях, наприклад, як вивести його на екран?
4. Які види циклів можна використовувати у RouterOS та який їх
синтаксис?
5. Як використати результат виконання певної команди при написанні
сценаріїв?
6. Де та як використовуються умовні оператори при написанні
скриптів?
7. Які існують функції у RouterOS для роботи з рядками?
9. Як виконати пошук певного елемента у списку налаштувань?
10. За допомогою яких команд та яким чином виконується
встановлення певних полів налаштувань та отримання їх значення?
333
11. Як створюються та використовуються коментарі при написанні
сценаріїв?
12. Що таке планувальник задач?
13. Як створити задачу в планувальнику та які параметри необхідно
при цьому вказати?
14. Як передати файл за допомогою FTP з маршрутизатора Mikrotik до
FTP-сервера або іншого роутера?
15. Як завантажити файл за допомогою FTP зі стороннього FTP-
сервера на маршрутизатор Mikrotik?


3. Демонстрацію усіх розроблених сценаріїв та задач у планувальнику,
а також результатів їх роботи (як одноразової, так і багаторазової, якщо це
передбачено планувальником).
334
ОСНОВИ МЕРЕЖНОГО ПРОГРАМУВАННЯ
Ознайомлення з базовими принципами мережного програмування.

Набуття практичних навичок створення програм, що реалізують обмін
інформацією через комп’ютерну мережу.
Взаємодія процесів через механізм поштових скриньок (MailSlot)
MailSlot – це файл, що перебуває в пам’яті, для доступу до якого

використовуються стандартні файлові функції Win32. Дані в Мailslot можуть
бути записані в будь-якій формі, але їх загальний розмір не може бути більше
64K. Поштові скриньки служать для симплексної передачі інформаційних
повідомлень між комп'ютерами усередині локальної мережі.
Поштові скриньки використовують протокол UDP, тобто вони є
дейтаграмними пакетами без підтвердження прийому. Можуть бути
надбудовами протоколів як IPX/SPX, так і TCP/IP.
На відміну від дискових файлів, файли MailSlot тимчасові. Коли всі
покажчики на MailSlot закриваються, MailSlot і всі дані, які він містить
видаляються. Є два види програм, що використовують дану можливість:
1. MailSlot-сервер.
2. MailSlot-клієнт.
MailSlot-cервер – процес, що створює й володіє MailSlot. Коли сервер
створює MailSlot, він одержує покажчик. Цей покажчик повинен
використовуватися, коли процес читає повідомлення від MailSlot. Тільки
процес, що створює MailSlot або одержує покажчик деяким іншим
механізмом, може прочитати дані з MailSlot. Всі MailSlot локальні усередині
процесу, що їх створює; процес не може створити дистанційний MailSlot.
335
MailSlot-клієнт – процес, що пише повідомлення в MailSlot. Будь-який
процес, що знає ім’я MailSlot може записати в нього інформацію.
Існує два способи передачі даних: симплексний і дуплексний.
Розглянемо симплексну передачу даних. Оскільки симплексна передача
даних – це передача даних тільки в одну сторону, то можна подати цю
архітектуру у вигляді, наведеному на рис. 22.1.
Клієнт Сервер
Файл поштової скриньки Поштова скринька
Відкриття скриньки Читання

Запис
Закриття скриньки
Рисунок 22.1 – Симплексна передача на основі Mailslot
Передача відбувається тільки в одну сторону й вона ненадійна й

некерована.
Розглянемо дуплексну передачу даних. Для дуплексної передачі даних
архітектура виглядає так, як зображено на рис. 22.2.
Поштова скринька Файл поштової скриньки
Читання Запис
Закриття
Файл поштової скриньки Поштова скринька
Запис
Читання
Закриття
Рисунок 22.2 – Дуплексна передача на основі Mailslot
336
Дуплексна передача даних повністю дублює симплексну передачу в
іншу сторону, тобто передача відбувається у дві сторони.
Система імен
Для створення поштових скриньок використовуються імена. При

створенні ім’я повинне бути задане у такій формі:
\\ім’я комп’ютера\mailslot\ім’я_пошт_скриньки
Як ім’я комп’ютера можуть використовуватися службові символи:
. – локальний станція, передача усередині однієї станції;
* – всі станції усередині сегмента станції відправника;
ім’я робочої групи або домену – передача виконується всіма робочими
групами або доменами;
власне ім’я станції – поштова скринька на відповідній станції.
Ім’я_пошт_скриньки – це допустиме ім’я файлу.
Приклад:
\\*\mailslot\ my_first_slot
\\.\mailslot\my_first_slot
\\VTP25a_1\mailslot\my_first_slot
Зверніть увагу на те, що тільки локально можна створювати поштову

скриньку. Використовувати можна будь-які поштові скриньки.
Створення поштової скриньки
// задамо ім’я
LPSTR nameSlot = "\\\\.\\mailslot\\my_slot";
// створення
hSlot = CreateMailSlot(nameSlot, 0, MAILSLOT_WAIT_FOREVER, NULL );
// перевірка помилки створення:
if (hSlot == INVALID_HANDLE_VALUE) return FALSE;
Функція CreateMailSlot – створення поштової скриньки; повертає
параметр handle поштової скриньки, по якому виконується читання та
закриття поштової скриньки.
337
Параметри функції CreateMailSlot:
nameSlot – ім’я поштової скриньки (обов’язкове);
0 – максимальний розмір повідомлення;
MAILSLOT_WAIT_FOREVER – режим очікування;
NULL – атрибут безпеки.
Після створення поштова скринька готова приймати дані. Створення
поштової скриньки виробляється тільки на стороні приймача, тобто ім’я
поштової скриньки повинне бути локальним.
Читання даних з поштової скриньки

while (TRUE)
{ UINT bytes = ReadFile(hSlot, rzBuf, sizeof(rzBuf), &rzcbBuf, NULL);
// обробка даних:
}
Функція ReadFile – читання поштової скриньки.
Параметри функції ReadFile:
hSlot – дескриптор поштової скриньки;
rzBuf – буфер, куди виконується запис;
sizeof(rzBuf) – розмір буфера;
rzcbBuf – адреса лічильника буфера.
В одній поштовій скриньці може бути кілька повідомлень з інших
станцій, ці повідомлення розділяються двома нулями.
Запис у поштову скриньку

LPSTR nameSlot = "\\\\VTP25a_1\\mailslot\\my_slot";
// відкриття файлу my_slot на станції VTP25a_1:
HANDLE hSlot = CreateFile(nameSlot,
GENERIC_WRITE, // режим запису
FILE_SHARE_REHD, // файл із розділеним читанням
NULL, // атрибут захисту
OPEN_EXISTING, // відкриття файлу
FILE_ATTRIBUTE_NORMAL, // параметри захисту
NULL);
// функція запису у файл:
WriteFile(hSlot, cBuff, dwLength, &dwScratht, NULL);
Після виконання цієї функції інформація відсилається на сервер.
338
Для роботи з поштовими скриньками визначено дві інформаційні
функції:
1) GetMailslotInfo – функція, що дозволяє, одержати кількість
повідомлень усередині поштової скриньки, розмір поточного повідомлення,
режим роботи поштової скриньки т.інш.
2) SetMailslotInfo – функція, що може змінювати тайм-аут.
Взаємодія процесів через механізм каналів (Pipes)
Канали дозволяють організувати передачу даних між локальними

процесами, а також між процесами, запущеними на різних робочих станціях
у мережі. Канали типу Pipe найбільш схожі на файли, тому вони досить
прості у використанні.
Через канал можна передавати дані тільки між двома процесами. Один
із процесів створює канал, інший відкриває його. Після цього обидва процеси
можуть передавати дані через канал в одну або обидві сторони,
використовуючи для цього функції, призначені для роботи з файлами, такі,
як ReadFile і WriteFile. Додатки можуть виконувати над каналами Pipe
синхронні або асинхронні операції, аналогічно тому, як це можна робити з
файлами. У випадку використання асинхронних операцій необхідно окремо
потурбуватися про організацію синхронізації.
Іменовані й анонімні канали
Існують два різновиди каналів Pipe: іменовані (Named Pipes) і анонімні

(Anonymous Pipes). Як видно з назви, іменованим каналам при створенні
привласнюється ім’я, що доступно для інших процесів. Знаючи ім’я якої-
небудь робочої станції в мережі, процес може одержати доступ до каналу,
створеному на цій робочій станції. Анонімні канали зазвичай
використовуються для організації передачі даних між батьківськими й
дочірніми процесами, запущеними на одній робочій станції.
Імена каналів
Імена каналів у загальному випадку мають такий вигляд:
339
\\Ім’ясервера\pipe\Ім’яканала
Якщо процес відкриває канал, створений на іншій робочій станції, він
повинен указати ім’я сервера. Якщо ж процес створює канал або відкриває
канал на своїй робочій станції, то замість ім’я вказується символ крапки:
\\.\pipe\Ім`яканала
У всякому разі процес може створити канал тільки на тій робочій
станції, де він запущений, тому при створенні каналу ім’я сервера ніколи не
вказується.
Реалізації каналів
У найпростішому випадку один серверний процес створює один канал

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

CreateNamedPipe. Прототип цієї функції такий:
HANDLE CreateNamedPipe(
LPCTSTR lpName, // адреса рядка ім’я каналу
DWORD dwOpenMode, // режим відкриття каналу
DWORD dwPipeMode, // режим роботи каналу
DWORD nMaxInstances, // максимальна кількість
// реалізацій каналу
DWORD nOutBufferSize, // розмір вихідного буфера в байтах
DWORD nInBufferSize, // розмір вхідного буфера в байтах
DWORD nDefaultTimeOut, // час очікування в мілісекундах
LPSECURITY_ATTRIBUTES lpSecurityAttributes); // адреса
// змінної для атрибутів захисту
340
Установлення з’єднання з каналом з боку сервера
Після того як серверний процес створив канал, він може перейти в

режим з’єднання із клієнтським процесом. З’єднання з боку сервера
виконується за допомогою функції ConnectNamedPipe.
Прототип функції ConnectNamedPipe такий:
BOOL ConnectNamedPipe(
HANDLE hNamedPipe, // ідентифікатор іменованого каналу
LPOVERLAPPED lpOverlapped); // адреса структури OVERLAPPED
Установлення з’єднання з каналом з боку клієнта
Для створення каналу клієнтський процес може скористатися функцією

CreateFile.
Відключення серверного процесу від клієнтського процесу
Якщо сервер працює з декількома клієнтськими процесами, то він може

використовувати для цього кілька реалізацій каналу, причому ті самі
реалізації можуть застосовуватися по черзі. Установивши канал із
клієнтським процесом за допомогою функції ConnectNamedPipe, серверний
процес може потім розірвати канал, викликавши для цього функцію
DisconnectNamedPipe. Після цього реалізація каналу може бути знову
використана для з’єднання з іншим клієнтським процесом. Прототип функції
DisconnectNamedPipe такий:
BOOL DisconnectNamedPipe(HANDLE hNamedPipe);
Закриття ідентифікатора каналу
Якщо канал більше не потрібний, то після відключення від

клієнтського процесу серверний і клієнтський процеси повинні закрити його
ідентифікатор функцією CloseHandle:
CloseHandle(hNamedPipe);
Запис даних у канал
Запис даних у відкритий канал виконується за допомогою функції

WriteFile, аналогічно запису у звичайний файл.
341
Читання даних з каналу
Для читання даних з каналу використовується функція ReadFile.
Функція CallNamedPipe
Звичайно сценарій взаємодії клієнтського процесу із серверним полягає
у виконанні наступних операцій:
1) підключення до каналу за допомогою функції CreateFile;
2) виконання операції читання або запису функціями ReadFile або
WriteFile;
3) відключення від канала функцією CloseHandle.
Функція CallNamedPipe дозволяє виконати ці операції за один прийом,
за умови, що канал відкритий у режимі передачі повідомлень і що клієнт
посилає одне повідомлення серверу й у відповідь також одержує від сервера
одне повідомлення.
BOOL CallNamedPipe(
LPCTSTR lpNamedPipeName, // адреса ім’я каналу
LPVOID lpOutBuffer, // адреса буфера для запису
DWORD nOutBufferSize, // розмір буфера для запису
LPVOID lpInBuffer, // адреса буфера для читання
DWORD nInBufferSize, // розмір буфера для читання
LPDWORD lpBytesRead, // адреса змінної для запису
// кількості прочитаних байт даних
DWORD nTimeOut); // час очікування в мілісекундах
Функція TransactNamedPipe
Функція TransactNamedPipe, так само як і функція CallNamedPipe,
призначена для виконання передачі й прийому даних від клієнтського
процесу серверному. Однак ця функція більше гнучка у використанні, ніж
функція CallNamedPipe. Насамперед, перед використанням функції
TransactNamedPipe клієнтський процес повинен відкрити канал із сервером
функцією CreateFile. Крім того, клієнтський процес може виконувати обмін
даними із сервером, викликаючи функцію TransactNamedPipe багато разів.
При цьому не буде відбуватися багаторазового відкриття й закриття каналу.
BOOL TransactNamedPipe(
HANDLE hNamedPipe, // ідентифікатор каналу Pipe
LPVOID lpvWriteBuf, // адреса буфера для запису
DWORD cbWriteBuf, // розмір буфера для запису
342
LPVOID lpvReadBuf, // адреса буфера для читання
DWORD cbReadBuf, // розмір буфера для читання
LPDWORD lpcbRead, // адреса змінної, у яку буде
// записана кількість дійсна прочитаних байт
LPOVERLAPPED lpov); // адреса структури типу OVERLAPPED
Функція PeekNamedPipe
Читання даних з каналу функцією ReadFile викликає видалення
прочитаних даних. На противагу цьому, функція PeekNamedPipe дозволяє
одержати дані з іменованого або анонімного каналу без видалення, а отже
при наступних викликах цієї функції або функції ReadFile будуть отримані
всі ті самі дані, що й при першому виклику функції PeekNamedPipe. Ще одна
відмінність полягає в тому, що функція PeekNamedPipe ніколи не переходить
у стан очікування, відразу повертаючи керування незалежно від того, чи є
дані в каналі чи ні.
BOOL PeekNamedPipe(
HANDLE hPipe, // ідентифікатор каналу Pipe
LPVOID lpvBuffer, // адреса буфера для прочитаних даних
DWORD cbBuffer, // розмір буфера прочитаних даних
LPDWORD lpcbRead, // адреса змінної, у яку буде
// записана дійсна кількість
// прочитаних байт даних
LPDWORD lpcbAvail, // адреса змінної, у яку буде
// записане загальна кількість байт даних,
// доступних у каналі для читання
LPDWORD lpcbMessage); // адреса змінної, у яку буде
// записана кількість непрочитаних
// байт у даному повідомленні
Функція WaitNamedPipe
За допомогою функції WaitNamedPipe процес може виконувати
очікування моменту, коли канал Pipe буде доступний для з’єднання:
BOOL WaitNamedPipe(
LPCTSTR lpszPipeName, // адреса ім'я каналу Pipe
DWORD dwTimeout); // час очікування в мілісекундах
Функція SetNamedPipeHandleState
При необхідності ви можете змінити режими роботи для вже
створеного каналу Pipe. Для цього призначена функція
SetNamedPipeHandleState:
BOOL SetNamedPipeHandleState(
343
HANDLE hNamedPipe, // ідентифікатор каналу Pipe
LPDWORD lpdwMode, // адреса змінної, у якій зазначений
// новий режим каналу
LPDWORD lpcbMaxCollect, // адреса змінної, у якій
// вказується максимальний розмір
// пакета, переданого в канал
LPDWORD lpdwCollectDataTimeout); // адреса максимальної
// затримки перед передачею даних
Функція GetNamedPipeHandleState
За допомогою функції GetNamedPipeHandleState процес може
визначити стан каналу Pipe, знаючи його ідентифікатор:
BOOL GetNamedPipeHandleState(
HANDLE hNamedPipe, // ідентифікатор іменованого каналу
LPDWORD lpState, // адреса прапорів стану каналу
LPDWORD lpCurInstances, // адреса кількості реалізацій
LPDWORD lpMaxCollectionCount, // адреса розміру пакета
// переданих даних
LPDWORD lpCollectDataTimeout, // адреса максимального
// часу очікування
LPTSTR lpUserName, // адреса – ім’я користувача
// клієнтського процесу
DWORD nMaxUserNameSize); // розмір буфера для
// ім'я користувача клієнтського процесу
Функція GetNamedPipeInfo
Функція дозволяє одержати інформацію про іменований канал за його
ідентифікатором:
BOOL GetNamedPipeInfo(
HANDLE hNamedPipe, // ідентифікатор каналу
LPDWORD lpFlags, // адреса прапорів типу каналу
LPDWORD lpOutBufferSize, // адреса розміру вихідного буфера
LPDWORD lpInBufferSize, // адреса розміру вхідного буфера
LPDWORD lpMaxInstances); // адреса максимальної кількості
// реалізацій каналу
Взаємодія процесів через механізм сокетів (Socket)
У локальних і глобальних мережах існує два принципово різних

способи передачі даних. Перший з них припускає посилання пакетів даних
від одного вузла іншому (або відразу декільком вузлам) без одержання
підтвердження про доставку й навіть без гарантії того, що передані пакети
будуть отримані в правильній послідовності. Прикладом такого протоколу
344
може служити протокол UDP (User Datagram Protocol ), що використовується
в мережах TCP/IP, або протокол IPX, що є базовим у мережах Novell
NetWare. Основні переваги дейтаграмних протоколів полягають у високій
швидкодії й можливості широкомовної передачі даних, коли один вузол
відправляє повідомлення, а інші їх одержують, причому усі одночасно.
Другий спосіб передачі даних припускає створення каналу передачі
даних між двома різними вузлами мережі. При цьому канал створюється
засобами дейтаграмних протоколів, однак доставка пакетів у каналі є
гарантованою. Прикладами протоколів, що використовують канали зв’язку,
можуть служити протоколи TCP і SPX (протокол NETBIOS допускає
передачу даних з використанням як дейтаграм, так і каналів зв’язку).
Для передачі даних з використанням кожного з перерахованих вище
способів кожний додаток повинен створити об’єкт, що називається сокетом.
За своїм призначенням сокет найбільш схожий на ідентифікатор файлу
(file handle), що потрібний для виконання над файлом операцій читання або
запису. Перш ніж додаток, запущений на вузлі мережі зможе виконувати
передачу або прийом даних, він повинен створити сокет і ініціалізувати його,
указавши деякі параметри.
Для сокета необхідно вказати три параметри. Це IP-адреса, пов’язана із
сокетом, номер порту, для якого будуть виконуватися операції передачі
даних, а також тип сокета. Існують сокети двох типів. Перший тип
призначений для передачі даних у вигляді дейтаграм, другий – з
використанням каналів зв’язку.
У процесі ініціалізації додаток повинен зареєструвати себе в бібліотеці
WSOCK.
Для ініціалізації необхідно викликати функцію WSAStartup:
int WSAStartup (WORD wVersionRequested, LPWSADATA lpWSAData);
Перед тим як завершити свою роботу, додаток повинен звільнити
ресурси, отримані з операційної системи для роботи з Sockets. Для виконання
цього завдання додаток повинен викликати функцію WSACleanup:
int WSACleanup (void);
345
Створення й ініціалізація сокета
Після ініціалізації інтерфейсу Windows Sockets додаток повинен
створити один або декілька сокетів, які будуть використані для передачі
даних.
Сокет створюється за допомогою функції socket, що має наступний
прототип:
SOCKET socket (int af, int type, int protocol);
Видалення сокета
Для звільнення ресурсів додаток повинен закривати сокети, які йому
більше не потрібні, викликаючи функцію closesocket:
int closesocket (SOCKET sock);
Параметри сокета
Перед використанням необхідно задати параметри сокета. Для цього ви
повинні підготувати структуру типу sockaddr. Для роботи з адресами у
форматі Internet використовується інший варіант цієї структури, у якому
деталізується формат поля sa_data:
struct sockaddr_in
При ініціалізації сокета в цій структурі необхідно вказати адресу IP, з
якою буде працювати даний сокет. Якщо сокет буде працювати з будь-якою
адресою (наприклад, ви створюєте сервер, що буде доступний з вузлів з будь-
якою адресою), то адресу для сокета можна вказати в такий спосіб:
srv_address.sin_addr.s_addr = INADDR_ANY;
У тому випадку, якщо сокет буде працювати з певною адресою IP
(наприклад, ви створюєте додаток-клієнт, що буде звертатися до сервера з
конкретною адресою IP), у зазначену структуру необхідно записати реальну
адресу.
Дейтаграмний протокол UDP дозволяє посилати пакети даних
одночасно всім станціям у широкомовному режимі. Для цього ви повинні
вказати адресу як INADDR_BROADCAST.
Якщо відома адреса у вигляді чотирьох десяткових чисел, розділених
крапкою (саме так його вводить користувач), то ви можете заповнити поле
адреси за допомогою функції inet_addr:
dest_sin.sin_addr .s_addr = inet_addr ("200.200.200.201");
346
Однак найчастіше користувач працює з доменними іменами,
використовуючи сервер DNS або файл HOSTS. У цьому випадку спочатку
необхідно скористатися функцією gethostbyname, що повертає адресу IP, а
потім записати отриману адресу в структуру sin_addr.
Прив’язка адреси до сокета

Після підготуваня структури SOCKADDR, записавши в неї параметри
сокета (зокрема, адресу), варто виконати прив’язку адреси до сокета за
допомогою функції bind:
int bind (SOCKET sock, const struct sockaddr FAR * addr, int namelen);
Створення каналу зв'язку

Якщо передача буде виконуватися дейтаграмним засобом за
допомогою протоколу негарантованої доставки UDP, то канал зв’язку
непотрібний. Відразу після створення сокетів і їхньої ініціалізації можна
приступати до передачі даних. Але для передачі даних з використанням
протоколу TCP необхідно створити канал зв’язку.
Сторона сервера
Насамперед необхідно перемкнути сокет у режим прийому для
виконання очікування з’єднання із клієнтом за допомогою функції listen:
int listen(SOCKET sock, int backlog);
Далі необхідно виконати очікування з’єднання. Необхідно циклічно
викликати функцію accept доти, поки не буде встановлене з’єднання. Потім
можна буде приступати до обміну даними. Функція accept має наступний
прототип:
SOCKET accept (SOCKET sock, struct sockaddr * addr,
int FAR * addrlen);
Сторона клієнта
На стороні клієнта необхідно виконати з’єднання з сервером,
виконавши функцію connect:
int connect(SOCKET sock,struct sockaddr* addr, int namelen);
347
Передача й прийом даних
Після того як канал створений, можна починати передачу даних. Для
передачі даних за допомогою протоколу гарантованої доставки TCP
необхідно скористатися функціями send і recv, які входять у програмний
інтерфейс Windows Sockets.
int send (SOCKET sock, const char FAR* buf, int bufsize, int flags);
Параметри функції recv, призначеної для прийому даних, аналогічні
параметрам функції send :
int recv (SOCKET sock, char FAR * buf, int bufsize, int flags);
Якщо для зв’язку використовується UDP-протокол, то для передачі та
прийому необхідно скористатися функціями: sendto та recvfrom.
У загальному при реалізації сервера необхідно виконати такі дії:

1. Ініціалізувати бібліотеку Winsock (WSAStartup).
2. Створити сокет (socket).
3. Зв’язати сокет (bind).
4. Перемкнути сокет у режим прийому (listen).
5. Виконати очікування підключення (аccept).
6. Прийняти/відправити дані (recv/send).
7. Закрити сокет (closesocket).
Для реалізації клієнта:
1. Ініціалізувати бібліотеку Winsock (WSAStartup).
2. Створити сокет (socket).
3. З’єднати із сервером (сonnect).
4. Прийняти/відправити дані (recv/send).
5. Закрити сокет (closesocket).
1. Приклад передачі інформації за допомогою поштових скриньок (Visual

Studio C++)
348
Текст програми сервера
#include "stdafx.h"
#include <conio.h>
#include <stdio.h>
#include <windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
LPSTR nameSlot = TEXT("\\\\.\\mailslot\\my_slot");
HANDLE hSlot;
char rzBuf[1024];
DWORD rzcbBuf;
hSlot = CreateMailslot(nameSlot, 0, MAILSLOT_WAIT_FOREVER, NULL );
if (hSlot == INVALID_HANDLE_VALUE)
return FALSE;
while (TRUE)
{ UINT bytes = ReadFile(hSlot, rzBuf, sizeof(rzBuf)-1, &rzcbBuf, NULL);
// обробока данных:
if (!bytes) return -1;
printf("%s",rzBuf);
}
CloseHandle(hSlot);
_getch();
return 0;
}
Текст програми клієнта

#include "stdafx.h"
#include <stdio.h>
#include <conio.h>

{
LPSTR nameSlot = TEXT("\\\\*\\mailslot\\my_slot");
char cBuff[100];
DWORD dwByt;
HANDLE hSlot = CreateFile(nameSlot,
GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
if(!hSlot)
{
printf("Error!");
_getch();
return -1;
}
strcpy(cBuff, "Hello!");
WriteFile(hSlot, cBuff, 20, &dwByt, NULL);
CloseHandle(hSlot);
_getch();
return 0;
}
349
Спочатку необхідно запустити сервер, а потім клієнт. У результаті
виконання програм на стороні сервера буде виконано виведення
повідомлення «Hello!».
2. Приклад передачі інформації за допомогою іменованих каналів (Visual

Studio C++).

#include "stdafx.h"
#include <stdio.h>
#include <conio.h>
LPSTR lpszPipeName = "\\\\.\\pipe\\simple";
SECURITY_ATTRIBUTES sa;
PSECURITY_DESCRIPTOR pSD = NULL;
HANDLE hPipe = INVALID_HANDLE_VALUE;
OVERLAPPED os;
TCHAR szIn[80];
TCHAR szOut[80];
DWORD cbRead;
DWORD cbWritten;
BOOL bRet;
int main(int argc, char* argv[])
{
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = pSD;
sa.bInheritHandle = TRUE;
hPipe = CreateNamedPipe(lpszPipeName,
FILE_FLAG_OVERLAPPED | PIPE_ACCESS_DUPLEX,
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE |PIPE_WAIT, 1,
0, 0, 1000, &sa);
if (hPipe == INVALID_HANDLE_VALUE) {
printf("Failed to create named pipe");
return -1;
}
while ( 1 )
{
ConnectNamedPipe(hPipe, &os);
bRet = ReadFile(hPipe, szIn, sizeof(szIn),&cbRead,&os);
if(cbRead)
{
sprintf(szOut, "Hello from Server");
printf("Recived from client -> %s", szIn);
break;
}
}
bRet = WriteFile(hPipe,szOut,sizeof(szOut),&cbWritten,&os);
350
DisconnectNamedPipe(hPipe);
_getch();
return 0;
}

#include "stdafx.h"
#include <stdio.h>
#include <conio.h>
LPSTR lpszPipeName = "\\\\VTP\\pipe\\simple"; // Необхідно вказати ім’я
char outbuf[80];
char inbuf[80];
DWORD bytesRead;
int main(int argc, char* argv[])
{
sprintf(outbuf,"Hello from Client");

BOOL ret = CallNamedPipe(lpszPipeName,
outbuf, sizeof(outbuf),
inbuf, sizeof(inbuf),
&bytesRead, NMPWAIT_WAIT_FOREVER);
if (!ret) {
printf("client: CallNamedPipe failed, GetLastError = %d\n",
GetLastError());
getch();
exit(1);
}
printf("Received from Server-> %s \n", inbuf);
_getch();
return 0;
}
У результаті виконання програм сервер та клієнт обміняються
повідомленнями, які будуть виведені на екран.
3. Приклад передачі інформації за допомогою сокетів (Visual Studio C++)

#include "stdafx.h"
#include <winsock2.h>
#include <stdio.h>
#include <conio.h>
#pragma comment(lib, "Ws2_32.lib")
char szReq[60];
{
351
WORD sockVer;
WSADATA wsaData;
int retVal;
sockVer = MAKEWORD(2,2);
WSAStartup(sockVer, &wsaData);
//Создаем сокет
SOCKET servSock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
if(servSock == INVALID_SOCKET)
{
printf("Unable to create socket\n");
WSACleanup();
return SOCKET_ERROR;
}
SOCKADDR_IN sin;
sin.sin_family = PF_INET;
sin.sin_port = htons(11111);
sin.sin_addr.s_addr = INADDR_ANY;
retVal = bind(servSock, (LPSOCKADDR)&sin, sizeof(sin));

if(retVal == SOCKET_ERROR)
{
printf("Unable to bind\n");
WSACleanup();
}
retVal = listen(servSock, 10);

{
printf("Unable to listen\n");
WSACleanup();
}
SOCKET clientSock;
clientSock = accept(servSock, NULL, NULL);
if(clientSock == INVALID_SOCKET)
{
printf("Unable to accept\n");
WSACleanup();
}
retVal = recv(clientSock, szReq, 20, 0);
{
printf("Unable to recv\n");
}
352
printf("Got the request from client\n%s\n",szReq);
char *szResp = "Response";
printf("Sending response from server\n");

retVal = send(clientSock, szResp, strlen(szResp), 0);
{
printf("Unable to send\n");
}
closesocket(clientSock);
closesocket(servSock);
WSACleanup();
_getch();
return 0;
}
#include "stdafx.h"
#include <stdio.h>
#include <conio.h>
#include <winsock2.h>
#pragma comment(lib, "Ws2_32.lib")
char szResponse[20];
{
WORD ver = MAKEWORD(2,2);
WSADATA wsaData;
int retVal=0;
WSAStartup(ver,(LPWSADATA)&wsaData);
LPHOSTENT hostEnt;
hostEnt = gethostbyname("localhost");
if(!hostEnt)
{
printf("Unable to collect gethostbyname\n");
WSACleanup();
return 1;
}
SOCKET clientSock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
if(clientSock == SOCKET_ERROR)
{
353
printf("Unable to create socket\n");
WSACleanup();
return 1;
}
SOCKADDR_IN serverInfo;
serverInfo.sin_family = PF_INET;
serverInfo.sin_addr = *((LPIN_ADDR)*hostEnt->h_addr_list);
serverInfo.sin_port = htons(11111);
retVal=connect(clientSock,(LPSOCKADDR)&serverInfo, sizeof(serverInfo));
if(retVal==SOCKET_ERROR)
{
printf("Unable to connect\n");
WSACleanup();
return 1;
}
printf("Connection made sucessfully\n");
char *pBuf = "Request";
printf("Sending request from client\n");

retVal = send(clientSock, pBuf, strlen(pBuf), 0);
{
printf("Unable to send\n");
WSACleanup();
return 1;
}
retVal = recv(clientSock, szResponse, 9, 0);
{
printf("Unable to recv\n");
WSACleanup();
return 1;
}
printf("Got the response from server\n%s\n",szResponse);
closesocket(clientSock);
WSACleanup();
_getch();
return 0;
}
У результаті виконання програм сервер та клієнт обміняються

повідомленнями, які будуть виведені на екран.
354
1. Як реалізується передача даних через механізм поштових скриньок?

2. Які функції використовуються для створення клієнта та сервера за
механізмом поштових скриньок?
3. Як реалізується передача даних через механізм каналів?
4. Які існують типи каналів та в чому їх відмінність?
механізмом каналів?
6. Як реалізується передача даних через механізм сокетів?
механізмом сокетів?

Створити клієнт та сервер, що реалізують відповідну задачу за

допомогою відповідного механізму взаємодії процесів у мережі.
Задачі:
1. При натисканні клавіш на клавіатурі в одному додатку (клієнт)
інший додаток (сервер) повинен відображати натиснуті клавіші.
2. Передати файл, що розташований на робочій станції, на якій
виконується сервер, на робочу станцію, на якій виконується клієнт.
3. При переміщенні вікна клієнтського додатка сервер повинен
відображати координати лівого верхнього кута клієнтського додатка.
355
Варіанти завдань:
Варіант Задача Механізм Варіант Задача Механізм
1 1 MailSlot 7 2 Socket (UDP)
2 1 Pipe 8 2 Socket (TCP)
3 1 Socket (UDP) 9 3 MailSlot
4 1 Socket (TCP) 10 3 Pipe
5 2 MailSlot 11 3 Socket (UDP)
6 2 Pipe 12 3 Socket (TCP)

1. Тексти програм, що реалізують відповідну задачу.
2. Скріншоти результатів виконання програм.
356
СПИСОК ЛІТЕРАТУРИ
1. Опис операційної системи Mikrotik RouterOS // http://wiki.mikrotik.com,

02.07.16.
2. Хилл Б. Полный справочник по Cisco / Б. Хилл – М. : Вильямс, 2009. –
1088 с.
3. Олифер В. Г. Компьютерные сети. Принципы, технологии, протоколы.
5-е издание / В. Г. Олифер, Н. А. Олифер. – СПб. : Питер, 2016. – 992 с.
4. Гук М. Аппаратные средства локальных сетей. Энциклопедия / М. Гук.
– СПб. : Питер, 2005. – 576 с.
5. Таненбаум Э. Компьютерные сети: 5-е издание / Э. Таненбаум,
Д. Уэзеролл – СПб. : Питер, 2012. − 960 с.
6. Кравець В. О. Комп’ютені мережі. Діагностика комп’ютених мереж /
В. О. Кравець, Ю. М. Колибін, О. А. Серков та інш. – Харків : НТУ «ХПІ»,
2011. – 250 с.
7. Закер К. Компьютерные сети. Модернизация и поиск неисправностей /
К. Закер – СПб. : БХВ-Петербург, 2005. – 1008 с.
8. Кульгин М. Компьютерные сети. Практика построения: 2-е издание /
М. Кульгин – СПб. : Питер, 2003. – 461 с.
9. Калита Д. М. Комп’ютерні мережі. Апаратні засоби та протоколи передачі
даних / Д. М. Калита – Київ : «Київський університет», 2003. – 327 с.
10. Семенов Ю. А. Протоколы Интернет. Энциклопедия / Ю. А. Семенов –
М. : «Горячая линия-Телеком», 2005. – 1100 с.
357
Навчальне видання
МЕЗЕНЦЕВ Микола Вікторович

ЗАПОЛОВСЬКИЙ Микола Йосипович
ПАНЧЕНКО Володимир Іванович
КОМП’ЮТЕРНІ МЕРЕЖІ
Лабораторний практикум
для студентів денної та заочної форм навчання за спеціальністю
«Комп’ютерна інженерія»
Роботу до видання рекомендував В. Д. Дмитрієнко

Відповідальний за випуск С. Г. Семенов
Редактор Л. Л. Яковлева
План 2019 р., п. 114

Підп. до друку 19.06.2019 р. Формат 60 × 84 1 .
16 Папір офсет. № 2.
Друк – цифровий. Гарнітура Times New Roman. Ум.-друк. арк. 10,2
Зам. № 10/11 Наклад 50 прим. Ціна договірна.
Видавничий центр НТУ «ХПІ» 61002, Харків, вул. Кирпичова, 2.

Свідоцтво про державну реєстрацію ДК № 3478 від 21.08.2017 р.
Видавець та виготовлювач: ФОП Панов А.М.

Свідотство серії ДК №4847 від 06.02.2015 р.
м. Харків, вул. Жон Мироносиць, 10, оф. 6,
тел. +38(057)714-06-74, +38(050)976-32-87
copy@vlavke.com

Net Labs PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Net Labs PDF

Uploaded by

Copyright:

Available Formats

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

М. В. МЕЗЕНЦЕВ, М. Й. ЗАПОЛОВСЬКИЙ, В. І. ПАНЧЕНКО

Рецензенти: Г. Ф. Кривуля, д-р. техн. наук, професор, Харківський

О. О. Можаєв, д-р. техн. наук, професор, Харківський

Мезенцев М. В. Комп’ютерні мережі: лабораторний практикум /

Розглянуто використання технологій віртуалізації для практичної роботи з

Іл. 146. Табл. 29. Бібліогр. 10 назв.

GNS3 – це графічний симулятор, що дозволяє емулювати складні

ЗНАЙОМСТВО З СЕРЕДОВИЩЕМ GNS3. IP-АДРЕСАЦІЯ

1.1. Мета лабораторної роботи

Набуття практичних навичок у створенні простих топологій мереж у

1.2. Теоретична частина

Масштабована мережа вимагає застосування такої схеми адресації, яка

1.3. Практична частина

Останню версію GNS3 можна скачати з сайта http://www.gns3.net/ з

Рисунок 1.1 – Загальний вигляд програми GNS3

Рисунок 1.2 – Додавання елементів мережі

При додаванні кожного елемента можна дати йому ім’я та встановити

Рисунок 1.3 – Конфігурація пристрою РС1

Рисунок 1.5 – Зовнішній вигляд вікна VPCS

Утиліта VPCS підтримує емуляцію 9 хостів. Для переключення на

Як видно з рис. 1.6, для завдання ІР-адреси необхідно виконати

Lля VPCS1 IP-адреса 192.168.0.2 з маскою 255.255.255.0 задається

Таблиця 1.1 – ІР-адреси хостів

Якщо все зроблено правильно, то можна пропінгувати будь-який хост з

Рисунок 1.8 – Команда ping від хоста 4 до хоста 1

У VPCS для кожної команди можна отримати довідку про параметри

Рисунок 1.9 –Довідка про параметри команди ping

1.4. Контрольні питання

1. Для чого використовується GNS3?

1.5. Порядок виконання і здачі роботи

– Вивчити теоретичну і практичну частини.

1.6. Завдання для самостійної роботи

1. Створити топологію (рис. 1.10)

Рисунок 1.10 – Топологія для самостійного завдання

Таблиця 1.2 – Варіанти завдань

тут n – день народження студента; m – місяць народження студента.

1.7. Зміст звіту

Звіт готується в електронному вигляді і роздруковується. Звіт містить:

ОЗНАЙОМЛЕННЯ З МЕРЕЖНОЮ ОПЕРАЦІЙНОЮ СИСТЕМОЮ IOS

2.1. Мета лабораторної роботи

Набуття практичних навичок у конфігуруванні мережних пристроїв, що

2.2. Теоретична частина

При першому вході в мережний пристрій користувач бачить командний

Таблиця 2.1 – Show-команди

Cisco Discovery Protocol (CDP)

CDP дозволяє пристроям обмінюватися основною конфігураційною

Команди ping і traceroute

Для діагностики можливості встановлення зв’язку в мережах

Таблиця 2.2 – Результати команди ping

Протокол віртуального терміналу telnet, що входить до складу

2.3. Практична частина

Для поточного користувача GNS3 створює свій каталог, куди будуть

Рисунок 2.1 – Налаштування образу операційної системи IOS

Якщо все зроблено вірно, в списку роутерів повинен з’явитися Router

Сконфігуруйте роутери. Для цього для кожного роутера послідовно

NM-1E – 1 Ethernet порт (інтерфейс);

Оберіть пункт меню View\Show/Hide interface labels та виконайте

Робота з мережним пристроєм Cisco

Основні команди мережного пристрою

1. Увійдіть на мережному пристрої Router1 в режим користувача:

Перейдіть в призначений для користувача режим командою disable.

Постараємося зрозуміти, як включати (піднімати) інтерфейси