"По просьбе телезрителей"

Питаюсь переписать правила ACL PCF на новую ревизию. Пока не получается.

Задача в упрощенном виде следующая.


1. Разрешить пари MAC-IP-ПОРТ.
2. Разрешить правильние ARP ответи с тех-же пар MAC-IP-ПОРТ.

В разрезе по байтам пакета:
1 задача.
MAC источника - с 6 по 11 байт
Тип протокола - 20 и 21 байт
IP источника - с 30 по 33 байт

2 задача
MAC отправителя - с 6 по 11 байт
Тип протокола - 20 и 21 байт
MAC источника в заголовке ARP пакета- с 30 по 35 байт
IP источника - с 36 по 39 байт

На предидущей ревизии все виглядело следующим образом (вместе с PHP кодом):


create access_profile packet_content_mask source_mac FF-FF-FF-FF-FF-FF offset1 l2 0 0xFFFF offset2 l3 8 0xFFFF offset3 l3 10 0xFFFF offset4 l3 12 0xFFFF offset5 l3 14 0xFFFF offset6 l3 16 0xFFFF offset7 l3 18 0xFFFF profile_id 10

$command='config access_profile profile_id 10 add access_id '.$rule_no.' packet_content source_mac '.$mac_original.' mask FF-FF-FF-FF-FF-FF offset1 0x0800 offset2 0x0 mask 0x0 offset3 0x0 mask 0x0 offset4 0x'.substr($ip_hex,0,4).' mask 0xffff offset5 0x'.substr($ip_hex,4,4).' mask 0xffff offset6 0x0 mask 0x0 offset7 0x0 mask 0x0 port '.$port.' permit ';

$command='config access_profile profile_id 10 add access_id '.(1000+$rule_no).' packet_content source_mac '.$mac_original.' mask FF-FF-FF-FF-FF-FF offset1 0x0806 mask 0xffff offset2 0x'.substr($mac,0,4).' mask 0xffff offset3 0x'.substr($mac,4,4).' mask 0xffff offset4 0x'.substr($mac,8,4).' mask 0xffff offset5 0x'.substr($ip_hex,0,4).' mask 0xffff offset6 0x'.substr($ip_hex,4,4).' mask 0xffff offset7 0x0 mask 0x0 port '.$port.' permit ';


