Я изначально спросил этот вопрос о переполнении стека и был упомянут здесь.
Используя Hyper-V, я создал частный домен Windows, который изолирован от нашей основной сети. В конечном итоге я хочу предоставить этот домен другим пользователям для разработки и тестирования, чтобы они могли быть администраторами домена.
Моя проблема в следующем: на контроллере домена запущена служба DHCP. Если кто-то развернет домен на своем хосте Hyper-V и по ошибке подключит его к основной сети, служба DHCP начнет назначать неверные IP-конфигурации.
Я бы хотел предотвратить такую ситуацию. Я подумывал написать услугу для упаковки dhcploc, эта служба затем остановит локальную службу DHCP, если будет найден удаленный сервер DHCP. Это действительно ограничение ущерба, поскольку у мошеннического DHCP-сервера все еще будет небольшое окно возможностей.
Есть ли лучшая / более простая альтернатива, которая достигла бы цели? Есть ли какие-то предостережения, о которых мне следует знать?
Спасибо
Проще всего вообще не использовать DHCP. Неужели частный виртуальный домен настолько велик, что вы не можете управлять IP-адресами с помощью статических IP-адресов? Во-вторых, у вас будут большие проблемы, если к вашей основной сети подключают контроллеры домена, предназначенные только для тестирования. Я еще не использовал Hyper-V, но в VMWare, по крайней мере, вы можете назначить довольно подробные разрешения, которые не позволят пользователю подключить виртуальную машину к другой сети или изменить ее сетевую конфигурацию.
Когда вы говорите «отгорожен», что именно вы имеете в виду?
Если у вас есть два DHCP-сервера в одной подсети, тогда у вас будут некоторые запросы, идущие на один DHCP-сервер, а некоторые - на другой, и, конечно же, конфликты, если оба сервера предоставляют IP-адреса из одного пула.
Для описанной вами ситуации я бы создал маршрутизируемую подсеть для вашего «изолированного» сервера и использовал бы VLAN для изоляции подсети, или вы могли бы использовать другой дешевый коммутатор для большего физического разделения.
Ваш DHCP-сервер Windows может быть многосетевым (подключенным к двум или более сетям). С двумя сетевыми картами вы подключаете одну карту к своей производственной сети, а другую - к отдельному сетевому коммутатору или отдельной VLAN, позволяя одному серверу действовать как DHCP-сервер для обеих сетей. Или, согласно вашему исходному вопросу, вам не нужно будет этого делать, если вы хотите продолжить работу двух DHCP-серверов.
Затем на изолированном выключателе или VLAN вы создаете подсеть, отличную от вашей производственной сети. Например:
Промышленный коммутатор / VLAN: 172.16.0.0/16 Коммутатор для разработки / VLAN: 172.17.0.0/16
Производственный DHCP-сервер может использовать область 172.16.1.1 - 172.16.1.200 Разработка DHCP-сервер может использовать область 172.17.1.1 - 172.17.1.200
В области рабочего DHCP вы можете передать статический маршрут для разработки, а в области DHCP для разработки вы можете передать статический маршрут производственной среде ....
Вам может потребоваться некоторая маршрутизация между ними, если, например, вашей области разработки требуется доступ в Интернет, а Интернет доступен только через производственную сеть.
Учитывая, что ваша тестовая конфигурация DHCP использует MAC-адреса для назначения обычных IP-адресов, вы можете ограничить область действия, включив только известные MAC-адреса. Таким образом, даже если кто-то случайно поместит его в основную сеть, он не выдаст никаких IP-адресов, потому что ни один из запросов не соответствует ни одному из MAC-адресов в его области. Что касается потенциальных проблем с размещением тестового DC в вашей основной сети, это зависит от нескольких вещей:
1) Надеюсь, вы используете отдельную подсеть для тестовой сети, чем основная сеть. Ex. тестовая сеть = 172.16.0.0 и основная сеть = 10.0.0.0. Это ограничит доступ тестовых контроллеров домена к материалам в основной сети до тех пор, пока он не сможет получить доступ к маршрутизатору, который знает обе подсети и настроен на маршрутизацию между ними. 2) Как создавался тестовый ДЦ? Если он был сначала подключен к основной сети для получения данных AD посредством репликации, а затем удален и помещен в тестовую среду, он все равно узнает о других контроллерах домена в основной сети и попытается выполнить репликацию в / из них, как только он появится. Это очень плохо по очевидным причинам ... Если он был создан в тестовой среде и имеет уникальное доменное имя, отдельное от основного доменного имени, то все в порядке.
Под «более серьезными проблемами» я имел в виду то, что если люди случайно подключают контроллеры домена к основной сети, то кто-то должен обучить их использованию Hyper-V, а не пытаться ограничить ущерб, если они это сделают! Я бы очень нервничал, если бы у меня были разработчики, играющие с контроллерами домена (тестовыми или нет) в моей производственной сети ... Могли бы вы еще больше отделить их рабочие станции Hyper-V в другой подсети от основной сети?