Dhcp server linux option 82

isc-dhcp-server + option_82

надо настроить сабж. использую дебиан и freebsd-rip. вникаю по этой статье:
http://xgu.ru/wiki/%D0%9E%D0%BF%D1%86%D0%B8%D1%8F_82_DHCP

в статье уопминается 3-я версия isc-dhcp-server, которую нужно еще собрать с указанием опции USE_SOCKETS.
ради интереса посмотрел во фревые порты, если ли там опции сборки USE_SOCKETS или нет. так вот, в версии 3.1 они есть, а в 4.1 и 4.2 этих опции при наборе команды make config уже нет.
отсюда первый вопрос: надо ли собирать вручныю пакет с поддержкой option82 на дебиан, где используется версия пакета 4.1, или нет?

ради интереса залез в includes/site.h дебиан-пакета. вижу следующее описание:
/* Define USE_SOCKETS to use the standard BSD socket API.

On many systems, the BSD socket API does not provide the ability to
send packets to the 255.255.255.255 broadcast address, which can
prevent some clients (e.g., Win95) from seeing replies. This is
not a problem on Solaris.

In addition, the BSD socket API will not work when more than one
network interface is configured on the server.

However, the BSD socket API is about as efficient as you can get, so if
the aforementioned problems do not matter to you, or if no other
API is supported for your system, you may want to go with it. */

Оно достаточно расплывчатое, не ясно, имеет ли в текущей версии isc-dhcp какое-то отношение к пресловутой option82?

и второй вопрос, уже к тем, у кого option82 работает:
dhcp сервер в таком режиме конфигурации работает и в multicast режиме и в unicast, или только unicast?

Источник

Опция 82 DHCP

Материал из Xgu.ru

Опция 82 DHCP (DHCP option 82) — опция протокола DHCP, использующаяся для того чтобы проинформировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был получен запрос. Применяется при решении задачи привязки IP-адреса к порту коммутатора и для защиты от атак с использованием протокола DHCP (DHCP snooping).

Содержание

[править] Задача

Протокол динамического конфигурирования DHCP очень удобен — настройка стека TCP/IP клиентских машин не требует никакого внимания со стороны администратора, всё происходит само собой. С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост получит какой адрес. Если нужно сохранить удобство использования DHCP, но при этом сделать так, чтобы адреса были чётко закреплены за каждым компьютером, используется так называемая привязка к MAC-адресу: DHCP-сервер имеет таблицу соответствия MAC-адресов IP-адресам, и назначает IP-адреса в соответствии с этой таблицей. Минус этого решения — необходимость отслеживания MAC-адресов и сопровождения таблицы соответствия.

В некоторых случаях может помочь компромиссное решение — поставить IP-адреса в соответствие не MAC-адресам, а портам коммутатора, к которым подключен клиентский компьютер. Другой вариант — выдавать IP-адреса в зависимости от того, с какого DHCP-ретранслятора пришел запрос. В этом случае выдаются адреса из одной подсети, но с привязкой конкретных диапазонов адресов к различным коммутаторам, работающим как DHCP-ретрансляторы. Это может помочь облегчить администрирование сети в том смысле, что по IP-адресу клиентского компьютера, будет понятно к какому коммутатору он подключен.

Решить эти задачи позволяет опция 82 протокола DHCP.

Ниже описывается, каким образом настроить DHCP-сервер, чтобы он выдавал IP-адрес в зависимости от того, к какому порту коммутатора подключен клиент, сделавший запрос. Рассматривается случай, когда коммутатор, через который поступает запрос, используется в роли DHCP-ретранслятора (решение задачи для случая, когда это не так, описано на странице DHCP snooping).

[править] Протокол DHCP

DHCP (Dynamic Host Configuration Protocol) — один из важнейших протоколов в стеке протоколов TCP/IP, предназначенный для назначения хостам различных параметров необходимых для работы в сети, в частности, их IP-адресов, адреса шлюза по умолчанию, IP-адресов DNS-серверов и множества других.

Во взаимодействии по протоколу DHCP принимают участие две или три стороны:

• DHCP-клиент — тот, кто хочет получить параметры настройки TCP/IP;
• DHCP-сервер — тот, кто выдаёт эти параметры;
• DHCP-ретранслятор (relay agent) — вспомогательный участник, который может играть роль посредника между клиентом и сервером. Он используется в тех случаях, когда у клиента нет возможности обратиться к серверу напрямую, в частности, в том случае, если они находятся в разных широковещательных доменах. DHCP-ретранслятор обрабатывает стандартный широковещательный DHCP-запрос и перенаправляет его на DHCP-сервер в виде целенаправленного (unicast) пакета, а полученный от DHCP-сервера ответ, в свою очередь, перенаправляет DHCP-клиенту.

