originalmente preguntéestePregunta sobre el desbordamiento de la pila y fue remitida aquí.
Usando Hyper-V construí un dominio de Windows privado que está aislado de nuestra red principal. En última instancia, quiero proporcionar este dominio para que otros lo utilicen para desarrollo y pruebas, para que puedan ser administradores del dominio.
Mi problema es este: el controlador de dominio tiene el servicio DHCP ejecutándose. Si alguien implementa el dominio en su host Hyper-V y lo conecta por error a la red principal, el servicio DHCP comenzará a asignar configuraciones de IP incorrectas.
Me gustaría prevenir esta situación. Consideré escribir un servicio para terminardhcploc, este servicio detendrá el servicio DHCP local si se puede encontrar un servidor DHCP remoto. Esto es realmente una limitación de daños, ya que el servidor DHCP fraudulento aún tendría una pequeña ventana de oportunidad.
¿Existe una alternativa mejor/más simple que pueda lograr el objetivo? ¿Hay alguna advertencia que deba tener en cuenta?
Gracias
Respuesta1
Dado que su configuración DHCP de prueba utiliza direcciones MAC para asignar IP regulares, puede limitar el alcance para incluir solo las direcciones MAC conocidas. De esta manera, incluso si alguien lo coloca accidentalmente en la red principal, no entregará ninguna IP porque ninguna de las solicitudes coincide con ninguna de las MAC en su alcance. En cuanto a los posibles problemas de poner un DC de prueba en su red principal, depende de un par de cosas:
1) Es de esperar que esté utilizando una subred separada para la red de prueba que la red principal. Ex. red de prueba = 172.16.0.0 y red principal = 10.0.0.0. Esto limitará el acceso de los DC de prueba a elementos en la red principal siempre y cuando no pueda acceder a un enrutador que conozca ambas subredes y esté configurado para enrutar entre ellas. 2) ¿Cómo se creó el DC de prueba? Si primero se conectó a la red principal para capturar datos de AD mediante replicación y luego se eliminó y se colocó en el entorno de prueba, aún conocería los otros DC en la red principal e intentaría replicar hacia/desde ellos una vez que surgiera. Esto es muy malo por razones obvias... Si se creó dentro del entorno de prueba y tiene un nombre de dominio único separado del nombre de dominio principal, entonces está listo.
Lo que quise decir con "problemas mayores" es que si las personas colocan accidentalmente controladores de dominio en la red principal, entonces alguien debería brindarles capacitación sobre el uso de Hyper-V en lugar de tratar de limitar el daño en caso de que lo hagan. Estaría muy nervioso si tuviera gente de DEV jugando con DC (de prueba o no) alrededor de mi red de producción... ¿Podrían tener sus estaciones de trabajo Hyper-V separadas aún más en una subred completamente diferente de la red principal?
Respuesta2
Cuando dices "vallado", ¿a qué te refieres exactamente?
Si tiene dos servidores DHCP en la misma subred, entonces tendrá algunas solicitudes dirigidas a un servidor DHCP y otras al otro y, por supuesto, habrá conflictos si ambos servidores proporcionan direcciones IP del mismo grupo.
Para la situación que describió, crearía una subred enrutada para su servidor "cercado" y usaría una VLAN para aislar la subred o podría usar otro conmutador económico para una separación más física.
Su servidor DHCP de Windows puede ser multitarjeta (conectado a dos o más redes). Con dos tarjetas de red, usted cablea una tarjeta a su red de producción y cablea la otra tarjeta a un conmutador de red separado o a una VLAN separada, lo que permite que un servidor actúe como servidor DHCP para ambas redes. O, según su pregunta original, no necesitará hacer esto si desea continuar operando dos servidores DHCP.
Luego, en el conmutador o VLAN delimitado, crea una subred que es diferente a su red de producción. Por ejemplo:
Conmutador de producción/VLAN: 172.16.0.0/16 Conmutador de desarrollo/VLAN: 172.17.0.0/16
El servidor DHCP de producción puede usar un alcance de 172.16.1.1 - 172.16.1.200 El servidor DHCP de desarrollo puede usar un alcance de 172.17.1.1 - 172.17.1.200
En el alcance de DHCP de Producción, podría entregar una ruta estática a Desarrollo y en el alcance de DHCP de Desarrollo, podría entregar una ruta estática a Producción....
Es posible que necesite alguna ruta entre los dos si, por ejemplo, su área de Desarrollo necesita acceso a Internet y solo se puede acceder a Internet a través de la red de Producción.
Respuesta3
Lo más fácil es no tener ningún DHCP. ¿El dominio virtual privado es tan grande que no se pueden administrar las direcciones IP mediante IP estáticas? En segundo lugar, tiene problemas mayores si las personas conectan DC a su red principal que se supone que son solo para pruebas. No he usado Hyper-V todavía, pero en VMWare al menos puedes asignar permisos bastante granulares que evitarían que un usuario conecte la VM a una red diferente o cambie su configuración de red.