[Bumba]

На последней версии RouterOS 6.45.5

dhcp-snooping с option82 у кого-нибудь нормально работает?

 

В доках (если эти писульки на mikrotik wiki вообще документацией можно назвать) пишут, что на CRS326 должно работать, причем на уровне железа.

Я два дня пытаюсь понять что по их мнению означает "работает".

 

Тестирую свитч CRS326 ROS 6.45.5.

Потр 1 - uplink - tag vlan 11, untag vlan 1, pvid 1. Vlan 1 для управления. Для тестирования поставил пробовал trust и untrust.

Остальные порты клиентов untag Vlan 11, pvid 11.

 

DHCP Сервер для тестирования порт 20 untag pvid 11.

Вр-превых trust/untrast порту не работает.  Но в лог пишет, что мол на untrast порту получен DHCP ответ сервера.

Нафик мне это сообщение, если пакет (запрос) при этом всё равно пропущен.

На procurve если порт untrast то будут резаться BOOTPREQUEST от клиентов. Ответы от сервера пропускаются.

 

Во-вторых опция 82 НЕ добавляется в первый пакет запроса от клиента. И конечно мои настройки на сервере, завязанные на эту опцию идут лесом.

Кстати опция 82 добавляется только в пакет который выходит на trust порт. Если порт untrast в него всё равно идут DHCPREQUEST но без опции.

 

Получается, что от фэйк-серверов не избавится, а на нужный идут неправильные опции.

 

Сама опция 82 в "микродоках" не описана. Настроить remote-id или circuit-id нельзя. Содержимое только дампом пакетов определить можно.

Супер!

 

 

[Bumba]

Продолжение.

Пытаюсь обмануть микротик.

 

Если на trust порту (там где DHCP сервер должен быть) включен hw-offload, то в этот порт идет сначала прямой DHCPrequest от клиента без опции82, а потом дубль этого пакета но уже с опцией (это свитч уже дублирует как я понял).

Если выключить hw-offload то идёт пакет уже с добавленной опцией82. Т.е. похоже идёт через ЦП. Прекрасно, блин :(.

 

Но это ещё не всё. Допустим оставим серваку "медленный" порт (с hw-offload off). Но и тут фигня.

На DHCPDISCOVER клиента, сервер честно предлагает IP (DHCPOFFER), а вот от клиента нет подтверждения, что он его получил, нет последующего запроса DHCPREQUEST.

 

Пакеты смотрел только со стороны сервера.

В качестве сервера используется ISC dhcpd 4.3.5.

[jffulcrum]

6 часов назад, Bumba сказал:

на CRS326 должно работать, причем на уровне железа

В SwOS. 

[Bumba]

1 час назад, jffulcrum сказал:

В SwOS.  

:-)

Из микродоков в разделе RouterOS про бридж и dhcp-snooping

Начинается красиво:

Цитата

Starting from RouterOS version 6.43, bridge supports DHCP Snooping and DHCP Option 82. The DHCP Snooping is a Layer2 security feature, that limits unauthorized DHCP servers from providing a malicious information to users.

Дальше бубубу... с примитивной схемкой.

А в конце вот это дополнительное замечание:

Цитата

Currently only CRS3xx devices fully support hardware DHCP Snooping and Option 82. For CRS1xx and CRS2xx series switches it is possible to use DHCP Snooping along with VLAN switching, but then you must make sure that DHCP packets are sent out with the correct VLAN tag using egress ACL rules. Other devices are capable of using DHCP Snooping and Option 82 features along with hardware offloading, but you must make sure that there is no VLAN related configuration applied on the device, otherwise DHCP Snooping and Option 82 might not work properly. See Bridge Hardware Offloading section with supported features.

В первом же предложении: CRS3xxx - полностью поддерживает в железе. Только это в их, в особом микротиковском, понятии.

А потом про другие девайсы, оффлоад и виланы.

Правда это "примечании" такое запутанное, что остаётся только гадать, что имелось в виду.

 

ЗЫ. C SwOS я "наигрался". Это вапче примитив. Если уж в ROS они не сделали, то думаю в 2.10  SwOS и подавно.

У меня есть пара CSS326, но они в работе и я не могу с ними экспериментировать.

 

[jffulcrum]

Тем не менее, в SwOS многие вещи работают лучше, чем в ROS, или даже просто работают. Попробую проверить, как раз парочка 312 приехала для колхозной SAN

[Bumba]

4 минуты назад, jffulcrum сказал:

Тем не менее, в SwOS многие вещи работают лучше, чем в ROS, или даже просто работают. Попробую проверить, как раз парочка 312 приехала для колхозной SAN

Да конечно SwOS быстрее, потому что там нет большей части лабуды, которую я не собираюсь использовать.

Но!

В ней нет такой простой вещи, как loop detection, а у меня юзвери в локалке такие...

