Dslforum org в роутере что это
Делаем гостевую Wi-Fi сеть в ВУЗе, часть 2. Функции для гостевой Wi-Fi сети
При расширении зоны действия Wi-Fi увеличением числа точек доступа, управляемых шлюзом Zyxel VPN300 (сначала был Zyxel UAG5100), увеличилось количество гостей и проблемы начались в час пик со скоростью интернета, открытием сайтов, шустростью сёрфинга. Уже не успевал мониторить/конфигурировать комплекс и оперативно реагировать на заявки.
Помощника не дали, как это своими силами лечилось и чем настраивалось, делюсь опытом для всех и проведу краткую экскурсию по функциям.
Вот и вот мои предыдущие статьи. В конце текста информация обо мне.
Будут рассмотрены функции
на шлюзах Zyxel:
на коммутаторах Zyxel:
Вообще, проблемы начались ещё при UAG5100, поэтому сначала с ним были настроены функции, опробованы в реальных условиях и реально помогло. Поэтому, когда получили VPN300, эти же функции активировал на нём и всё отлично работает. Уже не помню, когда гости последний раз не могли получить фотку или отправить письмо.
Функции на шлюзах Zyxel
1) Ограничение скорости в профиле SSID – ограничивает скорость каждому гостю, подключённого к точке доступа, управляемой шлюзом (рис.1).
Блокировка трафика Intra-BSS – запрещает перекрестный трафик в сети внутри SSID на одной точке доступа (ТД) (рис.1).
На автономные и ТД Nebula правила не действуют, только на управляемые шлюзом ТД.
Рис.1. Ограничение скорости в профиле SSID и блокировка трафика Intra-BSS.
ограничили скоростью любителей покачать торренты или просмотром 4К на телефоне при медленном интернет-канале провайдера.
блокируется рассылка трафика от соседних телефонов в пределах одной ТД. После этого устройства Wi-Fi уже не так много мусора получают от соседей. Сёрфинг стал шустрее и соседи на ТД не пингуются.
Рис.2. Изоляция L2.
ограничивается рассылка трафика от гостевых устройств в пределах шлюза. Сёрфинг стал шустрее, ТД и соседи на разных ТД не пингуются, кроме тех, кто внесён в белый список;
значительно повысилась отказоустойчивость сети.
3) Привязка IP/MAC-адресов – шлюз проверяет связку IP-MAC со своей базой выданных IP при поступлении запросов (рис.3). Пользователь не сможет вручную назначить своему компьютеру другой IP-адрес и использовать его для подключения к шлюзу.
Рис.3. Привязка IP/MAC-адресов.
Итог: бывают кулхацкеры, сканируют сеть и ставят себе чужие IP или чайники с статическими IP на ноутбуках и долбят всю сеть в поисках домашнего сетевого диска с IP 192.168.1.2. Шлюз препятствует их несанкционированному вмешательству и незамедлительно сообщает на e-mail (п.13) и в логи, успеваем принять меры по блокировке таких гостей.
4) BWM (Bandwidth Management) – управление пропускной способностью (рис.4). Ограничение скорости силами шлюза любому подключённому устройству/учётке/подсети или группе устройств/учёток/подсетей.
Рис.4. BWM (Bandwidth Management) – управление пропускной способностью.
В гостевой Wi-Fi сети всем неавторизованным (их много) ограничиваем скорость до минимума (например, 256 кбит/с), чтобы не заваливали агрессивными запросами (куча вкладок в браузере, вирусы, обновления), но разрешаем повышенные скорости до внешних серверов авторизации, для быстрой загрузки страницы авторизации. Далее, всем авторизованным выставим комфортные скорости, а VIP-персонам безлимит.
ВНИМАНИЕ! VIP-персоны с безлимитными скоростями упрутся в установленные ограничения скоростей в профиле SSID (рис.1), поэтому в профиле SSID выставляем максимально безопасные ограничения (30 мбит/с), чтобы VIP-персоны всю полосу на одной ТД не заняли.
Правилам можно применить расписание, к примеру, ночью авторизованным ещё выше скорости выделять.
Функционал очень широкий и понятный. Разберётесь. Подойдёт сетям с автономными и ТД Zyxel Nebula.
Итог: обезопасили гостевую сеть от агрессивных Wi-Fi устройств неавторизованных гостей, которые не собираются проходить авторизацию и засоряют её. И умеренно ограничиваем скорость большому количеству авторизованных во избежание перегруза интернет-канала.
5) Контроль сессий – ограничение количества сессий гостям (рис.5).
Рис.5. Контроль сессий.
Например, делаем так (правила действуют снизу вверх):
Правило №1. Для авторизованных телефонов и ноутбуков поставим 384, вполне хватает для спокойного сёрфинга, чтения новостей, просмотра роликов;
Правило №2. При использовании внешнего сервиса авторизации разрешим 1024 сессий на внешние серверы авторизации;
Правило №3. Неавторизованным поставим 256, чтобы не заваливали агрессивными запросами (куча вкладок в браузере, вирусы, обновления).
Итог: ещё раз обезопасили гостевую сеть от агрессивных Wi-Fi устройств неавторизованных гостей, которые не собираются проходить авторизацию, но при этом засоряют её.
Рис.6. Веб-аутентификация.
гибкая возможность назначить различным устройствам авторизацию как встроенный биллинг, внешний сервис или не требовать авторизацию у устройств, неспособные пройти авторизацию (телевизоры; терминалы, кассовые аппараты, активация новых Apple; Windows);
немаловажен ещё момент, а если внешний сервис не будет доступен? Тогда всем включаем встроенный биллинг и ресепшн по предварительной записи раздаёт ваучеры по паспорту (постановление Правительства РФ №758 от 31 июля 2014 года). Очень удобно и полная отказоустойчивость 24/7 при активном заселении гостей или перед началом конференции.
Активируется платной лицензией «Управление хот-спотами (биллинг)» на шлюзах Zyxel линейки VPN (все); USG Flex (200/500/700). Функционал отсутствует у USG Flex 100/100W и всей линейки ATP.
Рис.7-1. Биллинг.
Метод аккаунтинга (Рис.7-1):
Без накопления (Time-To-Finish) – при первой авторизации по учётке, запускается таймер учёта оставшегося времени и учётка аннулируется по истечении выданного времени с момента первой авторизации, вне зависимости от использования интернета. Например, в 9 утра авторизовались по учётке с тарифом «2 часа», поработали полчаса и вышли из учётки (logoff), она всё равно она аннулируется в 11 часов. Квоты на скачивание/отправку в мбайт/гбайт недоступны в этом методе.
Накопление (Accumulation) – при первой авторизации по учётке, запускается таймер учёта времени работы в интернете и учётка аннулируется при израсходовании выданного времени с момента первой авторизации. Например, в 9 утра авторизовались по учётке с тарифом «2 часа», поработали полчаса и вышли из учётки (logoff), таймер приостановится и возобновит учёт времени при повторной авторизации и так до повторного логоффа, или срабатывания таймаута неактивности, или полного истечения выданного времени. Квоты на скачивание/отправку в мбайт/гбайт доступны в этом методе.
Накопительная учётная запись будет удалена через ХХ дней – не до конца использованные учётки в любом случае будут удаляться через ХХ дней с момента первой авторизации.
Создание профиля биллинга (тарифного плана) (рис.7-2).
«Цена», можно 0 выставить;
«Период времени» устанавливается в минутах, часах и днях (это сутки);
«Тип квоты», «Всего» или «Загрузить/скачать» устанавливается в МБайтах и ГБайтах;
«Ограничить полосу пропускания», устанавливается в кбит/с.
Рис.7-2. Профили (тарифы) биллинга.
Если перед конференцией много посетителей набралось, за один этап можно сгенерировать до 50 учёток по выбранному тарифу (кнопка A, B или C), распечатать на обычном А4 принтере прям из браузера и выдать. При бОльшем количестве посетителей, процедуру генерирования учёток повторить (рис.7-3).
Рис.7-3. Генератор учётных записей для ваучеров. 
Wi-Fi гости, когда интернет-каналом является 3G USB-модем.
если интернет медленный (USB-модем и т.д.) и не хватает гостям, их можно ограничить скоростями, квотами или временем в тарифах «А». Быстрые тарифы «B» сделать платными. Тарифы «С» безлимитными;
при отсутствии или недоступности внешнего сервиса авторизации или сотовой связи всегда можно перестраховаться включением встроенного сервиса авторизации по ваучерам;
любой гость с ваучером может зайти на http://6.6.6.6 (настраивается в п.6, рис.6) и узнать оставшееся время, квоты.
Один из нескольких случаев, как функционал биллинга выручил.
Перед началом крупной конференции «Безопасность в ИТ» внешний сервис авторизации упал и никто не мог авторизоваться, а гости съехались чуть ли не со всей России и всем нужен был бесплатный Wi-Fi. Экстренно переключили шлюз на встроенную авторизацию по ваучерам (п.6, рис.6), распечатали 500 ваучеров и спокойно раздали всем желающим по записи. Недовольных и позора не было. Поэтому наличие встроенного сервиса авторизации с термопринтером очень критично.
Ненадёжный внешний сервис авторизации поменяли на надёжного, пока ни разу не подводил, но всё равно в запасе всегда должен быть встроенный сервис авторизации, мало ли что.
8) Менеджер принтеров – управление принтерами для распечатки ваучеров (рис.8).
Активируется платной лицензией «Управление хот-спотами (биллинг)» на шлюзах Zyxel линейки VPN (все); USG Flex (200/500/700). Функционал отсутствует у USG Flex 100/100W и всей линейки ATP.
Поддерживает принтеры только Zyxel SP350E. Для распечатки ваучеров не требуется доступ к веб-управлению шлюза, достаточно нажать на термопринтере на нужную кнопку с тарифом (создаются в п.7) и распечатается ваучер с реквизитами. Русские символы не поддерживает. Кодировка текста у ваучера UTF-8. Обходились транслитом.
Рис.8. Менеджер принтеров.
всего одна кнопка нажимается для распечатки ваучера, не требует наличие ПК и обучение персонала.
9) Ресурсы без аутентификации – разрешение посетить сайты без авторизации (рис.9).
Рис.9. Ресурсы без аутентификации.
Итог: разрешаем гостям заходить на собственные сайты заведения (навигация, расписание, реклама, прейскурант цен), не требуя авторизацию. Они будут отображаться на выскакивающей странице авторизации. При попытке гостя зайти на сторонние сайты, ему снова выскочит страница авторизации.
10) Расписание – установка времени включения/отключения какого-нибудь профиля (рис.10). Например: радиопрофили точек доступа, SSID, маршрутизации, направления интернет-трафика к другому провайдеру, патруля приложений (отсутствует у моделей VPN), правила файрволла, BWM и т.д.
Рис.10. Добавление расписания.
Итог: в ночное время можно отключить радиопрофили и интернет от «нехороших» гостей, кулхацеров, если это не гостиница. Или перенаправить трафик к другому провайдеру, у которого ночной тариф безлимитный и скорости больше. Или выключать ограничение скоростей в BWM.
11) WWW – доступ к шлюзу (рис.11).
Рис.11. Ограничение доступа к шлюзу.
В «Контроль доступа админов» добавляем правило, выбираем зону с Wi-Fi гостями и выставляем deny для гостевых подсетей.
Итог: перестрахуемся, запретив авторизацию админам на шлюз из гостевой Wi-Fi подсети. Андроиды последних версий автоматически предлагают зайти на роутер и гости подбирают пароль к шлюзу.
12) Ежедневный отчёт по E-Mail – отправка графического отчёта по E-Mail за прошедшие сутки (рис.12-1).
Рис.12-1. Выбор данных для отправки отчёта
Отчёт читабельный и информативный, 15 шт графиков и почти 80 таблиц со статистикой внешних и внутренних интерфейсов, включая список стран, по которым было скачивание/отправка трафика. Чтобы не утруждать скроллингом отчёта, прикреплю пару скриншотов из отчётов (рис.12-2):
Рис.12-2.Слева отчёт ТОП-4 кол-ва клиентов и трафика. Справа отчёт монитора сессий и график нагрузки всех WAN портов.
Итог: ежесуточно на электронную почту приходит отчёт, по ней понимаем, что гостевая сеть работает, не зависла, гости сидят в интернете. Значительно упрощает мониторинг и экономит время. Пока едешь на работу, знакомишься с отчётом в почтовом клиенте телефона и делаешь вывод, что всё нормально работает, нет острой необходимости по прибытии на рабочее место делать обход (проверку) гостевой Wi-Fi сети, если очень занят.
Отчёт о проведении обхода.
13) Настройка лога с оповещением – отправка событий на сислог сервер, флешку и двум E-Mail (рис.13-1).
Рис.13-1. Выбор категорий лога.
Выручает отправка логов (alert) сразу на E-Mail, настроенного на телефоне, на нём входящие письма сигнализируются. Чаще всего приходят такие категории:
Аутентификация – неудачные авторизации, блокировка Wi-Fi гостевого устройства после нескольких неудачных попыток авторизоваться. Сразу узнаем, что с такого-то IP пытаются подобрать пароль к логину admin или к другим.
Security Policy Control – в файрволле при установке в правиле параметра “log alert”, на почту придут оповещения о появлении трафика, по которому правило начинает работать. К примеру, сразу узнаем, что «нехорошие» гости прощупывают шлюз на наличие открытых портов и других, даже если закрыты.
CAPWAP – состояние ТД (дисконнект, перезагрузка и т.д.). Сразу узнаем, что такая-то ТД нештатно отключилась и принимаем меры.
На рис.13-2 отображены оповещения о дисконнекте ТД (слева), неправильном вводе пароля (в центре) и запросе на подключение на 22 порт шлюза (справа).
Рис.13-2. Письма-оповещения о критических событиях.
после оповещения о дисконнекте точки доступа действуем на опережение, не тратим время на анализ заявок, как «почему телефоны у гостей не находят SSID». Очевидно, что 99% причин – это аварийное отключение подачи электричества PoE коммутатору;
благодаря мгновенному оповещению, всегда в курсе что происходит с гостевой сетью и понимаем, что за проблемы у гостей. Реально помогает работе с комплексом.
Доложение обстановки.
Примечание: почему на обоих скриншотах (рис.12-2 и рис.13-2) фигурирует Zyxel UAG5100? В дни написания статьи параллельно проводился эксперимент с Zyxel VPN300 для нового проекта. Для чистоты эксперимента и чтобы не мешать Wi-Fi гостям, временно перекинул точки доступа с VPN300 на резервный UAG5100, но функции роутера и авторизации гостей оставил у VPN300. По окончании экспериментов все ТД верну на VPN300. В принципе, в показанных скриншотах нет разницы между UAG5100 и VPN300.
Функции на коммутаторах Zyxel
Нажимаем на Status, затем Neighbor:
Рис.14-1. Запускаем Neighbor.
Получаем список подключённых (Remote) PoE устройств, которые можем перезагрузить (кнопка Cycle) или сбросить (кнопка Reset) до дефолтного состояния или зайти по забытому IP на него (рис.14-2).
Рис.14-2. Neighbor, найденные соседи.
Итог: актуально, если применил конфиг с ошибкой (к примеру, перепутал VLAN ID) и ТД перестала отвечать или зависла. Как теперь её сбросить или перезагрузить, если она на высоком потолке или нет времени выехать на объект? Поэтому Neighbor выручал сбросом или перезагрузкой.
Рис.15. Запуск Locator (светодиодной сигнализации).
Текст уже большой стал. Закругляюсь. Для учебных заведений очень полезны функции шлюза как контентная фильтрация; патруль приложений; Гео-IP.
Финальный итог и почему выбрал Zyxel?
Часть функций относится к работе с трафиком — это работа шлюза и такое отсутствует в программных контроллерах Wi-Fi. Вот почему так нужен встроенный Wi-Fi контроллер в железке-шлюзе. Городить комплекс из железок (шлюз, МСЭ, контроллер) дороже, хлопотно и каждый узел настраивать, это требует время, покупку стойки с ИБП, сплит-систему.
Вы скажете, так надёжнее! Но у шлюзов Zyxel есть функция резервирования шлюза «Device HA Pro». Проще два одинаковых шлюза купить и поднять резервирование между ними, всё равно они негабаритные.
Вы заметили, что ни разу не обращался к CLI (ввод текстовых команд). Всё настраивается на веб-странице, упрощается настройка/мониторинг шлюза для опытных пользователей или молодых ИТ-специалистов. Провайдерские знания не потребуются. Многое можно сделать на планшете, не заморачиваясь вводом длинных команд.
Для гостевой Wi-Fi сети с роумингом и авторизацией очень сложно найти с вышеперечисленными функциями универсальный шлюз у других вендоров в силу отсутствия подробных характеристик и гидов и по разумной цене. Найти у них совместимые ТД оказалось большой проблемой, как искал их, читайте тут. Поэтому рекомендую любые управляемые ТД Zyxel со шлюзами USG Flex / VPN / частично ATP (ATP не поддерживает биллинг и термопринтеры). Список управляемых ТД, поддерживаемые шлюзом, указывается в конце документа характеристик шлюза. Например, тут. Ещё прошу обратить внимание, как понятно и чётко перечислены функции шлюза, что внушает доверие перед покупкой.
Сохраняйте экосистему Zyxel. Бесплатная утилита ZON найдёт Zyxel в своей подсети, списком отобразит и оттуда сигнализацию (Locator) запустит, сбросит или прошивку обновит. С ней значительно проще, легче и комфортнее работается. Теперь вполне справляюсь в одиночку.
Не игнорируйте коммутаторы Zyxel с PoE, есть с индикацией нагрузки PoE на лицевой панели, упрощают работу с инфраструктурой.
Рис.17. Индикация нагрузки PoE на лицевой панели.
Хотите это обсудить? Поспорить? Пишите в комментариях, а также общайтесь со мной и другими практикующими специалистами Zyxel в телеграм-канале https://t.me/zyxelru.
Об авторе:
DHCP сервер на нескольких VLAN
Под термином “клиент” будем понимать зону ответственности за совокупность сетевых устройств.
Требуется обеспечить доступ для нескольких сотен клиентов к неким общим ресурсам в таком режиме, чтобы:
Таким образом, при появлении у клиента нового устройства адрес для него будет выдан автоматически (и у нас не будет проблем из-за того, что один клиент может использовать для своих нужд единицы IP-адресов, а другому потребуются их десятки или сотни), а при добавлении нового клиента мы просто создадим еще один VLAN и добавим его в нашу общую группу. Даже если из-за большого количества клиентских устройств первоначально выделенное нами адресное пространство будет исчерпано, то мы всегда сможем его расширить, изменив настройки всего в двух местах (на DHCP-сервере и на интерфейсе, который объединяет все клиентские VLAN).
Технически описанное выше решение можно реализовать только аппаратными средствами на коммутаторах уровня L3 или программно-аппаратными средствами на коммутаторах уровня L2 (лишь бы они понимали 802.1q) и каком-либо компьютере с linux-подобной операционной системой. Так как у меня уже был сервер (являющийся, к тому же, целевым для клиентов), то логично было бы остановиться на аппаратно-программном варианте.
Итак, программируем коммутатор таким образом, чтобы на каждом клиентском VLAN был один физический порт коммутатора в “access mode”, и один общий порт в режиме 802.1q (к этому порту будет подключаться наш сервер). Подробно технология настройки не расписывается, т.к. она достаточно тривиальна и зависит от конкретной модели используемого коммутатора.
Далее приступаем к созданию конфигурации для сервера. Пусть физический интерфейс, который подключается к порту 802.1q коммутатора, имеет имя eth0. Для моей конкретной задачи понадобилось 200 клиентских VLAN с VLAN ID от 600 до 799 включительно, так что будем их создавать:
Общая настройка видов имен VLAN-интерфейсов. Я хочу, чтобы имена VLAN-интерфейсов имели вид “vlanXXX”, где XXX — VLAN ID:
Непосредственно создаем VLAN на базе интерфейса eth0:
Создаем бридж, в который будем объединять созданные vlan:
Объединяем созданные интерфейсы в бридж:
Теперь прописываем на интерфейс br1 адрес, который будет выступать для всех наших клиентов в качестве шлюза по умолчанию:
И запрещаем трафик между клиентскими VLAN средствами ebtables:
(в данном случае используется таблица ebtables ‘filter’, запрещающая передачу трафика между интерфейсами, входящими в бридж в виде логических портов). Если все-таки необходимо разрешить возможность передачи трафика между клиентами под нашим контролем (см. п. 3 техзадания), то вместо вышеприведенного правила устанавливаем следующие:
Здесь мы работаем с таблицей ‘broute’. В ней не стандартные действия для целей ACCEPT и DROP. Цель ACCEPT разрешает форвардинг трафика с заданными условиями (т.е. трафик передается на уровне L2), а цель DROP запрещает форвардинг трафика и обеспечивает его передачу на роутинг (и, соответственно, мы сможем им управлять посредством iptables). Однако т.к. все адреса принадлежат одной IP-подсети но могут находиться в разных клиентских VLAN, на интерфейсе br1 необходимо будет разрешить arp proxy:
Замечу, что у меня не не стояло задачи пропуска трафика между клиентами, поэтому описанное выше расширение чисто умозрительное и на практике не проверялось!
Осталось только настроить сервер DHCP и поселить его на интерфейс br1. Эта операция также тривиальна, поэтому в рамках данной статьи не описывается.
Ну что, все работает? А вот как бы не так:
Здесь все нормально: получили один broadcast запрос DHCPDISCOVER, ответили одним broadcast-ответом DHCPOFFER.
А теперь давайте посмотрим, что происходит на физическом интерфейсе:
Мало того, что мы засветили всем клиентам MAC/IP адреса одного из них, так еще и вдобавок получили не хилый broadcast storm на физический коммутатор. Кстати, от такого шторма у некоторых коммутаторов просто едет крыша: работающий у нас QTECH не только не смог пропустить broadcast на все заявленные 200 клиентских VLAN (т.е. конечный клиент с произвольной вероятностью либо получал свой адрес от DHCP сервера, либо не дожидался от него вообще никакого ответа), но и даже забыл таблицу известных ему MAC-адресов (во всяком случае в консоли он показывал только один MAC-адрес для всех портов). А вот коммутатор ASOTEL справлялся с такой нагрузкой и клиенты могли получить адреса от нашего DHCP-сервера.
Ну ладно, будем исправлять ситуацию. Надо заставить сервер посылать broadcast только в тот VLAN, от которого пришел первоначальный запрос, а не размножать его по всем доступным местам.
Модуля трекинга DHCP broadcast-ов я не нашел. Как выяснилось позднее, он бы в данном случае все равно не помог, т.к. broadcast-ответ DHCP-сервером формируется при помощи системного вызова
socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_IP))
который не проходит ни через одну из таблиц ebtables или iptables. Т.е. если входящие broadcast отловить еще можно, то вот ответы передаются драйверу минуя стек протоколов. И это логично: если уж мы сами формируем ethernet-заголовок, то какой смысл дополнительно обрабатывать его средствами ядра?
Для начала вспомним, что в современных linux-ядрах есть такие вкусности, как Virtual Ethernet Device (из них можно делать хорошие pipes для перегонки ethernet-трафика внутри нашего компьютера) и Network Namespace (средство для изоляции сетевого стека. В аппаратных маршрутизаторах это, обычно, называется VRF). В принципе для данной задачи можно обойтись исключительно Virtual Ethernet (veth), но для красоты решения (и упрощения связки DHCP Server — DHCP Relay Agent) будем использовать также и Network Namespace (netns).
После инициализации сети в linux по умолчанию имеется только один root netns, в котором находится единственная копия сетевого стека, таблицы маршрутизации, интерфейсы и т.п. В дальнейшем описании для определенности будем использовать следующую терминологию:
Network Namespace назовем “слоем” (layer);
root netns назовем слоем “backplate” (хотя в реальности этот netns имеет имя в виде пустой строки);
каждый клиентский VLAN добавляем в отдельный bridge, на интерфейс которого будем вешать DHCP Relay Agent. Через этот интерфейс клиенты смогут посылать broadcast-запросы агенту и принимать от него broadcast-ответы.
из каждого клиентского bridge сделаем ethernet pipe до нашего основного br1. Через связку “customer vlan”-”customer vlan bridge”-”virtual ethernet”-”br1” будет проходить полезный трафик между клиентским сервисом и общими внешними ресурсами.
Сам DHCP Relay Agent живет в одном экземпляре (он может слушать несколько клиентских интерфейсов) на специальном ethernet pipe, на другой стороне которого находится наш DHCP Server.
весь прикладной уровень (т.е. все, что не касается DHCP), расположим на уровне backplate;
все, что связано с DHCP Relay Agent, расположим на уровне с именем “relay”;
собственно сервер DHCP должен быть доступен как для DHCP Relay Agent (для обработки сообщений, распространяемых в виде broadcast и преобразуемых агентом в unicast и обратно), а также непосредственно для клиентов DHCP (для обработки специального случая: сообщения DHCPRELEASE, отправляемого unicast клиентом напрямую тому DHCP-серверу, который выдавал этот адрес).
С учетом данных требований сам DHCP-сервер расположим на уровне backplate на интерфейсе br1, но для предотвращения приема им broadcast-запросов от конечных клиентом на интерфейс будут наложены специальные фильтры.
Ну, поехали… Создаем слой “relay”
Создаем на слое backplate виртуальный pipe, предназначенный для общения DHCP Relay Agent и DHCP Server:
Переносим хвост dhcpd (интерфейс, на котором будет работать Relay Agent) в слой relay:
Настраиваем в слое relay интерфейс dhcpd:
Создаем наш основной бридж br1:
Пусть этот бридж работает как умный коммутатор (т.е. хранит у себя таблицу MAC-адресов и выполняет форвардинг на конкретный порт в зависимости от наличия на нем целевого адреса). Для этого устанавливаем время обучения равным 30 секундам:
Ну и клиенты — личности своеобразные, вполне могут и кольца сотворить. Ежели кто этим и займется, то пусть страдает сам, не затрагивая при этом других. Т.е. запустим на нашем виртуальном коммутаторе STP:
Т.к. этот бридж является также шлюзом по умолчанию для клиентов, то повесим на него IP-адрес (вместе с сеткой) и поднимем непосредственно сам интерфейс:
Добавляем в бридж интерфейс, по которому DHCP сервер будет общаться с агентом:
Запрещаем трафик между клиентскими VLAN средствами ebtables:
Запрещаем обработку DHCP-сервером broadcast-запросов (они должны вылавливаться агентом и отсылаться серверу в виде unicast):
Для подстраховки разрешаем использование адреса, выделенного для DHCP Relay Agent только на интерфейсе с именем relay:
Ладно, последний мазок. Так как я категорически не доверяю клиентам, заставим ядро убеждаться в том, что приходящие от них IP-пакеты имеют source address вида 10.12.8.0/23 (а не, к примеру, 192.168.1.1). Для этого включаем на интерфейсе rp filter:
Общая настройка видов имен VLAN-интерфейсов. Я хочу, чтобы имена VLAN-интерфейсов имели вид “vlanXXX”, где XXX — VLAN ID:
Непосредственно создаем VLAN на базе интерфейса eth0:
Переносим созданный интерфейс vlan600 из слоя backplate в слой relay:
Поднимаем интерфейс vlan600, но уже в слое relay:
Создаем в слое relay бридж для данного клиентского VLAN (на который будем вешать DHCP Relay Agent).
Мы хотим, чтобы этот бридж работал в качестве хаба (т.е. выполнял бы трансляцию пакета сразу же после его получения, не используя период сбора информации о MAC-адресах). Для этого до момента добавления первого интерфейса в бридж устанавливаем его параметры:
Кроме того, STP на данном бридже нам явно не нужен:
Поднимаем интерфейс бриджа:
И добавляем в него клиентский VLAN:
Создаем на слое backplate (ну все равно он туда придет) ethernet pipe для связки клиентского бриджа br600 и нашего основного бриджа br1:
Переносим второй конец pipe в слой relay:
И добавляем этот конец трубы в бридж:
Ну и добавляем конец pipe, оставшийся в слое backplate, в бридж br1:
Повторяем в цикле операции создания клиентских VLAN в нужном количестве.
Теперь достаточно запустить сам DHCP сервер в слое backplate и DHCP Relay Agent в слое relay. В моем случае используется сборка из BusyBox, что в данном случае не критично. Использование ISC агента и сервера не должно вызвать больших затруднений.
Итак, запускаем агента. В качестве клиентских интерфейсов используются br600-br799, в качестве интерфейса для связи с DHCP-сервером используется интерфейс dhcpd, а сам DHCP сервер имеет адрес 10.12.8.1:
Ну и, наконец, запускаем DHCP сервер:
В файле /etc/udhcpd.conf единственная строчка, которая относится к данной схеме:
Все, теперь broadcast-запросы в пользовательском VLAN отлавливаются DHCP Relay Agent через соответствующий br-интерфейс, после чего запрос unicast-ом передается на серверу через интерфейс dhcpd. Сервер отсылает unicast-ответ через интерфейс relay, который агент получает из интерфейса dhcpd и транслирует broadcast-ом в исходный VLAN.
Клиенты стали получать адреса через DHCP, broadcast-storm исчез. И клиент может послать DHCPRELEASE непосредственно серверу на адрес 10.12.8.1
© Copiright 2015 by Vedga. Копирование текста на другие ресурсы без согласия автора запрещено.
Что посмотреть к этой статье: