====== NETSHe _ GNS3 Examples RU ====== {{NETSHe _ GNS3 Examples RU.odt|Original file}} Контактные данные организации{{примеры_проектов_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}}