Вот и снупинга выходит, что нет. Прощаюсь с надеждой победить уродов, которые иногда пихают wifi рутеры в сеть не тем портом...

Опят таки нет поддержки dhcp-relay... Нет даже намёка на то что будет 802.1x...

И т.д, и т.п.

 

[nemo_lynx]

1. ИМХО, untrust dhcp означает, что на этом порту должны дропаться не реквесты от клиентов, а ответы dhcp-сервера. А вот реквесты как раз должны форвардиться далее. То есть, эта фича блокирует не весь дхцп, а лишь работу несанкционированных серверов.

2. DHCP-Snooping != DHCP-Relay. У вас дхцп-сервер находится в том же влане, что и клиент? Не мудрено, что реквест абонента доходит до сервера без изменений. А если сервер перенести во влан управления, а на микроте включить dhcp-relay?

Изменено 10 октября, 2019 пользователем nemo_lynx

[Bumba]

55 минут назад, nemo_lynx сказал:

1. ИМХО, untrust dhcp означает, что на этом порту должны дропаться не реквесты от клиентов, а ответы dhcp-сервера. А вот реквесты как раз должны форвардиться далее. То есть, эта фича блокирует не весь дхцп, а лишь работу несанкционированных серверов.

Это смотря с какой стороны порта смотреть.

Вот рабочая схема для порт untrast (у меня так на свитче HP (Aruba) работает):

из клиента в порт - режется DHCPREPLAY, DHCPOFFER остальное пропускается

из порта в клиент - режется DHCPREQUEST и DHCPDISCOVER остальное пропускается

Микротик НЕ режет DHCPREPLAY из клиента (фейк-сервер) в untrast-порт, только warning в лог пишет.

Причем иногда резал. А после перезагрузки опять пропускал пакеты.

 

55 минут назад, nemo_lynx сказал:

2. DHCP-Snooping != DHCP-Relay. У вас дхцп-сервер находится в том же влане, что и клиент? Не мудрено, что реквест абонента доходит до сервера без изменений. А если сервер перенести во влан управления, а на микроте включить dhcp-relay?

Я пока проверял простую, традиционную схему. С сервером в одном вилане с клиентами. Главное что меня интересовало, это как бороться с неавторизованными серверами в данном вилане. Получается - никак микротик не поможет.

До relay ещё не дошёл это уже другое.

 

55 минут назад, nemo_lynx сказал:

Не мудрено, что реквест абонента доходит до сервера без изменений.

Если вы про опцию82?...

На свитчах HP/Aruba к клиентским пакетам запросов и к серверным ответам добавляется опция82 без использования relay. Кстати, на этих свитчах, в отличие от микротика, dhcp-snooping включается на уровне vlan, а не глобально. А ещё есть (уже глобальный) список авторизованных серверов (в ROS такого нет).

Микротик тоже добавляет опцию82 ко всем пакетам, только вот помимо этого он ещё и не изменённый пакет пропускает. Это приводит к дублированию  и к путанице. Помогает отключение hw-offload, что естественно нежелательно.

 

Изменено 10 октября, 2019 пользователем Bumba

[maxkst]

В 10.10.2019 в 14:16, Bumba сказал:

Прощаюсь с надеждой победить уродов, которые иногда пихают wifi рутеры в сеть не тем портом...

В схеме vlan-per-user это легко режется в бридж-фильтре, если вланы объединены, и вообще не проблема, если изолированы

[Bumba]

3 часа назад, maxkst сказал:

В схеме vlan-per-user это легко режется в бридж-фильтре, если вланы объединены, и вообще не проблема, если изолированы

У меня локалка какие вланы пер юзер...

Мне нужно в зависимости от типа устройств и их расположения назначать разные ip, всякие другие параметры  и пр.

Да и вообще. Я интересовался именно DHCP snooping и связанной с ней opt82. Еще и relay + opt82.

 

Всю прошлую неделю экспериментировал.

В итоге вывод: хрень у них а не снупинг. А ждать, когда доделают не могу. И даже если они будут новые "исправленные" версии ROS выпускать, то и проверить уже не будет возможности.

 

Буду использовать как "тупой" аксес свитч с виланами.

 

Если кому интересно. Главные "недостатки" (а точнее баги конкретные) ихнего DHCP snooping:
- если hw-offload на порту включен - дублирование пакета (с опцией и без). Т.е. смысл опции82 теряется. На порту LAG (bonding) вапче пакеты размножаются как хотят

- само включение (DHCP snooping) надо производить после! того, как указаны тарст порты. И если ошиблись или надо поменять с одного порта на другой. То надо сначала всё выключить, перезагрузить, а потом опять устанавливать траст и затем включать снупинг. Идиотизм.

Это потому, что при включении снупиг на бридже в switch rules автоматически добавляется правило (динамическое и не удаляемое).

- если пакет dhcp пришел на свитч с опцией, то она заменяется на локальную. Поменять это поведение нельзя, как в других нормальных свитчах.

