4
Hyper-V-Manager über VPN auf Hyper-V Server 2012
Hallochen allerseits!
In der bestehenden Domaine ist ein Hyper-V Server 2012 vorhanden. Dieser wird von einem Domaine-Client mit Windows 8 administriert. Im internen Netzwerk funktionieren sowohl Remotedesktop als auch der Hyper-V-Manager problemfrei.
Es besteht aber folgende Kuriosität:
Der Client kann sich per VPN ins interne Netzwerk einloggen mittels eines FortiClient. Eine FortiGate 60D ist der VPN-Server. Das ist problemfrei.
Befindet sich der Client unmittelbar im Netzwerk vor dem VPN-Server (gleicher IP-Bereich wie VPN-Interface), dann funktioniert weiterhin der Remotedesktop. Auch kann ich mich mit dem Hyper-V-Manager mit dem Hyper-V Server 2012 verbinden. Indes kann nicht auf die virtuellen Maschinen zugegriffen werden. Es findet sich die Meldung, dass der Zugriff für den Client verweigert werde.
Komisch ist, dass bei einer Einwahl von extern (aus Internet über Router und Portforwarding für das VPN zur FortiGate) weder der Remotedesktop gestartet werden kann noch sich der Hyper-V-Manager mit dem Hyper-V Server 2012 verbinden lässt. Ein Ping bleibt ohne Reaktion.
Interessanterweise ist eine Remotedesktop-Verbindung zu einem Windows SBS 2003 R2 problemfrei. Auch dessen Netzwerkfreigaben sind einschränkungslos nutzbar. Dieser Server kann zudem angepingt werden.
Wo liegt hier das Problem?
Am Router dürfte es nicht liegen, weil der VPN-Tunnel an die FortiGate weitergeleitet wird und daher der Router als solches in den Datenverkehr über den Tunnel nicht eingebunden ist.
Die Policy auf dem VPN-Server leitet alles vom VPN-Client ins interne Netz.
Sind etwa dennoch weitere Freigaben auf der FortiGate erforderlich? Oder ist eine Anpassung der Firewall auf dem Hyper-V Server 2012 nötig?
Besteht möglicherweise nur ein Routing-Problem auf dem Client? Route print lässt keine zunächst keine Besonderheiten zwischen den beiden Einwahlvarianten erkennen.
Wer weiß eine Lösung für dieses Problem? Wie lässt sich der Hyper-V Server 2012 von extern über VPN vollständig administrieren?
HansDampf06
In der bestehenden Domaine ist ein Hyper-V Server 2012 vorhanden. Dieser wird von einem Domaine-Client mit Windows 8 administriert. Im internen Netzwerk funktionieren sowohl Remotedesktop als auch der Hyper-V-Manager problemfrei.
Es besteht aber folgende Kuriosität:
Der Client kann sich per VPN ins interne Netzwerk einloggen mittels eines FortiClient. Eine FortiGate 60D ist der VPN-Server. Das ist problemfrei.
Befindet sich der Client unmittelbar im Netzwerk vor dem VPN-Server (gleicher IP-Bereich wie VPN-Interface), dann funktioniert weiterhin der Remotedesktop. Auch kann ich mich mit dem Hyper-V-Manager mit dem Hyper-V Server 2012 verbinden. Indes kann nicht auf die virtuellen Maschinen zugegriffen werden. Es findet sich die Meldung, dass der Zugriff für den Client verweigert werde.
Komisch ist, dass bei einer Einwahl von extern (aus Internet über Router und Portforwarding für das VPN zur FortiGate) weder der Remotedesktop gestartet werden kann noch sich der Hyper-V-Manager mit dem Hyper-V Server 2012 verbinden lässt. Ein Ping bleibt ohne Reaktion.
Interessanterweise ist eine Remotedesktop-Verbindung zu einem Windows SBS 2003 R2 problemfrei. Auch dessen Netzwerkfreigaben sind einschränkungslos nutzbar. Dieser Server kann zudem angepingt werden.
Wo liegt hier das Problem?
Am Router dürfte es nicht liegen, weil der VPN-Tunnel an die FortiGate weitergeleitet wird und daher der Router als solches in den Datenverkehr über den Tunnel nicht eingebunden ist.
Die Policy auf dem VPN-Server leitet alles vom VPN-Client ins interne Netz.
Sind etwa dennoch weitere Freigaben auf der FortiGate erforderlich? Oder ist eine Anpassung der Firewall auf dem Hyper-V Server 2012 nötig?
Besteht möglicherweise nur ein Routing-Problem auf dem Client? Route print lässt keine zunächst keine Besonderheiten zwischen den beiden Einwahlvarianten erkennen.
Wer weiß eine Lösung für dieses Problem? Wie lässt sich der Hyper-V Server 2012 von extern über VPN vollständig administrieren?
HansDampf06
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 208069
Url: https://administrator.de/contentid/208069
Printed on: April 19, 2024 at 05:04 o'clock
4 Comments
Latest comment
Testweise würde ich die FW des H-V mal deaktiveren. Wenn es dann funktioniert war es das auch schon.
Hallo,
Gateway ist eingetragen?
lg
Gateway ist eingetragen?
lg
@certifiedit:
Das Deaktivieren der Firewall muss ich ausprobieren, wenn ich wieder vor Ort bin.
@Flatcher:
Die Routing-Einstellungen sind überprüft und dürften korrekt sein. Immerhin kann ich den WinSBS2003R2 vollständig von extern erreichen und nutzen. Auch tracert bestätigt, dass die Kommunikation den richtigen Weg nimmt.
Am DNS kann es nicht liegen, weil einerseits der Client von extern die betreffenden Computernamen im internen Netzwerk auflösen kann (ping mit -a) und weil andererseits der Hyper-V Server explizit in der hosts-Datei gelistet ist (einziger Eintrag).
Da sich das Problem differenziert bei der VPN-Einwahl zeigt (Einwahl von extern / Einwahl von DMZ zwischen Internetrouter und VPN-Server), vermute ich ganz stark, dass es trotz der NAT auf dem VPN-Server an den vom internen Netzwerk abweichenden IP-Adressen des Clients liegt. Alles andere dürfte sich durch den Standortunterschied nicht verändern.
Wenn diese Annahme richtig sein sollte, vermute ich die Notwendigkeit eines entsprechenden Rechteeintrags auf dem Hyper-V Server. Ob, wo und wie das zielführend umzusetzen wäre, weiß ich aber nicht.
Das Deaktivieren der Firewall muss ich ausprobieren, wenn ich wieder vor Ort bin.
@Flatcher:
Die Routing-Einstellungen sind überprüft und dürften korrekt sein. Immerhin kann ich den WinSBS2003R2 vollständig von extern erreichen und nutzen. Auch tracert bestätigt, dass die Kommunikation den richtigen Weg nimmt.
Am DNS kann es nicht liegen, weil einerseits der Client von extern die betreffenden Computernamen im internen Netzwerk auflösen kann (ping mit -a) und weil andererseits der Hyper-V Server explizit in der hosts-Datei gelistet ist (einziger Eintrag).
Da sich das Problem differenziert bei der VPN-Einwahl zeigt (Einwahl von extern / Einwahl von DMZ zwischen Internetrouter und VPN-Server), vermute ich ganz stark, dass es trotz der NAT auf dem VPN-Server an den vom internen Netzwerk abweichenden IP-Adressen des Clients liegt. Alles andere dürfte sich durch den Standortunterschied nicht verändern.
Wenn diese Annahme richtig sein sollte, vermute ich die Notwendigkeit eines entsprechenden Rechteeintrags auf dem Hyper-V Server. Ob, wo und wie das zielführend umzusetzen wäre, weiß ich aber nicht.
Hallochen!
Gestern bin ich dem Problem, da es gelöst werden muss, wieder auf den Pelz gerückt. Und siehe da, es lässt sich eingrenzen.
Auf die Fährte hat mich ein Beitrag von John Howard betreffend Zugriffsproblemen bei Hyper-V über VPN gebracht. Er definiert es als DNS-Problem. Und in der Tat liegt dort der Hund begraben, wie ich selbst verifizieren konnte. Die IP des einwählenden Win8-Managers wird im DNS nicht aktualisiert. Wird hingegen der VPN-Zugang so konfiguriert, dass dem Win8-Manager bei der Einwahl die sonst feste intern statische IP zugewiesen wird, kann ganz gewohnt administriert werden wie aus dem internen Netz. Mit anderen Worten: VPN ist nur scheinbar die Ursache. Ursache ist vielmehr die falsche Adressierung der Kommunikation durch den Hyper-V Server mangels DNS-Aktualisierung für den extern agierenden Win8-Manager. Durch vergleichende Betrachtung des Netzverkehrs mit einem Sniffer kann das gut nachvollzogen werden.
Daraus leiten sich zwei Lösungsvarianten ab, wobei sich die Problemlage im zweiten Ansatz verschiebt.
1. Sicherherstellung, dass sich der Win8-Manager bei VPN-Einwahl im DNS registriert, also seine IP anpasst (genauso bei Anwesenheit intern). Da der Win8 Domänenmitglied ist, ist seine IP im DNS scheinbar fest. Wie kann das gehandhabt werden, also was ist zu tun?
2. Ein zweites VPN-Profil, bei dem der Win8 bei externer Einwahl seine interne IP erhält. Das Anlegen mehrerer VPN-Profile auf der FortiGate ist kein Problem. Nur kann mit dem FortiClient nur auf eines der Profile zugegriffen werden (alphabetisch erstes). Alle anderen bringen keine Verbindung zu stande. Woran liegt das? Was muss für die Unterscheidung der VPN-Profile bei der Einwahl gemacht werden? Unterschiedliche User und Gruppen sowie PSK je Profil habe ich bereits probiert ohne Erfolg. Ordnet die FortiGate die Einwahl immer dem alphabetisch ersten VPN-Profil zu? Wer weiß dazu Rat, weil das auch unabhängig von Hyper-V eine bedeutsame Frage ist?
Gestern bin ich dem Problem, da es gelöst werden muss, wieder auf den Pelz gerückt. Und siehe da, es lässt sich eingrenzen.
Auf die Fährte hat mich ein Beitrag von John Howard betreffend Zugriffsproblemen bei Hyper-V über VPN gebracht. Er definiert es als DNS-Problem. Und in der Tat liegt dort der Hund begraben, wie ich selbst verifizieren konnte. Die IP des einwählenden Win8-Managers wird im DNS nicht aktualisiert. Wird hingegen der VPN-Zugang so konfiguriert, dass dem Win8-Manager bei der Einwahl die sonst feste intern statische IP zugewiesen wird, kann ganz gewohnt administriert werden wie aus dem internen Netz. Mit anderen Worten: VPN ist nur scheinbar die Ursache. Ursache ist vielmehr die falsche Adressierung der Kommunikation durch den Hyper-V Server mangels DNS-Aktualisierung für den extern agierenden Win8-Manager. Durch vergleichende Betrachtung des Netzverkehrs mit einem Sniffer kann das gut nachvollzogen werden.
Daraus leiten sich zwei Lösungsvarianten ab, wobei sich die Problemlage im zweiten Ansatz verschiebt.
1. Sicherherstellung, dass sich der Win8-Manager bei VPN-Einwahl im DNS registriert, also seine IP anpasst (genauso bei Anwesenheit intern). Da der Win8 Domänenmitglied ist, ist seine IP im DNS scheinbar fest. Wie kann das gehandhabt werden, also was ist zu tun?
2. Ein zweites VPN-Profil, bei dem der Win8 bei externer Einwahl seine interne IP erhält. Das Anlegen mehrerer VPN-Profile auf der FortiGate ist kein Problem. Nur kann mit dem FortiClient nur auf eines der Profile zugegriffen werden (alphabetisch erstes). Alle anderen bringen keine Verbindung zu stande. Woran liegt das? Was muss für die Unterscheidung der VPN-Profile bei der Einwahl gemacht werden? Unterschiedliche User und Gruppen sowie PSK je Profil habe ich bereits probiert ohne Erfolg. Ordnet die FortiGate die Einwahl immer dem alphabetisch ersten VPN-Profil zu? Wer weiß dazu Rat, weil das auch unabhängig von Hyper-V eine bedeutsame Frage ist?
