Extended ACL на MES5324

[Sunduk]

Коллеги, доброго времени суток!
Имеется старый коммутатор Cisco, который умеет расширенные ACL. На данном коммутаторе имеется следующий ACL:

Код: Выделить всё

ip access-list extended name
permit ip host [ip server 1] host [ip vcenter]
permit ip host [ip server 2] host [ip vcenter]
permit ip host [ip server 3] host [ip vcenter]
permit ip host [комп админа] host [ip vcenter]
deny ip any host [ip vcenter]
permit ip any any


Есть необходимость перенести данный ACL на MES5324, однако, столкнулся с тем, что синтаксис вообще похоже не предполагает подобных конструкций. В двух словах надо разрешить доступ сервера 1, 2 и 3 и компа админа к серверу vcenter, а остальным запретить.

[Sunduk]

Настроил ACL следующего вида на стендовой модели, где 192.168.1.95 имитирует рабочее место админа, а 192.168.35.1 имитирует сервер, к которому нужно ограничить доступ:

Код: Выделить всё

ip access-list extended test
 permit ip any any 192.168.1.95 0.0.0.0 192.168.35.1 0.0.0.0 ace-priority 20
 deny ip any any any 192.168.35.1 0.0.0.0 ace-priority 40
 permit ip any any any any ace-priority 60

Повесил данный ACL на интерфейс шлюза сети 192.168.35.0/24, однако эффект не был достигнут, пинги до 192.168.35.1 есть не только с 192.168.1.95, но и с других адресов.
Так же заметил, что на на Eltex есть возможность установить лишь service-acl input, а вот out установить невозможно, хотя на Cisco ACL был повешен именно на out.

[Litvinova Anastasiya]

Добрый день.
Просьба уточнить, куда конкретно пробуете назначить настроенный ACL? Я предполагаю, что настраиваете ACL в interface vlan (SVI). К сожалению, на коммутаторе аппаратно не поддерживается добавление ACL на исходящий трафик в interface vlan, но, как вариант, могу предложить Вам назначить настройки ACL на входящий (input) трафик SVI в сторону хоста 192.168.1.95.

Конфигурация примет следующий вид:
1) ip access-list extended test
permit ip any any 192.168.1.95 0.0.0.0 192.168.35.1 0.0.0.0 ace-priority 20
deny ip any any any 192.168.35.1 0.0.0.0 ace-priority 40
permit ip any any any any ace-priority 60
exit
!
interface vlan xx
ip address x.x.x.x x.x.x.x
service-acl input test

[Sunduk]

В данном случае была предложена стендовая модель, там да, вешал на interface VLAN со шлюзом для сети 192.168.35.0/24 и да, в действующей модели нужен ACL именно на исходящий трафик.

Задумку понял, повесить ACL на входящий трафик другого интерфейса, но получается, что если их несколько, то вешать нужно на каждый. Сейчас попробую в стендовой модели. Но на продакшне модель намного сложнее, получается, ACL нужно будет повесить вообще на все интерфейсы.
Хотя вот боюсь, что не получится по итогу всё равно, т.к. в действующей модели interface VLAN совмещает две ip-сети, доступы между которыми так же предполагаются к настройке с ограничением доступа.

