[kf72]

Здравствуйте!

поменял управляющие вланы в сегментах сети.

как защитить коммутаторы доступа со стороны доступа и со стороны ядра?

попробовал ацл - разрешил сеть/24 остальное запретил и навесил на влан (на порт не умеет) - не помогло.

как надо ?

[Megas]

нихрена не понятно, хотя бы с каким железом то работаете?

а то может вам просто от уборщиц его надо зашиить или от излучения, может лучше в фольгу завернуть?

[Saab95]

Самое правильное будет разместить оборудование в антивандальном шкафу.

[kf72]

посмеялись, а теперь к делу.

ядро циска 6509 суп2.

доступ длинки 3026, 3028, 3200

управляющие вланы разнесены с клиентскими.

задача - ограничить доступ к оборудованию 3 подсетями /24, чтобы абоненты доступа к настройкам оборудования доступа не имели в принципе.

создал ацл. разрешил нужные сети, все прочее запретил. применил ацл на управляющий влан на ядре. не помогло.

[Ilya Evseev]

поменял управляющие вланы в сегментах сети.

как защитить коммутаторы доступа со стороны доступа и со стороны ядра?

попробовал ацл - разрешил сеть/24 остальное запретил и навесил на влан (на порт не умеет) - не помогло.

как надо ?

Самый простой способ: IP шлюза в управляющем VLAN назначить серверу мониторинга, а маршрутизирующим коммутаторам не выдавать в нём адреса вообще.

После этого на сервере выстроить такой файрволл, чтобы мыш не проскочил.

Трафик в этом VLAN небольшой, причём на 90% адресован самому серверу.

[Gunner]

на длинках делается так

create access_profile profile_id 1 ip source_ip_mask 255.255.255.255 destination_ip_mask 255.255.255.0

config access_profile profile_id 1 add access_id auto_assign ip source_ip вашипилисетка destination_ip сетьуправления port 1-27 permit rx_rate no_limit

create access_profile profile_id 2 ip source_ip_mask 0.0.0.0 destination_ip_mask 255.255.255.0

config access_profile profile_id 2 add access_id auto_assign ip source_ip 0.0.0.0 destination_ip сетьуправления port 1-27 deny

[zi_rus]

на длинках делается

create cpu access_profile ...

 

но мне больше нравится

create trusted_host network ...

[vurd]

посмеялись, а теперь к делу.

ядро циска 6509 суп2.

доступ длинки 3026, 3028, 3200

управляющие вланы разнесены с клиентскими.

задача - ограничить доступ к оборудованию 3 подсетями /24, чтобы абоненты доступа к настройкам оборудования доступа не имели в принципе.

создал ацл. разрешил нужные сети, все прочее запретил. применил ацл на управляющий влан на ядре. не помогло.

 

Т.е. сейчас есть рутинг между сетями клиентов и свитчами, и всё это сходится в каталист?

В принцинпе повесив на SVI управляющих сетей ACL можно решить задачу. Что-то у вас там не так написано, покажите этот кусок конфига. Сам ACL и show run int vla <чототут>.

И, кстати, почему бы не использовать VRF?

[ingress]

создал ацл. разрешил нужные сети, все прочее запретил. применил ацл на управляющий влан на ядре. не помогло.

 

что, до сих пор пользователи управляют оборудованием? :)

на 6500 ACL надо на out делать VLAN управления, где разрешить все хосты, в конце сказать явно deny any any.

[ichthyandr]

мы управляющие вланы завели на отдельный роутер, на каталисте, агрегирующем абонентов, они не терминируются