SpiderX

xeb Отлично. Работает. Спасибо! Вроде все задуманное сейчас работает. Осталось только проблему с connlimit_check на x86 побороть.

xeb Я просто такой логики, что range - для немаршрутизируемых ip, сразу как-то не отследил :) Вариант с chap-secrets меня полностью устраивает, но есть проблема. Из IPoE_ru: Выгрузил ipoe.ko Конфиг: Лог: Если в конфиге сделать interface=re:vlan[0-9]{4},range=какой-то range, выдает адреса из этого рейнджа, и мы возвращаемся к моей проблеме "На vlan0002 он выдает 192.0.2.18, и на vlan0003 он выдает 192.0.2.18." :) Замкнутый круг какой-то :) Т.е. не выдавать клиенту локальный IP не получается, он является обязательным судя по всему.

nik247 Спасибо. А при какой конфигурации accel-ppp достигается такой эффект: eth1.25 | eth1.25 | 08:00:27:f2:5c:1e | 10.206.252.8[b]3[/b] | 4000/4000 | ipoe | | active | 09:27:06 eth0.24 | eth0.24 | 00:0c:42:34:39:3f | 10.206.252.8[b]2[/b] | 4000/4000 | ipoe | | active | 09:27:02 ? Адреса выдает другой dhcp-сервер или радиус? Как я вижу в режиме mode=L2,shared=0 accel-ppp не может сам выдавать адреса, чтобы реализовать ip unnumbered (хотя тут описано, что такой режим поддерживается). Верно? mode=L2 shared=0 start=dhcpv4 ifcfg=1 interface=vlan0002,range=192.0.2.16/28 interface=vlan0003,range=192.0.2.16/28 На vlan0002 он выдает 192.0.2.18, и на vlan0003 он выдает 192.0.2.18. range отличный от маски /30 он не парсит, т.е. interface=vlan0002,range=192.0.2.18/32 interface=vlan0003,range=192.0.2.19/32 не проходит. При shared=1 выдает адреса из пула как положено. Баг с shared=0 ? P.S. Патч к ipoe.ko, не собирался с ядром выше 3.7. В 3.7 структуры поменяли. http://pastebin.com/4B0LFC86

Почитал форум, понял, что мало понял логику работы accel-ppp. Открыл для себя, что должен судя по форуму создаваться интерфейс *.ipoe, у меня он не создается. Кто-то может поделится рабочим конфигом accel для ipoe mode=L2, ifcfg=1 или 0, shared=0 ? accel-ppp стартует с такой ошибкой: это может быть причиной того, что не создается *.ipoe? И что ему собственно надо?

xeb 1. Забыл главное сказать - accel-ppp не стартует, в логе только вот эта ошибка. Если закомментировать вызов connlimit_check: и пересобрать pptp модуль, то все сразу становится хорошо. На том же ядре, ОС, на той же версии компилятора, но на архитектуре amd64 все работает без проблем. 2. Работает. Спасибо. А есть планы по ip unnumbered? Сейчас dhcp-серверу в accel-ppp нужен обязательно диапазон, если бы можно было указать конкретный ip, который нужно выдать с возможностью указать произвольную маску, например так: interface=vlan0002,mode=L2,shared=0,start=dhcpv4,host=192.0.2.18/24,range=192.0.2.1/24,ifcfg=0 interface=vlan0003,mode=L2,shared=0,start=dhcpv4,host=192.0.2.19/32,range=192.0.2.1/24,ifcfg=0 а из range взять только шлюз по умолчанию для клиента, который получит эти настройки, то собственно больше ничего и не надо. При старте сессии accel-ppp создаст маршруты 192.0.2.18 dev vlan0003 src 192.0.2.1 192.0.2.19 dev vlan0003 src 192.0.2.1 сейчас он создает их без указания src. Для режима работы ifcfg=1, наверно надо будет создать интерфейс, и повестить на него ip шлюза, ну или нужна директива, в которой указать на какой интерфейс повесить этот ip. Сейчас такое поведение можно скорее всего получить для варианта, когда accel-ppp работает в качестве dhcp-relay, а настройки выдавать клиенту будет конечный dhcp-сервер на основе интерфейса, и он же по событию сможет прописать маршрут, но для accel-ppp такой функционал без дополнительного dhcp-сервер был бы нелишним.

