[Shiva]

надо пакеткнтеншн маск на абонентских порах, которы заблокируют только PADO

[SpiderX]

mcdemon

 

Подскажи еще такую вещь. Как сделать правило что-бы в управляющем влане разрешался весь трафик, то-есть не фильтровался ацл.

А зачем?

Управляющий влан, и как следствие трафик, должны быть только на аплинках, а не на клиентских портах.

Зачем разрешать в ACL то, чего никогда не будет?

 

slavikeks

Вот это правило лишнее. В него скорее всего никогда трафик не попадет.

create access_profile ip udp dst_port_mask 0xFFFF profile_id 2

config access_profile profile_id 2 add access_id auto_assign ip udp dst_port 68 port 1-24 deny

config access_profile profile_id 2 add access_id auto_assign ip udp dst_port 67 port 1-24 permit

В правилах профиля 1 сначала запрещаются все пакеты с портом источника 67, а потом разрешаются все пакеты с портом источника 68. Иначе говоря, на клиентских портах блокируются dhcp сервера, и разрешаются dhcp клиенты.

В правилах профиля 2 сначала запрещаются все пакеты, предназначенные dhcp клиентам, и разрешаются пакеты, предназначенные dhcp серверу.

Правило 2.1 вряд ли когда-то сработает так как ACL работают только на входящий трафик, и я сомневаюсь, что кто-то с клиентского порта пошлет пакет с портом назначения 68. Но как для перестарховки, то не помешает.

Правило 2.2 тоже вряд ли когда-то сработает, так как пакеты с портом назначения 67 как правило имеют порт источника 68, и они пройдут через правило 1.2, и до правила 2.1 просто не дойдут. Опять же таки для перестарховки - не помешает, но тогда рекомендую добавить к правилу counter enable.

 

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

Лучше всего адаптировать к вашим ACL правила из http://d-link.ru/ru/faq/62/206.html

Можно иначе, блокируя PADO пакеты с клиентских портов, но это можно только через PCF:

create access_profile packet_content_mask offset1 l2 0 0xffff offset2 l3 0 0x00ff profile_id 1

config access_profile profile_id 1 add access_id 1 packet_content offset1 0x8863 offset2 0x0007 port 1-24 deny

 

P.S. Я надеюсь вопрос был задан в контексте DES-3200.

[slavikeks]

Большое спасибо

create access_profile packet_content_mask offset1 l2 0 0xffff offset2 l3 0 0x00ff profile_id 1

config access_profile profile_id 1 add access_id 1 packet_content offset1 0x8863 offset2 0x0007 port 1-24 deny

работает на ура на 3200 но у нас ещё есть 3028 попробывал сделать как тут http://d-link.ru/ru/faq/62/206.html но на строчке

# Разрешаем PPPoE-session пакеты от клиентов к серверу
config access_profile profile_id 9 add access_id 300 ethernet destination 6c-62-6d-b5-00-37 ethernet_type 0x8864 port 1-24 permit

свитч отвечает

No enough room for this rule!

при этом пппое через аплинки поднимается, а на абонентских блокируется.

[SpiderX]

для DES-3028:

create access_profile packet_content_mask offset_0-15 0x0 0x0 0x0 0xffff00ff profile_id 1

config access_profile profile_id 1 add access_id auto_assign packet_content offset 12 0x88630007 port 1-24 deny

[mcdemon]

mcdemon

 

Подскажи еще такую вещь. Как сделать правило что-бы в управляющем влане разрешался весь трафик, то-есть не фильтровался ацл.

А зачем?

Управляющий влан, и как следствие трафик, должны быть только на аплинках, а не на клиентских портах.

Зачем разрешать в ACL то, чего никогда не будет?

Дело в том, что есть еще даунлинки. А там часто бывают например дес2108 на которых нет ацл.

+ иногда для настройки ресетнутого дес-2108 мне необходимо ввести порт на него, в нетегированный влан в котором находится управление.

 

Вообщем надо :)

Изменено 20 апреля, 2012 пользователем mcdemon

[slavikeks]

Большое Вам спасибо за помощь! Всё работает.

Возможно не в тему, есть такой вопрос. Хочу сеть разбить на сегменты на Л3 свитче делаю маршрутизацию между вланами. Вот как сделать чтобы pppoe работало в о всех сегментах? Единственное, что пришло в голову, это прокидывать по влану от pppoe сервера в сегмент.

Ещё раз извиняюсь за оффтоп.

[SpiderX]

mcdemon

