7.7 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 im Artikel zur Unterstützung des WebSocket-Protokolls in IIS 8.0 (in englischer Sprache).

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

  • Das IIS-Modul URL Rewrite muss installiert sein.

7.7.1 Konfigurieren des IIS-Reverseproxy für Host Access for the Cloud

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.

Konfigurieren von IIS

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

  2. Wählen Sie die Aktion Add Rule(s) (Regeln hinzufügen) aus, und fügen Sie eine Regel für den Reverseproxy hinzu.

  3. Geben Sie für die Eingangsregel 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. Überprüfen 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:“ (In) ein.

  5. Klicken Sie auf „OK“, um die neue Regel für den Reverseproxy zu erstellen.

Konfigurieren von Host Access for the Cloud

Zum Herstellen von Proxyverbindungen muss das IIS-Modul URL Rewrite 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. Das Standardverzeichnis für diese Datei lautet: <Installationsverzeichnis>/sessionserver/conf.

  2. Fügen Sie „container.properties“ folgende Zeilen 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 Allowed Origins 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.

Fehlerbehebung

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

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.