1. Есть проблемы со сборкой на x86: которые вылеваются в: Параметры сборки: На версии из На последнем релизе (1.7.3) такое же поведение. 2. Хотел заставить работать ipoe в режиме mode=L2, shared=0, ifcfg=0. Сетевые настройки выдает accel-ppp, аутентификации нет. Конфиг: Лог: возможно не правильно использую секцию [auth], но никакой информации, кроме как упоминания в changelog на sf и на 150-х страницах тут, о ней нет. В мане ее тоже нет. Она вообще работает?

Проблема не в этом, в этом решение конкретно взятой проблемы.

Вот на них и настроить: config filter dhcp_server ports <CLIENTS> state enable config filter dhcp_server ports <UPLINK> state disable config filter dhcp_server illegal_server_log_suppress_duration 5min config filter dhcp_server trap enable config filter dhcp_server log enable

config multicast port_filtering_mode all filter_unregistered_groups limited multicast group Ну или cpu acl использовать. Ну и порт 5355 по tcp тоже закрыть нужно через acl.

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

Не совсем точно выразился, подразумевал 802.1q, так как именно с ним работают в этом примере; С 12 по 15 - это четыре байта, то есть 802.1q целиком, а не только его часть — поле VID. Правильно, через c_tag всегда можно обратиться к внутреннему тегу, не обращая внимания ни на какие смещения. Точно также как с помощью поля L2 всегда можно обратиться к Ethertype, и т.д. И я склонен верить этому документу, там четко описано, что эти ACL для DES-3200. Там приведен синтаксис с полями L2/L3/L4, который появился только начиная с DES-3200. А вот чего нет в этом документе, так как это работы с src ip и/или c dst ip.

Я написал: захватывал их на клиентском сервере доступа. Это вот как раз то, о чем я тоже писал: Вот это к DES-3200 отношения скорее всего не имеет, и, если я не ошибаюсь, было написано во времена DES-3526, в котором такие смещения учитывать надо. В DES-3200 смещений из-за vlanid нет, так как в нем присутствуют поля L2, L3, L4, которые позволяют как раз этих смещений избежать. К тому же у нас тут заминка из-за смещения на 2 байта, а поле vlanid - это 4 байта. Начать, я думаю, стоит, по традиции, с версий прошивок. У меня 1.5, и кое-где 1.6 ветки. На какой конкретно прошивке используется приведенное правило?

AlKov Не ошибся. Это легко проверить. Возьмите это правило, вместо deny сделайте permit counter enable. И смотрите на счетчик. Вот счетчик с одного из моих свитчей: Да, 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 Тут уточняется 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

Можно.

mcdemon На даунлинки в общем случае можно первым правилом вешать этот ACL: указывая в нем VLANID mgmt vlan'а. Если это действительно иногда, то проще удалять ACL с порта, настраивать свитч, и возвращать ACL. В противном случае надо к чему-то привязываться для отфильтровки дес2108, к их mac-адресам, к ip-адресам, в которых находятся свитчи. Можно попробовать написать ACL для пропуска трафика c ip-адресом источника 10.90.90.90, но тогда при настройке 2108, как минимум, ipif System придется настраивать последним. Можно пробовать PPPoE Relay / Protocol-based vlan.

для DES-3028:

Все Smart-UPS от APC серии SMT начиная от 1000 VA. Они совсем недавно появились, в начале этого года.

