Änderungen von Dokument Betrieb hinter Proxy/Load-Balancer o.ä.

Zusammenfassung

• Seiteneigenschaften (1 geändert, 0 hinzugefügt, 0 gelöscht)

Details

Seiteneigenschaften

Inhalt

...	...	@@ -1,5 +3,3 @@
1		-{{content/}}
2		-
3	3	Sollte der Anwendungsserver (z.B. Apache Tomcat), auf welchem {{formcycle/}} installiert ist, hinter einem weiteren Server wie z.B. einem Revers-Proxy, einem Load-Balancer oder ähnlichem betrieben werden, ist zu beachten, dass die Informationen eines Aufrufs unverändert an diesen übermittelt werden. Konkret bedeutet dies, dass sowohl der //Host//-Header als auch das verwendete Protokoll durch die zwischengeschalteten Server unverändert weitergereicht werden müssen. In den meisten Standardkonfigurationen ist dies jedoch nicht der Fall, da die Anfragen vom zwischengeschalteten Server entgegengenommen und als neue Anfrage an den Anwendungsserver gestellt werden.
4	4
5	5	{{figure image="proxy_de.jpg"}}
...	...	@@ -84,49 +84,20 @@
84	84
85	85	== Verwenden von //X-Forwarded// Headern für unverschlüsselte Kommunikation ==
86	86
87		-Wenn der zwischengeschaltete Server das Senden von //X-Forwarded// Headern unterstützt und der {{formcycle/}} hostetende Servlet-Container (z.B. Tomcat) diese Header auswerten kann, ist es möglich die Kommunikation von zwischengeschaltetem Server und {{formcycle/}} auch über ein anderes Protokoll zu konfigurieren. Sowohl beim vorgeschalteten Server als auch beim Servlet-Container muss das Verwenden dieser Header konfiguriert sein. Nähere Informationen zur Konfiguration finden sich in der Dokumentation des jeweiligen Produktes. Bei dieser Variante ist es nicht mehr notwendig im Tomcat Zertifikate zu hinterlegen. Es folgen hier zwei Konfigurationsbespiele für //Apache //und //nginx//.
	85	+Wenn der zwischengeschaltete Server das Senden von //X-Forwarded// Headern unterstützt und der {{formcycle/}} hostetende Servlet-Container diese Header auswerten kann, kann die Kommunikation zwischen zwischengeschaltetem Server und {{formcycle/}} auch über ein anderes Protokoll erfolgen. Sowohl beim vorgeschalteten Server als auch beim Servlet-Container muss das Verwenden dieser Header konfiguriert sein. Nähere Informationen zur Konfiguration finden sich in der Dokumentation des jeweiligen Produktes.
88	88
89	89	=== Konfigurationsbeispiele ===
90	90
91		-Im //Apache// kann das Mitsenden der entsprechenden Header in den für den Reverse-Proxy zuständigen //VirtualHosts// beispielsweise wie folgt konfiguriert werden:
	89	+Im //Apache// kann das Mitsenden der entsprechenden Header in den für den Reverse-Proxy zuständigen //VirtualHost//s beispielsweise wie folgt konfiguriert werden:
92	92
93	93	{{code language="none"}}
94		-<VirtualHost www.example.com:80>
95		- ...
96		- RequestHeader set X-Forwarded-Port "80"
97		- RequestHeader set X-Forwarded-Proto "http"
98		- ...
99		- # Weiterleitung über HTTP
100		- ProxyPass / http://192.168.0.1/
101		- ProxyPassReverse / http://192.168.0.1/
102		- ...
103		- # Weiterleitung der WebSocket-Verbindung über WS
104		- RewriteEngine on
105		- RewriteCond %{HTTP:Upgrade} websocket [NC]
106		- RewriteCond %{HTTP:Connection} upgrade [NC]
107		- RewriteRule ^/?(.*) "ws://192.168.0.1:80/$1" [P,L]
108		-</VirtualHost>
	92	+//HTTP
	93	+RequestHeader set X-Forwarded-Port "80"
	94	+RequestHeader set X-Forwarded-Proto "http"
109	109
110		-<IfModule mod_ssl.c>
111		- <VirtualHost www.example.com:443>
112		- ...
113		- SSLEngine on
114		- SSLProxyEngine On
115		- ...
116		- RequestHeader set X-Forwarded-Port "443"
117		- RequestHeader set X-Forwarded-Proto "https"
118		- ...
119		- # Weiterleitung über HTTPS
120		- ProxyPass / http://192.168.0.1/
121		- ProxyPassReverse / http://192.168.0.1/
122		- ...
123		- # Weiterleitung der gesicherten WebSocket-Verbindung über WSS
124		- RewriteEngine on
125		- RewriteCond %{HTTP:Upgrade} websocket [NC]
126		- RewriteCond %{HTTP:Connection} upgrade [NC]
127		- RewriteRule ^/?(.*) "wss://192.168.0.1:443/$1" [P,L]
128		- </VirtualHost>
129		-</IfModule>
	96	+//HTTPS
	97	+RequestHeader set X-Forwarded-Port "443"
	98	+RequestHeader set X-Forwarded-Proto "https"
130	130	{{/code}}
131	131
132	132	Bei //nginx// kann für das Mitsenden der entsprechenden Header in der für den Reverse-Proxy zuständigen Sektion beispielsweise folgende Konfiguration verwendet werden:
...	...	@@ -150,7 +150,7 @@
150	150	{{code language="none"}}
151	151	<Engine......
152	152	<Valve className="org.apache.catalina.valves.RemoteIpValve"
153		- internalProxies="<optionale Angabe, siehe unten>"
	122	+ internalProxies="<IP's der vertrauenswürdigen Proxy-Server>"
154	154	remoteIpHeader="x-forwarded-for"
155	155	protocolHeader="x-forwarded-proto"
156	156	protocolHeaderHttpsValue="https" />
...	...	@@ -157,4 +157,4 @@
157	157	</Engine>
158	158	{{/code}}
159	159
160		-Der Default für den Parameter [[//internalProxies //>>https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/filters/RemoteIpFilter.html||rel="noopener noreferrer" target="_blank"]]ist //10/8, 192.168/16, 169.254/16, 127/8, 172.16/12, and 0:0:0:0:0:0:0:1//. Falls die IP(s) des vertrauenswürdigen Proxy-Server nicht damit abgedeckt sind, müssenn diese in Form eines Regulären Ausdrucks angegeben werden. Erwartet wird hier eine oder mehrere IP-Adressen (z.B.: 192\.168\.0\.10|192\.168\.0\.11) oder ein IP-Adressbereich, welcher mittels regulären Ausdrucks (z.B.: 169\.254\.\d{1,3}\.\d{1,3}) definiert werden kann.
	129	+**Hinweis:** Sollte die Konfiguration der //X-Forwarded//-Header nicht greifen, so ist es unter Umständen notwendig in der Eigenschaft //internalProxies// die IP's der vertrauenswürdigen Proxy-Server zu konfigurieren. Erwartet wird hier eine oder mehrere IP-Adressen (z.B.: 192\.168\.0\.10|192\.168\.0\.11) oder ein IP-Adressbereich, welcher mittels regulären Ausdrucks (z.B.: 169\.254\.\d{1,3}\.\d{1,3}) definiert werden kann.