На даунлинки в общем случае можно первым правилом вешать этот ACL:

create access_profile packet_content_mask c_tag 0xffff offset1 l2 0 0xFFFF profile_id 1

config access_profile profile_id 1 add access_id 1 packet_content c_tag 0x0faa offset1 0x0 port 1 permit

указывая в нем VLANID mgmt vlan'а.

 

иногда для настройки ресетнутого дес-2108 мне необходимо ввести порт на него, в нетегированный влан в котором находится управление.

Если это действительно иногда, то проще удалять ACL с порта, настраивать свитч, и возвращать ACL.

В противном случае надо к чему-то привязываться для отфильтровки дес2108, к их mac-адресам, к ip-адресам, в которых находятся свитчи.

Можно попробовать написать ACL для пропуска трафика c ip-адресом источника 10.90.90.90, но тогда при настройке 2108, как минимум, ipif System придется настраивать последним.

 

Возможно не в тему, есть такой вопрос. Хочу сеть разбить на сегменты на Л3 свитче делаю маршрутизацию между вланами. Вот как сделать чтобы pppoe работало в о всех сегментах?

Можно пробовать PPPoE Relay / Protocol-based vlan.

Изменено 20 апреля, 2012 пользователем SpiderX

[mcdemon]

mcdemon

На даунлинки в общем случае можно первым правилом вешать этот ACL:

 

Цитата

create access_profile packet_content_mask c_tag 0xffff offset1 l2 0 0xFFFF profile_id 1

config access_profile profile_id 1 add access_id 1 packet_content c_tag 0x0faa offset1 0x0 port 1 permit

 

указывая в нем VLANID mgmt vlan'а.

 

можно на все порты его ведь вешать? ничего страшного если на абонентский порт попадет это правило, ведь я на абонентские порты не делаю mgmt vlan

[SpiderX]

можно на все порты его ведь вешать? ничего страшного если на абонентский порт попадет это правило, ведь я на абонентские порты не делаю mgmt vlan

Можно.

[mcdemon]

# Allow ARP Request From 172.20.0.0/16

config access_profile profile_id 2 add access_id 8 packet_content offset1 0x0806 offset2 0xAC14 port 1 permit counter enable

config flow_meter profile_id 2 access_id 8 rate 64 rate_exceed drop_packet

 

подскажи как переделать на свою подсеть? я не разбираюсь как перевести подсеть в вид 0xAC14 :)

[zhenya`]

DEC HEX

172 = AC

20 = 14.

Изменено 21 апреля, 2012 пользователем zhenya`

[mcdemon]

10.0.0.0/8

176.100.128.0/19

как в этот вид привести?

 

и еще вопрос 0x0806 - это типа уточняется, что ethernet?

[AlKov]

To SpiderX, а Вы не ошиблись в смещениях offset2 и offset3 profile 2?

create access_profile packet_content_mask destination_mac FF-FF-FF-FF-FF-FF offset1 l2 0 0xFFFF offset2 l3 14 0xFFFF offset3 l3 16 0xFFFF profile_id 2

# Allow ARP Request From 172.20.0.0/16

config access_profile profile_id 2 add access_id 8 packet_content offset1 0x0806 offset2 0xAC14 port 1 permit counter enable

Я так понимаю, здесь подразумевается src ip address. А если верить этому, src ip начинается со смещения 12 L3, а по смещению 16 находятся первые два байта уже dst ip.

Или я что-то не учёл??

 

P.S.

10.0.0.0/8

176.100.128.0/19

как в этот вид привести?

Для 10.0.0.0/8

config access_profile profile_id 2 add access_id auto_assign packet_content offset1 0x0806 offset2 0x0A00 mask 0xff00 port 1 permit

для 176.100.128.0/19

config access_profile profile_id 2 add access_id auto_assign packet_content offset1 0x0806 offset2 0xB064 mask 0xffff offset3 0x8000 mask 0xE000 port 1 permit

и еще вопрос 0x0806 - это типа уточняется, что ethernet?

Типа да. :)

[mcdemon]

Типа да. :)

а нет, 806 этож ARP :)

[SpiderX]

AlKov

 

To SpiderX, а Вы не ошиблись в смещениях offset2 и offset3 profile 2?

Не ошибся. Это легко проверить. Возьмите это правило, вместо deny сделайте permit counter enable. И смотрите на счетчик.

Вот счетчик с одного из моих свитчей:

Access ID : 8

Ports : 1-6

Mode : Permit RX_Rate 64k bps

