Zum Inhalt

Zugriff auf Host Access for the Cloud mit IIS-Reverseproxy

Dieser Abschnitt erläutert die Verwendung von IIS-Reverseproxy mit Host Access for the Cloud. Um die Common Criteria-Sicherheitsanforderungen zu erfüllen, muss der Host Access for the Cloud-Server auf nachfolgende Weise hinter einem Proxy platziert werden.

Voraussetzungen

  • Internet Information Services (IIS) 8.0 oder höher muss installiert sein.

  • Das IIS-WebSockets-Protokoll muss aktiviert sein. Informationen zum Aktivieren dieses Protokolls finden Sie unter IIS 8.0 WebSocket Protocol Support (Unterstützung des WebSocket-Protokolls in IIS 8.0).

  • IIS Application Request Routing (ARR) 3.0 oder höher ist erforderlich.

  • Das IIS-URL-Rewrite-Modul muss installiert sein.

Konfigurieren des IIS-Reverseproxys für HACloud

In diesem Beispiel wird die Konfiguration eines IIS-Servers mit der IP-Adresse 192.168.1.1 für Proxyverbindungen zum Host Access for the Cloud-Sitzungsserver unter http://10.10.10.1:7070 veranschaulicht.

IIS konfigurieren

  1. Starten Sie den Internet Information Services-Manager (IIS-Manager), navigieren Sie zu der zu verwendenden Website und öffnen Sie die URL-Rewrite-Funktion.

    IIS-Rewrite-Funktion

  2. Wählen Sie die Aktion „Regel hinzufügen“ aus und fügen Sie die Reverseproxy-Regel hinzu.

    Reverseproxy-Regel

  3. Geben Sie für die eingehende Regel den Hostnamen oder die IP-Adresse und den Port des Host Access for the Cloud-Servers ein. Wenn der Host Access for the Cloud-Sitzungsserver beispielsweise auf dem gleichen Computer installiert ist wie IIS und der zugehörige Standardport verwendet wird, geben Sie localhost:7443 ein.

  4. Aktivieren Sie die ausgehende Regel „Rewrite the domain names...“ (Domänennamen umschreiben) und geben Sie den Hostnamen oder die IP-Adresse des IIS-Servers im Feld „To:“ (An) ein.

  5. Klicken Sie auf „OK“, um die neue Reverseproxy-Regel zu erstellen.

HACloud konfigurieren

Zum Herstellen von Proxyverbindungen muss das IIS-URL-Rewrite-Modul die Webseiten und WebSocket-Verbindungen, die den Proxy durchlaufen, prüfen und umschreiben. Zur erfolgreichen Umschreibung müssen diese Elemente in nicht komprimierter Form gesendet werden. Beachten Sie, dass die konfigurierte Komprimierung weiterhin vom IIS-Server zum Browser des Clients erfolgt. Der Sitzungsserver muss auch so konfiguriert werden, dass WebSocket-Verbindungen vom Proxy ausgehen können.

  1. Öffnen Sie „container.properties“ in einem Texteditor. Der Standardspeicherort für diese Datei ist: /sessionserver/conf.

  2. Fügen Sie die folgenden Zeilen zu container.properties hinzu:

    websocket.compression.enable=false 
server.compression.enabled=false 
websocket.allowed.origins=http://<Name oder IP-Adresse des IIS-Servers>. Beispiel: 192.168.1.1.

    Speichern Sie die Änderungen in der Datei. Die Eigenschaft „Zulässige Ursprünge“ ist eine durch Kommas getrennte Liste von URLs. Wenn Webclients über HTTPS eine Verbindung mit Ihrer Website herstellen, passen Sie die URL entsprechend an. Wenn sichere sowie nicht sichere Verbindungen verwendet werden, verwenden Sie beide URLs als Wert: websocket.allowed.origins=http://192.168.1.1,https://192.168.1.1. Um Fehler zu vermeiden, sollten Sie sicherstellen, dass in der Liste „Zulässige Ursprünge“ alle möglichen Adressformate enthalten sind.

  3. Starten Sie die Website und den Sitzungsserver neu und testen Sie den Proxy durch Herstellen einer Verbindung mit http(s)://192.168.1.1.

Fehlersuche

Wenn Webserverfehler ausgegeben werden, kann das Problem durch Aktivieren der detaillierten Fehler diagnostiziert werden. Öffnen Sie im IIS-Manager die Funktion „Fehlerseiten“ und aktivieren Sie „Detaillierte Fehler“:

Fehler bearbeiten

Normalerweise werden Fehler im 5XX-Bereich durch Probleme mit der aktivierten Komprimierung oder Fehler im Wert „Zulässige Ursprünge“ verursacht.

Wenn der IIS-Proxy über HTTPS eine Verbindung mit dem Sitzungsserver herstellt, muss das mit dem Sitzungsserver verwendete Zertifikat vom IIS-Server verbürgt werden. Wenn der Sitzungsserver ein eigensigniertes Zertifikat verwendet, muss dieses Zertifikat zum Windows-Truststore hinzugefügt werden. Wenn der Sitzungsserver ein signiertes Zertifikat verwendet, muss der Signaturgeber eine vertrauenswürdige Zertifizierungsstelle sein.