Dhcp relay agent information

Коммутатор может быть сконфигурирован как агент DHCP Relay. В этом случае расширяются возможности применения DHCP-серверов в сети, поскольку уже не нужно использовать несколько DHCP-серверов, по одному в каждой подсети. Коммутатор просто перенаправляет DHCP-запрос от клиента в локальной подсети на удалённый DHCP-сервер.

Option 82 используется для передачи дополнительной информации в DHCP-запросе. Причём эту информацию добавляет сам коммутатор. Эта информация может быть использована для применения политик для увеличения уровня безопасности и эффективности.
Для простоты эти пакеты содержат информацию BOOTP, т.е. DHCP-запросы обрабатываются коммутатором также как BOOTP-запросы.

Формат поля опции с Circuit ID — в ней указывается порт коммутатора, за которым находится клиент и VID соответствующего VLAN:

1. 2. 3. 4. 5. 6. 7.
1 6 0 4 VLAN Module Port
1 байт 1 байт 1 байт 1 байт 2 байта 1 байт 1 байт

1. Тип опции 2. Длина 3. Тип Circuit ID 4. Длина
5. VLAN : VLAN ID DHCP-запроса клиента
6. Module : Для автономного коммутатора, поле Module всегда 0; для стекируемого коммутатора, Module = Unit ID.
7. Port : Порт коммутатора, с которого получен DHCP-запрос (начинается с 1) port

Формат поля опции с Remote ID — в ней указывается MAC-адрес коммутатора, являющегося агентом DHCP Relay:

1. 2. 3. 4. 5.
2 8 0 6 MAC address
1 байт 1 байт 1 байт 1 байт 6 байтов

1. Тип опции 2. Длина 3. Тип Remote ID type 4. Длина
5. MAC address : MAC-адрес коммутатора.

Оборудование:

  1. DHCP-сервер 10.51.8.1 в подсети 10.0.0.0/8
  2. Маршрутизатор или коммутатор L3, выступающий в роли шлюза для 2-ух подсетей
    10.51.8.11 для подсети 10.0.0.0/8
    30.51.8.11 для подсети 30.0.0.0/8
  3. Коммутатор L2 (DES-3526/DES-3550) в роли агента DHCP Relay
    30.51.8.12 в подсети 30.0.0.0/8
    MAC-адрес: 00-80-C8-35-26-0A
  4. 2 ноутбука в качестве DHCP — клиентов, подсоединённые к портам 9 и 10 коммутатора L2 соответственно

Схема сети:

Задача:

  1. DHCP-сервер использует диапазон адресов 30.51.8.100 — 30.51.8.200 для выдачи DHCP-клиенту, запросы которого перенаправляются агентом DHCP Relay 30.51.8.12 (коммутатор L2)
    — Обычный режим DHCP
  2. Как только какой-либо клиент DHCP подключается к порту 9 коммутатора L2, DHCP-сервер выдаст ему IP-адрес 30.51.8.161; если к порту 10 — то 30.51.8.162. — Функция DHCP option 82

Команды для настройки коммутатора L2 (DES-3526/DES-3550):

  1. create iproute default 30.51.8.11
  2. config dhcp_relay add ipif System 10.51.8.1
  3. config dhcp_relay option_82 state enable
  4. enable dhcp_relay

Настройка DHCP-сервера:

В этом примере используется 30-ти дневная версия haneWIN DHCP server 2.1, которую вы можете взять с сайта www.hanewin.net

  1. В пункте Option -> Preferences -> DHCP взведите галочку Accept Relay Agent Information (Option 82)
  2. Сконфигурируйте Option -> Default Client Profile -> Basic Profile
    Relay IP : 30.51.8.12
    Dynamic IP Addresses : От 30.51.8.100 до 30.51.8.200
    Subnet mask : 255.0.0.0
    Gateway Address : 30.51.8.11
  3. Сконфигурируйте DHCP option 82
    a) Задайте IP-адрес 30.51.8.161 для DHCP-клиента A, подключённого к порту 9 коммутатора L2
    "Add static entries"
    Взведите галочки "Circuit Identifier" и "Remote Identifier"
    Hardware Address : 00040001000900060080c835260a
    IP Address : 30.51.8.161
    b) Задайте IP-адрес 30.51.8.162 для DHCP-клиента B, подключённого к порту 10 коммутатора L2
    "Add static entries"
    Взведите галочки "Circuit Identifier" и "Remote Identifier"
    Hardware Address : 00040001000a00060080c835260a
    IP Address : 30.51.8.162

Материал из 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:

В этой статье я хотел бы осветить практические аспекты использования DHCP relay+option82 как возможность авторизации (в дальнейшем именно эта связка будет иметься ввиду), а так же привести примеры конфигурации свитча Dlink DES-3200-10 и isc-dhcp-server. Практически во всех статьях dhcp relay трактуют так: «можно вынести dhcp-сервер за пределы широковещательного домена». Однако почему-то не упоминают или почти не упоминают, что это хорошая возможность избавиться от широковешательных запросов в пределах того же самого широковешательного домена. И самое главное, на что акцентирую внимание — мы можем быть уверены, благодаря option82, что запрос пришёл именно со свитча с заданным маком и именно с порта с указанным номером, а следовательно — таким образом можно «авторизовать» пользователя.

