DHCP Relay совсем не означает L3. Чистый L2 D-Link DES-3200 или DES-1210/ME прекрасно умеет DHCP Relay. Забирать пакет из VLAN пользователя и направлять его юникастом на DHCP сервер через свой управляющий VLAN. Бродкастовый пакет DHCP даже на соседние порты в общем-то не попадёт. Ответ сервера попадёт юникастом на свитч, а оттуда туда, откуда пришёл. У других производителей то же есть аналогичные свитчи. Больше работал с D-Link, поэтому мне проще их модели сказать.
Опять же изоляция портов пользователей друг от друга traffic_segmentation или Assymetric Vlan (опять же в терминологии D-Link).
Остаётся вопрос, а надо ли ip unnambered вообще. Если нет, задача сводится к правильной архитектуре L2 уровня на нормальных управляхах + нормальный маршрутизатор в ядре (как программный, так и аппаратный).
Правда при использовании варианта из статьи можно использовать СОВСЕМ тупые свитчи, где по факту есть только VLAN и всё. Соответственно экономия. Это единственный плюс который я вижу. Хотя тут легко нарваться на правило — жадный платит дважды.
Не понял зачем было городить такой огород о_О.
У большинства управляемых свитчей L2 уровня всё это уже есть.
Блокировка трафика между пользователями у D-Link называется traffic_segmentation. У остальных (эджкоры, тп-линк и т.д.) то же есть.
DHCP_Relay есть прямо в свитче, соберёт с разных VLAN и портов и отправит на 1 сервер. Ответ вернётся только конкретному клиенту.
ip unnumbered разве что… Но аппаратных решений умеющих это без такого огорода — ОЧЕНЬ много. Даже то же программное. Но не этот огород.
Пока что не понятен смысл… Но как сферический конь в вакууме — интересно :)
Ну шифрование в некоторых видах GPON применяется на аппаратном уровне. И это легко может быть AES-128 или AES-256. Так что расшифровывать за… мучаетесь.
Тут я смотрю скорее был просто чисто академический интерес, т.к. особо вряд ли тут что поимеешь. Разве что сеть провайдера построена криво и какой-то ограничивающий функционал возложен на ONT. Тогда да, можно что-то поиметь.
Каждый раз, при входящем звонке, тупо заново формировать очередь О_о
А не проще из консоли по необходимости вызывать процедуру формирования очереди, но только тогда когда это необходимо?
Ещё возможно ты на старой прошивке пробовал. Заводские лучше обновлять на свежие, за редким исключением. Иногда в процессе «починки» или добавления ломают что-нить. Тогда приходится откатываться на предыдущую. Но это редкость и обычно последняя — нормально рабочая.
IMPB в свичах DLink знаете? Он заполняется в ручную или через SNMP. DHCP_Snoop обеспечивает его заполнение автоматически с использованием DHCP пакетов. С радиусом это ни как не связано.
И так. Подробнее. Что делает DHCP_Snoop в связке с IMPB на свичах D-Link (у многих остальных есть аналоги, но тут всё достаточно хорошо отточено уже давно).
Когда эта петрушка включена на порту — от пользователя с порта могут уйти только DHCP-запросы. Любой другой трафик блокируется. Т.е. если пользователь попробовал прописать себе IP руками — он ничего не получит. (В том числе IP соседа).
Дальше. Он запросил IP по DHCP, ему сервер DHCP ответил. Свитч из ответа сервера выдернет для себя пару IP+mac и время на которое выдан, которые отданы этому клиенту и запомнит их для клиентского порта. Т.е. этот клиент сможет работать с этой парой. Начнёт ходит L2 трафик от этого mac и L3 трафик от пары IP+mac. Любые другие mac и ip+mac на клиентском порту будут продолжать блокироваться. Можно ограничить сколько одновременных пар можно будет выучить на порт.
В принципе на этой стадии клиент может попробовать прописать себе свой же IP руками. Но т.к. свитч запоминает, на сколько IP был выдан, то без повторных запросов DHCP со стороны клиента, свитч по истечении этого времени «забудет» пару IP+mac и клиент опять будет заблокирован.
Возможная махинация с прописыванием себе мака соседа блокируется использование option 82, т.е. ты клиента прибиваешь к порту.
Плюсы:
1. Глупости и не правильная настройка со стороны клиента блокируются на ходу. Даже роутер воткнутый в LAN, а не в WAN будет заблокирован, т.к. он не запрашивает DHCP.
2. Большинство атак, махинаций и попыток «воровать» интернет соседа так же заблокированы.
3. Динамическая привязка к твоему биллингу за счёт первоначальной настройки свитча, а дальше всё обслуживается 1 запросом DHCP. Тут надо только, что бы у тебя была привязка пользователя к порту. Кстати можно даже не привязываться к его маку, можно просто именно к порту.
Минусы:
1. Есть глючные клиентские устройства, которые криво работают с DHCP. Например роутеры, которые «забывают» уточнить данные по истечению времени аренды. Обычно (если это не полный китай) лечится обновлением прошивки.
Всё. Понял наконец. Из-за твоего фильтра бродкаста получится умирают DHCP запросы от пользователей. Поэтому приходится их разрешать руками. Это ты имел в виду?
Что именно в 3 версии вываливалось, если не секрет? И какую именно тестил? Я сейчас 3.0.7 кручу. Достаточно свежая — но это пока что без нагрузки (1-10 клиентов) и с самыми простыми скриптами.
Пока что смотрю на фрирадиус, т.к. он всё равно нужен для аутентификации юзеров. Смысл плодить сущности (отдельный DHCP, отдельный радиус и т.д.), если всё есть в одном.
Бррр. Тебе необходимо заблокировать «левые» DHCP сервера в своей сети. Именно это эта команда и делает. Блокируешь на пользовательских портах, оставляешь на магистральных. Что не так?
В остальных бродкастах не разобрался. арп понял по коментарию, но вообще типы пакетов 0x806 0x800 0x86DD и т.д. не помню, а искать сейчас влому :) Так что ты имел в виду этими записями (что фильтровал, а что пропускал), пока что не понял :)
Мы наверное о разных DHCP_Snooping говорим. Он есть прямо на свитчах DLink. Пока пользователь не получит IP по DHCP, ни какой другой трафик, кроме DHCP-запросов от него не пройдёт (при максимальных настройках). Когда идёт ответ, свитч запомнит, какой ему ip выдало и привяжет пару mac+ip к порту. А уже DHCP сервер за счёт option 82 сделат, какой ip на какой порт выдать.
Попытка сменить себе после этого ip на какой-то другой — ничего не даст. Новый ip будет заблокирован. При всём желании
можно ручками у себя прописать IP-соседа из одного влана и когда он выключает комп сидеть под его IP.
не сделаешь. Даже попытка прописать себе свой IP статикой проживёт ровно до истечения lease dhcp-ответа. После этого свитч запомненную информацию скинет. Так что пользователь обязан юзать DHCP. И не пропишет своими кривыми ручками что-то не то.
В результате надобность в
config access_profile profile_id 4 add access_id 1 ip vlan_id $vlanid source_ip 10.5.0.88 port 1 permit
Опять же изоляция портов пользователей друг от друга traffic_segmentation или Assymetric Vlan (опять же в терминологии D-Link).
Остаётся вопрос, а надо ли ip unnambered вообще. Если нет, задача сводится к правильной архитектуре L2 уровня на нормальных управляхах + нормальный маршрутизатор в ядре (как программный, так и аппаратный).
Правда при использовании варианта из статьи можно использовать СОВСЕМ тупые свитчи, где по факту есть только VLAN и всё. Соответственно экономия. Это единственный плюс который я вижу. Хотя тут легко нарваться на правило — жадный платит дважды.
У большинства управляемых свитчей L2 уровня всё это уже есть.
Блокировка трафика между пользователями у D-Link называется traffic_segmentation. У остальных (эджкоры, тп-линк и т.д.) то же есть.
DHCP_Relay есть прямо в свитче, соберёт с разных VLAN и портов и отправит на 1 сервер. Ответ вернётся только конкретному клиенту.
ip unnumbered разве что… Но аппаратных решений умеющих это без такого огорода — ОЧЕНЬ много. Даже то же программное. Но не этот огород.
Пока что не понятен смысл… Но как сферический конь в вакууме — интересно :)
Тут я смотрю скорее был просто чисто академический интерес, т.к. особо вряд ли тут что поимеешь. Разве что сеть провайдера построена криво и какой-то ограничивающий функционал возложен на ONT. Тогда да, можно что-то поиметь.
Блин, да нормальный антивирус скушает каку ещё на стадии
А не проще из консоли по необходимости вызывать процедуру формирования очереди, но только тогда когда это необходимо?
Когда эта петрушка включена на порту — от пользователя с порта могут уйти только DHCP-запросы. Любой другой трафик блокируется. Т.е. если пользователь попробовал прописать себе IP руками — он ничего не получит. (В том числе IP соседа).
Дальше. Он запросил IP по DHCP, ему сервер DHCP ответил. Свитч из ответа сервера выдернет для себя пару IP+mac и время на которое выдан, которые отданы этому клиенту и запомнит их для клиентского порта. Т.е. этот клиент сможет работать с этой парой. Начнёт ходит L2 трафик от этого mac и L3 трафик от пары IP+mac. Любые другие mac и ip+mac на клиентском порту будут продолжать блокироваться. Можно ограничить сколько одновременных пар можно будет выучить на порт.
В принципе на этой стадии клиент может попробовать прописать себе свой же IP руками. Но т.к. свитч запоминает, на сколько IP был выдан, то без повторных запросов DHCP со стороны клиента, свитч по истечении этого времени «забудет» пару IP+mac и клиент опять будет заблокирован.
Возможная махинация с прописыванием себе мака соседа блокируется использование option 82, т.е. ты клиента прибиваешь к порту.
Плюсы:
1. Глупости и не правильная настройка со стороны клиента блокируются на ходу. Даже роутер воткнутый в LAN, а не в WAN будет заблокирован, т.к. он не запрашивает DHCP.
2. Большинство атак, махинаций и попыток «воровать» интернет соседа так же заблокированы.
3. Динамическая привязка к твоему биллингу за счёт первоначальной настройки свитча, а дальше всё обслуживается 1 запросом DHCP. Тут надо только, что бы у тебя была привязка пользователя к порту. Кстати можно даже не привязываться к его маку, можно просто именно к порту.
Минусы:
1. Есть глючные клиентские устройства, которые криво работают с DHCP. Например роутеры, которые «забывают» уточнить данные по истечению времени аренды. Обычно (если это не полный китай) лечится обновлением прошивки.
Пока что смотрю на фрирадиус, т.к. он всё равно нужен для аутентификации юзеров. Смысл плодить сущности (отдельный DHCP, отдельный радиус и т.д.), если всё есть в одном.
Попытка сменить себе после этого ip на какой-то другой — ничего не даст. Новый ip будет заблокирован. При всём желании не сделаешь. Даже попытка прописать себе свой IP статикой проживёт ровно до истечения lease dhcp-ответа. После этого свитч запомненную информацию скинет. Так что пользователь обязан юзать DHCP. И не пропишет своими кривыми ручками что-то не то.
В результате надобность в отпадает, т.к. это делается динамически.