Продолжение первой статьи цикла, в котором мы собираем полноценный стенд для изучения компьютерных сетей на базе Hyper-V, Ubuntu и GNS3.
В прошлый раз мы собрали стенд для изучения сетей на Hyper-V. Тогда мы установили GNS3, подняли GNS3 VM и виртуальную машину Ubuntu 26.04 LTS, подключили все к стандартному Default Switch и проверили связность между PC1 (VPCS) и Ubuntu.
В этой статье мы подготовим стабильную подсеть, а в следующей настроим Linux-маршрутизатор с NAT. Вместе они станут основой для дальнейшего развития стенда.
Для этого сегодня мы изменим топологию стенда и уйдем от Default Switch в Hyper-V. Затем скачаем и настроим шаблон Alpine через Docker, установленный внутри GNS3 VM.
Я считаю, что нужно один раз нормально настроить сетевую часть стенда и не касаться ее при добавлении новых устройств в будущем.
Архитектура стенда
Перед настройками необходимо спланировать саму сеть. Поэтому я покажу сразу всю архитектуру стенда с учетом ролей оборудования, которую мы получим после следующей статьи. В текущей части создадим новый сетевой сегмент, добавим интерфейсы и подключим Alpine. IP-адреса, маршрутизацию, DHCP и DNS настроим позже.
Архитектура стенда:
Схема получается достаточно сложной для восприятия, поэтому представлю ее в виде таблицы:
Устройство | Интерфейс | Коммутатор Hyper-V | IP-адрес | Роль |
|---|---|---|---|---|
Ubuntu 26.04 | eth0 | Default Switch | DHCP (как в первой статье) | Выход в интернет (WAN) |
Ubuntu 26.04 | eth1 (новый) | GNS3-Lab (Internal) | 192.168.50.1/24 | Шлюз, DHCP- и DNS-сервер стенда |
GNS3 VM | eth0 | Default Switch | DHCP | Управление GNS3 VM, интернет для самой ВМ (нужен, чтобы скачать образ Alpine из Docker Hub) |
GNS3 VM | eth1 (новый) | GNS3-Lab (Internal) | IP-адрес для работы стенда не потребуется | Точка входа топологии GNS3 в сеть стенда |
Alpine (узел в GNS3) | eth0 | — | 192.168.50.x/24 (DHCP или статически) | Первый узел стенда |
Хост Windows | vEthernet (GNS3-Lab) | — | DHCP от Ubuntu | Возможность достучаться до стенда прямо с хоста |
Для нашего сегмента я выбрал подсеть 192.168.50.0/24. Она не пересекается ни со стандартными диапазонами домашних роутеров (192.168.0.0/24 или 192.168.1.0/24), ни с диапазоном 172.x, который обычно использует NAT Default Switch. Если у вас уже есть сеть 192.168.50.0/24, возьмите любую другую свободную /24 из диапазона 192.168.0.0/16. На логику это не влияет, важно лишь одинаково заменить адрес сети при дальнейшей настройке.
Ключевая идея:
GNS3 VM получает второй сетевой адаптер, который используется только как «мост». Узел Cloud в топологии GNS3 привязывается к нему и отправляет трафик на новый коммутатор Hyper-V.
Именно так топология в первой статье и оказалась в одной подсети с Ubuntu, просто тогда мостом был единственный адаптер GNS3 VM, висевший на Default Switch.
Cloud – это специальный узел GNS3, который связывает виртуальную топологию с реальным сетевым интерфейсом сервера. Все, что приходит на этот интерфейс, попадает в топологию как обычный Ethernet-кадр. В нашем случае это будет виртуальный интерфейс Hyper-V.
Поскольку сервером у нас выступает GNS3 VM, в списке доступных для Cloud интерфейсов будут ее сетевые адаптеры eth0 и eth1.
Почему не Default Switch и не External
У Hyper-V есть три типа виртуальных коммутаторов:
External – привязан к физическому адаптеру, даёт доступ во внешнюю сеть;
Internal – трафик ходит между виртуальными машинами и самим хостом, но не выходит наружу;
Private – трафик ходит только между виртуальными машинами, хост в этот сегмент не включен.
Default Switch является частным случаем Internal-коммутатора с включенным NAT и DHCP, которым управляет сама Windows. После перезагрузки подсеть NAT изменяется. Мы вынуждены заново проверять адресацию и настраивать подключение к оборудованию.
Нам нужен Internal-коммутатор. С одной стороны, мы полностью управляем этим коммутатором и его адресацией. С другой стороны, он доступен с хоста, что удобно для диагностики. Про типы коммутаторов и их создание подробно написано в документации Microsoft.
Поехали настраивать.
Создаем отдельный виртуальный коммутатор Hyper-V
Все команды PowerShell выполняются от имени администратора.
Новый виртуальный коммутатор
Создаем новый виртуальный внутренний (internal) коммутатор GNS3-Lab командой:
New-VMSwitch -Name "GNS3-Lab" -SwitchType Internal -Notes "Изолированный сегмент для стенда GNS3"
Результат:
PS C:\Windows\system32> New-VMSwitch -Name "GNS3-Lab" -SwitchType Internal -Notes "Изолированный сегмент для стенда GNS3" Name SwitchType NetAdapterInterfaceDescription ---- ---------- ------------------------------ GNS3-Lab Internal PS C:\Windows\system32> Get-VMSwitch -Name "GNS3-Lab" Name SwitchType NetAdapterInterfaceDescription ---- ---------- ------------------------------ GNS3-Lab Internal PS C:\Windows\system32>
Перед изменением сетевых адаптеров рекомендую выключить обе машины командой:
Stop-VM -Name "<имя виртуальной машины>"
Результат (у меня они уже были выключены):
PS C:\Windows\system32> Stop-VM -Name "GNS3 VM" ПРЕДУПРЕЖДЕНИЕ: Виртуальная машина уже находится в указанном состоянии. PS C:\Windows\system32> Stop-VM -Name "Ubuntu-26.04" ПРЕДУПРЕЖДЕНИЕ: Виртуальная машина уже находится в указанном состоянии.
Добавить второй адаптер на виртуальную машину можно командой:
Add-VMNetworkAdapter -VMName "<имя виртуальной машины>" -SwitchName "<имя коммутатора>" -Name "<имя интерфейса>"
В моем случае:
Add-VMNetworkAdapter -VMName "GNS3 VM" -SwitchName "GNS3-Lab" -Name "Lab-Bridge" Add-VMNetworkAdapter -VMName "Ubuntu-26.04" -SwitchName "GNS3-Lab" -Name "LAN"
Базовые адаптеры eth0 обеих машин остаются подключенными к Default Switch. Они по-прежнему обеспечивают управление виртуальными машинами и выход во внешнюю сеть.
Запускаем GNS3 + GNS3 VM. Ubuntu пока можно не запускать.
Так как коммутатор Internal, Windows автоматически создаст на хосте виртуальный адаптер vEthernet (GNS3-Lab). Проверим, что он появился командой:
Get-NetAdapter | Where-Object { $_.Name -like "*GNS3-Lab*" }
В моем случае:
PS C:\Users\jetcry> Get-NetAdapter | Where-Object { $_.Name -like "*GNS3-Lab*" } Name InterfaceDescription ifIndex Status MacAddress LinkSpeed ---- -------------------- ------- ------ ---------- --------- vEthernet (GNS3-Lab) Hyper-V Virtual Ethernet Adapter #3 29 Up 00-15-5D-02-64-10 10 Gbps PS C:\Users\jetcry>
Чтобы устройства из GNS3 могли обмениваться трафиком с Ubuntu через новый интерфейс, включим подмену MAC-адресов на адаптере Lab-Bridge:
Set-VMNetworkAdapter ` -VMName "GNS3 VM" ` -Name "Lab-Bridge" ` -MacAddressSpoofing On
Проверим результат командой:
Get-VMNetworkAdapter -VMName "GNS3 VM" | Format-Table Name, SwitchName, MacAddress, MacAddressSpoofing
В моем случае:
PS C:\Windows\system32> Get-VMNetworkAdapter -VMName "GNS3 VM" | >> Format-Table Name, SwitchName, MacAddress, MacAddressSpoofing Name SwitchName MacAddress MacAddressSpoofing ---- ---------- ---------- ------------------ Сетевой адаптер Default Switch 00155D02640A On Lab-Bridge GNS3-Lab 00155D02640E On
Переходим к шаблону Alpine.
Заменяем VPCS на Alpine Linux
Почему Alpine
VPCS хорош для быстрой проверки IP-связности, но на нем нельзя поставить SSH-клиент, curl или любую другую утилиту. Сам по себе он является маленьким эмулятором конечного узла.
Alpine Linux – это уже полноценный дистрибутив на musl libc (стандартная библиотека C) и BusyBox, при этом очень компактный. Базовый образ занимает всего несколько мегабайт. У него есть пакетный менеджер apk, шелл ash и минимальный набор предустановленных сетевых утилит из BusyBox.
Ash – легкая командная оболочка, которая принимает и выполняет команды.
BusyBox – компактный набор основных Linux-утилит, объединенных в одном исполняемом файле. Благодаря этому Alpine занимает мало места и быстро запускается.
Официальный шаблон Alpine Linux для GNS3 (в том числе Docker-вариант) описан на странице appliance в маркетплейсе GNS3.
Для GNS3 есть два способа получить Alpine:
через QEMU-образ как полноценную виртуальную машину;
через Docker-контейнер, который выполняется прямо внутри GNS3 VM. Docker уже входит в состав образа GNS3 VM.
Второй вариант проще, быстрее стартует и весит меньше, поэтому используем его. Отмечу, что этот способ указан как штатный в документации GNS3 по Docker-контейнерам.
Добавляем шаблон Alpine в GNS3
Добавим Alpine в GNS3 как Docker-контейнер. Для этого переходим в Edit - Preferences - Docker - Docker containers - New. Выбираем в качестве сервера GNS3 VM.
Выбираем New image и указываем имя Docker-образа:
alpine:latest
Автоматически подтянется имя шаблона:
Указываем число адаптеров:
Указываем команду запуска:
sh
Вот так:
Тип консоли оставляем Telnet:
Следующее окно пропускаем, ничего не вводим:
Это поле будет нужно, если контейнеру надо передать специальные параметры при запуске. Например, логин/пароль для какого-то приложения внутри контейнера или настройки прокси.
Для alpine:latest как сетевого клиента это не требуется.
Нажимаем Finish.
Можно увидеть, как скачивается образ Alpine:
Pulling 'alpine:latest' from Docker repository Pulling image alpine:latest:55afa1ecc21d: [> ] 48.55kB/3.846MB Pulling image alpine:latest:55afa1ecc21d: [=====> ] 441.8kB/3.846MB Pulling image alpine:latest:55afa1ecc21d: [==============================================> ] 3.587MB/3.846MB Pulling image alpine:latest:55afa1ecc21d: [> ] 65.54kB/3.846MB Pulling image alpine:latest:55afa1ecc21d: [==================================================>] 3.846MB/3.846MB Pulling image alpine:latest:55afa1ecc21d: [==================================================>] 3.846MB/3.846MB Success pulling image alpine:latest
После этого шаблон Alpine появится в списке доступных устройств GNS3. Перетаскиваем его на рабочую область.
Добавляем в топологию узел Cloud и обязательно выбираем в качестве сервера GNS3 VM. После добавления он получит имя Cloud1. Подключаем Alpine к интерфейсу eth1 облака Cloud1:
Запускаем Alpine и открываем консоль:
alpine-PC-1 console is now available... Press RETURN to get started. / #
Команда help показывает команды, которые выполняет сама оболочка: cd, echo, export, pwd, exit, history и другие:
alpine-PC-1 console is now available... Press RETURN to get started. / # help Built-in commands: ------------------ . : [ [[ alias bg break cd chdir command continue echo eval exec exit export false fg getopts hash help history jobs kill let local printf pwd read readonly return set shift source test times trap true type ulimit umask unalias unset wait / #
Список утилит BusyBox можно посмотреть командой:
busybox --list
Проверим интерфейс eth0:
ip addr show eth0
В моем случае:
/ # ip addr show eth0 6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000 link/ether 02:42:c1:0d:ea:00 brd ff:ff:ff:ff:ff:ff inet6 fe80::42:c1ff:fe0d:ea00/64 scope link valid_lft forever preferred_lft forever / #
Видим, что интерфейс есть и находится в состоянии UP. IPv4-адрес пока не назначен.
Отмечу, что изменения внутри стандартного Docker-контейнера не сохранятся после удаления и создания нового экземпляра контейнера. Например, установленные через apk пакеты придется устанавливать заново. Для постоянной конфигурации позднее можно подготовить собственный Docker-образ с нужными утилитами или использовать стартовый скрипт, который автоматически настраивает контейнер после запуска. Если интересно, разберем это в качестве отдельной статьи.
Итоги
Мы создали отдельный виртуальный коммутатор Hyper-V специально под стенд.
Затем загрузили Docker-образ Alpine, создали шаблон контейнера и добавили новый узел в топологию GNS3.
В следующей статье настроим Ubuntu 26.04 как маршрутизатор с NAT, DHCP и DNS для устройств стенда. После этого Alpine и любые будущие узлы получат выход в интернет.