mcdemon А зачем? Управляющий влан, и как следствие трафик, должны быть только на аплинках, а не на клиентских портах. Зачем разрешать в ACL то, чего никогда не будет? slavikeks Вот это правило лишнее. В него скорее всего никогда трафик не попадет. В правилах профиля 1 сначала запрещаются все пакеты с портом источника 67, а потом разрешаются все пакеты с портом источника 68. Иначе говоря, на клиентских портах блокируются dhcp сервера, и разрешаются dhcp клиенты. В правилах профиля 2 сначала запрещаются все пакеты, предназначенные dhcp клиентам, и разрешаются пакеты, предназначенные dhcp серверу. Правило 2.1 вряд ли когда-то сработает так как ACL работают только на входящий трафик, и я сомневаюсь, что кто-то с клиентского порта пошлет пакет с портом назначения 68. Но как для перестарховки, то не помешает. Правило 2.2 тоже вряд ли когда-то сработает, так как пакеты с портом назначения 67 как правило имеют порт источника 68, и они пройдут через правило 1.2, и до правила 2.1 просто не дойдут. Опять же таки для перестарховки - не помешает, но тогда рекомендую добавить к правилу counter enable. Лучше всего адаптировать к вашим ACL правила из http://d-link.ru/ru/faq/62/206.html Можно иначе, блокируя PADO пакеты с клиентских портов, но это можно только через PCF: P.S. Я надеюсь вопрос был задан в контексте DES-3200.

Если использовать конкретно мою модель ACL, то да. Да. Чтобы это сделать нужно правила работы dhcp поднять выше правила блокировки ip broadcast. Самое простое, что можно сделать в текущей модели, так это, пожалуй: 1. Удалить 2.7. 2. Вместо: сделать: 3. Создать промежуточный профиль между 3 и 4, который станет новым 4, а старые 4 и 5 профили и правила сместить на единицу: create access_profile packet_content_mask destination_mac FF-FF-FF-FF-FF-FF offset1 l2 0 0xFFFF profile_id 4 и добавить старое правило из 2.7:

Там специфические настройки для моей сети - просто перечисление ip/сетей, куда клиенты должны иметь доступ без авторизации: Коммутатор вообще все пакеты пропускать будет, так как у него не будет критерия по которому их пропускать. Нет, на аплинки на уровне доступа вообще лучше ставить всего по меньше, во избежания головной боли :) Это правило вообще лучше никогда не использовать. Мне оно нужно было только для клиентов, которые имеют подключения к сети как физ. и юр. лица. И им домой нужно было подать доступ к их офисным сетям, делалось просто через подачу тегированного трафика в порт. И вот чтобы с этим трафиком ничего не происходило на клиентском порту было создано правило, что если на порт приходит тегированный трафик с опеределенным VLANID просто пропускаем его и все. Лучше. Этот ACL аналог DHCP Server Screening, за исключением логов. Этот ACL и Screening друг друг не отменяют. DHCP Server Screening (я об этом уже писал) отрабатывает до пользовательских ACL, то есть логи/трапы от Screening'а — все это будет, а ACL я использую для подстраховки, так как в бета-прошивках Длинка возможно все :) Нет, это правило - лишняя перестраховка. С клиентских портов никакой трафик не должен уходить на порт назначения 68, поэтому и фильтруем, на всякий случай. Тебе нельзя использовать в первую очередь правило 2.7, а потом уже 3.1. Да. Да. Не на всех сериях эти правила видны пользователям, но это не значит, что их нет :)

И да, и нет. Они не пройдут дальше порта, но они придут на порт (так как ACL не влияют на коммутацию пакетов и практически весь функционал свитчей отрабатывает до пользовательских ACL), и следовательно все отработает так, как настроено. Так, если посмотреть на правило 3.1., видно, что пакеты к dhcp-серверу будут заблокированы, но так как используется dhcp relay, а он отрабатывает до ACL, то dhcp протокол работает без проблем. Тоже самое касается и LBD, пакет придет на порт - порт заблокируется. Поэтому использование ACL ни в коем случае не отменяет настройку других модулей в прошивке свитча, а лишь дополняет ее.

Что значит более глобально? Можно пример? Каждый пакет имеет mac-адрес, в интересующем ACL ограничения накладываются по mac-адресу, т.е. на втором уровне. Если второй уровень это недостаточно "глобально", ну режьте на первом, патчкордом из порта :) Использую, нигде я их не брал.

Да. Там не только синтаксис другой, там принципы построения ACL иные. Составить можно.

Можно, через PCF. ACL только для DES3200 Тут можно еще порезать протоколы (если встречаются в сети), и попытаться порезать арпы для сетей, которые используются. Правила 3.12-3.20 доступ к внутренним ресурсам сети (ЛК), dns'ам, smtp и т.д.

http://www.equicom.dp.ua/ping/ping3/ping3.htm