Ein Reverse-Proxy wird normalerweise verwendet, um einen einzigen Zugangspunkt für die Frontend- oder Client-Seite eines Dienstes zu haben. Reverse-Proxys werden in der Regel so implementiert, dass sie die Sicherheit, Leistung und Zuverlässigkeit erhöhen. Sie ermöglichen es auch, denselben Dienst auf mehreren Ursprungsservern - oder Knoten - zu betreiben, ohne dass der Web-Client von dieser Architektur und Komplexität weiß.

Die Verwendung von i-net CoWork mit einem Reverse-Proxy ist erforderlich in einer Umgebung mit mehreren Knoten, wenn zusätzliche Server verwendet werden, um die verfügbare Arbeitskraft zu skalieren und eine bessere Leistung für den parallelen Zugriff vieler Benutzer zu bieten. Ein Reverse-Proxy kann auch verwendet werden, um einfach einen statischen, dem Client zugewandten Zugriffspunkt auf den i-net CoWork-Server in einer DMZ bereitzustellen.

Es wird empfohlen, die folgenden Header an den i-net CoWork-Server weiterzuleiten:

• X-Forwarded-Proto
• X-Forwarded-Host
• X-Forwarded-Port
• X-Forwarded-Context

Der HAProxy benötigt die folgenden Optionen:

# Wenn die Anwendung ueber Standard-Https-Ports laeuft
http-request set-header X-Forwarded-Port 443
http-request set-header X-Forwarded-Proto https if { ssl_fc }
 
# Wenn die Anwendung unter einem bestimmten Subkontext verfuegbar ist
# z.B. https://mycompany.com/subcontext
http-request set-header X-Forwarded-Context /subcontext
 
# Setzen des Hosts ist nicht Standard
http-request set-header X-Forwarded-Host %[req.hdr(Host)]

Die NGinx benötigt folgende Optionen, die auch hier dokumentiert sind:

# Wenn die Anwendung ueber Standard-Https-Ports laeuft
proxy_set_header X-Forwarded-Port 443;
proxy_set_header X-Forwarded-Proto https;;
 
# Wenn die Anwendung unter einem bestimmten Subkontext verfuegbar ist
# z.B. https://mycompany.com/subcontext
proxy_set_header X-Forwarded-Context /subcontext;
 
# Setzen des Hosts ist nicht Standard
proxy_set_header X-Forwarded-Host $remote_addr;

Der Apache benötigt die folgenden Optionen:

# Wenn die Anwendung ueber Standard-Https-Ports laeuft
Header set X-Forwarded-Port 443
Header set X-Forwarded-Proto https
 
# Wenn die Anwendung unter einem bestimmten Subkontext verfuegbar ist
# z.B. https://mycompany.com/subcontext
Header set X-Forwared-Context /subcontext

Der IIS hat einen Prozess, der mehrere Schritte erfordert, um die Weiterleitung der Header zu aktivieren.

1. Installieren der URL Rewrite IIS Erweiterung. Diese kann bei Microsoft heruntergeladen werden.
2. Installieren der Application Request Routing (ARR) IIS Erweiterung.
3. IIS als Proxy aktivieren.
   • Wählen Sie den Hauptbaumknoten (Servername) > Application Request Routing Cache > Server Proxy Settings.
   • Markieren Sie das Feld Proxy aktivieren.
   • Klicken Sie auf Übernehmen.
4. Aktivieren Sie die Weiterleitung der Header im Menü URL umschreiben > Server Variables bearbeiten... > Hinzufügen und fügen Sie die folgenden Header hinzu:
   • HTTP_X_FORWARDED_PROTO
   • HTTP_X_FORWARDED_HOST
   • HTTP_X_FORWARDED_PORT
   • HTTP_X_FORWARDED_CONTEXT
5. Richten Sie die Header-Felder in der Reverse-Proxy-Regel wie in der folgenden Tabelle angegeben ein

Die resultierende web.config sollte wie folgt aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="^subcontext(.*)" />
                    <action type="Rewrite" url="http://localhost:9000{R:1}" />
                    <serverVariables>
                        <set name="HTTP_X_FORWARDED_PORT" value="{SERVER_PORT}" />
                        <set name="HTTP_X_FORWARDED_CONTEXT" value="/subcontext" />
                        <set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
                        <set name="HTTP_X_FORWARDED_PROTO" value="https" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Hinweis: Der IIS verlangt, dass die Header-Felder mit Großbuchstaben und mit Untersrtrichen anstelle eines Bindestrichs kombiniert werden.

Die Absicherung des Servers mit gehärteten SSL-Optionen und z.B. HSTS erfordert zusätzliche Header, die auf dem Proxy gesetzt werden müssen - oder, falls keiner verwendet wird, in der Webserver-Header-Konfiguration.

Die folgenden Header sind von der Empfehlung auf https://cipherlist.dev abgeleitet. Sie können mit Hilfe von SSL Labs oder dem SSL Checker überprüfen, wie die Einstellungen von Browsern interpretiert werden. Um gehärtete SSL-Optionen zu erstellen, können Sie auch den Mozilla SSL Konfigurationsgenerator verwenden.

# siehe https://cipherlist.dev
# Haertung des Ressourcenzugriffs. Verbietet Browsern die Verwendung anderer Protokolle, als sie hier definiert sind.
# Hinweis: nur sichere Protokolle sind erlaubt.
# Hinweis: ''designers'' ist nur erforderlich, damit das i-net Designer-Protokoll die Desktop-Anwendung oeffnen kann.
http-response set-header Content-Security-Policy "default-src https: mailto: designers: 'unsafe-inline' 'unsafe-eval'; img-src https: data: blob:; connect-src wss: https:"
 
# SAMEORIGIN erlaubt die Verwendung von iframe/cross origin. Verwenden Sie DENY, um die herkunftsuebergreifende Verwendung nicht zuzulassen
http-response set-header X-Frame-Options SAMEORIGIN
 
http-response set-header X-Content-Type-Options nosniff
http-response set-header X-XSS-Protection "1; mode=block"
 
http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"