Dhcp опция 82 что это
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
192.168.0.1 – IP-адрес DHCP-сервера, доступного в управляющем VLAN.
Базовые настройки dhcp_local_relay:
И наконец приведу базовый конфиг для ISC’s DHCP с комментариями:
Сеть на DHCP Option82 – это просто
В данной статье речь пойдет о построении сети с использованием технологии подключения пользователей, известной как IPoE с использованием динамической выдачи адресов по протоколу DHCP с использованием опции 82.
Итак нашей задачей является построить сеть в которой от пользователя требуется минимум действий для авторизации и работы в сети. Можно даже назвать это как: «воткнул кабель в компьютер, и заработало».
В качестве биллинговой системы мы будем использовать бесплатную (до 200 абонентов) сертифицированную АСР Felix2. В качестве DHCP сервера будем использовать ISC DHCP сервер.
Общая схема работы
Когда пользователь включает компьютер, операционная система отправляет DHCP запрос на получение IP адреса в сеть. На коммутаторе включено перенаправление DHCP запросов (DHCP Relay) и включена поддержка опции 82 протокола DHCP, поэтому он перехватывает DHCP запрос от пользователя, добавляет данные Option82 (Agent Circuit ID и Agent Remote ID) к DHCP пакету и перенаправляет запрос на DHCP сервер.
Когда DHCP запрос попадает на DHCP сервер, тот выдает IP-адрес основываясь на данных текущей конфигурации. В конфигурации задано соответствие IP-адреса, выдаваемого пользователю, IP-адресу и порту коммутатора к которому подключен пользователь. Конфигурация DHCP сервера формируется АСР Felix2 по имеющейся в базе данных информации.
АСР Felix2 периодически забирает от DHCP сервера данные о MAC адресах пользователей (которым были выданы IP-адреса) на портах коммутаторов. По IP-адресу и номеру порта коммутатора система находит пользователя в базе и отмечает, что MAC адрес принадлежит этому пользователю.
Также АСР Felix2 периодически забирает ARP таблицу с маршрутизатора (таблица соответствий IP — MAC) и, если пара IP-MAC соответствует пользователю в базе, данный пользователь считается авторизованным. Как только пара IP-MAC пропадает (пользователь выключает компьютер) система переводит пользователя в список неавторизованных (выполнив перед этим проверку, что оборудование абонента действительно выключено).
Практическая реализация
Для начала нам потребуется компьютер с двумя сетевыми картами и любой коммутатор, поддерживающий DHCP Relay (option 82). Первую (тестовую) сеть будем строить по следующей схеме:
В данной схеме система на АСР Felix2 будет выполнять дополнительно функцию маршрутизатора.
Установка
Скачаем (felix2.ru/download) и установим любым из описанных способов на сервер АСР Felix2.
В данной статье мы будем использовать «Установочный диск АСР Felix2». Подробная инструкция по установке АСР Felix2 находится здесь: felix2.ru/documentation
После установки входим в систему, используя логин root и пароль, указанный во время установки.
Сетевой интерфейс eth0 после установки сконфигурирован для работы с внутренней сетью:
IP-адрес: 10.1.1.1
Маска подсети: 255.255.255.0
Интерфейс eth1 нужно настроить для работы с вышестоящим Интернет провайдером:
Здесь 1.1.1.2 — IP-адрес выданный нам вышестоящим Интернет провайдером, 1.1.1.1 – IP-адрес шлюза провайдера.
Чтобы конфигурация сети не сбросилась после перезагрузки, ее нужно описать в файле /etc/network/interfaces
Установим ISC-DHCP сервер:
Сразу после установки DHCP сервер не запустится, так он еще не сконфигурирован:
Конфигурирование
Файл шаблона конфигурации ISC DHCP сервера (dhcp_opt82_ip-port.conf) и все остальные необходимые конфигурационные файлы можно скачать отсюда:
ftp://download.felix2.ru/config.examples/felix2_dhcp_opt82.tar.gz
Скачиваем, распаковываем, заменяем конфигурационные файлы:
Перезапускаем АСР Felix2:
Создание оборудования и тестового пользователя в АСР Felix2
Зайдем в веб-интерфейс администратора. Можно для этого использовать тестовую машину, временно поставив на ней статический IP-адрес (например 10.1.1.10/24). Веб интерфейс администратора доступен на 444 порту по протоколу HTTPS. Логин/пароль по умолчанию: su/su.
Выбираем оборудование к которому будет подключен пользователь. Система предложит выбрать оборудование из списка оборудования, установленного в данном доме.
Указываем что пользователь будет подключен к первому порту коммутатора. Отмечаем флаг «Подключение выполнено» и нажимаем «Добавить».
Проверим, что конфигурационный файл DHCP сервера обновился:
Проверим, что DHCP сервер работает:
Настройка коммутатора
Теперь нужно настроить коммутатор. Если коммутатор «из коробки», в инструкции должен быть указан IP-адрес «по умолчанию». Если оборудование «б/у», и вы не знаете какой у него IP-адрес/логин/пароль, нужно сбросить конфигурацию через консольное подключение.
В данной статье мы будем использовать коммутатор DES-3200-28 «из коробки».
Ставим на тестовой машине статический IP-адрес (например 10.90.90.1/8) Подключаемся к коммутатору по протоколу telnet:
Включаем, настраиваем DHCP Relay:
Теперь коммутатор будет перехватывать DHCP запросы, добавлять идентификационную информацию (option 82) и отправлять на DHCP сервер (10.1.1.1)
Задаем маршрут «по умолчанию» и новый IP-адрес коммутатора:
После последней команды (смена IP-адреса) соединение будет разорвано. Ставим на тестовой машине статический IP-адрес (например 10.1.1.10/24) Подключаемся к коммутатору по новому адресу, сохраняем конфигурацию:
Включаем на тестовом компьютере получение сетевых настроек по DHCP.
Подключаем тестовый компьютер в первый порт коммутатора. Проверяем что DHCP-Relay пакеты от коммутатора доходят до сервера и клиент получает IP-адрес:
Проверяем, что данные пользователя правильно отображаются в интерфейсе АСР Felix2.
Реальная схема сети
600 абонентов). Аплинк от магистрального провайдера приходит в оптический порт коммутатора. Этот порт нужно объединить в VLAN с портом, куда подключается сетевая карта eth1 от сервера с АСР Felix2.
Например, объединяем 1 и 24 порт в 1000й VLAN:
При росте сети также желательно разнести дома по отдельным VLAN.
Схема сети с выделенным маршрутизатором
При росте внутрисетевого(локального) трафика, соединение между коммутатором и сервером с АСР Felix2, выполняющим одновременно роль маршрутизатора, станет узким местом. Чтобы избежать этого, нужно установить выделенный маршрутизатор.
Также нужно указать АСР Felix2 получать ARP таблицу с внешнего маршрутизатора. Отредактируем файл /etc/felix2/felix2.xml:
Модуль arp_fetcher может получать таблицу ARP адресов с оборудования CISCO (interface=«CISCO»), D-Link (interface=«DLINK»), или с программного маршрутизатора на базе Linux (interface=«Linux»).
По просьбе хабражителей добавлен пример сгенерированного системой конфигурационного файла для ISC DHCP сервера.
В данном примере пользователям, подключенным в порты 1-3 коммутатора с адресом 10.1.1.253, выдаются адреса 10.1.1.2-10.1.1.4 соответственно.
Практические аспекты использования DHCP relay+option82
В этой статье я хотел бы осветить практические аспекты использования 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-сервер за пределы сети.
04. DHCP опция 82
Опция 82 протокола DHCP используется для того, чтобы проинформировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был получен запрос. Коммутатор с функцией DHCP-relay или DHCP-snooping добавляет опцию в DHCP-запросы от клиента и передает их серверу. DHCP-сервер, в свою очередь, предоставляет IP-адрес и другую конфигурационную информацию в соответствии с преднастроенными политиками на основании информации, полученной в заголовке опции 82. Коммутатор снимет заголовок опции с принятого от DHCP-сервера сообщения и передаст сообщение клиенту в соответствии с информацией о физическом интерфейсе, указанной в опции. Применение опции 82 прозрачно для клиента.
Заголовок опции 82 может содержать несколько суб-опций. RFC3046 описывает 2 суб-опции Circuit-ID и Remote-ID.
4.2. Настройка добавления опции 82
Включить добавление опции 82 DHCP relay;
Включить добавление опции 82 DHCP snooping;
Настроить атрибуты опции 82 DHCP relay на интерфейсе;
Включить опцию 82 для DHCP сервера;
Настроить формат опции 82 для DHCP Relay;
Настроить метод создания опции 82;
Команды для диагностики опции 82;
Включить добавление опции 82 DHCP relay:
Команда
Описание
ip dhcp relay information option
no ip dhcp relay information option
! В режиме глобальной конфигурации
Включить опцию 82 для добавления DHCP relay
Выключить добавление опции 82 DHCP relay;
2. Включить добавление опции 82 DHCP snooping;
Команда
Описание
ip dhcp snooping information enable
no ip dhcp snooping information enable
! В режиме глобальной конфигурации
Включить опцию 82 для добавления DHCP snooping
Выключить добавление опции 82 DHCP snooping;
3. Настроить атрибуты опции 82;
Команда
Описание
ip dhcp relay information policy
no ip dhcp relay information policy
! В режиме конфигурирования интерфейса VLAN
Восстановить значение по-умолчанию (replace)
ip dhcp snooping information option allow-untrusted [replace]
no ip dhcp snooping information option allow-untrusted
! В режиме глобальной конфигурации
Отбрасывать DHCP-запросы c добавленной опцией 82, полученные с недоверенных портов (по-умолчанию)
ip dhcp
no ip dhcp
! В режиме конфигурирования интерфейса
Задать контекст не длиннее 64 символов, передаваемый в качестве суб-опции Circuit-ID, добавляемой в DHCP-запросы, полученные с интерфейса. Возможно указать следующие ключи:
Вернуть значение по-умолчанию (standard)
ip dhcp
! В режиме конфигурирования интерфейса
Задать формат опции 82, суб-опции Circuit-ID, добавляемой агентом DHCP-relay
4. Включить опцию 82 для DHCP сервера;
Команда
Описание
ip dhcp server relay information enable
no ip dhcp server relay information enable
! В режиме глобальной конфигурации
Идентифицировать сервером коммутатора опцию 82.
Игнорировать сервером коммутатора опцию 82.
5. Настроить формат опции 82 для DHCP Relay;
Команда
Описание
ip dhcp
! В режиме глобальной конфигурации
Задать формат опции 82, суб-опции Circuit-ID
ip dhcp
! В режиме глобальной конфигурации
Задать формат опции 82, суб-опции Remote-ID
6. Настроить разделитель;
Команда
Описание
ip dhcp
no ip dhcp
! В режиме глобальной конфигурации
Задать разделитель каждого параметра суб-опций опции 82.
Восстановить значение по-умолчанию (slash)
7. Настроить метод создания опции 82;
Команда
Описание
ip dhcp
no ip dhcp
! В режиме глобальной конфигурации
Задать метод создания суб-опции Remote-ID опции 82
Восстановить значение по-умолчанию (mac)
ip dhcp
! В режиме глобальной конфигурации
Задать формат заданной пользователем суб-опции Remote-ID опции 82
ip dhcp
no ip dhcp
! В режиме глобальной конфигурации
Задать метод создания суб-опции Circuit-ID опции 82
Восстановить значение по-умолчанию (vlan port)
ip dhcp
! В режиме глобальной конфигурации
Задать формат заданной пользователем суб-опции Circuit-ID опции 82
8. Команды для диагностики опции 82;
Команда
Описание
show ip dhcp relay information option
! В привилегированном режиме
Отобразить информацию состоянии опции 82
debug ip dhcp
! В привилегированном режиме
Отобразить информацию о пакетах, обработанных агентом DHCP relay или DHCP snooping.
4.3. Пример конфигурации опции 82
4.3.1. Пример конфигурации опции 82 для DHCP relay
В приведенном на рисунке 42.2 примере коммутаторы уровня 2 Switch1 и Switch2 подключены к коммутатору 3-го уровня Switch3, который будет передавать сообщения от DHCP-клиента DHCP-серверу и обратно как агент DHCP relay. Если DHCP опция 82 отключена, DHCP-сервер не может распознать, к сети какого коммутатора, Switch1 или Switch2, подключен DHCP-клиент. В этом случае ПК, подключенные Switch1 и Switch2, получат адреса из общего пула DHCP-сервера. Если же DHCP опция 82 включена, Switch3 будет добавлять информацию о портах и VLAN в запрос от DHCP-клиента. Таким образом, DHCP-сервер сможет выделить адрес из двух разных подсетей, чтобы упростить управление.
Конфигурация коммутатора Switch3(MAC address is f8:f0:82:75:33:01):
Пример конфигурации ISC DHCP Server для Linux:
После описанных выше настроек DHCP-сервер будет выделять адреса из диапазона 192.168.102.21
192.168.102.50 для устройств, подключенных к коммутатоу Switch2, и из диапазона 192.168.102.51 ～ 192.168.102.80 для устройств, подключенных к коммутатоу Switch1.
4.3.2. Пример конфигурации опции 82 для DHCP snooping
Как показано на рисунке 42.3, коммутатор уровня 2 Switch1 c включенным DHCP-snooping передает DHCP-запросы серверу и ответы от DHCP-сервера клиенту. После того, как на коммутаторе будет включена функция добавления опции 82 для DHCP snooping, Switch1 будет добавлять информацию о коммутаторе, интерфейсе и VLAN клиента в сообщения запроса.
Конфигурация коммутатора Switch1(MAC address is f8:f0:82:75:33:01):
Пример конфигурации ISC DHCP Server для Linux:
После описанных выше настроек DHCP-сервер будет выделять адреса из диапазона 192.168.102.51 ～ 192.168.102.80 для устройств, подключенных к коммутатоу Switch1.
4.4. Решение проблем с конфигурацией опции 82
Убедитесь, что DHCP-relay и/или DHCP-snooping настроен правильно;
Опция 82 требует взаимодействия DHCP relay и DHCP сервера для выделения IP-адресов. DHCP-сервер должен установить политику выделения адресов основываясь на сетевой топологии DHCP-relay. Если в сети больше одного ретранслятора, уделите внимание политике передачи DHCP-запросов;
При поиске неисправностей подробная информация о процессе работы функции опции 82 DHCP-relay и DHCP-сервера может быть получена с помощью команд «debug ip dhcp relay packet» и «debug ip dhcp server packet».