[wtyd]

Раньше я с другим оборудованием работал, сейчас надо на dlink реализовать работу dhcp в сети. В теории есть два способа настройки раздачи слонов адресов на свичах доступа:

 

1. классический dhcp snooping. Свичи снупируют dhcp-запросы среди прочего броадкаста, рассылают их только в доверенные порты, охраняют сеть от левых dhcp-серверов, а на роутере в такой схеме работает dhcp-relay, который переправляет броадкастовые запросы по юникасту на указанные dhcp-серверы. В такой схеме снупинг включается per vlan basis, т.е. только в нужных клиентских вланах, не указанные в настройках вланы не затрагиваются.

 

2. dhcp-relay. Это когда свич доступа снупирует dhcp-запрос и передаёт его сам без роутера юникастом на указанные dhcp серверы. Маршрутизатор тут уже не участвует, юникаст от свичей до dhcp пролетает без дополнительных настроек на роутерах сети.

 

Я не нашёл в длинках первый вариант, там есть только второй. Может быть как-то можно включить классический снупинг в нужных вланах на длинках ?

 

На счёт релея не всё понятно. По-моему, релей на всех вланах по-умолчанию включен. Как следует настраивать dhcp-relay на длинках ? Хочу получить схожий с первым вариантом функционал (блокировать левые серверы, не рассылать запросы во все порты кроме "серверных"/инфраструктурных, фича не должна трогать определённые транзитные вланы (!)). Как в длинках dhcp-relay работает ? Per port basis ?

 

 

Видимо, надо включить фичу, потом отключить её на аплинках, на даунлинках, т.е. на портах инфраструктуры сети, в которых есть тегированные вланы. Я правильно рассуждаю ?

 

Просто не хочется сидеть и несколько дней на лабе все эти нюансы изучать.

[xcme]

У D-Link функционал фильтрации DHCP отделен от релея. Блокировка левых DHCP:

config filter dhcp_server ports 25-28 state disable
config filter dhcp_server ports  1-24 state  enable
config filter dhcp_server trap_log enable

 

Сам релей работает в двух вариантах: dhcp_local_relay - когда свичик, например, просто вписывает опцию 82 в пакет, не меняя его путь; и dhcp_relay - когда пакет еще и релеится самим коммутатором. Пример для dhcp_relay с опцией 82 и релея для группы портов:

config dhcp_relay option_82 state enable
config dhcp_relay option_82 check disable
config dhcp_relay option_82 policy keep
config dhcp_relay add ipif System <IP_сервера>
config dhcp_relay ports 25-28 state disable
config dhcp_relay ports  1-24 state  enable
enable dhcp_relay

Можно релеить не по портам, а по vlan:

config dhcp_relay add vlanid 1234 <IP_сервера>

 

К первому варианту ближе, наверное, dhcp_local_relay, но я этот функционал не использовал.

 

p.s. D-Link релеит DHCP-уникаст пакеты тоже, поэтому на магистралях релей желательно выключать совсем, хотя это зависит от дизайна сети.

[wtyd]

О, т.е. dhcp_local_relay это и есть классический снупинг ?

[xcme]

О, т.е. dhcp_local_relay это и есть классический снупинг ?

Классический - это как в кошках? :) Вообще "снупинг" - это "подслушивание" с целью принятия какого то решения. Для D-Link это может быть: а) блокировка пакета (dhcp_filter); б) изменение пакета (dhcp_local_relay); в) изменение пакета и его релей (dhcp_relay); г) создание связки IP-Mac-Port в таблице (IMPB). Функционал разный, хотя для всего этого будет применяться DHCP Snooping.

[tehmeh]

О, т.е. dhcp_local_relay это и есть классический снупинг ?

Да, как dhcp snooping option insertion, то есть никаких рилеев, просто добавляем опцию в пакеты.

[wtyd]

О, т.е. dhcp_local_relay это и есть классический снупинг ?

Классический - это как в кошках? :) Вообще "снупинг" - это "подслушивание" с целью принятия какого то решения. Для D-Link это может быть: а) блокировка пакета (dhcp_filter); б) изменение пакета (dhcp_local_relay); в) изменение пакета и его релей (dhcp_relay); г) создание связки IP-Mac-Port в таблице (IMPB). Функционал разный, хотя для всего этого будет применяться DHCP Snooping.

 

