Я изначально спросилэтотвопрос о переполнении стека и был перенаправлен сюда.
Используя Hyper-V, я создал частный домен Windows, который отгорожен от нашей основной сети. В конечном итоге я хочу предоставить этот домен другим для использования в целях разработки и тестирования, чтобы они могли быть администраторами домена.
Моя проблема заключается в следующем: на контроллере домена запущена служба DHCP. Если кто-то развернет домен на своем хосте Hyper-V и по ошибке подключит его к основной сети, служба DHCP начнет назначать неправильные конфигурации IP.
Я хотел бы предотвратить эту ситуацию. Я думал написать услугу, чтобы обернутьdhcploc, эта служба затем остановит локальную службу DHCP, если будет найден удаленный сервер DHCP. Это действительно ограничение ущерба, поскольку у мошеннического сервера DHCP все еще будет небольшое окно возможностей.
Есть ли лучшая/более простая альтернатива, которая позволит достичь цели? Есть ли какие-то оговорки, о которых мне следует знать?
Спасибо
решение1
Учитывая, что ваша тестовая конфигурация DHCP использует MAC-адреса для назначения обычных IP-адресов, вы можете ограничить область действия, включив в нее только известные MAC-адреса. Таким образом, даже если кто-то случайно поместит его в основную сеть, он не будет выдавать никаких IP-адресов, поскольку ни один из запросов не соответствует ни одному из MAC-адресов в его области действия. Что касается потенциальных проблем с размещением тестового DC в вашей основной сети, это зависит от нескольких вещей:
1) Надеюсь, вы используете отдельную подсеть для тестовой сети, нежели для основной сети. Например, тестовая сеть = 172.16.0.0 и основная сеть = 10.0.0.0. Это ограничит доступ тестовых DC к материалам в основной сети, пока они не смогут добраться до маршрутизатора, который знает об обеих подсетях и настроен на маршрутизацию между ними. 2) Как был создан тестовый DC? Если он был сначала подключен к основной сети, чтобы получить данные AD через репликацию, а затем удален и помещен в тестовую среду, он все равно будет знать о других DC в основной сети и попытается реплицировать их на/с них, как только появится. Это очень плохо по очевидным причинам... Если он был создан в тестовой среде и имеет уникальное доменное имя, отдельное от основного доменного имени, то все в порядке.
Под «большими проблемами» я подразумевал, что если люди случайно подключают контроллеры домена к основной сети, то кто-то должен был бы провести для них обучение по использованию Hyper-V, а не пытаться ограничить ущерб в случае, если они это сделают! Я бы очень нервничал, если бы у меня были люди из DEV, играющиеся с контроллерами домена (тестовыми или нет) в моей производственной сети... Можно ли еще больше отделить их рабочие станции Hyper-V от основной сети в другую подсеть?
решение2
Когда вы говорите «огорожено», что именно вы имеете в виду?
Если у вас два DHCP-сервера в одной подсети, то некоторые запросы будут поступать на один DHCP-сервер, а некоторые — на другой, и, конечно же, возникнут конфликты, если оба сервера будут выдавать IP-адреса из одного и того же пула.
В описанной вами ситуации я бы создал маршрутизируемую подсеть для вашего «отгороженного» сервера и использовал бы VLAN для изоляции подсети, или вы могли бы использовать другой дешевый коммутатор для более физического разделения.
Ваш сервер Windows DHCP может быть многосетевым (подключенным к двум или более сетям). При наличии двух сетевых карт вы подключаете одну карту к своей производственной сети, а другую карту — к отдельному сетевому коммутатору или отдельной 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 Production вы можете назначить статический маршрут в область разработки, а в области DHCP Development вы можете назначить статический маршрут в область производства...
Вам может потребоваться маршрутизация между ними, если, например, вашей зоне разработки необходим доступ в Интернет, а Интернет доступен только через производственную сеть.
решение3
Проще всего вообще не использовать DHCP. Частный виртуальный домен настолько большой, что вы не можете управлять IP-адресами с помощью статических IP-адресов? Во-вторых, у вас будут большие проблемы, если люди подключают к вашей основной сети контроллеры домена, которые должны использоваться только для тестирования. Я пока не использовал Hyper-V, но в VMWare вы, по крайней мере, можете назначать довольно детальные разрешения, которые не позволят пользователю подключать виртуальную машину к другой сети или изменять ее сетевую конфигурацию.