Оборудование - DGS-3627. Возник такой вопрос. На свиче настроено 3 vlan. Для управления я выделил отдельную - default. Каждой vlan назначил IP-интерфейс - соответственно, 192.168.1.1, 192.168.2.1, 192.168.3.1. Проблема в том, что, управлять устройством при таком раскладе можно из любой подсети - достаточно указать адрес его IP-интерфейса. Например, находясь во 2 vlan указать IP 192.168.2.1 (интерфейс второй vlan) в браузере и получаешь приглашение. Вопрос: как запретить из всех vlan, кроме специально для этого выделенной, иметь доступ к управляющим функциям свича (web, telnet...). Что-то не нашел никакого явного способа указать управляющую vlan/интерфейс. Есть для этого простой способ или надо это делать через acl?

плохо искали вот пример того как это можно сделать:

1. ACL
   Код:
   create access_profile profile_id 1                           ip vlan
   config access_profile profile_id 1 add access_id auto_assign ip vlan default port 1-24 permit
   
   create access_profile profile_id 2                           ip destination_ip_mask your.hardware.network.0
   config access_profile profile_id 2 add access_id auto_assign ip destination_ip      your.hardware.network.0  port 1-24 deny
2. CPU Interface Filtering
   Код:
   create cpu access_profile profile_id 1                 ip source_ip_mask your.hardware.network.0
   config cpu access_profile profile_id 1 add access_id 1 ip source_ip      your.hardware.network.0 port 1-24 permit
   
   # ICMP чтоб трейсы ходили
   create cpu access_profile profile_id 2                 ip source_ip_mask 0.0.0.0 icmp type
   config cpu access_profile profile_id 2 add access_id 1 ip source_ip      0.0.0.0 icmp type  0 port 1-24 permit
   config cpu access_profile profile_id 2 add access_id 2 ip source_ip      0.0.0.0 icmp type  3 port 1-24 permit
   config cpu access_profile profile_id 2 add access_id 3 ip source_ip      0.0.0.0 icmp type  8 port 1-24 permit
   config cpu access_profile profile_id 2 add access_id 4 ip source_ip      0.0.0.0 icmp type 11 port 1-24 permit
   
   create cpu access_profile profile_id 3                 ip source_ip_mask 0.0.0.0
   config cpu access_profile profile_id 3 add access_id 1 ip source_ip      0.0.0.0 port 1-24 deny
   
   enable cpu_interface_filtering

п.1 + п.2 дадут Вам то что хотите

_________________
с уважением, БП

Спасибо) В принципе, уже и сам понял, как сделать это с помощью cpu interface filtering. Только сделал не совсем так:

create cpu access_profile profile_id 1 ethernet vlan
config cpu access_profile profile_id 1 add access_id 1 ethernet vlan vlan2 port all deny

Для traceroute, конечно, отдельно надо будет завести, как вы и указали. Получается, другого способа нет? Я-то хотел где-нибудь галочку поставить типа management vlan и все) А так - надо на каждом свиче для каждого влана правила писать. Все равно - спасибо за ответ.

Нет именно так поскольку это L3 свитч.

ну так ведь изначально для него задача и ставилась:




и? потом делать так при появлении каждого нового VLAN? не ... IMHO, это не разумно ...


а чем Вам этот метод не нравится? зачем что-то еще писать?
во первых - ту самую галочку Вы уже поставили когда вынесли управление в отдельный VLAN, во вторых - проблема была в том что 3627 - это L3 свич и он роутит пакеты между своими интерфейсами, НО! но если Вы сделатете так как я написал, то тогда не только интерфейс самого свича в железной сети, но сам Ваш железный VLAN (в примере - default) не будет виден абсолютно никому, т.е., в третьих - на других свичах и делать ничего не надо будет ...

_________________
с уважением, БП

Почему не используете create trusted_host ?

в свете вышепредложенного варианта оно без надобности ... разве что только чтоб разграничить доступ внутри железного VLAN ...

_________________
с уважением, БП

Trusted Hosts - тоже, в принципе, нормальный выход. По ACL вопрос - будет ли отличаться:



от

Был бы также весьма признателен за краткие комментарии к коду, чтобы лучше разобраться с действием acl.

Я ещё проще реализовал, полностью разделив юзерскую подсеть от комутаторов на уровне доступа (DES3526). У нас свичи с айпишками 10.10.хх.хх, а пользователи - 10.1.хх.хх (при этом есть локальные ресурсы с айпихами 10.10.9.хх). Пользователи в 1-24 портах, магистрали в 25-26.

create access_profile ip source_ip_mask 255.255.0.0 destination_ip_mask 255.255.255.0 profile_id 3

config access_profile profile_id 3 add access_id 1 ip source_ip 10.1.0.0 destination_ip 10.10.9.0 port 1-24 permit

(разрешает доступ к локальным ресурсам)

create access_profile ip source_ip_mask 255.255.0.0 destination_ip_mask 255.255.0.0 profile_id 4

config access_profile profile_id 4 add access_id 25 ip source_ip 10.1.0.0 destination_ip 10.10.0.0 port 1-24 deny

(запрещает всё остальное).
Для 3627 можно подобные правила написать.
В результате клиенты "видят" из железа только свои шлюзы, локальные ресурсы и днс-ку, не имея доступа ни к серверам, ни к комутаторам. При этом комутаторы не отвечают даже на снмп-запросы из пользовательской сети.

хотя, защиты слишком много не бывает

_________________
AB-Style: Выходных дней два в году - Новый Год и Апокалипсис. Да и то что-то с Апокалипсисом не везёт...
D-Link User: DES-3526/3550, DES-3528, DES-3018, DES-3200-XX, DGS-3612/3627G, DCS-9x0, DCS-3220, DVG-5112S, DPH-400S + разные роутеры и медиаконвертеры

разрешаем любой трафик в дефолтном VLAN:

запрещаем любые обращения на IP адреса в дефолтном VLAN:

т.к. мы уже разрешили весть трафик в дефолтном VLAN, то пакеты этого VLAN будут бегать абсолютно всегда и с управлением проблем не будет, т.к. 3627 - это L3 свич и он роутит пакеты между своими интерфейсами и поэтому нам и нужен profile_id 2 который просто запрещает юзерам увидеть IP адреса железа в дефолтном VLAN, обратите внимание - IP адреса железа, а не самого 3627! дабы защитить сам 3627 нам и понадобится CPU Interface Filtering, в правилах которого разрешаем железу обращаться к IP 3627:

т.к., повторюсь, 3627 - это L3 свич, который является шлюзом для юзеров то необходимо разрешить чтобы пинговали этот самый шлюз и через него мог пройти трейсроут в другую сеть:

после этого запрещаем всякую активность в отношении интерфейсов свича:

_________________
с уважением, БП

Большое спасибо за объяснения!