Классический снупинг -- да, как в кошках в том числе. Снупинг в нашем случае это не "подслушивание", когда подслушивают, то звук от этого не меняется, но это не важно же :-).

 

Всем спасибо, стало значительно понятней.

[mihele95]

dhcp_local_relay - отправляет dhcp запрос в указанном vlan

dhcp_relay отправляет запрос юникастом по системному vlan на указанный ip адрес

 

config filter dhcp_server ports 1-24 state enable

- защищает от несанкционированных dhcp серверов на абонентских портах

 

еще изолировать абонентские порты между собой можно

 

config traffic_segmentation 1-24 forward_list 28

, где 1-24 абонентские порты, 28 - магистральный

 

 

DHCP snooping, если имеется в виду IPMB настраивается так:

 

config address_binding dhcp_snoop max_entry ports 28 limit no_limit
config address_binding dhcp_snoop max_entry ports 1-24 limit 5
config address_binding ip_mac ports 1-24 arp_inspection strict
config address_binding ip_mac ports 1-24 allow_zeroip enable
config address_binding ip_mac ports 28 forward_dhcppkt disable
config address_binding ip_mac ports 1-24 forward_dhcppkt enable
enable address_binding dhcp_snoop
enable address_binding trap_log
config address_binding dhcp snooping recovery_timer 300
disable address_binding dhcp_snoop ipv6
disable address_binding nd_snoop

 

при получении dhcp lease абонентом, на коммутаторе создается связка Ip-mac и при изменении данных со стороны абонента порт блокируется

Edited May 30, 2016 by mihele95

[Negator]

Не забудьте про кучу нюансов в различных моделях коммутаторов.

[rdc]

какой смысл в фильтрации dhcp?

traffic_segmentation решает практически все проблемы, кроме подделки маков.

 

а вообще надо делать vlan per customer, и будут решены вообще все проблемы.

и работает на любых свичах, даже на ископаемых DES-3226

[wtyd]

какой смысл в фильтрации dhcp?

traffic_segmentation решает практически все проблемы, кроме подделки маков.

 

а вообще надо делать vlan per customer, и будут решены вообще все проблемы.

и работает на любых свичах, даже на ископаемых DES-3226

 

А как можно узнать МАС соседа, если включена сегментация трафика ? :-)

[Negator]

По идее никак.

[rdc]

Целенаправленно вряд ли будут узнавать, но мне попадалались ситуации типа - сделали зачем-то mac clone, потом купили роутер покруче, а старый подарили соседу.

Также встречается ситуация, когда после заливки альтернативной прошивки мак роутера меняется на дефолтный для этой прошивки.

[wtyd]

Тут ещё одна проблема возникла, из-за неё картинка полностью опять не складывается. По-скольку маки в нашей базе всёравно есть и они постоянно актуализируются, то проще всего выдавать адреса по маку. С opt82 связываться вообще не хочется, т.к. его сложно парсить и вдруг у какого-то другого вендора оно не так будет ? Но похоже придётся юзать opt82 ... надо сделать так, что когда мак не зарегистрирован в системе, то выдать адрес их соответствующего серого пула. Т.е. надо знать номер влана или белый адрес роутера в этом влане. Адрес роутера можно узнать, если делать "классическую" схему (dhcp_local_relay + ip helper на цыске), номер влана можно как-то выдрать из opt82 при dhcp_relay на свичах доступа.

 

В качестве dhcp используем freeradius. Среди коллег нет особого желания делать "классическую" схему :-). Как в радиусе узнать номер влана ? Максимум, что там есть в явном виде это атрибуты DHCP-Agent-Circuit-Id и DHCP-Agent-Remote-Id, их формат мне пока не понятен, как из них выдрать номер влан ?

 

Например, сейчас (сделал логирование) есть примерно такое:

 

DHCP-Relay-Remote-Id=0x00060021918daafd, DHCP-Relay-Circuit-Id=0x000400050013

 

"0005" это два байта, номер влана в хексе. "13" это байт номер порта (19) в хексе. Как в радиусе на unlang что-нибудь написать, чтобы update control присвоил имя пула строку "0005" например ?

Edited June 1, 2016 by wtyd

[pkozik]

Поскольку opt82 относится к DHCP, то и копать надо в нём.

В dhcpd.conf примерно так прописывается обработка (здесь - по vlan):

 