Я немного позанудствую и напомню, как действует DHCP relay. Он перехватит широковещательный запрос (VLAN-а, на который он настроен), обернёт его в L3 и отправит unicast-ом указанному DHCP-серверу. Ну и не лишним будет напомнить, что делаетoption82. Она добавляет в DHCP-пакет два дополнительных параметра:

DHCP-Relay-Circuit-Id — номер порта с которого пришёл запрос.
DHCP-Relay-Remote-Id — (по умолчанию) макадрес свитча с которого пришёл запрос.

Ещё хочется сказать о методах внедрения этой опции в пакет.В оборудовании Dlink есть два способа:

dhcp_relay — добавляет Option82 и как писалось выше, обернёт его в L3 и отправит unicast-ом указанному DHCP-серверу
dhcp_local_relay (DHCP Snooping) — только добавляет Option82 и пересылает широковещательный пакет дальше.

Немного отклонюсь от темы. Дело в том что конструкцию dhcp_local_relay я нашёл только в оборудовании Dlink. Мне стало интересно, почему же другие производители не внедрили такую замечательную опцию? Оказывается, внедрили, и давно. Называется она DHCP Snooping.

Возможно, у кого-то возникнет вопрос: «зачем нам избавляться от широковещательного трафика»? Дело в том, что на практике я очень часто встречался с таким явлением, что при выходе из строя коммутатора, например, в результате грозы, возникают петли, что приводит к широковещательному шторму. Конечно, как вы уже догадались, от одного широковещательного трафика в IPv4 нам все равно не избавиться — это ARP-трафик. Именно он отвечает за построение таблиц MAC-IP. Конечно, можно это запретить и заполнить таблицы вручную. Но, боюсь что возникшие при этом неудобства сведут на нет все прелести от статических ARP-таблиц.

Во всех статьях указано, что DHCP-клиент и DHCP-сервер могут (должны) находиться в разных подсетях — это неправда. Вот наша схема:

Далее я приведу пример конфигураций:

Теперь конфиг isc-dhcp-server (isc-dhcpd-4.2.4 ) на
Linux big-A75F-M2 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux:

$sudo apt-get install vlan-tools isc-dhcp-server
$sudo vconfig add eth0 7
$sudo ifconfig eth0.7 10.90.90.92/8
#Создаем VLAN7 и назначаем адрес 10.90.90.92/8 на котором у нас будет висеть сервер DHCP

Конечно, это только стендовый конфиг, но нам самое главное разобраться с принципом работы. Все же забегая в перед я могу сказать, что у меня работает биллинговая система с option82 и конструкцией dhcp_local_relay(dhcp snooping), а в качестве сервера используется freeradius2 с perl-выборкой IP-адресов из базы postgres. Но это уже выходит за рамки данной статьи.

На машине с сервером запускаем:

c0:a0:bb:48:e5:b0 > 00:15:17:db:e3:e0, ethertype IPv4 (0x0800), length 345: 10.90.90.90.68 > 10.90.90.92.67: BOOTP/DHCP, Request from 48:5b:39:43:78:e5, length 303

Listening on LPF/eth0.7/00:15:17:db:e3:e0/10.0.0.0/8
Sending on LPF/eth0.7/00:15:17:db:e3:e0/10.0.0.0/8

Должен вернуть UID процесса, если ни чего не выведет, проверяйте конфигурацию.

Для чего нужна такая проверка? Я помню случаи, когда сервер стартовал, висел в памяти несколько секунд и вылетал. А я тщетно пытался получить получить IP-адрес.

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

Dec 2 20:36:17 big-A75F-M2 dhcpd: DHCPREQUEST for 10.0.0.155 from 48:5b:39:43:78:e5 (big-1001PX) via 10.90.90.90

Dec 2 20:36:17 big-A75F-M2 dhcpd: DHCPACK on 10.0.0.155 to 48:5b:39:43:78:e5 (big-1001PX) via 10.90.90.90

Dec 2 20:38:06 big-A75F-M2 dhcpd: Lease for 10.0.0.155 raw option-82 info is CID: 0.4.0.10.0.3 AID: 0.6.c0.a0.bb.48.e5.b0

Теперь одна очень важная вещь, про неё нигде не написано, но я дошёл до неё экспериментальным путём. IP-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам. Ни при каких других комбинациях мне не удалось заставить работать связку Dlink DES-3200 (Boot PROM Version: Build 4.00.002 Firmware Version: Build 4.04.004 Hardware Version: C1) и isc-dhcp-server 4.2.4.

И еще не большой бонус, как не погибнуть от броадкастов. Конфиг для Dlink DES-3200 С1:

Это статья не клон и не попытка переписать чужие статьи своими словами. Ниже список похожих публикаций и отличия от них. В своей статье я делал акцент на использование данной конструкции как метод авторизации, а не попытку вынести DHCP-сервер за пределы сети.


[an error occurred while processing the directive]
Карта сайта