_{Original file}

Контактные данные организации

NETSHe & GNS3

Примеры проектов

Контактные данные организацииВерсия 2.0

Апрель, 2020

ООО «Нетше Лаб» предлагает готовые тестовые проекты GNS3, их можно скачать по ссылке http://gw.stasoft.net/share/gns3/projects/ Все проекты содержат устройства под управлением операционной системы NETSHe и иллюстрируют основной eё функционал в простой форме.

Внимание! При переносе проектов с Linux на Windows и обратно следует учесть разницу исполняемых сред (Qemu внутри GNS VM машины на Linux или Qemu непосредственно на Linux). Следствием этого является использование разных интерфейсов для связи с сетями и объектами вне проекта GNS3.

Для подключения к Интернет и доступа к веб-интерфейсу устройства с NETSHe (WebUI, Web User Interface) проект содержит компонент Cloud. Для этого компонента надо изменить интерфейс в его настройках, на следующей картинке это показано для проекта, принесенного из Linux в Windows:

Пошаговые действия таковы:

1. - удалить линк, соединяющий Cloud c другим компонентом проекта, на котором желательно запомнить имя соединяемого порта,
2. - в контекстном меню Cloud выбрать Configure,
3. - в списке интерфейсов удалить virbr0 и добавить Ethernet,
4. - восстановить линк.

В остальном проекты, созданые в других экземплярах GNS3 и/или под управлением других операционных систем, могут быть запущены, отредактированы и без ограничений использоваться на новом компьютере.

В данном проекте всего два устройства, главное из которых NETSHe маршрутизатор. Тестовый компьютер PC1 получает свой IP-адрес от NETSHe, на котором поднят DHCP сервер.

Результат: с тестового компьютера доступны адреса в сети Интернет.

В данном примере два маршрутизатора NETSHe и два тестовых компьютера PC1 и PC2, получающих адреса DHCP от маршрутизаторов. Сами маршрутизаторы получают еще адреса по DHCP от платформы виртуализации, но эти адреса используются исключительно для доступа к веб-интерфейсам.

На обоих маршрутизаторах маршруты по умолчанию указывают на соседний маршрутизатор. Ниже показаны таблицы маршрутизации из консоли одного из маршрутизаторов, а другого маршрутизатора - из WebUI. Веб-интерфейс показан в браузере хостового компьютера.

В результате тестовые компьютеры доступны друг для друга, хотя каждый из маршрутизаторов не знает о локальной сети другого.

В данном примере два маршрутизатора NETSHe и два тестовых компьютера. PC1 и PC2 получают IP-адреса от своих маршрутизаторов, при этом их адреса из двух разных IP-подсетей 192.168.1.0/24 и 192.168.2.0/24.

Между маршрутизаторами настроен IPsec site-to-site, в политиках IPsec сети 192.168.1.0/24 и 192.168.2.0/24 зеркально указаны как удаленная и локальная сети соответственно. Таким образом трафик, адресованный другой сети, попадает в IPsec туннель. Политики IPsec показаны ниже из консоли и из WebUI соответственно:

Как результат PC1 и PC2, между которыми нет маршрутизации, потому что маршрутизаторы не имеют маршрутов в локальную сеть соседа, становятся доступны друг другу через туннель.

Обратите внимание на картинке, что

1. компьютеры не имеют выхода в Интернет, Cloud используется для доступа к WebUI устройств,
2. туннель поднимается по наличию трафика, в данном примере запуска ping от одного тестового компьютера к другому,
3. соединение между компьютерами устанавливается не с первого пакета, нужно время на поднятие туннеля,
4. После поднятия IPsec связь стабильная.

Участники примера аналогичны предыдущему, только трафик между PC1 и PC2 передается через туннель GRE.

Посредством WebUI cледует обратить внимание на параметры туннелей.

Все тот же состав устройств. RIP протокол используется для динамического построения таблиц маршрутизации обоих маршрутизаторов.

Cloud используется для доступа к WebUI, с помощью которого настраивать RIP удобнее, нежели с помощью консоли.

Результирующая таблица маршрутизации показывает локальные сети друг друга.

