Может ли DHCP-сервер Windows обслуживать область, в которую он не входит?

Ситуация

У меня есть коробка Windows SBS 2008, работающая как DC / DNS / DHCP / Exchange / File Server в сети на 192.168.1.0/24. Достаточно сказать, что IP-адрес SBS-бокса неизменен. В какой-то момент в прошлом мой предшественник здесь пытался запустить 2 сетевых адаптера с 2 IP-адресами на нем (что очень не поддерживается), и с тех пор попытка изменить любое из свойств сети приводит к синему экрану при запросе перезапуска - нам приходилось восстанавливать из снимков, когда это происходит, похоже, нет никакого способа обойти это.

Недавно мы начали проект по избавлению от SBS и построению настоящего домена 2008/2012 (tbd) с 2 контроллерами домена, отдельной виртуальной машиной для Exchange, одной для общих файловых ресурсов и т.д. и т.д. (ура!), Но предварительным условием является переход на новый IP Scope (мы будем использовать VPN с головным офисом, что позволит нам перенести многие из этих сервисов в их сеть).

Это оставляет меня в некотором роде липкой ситуации - мне нужно получить маршрутизаторы, рабочие станции, терминалы ... почти все в сети, ЗА ИСКЛЮЧЕНИЕМ DC / DNS / DHCP / Exchange / файлового сервера, в другую область, сохраняя при этом соединение с ними. службы, работающие на SBS, который должен оставаться на 192.168.1.0/24.

Еще одна сложность в этом вопросе - у нас здесь 2 шлюза. Один используется SBS, другой ... почти все остальное - это позволяет трафику SMTP и HTTPS извне попадать в него.

План

Хорошо, вот что я планирую сделать - я установил виртуальную машину с минимальной установкой Ubuntu 12.04 и сетевой картой в каждой области сети. У него есть статические маршруты, настроенные для доступа к каждой сети на соответствующем интерфейсе, и я планирую протолкнуть другой маршрут через DHCP, позволяя клиентам в разных областях связываться друг с другом путем маршрутизации через окно Linux.

Так, например, у меня есть маршруты:

Клиент на 10.0.0.20

destination 192.168.1.0 mask 255.255.255.0 gateway 10.0.0.10 interface 10.0.0.20

Маршрутизатор Linux с версиями 10.0.0.10 и 192.168.1.10

destination 192.168.1.0 mask 255.255.255.0 gateway 0.0.0.0 interface 192.168.1.10

destination 10.0.0.0 mask 255.255.255.0 gateway 0.0.0.0 interface 10.0.0.10

DC в 192.168.1.200

destination 10.0.0.0 mask 255.255.255.0 gateway 192.168.1.10 interface 192.168.1.200

В то же время я перенесу интернет-шлюз, который в настоящее время используется всеми (а не тот, который настроен для DC), в сеть 10.0.0.0/24, поэтому клиенты 10.0.0.0/24 имеют шлюз по умолчанию в своей области, а Клиенты 192.168.1.0/24 (на самом деле только DC) имеют в своей области шлюз по умолчанию (на данный момент единственные оставшиеся вещи в сети 192.168.1.0/24 - это DC и его шлюз).

Вопрос

Да, я собираюсь кое-что спросить! Я хочу подтвердить, может ли DC обслуживать этих клиентов DHCP, находясь в другой области. Исследования привели меня Вот, который, кажется, предполагает, что в одном случае это невозможно без DHCP-сервера ретрансляции (при условии, что я правильно анализирую «сетевой сегмент» как достаточно аналогичный подсети), но также упоминает Super Scope, что звучит так, как будто это МОЖЕТ решить проблему (поскольку он назначает адрес любым устройствам за пределами других областей ... я думаю).

Мне кажется, что когда клиент запрашивает адрес, у него все равно нет адреса, так как же он может определить, находится ли он в том же «сегменте сети», что и DC?

Чтобы уточнить в формате TL; DR - могу ли я обслуживать адреса 10.0.0.0/24, а также другие сетевые свойства, такие как статические маршруты, DNS и шлюзы по умолчанию, клиентам с DHCP-сервера, расположенного по адресу 192.168.1.200/24? Нужно ли мне для этого использовать Superscope?

Также, если вы видите другие проблемы с моим планом, пожалуйста, не молчите!

Дополнение

Используя инструмент DHCP-helper, предложенный @ HopelessN00b, я смог добиться этого довольно гладко! Несколько вещей были проблемными -

• Все клиенты находятся в одном сегменте сети, нет необходимости проходить через коммутатор уровня 3 для доступа к DHCP-серверу. В результате все мои клиенты захватили 192 адреса, потому что они общались напрямую с сервером. Я хотел оставить в списке прицел 192, потому что а) если бы я пришел сегодня утром и обнаружил, что облажался, было бы легко откатиться; и б) В качестве удобного списка тех служб, которые все еще находятся в подсети 192; но я смог обойти эту хитрость, создав диапазон исключения для области, которая соответствовала полному диапазону адресов в области видимости (т. е. область изменилась с 192.168.1.20 до 192.168.1.200, я создал диапазон исключения от 192.168.1.20 - 192.168.1.200). Это заставляет меня чувствовать себя немного грязным, но это работает, и подсети 192 нужно прожить всего несколько недель, чтобы мы могли перенести службы.
• Сегодня утром я обнаружил несколько устройств, которые не поддерживают получение статического маршрута через параметр 121 DHCP (а именно: терминалы WYSE). Они с радостью брали адреса 10.61.73.x, но не могли перенаправить на сервер терминалов 192.168.1.x. Поскольку сам терминальный сервер успешно выбрал маршруты, я установил их статически в подсети 192 на данный момент, что решило их проблемы.

@ us10610 хотел узнать конфигурацию, которую я использовал в Linux для DHCP-Helper - это было ужасно просто - /etc/default/dhcp-helper содержит одну строку, которую я изменил по умолчанию: DHCPHELPER_OPTS="-b eth1"

eth1 сетевой адаптер, который разделяет подсеть с DHCP-сервером. Затем он с радостью принял DHCP UDP от другого сетевого адаптера и транслировал их на eth1