Как правило, DHCP-сервер выделяет IP-адреса (и прочие параметры TCP/IP) одним из двух способов:

• Случайным образом из предопределённого пула (в том случае, если клиенту ранее уже выдавался какой-то адрес, он может попробовать получить его вновь);
• Жёстко зафиксированным образом, исходя из MAC-адреса клиента.

[править] Option 82

Опция 82 состоит из двух подопций:

Agent Circuit ID — содержит информацию о том, с какого порта пришел запрос на DHCP-ретранслятор.

Agent Remote ID — идентификатор самого DHCP-ретранслятора (который задается при настройке, можно например использовать MAC-адрес коммутатора или его описание, любое удобное значение).

Опция 82 в запросе DHCP:

DHCP-серверы, поддерживающие опцию 82:

Несмотря на то, что это нигде не указано явно, вероятнее всего, Microsoft Windows 2003 Server опцию 82 не поддерживает. (Однако на личном опыте проверено что работает, надо только добавить эту опцию)

[править] Инсталляция и настройка DHCP сервера ISC-DHCP

Будем использовать dhcp-сервер ISC-DHCP (v3). ISC DHCP Server — наиболее распространнённый DHCP-сервер, из использующихся в UNIX/Linux-системах. Для нас сейчас важно и то, что это один из серверов, умеющих распознавать опцию 82.

Будем предполагать, что инсталляция и настройка сервера выполняется в Debian GNU/Linux. Пользователи других систем должны учесть, что процедура инсталляции и местоположение конфигурационных файлов могут несколько отличаться.

[править] Установка DHCP-сервера с поддержкой опции 82

В обычном случае установить откомпилированный DHCP-сервер из репозитория пакетов можно было бы с помощью команды:

и можно было бы считать, что на этом инсталляция сервера закончена, и можно переходить к его настройке. Однако, в том случае, если предполагается использование DHCP-ретранслятора (что обязательно, если будет использоваться опция 82), может потребоваться сборка пакета с включённой директивой USE_SOCKETS. Подробнее эта процедура описана ниже.

[править] Сборка с включённой директивой USE_SOCKETS

По умолчанию DHCP-сервер ожидает услышать запросы клиентов на широковещательном адрес 255.255.255.255. Однако, когда запрос перенаправляет DHCP-ретранслятор, запрос приходит непосредственно на адрес DHCP-сервера. Для того чтобы DHCP-сервер корректно обрабатывал информацию от DHCP-ретранслятора, его необходимо скомпилировать с использованием директивы

и указать в конфигурационном файле local-address.

Скачиваем исходники DHCP-сервера:

Перед началом сборки исходников необходимо установить все пакеты, необходимые для успешной сборки пакета, для чего выполнить:

Теперь необходимо в файле site.h раскомментировать директиву #define USE_SOCKETS:

Перейти в каталог dhcp3-3.0.6.dfsg:

Для того чтобы собрать пакет необходимо выполнить:

или, если сборка производится root’ом:

После сборки пакеты должны быть установлены в системе (инсталлируем только common и server, так как нам не нужен DHCP-ретранслятор и DHCP-клиент):

[править] Настройка DHCP-сервера

Сразу же после инсталляции пакета, сервер не заработает — сначала необходимо отредактировать его конфигурационный файл /etc/dhcp3/dhcpd.conf.

Интерфейс, на котором будет работать DHCP-сервер, передается ему в качестве аргумента при вызове.

В Debian GNU/Linux аргументы и ключи вызова программ принято указывать в соответствующих файлах в каталоге /etc/default, в частности, конфигурационный файл, в котором находятся опции для нашего сервера, называется /etc/default/dhcp3-server.

При условии, что сервер будет слушать запросы на интерфейсе eth0, файл будет выглядеть так:

Можно указать несколько интерфейсов, запросы с которых будет обрабатывать сервер. Они должны быть разделены пробелом.

Теперь можно запускать сервер:

После сборки сервера с #define USE_SOCKETS:

[править] Написание правил для соответствия адреса порту коммутатора

[править] Используемые операторы

suffix (data-expr, length)

Оператор suffix анализирует выражение data-expr и возвращает последние байты в указанном количестве. length — это числовое значение. Если data-expr или length равны нулю, то результат также будет равен 0. Если длина указанная в length больше чем сами данные, то suffix возвращает все данные.

substring (data-expr, offset, length)

