Идея создания сетевой тестовой среды возникла когда пришла необходимость запускать и отлаживать устройства с IPsec и GRE протоколами. С похожими проблемами сталкивались и разработчики strongSwan. Проблема была с прогоном unit тестов. Они приготовили виртуальную сеть на базе UML (user mode linux). В этом документе описано в общих чертах, что это такое и как работает. Подносить виртуальную сеть под UML буду при первой возможности, a на первом этапе тестовая среда была поднята на QEMU и на дистрибуциях приготовленных под YOCTO. Итак даная статья описывает: как создать свою дистрибуцию linux, поднять и настроить несколько инстанций QEMU, настроить виртуальную сеть и как пример поставить GRE туннель. Получается очень полезная штука для отладки и тестирования маршрутизаторов. Так, что всех заинтересованных приглашаю ниже.
В качестве Host использовалась дистрибуция Ubuntu.
Linux 4.10.0-28-generic #32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Готовим дистрибуцию linux
Итак сначала подготовим дистрибуцию linux для виртуальных машин. Для этого используем систему сборки YOCTO. Дистрибуция получается лёгкая, а также даёт возможность конфигурации/компиляции ядра и установки дополнительных пакетов. Ещё один плюс, это кросс-платформенность дистрибуции linux. Потренировавшись на виртуальных сборках можем переносить дистрибуцию на встраиваемые системы. Подготовка дистрибуции может занять около часа или двух. Готовые сборки можно взять здесь.
Необходимые инструменты
$sudo apt-get install chrpath gawk texinfo python
Возможно потребуется ещё кое-что.
a) Установка yocto
$mk yocto
$cd yocto
$git clone -b pyro git://git.yoctoproject.org/poky.git
$git clone -b pyro git://git.openembedded.org/meta-openembedded
$source ./poky/oe-init-build-env
б) Правка конфигурационных файлов
Рабочий каталог будет «yocto/ build»
Поправим установки.
В файле conf/bblayers.conf поправляем
BBLAYERS ?= " \
/home/user/yocto/poky/meta \
/home/user/yocto/poky/meta-poky \
/home/user/yocto/poky/meta-yocto-bsp \
/home/user/yocto/meta-openembedded/meta-oe \
/home/user/yocto/meta-openembedded/meta-networking \
/home/user/yocto/meta-openembedded/meta-webserver \
/home/user/yocto/meta-openembedded/meta-python \
/home/user/yocto/meta-openembedded/meta-multimedia \
"
Устанавливаем некоторые полезные пакеты. В файле /conf/local.conf
# We default to enabling the debugging tweaks.
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
CORE_IMAGE_EXTRA_INSTALL = " \
kernel-modules \
lrzsz \
setserial \
strongswan \
opkg \
nbench-byte \
lmbench \
alsa-utils \
i2c-tools \
devmem2 \
dosfstools \
libdrm-tests \
netkit-ftp \
iproute2 \
iptables \
bridge-utils \
socat \
wget \
curl \
vlan \
dhcp-server \
dhcp-client \
ntp \
libstdc++ \
nginx \
ppp \
proftpd \
boost \
openssl \
openssh \
fcgi \
mc \
ethtool \
minicom \
procps \
tcpdump \
file"
Дополнительно надо поправить файл конфигурации sshd «yocto/poky/meta/recipes-connectivity/openssh/openssh/sshd_config».
# override default of no subsystems
#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp
Эта поправка необходима для того, чтобы не устанавливать дополнительный сервер sftp. Используется он при монтировании файл-системы через ssh.
в) Запуск сборки
$bitbake core-image-minimal
Необходимо подождать.
Если сборка закончилась успехом, то на выходе получаем:
rootfs - /yocto/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170803162854.rootfs.ext4
kernel - /yocto/build/tmp/deploy/images/qemux86/bzImage—4.10.17+git0+e92bd55409_6648a34e00-r0-qemux86-20170801184648.binСистемы сборки определяет, что изменялось и дописывает файлы с отпечатком времени в названии файла. На самые последние версии указывают линки.
«bzImage»
«core-image-minimal-qemux86.ext4»г) Проверяем сборку
Устанавливаем qemu для платформы хоста. В данном случае это x86 64 бита.
$sudo apt-get install qemu-system-x86
$qemu-system-x86_64 --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.34), Copyright (c) 2003-2008 Fabrice Bellard
Запускаем qemu.
$cd ~/yocto/build/tmp/deploy/images/qemux86
$qemu-system-x86_64 -hda ./core-image-minimal-qemux86.ext4 -kernel ./bzImage -append "console=ttyS0 root=/dev/hda initrd=/initrd" -nographic
Если видим следующую картинку то виртуальная машина встала.
Конфигурация виртуальной сети
Скрипты и установки находятся здесь https://github.com/framer/test-net.
а) Создание схемы сети
Для наглядности создадим схему виртуальной сети.
H1,H2,R1,R2 — Виртуальные машины.
BR0,BR1,BR2,BR3 — Виртуальные коммутаторы.
Каждая виртуальная машина имеет интерфейс управления (eth0) подключенный к коммутатору BR0. Также создаём сеть 192.168.40.0/24. Эти интерфейсы и сеть будут использоваться для установок и управления.
б) Установка виртуальных коммутаторов
Сначала поставим виртуальные коммутаторы к которым будут подключаться интерфейсы TAP виртуальных машин. Установим несколько виртуальных коммутаторов для разных сегментов сетей. Установить можно так:
$cd ./src
$sudo ./setup_bridge.sh 4
$ip link
Для коммутатора BR0 припишем адрес управления и включаем передачу пакетов между интерфейсами.
$ip addr add 192.168.40.1/24 dev br0
$sysctl -w net.ipv4.ip_forward=1
в) Файл установок «conf.json»
Файл установок приготовлен согласно с схемой. Если, что либо надо изменить или дополнить, то необходимо отредактировать этот файл. В этом файле установки интерфейсов и адресов управления. Установка адресов тестируемой сети будет после запуска виртуальных машин.
г) Создание инстанций виртуальных машин
Сначала копируем созданное предварительно ядро и корневую файл систему, в каталог «src».
Название файлов следующее:
bzImage — ядро
rootfs — корневая файл система.
Если кто-то не имеет своей дистрибуции то готовые сборки можно взять здесь.
Для создания инстанций используется скрипт «create_network.py».
$./create_network.py
Скрипт создаёт инстанции виртуальных машин. Так как ещё нет конфигурации сети управления, то нет доступа к виртуальной машине через сеть. Скрипт запускает виртуальные машины в режиме перехвата потоков ввода/вывода и делает установку сети управления.
После отработки скрипта создаются каталоги для каждой виртуальной машины.
$ls .. -Al
д) Запуск среды
Для запуска среды делаем так:
$sudo ./run_network.py
Запускаем под sudo, так как машины создаю интерфейсы tap. Машины работают в background. Стандартная консоль пишется в файл «output.log».
Доступ к машинам осуществляется через ssh. Существует одна проблема. Если мы будем создавать среду заново, то при запуске машины для ssh будут генерироваться заново ключи. Хост определит, что под теми самыми адресами работает машина с другими ключами и начнёт ругаться. В этом случае необходимо почистить файл «.ssh/known_hosts».
После того как машины встали можно подмонтировать корневые файл системы.
$./mount_fs.py
Подмонтированные файл системы находятся в каталогах H1/tmp, H2/tmp, R1/tmp, R2/tmp.
е) Установка параметров сети
После запуска среды, виртуальные машины имеют установленную только сеть управления. Установить остальные параметры сети согласно со схемой, для всех машин сразу, можно запустив скрипт:
$cd ../scripts
$./static.sh
static.sh — пример сети со статической маршрутизацией.
Теоретически сеть настроена.
Диагностика сети. Диагностику сети можно производить на каждом виртуальном коммутаторе.
Подключимся к H1 через ssh.
На H1 запустим ping на H2.
root@H1:~# ping 192.168.51.10
На host запустим диагностику
$ sudo tcpdump -i br2
ф) Остановка сети
Для остановки и отмонтирования файл системы запустим.
$sudo ./stop_network.py
Конфигурация GRE
а) Поправим схему сети
б) Запуск среды и установка среды
$sudo run_network.py
Подождать и подмонтировать файл системы.
$mount_fs.py
Установить параметры среды
$cd ../scripts
$./gre.sh
в) Диагностика сети
Подключимся к H1 через ssh.
На H1 запустим ping на H2.
root@H1:~# ping 192.168.51.10
На host запустим
$ sudo tcpdump -i br2
Заключение
Зачем все это?
Во-первых. Тот кто работает над созданием маршрутизаторов задаётся вопросом. «А как он будет работать в реальных условиях?» И тут даная система приходит на помощь. Имея на хосте дополнительные сетевые карты можно подключить реальную карту к виртуальному коммутатору и заменить виртуальную машину на реальное устройство. Автоматизация создания среды позволяет готовить разные сценарии работы и проверять функциональность реального устройства.
Во-вторых. Наверное, для студентов.