Инструменты пользователя

Инструменты сайта


примеры_проектов_gns3

NETSHe _ GNS3 Examples RU

Original file

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

NETSHe & GNS3

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

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

Апрель, 2020

Введение. Примеры проектов c NETSHe в среде GNS3

ООО «Нетше Лаб» предлагает готовые тестовые проекты 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:

примеры_проектов_gns3_image_2.jpg

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

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

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

Использование NETSHe для подключения к сети по DHCP с выдачей клиентам адресов через DHCP и применением NAT

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

примеры_проектов_gns3_image_3.jpg

примеры_проектов_gns3_image_4.jpg

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

примеры_проектов_gns3_image_5.jpg

Настройка NETSHe как статического маршрутизатора без NAT и межсетевого экрана. Настройка доступа к веб-интерфейсам устройств с NETSHe.

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

примеры_проектов_gns3_image_6.jpg

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

примеры_проектов_gns3_image_7.jpg

примеры_проектов_gns3_image_8.jpg

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

примеры_проектов_gns3_image_9.jpg

Настройка IPsec site-to-site

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

примеры_проектов_gns3_image_10.jpg

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

примеры_проектов_gns3_image_11.jpg

примеры_проектов_gns3_image_12.jpeg

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

примеры_проектов_gns3_image_13.jpg

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

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

примеры_проектов_gns3_image_14.jpg

Настройка GRE туннеля и статической маршрутизации

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

примеры_проектов_gns3_image_15.jpg

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

примеры_проектов_gns3_image_16.jpeg

Использование RIP для взаимодействия сетей

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

примеры_проектов_gns3_image_17.jpg

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

примеры_проектов_gns3_image_18.jpeg

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

примеры_проектов_gns3_image_19.jpeg

Использование OSPF для взаимодействия сетей

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

примеры_проектов_gns3_image_20.jpg

Использование VRRF для взаимодействия сетей

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

примеры_проектов_gns3_image_21.jpg

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

примеры_проектов_gns3_image_22.jpgпримеры_проектов_gns3_image_23.jpg

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

примеры_проектов_gns3_image_24.jpg

Настройка основного и резервного каналов (backup link)

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

примеры_проектов_gns3_image_25.jpg

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

примеры_проектов_gns3_image_26.jpg

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

примеры_проектов_gns3_image_27.jpg

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

примеры_проектов_gns3_image_28.jpg

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

примеры_проектов_gns3_image_29.jpg

Пример с NETSHe для DM VPN главного офиса и филиалов

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. Соответственно, с любого компьютера локальной сети можно получить доступ к веб-интерфейсу.

примеры_проектов_gns3_image_30.jpg

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

примеры_проектов_gns3_image_31.jpg

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

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

примеры_проектов_gns3_image_32.jpg

примеры_проектов_gns3.txt · Последнее изменение: 2020/07/17 11:24 — doku_netshe_admin

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki