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.