Counter : 66

Offset1 Value: 0x0806 Mask: 0xFFFF

Offset2 Value: 0xAC14 Mask: 0xFFFF

 

Я так понимаю, здесь подразумевается src ip address. А если верить этому, src ip начинается со смещения 12 L3, а по смещению 16 находятся первые два байта уже dst ip.

Или я что-то не учёл??

Да, src ip.

Я не могу сейчас посмотреть ссылку, сайт лежит. Но, когда я писал ACL, я нашел много неточностей в мануалах от D-Link, на их форуме. К тому же большую путаницу вносил тот факт, что часть информации об ACL относится к одной серии, часть к другой, а поведение в разных сериях разное. Поэтому я просто решил, что надежней при написании ACL будет проверять их реальное поведение на реальных пакетах.

При использовании смещений 12 и 14 для поля L3 пакеты в правило не попадали, а работало все корректно при использовании смещений 14 и 16.

Как я помню, где-то написано, что поле L3 начинается после окончания ethertype, а где-то написано, что оно начинается с указания типа протокола. И разница между этими двумя формулировками как раз 2 байта, которые отводятся на поле Hardware Type.

Я сейчас захватил парочку пакетов с NAS'а, вот их скриншот.

красным выделен ethertype, зеленым — src ip.

Если начинать отсчет с учетом поле HType, то смешение на 14 байт приходится как раз на "AC".

 

P.S. Дамп тоже прикрепил к сообщению, можете проиграть его packet player'ом в свитч.

 

mcdemon

и еще вопрос 0x0806 - это типа уточняется, что ethernet?

Тут уточняется Ethertype, то, что это Ethernet, как раз указывается в поле Hardware Type.

 

10.0.0.0/8.

Все октеты из десятичной переводим в 16-ричную систему счисления. Это можно сделать любым калькулятором.

10 - A0

0 - 00

Так как маска сети включает в себя все возможные комбинации ip-адресов, содержащие 10 в первом октете, то третий и четвертый байты в третьем смещении можно игнорировать.

Но поскольку в ACL правиле будет фигурировать поле A000 из-за того, что в профиле для этого правила задано учитывать оба байта (create access_profile packet_content_mask destination_mac FF-FF-FF-FF-FF-FF offset1 l2 0 0xFFFF offset2 l3 14 0xFFFF offset3 l3 16 0xFFFF profile_id 2 ), то нужно повесить на данное поле маску, в которой указать, что значащим должен быть только первый байт, а второй может быть любым.

В противном случае правило отрабатывало бы только для сетей, начинающихся на 10.0.

Маска в данном случае очень простая - 0xff00.

Рассчитывается так:

1. Переводим в двоичную систему счисления:

A000 - 1010000000000000 (минимальный адрес, который нужно покрыть - 10.0)

A0FF - 1010000011111111 (максимальный адрес, который нужно покрыть - 10.255)

2. Выделяем общие биты:

10100000|00000000

10100000|11111111

3.Совпадающий биты заменяем единицами, разнящиеся - нулями.

10100000|00000000

10100000|11111111

-----------------

11111111|00000000

4. Запишем полученную маску в 16-ричной системе.

1111111100000000 = 1111 1111 0000 0000 = F F 0 0 = 0xFF00

 

176.100.128.0/19.

176 - B0

100 - 64

128 - 80

0 - 00

Тут маска сети перекрывает сети от 176.100.128 до 176.100.159 включительно.

Разнятся только третий и четвертый октеты ip-адреса, значит маска нужна только для третьего и четвертого байтов ip-адреса в 3 смещении в ACL правиле.

 

128.0   - 8000 - 100|0000000000000
159.255 - 9FFF - 100|1111111111111
----------------------------------
                111|0000000000000 = 1110 0000 0000 0000 = E 0 0 0 = 0xE000

Для 3 смещения маска будет 0xE000.

 

Конечные правила уже написал AlKov.

arp.txt

Изменено 22 апреля, 2012 пользователем SpiderX

[AlKov]

Не ошибся. Это легко проверить. Возьмите это правило, вместо deny сделайте permit counter enable. И смотрите на счетчик.

Сделал (добавил счетчик к уже работающему правилу). Смотрим -

