По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
На инсталляционном носителе Windows находится не только операционная система, но и связанные с ней драйвера и компоненты системы. Все это хранится в файле, называемом - файл образ. Во время инсталляции этот образ применяется к целевому тому. Образы Windows используют формат файлов Windows Imaging (WIM), который имеет следующие преимущества:
Методы развертывания. Можно развернуть wim-файлы с помощью загрузочного USB-накопителя, из общего сетевого ресурса или с помощью специализированных технологий развертывания, таких как Службы развертывания Windows (WDS) или System Center Configuration Manager.
Редактируемость. Можно подключить образ к текущей ОС и редактировать его, включать, отключать или удалять роли и компоненты операционной системы, если это необходимо.
Возможность обновления. Имеется возможность обновить текущий образ, не создавая захват операционной системы.
Установочный носитель Windows Server 2019 содержит два WIM-файла - это Boot.wim и Install.wim. Файл Boot.wim использует для загрузки среды предустановки, которая запускается в момент развертывания Windows Server 2019. Install.wim хранит один или несколько образов операционной системы. Например, как показано на рисунке ниже, файл Install.wim содержит четыре разных выпуска Windows Server 2019. В зависимости от специфики оборудования, бывает ситуация, в которой потребуется добавить дополнительные драйверы в файл boot.wim. Например, потребуется добавить дополнительные драйвера, если процедура установки Windows не сможет получить доступ к устройству, на которое будет устанавливаться, поскольку драйвер этого устройства не включен в образ загрузки по умолчанию.
Модификация Windows образа
Deployment Image Servicing and Management (DISM) - это приложение командной строки. Программа работает с образами в автономном состоянии. Dism используется для реализации следующих задач:
Просмотр, добавление или удаление ролей и компонентов
Добавление, удаление обновлений
Добавление, удаление драйверов
Добавление, удаление приложений Windows *.appx
К примеру, можно скопировать файл Install.wim с дистрибутива Windows Server и используя Dism.exe примонитировать образ, добавить новые драйвера и обновления программного обеспечения к этому образу и сохранить или отменить эти изменения, и все это без необходимости выполнять фактическое развертывание ОС. Преимущество заключается в том, что, когда используется этот обновленный образ для развертывания, добавленные драйвера и обновления уже применяются к образу, и не нужно устанавливать их отдельно как часть процедуры настройки после установки.
На сайте каталога Центра обновления Майкрософт (https://catalog.update.microsoft.com) хранятся все сертифицированные драйвера оборудования, обновления программного обеспечения и исправления, опубликованные Microsoft. После загрузки драйверов и обновлений программного обеспечения их можно добавить к существующим установочным образам с помощью Dism.exe или соответствующих командлетов PowerShell в модуле DISM PowerShell.
Обслуживание образа Windows
Для уменьшения времени установки и настройки системы на новых серверах, нужно убедиться в тем, чтобы образы развертывания поддерживались в актуальном состоянии. К образу должны быть применены последние обновления программного обеспечения, а также должны быть включены все новые драйверы устройств для часто используемого серверного оборудования. Если не поддерживать образ развертывания в актуальном состоянии, потребуется дополнительное время на установку драйверов и обновлений. Применение обновлений после развертывания требует значительного времени, а также существенно увеличивает сетевой трафик. Одна из целей при выполнении развертывания сервера должна заключаться в том, чтобы как можно быстрее запустить сервер и включить его в работу.
Программа DISM может использоваться для обслуживания текущей операционной системы в оперативном состоянии или для автономного обслуживания образа Windows.
Обслуживание включает в себя выполнение следующих шагов:
Монтирование образа для изменения
Обслуживание образа
Фиксация или отмена внесенных изменений
Подключение образа
Примонтировав образ, появляется возможность вносить в него изменения, такие как добавление и удаление драйверов, установка обновлений, включение компонентов системы.
Обычно WIM-файл содержит несколько образов операционных систем. Каждому образу присваивается порядковый номер, который необходимо знать, прежде монтировать образ. Номер индекса можно определить с помощью Dism.exe с параметром /Get-wiminfo. Например, если дистрибутив ОС скопирован в D:Images, можно использовать следующую команду, чтобы получить список находящихся в нем образов:
Dism.exe /get-wiminfo /wimfile:d:imagessourcesinstall.wim
Тот же самый результат можно получить, используя командлет PowerShell Get-WindowsImage.
Get-WindowsImage -ImagePath d:imagessourcesinstall.wim
Когда нужный индекс операционной системы определен, монтируем этот образ программой Dism.exe c параметром /Mount-image. Например, чтобы смонтировать редакцию Standard Edition Windows Server 2019 из файла Install.wim, который доступен в папке D:Mount, введите следующую команду:
Dism.exe /mount-image /imagefile:d:imagessourcesinstall.wim /index:2 /mountdir:c:mount
В качестве альтернативы можно использовать команду Mount-WindowsImage:
Mount-WindowsImage -ImagePath D:imagessourcesinstall.wim -index 2 -path c:mount
Интеграция драйверов и обновлений
После того, как образ подключен, можно приступить к его обслуживанию. Наиболее распространенными задачами являются добавление в образ драйверов устройств и обновлений программного обеспечения. Чтобы добавить драйвера к подключенному образу используется Dism с параметром /Add-Driver. Чтобы не добавлять каждый драйвер по отдельности, используется параметр /Recurse, чтобы все драйверы находились в папке и подпапках добавлялись в образ. Например, чтобы добавить все драйвера, расположенные в папке и подпапках D:Drivers к образу, смонтированному в папке C:Mount, используйте следующую команду:
Dism.exe /image:c:mount /Add-Driver /driver:d:drivers /recurse
Командлет Add-WindowsDriver выполнит тоже действие:
Add-WindowsDriver -Path c:mount -Driver d:drivers -Recurse
Параметр /Get-Driver используется для просмотра всех добавленных драйверов, а /Remove-Driver позволяет удалить драйвер из образа. В PowerShell это командлеты Get-WindowsDriver и Remove-WindowsDriver соответственно. Удалять можно только те драйвера, которые были добавлены в образ.
Параметр /Add-Package позволяет добавляет обновления в формате *.cab или *.msu. Обновления программного обеспечения доступны на сайте Центра обновления Майкрософт в формате *.msu. Загрузим обновление с веб-сайта каталога Центра обновления Майкрософт под названием "2019-10 Cumulative Update for Windows Server, version 1903 for x64-based Systems (KB4517389) в папку D:updates на компьютере и применим обновление к образу.
Dism.exe /image:c:mount /Add-Package /PackagePath:"d:updateswindows10.0-kb4517389-x64_6292f6cb3cdf039f01410b509f8addcec8a89450.msu "
Тоже самое можно сделать используя PowerShell команду Add-WindowsPackage:
Add-WindowsPackage -path c:mount -packagepath "d:updateswindows10.0-kb4517389-x64_6292f6cb3cdf039f01410b509f8addcec8a89450.msu"
Добавление ролей и компонентов
Для просмотра ролей и компонентов в смонтированном образе используется параметр /Get-Features. Команда выглядит следующим образом:
Dism.exe /image:c:mount /Get-Features
Используя параметры /Enable-Feature и /Disable-Feature можно включать или отключать компоненты. Пример ниже включит NetFramework в текущем образе.
Dism.exe /image:c:mount /Enable-Feature /all /FeatureName:NetFx3ServerFeatures
Сохранение изменений
После внесения всех изменений в образ, их нужно сохранить, используя параметры /Unmount-Wim и /Commit. Параметр, отменяющий изменения - /Discard. Чтобы внести изменения и затем зафиксировать образ, смонтированный в папке C:mount, выполним команду:
Dism.exe /Unmount-Wim /MountDir:c:mount /commit
После применения изменений, win файл будет обновлен. Затем его можно импортировать в Windows Deployment Services (WDS) или использовать его с загрузочным usb носителем для развертывания Windows Server 2019 с уже примененными обновлениями, изменениями и драйверами.
Пока не создан единый протокол маршрутизации, управляющий остальными, существует необходимость в том, чтобы несколько протоколов маршрутизации мирно сосуществовали в одной сети. К примеру, одна компания работает с OSPF, а другая компания работает с EIGRP, и эти две компании слились в одно целое предприятие. Пока вновь образованный ИТ-персонал не перейдет для использования на единый протокол маршрутизации (возможно они когда-нибудь это сделают), маршруты, известные протоколу OSPF, необходимо объявить в часть сети, работающей под управлением EIGRP, и наоборот.
Упомянутый выше сценарий возможен благодаря Route redistribution, и именно этому посвящена данная статья. Другие причины, по которым вам потребуется выполнить Route redistribution, это: различные части сети конкретной компании находятся под различным административным контролем; если необходимо объявить маршруты своему поставщику услуг через BGP, или, возможно, необходимо подключиться к сети делового партнера.
Рассмотрим следующую базовую топологию.
В простой топологии, показанной выше, мы хотим, чтобы OSPF и EIGRP объявляли друг другу маршруты, о которых они знают. Эта концепция называется взаимным перераспределением маршрутов. Поскольку роутер CENTR имеет один интерфейс в автономной системе OSPF (AS) и один интерфейс в EIGRP AS, он несет ответственность за выполнение Route redistribution.
Seed Metrics
Основная проблема, с которой мы сталкиваемся при Route redistribution между различными протоколами маршрутизации, заключается в разнообразных подходах, применяемых протоколами маршрутизации для измерения своих метрик. Например, OSPF использует cost-метрику, которая основана на bandwidth, в то время как EIGRP использует метрику, основанную на bandwidth и delay, но также может учитывать надежность или (и) нагрузку (и даже использовать Maximum Transmission Unit (MTU) в качестве прерывания связи). Итак, что же нам делать?
Мы, как администраторы, можем настроить метрику, назначенную маршрутам, поступающим из одной AS, которые перераспределяются в другую AS. Если нам лень вручную настраивать метрику, которая будет использоваться для Route redistribution, то используется seed metric. В следующей таблице показаны seed metrics, используемые различными протоколами маршрутизации.
Основываясь на приведенной выше таблице, мы видим, что, маршрутам, которые перераспределяются в OSPF по дефолту будет назначена метрика 20, если же маршруты, перераспределяются в протокол OSPF от протокола BGP, то им будет присвоено значение метрики 1. Интересно, что и RIP, и EIGRP по умолчанию имеют seed metrics бесконечности. Это означает, что любой маршрут, перераспределенный в эти протоколы маршрутизации, будет считаться недостижимым по умолчанию и поэтому не объявляются никаким другим роутерам. BGP, однако, перераспределяет маршрут, полученный из протокола внутреннего шлюза (IGP), используя исходную метрику этого маршрута.
Пример базовой настройки
Конечно, есть еще много вопросов, связанных с перераспределением маршрутов, таких как циклы маршрутизации, которые могут возникнуть, когда у нас есть несколько роутеров, соединяющих наши автономные системы, или выборочная фильтрация определенных маршрутов от перераспределения. Но мы вернемся ко всему этому в следующих статьях. А пока давайте разберемся, как выполнить базовую настройку Route redistribution (перераспределения маршрутов). Рассмотрим предыдущую топологию, на этот раз с добавлением информации о сети и интерфейсе:
В этой топологии роутер CENTR изучает маршруты от OFF1 через OSPF и от OFF2 через EIGRP. Это видно в выходных данных команды show ip route, отображенной на CENTR:
Однако ни роутер OFF1, ни роутер OFF2 не изучили никаких маршрутов, потому что роутер CENTR еще не выполняет Route redistribution. Об этом свидетельствует вывод команды show ip route, отображенной на OFF1 и OFF2:
Теперь давайте добавим конфигурацию Route redistribution к роутеру CENTR. Чтобы подтвердить предыдущее утверждение о том, что seed metric для маршрутов, перераспределяемых в EIGRP, является бесконечностью, мы изначально не будем настраивать какие-либо метрики и позволим seed metric вступить в силу.
CENTR# conf term
Enter configuration commands, one per line. End with CNTL/ Z
CENTR(config)#router ospf 1
CENTR(config-router)#redistribute eigrp 1
CENTR(config-router)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)# redistribute ospf 1
CENTR(config-router)#end
CENTR#
Команда redistribute применена в режиме конфигурации роутера для каждого протокола маршрутизации, и метрика не была указана. Важно, что, когда мы ввели команду redistribute eigrp 1 выше, мы не включили ключевое слово subnets в команду, которая заставляет как классовые, так и бесклассовые сети перераспределяться в OSPF. Однако, как видно из приведенных ниже выходных данных, ключевое слово subnets было автоматически добавлено для нас:
Данное поведение автоматического добавления ключевого слова subnets наблюдается в последних версиях Cisco IOS. Некоторые, более старые версии Cisco IOS, не включают автоматически ключевое слово subnets, и вам может потребоваться вручную добавить его в команду redistribute. Давайте теперь взглянем на таблицы IP-маршрутизации на роутерах OFF1 и OFF2, чтобы увидеть, какие маршруты они изучили (и не изучили).
Приведенные выше выходные данные показывают нам, что роутер CENTR успешно перераспределил маршруты, известные EIGRP в OSPF, которые затем были изучены роутером OFF1. Обратите внимание, что перераспределенные маршруты, известные роутеру OFF1, имеют метрику 20, которая является seed metrics OSPF. Однако роутер OFF2 не изучал никаких новых маршрутов, потому что, когда роутер CENTR перераспределял маршруты в EIGRP, он использовал seed metrics EIGRP бесконечность (что означает недостижимость). В результате эти маршруты не были объявлены роутеру OFF2.
Чтобы решить эту проблему, нам нужно назначить метрику маршрутам, перераспределяемым в EIGRP. Существует три основных способа присвоения не дефолтных метрик маршрутам, перераспределяемым в протокол маршрутизации..
Установите метрику по умолчанию для всех протоколов маршрутизации, перераспределяемых в определенный протокол маршрутизации.
Установите метрику как часть команды redistribute.
Установите метрику используя route-map
Чтобы проиллюстрировать первый вариант, давайте настроим метрику для назначения всем маршрутам, перераспределяемым в EIGRP.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)#router eigrp 1
CENTR (config-router)#default-metric ?
1-4294967295 Bandwidth in Kbits per second
CENTR (config-router)#default-metric 1000000 ?
0-4294967295 delay metric in 10 microsecond units
CENTR(config-router)#default-metric 1000000 1 ?
0-255 Reliability metric where 255 is 100% reliable
CENTR (config-router)#default-metric 1000000 1 255 ?
1-255 Effective bandwidth metric (Loading) where 255 is 100% loaded
CENTR (config-router)#default-metric 1000000 1 255 1 ?
1-65535 Maximum Transmission Unit metric of thenpath
CENTR (config-router)#default-metric 1000000 1 255 1 1500
CENTR (config-router)#end
CENTR#
Контекстно-зависимая справка была использована в приведенном выше примере для отображения каждого компонента метрики, назначаемого маршрутам, перераспределяемым в EIGRP. Однако последняя команда была default-metric 1000000 1 255 1 1500. Если бы мы устанавливали default-metric для OSPF, мы могли бы использовать такую команду, как default-metric 30, чтобы назначить стоимость 30 OSPF маршрутам, перераспределяемым в OSPF. Однако в этом примере мы указали только default-metric для EIGRP. Давайте теперь проверим таблицу IP-маршрутизации на роутере OFF2, чтобы увидеть, были ли маршруты OSPF успешно объявлены в EIGRP.
Прекрасно! Роутер OFF2 изучил маршруты, происходящие из OSPF AS. Мы знаем, что маршруты первоначально пришли из-за пределов EIGRP, из-за кода EX, появляющегося в каждом из этих маршрутов.
Второй вариант установки метрики на Route Redistribution состоял в том, чтобы назначить метрику как часть команды redistribute, которая позволяет нам указать различные метрики для различных протоколов маршрутизации, перераспределяемых в процесс маршрутизации. Чтобы проиллюстрировать этот подход, давайте удалим предыдущие команды default-metric и redistribute из роутера CENTR и введем команду redistribute, которая определяет метрику, которая будет назначена.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no default-metric 1000000 1 255 1 1500
CENTR(config-router)#no redistribute ospf 1
CENTR(config-router)#redistribute ospf 1 ?
Match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
cr
CENTR(config-router)#redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#end
CENTR#
Если мы сейчас вернемся к роутеру OFF2, то получим тот же результат, что и раньше:
Третьим вариантом установки метрики для Route Redistribution использовании маршрутной карты (route-map). Маршрутные карты являются супермощными и могут быть использованы для различных конфигураций. По сути, они могут соответствовать определенному трафику и устанавливать один или несколько параметров (например, IP-адрес следующего прыжка) для этого трафика. Однако в нашем контексте мы просто будем использовать route-map для указания значения метрики, а затем применим ее к команде redistribute. В следующем примере показано, как мы можем удалить нашу предыдущую команду redistribute из роутера CENTR, создать route-map, а затем ввести новую команду redistribute, которая ссылается на нашу карту маршрута (route-map):
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#exit
CENTR(config)#route-map SET-МETRIC-DEMO
CENTR(config-route-map)#set metric 1000000 1 255 1 1500
CENTR(config-route-map)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)#redistribute ospf 1 route-map SET-МETRIC-DEMO
CENTR(config-router)#end
CENTR#
В приведенном выше примере, после удаления нашей команды redistribute, мы создали карту маршрута с именем SET-METRIC-DEMO. Это был очень простой route-map, которая не должна была соответствовать никакому траффику. Он был просто использован для установки метрики. Однако в следующей статье мы увидим, что route-map может быть использована, чтобы дать нам больше контроля над нашим перераспределением маршрутов. В нашем текущем примере карта маршрута была затем применена к нашей новой команде redistribute. Опять же, это дает нам тот же результат с точки зрения таблицы IP-маршрутизации роутера OFF2:
OSPF E1 или E2 Routes
Прежде чем мы закончим эту статью в нашей серии Route redistribution, давайте еще раз рассмотрим таблицу IP-маршрутизации на роутере OFF1:
Обратите внимание, что каждый из маршрутов, перераспределенных в OSPF, отображается в таблице IP-маршрутизации роутера OFF1 с кодом E2. Однако наблюдаются также код E1, оба указывающих, что маршрут возник из-за пределов OSPF AS роутера. Итак, в чем же разница между этими двумя кодами?
Код E2 указывает, что маршрут несет метрику, назначенную роутером, выполняющим перераспределение, который известен как автономный системный пограничный роутер (ASBR). Это означает, что независимо от того, сколько дополнительных роутеров в OSPF мы должны пересечь, чтобы вернуться к ASBR, метрика остается такой же, какой она была, когда ASBR перераспределил ее. Когда мы перераспределяем маршруты в OSPF, эти маршруты, по дефолту, являются этими External Type 2 (E2).
Код E1 указывает, что метрика маршрута состоит из первоначальной стоимости, назначенной ASBR, плюс стоимость, необходимая для достижения ASBR. Это говорит о том, что маршрут Е1, как правило, более точен, и на самом деле это так. Хотя наличие кода E1 не дает нам никакого преимущества в простой топологии, как у нас, где роутер OFF1 имеет только один путь для достижения ASBR (т. е. CENTR), и где есть только один способ для маршрутов EIGRP быть введенными в наш OSPF AS (т. е. через роутер CENTR).
Если мы хотим перераспределить маршруты E1 в OSPF вместо маршрутов E2, то это можно сделать с помощью команды redistribute. В следующем примере мы удаляем нашу команду redistribute для процесса маршрутизации OSPF на роутере CENTR, а затем повторно применяем команду redistribute, указывающую, что мы хотим, чтобы External Type 1 (E1) применялись к перераспределенным маршрутам.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router ospf 1
CENTR(config-router)#no redistribute eigrp 1 subnets
CENTR(config-router)#redistribute eigrp 1 metric-type ?
1 Set OSPF External Туре 1 metrics
2 Set OSPF External Туре 2 metrics
CENTR(config-router)#redistribute eigrp 1 metric-type 1
CENTR(config-router)#end
CENTR#show
Давайте проверим таблицу IP-маршрутизации на роутере OFF1, чтобы увидеть, изменились ли параметры на основе этой новой команды redistribute, введенной на роутере CENTR.
В приведенных выше выходных данных обратите внимание, что маршруты, перераспределенные в OSPF, имеют код E1, а не дефолтный код E2. Кроме того, обратите внимание, что это приводит к тому, что метрика этих маршрутов будет немного выше. В частности, роутер CENTR перераспределил EIGRP-изученные маршруты в OSPF, используя начальную метрику OSPF 20.
Однако существует стоимость OSPF 1, чтобы добраться от роутера OFF1 до роутера CENTR. Таким образом, поскольку перераспределенные маршруты были сконфигурированы как маршруты E1, стоимость этих маршрутов с точки зрения роутера OFF1 является стоимостью, первоначально назначенной роутером OFF1, которая составляла 20, плюс стоимость для OFF1, чтобы добраться до CENTR, который равен 1, итого общей стоимости 21.
Отлично, теперь вы знаете, как делать перераспределение маршрутов. Теперь почитайте, как сделать Фильтрацию маршрутов с помощью карт маршрутов.
В данной статье мы опишем настройки сети, которые могут очень пригодится для малых и средних сетей. Мы настроим на Cisco ASA DHCP сервер с несколькими внутренними локальными сетями.
У нас есть три разных внутренних локальных сети с ПК пользователей и другой инфраструктурой – серверами, принтерами и так далее.
Нашей задачей является разделение этих сетей с помощью использования Cisco ASA (данная задача решается как на старых моделях 5500, так и на новых 5500-X). Три внутренних локальных сети будут подключены к одному коммутатору второго уровня с тремя VLAN-ами на данном коммутаторе
ASA будет предоставлять доступ к интернету для всех внутренний ЛВС. Кроме того, ASA также будет выполнять функции DHCP сервера для каждой из ЛВС, назначая нужные IP – адреса для каждой из сетей, используя разные DHCP пулы. Кроме того, мы будем использовать один физический интерфейс на ASA для размещения внутренних зон безопасности (“inside1”,“inside2”,“inside3”). Для этого нам необходимо настроить саб-интерфейсы на физическом интерфейсе нашего МСЭ, который подключен к транковому порту коммутатора. Каждый саб-интерфейс будет служить шлюзом по умолчанию для соответствующих подсетей.
Касаемо настроек свитча – нам необходим один порт Dot1Q, который будет подключен к фаерволлу, и также необходимо будет настроить порты доступа для внутренних хостов.
Топология изображена ниже:
Убедитесь, что вы используете лицензию security-plus.
Из топологии мы видим:
Интерфейс GE1 на ASA – внешняя зона с адресом 100.1.1.1 будет подключен к провайдеру
Интерфейс GE0 на ASA – интерфейс, подключенный к транковому порту на коммутаторе. Данный интерфейс будет разбит на три саб-интерфейса, каждый из которых принадлежит свой зоне безопасности и VLAN.
Саб-интерфейс GE0.1 - VLAN10 (адрес 10.1.1.254) – зона безопасности “inside 1”
Саб-интерфейс GE0.2 - VLAN10 (адрес 10.2.2.254) – зона безопасности “inside 2”
Саб-интерфейс GE0.3 - VLAN10 (адрес 10.3.3.254) – зона безопасности “inside 3”
Интерфейс Eth0/1, Eth0/2, Eth 0/3 на коммутаторе – настраиваются как порты доступа для соответствующих VLAN-ов (10, 20, 30)
Хосты в VLAN 10 – получат адреса с ASA через DHCP (10.1.1.0/24) на интерфейсе “inside1”
Хосты в VLAN 20 - получат адреса с ASA через DHCP (10.2.2.0/24) на интерфейсе “inside2”
Хосты в VLAN 30 – получат адреса с ASA через DHCP (10.3.3.0/24) на интерфейсе “inside3”
Все внутренние локальные сети – данные сети получат доступ к интернету через ASA с использованием PAT (NAT Overload) на внешнем интерфейсе МСЭ
Важно отметить, что в данном примере настройка меж-VLAN маршрутизации проведена не была – есть только доступ в интернет.
Конфигурация Cisco ASA
Ниже указан конфиг для МСЭ
! Данный физический интерфейс разбиваем на три саб-интерфейса (порт подключен к транковому порту коммутатора)
interface GigabitEthernet0
no nameif
no security-level
no ip address
!
! Это саб-интерфейс GE0.1 для VLAN10
interface GigabitEthernet0.1
vlan 10
nameif inside1
security-level 100
ip address 10.1.1.254 255.255.255.0
! Это саб-интерфейс GE0.2 для VLAN20
interface GigabitEthernet0.2
vlan 20
nameif inside2
security-level 90
ip address 10.2.2.254 255.255.255.0
! Это саб-интерфейс GE0.3 для VLAN30
interface GigabitEthernet0.3
vlan 30
nameif inside3
security-level 80
ip address 10.3.3.254 255.255.255.0
! This is the WAN interface connected to ISP Это WAN интерфейс, подключенный к ISP
interface GigabitEthernet1
nameif outside
security-level 0
ip address 100.1.1.1 255.255.255.0
! Настраиваем сетевые объекты для трех ЛВС
object network inside1_LAN
subnet 10.1.1.0 255.255.255.0
object network inside2_LAN
subnet 10.2.2.0 255.255.255.0
object network inside3_LAN
subnet 10.3.3.0 255.255.255.0
! Данный ACL полезен тем, что разрешает ходить ICMP трафику (пинг и так далее)
access-list OUT extended permit icmp any any
access-group OUT in interface outside
! Разрешаем доступ в Интернет – для этого настраиваем PAT (NAT Overload) на внешнем интерфейсе
object network inside1_LAN
nat (inside1,outside) dynamic interface
object network inside2_LAN
nat (inside2,outside) dynamic interface
object network inside3_LAN
nat (inside3,outside) dynamic interface
access-group OUT in interface outside
route outside 0.0.0.0 0.0.0.0 100.1.1.2
! Создаем три разных DHCP cущности
! DHCP сущность для VLAN10 – “inside1”
dhcpd address 10.1.1.1-10.1.1.100 inside1
dhcpd enable inside1
! DHCP сущность для VLAN20 – “inside2”
dhcpd address 10.2.2.1-10.2.2.100 inside2
dhcpd enable inside2
! DHCP сущность для VLAN30 – “inside3”
dhcpd address 10.3.3.1-10.3.3.100 inside3
dhcpd enable inside3
! Назначаем DNS cервер для внутренних хостов
dhcpd dns 200.1.1.1
На этом все, переходим к настройке свитча.
Настройка коммутатора
Настройка коммутатора очень проста – необходимо настроить транковый порт и три порта доступа, с указанием VLAN.
! Транковый порт, который подключается к GE0
interface Ethernet0/0
switchport trunk encapsulation dot1q
switchport mode trunk
duplex auto
! Порт доступа для VLAN10
interface Ethernet0/1
switchport access vlan 10
switchport mode access
duplex auto
! Порт доступа для VLAN20
interface Ethernet0/2
switchport access vlan 20
switchport mode access
duplex auto
! Порт доступа для VLAN30
interface Ethernet0/3
switchport access vlan 30
switchport mode access
duplex auto