- сама опция82 не настраивается. Тупо пользуйся тем форматом какой дали.

- снупинг включается на всём свитче сразу, а не на отдельных виланах

- нет таблицы авторизованных dhcp серверов.

 

PS. скажу честно - сравнивал только с имеющимися у меня HP/Aruba (procurve).

PPS. Может я где-то ошибаюсь в конфиге, но вот нормальной документации на ROS не существует. К тому же всё сильно зависит от железа и версии софта.

Изменено 17 октября, 2019 пользователем Bumba

[Ace63]

Не нужно на микротике собирать взрослые вещи если не нужны танцы с бубном. Лучше использовать нормальное железо. Микротик - это SOHO, на этом все.

[Bumba]

4 часа назад, Ace63 сказал:

Не нужно на микротике собирать взрослые вещи если не нужны танцы с бубном. Лучше использовать нормальное железо. Микротик - это SOHO, на этом все.

Да уж.

Выбирал из расчёта 11-12 тыс. на свитч.  Вот попробовать взял штуку.

Институт бедный, денюх на сеть нету, а менять надо минимум 10 свитчей.

Присматриваюсь к SNR-S2985G-24TC или Ubiquiti Edge ES-24-Lite или

[Ace63]

3 часа назад, Bumba сказал:

Да уж.

Выбирал из расчёта 11-12 тыс. на свитч.  Вот попробовать взял штуку.

Институт бедный, денюх на сеть нету, а менять надо минимум 10 свитчей.

Присматриваюсь к SNR-S2985G-24TC или Ubiquiti Edge ES-24-Lite или

SNR норм, рабочие лошадки.. Как коммутатор доступа отличная железка. И не нужно вот этих танцев как в микротике, чтобы через свитч-чип работало, тут все просто работает и все. Если есть сомнения у НАГа можно взять в тест

Изменено 18 октября, 2019 пользователем Ace63

[alibek]

3 часа назад, Bumba сказал:

Ubiquiti Edge ES-24-Lite

Коммутаторы Ubiquiti я бы не советовал.

[ShyLion]

5 minutes ago, Ace63 said:

SNR норм, рабочие лошадки.. Как коммутатор доступа отличная железка. И не нужно вот этих танцев как в микротике, чтобы через свитч-чип работало, тут все просто работает и все. Если есть сомнения у НАГа можно взять в тест

 

+1, в сети их сотни

 

[McSea]

 

On 10/10/2019 at 8:58 PM, Bumba said:

ЗЫ. C SwOS я "наигрался". Это вапче примитив. Если уж в ROS они не сделали, то думаю в 2.10  SwOS и подавно.

У меня есть пара CSS326, но они в работе и я не могу с ними экспериментировать.

 

Зря так думаете, у микротика приоритетная ОС для коммутаторов как раз SwOS, CRS326 также можно в нее загрузить, он dual boot

Но смысла в CRS мало, CSS326 за свои деньги (8600 руб сейчас) нормальный коммутатор, RSTP на нем работает (это на тему защиты от петель), DHCP снупинг есть, но я его не проверял, нет необходимости.

[McSea]

@Bumba Проверил работу DHCP снупинга на SwOS 2.10 (в домашней сети без вланов) - адреса получаются, только когда DHCP сервер воткнут в trusted port, включается на ходу без перезагрузок. 

Опция 82 добавляется и в запросы и в ответы сервера, и первый раз и в 10-й, в Agent Circuit ID пишется имя коммутатора, которое настраивается + "eth 0/8:1" (зависит от порта); в Agent Remote ID пишется номер порта, как "Port9".

 

[Bumba]

8 часов назад, alibek сказал:

Коммутаторы Ubiquiti я бы не советовал.

А что с ними не так? В смысле что самое главное не так?

Я имел в виду именно серию Edge Switch, а не UniFi.

 

8 часов назад, Ace63 сказал:

Если есть сомнения у НАГа можно взять в тест

Если выбью деньги хотя бы на 5 штук, может попробую попросить. :)

[Bumba]

4 часа назад, McSea сказал:

RSTP на нем работает (это на тему защиты от петель)

STP слишком громоздкий что бы его использовать только для loop-detect. А альтернативных связей между разными свитчами в моей древовидной конфигурации нет.

 

Изменено 18 октября, 2019 пользователем Bumba

[Bumba]

50 минут назад, McSea сказал:

Проверил работу DHCP снупинга на SwOS 2.10 (в домашней сети без вланов) - адреса получаются, только когда DHCP сервер воткнут в trusted port, включается на ходу без перезагрузок.

Я конечно могу попробовать и SwOS загрузить, но мне чего-то не верится теперь что это там тоже будет работать так, как мне надо.

Я сверху написал, какие ещё недостатки меня не устраивают. И в SwOS я что-то не видел dhcp-proxy и proxy-arp.