Access ID : 12
Ports     : 1-9
Mode      : Permit
Counter   : 40
Destination MAC:      00-00-00-00-00-00         Mask: 00-00-00-00-00-00
Source MAC:           00-00-00-00-00-00         Mask: 00-00-00-00-00-00
Offset1  Value:       0x0011                    Mask: 0x00FF
Offset2  Value:       0x0000                    Mask: 0x0000
Offset3  Value:       0x0000                    Mask: 0x0000
Offset4  Value:       0x0AFE                    Mask: 0xFFFF
Offset5  Value:       0xD507                    Mask: 0xFFFF
Offset6  Value:       0x0035                    Mask: 0xFFFF

Вот такое правило

create access_profile  packet_content_mask   destination_mac FF-FF-FF-FF-FF-FF  source_mac FF-FF-FF-FF-FF-FF  offset1 l3 8 0xFF  offset2 l3 12 0xFFFF  offset3 l3 14 0xFFFF  offset4 l3 16 0xFFFF  offset5 l3 18 0xFFFF  offset6 l4 2 0xFFFF  profile_id 8
....
config access_profile profile_id 8  add access_id 12  packet_content   destination_mac 00-00-00-00-00-00  mask 00-00-00-00-00-00 source_mac 00-00-00-00-00-00
mask 00-00-00-00-00-00 offset1 0x0011   mask 0x00ff offset2 0x0000   mask 0x0000 offset3 0x0000   mask 0x0000 offset4 0x0afe   mask 0xffff offset5 0xd507
mask 0xffff offset6 0x0035   mask 0xffff port 1-9 permit counter enable

Как видим, тоже работает!! Правда у меня не src, а dst ip (доступ к DNS 10.254.213.7), но суть дела не меняет - используется именно смещение 16-18 L3.

Я сейчас захватил парочку пакетов с NAS'а, вот их скриншот.

А где Вы смотрели пакеты? Явно не "внутри" коммутатора. Это я к тому, что если верить опять же мануалу от dlink, внутри коммутатора пакет смещается

Т.к внутри свитча пакеты всегда тегированы, вне зависимости от того назначали вы тег или нет, то заполним символами „х“ данные с 12 по 15 байт (в свитче эти байты заполняются информацией о VLAN). Обратите внимание - у Вас в этих байтах могут быть данные, которые Вы захотите использовать для написания ACL:

 

0000 00115b4f 219f0011 5b31b9e7 xxххххxx

0010 08004500 00305b91 40008006 1d7bc0a8

0020 0065c0a8 00060746 01bdbee9 ca670000

0030 00007002 ffff6f0f 00000204 05b40101

0040 0402

 

Как видите информация относительно исходного варианта сместилась. Теперь сократим запись оставив только то, что нужно:

 

0010 08004500 00305b91 40008006 1d7bc0a8

0020 0065c0a8 00060746 01bdbee9 ca670000

Ну и тот ACL, вырезку из которого я привел выше, работает исправно уже более года..

Вообщем, я в ступоре, не знаю теперь кому и чему верить.. :)

Может еще раз вместе перечитаем дилинковские мануалы по pcf?

 

P.S. Мои ACL с DES-3200-10(18).

Изменено 22 апреля, 2012 пользователем AlKov

[SpiderX]

А где Вы смотрели пакеты?

Я написал: захватывал их на клиентском сервере доступа.

 

Это я к тому, что если верить опять же мануалу от dlink, внутри коммутатора пакет смещается

Это вот как раз то, о чем я тоже писал:

что часть информации об ACL относится к одной серии, часть к другой, а поведение в разных сериях разное.

Вот это к DES-3200 отношения скорее всего не имеет, и, если я не ошибаюсь, было написано во времена DES-3526, в котором такие смещения учитывать надо.

В DES-3200 смещений из-за vlanid нет, так как в нем присутствуют поля L2, L3, L4, которые позволяют как раз этих смещений избежать.

К тому же у нас тут заминка из-за смещения на 2 байта, а поле vlanid - это 4 байта.

 

Может еще раз вместе перечитаем дилинковские мануалы по pcf?

Начать, я думаю, стоит, по традиции, с версий прошивок. У меня 1.5, и кое-где 1.6 ветки.

 

На какой конкретно прошивке используется приведенное правило?

[AlKov]

На какой конкретно прошивке используется приведенное правило?

 

В 99% - Firmware Version : Build 1.52.B008

Есть 2-3 коммутатора с 1.60.B009, но похоже сиё не принципиально.

К тому же у нас тут заминка из-за смещения на 2 байта, а поле vlanid - это 4 байта.

Это как так, откуда такая информация?? По той же дОке о 3200 - c_tag (как я понимаю, тот самый vlanid) = 2 байта.

 

