Аналогичная ситуация, как здесь.
Т.е. "ниже" коммутатора с QinQ и dhcp_local_relay стоит "простой" коммутатор, который умеет только 802.1q.
Соотв. check-mac-change пришлось отключить.
Прецендентов пока не было, т.к. только начинаем переходить на IPoE, но скорее всего "умные головы" в конце-концов найдутся..
Возможно ли устранить проблему при подобном дизайне сети? Без замены железа на доступе.
Если например, отключить dhcp_local_relay (по большому счёту нам он не нужен), то будет ли вообще работать авторизация по DHCP Discover?
Как решить проблему со сменой МАС на порту доступа?
Как решить проблему со сменой МАС на порту доступа?
Last edited by KovAl on 11 May 2018, 06:16, edited 1 time in total.
Re: Как решить проблему со сменой МАС на порту доступа?
Немного не осилю, давайте по порядку попробуем.
У вас [ipoe]. QinQ на агрегации и еще option 82.
На доступе есть коммутаторы, не управляемые или 802.1q умеют? ps://у меня чего то IEEE не открываются доки сегодня, и не помню о чем гласит 802.3q.
Авторизация по DHCP Discover работать должна, чего ей то, вы же стремитесь к схеме vlan-per-user?
У вас [ipoe]. QinQ на агрегации и еще option 82.
На доступе есть коммутаторы, не управляемые или 802.1q умеют? ps://у меня чего то IEEE не открываются доки сегодня, и не помню о чем гласит 802.3q.
Авторизация по DHCP Discover работать должна, чего ей то, вы же стремитесь к схеме vlan-per-user?
Re: Как решить проблему со сменой МАС на порту доступа?
Первое - извиняюсь за 802.3q, конечно же 802.1q. Опечатка.. Поправил.dimka88 wrote: ↑10 May 2018, 18:33 Немного не осилю, давайте по порядку попробуем.
У вас [ipoe]. QinQ на агрегации и еще option 82.
На доступе есть коммутаторы, не управляемые или 802.1q умеют? ps://у меня чего то IEEE не открываются доки сегодня, и не помню о чем гласит 802.3q.
Авторизация по DHCP Discover работать должна, чего ей то, вы же стремитесь к схеме vlan-per-user?
Дальше - QinQ на первом уровне агрегации("агрегация доступа", если так можно выразится).
А вот на доступе стоят DES-1100-16 c CLI прошивкой , которые умеют совсем мало.
Поэтому QinQ и вынесено на первый уровень агрегации (DES-3200).
option 82 по большому счёту не нужна, т.к. везде vlan-per-user.
Просто я - видимо ошибочно - посчитал, что без включённой опции dhcp_local_relay коммутатор будет дропать DHCP пакеты.
А проблема собственно в том, что в такой схеме не получается использовать check-mac-change в accel, т.к. как уже было сказано, в этом случае связка circuit-id - remote-id - mac получается не уникальной...
Что ещё можно использовать в данном случае, не знаю.. Пытался поиграться с port security на 1100-16 - отказался. Полное убожество...
А нет ли возможности заменить номер Svlan в Agent-Circuit-ID на номер Cvlan? Или добавить.
В этом случае получится уникальный идентификатор.
Re: Как решить проблему со сменой МАС на порту доступа?
Я думаю стоит идти классической схемой Q-in-Q vlan-per-user, проблем нет, check-mac-change отрабатывает корректно, ему вроде как все равно если одинаковые mac адреса в разных vlan.
Авторизация по username=ifname (eth1.100.11) 100-SVLAN 11-CVLAN.
Эти все vlan оборачиваем меткой например 100 на вашем DES 3200 и vlan 100 дотягиваем до accel-ppp. Слушаем интерфейс регуляркой: interface=re:eth1\.[0-9][0-9][0-9]\.[0-9][0-9],start=dhcpv4,ifcfg=1,proxy-arp=1
Насколько я понял, DES-1100-16 умеет работать с vlan и думаю этого минимального функционала должно быть достаточно, что бы на клиентских портах (mode access в разные vlan) и отдавать это все транком на коммутатор агрегации.
Авторизация по username=ifname (eth1.100.11) 100-SVLAN 11-CVLAN.
Code: Select all
DES-1100-16
1 порт - VLAN 11 или (101 если понимает такие метки)
2 порт - V LAN 12 или (102 если понимает такие метки)
...
15 порт - V LAN 25 или (115 если понимает такие метки)
16 порт - отдаем vlan 11-25 в транк
Насколько я понял, DES-1100-16 умеет работать с vlan и думаю этого минимального функционала должно быть достаточно, что бы на клиентских портах (mode access в разные vlan) и отдавать это все транком на коммутатор агрегации.
Re: Как решить проблему со сменой МАС на порту доступа?
Всё именно так и сконфигурёно. Единственно что proxy-arp=0, но это вряд ли поможет.
И проблема не в том, что одинаковые MAC в разных влан, а ровно наоборот - РАЗНЫЕ МАС с ОДИНАКОВЫМИ Agent-Circuit-ID и Agent-Remote-ID.
Именно так, как - повторюсь - в этой теме...
И проблема не в подмене МАС, а в "перетыкании" портов "на ходу". В этом случае, при наличии "активной сессии" на "легальном порту", "нелегал" получит доступ с порта "соседа". А т.к. check-mac-change выключен, это работает!! Проверял.
Вот смотрите -
Вот если бы в Agent-Circuit-ID был не Svlan, а Cvlan, или оба, то наверное, check-mac-change не отработал.
Или я ошибаюсь и дело здесь не в этом?
P.S. Правда, я не включал check-mac-change с тех самых пор. Но там, похоже, был какой-то баг в accel.
И проблема не в том, что одинаковые MAC в разных влан, а ровно наоборот - РАЗНЫЕ МАС с ОДИНАКОВЫМИ Agent-Circuit-ID и Agent-Remote-ID.
Именно так, как - повторюсь - в этой теме...
И проблема не в подмене МАС, а в "перетыкании" портов "на ходу". В этом случае, при наличии "активной сессии" на "легальном порту", "нелегал" получит доступ с порта "соседа". А т.к. check-mac-change выключен, это работает!! Проверял.
Вот смотрите -
Влан-ы разные..[2018-05-11 15:05:48]: info: eth0.3898.2303: recv [DHCPv4 Request xid=149cb47b ciaddr=172.16.5.250 chaddr=2c:a7:25:29:8d:3e <Message-Type Request> <Client-ID 012cab25298d3e> <Vendor-Class 756468637020302e392e38> <Request-List Subnet,Router,DNS,Host-Name,Domain-Name,17,Broadcast,66,Route,Classless-Route,249> <Relay-Agent {Agent-Circuit-ID _00040f3a0017} {Agent-Remote-ID _00063c1e04a176a0}>]
[2018-05-11 15:05:31]: info: eth0.3898.2311: recv [DHCPv4 Request xid=5fb48ff7 ciaddr=172.16.10.143 chaddr=8c:89:a5:7e:50:12 <Message-Type Request> <Max-Message-Size 1024> <Client-ID 018c89a57e5012> <Host-Name TL-WR841N> <Vendor-Class 4d53465420352e30> <Request-List Subnet,Router,DNS,Domain-Name,Vendor-Specific,44,46,47,Route,Classless-Route,249> <Relay-Agent {Agent-Circuit-ID _00040f3a0017} {Agent-Remote-ID _00063c1e04a176a0}>]
Вот если бы в Agent-Circuit-ID был не Svlan, а Cvlan, или оба, то наверное, check-mac-change не отработал.
Или я ошибаюсь и дело здесь не в этом?
P.S. Правда, я не включал check-mac-change с тех самых пор. Но там, похоже, был какой-то баг в accel.
Re: Как решить проблему со сменой МАС на порту доступа?
В схеме с QinQ использовать option 82 как по мне вообще не имеет смысла, если хотите что бы нелегал не получил доступ к легальному порту, стоит что то решить с физическим доступом к оборудованию, или проверять при авторизации связку ((username=ifname)+(Calling-Station-Id он же MAC)), в таком случае после того как нелегал отправит DHCP discover с легального порта, accel-ppp поймет что сменился MAC и положит сессию, а новая не поднимется, так так radius ответит Access reject
ps:/Вроде бы на check-mac-change жалоб и фиксов особо не было.
ps:/Вроде бы на check-mac-change жалоб и фиксов особо не было.
Re: Как решить проблему со сменой МАС на порту доступа?
to KovAl
А я вот вообще тогда не пойму, зачем при QinQ вы используете opt82?
А я вот вообще тогда не пойму, зачем при QinQ вы используете opt82?
Re: Как решить проблему со сменой МАС на порту доступа?
Я уже писал, что option 82 мне НЕ нужна, включена она была, можно сказать, по-инерции, т.к. "до того как" использовалась.
Не вопрос, могу выключить. Но решит ли это проблему? Будет ли корректно работать в этом случае check-mac-change?
На данный момент я вообще не понимаю алгоритм его работы. Если возможно, опишите подробно.
accel не реагирует на это, не направляет запрос к радиусу на авторизацию, а просто отдаёт "нелегалу" текущий легальный IP..
И такая "фишка" будет работать бесконечно долго, до ребута железки "нелегала"..
Не вопрос, могу выключить. Но решит ли это проблему? Будет ли корректно работать в этом случае check-mac-change?
На данный момент я вообще не понимаю алгоритм его работы. Если возможно, опишите подробно.
Именно с этим проблема.. Сеть строилась более 10 лет тому назад и об этом вообще не задумывались, т.к. как всегда на старте было "не до жиру", да и не актуально на тот момент было.
Именно так и сделано, НО... Ещё раз - если отключить проверку на валидность связки IP-МАС, то при физическом переключении активных портовdimka88 wrote: ↑11 May 2018, 19:00 ...или проверять при авторизации связку ((username=ifname)+(Calling-Station-Id он же MAC)), в таком случае после того как нелегал отправит DHCP discover с легального порта, accel-ppp поймет что сменился MAC и положит сессию, а новая не поднимется, так так radius ответит Access reject
accel не реагирует на это, не направляет запрос к радиусу на авторизацию, а просто отдаёт "нелегалу" текущий легальный IP..
И такая "фишка" будет работать бесконечно долго, до ребута железки "нелегала"..
Re: Как решить проблему со сменой МАС на порту доступа?
Вам именно и нужен check-mac-change=1 он решает проблему которую вы описывали, только выключите DHCP option 82.
Алгоритм работы check-mac-change для QinQ прост, accel-ppp увидев новый MAC во VLAN конечного пользователя тушит существующую сессию, и после этого другому клиенту просто необходимо посылать DHCP discover, и получит он от radius access reject, так как MAC не совпадет при авторизации в БД биллинга.
ps:// У нас есть чатик в телеграм, присоединяйтесь. Ссылка на главной странице http://accel-ppp.org
Алгоритм работы check-mac-change для QinQ прост, accel-ppp увидев новый MAC во VLAN конечного пользователя тушит существующую сессию, и после этого другому клиенту просто необходимо посылать DHCP discover, и получит он от radius access reject, так как MAC не совпадет при авторизации в БД биллинга.
ps:// У нас есть чатик в телеграм, присоединяйтесь. Ссылка на главной странице http://accel-ppp.org
Re: Как решить проблему со сменой МАС на порту доступа?
А не подскажете, "на горячую" эти манипуляции возможно сделать?
Я имею ввиду отредактировать accel-ppp.conf и затем reload.
Не снесёт у меня весь текущий "онлайн" (порядка 250 активных пользователей)?
Вряд ли смогу. "Телеграм" у меня нет, плюс учитывая то, что "борьбу с ветряными мельницами" у нас осуществляет вышестоящий провайдер,dimka88 wrote: ↑12 May 2018, 09:15 ps:// У нас есть чатик в телеграм, присоединяйтесь. Ссылка на главной странице http://accel-ppp.org
работать он вряд ли будет..
Из живых есть только древний ICQ