Оператор substring анализирует данные и возвращает строку данных, которая начинается от указанного значения offset и имеет длину, равную указанной в length. Offset и length — числовые выражения. Если data-expr, offset или length равны нулю, то результат также равен 0. Если значение offset больше или равно длине data-expr, то будет возвращена нулевая строка. Если длина length больше чем длина данных оставшихся после offset, тогда возвращаемая строка будет содержать все данные от значения offset до конца.

binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)

Преобразует результат вычисления data-expr2 в текстовую строку, содержащую по одному числу для каждого элемента результата вычисления data-expr2. Числа разделены между собой результатом вычисления data-expr1. Параметр numeric-expr1 указывает основание системы исчисления (от 2 до 16), в которую должны преобразовываться числа. Параметр numeric-expr2 указывает количество битов на каждое число, полученное в результате преобразования. Оно может быть равно 8, 16 или 32.

Берём адрес leased-address, инвертируем его, а потом делим на 8 битные числа, каждые из которых преобразуем в 10-чную систему счисления. Полученные числа объединяем между собой через «.» и присоединяем «.in-addr.arpa.» справа.

• man dhcp-eval — описано как создавать такие выражения и описаны другие операторы.

[править] Просмотр информации на коммутаторе

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

Например, в коммутаторе ProCurve опция 82 выглядит следующим образом:

В коммутаторах других производителей она выглядит аналогично.

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

Информация о MAC-адресе коммутатора:

На коммутаторах D-Link DES-35xx и 3028 выглядит так.

[править] Примеры правил

Указываем, что нас интересует последний байт в circuit-id:

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

Правило для порта 5.

Аналогично для порта 45:

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

Если нам необходимо учитывать от какого relay-агента пришел запрос, то можно создать соответствующее правило:

Если нужно привязать IP-адреса не к портам коммутатора, а к самим коммутаторам как таковым, учитывать порт, с которого пришел DHCP-запрос (Agent Circuit ID), не обязательно, а важно настроить совпадение MAC-адреса или IP-адреса DHCP-ретранслятора (Agent Remote ID) в пришедшей опции 82.

[править] Пример конфигурационного файла DHCP-сервера

[править] Настройка коммутатора HP ProCurve для работы DHCP-ретранслятором

1. Включить DHCP-ретранслятор на коммутаторе (по умолчанию включен)
2. Включить ip routing
3. Настроить режим вставки опции 82 (drop, replace, validate)
4. Настроить ip helper-address
5. Клиенты и сервер должны быть в разных подсетях

Включение DHCP-ретранслятора на коммутаторе (по умолчанию включен):

Включить ip routing (на коммутаторе включается функциональность 3го уровня):

Настроить режим вставки опции 82 (drop, replace, validate):

Параметры команды dhcp-relay option 82:

• append — коммутатор добавит опцию 82 в пришедший DHCP-пакет.
• replace — коммутатор заменит опцию 82 в пришедшем DHCP-пакете на свои значения.
• drop — коммутатор отбросит DHCP-пакет, если в нем будет опция 82. Если DHCP-пакет пришел без опции 82, то коммутатор добавит опцию и передаст пакет.
• keep — для любого полученного DHCP-пакета с существующей опцией 82 не выполнять никаких изменений и отправить пакет в таком же виде как он пришел.
• [ip | mac] — что используется в опции 82 в качестве Agent Remote ID. По умолчанию используется MAC-адрес. При использовании IP-адреса, в поле Agent Remote ID будет указан IP-адрес VLAN, в котором был получен запрос от DHCP-клиента.

При одновременной работе DHCP-ретранслятора и DHCP snooping на коммутаторе, необходимо обратить внимание на то, что настройки DHCP snooping, по обработке пакетов с опцией 82, перекрывают настройки DHCP-ретранслятора.

Настройка ip helper-address (ip helper-address задается в VLAN, в котором находится DHCP-клиент. IP-адрес в этой команде — это адрес DHCP-сервера):

[править] Просмотр настроек на коммутаторе

Посмотреть настроенные ip helper-address для VLAN 1:

Источник

IPoE, а также Client-VLAN и DHCP Option 82

В этой статье я опишу что из себя представляет технология доступа в Интернет IPoE, которой на самом деле не существует. А также расскажу про схему Client-VLAN и про опцию 82 DHCP (DHCP Option 82), которые стали неотъемлемой частью этой несуществующей технологии. Все это, конечно же, с технической точки зрения и с примерами конфигов.

