Сетевой экран является организатором локальной сети. Необходимо настроить VLAN и изоляцию между сегментами.
Настройку этого сетевого экрана без VLAN можно посмотреть тут.
Создание VLAN.
Для меж-вилановой маршрутизации на USG нужны виртуальные L3 под-интерфейсы (dot1q) на первичном физическом интерфейсе. Создадим их для каждого ID.
Аналогичными действиями создаются под-интерфейсы для всех VLAN.
В доп. настройках можно активировать разрешение для ping, чтоб находить интерфейс в сети. Временно можно установить зону trust. Об зонах написано немного ниже.
На первичном физическом интерфейсе IP-адрес не назначается.
Настройка через CLI.
|
1 2 3 4 5 6 7 |
system-view vlan batch 10 20 30 40 50 60 100 200 interface GigabitEthernet0/0/3.1 vlan-type dot1q 10 ip address 192.168.1.1 255.255.255.0 alias VLAN10 quit |
|
1 2 3 4 5 |
interface GigabitEthernet0/0/3.2 vlan-type dot1q 20 ip address 192.168.2.1 255.255.255.0 alias VLAN20 quit |
и тд.
|
1 2 3 4 5 |
firewall zone trust add interface GigabitEthernet0/0/0 add interface GigabitEthernet0/0/3.1 add interface GigabitEthernet0/0/3.2 add interface GigabitEthernet0/0/3.3 |
и тп.
Просмотр через CLI.
|
1 2 |
display ip interface brief display zone |
или
|
1 |
display current-configuration | include interface | ip address | zone |
На самом USG транк как отдельная настройка не нужна. Под-интерфейсы сами добавляют теги VLAN.
Access-порты.
Выбираем интерфейс и назначаем ему режим access.
Аналогично настраиваем все нужные порты.
Через CLI.
|
1 2 3 4 5 |
interface GigabitEthernet0/0/4 portswitch port link-type access port default vlan 200 quit |
|
1 2 3 4 5 |
interface GigabitEthernet0/0/5 portswitch port link-type access port default vlan 200 quit |
Создаем VLAN интерфейс.
Добавляем access-интерфейсы в VLAN-интерфейс.
Через CLI.
|
1 2 3 |
interface Vlanif200 ip address 192.168.200.1 255.255.255.0 alias VLAN200 |
|
1 2 |
firewall zone trust add interface Vlanif200 |
Проверяем какой IP-адрес в результате на портах.
Если нужно чтоб на под-интерфейсе и на access-портах была одна и та же сеть, например с ID 20, нужно создать интерфейс Vlanif20, не назначать ему IP и добавить в него нужные порты с ID 20. IP-адрес подтянется к из настроенного выше под-интерфейса.
DHCP-сервер.
Создавать нужно для каждого VLAN.
Настройка через CLI.
|
1 2 3 4 5 6 7 8 9 |
system-view interface GigabitEthernet0/0/3.1 dhcp enable dhcp server mask 255.255.255.0 dhcp server ip-range 192.168.1.1 192.168.1.200 dhcp select interface dhcp server gateway-list 192.168.1.1 dhcp server dns-list 192.168.1.1 quit |
Настройка через CLI.
|
1 2 3 4 5 6 7 |
system-view ip pool VLAN10-POOL gateway-list 192.168.1.1 network 192.168.1.0 mask 255.255.255.0 dns-list 8.8.8.8 lease day 0 hour 8 minute 0 quit |
|
1 2 |
interface GigabitEthernet0/0/3.1 dhcp select global |
Созданный через CLI пул не отображается в GUI.
Именованный пул можно создать через GUI: Objects >> IP Address Pool.
Это по смыслу такой же пул, как и созданный через CLI, но в нем есть какие-то метаданные для отображения. В GUI меньше возможностей для редактирования. Шлюз, сеть и маску всё равно придется вносить через CLI.
Удаление (если понадобится).
|
1 |
undo ip pool VLAN10-POOL |
В именном пуле можно задать его название. В этом разница с интерфейсным пулом, у которого в названии интерфейс.
|
1 |
display ip pool |
В данной настройке используется команда dhcp select global. Эта команда на интерфейсе указывает USG использовать глобальные DHCP-пулы, а не локальные, специфичные для интерфейса. В этом случае DHCP-запросы клиентов будут обслуживаться всеми глобальными пулами, которые соответствуют сети интерфейса. Пул не привязан к конкретному интерфейсу, а выбирается автоматически по IP-сети интерфейса.
Алгоритм примерно такой:
-клиент присылает DHCP Discover;
-USG смотрит IP сети интерфейса (например, GE0/0/3.1 >> 192.168.1.1/24 >> сеть 192.168.1.0/24);
-среди глобальных пулов выбирается тот, который содержит эту сеть;
-DHCP-ответ выдается из этого пула.
То есть, чтобы пул сработал параметр сети (через IP-адрес и маску) на интерфейсе должен совпадать с параметром network в пуле. Пул должен быть глобальным, а интерфейс настроен с dhcp select global.
Проверка.
Коммутаторы у всех разные и настраиваются порты по-разному, но смысл один – нужно настроить входящий порт в режиме Trunk.
Вот ссылки для настройки транка в некоторых коммутаторах: Mikrotik, BDCOM, Huawei, Zyxel.
В порт 3 USG подключаем коммутатор с настроенным trunk-портом.
Коммутатору раздается IP-адрес из VLAN управления.
Далее в коммутаторе настраиваются access-порты и в них подключаются ПК пользователей.
Проверяем любой подключенный ПК. Ему раздался IP-адрес из VLAN70. Всё согласно настройке.
Подключенные клиенты отображаются в меню Monitoring.
Просматривать через CLI все пулы сразу одной командой нельзя. Нужно выбирать по очереди по названию интерфейса.
|
1 |
display ip pool interface GigabitEthernet0/0/3.7 used |
Мониторинг DHCP не показывает сетевое имя устройства – это главный недостаток. При сотнях клиентов видны только цифры: IP, MAC, время аренды. Для крупных сетей это очень неудобно при идентификации устройств.
Второй важный недостаток у конкретно этой модели USG6510E – максимальное количество объектов, которые можно добавить = 256. Статическая привязка считается объектом и поэтому можно привязать IP-адрес к MAC-адресу только для указанного количества сетевых устройств.
В связи с этим, вынесем DHCP-сервер на другое устройство, а клиентам будем раздавать IP-адреса с помощью настройки DHCP-Relay.
DHCP-Relay.
DHCP Relay (или DHCP-ретрансляция) – это сетевой сервис, который пересылает DHCP-запросы от клиентов, находящихся в одной подсети, на DHCP-сервер, находящийся в другой подсети, обеспечивая централизованную выдачу IP-адресов и других параметров сети.
В представляемой конфигурации DHCP-сервер находится в VLAN70 на виртуальной машине. Его IP-адрес 192.168.7.5. Клиенты в сети 192.168.7.0/24 получают IP напрямую от DHCP-сервера. Relay не нужен, так как DHCP-запросы и ответы проходят в пределах одной сети (UDP broadcast – широковещательные запросы). Поэтому создаем настройку Relay для всех остальных VLAN кроме VLAN70.
Через CLI.
|
1 2 3 4 5 |
system-view interface GigabitEthernet0/0/3.8 dhcp select relay ip relay address 192.168.7.5 quit |
Этой настройкой мы сообщаем о том, что все DHCP-запросы из VLAN80 нужно перенаправлять на IP-адрес DHCP-сервера 192.168.7.5.
В роли DHCP-серверов рассмотрены два варианта: CHR Mikrotik и DC. Под спойлерами пример настройки.
Тут самая простая и логичная настройка. Создаем обычный DHCP-сервер с пулом и сетью. В поле Relay указываем IP-адрес другой сети (интерфейса USG), куда слать ответы.
Обязательно нужно создать маршрут из DHCP-сервера, через шлюз USG в сеть LAN-8.
Настройка через CLI.
|
1 2 3 4 5 |
/ip address add address=192.168.7.5/24 interface=ether3 network=192.168.7.0 /ip pool add name=POOL-LAN-8 ranges=192.168.8.2-192.168.8.20 /ip dhcp-server network add address=192.168.8.0/24 dns-server=192.168.8.1 gateway=192.168.8.1 /ip dhcp-server add address-pool=POOL-LAN-8 interface=ether3 name=DHCP-LAN-8 relay=192.168.8.1 /ip route add dst-address=192.168.8.0/24 gateway=192.168.7.1 |
При включенном файерволе нужно добавить разрешающее правило для DHCP запросов из других сетей.
Если нужно организовать раздачу IP в другие сети, то аналогично создаем еще один DHCP-сервер с другими IP-адресами, маршрут и тп.
Проверяем. Подключаем ПК в сеть. Ему раздается IP-адрес из DHCP-сервера в нужном диапазоне.
В DHCP-сервере так же видна раздача IP в соответствии с настройкой.
Просмотр статистики в USG.
|
1 |
display dhcp relay statistics |
По статистике можно понять, куда и сколько пакетов доходит или не доходит.
На сервере назначаем статический IP
Панель управления >> Сетевые подключения >> Свойства сетевого адаптера >> IPv4 >> указать IP, маску, шлюз, DNS.
В данной настройке IP-адрес у DHCP-сервера 192.168.7.10
Через CLI.
Просмотр сетевых адаптеров.
|
1 |
Get-NetAdapter |
Устанавливаем на нужный адаптер статический IP и маску.
|
1 |
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.7.10 -PrefixLength 24 -DefaultGateway 192.168.7.1 |
Устанавливаем DNS-сервер
|
1 |
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.7.10 |
Добавляем роль DHCP.
Через CLI.
|
1 |
Install-WindowsFeature –Name DHCP –IncludeManagementTools |
Параметр IncludeManagementTools устанавливает инструменты управления, которые в GUI появляются как оснастки:
dhcpmgmt.msc (консоль MMC)
PowerShell-модуль для DHCP
netsh dhcp команды
Переходим в консоль управления DHCP.
Win+R
|
1 |
dhcpmgmt.msc |
Авторизуем DHCP-сервер в Active Directory.
|
1 |
Add-DhcpServerInDC -DnsName "dc-pc360.local" -IpAddress 192.168.7.10 |
Проверка авторизации.
|
1 |
Get-DhcpServerInDC |
Создаем области для всех сетей.
Проходим по мастеру или гораздо быстрее через CLI.
|
1 2 3 4 5 6 |
Add-DhcpServerv4Scope -Name "LAN9" ` -StartRange 192.168.9.2 ` -EndRange 192.168.9.254 ` -SubnetMask 255.255.255.0 ` -State Active ` -Description "DHCP Scope for LAN9" |
|
1 2 3 |
Set-DhcpServerv4OptionValue -ScopeId 192.168.9.0 ` -DnsServer 192.168.7.10 ` -DnsDomain "pc360.local" |
Шлюзом указываем IP-адрес интерфейса USG.
Проверяем области.
|
1 |
Get-DhcpServerv4Scope |
Проверяем настройки конкретной области.
|
1 |
Get-DhcpServerv4OptionValue -ScopeId 192.168.9.0 |
Проверяем раздались ли клиентам IP-адреса.
Через CLI.
|
1 |
Get-DhcpServerv4Lease -ScopeId 192.168.9.0 |
Каким-то образом шлюз в одной области не настроился.
Исправляем это.
Проверяем еще раз – всё ок.
Проверяем пинг между компьютерами.
Чтоб USG не показывал звездочки во время трассировки нужно активировать TTL-exceeded сообщения на нём.
|
1 2 |
system-view icmp ttl-exceeded send |
Сервер настроен и готов к работе.
Изоляция между VLAN.
Изоляцию можно организовать через политики безопасности (Security Policy) или списки контроля доступа (ACL).
ACL работает на 3-м и 4-м уровне модели OSI, фильтруя пакеты на основе IP-адресов источника и назначения, протоколов и номеров портов. Этот способ далее не рассматривается, потому что настройка возможна только через CLI. Нужно создавать большое количество правил каждой сети с каждой, если добавляется новый VLAN, то это еще нужно правил добавить для каждой сети и в результате трудно понять общую картину безопасности и всем этим управлять.
Рассмотрим изоляцию с политиками безопасности. Здесь ключевую роль играют зоны.
При миграции на USG с другого FW или GW для быстрого развертывания можно добавить все созданные VLAN в зону trust. Главное преимущество такого метода – не нужно редактировать множество существующих политик безопасности. Изоляция между VLAN при этом отсутствует. Всё оборудование в сети видит друг друга и для настройки это хорошо, но для безопасности плохо. Так же для хождения трафика в этом случае нужно создать разрешающие правила из trust в local и из local в trust, потому что USG является организатором VLAN, и соответственно много служебного трафика идет к самому USG в зону local.
Другой, более трудоемкий изначально вариант, но с более широкими возможностями по управлению – создание отдельной зоны для VLAN. В этом случае нужно создавать множество дополнительных политик или редактировать существующие. Требуется явно описывать всё что разрешено, потому что всё остальное запрещено. Рассмотрим этот вариант подробнее, так как в перспективе и с точки зрения детального контроля он более правильный.
Итак, чтоб ограничить общение между сетевыми устройствами в разных сегментах, создадим одну дополнительную зону для VLAN. Затем применим её в политиках безопасности.
Приоритет зоны влияет только на порядок обработки политик, если пакет может попасть под несколько зон одновременно (что бывает редко). Поэтому в данном случае выбирается любой приоритет из допустимого диапазона 0-100. Выберем, например 70, чтобы визуально понимать порядок и не пересекаться со стандартными зонами.
В зону можно сразу добавить нужные интерфейсы. Либо сделать это в меню интерфейсов.
Через CLI.
|
1 2 3 4 5 6 |
system-view firewall zone name vlan set priority 70 add interface GigabitEthernet0/0/3.8 add interface GigabitEthernet0/0/3.9 quit |
Создаем политику безопасности блокирующую любой трафик внутри зоны vlan.
Через CLI.
|
1 2 3 4 5 6 7 |
system-view security-policy rule name DENY-VLAN-INTRA-ZONE source-zone vlan destination-zone vlan action deny quit |
Создаем исключение, разрешающее трафик между конкретными адресами в зоне vlan. Для этого сначала создаем объект, в который добавляем нужные IP-адреса.
|
1 2 3 |
ip address-set VLAN-ALLOW-GROUP type object address 0 192.168.8.18 mask 32 address 1 192.168.9.19 mask 32 |
Создаем политику разрешающую трафик между заданными IP-адресами. В источник и назначение добавляем созданный выше объект.
Через CLI.
|
1 2 3 4 5 6 7 |
security-policy rule name ALLOW-VLAN-EXCEPTION source-zone vlan destination-zone vlan source-address address-set VLAN-ALLOW-GROUP destination-address address-set VLAN-ALLOW-GROUP action permit |
Расположить политики желательно ближе к верху списка одну за другой.
Проверяем.
С включенной политикой исключения ping проходит между клиентами, с выключенной – не проходит. Изоляция работает.
Аналогично настраиваются исключения для других пар или групп IP-адресов.
Чтоб работали все существовавшие до VLAN политики, например доступ в Интернет, DNS и другие, нужно добавить зону vlan в нужную политику. Или создать новые политики с зонами vlan.
Вот примерно так это и настраивается.
Итог.
По результату эксплуатации такой сети нужно отметить некоторые недостатки.
1.Трафик локальной сети проходит через сетевой экран. Если возникла необходимость перезагрузить сетевой экран по причине внешних сетей, то перестает работать и внутренняя сеть на время перезагрузки. Для нашей организации это оказалось критичным.
2.Сложно отслеживать трафик. В данной модели инструменты мониторинга очень ограничены и в результате внешний и внутренний трафик отображаются в мониторинге вместе. Сложно понять что кто-то занимает канал скачивая из Интернета или это локальный трафик.
3.В сетевом экране возникает огромное количество политик для локального и внешнего трафика, для исключений и тп. Это усложняет управление. У админа начинает болеть голова где и какие правила размещать.
В итоге получилась сеть с сегментацией и изоляцией между VLAN с возможностью настраивать исключения. Но такой вариант подходит скорее для небольших сетей. В крупных сетях локальный трафик логичнее выносить на управляемый коммутатор или роутер. Для внутреннего трафика важна скорость и низкая задержка. Для внешнего – безопасность и контроль. Смешивая их, мы вынуждены пропускать огромные объемы доверенного внутреннего трафика через процессор USG, что создает ненужную нагрузку и сложность конфигурации.