Грустно, что Cisco 2006ого года выпуска умеет ACL на исходящий трафик, а не дешёвые современные коммутаторы Eltex - нет(

Но в любом случае спасибо за ответ

[Litvinova Anastasiya]

Если в дальнейшем Вы планируете задействовать несколько входящих интерфейсов для подключающихся к серверу хостов, то могу предложить еще вариант, который поможет упростить настройку. В таком случае потребуется зеркально отразить настройки ACL и применить их только на входящий трафик interface vlan сервера.
Настройки будут выглядеть так:

ip access-list extended test
permit ip any any 192.168.35.1 0.0.0.0 192.168.1.95 0.0.0.0 ace-priority 20
deny ip any any 192.168.35.1 0.0.0.0 any ace-priority 40
permit ip any any any any ace-priority 60
!
interface vlan xx
ip address x.x.x.x x.x.x.x
service-acl input test

[Sunduk]

Реальная сеть устроена несколько сложнее, стенд лишь эмитирует основные условия для отработки правил ACL.
На стенде используется Eltex 2348B (4.0.19), в живую Eltex 5324, на котором имеется n интерфейсов VLAN, которые участвуют в маршрутизации. Однако в упрощённом виде отмасштабированная модель достаточна для проверки правил.

В стендовой модели имеются 3 сети:
192.168.1.0/24
192.168.20.0/24
192.168.35.0/24

Схему прилагаю (см. вложение).

На Router 1 статикой маршруты к сетям 20.0/24 и 35.0/24 (статикой из-за простоты стендовой железки, в данном случае не имеет значения).
На Router 2 включен ip forwarding.
На Router 2 и Eltex 2348B поднят OSPF, соседство имеется.

Проверяем доступность, пинги от 1.95 и 1.15 до 35.1 ходят.

Настраиваем 2 ACL:

Код: Выделить всё

ip access-list extended int
 permit ip any any 192.168.35.1 0.0.0.0 192.168.1.95 0.0.0.0 ace-priority 20
 deny ip any any 192.168.35.1 0.0.0.0 any ace-priority 40
 permit ip any any any any ace-priority 60


Код: Выделить всё

ip access-list extended ext
 permit ip any any 192.168.1.95 0.0.0.0 192.168.35.1 0.0.0.0 ace-priority 20
 deny ip any any any 192.168.35.1 0.0.0.0 ace-priority 40
 permit ip any any any any ace-priority 60


Интерфейсы для сетей на Eltex 2348B следующие:

Код: Выделить всё

interface vlan 20
 ip address 192.168.20.253 255.255.255.0
exit
!
interface vlan 35
 ip address 192.168.35.254 255.255.255.0
exit


Итак, в первом случае вешаем service-acl input ext на interface vlan 20, в таком случае от 1.95 до 35.1 пинги ходят, остальное отбрасывается, в целом подходит, но в боевой модели несколько interface vlan, получается, такой ACL придётся вешать на каждый, что так же создаст дополнительную нагрузку. От части подходит, но с костылями.

Во втором случае вешаем service-acl input int на interface vlan 35, на 1.15 пинги до 35.1 сразу обрубаются, а на 1.95 проходит пингов 10-15, после чего они так же пропадают по не понятным мне причинам оО
Собственно, по этому типу я изначально и пытался построить фильтрацию траффика, а в следствии неудачи обратился на форум.
Может быть ещё промежуточные интерфейсы нужно добавлять в разрешённые по ACL (1.235, например)? Но тогда это усложняет настройку дополнительными костылями.

А в чём вообще проблема дописать в одной из следующих прошивок возможность service-acl output? На Cisco 2006 года выпуска модель ACL работает именно по такому принципу без каких-либо костылей.

[Sunduk]

Может быть ещё промежуточные интерфейсы нужно добавлять в разрешённые по ACL (1.235, например)?

Добавил, картина аналогичная, пингов 5-10 пролетает и связь теряется. Тоже самое, если добавить ещё и шлюз 1.1. Так что моё предположение было не верно и модель всё же не рабочая.
Самым адекватным всё же таки выглядит вариант со стороны разработчиков добавить в одной из следующих прошивок возможность фильтра на исходящий трафик.
Была ещё мысля на другую железку повесить шлюз в реальной сети на Eltex ESR-1500, архитектура сети позволяет, но там так же имеется только service-acl input(

[Litvinova Anastasiya]

Добрый день.
Как мной уже ранее говорилось, добавить настройку ACL в output interface vlan нет возможности, это вызвано аппаратным ограничением чипа.
Касаемо Вашей ситуации с настройкой ACL, хотелось бы более детально разобраться, чем конкретно вызвана неработоспособность схемы с предложенным мной решением по настройке ACL на interface vlan сервера. Просьба завести заявку по форме https://eltex-co.ru/support. Помимо схемы и описания, которые приложены Вами на форуме, просьба также выполнить следующие рекомендации, результаты отразить в заявке:
1. Вывод команды show tech-support с коммутатора MES2348B текстовым файлом.
2. Вывод таблиц ARP на MES2348B и сервере 192.168.35.1 в момент, когда нет ACL int на interface vlan 35, и затем такой же вывод после добавления ACL, в момент пропадания пинга.
3. Добавить следующую настройку в ip access-list extended int: permit ip any any 192.168.35.1 0.0.0.0 192.168.20.254 0.0.0.0 ace-priority 30, применить ACL на SVI в сторону сервера и проверить, будет ли пропадать пинг с сервера до хоста 192.168.20.254.
4. На сервере поставить на постоянный пинг хост 192.168.1.95. Далее снять дамп на сервере при помощи утилиты Wireshark, захватив им полностью ситуацию с момента, когда ACL еще не назначен на SVI в сторону сервера, до момента, когда после назначения ACL сначала пинг есть, а затем пропадает. Приложить дамп в заявку.

[Sunduk]

Добрый день!

После добавления дополнительно разрешающего правила permit ip any any 192.168.35.1 0.0.0.0 192.168.20.254 0.0.0.0 схема заработала, пинги пошли, спасибо!

Данный ACL был установлен на interface VLAN 20, в предложенной ранее схеме этого достаточно. За неимением свободного оборудования у меня отсутствует возможность собрать более полную стендовую модель, работа ACL в которой меня интересует, поэтому просто зарисую её схематично (см. приложение).

В данной стендовой схеме имеются три объекта, обозначим их как центральный объект, филиал 1 и филиал 2. Объекты объединены по OSPF двумя малыми сетями (/30), а именно 192.168.4.0/30 между центральный объектом и филиалом 1 и 192.168.5.0/30 между центральным объектом и филиалом 2.

На центральном объекте имеется три ЛВС:
192.168.0.0/24 обозначим данную сеть как серверный сегмент, шлюз 192.168.0.254, расположен на interface VLAN 1 Switch Agregation.
192.168.1.0/25 обозначим данную сеть как сеть доступа 1, шлюз 192.168.1.126/25, расположен на cаб-интерфейсе Router 1 gi1.1.
192.168.1.128/25 обозначим данную сеть как сеть доступа 2, шлюз 192.168.1.254/25 расположен на interface VLAN 2 Switch Agregation.

(да, было бы логичнее вынести серверы в отдельный VLAN и повесть все шлюзы на маршрутизатор саб.интерфейсами, но интересует решение именно в таком виде, поэтому предлагаю данную не идеальную схему)

В серверном сегменте имеется n серверов (нарисовал два для примера), серверы подключены непосредственно к Switch Agregation:
Server 1.1 - 192.168.0.253/24
Server 1.2 – 192.168.0.252/24

Имеется два коммутатора доступа, подключенные к Switch Agregation:
Switch Access 1.1 – interface VLAN 1 – 192.168.1.124/25
Switch Access 1.2 – interface VLAN 1 – 192.168.1.123/25

(да, тут было бы лучше вынести отдельную сеть управления, но интересует именно в таком виде)

К каждому из коммутаторов доступа подключены рабочие станции:

Switch Access 1.1:
АРМ Администратора – 192.168.1.1/25 (VLAN 1)
АРМ пользователя 1.1 – 192.168.1.129/25 (VLAN 2)
АРМ пользователя 1.2 – 192.168.1.2/25 (VLAN 1)

Switch Access 1.2:
АРМ пользователя 2.1 – 192.168.1.3/25 (VLAN 1)
АРМ пользователя 2.2 - 192.168.1.130/25 (VLAN 2)

На филиале 1 и 2 имеются по одной ЛВС, в каждой из которых расположены как сервер, так и рабочие станции.

Задачи следующие:
1. Обеспечить информационный обмен между АРМ Администратора (Центральный объект, 192.168.1.1) и Server 1.1 (Центральный объект, 192.168.0.253)
2. Обеспечить информационный обмен между Server 2 (Филиал 1, 192.168.2.252) и Server 1.1 (Центральный объект, 192.168.0.253)
3. Обеспечить информационный обмен между Server 3 (Филиал 2, 192.168.3.252) и Server 1.1 (Центральный объект, 192.168.0.253)
4. Сохранить информационной обмен внутри сети серверного сегмента (Центральный объект, 192.168.0.0/24), включая Server 1.1 (Центральный объект, 192.168.0.253).
5. За исключением Server 1.1 (Центральный объект, 192.168.0.253), обеспечить информационной обмен между сетью серверного сегмента (Центральный объект, 192.168.0.0/24) и всеми остальными сетями.
6. Запретить доступ к Server 1.1 (Центральный объект, 192.168.0.253) от всех адресов, кроме сети серверного сегмента центрального объекта и отдельно взятых указанных выше адресов (АРМ Администратора, Server 2, Server 3).

На Cisco в роли Switch Agregation данная задача изящно решается в один ACL на один интерфейс одного коммутатора:

Код: Выделить всё

ip access-list extended access_sever1
permit ip host 192.168.1.1 host 192.168.0.253
permit ip host 192.168.2.252 host 192.168.0.253
permit ip host 192.168.3.252 host 192.168.0.253
deny ip any host 192.168.0.253
permit ip any any

interface VLAN 1
ip address 192.168.1.125 255.255.255.128
ip address 192.168.0.254 255.255.255.0 secondary
ip access-group access_server1 out


Однако, как мы выяснили, на Eltex это так не работает из-за ограничений чипов (это на всех моделях Eltex так?).
Получается в случае с Eltex в роли коммутатора агрегации с возможностью вешать ACL только на входящий трафик, вероятно, потребуется следующий ACL:

Код: Выделить всё

ip access-list extended access_server1
permit ip any any 192.168.0.253 0.0.0.0 192.168.1.126 0.0.0.0
premit ip any any 192.168.0.253 0.0.0.0 192.168.1.1 0.0.0.0
permit ip any any 192.168.0.253 0.0.0.0 192.168.2.252 0.0.0.0
permit ip any any 192.168.0.253 0.0.0.0 192.168.3.252 0.0.0.0
deny ip any any any 192.168.0.253 0.0.0.0 any
permit ip any any any any


А теперь вопросы:
1. Надо ли дополнительно явно создавать правило permit ip any any 192.168.0.253 0.0.0.0 192.168.0.0 0.0.0.255 в этот ACL для того, чтобы внутри 192.168.0.0 был доступ к 192.168.0.253? По идее одна и та же сеть, я так думаю, что не нужно, но лучше получить точный ответ)
2. Куда вешать ACL: и на interface VLAN 1, и на interface VLAN2? Особенно интересно с учётом, что interface VLAN 1 на Switch Agregation является шлюзом серверного сегмента, а так же имеет адрес из сети доступа 1.
3. Надо ли так же добавлять в ACL в разрешённые адреса коммутаторов доступа (Switch Access 1.1 (192.168.1.124/25) и 1.2 (192.168.1.123/25))?

Код: Выделить всё

permit ip any any 192.168.0.253 0.0.0.0 192.168.1.123 0.0.0.0
permit ip any any 192.168.0.253 0.0.0.0 192.168.1.124 0.0.0.0


4. Не потребуется ли дополнительных ACL на коммутаторах доступа, чтобы ограничить в доступе к Server 1 (192.168.0.253) всех, кроме АРМ Администратора (192.168.1.1) за коммутаторами доступа?

А ещё отдельно:
Предположим, что Router 1 - это Eltex ESR 1500. На нём так же не обнаружил service-acl output, однако имеются service-policy output. Возможно ли как-то связать ACL и service-policy? Может, в случае переноса шлюза серверного сегмента на данное устройство можно создать более изящный ACL, а не городить инвертированный огород с костылями?

[Litvinova Anastasiya]

Добрый день.
Просьба завести заявку по форме https://eltex-co.ru/support. Помимо схемы и подробного описания проблемы, просьба в заявке также отразить результаты по всем даваемым мной ранее рекомендациям.