Jump to content

Recommended Posts

Posted

Исходные данные.

Есть локальная сеть предприятия с адресацией 192.168.0.0/24

Доступ в инет - через шлюзовой сервер (Gate).

Сеть под Windows, два контроллера домена (DC), на обоих развернуты DNS (форвардинг наружу на DNS ISP).

На одном из них также развернут DHCP сервер, раздает адреса в диапазоне (192.168.0.100 - 192.168.0.254) для рабочих станций.

Адреса (192.168.0.4 - 192.168.0.50) имеют многочисленные внутренние сервисы и сетевые устройства.

Физически сеть состоит из центрального коммутатора - агрегатора серверов (Switch-1) и основных сетевых устройств и "вертикально" подключенных коммутаторов (Switch-x) на этажах.

К коммутаторам на этажах подключены беспроводные точки доступа AP-x.

Все оборудование на D-Link: DGS-3100 и DES-3200, точки доступа WiFi - DAP-2360.

WiFi обеспечивает прямой доступ к внутренней локальной сети, до недавнего привилегией его использования обладали лишь немногие пользователи, имеющие ноутбуки от компании, да само руководство.

 

Задача

Руководство приняло решение внять настойчивым просьбам пользователей насчет "шарового WiFi", а также дать гостевой доступ партнерам, приезжающим в офис.

Из-за массового засилья мобильных устройств (смартфоны, планшеты и т.п.) существующий диапазон DHCP будет быстро исчерпан, потому требуется перевести всех мобильных пользователей в новый отдельный диапазон 192.168.1.0/24.

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

В то же время нужно сохранить для ряда пользователей доступ к внутренним сервисам сети, т.е. их адресация должна остаться прежней (192.168.0.0/24).

 

Карта сети в сильно упрощенном виде показана на рисунке.

post-51369-051093300 1381752138_thumb.png

 

Как думали бороть.

Все беспроводные точки доступа загнать в отдельный вилан на базе меток, на порту, в который воткнут на Switch-1 гейт - также навесить этот же вилан, аналогично - с портом КД, на котором размещен DHCP сервер.

На гейте и DC прописать вторым адресом адреса из подсети WiFi, т.е. 192.168.1.1 и 192.168.1.2 соответственно.

Адреса беспроводным клиентам выдавать на базе резервирования по MAC для тех из них, кому требуется остаться на старой адресации. Для остальных (для личных устройств и гостей) - выдавать из отдельной новой зоны (Scope) с новой адресацией.

 

Как получается по факту.

Все тестили на виртуалках.

Основной затык пока с DHCP сервером. Реализация от MS (2003R2) не хочет отдавать IP ардес из новой зоны, даже если там внести принудительное резервирование. Снифер видит получение сервером запроса от клиента на 255.255.255.255 67 UDP и его ответ с IP адресом из диапазона 192.168.0.0/24, а не из 192.168.0.1/24

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

Во время теста старый выданный адрес вытирался из выданных, чистились кеши, менялись клиентские виртуалки (тестилось на ХР и на убунте), все перезагружалось и т.п. Анализ DHCP пакетов подтверждает что клиент в запросе не упоминает старый выданный адрес, предлагая получить его, а просто запрашивает новый, на что сервер, упорно не желая видеть резервирование в новой зоне, выдает первый попавшийся адрес из старой.

Т.е. это просто особенность поведения сервера MS DHCP. Кстати пробовали на виртуалке его реализацию в 2012-м сервере (там даже появилась отказоустойчивость и DHCP сервера теперь реплицируют свои базы) - его поведение аналогично.

В принципе, если задействовать виланы, то можно будет поднять DHCP сервер на одной из точек доступа. Правда тогда неудобно будет прописывать на нем же резервирование для старых клиентов с ноутбуками, да и к сожалению имеющиеся в наличии точки доступа достаточно глупые, без контроллера и на них нельзя сделать два разных диапазона DHCP, придется ставить отдельный DHCP сервер в их сегменте сети. Ну и на гейте придется маршрутизировать трафик от беспроводных клиентов со старой адресацией, чтобы они через гейт могли попадать во внутреннюю сеть к ее сервисам.

 

Просьба.

То, как думали бороть проблему - представляется корявым решением. Пожалуйста, наставьте на путь истинный и просветите, как все это надо делать ПРАВИЛЬНО.

Только пожалуйста, не предлагайте коренным образом перестраивать топологию сети или менять все оборудование на циски или даже микротики - по бюджету мы на эти железки претендовать не можем, да и никто не даст менять полностью все оборудование, что есть по факту.

Posted

На точках доступа поднять доп SSID чтобы он вещал в отдельный влан, на коммутаторах прописать соответствующий влан.

На венде поднять гиперви, там засетапить фрю/линупс, туда же прокинуть вланы в виде отдельных интерфейсов (гиперви только так и умеет с вланами работать), и дальше разроутить там всё.

Лично я бы виртуальный роутер заюзал для всех, ибо фря/линупс даже в виртуалке сильно лучше венды.

Там же поднял бы дхцп для гостей и unbound для того чтобы днс кешировал как для своих так и для гостей.

Дхцп для своих наверное лучше под вендой оставить, оно там типа интегрировано в домен и умеет обновлять записи в днс.

 

Собственно такая схема у меня и работает в одном месте.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...