Пробуем перейти на новую ревизию (используя http://dlink.ru/ru/faq/62/892.html (если я провильно понял логику)):

1 задача.
MAC источника - с 6 по 11 байт (offset_chunk №№ 2 и 3)
Тип протокола - 20 и 21 байт (offset_chunk №№ 5)
IP источника - с 30 по 33 байт (offset_chunk №№ 8 )

2 задача
MAC отправителя - с 6 по 11 байт (offset_chunk №№ 2 и 3)
Тип протокола - 20 и 21 байт (offset_chunk №№ 5)
MAC источника в заголовке ARP пакета- с 30 по 35 байт (offset_chunk №№ 8 и 9)
IP источника - с 36 по 39 байт (offset_chunk №№ 9 и 10)

Итого мне нужно 7 (семь) offset_chunk что-би ето реализовать. Даже если реализовивать только задачу №2 и не фильтровать MAC отправителя - все равно нужно 5 (пять) offset_chunk. А все есть 4 штуки offset_chunk.

Как жить дальше? Только IMPB+DHCP Snoping?

Там есть вещи, которие мне не нравятся. Я так понимаю, что сначала отрабативает IMPB+DHCP Snooping, а потом уже ACL.
Дело в том, что у меня есть потребность разрешить на всех клиентских портах доступ с IP вида 10.1.0.200-255 к серверу VPN (авторизации и.т.д.) без ограничений по макам. И единственний способ ето сделать при IMPB - использовать DHCP, что не всегда допустимо.

Кроме того, исходя из опита, самий простой способ - самий надежний и ACL PCF представляется именно таким и на протяжении вот уже 6 лет у меня с ним не возникало никаких подводних камней: есть запись - есть доступ, нет записи - нет доступа. А тут появляются дополнительние списки, условия, сервиси и т.д.

Но если нет другого способа - то придется использовать IMPB+DHCP Snooping. Жаль конечно.

Но я так понял, что старая ревизия пока еще доступна?

Я понимаю, что всем не угодишь, но ето уже не первий раз на моей памяти, когда новий дизайн чипа Ваших устройств зарезает на корню все прелесть ACL PCF. Даже мне, простому обивателю понятно, что для фильтровать пакет по 16 байтам учитивая, что только МАС, ІР источника и получателя вместе 20 байт - ето не есть нормально. А есть еще номера протоколов и портов. Кайф ACL PCF состоит в том что в условие фильтра попадают все четире утовня - от Ethernet до полезной нагрузки пакета. Пичалька.

Если бы Вы эксплуатировали эти фичи, а не изучали в теории, то поняли бы сколько негатива они, в текущей реализации,
приносят провайдерам. Постоянно блокируются клиенты на пустом месте. Если dhcp-клиент «запомнил» IP из другой сети
и шлет INFO с ним — блок. Поэтому мы используем такую схему:

Может подскажете как это реализовать на новой ревизии?
Просто уже мозг сломал. Сделали бы что-ли утилиту с человеческим лицом…

_________________
Глубина нашего невежества прямо пропорциональна степени нашей лени...

Вроде как можно.

Вре задачи кроме

можно реализовать через ethernet или ip ACL.

А #15 в новой ревизии можно (ибо надо ОДНОВРЕМЕННО фильтровать по МАС и ІР - два разних протокола) только через PCF. Итого у нас вместе 10 байт (6 МАС и 4 ІР), и на них нужно offset_chunk №№ 2 и 3 - на МАС и IP источника - offset_chunk №№ 8.

Итого:



Вроде так. На практике не проверял. Не совсем очевидно и понятно, не будет ли конфликт между правилами из PFC и ethernet,ip. Више по тексту товарищ по нещастью описал именно ситуацию с конфликтом и отсутствием его решения.

Но Вам Y0DA, повезло, и мне еще нужно сделать защиту от arp_spoofing, мне еще надо дополнительно пару offset_chunk. А их нету.

P.S. Вдруг пробежала мисль, что можно сделать два profile на ACL с разними номерами offset_chunk. Нельзя -

Пользуем ip-mac-port binding + dhcp-relay + Option82 повсеместно на des3526, des3028, des3200 почему-то без негатива.
Все тихо, мирно и спокойно. Ну, разве что, новые DIR615 не хотят после апдауна порта перезапрашивать по dhcp.

Ввстречал мнение, подтвержденное практикой, что если на порту после свича стоит еще активное оборудование (например медиаконвентор или неуправляемий свич), то после перезагрузки свича с IMPB нужно принудительно всем клиентам после активного оборудования заново получить по DHCP адреса IP, т.к. свич уже не "помнит" какие адреса DHCP через него прошли, а линк у клиентов не падал (в отличие от ситуации, когда клиенти включени непосредственно на порт).

А если експлуатировать IMPB реализованное вручную через ACL PCF, то етого еффекта нет.

P.S. Есть, правда, медиаконвентора с функцией (FLP по моему), когда при отсутствии медного линка с одной сторони, отключается линк с другой. Но мотажники очень пугаются таких конвенторов и все норовят приносить их на ремонт.

Да. Есть такая ерунда. К счастью, в моем сферичскомвакууме абоненты не снисходят до каких-то ххххаааабиков ) и сидят на солидных рутерах (линксисах, длинках и тплинках).

Вот-вот! А у нас, в силу непреодолимых препятствий 70% сети на доступе имеют кучу полууправляемых коммутаторов на портах управляемых D-Link-ов.

Уважаемые представители D-Link! Помогите пожалуйста с переделкой профилей, текущую конфигурацию я привёл.

