Rabe: c&p-unfall beseitigt

2012-04-06T12:51:06Z

c&p-unfall beseitigt

← Nächstältere Version		Version vom 6. April 2012, 12:51 Uhr
Zeile 22:		Zeile 22:

	=== ProxyPass auf dem Proxy ===		=== ProxyPass auf dem Proxy ===
	~~Damit bekommen wir auf dem '''Proxy''' die beiden Ports 20080 und 20443, die 1:1 mit den Ports 80 und 443 auf dem '''RealServer''' verbunden sind.~~ Der Zugriff für ProxyPass erfolgt entsprehend, z.B.		Der Zugriff für ProxyPass erfolgt entsprehend, z.B.
	<pre>		<pre>
	<VirtualHost *:80>		<VirtualHost *:80>
Zeile 67:		Zeile 67:
	</pre>		</pre>
	;Achtung: ''StrictHostKeyChecking yes'' verhindert, dass beim ersten Verbindungsaufbau nach example_tunnel nach dem unbekannten Hostkey gefragt wird. Dieser sollte bereits in ~/.ssh/known_hosts enthalten sein (''# StrictHostKeyChecking yes'').		;Achtung: ''StrictHostKeyChecking yes'' verhindert, dass beim ersten Verbindungsaufbau nach example_tunnel nach dem unbekannten Hostkey gefragt wird. Dieser sollte bereits in ~/.ssh/known_hosts enthalten sein (''# StrictHostKeyChecking yes'').


	=== ProxyPass auf dem Proxy ===		=== ProxyPass auf dem Proxy ===

Rabe: /* VirtuallHost */ typo

2012-04-06T10:15:16Z

VirtuallHost: typo

← Nächstältere Version		Version vom 6. April 2012, 10:15 Uhr
Zeile 165:		Zeile 165:


	=== ~~VirtuallHost~~ ===		=== VirtualHost ===
	;VirtualHost Config auf dem ''RealServer''':		;VirtualHost Config auf dem ''RealServer''':
	<pre>		<pre>

Rabe: Variationen

2012-04-06T00:20:08Z

Variationen

← Nächstältere Version		Version vom 6. April 2012, 00:20 Uhr
Zeile 179:		Zeile 179:
	</pre>		</pre>

	== Motivation ==		== Motivation und Variationen ==
	Eine der Hauptmotivationen hinter diesem Setup ist, den eigentlichen RealServer möglichst "im Hintergrund" zu behalten. Für Aussenstehende ist bei sorgfältiger Konfiguration nicht ersichtlich, dass verschiedene VirtualHosts durch andere Server bedient werden.		Eine der Hauptmotivationen hinter diesem Setup ist, den eigentlichen RealServer möglichst "im Hintergrund" zu behalten. Für Aussenstehende ist bei sorgfältiger Konfiguration nicht ersichtlich, dass verschiedene VirtualHosts durch andere Server bedient werden.

Zeile 189:		Zeile 189:
	* einen RealServer hinter mehreren Proxy-Servern betreiben (Fallback ...)		* einen RealServer hinter mehreren Proxy-Servern betreiben (Fallback ...)
	* mehrere RealServer hinter einem Proxy Server betreiben		* mehrere RealServer hinter einem Proxy Server betreiben
			* Kombination von 2 Dynamischen IP-Adressen für Proxy und RealServer (nicht einfach rückverfolgbar)
			* Kaskade aus mehreren Reverse-Proxies, zB CloudServer.org==(via SSH-Tunnel)==>Rootserver.de ==(SSH Tunnel)==>DSL-Anschluss/DynDNS

	[[Kategorie:Anwendungsbeispiel]]		[[Kategorie:Anwendungsbeispiel]]

Rabe: Brain-Dump

2012-04-06T00:14:58Z

Brain-Dump

Neue Seite

Dieser Artikel beschreibt, wie man mit '''Apache''' einen '''Reverse Proxy''' aufbauen kann. Üblicherweise wird das verwendet, um Applikationen, die auf einem nicht direkt vom Internet aus erreichbaren Server laufen auf einem externen Webserver zugreifbar zu machen.

== Anwendungsfall ==
Der Focus dieses Artikels besteht allerdings darin den Anwendungsfall zu beschreiben, bei dem ein Webserver hinter einem NAT-Router mit und ohne PortForwarding betrieben wird.

Das Ziel aller Bemühungen soll in jedem Fall sein: Die Website '''http://www.foo.example.com/''' soll auf der IP-Adresse des '''Proxy''' Servers auflaufen und von dort aus zum '''RealServer''' durchgereicht werden.

Wir gehen in den Beispielen davon aus, dass wir root-Rechte oder vergleichtbare Berechtigungen für die Konfiguration beider Webserver haben. Es muss die Konfiguration verändert werden können, es müssen ggf. Softwarepakete installiert werden, Apache muss neu gestartet werden.

== Begriffe ==
Im folgenden werden die Begriffe '''Proxy''', '''Realserver''', '''öffentliche IP-Adresse''' und '''Website''' wie folgt verwendet:

Der '''Proxy''' ist ein Apache, der auf einem per Internet erreichbaren Server läuft, z.B. auf einem Root-Server. Der Proxy-Server verwendet in den folgenden Beispielen verschiedene Websites auf einer oder verschiedenen '''offiziellen IP-Adressen''', z.B. als ''Namebased Virtual Hosts''. Die DNS-Einträge der jeweiligen Websites zeigen auf die ''offiziellen IP-Adressen''.

Der '''RealServer''' steht irgendwo, wo er nicht ohne weiteres von extern erreichbar ist, etwa hinter einem NAT-Router, Firewall oder ähnlichem. Es werden beide Szenarien betrachtet: Der '''RealServer''' ist über eine (bekannte) IP-Adresse mit Port-Forwarding oder ähnlichem grundsätzlich von extern erreichbar, hat aber eine dynamisch vergebene IP-Adresse, die sich täglich oder häufiger ändert. Die Auflösung der IP-Adresse erfolgt über einen DynDNS-Hostname, z.B. '''example.homeip.net'''.

In einem erweiterten Szenario läuft der '''RealServer''' irgendwo, kann aber mindestens eine SSH-Verbindung Richtung '''Proxy''' aufbauen. Im einfachsten Fall ist es hier ein NAT-Router, der keine statischen Portweiterleitungen nach innen hat oder welche, die nicht selbst verwaltet werden können (z.B. Firmennetz, LAN-Party, ...)

== Fall 1: RealServer per DynDNS von aussen erreichbar ==
Für diesen Fall benötigen wir den DynDNS-Namen, hier example.homeip.net. Es wird angenommen, dass hinter diesem Hostname eine '''öffentliche IP-Adresse''' steckt und dass auf Port 80/tcp entweder direkt oder via Port-Forwarding auf dem NAT-Router direkt der '''RealServer''' angesprochen werden kann.

=== ProxyPass auf dem Proxy ===
Damit bekommen wir auf dem '''Proxy''' die beiden Ports 20080 und 20443, die 1:1 mit den Ports 80 und 443 auf dem '''RealServer''' verbunden sind. Der Zugriff für ProxyPass erfolgt entsprehend, z.B.
<pre>
<VirtualHost *:80>
ServerName www.foo.example.com
ProxyPass / http://example.homeip.net/ connectiontimeout=5 timeout=30
</VirtualHost>
</pre>
(gekürzt auf die wesentlichen Direktiven)

== Fall 2: RealServer nur via SSH-Tunnel erreichbar ==
In diesem Fall ist der RealServer '''irgendwo'''. Der '''RealServer''' verfügt über eine [[Firewall Piercing|wie-auch-immer Methode]], um eine SSH-Verbindung zum '''Proxy''' aufbauen zu können und dass es möglich ist hier PortForwading zu betreiben.

=== SSH-Tunnel ===
Auf dem '''RealServer''' einzurichten:
; ~/.ssh/config:
<pre>
ServerAliveInterval = 15
ServerAliveCountMax = 8

Host example_tunnel
Hostname proxy.example.com
RemoteForward 127.0.0.1:20080 127.0.0.1:80
RemoteForward 127.0.0.1:20443 127.0.0.1:443
BatchMode yes
ConnectionAttempts 5
ConnectTimeout 10
ExitOnForwardFailure yes
KbdInteractiveAuthentication no
PasswordAuthentication no
StrictHostKeyChecking yes

</pre>

Funktional relevant sind hier folgende Zeilen:
<pre>
RemoteForward 127.0.0.1:20080 127.0.0.1:80
RemoteForward 127.0.0.1:20443 127.0.0.1:443
</pre>

; Tunnel aufbauen:
<pre>
ssh -N example_tunnel
</pre>
;Achtung: ''StrictHostKeyChecking yes'' verhindert, dass beim ersten Verbindungsaufbau nach example_tunnel nach dem unbekannten Hostkey gefragt wird. Dieser sollte bereits in ~/.ssh/known_hosts enthalten sein (''# StrictHostKeyChecking yes'').

=== ProxyPass auf dem Proxy ===
Damit bekommen wir auf dem '''Proxy''' die beiden Ports 20080 und 20443, die 1:1 mit den Ports 80 und 443 auf dem '''RealServer''' verbunden sind. Der Zugriff für ProxyPass erfolgt entsprehend, zB
<pre>
<VirtualHost *:80>
ServerName www.foo.example.com
ProxyPass / http://127.0.0.1:20080/ connectiontimeout=5 timeout=30
</VirtualHost>
</pre>
(gekürzt auf die wesentlichen Direktiven)

== Namensbasierte VirtualHosts auf dem RealServer ==
Egal ob der '''RealServer''' via DynDNS oder via SSH-Tunnel erreicht wird: Im Normalfall stellt der '''Proxy''' einen HTTP-Request hin zum konfigurierten '''RealServer''', zum Beispiel '''http://example.homeip.net/'''. Wenn auf dem RealServer verschiedene namensbasierte VirtualHosts eingerichtet werden, können diese im Normalfall nicht erreicht werden, denn hierfür wird bei einer HTTP/1.1 Anfrage der Wert aus dem Host Request-Header verwendet, hier wäre das also '''Host: example.homeip.net''' und nicht '''Host: www.foo.example.com''' oder bei SSH-Tunnel '''Host: 127.0.0.1:<tunnelport>'''.

Im Normalfall landen Anfragen für unbekannte Hostnamen im default-VirtualHost von Apache. Will man mehr als nur eine '''Webseite''' auf einem '''RealServer''' betreiben, muss man sich hier etwas ausdenken, zum Beispiel verschiedene DynDNS-Einträge mit der gleichen IP-Adresse, mehrere CNAMEs auf einen DynDNS-Hostname, bei SSH-Tunnel ggf. mehrere verschiedene Hostnamen in /etc/hosts für 127.0.0.1.

Praktischerweise müssen wir hier keine DNS-Hacks veranstalten, da mod_proxy die [http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#ProxyPreserveHost ProxyPreserveHost Directive] kennt, mit der der ursprüngliche '''Host: www.foo.example.com''' im Request an den '''RealServer''' erhalten bleibt. Der RealServer kann nun also wieder namensbasiert unterscheiden und wir benötigen nicht für jede '''Website''' einen eigenen DNS-Eintrag für den '''RealServer''' (CNAME auf example.homeip.net oder A-Record mit 127.0.0.1 für den SSH-Tunnel).

;VirtualHost auf dem '''Proxy''':
<pre>
# -----------------------
# www.foo.example.com
# -----------------------
<VirtualHost *:80>
ServerAdmin proxy@example.com
ServerName www.foo.example.com

ErrorLog …
CustomLog …
CustomLog …

# bei SSH Tunnel:
# ProxyPass / http://127.0.0.1:20080/ connectiontimeout=5 timeout=30
# ProxyPassReverse / http://127.0.0.1:20080/

# bei DynDNS:
ProxyPass / http://example.homeip.net/ connectiontimeout=5 timeout=30
ProxyPassReverse / http://example.homeip.net/

# in jedem Fall wollen wir, dass der RealServer den ursprünglichen Host-Request Header erhält
ProxyPreserveHost On

</VirtualHost>
</pre>

;VirtualHost auf dem '''RealServer''':
<pre>
<VirtualHost *:80>
ServerAdmin webmaster@example.com

ServerName www.foo.example.com

DocumentRoot /var/www/www.foo.example.com/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/www.foo.example.com/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

…

# Wir wollen, dass unser Apache als Client-IP-Adresse *nicht* den Proxy sieht
# sondern die IP-Adresse des Clients, der sich zum Proxy verbunden hat.
# Das erledigt mod_remote_ip:
#
# http://httpd.apache.org/docs/2.3/mod/mod_remoteip.html
#
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy sigsys.de
RemoteIPTrustedProxy 127.0.0.1
RemoteIPProxiesHeader X-Forwarded-By

…
</VirtualHost>
</pre>

== mod_remoteip ==
Bei allen Reverse-Proxy Szenarien besteht möglicherweise das ''Problem'', dass in den Logfiles des '''RealServers''' nur die IP-Adresse des '''Proxy''' oder gar '''127.0.0.1''' durch den SSH-Tunnel erscheint.

=== mod_remoteip für Apache 2.2 bauen ===
Das Modul mod_remoteip ist leider bei Apache 2.2 noch nicht verfügbar, wurde aber backported. siehe: http://www.serverphorums.com/read.php?10,340545
<pre>
# wget "https://raw.github.com/gist/1042237/078b18a627657151fb90ddc027caad67e7191e89/apache-2.2-mod_remoteip.c"
# mv apache-2.2-mod_remoteip.c mod_remoteip.c
# apxs2 -i -a -c mod_remoteip.c
# /etc/init.d/apache2 restart
</pre>
(getestet unter Debian Squeeze/amd64)

=== VirtuallHost ===
;VirtualHost Config auf dem ''RealServer''':
<pre>
<VirtualHost *:80>
ServerName www.foo.example.com

RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy proxy.example.com
RemoteIPTrustedProxy 127.0.0.1
RemoteIPProxiesHeader X-Forwarded-By

</VirtualHost>
</pre>

== Motivation ==
Eine der Hauptmotivationen hinter diesem Setup ist, den eigentlichen RealServer möglichst "im Hintergrund" zu behalten. Für Aussenstehende ist bei sorgfältiger Konfiguration nicht ersichtlich, dass verschiedene VirtualHosts durch andere Server bedient werden.

* RealServer unsichtbar hinter einer dynamischen IP betreiben
* IPv4-RealServer per IPv6 erreichbar machen
* IPv6-RealServer via IPv4 erreichbar machen
* RealServer via Mobilfunk anbinden und hinter einem Rootserver verstecken
* RealServer hinter einer komplexeren Firewall/Proxy-Kaskade betreiben, bei der als Minimalvoraussetzung eine SSH-Session nach außen aufgemacht werden kann, siehe auch [[Firewall Piercing]].
* einen RealServer hinter mehreren Proxy-Servern betreiben (Fallback ...)
* mehrere RealServer hinter einem Proxy Server betreiben

[[Kategorie:Anwendungsbeispiel]]

Apache Reverse Proxy - Versionsgeschichte

Rabe: c&p-unfall beseitigt

Rabe: /* VirtuallHost */ typo

Rabe: Variationen

Rabe: Brain-Dump