Практические аспекты использования DHCP relay+option82

в 17:12, , рубрики: .net, dhcp, option82, relay, метки: , ,

В этой статье я хотел бы осветить практические аспекты использования 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-сервер могут (должны) находиться в разных подсетях — это неправда. Вот наша схема:

image

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

DLINK DES-3200

config vlan default delete 1-10

 #Удаляем из дефолтного VLAN-а все порты
create vlan VLAN7 tag 7
 
#Создаем  VLAN в котором находиться наш DHCP-сервер
config vlan VLAN7 add tagged 9-10 
#Добавляем туда тегированные порты 9 и 10 (смотрят в сторону провайдера)

create vlan VLAN10 tag 10
 
#Создаем  VLAN 10 в котором у нас сидят абоненты
config vlan VLAN10 add tagged 9
-10 
#Добавляем туда тегированные порты 9 и 10 
config vlan VLAN10 add untagged 1-8 
# Добавляем туда не тегированные порты 1-8 (абонентские порты)

config ipif System ipaddress 10.90.90.90/8 
#Задаем IP-адрес свитча                                     

config ipif System vlan VLAN7
#Вешаем его на VLAN7

enable dhcp_relay
#Активируем опцию
config dhcp_relay option_82 policy replace
#Говорим что если информация в пакете уже есть то заменить
config dhcp_relay option_82 remote_id default

#Просто сохраняем параметры по умолчанию (мак)
config dhcp_relay option_82 circuit_id default

#Просто сохраняем параметры по умолчанию (№ порта)
config dhcp_relay add vlanid 10 10.90.90.92
#Говорим что весь трафик с VLAN10 перехватывать и отправлять его на DHCP-сервер с адресом 10.90.90.92
create iproute default 10.90.90.92
#Создаем дефолный маршрут, в данном примере не уверен что нужен вообще, но по феншую положено

Теперь конфиг 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


local-address 10.90.90.92;

#Теоретически это должно указывать где будет создаваться сокет для прослушки, но практически я понял что эта опция рудимент, я её пробовал изменять и комментировать ни чего не менялось, но как говорят по феншую положено :). Вообще надо сказать что сервер будет «плевать» на все ваши указания и будет автоматом вешаться на интерфейсы IP-которых попадают в подсеть описанную в subnet секции!

if exists agent.circuit-id
{
 log ( info, concat( "Lease for ", binary-to-ascii (10, 8, ".", leased-address),.

 " raw option-82 info is CID: ", binary-to-ascii (10, 8, ".", option agent.circuit-id), " AID: ",

 binary-to-ascii(16, 8, ".", option agent.remote-id)));
}
#Это просто выводит записи в наш лог файл если обнаруживается опция 82

subnet 10.0.0.0 netmask 255.0.0.0 {
    pool {
        range 10.0.0.155;
    }
}
#Задаем подсеть и пул 

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

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

$sudo tcpdump -i eth0.7 -e -n -t

И если мы увидели что-то типа:

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

То есть нет ни каких броадкастов, значит, все идёт хорошо и настало время запускать наш DHCP-сервер.
В первый раз я рекомендую его запустить просто набрав в строке:

$sudo dhcpd

Тогда вы сразу увидите все ошибки, если они есть, и обязательно должна быть запись вида:

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

На всякий случай можно проверить спустя несколько секунд:

$pgrep dhcpd

Должен вернуть 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:

config safeguard_engine state enable
config safeguard_engine utilization rising 90 falling 30 state enable
#Это защита от перегрузки процессора
config traffic control 1-8 broadcast enable multicast enable unicast disable action drop threshol
d 64 countdown 5 time_interval 5
#Это спасет от множественных броадкастов, генерируемых клиентами
enable loopdetect
config loopdetect ports 1-8 state enable
config loopdetect recover_timer 1200 interval 10 mode port-based
#А это спасёт от петель если уж они образовались

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

xgu.ru/wiki/%D0%9E%D0%BF%D1%86%D0%B8%D1%8F_82_DHCP — здесь присутствует ошибка, я потратил много времени, чтобы ее отыскать. Выше я писал о ней (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.);
habrahabr.ru/post/143846 — здесь dhcp вынесен за пределы сети;
www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&sqi=2&ved=0CBwQFjAA&url=http%3A%2F%2Fwww.dlink.ru%2Fru%2Ffaq%2F62%2F228.html&ei=aAMAVeKvEKv7ygOA3YDwCA&usg=AFQjCNGE6yaics2SjYMhwyxB1KPX_vAk1A&sig2=OqT6ZhfDoEdAISjUyH0PiQ&bvm=bv.87611401,d.bGQ — здесь также dhcp вынесен за пределы сети.

Автор: big-town

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js