Документация по NETSHe

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== NETSHe _ GNS3 Examples RU ======
<sub>{{NETSHe _ GNS3 Examples RU.odt|Original file}}</sub>

Контактные данные организации{{примеры_проектов_gns3_Image_0.gif}}{{примеры_проектов_gns3_Image_1.png}}

NETSHe & GNS3

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

Контактные данные организации**Версия**** ****2****.0**

**Апрель****, 20****20**



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

ООО «Нетше Лаб» предлагает готовые тестовые проекты GNS3, их можно скачать по ссылке [[http://gw.stasoft.net/share/gns3/projects/|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}}

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

  - - удалить линк, соединяющий Cloud c другим компонентом проекта, на котором желательно запомнить имя соединяемого порта,
  - - в контекстном меню Cloud выбрать Configure,
  - - в списке интерфейсов удалить virbr0 и добавить Ethernet,
  - - восстановить линк.
 В остальном проекты, созданые в других экземплярах 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}}

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

  - компьютеры не имеют выхода в Интернет, Cloud используется для доступа к WebUI устройств,
  -  туннель поднимается по наличию трафика, в данном примере запуска ping от одного тестового компьютера к другому,
  - соединение между компьютерами устанавливается не с первого пакета, нужно время на поднятие туннеля,
  - После поднятия 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}}
Документация по NETSHe

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

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

Инструменты страницы
