Ретранслятор dhcp dhcp relay zyxel keenetic настройка

ПОсле того как ты перевел Zyxel в режим точки доступа (путем убирания галочки в настройках интернет подключения), тебе нужно ОТКЛЮЧИТЬ DHCP сервер для основной и гостевой сети в настройках этого же ZYxel`я.

Заходишь во вкладку "Домашняя сеть"

Затем кликаешь на домашнюю сеть/гостевую сеть и снимаешь галочку с "Включен" в разделе Сервер DHCP

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

Как выполнить настройку функции Ретранслятор DHCP (DHCP Relay)?

В данной статье приведем пример настройки функции Ретранслятор DHCP (DHCP Relay) в интернет-центрах серии Keenetic. Функция DHCP Relay предназначена для того, чтобы устройства в выбранном сегменте вашей сети получали настройки от внешнего DHCP-сервера.
Для настройки нужно указать адрес DHCP-сервера и выбрать роль «WAN» для интерфейса, за которым этот сервер находится. Роль «LAN» следует назначить сегменту, который должен использовать указанный DHCP-сервер. Настройку можно найти в веб-конфигураторе интернет-центра в меню Домашняя сеть на вкладке DHCP Relay.

Далее рассмотрим пример практического применения функции Ретранслятор DHCP (DHCP Relay). Предположим, имеется следующая топология:
Интернет-центр Keenetic подключен к интернет-провайдеру через WAN-порт. На Keenetic организована стандартная локальная подсеть (Home network, 192.168.1.0/24), включающая в себя порты LAN1, LAN2 и Wi-Fi. Для порта LAN3 и LAN4 будет создан отдельный интерфейс DMZ (192.168.3.0/24), в котором будет находиться сервер с IP-адресом 192.168.3.10 и который должен раздавать IP-адреса, в том числе и для хостов интерфейса Home network.

Для создания DMZ-интерфейса необходимо выполнить указанные ниже команды. Для этого нужно подключиться к режиму командной строки (CLI) интернет-центра.

Для интерфейса Home network необходимо будет отключить DHCP-сервер, чтобы хосты получали IP-адрес только от сервера, расположенного в подсети DMZ. Как настроить различные сочетания работы DHCP-сервера на устройствах серии Keenetic, указано в статье: «Варианты работы DHCP-cервера на интерфейсах интернет-центра»

Для того чтобы интерфейсы DMZ и Home network могли "общаться" между собой, необходимо отключить функцию isolate-private с помощью следующих команд:

Читайте также  Сколько гигабайтов в одном терабайте

Далее в настройках веб-конфигуратора в меню Домашняя сеть > DHCP Relay необходимо указать IP-адрес DHCP-сервера и роли интерфейсов в работе данной функции. WAN — интерфейс, где находится DHCP-сервер (он может быть один), LAN — интерфейс, где находится клиент (их может быть несколько).

После этого клиенты в сети Home network должны будут получать IP-адреса от DHCP-сервера сети DMZ (в нашем примере, это IP-адреса из диапазона 192.168.3.x).

Если посмотреть дампы сетевых пакетов (собранные с помощью программы-анализатора трафика Wireshark) с клиента и сервера, то можно увидеть весь механизм работы DHCP Relay.

Дамп сетевых пакетов с клиента:

Дамп сетевых пакетов с сервера:

Из дампа видно, что клиент рассылает броадкастовый (широковещательный) запрос DHCP Discover в своей подсети. Запрос принимает интернет-центр 192.168.1.1 и транслирует его в DMZ-интерфейс на DHCP-сервер.

Пользователи, считающие этот материал полезным: 14 из 28

В этой статье я хотел бы осветить практические аспекты использования 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 процесса, если ни чего не выведет, проверяйте конфигурацию.

Читайте также  Приложение gmail остановлено что делать на samsung

Для чего нужна такая проверка? Я помню случаи, когда сервер стартовал, висел в памяти несколько секунд и вылетал. А я тщетно пытался получить получить 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-сервер за пределы сети.

Ссылка на основную публикацию
Adblock
detector