P.S. Что-то мне "грезится", что L2, L3 и L4 - это интерпретация только D-Link и я лично склонен верить этому документу, т.к он РАБОТАЕТ..

И самое непонятное - почему работает ACL, который я озвучил выше??

 

P.P.S. Завтра напишу на форум dlink об этом. Посмотрим ответы от производителя..

Изменено 22 апреля, 2012 пользователем AlKov

[SpiderX]

Это как так, откуда такая информация?? По той же дОке о 3200 - c_tag (как я понимаю, тот самый vlanid) = 2 байта.

Не совсем точно выразился, подразумевал 802.1q, так как именно с ним работают в этом примере;

Т.к внутри свитча пакеты всегда тегированы, вне зависимости от того назначали вы тег или нет, то заполним символами „х“ данные с 12 по 15 байт (в свитче эти байты заполняются информацией о VLAN).

С 12 по 15 - это четыре байта, то есть 802.1q целиком, а не только его часть — поле VID.

 

По той же дОке о 3200 - c_tag (как я понимаю, тот самый vlanid) = 2 байта.

Правильно, через c_tag всегда можно обратиться к внутреннему тегу, не обращая внимания ни на какие смещения.

Точно также как с помощью поля L2 всегда можно обратиться к Ethertype, и т.д.

 

и я лично склонен верить этому документу, т.к он РАБОТАЕТ..

И я склонен верить этому документу, там четко описано, что эти ACL для DES-3200. Там приведен синтаксис с полями L2/L3/L4, который появился только начиная с DES-3200.

А вот чего нет в этом документе, так как это работы с src ip и/или c dst ip.

[AlKov]

А вот чего нет в этом документе, так как это работы с src ip и/или c dst ip.

Не могу не согласиться. Но по картинке из той же докИ видно невооруженным глазом, что первый байт src ip 192.168.0.221 находится именно по смещению 12 L3, а dst ip 192.168.0.220 - соотв. с 16-го..

Или это не всегда соответствует действительности?

 

P.S. "Замечательный" ответ на вопрос где в L3 находятся src/dst ip от ТП D-Link

Отсчитывайте от L2 - это поле ethertype. L3 начинается сразу после ethertype в пакете.

:-)

Изменено 23 апреля, 2012 пользователем AlKov

[AlKov]

SpiderX, кажется я нашел причину наших разногласий.

Ваше правило составлено для ARP пакета, а мое для IP. И выходит, что "победила дружба". :)

Посмотрите снифером у себя какой-нибудь IP пакет, ну например тот же самый udp к DNS.

Что-то мне грезится, что в нем src ip окажется на "моём" месте...

[SpiderX]

Я думаю это лишнее, т. к. у меня есть профиль

create access_profile packet_content_mask offset1 l3 8 0x00FF offset2 l3 16 0xFFFF offset3 l3 18 0xFFFF offset4 l4 2 0xFFFF profile_id 3

и к нему правило

config access_profile profile_id 3 add access_id 16 packet_content offset2 0x5bc1 offset3 0x4504 mask 0xFFFE port 1 permit counter enable

Смещения на 16 и 18 байт, это dst ip. UDP пакеты к DNS идут сюда.

Изменено 23 апреля, 2012 пользователем SpiderX

[Fenrir]

Кстати, удавалось ли кому отфильтровать LLMNR (TCP/UDP #5355) на абонентских портах?

Пробовал на 1228/ME HW-A2 блокировать по dst port и по dst IP + dst port но пакеты упорно пролетают мимо фильтра. Есть подозрение что ACL не срабатывают потому что адрес назначения не Unicast. Кому нибудь удавалось решить этот вопрос? Научите плохому...

[Ivan_83]

TCP бывает только юникастовым.

[SpiderX]

Кому нибудь удавалось решить этот вопрос?

config multicast port_filtering_mode all filter_unregistered_groups

limited multicast group

Ну или cpu acl использовать.

 

In responding to queries, responders listen on UDP port 5355 on the following link-scope Multicast address:

IPv4 - 224.0.0.252, MAC address of 01-00-5E-00-00-FC

IPv6 - FF02:0:0:0:0:0:1:3 (this notation can be abbreviated as FF02::1:3), MAC address of 33-33-00-01-00-03

The responders also listen on TCP port 5355 on the unicast address that the host uses to respond to queries.

Ну и порт 5355 по tcp тоже закрыть нужно через acl.

Изменено 4 июля, 2012 пользователем SpiderX