Barvna shema: Svetla
Trenutno dejavna stran: start » de » Dokumentation » Datenintegration und Datenzugriff » WKL Database Gateway » Anleitungen » So betreiben Sie den Dienst hinter IIS oder einem Proxy

So betreiben Sie den Dienst hinter IIS oder einem Proxy

Steht vor dem Dienst ein IIS, ein Lastverteiler oder ein anderer Proxy, sieht der Dienst zunächst nur dessen Adresse. Damit Herkunftsregeln, die Anmelderichtlinie und die Pflicht zu HTTPS richtig greifen, muss der Dienst dem Proxy ausdrücklich vertrauen.

Lösungsübersicht

Der Proxy meldet die Adresse des Aufrufers in X-Forwarded-For, das Schema in X-Forwarded-Proto und den Host, den der Aufrufer angesprochen hat, in X-Forwarded-Host. Der Dienst glaubt diesen Kopfzeilen nur, wenn sie von einer Adresse unter Gateway:Security:TrustedProxies kommen. Ohne diesen Eintrag sähe er jeden Aufrufer mit der Adresse des Proxys – liegt dieser im Firmennetz, gälte jeder als „innen“.

Umsetzung

  1. Lassen Sie den Dienst nur auf 127.0.0.1 lauschen (oder auf einer Adresse, die nur der Proxy erreicht), etwa mit Kestrel:Endpoints:Http:Url = http://127.0.0.1:8434.
  2. Tragen Sie den Proxy als vertrauenswürdig ein:

    "Security": { "TrustedProxies": [ "127.0.0.1", "::1" ] }
  3. Lassen Sie den Proxy X-Forwarded-For, X-Forwarded-Proto: https und X-Forwarded-Host setzen. Fehlt X-Forwarded-For, gilt jede Anfrage als vom Proxy selbst – bei IIS auf demselben Rechner also als 127.0.0.1: innen, geschützt, von jeder Netzregel ausgenommen. Prüfen Sie deshalb nach dem Einrichten im Audit, dass dort die wirklichen Herkünfte stehen. Aus Schema und Host bildet der Dienst die absoluten Adressen seiner Antworten: Dienstdokument und Folgeseiten der OData-Oberfläche, Location nach dem Anlegen, Einmal-Links der Verwaltung. Fehlt X-Forwarded-Host, zeigen sie auf 127.0.0.1 und sind von außen nicht erreichbar. Der Dienst nimmt von jeder Kopfzeile den letzten Eintrag, den der nächste Proxy angehängt hat, und vom Host nur einen Rechnernamen oder eine Adresse mit Port.
  4. Mit IIS: Das Installationspaket mit GW_MODE=iis erledigt Schritt 1 und 2 und schreibt eine Vorlage iis\web.config in den Programmordner. Sie leitet http auf https um, reicht jede Anfrage an http://127.0.0.1:<GW_PORT> weiter, setzt X-Forwarded-Proto: https und X-Forwarded-Host und erlaubt Adressen bis 8 192 Zeichen. Legen Sie damit eine IIS-Website mit Ihrem Zertifikat an. Die Vorlage braucht die IIS-Module URL Rewrite und Application Request Routing. Erlauben Sie im IIS-Manager unter URL Rewrite > Servervariablen anzeigen die Variablen HTTP_X_FORWARDED_PROTO und HTTP_X_FORWARDED_HOST; ohne diese Freigabe lehnt IIS die Regel ab, die die Kopfzeilen setzt, und antwortet mit 500.

    IIS-Manager, Feature "URL Rewrite" der Website: zwei eingehende Regeln aus der Vorlage, "Wkl.Data.Gateway HTTPS" mit dem Aktionstyp Umleiten und "Wkl.Data.Gateway" mit Umschreiben; rechts unter "Servervariablen verwalten" die Aktion "Servervariablen anzeigen..."

    Die Regeln der Vorlage unter URL Rewrite.

    IIS-Manager, "Zulässige Servervariablen": HTTP_X_FORWARDED_HOST und HTTP_X_FORWARDED_PROTO

    Die beiden freigegebenen Servervariablen.

Ergebnis: Das Audit nennt die Adresse des Aufrufers, nicht die des Proxys; eine Anfrage über https am Proxy gilt als geschützte Verbindung, und die Adressen in den Antworten nennen den Proxy mit https.

Hinweise

  • Windows-Anmeldung nur ohne Bündelung von Verbindungen. Die Windows-Anmeldung gilt für die Verbindung, auf der sie geschah. Ein Proxy, der Anfragen verschiedener Benutzer über eine Verbindung zum Dienst leitet, gäbe dem zweiten die Rechte des ersten. IIS mit Application Request Routing leitet Anfragen über gemeinsame Verbindungen weiter. setup-host --mode iis setzt deshalb AuthMode auf PersonalKey, ohne Windows-Anmeldung; Personen melden sich mit ihrem persönlichen Schlüssel an. Steht Windows dennoch in AuthMode und ist ein vertrauter Proxy eingetragen, warnt der Dienst beim Start im Protokoll.
  • Lesen der Herkunft: Der Dienst liest X-Forwarded-For vom nächsten Glied aus; die erste Adresse, die selbst kein vertrauter Proxy ist, gilt. Einen Eintrag, den der Client vorn selbst einträgt, zählt er damit nicht. Eine unlesbare Angabe macht die Herkunft unbekannt; eine unbekannte Herkunft hebt keine Sperre auf.
  • Kopfzeile Server: Der Dienst selbst nennt seine Server-Software nicht. Hinter IIS fügt IIS Server: Microsoft-IIS/10.0 an. Ab IIS 10 entfernt removeServerHeader="true" am Element requestFiltering der Vorlage diese Kopfzeile: <requestFiltering removeServerHeader="true">. Ältere IIS-Versionen kennen das Attribut nicht und melden mit ihm den Fehler 500.19. Die Vorlage setzt es deshalb nicht.
  • Lange Adressen: IIS und http.sys lassen ohne Vorlage nur 2 KB Abfragezeichenfolge zu; Clients können lange Bedingungen ohnehin im Rumpf schicken, siehe HTTP: Lange Abfragen.

Verwandte Themen

de/wiki/data-conectivity/database-gateway/how-to/run-behind-iis-or-proxy.txt · Zadnja sprememba: uporabnika Wolfgang van der Stille