Dies ist mein erstes Mal, dass ich Hyper-V oder Windows 2008 einrichte, also haben Sie bitte Geduld mit mir.
Ich richte einen recht guten Server mit Windows Server 2008 R2 als Remote-Hyper-V-Host (am selben Standort) ein. Er wird Linux- und Windows-VMs hosten, zunächst für Entwickler, später aber auch für Webhosting und andere Aufgaben. Derzeit habe ich zwei VMs, eine Windows- und eine Ubuntu-Linux-VM, die recht gut laufen, und ich plane, sie für die zukünftige Verwendung zu klonen.
Im Moment überlege ich, wie ich den Entwickler- und Administratorzugriff auf den Server am besten konfigurieren kann, wenn er in die Colocation-Einrichtung verschoben wurde, und suche dazu Rat. Ich denke daran, ein VPN für den Zugriff auf bestimmte Funktionen der VMs auf dem Server einzurichten, aber ich habe ein paar verschiedene Möglichkeiten, dies zu erreichen:
Verbinden Sie den Server mit einer vorhandenen Hardware-Firewall (einem älteren Netscreen 5-GT), die ein VPN erstellen und externe IPs den VMs zuordnen kann, deren eigene IPs über die virtuelle Schnittstelle verfügbar gemacht werden. Ein Problem bei dieser Wahl ist, dass ich der Einzige bin, der auf dem Netscreen geschult ist, und seine Schnittstelle ist etwas barock, sodass andere möglicherweise Schwierigkeiten bei der Wartung haben. Der Vorteil ist, dass ich bereits weiß, wie es geht, und ich weiß, dass es das tun wird, was ich brauche.
Verbinden Sie den Server direkt mit dem Netzwerk und konfigurieren Sie die Windows 2008-Firewall, um den Zugriff auf die VMs einzuschränken und ein VPN einzurichten. Ich habe das noch nie gemacht, daher wird es eine Lernkurve geben, aber ich bin bereit herauszufinden, ob diese Option langfristig besser ist als Netscreen. Ein weiterer Vorteil ist, dass ich niemanden in die Netscreen-Oberfläche einweisen muss. Dennoch bin ich mir nicht sicher, ob die Fähigkeiten der Windows-Software-Firewall zum Erstellen von VPNs, zum Einrichten von Regeln für den externen Zugriff auf bestimmte Ports auf den IPs von Hyper-V-Servern usw. ausreichen. Wird sie für meine Anforderungen ausreichen und einfach genug einzurichten/zu warten sein?
Sonst noch etwas? Wo liegen die Grenzen meiner Ansätze? Was sind die besten Vorgehensweisen/was hat bei Ihnen gut funktioniert? Denken Sie daran, dass ich für einige Dienste sowohl Entwickler- als auch Verbraucherzugriff einrichten muss. Ist ein VPN überhaupt die richtige Wahl?
Bearbeiten:Ich werde wahrscheinlich Option 2 verwenden und RRAS einrichten, um ein VPN zu erstellen, bin aber trotzdem an Ihrem Input interessiert.
Antwort1
Ich persönlich würde eine separate physische Firewall (Netscreen oder was auch immer für Sie am besten geeignet ist) verwenden, die das VPN separat verwaltet, und in ein Out-of-Band-Verwaltungssystem (wie Dells DRAC) investieren, das Ihnen Low-Level-Zugriff auf Ihren Server (und den Konsolenport der Firewall, wenn Sie Ihre Firmware aktualisieren möchten) gewährt, falls VMs oder Hosts hängen bleiben oder abstürzen (glauben Sie mir: das wird passieren) oder wenn Sie sorgenfreie Windows-Updates usw. durchführen möchten.
Der Netscreen sollte IPSec-Mobil-VPN-Zugriff mit dem zusätzlichen Vorteil einer Zwei-Faktor-Authentifizierung (Zertifikate und Passphrasen) unterstützen. Es ist schon eine Weile her, seit ich einen verwendet habe, aber ich glaube, sie haben mehrere VPN-Optionen zur Verfügung.
Wenn Sie sich für eine Hardware-Firewall (oder besser gesagt für ein „Unified Threat Management“-Gerät als Firewall mit allem Drum und Dran, über das die meisten Firewalls heutzutage verfügen) entscheiden, haben Sie auch später mehr Flexibilität im Hinblick auf die Weiterleitung von SMTP-/DNS-Anfragen, DMZs usw., wenn Sie in eine Produktionsumgebung für das Webhosting wechseln.
Antwort2
Eine Firewall ist unnötig. Vor allem für einen Hyper-V-Host. Die meisten Hosts haben sowieso 2-3 Netzwerkkarten. Benutze EINE für Hyper-V, lass Hyper-V selbst dort NICHT verwenden (also nur für VMs) und achte dort nicht darauf, dass Hyper-V den Server schützt ;)
Auf der anderen Seite: Verwenden Sie die Windows-Firewall und lassen Sie NUR Remotedesktop zu. Fertig.