_________________
Глубина нашего невежества прямо пропорциональна степени нашей лени...

Y0DA
При текущей реализации некоторые правила реализовать не выйдет, например ваше

полностью обрубит весь трафик, т.к. при совпадении в нескольких профилях правило deny будет иметь наивысший приоритет.
Изменение поведения планируется в середине сентября, тогда вполне можно объединить пункты #6 и #8 в один ethernet профиль, #7, #15 #30 - в другой, packet_content_mask.
Правило Deny будет отрабатывать в порядке access_id.
Защиту от сторонних DHCP серверов можно обеспечить функционалом DHCP Server Screening.

Спасибо, будем пристально ждать!

_________________
Глубина нашего невежества прямо пропорциональна степени нашей лени...

Ждать уже, видимо, бесполезно. Лучше отказаться от приобретения 32 серии раз и навсегда. А может даже от коммутаторов D-Link вовсе.

_________________
Глубина нашего невежества прямо пропорциональна степени нашей лени...

Устал ждать и я. Пришлось перейти на IMPB, немного поменять логику работи.

Но. Свичи 3200-c1 НЕ УМЕЮТ НОРМАЛЬНО работать с DHCP relay. Я имею в виду, что если клиент на порту свича запросил DHCP, то свич все правильно сформирует и отправит запрос на DHCP сервер. Но только в том случае, если свич включен НЕ НА ДРУГОЙ 3200-с1 с включеной функцией dhcp-relay. В противном случае 3200-с1, несмотря на то, что запрос уже не multicast, а unacast, все-равно его перехвативает и ничего путнего из етого не виходит. Другими словами D-Link заставляет нас включать свичи доступа напрямую в свичи агрегации. Хотя последние 10 лет можно било комбинировать. Например свич агрегации ставится на район, а на дом ставится обичний свич доступа и в него включаються такие-же свичи по подездам. И все било ок. А теперь только в свич агрегиции (то-есть не в свич серии 3200-c1 с включенним dhcp-relay. 3200-b1 или 3526 - можно )

Подводя резюме. Переписать старие правила ACL PCF на новую ревизию - нельзя. Есть альтернатива - использовать IMPB+dhcp_snooping+dhcp_relay. Но тогда нужно или менять топологию или использовать в 20% мест либо предидущую ревизию или другие свичи.

Слово в защиту 3200-c1. Тут недавно появилась новая прошивка в глубокой бете на 3200-с1, где можна некоторим портам сказать dhcp trust, и на тех портах свич будет игнорировать все пакети dhcp. То есть вроде как возвращаемся к функциналу прошивки b1 в плане работи с dhcp_relay. Я на один свич залил - вроде пока ок. Там где надо - перехвативает dhcp в multicast и отправляет на сервер. А где надо - игнорирует dhcp в unicast (уже обработание запроси другим свичем). Но на форуме говорят что в новой прошивке поменялась очередность обработки пакетов ACL и DHCP. Я пока разници не заметил. Может нужно больше времени на тест. Пока не рискую обновлять другие свичи.

P.S. Ну не дают расслабится китайци. Вот уже 10 лет как каждий год ми примеряемся к новим граблям. Но возликуйте - скоро грядет IPv6 - там граблей обещают на ^2 больше

Чего ждать?
логику работы acl в DES-3200 C1 заменили на привычную еще в 4.32

В цепочке коммутаторов dhcp relay на магистральных портах можно отключать, чтобы пакет не релеился повторно

Может быть есть смысл опубликовать подробное howto (по типу темы с прошивками) и добавлять в него текущие изменения?

Честное слово, я тоже уже запутался, как что работает в ревизии С1, и не только в ACL. C dhcp relay и dhcp local relay тоже всё настолько перепутано, что приходится работать также - только "методом научного тыка"..
И делать это приходится не на стенде, а в продакшен, т.к. немалая часть проблем вылезает только на "живой сети"..