Ich habe ursprünglich gefragtDasFrage zu Stack Overflow und wurde hierher verwiesen.
Mithilfe von Hyper-V habe ich eine private Windows-Domäne erstellt, die von unserem Hauptnetzwerk abgegrenzt ist. Letztendlich möchte ich diese Domäne für andere bereitstellen, damit sie sie für Entwicklung und Tests verwenden können, sodass sie Domänenadministratoren sein können.
Mein Problem ist folgendes: Auf dem Domänencontroller läuft der DHCP-Dienst. Wenn jemand die Domäne auf seinem Hyper-V-Host bereitstellt und sie versehentlich mit dem Hauptnetzwerk verbindet, beginnt der DHCP-Dienst, falsche IP-Konfigurationen zuzuweisen.
Ich möchte diese Situation verhindern. Ich habe überlegt, einen Dienst zu schreiben, umdhcploc, dieser Dienst würde dann den lokalen DHCP-Dienst stoppen, wenn ein Remote-DHCP-Server gefunden werden kann. Dies dient eigentlich der Schadensbegrenzung, da dem betrügerischen DHCP-Server immer noch ein kleines Zeitfenster zur Verfügung stünde.
Gibt es eine bessere/einfachere Alternative, mit der das Ziel erreicht werden könnte? Gibt es irgendwelche Einschränkungen, die ich beachten sollte?
Danke
Antwort1
Da Ihre Test-DHCP-Konfiguration MAC-Adressen verwendet, um reguläre IPs zuzuweisen, können Sie den Umfang so einschränken, dass nur die bekannten MAC-Adressen enthalten sind. Auf diese Weise werden keine IPs vergeben, selbst wenn jemand den DC versehentlich in das Hauptnetzwerk einfügt, da keine der Anfragen mit einer der MACs in seinem Umfang übereinstimmt. Was mögliche Probleme beim Einbinden eines Test-DC in Ihr Hauptnetzwerk betrifft, so hängt dies von einigen Faktoren ab:
1) Hoffentlich verwenden Sie für das Testnetzwerk ein anderes Subnetz als für das Hauptnetzwerk. Beispiel: Testnetz = 172.16.0.0 und Hauptnetz = 10.0.0.0. Dadurch wird der Zugriff der Test-DCs auf Dinge im Hauptnetzwerk beschränkt, solange sie keinen Router erreichen können, der beide Subnetze kennt und so eingestellt ist, dass er zwischen ihnen routet. 2) Wie wurde der Test-DC erstellt? Wenn er zuerst an das Hauptnetzwerk angeschlossen wurde, um AD-Daten per Replikation abzurufen, und dann entfernt und in die Testumgebung eingefügt wurde, würde er immer noch die anderen DCs im Hauptnetzwerk kennen und versuchen, sie zu/von ihnen zu replizieren, sobald er verfügbar ist. Das ist aus offensichtlichen Gründen sehr schlecht... Wenn er innerhalb der Testumgebung erstellt wurde und einen eindeutigen Domänennamen hat, der vom Hauptdomänennamen getrennt ist, können Sie loslegen.
Mit „größeren Problemen“ meinte ich, dass Leute, die versehentlich DCs in das Hauptnetzwerk einbinden, in der Verwendung von Hyper-V geschult werden sollten, anstatt zu versuchen, den Schaden zu begrenzen, falls sie es doch tun! Ich wäre sehr nervös, wenn Entwickler mit DCs (Test oder nicht) in meinem Produktionsnetzwerk herumspielen würden … Könnten Sie ihre Hyper-V-Arbeitsstationen noch weiter vom Hauptnetzwerk trennen und in einem anderen Subnetz unterbringen?
Antwort2
Was genau meinen Sie mit „eingezäunt“?
Wenn Sie zwei DHCP-Server im selben Subnetz haben, werden einige Anfragen an den einen DHCP-Server und einige an den anderen gesendet. Außerdem kommt es natürlich zu Konflikten, wenn beide Server IPs aus demselben Pool vergeben.
Für die von Ihnen beschriebene Situation würde ich ein geroutetes Subnetz für Ihren „abgeschirmten“ Server erstellen und ein VLAN verwenden, um das Subnetz zu isolieren. Alternativ könnten Sie einen anderen günstigen Switch für eine stärkere physische Trennung verwenden.
Ihr Windows DHCP-Server kann multihomed sein (mit zwei oder mehr Netzwerken verbunden sein). Mit zwei Netzwerkkarten verkabeln Sie eine Karte mit Ihrem Produktionsnetzwerk und die andere Karte mit einem separaten Netzwerk-Switch oder einem separaten VLAN, sodass ein Server als DHCP-Server für beide Netzwerke fungieren kann. Oder, gemäß Ihrer ursprünglichen Frage, Sie müssten dies nicht tun, wenn Sie weiterhin zwei DHCP-Server betreiben möchten.
Anschließend erstellen Sie auf dem abgegrenzten Switch oder VLAN ein Subnetz, das sich von Ihrem Produktionsnetzwerk unterscheidet. Beispiel:
Produktions-Switch/VLAN: 172.16.0.0/16 Entwicklungs-Switch/VLAN: 172.17.0.0/16
Der Produktions-DHCP-Server kann einen Bereich von 172.16.1.1 - 172.16.1.200 verwenden. Der Entwicklungs-DHCP-Server kann einen Bereich von 172.17.1.1 - 172.17.1.200 verwenden.
Im DHCP-Bereich der Produktion könnten Sie eine statische Route an die Entwicklung vergeben und im DHCP-Bereich der Entwicklung könnten Sie eine statische Route an die Produktion vergeben...
Möglicherweise benötigen Sie ein Routing zwischen den beiden, wenn beispielsweise Ihr Entwicklungsbereich Internetzugang benötigt und auf das Internet nur über das Produktionsnetzwerk zugegriffen werden kann.
Antwort3
Am einfachsten ist es, überhaupt kein DHCP zu haben. Ist die private virtuelle Domäne so groß, dass Sie die IP-Adressen nicht mit statischen IPs verwalten können? Zweitens haben Sie größere Probleme, wenn Leute DCs an Ihr Hauptnetzwerk anschließen, die eigentlich nur zu Testzwecken dienen sollen. Ich habe Hyper-V noch nicht verwendet, aber in VMWare können Sie zumindest ziemlich detaillierte Berechtigungen zuweisen, die einen Benutzer daran hindern würden, die VM an ein anderes Netzwerk anzuschließen oder ihre Netzwerkkonfiguration zu ändern.