vnl

Министерство образования и науки, молодежи и спорта Украины
Днепропетровский национальный университет
им. Олеся Гончара
В.М. Григорьев
СЕТЕВЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ.
Лабораторный практикум и курсовое проектирование
Днепропетровск
2012
grigoryev.victor@gmail.com http://vmg.pp.ua
УДК 681.3.07
Г83
Григорьев, В.М. Сетевые информационные технологии [Текст]: Лабораторный
практикум и курсовое проектирование / В.М. Григорьев.─ Д.: ДНУ, 2012. – 241 с.
Рассмотрено использование технологий виртуализации для практической работы с
компьютерными сетями. Показано, что лаборатория для настройки компьютерных
сетей может быть создана с помощью виртуальных машин Qemu в оболочке GNS3
с использованием операционной системы RouterOS фирмы Mikrotik. Виртуальная
учебная лаборатория позволяет вместо реальной аппаратуры применять
соединенные между собой виртуальные машины, в которых запущены
операционные системы сетевых устройств.
Рассмотрены применения
предложенного подхода для практической работы со следующими сетевыми
технологиями: маршрутизация, беспроводные мосты, виртуальные частные сети
уровня 2 и 3 на основе EoIP, MPLS, IPsec, OpenVPN и производных от PPP
протоколов.
Для студентов специальности "Компьютерные системы и сети" ДНУ.
Утверждено Учёным советом факультета физики,
компьютерних систем, протокол № 19 от 10.09.2012 г.
электроники
и
Учебное издание
Виктор Михайлович Григорьев
. Сетевые информационные технологии. Лабораторный практикум и курсовое
проектирование
____________________________________________________________
Формат 60х84/16. Бумага типографская. Печать плоская. Тираж 100 экз.
____________________________________________________________
ДНУ, просп. Гагарина, 72, м. Днепропетровск, 49010.
© Григорьев В.М. 2012
2
grigoryev.victor@gmail.com http://vmg.pp.ua
Оглавление
Предисловие 7
1. Виртуальная лаборатория по компьютерным сетям
2. Работа с Mikrotik RouterOS в Qemu и GNS3
3. Настройка домашнего компьютера
4. Настройка типовой сети
5. Мосты. EoIP - Ethernet через IP . VPN уровня 2
6. Беспроводный мост
7. Маршрутизация
8. Балансировка нагрузки
9. Производные от PPP протоколы и OpenVPN
10. Построение VPN второго уровня c помощью
производных от PPP протоколов и OpenVPN
11. Построение VPN третьего уровня c помощью
производных от PPP протоколов и OpenVPN
12. PPPoE
13. IPsec VPN
14. MPLS
15. MPLS VPN уровня 2 и 3
16. VPN-клиенты Windows 7 для VPN-серверов Mikrotik
17. Курсовой проект
9
21
39
52
62
75
85
100
104
130
147
155
160
175
187
213
226
СОДЕРЖАНИЕ
Предисловие
1. Виртуальная лаборатория по компьютерным сетям
Выбор платформы виртуальной лаборатории
Удалённый доступ к Ubuntu
Место лаборатории в сети университета
Подключение к лаборатории с помощью протокола Openvpn
Подключение к лаборатории labs.mikrotik.com.ua из кафедры
Обмен файлами
Способы выполнения лабораторных работ и курсовой по сетям
2. Работа с Mikrotik RouterOS в Qemu и GNS3
Начальная подготовка Ubuntu
Установка и работа с операционной системы RouterOS
Установка и настройка GNS3
Первая топология
GNS автоматически генерирует команды для Qemu
Шаблон для топологий
Работа с RouterOS из командной строки
Импорт и экспорт топологий
3
7
9
9
13
15
17
20
19
21
21
21
26
28
31
32
35
36
grigoryev.victor@gmail.com http://vmg.pp.ua
О персональных компьютерах и свичах в топологиях
3. Настройка домашнего компьютера 13
Подключение с помощью протокола Openvpn
Работа c GNS3 в Windows
Удалённый доступ к Ubuntu
Установка Ubuntu
Установка Qemu
Установка GNS3
Установка tap-интерфейсов
Установка Winbox
Подключение из домашнего Ubuntu по Openvpn и удаленный доступ
Доступ к удалённому маршрутизатору из домашнего компьютера
4. Настройка типовой сети
DNS
DHCP
NAT
ARP
Фаервол (Firewall)
Ограничение скорости
Web-прокси
HotSpot
5. Мосты. EoIP - Ethernet через IP . VPN уровня 2
Мосты
EoIP
VPN уровня 2 через NAT
6. Беспроводный мост
Netinstall
7. Маршрутизация
Статическая маршрутизация
Маска /32
Динамическая маршрутизация
RIP
OSPF
Перераспределение маршрутов и BGP
8. Балансировка нагрузки
Монопольный канал
Равномерное распределение
9. Производные от PPP протоколы и OpenVPN
PPP
Протоколы PPTP, SSTP, L2TP, OpenVPN и PPPoE
Протоколы системных событий
Настройка PPP
Настройка PPTP
Настройка L2TP
RSA-сертификаты
4
37
39
39
40
41
42
44
46
46
47
48
49
52
55
56
58
59
60
61
61
64
66
66
69
73
75
83
85
85
89
91
92
95
96
100
100
103
104
104
106
108
108
111
113
114
grigoryev.victor@gmail.com http://vmg.pp.ua
Настройка SSTP
Настройка OpenVPN
Особенности работы из командной строки
10. Построение VPN второго уровня c помощью
производных от PPP протоколов и OpenVPN
1. Настройка с помошью Winbox
1.1 PPP
1.2 PPTP
1.3 L2TP
1.4 SSTP
1.5 OpenVPN
2. Настройка с помощью командной строки
2.1 PPP
2.2 PPTP
2.3 L2TP
2.4 SSTP
2.5 OpenVPN
Распределённый мост
Использование профилей пользователя
11. Построение VPN третьего уровня c помощью
производных от PPP протоколов и OpenVPN
Маршрутизация RIP
Маршрутизация OSPF
VPN уровня 3 через NAT
Протоколы GRE и IPIP
12. PPPoE
13. IPsec VPN
Состав IPsec
SA (Security Association)
Политики IPsec
Фазы IKE
`
Конфигурация IPsec в Mikrotik RouterOS
Шифрация соединения точка-точка
Организация VPN типа сайт-сайт с помощью IPsec
14. MPLS
LDP
Фильтрация меток
RSVP TE
15. MPLS VPN уровня 2 и 3
1. Организация MPLS VPN уровня 2 с помощью VPLS
1. Организация MPLS VPN уровня 2 с помощью VPLS
5
116
119
121
130
131
133
133
134
137
137
138
140
140
141
141
142
143
144
147
148
149
151
152
155
160
160
161
162
162
163
166
169
175
176
182
182
187
187
grigoryev.victor@gmail.com http://vmg.pp.ua
1.1. Настройка LDP VPLS
1.1.1. LDP VPLS с организацией LSP с помощью LDP
1.1.2. LDP VPLS с организацией LSP с помощью RSVP
1.2. Настройка BGP VPLS
1.2.1. Конфигурирование сессий BGP. Отражатель маршрутов
1.2.2. BGP VPLS с организацией LSP с помощью RSVP
1.2.3. BGP VPLS с организацией LSP с помощью LDP
2. MPLS VPN 3-го уровня
2.1 MPLS VPN 3-го уровня c организацией LSP с помощью LDP
2.2 MPLS VPN 3-го уровня c организацией LSP с помощью RSVP
16. VPN-клиенты Windows 7 для VPN-серверов Mikrotik
Соединение SSTP-клиента Windows7 с SSTP-сервером Mikrotik
Соединение L2TP IPsec-клиента Windows7 с L2TP -сервером Mikrotik
17. Курсовой проект
Постановка задачи
Пример выполнения
Быстрый старт
Требование к отчёту и порядок сдачи проекта
6
189
189
193
196
197
198
202
204
206
210
213
213
218
226
226
229
241
241
grigoryev.victor@gmail.com http://vmg.pp.ua
Предисловие
Издание охватывает некоторые разделы практической работы с
компьютерными сетями, работающих под управлением протоколов Ethernet и
TCP/IP. Все рассмотренные сетевые устройства изготовлены фирмой Mikrotik и
работают под управлением сетевой операционной системы RouterOS.
Показано, что лаборатория для настройки компьютерных сетей может быть
создана с помощью виртуальных машин Qemu в оболочке GNS3 с использованием
операционной системы RouterOS. Виртуальная лаборатория позволяет вместо
реальной аппаратуры применять соединенные между собой виртуальные машины,
в которых запущены операционные системы сетевых устройств.
Первый раздел посвящен детальному описанию виртуальной учебной лаборатория по компьютерным сетям. Виртуальные машины лаборатории работают под
управлением операционной системы Ubuntu Linux, которая, в свою очередь, работает в виртуальной машине Hyper-V в Windows. Показано место лаборатории в
сети университета.
Во втором разделе рассмотрена установка и работа с операционной системой
Routeros. Изучаются команды этой системы для налаживания компьютерной сети.
Показаны настройки оболочки GNS3.
Описание настройки домашнего компьютера приведены в третьем разделе.
Показано как подключиться к виртуальной учебной лаборатории в университете
через Интернет с помощью OpenVPN и клиента удаленного рабочего стола Ubuntu
фирмы Nomachine.
В четвертом разделе показана настройка типовой сети, которая включает в
себя конфигурацию протоколов DHCP, DNS, NAT, ARP, брандмауэра, ограничения
скорости, Веб-прокси и Hotspot.
В пятом разделе рассмотрены Ethernet-мосты. Освещено построение виртуальных частных сетей второго уровня на основе протокола EoIP (Ethernet over IP Ethernet через IP).
В шестой главе студенты строят беспроводной мост на реальной аппаратуре
фирмы Mikrotik - устройствах rb750 и rb751u-2hnd. Для организации беспроводного моста используется технология WDS (Wireless distributed system - беспроводная
распределенная система). Показано как переставить операционную систему маршрутизатора с помощью утилиты Netinstall.
Статической и динамической маршрутизации посвящен раздел семь. Рассмотреть протоколы маршрутизации RIP, OSPF и BGP. Уделено внимание адресам с
маской / 32.
В восьмой главе рассмотрены 2 варианта балансировки нагрузки: монопольный канал и равномерное распределение.
Разделы 9, 10 и 11 посвящены построение VPN второго и третьего уровня c
помощью производных от PPP протоколов и OpenVPN.
Конфигурация протокол PPPoE изучена в разделе 12.
В разделе 13 рассмотрено использование протокола IPsec для создания VPN
типа сайт-сайт.
Раздел 14 посвящен организации MPLS-сетей с помощью протоколов LDP и
RSVP
7
grigoryev.victor@gmail.com http://vmg.pp.ua
Раздел 15 посвящен настройке MPLS VPN второго и третьего уровня с помощью протоколов BGP, LDP и RSVP и технологий VPLS и VRF.
Соединения SSTP и L2TP IPsec клиентов Windows7 с SSTP и L2TP серверами
Mikrotik рассмотрены в разделе 16.
В итоговом 17 разделе приведен курсовой проект, служащий для закрепоения
знаний, изложенных в данной публикации.
Основой материала издания послужило содержимое сайта wiki.mikrotik.com
8
grigoryev.victor@gmail.com http://vmg.pp.ua
1. Виртуальная лаборатория по компьютерным сетям
Выбор платформы виртуальной лаборатории
Место лаборатории в сети университета
Подключение к лаборатории с помощью протокола Openvpn
Обмен файлами
Удалённый доступ к Ubuntu
Способы выполнения лабораторных работ и курсовой по сетям
9
13
16
18
18
19
Выбор платформы виртуальной лаборатории
Сетевые маршрутизаторы работают под управлением операционных систем. В
ряде случаев эти операционные системы можно запустить внутри виртуальных
машин. Сетевые устройства в сети соединены каналами связи. Для организации
виртуальной сетевой лаборатории надо соединить между собой виртуальные
машины, в которых запущены операционные системы сетевых устройств.
На лабораторном занятии в такой виртуальной лаборатории по компьютерным
сетям обычно присутствует десяток студентов, и каждый из них изучает сетевую
топологию, состоящую из нескольких сетевых устройств. Одновременно работают
десятки виртуальных машин. Возникает задача такого выбора операционной
системы сетевого устройства и виртуальной машины, чтобы обеспечить студентам
комфортную одновременную работу при условии ограниченности ресурсов хосткомпьютера.
Идея виртуальных сетевых лабораторий не нова, и для их реализации
существуют специализированные решения. Для моделирования устройств фирмы
Cisco, работающих под управлением операционной системы IOS, используются
программы Cisco Packet Tracer и Boson NetSim, имеющие удобный графический
интерфейс, позволяющий быстро создавать достаточно сложные сетевые
топологии. Однако встроенная в них урезанная версия IOS позволяет изучать лишь
сетевые технологии начального уровня.
Больший интерес представляет использование операционных систем реальных
сетевых устройств. Возникают следующие вопросы, касающиеся выбора
операционной системы устройства и виртуальной машины для запуска этой
операционной системы: сколько ресурсов хост-машины потребляет виртуальная
машина; каково время запуска операционной системы внутри виртуальной
машины; какие средства предоставляют виртуальные машины для соединения
между собой запущенных внутри них операционных систем и как быстро создать
сложную сетевую топологию из десятков устройств.
Для моделирования сетевых топологий широко используется контейнер
виртуальных машин GNS3. Для создания сетевых топологий в GNS3 используется
технология Drug-and-Drop: зацепил устройство мышью и перетащил его на рабочее
поле. GNS3 поддерживает три виртуальные машины: Dynamips, VirtualBox и
Qemu. Выбор именно этих машин для включения в GNS3 обусловлен наличием в
их составе развитых средств для соединения между собой операционных систем (в
VirtualBox - с помощью API).
9
grigoryev.victor@gmail.com http://vmg.pp.ua
Виртуальная машина Dynamips позволяет запустить внутри себя реальную
IOS для очень широкого класса устройств Cisco. Однако при работе с Dynamips
следует подбирать параметры для уменьшения нагрузки на центральный
процессор. Без должных настроек Dynamips использует все ресурсы компьютера
уже для топологии из трёх маршрутизаторов.
Под Qemu работает весьма широкий класс сетевых, встроенных и мобильных
операционных систем: Juniper JunOS, Vyatta, Openwrt, Google Android, Mikrotik
RouterOs, файерволы Cisco IDS, и др. Наш выбор был сделан в пользу Qemu в
составе GNN3. Под Qemu работает весьма широкий класс сетевых, встроенных и
мобильных операционных систем (ОС): Juniper JunOS, Vyatta, Openwrt, Google
Android, Mikrotik RouterOs, файерволы Cisco, и др. VirtualBox также поддерживает
множество ОС, но в составе GNN3 требует настройки отдельной виртуальной
машины для каждого устройства сетевой топологии. Qemu для всех устройств с
одинаковой ОС использует единые настройки.
Наш выбор был сделан в пользу Qemu в составе GNN3.
Нельзя не упомянуть виртуальную машину IOU для Cisco IOS. В ней можно
запустить пару операционных систем Cisco IOS с весьма мощной
функциональностью, и она не требует такой настройки, как
Dynamips. К
сожалению, IOU не обладает графическим интерфейсом.
Следовало определиться, в чём работать: в Windows или в Linux. GNS3 и
Qemu задуманы, сделаны и развиваются в Linux. Qemu под Linux поддерживает
аппаратную виртуализацию KVM. Qemu под Windows не поддерживает KVM и
при запуске нескольких экземпляров Qemu используется только одно ядро
центрального процессора, что существенно замедляет работу с большими
сетевыми топологиями.
Возникает вопрос выбора дистрибутива Linux. GNS3 написан на Python и
требует библиотеки Qt4. После ряда экспериментов с различными дистрибутивами
Linux по установке GNS3 из исходных кодов выбор пал на настольную версию
Ubuntu.
Определим операционную систему сетевого устройства для запуска под
Qemu. Если потребовать, чтобы устройство поддерживало сетевую технологию
MPLS, то выбор сразу сократится: это либо операционная система JunOS фирмы
Juniper, либо RouterOS фирмы Mikrotik.
По объёму потребляемых ресурсов JunOS существенно превосходит RouterOS.
Например, на компьютере с двуядерным процессором Intel Core2 6600 с частотой
2.4 ГГц время загрузки RouterOS версии 5.20 в Qemu под Ubuntu составляет
несколько секунд (см. ниже), а JunOS версии Olive12.1R1.9 грузится 75 секyнд.
RouterOS требует минимум 64 Мб памяти,
JunOS — 512 Мб. Образ диска
RouterOS - 60 Мб, JunOS - 600 Мб.
В Linux имеется программное решение KVM (Kernel-based Virtual Machine),
поддерживающее
аппаратную
виртуализацию
на
базе процессоров
Intel VT либо AMD SVM. Сам по себе KVM не выполняет эмуляции и
используется совместно с виртуальными машинами. Мы будем использовать KVM
без оптимизатора памяти ksmd.
10
grigoryev.victor@gmail.com http://vmg.pp.ua
Рассмотрим влияние KVM на время загрузки в Qemu в GNS3 нескольких
экземпляров RouterOS версии 5.20 с памятью 64 Мб на компьютере с двуядерным
процессором 2.4 ГГц и 4Гб памяти под управлением Ubuntu (табл. 1.1). Графики
зависимости времени загрузки от числа экземпляров RouterOS приведен ра рис.1.1.
Время загрузки нескольких экземпляров RouterOS в GNS3 в Ubuntu . Табл. 1.1
Кол-во эк- Qemu без KVM
земпляров
RouterOS N Общее время Время загрузки
загрузки T
одного экземсек.
пляра N/T сек.
16
82
5.125
32
166
5.1875
48
260
5.416667
64
470
7.34375
80
Недостаточно
памяти
Qemu с KVM
Общее время
загрузки T
сек.
30
62
100
140
180
Без KVM
С KVM
500
Время загрузки
Время загрузки
одного экземпляра N/T сек.
1.875
1.9375
2.083333
2.1875
2.25
470
400
300
260
200
82
100
0
166
30
16
180
100
140
62
32
48
64
80
Число экземпляров
Рис. 1.1. Время загрузки нескольких экземпляров RouterOS в GNS3 в Ubuntu (2 ядра) .
Из табл. 1.1 видим, что KVM уменьшает время загрузки RouterOS более, чем
в два с половиной раза и это время составляет около двух секунд. Для обычного
бытового компьютера имеем приемлемое время загрузки 80-ти экземпляров
RouterOS равное 3 минутам.
Загрузим одновременно 32 экземпляра RouterOS (62с). Не останавливая
загруженные RouterOS, запустим в новом GNS3 одновременно ещё 32 экземпляра
RouterOS. На это уйдёт 75с. Итого 137с. , что сравнимо с временем
одновременного старта 64-х RouterOS (140с., согласно Табл. 1.1).
Число одновременно работающих экземпляров RouterOs
под Qemu
определяется свободной памятью хост-машины Ubuntu. Анализ показал, что
каждый экземпляр RouterOS с памятью 64 Мб, запущенный в Qemu с KVM,
требует у Ubuntu 32 Мб памяти, а каждый экземпляр RouterOS с памятью 128 Мб
запущенный в Qemu с KVM, требует у Ubuntu 54 Мб памяти.
11
grigoryev.victor@gmail.com http://vmg.pp.ua
Операционную систему Ubuntu можно запускать также под управлением
виртуальной машины, например HYPER-V фирмы Microsoft. Qemu в Ubuntu под
управлением HYPER-V работает несколько медленнее, чем Qemu в Ubuntu на
реальном компьютере. Это обусловлено, помимо прочего, и тем, что KVM не
работает на виртуальной аппаратуре HYPER-V.
Хост-компьютер для HYPER-V имеет 4-ядерный процессор Intel Core i7 950
частотой 3066 МГц и 24Гб памяти. В HYPER-V запущена система Ubuntu c 12Гб
памяти и 4-мя виртуальными ядрами. Рассмотрим время загрузки в Qemu в GNS3
нескольких экземпляров RouterOS версии 5.20 с памятью 64 Мб на виртуальной
Ubuntu (табл. 1.2). Графики зависимости времени загрузки в зависимости от числа
экземпляров RouterOS приведен на рис.1.2.
Время загрузки нескольких экземпляров RouterOS в Ubuntu под HYPER-V . Табл. 1.1
Кол-во экземпляров
RouterOS N
Общее время загрузки T сек.
16
32
48
64
80
39
75
118
155
195
Время загрузки одного экземпляра N/T сек.
2.4375
2.34375
2.458333
2.421875
2.4375
Время загрузки
250
200
195
150
118
100
50
155
75
39
0
16
32
48
64
80
Число экземпляров
Рис. 1.3. Время загрузки нескольких экземпляров RouterOS в GNS3 в Ubuntu под
HYPER-V (4 ядра).
Из табл. 1.2 видим, что время загрузки RouterOS под Qemu в Ubuntu под
HYPER-V составляет около двух с половиной секунд, что сравнимо по времени с
бытовым компьютером. Для виртуального компьютера имеем приемлемое время
загрузки 80-ти экземпляров RouterOS равное 195 секундам.
Анализ показал, что каждый экземпляр RouterOS с памятью 64 Мб,
запущенный в Qemu, требует у Ubuntu под HYPER-V 57 Мб памяти, а каждый
экземпляр RouterOS с памятью 128 Мб запущенный в Qemu, требует у Ubuntu
HYPER-V 79 Мб памяти.
То есть RouterOS в Qemu с KVM потребляет
приблизительно вдвое меньше памяти, чем RouterOS в Qemu без KVM
12
grigoryev.victor@gmail.com http://vmg.pp.ua
Многоядерность процессоров распараллеливает загрузку нескольких
экземпляров RouterOs. Так время загрузки одного экземпляров RouterOS на
бытовом 2-х ядерном компьютером без поддержки KVM приблизительно в два
раза больше, чем на виртуальном 4-х ядерном процессоре HYPER-V (см.
таблицы). То есть реальное ядра бытового компьютера имеют приблизительно
одинаковую мощность по сравнению с ядром виртуального процессора HYPER-V.
RouterOS под виртуальной машиной Qemu в составе GNS3 под управлением
Ubuntu оказалась лучшим выбором для организации виртуальной лаборатории.
Операционная система RouterOs поддерживает практически все современные
сетевые технологии. Это позволило разработать лабораторный практикум для
изучения следующих сетевых технологий: Ethernet-мосты, DHCP, балансировка
нагрузки, EoIP, NAT, маршрутизация RIP, OSPF и BGP, перераспределение
маршрутов, PPP, PPTP, SSTP, L2TP, OpenVPN, виртуальные частные сети 2-го и 3го уровня, IPSec, MPLS, VPLS, VRF. Представляется нереальной комплектация
учебной лаборатории вуза реальным сетевым оборудованием, позволяющим
практически освоить перечисленные сетевые технологии. С
лабораторным
практикумом можно ознакомиться на сайте кафедры http://eom.dp.ua.
Образ установочного CD операционной системы RouterOs находится на сайте
фирмы Mikrotik в свободном доступе, но имеет одно ограничение – время
непрерывной работы составляет одни сутки. Этих суток хватает пользователю на
несколько лабораторных занятий. По истечении срока пользователи должны
сохранить настройки операционных систем RouterOs и сетевую топологию
выполняемой лабораторной работы, запустить сохранённую топологию без
настроек и восстановить настройки RouterOs. Написаны скрипты, которые
соединяются с помощью протокола ssh с устройствами в топологии, посылают в
устройства команды для создания или восстановления резервных копий и
загружают или выгружают эти копии. Переустанавливать при этом операционную
систему RouterOs не надо. Это объясняется тем, что при первом старте каждого
устройства в топологии GNS3 создаёт для него разностную копию образа диска
заранее установленной операционной системы и не изменяет оригинал.
Удалённый доступ к Ubuntu
Для
работы
можно
воспользоваться
лабораторией
по
адресу
labs.mikrotik.com.ua, хостинг для которой любезно предоставил координатор
Mikrotik по Украине Лукин Дмитрий (Ультратех ЛТД). Из кафедры лаборатория
доступна по адресу 192.168.3.253. Лаборатории также развёрнуты на кафедре
(192.168.14.56) и факультете (192.168.10.254).
Графический интерфейс linux
организован с помощью X-протокола.
Приложения осуществляют графический вывод на X-сервер, выступая по
отношению к нему как клиенты. Для доступа из Windows к удалённому рабочему
столу Ubuntu можно использовать обычный X-сервер для Windows, например
Xming. Опыт показал, что этот подход приемлем только для работы в локальной
сети. Может быть организована удалённая работа и по протоколу VNC, но при
этом требуется множество дополнительных настроек.
13
grigoryev.victor@gmail.com http://vmg.pp.ua
Мы используем наиболее продвинутую технологию фирмы NoMachine,
основанную на X-протоколе и протоколе SSH. Для удалённого доступа к рабочему
столу Ubuntu следует выкачать с сайта производителя программу NX Client for
Windows и установить её.
Client for Windows уже установлен на кафедральных компьютерах. Запустите
мастер подключения nxclient в котором в поле session введём произвольное имя
сессии, в поле
host введём адрес удалённого Ubuntu (192.168.10.254 или
192.168.14.56 или 192.168.3.253), в следующем поле можно установить тип
соединения ADSL, в следующем окне установим менеджер окон GNOME и
создадим ярлык. Запустим сессию с помощью ярлыка NX client for windows.
Введём имя и пароль, согласно номера студента V, например для номера D=1 login:
student1 и password: student1. Нажимаем Login. Ждём соединения с Ubuntu.
Последовательно в появившемся окошке видим сообщения:
Setup the environment
-установка окружения
Connecting to 192.168.10.254 - соединение с Ubuntu
Connected to 192.168.10.254 - соединились с Ubuntu
Waiting authentication
- ждём проверку подлинности
Authentication complete - проверку прошли
Или
Authentication failed for user student1-это если вы неправильно ввели имя или
пароль.
Если вы в прошлый раз некорректно завершили работу и не вышли из Ubuntu ,
то появится окно, извещающее о незакрытых сессиях (рис. 1.2)
Если недоступна кнопка Resume, то нажимайте Terminate и затем New.
Иначе вы увидите сообщения
Download session information - загрузка информации о сессии
Negotiation the link parameters - соглашение о параметрах связи
Esteblish a display connection - установка соединения к дисплею
Рис. 1.2 Незакрытые сессии
Появится окно во весь экран с большим изображения символа Nomachine !m.
Возможно придётся ждать несколько минут и вы в Ubuntu.
Войдя в Ubuntu, выполните в теминале команду top, показывающую загрузку
компьютера. Не начинайте работать, если компьютер занят более чем на 50% или
у него свободной памяти меньше, чем 500Мб. Утилита top покажет, кто занимает
компьютер. Свяжитесь с ним.
Место лабораторий в сети университета
14
grigoryev.victor@gmail.com http://vmg.pp.ua
Для получения RSA-сертификата и доступа к виртуальной сетевой
лаборатории университета следует обратиться к автору и посетить сайт
http://eom.pp.ua
Компьютеры университета имеют адреса в сети 192.168.0.0/16 и не видны из
Интернета. Доступ в Интернет университет осуществляет через адрес проксисервера 212.3.125.178. Компьютеры кафедры лежат в сети 192.168.14.0/24 и не
видны из сети университета и тем более из Интернета. Доступ в сеть
университета и далее в Интернет кафедра осуществляет через свой роутер по
адресу 192.168.10.10, который лежит в сети 192.168.10.0/24 корпуса 12 (рис 1.3).
Имеются две независимые лаборатории. Обе работают под управлением
операционной системы Ubuntu версии 10.04.3-desktop-amd64. Одна лаборатория
развёрнута на кафедральном компьютере в аудитории 12/211 и доступна из сети
кафедры по адресу 192.168.14.56. Вторая лаборатория развёрнута в виде
виртуальной машины внутри компьютера LIB в аудитории 12/310 и доступна из
кафедральной и университетской сети по адресу 192.168.10.254 (рис 1.3).
Компьютер LIB имеет следующие характеристики. Материнская плата Asus
P6X58D Premium, 8-ми ядерный процессор Intel Core i7 950 3066MG, RAM 12G,
HDD 2xWD1-1002FAEX. LIB работает под управлением операционной системы
Windows server 2008 r2 sp1. В LIB активирована роль виртуальных машин HYPERV. В рамках виртуальной сети HYPER-V имеется два виртуальных коммутатора
Микрософт: внутренний и внешний. Создано два виртуальных сетевых адаптера
inet и NAT. Адаптер NAT подключён к внутреннему коммутатору и имеет адреса
192.168.0.1/24 и 192.168.0.254/24.
Адаптер inet подключён к внешнему
коммутатору и имеет адрес 192.168.10.11/24. Физический сетевой
адаптер
компьютера LIB также подключен к внешнему коммутатору. Компьютер LIB
выходит в сеть университета через адаптер inet (рис 1.3).
В университетской сети осуществляется преобразование общедоступного
адреса назначения 212.3.125.93 в локальный адрес адаптера inet 192.168.10.11 для
портов http, rdp, 8000-8004. Поэтому компьютер LIB доступен из Интернета по
адресу 212.3.125.93 (рис 1.3).
В LIB в менеджере виртуальных машин HYPER-V запущена виртуальная
машина под управлением операционной системы Ubuntu. В Ubuntu настроено два
сетевых адаптера eth0 и eth1. Адаптер eth1 подключён к внешнему коммутатору
HYPER-V и имеет адрес 192.168.10.254/24.
По этому адресу виртуальная
лаборатория доступна из сети университета. Адаптер eth0 подключён к
внутреннему виртуальному коммутатору HYPER-V и имеет адрес192.168.0.2/24
(рис 1.3). В Ubuntu через этот адаптер назначен маршрут по умолчанию на адрес
192.168.0.1 адаптера NAT хост-машины LIB.
Адаптера eth0 используется для доступа из Ubuntu в Интернет, который
необходим для обновления операционной системы Ubuntu. В университете для
получения доступа в Интернет необходимо подать заявку с указанием IP-адреса и
MAC-адреса, что вызывает ряд трудностей для виртуальной сети HYPER-V.
Поэтому было решено в хост-машине LIB активировать роль маршрутизации и
организовать преобразование исходящих адресов из сети
192.168.0.0/24
15
grigoryev.victor@gmail.com http://vmg.pp.ua
внутреннего коммутатора в адрес 192.168.10.11 адаптера inet (рис 1.3). Этому
адаптеру разрешён доступ в Интернет.
Для обеспечения непрерывности процесса обучения студентов было решено
организовать доступ к виртуальным лабораториям университета через Интернет.
Для этого используется технология виртуальных частных сетей (VPN-Virtual
Private Network). Существует множества способов организации VPN: SSH-тунель,
PPtP, L2TP, IPsec и др. Мы остановились на протоколе OpenVPN с использованием
RSA-сертификатов, который нам представляется наиболее адекватным для
решения наших задач. На компьютере LIB запущена служба OpenVPN-сервера со
следующей конфигурацией адресов и маршрутов
port 8002
клиенты подключаются к этому порту
proto tcp
по этому протоколу
dev tun
в режиме маршрутизации
ca ca.crt
для них осуществляется
cert lib.crt
проверка
key lib.key
сертификатов
server 192.168.3.0 255.255.255.0
После
соединения сервер получает
адрес 192.168.3.1/24, а клиентам назначается адрес из сети 192.168.3.0/24.
Рис. 1.3. Место лаборатории в сети университета. DNUnet – сеть ДНУ; Inet – Интернет;
211 – свич в ауд. 211; Eom – маршрутизатор в ауд. 211; 12 – свич 12-го уч. корпуса; Student –
домашний компьютер студента; Ubuntu211 – Ubuntu в ауд. 211; Outer и Inner – внешний и
16
grigoryev.victor@gmail.com http://vmg.pp.ua
внутренний свичи Hyper-V сети компютера Lib; Ubuntu – виртуальная Ubuntu в Hyper-V
компьютера Lib; eth0, eth1 – сетевые адаптери Ubuntu; Inet, NAT – – сетевые адаптери
Hyper-V; netLib – – сетевые функции компьютера Lib
push "route 192.168.0.0 255.255.0.0"
Клиенты получают маршрут к сети
университета.
topology subnet Позволяет
избегать назначения клиентам адресов с
маской /30, что позволит им связываться между собой в сети 192.168.3.0/24.
tcp-nodelay
Отменить алгоритм Nagle (чуть быстрее)
client-config-dir "\\OpenVPN22\\config\\ccd\\" Определяет имя папки, в
которой лежат файлы, содержащие адреса и маршруты, которые назначаются
подключившимся клиентам. Имя файла совпадает с общедоступным именем
сертификата клиента. Приведём пример файла student5 для сертификата с
общедоступным именем сертификата равным student5
ifconfig-push 192.168.3.105 255.255.255.0
клиент
получает
адрес
192.168.3.105/24
push "route 10.5.0.0 255.255.0.0"
и маршрут в сторону сети
10.5.0.0/16
После установления OpenVPN-соединения клиенты получают доступ к адресу
192.168.0.2 сетевой лаборатории, расположенной в виде виртуальной машины
Ubuntu внутри компьютера LIB в аудитории 12/310. При этом никакие ограничения
на порты приёмника не накладываются. Клиент получает доступ ко всем сетевым
службам.
Для доступа к лаборатории на кафедральном компьютере в аудитории 12/211
осуществляется два преобразования адресов приёмника для пакетов со значением
порта назначения 22 (SSH). В начале, на компьютере Lib у приходящих пакетов с
адресом назначения 192.168.0.254 осуществляется замена этого адреса на адрес
кафедрального роутера 192.168.10.10. В роутере пакеты со значением порта
назначения 22 пробрасываются на адрес 192.168.14.56 компьютера в аудитории
12/211. В итоге, после установления OpenVPN-соединения клиенты получают
доступ ко второй сетевой лаборатории, расположенной в аудитории 12/211,
используя адрес 192.168.0.254. Клиент получает доступ только к сетевой службе
SSH.
Кафедральный компьютер и роутер в аудитории 12/211 не работают вне
рабочего времени.
Подключение к лаборатории с помощью протокола Openvpn
Итак. К виртуальным лабораториям организован доступ из Интернет с
помощью протокола Openvpn. Если вы находитесь в университете, то для
подключения к виртуальной лаборатории совсем не надо использовать Openvpn.
Доступная из Интернета сетевая лаборатория в аудитории 12/310 также доступна
из сети университета по адресу 192.168.10.254.
Мы осуществим настройку клиентской части Openvpn для доступа с
кафедрального компьютера к лаборатории в аудитории 12/310 только в качестве
пробы и тренировки. Полученные навыки следует использовать для подключения
17
grigoryev.victor@gmail.com http://vmg.pp.ua
по Openvpn из домашнего компьютера к виртуальной лаборатории внутри
компьютера LIB в аудитории 12/310.
В начале следует проверить доступность компьютера LIB в университетской
сети (через cmd.exe): ping 192.168.10.11
Проверим
наличие
службы
Openvpn
на
удалённом
хосте
telnet 192.168.10.11 8002
Пример отсутствия службы
C:\Users\Administrator>telnet 192.168.10.11 8002
Connecting To 192.168.10.11 ...Could not open connection to the host, on port 8002:
Connect failed
При наличии службы вы увидите чистый чёрный экран. При неудаче –
обратитесь к преподавателю для проверки сетевых настроек и правил брандмауэра.
Openvpn уже установлен на кафедральной виртуальной машине v-srv.
Зайдите туда удалённо. Получите у преподавателя
конфигурацию
client.ovpn
корневой сертификат
ca.crt
свой сертификат
studentV.crt
и ключ к нему
studentV.key
Здесь V-Ваш номер
Эти 4 файла кладём в папку Openvpn\config и меняем в файле конфигурации
client.ovpn 2 строки cert ***.crt и key ***.key на строки
cert studentV.crt
key studentV.key
Пример файла конфигурации client.ovpn для студента №5 (V=5)
client
dev tun
dev-node ovpn – Указываем имя tap-интерфейса для OpenVPN.
proto tcp
remote 192.168.10.11 8002
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert student5.crt
key student5key
ns-cert-type server
comp-lzo
log
openvpn.log
status openvpn-status.log
verb 4
Нажимаем правой кнопкой на client.ovpn и выбираем пункт “запустить с
помощью Openvpn”. Если всё сделали правильно, то увидите в чёрном консольном
окне что-то типа (V=5)
…
18
grigoryev.victor@gmail.com http://vmg.pp.ua
Wed May 04 16:37:53 2011 TLS: Initial packet from 212.3.125.93:8002, sid=c727c0b
Wed May 04 16:38:06 2011 VERIFY OK:
depth=1, /C=UA/ST=UA/L=Dnepropetrovsk/O=DNU/
OU=FFECS/CN=lib/name=keyName/emailAddress=mail@host.domain
Wed May 04 16:38:06 2011 VERIFY OK: nsCertType=SERVER
Wed May 04 16:38:06 2011 VERIFY OK: depth=0,
/C=UA/ST=UA/L=Dnepropetrovsk/O=DNU/
OU=FFECS/CN=lib/name=keyName/emailAddress=mail@host.domain
…
ifconfig 192.168.3.105 255.255.255.0'
…
Wed May 04 16:38:17 2011 Initialization Sequence Completed
Ваш адрес от Openvpn равен 192.168.3.105.
Другой конец Openvpnсоединения находится в Windows server 2008 R2 на компьютере LIB и имеет адрес
192.168.3.1. Проверим наличие Openvpn-соединения: ping 192.168.3.1
Ubuntu запущена внутри Hyper-V и имеет адрес 192.168.0.2. Проверим
доступность удалённой системы Ubuntu: ping 192.168.0.2
Подключение к лаборатории labs.mikrotik.com.ua из кафедры
Компьютер лаборатории labs.mikrotik.com.ua подключается к экземпляру
службы Openvpn компьютера Lib, получает адрес 192.168.3.253 и маршрут на сеть
университета 192.168.0.0/16 через адрес 192.168.3.1.
На кафедральном маршрутизаторе RB750U-2HND фирмы Mikrotik в ауд. 211
прописан маршрут в сторону сети 192.168.3.0/24 через адрес 192.168.10.11
компьютера Lib
Как результат все компьютеры кафедры (192.168.14.0/24) видят лабораторию
labs.mikrotik.com.ua по адресу 192.168.3.253.
Обмен файлами
Для передачи файлов воспользуйтесь протоколом FTP (File Transfer Protocol).
Например, вызовите cmd.exe и введите с кафедрального компьютера
ftp 192.168.10.254 (192.168.14.56, 192.168.3.253, labs.microtik.com.ua)
Далее введите имя и пароль. Попадёте в командную строку FTP. Перейдите в
бинарный режим с помощью команды bin. Выгружать файлы следует из командной
стоки FTP с помощью команды mput маска. Забирать файлы следует с помощью
команды mget маска. Пример маски *.txt. Попробуйте выгрузить и загрузить
произвольный небольшой файл, скажем abc.txt.
Для удалённого доступа к командной строке Ubuntu широко используется
протокол SSH (Secure Shell). Для Windows есть уникальная утилита putty,
выполняющая функции Ssh-клиента. Putty входит в состав Gns3. Gns3 установлено
на компьютере V-srv.
Зайдите удалённо на V-srv. Укажите в putty имя пользователя, адрес
192.168.10.254 (192.168.14.56, 192.168.3.253), протокол ssh и подключитесь к
командной строке Ubuntu. Запустите второй экземпляр putty для адреса
192.168.14.56 (192.168.10.254, 192.168.3.253) и подключитесь к командной строке
второго Ubuntu. Обменяйтесь файлом abc.txt между двумя Ubuntu с помощью
протокола FTP.
19
grigoryev.victor@gmail.com http://vmg.pp.ua
Для передачи файлов часто используют безопасное копирование с помощью
протокола SSH. В мире linux безопасное копирование осуществляется с помощью
команды scp. Например, в putty, подключённому по адресу 192.168.3.253, введите
scp abc.txt student1@:192.168.0.2:abc.txt
scp student1@192.168.0.2: abc.txt abc1.txt
Способы выполнения лабораторных работ и курсовой по сетям
Лабораторные работы можно выполнять или дома или на кафедре. Дома
можно или установить Ubuntu на своём компьютере или удалённо подключится у
Ubuntu через openVPN либо по адресу labs.microtik.com.ua, либо по адресу
192.168.0.2 либо по адресу 192.168.0.254. На кафедре можно без Openvpn удалённо
подключится либо по адресу 192.168.3.253, либо по адресу 192.168.10.254, либо
по адресу 192.168.14.56. Помним, что адреса 192.168.0.2 и 192.168.10.254
назначены виртуальному компьютеру внутри компьютера в аудитории 12/310, а
адреса 192.168.0.254 и 192.168.14.56 относятся к реальному компьютеру в
аудитории 12/211.
Ubuntu, установленная на реальном компьютере в аудитории 12/211 работает
быстрее, чем Ubuntu под виртуальной машиной. Однако, компьютер и роутер в
аудитории 12/211 не работают вне рабочего времени и доступ к этому компьютеру
через openVPN содержит дополнительное звено в виде этого роутера. Поэтому
удалённый доступ из дома лучше осуществлять по адресу labs.microtik.com.ua или
192.168.0.2.
Если у вас есть ноутбук и вы находитесь на кафедре, то назначьте на WiFiадаптер адрес из сети 192. 168.14.0/24, шлюз 192.168.14.1 и можно подключится
либо к Ubuntu по адресу 192.168.14.56, либо к Ubuntu по адресу 192.168.10.254,
либо по адресу 192.168.3.253
Находясь на кафедре, используется преимущественно локальный адрес
192.168.14.56. По окончании работы сделайте резервную копию своей работы (см.
ниже) и сохраните её с помощью FTP или SSH (scp) на Ubuntu по адресу
192.168.10.254 либо по адресу 192.168.3.253 Дома подключитесь к этим же
Ubuntu по адресам 192.168.0.2, labs.microtik.com.ua соответственно, восстановите
свою работу из резервной копии и продолжайте работать удалённо. По окончании
работы сделайте резервную копию своей работы.
Находясь на кафедре,
подключитесь к Ubuntu по адресу 192.168.14.56. Заберите по FTP или SSH (scp)
резервную копию из Ubuntu по адресу 192.168.10.254 либо по
адресу
192.168.3.253. Восстановите свою работу из резервной копии и продолжайте
работать.
Если вы установили Ubuntu на своём домашнем компьютере, то можно из
дома
подключиться к Ubuntu по адресу labs.microtik.com.ua (192.168.0.2,
192.168.0.254), забрать резервную копию по FTP или SSH (scp) на свой компьютер
и работать локально. Сделайте на своём компьютере новую резервную копию и
отправьте её по FTP или SSH (scp) в Ubuntu по адресу labs.microtik.com.ua
(192.168.0.2, 192.168.0.254).
Требования для сдачи работы
Поместить на свой рабочий стол в лабораториях свою фотографию с
подписью в виде своей фамилии.
20
grigoryev.victor@gmail.com http://vmg.pp.ua
2. Работа с Mikrotik RouterOS в Qemu и GNS3
Начальная подготовка Ubuntu
Установка и работа с операционной системы RouterOS
Установка и настройка GNS3
Первая топология
GNS автоматически генерирует команды для Qemu
Шаблон для топологий
Работа с RouterOS из командной строки
Импорт и экспорт топологий
О персональных компьютерах и свичах в топологиях
21
21
26
28
31
32
35
36
37
Начальная подготовка Ubuntu
Зайдём с помощью nxclient на удалённый рабочий стол Ubuntu.
Полезно
также параллельно зайти в Ubuntu с помощью ssh из putty. Это будет полезно на
случай зависания nxclient. Добавим терминал на панель (Applications->Accessories>terminal -правая кнопка мыши). Нажмём на верхней панели правую кнопку мыши,
выберем add to panel и добавим system monitor и Windows selector … menu .
Загружать свою топологию может любой студент. В период загрузки сетевой
топологии маршрутизаторы сильно грузят процессоры. Стартовать свою
топологию нет смысла, пока загружены процессоры. Поэтому за правило надо
взять наблюдение за окном системного монитора. С его помощью можно узнать,
когда загрузка маршрутизаторов у вас или других студентов завершилась. За
загрузкой системы можно наблюдать и с помощью консольной команды top.
При работе вы можете открыть массу окон, чтобы в них не запутаться
используйте закреплённый на панели Windows selector.
Мы часто используем терминал (консоль). Не запускайте много экземпляров.
Используйте табы в терминале (file-open tab) для открытия в одном окне множества
консолей. Внутри консоли работает поддержка мыши для выделения текста и
копирования/вставки из/в буфер обмена.
В качестве менеджера файлов мы используем mc. В нём для поиска
используйте клавиатурную последовательность F9-c-f. Для скрытия-показа панелей
– комбинацию клавиш ctrlO (удерживая Ctrl, нажимаем o).
Установка и работа с операционной системы RouterOS
1. Используем последнюю версию образа RouterOS mikrotik для Интелплатформы, который берём с сайта производителя mikrotik.com. В папке /home/4all
возьмём в свою папку CD-образ операционной системы, например mikrotik-5.2.iso.
Создадим пустой образ виртуального диска формата qcow2 размером 111mb:
qemu-img create -f qcow2 mikrotik-5.2.img 111M
В виртуальной машине Qemu из CD-образа mikrotik-5.2.iso установим
RouterOS
на
образ
виртуального
диска
mikrotik-5.2.img:
qemu mikrotik-5.2.img -cdrom mikrotik-5.2.iso -boot d
видим
[1]11424
VNC server running on `127.0.0.1:5900'
21
grigoryev.victor@gmail.com http://vmg.pp.ua
Нам нужен VNC-клиент для общения с виртуальной машиной. Выбираем
applications - internet - remote desktop viewer. Далее
connect - protocol VNC -host
127.0.0.1:5900 и нажимаем connect. Видим начальное окно установки RouterOS. В
VNC-клиенте мышь не поддерживается и он её захватывает. Захватывается и ввод
с клавиатуры. Освобождение осуществляется комбинацией клавиш ctrlАlt. С
помощью клавиш со стрелками и пробела выбираем модули для установки: system,
ppp, dhcp, hotspot, advanced-tools, mpls, routerboard, routing, security. Нажимая i,
начинаем установку. На вопросы отвечаем по умолчанию. После завершения
установки, закрываем qemu (и RouterOS) , нажав комбинацию CtrlC в том
терминале Ubuntu, откуда была запущена qemu, а не в VNC-клиенте.
Проверяем установку:
qemu mikrotik-5.2.img
Запускаем VNC–клиент. Вводим Login: admin, Password: оставляем пустым.
Для остановки RouterOS используйте команду RouterOS system shutdown. При
обилии маршрутизаторов ввод этой команды для каждого маршрутизатора
утомляет. Поэтому иногда будем практиковать неправильную остановку RouterOS,
нажав CtrlC в консоли Ubuntu.
Важно помнить, что в VNC–клиенте Qemu работает в двух режимах: системы
и монитора. Переключение ctrl+alt 1 и ctrl+alt 2. Перейдя в монитор, посмотрите
версию Qemu командой info version. Полный список команд с описанием смотри
на сайте Qemu.org.
Можно стартовать RouterOS и так
qemu mikrotik-5.2.img&
Enter
Знак & в конце команды важен: Qemu не захватит терминал. Если мы введём
такую последовательность
qemu mikrotik-5.2.img
CtrlZ
^Z
[1]+ Stopped
qemu mikrotik-5.2.img
то второй экземпляр Qemu остановился. Запустим его
bg
[1]+ qemu mikrotik-5.2.img &
Qemu освободил терминал. В обеих случаях комбинация CtrlC теперь не
пойдёт в программу Qemu. Нам для неправильной остановки RouterOS надо убить
процесс Qemu. Находим его номер
ps aux|grep qemu
Команда ps aux выводит подробные сведения обо всех процессах в системе от
всех пользователей. Этот вывод проходит через фильтр grep. Видим, кто запустил
процесс и, какой у процесса номер
Student5 9718 61.3 0.9 247212 80336 pts/3 Sl 21:09 0:08 qemu mikrotik5.14.img
Student5 9719 61.3 0.9 247212 80336 pts/3
Sl 21:09 0:08 qemu mikrotik5.14.img
22
grigoryev.victor@gmail.com http://vmg.pp.ua
Student5 9723 0.0 0.0 7624 944 pts/3 S+ 21:09 0:00 grep --color=auto
qemu
Убиваем процессы
kill 9718
kill 9719
проверяем
ps aux|grep qemu
видим
12020 pts/3
S+
0:00 grep --color=auto qemu
Если убить не удалось, то попробуйте использовать
kill -KILL 9718
kill -KILL 9719
Убить все процессы qemu можно так
killall qemu
Всегда проверяйте наличие нежеланных версий процесса. Набирая ps aux|
grep qemu|grep student, вы узнаете, кто сейчас запустил qemu. Узнать, кто сейчас
занимает процессорное время можно с помощью консольной утилиты top. Чужой
процесс вы не убьете - звоните студенту, чтобы он убил неправильные или
обратитесь к администратору.
2. В VNC–клиенте в окне Qemu не работает copy-paste. Добьемся этого
другими средствами.
Реальные железные маршрутизаторы не имеют клавиатуры и монитора, и
настройка производится через консоль и последовательный порт. Qemu позволяет
перенаправить последовательный порт на соединение по протоколу telnet. Наберём
в терминале Ubuntu команду
qemu mikrotik-5.2.img -serial telnet:127.0.0.1:3000,server,nowait
В другой закладке окна терминала введём
telnet 127.0.0.1 3000
Мы в консоли RouterOS. Copy-paste работает c помощью мыши. Проверьте.
Заметим, что Copy-paste работает только для мыши. Клавиатурные комбинации
для Copy-paste не работает.
Сделайте копию R0.img для mikrotik-5.2.img.
cp mikrotik-5.0rc8.img R0.img
и пока работайте с копией. Чистая версия нам понадобится для GNS3.
3. RouterOS внутри Qemu можно связать с внешним миром многими
способами (см. документацию на сайте wiki.qemu.org). Мы для связи с хостмашиной Ubuntu используем tap-интерфейсы, а для связи между RouterOS ―
протокол UDP.
Связь между хост-машиной Ubuntu и устройствами внутри виртуальной
лаборатории осуществляется как через консоль по протоколу Telnet, так и с
использованием tap-интерфейсов.
В лаборатории под Qemu запускается
множество операционных систем RouterOS маршрутизаторов фирмы Mikrotik. В
Ubuntu созданы tap-интерфейсы tapV00,
tapV01 ... tapV07, tapV10, ... tapV14, где
V = 0, 1, 2, 3, 4, 5. Интерфейсов tapV08 и tapV09 нет, по техническим причинам.
Tap-интерфейсы помещены в мосты. На мосты назначены адреса 10.V.0.2, 10.V.1.2
23
grigoryev.victor@gmail.com http://vmg.pp.ua
… 10.V.7.2, 10.V.10.2 … 10.V.19.2. Маска /24. Для каждого V все адреса мостов
образуют сеть 10.V.0.0/16. Например, для V=5 это сеть 10.5.0.0/24. Будем
называть V номером tap-сети. Мосты можно посмотреть командой brctl show, а
адреса командой ifconfig. Номер своей tap-сети студент получает перед началом
работы.
Возьмём tap-сеть с номером 0. Соединим маршрутизатор
R0 с tapинтерфейсом tap000. (Вы работаете со своей сетью и интерфейсом). В дальнейшем
старайтесь придерживаться соглашения - номер в имени маршрутизатора
определяется двумя последним цифрам в имени tap-интерфейса (R0 - tap000).
qemu
R0.img -serial telnet:127.0.0.1:3000,server,nowait -net nic -net
tap,script=no,downscript=no,ifname=tap000&
Не доверяйте процедуре Copy-Paste. Вы можете перенести невидимые или
нелатинские символы. Вводите команду вручную. После ввода команды видим
VNC server running on `127.0.0.1:5900'
Запускаем VNC –клиент к 127.0.0.1:5900. Переключаемся в монитора ctrl+alt
2. Вводим info network и наблюдаем (Рис. 2.1)
Рис. 2.1. Монитор Qemu
что Qemu увидела для Routeros tap-интерфейс как Ethernet-карточку модели e1000
с MAC-адресом 525400123456.
В новом табе окна терминала введём
telnet 127.0.0.1 3000
Мы в консоли RouterOS. Смотрим интерфейсы
[admin@MikroTik] > interface ethernet print
Flags: X - disabled, R - running, S - slave
# NAME
MTU MAC-ADDRESS
ARP
0 R ether1
1500 52:54:00:12:34:56 enabled
Видим, что наша
Ethernet-карточка модели e1000 с MAC-адресом
525400123456 называется в RouterOS как ether1. Со стороны Ubuntu tapинтерфейс для студента 0 помещён в мост m000 c адресом 10.0.0.2/24. Поэтому в
RouterOS назначим другой адрес из сети 10.0.0.0/24 например
[admin@MikroTik] > ip address add address=10.0.0.1/24 interface=ether1
Проверим связь MikroTik с хост-машиной Ubuntu
[admin@MikroTik] > ping 10.0.0.2
HOST
SIZE TTL TIME STATUS
24
grigoryev.victor@gmail.com http://vmg.pp.ua
10.0.0.2
56 64 10ms
10.0.0.2
56 64 1ms
sent=2 received=2 packet-loss=0% min-rtt=1ms avg-rtt=5ms max-rtt=10ms
Для надёжности проверим связь и со стороны хост-машины Ubuntu. В новом
табе окна терминала введём
Student0@u10034d64bbb071:~$ ping 10.0.0.1
Student0@u10034d64bbb071:~$ telnet 10.0.0.1
Мы опять в консоли RouterOS. Выход – CtrlD.
Тап-устройства имеют двоякую природу. С одной стороны это сетевые
интерфейсы, а с другой стороны это устройство ввода вывода /dev/net/tun. Сетевые
пакеты, пришедшие на Тап-интерфейс можно прочитать как данные из устройства
/dev/net/tun. Данные записанные в устройство /dev/net/tun исходят их Тапинтерфейса в виде сетевых пакетов. Опция
-net nic -net tap,script=no,downscript=no,ifname=tapXXX
командной строки qemu организует сетевой обмен данными между Ethernetадаптером виртуальной машины и Тап-интерфейсом tapXXX хост-машины. Qemu
производит этот обмен путём записи-чтения устройства /dev/net/tun в Ubuntu.
Подключимся с помощью безопасной консоли. В новом табе окна терминала
введём
Student0@u10034d64bbb071:~$ ssh admin@10.0.0.1
Согласитесь с выведенным предложением. Если вы получите сообщение о
нарушении безопасности, то удалите файл в папке .ssh и попробуйте снова. Если
вам будет отказано в подключении, то переставьте операционную систему
RouterOS. Без поддержки доступа по ssh, вы не сможете быстро делать резервные
копии и восстанавливаться из них. Выход – CtrlD.
Берём себе из папки /home/4all утилиту winbox.exe. Делаем для неё ярлык для
запуска. (desktop - create launcher) Помещаем его в верхню панель. Запускаем.
Вводим адрес 10.0.0.1 и попадаем в маршрутизатор. Остановим маршрутизатор из
winbox или командной строкой sys shut в консоли RouterOS.
4. Сделайте ещё одну копию R1.img образа диска маршрутизатора mikrotik5.2.img. Соединим два маршрутизатора, используя UDP. Тщательно вводите
команды.
qemu
R0.img -serial telnet:127.0.0.1:3000,server,nowait -net nic -net
udp,sport=33333,dport=22222,daddr=127.0.0.1&
Warning: vlan 0 is not connected to host network
VNC server running on `127.0.0.1:5900'
qemu
R1.img -serial telnet:127.0.0.1:3001,server,nowait -net nic -net
udp,sport=22222,dport=33333,daddr=127.0.0.1&
Warning: vlan 0 is not connected to host network
VNC server running on `127.0.0.1:5901'
Запускаем VNC –клиент и подключаемся к 127.0.0.1:5900 и 127.0.0.1:5901.
Переключаемся в монитор ctrl+alt 2. Вводим
info network
25
grigoryev.victor@gmail.com http://vmg.pp.ua
и видим, для R0
для R1
Т.е. Ethernet-адаптеру поставлен в соответствие UDP-канал. Подключаемся к
консолям роутеров через telnet
telnet 127.0.0.1 3000
telnet 127.0.0.1 3001
и назначаем роутерам имена R0 и R1
[admin@MikroTik] > system identity set name=R0
[admin@MikroTik] > system identity set name=R1
Промпт роутеров отразил смену имени
[admin@R0]>
[admin@R1]>
Назначаем роутерам адреса
[admin@R0]> ip address add address=1.1.1.1/24 interface=ether1
и для R1
[admin@R1]> ip address add address=1.1.1.2/24 interface=ether1
Пингуем из R1 в R0.
[admin@MikroTik] > ping 1.1.1.1
Связь есть.
Все пакеты из Ethernet-интерфейса R0 поступают на UDP порт 22222 хостмашины Ubuntu и Ethernet-интерфейс R0 принимает все пакеты из UDP порта
33333 хост-машины. Для R1 наоборот. Все пакеты из Ethernet-интерфейса R1
поступают на UDP порт 33333 хост-машины ubuntu и Ethernet-интерфейс R1
принимает все пакеты из UDP порта 22222 хост-машины. Таким образом сетевой
Ethernet-кабель моделируется двунаправленным UDP-каналом с использованием
двух портов 22222 и 33333.
Попытаться из командной строки организовать сложную топологию – дело
громоздкое и чревато ошибками. Тут на помощь приходит контейнер виртуальных
машин GNS3
Установка и настройка GNS3
Для быстрого сбора сетевых топологий следует использовать оболочку GNS3.
Эта оболочка генерирует командные строки для запуска Qemu, которые можно
увидеть, запустив перед запуском GNS программу Qemuwrapper.py –p ВашПорт.
Предупреждение Qemu is already running on port игнорируем.
Берём себе из папки /home/4all архив GNS3-0.7.4-src.tar.gz. Развернём его.
Появится новая папка. В терминале проверьте, что программы qemuwrapper.py и
gns3 в новой папке запускаются. Создайте ярлык для запуска GNS3. В качестве
ссылки для ярлыка надо указать файл gns3. Создайте в Вашей рабочей Папке две
папки
26
grigoryev.victor@gmail.com http://vmg.pp.ua
mkdir tmp
mkdir projects
Запустим GNS3. Закроем окошко создания проекта. Выберем для настройки
Edit - Preferences. Устанавливаем путь к своей папке проектов projects и путь к
папке, где лежит созданный ранее в этой работе образ диска операционной
системы RouterOS (Image Directory).
Настроим терминал: Edit - Preferences - General - Terminal setting. Возьмём
для Preconfigurated terminal commands - Gnome Terminal. Для Terminal command
возьмём- gnome-terminal -t %d -e 'telnet %h %p' >/dev/null 2>&1 & и жмём OK.
Выберем для настройки Edit - Preferences - Qemu - General setting.
Устанавливаем путь к своему файлу qemuwraper.py и путь к своей рабочей папке
tmp.
Важно, чтобы у всех одновременно работающих не было общих окрытых
портов TCP и UDP. Возьмём порты
10525+N - Qemuwraper
20000+N*1000 -UDP
3000+N*100 - консоль
N - ваш номер. Например, если вы student7, то вписываем порты
10532 - Qemu wraper
27000 -UDP
3700 – консоль
Хотя заметим, что в этой версии GNS порт консоли поменять не удаётся и его
придётся менять путём редактирования текстового файла topokogy.net
конфигурации сетевой топологии.
Удалите внешний Qemuwraper или дайте ему тот же порт. Нажимаем
применить. Должен пройти Test. Жмём OK. Если тест не прошёл, то закроем GNS3.
Запусти в терминале Qemuwraper, указав свой порт, например для студента 7
qemuwraper.py –p 10532
Снова запустим GNS3. Смотрите на ошибки в терминальном окно
Qemuwraper.
Периодически проверяйте целостность GNS, нажимая
Test. При
проблемах- настройте GNS снова.
Занятые порты TCP (UDP) и соответствующие им программы можно
посмотреть командой
netstat –atnp
(netstat –aunp)
Используйте фильтр grep и определите номер процесса. Далее, используя
команду ps aux и фильтр по номеру процесса, определите, кто забрал ваш порт.
Перейдём Edit - Preferences - Qemu - Qemu host и добавим в Binary image
путь к образу созданного ранее в этой работе образ диска операционной системы
RouterOS (здесь mikrotik-5.2.img). Галочки kQemu , kvm не ставим. Галочку kvm
нужно поставить у себя дома, если вы работаете с Ubuntu не под виртуалной
машиной и у вас установлена поддержка KVM. Даём произвольное имя для
образа. Нажимаем Save, Apply и Оk.
Изменим иконку Qemu host на левой панели GNS. Выберем Edit-Symbol
Manager. Выбираем слева иконку
(например router)
и, нажимая >, переносим
27
grigoryev.victor@gmail.com http://vmg.pp.ua
её в правую часть. Дважды щёлкаем на нёй в правой части. Появится имя: router и
тип: декоративный узел. Меняем имя: Mikrotik и тип: выбираем из списка
значение «Qemu host». Нажимаем применить. Имя в правой части изменится на
Mikrotik. Нажимаем OK. Слева в GNS в типах узлов появится новая иконка
Mikrotik - синоним Qemu host.
Перед созданием и запуском топологии запустим Qemuwrapper. Когда вы
наберётесь опыта, то это можно не делать. Например, если вы студент с номером 7,
то ваш Qemuwrapper использует порт 10532 (=10525+7). Откройте консоль Ubuntu,
найдите файл Qemuwrapper.py и запустите команду ./qemuwrapper.py –p 10532
Первая топология
Создадим первую топологию first. Запускаем GNS3. В появившемся окошке
вводим имя нового проекта first и ставим галочку Save nvrams. Нажимаем Ok. Если
проект уже создан, то выбираем Open. Для создания проекта можно открыть и
пункт меню File-NewBlankProject. Перетащим два устройства Qemu host с левой
панели на центральную и меняем их имена на R0 и R1 (пункт change the
hostnameв контекстном меню устройства).
Соединим
интерфейс e0
маршрутизатора R0 с интерфейсом e1 маршрутизатора R1 (Значок «add a link» на
верхней панели GNS3, пункт Мanual). После завершения соединения снова
нажмите значок «Add a link». Параметры запуска маршрутизатора можно узнать,
наведя на него мышь.
Заметим о соотношении названий интерфейсов в GNS и RouterOS
GNS
RouterOs
e0
ether1
e1
ether2
...
По умолчанию GNS3 назначает маршрутизатору шесть сетевых интерфейсов.
Менять не будем. Добавляем в маршрутизаторы tap-интерфейсы. Пусть у вас
номер тап-сети 7 и номер студента 5. Начнём. В контекстном меню R0 выбираем
Сonfigure - R0 - Qemu options и вводим. Заметим, что во вводе присутствуют
только три пробела
-net nic,vlan=6 -net tap,script=no,downscript=no,vlan=6,ifname=tap700
Нажимаем Ok. Для R1 вводим
-net nic,vlan=6 -net tap,script=no,downscript=no,vlan=6,ifname=tap701
Это приводит к созданию внутри маршрутизатора сетевой карточки ether7
которая связывается c сетевым tap-интерфейсом Ubuntu с именем tap700 (tap701).
Tap-интерфейса в GNS3 не видно.
Сохраните проект. Откройте в папке проектов появившуюся папку проекта
first. Откройте двойным щелчком (программой gedit) файл topology.net. Изучите
его. Поняв его устройство можно менять топологию без GNS3. Перед запуском
топологии, сделанной на другой машине, обязательно проверьте и исправьте этот
файл. Добавьте порты для консолей в возрастающем порядке номеров роутеров
autostart = False
[Qemu 127.0.0.1:10535] -согласно номеру студента 5
workingdir = working –папка - обязательная строка
udp = 30500 -согласно номеру студента 5
28
grigoryev.victor@gmail.com http://vmg.pp.ua
[[QemuDevice]]
image = /home/student7/mikrotik-5.5.img -измените при переносе с другой
машины
netcard = e1000
kvm = True - эта строка есть, если только работаете на чистом железе с
установленным kvm
[[QEMU R0]] – начало конфигурации для R0
console=3500-согласно номера студента 5 прописываем вручную
e0 = R1 e1 -связь
[[QEMU R1]] – начало конфигурации для R1
console=3501-согласно номера студента 5
e1 = R0 e0 -связь
[GNS3-DATA]
workdir = working -папка-обязательная строка
К сожалению после сохранения торологии в GNS настройки портов консоли
удаляются. Поэтому перед запуском GNS делайте копию файла topology.net или
заново назначайте порты консоли в этом файле.
Улучшив момент, когда система не занята (system monitor), стартуйте все
маршрутизаторы (зелёный треугольник вверху). Старт-стоп отдельного
маршрутизатора производится из контекстного меню. Не используйте рестарт – не
всегда работает. Дождитесь окончания загрузки.
В папке first вы увидите папку working, а в ней папки R0 и R1, а в этих папках
два образа диска FLASH и SWAP. Если это не так, то остановитесь и проверьте
настройки, так как в дальнейшем возникнут трудности.
Осуществлять конфигурацию маршрутизатора через консоль с помощью
интерфейса командной строки можно тремя способами: либо через VNC-клиент,
либо через консоль маршрутизатора в GNS либо через telnet. В первом случае надо
знать порт VNC-сервера. Порт VNC можно узнать в консоли Qemuwrapper, если
запускать маршрутизаторы по одному. Во втором случае консоль маршрутизатора
вызывается двойным щелчком мыши на иконке маршрутизатора.
В третьем
случае консоль маршрутизатора вызывается через консоль Ubuntu с помощью
команды telnet 127.0.0.1 порт-консоли. Заметим, что второй случай также
приводит к неявному вызову команды telnet 127.0.0.1 порт-консоли.
Во втором и третьем случае работать удобнее всего, так как работает
CopyPaste. Если консоль маршрутизатора не запустилась, то анализируйте вывод в
консоли Qemuwrapper и занятые порты (netstat). Если там всё нормально, то
останавливаем маршрутизатор, убиваем папку маршрутизатора в папке working
проекта first и снова стартуем маршрутизатор.
Стартуем консоли маршрутизаторов, два раза щёлкнув на их иконках в GNS3
(рис. 2.2). Если терминальное окно будет отличное от приведенного на рис. 2.2, то
исправьте настройки терминала в GNS3 (см.выше)
29
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 2.2. Gnome Terminal
Вводим имя admin без пароля. Назначаем имена (используйте CopyPaste)
system identity set name=R0
system identity set name=R1
Каждый маршрутизатор шлёт соседям широковещательную информацию о
себе и обрабатывает такую же информацию, принятую от соседей. Результат можно
посмотреть командой /ip neighbor discovery print и /ip neighbor discovery print
detail. Мы увидим соседей, достижимых по Ethernet-протоколу, в том числе через
сетевые мосты.
[admin@R0] > ip neighbor print
#INTERFACE ADDRES MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1
00:AA:00:28:C5:01 R1
5.2
x86
[admin@R0] > ip neighbor print detail
0
interface=ether1
mac-address=00:AA:00:28:C5:01
identity="R1"
platform="MikroTik" version="5.2" unpack=none age=17s uptime=10m5s
softwareid="1ZGH-GE5Q" board="x86" ipv6=yes interface-name="ether2"
Этот вывод надо понимать так. Этот маршрутизатор R0 через интерфейс
ether1 обнаружил соседа R1. Сосед R1 послал эту информацию через свой
интерфейс ether2 у которого MAC -адрес равен 00:AA:00:28:C5:01
Проверим, что интерфейс ether2 у R1 имеет этот MAC-адрес
[admin@R1] > interface ethernet print where name=ether2
# NAME
MTU MAC-ADDRESS
ARP
1 R ether2
1500 00:AA:00:28:C5:01 enabled
Аналогично для R1
[admin@R1] > ip neighbor pr int
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether2
00:AA:00:F4:68:00
R0
5.2
x86
[admin@R1] > ip neighbor print detail
0 interface=ether2 mac-address=00:AA:00:F4:68:00 identity="R0"
platform="MikroTik" version="5.2" unpack=none age=1m uptime=10m6s softwareid="1ZGH-GE5Q" board="x86" ipv6=yes interface-name="ether1"
Этот вывод надо понимать так. R1 через интерфейс ether2 обнаружил соседа
R0. Сосед послал эту информацию через свой интерфейс ether1 у которого MAC
-address= 00:AA:00:F4:68:00
Проверим, что интерфейс ether1 у R0 имеет этот MAC-адрес
[admin@R0] > interface ethernet print where name=ether1
# NAME
MTU MAC-ADDRESS
ARP
30
grigoryev.victor@gmail.com http://vmg.pp.ua
0 R ether1
1500 00:AA:00:F4:68:00 enabled
Возьмите за привычку давать маршрутизаторам имена и набирать эти команду
обнаружения соседей. Если вдруг маршрутизатор не видят соседи, то остановите
его, убейте его папку в папке working проекта и стартуйте маршрутизатор заново.
Так как ethet7 сам подсоединён к бриджу Ubuntu, то для сокращения объёма
вывода команд следует использовать фильтр
ip neighbor print where ((interface!=ether7)&&(interface-name!=ether7))
ip neighbor print detail where (interface!=ether7)&&(interface-name!=ether7)
Назначаем адреса. На R0
ip ad ad address=10.7.0.1/24 interface=ether7
ip ad ad address=1.1.1.1/24 interface=ether1
На R1
ip ad ad address=10.7.1.1/24 interface=ether7
ip ad ad address=1.1.1.2/24 interface=ether2
Должны пойти пинги в консолях маршрутизаторов
[admin@R0] >ping 10.7.0.2
[admin@R1] >ping 1.1.1.2
[admin@R1] >ping 10.7.1.2
[admin@R1] >ping 1.1.1.1
И в консоли Ubuntu ping 10.7.0.1 и ping 10.7.1.1.
Помните, что если в GNS3 назначить маршрутизатору один сетевой
интерфейс, а не шесть, как у нас сейчас, то tap-интерфейс в RouterOS будет
называться ether2 и настройки адресов для tap-интерфейса ether7 будут относится
к несуществующему интерфейсу.
Наличие tap-интерфейсов с настроенными внутри RoutrOS адресами даёт
четвёртый способ доступа к консоли RoutrOS из Ubuntu telnet 10.7.0.2 и telnet
10.7.1.2. Пятый способ предоставляет безопасная консоль ssh admin@10.7.0.2 и t
ssh admin@10.7.1.2
Запускаем winbox. Вводим адрес 10.7.0.2, имя admin. Сохраняемся и
соединяемся. Делаем то же для адреса 10.7.0.2. Совершите обзор возможностей
маршрутизатора. Они поражают, если посмотреть в Ubuntu на размер виртуального
диска командой ls –l *img. В winbox есть пункт меню NewTеrmial, что даёт шестой
способ доступа к консоли RoutrOS из Ubuntu.
Маршрутизаторы доступны по протоколам FTP и SSH. Более того
маршрутизаторы имеет веб-интерфейс и доступны в Ubuntu из Firefox по адресам
http://10.7.0.1 и http://10.7.1.1.
Операционная система RouterOS, установленная из образа, скачанного с
официального сайта Mikrotik, имеет ограниченное время непрерывной работы
равное 24 часам. В папке /home/4all лежит образ диска установленной
лицензионной системы RouterOS. Пользуйтесь им. При появлении на сайте
mikrotik.com новой версии RouterOS, скачайте npk-файл для платформы x86,
выгрузите его по FTP в старую версию RouterOS и перегрузите RouterOS.
RouterOS обновится.
GNS автоматически генерирует команды для Qemu
Для топологии first смотрим в окно консоли предварительно запущенного
31
grigoryev.victor@gmail.com http://vmg.pp.ua
Qemuwrapper. Берём содержимое консоли в карман и отформатируем согласно
правилам записи командной строки Qemu ( см. http://wiki.Qemu .org/Manual). MACадреса мы не указываем и убираем несоединённые интерфейсы. Получим
qemu -name R0 -m 256 /home/student5/projects/first/working/R0/FLASH
-hdb /home/student7/projects/first/working/R0/SWAP -net nic,vlan=0 –net
udp,vlan=0,sport=27002,dport=27003,daddr=127.0.0.1 -serial
telnet:127.0.0.1:3700,server,nowait -net nic,vlan=6 -net nic -net
tap,script=no,downscript=no,vlan=6,ifname=tap700
qemu -name R1 -m 256 /home/student5/projects/first/working/R1/FLASH
-hdb /home/ student5/first/working/R1/SWAP -net nic,vlan=1 -net
udp,vlan=1,sport=27003,dport=27002,daddr=127.0.0.1 -serial
telnet:127.0.0.1:3701,server,nowait -net nic,vlan=6 -net nic -net
tap,script=no,downscript=no,vlan=6,ifname=tap701
Заметим, что здесь мы не видим образ диска RouterOS mikrotik-5.2.img. Для
каждого маршрутизатора в топологии GNS делает для mikrotik-5.2.img разностные
образы с именем FLASH. SWAP – это образ диска для свопинга. Если ввести эти
команды в консоли ubuntu, то получим тот же эффект, что и в GNS3. Делать это не
обязательно. Если решитесь, то лучше для этого создайте командный файл.
Строки -serial telnet:127.0.0.1:3700,server,nowait и -serial telnet:
127.0.0.1:3701, server,nowait отвечают за связь с консолью. Для R0 строка
-net nic,vlan=0 -net udp,vlan=0,sport=27002,dport=27003,daddr=127.0.0.1
говорит, что все пакеты из интерфейса e0 (ether1) поступают на UDP порт 27002
хост-машины ubuntu и интерфейс e0 (ether1) принимает все пакеты из UDP
порта 27003 хост-машины.
Для R1 наоборот. Строка
-net nic,vlan=1 -net udp,vlan=1,sport=27003,dport=27002,daddr=127.0.0.1
говорит, что все пакеты из интерфейса e1 (ether2) поступают на UDP порт 27003
хост-машины ubuntu и интерфейс e1 (ether2) принимает все пакеты из UDP порта
27001 хост-машины.
И, наконец, строки
-net nic,vlan=6 -net nic –net tap,script=no,downscript=no,vlan=6,ifname=tap700
-net nic,vlan=6 -net nic -net tap,script=no,downscript=no,vlan=6,ifname=tap701
приводят к созданию внутри маршрутизатора сетевой карточки ether7 которая
связывается c сетевым tap-интерфейсом с именем tap700 (tap701).
В принципе можно обойтись и без GNS. Однако для сложных топологий
легко запутаться. Остановите все маршрутизаторы (красный квадрат). Сохраните
топологию.
Шаблон для топологий
Создадим топологию template. На топологии должны быть видны все адреса и
интерфейсы. Поместим на панель несколько (8) роутеров. В названиях роутеров
должны быть отражены номера ваших тап-интерфейсов. Например, дадим имена
роутерам от R0 до R7. Пусть у нас тап-сеть 5. Поставим в соответствие роутеру R0
тап-интерфейс tap500. Роутеру R1 тап-интерфейс tap501 и т.д. Для чего в
контекстном меню роутеров R0, R1 … R7 в поле options вводим настройки для
32
grigoryev.victor@gmail.com http://vmg.pp.ua
тап-интерфейсов:
-net nic,vlan=6 -net nic –net tap,script=no,downscript=no,vlan=6,ifname=tap500 -net
nic,vlan=6 -net nic -net tap,script=no,downscript=no,vlan=6,ifname=tap501
…
-net nic,vlan=6 -net nic -net tap,script=no,downscript=no,vlan=6,ifname=tap507
Сохранимся и закроем GNS3. Проверим, что никто не занял нашу тап сеть 5
ps ax|grep tap5
Вручную впишем в файл топологии порты для консолей. Сделайте копию
файла, так как GNS при следующем сохранении затрёт порты. Проверим, что никто
не занял наши порты консоли, например
netstst –ant|grep 300
Откроем топологию в GNS3. В папке working проекта появятся подпапки R0,
R1 … R7. Запускаем все роутеры, нажимая соответствующую иконку на верхней
панели GNS3. . В папках R0, R1 … R7 появятся файлы FLASH и SWAP. Ждём
окончания их загрузки. Запускаем все консоли, нажимая соответствующую иконку
на верхней панели GNS3.
В селекторе окон (вы поместили селектор ранее на верхнюю панель Ubuntu)
выбираем консоль роутера R0. Жмём Enter и вводим имя admin и пустой пароль.
Видим сколько осталось роутеру жить. Мышью берём в карман имя admin до конца
строки. В селекторе окон выбираем консоль роутера R1. Жмём Enter и извлекаем
имя admin из кармана. Жмём Enter 2 раза. Повторяем так для всех роутеров.
Проверяем, что роутеры имеют интерфейс ether7 для связи тап-интерфейсами
Ubuntu. В селекторе окон выбираем консоль роутера R0.. Вводим int print. Берём
команду в карман (до конца строки). Вставляем команду из кармана для остальных
роутеров. Командой из контекстного меню роутеров в GNS останавливаем роутеры
у которых нет ether7. Проверяем для этих роутеров в GNS строку -net nic –net tap,
определяющую связь тап-интерфейса Ubuntu с роутером. В папке роутера в папке
working проекта удаляем файлы FLASH и SWAP. Запускаем роутеры и снова проверяем наличие ether7.
В селекторе окон выбираем консоль роутера R0. Мы ему назначили с тап-интерфейс tap500 (тап-сеть 5). Назначаем адрес на ether7 из соответствующей сети
10.5.0.0/24
ip address add address=10.5.0.1/24 interface=ether7
Берём команду в карман (не до конца строки)
В селекторе окон выбираем консоль роутера R1. Мы ему назначили тап-интерфейс tap510. Вставляем команду из кармана и изменяем её. Назначаем адрес на
ether7 из соответствующей сети 10.5.1.0/24
ip address add address=10.5.1.1/24 interface=ether7
Назначаем адрес на ether7 для остальных роутеров.
Из консоли Ubuntu проверим доступность роутеров
ping 10.5.0.1
ping 10.5.1.1
…
ping 10.5.7.1
33
grigoryev.victor@gmail.com http://vmg.pp.ua
Остановите недоступные роутеры, удалите для них файлы FLASH и SWAP и
переназначьте адреса.
Свяжемся с роутерами с помощью безопасной оболочки ssh, которая позволит
входить в роутеры без ввода пароля.
ssh admin@10.5.0.1
На запрос ответьте yes и вы попадёте в роутер. Выход ^d.
Для других роутеров
ssh admin@10.5.1.1
…
ssh admin@10.5.7.1
Остановите недоступные роутеры, удалите для них файлы FLASH и SWAP и
переназначьте адреса. Если и это не поможет, то переставьте заново RouterOS.
Не двигайтесь дальше, пока не заработает ssh для всех роутеров.
Для каждого роутера R0 R1 R7 создадим в консоли Ubuntu восемь профилей с
именами 0 1 2 …7 соответственно. (Edit-Profiles-New). В профиле зададим заголовок, команду и другие настройки, например для R0 и тап-сети 0 (рис. 2.3)
Рис. 2.3. Настройка закладки
В верхней панели десктопа Ubuntu выберем AddToPanel и добавим Custom
Application Launcher, где введём команду запуска консоли с 8 закладками
gnome-terminal --tab-with-profile=0 --tab-with-profile=1 --tab-with-profile=2
--tab-with-profile=3 --tab-with-profile=4 --tab-with-profile=5 --tab-with-profile=6
--tab-with-profile=7
Рис. 2.4. Закладки
Запустите эту консоль с восемью закладками. Вы увидите в консоли 8 табов
(рис. 2.4). Каждая закладка связана с отдельным роутером. По очереди в каждой закладке назначьте имена. Пользуйтесь услугой Copy-paste.
sys id s n=R0 … sys id s n=R7
Остановите топологию. Закройте GNS. Далее при выполнении очередной
34
grigoryev.victor@gmail.com http://vmg.pp.ua
лабораторной работы следует лишь создать копию папки Template с топологией
шаблона.
Казалось, было бы легче создать профили с командами для связи с роутерами
через консоль, например telnet 127.0.0.1 3000, где 3000 – порт консоли. К сожалению, GNS не сохраняет и затирает назначенные вручную порты консоли.
Хотя в утилите winbox также присутствует консоль, использование закладок в
консоли Ubuntu представляется более эффективным способом одновременной
настройки нескольких роутеров. Удобство работы в основном достигается
использованием технологии Copy/Paste.
Работа с RouterOS из командной строки
Запустите топологию first. Обратимся к R0 из Ubuntu через telnet или ssh.
Если нажать на знак ? и или два раза нажать клавишу табуляции, то увидим список
команд и подменю. Синие пункты ― это меню, а остальное ― команды. Перейдём
в меню interface, набирая строку с этим же именем interface и нажимая Enter.
Команда или подменю идентифицируется по первым набранным символам и, если
они уникальны, то текст зеленеет. Поэтому достаточно набрать in. При желании
видеть всю команду нажмите табуляцию. Команда print выведет интерфейсы.
Команда print detail выведет более детальную информацию. Вернёмся уровнем
выше «..». Переход в главное меню /. Тоже самое можно сделать, набрав команду
целиком
[admin@ R0]>int print detail
Зайдём в меню ip address
[admin@ R0]> /ip address> pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
0
10.0.0.1/24 10.0.0.0
ether7
1
1.1.1.1/24
1.1.1.0
ether1
Команды работают в режиме полного ввода
[admin@R0]>/ip address>add add=2.2.2.2/24 interface=ether2
или диалога
[admin@ R0]> /ip address> add
address: 3.3.3.3/24
interface: ether3
Всегда помогает табуляция и знак вопроса. Настройки можно поменять.
Например, для адреса 2.2.2.2/24 поменяем интерфейс на ether4. В начале, узнаем
номер
[admin@ R0]> /ip address> pr
Flags: X - disabled, I - invalid, D - dynamic
#
ADDRESS
NETWORK
INTERFACE
0
10.0.0.1/24
10.0.0.0
ether7
1
1.1.1.1/24
1.1.1.0
ether1
2
2.2.2.2/24
2.2.2.0
ether2
3
3.3.3.3/24
3.3.3.0
ether3
Это №2. Меняем
35
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@ R0]> /ip address> set 2 interface=ether4
[admin@ R0]> /ip address> pr
Flags: X - disabled, I - invalid, D - dynamic
#
ADDRESS
NETWORK
INTERFACE
0
10.0.0.1/24
10.0.0.0
ether7
1
1.1.1.1/24
1.1.1.0
ether1
2
2.2.2.2/24
2.2.2.0
ether4
3 3.3.3.3/24
3.3.3.0
ether3
Убиваем созданное
[admin@ R0]> /ip address> rem 2,3
[admin@ R0]> /ip address> pr
#
ADDRESS
NETWORK
INTERFACE
0
10.0.0.1/24
10.0.0.0
ether7
1
1.1.1.1/24
1.1.1.0
ether1
Это основной принцип. Интерфейс чрезвычайно мощный. Например, можно
фильтровать вывод
/ip address print where interface=ether1
Уничтожим все IP-адреса на интерфейсе ether2
/ip ad rem [find where interface=ether2]
Кроме того поддерживаются скрипты. Вот пример скрипта, который наряду с
IP-адресами выводит и MAC-адреса
foreach i in=[/ip address find] do={
:local intr [/ip address get $i interface];
:local addr [/ip address get $i address];
:local MAC [/int eth get [/int eth find name=$intr] mac-address] ;
:put ($addr." ".$intr." ".$MAC); }
При желании, изучите скриптинг самостоятельно по материалам
официального сайта wiki.mikrotik.com. Покажем лишь как добавить и запустить
скрипт
[admin@MikroTik]> /system script add
[admin@MikroTik]> /system script pr
0I name="script1" owner="admin" policy=ftp,reboot,read,write,policy,test, winbox,
password ,sniff, sensitive, api run-count=0 source=""
Наберём тест скрипта в редакторе gedit. Выделим его, поместим в карман и
вставим в редакторе скриптов RouterOS
edit 0 source
Сохраняем скрипт командой Ctrl o и выполняем
[admin@MikroTik]> /system script> run 0
Видим IP- и MAC-адреса интерфейсов
10.0.0.1/24 ether7 52:54:00:12:34:5C
1.1.1.1/24 ether1 00:00:AB:18:47:00
Импорт и экспорт топологий
Периодически делайте резервную копию, следуя нижеизложенной методике.
1. Рассмотрим скрипт /home/4all/makeGetBackup для создания в Ubuntu
резервной копии настроек маршрутизаторов топологии
36
grigoryev.victor@gmail.com http://vmg.pp.ua
#!/bin/bash
for ((i=$1;i<=$2;i++)) ;do
ssh admin@10.D.$i.1 "system backup save name=R$i"
sftp admin@10.D.$i.1:/R*
done
Цикл for организует перебор целых чисел в диапазоне от $1 до $2. Здесь $1 и
$2 – 1-й и 2-й аргументы этого скрипта. В цикле утилита ssh (secure shell) даёт
команду system backup save name=R$i маршрутизатору Mikrotik с адресом
10.0.$i.1 на сохранение конфигурации маршрутизатора в файл R$i , а команду sftp
забирает этот файл из Mikrotik в локальный файл в Ubuntu.
Заберите скрипт в свою папку projects, адаптируйте его под свою tap-сеть:
замените в скрипте символ D на номер своей tap-сети. Сделайте скрипт
исполняемым : chmod a+x makeGetBackup
Запустим в GNS3 топологию template. В нашей топологии tap-интерфейсы
имеют адреса 10.D.0.1, 10.D.1.1 ... 10.D.7.1. Чтобы забрать конфигурацию в Ubuntu
надо выполнить команду
./makeGetBackup 0 7
В текущей папке появятся файлы резервных копий R0.backup, R1.backup ...
R7.backup. Поместите файлы резервных копий вместе с топологией topology.net в
архив.
Для восстановления из Ubuntu конфигураций операционных систем
маршрутизаторов предлагается скрипт /home/4all/Restore
#!/bin/bash
for ((i=$1;i<=$2;i++)) ;do
scp R$i.backup admin@10.D.$i.1:
ssh admin@10.D.$i.1 "system backup load name=R$i"
done
Здесь команда scp безопасно копирует по сети файл резервной копии из Ubuntu
в Mikrotik. Команда ssh удалённо выполняет в Mikrotik команду system backup
load name=R$i восстановления конфигурации из резервной копии.
Сделайте скрипт исполняемым
chmod a+x Restore
Для восстановления топологии, следует разархивировать архив в пустую
папку, создать в этой папке папку working и, при необходимости, отредактировать
файл топологии. Из этого файла выясните имена тап-интерфейсов сетевых
устройств топологии. Откройте топологию в GNS3. В папке working появятся
пустые подпапки с именами равными именам устройств в топологии. Следуя
именам тап-интерфейсов, скопируйте в пустые папки новой топологии файлы
FLASH и SWAP из папок R0, R1 … R7 топологии template. Запустить топологию.
Запустите консоль с закладками для проверки доступности роутеров по протоколу
ssh. Далее выполните в папке с резервными копиями R0.backup, R1.backup ...
R7.backup скрипт ../Restore 0 7.
Отвечайте yes на вопросы Ubuntu относительно принятия сертификатов.
Маршрутизаторы подхватят конфигурацию и перегрузятся. В случае проблем
удалите файл known_hosts в папке .ssh. Все роутеры будут иметь ранее назначенные
37
grigoryev.victor@gmail.com http://vmg.pp.ua
имена R0, R1 … R7. Конфигурация топологии template восстановлена
2. В RouterOs есть пара команд export и import, позволяющая сохранять
конфигурацию в виде читаемого тестового файла команд и затем восстанавливать
их. Легко изменить вышеприведенные скрипты makeGetBackup и Restore в
скрипты makeGetExport и Import для экспорта и импорта конфигураций:
Скрипт makeGetExport:
#!/bin/bash
for ((i=$1;i<=$2;i++)) ;do
ssh admin@10.0.$i.1 "export compact file=E$i"
sftp admin@10.0.$i.1:/E*
done
Скрипт Import:
#!/bin/bash
for ((i=$1;i<=$2;i++)) ;do
scp E$i.rsc admin@10.0.$i.1:
ssh admin@10.0.$i.1 "import E$i"
done
Перед использованием скрипта Import следует в файлах команд E*.rsc
закомментировать команды назначения IP-адресов на tap-интерфейс ether7, так как
эти адреса не могут быть не назначены заранее. Роутеры не должны иметь никакой
конфигурации. Иначе вы не получите сообщения об успешном выполнении Script
file loaded and executed successfully. Скрипты
makeGetExport и Import
используются полностью аналогично скриптам из п.1.
О персональных компьютерах и свичах в топологиях
В качестве роутеров, персональных компьютеров (ПК) и свичей мы будем
использовать те же Mikrotik RouterOS. В топологии они будут различаться только
внешним видом (иконкой). При таком подходе роутер и ПК можно соединять друг с
другом как без свича, так и через свич.
Традиционно в GNS3 в качестве модели ПК используется отдельная
программа Virtual PC Simulator, которая моделирует 10 ПК. Модель ПК можно
соединять с роутером только через свич. Для этого модель ПК подключают по
протоколу UDP к облаку в GNS3. Облако соединяют со свичом в GNS3. И наконец,
свич соединяют с роутером.
ПК в Virtual PC Simulator потребляют меньше ресурсов, чем ПК в виде
RouterOS. Но при этом тратится более ценный ресурс – UDP порты, которые нам
крайне необходимы для организации многопользовательской работы.
Требования для сдачи работы
1. Довести до автоматизма процесс создания и настройки топологии first. При
этом следует продемонстрировать ввод команд в консоли RouterOS всеми
шестью способами.
2. На примере топологии first продемонстрировать умение работать с
командным интерфейсом и скриптами RouterOS
3. Для топологии template продемонстрировать два способа сохранения
резервной копии и восстановления из неё.
4. Предъявить консоль с закладками.(табами).
38
grigoryev.victor@gmail.com http://vmg.pp.ua
3. Настройка домашнего компьютера
Подключение с помощью протокола Openvpn
Работа c GNS3 в Windows
Удалённый доступ к Ubuntu
Установка Ubuntu
Установка Qemu
Установка GNS3
Установка tap-интерфейсов
Установка Winbox
Подключение из домашнего Ubuntu по Openvpn и удаленный доступ
Доступ к удалённому маршрутизатору из домашнего компьютера
39
40
41
42
44
46
46
47
48
49
Подключение с помощью протокола Openvpn
К виртуальным лабораториям кафедры организован доступ из Интернета с
помощью протокола Openvpn.
Вначале следует открыть один из сайтов,
расположенных на компьютере Lib, например eom.pp.ua. Далее проверьте
доступность компьютера
ping 212.3.125.93
Ответ от 212.3.125.93: число байт=32 время=51мс TTL=56
Ответ от 212.3.125.93: число байт=32 время=46мс TTL=56
Ответ от 212.3.125.93: число байт=32 время=46мс TTL=56
Ответ от 212.3.125.93: число байт=32 время=46мс TTL=56
Если время задержки будет более 300 мс, то у Вас плохой интернет в сторону
сети университета.
Проверим
наличие
службы
Openvpn
на
удалённом
хосте
telnet 212.3.125.93 8002
Пример отсутствия службы
Connecting To 212.3.125.93 ...Could not open connection to the host, on port 8002:
Connect failed
При наличии службы вы увидите чистый чёрный экран. При неудаче –
проверьте настройки своего фаервола.
Выкачайте OpenVPN с сайта производителя и установите его. Получите у
преподавателя конфигурацию и сертификаты. Отредактируйте конфигурацию и
подключитесь по OpenVPN к компьютеру Lib, следуя инструкции из первой
лабораторной работы. В файле конфигурации закомментируйте строку dev-node,
поставив перед ней #.
Другой конец Openvpn-соединения находится в Windows server 2008 R2 на
компьютере LIB и имеет адрес 192.168.3.1. Проверим связь с OpenVPN-сервером
на компьютере LIB
ping 192.168.3.1
Ответ от 192.168.3.1: число байт=32 время=51мс TTL=128
Ответ от 192.168.3.1: число байт=32 время=104мс TTL=128
Ответ от 192.168.3.1: число байт=32 время=238мс TTL=128
Ответ от 192.168.3.1: число байт=32 время=51мс TTL=128
39
grigoryev.victor@gmail.com http://vmg.pp.ua
Если пинги не идут, проверим маршруты. Если время задержки будет более
300 мс, то работа будет некомфортной.
Проверим маршруты
Route print
Должна быть строка маршрута в сторону Ubuntu (192.168.0.2)
192.168.0.2 255.255.255.255 … 192.168.3.1 192.168.3.105
Этот маршрут даёт вам Openvpn сервер. Если её нет, то добавьте маршрут
вручную
Route add 192.168.0.2 mask 255.255.255.25 192.168.3.1
Проверим связь с Ubuntu
ping 192.168.0.2
Делаем службу Openvpn, если она не создалась при инсталляции. Для этого с
помощью команды смены папки cd идём в папку Openvpn\bin и запускаем команду
runas /user:администратор "Openvpnserv -install"
Вводим пароль администратора. Открываем администрирование - службы,
запускаем службу openvpn в режиме автозапуска.
Теперь при включении
компьютера вы автоматически соединитесь с Ubuntu.
Работа c GNS3 в Windows
Можно работать c GNS3 и в Windows, выкачав инсталляцию с сайта gns3.net.
К сожалению, на многоядерных процессорах используется только одно ядро и
поэтому GNS3 в Windows работает медленнее, чем в Linux. В целом GNS3 в
Windows работает менее стабильно, чем в Linux.
Далее делаем так же, как и в Linux (см. предыдущую лабораторную работу).
Заходим в папку GNS3. Работаем с командной строкой. Создадим пустой образ
виртуального диска формата qcow2 размером 111mb:
qemu-img create -f qcow2 mikrotik-5.14.img 111M
В Qemu под Windows при старте маршрутизатора стартует и VNC –клиент. В
виртуальной машине Qemu из CD-образа mikrotik-5.14.iso установим RouterOS на
образ виртуального диска mikrotik-5.14.img:
qemu mikrotik-5.14.img -cdrom mikrotik-5.14.iso -boot d
Снова запускаем
qemu mikrotik-5.14.img
Настраиваем GNS3 так же, как мы это делали в Linux. Перетаскиваем c левой
панели на центральную панель пару маршрутизаторов Mikrotik и соединяем их
Ethernet-интерфейсы. Назначаем адреса и пингуем.
При желании можно настроить tap-интерфейсы. С помощью Оpenvpn (раздел
утилиты) создайте пару сетевых tap-интерфейсов. При этом разрешайте установку
непроверенных драйверов. Переименуйте существующий tap-интерфейс в Ovpn
(Пуск – Подключения). Далее следует переименовать новые tap-интерфейсы в tap0
и tap1. Назначьте на эти интерфейсы адреса : 10.0.0.2/24 и 10.0.1.2/24. Строка
подключения маршрутизатора к интерфейсу tap0 (tap1) в Qemu будет короче, чем в
Linux:
-net nic,vlan=7 -net tap,vlan=7,ifname=tap0 (-net nic,vlan=7 -net
tap,vlan=7,ifname=tap1).
40
grigoryev.victor@gmail.com http://vmg.pp.ua
Далее надо в маршрутизаторе определить какой
его ethernet-интерфейс
соответствует tap-интерфейсу. Для этого в VNC –клиенте нажимаем ctrl alt 2 и
вводим info network. Запоминаем MAC-адрес tap-интерфейса. Нажимаем ctrl alt 1 и
возвращаемся в консоль маршрутизатора. Набираем в маршрутизаторе int eth
print. Смотрим по MAC-адресу, какой из ethernet-интерфейсов соответствует tapинтерфейсу. Помня, что VNC –клиент захватывает мышь, освобождаем её
нажатием комбинации клавиш ctrl и alt .
В файле конфигурации OpenVPN следует убрать знак # в начале строки devnode и указать далее имя существующего tap-интерфейса Ovpn, который вы будете
использовать для OpenVPN.
Удалённый доступ к Ubuntu
Удалённый Ubuntu запущен по адресу labs.mikrotik.com.ua и внутри Hyper-V
по адресу 192.168.0.2. Проверим доступность удалённой системы Ubuntu
ping labs.mikrotik.com.ua (192.168.0.2)
Для передачи файлов воспользуйтесь протоколом FTP (File Transfer Protocol).
Например, вызовите cmd.exe и введите ftp labs.mikrotik.com.ua (192.168.0.2). Далее,
следуя инструкции из предыдущей работы, попробуйте выгрузить и загрузить
произвольный небольшой файл, скажем abc.txt.
Для удалённого доступа к командной строке широко используется протокол
SSH (Secure Shell). Для Windows есть уникальная утилита putty, выполняющая
функции Ssh-клиента. Putty входит в состав Gns3. Укажите в putty имя
пользователя, адрес labs.mikrotik.com.ua (192.168.0.2), протокол ssh
и
подключитесь к командной строке Ubuntu. Запустите второй экземпляр putty для
адреса 192.168.0.2 (labs.mikrotik.com.ua) и подключитесь к командной строке
второго Ubuntu. Обменяйтесь файлом abc.txt между двумя Ubuntu с помощью
протоколов FTP и ssh (scp).
Для удалённого доступа к рабочему столу Ubuntu следует выкачать с сайта
производителя программу NX Client for Windows и установить её. Запустим
мастер подключения nxclient в котором в поле session введём произвольное имя
сессии, в поле
host введём адрес удалённого Ubuntu labs.mikrotik.com.ua, в
следующем поле можно установить ADSL, в следующем окне установим менеджер
окон GNOME и создадим ярлык. Запустим сессию с помощью ярлыка NX client for
windows. Введём имя и пароль, согласно номера студента V, например для номера
D=1 login: student1 и password: student1. Нажимаем Login. Ждём соединения с
Ubuntu. Возможно, придётся ждать несколько минут и вы в Ubuntu.
Всегда держите открытыми окна пингов в сторону адресов лабораторий и
вашего провайдера Интернет. Если работа с nxclient станет некомфортной, то
смотрите на задержки в этих окнах. Если велика задержка (более 300 мс) к адресу
вашего провайдера, то вы что-то закачиваете или выкачиваете. Если велика
задержка в сторону 212.3.125.93, то стал плохим интернет в сторону сети
университета. Если велика задержка в сторону 192.168.0.2 – то перегружен
удалённый Ubuntu, 192.168.3.1 – перегружен Windows в ауд. 12/310.
Установка Ubuntu
Ubuntu
можно установить либо на реальный компьютер, либо на
виртуальную машину. В качестве виртуальной машины можно воспользоваться
41
grigoryev.victor@gmail.com http://vmg.pp.ua
бесплатными продуктами Vmware player фирмы Vmware или VirtualBox фирмы
Oracle.
Мы будем работать с виртуальной машиной Qemu и запускать под ней
операционные системы маршрутизаторов. Опыт показывает, что Qemu в Ubuntu
под виртуальной машиной (Vmware player или VirtualBox ) работает быстрее и
стабильнее, чем Qemu в реальном Windows. Однако даже на хорошем компьютере
Ubuntu под виртуальной машиной не справляется с сетевой топологии из 5-6
маршрутизаторов. Поэтому настоятельно рекомендуется поставить Ubuntu на
реальный компьютер.
Для работы с Ubuntu необходим хороший Интернет. Всё необходимое вам
программное обеспечение Ubuntu берёт из Интернета и инсталляции программных
продуктов в виде файлов или дисков (как в Windows) практически не применяются.
Хотя есть выход – см. конец раздела.
Инсталяцию Ubuntu можно взять с сайта производителя. Берите инсталяцию
10.0.43 с долговременной поддержкой (LTS-Long Term Support) (http://oldreleases.ubuntu.com/releases/lucid/ubuntu-10.04-desktop-i386.iso
или
http://oldreleases.ubuntu.com/releases/lucid/ubuntu-10.04-desktop-amd64.iso).
Она
уже
устоялась и более стабильна.
На сайте вы увидите инсталляции серверные и desktop (Рабочий стол). Нам
для работы понадобится рабочий стол. Поэтому остановимся на инсталляции
desktop. Desktop-Ubuntu может послужить вам как альтернатива Windows.
Серверная версия Ubuntu вообще не имеет графического интерфейса, а его
самостоятельная установка вызовет у вас затруднения.
Если у вас памяти больше, чем 4Г и вы поставите 32-разрядную систему, то
она увидит только 4Г памяти. 64-разрядная система увидит всю память. 64разрядная операционная система работает быстрее, чем 32-разрядная только для
64-разрядных приложений и при значительных объёмах памяти. При малых
объёмах памяти (меньше чем 4Г ) 32-разрядная операционная система работает
быстрее, чем 64-разрядная.
Количество 32-разрядных приложений значительно превышает количество
64-разрядных приложений.
Если у вас памяти не менее, чем 4Г, то берите для установки инсталяцию
desktop 64 разряда. Иначе берите для установки инсталляцию desktop 32 разряда
даже если у вас 64-разрядный процессор. Выбор за вами.
Надо минимум 2 свободных раздела диска и не обязательно главных. Один
раздел надо под корневую файловую систему и второй для свопинга (подкачки).
Для первого раздела будет достаточно 30-40Г. Для свопинга рекомендуется размер
равный удвоенному размеру памяти. Разделы можно либо создать на втором новом
чистом диске либо подвинуть существующие разделы на имеющемся диске и
создать новые. Перед передвижением разделов диске следует его
дефрагментировать. Для передвижения и создания разделов следует
воспользоваться утилитой Gparted из инсталляции Ubuntu в режиме LiveCD..
Будьте осторожны и обязательно перед передвижением разделов сохраните в
безопасном месте ценную для вас информацию.
42
grigoryev.victor@gmail.com http://vmg.pp.ua
Во время установки обязательно не забудьте выбрать ручной режим разбивки
диска. Будьте внимательны, установите Ubuntu в нужные разделы и не испортите
своего Windows7. При определении пользователя используйте короткий пароль,
так как далее придётся часто его вводить. Выберите режим входа в систему без
ввода пароля. В качестве места установки менеджера загрузок операционных
систем Grub выберите MBR (master boot record) нужного диска. После установки и
перегрузки компьютера вы увидите меню Grub, в котором вы сможете выбрать,
какую операционную систему грузить: Ubuntu или старую Windows7.
Установка Ubuntu на компьютер с WindowsXP требует дополнительных
настроек загрузки
После установки вы увидите графический экран. У вас в запасе ещё 6
текстовых экранов. Переключение между экранами осуществляется комбинацией
клавиш CtrlAltF1, CtrlAltF2 … CtrlAltF7. Комбинация CtrlAltF7 закреплена за
графическим экраном.
Сразу после установки и далее регулярно обновляйте операционную систему
через пункт верхнего меню System – administration-Update manager. Первое
обновление при хорошем Интернете длится около часа.
Добавим иконку запуска терминала в верхнюю панель (applicationsaccessories-terminal-правая кнопка мыши -add to panel). Нажмите на верхней панели
правую кнопку мыши, выберете add to panel и добавьте программы System monitor
и Windows selector .
Используйте в терминале возможности мыши для работы с буфером обмена
(copy-paste) и не забывайте, что в терминале можно создавать закладки (file-open
tab)
Сделаем краткий обзор команд linux. В отличие от Windows Linux различает
маленькие и большие буквы. Смена папок осуществляется командой cd ИмяПапки.
Родительская папка имеет имя «..», текущая - «.», а корневая –«/». Просмотр
содержимого папки выполняется командой ls или, если подробно ls –l. Последняя
команда выводит права доступа к файлам. Если вы имеете право доступа на
выполнения файла abc в текущей папке def, то запустить его на выполнение можно,
введя ./abc. Перейдя в родительскую папку (cd ..), нам для выполнения abc надо
будет ввести def/abc.
В Linux есть переменная окружения PATH. Посмотреть её значение можно
командой echo $PATH. Это значение содержит перечень папок. Все исполняемые
файлы из папок, указанных в PATH запускаются на выполнение без указания
полного пути к ним. Так, если бы файл abc лежал бы в такой папке, то для его
выполнения следовало бы просто ввести abc. Текущая папка при этом значения не
имеет.
Копирование (перемещение) файлов и папок осуществляется командами
cp (mv) источник приёмник
Используются шаблоны имён типа abc*cde*. Для работы с конкретным
файлом или папкой можно не вводить всего его имени, а попытаться подобрать
уникальный шаблон. Например, если в папке файл abc, является единственным
файлом, имя которого начинается с буквы «а», то вместо имени abc можно
использовать шаблон a*.
43
grigoryev.victor@gmail.com http://vmg.pp.ua
Установка софта производится через пункт меню system – administration synaptic package manager или из командной строки. Установите файловый
менеджер
sudo apt-get install mc
Команда sudo приводит к выполнению следующей за ней команды apt-get в
режиме суперпользователя root и потребует пароль, который вы указали при
инсталляции Ubuntu.
Для редактирования текстовых файлов пользуйтесь редактором nano
ИмяФайла или встроенным редактором файлового менеджера mc, который
вызывается нажатием клавиши F4.
Инсталляции программ для Ubuntu оформлены в виде .deb-файлов. При
инсталляции программ Ubuntu берёт из Интернета необходимые .deb-файлы и
хранит их в папке /var/cache/apt/archives. Если у вас плохой Интернет, то попросите
эту папку у того у кого Интернет хороший и кто полностью настроил Ubuntu
согласно этой лабораторной работе.
Можно выкачать нужные .deb-файлы и на сайте packages.ubuntu.com. На сайте
можно увидеть, от каких других deb-файлов зависит конкретный deb-файл.
Установка программы из .deb-файла осуществляется командой
sudo dpkg –i файл.deb
Если файл.deb зависит от других deb-файлов, то их также надо иметь под
рукой. Эти другие deb- файлы могут зависеть от третьих deb- файлов и т.д.
Программа apt-get install автоматически осуществляет поиск в Интернет всех
нужных deb-файлов..
Установка Qemu
Если вы ставите Ubuntu не в виртуальной машине, то проверьте, поддерживает
ли ваш процессор аппаратную виртуализацию. Для Intel
cat /proc/cpuinfo|grep vmx
Для Amd
cat /proc/cpuinfo|grep svm
Если вы увидите число строк более 0, то установите KVM (kernrl virtual
machine-виртуальную машину на уровне ядра)
sudo apt-get install kvm
Проверьте установку командой lsmod|grep kvm
Вы должны увидеть нечто подобное
kvm_intel
39416 0
kvm
245573 1 kvm_intel
Проверьте установку также командой modinfo kvm. Вы должны увидеть нечто
подобное
filename:/lib/modules/2.6.32-36-generic/kernel/arch/x86/kvm/kvm.ko
license:
GPL
author:
Qumranet
srcversion: 16E69C2C619C7884ECEDAE1
depends:
vermagic: 2.6.32-36-generic SMP mod_unload modversions 586
44
grigoryev.victor@gmail.com http://vmg.pp.ua
parm:
oos_shadow:bool
parm:
ignore_msrs:bool
Проверьте появление нового устройства kvm в папке /dev. ls /dev/kvm
Запустим qemu следующим образом
qemu -net udp
и увидим
Invalid -net type 'udp'
qemu не поддерживает UDP. Именно благодаря UDP в GNS организуется
связь маршрутизаторов между собой. То есть стандартная qemu нам не подходит.
На сайте http://www.gns3.net/download есть патчи для 13-й версии Qemu,
обеспечивающие поддержку
UDP. Скачиваем эти патчи, а также берём
соответствующую версию Qemu по ссылке http://wiki.qemu.org/download/qemu0.13.0.tar.gz
Установите утилиту patch
sudo apt-get install patch
Выбираем в верхней панели Places – Download и распаковываем два архива,
наведя на них курсор мыши и выбрав нужный пункт в контекстном меню. Патч
Qemu-0.13.0-mcast-udp.patch из архива помещаем в ту же папку, где находится
появившаяся после распаковки архива папка qemu-0.13.0. Патчим Qemu, набирая в
терминале
patch -p0 < qemu-0.13.0-mcast-udp.patch
Видим
(Stripping trailing CRs from patch.)
patching file qemu-0.13.0/Makefile.objs
…
(Stripping trailing CRs from patch.)
patching file qemu-0.13.0/block/raw-win32.c
Содержимое папки net (файлы udp.c и udp.h) из новой папки qemu0.13.0.patched помещаем в папку net папки qemu-0.13.0. Входим в папку qemu0.13.0 и выполняем команду
./configure --enable-kvm --target-list=i386-softmmu
Команда configure готовит qemu для построения (компиляции и компоновки).
Ключ enable-kvm включает поддержку kvm в qemu. Qemu поддерживает
практически все аппаратные платформы. Нам надо построить Qemu только для 32разрядных процессоров Intel. В этом нам поможет ключ --target-list=i386-softmm.
Команда не выполнится в виду отсутствия библиотеки zlib
Error: zlib check failed
Make sure to have the zlib libs and headers installed.
Ставим эту библиотеку
sudo apt-get install zlib1g-dev
Снова запускаем
./configure --enable-kvm –target-list=i386-softmmu
Видим
KVM support
yes
45
grigoryev.victor@gmail.com http://vmg.pp.ua
Строим qemu
make
и устанавливаем
sudo make install
Проверяем установку, запуская qemu
qemu -net udp
Видим
Segmentation fault
Мы не в видим сообщение о том, что qemu не поддерживает UDP. Снова
запускаем qemu. Видим желаемое сообщение
VNC server running on `127.0.0.1:5900'
Виртуальная машина Qemu общается с внешним миром через протокол VNCVirtual Network Computing. Запускаем VNC –клиент (applications-internet-remote
desktop viewer-connect-protocol VNC-host 127.0.0.1:5900-connect). Видим, что нет
загрузочного диска (boot disk) операционной системы. Его мы ещё не сделали.
Установка GNS3
Берём с http://sourceforge.net/projects/gns-3/files/GNS4/0.7.3 архив GNS3-0.7.4src.tar.gz. Не берите более новые версии. Будут проблемы совместимости GNS3 и
нашей нестандартной установки qemu. Распаковываем архив GNS3-0.7.4-src.tar.gz.
Входим в консоли в новую папку и устанавливаем GNS3
sudo python setup.py install
Инсталлятор создаст файл для запуска GNS3. Скорее всего, это будет файл
/usr/local/bin/gns3. Имя и расположение файла для запуска GNS зависит от версии.
Обратите внимание, куда инсталлятор поместит файл qemuwrapper.py. Он нам
понадобится позже.
Входим в консоли в папку, где находится файл для запуска GNS3 и запускаем
его, например ./gns3. Cкорее всего видим сообщение об отсутствии нужного
программного обеспечения Can't import Qt modules, PyQt is probably not
installed.
Осуществляем необходимую установку из командной строки
sudo apt-get install python-qt4
Теперь GNS3 запустится. Поместите в верхнюю панель ссылку на файл gns3
для запска GNS3.
Следуя предыдущим разделам, установите под qemu операционную систему
RouterOS и настройте GNS3.
Установка tap-интерфейсов
Для связи маршрутизаторов Mikrotik, работающих под Qemu с внешним
миром необходимо установить в Ubuntu tap-интерфейсы, которые есть в пакете
openvpn. Установите пакет вместе с пакетом bridge-utils . Затем меняем /etc/rc.local.
У вас tap-сеть 5.
sudo gedit /etc/rc.local
#!/bin/sh -e
ifs="00 01 02 03 04 05 06 07 10 11 12"
for i in $ifs; do
46
grigoryev.victor@gmail.com http://vmg.pp.ua
openvpn --mktun --dev tap5$i
brctl addbr br5$i
brctl addif br5$i tap5$i
ifconfig tap5$i up
ifconfig br5$i 10.5.$i.2 netmask 255.255.255.0 up
done
exit 0
Этот файл выполняется при старте Ubuntu. Объясним его работу. Команда
openvpn создаёт в цикле for tap-интерфейсы tap500, tap501 … tap512. Команда brctl
addbr создаёт мосты. Команда brctl addif добавляет tap-интерфейсы в мост. Первая
команда ifconfig поднимает tap-интерфейс. Следующая команда ifconfig назначает
IP-адресс мосту и поднимает его. Выполняем
sudo /etc/rc.local
Наберите в консоли ubuntu
brctl show|more
Видим, что tap-интерфейсы лежат в мостах.
Проверяем интерфейсы
ifconfig|more
Должны увидеть, что создались интерфейсы tap* и мосты br* с адресами
10.5.*.2 здесь * это 00 01 … 19
При переносе топологий между домашним и университетским компьютером
не забудьте в файле конфигурации сетевой топологии topology.net изменить имена
tap-интерфейсов согласно своему номеру D tap-сети.
Обеспечим проброс IP-пакетов, то есть превратим Ubuntu в маршрутизатор.
Для этого раскоментируйте строку #net.ipv4.ip_forward=1 в файле /etc/sysctl.conf
и перегрузитесь
Установка Winbox
Ставим wine для запуска исполняемых файлов Windows в Linux.
sudo apt-get install wine
Процесс занимает значительное время. Попутно установятся шрифты
TrueType. Скачиваем Winbox с сайта mikrotik.com. Даём всем права на его
выполнение
chmod a+x winbox.exe.
Поместите в верхнюю панель ссылку на этот файл. Запустите Winbox .
Подключение из домашнего Ubuntu по Openvpn и удаленный доступ
Можно из домашнего Ubuntu подключаться по Openvpn к университетским
Ubuntu по адресам 192.168.0.2 и 192.168.0.254 . Для подключения по Openvpn,
полученные файлы сертификатов следует положить в папку /etc/openvpn.
Отредактируйте файл client.ovpn, переименуйте его в /etc/client.conf и
закомментируйте строку dev-node tap. Старт (стоп)
службы оpenvpn
осуществляется командой sudo /etc/init.d/openvpn start (stop ). Командой ping
проверьте связь домашнего Ubuntu с адресами 192.168.0.2 и 192.168.0.254.
47
grigoryev.victor@gmail.com http://vmg.pp.ua
Если вы хотите получить доступ только к командной строке Ubuntu,
воспользуйтесь безопасным шелом ssh, например
ssh studentD@192.168.0.2, где D – ваш номер.
Установите на свой компьютер службы ftp и ssh
sudo apt-get install ftpd
sudo apt-get install openssh-server
Находясь внутри удалённой Ubuntu с адресом 192.168.0.2, откройте терминал
и в нём наберите
ftp Openvpn-адрес-вашего-компьютера.
Выгрузите и загрузите какой-нибудь файл.
Для передачи файлов часто используют безопасное копирование по протоколу
SSH с помощью команды scp. Например, поэкспериментируйте из дома с
командами
scp файл studentD@192.168.0.2:файл
scp studentD@192.168.0.2:файл файл
scp файл studentD@labs.mikrotik.com.ua:файл
scp studentD@ labs.mikrotik.com.ua:файл файл
Зайдите на labs.mikrotik.com.ua или Ubuntu компьютера Lib с помощью ssh и
снова поэкспериментируйте
scp файл name@адрес-вашего-компьютера:файл
scp nameD@адрес-вашего-компьютера:файл файл
Здесь name-имя с которым вы зашли в свой Ubuntu.
Для доступа к удалённому рабочему столу следует с сайта
www.nomachine.com из Интернета скачать nxclient и установить его
dpkg -i nxclient-*.deb
или воспользуйтесь в Ubuntu штатной программой qtnx – клиентом nx-сервера.
Заметим, что qtnx даже при сжатии jpeg, медленнее прорисовывает экран, чем
nxclient.
Настройте два ярлыка nxclient для доступа по адресам 192.168.0.2 и
labs.mikrotik.com.ua.
Доступ к удалённому маршрутизатору из домашнего компьютера
И для Windows и для Ubuntu имеется возможность из локального
компьютера подключаться к удалённому маршрутизатору Mikrotik, работающему
внутри qemu в Ubuntu на компьютере Lib. При плохой сети работа с удалённым
Linux-десктопом через NX клиента может быть некомфортной. Поэтому можно
ограничить роль NX только сбором и запуском топологии.
Если студента D имеет номер tap-сети V, то все адреса tap-интерфейсов
маршрутизаторов mikrotik должны лежать в этой сети
10.V.0.0/24. В
конфигурации Openvpn сервера на компьютере Lib для сертификата студента D
есть строка push "route 10.V.0.0 255.255.0.0". Поэтому после Openvpn-соединения
вы получаете маршрут в сторону своей tap-сети.
48
grigoryev.victor@gmail.com http://vmg.pp.ua
Выполняем на своём компьютере команду (после Openvpn соединения)
команду
netstat -r и видим (при V=2) строку
Для Windows
NetworkDest
Netmask
Gateway
Interface Metric
10.2.0.0
255.255.0.0 192.168.3.1 192.168.3.105
30
Для Ubuntu
Destination Gateway
Genmask Flags MSS Window irtt Iface
10.2.0.0
192.168.3.1 255.255.0.0 UG
00
0 tun0
Эти строки показывают, что от вас есть маршрут на tap-сеть 10.2.0.0/16. Здесь
192.168.3.1-адрес tap-интерфейса на Lib. Теперь внутри маршрутизатора Mikrotik
на удалённом Ubuntu
надо установить обратный маршрут на домашний
компьютер. Если tap интерфейс маршрутизатора Mikrotik имеет адрес 10.2.0.1, то в
консоли маршрутизатора надо дать команду
ip route add
dst-address=192.168.3.105/32 gateway=10.2.0.2
Здесь 10.2.0.2 - адрес tap-интерфейса в удалённой Ubuntu. 192.168.3.105— ваш
адрес в Openvpn. Мы увидим наш домашний компьютер из консоли Mikrotik на
удалённом Ubuntu: ping 192.168.3.105. Мы видим адрес маршрутизатора со своего
компьютера: Ping 10.2.0.1. Мы можем конфигурировать этот маршрутизатор,
запустив на своей машине Winbox или ssh (putty) и указав адрес 10.2.0.1.
Если связь совсем плохая и не удаётся войти на удалённый рабочий стол, то
можно стартовать топологию через командную строку, после соединения по ssh
export DISPLAY=:2000.0
gns3.pyw topology.net&,
предварительно изменив с помощью редактора nano в файле topology.net режим
запуска на автостарт autostart = True. Соединяётесь с консолями роутеров по ssh
(putty) и настраивайте их без графического интерфейса.
Конфигурация по
подключению к удалённому маршрутизатору Mikrotik,
работающему внутри qemu в Ubuntu в аудитории 12/211 (192.168.0.254) не
производилась.
Требования для сдачи работы
1. Соберите и запустите в Gns3 под Windows торологию first. Сравните время
загрузки по сравнению с Ubuntu.
2. Предъявить в виде скриншота доказательство подключения программ NX
Client for Windows и putty со свого домашнего компьютера к своему рабочему
столу в Ubuntu на компьютере lib (192.168.0.2) и в Ubuntu по адресу
labs.mikrotik.com.ua. Скриншоты поместить на рабочие столы тех компьютеров, на
которые вы удалённо зашли. Пример скриншота для адреса 192.168.0.2 приведен
на рис. 3.1
3. Предоставить в виде скриншота доказательство того, что вы со своего
домашнего компьютера зашли через winbox в маршрутизатор Mikrotik в топологии
first на компьютере Lib. На скриншота должен присутствовать вывод команды
ipconfig домашнего компьютера (рис. 3.2).
49
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 3.1 Пример скриншота. Скриншот доказывает подключения программ NX Client for
Windows и putty со своего домашнего компьютера к своему рабочему столу в Ubuntu по
адресу 192.168.0.2 (1). Пользователь p (2). Адрес домашнего компьютера 192.168.1.2 (3).
OpenVPN-адресс равен 192.168.3.100 (4). Имя Ubuntu – u10034bbb071 (5). Фотография (6).
Рабочий стол домашнего компьютера (7).
4. Запустить топологию first на компьютере Lib с помощью ssh (putty) без
использования NX-клиента. Со своего домашнего компьютера зайдите в консоли
роутеров с помощью ssh (putty).
5. Ни разу не воспользовавшись NX-клиентом для Ubuntu на компьютере Lib:
а. Создайте новую топологию first1, перенеся только файл topology.net
топологии first в новую папку first1. Создайте в папке first1 папку working.
б. Запустить топологию first1 с помощью ssh (putty) без использования NXклиента. Настройте tap-интерфейсы роутеров через команду
telnet 127.0.0.1 ПортКонсоли,
которую запускайте в окне ssh (putty).
в. Со своего домашнего компьютера зайдите через winbox в маршрутизатор
Mikrotik в топологии first1. Настройте топологию first1 так же как и топологию
first.
50
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 3.2
51
grigoryev.victor@gmail.com http://vmg.pp.ua
4. Настройка типовой сети
DNS
DHCP
NAT
ARP
Фаервол (Firewall)
Ограничение скорости
Web-прокси
HotSpot
55
56
58
59
60
61
61
64
Собираем топологию, соединив указанные на рис.4.1 сетевые
порты.
Добавьте к топологии заметки так, чтобы она выглядела так же, как и рисунок.
Рис.4.1. Топология
Обеспечим возможность конфигурации роутеров с использованием tapинтерфейсов. Для этого в каждом роутере добавим опции Qemu
Client: -net nic,vlan=6 -net tap,script=no,downscript=no,vlan=6,ifname=tapV00
Station -net nic,vlan=6 -net tap,script=no,downscript=no,vlan=6,ifname=tapV01
AP
-net nic,vlan=6 -net tap,script=no,downscript=no,vlan=6,ifname=tapV02
Internet -net nic,vlan=6 -net tap,script=no,downscript=no,vlan=6,ifname=tapV03
где V – номер вашей tap-сети.
Во избежание конфликтов с другими студентами изменим в файле topology.net
порты для консолей (строка console=Порт) 3000+D*100
Client:
3000+D*100
Station
3000+D*100+1
AP
3000+D*100+2
Internet
3000+D*100+3
где D – ваш номер.
Запустим топологию. После запуска всех роутеров откроем в терминале
Ubuntu четыре закладки и в каждой из них откроем консоль роутера командой
(D=7)
telnet 127.0.0.1 3700
…
telnet 127.0.0.1 3703
После назначения IP-адресов на тап-интерфейсы маршрутизаторов вместо
telnet используйте ssh, как описано в разделе 2 (см. рис. 2.5).
Назначим имена маршрутизаторам. Например, для роутера Client введём
команду
system identity set name= Client
Скопируйте эту команду в карман, вставьте в консоль остальных роутеров,
исправьте имя и выполните.
52
grigoryev.victor@gmail.com http://vmg.pp.ua
Командой inrerface print проверьте, что каждый роутер увидел tap-интерфейс,
как интерфейс ether7. То есть интерфейсов должно быть семь. Проверим, что
роутеры видят соседей.
[admin@Station] > ip neighbor print
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether2
52:54:00:12:34:5C
Client 5.14
x86
1 ether1
52:54:00:12:34:5C
Station 5.14
x86
2 ether2
00:AA:00:9F:F3:00
Client 5.14
x86
3 ether6
00:AA:00:6C:EE:05
AP
5.14
x86
4 ether7
00:00:AB:39:92:00
Station 5.14
x86
Роутер Station видит роутер Client через ether2 (e1) и роутер AP через ether6
(e51) (см. рис.4.1).
Назначим IP-адреса на интерфейс ether7 роутеров.
Client 10.V.0.1/24
Station 10.V.1.1/24
AP
10.V.2.1/24
Intrernet
10.V.3.1/24
где V – номер вашей tap-сети.
Откроем закладку AP в консоли Ubuntu. Закрепим знания командного
интерфейса RouterOS. Для получения справки нажмите табуляцию. Более
подробная справка выводится после нажатия знака ?. . Подменю выведутся синим
цветом, а команды - красным. При двойном нажатии табуляции вы также увидите
команды и операторы встроенного языка скриптов. Для входа в подменю надо
набрать его имя. Для входа в более низкие уровни подменю следует набирать через
пробел имена меню, идущие к цели. Для перехода в родительское меню
используют .., а для перехода в корневое меню - /. например
[admin@AP] > ip address
[admin@AP] /ip address>
[admin@AP] /ip address> ..
[admin@AP] /ip> address
[admin@AP] /ip address> /
[admin@AP] >
Назначим адрес (V=0)
[admin@AP]>ip address add address=10.0.2.1/24 interfac=ether7
Меню и команды определяются первыми уникальными символами их
названий, поэтому следующий ввод эквивалентен предыдущему
[admin@AP ] > ip ad ad ad= 10.0.2.1/24 in=ether7
failure: already have such addres
Routeros путём смены цвета даёт знать, когда он понял очередную порцию
ввода и можно переходить к новой порции ввода. Команды можно вводить из
разных уровней подменю
[admin@AP] > ip
[admin@AP] /ip>ad ad ad=10.0.2.1/24 in=ether7
failure: already have such addres
Покажем как редактировать введённые команды. Вначале удалим команду.
53
grigoryev.victor@gmail.com http://vmg.pp.ua
Нам надо знать её номер.
[admin@AP] >ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
0 192.168.1.103/24 192.168.1.0 ether5
Её номер # равен 0. Удаляем команду.
[admin@AP] >ip ad rem 0
Проверяем
[admin@AP] >ip address print
Введём команду с неправильным именем интерфейса
[admin@AP ] > ip ad ad ad= 10.0.2.1/24 in=ether4
Поменяем имя интерфейса на ether7. Нам надо знать номер неправильной
команды. [admin@AP] >ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
0 192.168.1.103/24 192.168.1.0 ether4
Меняем, указывая номер 0
[admin@AP ] > ip ad set 0 in=ether7
Установите адреса в остальных роутерах. Для каждого роутера проверьте
связь с Ubuntu , например, при V=0
[admin@Client] >ping 10.0.0.2
…
[admin@Intrernet] >ping 10.0.3.2
Из Ubuntu проверьте связь с адресами 10.0.0.1, 10.0.1.1, 10.0.2.1 10.0.3.1
роутеров.
Рис.4.2. Экземпляр winbox
Откроем winbox. Вводим в поле ConnectTo адрес 10.0.0.1 роутера Client,
нажимаем Save и Connect. Winbox должен зайти в роутер Client. Запускаем ещё
три экземпляра winbox и аналогично подключаемся к остальным роутерам.
Запустив пятый экземпляр winbox вы должны увидеть то, что изображено на
54
grigoryev.victor@gmail.com http://vmg.pp.ua
рис.4.2 (V=0)
Если вы установили в верхнюю панель Ubuntu ярлык для запуска селектора
окон, то этот селектор должен выглядеть приблизительно так (рис.4.3)
Рис.4.3. Селектор окон
В GNS интерфейс e0 роутера AP соединён с интерфейсом e0 роутера Internet.
Интерфейс e0 в GNS соответствует интерфейсу ether1 внутри роутеров. Назначьте
адреса 1.1.1.2/24 и 1.1.1.1/24 на этот интерфейс ether1 роутеров AP и Internet,
соответственно. Тем самым мы обеспечили связь по протоколу IP. Проверьте связь
с помощью команды пинг в winbox (Tools->Ping).
DNS
Сделаем роутер AP сервером имён DNS. Для этого выберем IP->DNS,
установим галочку Allow remote requests и в поле Servers введём адрес 1.1.1.2.
Далее нажимаем кнопку Static и задаём две строки
РоутерName
Addess
AP
a.in
1.1.1.2
Internet
i.in
1.1.1.1
Открываем в winbox терминал и проверяем
[admin@AP] > ping i.in
HOST
SIZE TTL TIME STATUS
1.1.1.1
56 64 0ms
1.1.1.1
56 64 0ms
Ctrl+c
sent=2 received=2 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms
Сделаем роутер Internet клиентом сервера имён DNS. Для этого в его окне
winbox выберем IP->DNS и в поле Servers введём адрес 1.1.1.2 нашего сервера
имён DNS. Открываем в winbox терминал и проверяем
[admin@Internet] > ping a.in
HOST
SIZE TTL TIME STATUS
1.1.1.2
56 64 1ms
1.1.1.2
56 64 0ms
Ctrl+c
sent=2 received=2 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=1ms
55
grigoryev.victor@gmail.com http://vmg.pp.ua
DHCP
Функции DHCP-сервера далеко не исчерпываются раздачей адресов по
запросу от DHCP-клиентов. DHCP-сервер может снабдить клиентов адресами
шлюза, сервера имён и другой информацией. При настройке DHCP-сервера надо
указать: имя интерфейса, через который он будет принимать запросы; IP-сеть и
диапазон адресов из которого он будет раздавать адреса; шлюз, который будет
назначен клиентам и т. д.
В роутере AP назначьте на интерфейс e5 (ether6) адрес 10.9.1.254/24. Сделаем
так, чтобы роутер Station получал адрес динамически. Для этого сделаем роутер AP
DHCP-сервером. Выбираем IP->DHCP server->DHCP Setup.
Далее в серии появляющихся окон определяем или соглашаемся с
предложением
DHCP Server Interface ether6
-выбираем и Next
DHCP address space
10.9.1.0/24
-соглашаемся и Next
Gateway for DHCP network 10.9.1.254
-соглашаемся и Next
Addresses to give out 10.9.1.1-10.9.1.253 -соглашаемся и Next
DNS servers 1.1.1.2
-соглашаемся и Next
Lease time
-соглашаемся и Next
Получаем сообщение об успешном завершении
Роутер Station сделаем DHCP-клиентом. Для этого в winbox этого роутера
выберем IP->DHCP Client и нажмём +. В новом окне в списке Interface выберем
ether6 и нажмём Ok. В списке адресов IP->Adresses появится новый адрес
10.9.1.253 с буквой D (динамический). Если этого не случится, то следует перейти
к окну списку интерфейсов, отключить, а затем включить интерфейс ether6 (Disable
затем Enable в контекстном меню). Роутер Station получил также маршрут по
умолчанию на 10.9.1.254 . Посмотрите его. Для этого выберите IP->Routes или
наберите в терминале
[admin@Station] > ip route pr
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 ADS 0.0.0.0/0
10.1.1.254
0
1 ADC 10.9.1.0/24
10.9.1.253
ether6
0
Роутер Station стал клиентом имён DNS. Выберем IP->DNS и в поле Servers
увидим два адреса 1.1.1.2 и 10.9.1.254 нашего сервером имён DNS AP. Проверим
[admin@Station] > ping a.in
HOST
SIZE TTL TIME STATUS
1.1.1.2
56 63 7ms
…sent=3 received=3 packet-loss=0% min-rtt=5ms avg-rtt=6ms
Роутер Station видит роутер AP. Однако роутер Station не видит роутер Internet
(i.in), так как последний не имеет маршрута в сторону первого.
В GNS интерфейс e0 роутера Client соединён с интерфейсом e1 роутера Station.
Интерфейс e0 в GNS соответствует интерфейсу ether1 в RouterOS, а e0 – ether2.
Назначим адреса 192.168.88.2/24 и 192.168.88.1/24 на этот интерфейсы ether1 и
56
grigoryev.victor@gmail.com http://vmg.pp.ua
ether2 роутеров Client и Station, соответственно. Тем самым мы обеспечили связь
по протоколу IP. Проверьте связь с помощью команды пинг (Tools->Ping).
Назначим роутеру Client маршут по умолчанию
[admin@Client] > ip route add gateway=192.168.88.1
Проверим связь, постепенно увеличивая "расстояние" до интерфейсов
удалённых роутеров.
[admin@Client] >ping 192.168.88.1 - нормально в сторону Station
[admin@Client] >ping 10.9.1.253 - нормально в сторону Station
[admin@Client] >ping 10.9.1.254 -timeout в сторону AP
Неудача обусловлена отсутствием в роутере AP обратного маршрута в
сторону сети 192.168.88.0/24.
[admin@AP] > ip ro pr
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 ADC 1.1.1.0/24
1.1.1.2
ether1
0
1 ADC 10.0.2.0/24
10.0.2.1
ether7
0
2 ADC 10.9.1.0/24
10.9.1.254
ether6
0
Установим в роутере AP обратный маршрута по умолчанию в сторону
интерфейса ether6 (e5) роутера Station. Добьёмся того, чтобы DHCP-сервер AP
выдавал роутеру Station всегда постоянный адрес 10.9.1.1. Иначе мы не сможем
прописать маршрут. В роутере AP выберем в winbox IP->DHCP Server->Leases.
Дважды щёлнем мышью на единственной строке. В открывшемся окне изменим
адрес на 10.9.1.1 и нажмём кнопку Make Static. Изменим заданный по умолчанию
Client ID. Перейдём к роутерe Station. В DHCP-клиенте на роутере Station следует
задать такой же Client ID. Отключим и включим интерфейс ether6. В списке
адресов IP->Adresses роутера Station появится адрес с буквой D (динамический) и
заданным значением 10.9.1.1.
Замечание. Убедитесь, что MAC-адрес в настройках DHCP-сервера –LeaseseGeneral совпадает с MAC-адресом интерфейса ether6 роутера Station (DHCPклиента).
Перегрузите топологию и убедитесь, что роутер
Station динамически
получает адрес 10.9.1.1 на интерфейсе ether6.
Установим роутеру AP маршут по умолчанию
[admin@AP] > ip route add gateway=10.9.1.1
Проверим связь
[admin@AP] >ping 192.168.88.2
-нормально в сторону Client
[admin@Client] >ping 10.9.1.1
-нормально в сторону Station
[admin@Client] >ping 10.9.1.254
-нормально в сторону AP
[admin@Client] >ping 1.1.1.2
-нормально в сторону AP
Роутер Client сделаем клиентом имён DNS. Выберем IP->DNS и в поле Servers
введём адрес 10.9.1.254 нашего сервера имён DNS AP. Проверим
57
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@Client] > ping a.in - номально в сторону AP
HOST
SIZE TTL TIME STATUS
1.1.1.2
56 63 1ms
1.1.1.2
56 63 1ms
sent=2 received=2 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=1ms
[admin@Client] > ping i.in - timeout в сторону Internet
HOST
SIZE TTL TIME STATUS
1.1.1.1
timeout
1.1.1.1
timeout
sent=2 received=0 packet-loss=100%
Пакет пинга дойдёт до назначения. Адреса источника и приёмника
поменяются местами. Пакет не сумеет вернуться, так как на роутере Internet нет
обратного маршрута на сеть 192.168.88.0/24 роутера Client.
Всё нормально, если мы примем такую модель: Роутер Internet представляет
весь Интернет. Роутеры Client и Station лежат во внутренней сети. Роутер AP
является шлюзом для выхода в Интернет и принадлежит двум сетям - внутренней
и Интернет.
NAT
NAT (от англ. Network Address Translation — «преобразование сетевых
адресов»). Добьемся, чтобы роутер Client видел маршрутизатор Internet. Для этого
на роутере AP у каждого исходящего в сторону роутера Internet пакета надо
поменять адрес источника на адрес, который есть в таблицах маршрутов роутера
Internet, то есть на адрес интерфейса ether1 AP 1.1.1.2. Каждая такая подмена
записывается в таблицу преобразований. Когда пакет возвращается, производится
поиск преобразования в таблице и осуществляется обратная замена адреса.
Принимаются меры для обеспечения уникальности результата поиска в таблице
преобразований. Так при преобразовании TCP/UDP-пакета производится замена
порта источника на новый порт из списка свободных. Для организации доступа из
внутренней сети в Интернет настроим на роутере AP преобразование адресов
источника
[admin@AP] > ip firewall nat add chain=srcnat action=masquerade
Теперь имеем доступ из внутренней сети в Интернет
[admin@Client] > ping i.in
HOST
SIZE TTL TIME STATUS
1.1.1.1
56 62 5ms
1.1.1.1
56 62 2ms
sent=7 received=7 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=5ms
Роутеры во внутренней сети не видны из Интернета. Нет маршрута уже в сторону
ближайшего внутреннего адреса
[admin@Internet] > ping 10.9.1.254
HOST
SIZE TTL TIME STATUS
no route to host
Маршрутизаторы
во внутренней сети не видны из Интернета. Для
58
grigoryev.victor@gmail.com http://vmg.pp.ua
организации доступа из Интернета к роутеру Client во внутренней сети добавьте на
пограничном роутере AP ещё один адрес 1.1.1.3/24 на интерфейсе ether1 и
осуществите преобразование адресов приёмника из адреса 1.1.1.3 в адрес
192.168.88.2 роутера Client
[admin@AP]>ip firewall nat add chain=dstnat dst-address=1.1.1.3 action=dst-nat toaddresses=192.168.88.2
Проверим. Зайдём удалённо из роутера Internet по адресу 1.1.1.3 (AP)
[admin@Internet] > system telnet 1.1.1.3
Trying 1.1.1.3...
Connected to 1.1.1.3.
Escape character is '^]'.
MikroTik v5.14
Login: admin
Password:
MikroTik RouterOS 5.14 (c) 1999-2012
http://www.mikrotik.com/
[admin@Client] >
То есть мы набрали адрес роутера AP, а вошли в удалённую консоль роутера
Client. Для выхода из консоли нажмите Ctrl+d.
В качестве упражнения удалите оба правила преобразования адресов и
повторите настройку с помощью утилиты winbox.
ARP
ARP (Address Resolution Protocol - протокол разрешения адреса) соединяет
вместе IP-адрес удалённого клиента с его MAC-адресом. ARP работает с ARPтаблицей, содержащей IP-адрес, MAC-адрес и интерфейс. Для определения
Ethernet-адреса, соответствующего IP-адресу АДРЕС, сетевое устройство
обращается в свою ARP-таблицу. Если такого соответствия нет, то система шлёт
широковещательный ARP-запрос следующего содержания: "Устройство, имеющее
адрес АДРЕС, сообщи свой MAC-адрес". Устройство с адресом АДРЕС в ARPответе сообшает свой MAC-адрес. Оба устройства автоматически добавляют в
свою ARP-таблицу новую строку. Для повышения сетевой безопасности можно
запретить такое автоматическое добавление и создавать строки ARP-таблицы
вручную. Тогда сетевое устройство после самостоятельной смены своего IP-адреса
не сможет иметь доступа во внешний мир.
На интерфейсе ether2 роутера Station запретим автоматическое добавления
строк в ARP-таблицу
[admin@Station] > int ethernet set ether2 arp=reply-only
Определим MAC-адрес интерфейса ether1 на роутере Client
[admin@Client] > interface ethernet print where name =ether1
# NAME
MTU MAC-ADDRESS
ARP
0 R ether1
1500 00:AA:00:BA:7F:00 enabled
Запоминаем MAC-адресс и добавляем в роутере Station строку в ARP-таблицу
[admin@Station]>ip arp add address=192.168.1.2 mac-address=
00:AA:00:BA:7F:00 interface=ether2
59
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@Station] > ip arp print
Перезапустим интерфейс ether2 на Station
[admin@Station] >interface ethernet disable ether2
[admin@Station] >interface ethernet eneable ether2
Убедимся, что ARP работает
[admin@Client] >ip arp print
[admin@Client] >ping 192.168.88.1 - успех
[admin@Client] >ip arp print
Сменим адрес
[admin@Client] > ip ad set 1 address=192.168.88.3/24
[admin@Client] > ping 192.168.88.1
HOST
SIZE TTL TIME STATUS
192.168.88.1
timeout
Восстановим адрес
[admin@Client] > ip ad set 1 address=192.168.88.2/24
[admin@Client] > ping 192.168.88.1 - удача
Уберём настройки ARP
[admin@Station] > ip arp print
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic
# ADDRESS
MAC-ADDRESS
INTERFACE
1 192.168.88.2 00:AA:00:BA:7F:00 ether2
[admin@Station] > ip arp rem 1
[admin@Station] > interface ethernet set ether2 arp=enabled
Перезапусти интерфейс ether2 на Station
Фаервол (Firewall)
Фаервол (брандмауер) защищает сетевое устройство от нежелательного
доступа. Это осуществляется путём создания правил в фильтре фаервола и
средствами преобразования адресов NAT. Правила работают по принципу Если-То
и упорядочены в цепи (сhains). Имеются предопределённые цепи и цепи,
определённые пользователем. Существуют такие предопределённые цепи: input
(контролирует входящие к роутеру пакеты), output (выходящие из роутера пакеты)
и forward (проходящие пакеты)
Подсоединимся к консоли роутера Station. Разрешим входящие пакеты с
адресом источника 192.168.88.2 роутера Client
[admin@Station] > ip firewall filter add chain=input src-address=192.168.88.2
action=accept
и запретим остальные входящие пакеты
[admin@Station] > ip firewall filter add chain=input action=drop
Каждый новый пакет проверяется по очереди всеми правилами. Если пакет
удовлетворяет условию правила, то выполняется указанное в правиле действие и
дальнейшие
правила не выполняются, если только не указано действие
passthrough
Winbox, подключенный к Station по запрещённому адресу, перестанет
функционировать и роутер Station станет недоступен из роутера AP
60
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@AP] > ping 10.9.1.1
HOST
SIZE TTL TIME STATUS
10.1.1.1
timeout
Удалим правила фаервола
[admin@Station] > ip firewall filter pr
Flags: X - disabled, I - invalid, D - dynamic
0 chain=input action=accept src-address=192.168.88.2
1 chain=input action=drop
[admin@Station] > ip firewall filter rem 0,1
Доступ восстановлен.
На роутере Station запретим проходящие пакеты с TCP-портом назначения
равным 23 (telnet)
[admin@Station]>ip firewall filter add chain=forward action= drop
protocol=tcp dst-port=23
Зайдём на роутер Client и будем с помощью telnet последовательно
подключаться к роутерам Internet (1.1.1.1), AP (1.1.1.2), AP (10.9.1.254) и Station
(Station)
[admin@Client] > system telnet 1.1.1.1 - неудача
[admin@Client] > system telnet 1.1.1.2 - неудача
[admin@Client] > system telnet 10.9.1.254 - неудача
[admin@Client] > system telnet 10.9.1.1
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.
Успех. Выход - CtrlD. Удалите правила фаервола.
Ограничение скорости
Самый простой способ ограничить скорость загрузки и выгрузки состоит в
использовании простых очередей (Simple Queue). При этом важен порядок правил
очередей. Создадим на роутере Station ограничение для трафика от сети
192.168.88.0/24 к адресу 10.9.1.1: 65 Кбит/с на выгрузку и 128 Кбит/с на загрузку
admin@Station]
>
queue
simple
add
name="queue1"
targetaddresses=192.168.88.0/24
dst-address=10.9.1.1/32
direction=both
maxlimit=64k/128k
Проверим. В winbox на роутере client запустим тестер полосы пропускания
Tools-Bandwidth Test (рис.4.4).
Трафик можно также посмотреть, выбрав в winbox меню Interfaces. Более
подробную информацию увидим, вызвав окно для интерфейса ether1 и в нём
активировав вкладку Trafic (рис.4.5). Нажав на кнопку Torch, мы также увидим
скорости передачи.
Web-прокси
Настроим в Ubuntu Интернет. Для этого в Ubuntu в пункте меню верхней
панели System-Preferences-Network Proxy укажем адрес 212.3.125.178 и порт 8080
прокси-сервера университета. Проверим настройки, зайдя в Firefox на сайты i.ua и
ya.ru.
61
grigoryev.victor@gmail.com http://vmg.pp.ua
Запустим qemuwrapper для своего порта. Создадим топологию из одного роутера. Добавим роутеру два tap-интерфейса, введя в GNS3 для него в поле Qemu
options строку
Рис.4.4. Тестер полосы пропускания
-net nic,vlan=6 -net tap,vlan=6,script=no,downscript=no,ifname=tapV00
-net nic,vlan=7 -net tap,vlan=7,script=no,downscript=no,ifname=tapV01
где V-номер вашей tap-сети. Строку вводите тщательно без ошибок. Лучше эту
строку определить путём редактирования файла topology.net. Запускаем топологию. Проверим, что появилось два новых интерфейса
[admin@MikroTik] > int eth pr
6 R ether7
1500 52:54:00:12:34:5C enabled
7 R ether8
1500 52:54:00:12:34:5D enabled
62
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис.4.5
Уточним, к какому из tap-интерфейсов относится интерфейс ether7 и ether8.
Для этого запустим VNC-клиент, узнав порт в консоли Qemuwrapper. Нажимаем
комбинацию клавиш CtrlAlt2. Вводим команду network info и видим
Сравнивая MAC-адреса, делаем вывод, что ether7 это tap000, а ether8 это
tap001.
Назначим адреса (тап-сеть 0)
[admin@MikroTik]>ip add add addr=10.0.0.1/24 interface=ether7
[admin@MikroTik]>ip add add addr=10.0.1.1/24 interface=ether8
Настроим интерфейс с адресом 10.0.0.1 для доступа роутера в Интернет через
шлюз 10.0.0.2.
[admin@MikroTik] > ip route add gateway=10.0.0.2
Проверим доступность прокси-сервера университета
[admin@MikroTik] > ping 212.3.125.178
Второй интерфейс с адресом 10.0.1.1 настроим как новый прокси для хост-машины Ubuntu. Для этого запустим winbox по адресу 10.0.0.1 и сделаем роутер прокси-сервером. Выберем IP – WebProxy. В закладке General окна WebProxySetting
63
grigoryev.victor@gmail.com http://vmg.pp.ua
установим галочку Enabled. Укажем Parent Proxy 212.3.125.178 и Parent Proxy Port
8080.
Укажем адрес 10.0.1.1 и порт 8080 в настройках прокси хост-машины Ubuntu.
Зайдите на пару сайтов в Firefox и понаблюдайте соединения прокси-сервера
роутера в окне IP->WebProxy->Connections.
Блокируем сайт i.ua для Ubuntu. Для этого выбираем в winbox IP - WebProxyAccess и далее нажимаем на +. В появившемся окне WebProxyRule в поле Dst.Host
вводим i.ua. Выбираем action равным deny. Вводим i.ua в адресной строке Firefox и
видим
ERROR: Forbidden
While trying to retrieve the URL http://i.ua/:
Access Denied
Your cache administrator is webmaster.
Generated Fri, 16 Mar 2012 17:01:38 GMT by 10.0.1.1 (Mikrotik HttpProxy)
Если мы хотим перенаправлять запросы на другой сайт, то в поле Redirect
окна WebProxyRule вводим название сайта, например ya.ru. Вводим i.ua в адресной строке Firefox и попадаем на сайт ya.ru.
Выбирая System-Logging-Rules- + - Topics – WebProxy, включаем
протоколирование работы прокси-сервера роутера, которое можно увидеть из
пункта меню Log после захода в Firefox на какой-либо сайт.
HotSpot
HotSpot - это средство для быстрого подключения к Интернет. Перед
доступом в публичную сеть HotSpot проводит аутентификацию и ведение учёта
клиентов. HotSpot используется в открытых точках доступа, Интернет-кафе,
аэропортах, университетских городках и т.д. Пользователь получает динамический
адрес и права доступа. Ему определяются доступные сайты и скорость доступа.
Для настройки HotSpot роутер должен иметь внутренний и внешний
(публичный) адрес, доступ к серверу имён DNS и хотя бы одного HotSpotпользователя.
Установка HotSpot проста и подобна установке DHCP-сервера.
Так как DHCP-клиент в Ubuntu требует root-привилегий, то проведём
урезанную настройку Hotspot без использования DHCP и DNS.
В winbox выбираем IP-Hotspot-HotspotSetup и последовательно определяем:
Hotspot interface: ether8; Local Address of Network: оставляем 10.0.1.1/24, галочку
Masquarade Network не ставим; Address of Network - оставляем 10.0.1.2-10.0.1.254;
Select Certificate –None; IP Address of SMTP server - оставляем 0.0.0.0; DNS Server
-пропускаем; DNS name – пропускаем; в окне Create Local HotSpot User оставляем
User admin и без пароля. Видим окно Setup has completed successfully.
Пытаемся войти на какой-либо сайт. Доступ в интернет теперь паролирован.
Вводим имя admin без пароля и попадаем в Интернет. Для выхода из HotSpot
вводим адрес http://10.0.1.1
Hotspot автоматически генерирует динамические правила для фаервола
(рис.4.6)
Во вкладках окна IP-Hotspot можно увидеть подключенных клиентов, их
адреса и другую информацию. Вкладка Walled-Garden позволяет настроить доступ к
64
grigoryev.victor@gmail.com http://vmg.pp.ua
сетевым ресурсам (www, Telnet, SSH, Winbox ….) без HotSpot –авторизации.
Разрешите доступ к сайту ya.ru без запроса имени и пароля. Вкладка IP-binding
позволяет определённым клиентам обходить HotSpot.
Рис.4.6. Правила для фаервола
и NAT (рис.4.7)
Рис.4.7. Правила для NAT
Пользователь принадлежит профилю. Вкладка Hotspot user profile позволяет
установить ограничение скорости, входные и выходные фильтры и т.д.
1.
2.
Требования для сдачи работы
Для топологии на рис.4.1 продемонстрируйте настройки DNS, DHCP,
NAT. Покажите работу с ARP и Firewall и умение ограничивать трафик.
Для топологии из одного роутера продемонстрировать работу Webпрокси и HotSpot.
65
grigoryev.victor@gmail.com http://vmg.pp.ua
5. Ethernet-мосты. EoIP - Ethernet через IP VPN уровня 2
Мосты
EoIP
VPN уровня 2 через NAT
66
69
73
Мосты
Mikrotik RouterOs поддерживает объединение Ethernet-портов в мост.
Объединяя несколько Ethernet-портов в мост, мы получим на этих портах
программный коммутатор второго уровня или свич.
Tap-интерфейсы на стороне Ubuntu лежат в мостах. Ubuntu и RouterOs
обмениваются информацией о мостах. Сделайте копию bridge1 топологии template
из раздела 2, загрузите её в GNS3 и стартуйте только маршрутизатор R0. С
помощью команды brctl show посмотрите в Ubuntu список мостов и интерфейсов в
них. Пусть у вас tap-сеть 7. Вашему tap-интерфейсу tap700 маршрутизатора R0
соответствует мост B700 (m700) в Ubuntu. Посмотрим в Ubuntu какие MAC-адреса
видит этот мост.
student7@hu1104:~$ brctl showmacs B700
port no mac addr
is local?
ageing timer
1
00:00:ab:73:50:00
no
50.40
1
52:54:00:12:34:5c
no
50.40
1
be:79:1f:04:47:4c
yes
0.00
Посмотрим в Ubuntu MAC-адрес моста B700
student7@hu1104:~$ ifconfig B700
br0
Link encap:Ethernet HWaddr be:79:1f:04:47:4c
inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0
Посмотрим MAC-адреса в маршрутизаторе R0
[admin@R0] > int et pr
0 R ether1
1500 00:AA:00:61:15:00 enabled
6 R ether7
1500 52:54:00:12:34:5C enabled
Ubuntu видит MAC-адрес 52:54:00:12:34:5c ether7 в маршрутизаторе R0.
Остановим топологию. Соединим интерфейсы e0 маршрутизаторов R0 и R1.
Запустим топологию. Посмотрим MAC-адреса в маршрутизаторе R1
[admin@R1] > int eth pr
0 R ether1
1500 00:AA:00:A2:FE:00 enabled
6 R ether7
1500 52:54:00:12:34:5C enabled
Посмотрим в Ubuntu MAC-адреса моста B700
student7@hu1104:~$ brctl showmacs B700
port no mac addr
is local?
ageing timer
1
00:aa:00:61:15:00 no
8.71
1
00:aa:00:a2:fe:00 no
7.14
1
52:54:00:12:34:5c no
7.13
1
8a:d6:19:c9:ae:29
no
96.80
1
be:79:1f:04:47:4c yes
0.00
Мост B700 увидел интерфейсы ether1 R0 (00:AA:00:61:15:00) и ether1 R1
66
grigoryev.victor@gmail.com http://vmg.pp.ua
(00:AA:00:A2:FE:00)
p@hu1104:~$ brctl showmacs B701
port no mac addr
is local?
ageing timer
1
00:aa:00:61:15:00
no
21.25
1
00:aa:00:a2:fe:00 no
19.68
1
52:54:00:12:34:5c no
19.68
1
8a:d6:19:c9:ae:29
yes
0.00
1
be:79:1f:04:47:4c no
113.20
Мост B701 увидел интерфейсы ether1 R0 (00:AA:00:61:15:00) и ether1 R1
(00:AA:00:A2:FE:00) и мосты Ubuntu увидели друг друга (8a:d6:19:c9:ae:29
be:79:1f:04:47:4c).
Для более сложных топологий маршрутизаторы начинают взаимодействовать
с мостами Ubuntu, и объём информации увеличивается. Для сокращения объёма
информации временно откажемся от tap-интерфейсов и сократим число Ethernetадаптеров в каждом маршрутизаторе до реально используемого количества портов.
Временно откажемся от шаблона и создадим топологию bridge1, приведённую на
рисунке рис. 5.1. Помните о трудностях назначения портов для консолей Routeros.
Здесь и дальше свичи – это роутеры Mikrotik, которым мы предадим вид свича
(пункт symbol в контекстном меню).
До установки связей назначьте в контекстном меню для R0 и R1 по одной
сетевой карточке (NIC), а для Sw1 – две. Запустите топологию. Назначьте порты
консоли. Открываем 3 закладки в консоли Ubuntu и для открытия терминалов
Mikrotik вводим в закдадках telnet 127.0.0.1 порт-консоли
С помощью команды system identity set name=. назначаем маршрутизаторам
имена R0, Sw1 и R1. Проверим соседей
[admin@Sw1] > ip neighbor print
# INTERFACE ADDRESS MAC-ADDRESSIDENTITY VERSION BOARD
0 ether1
00:AA:00:CF:53:00 R0
5.2
x86
1 ether2
00:AA:00:3F:C9:00 R2
5.2
x86
Объединим интерфейсы Sw1 в мост
[admin@Sw1]> interface bridge add
[admin@Sw1]>interface bridge port add bridge=bridge1 interface=ether1
[admin@Sw1] > interface bridge port add bridge=bridge1 interface=ether2
Рис.5.1. Топология bridge1
Снова проверим соседей. Теперь все видят всех
[admin@R0] > ip neighbor print
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1
00:AA:00:E1:33:00 Sw1
5.2
x86
1 ether1
00:AA:00:3F:C9:00 R2
5.2
x86
67
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@Sw1] > ip neighbor print
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 bridge1
00:AA:00:CF:53:00 R0
5.2
x86
1 bridge1
00:AA:00:3F:C9:00 R2
5.2
x86
[admin@R2] > ip neighbor pr
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1
00:AA:00:E1:33:00 Sw1
5.2
x86
1 ether1
00:AA:00:CF:53:00 R0
5.2
x86
У моста есть таблица, состоящая из двух колонок: порт и список MACадресов. Если к порту моста подключается новая связь, то мост считывает с этого
связи все MAC-адреса, доступные через эту связь и запоминает их в этой таблице.
Мост использует эту таблицу для направления
пришедших пакетов на
соответствующий интерфейс. У пришедшего пакета мост берёт MAC-адрес
приёмника, ищет адрес в таблице и направляет пакет на соответствующий порт.
Посмотрим MAC-адреса
[admin@R0] > interface Ethernet print
0 R ether1
1500 00:AA:00:CF:53:00 enabled
[admin@R2] > interface Ethernet print
0 R ether1
1500 00:AA:00:3F:C9:00 enabled
Выведем таблицу, показывающую, на какой интерфейс мост направляет пакет
с определённым MAC-адресом
[admin@Sw1] > interface bridge host print
Flags: L - local, E - external-fdb
BRIDGE MAC-ADDRESS
ON-INTERFACE AGE
bridge1
00:AA:00:3F:C9:00 ether2
28s (MAC-адрес R1)
bridge1
00:AA:00:CF:53:00 ether1
30s (MAC-адрес R0)
L bridge1
00:AA:00:E1:33:00 ether1
0s
L bridge1
00:AA:00:E1:33:01 ether2
0s
Все устройства видят друг друга по протоколу Ethernet. Для полноты картины
назначьте адреса, указанные на рисунке рис.5.1 и пропингуйте. Пинги не могут не
пойти.
Создадим топологию bridge2, приведённую на рисунке рис.5.2. До установки
связей назначьте в контекстном меню для R0 и R3 по одной сетевой карточке (NIC),
а для Sw1 и Sw2 – две. Запустите топологию. Подводя мышь к маршрутизаторам,
узнаём порты консоли. Открываем 4 закладки в консоли Ubuntu и для открытия
консолей Mikrotik вводим в закладках telnet 127.0.0.1 порт консоли
Рис.5.1. Топология bridge2
68
grigoryev.victor@gmail.com http://vmg.pp.ua
Назначаем имена. Объединим все интерфейсы в Sw1 и в Sw2 в мост.
Посмотрим MAC-адреса
[admin@R0] > int Ethernet print
0 R ether1
1500 00:AA:00:CF:53:00 enabled
[admin@R3] > int Ethernet print
0 R ether1
1500 00:AA:00:35:2D:00 enabled
Выведем таблицы, показывающие мостам, на какой интерфейс направлять
пакет с определённым MAC-адресом
[admin@Sw1] > interface bridge host pr
Flags: L - local, E - external-fdb
BRIDGE MAC-ADDRESS
ON-INTERFACE AGE
bridge1 00:AA:00:35:2D:00
ether2
4s
(MAC-адрес R3)
bridge1 00:AA:00:63:2B:00
ether2
5s
bridge1 00:AA:00:CF:53:00
ether1
8s
(MAC-адрес R0)
L bridge1 00:AA:00:E1:33:00
ether1
0s
L bridge1 00:AA:00:E1:33:01
ether2
0s
[admin@Sw2] > interface bridge host pr
Flags: L - local, E - external-fdb
BRIDGE MAC-ADDRESS
ON-INTERFACE AGE
bridge1
00:AA:00:35:2D:00 ether1
8s
(MAC-адрес R3)
L bridge1 00:AA:00:63:2B:00 ether1
0s
L bridge1 00:AA:00:63:2B:01 ether2
0s
bridge1
00:AA:00:CF:53:00 ether2
12s
(MAC-адрес R0)
bridge1
00:AA:00:E1:33:01 ether2
9s
Видим, что мосты Sw1 и Sw2 сумеют правильно направить пакеты в сторону
R0 и R1. Все устройства видят друг друга по протоколу Ethernet. Для полноты
картины, проверьте на всех устройствах соседей ( ip neighbor pr), назначьте
адреса, указанные на рисунке рис.5.2 и пропингуйте. Пинги не могут не пойти.
Можно конструировать сколь угодно сложную топологию из мостов. Если
предвидятся циклы (петли), то следует
запустить в мостах протокол
покрывающего дерева STP или его разновидность RSTP, например
interface bridge set 0 protocol-mode=rstp
Этот вопрос здесь не обсуждается
EoIP
Обычно Ethernet-пакеты ходят по проводам, радиоканалам или оптическому
волокну. Ничего не мешает им ходить внутри IP-пакетов. Туннелирование Ethernet
через IP (Ethernet over IP - EoIP) - это протокол MikroTik RouterOS, который
создаёт Ethernet-туннель между двумя маршрутизаторами поверх IP-соединения.
EoIP-тунель может работать через любое соединение, способное передавать IPпакеты: Ethernet, IPIP-туннель, PPP и т.д.
Если в двух маршрутизаторах настроена поддержка EoIP, то Ethernet-трафик
(все Ethernet протоколы) пойдут через интерфейс EoIP так же, как если бы
существовали физические Ethernet -интерфейсы и был проложен кабель между
69
grigoryev.victor@gmail.com http://vmg.pp.ua
маршрутизаторами.
EoIP позволяет с помощью моста объединить через Интернет локальные сети.
Протокол EoIP подобно протоколу PPTP инкапсулирует Ethernet-фреймы в GRE
пакеты (протокол IP № 47) и пересылает их на удалённую сторону EoIP-туннеля.
При настройке EoIP используются следующие параметры
Свойства
Описание
arp (disabled | enabled |
proxy-arp | reply-only; Режим ARP
Default: enabled)
l2mtu
(integer; Максимальный размер блока 2 уровня на передачу. Только
Default: )
для чтения
mac-address
(MAC; MAC-адрес
интерфейса.
Разрешённый
диапазон
Default: )
00:00:5E:80:00:00 - 00:00:5E:FF:FF:FF
mtu (integer; Default:
Максимальный размер блока 3 уровня на передачу.
1500)
name (string; Default: ) Имя интерфейса
remote-address
(IP;
IP-адрес удалённой стороны EoIP-туннеля
Default: )
local-address
(IP;
IP-адрес локальной стороны EoIP-туннеля. Не обязательно
Default: )
tunnel-id
(integer: Уникальный для каждого туннеля идентификатор. Должен
65536; Default: )
совпадать на обеих концах
Значение mtu=1500 не следует менять для избегания
перефрагментации пакета внутри туннеля. Это
позволяет так
прозрачно объединить Ethernet-сети с помощью моста, что
станет возможным транспорт полноразмерных Ethernet-фреймов
через туннель.
При использовании мостов для EoIP-тунелей для корректной работы
алгоритмов мостов строго рекомендуется следить за уникальностью MAC-адрес
для каждого туннеля. Иначе вы должны быть уверены в уникальности хостов,
подсоединённых к мосту.
Сделаем копию EoIP шаблона template із роздела 2,. Соберём топологию,
указанную на рисунке Рис.5.3. (tap-сеть 0)
Рис.5.3. Топология Eoip. Два сайта подключены к Интернет через маршрутизаторы R0 и
R3. Маршрутизаторы R0 і R3 представляют локальные сети сайтов.
70
grigoryev.victor@gmail.com http://vmg.pp.ua
Облако Inet – это просто картинка, символизирующая нашу модель
Интернета. Вы можете вместо неё использовать овал.
Модель
заключается в соединении роутеров через tap-интерфейсы хост-машины
Ubuntu.
Назначим имена маршрутизаторам. Проверим соседей. R1 не будет видеть
R2. Это нормально. Проложим маршрут между tap-сетями 10.0.1.0/24 и
10.0.2.0/24 роутеров R1 и R2 через нашу модель Интернета.
[admin@R1]>ip route add dst-address=10.0.2.0/24 gateway=10.0.1.2
[admin@R2]>ip route add dst-address=10.0.1.0/24 gateway=10.0.2.2
Здесь 10.0.1.2 и 10.0.2.2 - адреса tap-интерфейсов на стороне хост-машины
Ubuntu. Проверим
[admin@R2] > ping 10.0.1.1
HOST
SIZE TTL TIME STATUS
10.0.1.1
56 63 11ms
Пинги пошли. R1 и R2 соединены через нашу модель Интернета. Настроим
EoIP-туннель
[admin@R1] > int eoip add remote-address=10.0.2.1 disabled=no
[admin@R2] > int eoip add remote-address=10.0.1.1 disabled=no
Создадим на R1 и R2 мосты и добавим в них физический Ethernet-интерфейс
e0 (ether1) и интерфейс EoIP
[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
[admin@R2] > int bridge add
[admin@R2]> int bridge port add bridge=bridge1 interface=eoip-tunnel1
[admin@R2]>int bridge port add bridge=bridge1 interface=ether1
Посмотрим MAC-адреса
[admin@R0] > interface Ethernet print
0 R ether1
1500 00:AA:00:3C:37:00 enabled
[admin@R3] > interface Ethernet print
0 R ether1
1500 00:AA:00:C3:F2:00 enabled
Выведем таблицы, показывающие мостам на какой интерфейс направлять
пакет с определённым MAC-адресом
[admin@R1] > int bridge host pr
bridge1
00:AA:00:C3:F2:00 eoip-tunnel1 11s ( MAC-адреса R3)
bridge1
00:AA:00:3C:37:00 ether1
57s
( MAC-адреса R0 )
…
[admin@R2] > int bridge host pr
bridge1
00:AA:00:C3:F2:00 ether1
20s
( MAC-адреса R3)
bridge1
00:AA:00:3C:37:00 eoip-tunnel1 21s
( MAC-адреса R0)
Смотрим соседей
[admin@R0] > ip neighbor print
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1
00:AA:00:72:18:00
R1
5.18
x86
1 ether1
52:54:00:12:34:5C
R2
5.18
x86
71
grigoryev.victor@gmail.com http://vmg.pp.ua
2 ether1
FE:4F:AF:27:83:4C
R1
5.18
x86
3 ether1
FE:E4:7D:AA:67:D9
R2
5.18
x86
4 ether1
00:AA:00:C3:F2:00
R3
5.18
x86
R0 видит все роутеры R1, R2 и R3.
[admin@R3] > ip neighbor print
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1
00:AA:00:3C:37:00
R0
5.18
x86
1 ether1
52:54:00:12:34:5C
R1
5.18
x86
2 ether1
FE:4F:AF:27:83:4C
R1
5.18
x86
3 ether1
FE:E4:7D:AA:67:D9
R2
5.18
x86
R3 видит все роутеры R0, R1 и R2.
Есть связь на втором сетевом уровне. Окончательно убедимся в этом.
Например, на R0 с помощью специальной утилиты mac-telnet соединимся по
Ethernet с R3, введя MAC-адрес его Ethernet-интерфейса ether1
[admin@R0] tool mac-telnet 00:AA:00:C3:F2:00
Попадаем в R3. Возврат CtrlD
На R3 соединимся по Ethernet с R0
[admin@R3] > tool mac-telnet 00:AA:00:3C:37:00
Попадаем в R0. Возврат CtrlD
Мы построили виртуальную частную сеть второго уровня над существующей
сетью в виде модели Интернета для Ubuntu.
Для полноты картины назначьте IP-адреса для R0 и R1 согласно рисунку и
пропингуйте крайние роутеры друг из друга.
Рис. 5.4 Структура EoIP-пакету. MAC-адреса в красных прямоугольниках.
Виконаємо команду
[admin@R0] > ping 00:AA:00:C3:F2:00
и с помощью анализатора сетевых пакетов Wireshark увидим (рис. 5.4),что для
72
grigoryev.victor@gmail.com http://vmg.pp.ua
инкапсуляции Ethernet-пакета в IP-пакет используется протокол GRE (Generic
Routing Encapsulation).
Задание. Для топологии EoIP3, изображённой на Рис. 5.5, организовать VPN
уровня 2 с помощью EoIP. Не забудьте использовать разные tunnel-id.
Рис.5.5. Топологии EoIP3
Самостоятельно с помощью команд int bridge host pr посмотрите таблицы,
показывающие мостам на какой интерфейс направлять пакет с определённым MACадресом. Убедитесь командой ip neighbour print, что все маршрутизаторы видит
друг друга как соседа. С помощью команды tool mac-telnet окончательно убедитесь,
что есть связь на втором сетевом уровне. Назначаем IP-адреса на R0, R3 и R5
согласно рисунку. Пингуем маршрутизаторы. Заметим, что R0, R3 и R5 будут
находится в одном домене широковещания. Это позволяет успешно
функционировать широковещательным ARP-запросам: от одного ко всем (через
EoIP туннели через Интернет)
VPN уровня 2 через NAT
Рассмотрим случай, когда филиалы корпорации не имеют прямого выхода в
Интернет. Рассмотрим топологию EoIPNAT, изображённую на Рис. 5.6. Здесь R3 и
R4 – маршрутизаторы топологию EoIPNAT Интернет-провайдера. Он их
конфигурирует по запросу корпорации. Соберите топологию и проверьте соседей.
В начале, согласно рисунку назначьте для
R2 и R3 адреса из сети
192.168.1.0/24. Для R2 назначьте шлюз 192.168.1.1. Назначьте для R4 и R6
адреса из сети 192.168.2.0/24. Для R2 назначьте шлюз 192.168.2.1. Назначьте на
интерфейсы ethert7 роутеров R3 и R4 дополнительные адреса 10.0.3.22.24 и
10.0.4.22/24 соответственно. Настройте NAT для исходящих и приходящих адресов.
Должны получить нечто подобное
[admin@R3] > ip firewall nat pr
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade out-interface=ether7
1 chain=dstnat action=dst-nat to-addresses=192.168.1.2 dst-address=10.0.3.22
[admin@R4] > ip firewall nat print
73
grigoryev.victor@gmail.com http://vmg.pp.ua
Flags: X - disabled, I - invalid, D - dynamic
0 chain=dstnat action=dst-nat to-addresses=192.168.2.2 dst-address=10.0.4.22
1 chain=srcnat action=masquerade out-interface=ether7
Рис. 5.6. Топология EoIP3
Проверьте работу NAT: роутеры R2 и R6 должны видеть (пинговать) друг
друга. Помним, что для внешнего мира они имеют адреса 10.0.3.22 и 10.0.4.22.
Настроим EoIP-туннель между R2 и R6 особым образом, учитывая NAT
[admin@R2] > int eoip add remote-address=10.0.4.22 disabled=no
[admin@R6] > int eoip add remote-address=10.0.3.22 disabled=no
Создадим на R2 и R6 мосты, добавим в них интерфейс EoIP и физический
Ethernet интерфейс e1 (ether2), идущий в сторону R0 (R5).
[admin@R2] > int bridge add
[admin@R2]>int bridge port add bridge=bridge1 interface=eoip-tunnel1
[admin@R2]>int bridg port add bridge=bridge1 interface=ether2
[admin@R6]>int bridge add
[admin@R6]>int bridge port add bridge=bridge1 interface=eoip-tunnel1
[admin@R6]>int bridg port add bridge=bridge1 interface=ether2
Самостоятельно посмотрите таблицы, показывающие мостам на какой
интерфейс направлять пакет с определённым MAC-адресом
[admin@R2] > int bridge host pr
[admin@R6] > int bridge host pr
Убедитесь командой ip neighbour print, что крайний маршрутизатор R0 ( R5)
видит R5 ( R0) как соседа. С помощью команды /tool mac-telnet окончательно
убедитесь, что есть связь на втором сетевом уровне между R0 и R5. Назначаем IPадреса на R0 и R5 согласно рисунку. Пингуем из R0 роутер R5 или наоборот.
Требования для сдачи работы
Продемонстрировать работающие топологии bridge1, bridge2, EoIP, EoIP3 и
EoIPNAT.
74
grigoryev.victor@gmail.com http://vmg.pp.ua
6. Беспроводный мост
Собираем схему на рис. 6.1, соединив указанные на рисунке сетевые порты с
помощью Erthernet-кабелей (витой пары). Кабеля обжаты с двух сторон разъёмами
rj45. Блоки питания у роутеров rb750 и rb751u-2hnd разные. Не перепутайте. У
rb750 блок питания меньше, чем у rb751u-2hnd.
Рис. 6.1. Схема лабораторной установки
Штекеры блоков питания пока не подключаем к роутерам. Подключим вилки
4-х блоков питания к удлинителю. Включим удлинитель в розетку и включим на
удлинителе выключатель. Воткнём штекер одного из блоков питания rb750 в
роутер rb750 toBridge1. Подождём, пока роутер загрузится. Светодиодный
индикатор активности сетевого порта 5 должен начать постоянно светится.
Загорится и индикатор на соответствующем порту свича. Запустим на компьютере
утилиту winbox. В появившемся окне программы winbox нажмём кнопку с
надписью "...". Появится список включенных роутеров, подключенных через свич к
компьютеру. В списке мы видим одну строку. Обратите внимание на название
колонок списка. Нажмём в строке на значение mac-address. Выбранный mac-адрес
появится в поле ввода окна программы winbox. В окне программы winbox введём в
поле Login имя admin, поле Password оставим пустым и нажмём кнопку с надписью
"Connect". Появится графический интерфейс для конфигурации роутера toBridge1.
Скорее всего с роутером уже работали. Его надо сбросить в фабричные
настройки. Для этого выберем System->Reset configuratuon. В появившемся окне
установим галочки "No Default Configuration" и "Do Not Backup" (Без
конфигурации по умолчанию и не делать резервную копию). Нажимаем кнопку
"Reset Configuration" (Сброс конфигурации) и затем кнопку Yes. В появившемся
окне подтверждаем наше намерение о сбросе роутера. Ждём, пока роутер
перегрузится. Прогамма winbox известит о потере связи с роутером. Согласимся с
этим.
Снова запустим winbox для роутера toBridge1. Дадим операционной системе
RouterOS внутри роутера название toBridge1. Для этого выберем System->Identity,
введём в поле ввода имя toBridge1 и нажмём кнопку Ok. Закроем и запустим на
компьютере утилиту winbox. Если список в нижней половине окна программы
75
grigoryev.victor@gmail.com http://vmg.pp.ua
winbox не пустой, то очистим его с помощью команды Tools->Remove All
Addresses. Нажмём кнопку с надписью "...". В новом окне видим в строке в поле
Identity значение равное toBridge1. Нажмём в этой строке на значение mak-address.
Выбранный mac-адрес появится в поле ввода окна программы winbox. Проверим,
что в поле Login присутствует имя admin, а поле Password является пустым.
Нажимаем кнопку Save. Данные для соединения с роутером toBridge1 появятся в
нижней половине окна winbox, что позволит в дальнейшем при соединенении с
роутером обойтись без кнопки "...".
Воткнём штекер одного из блоков питания rb751u-2hnd в роутер Station.
Подождём около 30 секунд, пока роутер загрузится. Светодиодный индикатор
активности сетевых портов 2 и 5 должен начать постоянно светится. Загорится и
индикатор на соответствующем порту свича. На роутере toBridge1 должен начать
постоянно светится светодиодный индикатор активности сетевого порта 1. Это
свидетельствует о наличии связи (линка) между роутерами toBridge1 и Station
через Erthernet-кабель. Запустим на компьютере ещё один экземпляр утилиты
winbox. В появившемся окне программы winbox нажмём кнопку с надписью "...".
Появится список включенных роутеров, подключенных через свич к компьютеру.
В списке мы видим две строки. Одна из них со значением в поле Identity равным
toBridge1, относится к роутеру toBridge1. Нажмём в другой строке списке списка
на значение mak-address. Выбранный адрес появится в поле ввода окна программы
winbox. В окне программы winbox нажмём кнопку с надписью "Connect". Появится
графический интерфейс для конфигурации роутера Station. Его надо сбросить в
фабричные настройки и дать ему имя Station. Данные для соединения с роутером
Station добавим в нижнюю половину окна winbox.
Рис. 6.2. Экземпляр утилиты winbox
76
grigoryev.victor@gmail.com http://vmg.pp.ua
Воткнём штекер одного из блоков питания rb751u-2hnd в роутер AP (access
point – точка доступа). Проверим светодиодный индикатор 5 и индикатор на свиче.
Запустим на компьютере третий экземпляр утилиты winbox. Сбросим настройки
роутера и дадим ему имя AP. Данные для соединения с роутером Station добавим в
нижнюю половину окна winbox.
Воткнём штекер одного из блоков питания rb750 в роутер toBridge2. Проверим
светодиодные индикаторы на свиче и на роутерах AP и toBridge2. Запустим на
компьютере четвёртый экземпляр утилиты winbox. Сбросим настройки роутера и
дадим ему имя toBridge2. Данные для соединения с роутером toBridge2 добавим в
нижнюю половину окна winbox.
Запустив на компьютере 5-й экземпляр утилиты winbox, видим (рис. 6.2)
После нажатия на кнопку "...", видим имена и версии роутеров, а также
названия устройств (рис. 6.3). Версия и маc-адреса у вас могут быть другими.
Сохраним список соединений, выбрав Tools->Export. Закроем на компьютере 5-й
экземпляр winbox.
Не рекомендуется выключать устройство, выдёргивая шнур питания. Для
каждого роутера, выбрав в winbox System->Shutdown->Yes, плавно завершим
работу операционных систем. Сами устройства не выключатся. Выключим
устройства, вынув штекер питания. Вместо Shutdown можно дать команду Reboot
на перегрузку.
Рис. 6.3. Названия устройств
Проверим линки. В каждом из четырёх окон winbox проверим соседей,
выбирая IP->Neighbors. Для каждого роутера в колонке Identity вы должны увидеть
имена трёх соседей. Например, для роутера toBridge1, видим (рис. 6.4)
Рис. 6.4. Соседи
Имя Staion повторяется дважды, так как между роутерами toBridge1 и Staion
две связи: одна напрямую и вторая через свич.
77
grigoryev.victor@gmail.com http://vmg.pp.ua
Обеспечим возможность конфигурации роутеров с использованием протокола
IP. Для этого назначим IP-адреса на пятый порт роутеров. Все четыре адреса
должны лежать в одной подсети с IP-адресом конфигурационного компьютера и их
значения определяются системой адресации сетевого окружения, в котором
выполняется данная лабораторная работа. В период подготовки данной работы
использовались следующие адреса.
Конфигурационный компьютер
192.168.1.2/24
toBridge1
192.168.1.101/24
Station
192.168.1.102/24
AP
192.168.1.103/24
Intrernet
192.168.1.104/24
Назначьте эти адреса на интерфейс ether5 роутеров.
Если конфигурационным является кафедральный компьютер, то он имеет
адрес в сети 192.168.14.0/24 и на роутеры следует назначать свободные адреса из
этой сети. Возможно назначение на кафедральный компьютер второго адреса из
другой сети.
Из конфигурационного компьютера с помощью утилиты ping проверьте связь
с роутерами, например ping 192.168.1.101 и добавьте в winbox соединения через IPадреса со всеми роутерами (рис. 6.5).
При редактировании команд в консоли winbox при вставке из кармана
Windows могут возникнуть проблемы. В этом плане более стабильно работает
утилита putty. putty входит в комплект поставки программы gns3 под Windows.
Рис. 6.5. Соединения через IP-адреса со всеми роутерами
78
grigoryev.victor@gmail.com http://vmg.pp.ua
Откроем putty. В поле Host Name (or IP address) введём 192.168.1.101.
Connection type установим в Telnet. В поле Saved Session введём имя соединения к
роутеру, например toBridge1. В категории Connection -Data в поле Auto-login
username введём admin. Перезапустим putty. В списке Saved Session выберем
toBridge1, Нажимаем кнопки Load и затем Open. Откроется консоль роутера
toBridge1 c приглашением ввода пароля.
Откроем putty. В поле Host Name (or IP address) введём 192.168.1.101.
Connection type установим в SSH - secure shell - безопасная консоль. В поле Saved
Session введём имя соединения к роутеру, например toBridge1SSH. В категории
Connection -Data в поле Auto-login username введём admin. Перезапустим putty. В
списке Saved Session выберем toBridge1SSH. Нажимаем кнопки Load и затем Open.
Откроется окно, с вопросом о доверии к роутеру. Ответе Yes. Сразу откроется
консоль роутера toBridge1 без приглашения ввода пароля.
Настройте аналогично соединения к остальным роутерам.
В putty более корректно осуществляется вставка содержимого кармана - для
этого достаточно нажать правую кнопку мыши. Кроме того putty автоматически
вставляет в карман выделенный мышью текст.
Откройте 4 консоли putty для связи со всеми роутерами.
Снова проверим линки. В каждом из четырёх окон winbox проверим соседей,
выбирая IP->Neighbors. Для каждого роутера в колонке Ip Address вы должны
увидеть адреса соседей.
Обеспечим беспроводное соединение роутеров Station и AP. Роутер AP будет
работать в режиме точки доступа, а Роутер Station будет работать в режиме
станции. Разрешим протоколирование беспроводный событий. Откроем winbox для
роутеров AP и Station. Выберем System->Logging и в закладке Rules нажмём +. В
новом окне в списке Topic выберем Wireless и Ok
Настроим точку доступа. Откроем winbox для роутера AP. Выберем Wireless и
дважды щёлкним мышью на беспроводном интерфейсе wlan1. В открывшемся окне
сбросим интерфейс с помощью кнопки Reset Configuration. Оценим
радиообстановку в лаборатории с помощью кнопки Snooper. Запомним занятые
частоты и идентификаторы SSID активных беспроводных сетей. В закладке
Wireless выберем
Mode:
ap bridge
Band:
2GHz-B/G/N
Frequency: 2437 -незанятая частота
SSID:
AP -новый идентификатор нашей сети
Нажимаем кнопки Apply и затем Enable.
Настроим станцию. Откроем winbox для роутера Station. Выберем Wireles и
дважды щелкнем мышью на беспроводном интерфейсе wlan1. В открывшемся окне
сбросим интерфейс и с помощью кнопки Scan откроем новое окно и в нём найдём
и выберем нашу сеть AP. Нажмём Connect и Сlose. В закладке Wireless нажимаем
кнопки Apply и Enable. Должно установиться беспроводное соединение. Внизу
справа появится сообщение "searching for network" и затем "connected to ess".
Можно не использовать кнопку Scan, а сразу в закладке Wireless выбрать
79
grigoryev.victor@gmail.com http://vmg.pp.ua
Mode:
station
Band:
2GHz-B/G/N
Frequency: 2437 -наша незанятая частота
SSID:
AP -идентификатор нашей сети
О наличии соединения свидетельствует также буква R перед названием
интерфейса wlan1 в списке интерфейсов в обоих роутерах.
Так как могут существовать много радиосетей с одним и тем же идентификатором
SSID, станция ищет точку доступа с самым сильным сигналом (рис. 6.6). Это
можно увидеть в Winbox через лог системы (меню Log слева)
Рис. 6.6. Станция ищет точку доступа с самым сильным сигналом
Заставим станцию сразу подсоединятся к нашей точке доступа. Для этого
возьмём в карман Mak-адресс точки доступа (вкладка general интерфейса wlan1).
На станции в окне wirelessTables откроем вкладку ConnectList и нажмём знак +.
Вставим в новом окне Mak-адресс и имя нашей точки доступа (рис. 6.7).
Перезагрузим радиоинтерфейс (Disable-Enable). Теперь станция не ищет точку
доступа с самым сильным сигналом (рис. 6.8). В настройках станции можно
оставить только две настройки Mode: station и Band: 2GHz-B/G/N.
Рис. 6.7. Вкладка ConnectList
80
grigoryev.victor@gmail.com http://vmg.pp.ua
В роутерах AP и Station назначьте на беспроводный интерфейс адреса
10.1.1.254/24 и 10.1.1.1/24 соответственно. Проверьте связь с помощью команды
ping. Проверьте скорость беспроводного соединения в окне Tools-BandwidthTest в
различных направлениях. Вы должны получить десятки мегабит в секунду. Во
время проверки посмотрите (рис. 6.9) уровни принимаемых сигналов (WirelessRegistration-двойной щелчок мыши на строке – Signal). Видим, что сигнал состоит
из более простых сигналов различных скоростей.
Рис. 6.8. Станция не ищет точку доступа с самым сильным сигналом
Скорости 1, 2, 5.5, 11 Mbps соответствуют протоколу IEEE 802.11b, скорости
6, 9, 12, 18, 24, 36,48, 54 Mbps – протоколам 802.11а и 802.11g. Остальные скорости
соответствуют протоколу 802.11n и обозначаются в виде HTШиринаКаналаMCSindex. MCS index определён в таблице табл.1 в которой GI (guard interval) у
нас произвольный 400 или 800 ns.
Согласно рисунку рис. 6.9 самым мощным (20 децибел) является сигнал со
скоростью HTC20-4, который принимает Station от AP. Согласно обозначению,
ширина канала равна 20 Мгц. Согласно таблице видим, что используется
модуляция 16-QAM (16-ти позиционная квадратурная амплитудно-фазовая);
применяется
помехоустойчивое
кодирование
с
отношением
числа
информационных бит к общему числу бит равным ¾; скорости равны 39 и 43.3
Mbps.
На AP от Station
На Station от AP
Рис. 6.9 Уровни принимаемого сигнала
81
grigoryev.victor@gmail.com http://vmg.pp.ua
На двух роутерах удалите IP-адреса у беспроводных интерфейсов. Добавьте
мосты
[admin@ Station] > Interface bridge add
Имя у моста будет bridge1
[admin@ AP] > Interface bridge add name= bridge2
Скорости протокола IEEE 802.11b
MCS
index
Modulation
type
Coding
rate
0
1
2
3
4
5
6
7
BPSK
QPSK
QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
1/2
1/2
3/4
1/2
3/4
2/3
3/4
5/6
Табл. 5.1
Data rate (Mbit/s)
20 MHz
40 MHz channel
channel
800 ns 400
800 ns 400 ns
ns
6.5
7.2
13.5
15
13
14.4
27
30
19.5
21.7
40.5
45
26
28.9
54
60
39
43.3
81
90
52
57.8
108
120
58.5
65
121.5
135
65
72.2
135
150
Добавим в мосты порты, идущие в сторону роутеров toBridge1 и toBridge2.
[admin@AP] >interface bridge port add bridge=bridge1 interface=ether1
[admin@Station] >interface bridge port add bridge=bridge1 interface=ether1
Для организации беспроводного моста будем использовать технологию WDS
(Wireless distributed system – беспроводная распределённая система). На точке
доступа AP установите WDS-режим в динамический и укажем имя моста для
автоматического добавления туда динамически создаваемого wds-интерфейса
[admin@AP] >interface wireless set wlan1 wds-mode=dynamic wds-defaultbridge=bridge2
Беспроводный роутер Station в режиме станции (mode=station) не
поддерживает помещение беспроводного интерфейса wlan1 в мост из-за
ограничений протокола 802.11. Изменим режим работы на station-wds
[admin@ Station] >interface wireless set wlan1 mode= station-wds
Станция переподсоединится к точке доступа и на точке доступа появится
новый wds-интерфейс
[admin@AP] > interface print
Flags: D - dynamic, X - disabled, R - running, S - slave
#
NAME TYPE MTU L2MTU MAX-L2MTU
…
6 R bridge2
bridge
1500 1600
7 DR wds1
wds
1500 2290
В мост автоматически добавится wds-интерфейс
[admin@AP] > interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic
82
grigoryev.victor@gmail.com http://vmg.pp.ua
# INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0
ether1
bridge2 0x80
10
none
1 D wds1 bridge2 0x80
74
none
Теперь в мост на станции можно добавить беспроводный интерфейс
[admin@Station] >inter bridge port add bridge=bridge1 interfac=wlan1
Узнаем MAC-адрес Ethernet-интерфейса ether1 на роутере toBridge2
[admin@toBridge2] > interface ethernet print
Flags: X - disabled, R - running, S - slave
#
NAME
MTU MAC-ADDRESS ARP
0R
ether1
1500 00:0C:42:E1:55:B8
enabled
Посмотрим, какие MAC-адреса и через какие интерфейсы видит мост bridge1
на роутере Station
[admin@Station] > interface bridge host print
Flags: L - local, E - external-fdb
BRIDGE
MAC-ADDRESS ON-INTERFACE AGE
bridge1
00:0C:42:E1:55:B8
wlan1
45s
L bridge1
00:0C:42:E2:54:97
ether1
0s
L bridge1
00:0C:42:E2:54:9B
wlan1
0s
bridge1
00:0C:42:E4:A7:1A
wlan1
58s
bridge1
00:0C:42:E5:EF:51
ether1
22s
Мост bridge1 на роутере Station через свой интерфейс wlan1 видит MAC-адрес
00:0C:42:E1:55:B8 Ethernet-интерфейса ether1 на роутере toBridge2. Аналогично
можно увидеть, что мост bridge2 на роутере AP через свой интерфейс wlan1 видит
MAC-адрес Ethernet-интерфейса ether1 на роутере toBridge1. Поэтому крайние
роутеры увидели друг друга как непосредственные соседи. Например для toBridge1
[admin@toBridge1] > ip neighbor print detail
…
6
interface=ether1
mac-address=00:0C:42:E1:55:B8
identity="toBridge2"
platform="MikroTik" version="5.14" unpack=none age=2s uptime=6h1m32s softwareid="8JYR-0LZN" board="RB750" ipv6=no interface-name="ether1"
Это даёт нам право поместить Ethernet-интерфейсы ether1 на роутерах
toBridge1 и toBridge2 в одну IP-сеть
[admin@toBridge1] > ip addre add address=1.1.1.2/24 interface=ether1
[admin@ toBridge2] >ip addre add address=1.1.1.1/24 interface=ether1
Проверьте связь между роутерах toBridge1 и toBridge2 с помощью пингов
Netinstall
Если к роутеру не удаётся подключиться с помощью winbox, то попробуйте
это сделать через его первый порт. Если и это не удастся, то вам надо (с
разрешения и под. присмотром преподавателя) переставить операционную систему
роутера с помощью утилиты Netinstall.
Для серии 700 маршрутизаторов Routerboard выкачиваем с официального
сайта Mikrotik последнюю версии программы Netinstall и архив all_packagesmipsbe-5.* самой операционной системы. Извлекаем в папку пакеты advanced dhcp
83
grigoryev.victor@gmail.com http://vmg.pp.ua
mpls ppp routerboard routing security system. Для беспроводных роутеров нам
понадобится и пакет wireless. Запускаем netinstall и в нём жмём кнопку Net Booting.
В открывшемся окне устанавливаем галочку Boot server enabled и в поле Client IP
address вводим адрес из той же сети, в которой находится компьютер на котором
запущен netinstall. Например, если адрес компьютера, на котором запущен netinstall
равен 192.168.1.2/24, то вводим 192.168.1.203. Соединим кабелем (напрямую или
через свич) первый порт роутера и порт компьютера с адресом 192.168.1.2/24 (на
котором запущен netinstall). С помощью тонкого длинного предмета нажимаем и
удерживаем микрокнопку в отверстии возле входа питания. Вставляем штекер
питания и ждём, пока индикатор рядом не перестанет мигать. В окне программы
netinstall в списке Routers/Drives после локальных дисков должна появиться новая
строка с указанием марки роутера и МАС-адреса. Выбираем эту строку. Используя
кнопку Browse, выбираем папку с пакетами, которые мы будем устанавливать.
Нажимаем кнопку Select all.
Убедимся, что в списке Routers/Drives выбран именно роутер, а не локальный
диск. ЕСЛИ ЭТО НЕ ТАК, ТО ВЫ УСТАНОВИТЕ RouterOS на локальный
компьютер и если это загрузочный диск, то ваша Windows перестанет грузится и
вам придется восстанавливать загрузочную запись.
Нажимаем кнопку Install. Вы увидите индикатор прогресса установки и в поле
статуса вы увидите фразу Installing. По завершении процесса установки в поле
статуса вы увидите фразу OK. Закрывайте netinstall. Система установлена, и роутер
автоматически перегрузится.
Дождитесь окончания перегрузки (индикаторы перестанут мигать), зайдите в
роутер через winbox и остановите роутер (system->shutdown) и выдерните блок
питания.
Сохраните свою конфигурацию в файл (Files-Backup), перетащите файл на
рабочий стол и заберите его домой. Принеся файл из дому, перетащите его в окно
Files и восстановите конфигурацию (Restore).
1.
2.
Требования для сдачи работы
Предъявить работающий беспроводный мост. Роутеры toBridge1 и
toBridge2 должны видеть друг друга c помощью утилиты mac-telnet.
Определите скорости соединения между роутерами Station и AP и между
роутерами toBridge1 и toBridge2
84
grigoryev.victor@gmail.com http://vmg.pp.ua
7. Маршрутизация
Статическая маршрутизация
Маска /32
Динамическая маршрутизация
RIP
OSPF
Перераспределение маршрутов и BGP
85
89
91
92
95
96
В сетевом устройстве IP-пакеты бывают входящие и выходящие. Для
входящих TCP/UDP-пакетов в устройстве должна быть запущена программа,
которая их обрабатывает. На входящие IP-пакеты ICMP-протокола (пинги)
отвечает система устройства. Выходящие пакеты могут быть как проходящими
(пробрасываемыми), так и порождаемыми процессами самого устройства. Для того
чтобы сетевое устройство пробрасывало пакеты, на нём должен работать процесс
маршрутизации. Тогда устройство становится маршрутизатором или роутером.
Для того чтобы пакет ушел из устройства для пакета должен быть прописан
маршрут. Должна быть строка в таблице маршрутов. Маршрутизация
осуществляется только по адресу назначения. Сетевые интерфейсы не понимают
IP. Они понимают пакеты 2-го сетевого уровня, например Ethernet или PPP. Для
проброса или отправки IP-пакет должен быть помещён в правильный пакет 2-го
уровня. Это делается на основании таблиц маршрутизации плюс (в случае Ethernet
) и протокола ARP. Остановимся на Ethernet .
Статическая маршрутизация
Соберём топологию routing. Воспользуйтесь шаблоном template. Для этого
сделаем копию routing папки template. Откроем routing в GNS3. Переименуйте
устройства (номер не трогайте -это номер tap-сети), измените их иконки и
соедините интерфейсы согласно рисунку рис. 7.1. Соединить, а затем
переименовать не удастся. Запомните это. Запустите топологию, назначьте имена
и адреса согласно рисунку.
Воспользуйтесь многозакладочной консолью,
настроенной ранее. Помним, что e0 это ether1, e1 это ether2. Обязательно проверьте
соседей командой ip neighbour print .
Рис. 7.1 Топология routing
Превратим устройства Sw0, Sw3, Sw5 в коммутаторы второго уровня (свичи),
объединив интерфейсы e0 и e1 в мост bridge1
interface bridge add-добавится мост с именем по умолчанию bridge1
85
grigoryev.victor@gmail.com http://vmg.pp.ua
interface bridge port add bridge= bridge1 interface=ether1
interface bridge port add bridge= bridge1 interface=ether2
Если в Ubuntu установлен Dynamips, то можно пользоваться и штатными
свичами из GNS3. Мы это не делаем из методических соображений.
К свичам sw0, sw3 и sw5 можно подсоединить ещё много сетевых устройств с
адресами из указанных на рисунке IP-сетей. Для сути дела хватит то, что
изображено.
Как только на сетевую карточку e0(ether1) R1 назначается адрес, например
1.1.1.1/24, система по маске определяет IP-сеть для этого адреса (1.1.1.0/24) и в
таблицу маршрутов добавляется строка, говорящая, что пакеты на адреса из сети
1.1.1.0/24 отправлять на ether1
[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 ADC 1.1.1.0/24
1.1.1.1
ether1
0
1 ADC 2.2.2.0/24
2.2.2.2
ether1
0
2 ADC 10.0.1.0/24
10.0.1.1
ether7
0
В столбце PREF -SRC указан адрес источника. 24-число единиц в маске. В
других обозначениях это маска 255.255.255.0 .
Далее система сможет обработать любой выходящий или проходящий пакет с
адресом назначения, лежащим в этой сети 1.1.1.0/24. Пусть это будет пакет с
адресом назначения 1.1.1.2. Система видит, что пакет подпадает под строку
таблицы маршрутизации. И, согласно этой строке, видит, что путь к адресу 1.1.1.2
лежит через интерфейс ether1. Для определения Ethernet адреса, соответствующего
адресу 1.1.1.2, система обращается в ARP-таблицу соответствия MAС-адрес - IPадрес (ip arp print). Если такого соответствия нет, то система шлёт через
интерфейс ether1 широковещательный Ethernet-пакет с ARP-запросом "Устройство
имеющее адрес 1.1.1.2, сообщи свой MAC-адрес". Устройство R2 с адресом 1.1.1.2
в Ethernet -пакете ARP-ответа сообщает MAC-адрес М своей карточки e0 (ether1).
IP-Пакет на R1 в сторону 1.1.1.2 помещается в Ethernet пакет с MAC-адресом
назначения М и отправляется из сетевой карточки e0(ether1) R1 на сетевую
карточки e0(ether1) R2.
На устройстве R2 с адресом 1.1.1.2 в свою очередь должен быть прописан
маршрут в обратную сторону. В нашем случае он добавляется автоматически
системой
[admin@R2] > 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 ADC 1.1.1.0/24
1.1.1.2
ether1
0
1 ADC 7.7.7.0/24
7.7.7.1
ether2
0
2 ADC 10.0.2.0/24
10.0.2.1
ether7
0
86
grigoryev.victor@gmail.com http://vmg.pp.ua
То есть маршрутизатор безо всяких настроек осуществляет проброс
пришедших пакетов из одной непосредственно присоединённой IP-сети в другую.
Если надо пробросить или отправить IP-пакет, предназначенный для IP-сети,
которая не присоединена непосредственно к маршрутизатору, необходимо
добавить соответствующую строку в таблицу маршрутов. Это автоматически
делают протоколы динамической маршрутизации, согласно заданным в них
правилам. Это можно сделать и с помощью команд статической маршрутизации.
Например, команда для R1
ip route add dst-address=7.7.7.0/24 gateway=1.1.1.2
добавляет в таблицу маршрутов строку
[admin@R1] > ip route print
2 A S 7.7.7.0/24
1.1.1.2
1
o том, что пакеты на 7.7.7.0/24 отправлять на 1.1.1.2 . Здесь dst-address - сеть
назначения (7.7.7.0/24). В качестве адреса шлюза gateway надо брать ближайший
(но не свой) адрес в направлении к сети назначения. Далее система сможет
обработать любой выходящий или проходящий пакет с адресом назначения,
лежащим в сети 7.7.7.0/24. Она их будет направлять по адресу 1.1.1.2. Или точнее.
Этот адрес 1.1.1.2 лежит в сети 1.1.1.0/24, для которой уже существует строка в
таблице маршрутизации. Согласно этой строке, пакеты для 1.1.1.2 направляются
на интерфейс ether1. Они помещаются в Ethernet -пакеты с адресом назначения
равным Ethernet-адресу, соответствующему IP-адресу 1.1.1.2.
Вся IP-сеть обозначается как 0.0.0.0/0. Маршрут на неё называется
маршрутом по умолчанию. Для R1 его можно задать так
[admin@R1] > ip route add gateway=2.2.2.3
Важно, что адрес 2.2.2.3 должен лежать в присоединённой к R1 сети 2.2.2.0/24,
то есть вначале на R1 рекомендуется пропинговать шлюз
[admin@R1] > ping 2.2.2.3
Следует помнить, что для прохождения пинга из исходной точки в точку
назначения необходимо, чтобы на каждом хосте, куда попадёт пакет пинга,
должен быть маршрут в точку конечного назначения. При возврате этого пакета из
точки назначения в исходную точку на каждом хосте, куда попадёт этот пакет
пинга, должен быть маршрут в исходную точку.
Весь мир представит интерфейс-петля bridge1 на R4 с произвольным адресом
6.6.6.6/32
[admin@R4] > interface bridge add
[admin@R4]>ip address add addre=6.6.6.6/32 interface=bridge1
Теперь в нашей таблице маршрутов на R1 есть следующие строки
DST-ADDRESS
PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0
2.2.2.3
1
1 ADC 1.1.1.0/24
1.1.1.1
ether1
0
2 ADC 2.2.2.0/24
2.2.2.2
ether2
0
3 A S 7.7.7.0/24
1.1.1.2
1
4 ADC 10.0.1.0/24
10.0.1.1
ether7
0
Один и тот же пакет может удовлетворять нескольким строкам таблицы. Так
пакеты в сторону сети 1.1.1.0/24 удовлетворяют и правилу 0 и правилу 1. Система
87
grigoryev.victor@gmail.com http://vmg.pp.ua
всегда использует более точное правило, или правило для сети, у которой маска
имеет больше единиц. В нашем случае это правило 1.
Добавим маршруты на остальных устройствах. Компьютер C6 видит весь
мир через адрес 7.7.7.1
admin@ C6] > ping 7.7.7.1
HOST
SIZE TTL TIME STATUS
7.7.7.1
56 64 4ms
Поэтому
admin@ C6 ] > ip route add gateway=7.7.7.1
Роутер R4 видит весь мир через 2.2.2.2
[admin@R4] > ping 2.2.2.2
HOST
SIZE TTL TIME STATUS
2.2.2.2
56 64 4ms
Поэтому
[admin@R4] > ip route add gateway=2.2.2.2
Роутер R2 видит весь мир через 1.1.1.1. Поэтому
[admin@R2] > ip route add gateway=1.1.1.1
Маршруты прописаны. Проверим, для самого тяжёлого случая: пинг из
внешнего мира в сторону C6
[admin@R4] > ping 7.7.7.2 src-address=6.6.6.6
HOST
SIZE TTL TIME STATUS
7.7.7.2
56 62 1ms
7.7.7.2
56 62 2ms
Посмотрим ARP-таблицы. Например
[admin@R2] > ip arp pr
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic
# ADDRESS MAC-ADDRESS
INTERFACE
0 D 1.1.1.1
00:AA:00:A3:7E:00
ether1
1 D 7.7.7.2
00:AA:00:4C:4F:00
ether2
Найдите эти MAC-адреса Ethernet-интерфейсов у соседних устройств R1 и
С6 (команда int eth pr).
Если два устройства соединены через свич, то с точки зрения сетевого уровня
этот свич можно убрать и соединить устройства напрямую. Обратно. Если два
устройства (с адресами из какой-то IP-сети) соединены напрямую, то между ними
можно вставить свич. Причем к свичу можно подсоединить устройства с адресами
из этой сети. Эти устройства и исходные два устройства будут видеть друг друга
по протоколу IP. Т.е. при рассмотрении маршрутизации можно вообще не
принимать во внимание свичи.
Уберём свичи. Остановите топологию. Сделайте копию папки routing.
Переименуйте её в routingBezSw. Откройте routingBezSw. Измените топологию
согласно рисунку Рис. 7.2, не перепутав интерфейсы
88
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис.7. 2 Топология с рис. 7.1 без свичей
Проверим, для самого тяжёлого случая: пинг из внешнего мира в сторону C6
[admin@R4] > ping 7.7.7.2 src-address=6.6.6.6
В рамках одной Ethernet -сети можно организовать более, чем одну IP-сеть.
Задание. Организуйте Ethernet-сеть из пяти устройств (0, 1, 2, 3 и 4), путём их
подключения к одному роутеру, настроенному как свич. Топологию назовите
Zadanie.Устройства 0, 1 и 2 поместите в одну IP-сеть, а устройства 0, 3 и 4
поместите в другую IP-сеть 2.2.2.0/24. Устройство 0 лежит в двух IP-сетях и будет
маршрутизатором. У него на Ethernet-интерфейс назначьте два IP-адреса 1.1.1.1 и
2.2.2.1 из наших IP-сетей 1.1.1.0/24 и 2.2.2.0/24. Путём назначения статических
маршрутов для устройств 1, 2, 3 и 4 добейтесь, чтобы все устройства пигновали
друг друга по кругу.
Маска /32
Младший адрес в IP-сети определяет саму сеть, а старший предназначен для
широковещания. Поэтому реальное число адресов в сети равно 2 в степени d и
минус 2, где d-число нулей в маске. Для сетей с маской /24 это 2^8-2=254. Для
сетей с маской /30 это 2^8-2=2. Маска /31 - смысла не имеет
Интерес представляют адреса с маской /32, используемые при связи точкаточка. Соберём новую топологию М32 из двух устройств R1 и R2, соединив их
интерфейсы ether1. Стандартно при назначении адреса интерфейс помещается в
сеть, которая определяется этим адресом. Назначим адреса особым образом,
заменив сеть, в которую помещается интерфейс на адрес противоположной
стороны
[admin@
R1]>ip
address
add
address=2.2.2.2/32
network=3.3.3.3
interface=ether1
[admin@ R2]>ip address add addr=3.3.3.3/32 network=2.2.2.2 interface=ether1
Посмотрим таблицы маршрутов
[admin@ R1]>ip route print detail
dst-address=3.3.3.3/32 gateway=ether1
[admin@ R2]>ip route print detail
dst-address=2.2.2.2/32 gateway=ether1
R1 пингует R2 и наоборот
1. Изучим маршрутизацию для адресов с маской /32. Соберите топологию
PtPRouting, изображённую на рисунке рис.7.3. Назначим адреса. Образуем
соединение точка-точка между R2 и R3.
89
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис.7.3 Топология PtPRouting
[admin@
R2]>ip
address
add
address=1.1.1.1/32
network=2.2.2.2
interface=ether1
[admin@ R3]>ip address add address=2.2.2.2/32 network= 1.1.1.1
interface=ether1
Образуем соединение точка-точка между R3 и R4.
[admin@
R3]>ip
address
add
address=3.3.3.3/32
network=4.4.4.4
interface=ether1
[admin@
R4]>ip
address
add
address=4.4.4.4/32
network=3.3.3.3
interface=ether1
Две “точки” в R3 слились в одну на интерфейсе e0. Назначим маршруты
[admin@ R2]>ip route add dst-address=4.4.4.4/32 gateway=2.2.2.2
[admin@ R3]>ip route add dst-address=1.1.1.1/32 gateway=3.3.3.3
R2 пингует R4 и наоборот. Уберём свич, согласно рис.7.4, образуя топологию
PtPRoutingBezSw
Рис. 7.4 Топологии PtPRoutingBezSw, routingRIPPtP, routingRIPPtP1 и routingOSPFPtP
На R3 сменим интерфейс для адреса 3.3.3.3
[admin@R3] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
0 10.0.3.1/24
10.0.3.0
ether7
1 2.2.2.2/32
1.1.1.1
ether1
2 3.3.3.3/32
4.4.4.4
ether1
[admin@R3] > ip ad set 2 interface=ether2
Крайние роутеры опять пингуют друг друга
Рис. 7.5 Топология unnumbered
90
grigoryev.victor@gmail.com http://vmg.pp.ua
2. Для соединения двух IP-сетей обычно используют третью IP-сеть между
ними. Можно избежать привлечения третьей сети, если использовать так
называемую ненумерованную (unnumbered) адресацию. Имеем две Ethernet-сети
QEMU1,QEMU3 и QEMU2,QEMU4. В них настроены IP-сети 1.1.1.0/24 и
1.1.2.0/24. Рисунок рис.7.5 отражает упрощённую топологию unnumbered: между
QEMU1 и QEMU3 ( QEMU2 и QEMU4) можно поместить свич и к нему
присоединить устройства с адресами из сети 1.1.1.0/24 (1.1.2.0/24). Соединим
Ethernet-сети, соединив QEMU1 и QEMU2, образуя единую Ethernet-сеть
Для соединения двух IP-сетей 1.1.1.0/24 и 1.1.2.0/24 обычно используют
третью IP-сеть, скажем 1.1.3.0/30, настроенную на роутерах QEMU1 и QEMU2 .
Можно избежать привлечения третьей сети, если использовать так называемую
ненумерованную (unnumbered) адресацию.
Настроим первую IP-сеть
QEMU1>ip address add address=1.1.1.1/24 interface=ether1
Назначим ненумерованный адрес
QEMU1>ip address add address=1.1.1.1/32 network=1.1.2.1 interface=ether2
Видим, что адрес
1.1.1.1 назначен на разные интерфейсы и с разными
масками. Настроим адрес и маршрут на QEMU3.
QEMU3>ip address add address=1.1.1.2/24 nterface=ether1
QEMU3>ip route add gateway= 1.1.1.1
Настроим вторую IP-сеть
QEMU2>ip address add address=1.1.2.1/24 interface=ether1
Назначим ненумерованный адрес
QEMU2>ip address add address=1.1.2.1/32 network=1.1.1.1 interface=ether2
Опять, адрес 1.1.2.1 назначен на разные интерфейсы и с разными масками.
Настроим адрес и маршрут на QEMU4.
QEMU4>ip address add address=1.1.2.2/24 interface=ether1
QEMU4>ip route add gateway= 1.1.2.1
Настроим шлюзы между сетями
QEMU1>ip route add gateway=1.1.2.1
QEMU2>ip route add gateway=1.1.1.1
QEMU3 и QEMU4 увидят друг друга по протоколу IP. Проверьте пингом.
Динамическая маршрутизация.
Прописать все статические маршруты уже для средней сети - задача
нереальная. На помощь приходят протоколы динамической маршрутизации.
Рассмотрим, как настраивать маршрутизацию в протоколах RIP, OSPF и BGP.
Теорию рассматривать не будем. Ограничимся соображениями, относящимися
к настройке. Протоколы динамической маршрутизации работают в пределах
какой-то сети. Устройства, на которых активен данный протокол, обмениваются
маршрутной информацией друг с другом в пределах этой сети. В ходе этого обмена
у каждого устройства сети через некоторое время так изменяется таблица
маршрутов, что устройства в сети начинают видеть друг друга. Конкретно, кто
кого увидит, определяется начальными настройками протоколов маршрутизации
на каждом устройстве.
91
grigoryev.victor@gmail.com http://vmg.pp.ua
Протокол BGP предназначен для обмена маршрутной информацией между
автономными системами - большими сетями с единым администратором, в
которых уже настроена маршрутизация. При настройке BGP следует явно указать,
с какими автономными системами надо установить канал обмена маршрутной
информацией. BGP в других автономных системах также должно установить
канал. Стороны на концах каналов называют пирами.
Для протоколов
RIP и OSPF устройство обменивается маршрутной
информацией со своими соседями. Состав информации определяется настройками.
В рамках OSPF устройство отсылает соседям информацию о своих связях с
соседями. Оно же и получает такую информацию от своих соседей. Далее каждое
устройство на основании полученной информации строит карту (граф, топологию)
всей сети. Затем по этой карте создаёт таблицу маршрутов.
В рамках RIP устройства обмениваются между собой целыми таблицами
маршрутов. В начале, устройство отправляет соседям только информацию о
непосредственно присоединённых сетях и получает такую же от соседей. Далее
устройство отправляет соседям обновлённую таблицу. Принцип прост: если от
непосредственного соседа с адресом 1.1.1.1 в присланной таблице маршрутов есть
строка 7.7.7.0/24 *, то сосед знает, что делать с пакетами в сеть 7.7.7.0/24 и значит
их можно ему отправлять, то есть в свою таблицу надо добавить строку 7.7.7.0/24
1.1.1.1
При настройке RIP и OSPF следует указать адреса сетей, которые мы хотим
включить в процесс маршрутизации. Для настройки BGP надо указать адрес пира.
Можно настроить протоколы, чтобы они получали маршрутную информацию
из таких источников: непосредственно-подключенные маршруты, статические
маршруты и другие протоколы маршрутизации. То есть использовать
перераспределение (redistribution) маршрутов. Например. Пусть в сети А
используется OSPF, а в сети В - RIP. Имеется общий для двух сетей
маршрутизатор Z. Тогда на маршрутизаторе Z для
RIP надо включить
перераспределение OSPF, а для OSPF надо включить перераспределение RIP.
RIP
Сделаем копию routingRIP топологии routingBezSw. Запустим routingRIP и
убъём все статические маршруты на всех устройствах. Например для R1
[admin@R1] > ip ro pr
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
2.2.2.3
1
1 ADC 1.1.1.0/24
1.1.1.1 ether1
0
2 ADC 2.2.2.0/24
2.2.2.2 ether2
0
3 A S 7.7.7.0/24
1.1.1.2
1
4 ADC 10.0.1.0/24
10.0.1.1 ether7
0
[admin@R1] > ip ro remove 0,3
[admin@R1] > ip ro pr
0 ADC 1.1.1.0/24
1.1.1.1
ether1
0
92
grigoryev.victor@gmail.com http://vmg.pp.ua
1 ADC 2.2.2.0/24
2.2.2.2
ether2
0
2 ADC 10.0.1.0/24
10.0.1.1
ether7
0
Добавим на R6 интерфейс-петлю bridge1 с адресом 5.5.5.5/32 (рис.7.6)
[admin@R6] > interface bridge add
[admin@R6]>ip addre add address= 5.5.5.5/32 interface=bridge1
Рис.7.6. Топологии routingRIP, routingRIP1, routingOSPF
1. На всех устройствах разрешим перераспределение непосредственноподключенных маршрутов
routing rip set redistribute-connected=yes
Укажем соседей, которым передаётся маршрутная информация
[admin@R4] routing rip neighbor add address=2.2.2.2
[admin@R1] routing rip neighbor add address=2.2.2.3
[admin@R1] routing rip neighbor add address=1.1.1.2
[admin@R2] routing rip neighbor add address=1.1.1.1
[admin@R2] routing rip neighbor add address=7.7.7.2
[admin@C6] routing rip neighbor add address=7.7.7.1
Крайние роутеры пингуют друг друга
[admin@R4] ping 5.5.5.5 src-address=6.6.6.6
[admin@C6] ping 6.6.6.6 src-address= 5.5.5.5
Натроим лог
[admin@C6] >sys log add topics=route action= memory
Посмотрим лог
[admin@C6] >log print follow-only
17:38:10 route,rip,debug ---=== RIPv2 RESPONSE ===--17:38:10 route,rip,debug prefix=5.5.5.5/32 metric=16 nexthop=0.0.0.0
17:38:10 route,rip,debug prefix=6.6.6.6/32 metric=3 nexthop=0.0.0.0
17:38:36 route,rip,debug 44 bytes sent to 224.0.0.9 via bridge1:
17:38:36 route,rip,debug ---=== RIPv2 RESPONSE ===--17:38:36 route,rip,debug prefix=5.5.5.5/32 metric=16 nexthop=0.0.0.0
17:38:36 route,rip,debug prefix=6.6.6.6/32 metric=4 nexthop=0.0.0.0
17:38:36 route,rip,debug 44 bytes sent to 7.7.7.1 via ether1:
Видим, что широковещание (адрес 224.0.0.9)
17:38:36 route,rip,debug 44 bytes sent to 224.0.0.9 via bridge1:
пойдёт через bridge1 и не выйдет во внешний мир. Маршрутная информация будет
передана в режиме точка-точка
17:38:36 route,rip,debug 44 bytes sent to 7.7.7.1 via ether1:
2. Сделаем копию routingRIP1 топологии routingRIP. Работаем с копией. На
всех устройствах отключим перераспределение непосредственно-подключенных
маршрутов
93
grigoryev.victor@gmail.com http://vmg.pp.ua
routing rip set redistribute-connected=no
Добавим сети для маршрутизации по протоколу RIP
[admin@R4] > routing rip network add network=6.6.6.6/32
[admin@C6] >routing rip network add network=5.5.5.5/32
Интересно наблюдать, что такие пинги проходят
[admin@R4] > ping 5.5.5.5 src-address=6.6.6.6
[admin@C6] > ping 6.6.6.6 src-address=5.5.5.5
У пингов адрес источника либо приёмника равен 5.5.5.5 или 6.6.6.6 .
Посмотрите таблицы маршрутов на всех устройствах, и вы увидите маршруты на
соответствующие сети.
А такие пинги не проходят
[admin@R4] > ping 5.5.5.5
[admin@C6] > ping 6.6.6.6
Рассмотрим ping 5.5.5.5. У ICMP-пакета адрес источника равен адресу R4
2.2.2.3. Пакет дойдёт до адреса 5.5.5.5 на С4, но не вернётся, так как на С4
маршрута в сторону сети 2.2.2.0/24 -нет.
Укажем протоколу RIP рекламировать маршруты о присоединённых сетях
[admin@R4] > routing rip network add network=2.2.2.0/24
[admin@R1] > routing rip network add network=2.2.2.0/24
[admin@R1] > routing rip network add network=1.1.1.0/24
[admin@R2] > routing rip network add network=1.1.1.0/24
[admin@R2] > routing rip network add network=7.7.7.0/24
[admin@C6] >routing rip network add network=7.7.7.0/24
Теперь все устройства в сети попарно пингуют друг друга.
Снова посмотрим лог
[admin@C6] >log print follow-only
Увидим, что широковещание
17:51:26 route,rip,debug 104 bytes sent to 224.0.0.9 via ether1:
пойдёт через ether1 и выйдет во внешний мир. Если C6 подключен к R2 через
свич (как оно обычно и бывает), то широковещание пойдёт на другие устройства,
подключенные к свичу, что не всегда желательно.
Таким образом, использование при настройке RIP рекламирования маршрутов
о присоединённых сетях приводит к широковещанию и лучше вместо него
указывать соседей, как в п.1.
3. Рассмотрим RIP для соединений точка-точка. Возьмите топологию
PtPRoutingBezSw, изображённую на Рис.7.4. Сделайте копию routingRIPPtP.
Запустите её и уничтожьте статические маршруты. На всех устройствах разрешим
перераспределение непосредственно-подключенных маршрутов
routing rip set redistribute-connected=yes
Укажем соседей
[admin@R2] > routing rip neighbor add address=2.2.2.2
[admin@R3] > routing rip neighbor add address=1.1.1.1
[admin@R3] > routing rip neighbor add address=4.4.4.4
[admin@R4] > routing rip neighbor add address=3.3.3.3
Крайние роутеры пингуют друг друга.
94
grigoryev.victor@gmail.com http://vmg.pp.ua
В таблицах маршрутах появятся маршруты на сети чужих tap-интерфейсов,
например
[admin@R2] > ip ro pr
2 ADC 10.0.2.0/24
10.0.2.1
ether7
0
3 ADr 10.0.3.0/24
2.2.2.2
120
4 ADr 10.0.4.0/24
2.2.2.2
120
tap-интерфейс 10.0.4.1 в R4 пингуется из R2 . Другая сторона tap-интерфейса
10.0.4.2 (которая в Ubuntu) нет. Это потому, что у Ubuntu нет маршрута в нашу
сеть.
Сделаем копию routingRIPPtP1 топологии routingRIPPtP. Работаем с копией.
На всех устройствах отключим перераспределение
непосредственноподключенных маршрутов. routing rip set redistribute-connected=no. Соседей
можно убрать
routing rip neighbor remove [find]
Добавим особым образом сети для маршрутизации по протоколу RIP.
[admin@R2] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
0 10.0.2.1/24
10.0.2.0
ether7
1 1.1.1.1/32
2.2.2.2
ether1
[admin@R2] > routing rip network add network=2.2.2.2
[admin@R3] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
0 10.0.3.1/24
10.0.3.0
ether7
1 2.2.2.2/32
1.1.1.1
ether1
2 3.3.3.3/32
4.4.4.4
ether2
[admin@R3] > routing rip network add network=1.1.1.1
[admin@R3] > routing rip network add network=4.4.4.4
[admin@R4] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
0 10.0.4.1/24
10.0.4.0
ether7
1 4.4.4.4/32
3.3.3.3
ether1
[admin@R4] > routing rip network add network=3.3.3.3
[admin@R4] > ping 1.1.1.1
HOST
SIZE TTL TIME STATUS
1.1.1.1
56 63 1ms
Пинги идут. В таблицах маршрутах нет путей на сети чужих tap-интерфейсов,
например
[admin@R2] > ip ro pr
0 ADC 2.2.2.2/32
1.1.1.1
ether1
0
1 ADr 4.4.4.4/32
2.2.2.2
120
2 ADC 10.0.2.0/24
10.0.2.1
ether7
0
95
grigoryev.victor@gmail.com http://vmg.pp.ua
OSPF
1. Возьмите топологию routingRIP на рис. 7.6. Сделайте копию routingOSPF.
Запустите её и уничтожьте RIP-настройки. Настроим OSPF самым простым
образом
[admin@R4]>rout ospf netw add netw=6.6.6.6.32 area=backbone
[admin@R4]>rout ospf netw add netw=2.2.2.0/24 area=backbone
[admin@R1]>rout ospf netw add netw=2.2.2.0/24 area=backbone
[admin@R1]>rout ospf netw add netw=1.1.1.0/24 area=backbone
[admin@R2]>rout ospf netw add netw=1.1.1.0/24 area=backbone
[admin@R2]>rout ospf netw add netw=7.7.7.0/24 area=backbone
[admin@C6]>rout ospf netw add netw=7.7.7.0/24 area=backbone
[admin@C6]>rout ospf netw add netw=5.5.5.5/32 area=backbone
Появились необходимые маршруты, например
[admin@C6] > ip ro pr
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 1.1.1.0/24
7.7.7.1
110
1 ADo 2.2.2.0/24
7.7.7.1
110
2 ADC 5.5.5.5/32
5.5.5.5
bridge1
0
3 ADo 6.6.6.6/32
7.7.7.1
110
4 ADC 7.7.7.0/24
7.7.7.2
ether1
0
5 ADC 10.0.6.0/24
10.0.6.1
ether7
0
Проверим
[admin@C6] > ping 6.6.6.6 src-address=5.5.5.5
HOST
SIZE TTL TIME STATUS
6.6.6.6
56 62 12ms
2. Рассмотрим OSPF для соединений точка точка. Возьмите топологию
routingRIPPtP. Сделайте копию routingOSPFPtP. Запустите её и уничтожьте там
RIP-настройки.
Добавим особым образом сети для маршрутизации по протоколу OSPF.
[admin@R2]>routi ospf netw add netwo=2.2.2.2 area=backbone
[admin@R3]>routi ospf netw add networ=1.1.1.1 area=backbone
[admin@R3]>routi ospf netw add networ=4.4.4.4 area=backbone
[admin@R4]>routi ospf netw add networ=3.3.3.3 area=backbone
Проверим
[admin@R4] > ping 1.1.1.1
HOST
SIZE TTL TIME STATUS
56 63 1ms
Рис 7.7. Топология bgp
96
grigoryev.victor@gmail.com http://vmg.pp.ua
Перераспределение маршрутов и BGP
Соберите топологию bgp изображённую на Рис 7.7. Запустите её и назначьте
адреса согласно рисунку. В каждом устройстве создайте пустые мосты bridge1 и
назначьте на них адреса 2.2.2.2, 11.0.1.1, 11.1.1.1 и 3.3.3.3 с маской /32 согласно
рисунку. Остальные адреса имеют маску /24.
Топология состоит из двух автономных систем 1 и 2. В каждой из них
настройте OSPF. Для автономной системы 1
[admin@R0]>rout ospf netw add netw=1.1.2.0/24 area=backbone
[admin@R2]>rout ospf netw add netw=1.1.2.0/24 area=backbone
[admin@R2]>rout ospf netw add netw=2.2.2.2/32 area=backbone
Для автономной системы 2
[admin@R1]>rout ospf netw add netw=1.1.3.0/24 area=backbone
[admin@R3]>rout ospf netw add netw=1.1.2.0/24 area=backbone
[admin@R3]>rout ospf netw add netw=3.3.3.3/32 area=backbone
На R0 и R1 благодаря OSPF появятся маршруты на сети мостов
[admin@R0] > 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
2 ADo 2.2.2.2/32
1.1.2.2
110
[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
2 ADo 3.3.3.3/32
1.1.3.2
110
Настроим BGP для связи автономных систем AS1 и AS1. Назначим номера
автономных систем 1 и 2
[admin@R0] >routing bgp instance set 0 as=1 router-id=11.0.1.1
[admin@R1] >routing bgp instance set 0 as=2 router-id=11.1.1.1
Рекомендуется устанавливать BGP-сессию между интерфейсами петлями, в
роли которых у нас выступают пустые мосты. Но сначала необходимо настроить
маршрут между адресами мостов 11.0.1.1 и 11.1.1.1
[admin@R0] >ip ro add dst-address=11.1.1.1/32 gateway=1.1.1.2
[admin@R1] >ip ro add dst-address=11.0.1.1/32 gateway=1.1.1.1
Установим BGP-сессию
[admin@R0]>routing bgp peer add remote-address=11.1.1.1 remote-as=2
multihop=yes update-source=bridge1
[admin@R1]> routing bgp peer add remote-address=11.0.1.1 remote-as=1
multihop=yes update-source=bridge1
В качестве источника BGP-обновлений выбран мост bridge1.
Об установке BGP-сессии лучше нам покажет Windox в поле Uptime меню
routing bgp peer. Для всех роутеров в winbox cмотрим на таблицы маршрутов (ip
route). Они не поменялись. Включим в BGP перераспределение OSPF-маршрутов
[admin@R0] > routing bgp instance set 0 redistribute-ospf=yes
97
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@R1] > routing bgp instance set 0 redistribute-ospf=yes
На R0 и R1 появятся новые маршруты,
[admin@R0] > 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
2 ADo 2.2.2.2/32
1.1.2.2
110
3 ADb 3.3.3.3/32
11.1.1.1
20 (от OSPF на 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
2 ADb 2.2.2.2/32
11.0.1.1
20 (от OSPF на R0)
3 ADo 3.3.3.3/32
1.1.3.2
110
На R2 и R3 ничего не изменилось. Включим в OSPF перераспределение BGP
-маршрутов.
Заметим, что в реальности это делать нельзя, так как размеры BGP-таблиц
включают маршруты для всего мира и содержат миллионы строк. В корпоративной
сети эти маршруты вовсе не надо.
[admin@R0]>routin ospf instanc set 0 redistribute-bgp=as-type-1
[admin@R1]>routin ospf instanc set 0 redistribute-bgp=as-type-1
На R0 и R1 ничего не изменилось. Но на R2 и R3 появились новые
маршруты.
[admin@R2] > ip ro pr
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
2 ADo 3.3.3.3/32
1.1.2.1
110
(от BGP на R0)
[admin@R3] > ip ro pr
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
1 ADo 2.2.2.2/32
1.1.3.1
110
(от BGP на R1)
Следующие пинги будут успешными
[admin@R2] > ping 3.3.3.3 src-address=2.2.2.2
[admin@R3] > ping 2.2.2.2 src-address=3.3.3.3
А эти нет
[admin@R2] > ping 3.3.3.3
[admin@R3] > ping 2.2.2.2
Пинги дойдут до назначения но не смогут вернуться. Это объясняется тем, что
по пути обратного следования пакеты пингов не найдут маршрута к источнику.
Заставим BGP анонсировать сети
[admin@R0] > routing bgp network add network=1.1.2.0/24
[admin@R1] > routing bgp network add network=1.1.3.0/24
Теперь пинги пойдут.
98
grigoryev.victor@gmail.com http://vmg.pp.ua
Итоговая таблица маршрутов (без маршрутов на сети присоединённых
интерфейсов)
[admin@R2] > ip ro pr
1 ADo 1.1.3.0/24
1.1.2.1
110
3 ADo 3.3.3.3/32
1.1.2.1
110
[admin@R0] > ip route print
2 ADb 1.1.3.0/24
11.1.1.1
20
3 ADo 2.2.2.2/32
1.1.2.2
110
4 ADb 3.3.3.3/32
11.1.1.1
20
7 A S 11.1.1.1/32
1.1.1.2
1
admin@R1] > ip route print
1 ADb 1.1.2.0/24
11.0.1.1
20
3 ADb 2.2.2.2/32
11.0.1.1
20
4 ADo 3.3.3.3/32
1.1.3.2
110
6 A S 11.0.1.1/32
1.1.1.1
1
[admin@R3] > ip ro pr
0 ADo 1.1.2.0/24
1.1.3.1
110
2 ADo 2.2.2.2/32
1.1.3.1
110
Например, ни из R2 ни из R3 недоступна сеть 1.1.1.0/24. В этом нет
недостатка. Эта сеть ничто иное, как канал связи между автономными системами.
Устройства, входящие в эту сеть пингуются по другим своим адресам. При
желании легко настроить недостающие маршруты в эту сеть. Мы не будем этого
делать.
Требования для сдачи работы
Предъявить 13 работающих топологий routing, routingBezSw, Zadanie, М32,
PtPRoutingBezSw,
unnumbered,
routingRIP,
routingRIP1,
routingRIPPtP,
routingRIPPtP1, routingOSPF, routingOSPFPtP и bgp.
99
grigoryev.victor@gmail.com http://vmg.pp.ua
8. Балансировка нагрузки
Монопольный канал
Равномерное распределение
100
103
Собираем топологию lb1 согласно рисунку Рис.8.1. Роутеры R1 и R4
взаимодействуют с роутером R3 через роутер R2. Между R2 и R3 есть два канала
связи.
Рассмотрим 2 варианта балансировки нагрузки: монопольный канал и
равномерное распределение.
1. Монопольный канал. Потребуем, чтобы трафик от роутера R1 всегда шел
по каналу связи от интерфейса e0 роутера R2 к интерфейсу e0 роутера R3, а трафик
от R4 всегда шел от интерфейса e1 R2 к интерфейсу e1 R3
Рис.8.1. Топология lb1
Назначаем адреса и шлюзы
[admin@R2] >ip ad ad address=1.2.3.2/24 interface=ether1
[admin@R2] >ip ad ad address=2.2.3.2/24 interface=ether2
[admin@R2] >ip ad ad address=1.1.2.2/24 interface=ether3
[admin@R2] >ip ad ad address=1.4.2.2/24 interface=ether4
[admin@R1] >ip ad ad address=1.1.2.1/24 interface=ether1
[admin@R1] >ip ro add g= 1.1.2.2
[admin@R4] >ip ad ad address=1.4.2.1/24 interface=ether1
[admin@R4] >ip ro add g= 1.4.2.2
R3
[admin@R3] >ip ad ad address=1.2.3.3/24 interface=ether1
[admin@R3] >ip ad ad address= 2.2.3.3/24 interface=ether2
Явно пропишем на R3 желаемые маршруты для обратного трафика в сторону
R2
Через e0 (ether1 )
[admin@R3] >ip ro add dst-address=1.1.2.0/24 gateway=1.2.3.2
Через e1 (ether2)
[admin@R3] >ip ro add dst-address=1.4.2.0/24 gateway=2.2.3.2
100
grigoryev.victor@gmail.com http://vmg.pp.ua
С прямым трафиком от R2 к R3 сложнее. Пометим на R2 пакеты метками
1.1.2.0in либо 1.4.2.0in в зависимости от сети источника 1.1.2.0/24(от R1) или
1.4.2.0/24 (от R4)
[admin@R2] >ip firewall mangle add chain=prerouting action= mark-routing
new-routing-mark=1.1.2.0in src-address=1.1.2.0/24
[admin@R2]>ip firewall mangle add chain=prerouting action= mark-routing
new-routing-mark=1.4.2.0in src-address=1.4.2.0/24
Рис.8.2. Тест полосы пропускания
Рис.8.3. Трафик на R3
101
grigoryev.victor@gmail.com http://vmg.pp.ua
В зависимости от полученной метки 1.1.2.0in либо 1.4.2.0in, роутер R2
направляет пакеты на различные адреса и различные интерфейсы:
[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
Запустим Winbox на R1 и выполним тест полосы пропускания в сторону
адреса 2.2.2.3 на R3 (Рис.8.2). На Рис.8.3 видим, что весь трафик на R3 пошёл через
ether1, то есть по пути от R2 e0 к R3 e0.
Рис.8.4. Тест полосы пропускания
Запустим Winbox на R4 и выполним тест полосы пропускания в сторону
адреса 1.2.3.3 на R3 (Рис.8.4). На Рис.8.5 видим, что весь трафик на R3 пошёл через
ether2, то есть по пути от R2 e1 к R3 e1.
Рис.8.5. Трафик на R3
102
grigoryev.victor@gmail.com http://vmg.pp.ua
2. Равномерное распределение. Делаем копию lb1 топологии lb. Потребуем,
чтобы трафик от R1 и R4 к R3 равномерно распределялся по двум путям
1. От интерфейса e0 роутера R2 к интерфейсу e0 роутера R3
2. От интерфейса e1 роутера R2 к интерфейсу e1 роутера R3
Уберём старую маркировку пакетов на R2
[admin@R2] >ip firewall mangle print
[admin@R2] >ip firewall mangle rem
и сделаем новую маркировку
[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, каждый второй в
каждой паре получает маркер gw2.
Найдите на R2 маршруты с опцией routing-mark
[admin@R3] >ip ro pri
и удалите их
[admin@R3] >ip ro rem …
Добавляем маршруты с новой опцией routing-mark
[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
Тем самым мы равномерно распределили прямой трафик. Распределим
обратный трафик. Сделать это проще всего, если указать два шлюза. Уберём на R3
старые два маршрута для обратного трафика (ip ro pri, ) и добавляем сразу два
шлюза
[admin@R3] >ip ro add gateway=1.2.3.2,2.2.3.2
Запуская на R1 или R4 тест полосы пропускания в сторону адреса 1.2.3.3
или 2.2.3.3 на R3. На Рис.8.6 видим одновременную загрузку двух интерфейсов.
Рис.8.6. Одновременная загрузка двух интерфейсов
Требования для сдачи работы
Предоставить работающие топологии lb и lb1
103
grigoryev.victor@gmail.com http://vmg.pp.ua
9. Производные от PPP протоколы и OpenVPN
PPP
Протоколы PPTP, SSTP, L2TP, OpenVPN и PPPoE
Протоколы системных событий
Настройка PPP
Настройка PPTP
Настройка L2TP
RSA-сертификаты
Настройка SSTP
Настройка OpenVPN
Особенности работы из командной строки
104
106
108
108
111
113
114
116
119
121
PPP
PPP (англ. Point-to-Point Protocol) — двухточечный протокол канального
уровня сетевой модели OSI. Обычно используется для установления прямой связи
между двумя узлами сети, причем он может обеспечить аутентификацию
соединения, шифрование и сжатие данных. Используется на многих типах
физических сетей: нуль-модемный кабель, телефонная линия, сотовая связь,
последовательные каналы связи и т. д.
PPP представляет собой целое семейство протоколов: протокол управления
линией связи (LCP - Link Control Protocol), протокол управления сетью (NCP Network Control Protocol), протоколы аутентификации (PAP, CHAP),
многоканальный протокол PPP (MLPPP), протокол сжатия CCP (Compression
Control Protocol), протокол шифрования ECP (Encryption Control Protocol) и т. д.
PPP протокол был разработан на основе протокола HDLC и дополнен
некоторыми возможностями, которые до этого встречались только в коммерческих
протоколах.
PPP позволяет работать нескольким протоколам сетевого уровня на одном
канале связи. Другими словами, внутри одного PPP-соединения могут передаваться
потоки данных различных сетевых протоколов (IP, Novell IPX и т. д.), а также
данные протоколов канального уровня локальной сети. После установления
соединение для настройки каждого сетевого протокола используется протокол NCP.
Он используется для согласования и определения настроек сетевого уровня, таких
как сетевой адрес или настройки сжатия.
Каждый кадр PPP всегда начинается и завершается флагом 0x7E. Затем следует
байт адреса и байт управления, которые тоже всегда равны 0xFF и 0x03
соответственно. В связи с вероятностью совпадения байтов внутри блока данных с
зарезервированными флагами, существует система автоматической корректировки
«проблемных» данных с последующим восстановлением.
Флаг Адрес
0x7E 0xFF
1
1
Управление
0x03
1
Данные
1-1500
Контрольная сумма
2
Флаг 0x7E
1
Поля «Флаг», «Адрес» и «Управление» образуют заголовок кадра HDLC.
104
grigoryev.victor@gmail.com http://vmg.pp.ua
Заголовок HDLC может быть опущен и не передаваться, если PPP в процессе
конфигурирования с помощью LCP договорится об этом с другой стороной.
Поле «Данные», PPP кадра, в свою очередь разбиты ещё на два поля: флаг
протокола (1-2 байта), который определяет тип данных до конца кадра и сами
данные.
Флаги протокола от 0x0XXX до 0x3XXX идентифицируют протоколы сетевого
уровня. Например, популярному IP протоколу соответствует флаг 0x0021, а
Novell IPX — 002B.
•
Флаги протокола от 0x4XXX до 0x7XXX идентифицируют протоколы с низким
уровнем трафика.
•
Флаги протокола от 0x8XXX до 0xBXXX идентифицируют протокол
управления сетью (NCP).
•
Флаги протокола от 0xCXXX до 0xEXXX идентифицируют управляющие
протоколы. Например, 0xC021 обозначает, что кадр содержит данные
протокола управления соединением LCP.
Фазы PPP:
1. Link Dead. Эта фаза наступает, когда связь нарушена, либо одной из сторон
указали не подключаться (например, пользователь завершил модемное
соединение.)
2. Установки связи (Link Establishment Phase). В данной фазе проводится
настройка линии с помощью протокола LCP. Если настройка была успешно,
управление переходит в фазу аутентификации, либо в фазу Network-Layer
Protocol, в зависимости от того, требуется ли аутентификация.
3. Аутентификации
(Authentication
Phase).
Данная
фаза
является
необязательной. Она позволяет сторонам проверить друг друга перед
установкой соединения. Если проверка успешна, управление переходит в фазу
Network-Layer Protocol.
4. Протокола сетевого уровня (Network-Layer Protocol Phase). В данной фазе
вызывается NCP для желаемого протокола. Например, IPCP используется для
установки IP сервисов. Передача данных также проходит в этой фазе. Закрытие
сетевых протоколов тоже включается в данную фазу.
5. Link Termination Phase. Эта фаза закрывает соединение. Она вызывается в
случае ошибок аутентификации, если было настолько много ошибок
контрольных сумм, что обе стороны решили закрыть соединение, если
соединение неожиданно оборвалось, либо если пользователь отключился.
Данная фаза пытается закрыть все настолько аккуратно, насколько возможно в
данных обстоятельствах.
•
Протокол LCP обеспечивает автоматическую настройку интерфейсов на
каждом конце (например, установка размера пакетов). Так как LCP
инкапсулируется в кадры РРР, то необходимо установление первоначального
соединения РРР. После установления PPP-соединения передающее и принимающее
устройство обмениваются пакетами LCP для уточнения параметров соединения и
специфической информации, которая потребуется при передаче данных. Далее
105
grigoryev.victor@gmail.com http://vmg.pp.ua
LCP переопределяет это соединение. Устройства не могут передавать данные друг
другу по сети, прежде чем LCP пакеты не определят доступность устанавливаемого
соединения.
LCP протокол осуществляет идентификацию соединяющихся устройств.
Далее он: разрешает или отклоняет установку соединения; определяет приемлемый
размера кадров для передачи (MTU) и приёма (MRU); осуществляет ограничение
по ширине канала; шифрует и аутентифицирует соединения; сжимает данные;
обнаруживает петли маршрутизации; проверяет синтаксис и ошибки в
конфигурации; разрывает соединения, если какое-либо значение превышает
заданный параметр.
Среди протоколов аутентификации известен CHAP (Challenge-Handshake
Authentication Protocol), который является предпочтительным для соединений с
провайдерами. Всё еще иногда используется устаревший протокол PAP (Password
Authentication Protocol ). Другим вариантом аунтентификации через PPP является
Extensible Authentication Protocol (EAP).
После того, как соединение было установлено, поверх него может быть
настроен сетевой уровень. Если в качестве протокола сетевого уровня используется
IP, то для настройки используется протокол IPCP (Internet Protocol Control Protocol
- протокол управления IP) как частный случай протокола NCP. IPCP использует тот
же механизм обмена пакетами, что и LCP. Обмен пакетами IPCP не происходит до
тех пор, пока PPP не завершит успешно фазу установки связи по протоколу LCP и,
если требуется и аутентификация, то и фазу аутентификации. В ходе фазы
протокола сетевого уровня PPP-серверу назначается IP-адрес. Далее клиенту по
протоколу IPCP передаётся назначенный ему IP-адрес.
После установки соединения, стороны, участвующие в соединении, могут
быть объединены в мост. Для согласования параметров мостов используется ещё
одна разновидность NCP – протокол управления мостами BCP (bridge control
protocol)
Протоколы PPTP, SSTP, L2TP, OpenVPN и PPPoE
PPTP (Point-to-Point Tunneling Protocol) — туннельный протокол типа точкаточка. L2TP (Layer 2 Tunneling Protocol — протокол туннелирования второго
уровня. Все они основываются на протоколе PPP, включают его в себя полностью и
отличаются от него лишь способом организации канала связи. Во всех случаях для
организации канала используется уже существующая связь между клиентом и
сервером по протоколу IP.
Мы можем с помощью анализаторе пакетов Wireshark мониторить трафик и
наблюдать инкапсуляцию протоколов.
После организации PPTP-туннеля (на рис. 9.1 приведён соответствующий
снимок мониторинга трафика) и установления TCP/IP-соединения поверх туннеля,
имеет место следующая инкапсуляция протоколов (если не используется
шифрование и сжатие): TCP в IP в PPP в GRE в IP. Стек протоколов можно видеть
на Рис. 9.2.
106
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 9.1. Мониторинг PPTP-трафика
Рис. 9.2. Стек протоколов PPTP
Протокол L2TP и для организации связи и для передачи данных использует
UDP-протокол. Для установки связи используется UDP порт 1701. Далее всё берёт
на себя PPP. На Рис. 9.3 приведён соответствующий снимок мониторинга трафика
Рис. 9.3 Мониторинг L2TP -трафика
107
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 9.4 Стек протоколов L2TP
После организации связи и установления TCP-соединения поверх L2TPтуннеля имеет место следующая инкапсуляция протоколов (если не используется
шифрование и сжатие): TCP в IP в PPP в L2TP в UDP в IP. Стек протоколов можно
видеть на Рис. 9.4.
В протоколе SSTP (Secure Socket Tunneling Protocol – протокол безопасного
туннелирования сокетов) для организации канала используется
шифрование по
протоколу SSL. В SSTP установка соединения и обмен данными происходит в
зашифрованном виде и мы не сможем с помощью программы Wireshark наблюдать
инкапсуляцию протоколов.
OpenVPN не использует PPP. OpenVPN для организации связи и для передачи
данных использует протокол UDP или TCP. Далее в поля данных этих протоколов
помещаются кадры протоколов IP (интерфейс tun) или Ethernet (интерфейс tap),
которые шифруются с помощью OpenSSL. Процедура установки
связи и
поддержка протокола сетевого уровня являются оригинальными разработками. Для
установки связи по OpenSSL протоколу клиент и сервер используют сертификаты
и/или пароли. В OpenVPN установка соединения и обмен данными происходит в
зашифрованном виде и мы ничего не увидим в анализаторе пакетов.
PPPoE (Point-to-point protocol over Ethernet) — протокол передачи кадров PPP
через Ethernet. В основном используется устройствами широкополосного доступа
DSL. PPPoE позволяет организовать через Ethernet соединение с именем и паролем.
Клиент посылает широковещательный Ethernet-фрейм, на который должен
ответить один из PPPoE-серверов. PPPoE-сервера посылает клиенту ответ. Клиент
выбирает подходящий сервер и посылает ему запрос на соединение. Сервер
посылает клиенту подтверждение. Между сервером и клиентом создается
виртуальный канал, который идентифицируется идентификатором сессии и MACадресами клиента и сервера. Затем в этом канале поднимается PPP соединение.
Протоколы системных событий
В случае неудачи при соединении по всем протоколам, рассматриваемым в
этой работе, надо смотреть протоколы системных событий (логи). Вначале
добавим лог для нужного протокола: system->loginf->+. В появившемся окне New
Log Rule в поле Topics добавляем нужный протокол PPP, PPTP, L2TP, SSTP,
OpenVPN или PPPoE. Сам лог смотрим в пункте Log главного меню Winbox во
время попытки соединения.
Настройка PPP
Воспользовавшись шаблоном, создайте топологию PPP (рис. 9.5). Выбирая в
GNS3 в контекстном меню маршрутизаторов configure -> qemu options, добавим в
108
grigoryev.victor@gmail.com http://vmg.pp.ua
маршрутизатор
(к
существующей
конфигурации
тап-интерфейсов)
последовательные порты, соединённые друг с другом с помощью UDP
R0 -serial udp::D555@:D556
R1 -serial udp::D556@:D555
Рис. 9.5. Топология PPP.
D – ваш номер. Имеем модель соединения двух устройств с помощью
последовательного канала связи или, если конкретно, то с помощью нуль-модема.
Запустим топологию.
Наберём в консоли ubuntu netstat –u –p
Рис. 9.6. Два UDP-соединения
и видим на рис. 9.6, что два экземпляра программы qemu (внутри qemu запущен
маршрутизатор) установили между собой два UDP-соединения, что обеспечило
между ними двустороннюю дуплексную связь. Это соединение моделирует связь
последовательных портов двух маршрутизаторов через ноль-модем.
В консоли R0 вводим
[admin@R0] > port print detail
name="serial0" used-by="Serial Console" channels=1 baud-rate=9600 data-bits=8
parity=none stop-bits=1 flow-control=none
name="serial1" used-by="" channels=1 baud-rate=9600 data-bits=8 parity=none
stop-bits=1 flow-control=none
Видим, что появился новый последовательный порт serial1, который работает
на скорости 9600 бит в секунду, с длинной байта в 8 бит, без контроля чётности, с
одним стоп-битом и без управления передачей. Маршрутизатор Mikrotik имеет
встроенный последовательный порт serial0. Этот порт используется консолью
(терминалом) маршрутизатора.
Назначим на тап-интерфейсы маршрутизаторов R0 и R1 адреса 10.D.1.1 и
10.D.0.1. Запустим в Ubuntu два экземпляра программы winbox для конфигурации
маршрутизаторов через тап-интерфейс.
Итак, между маршрутизаторами R0 и R1 установлен последовательный канал
связи. Осуществим через этот канал соединение маршрутизаторов по проколу PPP.
Пусть R0 будет PPP-сервером, а R1 - PPP-клиентом.
109
grigoryev.victor@gmail.com http://vmg.pp.ua
Mikrotik RouterOS обеспечивает масштабируемую аутентификацию,
авторизацию и учёт пользователей AAA(Authentication, Athorization and
Accounting). Локальная аутентификация выполняется с помощью базы данных
профилей и базы данных пользователей. Действительная конфигурация для
данного пользователя составляется из записи базы данных пользователей,
соответствующей записи из базы данных профилей и записи из базы данных
профилей, которая является записью по умолчанию для той службы, к которой
пытается подсоединиться пользователь. Запись по умолчанию из базы данных
профилей имеет самый низкий приоритет. Запись из записи базы данных
пользователей имеет наивысший приоритет, за некоторыми исключениями,
касающимися адресации.
Рис. 9.7. PPP-сервер
В winbox для R0 добавим PPP-пользователя q с паролем q (PPP->Secrets +).
Добавим PPP-сервер (PPP->Interfaces + PPP-server), связав его с новым
последовательным портом serial в режиме ноль-модема (рис. 9.7).
Рис.9.8 PPP-клиент
110
grigoryev.victor@gmail.com http://vmg.pp.ua
В winbox R1 добавим PPP-клиент (PPP->Interfaces + PPP-client ->advanced
mode) связав его с новым последовательным портом serial в режиме ноль-модема
(рис. 9.8). В закладке PPP добавим PPP-пользователя q с паролем q, очистив флаги
соединения по запросу, default route и DNS. рис. 9.9.
Рис. 9.9. PPP-клиент
У клиента и сервера видим статус connected (соединён). Они соединились на
втором сетевом уровне.
Настройка PPTP
Для реализации PPTP-, SSTP-, L2TP- и OpenVPN- канала между
маршрутизаторами R0 и R1 в топологии, изображённой на рис. 9.5 нужно иметь IPканал между этими маршрутизаторами. Сделаем его с помощью модели Интернета.
Для этого, как и ранее пропишем маршруты в сторону тап-инерфейса Ubuntu (тапсеть 0).
Рис. 9.10. Топология PPPInet (тап-сеть 0).
[admin@R0]>ip rou add dst-address=10.0.1.0/16 gatewa=10.0.0.2
111
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@R1]>ip rou add dst-address=10.0.0.0/16 gatewa=10.0.1.2
Теперь маршрутизаторы R0 и R1 видят друг друга по IP. Полученную
топологию назовём PPPInet и изобразим в виде рис. 9.10. Осуществим соединение
маршрутизаторов по протоколу PPTP. Пусть R0 будет PPTP-сервером, а R1 PPTPклиентом.
В winbox R0 добавим PPTP-сервер (PPP->кнопка PPTP-server) (рис. 9.11).
Рис. 9.11. PPTP-сервер
.
Рис. 9.12. PPTP-клиент
112
grigoryev.victor@gmail.com http://vmg.pp.ua
В winbox R1 добавим PPTP-клиент (PPP->Interfaces + PPTP-client ->Dial Out),
указав адрес PPTP-сервера 10.0.0.1 и добавив созданного ранее PPP-пользователя
q с паролем q. рис. 9.12. У клиента и сервера видим статус connected (соединён).
Они соединились на втором сетевом уровне
Рис. 9.13. L2TP –сервер
Настройка L2TP
Осуществим соединение маршрутизаторов по протоколу L2TP. Процесс
соединения аналогичен PPTP. Пусть R0 будет L2TP-сервером, а R1 L2TPклиентом. В winbox R0 добавим L2TP-сервер (PPP->кнопка L2TP-server) (рис.
9.13). В winbox R1 добавим L2TP-клиент (PPP->Interfaces + L2TP-client ->Dial Out),
указав адрес L2TP-сервера 10.0.0.1 и добавив созданного ранее PPP-пользователя
q с паролем q (рис. 9.14).
Рис. 9.14. L2TP –клиент
113
grigoryev.victor@gmail.com http://vmg.pp.ua
У клиента и сервера видим статус connected (соединён). Они соединились на
втором сетевом уровне.
RSA-сертификаты
Механизм сертификатов основан на технологии
несимметричного
шифрования, осуществляемой парой ключей – открытым и закрытым. Если
сообщение зашифровано открытым ключом, то может быть расшифровано только
закрытым ключом и если сообщение зашифровано закрытым ключом, то может
быть расшифровано только открытым ключом. Обмениваются только открытыми
ключами.
Можно предложить такой механизм аутентификации (проверки подлинности),
основанный на несимметричном шифровании
Б шлёт А запрос на аутентификацию.
А в ответ шлёт Б случайную последовательность.
Б шифрует её закрытым ключом и отправляет зашифрованное А.
А расшифровывает принятое открытым ключем и сравнивает с отосланным.
Если совпало, то Б это Б.
А аутентифицировал Б и сообщает ему об этом
Раздачей сертификатов управляет удостоверяющий центр. Сертификат
содержит «паспортные» данные получателя сертификата, открытый ключ и
цифровую подпись удостоверяющего центра (зашифрованные открытым ключом
удостоверяющего центра паспортные данные и открытый ключ из этого
сертификата).
Обмен сертификатами равносилен обмену открытыми ключами. Два
корреспондента получив сертификаты, могут ими обменятся и затем проверить их
на подлинность, если у них есть сертификат удостоверяющего центра. Для этого
они должны зашифровать данные этого сертификата открытым ключом
удостоверяющего центра и сравнивают с цифровой подписью проверяемого
сертификата.
Сертификаты можно использовать для аутентификации (проверки
подлинности). Уже сама проверка подписи присланного сертификата может
являться аутентификацией отправителя.
В домашних условиях вы можете попрактиковаться с сертификатами,
используя программу openssl, встроенную в пакет openvpn для Windows. openssl
расположена в папке easy-rsa. Работать с openssl надо только через cmd. Перейдите
в папку easy-rsa.
Способов работы с сертификатами с помощью openssl много. Так вместе с
openvpn поставляется набор командных файлов для работы с сертификатами.
Порядок работы с ними описан в файле readme.txt. Анализируя командные файлы
можно понять принцип работы с сертификатами. Рассмотрим эти принципы.
Вам надо стать удостоверяющим центром. Для этого создаём закрытый ключ
удостоверяющего центра по алгоритму DES длиной 1024 бит
openssl genrsa -des3 -out ca.key 1024
Generating RSA private key, 1024 bit long modulus
..............++++++
114
grigoryev.victor@gmail.com http://vmg.pp.ua
..........................++++++
e is 65537 (0x10001)
Enter pass phrase for ca.key:qqqqq
Verifying - Enter pass phrase for ca.key:qqqqq
Далее на основании этого закрытого ключа создаём самоподписанный
корневой сертификат CA (Certificate Authority) ca.crt
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -config openssl.cnf
Отредактируйте паспортные данные в файле openssl.conf, анализируя
полученные ошибки. Так, например строку $ENV::KEY_COUNTRY надо будет
заменить на UA. При использовании командных файлов используются значения
переменных окружения, устанавливаемых в файле vars.bat. В результате получим
Country Name (2 letter code) [UA]:
State or Province Name (full name) [DP]:
Locality Name (eg, city) [DNSK]:
Organization Name (eg, company) [DNU]:
Organizational Unit Name (eg, section) [FFECS]:
Common Name (eg, your name or your server's hostname) [CA]:
Name [name_default]:
Email Address [mail@ca.com]:
Для
получения сертификата в удостоверяющем центре надо: создать
закрытый ключ, создать на основе этого ключа запрос на сертификат и отослать
запрос в удостоверяющий центр. Удостоверяющий центр на основании запроса
создаёт и подписывает сертификат и отправляет его запросившему сертификат.
Для простоты будем получать сертификаты у самого себя.
Создаём закрытый ключ qqq.key по алгоритму DES длиной 1024 бит
openssl genrsa -des3 -out qqq.key 1024
Создаём
запрос на сертификат у самого себя, то есть у своего
удостоверяющего центра
openssl req -new -key qqq.key -out qqq.csr -config openssl.cnf
Country Name (2 letter code) [UA]:
State or Province Name (full name) [DP]:
Locality Name (eg, city) [DNSK]:
Organization Name (eg, company) [DNU]:
Organizational Unit Name (eg, section) [FFECS]:
Common Name (eg, your name or your server's hostname) [CA]:CNqqq
Name [name_default]:Nameqqq
Email Address [mail@ca.com]:qqq@mail.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
115
grigoryev.victor@gmail.com http://vmg.pp.ua
Отправлять запрос qqq.csr самому себе. Тем самым создаём и подписываем
сертификат qqq.crt
openssl x509 -req -days 3650 -in qqq.csr -CA ca.crt -CAkey ca.key -set_serial
01 -out qqq.crt
Signature ok
subject=/C=UA/ST=DP/L=DNSK/O=DNU/OU=FFECS/CN=CNqqq/name=Nameq
qq/emailAddress=qqq@mail.com
Getting CA Private Key
Enter pass phrase for ca.key:qqqqq
Теперь мы понимаем, что такое сертификаты как их создавать. Заметим, что
мы предельно упростили процесс получения сертификата. Наш сертификат не
содержит паспортных данных. Всё изложенное надо понимать только как
иллюстрацию к процессу получения сертификата. В реальности надо работать с
командными файлами.
Настройка SSTP
Осуществим соединение маршрутизаторов по протоколу SSTP. Пусть R0 будет
SSTP-сервером, а R1 SSTTP-клиентом. SSTP соединение требует RSAсертификатов.
В Ubuntu для работы с программой openssl создан командный интерфейс.
Воспользуемся им. Перепишем папку /usr/share/doc/openvpn/examples/easy-rsa/2.0 в
свою папку. Распакуем в ней 2 архива. Определим в файле Makefile
DESTDIR=/home/ВашаПапка и PREFIX=RSA. Инсталлируйте: make install.
Войдём из консоли в появившуюся папку RSA. Выполните
. vars (через пробел)
./clean-all
Исправьте данные в файле vars на данные о себе (не обязательно) и выполните
команды для установки переменных окружения и очистки базы сертификатов
source ./vars
./clean-all
Создайте один раз корневой сертификат
CA (Certificate Authority),
необходимый для подписи сертификатов клиента и сервера.
./pkitool --initca
Создайте сертификат сервера
./pkitool --server server
Создайте сертификат клиента
./pkitool client
Здесь server и client – любые имена.
Сертификаты появятся в папке keys. Перейдите в неё.
Посмотрите файл базы сертификатов index.txt.
Всегда перед началом выполнения команд в этой папке установите
переменные окружения командой . vars или source ./vars
Перепишем сертификаты и ключ из Ubuntu в SSTP-сервер маршрутизатора
Mikrotik .
116
grigoryev.victor@gmail.com http://vmg.pp.ua
ftp 10.0.0.1
name: admin
password;
bin
put ca.crt
put server.crt
put server.key
Аналогично перепишем сертификаты и ключ в SSTP- клиент.
В winbox R0 в позиции Files проверим наличие переданных файлов ca.crt
server.crt server.key. Выберем System -> Certificates нажимая 3 раза кнопку Import
последовательно импортируем файлы ca.crt server.crt server.key. После импорта
server.key соответствующая строка получит метку KR. Дважды щёлкнув на этой
строке, изменим имя сертификата на srv (рис. 9.15).
Рис. 9.15. Импорт сертификатов
Рис. 9.16. SSTP-сервер
В winbox R1 в позиции Files проверим наличие переданных файлов ca.crt
client.crt client.key. Выберем System -> Certificates, нажимая 3 раза кнопку Import
последовательно импортируем файлы ca.crt client.crt client.key. После импорта
client.key соответствующая строка получит метку KR. Дважды щёлкнув на этой
строке, изменим имя сертификата на cli
117
grigoryev.victor@gmail.com http://vmg.pp.ua
В winbox R0 добавим SSTP-сервер (PPP->кнопка SSTP-server), указав в нём
имя серверного сертификата srv c проверкой сертификата клиента (рис. 9.16).
В winbox R1 добавим SSTP-клиент (PPP->Interfaces + L2TP-client ->Dial Out),
указав адрес SSTP-сервера 10.0.0.1, добавив созданного ранее PPP-пользователя q
с паролем q и указав имя клиентского сертификата cli c проверкой сертификата
сервера (рис. 9.17). Сбросим флажок verify-server-address-from-certificate.
У клиента и сервера видим статус connected (соединён). Они соединились на
втором сетевом уровне.
Рис. 9.17. SSTP-клиент
Если флажок verify-server-address-from-certificate установлен, то SSTP-клиент
производит сравнени адреса (10.0.0.1) SSTP-сервера со значением параметра
“common name” сертификата, полученного от этого сервера. Чтобы эта проверка
прошла, следует создать правильный сертификат сервера. Для этого в файле vars
надо определить
export KEY_ORG="10.0.0.1"
и выполнитить команды
source ./vars
./clean-all
./pkitool --initca
./pkitool --server 10.0.0.1
118
grigoryev.victor@gmail.com http://vmg.pp.ua
Настройка OpenVPN
Осуществим соединение маршрутизаторов по протоколу OpenVPN. Пусть R0
будет OpenVPN -сервером, а R1 OpenVPN -клиентом. OpenVPN соединение
требует RSA-сертификатов.
Воспользуемся сертификатами srv и cli, импортированными при создании
SSTP соединения
В winbox R0 добавим OpenVPN-сервер (PPP->кнопка OVPN-server), указав в
нём имя серверного сертификата srv c проверкой сертификата клиента и режим
Ethernet, который понадобится для организации моста (рис. 9.18).
Добавим в winbox R0 мост (Bridge и +).
В протоколе OpenVPN у сервера надо задать локальный и удалённый адрес,
даже если мы его не будем использовать. Заметим, что OpenVPN–сервер
использует профиль default. Откроем его (PPP->profiles->default) и укажем в нём
мост и произвольные (пока) локальный и удалённый адрес 192.169.100.1 и
192.169.200.1. (рис. 9.19).
Рис. 9.18. OpenVPN-сервер
В winbox R1 добавим мост (Bridge+). Заметим, что OpenVPN –клиент
использует профиль default. Откроем его (PPP->profiles->default) и укажем в нём
мост для единообразия настройки (рис. 9.20).
В winbox R1 добавим OpenVPN -клиент (PPP->Interfaces + OpenVPN -client
->Dial Out) режиме Ethernet (который понадобится для организации моста), указав
адрес OpenVPN -сервера 10.0.0.1, добавив созданного ранее PPP-пользователя q с
паролем q и указав имя клиентского сертификата cli c проверкой сертификата
сервера (рис. 9.21).
119
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 9.19. Профиль для OpenVPN-сервера.
Рис. 9.20. Профиль для OpenVPN-клиента
У клиента и сервера видим статус connected (соединён). В winbox видим (IP>addresses), что сервер и клиент получили назначенные адреса 192.169.100.1/32 и
192.169.200.1/32.
Итак маршрутизаторы R0 и R1 соединены по 5 каналам. (рис. 9.22 и 9.23.)
120
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 9.21. OpenVPN –клиент
Рис. 9.22. 5 соединенных серверов
Рис. 9.23. 5 соединенных клиентов
Особенности работы из командной строки
База данных профилей управляется из подменю /ppp profile. Профили PPP
используются для определения значений по умолчанию для записи пользователя,
определённой с помощью подменю /ppp secret. Установки в /ppp secret подавляют
соответствующие установки, сделанные па подменю /ppp profile, за исключением
того, что назначение единственного IP-адреса всегда имеет приоритет над адресом,
121
grigoryev.victor@gmail.com http://vmg.pp.ua
взятым из назначенного пула IP-адресов. Значения свойств профиля PPP
приведены в табл. 9.1.
Значения свойств профиля PPP
Таблица 9.1.
Свойство
Значения Описание
addressстрока
Имя списка адресов, к которому будет добавлен адрес,
list
назначенный PPP
bridge
строка
Имя моста, к которому будет добавлен PPP-интерфейс
как порт.
changeyes | no | Изменить MSS (Maximum Segment Size) соединения.
tcp-mss
default
yes– подогнать MSS соединения
no – не подгонять MSS соединения
default – взять это значение из профиля по умолчанию
для интерфейса; no если это и есть профиль по
умолчанию
Используется для избежание фрагментации пакетов.
dns-server IP
idletimeout
incoming- строка
filter
localaddress
name
only-one
outgoingfilter
IP
IP-адрес DNS-сервера, назначаемый клиенту
Допустимое время неактивности, после которого линк
будет разорван
Имя цепочки фаервола для входящих пакетов, которая
берёт контроль над каждым пакетом, приходящим от
клиента. Цепочка должна быть добавлена вручную
IP-адрес или имя пула IP-адресов для PPP-сервера
строка
Имя этого профиля
yes | no | Определяет, разрешено ли пользователю иметь боле
default
одного соединения
yes - нельзя
no - можно
default - взять это значение из профиля по умолчанию
для интерфейса
строка
Имя цепочки фаервола для исходящих пакетов, которая
берёт контроль над каждым пакетом, идущим к
клиенту. Цепочка должна быть добавлена вручную.
строка
Ограничение скорости
IP
IP-адрес или имя пула IP-адресов для PPP-клиента
rate-limit
remoteaddress
sessionМаксимальное время, которое соединения может
timeout
оставаться активным
useyes | no | Определяет, используется ли сжатие данных
compressio default
yes - да
n
no - нет
default - взять это значение из профиля по умолчанию
для интерфейса; no если это и есть профиль по
умолчанию
122
grigoryev.victor@gmail.com http://vmg.pp.ua
useyes | no | Определяет, используется ли шифрование данных
encryption default | yes - да
required
no - нет
default - взять это значение из профиля по умолчанию
для интерфейса; no если это и есть профиль по
умолчанию
require - явно требовать шифрования
use-ipv6
yes | no | Определяет, разрешён ли IPv6. По умолчанию
default | разрешён, если IPv6 установлен.
required
yes - да
no - нет
default - взять это значение из профиля по умолчанию
для интерфейса; no если это и есть профиль по
умолчанию
require - явно требовать поддержки IPv6
use-mpls
yes | no | Определяет, разрешён ли MPLS через PPP.
default | yes - да
required
no - нет
default - взять это значение из профиля по умолчанию
для интерфейса; no если это и есть профиль по
умолчанию
require - явно требовать поддержки MPLS
use-vjyes | no | Определяет, используется ли алгоритм сжатия
compressio default
заголовков Van Jacobson
n
yes - да
no - нет
default - взять это значение из профиля по умолчанию
для интерфейса; no если это и есть профиль по
умолчанию
winsIP
IP-адрес WINS-сервера, назначаемый клиенту
server
Есть два профиля по умолчанию, которые нельзя удалить
/ppp profile print
Flags: * - default
0 * name="default" use-compression=no use-vj-compression=no useencryption=no only-one=no change-tcp-mss=yes
1
*
name="default-encryption"
use-compression=default
use-vjсompression=default use-encryption=yes only-one=default change-tcp-mss=default
База данных пользователей управляется из подменю /ppp secret. Значения
свойств пользователей PPP приведены в табл. 9.2.
Значения свойств пользователей PPP
Свойство
caller-id
Значения
строка
Таблица 9.2.
Описание
Для PPTP и L2TP это IP-адрес, из которого клиент
123
grigoryev.victor@gmail.com http://vmg.pp.ua
limitbytes-in
limitbytes-out
localaddress
name
password
profile
remoteaddress
remoteipv6-prefix
routes
service
IP
должен соединяться. Для PPPoE это MAC-адрес из
которого клиент должен соединяться. Используется
только при необходимости
Максимальное число байт, которое может выгрузить
клиент
Максимальное число байт, которое может загрузить
клиент
IP-адрес или имя пула IP-адресов для PPP-сервера
строка
строка
строка
IP
Имя пользователя для аутентификации
Пароль для аутентификации
Какой профиль пользователя использовать
IP-адрес или имя пула IP-адресов для PPP-клиента
IPv6
Префикс IPv6 для PPP-клиента
целое
целое
строка
Маршруты, которые появятся на сервере, когда клиент
соединится. Формат маршрута: dst-address gateway
metric (например, 10.1.0.0/ 24 10.0.0.1 1). Несколько
маршрутов разделяются запятыми. Игнорируется для
OpenVPN
any
| Определяет сервисы, доступные этому пользователю
async
|
isdn | l2tp
| pppoe |
pptp
|
ovpn
Проанализируем общие параметры настройки PPP, PPTP, L2TP, SSTP, PPOE и
OpenVPN серверов и клиентов. Общие параметры серверов приведены в табл. 9.3.
Общие параметры серверов
Свойство
max-mtu
max-mru
mrru
authentication
keepalive-timeout
certificate
verify-client-certificate
Port
l2tp
+
+
+
+
Таблица 9.3.
ovpn ppp
+
+
+
+
+
+
pppoe
+
+
+
+
+
+
+
+
Общие параметры клиентов приведены в таблице. 9.4.
124
pptp
+
+
+
+
+
sstp
+
+
+
+
+
+
+
+
grigoryev.victor@gmail.com http://vmg.pp.ua
Общие параметры клиентов
Свойство
max-mtu
max-mru
mrru
connect-to
User,password
add-default-route
dial-on-demand
authentication
port
certificate
use-peer-dns
keepalive-timeout
l2tp
+
+
+
+
+
+
+
+
Таблица 9.4.
ovpn ppp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
pppoe
+
+
+
+
+
+
+
pptp
+
+
+
+
+
+
+
+
sstp
+
+
+
+
+
+
+
+
+
+
+
+
+
Объяснение значений свойств из табл. 9.3 и табл. 9.4 приведены в табл. 9.5
.
Объяснение значений свойств клиентов и серверов Таблица. 9.5.
Свойство
max-mtu
max-mru
mrru
authentication
keepalive-timeout
certificate
verify-client-certificate
port
connect-to
User,password
add-default-route
dial-on-demand
use-peer-dns
Пояснение
Максимальный размер пакета, передаваемый без
фрагментации. Для Ethernet -1500
Максимальный размер пакета, принимаемый без
фрагментации Для Ethernet -1500
Максимальный
размер
принимаемого
пакета.
Позволяет передавать Ethernet-фреймы через туннель.
Если пакет больше, чем max-mru он будет разбит.
Использовать протокол проверки подлинности
mschap2, mschap1, chap или pap
Время активности
Имя сертификата
Проверять ли сертификат клиента
TCP-порт
Адрес для соединения
Имя и пароль
Добавить маршрут по умолчанию
Обратный вызов по требованию
Испоьзовать DNS пира
Значения max-mtu и max-mtu могут быть меньше, чем 1500. Например, PPPoE
требует для себя дополнительные 6 байт. 2 байта добавляет само PPP. Остаётся
1492 байта для IP-датаграмы. Следовательно, max-mtu и max-mtu для PPPoE не могут превышать 1492.
Сейчас мы поэкспериментируем с настройками через командную строку.
125
grigoryev.victor@gmail.com http://vmg.pp.ua
Возьмите чистую копию PPPcmd топологии PPPInet с рис.9.10 у которой настроена
только связь между маршрутизаторами через тап-интерфейс. Добавим пользователя
q
[admin@R0] > ppp secret add
name: q
Имеем
[admin@R0] > ppp secret print detail
name="q" service=any caller-id="" password="" profile=default routes="" limitbytes-in=0 limit-bytes-out=0
Есть встроенные сервера PPTP, L2TP, SSTP и OpenVPN
[admin@R0] > interface pptp-server server print
enabled: yes
max-mtu: 1460
max-mru: 1460
mrru: disabled
authentication: mschap1,mschap2
keepalive-timeout: 30
default-profile: default
[admin@R0] > interface l2tp-server server print
enabled: no
max-mtu: 1460
max-mru: 1460
mrru: disabled
authentication: pap,chap,mschap1,mschap2
default-profile: default-encryption
[admin@R0] > interface sstp-server server print
enabled: no
port: 443
max-mtu: 1500
max-mru: 1500
mrru: disabled
keepalive-timeout: 60
default-profile: default
authentication: pap,chap,mschap1,mschap2
certificate: none
verify-client-certificate: no
[admin@R0] > interface ovpn-server server print
enabled: no
port: 1194
mode: ip
netmask: 24
mac-address: FE:8C:42:2D:6D:A2
max-mtu: 1500
keepalive-timeout: 60
default-profile: default
126
grigoryev.victor@gmail.com http://vmg.pp.ua
certificate: none
require-client-certificate: no
auth: sha1,md5
cipher: blowfish128,aes128
Добавляем сервер PPP
[admin@R0] > interface ppp-server add disabled=no port=serial1 nullmodem=yes
Активируем сервера PPTP, L2TP, SSTP и OpenVPN
[admin@R0]>interface l2tp-server server set enabled=yes
[admin@R0]>interface ovpn-server server set enabled=yes
[admin@R0]>interface pptp-server server set enabled=yes
[admin@R0]>interface sstp-server server set enabled=yes
После активации и соединении клиентов автоматически создаются
соответствующие интерфейсы.
При необходимости, можно создать дополнительные сервера. Для этого
служат команды
interface l2tp-server add
interface ovpn-server add
interface pptp-server add
interface sstp-server add
При этом запрашивается, для какого пользователя создаётся интерфейс. Мы
этого делать не будем.
Начинаем настраивать клиентов. Начнём с протокола PPP
[admin@R1]>int ppp-client add port=serial1 null-modem=yes user=q
disabled=no
[admin@R1]>int ppp-client pr det
Flags: X - disabled, R - running
0 R name="ppp-out1" max-mtu=1500 max-mru=1500 mrru=disabled port=serial1 datachannel=0 info-channel=0 pin="" user="0" password="0" profile=default phone="" dialcommand="ATDT" modem-init="" null-modem=yes dial-on-demand=no add-defaultroute=no use-peer-dns=no keepalive-timeout=10 allow=pap,chap,mschap1,mschap2
Флаг R свидетельствует об установлении соединении.
Перейдём к выяснению минимального количества параметров необходимых
для добавления клиентов протоколов l2tp, pptp, sstp и OpenVPN.
[admin@R1] > int l2tp-client add
connect-to: 10.0.0.1
user: q
[admin@R1] > int l2tp-client pr det
Flags: X - disabled, R - running
0 X name="l2tp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connectto=10.0.0.1 user="q" password="" profile=default-encryption add-default-route=no dialon-demand=no allow=pap,chap,mschap1,mschap2
[admin@R1] > int ovpn-client add
127
grigoryev.victor@gmail.com http://vmg.pp.ua
connect-to: 10.0.0.1
user: q
[admin@R1] > int ovpn-client pr det
Flags: X - disabled, R - running
0 name="ovpn-out1" mac-address=FE:F8:51:31:89:E0 max-mtu=1500 connectto=10.0.0.1 port=1194 mode=ip user="q" password=""
profile=default
certificate=none auth=sha1 cipher=blowfish128 add-default-route=no
[admin@R1] > int pptp-client add
connect-to: 10.0.0.1
user: q
[admin@R1] > int pptp-client pr det
Flags: X - disabled, R - running
0 X name="pptp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connectto=10.0.0.1 user="q" password="" profile=default-encryption add-default-route=no dialon-demand=no allow=pap,chap,mschap1,mschap2
[admin@R1] > int sstp-client add
connect-to: 10.0.0.1
user: q
[admin@R1] > int sstp-client print detail
Flags: X - disabled, R - running
0 X name="sstp-out1" max-mtu=1500 max-mru=1500 mrru=disabled connectto=10.0.0.1 :443 http-proxy=0.0.0.0:443 certificate=none verify-server-certificate=no
user="q" password="" profile=default keepalive-timeout=60 add-default-route=no dialon-demand=no authentication=pap,chap,mschap1,mschap2
Видим в параметрах всех интерфейсов установленных флаг X: после создания
все клиенты находятся в неактивном состоянии. Активировать их можно двумя
способами. Например, для l2tp
[admin@R1]>int l2tp-client set 0 disabled=no
[admin@R1]>int l2tp-client enable 0
где 0 – номер интерфейса можно получить командой l2tp-client print. Снова введя
эту команду, видим, что клиент соединился с сервером. Об этом свидетельствует
флаг R. Активация остальных протоколов производится аналогично. Клиенты и
сервера протоколов l2tp и sstp соединяются. Однако для протокола OpenVPN
соединения не происходит. Не хватает ряда параметров. Воспользовавшись
вышеизложенным материалом по настройке протокола OpenVPN с помощью
утилиты winbox, добейтесь соединения из командной строки. Смена параметров
производится как обычно. Например
[admin@R1]>int ovpn-client print detail
[admin@R1]>int ovpn-client set
Требования для сдачи работы
В топологии PPPInet с помощью утилиты winbox осуществить связь между
клиентами и серверами по протоколам PPP, PPTP, L2TP, SSTP и OpenVPN.
Предъявить 5 соединенных серверов (рис. 9.22) и 5 соединенных клиентов
(рис. 9.23).
В топологии PPPcmd с помощью командной строки осуществить связь между
128
grigoryev.victor@gmail.com http://vmg.pp.ua
клиентами и серверами по протоколам PPTP, L2TP, SSTP и OpenVPN.
Предъявить 4 соединенных сервера (рис. типа 9.22) и 4 соединенных клиента
(рис. типа 9.23).
129
grigoryev.victor@gmail.com http://vmg.pp.ua
10. Построение VPN второго уровня c помощью производных от
PPP протоколов и OpenVPN
1. Настройка с помошью Winbox
1.1 PPP
1.2 PPTP
1.3 L2TP
1.4 SSTP
1.5 OpenVPN
2. Настройка с помощью командной строки
2.1 PPP
2.2 PPTP
2.3 L2TP
2.4 SSTP
2.5 OpenVPN
Распределённый мост
Использование профилей пользователя
131
133
133
134
137
137
138
140
140
141
141
142
143
144
Изучим организацию VPN второго уровня c помощью производных от PPP
протоколов и OpenVPN с использованием мостов.
Так как у нас используется один пользователь q и два пофиля default и default
encryption для всех соединений, то во избежание взаимного влияния будем строить
мосты по очереди для одного типа PPP-соединения, оставляя другие соединения
неактивными.
Запустим топологию на рис. 9.10, у которой настроены все пять соединений,
согласно предыдущему разделу. Деактивируем всех клиентов, нажимая в winbox
R1->PPP значок X на каждом клиенте. Деактивируем сервера (winbox R0->PPP),
снимая галочку enable в их настройках. Сервер PPP R0 (winbox R0->PPP)
деактивируется нажатием кнопки disable в его настройках.
Рис. 10.1. Топология для VPN уровня 2
Остановим топологию, добавим два элемента qemu host, соединив их, как
указано на рисунке Рис. 10.1.
130
grigoryev.victor@gmail.com http://vmg.pp.ua
Последовательно используем все 5 видов соединений для организации моста
между R2 и R3. При успешном создании моста R2 и R3 будут в одном Ethernetсегменте, образуя VPN уровня 2. Адреса для R2 и R3 можно назначать из одной
IP-подсети, например 172.16.1.0/24
1. Настройка с помошью Winbox
Запустим топологию. Назначим адаптерам адреса согласно рис. 10.1. И на
клиенте R1 и на сервере R0 добавим в созданный мост bridge1 интерфейс ether1. (В
winbox это Bridge->ports +). Проверим, чтобы этот мост фигурировал в настройках
профиля default и на клиенте R1 и на сервере R0 (PPP->profiles->default). В
настройках по умолчанию используется также профиль default encryption. Сделаем
так, чтобы мост bridge1 фигурировал в настройках этого профиля и на клиенте R1
и на сервере R0 (PPP->profiles->default encryption). См. рис. 10.2.
Рис. 10.2. Добавление моста в профиль
Рис. 10.3. Мост в PPP
131
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 10.4. Мост в PPTP
Рис. 10.5. Установление PPTP-соединения в режиме моста.
132
grigoryev.victor@gmail.com http://vmg.pp.ua
1.1 PPP.
Активируем сервер PPP на R0, нажав в winbox кнопку enable в его
настройках. Активируем клиент PPP на R1, нажав в winbox на строке ppp правой
кнопкой и выбрав enable. И на клиенте R1 и на сервере R0 у PPP-интерфейсов
должна появиться метка R. PPP-интерфейс автоматически добавится в мост bridge1
(рис.10.3).
R3 видит R2 по протоколу Ethernet и наоборот. Проверьте это с помощью
утилиты tool mac-telnet. Мы создали между R3 и R2 VPN второго уровня.
Естественно, что R3 видит R2 по IP и наоборот. Проверьте это утилитой пинг.
Деактивируем PPP -клиента, нажимая в winbox R1значок X на
соответствующей строке. Деактивируем PPP-сервер, снимая галочку enable в его
настройках.
1.2 PPTP
Активируем сервер PPTP на R0, установив галочку enable в его настройках.
По умолчанию PPTP-клиент и сервер использует профиль default encryption.
Активируем клиент PPTP на R1, нажав на строке pptp правой кнопкой и выбрав
enable. И на клиенте R1 и на сервере R0 у PPTP -интерфейсов должна появиться
метка R, а эти интерфейсы автоматически добавятся в мост bridge1 (рис. 10.4).
Рис. 10.6. Стек протоколов для PPTP-соединения в режиме моста при отключенном
шифровании
После организации связи и установки telnet- соединения (рис. 10.5) видим
такой стек протоколов (рис. 10.6) : IP над GRE над PPP над BCP над Ethernet над
IP над TCP.
Приведенные скриншоты получены при отключенном шифровании. Как
правило, в протоколе PPTP, пакеты, вложенные в PPP-кадры, шифруются. В этом
случае видимые на рис. 10.6 адреса (172.16.1.2 172.16.1.1) будут зашифрованы
(равно как и данные) и будут недоступны для наблюдения (рис. 10.7).
Рис. 10.7. Стек протоколов для PPTP-соединения в режиме моста при включенном
шифровании
Деактивируем PPTP-клиента, нажимая в winbox значок X на соответствующей
строке. Деактивируем PPTP сервер, снимая галочку enable в его настройках.
133
grigoryev.victor@gmail.com http://vmg.pp.ua
1.3 L2TP
Активируем сервер L2TP на R0, установив галочку enable в его настройках.
По умолчанию L2TP-клиент и сервер использует профиль default encryption.
Активируем клиент L2TP R1, нажав на строке l2tp правой кнопкой и выбрав
enable. И на клиенте R1 и на сервере R0 у L2TP -интерфейсов должна появиться
метка R, а эти интерфейсы автоматически добавятся в мост bridge1 (рис. 10.8).
R3 и R2 видят друг друга по протоколам Ethernet и IP. Проверьте это. Мы
создали между R3 и R2 VPN второго уровня.
В домашних условиях и при наличии прав вы можете воспользоваться
анализатором пакетов Wireshark. При установлении L2TP-соедиенеия вы увидите
картину, изображённую на рис. 10.9.
После организации связи и установки telnet-соединения (рис. 10.9) видим (рис.
10.10) такой стек протоколов: IP над UDP над L2TP над PPP над BCP над Ethernet
над IP над TCP.
Приведенные скриншоты получены при отключенном шифровании. Как
правило, в протоколе L2TP, пакеты, вложенные в PPP-кадры, шифруются. Реально
вы ничего не увидите (рис. 10.11).
Рис. 10.8. Мост в L2TP
Деактивируем L2TP -клиента, нажимая в winbox R1 значок X на
соответствующей строке. Деактивируем L2TP сервер, снимая галочку enable в его
настройках.
134
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис.10.9.Установление L2TP-соединения в режиме моста.
Рис. 10.10. Стек протоколов для L2TP-соединения в режиме моста при отключенном
шифровании
Рис. 10.11. Стек протоколов для L2TP-соединения в режиме моста при включенном
шифровании
135
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 10.12. Мост в SSTP
Рис. 10.13. Установление SSTP-соединения в режиме моста.
1.4 SSTP
136
grigoryev.victor@gmail.com http://vmg.pp.ua
1.4 SSTP
Активируем сервер SSTP R0 (winbox R0->PPP), установив галочку enable в
его настройках. По умолчанию SSTP-клиент использует профиль default encryption.
Активируем клиент SSTP R1 (winbox R0->PPP), нажав на строке sstp правой
кнопкой и выбрав enable. И на клиенте R1 и на сервере R0 у SSTP -интерфейсов
должна появиться метка R, а эти интерфейсы автоматически добавятся в мост
bridge1 (рис. 10.12).
R3 и R2 видят друг друга по протоколам Ethernet и IP. Проверьте это. Мы
создали между R3 и R2 VPN второго уровня.
В протоколе SSTP для организации канала используется
шифрование по
протоколуTLS V1 SSL. В SSTP установка соединения и обмен данными
происходит в зашифрованом виде, и в Wireshark мы ничего не увидим (рис. 10.13).
Деактивируем SSTP -клиента, нажимая в winbox R1->PPP значок X на
соответствующей строке. Деактивируем SSTP сервер (winbox R0->PPP), снимая
галочку enable в его настройках
Рис. 10.14. Мосты в OpenVPN
1.5 OpenVPN
Активируем сервер OpenVPN в R0, установив в winbox галочку enable в его
настройках. Активируем клиент OpenVPN в R1, нажав на строке Ovpn правой
кнопкой и выбрав enable. И на клиенте R1 и на сервере R0 у OpenVPNинтерфейсов должна появиться метка R, а эти интерфейсы автоматически
добавятся в мост bridge1 (рис. 10.14)
R3 и R2 видят друг друга по протоколам Ethernet и IP. Проверьте это. Мы
создали между R3 и R2 VPN второго уровня.
137
grigoryev.victor@gmail.com http://vmg.pp.ua
OpenVPN–сервер использует профиль default в котором для него необходимо
указать локальный и удалённый адреса. Мы взяли адреса 192.168.100.1 и
192.168.200.1, которые никак не влияют на созданный мост. Эти адреса OpenVPN
назначил на OpenVPN-интерфейсы.
Рис. 10.15. OpenVPN назначил адреса для клиента и сервера
Посмотрите в winbox R0 и R1 пункт IP->adresses (рис. 10.15). Пропингуйте из
R0 в R1 и из R1 в R0 по этим адресам.
Для остальных 4-х соединений PPP, PPTP, L2TP и SSTP адреса 192.168.100.1
и 192.168.200.1 в профиле default не используется.
Рис. 10.16. Установка соединения и обмен данными в OpenVPN
В OpenVPN установка соединения и обмен данными происходит в
зашифрованном виде и мы ничего не увидим в анализаторе пакетов (рис. 10.16).
Деактивируем OpenVPN-клиента, нажимая в winbox R1 значок X на
соответствующей строке. Деактивируем OpenVPN-сервер R0, снимая галочку
enable в его настройках
2. Настройка с помощью командной строки
Добавьте в топологию на рис. 10.1 новые 4-е устройства qemu host. Назначьте
адреса и имена в новую топологию l2vpn согласно рис. 10.17. Обеспечим
взаимную
138
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 10.17. Топология l2vpn
видимость тап-интерфейсов роутеров R0, R1, R4 и R5 по протоколу IP (тап-сеть 0)
[admin@R4] >ip ro add dst-address=10.0.0.0/16 gateway=10.0.4.2
[admin@R5] >ip ro add dst-address=10.0.0.0/16 gateway=10.0.5.2
Для новых маршрутизаторов R4, R5, R6 и R7 осуществим настройки из
командной строки и без помощи winbox. При этом повторим для новых
маршрутизаторов те же настройки, которые мы осуществили для старых
маршрутизаторов R0, R1, R2 и R3 с помощью утилиты winbox.
На R4 и R5 осуществим следующие действия
1. Добавим мост и интерфейс в него
int br add
int bridge port add bridge=bridge1 interface=ether1
2. Этот мост добавим в профили по умолчанию
ppp profile print
ppp profile set 0,1 bridge=bridge1
3. Добавим пользователя с паролем
ppp secret add name=q password=q
139
grigoryev.victor@gmail.com http://vmg.pp.ua
2.1 PPP
Запускаем PPP сервер на R4
[admin@R4] >int ppp-server add port=serial1 null-modem=yes disabled=no
Запускаем PPP клиент на R5
[admin@R5] >interface ppp-client add user=q password=q disabled=no dialon-demand=no null-modem=yes port=serial1 use-peer-dns=no add-defaultroute=no
Видим поднявшиеся PPP – интерфейсы (буква R). Клиент
[admin@ R5] > interface ppp-clien pr
Flags: X - disabled, R - running
0 R name="ppp-out1" max-mtu=1500 max-mru=1500 mrru=disabled port=serial1
data-channel=0 info-channel=0 pin="" user="q" password="q"
profile=default
phone="" dial-command="ATDT" modem-init=""
null-modem=yes dial-ondemand=no add-default-route=no use-peer-dns=no
keepalive-timeout=10
allow=pap,chap,mschap1,mschap2
Сервер
[admin@ R4] > int ppp-serve pr det
Flags: X - disabled, R - running
0 R name="ppp-in1" max-mtu=1500 max-mru=1500 mrru=disabled port=serial1 datachannel=0 authentication=pap,chap,mschap1,mschap2 profile=default modem-init=""
ring-count=1 null-modem=yes
И в R4 и в R5 в мост добавился интерфейс c неизвестным именем, например
для R4
[admin@ R4] > interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic
#INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0 ether1
bridge1
0x80 10
none
1 D (unknown)
bridge1
0x80 10
none
R6 и R7 видят друг друга по протоколам Ethernet и IP. Проверьте это.
Остановим сервер и клиент
[admin@ R4] >int ppp-server set 0 disabled=yes
[admin@ R5] >int ppp-client set 0 disabled=yes
2.2 PPTP
Запускаем PPTP-сервер R4
[admin@ R4] >interface pptp-server server set enabled=yes
Запускаем PPTP-клиент R5
[admin@ R5] >int pptp-client add user=q password=q connect-to=10.0.4.1
disabled=no
Видим поднявшиеся PPP – интерфейсы (буква R). У сервера
[admin@ R4] >interface pptp-serve pr detail
Flags: X - disabled, D - dynamic, R - running
0 DR name="<pptp-q>" user="q" mtu=1460 mru=1460 client-address="10.0.5.1"
uptime=4m29s encoding="MPPE128 stateless"
У клиента
140
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@ R5] > int pptp-client print detail
Flags: X - disabled, R - running
0 R name="pptp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connectto=10.0.4.1 user="q" password="q" profile=default-encryption add-default-route=no
dial-on-demand=no allow=pap,chap,mschap1,mschap2
Команда interface bridge port print покажет, что и в R4 и в R5 в мост
добавился интерфейс. R6 и R7 видят друг друга по протоколам Ethernet и IP.
Проверьте это.
Остановим сервер и клиент
[admin@ R4] >int pptp-server set 0 disabled=yes
[admin@ R5] >int pptp-client set 0 disabled=yes
2.3 L2TP
L2TP полностью аналогичен PPTP (поменяйте в командах строку pptp на
строку l2tp)
2.4 SSTP
Надо импортировать сертификаты. Сертификаты мы создали ранее и они
находятся в Ubuntu в папке easy-rsa/keys. Перейдите в неё. Перепишем
сертификаты и ключ из Ubuntu в SSTP-сервер.
ftp 10.0.4.1
Перепишем сертификаты и ключ в SSTP- клиент.
ftp 10.0.5.1
Импортируем сертификаты в сервере
[admin@ R4] > certificate import file-name=ca.crt
[admin@ R4] > certificate import file-name=server.crt
[admin@ R4] > certificate import file-name=server.key
На запрос passphrase – просто жмём enter
Проверим
[admin@ R4] > certificate pr
Flags: K - decrypted-private-key, Q - private-key, R - rsa, D - dsa
0 name="cert1" subject=C=US,ST=CA,L=SanFrancisco,O=FortFunston,CN=Fort-Funston CA,emailAddress=me@myhost.mydomain
issuer=C=US,ST=CA,L=SanFrancisco,O=Fort-Funston,CN=Fort-Funston CA,
emailAddress= me@myhost.mydomain serial-number="C8A494A29F4DC49F" email=
me@myhost.mydomain
invalid-before=may/11/2011 15:34:56 invalid-after=
may/08/2021 15:34:56 ca=yes
1 KR name="cert2" subject=C=US,ST=CA,L=SanFrancisco, O=FortFunston,CN=server,
emailAddress=me@myhost.mydomain
issuer=C=US,ST=CA,L= SanFrancisco,O=Fort-Funston,CN=Fort-Funston CA,
emailAddress= me@myhost.mydomain serial-number= "01" email=me
@myhost.mydomain
invalid-before=may/11/2011 15:35:13 invalidafter=may/08/2021 15:35:13 ca=yes
Переименовываем KR сертификат
[admin@ R4] > sys certificate set 1 name=srv
141
grigoryev.victor@gmail.com http://vmg.pp.ua
Импортируем сертификаты у клиента
[admin@ R5] >certificate import file-name=ca.crt
[admin@ R5] >certificate import file-name=client.crt
[admin@ R5] >certificate import file-name=client.key
На запрос passphrase – просто жмём enter
Проверим
[admin@ R5] >certificate print detail
Flags: K - decrypted-private-key, Q - private-key, R - rsa, D - dsa
0 name="cert1" subject=C=US,ST=CA,L=SanFrancisco,O=FortFunston,CN=Fort-Funston CA,emailAddress=me@myhost.mydomain
issuer=C=US,ST=CA,L=SanFrancisco,O=Fort-Funston,CN=Fort-Funston
CA,emailAddress=me@myhost.mydomain serial-number= C8A494A29F
email=me@myhost.mydomain invalid-before =may /11/2011 15:34:56 invalidafter=may/08/2021 15:34:56
ca=yes
1 KR name="cert2" subject=C=US,ST=CA,L=SanFrancisco,O=FortFunston,CN=client, emailAddress=me@myhost.mydomain issuer=C=US,
ST=CA,L=SanFrancisco,O=Fort-Funston,CN=Fort-Funston CA,
mailAddress=me@myhost.mydomain serial-number="02" email=me
@myhost.mydomain invalid-before=may/11/2011 15:35:33 invalid-after= may/08/2021
15:35:33 ca=yes
Переименовываем KR сертификат клиента
[admin@ R5] >certificate set 1 name=cli
Запускаем SSTP сервер R4
[admin@R4]>interface sstp-server server set enabled=yes certificate=srv
verify-client-certificate=yes
Запускаем SSTP клиент R5
[admin@R4]>int sstp-client add user=q password=q connect-to=10.0.4.1
disabled=no certificate=cli verify-server-certificate=yes
Интерфейсы поднялись. И в R4 и в R4 в мост добавился интерфейс. R6 и R7
видят друг друга по протоколам Ethernet и IP. Проверьте это.
Остановим сервер и клиент
[admin@ R4] >int sstp-server set 0 disabled=yes
[admin@ R5] >int sstp-client set 0 disabled=yes
2.5 OpenVPN
Пропишем в профиле сервера локальный и удалённый адреса
[admin@ R4] >ppp profile pr
[admin@ R4]>ppp profile set 0 local-address=192.168.100.1 remoteaddress=192.168.200.1
Запускаем OpenVPN-сервер R4
[admin@ R4] >interface ovpn-server server set enabled=yes certificate=srv
require-client-certificate=yes mode=Ethernet
Запускаем OpenVPN-клиент R5
[admin@ R5] >interface ovpn-client add user=q password=q connectto=10.0.4.1 disabled=no certificate=cli mode=Ethernet
142
grigoryev.victor@gmail.com http://vmg.pp.ua
Интерфейсы поднялись (буква D). [admin@ R4] >interface bridge port print
detail
Flags: X - disabled, I - inactive, D - dynamic
0 interface=ether1 bridge=bridge1 priority=0x80 path-cost=10 edge=auto pointto-point=auto external-fdb=auto horizon=none
1 D interface=<ovpn-q> bridge=bridge1 priority=0x80 path-cost=10 edge=no
point-to-point=yes external-fdb=no horizon=none
И в R4 и в R4 в мост добавился интерфейс
[admin@ R5] >interface bridge port print detail
Flags: X - disabled, I - inactive, D - dynamic
0 interface=ether1 bridge=bridge1 priority=0x80 path-cost=10 edge=auto pointto-point=auto external-fdb=auto horizon=none
1 D interface=ovpn-out1 bridge=bridge1 priority=0x80 path-cost=10 edge=no
point-to-point=yes external-fdb=no horizon=none
R6 и R7 видят друг друга по протоколам Ethernet и IP. Проверьте это.
Остановим сервер и клиент
[admin@ R4] >int ovpn-server set 0 disabled=yes
[admin@ R5] >int ovpn-client set 0 disabled=yes
Рис. 10.18. Топология l2vpn1
Распределённый мост
Рассмотрим более сложные варианты использования мостов. Возьмём
протокол PPTP. Для остальных протоколов конфигурация аналогична. Соберём
топологию, изображённую на рис. 10.18. Назначьте адреса согласно этому рисунку.
Во всех маршрутизаторах R0, R1, R4 и R5 добавим мосты и в них Ethernetинтерфейс, идущий к подсоединённому компьютеру R2, R3, R6 и R7,
соответственно.
interface bridge add
143
grigoryev.victor@gmail.com http://vmg.pp.ua
interface bridge port add bridge=bridge1 interface=ether1
Маршрутизаторы R0, R1 и R4 будут PPTP-серверами, а маршрутизаторы R1,
R4 и R5 – PPTP-клиентами. То есть R1 и R4 являются одновременно и серверами и
клиентами.
Определим в серверах пользователя q с паролем q.
ppp secret add name=q password=q
По умолчанию сервера и
клиенты имеют профиль default encription.
Пользователь по умолчанию имеет профиль default. Профиль пользователя
подавляет профиль сервера. В каком профиле определить мост? И на серверах и на
клиентах определим мост в профиле default.
ppp profile set 0 bridge=bridge1
Здесь 0 - номер профиля default, который можно увидеть из команды ppp
profile print
В самих клиентах заменим профиль default encription на профиль default,
зададим пользователя q с паролем, зададим адреса серверов и активируем их
[admin@R1]>interface pptp-client add profile=default user=q password=q
connect-to=10.0.0.1 disabled=no
[admin@R4]>interface pptp-client add profile=default user=q password=q
connect-to=10.0.1.1 disabled=no
[admin@R5]>interface pptp-client add profile=default user=q password=q
connect-to=10.0.4.1 disabled=no
Активируем сервера.
interface pptp-server server set enabled=yes
В консолях маршрутизаторов R0, R1, R4, R5 введём команду interface bridge
port print. Видим, что в мостах появятся новые динамические PPTP интерфейсы.
Причем в маршрутизаторах R1, R4 их будет два: для клиента и сервера.
Получился распределённый мост (или свич): все компьютеры R2, R3, R6, R7
лежат в одной Ethernet-сети.
R2 и R7 видят друг друга по протоколам Ethernet и IP. Проверьте это.
Повторите всё для протоколов L2TP, SSTP и OpenVPN.
Использование профилей пользователя.
Соберём топологию l2vpn2, изображённую на рис. 10.19. В ней адреса
компьютеров R2 и R3 лежат в сети 172.16.1.0/24. Адреса компьютеров R6 и R7
лежат в той же сети 172.16.1.0/24. Назначьте адреса и имена согласно рисунку.
Маршрутизатор R0 будет PPTP-сервером, а маршрутизаторы R1, R4- PPTP
клиентами. Во всех клиентах R1 и R4 добавьте мосты и в них Ethernet-интерфейс,
идущий к подсоединённому компьютеру. На клиентах в профиле default определим
мост
ppp profile set 0 bridge=bridge1
Здесь 0 - номер профиля default, который можно увидеть из команды ppp
profile print
144
grigoryev.victor@gmail.com http://vmg.pp.ua
На сервере добавим два моста и в каждый из них добавим по одному Ethernet
интерфейсу, идущему к разным компьютерам. Пусть ether1 идёт к R2, а ether2 идёт
к R7.
Рис. 10.19. Топология l2vpn2
[admin@R0]>interface bridge add
[admin@R0]>interface bridge add (2 раза)
[admin@R0]>int bridge port add bridge=bridge1 int= ether1
[admin@R0]>int bridge port add bridge=bridge2 int= ether2
Создадим для моста bridge1 профиль 1, а для моста bridge2 профиль 2
[admin@R0]>ppp profile add name=1 bridge=bridge1
[admin@R0]>ppp profile add name=2 bridge=bridge2
Создадим пользователей 1 и 2 с профилями 1 и 2, соответственно
[admin@R0]>ppp secret add name=1 password=1 profile=1
[admin@R0]>ppp secret add name=2 password=1 profile=2
Активируем сервер
interface pptp-server server set enabled=yes
В самих клиентах заменим профиль default encription на профиль default,
зададим разных пользователей с паролем, зададим адрес сервера и активируем их
[admin@R1]>interface pptp-client add profile=default user=1 password=1
connect-to=10.0.0.1 disabled=no
[admin@R4]>interface pptp-client add profile=default user=2 password=2
connect-to=10.0.0.1 disabled=no
145
grigoryev.victor@gmail.com http://vmg.pp.ua
В консолях маршрутизаторов R0, R1 и R4 введём команду interface bridge
port print. Видим, что в мостах появятся новые динамические PPTP-интерфейсы.
Причем в маршрутизаторе R0 они располагаются в разных мостах.
Мы получили два независимых распределённых виртуальных моста (свича).
Компьютеры R2 и R3 лежат в одной Ethernet-сети, а компьютеры R6 и R7 лежат в
другой Ethernet-сети. Эти Ethernet-сети никак не связаны, и в них даже можно
назначать одинаковые адреса, например из сети 172.16.1.0.24. Проверим
[admin@R3]>system telnet 172.16.1.1
Попадём в R2. Выход ctrl-d.
[admin@R6]>system telnet 172.16.1.1
Попадём в R7. Выход ctrl-d.
Повторите всё для протоколов L2TP, SSTP и OpenVPN.
1.
2.
3.
4.
Требования для сдачи работы
Для топологии, изображённой на рис.10.1 объединить, используя утилиту
winbox, компьютеры R2 и R3 в VPN второго уровня c помощью протоколов
PPP, PPTP, L2TP, SSTP и OpenVPN.
Для топологии, изображённой на рис.10.17 объединить, используя командную
строку, компьютеры R6 и R7 в VPN второго уровня c помощью протоколов
PPP, PPTP, L2TP, SSTP и OpenVPN.
Настроить распределённый мост, изображённый на рис. 10.18 с помощью
протоколов PPTP, L2TP, SSTP и OpenVPN. Крайние роутеры R2 и R7 должны
пинговать друг друга.
С помощью протоколов PPTP, L2TP, SSTP и OpenVPN для топологии,
изображённой на рис. 10.19 настроить две независимые VPN второго уровня.
В первую VPN входят роутеры R2 и R3, а во вторую – R6 и R7.
146
grigoryev.victor@gmail.com http://vmg.pp.ua
11. Построение VPN третьего уровня c помощью производных от
PPP протоколов и OpenVPN
Маршрутизация RIP
Маршрутизация OSPF
VPN уровня 3 через NAT
Протоколы GRE и IPIP
148
149
151
152
Соберём топологию, изображённую рис. 11.1. Назначьте имена и адреса
согласно рисунку. Пропишем на компьютерах R2, R3 и R6 маршрут по умолчанию
[admin@R2]>ip route add gateway = 192.168.100.1
[admin@R3]>ip route add gateway = 192.168.101.1
[admin@R6]>ip route add gateway = 192.168.102.1
Рис. 11.1. Топология l3vpnrip
Объединим компьютеры R2, R3 и R6 в VPN третьего уровня.
R0 сделаем PPPT-сервером, а R3 и R6 - PPPT-клиентами. Поставим задачу
так организовать маршрутизацию, чтобы компьютеры R2, R3 и R6 видели бы друг
друга по протоколу IP.
Если мы не используем мосты, то надо определится с адресами, назначаемыми
на PPPTP-интерфейсы после установки PPPT-соединения.
Добавим в PPPT-сервере R0 пул адресов, назначаемых подсоединившимся
PPPTP-клиентам
[admin@R0]>ip pool add ranges=172.16.1.2-172.16.1.254 name=pool
Пропишем это в профиле default. Адрес 172.16.1.1 мы будем назначать на
интерфейс PPPT-сервера
[admin@R0]>ppp profile set 0 local-address=172.16.1.1 remote-address=pool
147
grigoryev.victor@gmail.com http://vmg.pp.ua
Не забудьте убрать из профиля мост (если он там остался). Создадим
пользователя
[admin@R0]>ppp secret add name=q password=q
Активируем сервер
interface pptp-server server set enabled=yes
В самих клиентах R1 R4 зададим пользователя q с паролем и зададим адрес
сервера
interface pptp-client add profile=default user=q password=q connectto=10.0.0.1 disabled=no
На сервере появилось два одинаковых адреса, но в разных сетях
[admin@R0]>ip ad pr
0
10.0.0.1/24
10.0.0.0
ether7
1
192.168.100.1/24
192.168.100.0
ether1
2D
172.16.1.1/32
172.16.1.253
<pptp-q-1>
3D
172.16.1.1/32
172.16.1.254
<pptp-q>
На клиенте R1 появился адрес 172.16.1.254
[admin@ R1] > ip ad pr
0
10.0.1.1/24
10.0.1.0
ether7
1
192.168.101.1/24
192.168.101.0
ether1
2D
172.16.1.254/32
172.16.1.1
pptp-out1
На клиенте R4 появился адрес 172.16.1.253
[admin@ R4] > ip ad pr
0
10.0.4.1/24
10.0.4.0
ether7
1
192.168.102.1/24
192.168.102.0
ether1
2D
172.16.1.253/32
172.16.1.1
pptp-out2
Обратите внимание на маску назначенных адресов и сети. В нашей топологии
фигурирует 3 сети с маской /24 192.168.100.0/24 192.168.101.0/24 192.168.102.0/24
и в общем случае переменное число сетей с маской /32. Это число зависит от
количества клиентов. В нашем случае имеем 3 сети 172.16.1.1 172.16.1.253
172.16.1.254
Можно прописать маршрутизацию статически (сделайте это).
Маршрутизация RIP
Воспользуемся протоколом RIP. Так как нельзя предсказать, какие адреса
будут назначены клиентам, будем оперировать сетью 172.16.1.0/24.
[admin@R0]>routing rip network add network=172.16.1.0/24
[admin@R0]>routing rip network add network=192.168.100.0/24
[admin@R1]>routing rip network add network=172.16.1.0/24
[admin@R1]>routing rip network add network=192.168.101.0/24
[admin@R4]>routing rip network add network=172.16.1.0/24
[admin@R4]>routing rip network add network=192.168.102.0/24
Посмотрим созданные RIP-маршруты
[admin@R4]> ip ro pr
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
148
grigoryev.victor@gmail.com http://vmg.pp.ua
#
DST-ADDRESS
PREF-SRC
GATEWAY
DISTANCE
0AS
10.0.0.0/16
10.0.4.2
1
1 ADC
10.0.4.0/24
10.0.4.1
ether7
0
2 ADC
172.16.1.1/32
172.16.1.253
pptp-out2
0
3 ADr 172.16.1.254/32
172.16.1.1
120
4 ADr 192.168.100.0/24
172.16.1.1
120
5 ADr 192.168.101.0/24
172.16.1.1
120
6 ADC192.168.102.0/24 192.168.102.1 ether1
0
Есть маршруты на сети 192.168.100.0/24 и192.168.101.0/24 и компьютеров R2
и R3, соответственно.
[admin@R1]> ip ro pr
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
0AS
10.0.0.0/16
10.0.1.2
1
1 ADC
10.0.1.0/24
10.0.1.1
ether7
0
2 ADC
172.16.1.1/32
172.16.1.254
pptp-out1
0
3 ADr
172.16.1.253/32
172.16.1.1
120
4 ADr
192.168.100.0/24
172.16.1.1
120
5 ADC
192.168.101.0/24 192.168.101.1
ether1
0
6 ADr
192.168.102.0/24
172.16.1.1
120
Есть маршруты на сети 192.168.100.0/24 и192.168.102.0/24 и компьютеров R2
и R6, соответственно.
Аналогично на R2 есть маршруты на сети 192.168.101.0/24 и192.168.102.0/24
и компьютеров R3 и R6, соответственно.
R2, R3 и R6 увидят друг друга по IP. VPN третьего уровня создана.
Такой трюк с сетью 172.16.1.0/24 для OSPF не проходит
Маршрутизация OSPF
Теперь переделаем конфигурацию для маршрутизации путём назначения
каждому клиенту определённого адреса. Этого добьемся путем назначения
каждому клиенту отдельного имени со своим профилем. Сделайте копию l3vpnospf
топологии l3vpnrip. На сервере R0 создадим 2 профиля
[admin@R0]>ppp profile add name=1 local-address=172.16.1.1 remoteaddress=172.16.1.2
[admin@R0]>ppp profile add name=2 local-address=172.16.1.1 remoteaddress=172.16.1.3
Создадим пользователей 1 и 2 с профилями 1 и 2, соответственно
[admin@R0]>ppp secret add name=1 password=1 profile=1
[admin@R0]>ppp secret add name=2 password=2 profile=2
Активируем сервер
[admin@R0]>interface pptp-server server set enabled=yes
Убъём старых pptp клиентов на R1 R4
interface pptp-client rem 0
149
grigoryev.victor@gmail.com http://vmg.pp.ua
Добавим новых
[admin@R1]>interface pptp-client add user=1 password=1 connect-to=10.0.0.1
disabled=no
[admin@R4]>interface pptp-client add user=2 password=2 connect-to=10.0.0.1
disabled=no
На сервере появилось два одинаковых адреса, но в разных сетях
[admin@ R0] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
#
ADDRESS
NETWORK
INTERFACE
0
10.0.0.1/24
10.0.0.0
ether7
1
192.168.100.1/24
192.168.100.0
ether1
2 D 172.16.1.1/32
172.16.1.3
<pptp-2>
3 D 172.16.1.1/32
172.16.1.2
<pptp-1>
На клиентах появились адреса
[admin@ R1] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
#
ADDRESS
NETWORK
INTERFACE
0
10.0.1.1/24
10.0.1.0
ether7
1
192.168.101.1/24
192.168.101.0
ether1
2 D 172.16.1.2/32
172.16.1.1
pptp-out1
[admin@ R4] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
#
ADDRESS
NETWORK
INTERFACE
0
10.0.4.1/24
10.0.4.0
ether7
1
192.168.102.1/24
192.168.102.0
ether1
2 D 172.16.1.3/32
172.16.1.1
pptp-out1
Воспользуемся протоколом OSPF
[admin@R0]>routing ospf network add network=172.16.1.2 area=backbone
[admin@R0]>routing ospf network add network=172.16.1.3 area=backbone
[admin@R0]>routing ospf network add network=192.168.100.0/24
area=backbone
[admin@R1]>routing ospf network add network=172.16.1.1 area=backbone
[admin@R1]>routing ospf network add network=192.168.101.0/24
area=backbone
[admin@ R4]>routing ospf network add network=172.16.1.1 area=backbone
[admin@R4]>routing ospf network add network=192.168.102.0/24
area=backbone
Обратите внимание, что в настройках сетей для OSPF (как и в RIP)
экспортируется сеть, а не адрес. Посмотрим созданные OSPF маршруты
[admin@ R4] > ip ro pr
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
0AS
10.0.0.0/16
10.0.4.2
1
1 ADC
10.0.4.0/24
10.0.4.1
ether7
0
150
grigoryev.victor@gmail.com http://vmg.pp.ua
2 ADC
172.16.1.1/32
172.16.1.3
pptp-out1
0
3 ADo
172.16.1.2/32
172.16.1.1
110
4 ADo
172.16.1.3/32
172.16.1.1
110
5 ADo
192.168.100.0/24
172.16.1.1
110
6 ADo
192.168.101.0/24
172.16.1.1
110
7 ADC 192.168.102.0/24 192.168.102.1 ether1
0
Есть маршруты на сети 192.168.100.0/24 и192.168.101.0/24 и компьютеров R2
и R3, соответственно
[admin@ R1] > ip ro pr
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
0AS
10.0.0.0/16
10.0.1.2
1
1 ADC
10.0.1.0/24
10.0.1.1
ether7
0
2 ADC
172.16.1.1/32
172.16.1.2
pptp-out1
0
3 ADo
172.16.1.2/32
172.16.1.1
110
4 ADo
172.16.1.3/32
172.16.1.1
110
5 ADo
192.168.100.0/24
172.16.1.1
110
6 ADC
192.168.101.0/24 192.168.101.1
ether1
0
7 ADo
192.168.102.0/24
172.16.1.1
110
Есть маршруты на сети 192.168.100.0/24 и192.168.102.0/24 и компьютеров R2
и R6, соответственно.
Аналогично на R2 есть маршруты на сети 192.168.101.0/24 и192.168.102.0/24
и компьютеров R3 и R6, соответственно.
R2, R3 и R6 увидят друг друга по IP. R6 и наоборот. VPN третьего уровня
создана
Повторите настройки OSPF для протоколов L2TP, SSTP и OpenVPN.
VPN уровня 3 через NAT
Соберём топологию, изображённую рис. 11.2. Проверьте соседей. Здесь R3 и
R4 – маршрутизаторы Интернет-провайдера. Назначьте для R2 и R3 адреса из
сети 192.168.1.0/24 согласно рисунку. Для R2 назначьте шлюз 192.168.1.1.
Назначьте для R4 и R6 адреса из сети 192.168.2.0/24. Для R2 назначьте шлюз
192.168.2.1. Назначьте на тап-интерфейсы R4 и R6 адреса, согласно номеру своей
тап-сети. Обеспечьте маршрутизацию между тап-интерфейсами. Назначьте на тапинтерфейс R4 второй адрес
[admin@R4]>ip ad ad address=10.0.4.22/24 interface=ether7
Настройте NAT для исходящих
[admin@R3]>ip firewall nat add chain=srcnat action=masquerade outinterface=ether7
и приходящих адресов
[admin@R4]>ip firewall nat add chain=dstnat action=dst-nat toaddresses=192.168.2.2 dst-address=10.0.4.22
Набрав на R2
[admin@R2] > sys telnet 10.0.4.22
151
grigoryev.victor@gmail.com http://vmg.pp.ua
должны попасть в 192.168.2.2 (R6). Выход CtrlD
Настроим PPTP, полагая, что профиль default имеет номер 0
[admin@R6] > ppp profile set 0 local-address=172.16.1.1 remoteaddress=172.16.1.2
[admin@R6] > ppp secret add name="q" service=pptp password="q"
profile=default
Запускаем PPTP сервер на R6
[admin@R6] >interface pptp-server server set enabled=yes
Настроим PPTP-клиент на R2. Соединяемся к PPTP-серверу R6 через NAT
т.е. через адрес 10.0.4.22, а не через адрес 192.168.2.2 PPTP-сервера R6 .
[admin@R2] > interface pptp-client add connect-to=10.0.4.22 user="q"
password="q" disabled=no
Проверим доступность R6 из R2 по новому адресу
[admin@R2] ping 172.16.1.1
Рис. 11.2 VPN 3 уровня через NAT
Рис. 11.3. Топология
Протоколы GRE и IPIP
Помимо протоколов PPTP, L2TP, SSTP и OpenVPN для организации VPN третьего
уровня можно использовать протоколы GRE или IPIP. Соберём топологию на рис.
11.4. Назначим на Ethernet-интерфейсы адреса из сети 1.1.1.0/24.
С помощью Winbox (Interfaces->+->GRE Tunnel) GRE-туннель и назначьте на
его концы адреса из сети 11.1.1.0/24. Пустите пинг из Qemu2 на адрес туннеля
11.1.1.1.
152
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 11.4. GRE и IPIP
Деактивируйте GRE-туннель и настройте IPIP-туннель (Interfaces->+->IP
Tunnel). Назначьте на его концы адреса из сети 11.1.1.0/24. Пустите пинг из Qemu2
на адрес туннеля 11.1.1.1.
Если вы обладаете правами суперпользователя, то в GNS3 с помощью
Wirehark можно увидеть иерархию протоколов, изображённую на рис. 11.5 и 11.6.
Рис. 11.5. Иерархия протоколов для GRE
Рис. 11.6. Иерархия протоколов для IPIP
153
grigoryev.victor@gmail.com http://vmg.pp.ua
Требования для сдачи работы
Для топологии на рис. 11.3 настроить VPN 3 уровня через NAT для
протоколов PPTP, L2TP, SSTP и OpenVPN. Протокол маршрутизации
выбрать самостоятельно.
В топологии на рис. 11.4 предъявить работающие GRE и IPIP туннели.
154
grigoryev.victor@gmail.com http://vmg.pp.ua
12. PPPoE
Протокол Ethernet не имеет средств для аутентификации, сжатия данных и
шифрования. Протокол PPPOE предоставляет эти дополнительные возможности.
Рассмотрим типичную локальную сеть (рис. 12.1), состоящую из свича Sw3 и трёх
сетевых устройств Srv0, Cli1 и Cli2. На уровне протокола Ethernet все эти
устройства доступны друг другу без всяких паролей. Протокол PPPOE позволяет,
по крайней мере, ввести доступ к локальной сети только через пароль.
Помним, что свич Sw3 это обычный роутер, у которого интерфейсы e0, e1 и e2
объеденены в мост. Srv0 будет PPPoE-сервером. Добавим пользователей PPPoE
[admin@Srv0]>ppp secret add
name="1" service=pppoe password="1"
profile= default
[admin@Srv0]>ppp secret add
name="2" service=pppoe password="2"
profile=default
Рис. 12.1. Локальная сеть
Настроим в сервере PPPoE пул адресов. PPPoE-клиенты Cli1 и Cli2 будут
получать адреса из этого пула
[admin@Srv0]>ip pool add name="pool1" ranges=192.168.1.100-192.168.1.200
Изменим профиль по умолчанию, указав в нём созданный пул адресов, а в
качестве локального адреса PPPoE-сервера укажем адрес 192.168.1.1
[admin@Srv0]>ppp profile set 0 local-address=192.168.1.3 remoteaddress=pool1
где 0-номер профиля по умолчанию.
Настроим сервер PPPoE на интерфейсе ether1 (e0) с профилем по умолчанию
[admin@Srv0]>interface pppoe-server server add interface=ether1 defaultprofile=default
Настроим клиентов PPPoE, указывая Erthernet-интерфейсы через которые они
будут соединяться с PPPoE-сервером, а также имя и пароль для доступа в сеть
155
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@Cli1]>interface pppoe-client add interface=ether1 user="1"
password="1" profile=default
[admin@Cli2]>interface pppoe-client add interface=ether1 user="2"
password="2" profile=default
Установятся два PPPoE-соединения (флаг R)
[admin@Srv0] > int pppoe-server pr
Flags: X - disabled, D - dynamic, R - running
#NAME USER SERVICE REMOTE-ADDRESS ENCODING UPTIME
0 DR <pp... 2
service1 00:AA:00:28:B...
40m36s
1 DR <pp... 1
service1 00:AA:00:BD:1...
40m33s
[admin@Cli1] > int pppoe-client pr
Flags: X - disabled, R - running
0
R name="pppoe-out1" max-mtu=1480 max-mru=1480 mrru=disabled
interface=ether1 user="1" password="1" profile=default service-name="" ac-name=""
add-default-route=yes
dial-on-demand=no
use-peer-dns=no
allow=pap,chap,mschap1,mschap2
[admin@Cli2] > int pppoe-client pr
Flags: X - disabled, R - running
0
R name="pppoe-out1" max-mtu=1480 max-mru=1480 mrru=disabled
interface=ether1 user="2" password="2" profile=default service-name="" ac-name=""
add-default-route=yes
dial-on-demand=no
use-peer-dns=no
allow=pap,chap,mschap1,mschap2
Клиентам динамически назначаться IP-адреса с маской /32 из указанного пула.
[admin@Cli1] > ip ad pri
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
1 D 192.168.1.253/32 192.168.1.1 pppoe-out1
[admin@Cli2] > ip ad pri
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
1 D 192.168.1.254/32 192.168.1.1 pppoe-out1
Обратите внимание на сеть 192.168.1.1. Это адрес PPPoE-сервера, который
будет ему назначен дважды, но с разными сетями 192.168.1.253 и 192.168.1.254,
определяемыми адресами клиентов
[admin@Srv0] > ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS
NETWORK
INTERFACE
1 D 192.168.1.1/32 192.168.1.254 <pppoe-2>
2 D 192.168.1.1/32 192.168.1.253 <pppoe-1>
У клиентов добавится маршрут по умолчанию 192.168.1.1
и маршрут
в сторону PPPoE-сервера
[admin@Cli1] > ip ro pr
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
156
grigoryev.victor@gmail.com http://vmg.pp.ua
0 ADS 0.0.0.0/0
192.168.1.1
1
2ADC 192.168.1.1/32
192.168.1.253 pppoe-out1
0
[admin@Cli2] > ip ro pr
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 ADS 0.0.0.0/0
192.168.1.1
1
2ADC 192.168.1.1/32 192.168.1.254
pppoe-out1
0
У сервера добавится два маршрут в сторону PPPoE-клиентов
[admin@Srv0] > ip ro pr
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
1 ADC 192.168.1.253/32 192.168.1.1 <pppoe-1>
0
2 ADC 192.168.1.254/32 192.168.1.1 <pppoe-2>
0
Клиенты видят друг друга по протоколу IP, будто бы работают в чистой
Ethernet сети безо всякого PPPoE. Однако, не зная пароль, они в сеть не попадут.
[admin@Cli1] > ping 192.168.1.254
HOST
SIZE TTL TIME STATUS
192.168.1.254
56 63 12ms
sent=1 received=1 packet-loss=0% min-rtt=12ms avg-rtt=12ms max-rtt=12ms
[admin@Cli2] > ping 192.168.1.253
HOST
SIZE TTL TIME STATUS
192.168.1.254
56 63 12ms
sent=1 received=1 packet-loss=0% min-rtt=12ms avg-rtt=12ms max-rtt=12ms
PPPoE допускает более сложные конфигурации. Соберите топологию,
приведенную на рисунке рис. 12.2. Назначьте имена согласно рисунку. Назначьте
на R7, R6 и R4 адреса 192.168.1.1/24, 192.168.1.2/24 192.168.1.3/24 согласно
рисунку.
В этой топологии мы видим
локальную Erthernet-сеть, образованную
компьютерами R7, R6 и маршрутизатором R4. Мы хотим через роутер R4 с
помощью протокола PPPoE присоединить к этой Erthernet-сети новые компьютеры
R2 и R3.
R4 будет PPPoE-сервером. Добавим пользователей PPPoE
[admin@R4] > /ppp secret add
name="1" service=pppoe password="1"
profile=defaul
[admin@R4] > /ppp secret add
name="2" service=pppoe password="2"
profile=default
Настроим в сервере PPPoE пул адресов. Адреса пула должны лежать в уже
существующей сети 192.168.1.0/24
[admin@R4] >ip pool add name="pool1" ranges=192.168.1.100-192.168.1.200
Изменим профиль по умолчанию, указав в нём созданный пул адресов, а в
качестве локального адреса PPPoE-сервера укажем уже занятый этим роутером R4
адрес 192.168.1.3
[admin@R4]>ppp profile set 0 local-address=192.168.1.3 remote-address=pool1
157
grigoryev.victor@gmail.com http://vmg.pp.ua
Настроим PPPoE-сервер на интерфейсе ether1 (e0)
[admin@R4]>interface pppoe-server server add interface=ether1defaultprofile=default
Настроим клиентов PPPoE, указывая им Erthernet-интерфейсы через которые
они будут соединяться с PPPoE-сервером
[admin@R3] >interface pppoe-client add interface=ether1 user="1"
password="1" profile=default
[admin@R2]>interface
pppoe-client
add
interface=ether2
user="2"
password="2" profile=default
Рис. 12.2. Более сложная конфигурация PPPoE
Проверьте, что установились два PPPoE-соединения (int pppoe-server pr, int
pppoe-client pr) и динамически назначены IP-адреса с маской /32 клиентам из
указанного пула и адрес 192.168.1.3 серверу (ip ad pri). Адрес 192.168.1.3 у R4
повторяется три раза, но сети у адресов разные и они (сети) определяются
клиентскими адресами.
Чтобы PPPoE клиенты R2 и R3 могли связаться по IP с компьютерами R6 и
R7 они должны быть в состоянии послать им ARP-запрос и получить от них ARPответ. Но между ними лежит устройство R4. Нужно сделать так, чтобы R4
транслировало ARP-пакеты. Поэтому в R4 организуем прокси-ARP для интерфейса
ether2(e1), так как e1 смотрит в сторону R6 и R7
158
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@R4] > interface ethernet print
0 R ether1
1500 00:AA:00:E5:69:00 enabled
1 R ether2
1500 00:AA:00:E5:69:01 enabled
[admin@R4] > interface ethernet set 1 arp=proxy-arp
Теперь каждое устройство пингует каждое. Проверьте.
Мы объединили два сегмента Ethernet в одну IP-сеть.
Требования для сдачи работы
Предоставить работающие топологии, изображённые на рис. 12.1 и рис. 12.2.
159
grigoryev.victor@gmail.com http://vmg.pp.ua
13. Ipsec
Состав IPsec
SA (Security Association)
Политики IPsec
Фазы IKE
Конфигурация IPsec в Mikrotik RouterOS
Шифрация соединения точка-точка
Организация VPN типа сайт-сайт с помощью IPsec
`
160
161
162
162
163
166
169
Состав IPsec
Ipsec (Internet Protocol Security) это конструктор, набор протоколов,
фреймворк, позволяющий обеспечить требуемую безопасность передачи
Фреймворк Ipsec.
Таблица 13.1
Ipsec-протокол
AH
ESP, ESP+AH
Конфиденциальность
DES, 3DES, AES, SEAL
и др
Целостность
MD5, SHA
Аутентификация
PSK, RSA
Алгоритм
Диффи Группа Диффи-Хеллмана (сила
Хеллмана
шифра)
IKE – Протокол обмена Интернет-ключей
Конфиденциальность обеспечивается протоколами шифрования DES, 3DES,
AES, SEAL. Приведены протоколы в порядке возрастания безопасности. Чем
безопасней протокол, тем он требует больших вычислительных мощностей.
Целостность – гарантия того, что данные не были изменены во время
передачи. Для этого по алгоритму MD5 или SHA вычисляют хеш данных о
целостности которых беспокоятся. Хеш вместе с данными передаются по сети.
Для аутентификации участников сетевого обмена применяется или заранее
известный обеим сторонам ключ
(PSK - Preshared Keys) или цифровые
сертификаты RSA.
Алгоритм Диффи-Хеллмана предлагает процедуру обмена данными между
двумя сторонам через небезопасное соединение, которая приводит к генерации
общего секретного ключа для шифрования. Сам ключи не передаётся.
Есть два варианта Ipsec-протокола: AH и ESP. Протокол AH (Authentication
Header - заголовок аутентификации) обеспечивает проверку подлинности
содержания IP-датаграммы путем добавления в датаграмму контрольного хешзначения, которое рассчитывается на основе этой датаграммы. Какие части
датаграммы используются для расчета, а также размещение полей датаграммы,
зависит от того, какой режим используется: туннельный или транспортный.
В транспортном режиме AH-заголовок вставляется после заголовка IP. AHзаголовок содержит контрольное хеш-значение. Для его расчета используется IPданные и заголовки. IP-поля, которые могут меняться во время транзита, какие как
TTL, приводятся к нулевым значениям до аутентификации.
160
grigoryev.victor@gmail.com http://vmg.pp.ua
В туннельном режиме исходный пакет IP инкапсулируется в новый пакет IP.
Весь исходный пакет IP проходит проверки подлинности. AH-заголовок
вставляется после нового заголовка IP
AH это протокол, который не шифрует датаграмму. Для шифрования
используется другой протокол ESP. Основным и единственным назначением AH
является обеспечение защиты от атак, связанных с несанкционированным
изменением содержимого пакета, и в том числе от подмены исходного адреса
сетевого уровня.
Протокол ESP (Encapsulating Security Payload - Инкапсуляция зашифрованных
данных)
использует
общий
ключ
шифрования
для
обеспечения
конфиденциальности данных. ESP также поддерживает свою собственную схему
аутентификации, подобную той, которая используется в AH, или может быть
использован в сочетании с АH.
В транспортном режиме IP-заголовки не подвергаются аутентификации и
шифрованию, а IP-даные подвергаются.
В туннельном режиме исходный пакет IP инкапсулируется в новый пакет IP,
обеспечивая шифрование 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 для обработки получаемого пакета.
161
grigoryev.victor@gmail.com http://vmg.pp.ua
* 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 будут использоваться для каждого приложения, или даже для
каждого TCP соединения.
Фазы IKE
Основное время служба IKE ничего не делает. Если имеется некий трафик,
соответствующий правилу политики, который нуждается в шифровании или
аутентификации, но политика не имеет никакого SA, то политика извещает об этом
службу IKE и она инициирует связь к удалённому хосту. IKE выполняет две фазы:
Фаза 1. Производится аутентификация сторон, и согласовываются их IPSecполитики. С помощью Алгоритм Диффи-Хеллмана рассчитываются общие ключи
для SA. Создаётся слабый туннель, позволяющий начать обмен IKE для фазы 2.
Есть два режима фазы 1 обычный и агрессивный (за три пакета).
Фаза 2. Производится согласование параметров SA
с целью создания
туннеля IPSec. Устанавливается однонаправленный SA для каждой комбинации
алгоритма и протокола. Создаётся сильный туннель.
Все SA, установленные службой IKE, будут иметь значение времени жизни.
Имеются два значения времени жизни - твёрдое и мягкое. Когда SA достигает
своего мягкого порога, служба IKE получает извещение и запускает ещё одну фазу
2 обмена для освежения SA . Если SA достигли твёрдого времени жизни, то они
отбрасываются.
162
grigoryev.victor@gmail.com http://vmg.pp.ua
Генерация ключей требует значительных вычислительных затрат. Это обычно
имеет место один раз в течение фазы 1.
Конфигурация IPsec в Mikrotik RouterOS
Конфигурация пиров осуществляется через подменю /ip ipsec peer
согласно табл.13.2. Конфигурации используются для установки соединения между
службами IKE (1-я фаза). Это соединение далее используется в процессе
согласования ключей и алгоритмов для SA.
Конфигурация пиров
Таблица 13.2
Свойство
Описание
Адресный префикс. Если адрес удалённого
address (IP[/Netmask]:port; Default:пира подпадает под этот префикс, то эта
0.0.0.0/32:500)
конфигурация
используется
в
аутентификации и установке фазы 1.
Метод аутентификации:
pre-shared-key - аутентификации по общей
auth-method (pre-shared-key | rsaдля пиров парольной строке
signature; Default: pre-shared-key)
rsa-signature – аутентификация с помощью
пары RSA -сертификатов
Имя локального сертификата. Он должен
certificate (string; Default: )
иметь закрытый ключ. Применимо при
аутентификации RSA-signature
dh-group (ec2n155 | ec2n185
Группа Diffie-Hellman (сила
| modp1024 | 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)
понимаете
Позволяет пиру установить SA для
несуществующей
политики.
Политика
generate-policy (yes | no; Default: no) создаётся динамически во время жизни SA.
Этот
способ
полезен,
когда
адрес
удалённого пира неизвестен
hash-algorithm (md5 | sha1; Default:Алгоритм хеширования. SHA сильнее, но
md5)
медленнее
lifebytes
(Integer:
0..4294967295;Время жизни первой фазы. Определяет
Default: 0)
сколько байт может быть передано до того
163
grigoryev.victor@gmail.com http://vmg.pp.ua
как SA будет отброшено. Если указан 0, то
SA не отбрасывается.
Время жизни фазы 1: определяет время
lifetime (time; Default: 1d)
действительности SA
Использование механизма Linux NATnat-traversal (yes | no; Default: no)
traversal для разрешения несовместимости
IPsec и NAT
Логика проверки времени жизни фазы 2:
claim – взять самое короткое из
предложенных времён жизни и известить
инициатора об этом
proposal-check (claim | exact | obey | exact – требовать, чтобы время жизни было
strict; Default: obey)
такое же
obey – принять всё, что пошлёт инициатор
strict – если предложенное время больше,
чем время по умолчанию, то отбросить.
Иначе принять предложенное
Имя сертификата для аутентификации
удалённой стороны. Закрытый ключ не
remote-certificate (string; Default: )
требуется. Применимо при аутентификации
RSA-signature
Парольная
строка.
Применимо
при
аутентификации pre-shared key. Если
secret (string; Default: "")
начинается с 0x, то рассматривается как 16-е
число
send-initial-contact (yes | no; Default:Определяет отсылать ли начальную IKEyes)
информацию или ждать удалённую сторону
При смене этой конфигурации на лету, информация о фазах IPSec
уничтожается, однако пакеты продолжают шифроваться и дешифроваться согласно
установленным SA.
Политика IPsec настраивается в подменю /ip ipsec policy
согласно табл.2. Таблица политик предназначена для определения того,
какие установки безопасности будут применены к пакету
Конфигурация политик
Таблица 13.3
Свойство
Описание
Определяет, что делать с пакетом, который
удовлетворяет политике.
action (discard | encrypt | none;none – пропустить пакет без изменения
Default: encrypt)
discard - отбросить пакет
encrypt
–
применить
преобразование,
определённое в этой политике и SA
dst-address (IP/Mask:Port; Default:
Адресный префикс и порт назначения.
0.0.0.0/32:any)
ipsec-protocols (ah|esp; Default: esp) Определяет какая комбинация протоколов AH
и ESP будет применена к трафику, который
164
grigoryev.victor@gmail.com http://vmg.pp.ua
удовлетворяет политике.
Определяет, что делать, если некоторые SA
для этой политике не могут быть найдены:
use – пропустить это преобразование, не
отбрасывать пакет и не получать SA от IKElevel (require | unique | use; Default:
службы
require)
require - отбросить пакет и получить SA
unique - отбросить пакет и получить
уникальный SA , который только и
используется для этой конкретной политики
Классификатор порядка политик (целое со
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 и srcaddress= sa-dst-address. Для шифрования трафика между сетями следует
использовать туннель. Пакет из сети src-address в сеть dst-address будет помещён в
новый пакет с адресом источника sa-src-address и адресом приёмника sa-dstaddress.
Установка предлагаемой информации производится в подменю /ip ipsec
proposal согласно Таблица 13.4. Предлагаемая информация отсылается
службой IKE для установки SA для политики. Имя предлагаемой информации
устанавливается в политике.
Установка предлагаемой информации
Таблица 13.4
Свойство
Описание
auth-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)
165
grigoryev.victor@gmail.com http://vmg.pp.ua
Подменю
/ip
ipsec
installed-sa
предоставляет
информацию об
установленных SA и их ключах. С помощью команды /ip ipsec installed-sa flush
можно вручную сбросить SA, которые некорректно установлены IKE. Подменю / ip
ipsec remote-peers содержим информацию только для чтения об активных
удалённых пирах.
Шифрация соединения точка-точка
Соберём топологию ipsec1, изображённую на Рис. 13.1, в которой роутеры
соединяются друг с другом через нашу модель Интернета. Вместо приведенных
адресов используйте адреса из своей tap-сети. Пропишите для этого в роутерах
соответствующие маршруты. Пусть первый пакет исходит от R1. В winbox для
настройки пиров R0 и R1 выбираем IP->IPsec->Peers->+. Вводим секретную фразу
и адрес противоположной стороны (рис. 13.2).
Рис. 13.1 Топология ipsec1
Рис. 13.2 Настройка пира R0
166
grigoryev.victor@gmail.com http://vmg.pp.ua
Настраиваем генерацию политики по запросу на шифрование от R1. В R1
настраиваем инициацию шифрования (Рис. 13. 3).
Для определения политики в R1 выбираем в winbox IP->IPsec->Policies->+ и
вводим адреса Src.Address: 10.0.1.1. Dst.Address: 10.0.1.1. SA Src.Address: 10.0.1.1.
SA Dst.Address: 10.0.1.1. (рис. 13.4). Не нажимая Apply, переходим к вкладке
Action и вводим те же адреса (Рис. 13. 5). Нажимаем Ok и инициируем
шифрование, запуская на R1 в сторону R0 пинги (Tools->Ping). Видим некоторую
задержку (рис. 13.6).
Проверяем. На R0 появилась политика (IP>IPsec->Policies). И R0 и R1
увидели удалённого собеседника (IP->IPsec->Remote Peers). И на R0 и на R1
инсталлировались SA (IP->IPsec->Installed SAs). Трафик шифруется.
Рис. 13.3 Настройка пира R1
167
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 13.4. Настройка политики в R1
Рис. 13.5. Дальнейшая настройка политики в R1
Рис. 13.6. Шифрация началась
Задание. В Windows протокол L2TP представлен не в чистом виде, а в
сочетании c IPsec. Сделайте копию IPsecL2TP последней топологии, организуйте
L2TP соединение от R1 к R0 и организуйте поверх него IPsec.
168
grigoryev.victor@gmail.com http://vmg.pp.ua
Организация VPN типа сайт-сайт с помощью IPsec
Соберём топологию ipsec2, изображённую на рис. 13.7. Внешние адреса
10.0.0.1 и 10.0.1.1 измените согласно своему номеру тап-сети. У кого номер тап
сети равен 1, измените внутренние адреса сетей 10.1.101.0/24 и 10.1.101.0/24.
Рис. 13.7. Топология ipsec2
Рис. 13.8. Настройка пира R0
169
grigoryev.victor@gmail.com http://vmg.pp.ua
Дайте сетевым устройствам имена внутри RouterOS. Превратите sw6 и sw7 в
свичи, поместив используемые Ethernet-интерфейсы в мост. Проверьте соседей.
Назначьте адреса согласно рисунку. На R2 и R3 пропишите маршрут по
умолчанию на 10.1.202.1. На R4 и R5 пропишете маршрут по умолчанию на
10.1.101.1
Рис. 13.9. Настройка пира R1
На R0 пропишем маршрут на R1 через модель Интернета
[admin@R0] > Route add dst=10.0. 1.0/24 gate=10.0.0.2
На R1 пропишем маршрут на R0 через модель Интернета
[admin@R1] > Route add dst=10.0. 0.0/24 gate=10.0.1.2
На R0 пропишем маршрут на сеть 10.1.101.0/24 через 10.0.0.2
[admin@R0] > Route add dst=10.1.101.0/24 gate=10.0.0.2
На R1 пропишем маршрут на сеть 10.1.202.0/24 через 10.0.1.2
[admin@R1] > Route add dst=10.1.202.0/24 gate=10.0.1.2
170
grigoryev.victor@gmail.com http://vmg.pp.ua
Компьютеры из сети 10.1.101.0/24 не увидят компьютеры из сети 10.1.202.0/24
и наоборот. Это естественно. Ubuntu не знает, что делать с пакетами из этих сетей.
Выполните в Ubuntu команду Netstat –r и вы не увидите маршрутов на эти сети.
Мы не знаем, кто инициирует шифрование. Поэтому произведём
симметричную конфигурацию пиров, указав адрес собеседника и секрет (Рис. 13. 8
и 9).
Определим на R0 политику, задающую шифрование от сети Src.Address:
10.1.202.0/24 к сети Dst.Address: 10.1.101.0/24 (Рис. 13.10). Для SA в качестве
адреса источника SA Src.Address возьмём внешний адрес 10.0.0.1 R0, а в качестве
адреса приёмника SA Dst.Address возьмём внешний адрес 10.0.1.1 R1. Обмен
осуществляется в туннельном режиме (Рис. 13.11).
Определим на R1 политику, задающую шифрование от сети Src.Address:
10.1.101.0/24 к сети Dst.Address 10.1.202.0/24 (Рис. 13.12). Для SA в качестве
адреса источника возьмём внешний адрес SA Src.Address 10.0.1.1 R1, а в качестве
адреса приёмника SA Dst.Address возьмём внешний адрес 10.0.0.1 R0. Обмен
осуществляется в туннельном режиме (Рис. 13.13).
Убедимся, что мы с помощью IPsec создали VPN типа сайт-сайт между сетями
10.1.101.0/24 и 10.1.101.0/24. Для этого протрассируем пакеты из сети 10.1.101.0/24
в сеть 10.1.101.0/24. Наберём в R4 команду
[admin@ R4] > tools tracert 10.1.202.2
где 10.1.202.2 – это адрес R2.
Пакеты протокола ICMP между сайтами пошли (Рис. 13.14). VPN создано.
Рис. 13.10. Политика на R0
171
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 13.11. Политика на R0. SA
Рис. 13.12. Политика на R1
172
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 13.13. Политика на R1. SA
На Рис. 13.14 видим отсутствие внешних адресов 10.0.0.1 и 10.0.0.1
маршрутизаторов R0 и R1, хотя трафик не может через них не проходить. Это
объясняется тем, что ICMP в R4 и R6 не может знать, что пакеты будут
зашифрованы и помещены в пакеты с адресами 10.0.0.1/24 и 10.0.1.1/24.
Компьютеры из сети 10.1.101.0/24 не видят компьютеры из сети 10.1.202.0/24
и наоборот. Это естественно. Так как Ubuntu не знает, что делать с пакетами из
сетей 10.1.101.0/24 и 10.1.202.0/24. Что случилось? Как образовалась VPN?
Просто теперь пакеты из этих сетей зашифрованы и посещены в пакеты с адресами
10.0.0.1/24 и 10.0.1.1/24, с которыми Ubuntu знает, что делать. Если вы обладаете
правами суперпользователя, то это можно увидеть с помощью программы
анализатора сетевых пакетов Wireshark (Рис. 13.15).
Рис. 13.14. Прохождение пакетов ICMP между сайтами в VPN
Рис. 13.15. Wireshark показывает шифрование пакетов
173
grigoryev.victor@gmail.com http://vmg.pp.ua
Проверяем. И R0 и R1 увидели удалённого собеседника (IP->IPsec->Remote
Peers). И на R0 и на R1 инсталлировались SA (IP->IPsec->Installed SAs).
Задание. Организуйте VPN типа сайт-сайт с помощью IPsec для топологии
ipsec3, представленной на Рис. 13.16. Внешние адреса R0, R1 и R10 измените
согласно своему номеру тап-сети. У кого номер 1 измените адреса сетей.
Рис. 13.16. Топология ipsec3
Требования для сдачи работы
Предъявить работающие топологии IPsecL2TP и ipsec3
174
grigoryev.victor@gmail.com http://vmg.pp.ua
14. MPLS в роутерах Mikrotik.
LDP
Фильтрация меток
RSVP TE
176
182
182
MPLS это многопротокольная коммутация по меткам (MultiProtocol Label
Switching). Она отчасти заменяет IP-маршрутизацию - решение о пересылке пакета
(исходящий интерфейс и следующий хоп маршрута) принимается не на основе
адреса назначения этого пакета и таблицы маршрутизации, а на основе метке,
которая прикреплена к пакету. Такой подход ускоряет процесс пересылки, потому
что поиск следующего хопа становится значительно проще по сравнению с
поиском самого длинного соответствующего префикса в таблице маршрутов.
Эффективность пересылки это не основное преимущество MPLS. MPLS
вносит в сетевые технологии качественно новые возможности, например
маршрутизация по адресу источника.
MPLS-метка IP-пакета является целым числом и располагается в резервном
поле его заголовка второго уровня (рис.14.1) Как правило, вторым уровнем для
локальных сетей является Ethernet.
Рис 14.1 IP-пакет в составе Ethernet-пакета, содержащего MPLS метку 18. Получено с
помощью анализатора пакетов Wireshark.
В простейшей форме MPLS можно рассматривать как улучшение
маршрутизации - помеченный пакет проходит тот же путь, который он бы прошёл,
если он не был бы маркирован. Этот путь коммутации по метке (LSP -label
switching path) обеспечивает передачу данных на выход облака MPLS.
Маршрутизатор внутри облака MPLS, осуществляющий коммутацию пакетов по
меткам, называют
LSR (label switch router). Когда LSR получает пакет, он
использует метку пакета для определения следующего хопа в LSP. При этом LSR
меняет у пакета метку перед его отправкой.
LSR-роутеры, связывающие MPLS-облако с внешним миром называют
граничными роутерами (см. рис. 14.2).
175
grigoryev.victor@gmail.com http://vmg.pp.ua
Метки внутри облака 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:
• Множеств пакетов с одинаковой сетью назначения.
• Множеств пакетов с одинаковой сетью назначения и одинаковой сетью
источником.
• Множество пакетов с одинаковыми портами назначения и т. д.
Для пакета при входе в MPLS-облако всегда определяется его класс FEC. В
MPLS-облаке для пакетов из каждого класса FEC с помощью протокола LDP
назначается своя система меток. Пакеты с метками из одного FEC обрабатываются
одинаковым образом. Где бы пакет не находился в MPLS-сети, метка определяет к
какому классу FEC пакет относится. То есть пакет помнит своё происхождение.
Именно этим свойством MPLS вносит принципиально новое качество в
современные сетевые технологии. Рассмотрим сеть на рис. 14.2.
Рис. 14.2. MPLS-сеть из 6-и LSR-роутеров с назначенными адресами на интерфейсы
петли c маской /32. Маски сетей между роутерами равны /24. Роутеры LSR1 и LSR6 —
граничные.
176
grigoryev.victor@gmail.com http://vmg.pp.ua
Хотя это и не строгое требование, желательно в LSR-маршрутизаторах,
назначать IP-адрес на интерфейс петли Loopback, и использовать этот адрес для
установки LDP-сессий. Так как может быть только одна LDP-сессия между двумя
маршрутизаторами вне зависимости от того, сколько линков соединяет их,
использование IP-адреса на интерфейс Loopback гарантирует, что работа LDP не
будет зависеть от смены состояния и адресов этих линков.
Интерфейс петля не связан с каким-то реальным устройством. В качестве
такого интерфейса в RouterOS может служить пустой мост. Создадим такие
интерфейсы и назначим на них адреса согласно рисунку. Например, для LSR1
[admin@LSR1]>interface bridge add name=loopback
[admin@R1]>ip address add address=9.9.9.1/32 interface=loopback
Адреса и маски можно брать произвольные. Маска /32 взята, чтобы
подчеркнуть изолированность интерфейса.
Так как LDP распределяет метки по активным маршрутам, важным
требованием является правильная настройка IP-маршрутизации. Используем
протокол маршрутизации OSPF, анонсируя на каждом LSR-маршрутизаторе все
присоединённые сети. Например, на LSR1 OSPF может быть настроен с помощью
следующих команд:
[admin@LSR1] > routing ospf network add area=backbone network=172.16.0.0/16
[admin@LSR1] > routing ospf network add area=backbone network=9.9.9.1/32
[admin@LSR1] > routing ospf network add area=backbone network=1.1.1.0/24
[admin@LSR1] > routing ospf network add area=backbone network=4.4.4.0/24
На остальных маршрутизаторах настройку OSPF осуществлена подобным
образом. На внешних по отношению к облаку MPLS маршрутизаторах назначим
маршрут по умолчанию. Например
[admin@L] > ip route add gateway=172.16.0.1
Проверим правильность настройки маршрутизации, направив ICMP-пакеты
от роутера L (172.16.0.2 ) к роутеру M
[admin@L] > ping 172.17.0.2
На каждом LSR-роутере посмотрим маршруты в сторону сети 172.17.0.0/16
маршрутизатора M.
[admin@LSR1] > ip route print detail where dst-address =172.17.0.0/16
ADo
dst-address=172.17.0.0/16 gateway=1.1.1.1,4.4.4.1 gateway-status=1.1.1.1
reachable via ether1,4.4.4.1 reachable via ether2
[admin@LSR2] > ip route print detail where dst-address =172.17.0.0/16
ADo dst-address=172.17.0.0/16 gateway=2.2.2.2 gateway-status=2.2.2.2 reachable via
ether2
[admin@LSR3] > ip route print detail where dst-address =172.17.0.0/16
ADo dst-address=172.17.0.0/16 gateway=3.3.3.2 gateway-status=3.3.3.2 reachable via
ether2
[admin@LSR4] > ip route print detail where dst-address =172.17.0.0/16
16 ADo dst-address=172.17.0.0/16 gateway=5.5.5.1 gateway-status=5.5.5.1 reachable
via ether2
[admin@LSR5] > ip route print detail where dst-address =172.17.0.0/16
ADo dst-address=172.17.0.0/16 gateway=6.6.6.2 gateway-status=6.6.6.2 reachable via
177
grigoryev.victor@gmail.com http://vmg.pp.ua
ether2
[admin@LSR6] > ip route print detail where dst-address =172.17.0.0/16
ADC
dst-address=172.17.0.0/16 pref-src=172.17.0.1 gateway=ether3 gatewaystatus=ether3 reachable via ether3
Флаги перед маршрутом означают: A-активный маршрут, D-динамически
создан системой, o-создан протоколом OSPF, С-непосредственно соединённая сеть.
В параметре gateway показаны все возможные адреса следующего перехода по
направлению к сети назначения. Параметр gateway-status указывает на активный
адрес следующего перехода по направлению к сети назначения. После фразы
«reachable via» можно увидеть через какой интерфейс достижима сеть назначения.
Результаты вывода команд сведём в таблицу 14.1
Маршруты на сеть 172.17.0.0/24
Хост
Таблица 14.1
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-address=9.9.9.1 lsr-id=9.9.9.1
[admin@LSR1]>mpls ldp interface add interface=ether1
[admin@LSR1]>mpls ldp interface add interface=ether2
Для LSR2 это делается командами
[admin@LSR2]>mpls ldp set enabled=yes transport-address=9.9.9.2 lsr-id=9.9.9.2
[admin@LSR2]>mpls ldp interface add interface=ether1
[admin@LSR2]>mpls ldp interface add interface=ether2
[admin@LSR2]>mpls ldp interface add interface=ether3
Остальные маршрутизаторы настраиваются подобным образом. LDP
активируется на интерфейсах, идущих в сторону MPLS-облака и не активируется
на интерфейсах, идущих в сторону маршрутизаторов L и M.
178
grigoryev.victor@gmail.com http://vmg.pp.ua
После установления 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
ADDRESSES
0 DO 9.9.9.2
9.9.9.1
9.9.9.2:0 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 4.4.4.1 5.5.5.2 7.7.7.2 9.9.9.4
Видим, что LSR1 имеет два соседа LSR2 (9.9.9.2) и LSR4(9.9.9.4). Видим
также все адреса этих соседей. LDP-соседи для всех LSR-маршрутизаторов
приведены в таблице 14.2.
LDP-соседи
LSR
Таблица 14.2
LDP-соседи
LSR1
LSR2 LSR4
LSR2
LSR1 LSR3 LSR4
LSR3
LSR2 LSR5 LSR6
LSR4
LSR1 LSR2 LSR5
LSR5
LSR3 LSR4 LSR6
LSR6
LSR3 LSR5
В качестве класса FEC возьмём пакеты, идущие в сеть 172.17.0.0./24. LDP на
каждом LSR назначит для этого класса входные метки, которые можно посмотреть
командой
mpls local-bindings print where dst-address =172.17.0.0/16
Результаты вывода этих команд сведём в таблицу 14.3
Входные метки пакетов, идущих в сеть 172.17.0.0./24
Таблица 14.3
Хост
Входные метки
Идентификаторы соседей,
которые получат эту метку
LSR1
18
9.9.9.2 9.9.9.4
LSR2
25
9.9.9.1 9.9.9.3
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
9.9.9.4
На 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
179
grigoryev.victor@gmail.com http://vmg.pp.ua
# 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 от LDPсоседа LSR4. Именно эти метки назначены на этих роутерах для нашего класса
FEC как входные (см. Табл. 14.3). Согласно Табл. 14.1 IP-адрессом следующего
перехода (NEXTHOP ) в сторону сети 172.17.0.0/16 будет адрес 1.1.1.1 роутера
LSR2. Поэтому метка 25 от хоста LSR2 объявляется активной (флаг A слева).
Для других LSR имеем
[admin@LSR2] > mpls remote-bindings print where dst-address =172.17.0.0/16
# DST-ADDRESS
NEXTHOP
LABEL
PEER
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
[admin@LSR3] > mpls remote-bindings print where dst-address =172.17.0.0/16
# DST-ADDRESS
NEXTHOP
LABEL
PEER
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
[admin@LSR4] > mpls remote-bindings print where dst-address =172.17.0.0/16
# DST-ADDRESS
NEXTHOP
LABEL
PEER
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
[admin@LSR5] > mpls remote-bindings print where dst-address =172.17.0.0/16
# DST-ADDRESS
NEXTHOP
LABEL
PEER
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
[admin@LSR6] > mpls remote-bindings print where dst-address =172.17.0.0/16
# DST-ADDRESS
NEXTHOP
LABEL
PEER
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
Сведём результат в таблицу 14.4. Метка выбирается активной (показана
жирной), если она пришла от NEXTHOP (показан в скобках).
Получаемые метки.
К Хосту
LSR1
LSR2
LSR3
LSR4
LSR5
LSR6
Таблица 14.4
От хоста
LSR1 LSR2
LSR3
25 (1.1.1.1)
18
35(2.2.2.2)
25
18
25
35
35
LSR4 LSR5
LSR6
21
21
29
impl-null(3.3.3.2)
29 (5.5.5.1)
21
impl-null(6.6.6.2)
29
180
grigoryev.victor@gmail.com http://vmg.pp.ua
Активная метка становится новой меткой пакета в сторону сети 172.17.0.0/16.
Адрес из которого пришла активная метка становится адресом перехода
(NEXTHOP).
Каждый 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
Результат вывода этих команд сведём в таблицу 14.5.
Таблица пересылки по меткам
Таблица 14.5.
Хост
INOUTINTERFAC NEXTHOP (Хост)
LABEL
LABELS
E
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 определяется в табл.14.3. Колонки OUT-LABEL и
NEXTHOP определяются по активным меткам, пришедшим от LDP-соседей
(табл.14.4). Колонка INTERFACE берётся из таблицы маршрутов Табл. 14.1.
Проверим смену меток, отправив ICMP-пакеты от адреса 172.16.0.2
(L) в сторону 172.17.0.2 (M)
[admin@L] > tool tracert 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 (табл. 14.3). В LSR1,
согласно табл. 14.5, он получит новую метку 25 и будет направлен на LSR2
(1.1.1.1). В LSR2, согласно табл. 14.5, он получит новую метку 35 и будет
направлен на LSR3 (2.2.2.2). В LSR3, согласно табл. 14.5, он будет направлен на
LSR6 (3.3.3.2). При этом ему не надо новой метки, так как сеть 172.17.0.0/16
присоединена к LSR6 непосредственно.
Физически IP-маршрутизация в Ethernet-сетях осуществляется путём
должной замены у IP-пакетов их Ethernet заголовков. Новые Ethernet заголовки
определяются с помощью протокола ARP. MPLS в этом процессе участия не
принимает.
Фильтрация меток
Не все привязки меток к IP-подсетям могут быть нам нужны. Для
выборочной привязки предусмотрена фильтрация меток, которые LSR-роутеры
могут выдавать или принимать.
Запретим обмениваться метками между роутерами LSR2 и LSR4 в сети на
рис. 14.2
181
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@LSR2]>mpls ldp advertise-filter add neighbor=9.9.9.4 advertise=no
[admin@LSR4]>mpls ldp advertise-filter add neighbor=9.9.9.2 advertise=no
и роутерами LSR3и LSR5
[admin@LSR3]>mpls ldp advertise-filter add neighbor=9.9.9.5 advertise=no
[admin@LSR5]>mpls ldp advertise-filter add neighbor=9.9.9.3 advertise=no
Пусть в сети на рис.14.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
#
DST-ADDRESS NEXTHOP
LABEL
PEER
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.
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 определяет роутеры, через которые будет устанавливаться путь
от входящего к исходящему роутеру туннеля. Этот путь может быть определён
несколькими способами.
182
grigoryev.victor@gmail.com http://vmg.pp.ua
1. В качестве пути берётся маршрут проложенный протоколами
маршрутизации, как от входящего роутера к исходящему так и обратно. Если
сетевые интерфейсы маршрутизаторов, через которые проходят маршруты не
имеют заданной полосы пропускания, то тоннель не может быть создан
2. Использование протокола CSPF (Constrained Shortest Path First —
ограниченный кратчайший путь в первую очередь). CSPF реализован в составе
протокола маршрутизации OSPF. OSPF для реализации CSPF распространяет по
сети информацию о пропускной способности интерфейсов. Далее OSPF строит
маршруты с учётом ограничений на полосу пропускания. Входящий роутер,
используя CSPF, вычисляет путь к исходящему роутеру с учётом ограничений на
полосу пропускания.
3. Явно указываются адреса интерфейсов роутеров, через которые будет
проходить тоннель. Адреса указываются в прямом и обратном направлении.
Указывается либо весь путь, либо только его часть. В последнем случае остальная
часть пути определяется протоколами маршрутизации или протоколом CSPF.
Тоннель не создаётся, если вдоль пути найдутся интерфейсы с недостаточной
пропускной способностью.
Создание туннеля инициируется входящим роутером. Он отсылает
исходящему роутеру сообщение Path, содержащее информацию о параметрах и
ограничениях на полосу пропускания устанавливаемого туннеля. Если роутер,
находящийся на пути прохождения сообщения Path, удовлетворяет ограничениям
на полосу пропускания, то он проталкивает сообщение Path следующему роутеру
по пути к исходящему роутеру. В итоге сообщение Path достигнет исходящего
роутера тоннеля. Исходящий роутер отсылает ответное сообщение Resv в
обратном направлении. Если роутер, находящийся на пути прохождения
сообщения Resv, удовлетворяет ограничениям на полосу пропускания, то он
проталкивает сообщение Resv следующему роутеру по пути к входящему роутеру.
В итоге сообщение Resv достигнет входящего роутера тоннеля. Туннель считается
установленным. В противном случае тоннель установится не может. Входящий и
исходящий роутеры туннеля периодически обмениваются сообщениями Path для
поддержания тоннеля в рабочем состоянии
Снова рассмотрим сеть на рис. 14.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 set mpls-te-area=backbone mpls-te-router-id=loopback
Для того, чтобы роутер мог участвовать в туннеле (либо как входящий, либо
как промежуточный, либо как исходящий) в нем надо настроить поддержку
протокола RSVP TE. Для этого надо указать, какие интерфейсы роутера будут
участвовоать в работе RSVP TE и их заявляемые пропускные способности
[admin@LSR1] > mpls traffic-eng interface add interface=ether1 bandwidth=100000
[admin@LSR1] > mpls traffic-eng interface add interface=ether2 bandwidth=100000
[admin@LSR2] > mpls traffic-eng interface add interface=ether1 bandwidth=100000
183
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@LSR2] > mpls traffic-eng interface add interface=ether2 bandwidth=100000
[admin@LSR2] > mpls traffic-eng interface add interface=ether3 bandwidth=100000
[admin@LSR3] > mpls traffic-eng interface add interface=ether1 bandwidth=100000
[admin@LSR3] > mpls traffic-eng interface add interface=ether2 bandwidth=100000
[admin@LSR3] > mpls traffic-eng interface add interface=ether3 bandwidth=100000
[admin@LSR4] > mpls traffic-eng interface add interface=ether1 bandwidth=100000
[admin@LSR4] > mpls traffic-eng interface add interface=ether2 bandwidth=100000
[admin@LSR4] > mpls traffic-eng interface add interface=ether3 bandwidth=100000
[admin@LSR5] > mpls traffic-eng interface add interface=ether1 bandwidth=100000
[admin@LSR5] > mpls traffic-eng interface add interface=ether2 bandwidth=100000
[admin@LSR5] > mpls traffic-eng interface add interface=ether3 bandwidth=100000
[admin@LSR6] > mpls traffic-eng interface add interface=ether1 bandwidth=100000
[admin@LSR6] > mpls traffic-eng interface add interface=ether2 bandwidth=100000
После этих настроек протокол OSPF роутеров станут распространять RSVPинформацию по сети
[admin@LSR1] > routing ospf lsa print
AREA
TYPE
ID
ORIGINATOR SEQUENCE-NU...
...
backbone
opaque-area 1.0.0.0
8.8.8.2
0x80000002
backbone
opaque-area 1.0.0.0
172.16.0.1
0x80000002
backbone
opaque-area 1.0.0.0
172.17.0.1
0x80000002
backbone
opaque-area 1.0.0.0
172.18.0.1
0x80000002
Начнём создавать туннель от 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: 2
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
184
grigoryev.victor@gmail.com http://vmg.pp.ua
reserved-bandwidth: 1000bps
Видим что путь туннеля прошел через роутеры 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 REMAININGBW
0 ether1
100kbps
1 100.0kbps
1 ether2
100kbps
1 99.0kbps
2 ether3
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@LSR1]>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 позволит роутеру LSR1 получать информацию о
том, через какие роутеры пройдёт путь туннеля.
Осуществим мониторинг состояния туннеля[admin@LSR6] > interface trafficeng monitor numbers=0
tunnel-id: 2
primary-path-state: established
primary-path: dyn
secondary-path-state: not-necessary
active-path: dyn
active-lspid: 1
active-label: 17
explicit-route: S:3.3.3.1/32,S:2.2.2.2/32,S:2.2.2.1/32,S:1.1.1.1/32,S:1.1.1.2/32
recorded-route: 2.2.2.2[19],1.1.1.1[19],1.1.1.2[0]
reserved-bandwidth:
1000bps
Видим что путь туннеля прошел через роутеры LSR3 (2.2.2.2) и LSR2
(1.1.1.1) и ему назначена метка 17.
Можно видеть, как резервируется часть полосы интерфейсов под тоннель,
например
[admin@LSR2] > mpls traffic-eng interface print
Flags: X - disabled, I - invalid
# INTERFACE
BANDWIDTH TE-METRIC REMAININGBW
0 ether1
100kbps
1 99.0kbps
1 ether2
100kbps
1 99.0kbps
2 ether3
100kbps
1 100.0kbps
185
grigoryev.victor@gmail.com http://vmg.pp.ua
Посмотрим 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
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS DESTINATION INTERFACE NEXTHOP
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-eng1
[admin@LSR6] > ip address add address=10.11.1.2/24 interface=traffic-eng
Проверим связь
[admin@LSR6] > ping 10.11.1.1
HOST
SIZE TTL TIME STATUS
10.1.1.1
56 62 1ms
Требования для сдачи работы
Предъявить работающую MPLS-сеть, изображённую на рис. 14.2.
Организовать распределение меток внутри облака MPLS с помощью протоколов
LDP и RSVP
186
grigoryev.victor@gmail.com http://vmg.pp.ua
15. MPLS VPN уровня 2 и 3
1. Организация MPLS VPN уровня 2 с помощью VPLS
1.1. Настройка LDP VPLS
1.1.1. LDP VPLS с организацией LSP с помощью LDP
1.1.2. LDP VPLS с организацией LSP с помощью RSVP
1.2. Настройка BGP VPLS
1.2.1. Конфигурирование сессий BGP. Отражатель маршрутов
1.2.2. BGP VPLS с организацией LSP с помощью RSVP
1.2.3. BGP VPLS с организацией LSP с помощью LDP
2. MPLS VPN 3-го уровня
2.1 MPLS VPN 3-го уровня c организацией LSP с помощью LDP
2.2 MPLS VPN 3-го уровня c организацией LSP с помощью RSVP
187
189
189
193
196
197
198
202
204
206
210
Протокол MPLS позволяет сетевому провайдеру оказывать своим заказчикам
услуги виртуальных частных сетей VPN. Рассмотрим (рис.15.1) провайдера
сетевых услуг, который соединяет 3 удалённых сайта А1, А2 и А3 заказчика А и 3
удалённых сайта В1, В2 и В3 заказчика В, используя свою сеть MPLS. Принято
выделять машрутизаторы провайдера, пограничные с сайтами заказчиков и
обозначать их с использованием символов PE — (provider edge -граница
провайдера). На рис.15.1 мы видим три граничных машрутизатора PE1, PE2 и
PE3.
Рис.15.1. Сеть провайдера сетевых услуг.
VPN организовываются на втором или третьем сетевом уровне. Рассмотрим
оргагнизации VPN уровня 2 и 3 с помощью протоколов VPLS и VRF,
соответственно.
1. Организация MPLS VPN уровня 2 с помощью VPLS
VPLS -это служба виртуальных частных локальных сетей (Virtual Private
LAN Service). Служит для обеспечения широковещательной функциональности
Ethernet-сетей поверх сетей
MPLS. Позволяет объединить территориально
187
grigoryev.victor@gmail.com http://vmg.pp.ua
удалённые локальные сети в один домен широковещания через виртуальные
псевдокабели Ethernet. Такое объединение может быть сделано и с помощью EoIPтуннелей, изученных в разделе 5. VPLS, в отличие от EoIP
• не требует инкапсуляции фреймов Ethernet в IP-пакеты и избегает
накладных расходов, связанных с обработкой IP –заголовков
• обладает большей гибкостью и функциональностью и поддерживается
большим числом производителей сетевого оборудования
• является более эффективным решением для создания VPN уровня 2.
В качестве виртуального псевдокабеля Ethernet выступает VPLS-туннель.
Для организации туннеля используются две метки: туннельная и транспортная.
Переговоры об организации VPLS-туннеля осуществляются либо с использованием
протокола LDP либо протокола BGP.
Рассмотрим настройку VPLS VPN на примере топологии на рис.15.1.
Заказчики A и B требуют прозрачное Ethernet-соединение между сайтами и хотят
сами назначать IP-адреса. Из рисунка рис.15.2 видим, что заказчики выбрали
одинаковые адреса 172.16.1.1 — 172.16.1.3 для своих сайтов А1, А2, А3 и В1, В2,
В3
.
Рис.15.2. MPLS VPLS VPN
Соберите топологию в GNS3. Назначьте адреса согласно рис.15.2. В каждом
маршрутизаторе провайдера создайте мост с именем lobridge и назначьте на него
188
grigoryev.victor@gmail.com http://vmg.pp.ua
адрес 9.9.9.*/32, согласно рис.15.2.
На граничных маршрутизаторах 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=ether4
Настроим IP-маршрутизацию. Используем протокол маршрутизации OSPF,
анонсируя на каждом маршрутизаторе провайдера все присоединённые сети.
Например, на PE1 OSPF может быть настроен с помощью следующих команд:
[admin@PE1] > routing ospf network add area=backbone network=9.9.9.1/32
[admin@PE1] > routing ospf network add area=backbone network=1.1.1.0/24
[admin@PE1] > routing ospf network add area=backbone network=4.4.4.0/24
Внутри облака MPLS пути коммутации пакетов по метке (LSP -label
switching path) организовываются либо с помощью протокола LDP либо с
помощью протокола RSVP. Имеем четыре способа организации VPLS VPN:
№ п/п
Организация VPLS-туннеля
Организация LSP
1
2
LDP
LDP
RSVP
3
4
LDP
BGP
RSVP
1.1. Настройка LDP VPLS
Рассмотрим организацию VPLS-туннеля с помощью протокола LDP. LSP
организовываются либо с помощью протокола LDP либо с помощью протокола
RSVP.
1.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
[admin@P4]>mpls ldp interface add interface=ether2
189
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@P4]>mpls ldp interface add interface=ether3
[admin@P4]>mpls ldp interface add interface=ether4
Остальные маршрутизаторы настраиваются подобным образом. LDP
активируется на интерфейсах идущих в сторону MPLS-облака и не активируется на
интерфейсах идущих в сторону маршрутизаторов заказчиков.
Для достижения прозрачного Ethernet-соединения между сайтами заказчика
следует организовать следующие VPLS-туннели, образующие полносвязную
топологию каждого с каждым: PE1 – PE2, PE1 – PE3 и PE2 – PE3.
Каждый туннель требует создания VPLS-интерфейсов на обоих своих концах.
VPLS-туннели настраиваются в меню /interface vpls.
Параметр vpls-id
идентифицирует туннель и должен быть уникальным для каждого туннеля между
двумя пирами. Рекомендуется назначить MAC-адрес. Необходимые настройки для
заказчика A (vpls-id=0:10) .
[admin@PE1]>interface vpls add name=A1toA2 remote-peer=9.9.9.6 macaddress=00:00:00:00:а1:a2 vpls-id=0:10 disabled=no
[admin@PE1]>interface vpls add name=A1toA3 remote-peer=9.9.9.7 macaddress=00:00:00:00:а1:a3 vpls-id=0:10 disabled=no
[admin@PE2]>interface vpls add name=A2toA1 remote-peer=9.9.9.1 macaddress=00:00:00:00:а2:a1 vpls-id=0:10 disabled=no
[admin@PE2]>interface vpls add name=A2toA3 remote-peer=9.9.9.7 macaddress=00:00:00:00:а2:a3 vpls-id=0:10 disabled=no
[admin@PE3]>interface vpls add name=A3toA1 remote-peer=9.9.9.1 macaddress=00:00:00:00:а3:a1 vpls-id=0:10 disabled=no
[admin@PE3]>interface vpls add name=A3toA2 remote-peer=9.9.9.6 macaddress=00:00:00:00:а3: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 macaddress=00:00:00:00:b1:b2 vpls-id=0:10 disabled=no
[admin@PE1]>interface vpls add name=B1toB3 remote-peer=9.9.9.7 macaddress=00:00:00:00:b1:b3 vpls-id=0:10 disabled=no
[admin@PE2]>interface vpls add name=B2toB1 remote-peer=9.9.9.1 macaddress=00:00:00:00:а2:B1 vpls-id=0:10 disabled=no
[admin@PE2]>interface vpls add name=B2toB3 remote-peer=9.9.9.7 macaddress=00:00:00:00:а2:B3 vpls-id=0:10 disabled=no
[admin@PE3]>interface vpls add name=B3toB1 remote-peer=9.9.9.1 macaddress=00:00:00:00:b3:b1 vpls-id=0:10 disabled=no
[admin@PE3]>interface vpls add name=B3toB2 remote-peer=9.9.9.6 macaddress=00:00:00:00:b3:b2 vpls-id=0:10 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 DOTV 9.9.9.6
9.9.9.1
9.9.9.6:0
yes
3.3.3.2
190
grigoryev.victor@gmail.com http://vmg.pp.ua
6.6.6.2
9.9.9.6
10.0.6.1
1 DOTV 9.9.9.7
9.9.9.1
9.9.9.7:0
9.9.9.7
10.0.7.1
10.10.10.2
VPLS-туннель
предоставляет
виртуальную
Ethernet-связь
между
маршрутизаторами. Для прозрачного соединения физических Ethernet-сегментов
они должны быть объединены в мост с VPLS-туннелем.
В нашем примере Ethernet-сегменты имеют полносвязную топологию. Если
использовать мосты без протокола (R)STP, то могут возникнуть петли трафика.
Например, если от PE1 исходит широковещательный пакет, то он достигнет через
VPLS-туннели и PE2 и PE3. PE3, получив такой пакет, отошлёт его PE2. PE2
получит две копии одного пакета. Петля. Избежать петель можно так: разрешить
(R)STP , использовать фаервол, использовать свойство horizon. Последнее решение
самое простое и эффективное.
Базовая идея расщепленного горизонта (split horizon) – не пересылать трафик,
возникающий на порту, на некоторое множество портов. Для VPLS это значит не
пересылать пакеты, появившиеся на одном туннеле в другой туннель, так как для
этого есть прямая связь.
Пакет, принятый на порту со значением horizon=X не пробрасывается на
порты с тем же значением horizon=X. Так в случае полносвязной топологии VPLSтуннелей, каждый маршрутизатор должен иметь одинаковое значение свойства
horizon для VPLS-туннелей, помещённых в один мост. Свойство horizon не
конфигурируется на физическом Ethernet-интерфейсе. Свойство horizon имеет
локальное значение и не передаётся по сети. Поэтому везде можно установить для
него одинаковые значения.
Для организации виртуальной сети заказчика А мосты на 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
Для организации виртуальной сети заказчика B мосты на 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:00:00:00:A1:A3
PE1
5.18
x86
1 ether1
00:AA:00:7C:68:02
PE2
5.18
x86
2 ether1
00:AA:00:D5:EC:02
PE3
5.18
x86
3 ether1 172.16.1.3 00:AA:00:C4:D5:00
A3
5.18
x86
4 ether1 172.16.1.2 00:AA:00:2B:9C:00
A2
5.18
x86
191
yes
grigoryev.victor@gmail.com http://vmg.pp.ua
A1 увидел A2 и A3 на втором уровне. В этом можно убедиться, используя
утилиту ping на втором уровне.
[admin@A1] >ping 00:AA:00:2B:9C:00
[admin@A1] >ping 00:AA:00:C4:D5:00
Здесь используются MAC-адреса интерфейса ether1 компьютеров A2 и A3.
[admin@A2] > ip neighbor pr
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1
00:AA:00:7C:68:02
PE2
5.18
x86
1 ether1
00:AA:00:D5:EC:02
PE3
5.18
x86
2 ether1 172.16.1.1 00:AA:00:F5:7F:00
A1
5.18
x86
3 ether1 172.16.1.3 00:AA:00:C4:D5:00
A3
5.18
x86
4 ether1
00:00:00:00:A1:A3
PE1
5.18
x86
A2 увидел A1 и A3 на втором уровне. В этом можно убедиться, используя
утилиту ping на втором уровне.
[admin@A3] > ip neighbor print
# INTERFACE ADDRESS MAC-ADDRESS IDENTITY VERSION BOARD
0 ether1 172.16.1.1
00:AA:00:F5:7F:00
A1
5.18
x86
1 ether1
00:00:00:00:A1:A3
PE1
5.18
x86
2 ether1
00:AA:00:7C:68:02
PE2
5.18
x86
3 ether1 172.16.1.2 00:AA:00:2B:9C:00
A2
5.18
x86
4 ether1
00:AA:00:D5:EC:02
PE3
5.18
x86
A3 увидел A1 и A2 на втором уровне.
Аналогичные результаты мы получим и для сайтов заказчика B.
Изучим, как MPLS-метки помогают организовать VPN. Пустим обычные
пинги c сайта A1 в сторону сайта A2
[admin@ A1]> ping 172.16.1.2
С помощью анализатора пакетов Wireshark изучим структуру ICMP-пакетов
на интерфейсах e0 маршрутизатора PE1, e1 маршрутизатора P1 и e1
маршрутизатора P2 . (Рис. 15.3, 15. 4 и 15.5).
Объясним полученное. На всех 3-х рисунках в части Ethernet II, видим
инкапсулированный Ethernet-пакет от MAC-адреса 00:AA:00:F5:7F:00 интерфейса
ether1 сайта A1 до MAC-адреса 00:AA:00:2B:9C:00 интерфейса ether1 сайта A2.
Можно увидеть информацию о состоянии VPLS-интерфейсов
[admin@PE1] > interface vpls monitor numbers=A1toA2
remote-label: 26
local-label: 36
remote-status:
transport: 9.9.9.6/32
transport-nexthop: 1.1.1.1
imposed-labels: 18,26
[admin@PE2] > interface vpls monitor numbers=A2toA1
remote-label: 36
local-label: 26
remote-status:
transport-nexthop: 3.3.3.1
192
grigoryev.victor@gmail.com http://vmg.pp.ua
imposed-labels: 19,36
Рис.15.3. Структура ICMP-пакета на интерфейсе e0 маршрутизатора PE1.
Рис.15.4. Структура ICMP-пакета на интерфесе e1 маршрутизатора P1
Рис.15.5. Структура ICMP-пакета на интерфесе e1 маршрутизатора P2
Видим, что VPLS на PE1 назначил метку 36 для туннеля между A1 и A2.
Удалённой стороне назначена метка 26. Эту метку можно увидеть на всех 3-х
рисунках. Для транспорта Ehernet-пакетов от A1 к A2 используется метка 18. Эту
метку можно увидеть на рис.15.3 и 15.4. Таблица пробросов MPLS на PE1
показывает, что пакеты с меткой 18 будут направлены на адрес 1.1.1.1
маршрутизатора P1.
[admin@PE1] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL
OUT-LABELS DESTINATION
INTERFACE NEXTHOP
1 L 30
18
9.9.9.6/32
ether1
1.1.1.1
Таблица пробросов MPLS на P1 показывает, что пакеты с входящей меткой 18
получат такую же выходящую метку и будут направлены на адрес 2.2.2.2
маршрутизатора P2. Эту метку можно увидеть на рис.15.4.
[admin@P1] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL
OUT-LABELS DESTINATION
INTERFACE NEXTHOP
3 L 18
18
9.9.9.6/32
ether2
2.2.2.2
1.1.2. LDP VPLS с организацией LSP с помощью RSVP
Рассмотрим сеть на рис.15.2. Уберём в ней поддержку протокола LDP для
маршрутизаторах P1, P2, P3 и P4 не являющихся граничными. Для этого на этих
маршрутизаторах выполним команды.
mpls ldp set enabled=no transport-address=0.0.0.0 lsr-id=0.0.0.0
193
grigoryev.victor@gmail.com http://vmg.pp.ua
mpls ldp interface remove [find]
Видим, что 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
На граничных маршрутизаторах для будущих RSVP TE - туннелей
определим динамически путь dyn с помощью протокола CSPF
mpls traffic-eng tunnel-path add use-cspf=yes name=dyn
Создадим RSVP TE-туннели, образуя полносвязную топологию для
граничных маршрутизаторов
[admin@PE1]>interface
traffic-eng
add
from-address=9.9.9.1
toaddress=9.9.9.6 bandwidth=100000 primary-path=dyn disabled=no recordroute=yes name = 1to2
[admin@PE1]>interface
traffic-eng
add
from-address=9.9.9.1
toaddress=9.9.9.7 bandwidth=100000 primary-path=dyn disabled=no recordroute=yes name = 1to3
[admin@PE2]>interface
traffic-eng
add
from-address=9.9.9.6
toaddress=9.9.9.1 bandwidth=100000 primary-path=dyn disabled=no recordroute=yes name = 2to1
[admin@PE2]>interface
traffic-eng
add
from-address=9.9.9.6
toaddress=9.9.9.7 bandwidth=100000 primary-path=dyn disabled=no recordroute=yes name = 2to3
[admin@PE3]>interface
traffic-eng
add
from-address=9.9.9.7
toaddress=9.9.9.1 bandwidth=100000 primary-path=dyn disabled=no recordroute=yes name = 3to1
[admin@PE3]>interface
traffic-eng
add
from-address=9.9.9.7
toaddress=9.9.9.6 bandwidth=100000 primary-path=dyn disabled=no recordroute=yes name = 3to2
Ждём, пока поднимутся RSVP TE-интерфейсы. Видим, что VPLSинтерфейсы также перешли в рабочее состояние. Убеждаемся, как и ранее, что
наша VPN уровня 2 по прежнему функционирует.
Изучим, как MPLS-метки помогают организовать VPN. Пустим обычные
пинги c сайта A1 в сторону сайта A2
[admin@ A1]> ping 172.16.1.2
С помощью анализатора пакетов Wireshark изучим структуру ICMP-пакетов
на интерфейсах e0 маршрутизатора PE1, e1 маршрутизатора P1 и e1
194
grigoryev.victor@gmail.com http://vmg.pp.ua
маршрутизатора P2 . (Рис 15.6, 15.7 и 15.8)
Объясним полученное. На всех 3-х рисунках в части Ethernet II, видим
инкапсулированный Ethernet-пакет от MAC-адреса 00:AA:00:4E:8E:00 интерфейса
ether1 сайта A1 до MAC-адреса 00:AA:00:7B:D2:00 интерфейса ether1 сайта A2.
MAC-адреса отличаются от предыдущего случая потому, что GNS3 их назначает
динамически при каждом запуске топологии.
Рис.15.6. Структура ICMP-пакета на интерфейсе e0 маршрутизатора PE1.
Рис.15.7. Структура ICMP-пакета на интерфейсе e1 маршрутизатора P1
Рис.15.8. Структура ICMP-пакета на интерфейсе e1 маршрутизатора P2
Можно увидеть информацию о состоянии VPLS-интерфейса
[admin@PE1] > interface vpls monitor numbers=A1toA2
remote-label: 43
local-label: 43
remote-status:
transport: 1to2
transport-nexthop: 1.1.1.1
imposed-labels: 16,43
Видим, что VPLS на PE1 назначил метку 43 для тунеля между A1 и A2.
Удалённой стороне назначена метка 43. Эту метку можно увидеть на всех 3-х
рисунках. Для транспорта Ethernet-пакетов от A1 к A2 используется RSVP TEинтерфейс 1to2 и метка 16. Эту метку можно увидеть на рис.15.6.
Можно увидеть информацию о состоянии RSVP TE-интерфейса
195
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@PE1] > interface traffic-eng monitor numbers=1to2
tunnel-id: 1
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[16],3.3.3.1[16],3.3.3.2[0]
reserved-bandwidth: 10.0kbps
Таблица пробросов MPLS на P1 показывает, что пакеты с входящей меткой 16
получат такую же выходящую метку и будут направлены на адрес 2.2.2.2
маршрутизатора P2. Эту метку можно увидеть на рис.15.7.
[admin@P1] > 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:2
ether1
1.1.1.2
1.2. Настройка BGP VPLS
Рассмотрим организацию
VPLS-туннеля с помощью протокола BGP.
Благодаря своей статической природе, VPLS-туннели, основанные на LDP имеют
проблемы масштабируемости, которые возрастают при увеличении числа сайтов,
подключённых по VPLS. Одной из проблем является требование сохранения
полносвязной топологии LDP-туннелей между сайтами, формирующими VPLS. В
случае если число узлов в VPLS высока, добавление нового сайта к существующей
VPLS-сети может стать обременительным для администратора сети. Добавление
нового сайта потребует создания необходимого количества VPLS-туннелей на
маршрутизаторе, к которому присоединён новый сайт, что потребует настройки
маршрутизаторов на других концах туннелей.
В общем,VPLS, основанные на BGP, служат двум целям:
• автоматического обнаружения: нет необходимости настраивать VPLS-связь
каждого нового граничного маршрутизатора со всеми удаленных конечными
точками туннелей VPLS;
• сигнализации: метки, используемые для туннелей VPLS на удаленных
конечных точках, распространяются в одном и том же обновлении BGP.
Это значит, что нет необходимости для целевых сессий LDP между
конечными точками туннеля, как в случае VPLS на основе LDP.
Правильная настройка VPLS, основанных на BGP, позволяет избежать
конфигурации маршрутизаторов, которые не подключены к новому сайту.
Для организации VPLS BGP маршрутизаторы обмениваются сообщениями
NLRI (Network Layer Reachability Information), содержащими некую информацию о
196
grigoryev.victor@gmail.com http://vmg.pp.ua
VPLS.
BGP VPLS это лишь метод обмена метками для туннелей VPLS, а не метод
обмена трафиком между конечными точками туннелей VPLS. Поэтому следует
обеспечить распространение фреймов MPLS между конечными точками туннелей
VPLS. Фреймы MPLS распространяются по путям LSP. LSP организовываются
либо с помощью протокола LDP либо с помощью протокола RSVP.
1.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-соединений типа все со всеми. Для того чтобы маршрутизатор был
отражателем маршрутов для прохождения сообщений VPLS NLRI он не обязан
участвовать в VPLS и даже может не поддерживать MPLS.
Есть несколько замечаний о конфигурации пиров BGP:
6. Для обмена сообщениями VPLS NLRI нет нужды распространять IP или
Ipv6 маршруты, достаточно определить address-families=l2vpn ;
7. Для адресации пиров используются адреса мостов, то есть интерфейса
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 routereflect=yes address-families=l2vpn update-source=lobridge
[admin@P1]>routing bgp peer add remote-address=9.9.9.6 remote-as=65530 route197
grigoryev.victor@gmail.com http://vmg.pp.ua
reflect=yes
address-families=l2vpn update-source=lobridge
[admin@P1]>routing bgp peer add remote-address=9.9.9.7 remote-as=65530 routereflect=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
addressfamilies=l2vpn update-source=lobridge
Должно установиться три BGP-соединения. Об этом можно убедиться,
просматривая время uptime существования соединения в выводе команды /routing
bgp peer print status.
Если надо добавить новый сайт в VPLS-сеть, присоединяя его к
маршрутизатору P2, необходимо лишь настроить BGP-пир на отражателе P1 в
сторону P2 и BGP пир на P2 в сторону отражателя P1. Причем на P1 с установкой
route-reflect=yes.
1.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 routedistinguisher=9.9.9.1:1
site-id=1
export-route-targets=1:1
import-routetargets=6:1,7:1
[admin@PE1]>interface vpls bgp-vpls add bridge=B bridge-horizon=1 routedistinguisher=9.9.9.1:2
site-id=1
export-route-targets=1:2
import-routetargets=6:2,7:2
[admin@PE2]>interface vpls bgp-vpls add bridge=A bridge-horizon=1 routedistinguisher=9.9.9.6:1
site-id=6
export-route-targets=6:1
import-routetargets=1:1,7:1
[admin@PE2]>interface vpls bgp-vpls add bridge=B bridge-horizon=1 routedistinguisher=9.9.9.6:2
site-id=6
export-route-targets=6:2
import-route198
grigoryev.victor@gmail.com http://vmg.pp.ua
targets=1:2,7:2
[admin@PE3]>interface vpls bgp-vpls add bridge=A bridge-horizon=1 routedistinguisher=9.9.9.7:1
site-id=7
export-route-targets=7:1
import-routetargets=1:1,6:1
[admin@PE3]>interface vpls bgp-vpls add bridge=B bridge-horizon=1 routedistinguisher=9.9.9.7:2
site-id=7
export-route-targets=7:2
import-routetargets=1:2,6:2
Здесь
site-id – должно быть уникально для каждого роутера в пределах конкретной
VPLS. Для повышения эффективности следует брать эти значения из узкого
диапазона целых чисел.
Bridge – определяет мост, к которому добавятся динамически создаваемые
VPLS-туннели.
Bridge-horizon – служит для предотвращения петлей (см. выше).
route-distinguisher определяет значение, прикрепляемое к VPLS NLRI;
получающие маршрутизаторы используют это значение для образования туннеля.
Чтобы принимающие роутеры различали информацию от различных VPLS, это
значение должно быть различно для разных VPLS на одном устройстве. Routedistinguisher не используется получающим маршрутизатором для определения
принадлежности передающего роутера конкретной VPLS. Для этого используется
route-targets.
export-route-targets – это своего рода метка (синоним) для routedistinguisher.
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-пакетами (рис.15.9).
В итоге создадутся динамические VPLS-интерфейсы на PE1, PE2 и PE3.
Например, на PE1
[admin@PE1] > interface vpls print
Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
0 RDB name="vpls1" mtu=1500 l2mtu=1500 mac-address=02:6E:3C:4F:4A:E0
arp=enabled disable-running-check=no remote-peer=9.9.9.6 cisco-style=no ciscostyle-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes
vpls=bgp-vpls1
1 RDB name="vpls2" mtu=1500 l2mtu=1500 mac-address=02:EE:3A:22:7B:CD
arp=enabled disable-running-check=no remote-peer=9.9.9.7 cisco-style=no ciscostyle-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes
vpls=bgp-vpls2
2 RDB name="vpls3" mtu=1500 l2mtu=1500 mac-address=02:3A:0B:F0:4A:C0
199
grigoryev.victor@gmail.com http://vmg.pp.ua
arp=enabled disable-running-check=no remote-peer=9.9.9.7 cisco-style=no ciscostyle-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes
vpls=bgp-vpls1
3 RDB name="vpls4" mtu=1500 l2mtu=1500 mac-address=02:CC:69:B3:28:85
arp=enabled disable-running-check=no remote-peer=9.9.9.6 cisco-style=no ciscostyle-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes
vpls=bgp-vpls2
Рис.15.9. BGP-cообщение Update от PE2 к PE1. Видим в разделе 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
0x
10
none
1
ether4
B
0x
10
none
2 D vpls1
A
0x
50
1
3 D vpls2
B
0x
50
1
4 D vpls3
A
0x
50
1
5 D vpls4
B
0x
50
1
200
grigoryev.victor@gmail.com http://vmg.pp.ua
Здесь мы также получили подтверждение, что работает отражение маршрута
на P1, так как нет BGP-пиров между PE1 и PE2, PE1 и PE3, PE2 и PE3.
Установлена полносвязная топология VPLS-туннелей. Посмотрите соседей на
сайтах заказчика А и B. Убеждаемся, как и ранее, что наша VPN уровня 2 по
прежнему функционирует.
Изучим, как MPLS-метки помогают организовать VPN. Пустим обычные
пинги c сайта A1 в сторону сайта A2
[admin@A1]> ping 172.16.1.2
С помощью анализатора пакетов Wireshark изучим структуру ICMP-пакетов
на интерфесах e0 маршрутизатора PE1, e1 маршрутизатора P1 и e1 маршрутизатора
P2 . (Рис 10, 11, 12)
Рис.15.10. Структура ICMP-пакета на интерфесе e0 маршрутизатора PE1.
Рис.15.11. Структура ICMP-пакета на интерфесе e1 маршрутизатора P1
Рис.15.12. Структура ICMP-пакета на интерфесе e1 маршрутизатора P2
Объясним полученное. На всех 3-х рисунках в части Ethernet II, видим
инкапсулированный Ethernet-пакет от интерфейса ether1 сайта A1 до интерфейса
ether1 сайта A2. MAC-адреса отличаются от предыдущего случая потому, что GNS3
их назначает динамически при каждом запуске топологии.
Можно увидеть информацию о состоянии VPLS-интерфейса
[admin@PE1] > interface vpls monitor numbers=0
remote-label: 17
local-label: 22
remote-status:
transport: 1to2
201
grigoryev.victor@gmail.com http://vmg.pp.ua
transport-nexthop: 1.1.1.1
imposed-labels: 16,17
Видим, что VPLS на PE1 назначил метку 22 для туннеля между A1 и A2.
Удалённой стороне назначена метка 17. Эту метку можно увидеть на всех 3-х
рисунках. Для транспорта Ehernet-пакетов от A1 к A2 используется RSVP TE
-интерфейс 1to2 и метка 16. Эту метку можно увидеть на рис.15.10.
Можно увидеть информацию о состоянии RSVP TE-интерфейса
[admin@PE1] > interface traffic-eng monitor numbers=1to2
tunnel-id: 1
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[16],3.3.3.1[16],3.3.3.2[0]
reserved-bandwidth: 10.0kbps
Таблица пробросов MPLS на P1 показывает, что пакеты с входящей меткой 16
получат такую же выходящую метку и будут направлены на адрес 2.2.2.2
маршрутизатора P2. Эту метку можно увидеть на рис.15.11.
[admin@P1] > 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 18
expl-null
9.9.9.6:1->9.9.9.1:2
ether1
1.1.1.2
1.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=
Удалим интерфейсы mpls traffic-eng в маршрутизаторах PE1, PE2 и PE3,
участвующих в работе RSVP TE
[admin@] > mpls traffic-eng interface rem [find]
Для организации путей LSP коммутации пакетов по метке активируем на
каждом LSR-маршрутизаторе протокол LDP согласно разделу 1.1.1.. Транспортный
адрес установим как адрес интерфейса Loopback с именем lobridge. Объявим
202
grigoryev.victor@gmail.com http://vmg.pp.ua
интерфейсы, смотрящие внутрь MPLS–сети, как интерфейсы, участвующие в
обмене меток.
Автоматически создадуться динамические VPLS-интерфейсы на PE1, PE2 и
PE3. Например, на PE1
[admin@PE1] > interface vpls print
Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
0 RDB name="vpls1" mtu=1500 l2mtu=1500 mac-address=02:ED:FD:BE:BF:19
arp=enabled disable-running-check=no remote-peer=9.9.9.6 cisco-style=no cisco-styleid=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=bgpvpls1
1 RDB name="vpls2" mtu=1500 l2mtu=1500 mac-address=02:F5:00:C9:2C:9E
arp=enabled disable-running-check=no remote-peer=9.9.9.7 cisco-style=no cisco-styleid=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=bgpvpls1
2 RDB name="vpls3" mtu=1500 l2mtu=1500 mac-address=02:0B:CA:F1:7D:66
arp=enabled disable-running-check=no remote-peer=9.9.9.6 cisco-style=no cisco-styleid=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=bgpvpls2
3 RDB name="vpls4" mtu=1500 l2mtu=1500 mac-address=02:19:F7:A7:04:35
arp=enabled disable-running-check=no remote-peer=9.9.9.7 cisco-style=no cisco-styleid=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes vpls=bgpvpls2
Динамические 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
ether4
B
0x80
10
none
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 по
прежнему функционирует.
Изучим, как MPLS-метки помогают организовать VPN. Пустим обычные
пинги c сайта A1 в сторону сайта A2
[admin@A1]> ping 172.16.1.2
С помощью анализатора пакетов Wireshark получим структуру ICMP-пакетов
на интерфесах e0 маршрутизатора PE1, e1 маршрутизатора P1 и e1 маршрутизатора
P2, которая полностью аналогична структуре для случая п. 1.1.1 (рис.15.3, 15.4 и
203
grigoryev.victor@gmail.com http://vmg.pp.ua
15.5)
Можно увидеть информацию о состоянии VPLS-интерфейсов
[admin@PE1] > interface vpls monitor numbers=0
remote-label: 17
local-label: 22
remote-status:
transport: 9.9.9.6/32
transport-nexthop: 4.4.4.1
imposed-labels: 25,17
Видим, что VPLS на PE1 назначил метку 22 для тунеля между A1 и A2.
Удалённой стороне назначена метка 17. Для транспорта Ehernet-пакетов от A1 к A2
используется метка 25. Таблица пробросов MPLS на PE1 показывает, что пакеты с
меткой 25 будут напрвлены на адрес 4.4.4.4 маршрутизатора P3.
[admin@PE1] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL
OUT-LABELS DESTINATION
INTERFACE
NEXTHOP
1 L 48
25
9.9.9.6/32
ether2
4.4.4.1
6V
22
vpls1
Таблица пробросов MPLS на P3 показывает, что пакеты с входящей меткой 25
получат выходящую метку 16
и будут направлены на адрес
5.5.5.1
маршрутизатора P4.
[admin@P1] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL
OUT-LABELS DESTINATION
INTERFACE NEXTHOP
10 L 25
16
9.9.9.6/32
ether2
5.5.5.1
2. MPLS VPN 3-го уровня
Этот тип 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. Обычно используют соотношение один-к-одному между route
distinguisher и отдельной таблицей маршрутизации VRF, но это не обязательно.
204
grigoryev.victor@gmail.com http://vmg.pp.ua
Вы можете теперь добавлять маршрут в таблицу маршрутизации VRF, определяя
атрибут routing-mark.
Для распространения между маршрутизаторами маршрутов из таблицы
маршрутов VRF используется многопротокольный BGP с адресным семейством
VPNv4. Для каждого экземпляра BGP, участвующего в VRF-маршрутизации
следует задать список VRF. VRF определяется атрибутом
routing-mark.
Помещение маршрута в таблицу VRF управляется атрибутами BGP. Как только
VRF для BGP настроены, создаются активные маршруты семейства адресов
VPNv4. Эти маршруты устанавливаются в отдельные таблицу маршрутов и видны
из меню /routing bgp vpnv4-route. Через BGP вы можете распространять
одинаковые префиксы Ipv4 для разных сетей. Как правило, маршруты VPNv4 с
одинаковыми префиксами будут распространятся только после должной настройки
MPLS.
Рис.15.13. Топология для MPLS VPN 3-го уровня
VRF-маршрутизация использует, так называемые VPNv4-маршруты, которая
работает с префиксами, состоящими из route-distinguisher и префикса IPv4. Тем
самым на одном маршрутизаторе можно по-разному маршрутизировать пакеты с
одинаковыми префиксами Ipv4, приходящими от различных источников. Как
правило VRF-маршрутизация функционирует только после должной настройки
MPLS
Рассмотрим настройку MPLS VPN 3-го уровня на примере топологии на
рис.15.13, которая является копией топологии на рис.15.12 и отличается от неё
205
grigoryev.victor@gmail.com http://vmg.pp.ua
лишь настройками адресов устройств A1, A2, A3, B1, B2, B3 заказчиков.
Заказчики A и B требуют связать в единое адресное пространство свои три сети IPсети. Причём эти сети у них оказались одинаковыми: 172.16.1.0/24, 172.16.2.0/24,
172.16.3.0/24.
Внутри облака MPLS
пути коммутации пакетов по метке LSP
организовываются либо с помощью протокола LDP либо с помощью протокола
RSVP. На текущий момент топология использует LDP.
2.1 MPLS VPN 3-го уровня c организацией LSP с помощью LDP
Уберём из топологии существующую там поддержку BGP VPLS и других
настроек, касающихся VPN уровня 2.
На всех граничных маршрутизаторах провайдера уберём поддержку BGP
VPLS
interface vpls bgp-vpls remove [find]
Уберём интерфейсы из мостов
interface bridge port remove [find]
Удалим мосты A и B
interface bridge port remove A,B
Назначьте, согласно рис. 15.13, адреса для сетей 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
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 routedistinguisher=9.9.9.1:1
export-route-targets=1:1 import-route-targets=6:1,7:1
[admin@PE1]>ip route vrf add routing-mark=B interfaces=ether4 routedistinguisher=9.9.9.1:2
export-route-targets=1:2 import-route-targets=6:2,7:2
[admin@PE2]>ip route vrf add routing-mark=A interfaces=ether3 routedistinguisher=9.9.9.6:1
export-route-targets=6:1 import-route-targets=1:1,7:1
[admin@PE2]>ip route vrf add routing-mark=B interfaces=ether4 routedistinguisher=9.9.9.6:2
export-route-targets=6:2 import-route-targets=1:2,7:2
[admin@PE3]>ip route vrf add routing-mark=A interfaces=ether3 routedistinguisher=9.9.9.7:1
export-route-targets=7:1 import-route-targets=1:1,6:1
[admin@PE3]>ip route vrf add routing-mark=B interfaces=ether4 routedistinguisher=9.9.9.7:2
export-route-targets=7:2 import-route-targets=1:2,6:2
206
grigoryev.victor@gmail.com http://vmg.pp.ua
Здесь (сравни с п. 1.2.2)
route-distinguisher определяет значение, прикрепляемое к BGP-пакету;
получающие маршрутизаторы используют это значение для заполнения таблиц
VPNv4-маршрутизации и организации VPN . Чтобы принимающие роутеры
различали информацию от различных VPN, это значение должно быть различно
для разных VPN на одном устройстве. Route-distinguisher не используется
получающим маршрутизатором для определения принадлежности передающего
роутера конкретной VPN. Для этого используется route-targets.
export-route-targets – это своего рода метка (синоним) для route-distinguisher.
import-route-targets – это список из внешних export-route-targets, служащий для
определения совокупности роутеров, образующих конкретную VPN.
Укажем BGP, что VRF, определяемые маркерами маршрутов A и B, будут
участвовать в маршрутизации для семейства адресов vpnv4.
[admin@PE1] > routing bgp instance vrf add routing-mark=A redistributeconnected=yes
[admin@PE1] > routing bgp instance vrf add routing-mark=B redistributeconnected=yes
[admin@PE2] > routing bgp instance vrf add routing-mark=A redistributeconnected=yes
[admin@PE2] > routing bgp instance vrf add routing-mark=B redistributeconnected=yes
[admin@PE3] > routing bgp instance vrf add routing-mark=A redistributeconnected=yes
[admin@PE3] > routing bgp instance vrf add routing-mark=B redistributeconnected=yes
Роутер PE1 получит от роутера PE2 BGP-сообщение Update (рис.15.14) в
котором для организации маршрутизации пакетов заказчика A в сторону сети
172.16.2.0/24 назначается метка 26. Заметим, что route-distinguisher 9.9.9.6:1 для
VPN заказчика A в роутере PE2 представлен в сообщении в виде 6.9.9.9:1. В
сообщении можно также видеть route-targets 6:1 VPN заказчика A в роутере PE2.
Аналогичные сообщения получат другие PE-роутеры.
Посмотрим на граничном маршрутизаторе PE1 маршруты c маркером A
[admin@PE1] > ip route print detail where routing-mark=A
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
0 ADC
dst-address=172.16.1.0/24 pref-src=172.16.1.1 gateway=ether3 gatewaystatus=ether3 reachable distance=0 scope=10 routing-mark=A
1 ADb dst-address=172.16.2.0/24 gateway=9.9.9.6 gateway-status=9.9.9.6 recursive via
1.1.1.1,4.4.4.1 ether1,ether2 distance=200 scope=40 target-scope=30 routing-mark=A
bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:6:1"
2 ADb dst-address=172.16.3.0/24 gateway=9.9.9.7 gateway-status=9.9.9.7 recursive via
4.4.4.1 ether2 distance=200 scope=40target-scope=30 routing-mark=A bgp-localpref=100 bgp-origin=incomplete bgp-ext-communities="RT:7:1"
207
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис.15.14 BGP-сообщение Update
Видим наличие маршрутов в сторону всех сетей 172.16.1.0/24, 172.16.2.0/24
и 172.16.3.0/24 компьютеров A1, A2 и A3 заказчика A.
Посмотрим на граничном маршрутизаторе PE1 маршруты c маркером B
[admin@PE1] > ip route print detail where routing-mark=B
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
3 ADC dst-address=172.16.1.0/24 pref-src=172.16.1.1 gateway=ether4 gatewaystatus=ether4 reachable distance=0 scope=10 routing-mark=B
4 ADb dst-address=172.16.2.0/24 gateway=9.9.9.6 gateway-status=9.9.9.6 recursive via
1.1.1.1,4.4.4.1 ether1,ether2 distance=200 scope=40 target-scope=30 routing-mark=B
bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:6:2"
5 ADb dst-address=172.16.3.0/24 gateway=9.9.9.7 gateway-status=9.9.9.7 recursive via
4.4.4.1 ether2 distance=200 scope=40 target-scope=30 routing-mark=B bgp-localpref=100 bgp-origin=incomplete bgp-ext-communities="RT:7:2"
208
grigoryev.victor@gmail.com http://vmg.pp.ua
Видим наличие маршрутов в сторону всех сетей 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 он идёт через интерфейс ether4.
Просмотр на граничных маршрутизаторах PE2 и PE3 маршрутов c маркерами
A либо B даст аналогичный результат.
Получили две независимые VPN третьего уровня для заказчиков А и В, у
которых одинаковые адресные пространства. Убедитесь в этом с помощью
команды /tool telnet. Например, зайдите из A1 в A2, из А1 в А3, из А2 в А3, из B1
в B2,из B1 в А3 и из B2 в B3. Выход из сессии telnet осуществляется с помощью
комбинации клавиш CtrlD.
Изучим, как MPLS-метки помогают организовать VPN. Пустим обычные
пинги c сайта A1 в сторону сайта A2
[admin@A1]> ping 172.16.2.2
С помощью анализатора пакетов Wireshark изучим структуру ICMP-пакетов
на интерфесах e0 маршрутизатора PE1, e1 маршрутизатора P1 и e1 маршрутизатора
P2 . (Рис. 15.15, 15.16 и 15.17)
Рис.15.15. Структура ICMP-пакета на интерфесе e0 маршрутизатора PE1
Рис.15.16. Структура ICMP-пакета на интерфесе e1 маршрутизатора P1
Рис.15.17. Структура ICMP-пакета на интерфесе e1 маршрутизатора P2
Объясним полученное.
маршрутизаторе PE1
Таблица
VPNv4-маршрутов на граничном
[admin@PE1] > rou bg vpnv4-route pr
Flags: L - label-present
ROUTE-DISTINGUISHER DST-ADDRESS GATEWAY INTERFACE IN-LABEL
OUT-LABEL
209
grigoryev.victor@gmail.com http://vmg.pp.ua
0 L 9.9.9.6:1
172.16.2.0/24 9.9.9.6
ether1
26
26
показывает, что для организации правильной маршрутизации пакетов заказчика A
(route-distinguisher =9.9.9.6:1) в сторону сети 172.16.2.0/24 им назначена метка 26.
Эту метку можно увидеть на всех 3-х рисунках. Для транспорта пакетов от A1 к A2
используется метка 17. Эту метку можно увидеть на рис.15.15. Таблица пробросов
MPLS на PE1 показывает, что пакеты с меткой 17 будут направлены на адрес
1.1.1.1 маршрутизатора P1.
[admin@PE1] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS DESTINATION INTERFACE
NEXTHOP
6 L 18
17
9.9.9.6/32
ether1
1.1.1.1
Таблица пробросов MPLS на P1 показывает, что пакеты с входящей меткой 17
получат выходящую метку 16 и будут направлены на адрес 2.2.2.2 маршрутизатора
P2. Эту метку можно увидеть на рис.15.16.
[admin@P1] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS DESTINATION INTERFACE NEXTHOP
3 L 17
16
9.9.9.6/32
ether2
2.2.2.2
Таблица VPNv4 маршрутов на граничном маршрутизаторе PE2
[admin@PE2] > rou bg vpnv4-route pr det
Flags: L - label-present
3 L route-distinguisher=9.9.9.6:1 dst-address=172.16.2.0/24 interface=ether3
in-label=26 bgp-ext-communities="RT:6:1"
и таблица пробросов MPLS
[admin@PE2] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS DESTINATION
6 26
172.16.2.0/24@A
показывает, что пакеты с меткой 26 попадут в сеть 172.16.2.0/24 через интерфейс
ether3. Это значит, что они попадут на компьютер A2.
Уберём поддержку протокола LDP для всех маршрутизаторов провайдера
mpls ldp set enabled=no transport-address=0.0.0.0 lsr-id=0.0.0.0
mpls ldp interface remove [find]
2.2 MPLS VPN 3-го уровня c организацией LSP с помощью RSVP
Следуя п. 1.1.2. организуем в MPLS-облаке LSP с помощью протокола
RSVP-TE.
Изучим, как MPLS-метки помогают организовать VPN. Пустим обычные
пинги c сайта A1 в сторону сайта A2
[admin@ A1]> ping 172.16.2.2
С помощью анализатора пакетов Wireshark изучим структуру ICMP-пакетов
на интерфесах e0 маршрутизатора PE1, e1 маршрутизатора P1 и e1 маршрутизатора
P2 . (рис 15.18, 15.19 и 15.20)
Объясним полученное.
Таблица
VPNv4-маршрутов на граничном
210
grigoryev.victor@gmail.com http://vmg.pp.ua
маршрутизаторе PE1
[admin@PE1] > rou bg vpnv4-route pr
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
ether1
16
16
показывает, что для организации правильной маршрутизации пакетов заказчика A
(route-distinguisher =9.9.9.6:1) в сторону сети 172.16.2.0/24 им назначена метка 16.
Эту метку можно увидеть на всех 3-х рисунках. Для транспорта пакетов от A1 к A2
используется метка 20. Эту метку можно увидеть на рис.15.18.
Рис.15.18. Структура ICMP-пакета на интерфесе e0 маршрутизатора PE1.
Рис.15.19. Структура ICMP-пакета на интерфесе e1 маршрутизатора P1
Рис.15.20. Структура ICMP-пакета на интерфесе e1 маршрутизатора P2
Таблица пробросов MPLS на P1 показывает, что пакеты с входящей меткой 20
получат такую же выходящую метку и будут направлены на адрес 2.2.2.2
маршрутизатора P2. Эту метку можно увидеть на рис.15.19.
[admin@P1] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS
DESTINATION
INTERFACE NEXTHOP
0 expl-null
1 T 19
expl-null
9.9.9.6:1->9.9.9.1:5
ether1
1.1.1.2
2 T 20
20
9.9.9.1:1->9.9.9.6:3
ether2
2.2.2.2
Таблица VPNv4 маршрутов на граничном маршрутизаторе PE2
[admin@PE2] > rou bg vpnv4-route pr det
Flags: L - label-present
3 L route-distinguisher=9.9.9.6:1 dst-address=172.16.2.0/24 interface=ether3
in-label=16 bgp-ext-communities="RT:6:1"
и таблица пробросов MPLS
211
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@PE2] > mpls forwarding-table pr
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS DESTINATION
1 16
172.16.2.0/24@A
показывает, что пакеты с меткой 16 попадут в сеть 172.16.2.0/24 через интерфейс
ether3. Это значит, что они попадут на компьютер A2.
Требования для сдачи работы
Настроить LDP VPLS с организацией LSP с помощью LDP и RSVP, BGP
VPLS с организацией LSP с помощью LDP и RSVP, MPLS VPN 3-го уровня c
организацией LSP с помощью LDP и RSVP.
212
grigoryev.victor@gmail.com http://vmg.pp.ua
16. VPN-клиенты Windows 7 для VPN-серверов Mikrotik
Соединение SSTP-клиента Windows7 с SSTP-сервером Mikrotik
Соединение L2TP IPsec-клиента Windows7 с L2TP -сервером Mikrotik
213
218
В Windows 7 встроены 4 VPN-клиента: PPTP, L2TP IPsec, SSTP и IKE v2. В
Mikrotik есть сервера PPTP, L2TP, SSTP и поддерживается IPsec. Настройка в
Windows 7 PPTP-клиента для PPTP-сервера Mikrotik элементарна и здесь
приводится не будет.
В этом разделе рассмотрим настройку VPN-соединения между Windows 7 и
Mikrotik по протоколам SSTP и L2TP IPsec.
Для упрощения конфигурации отключим брандмауэр Windows7.
Соединение SSTP-клиента Windows7 с SSTP-сервером Mikrotik
Будем работать под Window7. Установим OpenVPN. Создадим тап-интерфейс:
Все Программы – OpenVPN – Utilites-Add new tap virtual Ethernet adapter. В Панель
управления\Сеть и Интернет\Сетевые подключения переименуем новый адаптер в
tap0 и дадим ему адрес 10.0.0.2/24.
Будем работать с GNS3 под Window7. Зайдём в папку GNS3. Установим
routeros под qemu на образ диска mt.img из образа CD-инсталяции mt.iso
Qemu-img create –f qcow2 mt.img
Qemu mt.img –cdrom mt.iso –boot d
Произведём конфигурацию GNS3, как указано в предыдущих разделах
Создадим топологию из одного роутера Mikrotik в опциях которого укажем
параметры для связи с хост-машиной Windows 7 через тап-интерфейс tap0
-net nic –net tap,ifmame-tap0
Запустим топологию и назначим в Mikrotik адрес на интерфейс ether7,
связанный с тап-интерфесом tap0
Ip address add address=10.0.0.1/24 interface=ether7
Проверим связь из windows в Mikrotik
Ping 10.0.0.1
В папке OpenVPN\easy-rsa есть средства работы с RSA-сертификатами.
Отредактируем файл vars.bat
@echo off
set HOME=\OpenVPN\easy-rsa
set KEY_CONFIG=openssl-1.0.0.cnf
set KEY_DIR=keys
set KEY_SIZE=1024
set KEY_COUNTRY=UA
set KEY_PROVINCE=DP
set KEY_CITY=DNSK
set KEY_ORG=FFECS
set KEY_EMAIL=mail@host.domain
set KEY_CN=CN
213
grigoryev.victor@gmail.com http://vmg.pp.ua
set KEY_NAME=NAME
set KEY_OU=EOM
set PKCS11_MODULE_PATH=changeme
set PKCS11_PIN=1234
Создадим пустые файлы index и serial files. Это делается один раз
C:\OpenVPN\easy-rsa>vars
C:\OpenVPN\easy-rsa>clean-all
Создадим корневой сертификат с закрытым ключом. «Common Name»
сертификата возьмём произвольным, например myCN. Это делается один раз
C:\OpenVPN\easy-rsa>vars
C:\OpenVPN\easy-rsa>build-ca
WARNING: can't open config file: c:/openssl/ssl/openssl.cnf
…
Country Name (2 letter code) [UA]:
State or Province Name (full name) [DP]:
Locality Name (eg, city) [DNSK]:
Organization Name (eg, company) [FFECS]:
Organizational Unit Name (eg, section) [EOM]:
Common Name (eg, your name or your server's hostname) [CN]:myCN
Name [NAME]:
Email Address [mail@host.domain]:
Создадим серверный сертификат с закрытым ключом. «Common Name»
сертификата сделаем равным адресу 10.0.0.1 нашего будущего SSTP-сервера
Mikrotik. Имя файлов сертификата возьмем любым, например server
C:\OpenVPN\easy-rsa>build-key-server server
WARNING: can't open config file: c:/openssl/ssl/openssl.cnf
…
Country Name (2 letter code) [UA]:
State or Province Name (full name) [DP]:
Locality Name (eg, city) [DNSK]:
Organization Name (eg, company) [FFECS]:
Organizational Unit Name (eg, section) [EOM]:
Common Name (eg, your name or your server's hostname) [CN]:10.0.0.1
Name [NAME]:
Email Address [mail@host.domain]:
…
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
214
grigoryev.victor@gmail.com http://vmg.pp.ua
Создадим сертификат клиента с закрытым ключом. «Common Name»
сертификата возьмём произвольным, например clientCN. Имя файлов сертификата
возьмем любым, например client
C:\OpenVPN\easy-rsa>build-key client
WARNING: can't open config file: c:/openssl/ssl/openssl.cnf
…
Country Name (2 letter code) [UA]:
State or Province Name (full name) [DP]:
Locality Name (eg, city) [DNSK]:
Organization Name (eg, company) [FFECS]:
Organizational Unit Name (eg, section) [EOM]:
Common Name (eg, your name or your server's hostname) [CN]:clientCN
Name [NAME]:
Email Address [mail@host.domain]:
…
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Перепишем в Mikrotik корневой сертификат, серверный сертификат и
закрытый ключ к нему
C:\OpenVPN\easy-rsa>cd keys
C:\OpenVPN\easy-rsa\keys>ftp 10.0.0.1
Связь с 10.0.0.1.
220 MikroTik FTP server (MikroTik 5.18) ready
Пользователь (10.0.0.1:(none)): admin
331 Password required for admin
Пароль:
230 User admin logged in
ftp> bin
200 Type set to I
ftp> put ca.crt
200 PORT command successful
150 Opening BINARY mode data connection for '/ca.crt'
226 BINARY transfer complete
ftp: 1269 байт отправлено за 0,00 (сек) со скоростью 634,50 (КБ/сек).
ftp> mput serv*
mput server.crt? y
200 PORT command successful
150 Opening BINARY mode data connection for '/server.crt'
226 BINARY transfer complete
ftp: 3930 байт отправлено за 0,00 (сек) со скоростью 1310,00 (КБ/сек).
mput server.csr? n
mput server.key? y
215
grigoryev.victor@gmail.com http://vmg.pp.ua
200 PORT command successful
150 Opening BINARY mode data connection for '/server.key'
226 BINARY transfer complete
ftp: 916 байт отправлено за 0,00 (сек) со скоростью 916,00 (КБ/сек).
ftp> quit
Установим в MikroTik корневой сертификат, серверный сертификат и
закрытый ключ к нему
[admin@MikroTik] > certificate import file-name=ca.crt
passphrase:
[admin@MikroTik] > certificate import file-name=server.crt
passphrase:
[admin@MikroTik] > certificate import file-name=server.key
passphrase:
На запрос passphrase просто жмите Enter.
Проверим, что сертификаты установились правильно.
[admin@MikroTik] > certificate print
Flags: K - decrypted-private-key, Q - private-key, R - rsa, D – dsa
0
name="cert1" subject=C=UA, ST=DP, L=DNSK, O=FFECS, OU=EOM,
CN=myCN, name=NAME, emailAddress= mail@host.domain
issuer=C=UA,
ST=DP, L=DNSK, O=FFECS, OU=EOM, CN=myCN, name=NAME,
emailAddress= mail@host.domain
serial-number= "9DD0491799EEEE30"
email=mail@host.domain invalid-before=aug/21/2012 13:10:41
invalidafter=aug/19/2022 13:10:41 ca=yes
1 KR name="cert2" subject=C=UA,ST=DP,L=DNSK,O=FFECS,OU=EOM,
CN=serverCN,name=NAME,emailAddress=mail@host.domain issuer=C=UA,
ST=DP,L=DNSK,O=FFECS,OU=EOM,CN=myCN,name=NAME,emailAddress=m
ail@host.domain
serial-number="01" email=mail@host.domain invalidbefore=aug/21/2012 13:12:33 invalid-after=aug/19/2022 13:12:33 ca=yes
Переименуем сертификат c флагами KR в srv. (K - decrypted-private-key, R –
rsa)
[admin@MikroTik] > certificate set 1 name=srv
Добавим пользователя q с паролем q. После подключения клиент получит
адрес 3.3.3.3, а SSTP-сервер 2.2.2.2.
[admin@MikroTik] >ppp secret add name=a password=a service=sstp localaddress=2.2.2.2 remote-address=3.3.3.3 profile=default-encription
Активируем SSTP-сервер с указанием ему сертификата srv
[admin@MikroTik]>interface sstp-server server set enabled=yes certif=srv
profile=default-encription
Установим сертификат и в Windows 7. Вызовим консоль Майкрософт mmc.
Далее добавим оснастку для работы с сертификатами:
Файл-добавить или удалить оснастку – сертификаты – добавить -учётной
записи компьютера – далее - локальным компьютером - готово – ок.
216
grigoryev.victor@gmail.com http://vmg.pp.ua
Добавим в Windows корневой сертификат. Для этого в консоли Сертификаты
выбираем:
Доверенные корневые центры сертификации – сертификаты - правая кнопка
мыши - все задачи – импорт – далее – обзор -C:\OpenVPN\easy-rsa\keys\ca.crt –
далее - поместить все сертификаты в следующее хранилище Доверенные корневые
центры сертификации –далее – готово.
Видим: Импорт успешно выполнен
Рис. 16.1. VPN-подключение
Рис. 16.2. Параметры безопасности VPN-подключения
217
grigoryev.victor@gmail.com http://vmg.pp.ua
Аналогичным образом добавляем сертификат клиента C:\OpenVPN\easyrsa\keys\client.crt.
Организуем соединение SSTP-клиента Windows7 с SSTP-сервером Mikrotik по
адресу 10.0.0.1:
Панель управления \Сеть и Интернет \Центр управления сетями и общим
доступом – настройка нового подключения или сети - подключение к рабочему
месту –далее - использовать моё подключение к Интернет (VPN)-Интернет адрес
10.0.0.1 – Пользователь q – пароль q подключить.
Windiws сама определит, что на противоположной стороне находится SSTPсервер, проверит сертификат сервера и подключится. Проверим
Ping 2.2.2.2
Обмен пакетами с 2.2.2.2 по с 32 байтами данных:
Ответ от 2.2.2.2: число байт=32 время=4мс TTL=64
Ответ от 2.2.2.2: число байт=32 время=4мс TTL=64
В Панель управления \Сеть и Интернет \Сетевые подключения появится новый
элемент VPN-подключение (Рис. 16.1) с параметрами безопасности, приведенными
на Рис.16.2.
Остановим sstp-server
[admin@MikroTik]>interface sstp-server server set enabled=no
Соединение L2TP IPsec-клиента Windows7 с L2TP-сервером Mikrotik
Windows осуществляет L2TP-соединение только через IPsec-канал. Поэтому
вначале научимся шифровать трафик между Windows7 (10.0.0.2) и Mikrotik
(10.0.0.2) с помощью IPsec. Настроим IPsec-канал на стороне Mikrotik. Используем
(как установлено по умолчанию в IPsec для Windows7) алгоритм шифрования
3des, хеширование sha1
и DH-группу modp1024. В качестве метода проверки
подлинности используем ключ 123456789. Используем автоматическое создание
IPsec-политики (generate-policy=yes) и разрешим принимать соединения ото всех
(address=0.0.0.0/0)
[admin@MikroTik] > ip ipsec proposal print detail
Flags: X - disabled, * - default
0 * name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m pfsgroup=modp1024
[admin@MikroTik] > ip ipsec peer print detail
Flags: X - disabled
0 address=0.0.0.0/0 port=500 auth-method=pre-shared-key secret="123456789"
generate-policy=yes exchange-mode=main send-initial-contact=yes nat-traversal=no myid-user-fqdn="" proposal-check=obey hash-algorithm=sha1
enc-algorithm=3des dhgroup=modp1024 lifetime=1d lifebytes=0 dpd-interval=2m dpd-maximum-failures=5
Настроим IPsec-канал на стороне Windows 7. . Вызовем консоль Майкрософт
mmc. Далее добавим оснастку «Управление политикой IP-безопастности»
(локальный компьбтер). В контекстном меню выбираем создание политики IPбезопастности. Запустится мастер. Назовём политику «Политика IP218
grigoryev.victor@gmail.com http://vmg.pp.ua
безопастности». Нам надо настроить IP-фильтр, действие фильтра, метод проверки
подлинности, конечную точку туннеля и тип подключения (см. Рис. 16.3 а, б).
А)
Б)
Рис 16.3. Политика IP-безопастности
Во вкладке Общие политики IP-безопастности на рис. 16.3 можно увидеть
(настроить) алгоритм шифрования 3des, хеширование sha1
и DH-группу
modp1024 (рис. 16.4)
Рис. 16.4. Методы безопасности.
219
grigoryev.victor@gmail.com http://vmg.pp.ua
Настроим IP-фильтр (рис. 16.5), действие фильтра (рис. 16.6), метод проверки
подлинности (рис. 16.7), конечную точку туннеля (рис. 16.8) и тип подключения
(рис. 16.9). Заметим, что в IP-фильтре (рис. 16.5) в качестве источников пакетов
фигурирует Mikrotik
Рис. 16.5. IP-фильтр.
В консоли в контекстном меню политики выбираем назначить.
Пустим пинги в сторону Mikrotik. После некоторой задержки они пойдут. В
Mikrotik можно увидеть сгенерированную политику и SA
[admin@MikroTik] > ip ipsec policy print detail
[admin@MikroTik] > ip ipsec installed-sa print detail
220
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 16.6. Действие фильтра
Рис. 16.7. Метод проверки подлинности
221
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 16.8. Конечная точку туннеля
Рис. 16.9. Тип подключения
Перейдём к настройке соединение L2TP IPsec-клиента Windows7 с L2TPсервером Mikrotik. Надо сбросить IPsec. В Mikrotik.
[admin@MikroTik]> ip ipsec peer set 0 disabled=yes
[admin@MikroTik]> ip ipsec peer set 0 disabled=no
В консоли Windows в контекстном меню политики выбираем снять. Не
забудьте в нужное время назначить политику. Может быть полезной перегрузка
службы агента политики IPsec.
В случае неудачной конфигурации, могут перестать идти пинги из Windows
(Mikrotik) сторону адреса 10.0.0.1 (10.0.0.2) Mikrotik (Windows). Надо также будет
сбросить IPsec.
Добавим пользователя а с паролем а. После подключения L2TP-клиент
windows получит адрес 172.16.1.2, а L2TP-сервер Mikrotik - 172.16.1.1.
[admin@MikroTik]> ppp secret add name=a password=a service=l2tp localaddress=172.16.1.1 remote-address=172.16.1.2 profile=default-encription
222
grigoryev.victor@gmail.com http://vmg.pp.ua
Активируем L2TP-сервер
[admin@MikroTik]> int l2tp-server server set enabled=yes default-profile=defaultencryption
Адаптируем в MikroTik существующие настройки IPsec под L2TP , установив
exchange-mode=main-l2tp.
[admin@MikroTik] > ip ipsec peer set 0 exchange-mode=main-l2tp
В Windows 7 в Панель управления \Сеть и Интернет \Сетевые подключения
изменим элемент VPN-подключение, указав тип L2TP IPSeс VPN, обязательное
шифрование данных (рис.16.10) и в дополнительных параметрах - ключ 123456789
(рис. 16.11).
Рис. 16.10. Свойства L2TP IPSeс VPN
223
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 16.11. Ключ для IPSec
В контестном меню VPN-подключения выберем соединиться. Windows
соединиться с Mikrotik по протоколу L2TP IPSeс. На Windows с некоторой
задержкой пойдут пинги в сторону Mikrotik. Шифрование началось.
На Mikrotik сгенерировалась динамическая политика IPSeс
[admin@MikroTik] > ip ipsec policy print detail
Flags: X - disabled, D - dynamic, I - inactive
0 D src-address=10.0.0.2/32 src-port=any dst-address=10.0.0.1/32 dst-port=any
protocol=udp action=encrypt level=require ipsec-protocols= esp tunnel= no sa-srcaddress= 10.0.0.2 sa-dst-address= 10.0.0.1 proposal= default priority=2
Заметим, что в качестве источников фигурирует адрес 10.0.0.2 Windows.
Можно видеть и SA с увеличивающимся числом зашифрованных байт current-bytes
[admin@MikroTik] > ip ipsec installed-sa print detail
Flags: A - AH, E - ESP, P - pfs
0 E spi=0x192EBE8 src-address=10.0.0.2 dst-address=10.0.0.1 auth-algorithm=sha1
enc-algorithm=3des
replay=
4
state=
mature
auth-key=
"a5f9f8f9e2cf13f45392c249716f47ae33a372fa"
enc-key=
"20e7961814b47a170803a16b589cb89de460151905dcd53b"
addtime=aug/21/2012 21:24:38 expires-in=28m55s add-lifetime=48m/1h currentbytes=17723
1 E spi=0xE2E7A2FF src-address=10.0.0.1 dst-address=10.0.0.2 auth-algorithm=sha1
enc-algorithm=3des replay=4 state=mature auth-key= "0bcd8a290d3fba3f90919225fb9f508fd9d31029"
enc-key=
"762fa153bf883ae9f731ef4f1726a56c427df19d4fc65d29"
addtime=aug/21/2012 21:24:38 expires-in=28m55s addlifetime=48m/1h current-bytes=11447
224
grigoryev.victor@gmail.com http://vmg.pp.ua
Увидим также удалённый пир
[admin@MikroTik] > ip ipsec remote-peers print detail
0 local-address=10.0.0.1 remote-address=10.0.0.2 state=established
side=responder established=1m24s
Требования для сдачи работы
Предъявить соединения SSTP и L2TP IPsec клиентов Windows7 с SSTP и L2TP
серверами Mikrotik.
225
grigoryev.victor@gmail.com http://vmg.pp.ua
17. Курсовой проект.
Постановка задачи
Пример выполнения
Быстрый старт
Требование к отчёту и порядок сдачи проекта
226
229
241
241
Постановка задачи
У корпорации 4 филиала и в каждом по два маршрутизатора: в 0-м - R0 и R4,
в 1-м - R1 и R5, во 2-м - R2 и R6, 3-м - R3 и R7. Внешние маршрутизаторы R0, R1,
R2 и R3 имеют выход в Интернет, а внутренние R4, R5, R6 и R7 – нет (рис. 17.1).
а. Адреса внутренних сетей филиалов представлены на рис. 17.1: 0192.168.4*V.0/24;
1-192.168.4*V+1.0/24;
2-192.168.4*V+2.0/24;
3192.168.4*V+3.0/24. Например, для
варианта V=7 0-192.168.28.0/24 1192.168.29.0/24
2-192.168.30.0/24
3-192.168.31.0/24.
К
внутренним
маршрутизаторам R4, R5, R6 и R7 подсоединены локальные сети филиалов,
представленные в каждом филиале одним компьютером R13, R12, R10 и R11,
соответственно (рис. 17.2 или 17.3).
Рис. 17.1. Топология для курсового проекта. 1 этап.
Ставится задача поочерёдно объединить компьютеры R10, R11, R12 и R13
локальных сетей филиалов в две единые для всей корпорации виртуальные
частные сети на основании технологии MPLS. Одна VPN должна быть уровня 2, а
вторая – 3.
Технология для MPLS VPN уровня 3 – BGP VRF. Для MPLS VPN уровня 2
выберем BGP VPLS.
Участники MPLS-сети должны видеть друг друга по протоколу уровня 2 и
иметь возможность обмениваться метками. Поэтому для решения задачи следует
объединить внутренние маршрутизаторы R4, R5, R6 и R7 в одну вспомогательную
виртуальную частную сеть уровня 2 на основе технологии SSTP. Метки будут
помещаться в пакеты PPP при обмене данными по SSTP.
б. Выбор номера схемы соединения филиалов по протоколу SSTP
осуществляется из рис. 17.4 по формуле V%15+1.
в. В качестве протокола маршрутизации чётные варианты используют RIP, а
нечётные – OSPF.
Для связи SSTP-серверов и клиентов на внутренних маршрутизаторах R4, R5,
R6 и R7 между собой следует обеспечить их видимость друг другом по протоколу
226
grigoryev.victor@gmail.com http://vmg.pp.ua
IP. Для этого на внешних маршрутизаторах R0, R1, R2 и R3 следует организовать
преобразование исходящих и приходящих адресов.
Рис. 17.2. Топология для курсового проекта. 2 этап. Адреса для VPN уровня 2.
Рис. 17.3. Топология для курсового проекта. 2 этап. Адреса для VPN уровня 3.
г. Для организации MPLS VPN уровня 2 и 3 используется BGP с отражателем
маршрутов. Номер маршрутизатора отражателем маршрута равен V%4+4.
227
grigoryev.victor@gmail.com http://vmg.pp.ua
Например, для варианта V=7 это R7 (7%4+4=3+4=7). В MPLS-сети чётные
варианты организуют LSP с помощью LDP, а нечётные с помощью RSVP.
д. Адреса компьютеров R10, R11, R12 и R13 для VPN уровня 2 представлены
на
рис.
17.2:
R10-172.16.200+V.1/24,
R11-172.16.200+V.2/24,
R12172.16.200+V.3/24 и R13-172.16.200+V.4/24, где V-номер варианта. Например, для
варианта V=7: R10-172.16.207.1/24, R11-172.16.207.2/24, R12-172.16.207.3/24 и
R13-172.16.207.4/24.
Рис. 17.4. Схемы соединения филиалов 0, 1, 2 и 3 по протоколу SSTP. К-клиент, Ссервер. Фактически 0 это R4, 1- R5, 2-R6, 3-R7.
е. Адреса компьютеров R10, R11, R12 и R13 для VPN уровня 3 представлены
на рис. 17.3: 172.16.1+4*V.2/24, R11-172.16.2+4*V.2/24, R12-172.16.3+4*V.2/24 и
172.16.4+4*V.2/24, где V-номер варианта. Например, для варианта V=7: R10172.16.29.2/24 (1+4*7=29), R11-172.16.30.2/24,
R12-172.16.31.2/24 и R13172.16.32.2/24.
228
grigoryev.victor@gmail.com http://vmg.pp.ua
Пример выполнения
Выполним курсовой проект для варианта V=0 и номера тап-сети D=0.
Согласно варианту:
а. Адреса внутренних сетей филиалов 0-192.168.0.0/24 1-192.168.1.0/24 2192.168.2.0/24 3-192.168.3.0/24(4*0+3).
б. Схема соединения филиалов по протоколу SSTP имеет номер 0 из рис. 17.3.
.
Здесь, согласно рис. 17.3, 0 это R4, 1- R5, 2-R6, 3-R7.
в. В качестве протокола маршрутизации используем RIP.
г. В качестве отражателя маршрутов используется маршрутизатор R5. В
MPLS-сети LSP организуем с помощью LDP.
д. Адреса компьютеров для VPN уровня 2: R10-172.16.200.1/24, R11172.16.200.2/24, R12-172.16.200.3/24 и R13-172.16.200.4/24.
е. Адреса компьютеров для VPN уровня 3: R10-172.16.1.2/24(1+4*0=1), R11172.16.2.2/24, R12-172.16.3.2/24 и R13-172.16.4.2/24.
Создаём в GNS3 проект с именем MPLS. Соберите в нём топологию,
изображённую на рис. 17.1 и добавьте в каждый маршрутизатор тап-интерфейс,
согласно номеру своей тап-сети. Например, если у вас тап-сеть 0, то для R1
options = -net nic,vlan6 -net tap,vlan6,script=no,downscript=no,ifname=tap001
1. Стартуем проект. Назначим имена, например для R0
[admin@R0] >system identity set name=R0
Проверим у всех маршрутизаторов соседей с помощью команды ip neighbour
print. Назначим адреса на тап-интерфейсы, например для R2
[admin@R2] >ip address add address=10.0.2.1/24 interface=ether7
Пропингуем Ubuntu, например для R2
[admin@R0] >ping 10.0.2.1
Для удобства работы используйте протокол ssh и закладки в терминальном
окне Ubuntu (см. рис. 2.3 и.2.4 из разделы 2).
Дайте табам имена
Для R0, R1, R2 и R3 (и только) обеспечьте взаимную связь через свою модель
Интернета, назначив шлюз на тап-интерфейс Ubuntu, например для R1
[admin@R0] >ip route add dst-address=10.0.0.0/16 gateway=10.0.1.2
Пропингуйте R0, R1, R2 и R3 между собой по адресам тап-интерфейсов.
На каждом филиале на внутренних маршрутизаторах R4, R5, R6 и R7
сделайте шлюз на внешний маршрутизатор R0, R1, R2 и R3, соответственно.
Например, для филиала 1 после назначения адресов
[admin@R1] >ip address add address=192.168.1.1/24 interface=ether1
229
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@R5] >ip address add address=192.168.1.2/24 interface=ether1
и обязательной проверки
[admin@R5] >ping 192.168.1.1
назначаем шлюз
[admin@R5] >ip route add gateway=192.168.1.1
2. Настроим NAT для исходящих адресов на маршрутизаторах R0 R1 R2 R2,
имеющих доступ в Интернет
/ip firewall nat add chain=srcnat action=masquerade out-interface=ether7
Из внешних маршрутизаторов R4, R5, R6 и R7 должны пинговаться адреса
10.0.4.1 10.0.5.1 10.0.6.1 10.0.7.1 тап-интерфейсов внутренних маршрутизаторов
R4, R5, R6 И R7.
Настроим NAT для входящих адресов на маршрутизаторах R0 R1 R2 R3.
Назначим на тап-интерфейсы R0, R1, R2 и R3 дополнительные адреса 10.0.0.22/24
10.0.1.22/24 10.0.2.22/24 10.0.3.22/24. Например, для R3
[admin@R3] >ip address add address=10.0.3.22/24 interface=ether7
Определим для R0, R1, R2 и R3 предпочтительные исходящие адреса для
маршрутизации 10.0.0.1/24, 10.0.1.1.24, 10.0.2.1/24 и 10.0.3.1/24, соответственно.
Например, для R3
[admin@R3] >ip route set 0 pref-src= 10.0.3.1
Введём правила преобразования адресов 192.168.0.2, 192.168.1.2, 192.168.2.2,
192.168.3.2 внутренних маршрутизаторов R4, R5, R6 и R7 во внешние адреса тапинтерфейсов маршрутизаторов R0, R1, R2 и R2. Например
[admin@R0] >/ip firewall nat add chain=dstnat action=dst-nat to-addresses=
192.168.0.2 dst-address=10.0.0.22
[admin@R1] >/ip firewall nat add chain=dstnat action=dst-nat to-addresses=
192.168.1.2 dst-address=10.0.1.22
[admin@R2] >/ip firewall nat add chain=dstnat action=dst-nat to-addresses=
192.168.2.2 dst-address=10.0.2.22
[admin@R3] >/ip firewall nat add chain=dstnat action=dst-nat to-addresses=
192.168.3.2 dst-address=10.0.3.22
Проверьте тщательно преобразования. Вы должны, поочерёдно находясь на
каждом из внутренних маршрутизаторов R4, R5, R6 и R7, соединятся по
протоколу telnet к адресам 10.0.0.22/24, 10.0.1.22/24, 10.0.2.22/24 и 10.0.3.22/24
тап-интерфейсов внешних маршрутизаторов R0, R1, R2 и R3 и попадать в
соответствующие внутренние маршрутизаторы R4, R5, R6 и R7.
3. Объединим филиалы с помощью VPN с использованием SSTP. Мы используем
схему соединения филиалов по протоколу SSTP номер 0 из рис. 17.3. Для других
схем настройка SSTP несколько отличается. Будьте внимательны.
Начнём с сертификатов. Перейдите в свою папку easy-rsa в Ubuntu. Создайте
корневой сертификат CA (Certificate Authority), необходимый для подписи
сертификатов клиента и сервера
. vars (через пробел)
./clean-all
./pkitool --initca
Создадим 3 сертификата s0, s1 и s2 сервера, например
230
grigoryev.victor@gmail.com http://vmg.pp.ua
./pkitool --server s1
и 3 сертификата с0, с1 и с2 клиента, например
./pkitool с0
Перепишем по ssh корневой сертификат на все внутренние компьютеры R4,
R5, R6 и R7, например scp ca.crt admin@10.0.4.1:. Перепишем по ssh сертификаты
и ключи для сервера в SSTP-сервера. Перепишем по ssh сертификаты и ключи для
клиента в SSTP-клиенты
Для топологии 0 нашего варианта 0 (рис. 17.3) перепишем с0, с1 и с2 в R4, а
s0, s1 и s2 в R5, R6 и R7, соответственно
Импортируем в R4
[admin@R4] >certificate import file-name=ca.crt
[admin@R4] >certificate import file-name=с0.crt
[admin@R4] >certificate import file-name=с1.crt
[admin@R4] >certificate import file-name=с2.crt
[admin@R4] >certificate import file-name=с0.key
[admin@R4] >certificate import file-name=с1.key
[admin@R4] >certificate import file-name=с2.key
На запрос passphrase – просто жмём enter. Переименовываем KR
сертификаты. Здесь и далее будьте внимательны с номерами после set. Для их
правильного назначения используйте команду certificate print detail.
[admin@R4] >certificate set 1 name=c0
[admin@R4] >certificate set 2 name=c1
[admin@R4] >certificate set 3 name=c2
Импортируем в R5
[admin@R5 >certificate import file-name=ca.crt
[admin@R5 >certificate import file-name=s0.crt
[admin@R5 >certificate import file-name=s0.key
Переименовываем KR сертификат
[admin@R5 >certificate set 1 name=s0
Импортируем в R6
certificate import file-name=ca.crt
certificate import file-name=s1.crt
certificate import file-name=s1.key
Переименовываем KR сертификат
[admin@R6] >certificate set 1 name=s1
Импортируем в R7
[admin@R7] >certificate import file-name=ca.crt
[admin@R7] >certificate import file-name=s2.crt
[admin@R7] >certificate import file-name=s2.key
Переименовываем KR сертификат
[admin@R7] >certificate set 1 name=s2
На SSTP-серверах добавляем имена, пароли, локальный и удалённый адреса
для SSTP-пользователей
[admin@R5>ppp secret add name=c0 password=c0 local-address=172.16.0.1
remote-address=172.16.0.2
231
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@R6>ppp secret add name=c1 password=c1 local-address=172.16.0.3
remote-address=172.16.0.4
[admin@R7>ppp secret add name=c2 password=c2 local-address=172.16.0.5
remote-address=172.16.0.6
Здесь адреса взяты произвольно. Каких либо рекомендаций по их выбору не
даётся.
Добавляем SSTP-сервера и определяем в них сертификаты
[admin@R5 >int sstp-server add name=s0 user=c0
[admin@R5] >int sstp-server server set enabled=yes certificate=s0 verifyclient-certificate=ye
[admin@R6 >int sstp-server add name=s1 user=c1
[admin@R6]>int sstp-server server set enabled=yes certificate=s1 verifyclient-certificate=ye
[admin@R7 >int sstp-server add name=s2 user=c2
[admin@R7] >int sstp-server server set enabled=yes certificate=s2 verifyclient-certificate=ye
Параметр user – не обязателен.
Добавляем 3 SSTP-клиента в R4 и определяем в них сертификаты. Помним,
что SSTP-клиенты подсоединяются к SSTP-серверам через NAT. Поэтому вместо
адресов
SSTP-серверов
указываем
адреса
соответствующих
внешних
маршрутизаторов.
[admin@R4] >interface sstp-client add certificate=c0 connect-to=10.0.1.22
name=c0 user=c0 password=c0 verify-server-certificate=yes disabled=no
[admin@R4] >interface sstp-client add certificate=c1 connect-to=10.0.2.22
name=c1 user=c1 password=c1 verify-server-certificate=yes disabled=no
[admin@R4] >interface sstp-client add certificate=c2 connect-to=10.0.3.22
name=c2 user=c2 password=c2 verify-server-certificate=yes disabled=no
На R4, R5, R6 и R7 должны появиться новые адреса из диапазона 172.16.0.1172.16.0.6. Пропингуйте из SSTP-клиентов соответствующие им SSTP-сервера по
динамически назначенным адресам
[admin@R4] >ping 172.16.0.1
[admin@R4] >ping 172.16.0.3
[admin@R4] >ping 172.16.0.5
С помощью команды interface bridge add добавим на R4, R5, R6 и R7
интерфейсы-петли в виде моста bridge1. Назначим на них адреса. Значения этих
адресов никак не регламентируются
[admin@R4] >ip address add address=4.4.4.4/32 interface=bridge1
[admin@R5] >ip address add address=5.5.5.5/32 interface=bridge1
[admin@R6] >ip address add address=6.6.6.6/32 interface=bridge1
[admin@R7] >ip address add address=7.7.7.7/32 interface=bridge1
4. Добьемся, чтобы R4, R5, R6 и R7 видели друг друга по этим адресам. В
качестве протокола маршрутизации возьмём
RIP. Помним, что надо
рекламировать сети, а не маршруты
[admin@R4] >ip ad pr
0 10.0.5.1/24
10.0.5.0
ether7
232
grigoryev.victor@gmail.com http://vmg.pp.ua
1 192.168.0.2/24 192.168.0.0 ether1
2 D 172.16.0.2/32
172.16.0.1
c0
3 D 172.16.0.4/32
172.16.0.3
c1
4 D 172.16.0.6/32
172.16.0.5
c2
5
4.4.4.4/32
4.4.4.4
bridge1
[admin@R4] >routing rip network add network=4.4.4.4/32
[admin@R4] >routing rip network add network=172.16.0.1/32
[admin@R4] >routing rip network add network=172.16.0.3/32
[admin@R4] >routing rip network add network=172.16.0.5/32
[admin@R5] >ip ad pr
0 10.0.5.1/24
10.0.5.0
ether7
1 192.168.1.2/24 192.168.1.0 ether1
2 D 172.16.0.1/32
172.16.0.2
s0
3
5.5.5.5/32
5.5.5.5
bridge1
[admin@R5] >routing rip network add network=5.5.5.5/32
[admin@R5] >routing rip network add network=172.16.0.2/32
[admin@R6] >ip ad pr
0 10.0.6.1/24
10.0.6.0
ether7
1 192.168.2.2/24 192.168.2.0 ether1
2 D 172.16.0.3/32
172.16.0.4
s1
3
6.6.6.6/32
6.6.6.6
bridge1
[admin@R6] >routing rip network add network=6.6.6.6/32
[admin@R6] >routing rip network add network=172.16.0.4/32
[admin@R7] >ip ad pr
0 10.0.7.1/24
10.0.7.0
ether7
1
192.168.3.2/24 192.168.3.0 ether1
2 D 172.16.0.5/32
172.16.0.6
s2
3
7.7.7.7/32
7.7.7.7
bridge1
[admin@R7] >routing rip network add network= 7.7.7.7/32
[admin@R7] >routing rip network add network= 172.16.0.6/32
Проверяем маршруты
[admin@R4] >ip route print
0AS
0.0.0.0/0
192.168.0.1
1
1 ADC
4.4.4.4/32
4.4.4.4
bridge1
0
2 ADr
5.5.5.5/32
172.16.0.1
120
3 ADr
6.6.6.6/32
172.16.0.3
120
4 ADr
7.7.7.7/32
172.16.0.5
120
5 ADC
10.0.4.0/24
10.0.4.1
ether7
0
6 ADC
172.16.0.1/32
172.16.0.2 c0
0
7 ADC
172.16.0.3/32
172.16.0.4 c1
0
8 ADC
172.16.0.5/32
172.16.0.6 c2
0
9 ADC
192.168.0.0/24
192.168.0.2 ether1
0
[admin@R5] >ip route print
0 A S 0.0.0.0/0
192.168.1.1
1
1 ADr 4.4.4.4/32
172.16.0.2
120
233
grigoryev.victor@gmail.com http://vmg.pp.ua
2 ADC
5.5.5.5/32
5.5.5.5
bridge1
0
3 ADr
6.6.6.6/32
172.16.0.2
120
4 ADr
7.7.7.7/32
172.16.0.2
120
5 ADC
10.0.5.0/24
10.0.5.1
ether7
0
6 ADC
172.16.0.2/32
172.16.0.1 s0
0
7 ADr
172.16.0.3/32
172.16.0.2
120
8 ADr
172.16.0.5/32
172.16.0.2
120
9 ADC
192.168.1.0/24 192.168.1.2 ether1
0
[admin@R6] >ip route print
0AS
0.0.0.0/0
192.168.2.1
1
1 ADr
4.4.4.4/32
172.16.0.4
120
2 ADr
5.5.5.5/32
172.16.0.4
120
3 ADC
6.6.6.6/32
6.6.6.6
bridge1
0
4 ADr
7.7.7.7/32
172.16.0.4
120
5 ADC
10.0.6.0/24
10.0.6.1
ether7
0
6 ADr
172.16.0.1/32
172.16.0.4
120
7 ADC
172.16.0.4/32
172.16.0.3 s1
0
8 ADr
172.16.0.5/32
172.16.0.4
120
9 ADC
192.168.2.0/24 192.168.2.2 ether1
0
[admin@R7] >ip route print
0AS
0.0.0.0/0
192.168.3.1
1
1 ADr
4.4.4.4/32
172.16.0.6
120
2 ADr
5.5.5.5/32
172.16.0.6
120
3 ADr
6.6.6.6/32
172.16.0.6
120
4 ADC
7.7.7.7/32
7.7.7.7
bridge1
0
5 ADC
10.0.7.0/24
10.0.7.1
ether7
0
6 ADr
172.16.0.1/32
172.16.0.6
120
7 ADr
172.16.0.3/32
172.16.0.6
120
8 ADC
172.16.0.6/32
172.16.0.5 s2
0
9 ADC
192.168.3.0/24
192.168.3.2 ether1
0
Глядя на таблицы маршрутов, мы на всех устройствах видим маршруты на
сети 4.4.4.4/32, 5.5.5.5/32, 6.6.6.6/32 и 7.7.7.7/32. Мы с уверенностью в успехе
запускаем расширенные пинги из R4, R5, R6 и R7 на адреса 4.4.4.4 5.5.5.5 6.6.6.6
7.7.7.7 интерфейсов-петель с адресом источника равным адресу локального
интерфейса-петли, например
[admin@R4] >ping 5.5.5.5 src-address=4.4.4.4
[admin@R4] >ping 6.6.6.6 src-address=4.4.4.4
[admin@R4] >ping 7.7.7.7 src-address=4.4.4.4
[admin@R5] >ping 6.6.6.6 src-address=5.5.5.5
[admin@R5] >ping 7.7.7.7 src-address=5.5.5.5
и т.д.
SSTP VPN уровня 3 настроена. Значит настроена и VPN уровня 2. Настроим
MPLS поверх VPN уровня 2. В MPLS-сети LSP организуем с помощью LDP.
5. Настраиваем LDP, добавляя в него SSTP-интерфейсы и указывая в
качестве транспортного адреса адрес моста
234
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@R4] >mpls ldp set enabled=yes transport-address=4.4.4.4 lsrid=4.4.4.4
[admin@R4] >mpls ldp interface add interface=c0
[admin@R4] >mpls ldp interface add interface=c1
[admin@R4] >mpls ldp interface add interface=c2
[admin@R5] >mpls ldp set enabled=yes transport-address=5.5.5.5 lsrid=5.5.5.5
[admin@R5] >mpls ldp interface add interface=s0
[admin@R6] >mpls ldp set enabled=yes transport-address=6.6.6.6 lsrid=6.6.6.6
[admin@R7] >mpls ldp interface add interface=s1
[admin@R7] >mpls ldp set enabled=yes transport-address=7.7.7.7 lsrid=7.7.7.7
[admin@R7] >mpls ldp interface add interface=s2
Проверим LDP-соседей командой mpls ldp neighbor print. Маршрутизатор
R4 выдаёт такие транспортные адреса соседей: 5.5.5.5, 6.6.6.6 и 7.7.7.7. И R5 и R6 и
R7 выдают адрес 4.4.4.4.
6. Настроим BGP. Мы отражателем маршрутов назначим маршрутизатор R5.
Настроим BGP сессии к отражателю от остальных внутренних маршрутизаторов
R4, R6 и R7. В качестве источника обновлений возьмём интерфейс-петлю bridge1.
В качестве адреса удалённого пира используем адрес его интерфейса-петли.
Предварительно проверьте доступность remote-address.
[admin@R5] >routing bgp instance set 0 client-to-client-reflection=yes
[admin@R5]>routing bgp peer add remote-address=4.4.4.4 remote-as=65530
update-source=bridge1 route-reflect=yes
[admin@R5]>routing bgp peer add remote-address=6.6.6.6 remote-as=65530
update-source=bridge1 route-reflect=yes
[admin@R5]>routing bgp peer add remote-address=7.7.7.7 remote-as=65530
update-source=bridge1 route-reflect=yes
[admin@R4] >routing bgp instance set 0 client-to-client-reflection=no
[admin@R4]>routing bgp peer add remote-address=5.5.5.5 remoteas=65530update-source=bridge1 route-reflect=no
[admin@R6] >routing bgp instance set 0 client-to-client-reflection=no
[admin@R6]>routing bgp peer add remote-address=5.5.5.5 remote-as=65530
update-source=bridge1 route-reflect=no
[admin@R7] >routing bgp instance set 0 client-to-client-reflection=no
[admin@R7]>routing bgp peer add remote-address=5.5.5.5 remote-as=65530
update-source=bridge1 route-reflect=no
Для R4, R5, R6 и R7 в winbox должно начать изменятся время BGP-сессии
в поле routing bgp peer Uptime. Обязательно проверьте. Если это поле пустодальнейшая работа бессмыслена. Проверьте маршрутизацию.
Переходим к топологии на рис. 17.2, добавьте компьютеры R10, R11, R12 и
R13 к существующей топологии и дайте им имена. Проверьте соседей у новых
компьютеров и назначьте адреса на тап-интерфейсы. Сохраните проект MPLS и
сделайте две копии: BGPVPLS и BGPVRF.
235
grigoryev.victor@gmail.com http://vmg.pp.ua
Создадим VPN уровня 2 типа BGP VPLS. Откроем проект BGPVPLS. На R4,
R5, R6 и R7 с помощью коменды interface bridge add name=vpls создадим мосты
с именем vpls и добавим в каждый из них интерфейсы, идущие в сторону
компьютеров
R10, R11, R12 и R13 локальных сетей филиалов: interface
bridge port add bridge=vpls interface=ether2. Назначим на компьютеры R10, R11,
R12 и R13 адреса согласно варианту. Для варианта V=0 имеем(рис. 17.4).
Рис. 17.4 Топология BGPVPLS
[admin@R10] >ip address add address=172.16.200.1/24 interface= ether1
[admin@R11] >ip address add address=172.16.200.2/24 interface= ether1
[admin@R12] >ip address add address=172.16.200.3/24 interface= ether1
[admin@R13] >ip address add address=172.16.200.4/24 interface= ether1
Установим для BGP-сессий семейства адресов l2vpn
[admin@R4]>routing bgp peer set 0 address-families=l2vpn
[admin@R5]>routing bgp peer set 0,1,2 address-families=l2vpn
[admin@R6]>routing bgp peer set 0 address-families=l2vpn
[admin@R7]>routing bgp peer set 0 address-families=l2vpn
Для настройки VPLS BGP выполните команды
[admin@R4]>interface vpls bgp-vpls add bridge= vpls bridge-horizon=1 routedistinguisher=4.4.4.4:1
site-id=4
export-route-targets=4:1
import-routetargets=5:1,6:1,7:1
[admin@R5]>interface vpls bgp-vpls add bridge= vpls bridge-horizon=1 routedistinguisher=5.5.5.5:1
site-id=5
export-route-targets=5:1
import-route236
grigoryev.victor@gmail.com http://vmg.pp.ua
targets=4:1,6:1,7:1
[admin@R6]>interface vpls bgp-vpls add bridge= vpls bridge-horizon=1 routedistinguisher=6.6.6.6:1
site-id=6
export-route-targets=6:1
import-routetargets=4:1,5:1,7:1
[admin@R7]>interface vpls bgp-vpls add bridge= vpls bridge-horizon=1 routedistinguisher=7.7.7.7:1
site-id=7
export-route-targets=7:1
import-routetargets=4:1,5:1,6:1
Проверим на маршрутизаторах R4, R5, R6 и R7 LDP-соседей командой mpls
ldp neighbor print. Видим, что каждый является соседом каждого.
На каждом маршрутизаторе автоматически создадутся по три VPLSинтерфейса, например
[admin@R4] > /interface vpls print
Flags: X - disabled, R - running, D - dynamic, B - bgp-signaled, C - cisco-bgp-signaled
0 RDB name="vpls1" mtu=1500 l2mtu=1500 mac-address=02:6E:3C:4F:4A:E0
arp=enabled disable-running-check=no remote-peer=5.5.5.5 cisco-style=no ciscostyle-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes
vpls=bgp-vpls1
1 RDB name="vpls2" mtu=1500 l2mtu=1500 mac-address=02:EE:3A:22:7B:CD
arp=enabled disable-running-check=no remote-peer=6.6.6.6 cisco-style=no ciscostyle-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes
vpls=bgp-vpls1
2 RDB name="vpls3" mtu=1500 l2mtu=1500 mac-address=02:3A:0B:F0:4A:C0
arp=enabled disable-running-check=no remote-peer=7.7.7.7 cisco-style=no ciscostyle-id=0 advertised-l2mtu=1500 pw-type=raw-ethernet use-control-word=yes
vpls=bgp-vpls1
Проверьте командой interface bridge port print, что эти интерфейсы
добавились в мост vpls.
Устройства R10, R11, R12 и R13 видят друг друга как соседи, например
[admin@R10] > ip neighbor pr
# INTERFACE ADDRESS
MAC-ADDRESS
IDENTITY VERSION BOARD
5 ether1 172.16.200.2
00:AA:00:92:A8:00
R11
5.5
x86
8 ether1 172.16.200.3
00:AA:00:2C:6B:00
R12
5.5
x86
10 ether1 172.16.200.4
00:AA:00:76:48:00
R13
5.5
x86
Проверьте, что устройства R13, R12, R10 и R11 пингуют друг друга по MACадресам и адресам (V=0) 172.16.200.1 172.16.200.2 172.16.200.3 172.16.200.4.
VPN уровня 2 типа BGP VPLS настроена.
8. Создадим VPN уровня 3 типа BGP VRF. Откроем проект BGPVRF.
Назначим во внутренних маршрутизаторах адреса на интерфейс ether2, идущий в
сторону компьютера локальной сети филиала. Для варианта V=0 имеем (рис. 17.5)
[admin@R4] >ip address add address=172.16.1.1/24 interface=ether2
[admin@R6] >ip address add address=172.16.2.1/24 interface=ether2
[admin@R7] >ip address add address=172.16.3.1/24 interface=ether2
[admin@R5] >ip address add address=172.16.4.1/24 interface=ether2
237
grigoryev.victor@gmail.com http://vmg.pp.ua
Рис. 17.5. Топология BGPVRF
Установим для BGP-сессий семейства адресов vpnv4
[admin@R4]>routing bgp peer set 0 address-families= vpnv4
[admin@R5]>routing bgp peer set 0,1,2 address-families= vpnv4
[admin@R6]>routing bgp peer set 0 address-families= vpnv4
[admin@R7]>routing bgp peer set 0 address-families= vpnv4
Используем сокращённую настройку VRF. Поместим в R4, R5, R6 и R7
интерфейс ether2, идущий в сторону локальной сети филиала в VRF с routedistinguisher
2:2 и назначим маркер маршрутов rm. Это осуществляется
командой
ip route vrf add routing-mark= rm interfaces= ether2 route-distinguisher=2:2
import-route-targets=2:2 export-route-targets=2:2
Укажем BGP в R4, R5, R6 и R7, что VRF с идентификатором 2:2 будут
участвовать в маршрутизации для семейства адресов vpnv4 с перераспределением
присоединённых маршрутов. Это осуществляется командой
routing bgp instance vrf add routing-mark=rm redistribute-connected=yes
Посмотрим на маршруты. Например для R4
[admin@R4] >ip route print detail where routing-mark=rm
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
0 ADC dst-address=172.16.1.0/24 pref-src=172.16.1.1 gateway=vrf gatewaystatus=vrf reachable distance=0 scope=10 routing-mark=rm
238
grigoryev.victor@gmail.com http://vmg.pp.ua
1 ADb dst-address=172.16.2.0/24 gateway=6.6.6.6 gateway-status=6.6.6.6 recursive
via 172.16.0.3 c1 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
2 ADb dst-address=172.16.3.0/24 gateway=7.7.7.7 gateway-status=7.7.7.7 recursive
via 172.16.0.5 c2 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
3 ADb dst-address=172.16.4.0/24 gateway=5.5.5.5 gateway-status=5.5.5.5 recursive
via 172.16.0.1 c0 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
[admin@R4] >routing bgp vpnv4-route pr
Flags: L - label-present
# ROUTE-DISTINGUISHER
DST-ADDRESS
GATEWAY IN..
0 L 2:2
172.16.2.0/24
6.6.6.6
c1
1 L 2:2
172.16.3.0/24
7.7.7.7
c2
2 L 2:2
172.16.4.0/24
5.5.5.5
c0
3 L 2:2
172.16.1.0/24
vrf
[admin@R5] >ip route print detail where routing-mark=rm
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
0 ADb dst-address=172.16.1.0/24 gateway=4.4.4.4
gateway-status=4.4.4.4
recursive via 172.16.0.2 s0 distance=200 scope=40 target-scope=30 routingmark=rm
bgp-local-pref=100
bgp-origin=incomplete
bgp-extcommunities="RT:2:2"
1 ADb dst-address=172.16.2.0/24 gateway=6.6.6.6 gateway-status=6.6.6.6 recursive
via 172.16.0.2 s0 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
2 ADb dst-address=172.16.3.0/24 gateway=7.7.7.7 gateway-status=7.7.7.7 recursive
via 172.16.0.2 s0 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
3 ADC dst-address=172.16.4.0/24 pref-src=172.16.4.1 gateway=vrf gatewaystatus=vrf reachable distance=0 scope=10 routing-mark=rm
[admin@R5] >routing bgp vpnv4-route pr
Flags: L - label-present
# ROUTE-DISTINGUISHER DST-ADDRESS GATEWAY IN..
0 L 2:2
172.16.1.0/24
4.4.4.4
s0
1 L 2:2
172.16.2.0/24
6.6.6.6
s0
2 L 2:2
172.16.3.0/24
7.7.7.7
s0
3 L 2:2
172.16.4.0/24
vrf
[admin@R6] >ip route print detail where routing-mark=rm
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
0 ADb dst-address=172.16.1.0/24 gateway=4.4.4.4 gateway-status=4.4.4.4 recursive
via 172.16.0.4 s1 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref= bgp-origin=incomplete bgp-ext-communities="RT:2:2"
239
grigoryev.victor@gmail.com http://vmg.pp.ua
1 ADC
dst-address=172.16.2.0/24 pref-src=172.16.2.1 gateway=vrf gatewaystatus=vrf reachable distance=0 scope=10 routing-mark=rm
2 ADb dst-address=172.16.3.0/24 gateway=7.7.7.7 gateway-status=7.7.7.7 recursive
via 172.16.0.4 s1 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
3 ADb dst-address=172.16.4.0/24 gateway=5.5.5.5 gateway-status=5.5.5.5 recursive
via 172.16.0.4 s1 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
[admin@R6] >routing bgp vpnv4-route pr
Flags: L - label-present
#ROUTE-DISTINGUISHER DST-ADDRESS GATEWAY IN..
0 L 2:2
172.16.1.0/24
4.4.4.4
s1
1 L 2:2
172.16.3.0/24
7.7.7.7
s1
2 L 2:2
172.16.4.0/24
5.5.5.5
s1
3 L 2:2
172.16.2.0/24
vrf
[admin@R7] >ip route print detail where routing-mark=rm
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
0 ADb dst-address=172.16.1.0/24 gateway=4.4.4.4 gateway-status=4.4.4.4 recursive
via 172.16.0.6 s2 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
1 ADb dst-address=172.16.2.0/24 gateway=6.6.6.6 gateway-status=6.6.6.6 recursive
via 172.16.0.6 s2 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
2 ADC dst-address=172.16.3.0/24 pref-src=172.16.3.1 gateway=vrf gatewaystatus=vrf reachable distance=0 scope=10 routing-mark=rm
3 ADb dst-address=172.16.4.0/24 gateway=5.5.5.5 gateway-status=5.5.5.5 recursive
via 172.16.0.6 s2 distance=200 scope=40 target-scope=30 routing-mark=rm bgplocal-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:2:2"
admin@R7] >routing bgp vpnv4-route pr
Flags: L - label-present
#ROUTE-DISTINGUISHER DST-ADDRESS GATEWAY IN..
0 L 2:2
172.16.1.0/24
4.4.4.4
s2
1 L 2:2
172.16.2.0/24
6.6.6.6
s2
2 L 2:2
172.16.4.0/24
5.5.5.5
s2
3 L 2:2
172.16.3.0/24
vrf
Видим, что маршруты на сети 172.16.1.0/24 172.16.2.0/24 172.16.3.0/24
172.16.4.0/24 присутствуют во всех маршрутизаторах R4, R5, R6 и R7.
9. Назначим адреса на компьютеры, согласно варианту R10172.16.1+4*V.2/24, R11-172.16.2+4*V.2/24, R12-172.16 .3+4*V+2.2/24, R13-172.16 .
4+4*V.2/24. Для V=0 имеем
[admin@R10] >ip address add address=172.16.1.2/24 interface=ether1
[admin@R11] >ip address add address=172.16.2.2/24 interface=ether1
[admin@R12] >ip address add address=172.16.3.2/24 interface=ether1
240
grigoryev.victor@gmail.com http://vmg.pp.ua
[admin@R13] >ip address add address=172.16.4.2/24 interface=ether1
Для каждого компьютера проверьте связь по IP к маршрутизатору и затем
пропишите шлюзы
[admin@R10] >ip route add gateway=172.16.1.1
[admin@R11] >ip route add gateway=172.16.2.1
[admin@R12] >ip route add gateway=172.16.3.1
[admin@R13] >ip route add gateway=172.16.4.1
Теперь R10, R11, R12 и R13 видят друг друга по адресам 172.16.1.2,
172.16.2.2 172.16.3.2 172.16.4.2. То есть MPLS VRF VPN уровня 3 функционирует.
В отличие от VPN 2 Устройства R10, R11, R12 и R13 не видят друг друга как
соседи, а видят только физически присоединённые устройства, например
[admin@R10] > ip neighbor pr
# INTERFACE ADDRESS MAC-ADDRESS
IDENTITY VERSION
BOARD
0 ether1 172.16.1.1
00:AA:00:C2:5C:01
R4
5.5
x86
1 ether1 10.0.10.1
52:54:00:12:34:5C
R10
5.5
x86
2 ether7 172.16.1.1
00:AA:00:C2:5C:01
R4
5.5
x86
3 ether7 172.16.1.2
00:AA:00:23:42:00
R10
5.5
x86
Быстрый старт
Действующие резервные копии топологий BGPVRF и BGPVPLS
расположены на сайте eom.pp.ua (labs.mikrotik.com.ua). Начните работу над
курсовым проектом с изучения этих работающих конфигураций.
При восстановлении из резервных копий, используйте свои тап-интерфейсы
и рекомендуемые адреса для них. Это приведёт к необходимости редактировать
настройки, особенно во внешних маршрутизаторах R0, R1, R2 и R3.
Конфигурации содержат сертификаты, которые не восстанавливаются.
Следует создать сертификаты и импортировать их в маршрутизаторы до
восстановления всей конфигурации. Далее обязательно надо проверить сетевые
настройки для SSTP в которых фигурируют сертификаты.
Требование к отчёту и порядок сдачи проекта.
Отчёт должен содержать два скриншота топологий типа рис. 17.4 и 17.5,
адаптированных к своему варианту. Программу для выполнения скриншота
находится в меню Applications-Accessories-TakeScreeshot.
Текст отчёта повторяет вышеизложенный материал с адаптацией к своему
варианту. В отчёте все результаты команд вывода типа ip address print должны
быть текстовыми скриншотами реального вывода этих команд в консоли RouterOS
для работающего проекта согласно своего варианта. Текстовые скриншоты
создаются в консоли RouterOS с помощью мыши по технологии CopyPaste.
Для сдачи курсового проекта следует предъявить работающие топологии
BGPVPLS и BGPVRF. Эти проекты должны находится в вашей папке в Ubuntu на
сайте eom.pp.ua (labs.mikrotik.com.ua).
241