Externe IP des HyperV-Gasts: RRAS NAT auf Host VS direkter Zugriff auf externes Netzwerk mit Microsoft Virtual Switch?

Externe IP des HyperV-Gasts: RRAS NAT auf Host VS direkter Zugriff auf externes Netzwerk mit Microsoft Virtual Switch?

Ich habe einen Win2008 R2 HyperV-Host mit einem physischen Adapter, auf dem eine Reihe von VMs laufen. Ich habe ein Subnetz mit externen IP-Adressen: xxx208 / 255.255.255.240

Früher hatte ich folgendes Setup:

Das Host-Betriebssystem hätte die Rollen AD DC, HyperV, RRAS, DHCP und DNS. Dem physischen Adapter würden alle verfügbaren IP-Adressen explizit zugewiesen:

xxx210 / 255.255.255.240

...

xxx221 / 255.255.255.240

Im HyperV-Netzwerk würde ein externes Netzwerk erstellt – aber mit aktivierter Option „Verwaltungsbetriebssystem darf Adapter gemeinsam nutzen“ – auf diese Weise könnte ich dem Hostbetriebssystem auch eine öffentliche IP zuweisen:

Bildbeschreibung hier eingeben

HyperV hat einen weiteren Netzwerkadapter erstellt, den ich für das interne LAN (192.168.2.0 / 255) verwendet habe. RRAS wurde für NAT und LAN-Routing eingerichtet und führt NATting für Gäste wie folgt durch:

xxx210 -> 192.168.2.10, Eingehende Sitzungen zulassen = JA

...

xxx221 -> 192.168.2.21, Eingehende Sitzungen zulassen = JA

Grundsätzlich hatten also alle Gast-VMs keine externe IP-Adresse – aber für sie spielte das keine Rolle – sie hatten trotzdem Zugriff auf das Internet und waren von außen erreichbar.

dann begannen wir, Probleme mit RRAS, VPN usw. zu haben – also habe ich ein bisschen nachgelesen und gelesen, dass das NAT-Schema nicht gut ist ( could someone comment on this btw?) und ich physische Adapter virtualisieren sollte, um Gast-VMs direkten Zugriff auf das externe Netzwerk zu geben. Okay, das habe ich gemacht.

Hier ist das aktuelle Setup:

Ich habe „Verwaltungsbetriebssystem darf Adapter gemeinsam nutzen“ vom externen Adapter entfernt und HyperV ein zweites internes Netzwerk hinzugefügt.

Bildbeschreibung hier eingeben

Dann musste ich jeder Gast-VM einen zweiten Netzwerkadapter hinzufügen – und dann für jeden explizit eine öffentliche IP-Adresse festlegen. Das wurde erledigt und funktioniert einwandfrei. Die RRAS-Rolle wurde vom Host entfernt.

Fragen:

  1. Habe ich das Richtige getan? Mein inneres Gefühl sagt ja – da wir hier weniger „Teile“ haben (oder zumindest so aussehen), aber ich möchte einfach ein paar kompetente Meinungen einholen.

  2. Gibt es Probleme, die ich beim aktuellen Setup im Vergleich zum alten beachten sollte? Gibt es bewährte Vorgehensweisen, die ich befolgen sollte, nachdem ich das Netzwerk wie oben beschrieben eingerichtet habe?

  3. Wahrscheinlich die wichtigste Frage für mich. In beiden Szenarien läuft die Firewall auf der Gast-VM, und nach dem Wechsel hat sich nichts geändert. Und ich hatte es so verstanden, dass NAT den Datenverkehr nicht filtert – alles geht direkt an den Gast. ABER gleich nach dem Wechsel bekomme ich die folgenden Fehler im Protokoll (auf unserem Exchange-VM-Server):

Die eingehende Authentifizierung ist mit dem Fehler LogonDenied für den Empfangsconnector Default EXCHANGE fehlgeschlagen. Der Authentifizierungsmechanismus ist Ntlm. Die Quell-IP-Adresse des Clients, der versucht hat, sich bei Microsoft Exchange zu authentifizieren, ist [200.195.42.7].

das impliziert für mich irgendwie, dass die VM in der neuen Konfiguration „mehr“ externen Bedrohungen ausgesetzt war – aber ich verstehe einfach nicht, warum das im NAT-Szenario nicht der Fall war? Ich habe es überprüft – vor dem Wechsel gab es KEINE Fehler dieser Art. Warum bekomme ich jetzt solche Fehler? Was hat sich aus Netzwerksicht geändert?

verwandte Informationen