class "VLAN_INTERNET" {

#ok# match if substring(option agent.unknown-6, 0, 6)="VLAN15";

match if binary-to-ascii(10,16,"",substring(option agent.circuit-id,2,2))!$

}

 

class "VLAN_GUEST" {

match if binary-to-ascii(10,16,"",substring(option agent.circuit-id,2,2))="$

}

 

subnet 0.0.0.0 netmask 0.0.0.0{

authoritative;

option domain-name-servers 8.8.8.8;

pool{

range 172.17.0.2 172.17.255.254;

allow members of "VLAN_GUEST";

option routers 172.17.0.1;

option subnet-mask 255.255.0.0;

option ms-classless-static-routes 4, 224, 172, 17, 0, 1 ;

option rfc3442-classless-static-routes 4, 224, 172, 17, 0, 1 ;

}

pool{

range 10.224.16.109 10.224.16.150;

allow members of "VLAN_INTERNET";

option routers 10.224.16.108;

option subnet-mask 255.255.255.0;

}

}

 

 

В этом примере клиент в нужном влан получает правильный адрес, иначе - левый "гостевой".

Edited June 1, 2016 by pkozik

[wtyd]

Вы немного не на тот вопрос отвечаете, хотя всёравно спасибо :-). freeradius умеет быть dhcp-сервером и мы решили заюзать именно его потому что он клёвый. Теперь проблема в том, как на unlang из "DHCP-Relay-Circuit-Id=0x000400050013" выдрать "0005", преобразовать в decimal и выдать в формате четырёх знаков, т.е. с лидирующими нулями.

 

Пока рабочий вариант такой: &Pool-Name := "vlan-%{unpack:%{DHCP-Relay-Circuit-Id} 4 short}", но тут нет лиинг зерос :-).

[B_Bondarenko]

Вы немного не на тот вопрос отвечаете, хотя всёравно спасибо :-). freeradius умеет быть dhcp-сервером и мы решили заюзать именно его потому что он клёвый. Теперь проблема в том, как на unlang из "DHCP-Relay-Circuit-Id=0x000400050013" выдрать "0005", преобразовать в decimal и выдать в формате четырёх знаков, т.е. с лидирующими нулями.

 

Пока рабочий вариант такой: &Pool-Name := "vlan-%{unpack:%{DHCP-Relay-Circuit-Id} 4 short}", но тут нет лиинг зерос :-).

 

Добрый день!

А почему вы не хотите рассмотреть схему, когда у вас в базе радиуса будут прописаны конкретные пары remote/circut, которые будет генерировать некая внешняя программа при заведении абонента, либо при описании свитча полностью. Втаком случае вы сможете полностью абстрагироваться от формата опции 82 на конкретной модели свитча.

Мы уже ходили по пути парсинга opt82, но при определенной концентрации разнородного железа все это выходит из под контроля и с трудом поддается автоматическому анализу, сейчас храним именно пару remote/circut.

[wtyd]

Вы немного не на тот вопрос отвечаете, хотя всёравно спасибо :-). freeradius умеет быть dhcp-сервером и мы решили заюзать именно его потому что он клёвый. Теперь проблема в том, как на unlang из "DHCP-Relay-Circuit-Id=0x000400050013" выдрать "0005", преобразовать в decimal и выдать в формате четырёх знаков, т.е. с лидирующими нулями.

 

Пока рабочий вариант такой: &Pool-Name := "vlan-%{unpack:%{DHCP-Relay-Circuit-Id} 4 short}", но тут нет лиинг зерос :-).

 

Добрый день!

А почему вы не хотите рассмотреть схему, когда у вас в базе радиуса будут прописаны конкретные пары remote/circut, которые будет генерировать некая внешняя программа при заведении абонента, либо при описании свитча полностью. Втаком случае вы сможете полностью абстрагироваться от формата опции 82 на конкретной модели свитча.

Мы уже ходили по пути парсинга opt82, но при определенной концентрации разнородного железа все это выходит из под контроля и с трудом поддается автоматическому анализу, сейчас храним именно пару remote/circut.

 

В общем-то я думаю так же как и вы, т.е. я согласен. Я действительно хранил бы то, что удобнее радиусу. Просто уже есть база с маками клиентов и мы решили её заюзать, а opt82 мы парсим для незарегистрированных в системе маков. Ну типа так менее накладно и меньше менять надо.