Аналогичный результат получается, если использовать OSPF.

Virtual Router Redundancy Protocol (VRRF) в данном примере используется для резервирования выхода в Интернет тестового PC1, подключенного в коммутатор LAN корпоративной сети. Два маршрутизатора NETSHe распределяют между собой роли главный-резервный в соответствие с протоколом VRRP. Cloud в данном примере используется для выхода в Интернет, а так же для доступа к веб-интерфейсам маршрутизаторов NETSHe.

Настройки VRRF удобнее смотреть из WebUI. Первый маршрутизатор помечен как «мастер» в схеме VRRF.

В результате, если один из маршрутизаторов отключить (мастер VRRF), то сеть Интернет по-прежнему доступна для тестового компьютера.

В данном примере NETSHe маршрутизаторы обеспечивают тестовому компьютеру выход в Интернет. В отличие от предыдущих примеров, построенных на использовании стандартных сетевых протоколов маршрутизации, в данном случае требуется чуть больше пояснить механизм выбора маршрутов.

На маршрутизаторе NETSHe в зоне WAN имеется два интерфейса:

Интерфейс eth4 - основной WAN интерфейс, у которого в настройках указан адрес компонета Checkpoint как адрес проверки связности. Checkpoint - это некий сетевой хост, расположенный на предполагаемом основном пути трафика, но не являющийся так называемым next hop, непосредственно присоединенным хостом. Система периодически проверяет доступность адреса для проверки связности с помощью echo-запросов ICMP. Если более 50% запросов не получают ответа, система делает вывод, что адрес проверки связности недоступен, а сеть на этом направлении имеет повреждение. После такого решения система удаляет из главной (main) таблицы маршрутизации все маршруты, где указан данный интерфейс и которые не адресованы непосредственно присоединенным сетям. В последствие проверка связности продолжается, и, при наличии более 50% ответов от адреса проверки связности, ранее удаленные маршруты возвращаются в таблицу, а трафик возвращается на основной путь.

Интерфейс eth0 является резервным WAN, что и указано в его настройках на картинке ниже. Эта опция сообщает системе, что маршрут по умолчанию, идущий через этот интерфейс, является резервным, а значит, он должен быть записан в резервную (default) таблицу маршрутизации. Когда система примет решение о недоступности адреса проверки связности сети и отключит маршруты через основной канал, закономерно заработает маршрут по умолчанию из резервной таблицы маршрутизации, т.е. трафик пойдет по резервному каналу.

Погасим Checkpoint и убедимся, что трафик тестового компьютера в Интернет идет через резервный WAN порт маршрутизатора NETSHe.

Dynamic Multipoint Virtual Private Network (DM VPN) используется для построения динамических VPN сетей, когда статический публичный IP-адрес имеет только «главный» Hub маршрутизатор. Spoke маршрутизаторы могут перемещаться и иметь динамически выданные публичные IP-адреса, а в реализации DM VPN на NETSHe даже могут располагаться за NAT.

В данном примере объекты VPCS представляют локальные сети основного и дочерних офисов предприятия, а три маршрутизатора NETSHe реализуют VPN сеть между этими офисами.

В проект добавлены два устройства Switch1 и Cloud c именем WebUI-Access, они необходимы только в тестовой среде для доступа к веб-интерфейсу устройств с NETSHe, т.к. эмуляция ведется в виртуальной среде, а VPCS не имеют браузера для подключения к WebUI. В реальной сети доступ к WebUI любого устройства с NETSHe можно настроить со стороны любого интерфейса, по умолчанию он открыт для LAN. Соответственно, с любого компьютера локальной сети можно получить доступ к веб-интерфейсу.

Слева на картинке показаны интерфейсы, участвующие в DM VPN, справа - основные настройки DM VPN spoke.

Данное руководство подробно не описывает DM VPN, только иллюстрирует возможности GNS3 в симуляции сложных проектов, приближающихся к реальной жизни.

Очевидный результат для такого примера, когда все офисы доступны друг другу по VPN сети, а VPN сеть соответствует топологии «звезда».