Существует множество технологий доступа в Интернет для конечных абонентов. В России особенно популярны две: PPTP и PPPoE. В обоих случаях создается PPP-туннель, производится аутентификация, и внутри туннеля ходит абонентский IP-трафик. Основное отличие этих протоколов – они работают на разных уровнях сетевой модели OSI. PPPoE работает на втором (канальном) уровне, добавляя специальные теги, идентифицирующие конкретный туннель, в Ethernet-фреймы. PPTP работает на третьем (сетевом) уровне, упаковывая IP-пакеты в GRE.

IPoE принципиально отличается от PPTP и PPPoE. Вообще этой технологии не существует. Нет RFC, нет никаких стандартов ее описывающих. Сам термин придуман, скорее всего, в России и является абстрактным. Означает он следующее: IP over Ethernet. Смысл именно такой, как и расшифровка – IP-трафик поверх Ethernet, грубо говоря, обычная локалка. Абоненту выдается в лучшем случае статический или динамический белый IP-адрес, в худшем случае серый IP с NAT. Контроль доступа в данном случае может осуществляется при помощи привязок IP-MAC на коммутаторах доступа или на BRAS или выделения VLAN на каждого абонента (так называемый Client-VLAN).

Client-VLAN

При использовании технологии Client-VLAN возникает проблема: как сэкономить IP-адреса? Ведь, если подумать, каждому клиенту надо выделять /30 подсеть. На самом деле проблема легко решаема. Привожу пример для маршрутизатора на базе Linux:

Подсеть 192.0.2.0/24 рекомендована IANA для использования в примерах.

Это классический Cisco’вский ip unnumbered в Linux’овой реализации. IP шлюза (192.0.2.1) вешается на loopback-интерфейс, делается unreachable для всей подсети, чтобы пакеты ходили только на хосты, для которых прописан роутинг. Далее поднимается VLAN и прописывается роутинг на конкретный хост (маска /32) с src шлюза. А можно сделать немного иначе (это лишний раз демонстрирует гибкость Linux):

Все эти варианты работают, можно выбрать тот, при котором интерфейсы отображаются наиболее удобным образом. Во всех случаях IP абонента – 192.0.2.101/24.

Proxy_arp

Еще одна проблема, с которой вы можете столкнуться – нет связи между абонентами в разных VLAN и с IP из одной подсети. Действительно, система абонента видит, что IP-адрес назначения в одной подсети с ней, и шлет ARP-запросы, чтобы определить MAC, но из этого ничего не выходит, т.к. они в разных VLAN. Для решения этой проблемы служит технология proxy_arp. Суть ее в том, что маршрутизатор при получении ARP-запросов с интерфейса будет проверять есть ли у него запрашиваемый IP на других интерфейсах. Если есть, то в ответ на ARP-запрос выдаст свой MAC. Таким образом, пакеты будут отправляться на маршрутизатор, который позаботится об их доставке. Включается proxy_arp для конкретного интерфейса следующим образом:

DHCP Option 82

При использовании IPoE DHCP упростит настройку сети на стороне абонента до нуля. Воткнул патчкорд и ты в сети. Только возникает вопрос: как DHCP узнает кому какой адрес выдавать? Можно определять по MAC, особенно если вы уже используете привязки IP-MAC. Но привязки MAC чреваты частыми звонками в поддержку, т.к. абоненты иногда меняют оборудование. Справиться с этой проблемой поможет расширение протокола DHCP – Option 82. Опция 82 содержит два поля:

• Agent Circuit ID – номер порта DHCP-релэя, на который пришел DHCP-запрос.
• Agent Remote ID – некий идентификатор самого DHCP-релэя.

В качестве DHCP-релэев при этом обычно выступают коммутаторы доступа, к которым непосредственно подключаются абоненты. В качестве Agent Remote ID обычно используется MAC коммутатора (по умолчанию в D-Link). Опция 82 поддерживается широким диапазоном оборудования, в том числе типичными у российских провайдеров D-Link DES-3526/3028/3200.
На коммутаторах D-Link есть два режима DHCP-релэя: dhcp_relay и dhcp_local_relay. dhcp_relay работает глобально, для всех портов и VLAN, при этом добавляется опция 82 и запрос передается уже не бродкастом, а непосредственно на DHCP-сервер, т.е. это полноценный DHCP-релэй. dhcp_local_relay работает для конкретных VLAN, но запрос по сути не релэится, а в него просто добавляется опция 82.
Базовые настройки dhcp_relay на D-Link’ах:

192.168.0.1 – IP-адрес DHCP-сервера, доступного в управляющем VLAN.
Базовые настройки dhcp_local_relay:

И наконец приведу базовый конфиг для ISC’s DHCP с комментариями:

Источник