Віртуальна лабораторія з комп’ютерних мереж
Віртуальна лабораторія з комп'ютерних мереж
Вибір платформи віртуальної лабораторії
Мережеві маршрутизатори працюють під управлінням операційних систем. У ряді випадків ці операційні системи можна запустити всередині віртуальних машин. Мережеві пристрої у мережі з'єднані каналами зв'язку. Для організації віртуальної мережевої лабораторії треба з'єднати між собою віртуальні машини, у яких запущені операційні системи мережевих пристроїв.
На лабораторному занятті у такій віртуальній лабораторії з комп'ютерних мереж зазвичай присутній десяток студентів, і з них вивчає мережеву топологію, що з кількох мережевих пристроїв. Водночас працюють десятки віртуальних машин. Виникає завдання такого вибору операційної системи мережевого пристрою та віртуальної машини, щоб забезпечити студентам комфортну одночасну роботу за умови обмеженості ресурсів хост-комп'ютера.
Ідея віртуальних мережевих лабораторій не є новою, і для їх реалізації існують спеціалізовані рішення. Для моделювання пристроїв фірми Cisco, що працюють під керуванням операційної системи IOS, використовуються програми Cisco Packet Tracer і Boson NetSim, що мають зручний графічний інтерфейс, що дозволяє швидко створювати складні мережеві топології. Проте вбудована у них урізана версія IOS дозволяє вивчати лише мережні технології початкового рівня.
Найбільший інтерес становить використання операційних систем реальних мережевих пристроїв. Виникають такі питання, що стосуються вибору операційної системи пристрою та віртуальної машини для запуску цієї операційної системи: скільки ресурсів хост-машини споживає віртуальна машина; який час запуску операційної системи усередині віртуальної машини; які коштинадають віртуальні машини для з'єднання між собою запущених усередині них операційних систем та як швидко створити складну мережеву топологію з десятків пристроїв.
Для моделювання мережевих топологій широко використовують контейнер віртуальних машин GNS3. Для створення мережевих топологій GNS3 використовується технологія Drug-and-Drop: зачепив пристрій мишею і перетягнув його на робоче поле. GNS3 підтримує дві віртуальні машини: Dynamips та Qemu. Вибір саме цих машин для включення в GNS3 обумовлений наявністю в їхньому складі розвинених засобів для з'єднання між собою операційних систем.
Віртуальна машина Dynamips дозволяє запустити в собі реальну IOS для дуже широкого класу пристроїв Cisco. Однак під час роботи з Dynamips слід підбирати параметри зменшення навантаження на центральний процесор. Без належних налаштувань Dynamips використовує всі ресурси комп'ютера для топології з трьох маршрутизаторів.
Під Qemu працює вельми широкий клас мережевих, вбудованих та мобільних операційних систем: Juniper JunOS, Vyatta, Openwrt, Google Android, Mikrotik RouterOs, фаєрволи Cisco IDS та ін. Наш вибір був зроблений на користь 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 у складі GNS3 під керуванням Ubuntu виявилася найкращим вибором для організації віртуальної лабораторії.
Визначимо операційну систему мережного пристрою для запуску Qemu. Якщо вимагати, щоб пристрій підтримував мережну технологію MPLS, вибір відразу скоротиться: це або операційна система JunOS фірми Juniper, або RouterOS фірми Mikrotik.
За обсягом споживаних ресурсів JunOS значно перевищує RouterOS. Наприклад, на процесорі з частотою 2.4 ГГц час завантаження RouterOS версії 5.5 в Qemu під Ubuntu становить 6 (шість) секунд, а JunOS версії 10.1R1.8 вантажиться 80 секунд. При вимкненій підтримці KVM час завантаження був удвічі більшим. RouterOS вимагає мінімум 64 Мб пам'яті, JunOS - 512 Мб. Образ диска RouterOS – 40 Мб, JunOS – 2.6 Гб.
Qemu в Ubuntu під управлінням гіпревізора HYPER-V працює дещо повільніше, ніж Qemu в Ubuntu на реальному комп'ютері. Це зумовлено, зокрема, і тим, що апаратний прискорювач KVM не працює на віртуальній апаратурі Hyper-V. Так час завантаження RouterOS у Qemu під Ubuntu у HYPER-V склала 12 секунд проти 6 секунд у Qemu під Ubuntu на реальному процесорі частотою 2.4 ГГц. Хост-комп'ютер HYPER-V має 8-ядерний процесор Intel Core i7 950 3066 МГц.
Багатоядерність процесорів зменшує час завантаження кількох екземплярів RouterOs під керуванням Qemu. Так час завантаження 10 екземплярів RouterOS на реальному 2-х ядерному процесорі частотою 2.4 ГГц. та віртуальному 4-х ядерномупроцесорі HYPER-V виявилося однаковим і рівним 30 секунд.
Число одночасно працюючих екземплярів RouterOs під Qemu визначається вільною пам'яттю хост-машини. Так виділення для Ubuntu під HYPER-V 8 Гб пам'яті дозволило запустити сто екземплярів RouterOs. При 4-х віртуальних процесорах час завантаження становив 300 секунд.
Операційна система RouterOs підтримує майже всі сучасні мережеві технології. Це дозволило розробити лабораторний практикум для вивчення наступних мережевих технологій: Ethernet-мости, DHCP, балансування навантаження, EoIP, NAT, маршрутизація RIP, OSPF та BGP, перерозподіл маршрутів, PPP, PPTP, SSTP, L2TP, OpenVPN, віртуальні приватні мережі2 та 3-го рівня, IPSec, MPLS, VPLS, VRF. Видається нереальною комплектація навчальної лабораторії вузу реальним мережевим обладнанням, що дозволяє практично освоїти перераховані мережеві технології. З лабораторним практикумом можна ознайомитись на сайті http://lib.dnu.dp.ua.
Образ настановного CD операційної системи RouterOs знаходиться на сайті фірми Mikrotik у вільному доступі, але має одне обмеження - час безперервної роботи становить одну добу. Цієї доби вистачає користувачеві на кілька лабораторних занять. Після закінчення терміну користувачі повинні зберегти налаштування операційних систем RouterOs і мережеву топологію лабораторної роботи, запустити збережену топологію без налаштувань і відновити налаштування RouterOs. Написані скрипти, які з'єднуються за допомогою протоколу ssh із пристроями в топології, надсилають до пристроїв команди для створення або відновлення резервних копій і завантажують або вивантажують ці копії. Встановлювати при цьому операційну систему RouterOs не треба. Це пояснюється тим, що при першому старті кожного пристрою втопології GNS3 створює йому копію образу диска заздалегідь встановленої операційної системи та змінює оригінал.
Місце лабораторії у мережі університету
port 8002 клієнти підключаються до цього порту
proto tcp за цим протоколом
dev tun у режимі маршрутизації
ca ca.crt для них здійснюється
cert lib.crt перевірка
key lib.key сертифікатів
tcp-nodelay Скасувати алгоритм Nagle (трохи швидше)
push "route 10.5.0.0 255.255.0.0" та маршрут у бік мережі 10.5.0.0/16
Підключення до лабораторії за допомогою протоколу Openvpn
Ми здійснимо налаштування клієнтської частини Openvpn для доступу з кафедрального комп'ютера до лабораторії в аудиторії 12/310 лише як проба та тренування. Отримані навички слід використовувати для підключення 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 lib.dnu.dp.ua. Помилка не підключена до host, на port 8002: Connect failed
За наявності служби ви побачите чистий чорний екран. У разі невдачі – зверніться до викладача для перевірки мережевих налаштувань та правил фаєрволу.
Openvpn вже встановлений на кафедральній віртуальній машині v-SRV. Зайдіть туди віддалено. Отримайте у викладача
конфігурацію client.ovpn кореневий сертифікат ca.crt свій сертифікат studentN.crt і ключ до нього studentN.key Тут N-Ваш номер
Ці 4 файли кладемо в папку Openvpn\config і змінюємофайл конфігурації client.ovpn 2 рядки cert ***.crt і key ***.key на рядки cert studentN.crt key studentN.key
Приклад файлу конфігурації client.ovpn для студента №5 (N=5)
dev-node ovpn – Вказуємо ім'я tap-інтерфейсу для OpenVPN.