Debian Apache Virtualhost und Proxy: Unterschied zwischen den Versionen

Aus Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(13 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=Allgemeines=
==Allgemeines==
Im Folgenden wird erklärt, wie mit Hilfe von Virtualhosts mehrere Websites z.B. www.domain.org, wiki.domain.org, ox.domain.org als Subdomains einer Domain domain.org gehosted werden kann.
Im Folgenden wird erklärt, wie mit Hilfe von Virtualhosts mehrere Websites z.B. www.domain.org, wiki.domain.org, ox.domain.org als Subdomains einer Domain domain.org gehosted werden kann. Für diese Konfiguration empfiehlt sich ein sog. Wildcard SSL-Zertifikat ([[Debian_OpenSSL#Optional: Wildcard Zertifikat|→ siehe auch hier]]), das für alle Subdomains von domain.org Gültigkeit hat. Dadurch wird im Client vermieden, dass für jede Subdomain eine Warnung ausgegeben wird, dass Zertifikat und besuchte Domain nicht übereinstimmen.


Mit dem sog. Apache Reverse Proxy in Verbindung mit einem Virtualhost können andere Websites oder Geräte virtuell eingebunden werden. So ist es z.B. möglich, den Webserver eines Solarloggers, die Webseite der AVR-Steckdosenleiste, oder die Konfigurationsseite der Fritzbox  als Subdomain - z.B. http://solarlog.domain.org zu erreichen. Für einen Surfer aus dem Internet sieht es so aus, als ob die Solarlog-Seiten virtuell auf dem "normalen" Apache Server liegen.
Mit dem sog. Apache Reverse Proxy in Verbindung mit einem Virtualhost können andere Websites oder Geräte virtuell eingebunden werden. So ist es z.B. möglich, den Webserver eines Solarloggers, die Webseite der AVR-Steckdosenleiste, oder die Konfigurationsseite der Fritzbox  als Subdomain - z.B. http://solarlog.domain.org zu erreichen. Für einen Surfer aus dem Internet sieht es so aus, als ob die Solarlog-Seiten virtuell auf dem "normalen" Apache Server liegen.




=Anlegen eines Virtualhost=
==Anlegen eines Virtualhost==
Die Virtualhost-Definitionen liegen im Verzeichnis /etc/apache2/sites-enabled. Der Filename der Virtualhost-Definition kann beliebig gewählt werden. Es ist auch möglich, mehrere Virtualhosts in einer Datei abzulegen. Allerdings empfiehlt es sich der Übersichtlichkeit halber nur einen Virtualhost pro File abzulegen und aussagekräftige Filenamen zu verwenden. Der Filename muss die Dateiendung .conf haben, damit das File von Apache2 verwendet wird.
Die Virtualhost-Definitionen liegen im Verzeichnis /etc/apache2/sites-enabled. Der Filename der Virtualhost-Definition kann beliebig gewählt werden. Es ist auch möglich, mehrere Virtualhosts in einer Datei abzulegen. Allerdings empfiehlt es sich der Übersichtlichkeit halber nur einen Virtualhost pro File abzulegen und aussagekräftige Filenamen zu verwenden. Der Filename muss die Dateiendung .conf haben, damit das File von Apache2 verwendet wird.


Zeile 22: Zeile 22:




==HTTP==
===HTTP===
Ein einfacher Virtualhost für HTTP (Wiki_http.conf) hat z.B. folgenden Aufbau:
Ein einfacher Virtualhost für HTTP (Wiki_http.conf) hat z.B. folgenden Aufbau:
  <VirtualHost *:80>
  <VirtualHost *:80>
Zeile 31: Zeile 31:
  /etc/init.d/apache2 restart
  /etc/init.d/apache2 restart


==HTTPS==
===HTTPS===
Für HTTPS sind weitere Statements hinschtlich SSL erforderlich. Z.B. obiges Beispiel für https (wiki_https.conf):
Für HTTPS sind weitere Statements hinschtlich SSL erforderlich. Z.B. obiges Beispiel für https (wiki_https.conf):
  <VirtualHost *:443>
  <VirtualHost *:443>
   DocumentRoot /var/lib/mediawiki
   DocumentRoot /var/lib/mediawiki
   ServerName wiki.domain.org
   ServerName wiki.domain.org
   '''SSLKeyFile''' /etc/ssl/private/ssl-cert-snakeoil.key
   '''SSLCertificateKeyFile /etc/ssl/CA/key/wilcard-key.pem'''
   '''SSLCertificateFile''' /etc/ssl/certs/ssl-cert-snakeoil.pem
   '''SSLCertificateFile /etc/ssl/CA/certs/wildcard-cert.pem'''
   '''SSLEngine on'''
   '''SSLEngine on'''
  </VirtualHost>
  </VirtualHost>
Alternative: Verwendung von kombiniertem Zertifikat und Keyfile:
<VirtualHost *:443>
  DocumentRoot /var/lib/mediawiki
  ServerName wiki.domain.org
  '''SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem'''
  '''SSLEngine on'''
</VirtualHost>
Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird:
Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird:
  /etc/init.d/apache2 restart
  /etc/init.d/apache2 restart




=Reverse Proxy=
==Reverse Proxy==
Mit einem Reverse Proxy können andere Websites, die auch auf ganz anderen Servern/Geräten liegen in einen Virtualhost verpackt werden, sodass für einen Surfer überhaupt nicht erkennbar ist, dass die Zielseite evtl. auf einem ganz anderen Gerät liegt. Im Gegensatz zu einem Forward Proxy, der im Webbrowser konfiguriert werden muss, wird die komplette Konfiguration des Reverse Proxy komplett auf dem Server vorgenommen.  
Mit einem Reverse Proxy können andere Websites, die auch auf ganz anderen Servern/Geräten liegen in einen Virtualhost verpackt werden, sodass für einen Surfer überhaupt nicht erkennbar ist, dass die Zielseite evtl. auf einem ganz anderen Gerät liegt. Im Gegensatz zu einem Forward Proxy, der im Webbrowser konfiguriert werden muss, wird die komplette Konfiguration des Reverse Proxy komplett auf dem Server vorgenommen.  
===Generell===
====Apache2.2====
Apache Proxy Modul:
apt-get install libapache2-mod-proxy-html
a2enmod proxy
a2enmod proxy_html
a2enmod proxy_http
/etc/init.d/apache2 restart


Allgemeiner Aufbau eines Reverse Proxy Virtualhost Files:
Allgemeiner Aufbau eines Reverse Proxy Virtualhost Files:
Zeile 55: Zeile 72:
       Allow from all
       Allow from all
   </Proxy>
   </Proxy>
  ProxyPass / http://Ziel_IP:Zielport/
   <Location />
   <Location />
      ProxyPass        http://Ziel_IP:Zielport/
       ProxyPassReverse /  
       ProxyPassReverse http://Ziel_IP:Zielport/  
   </Location>
   </Location>
   ...
   ...
  </VirtualHost>
  </VirtualHost>


{{Achtung|Es muss unbedingt das Statement "ProxyRequests Off" vorhanden sein, da ansonsten der Server als offener Proxy von überall ("Allow from all") im Internet verwendet werden könnte (Forwarding Proxy). Nachdem hier kein Forwarding Proxy, der nur lokal freigegeben werden sollte, sondern ein Reverse Proxy eingerichtet werden soll, der von überall im Internet erreichbar sein muss, ist dieses Statement hier essenziell}}
====Apache2.4====
Apache Proxy Modul und Abhängigkeiten:
apt-get install libapache2-mod-proxy-html
a2enmod proxy
a2enmod proxy_html
a2enmod proxy_http
a2enmod xml2enc
/etc/init.d/apache2 restart
Allgemeiner Aufbau eines Reverse Proxy Virtualhost Files:
<VirtualHost *:'''''Port'''''>
  ServerName '''''subdomain.domain.org'''''
  ProxyRequests Off
  <Proxy *>
      Require all granted
  </Proxy>
  ProxyPass / http://Ziel_IP:Zielport/
  <Location />
      ProxyPassReverse /
  </Location>
  ...
</VirtualHost>


{{Achtung|Es muss unbedingt das Statement "ProxyRequests Off" vorhanden sein, da ansonsten der Server als offener Proxy von überall ("Allow from all") im Internet verwendet werden könnte (Forwarding Proxy). Nachdem hier kein Forwarding Proxy, der nur lokal freigegeben werden sollte, sondern ein Reverse Proxy eingerichtet werden soll, der von überall im Internet erreichbar sein muss, ist dieses Statement hier essenziell}}
{{Achtung|Es muss unbedingt das Statement "ProxyRequests Off" vorhanden sein, da ansonsten der Server als offener Proxy von überall ("Allow from all") im Internet verwendet werden könnte (Forwarding Proxy). Nachdem hier kein Forwarding Proxy, der nur lokal freigegeben werden sollte, sondern ein Reverse Proxy eingerichtet werden soll, der von überall im Internet erreichbar sein muss, ist dieses Statement hier essenziell}}


===HTTP Reverse Proxy===
Als Beispiel soll hier ein Solarlogger mit der internen IP-Adresse 192.168.0.222 (Port 80) unter http://solarlog.domain.org erreichbar sein.


==HTTP Reverse Proxy==
====Apache2.2====
Als Beispiel soll hier ein Solarlogger mit der internen IP-Adresse 192.168.0.222 (Port 80) unter http://solarlog.domain.org erreichbar sein.
  vi /etc/apache2/sites-enabled/solarlog_http.conf
  vi /etc/apache2/sites-enabled/solarlog_http.conf
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert:
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert:
Zeile 77: Zeile 119:
       Allow from all
       Allow from all
     </Proxy>
     </Proxy>
    ProxyPass / http://192.168.0.222:80/
     <Location />
     <Location />
      ProxyPass        http://192.168.0.222:80/
       ProxyPassReverse /  
       ProxyPassReverse http://192.168.0.222:80/  
     </Location>
     </Location>
  </VirtualHost>
  </VirtualHost>
Zeile 86: Zeile 128:




==HTTPS Reverse Proxy für HTTP Zielserver==
====Apache2.4====
vi /etc/apache2/sites-enabled/solarlog_http.conf
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert:
<VirtualHost *:80>
    ServerName solarlog.domain.org
    ProxyRequests Off
    <Proxy *>
      Require all granted
    </Proxy>
    ProxyPass / http://192.168.0.222:80/
    <Location />
      ProxyPassReverse /
    </Location>
</VirtualHost>
Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird:
/etc/init.d/apache2 restart
 
 
===HTTPS Reverse Proxy fuer HTTP Zielserver===
Mit Hilfe eines Reverse Proxies ist es sogar möglich, einen Webserver, der nur HTTP beherrscht, hinter einem SSL-fähigen Apache2 zu betreiben. Die Übertragung der Webseite zwischen Webbrowser und Apache2 (Reverse Proxy) ist dann per SSL-Verschlüsselung gesichert. Der Weg zwischen Apache2 und Zielserver erfolgt dann per HTTP, was aber kein Problem darstellen sollte, wenn sich der Zielserver im selben LAN befindet.
Mit Hilfe eines Reverse Proxies ist es sogar möglich, einen Webserver, der nur HTTP beherrscht, hinter einem SSL-fähigen Apache2 zu betreiben. Die Übertragung der Webseite zwischen Webbrowser und Apache2 (Reverse Proxy) ist dann per SSL-Verschlüsselung gesichert. Der Weg zwischen Apache2 und Zielserver erfolgt dann per HTTP, was aber kein Problem darstellen sollte, wenn sich der Zielserver im selben LAN befindet.


====Apache2.2====
Obiges Beispiel mit zusätzlicher SSL-Verschlüsselung:
Obiges Beispiel mit zusätzlicher SSL-Verschlüsselung:
vi /etc/apache2/sites-enabled/solarlog_https.conf
vi /etc/apache2/sites-enabled/solarlog_https.conf
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert:
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert:
  <VirtualHost *:80>
  <VirtualHost *:443>
     ServerName solarlog.domain.org
     ServerName solarlog.domain.org
     ProxyRequests Off
     ProxyRequests Off
Zeile 99: Zeile 161:
       Allow from all
       Allow from all
     </Proxy>
     </Proxy>
    ProxyPass / http://192.168.0.222:80/
    <Location />
      ProxyPassReverse /
    </Location>
    SSLEngine on
    SSLProxyEngine On
    SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
</VirtualHost>
Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird:
/etc/init.d/apache2 restart
====Apache2.4====
Obiges Beispiel mit zusätzlicher SSL-Verschlüsselung:
vi /etc/apache2/sites-enabled/solarlog_https.conf
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert:
<VirtualHost *:443>
    ServerName solarlog.domain.org
    ProxyRequests Off
    <Proxy *>
      Require all granted
    </Proxy>
    ProxyPass / http://192.168.0.222:80/
     <Location />
     <Location />
      ProxyPass        http://192.168.0.222:80/
       ProxyPassReverse /  
       ProxyPassReverse http://192.168.0.222:80/  
     </Location>
     </Location>
     SSLEngine on
     SSLEngine on
     SSLProxyEngine On
     SSLProxyEngine On
     SSLKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
     SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
    SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
  </VirtualHost>
  </VirtualHost>
Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird:
Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird:
  /etc/init.d/apache2 restart
  /etc/init.d/apache2 restart


==HTTPS Reverse Proxy mit Authorisierung==
 
===HTTPS Reverse Proxy mit Authorisierung===
Aufbauend auf dem HTTPS Reverse Proxy soll zusätzlich noch eine Authorisierung eingefügt werden, falls der Zielserver keine Authorisierung von Nutzern ermöglicht. Auf diese Weise können nur erlaubte Nutzer die Webseite benutzen und zusätzlich ist die Übertragung per SSL geschützt.
Aufbauend auf dem HTTPS Reverse Proxy soll zusätzlich noch eine Authorisierung eingefügt werden, falls der Zielserver keine Authorisierung von Nutzern ermöglicht. Auf diese Weise können nur erlaubte Nutzer die Webseite benutzen und zusätzlich ist die Übertragung per SSL geschützt.


====Apache2.2====
Obiges Beispiel mit zusätzlicher Authorisierung:
Obiges Beispiel mit zusätzlicher Authorisierung:
vi /etc/apache2/sites-enabled/solarlog_https.conf
vi /etc/apache2/sites-enabled/solarlog_https.conf
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert (Zusätzliche Parameter in Fett):
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert (Zusätzliche Parameter in Fett):
  <VirtualHost *:80>
  <VirtualHost *:443>
     ServerName solarlog.domain.org
     ServerName solarlog.domain.org
     ProxyRequests Off
     ProxyRequests Off
Zeile 124: Zeile 208:
       Allow from all
       Allow from all
     </Proxy>
     </Proxy>
    ProxyPass / http://192.168.0.222:80/
    <Location />
      ProxyPassReverse /
      '''AuthType Basic'''
      '''AuthName "Solarlog erfordert eine User Authentifzierung"'''
      '''AuthUserFile /var/apache_pwd/passwd.solarlog'''
      '''Require valid-user'''
    </Location>
    SSLEngine on
    SSLProxyEngine On
    SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
</VirtualHost>
'''AuthName''' bestimmt den Text der Aufforderung zur Eingabe von Username und Passwort
'''AuthUserFile''' legt das File mit Username/Passwort fest, das verwendet werden soll.
Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird:
/etc/init.d/apache2 restart
====Apache2.4====
Obiges Beispiel mit zusätzlicher Authorisierung:
vi /etc/apache2/sites-enabled/solarlog_https.conf
Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert (Zusätzliche Parameter in Fett):
<VirtualHost *:443>
    ServerName solarlog.domain.org
    ProxyRequests Off
    <Proxy *>
      Require all granted
    </Proxy>
    ProxyPass / http://192.168.0.222:80/
     <Location />
     <Location />
      ProxyPass        http://192.168.0.222:80/
       ProxyPassReverse /
       ProxyPassReverse http://192.168.0.222:80/
       '''AuthType Basic'''
       '''AuthType Basic'''
       '''AuthName Solarlog erfordert eine User Authentifzierung'''
       '''AuthName "Solarlog erfordert eine User Authentifzierung"'''
       '''AuthUserFile /var/apache_pwd/passwd.solarlog'''
       '''AuthUserFile /var/apache_pwd/passwd.solarlog'''
       '''Require valid-user'''  
       '''Require valid-user'''  
Zeile 134: Zeile 246:
     SSLEngine on
     SSLEngine on
     SSLProxyEngine On
     SSLProxyEngine On
     SSLKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
     SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
    SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
  </VirtualHost>
  </VirtualHost>
'''AuthName''' bestimmt den Text der Aufforderung zur Eingabe von Username und Passwort
'''AuthName''' bestimmt den Text der Aufforderung zur Eingabe von Username und Passwort

Aktuelle Version vom 15. Mai 2015, 11:59 Uhr

Allgemeines

Im Folgenden wird erklärt, wie mit Hilfe von Virtualhosts mehrere Websites z.B. www.domain.org, wiki.domain.org, ox.domain.org als Subdomains einer Domain domain.org gehosted werden kann. Für diese Konfiguration empfiehlt sich ein sog. Wildcard SSL-Zertifikat (→ siehe auch hier), das für alle Subdomains von domain.org Gültigkeit hat. Dadurch wird im Client vermieden, dass für jede Subdomain eine Warnung ausgegeben wird, dass Zertifikat und besuchte Domain nicht übereinstimmen.

Mit dem sog. Apache Reverse Proxy in Verbindung mit einem Virtualhost können andere Websites oder Geräte virtuell eingebunden werden. So ist es z.B. möglich, den Webserver eines Solarloggers, die Webseite der AVR-Steckdosenleiste, oder die Konfigurationsseite der Fritzbox als Subdomain - z.B. http://solarlog.domain.org zu erreichen. Für einen Surfer aus dem Internet sieht es so aus, als ob die Solarlog-Seiten virtuell auf dem "normalen" Apache Server liegen.


Anlegen eines Virtualhost

Die Virtualhost-Definitionen liegen im Verzeichnis /etc/apache2/sites-enabled. Der Filename der Virtualhost-Definition kann beliebig gewählt werden. Es ist auch möglich, mehrere Virtualhosts in einer Datei abzulegen. Allerdings empfiehlt es sich der Übersichtlichkeit halber nur einen Virtualhost pro File abzulegen und aussagekräftige Filenamen zu verwenden. Der Filename muss die Dateiendung .conf haben, damit das File von Apache2 verwendet wird.

Grundsätzlicher Aufbau einer Virtualhost Definition: 

<VirtualHost *:Port>
  DocumentRoot /Pfad
  ServerName subdomain.domain.org
  ...
</VirtualHost>

Port: Port für den der Virtualhost gelten soll. Normalerweise: 80 für HTTP und 443 für HTTPS. Pfad: Pfad unter dem die Webseite im Linux Dateisystem erreichbar ist. subdomain.domain.org: Subdomain (beliebig wählbar) und domain, unter der der Virtualhost erreichbar sein soll. Z.B. wiki.domain.org. Für HTTPS sind weitere Angaben bzgl. SSL-Zertifikat und -Key erforderlich. Details siehe HTTPS-Abschnitt. Es sind zahlreiche weitere Statements (z.B. <Directory> und <Location>) möglich, die im Rahmen dieser Anleitung nicht näher erläutert werden können.


HTTP

Ein einfacher Virtualhost für HTTP (Wiki_http.conf) hat z.B. folgenden Aufbau: 

<VirtualHost *:80>
  DocumentRoot /var/lib/mediawiki
  ServerName wiki.domain.org
</VirtualHost>

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart

HTTPS

Für HTTPS sind weitere Statements hinschtlich SSL erforderlich. Z.B. obiges Beispiel für https (wiki_https.conf): 

<VirtualHost *:443>
  DocumentRoot /var/lib/mediawiki
  ServerName wiki.domain.org
  SSLCertificateKeyFile /etc/ssl/CA/key/wilcard-key.pem
  SSLCertificateFile /etc/ssl/CA/certs/wildcard-cert.pem
  SSLEngine on
</VirtualHost>

Alternative: Verwendung von kombiniertem Zertifikat und Keyfile: 

<VirtualHost *:443>
  DocumentRoot /var/lib/mediawiki
  ServerName wiki.domain.org
  SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
  SSLEngine on
</VirtualHost>

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart


Reverse Proxy

Mit einem Reverse Proxy können andere Websites, die auch auf ganz anderen Servern/Geräten liegen in einen Virtualhost verpackt werden, sodass für einen Surfer überhaupt nicht erkennbar ist, dass die Zielseite evtl. auf einem ganz anderen Gerät liegt. Im Gegensatz zu einem Forward Proxy, der im Webbrowser konfiguriert werden muss, wird die komplette Konfiguration des Reverse Proxy komplett auf dem Server vorgenommen.

Generell

Apache2.2

Apache Proxy Modul: 

apt-get install libapache2-mod-proxy-html
a2enmod proxy
a2enmod proxy_html
a2enmod proxy_http
/etc/init.d/apache2 restart

Allgemeiner Aufbau eines Reverse Proxy Virtualhost Files: 

<VirtualHost *:Port>
  ServerName subdomain.domain.org
  ProxyRequests Off
  <Proxy *>
      Order allow,deny
      Allow from all
  </Proxy>
  ProxyPass / http://Ziel_IP:Zielport/
  <Location />
     ProxyPassReverse / 
  </Location>
  ...
</VirtualHost>
Warning.png Achtung:
Es muss unbedingt das Statement "ProxyRequests Off" vorhanden sein, da ansonsten der Server als offener Proxy von überall ("Allow from all") im Internet verwendet werden könnte (Forwarding Proxy). Nachdem hier kein Forwarding Proxy, der nur lokal freigegeben werden sollte, sondern ein Reverse Proxy eingerichtet werden soll, der von überall im Internet erreichbar sein muss, ist dieses Statement hier essenziell

Apache2.4

Apache Proxy Modul und Abhängigkeiten: 

apt-get install libapache2-mod-proxy-html
a2enmod proxy
a2enmod proxy_html
a2enmod proxy_http
a2enmod xml2enc
/etc/init.d/apache2 restart

Allgemeiner Aufbau eines Reverse Proxy Virtualhost Files: 

<VirtualHost *:Port>
  ServerName subdomain.domain.org
  ProxyRequests Off
  <Proxy *>
      Require all granted
  </Proxy>
  ProxyPass / http://Ziel_IP:Zielport/
  <Location />
     ProxyPassReverse / 
  </Location>
  ...
</VirtualHost>
Warning.png Achtung:
Es muss unbedingt das Statement "ProxyRequests Off" vorhanden sein, da ansonsten der Server als offener Proxy von überall ("Allow from all") im Internet verwendet werden könnte (Forwarding Proxy). Nachdem hier kein Forwarding Proxy, der nur lokal freigegeben werden sollte, sondern ein Reverse Proxy eingerichtet werden soll, der von überall im Internet erreichbar sein muss, ist dieses Statement hier essenziell

HTTP Reverse Proxy

Als Beispiel soll hier ein Solarlogger mit der internen IP-Adresse 192.168.0.222 (Port 80) unter http://solarlog.domain.org erreichbar sein.

Apache2.2

vi /etc/apache2/sites-enabled/solarlog_http.conf

Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert: 

<VirtualHost *:80>
   ServerName solarlog.domain.org
   ProxyRequests Off
   <Proxy *>
      Order allow,deny
      Allow from all
   </Proxy>
   ProxyPass / http://192.168.0.222:80/
   <Location />
      ProxyPassReverse / 
   </Location>
</VirtualHost>

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart


Apache2.4

vi /etc/apache2/sites-enabled/solarlog_http.conf

Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert: 

<VirtualHost *:80>
   ServerName solarlog.domain.org
   ProxyRequests Off
   <Proxy *>
      Require all granted
   </Proxy>
   ProxyPass / http://192.168.0.222:80/
   <Location />
      ProxyPassReverse / 
   </Location>
</VirtualHost>

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart


HTTPS Reverse Proxy fuer HTTP Zielserver

Mit Hilfe eines Reverse Proxies ist es sogar möglich, einen Webserver, der nur HTTP beherrscht, hinter einem SSL-fähigen Apache2 zu betreiben. Die Übertragung der Webseite zwischen Webbrowser und Apache2 (Reverse Proxy) ist dann per SSL-Verschlüsselung gesichert. Der Weg zwischen Apache2 und Zielserver erfolgt dann per HTTP, was aber kein Problem darstellen sollte, wenn sich der Zielserver im selben LAN befindet.


Apache2.2

Obiges Beispiel mit zusätzlicher SSL-Verschlüsselung: 

vi /etc/apache2/sites-enabled/solarlog_https.conf

Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert: 

<VirtualHost *:443>
   ServerName solarlog.domain.org
   ProxyRequests Off
   <Proxy *>
      Order allow,deny
      Allow from all
   </Proxy>
   ProxyPass / http://192.168.0.222:80/
   <Location />
      ProxyPassReverse / 
   </Location>
   SSLEngine on
   SSLProxyEngine On
   SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
</VirtualHost>

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart

Apache2.4

Obiges Beispiel mit zusätzlicher SSL-Verschlüsselung: 

vi /etc/apache2/sites-enabled/solarlog_https.conf

Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert: 

<VirtualHost *:443>
   ServerName solarlog.domain.org
   ProxyRequests Off
   <Proxy *>
      Require all granted
   </Proxy>
   ProxyPass / http://192.168.0.222:80/
   <Location />
      ProxyPassReverse / 
   </Location>
   SSLEngine on
   SSLProxyEngine On
   SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
</VirtualHost>

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart


HTTPS Reverse Proxy mit Authorisierung

Aufbauend auf dem HTTPS Reverse Proxy soll zusätzlich noch eine Authorisierung eingefügt werden, falls der Zielserver keine Authorisierung von Nutzern ermöglicht. Auf diese Weise können nur erlaubte Nutzer die Webseite benutzen und zusätzlich ist die Übertragung per SSL geschützt.

Apache2.2

Obiges Beispiel mit zusätzlicher Authorisierung: 

vi /etc/apache2/sites-enabled/solarlog_https.conf

Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert (Zusätzliche Parameter in Fett): 

<VirtualHost *:443>
   ServerName solarlog.domain.org
   ProxyRequests Off
   <Proxy *>
      Order allow,deny
      Allow from all
   </Proxy>
   ProxyPass / http://192.168.0.222:80/
   <Location />
      ProxyPassReverse /
      AuthType Basic
      AuthName "Solarlog erfordert eine User Authentifzierung"
      AuthUserFile /var/apache_pwd/passwd.solarlog
      Require valid-user 
   </Location>
   SSLEngine on
   SSLProxyEngine On
   SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
</VirtualHost>

AuthName bestimmt den Text der Aufforderung zur Eingabe von Username und Passwort AuthUserFile legt das File mit Username/Passwort fest, das verwendet werden soll.

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart

Apache2.4

Obiges Beispiel mit zusätzlicher Authorisierung: 

vi /etc/apache2/sites-enabled/solarlog_https.conf

Folgende Zeilen definieren einen Virtualhost, der als reverse Proxy fungiert (Zusätzliche Parameter in Fett): 

<VirtualHost *:443>
   ServerName solarlog.domain.org
   ProxyRequests Off
   <Proxy *>
      Require all granted
   </Proxy>
   ProxyPass / http://192.168.0.222:80/
   <Location />
      ProxyPassReverse /
      AuthType Basic
      AuthName "Solarlog erfordert eine User Authentifzierung"
      AuthUserFile /var/apache_pwd/passwd.solarlog
      Require valid-user 
   </Location>
   SSLEngine on
   SSLProxyEngine On
   SSLCertificateFile /etc/ssl/CA/certs/wildcard.pem
</VirtualHost>

AuthName bestimmt den Text der Aufforderung zur Eingabe von Username und Passwort AuthUserFile legt das File mit Username/Passwort fest, das verwendet werden soll.

Nach Änderungen an den Virtualhost-Definitionen muss Apache2 neu gestartet werden, damit die Änderung übernommen wird: 

/etc/init.d/apache2 restart

Directory für User/Passwordfile anlegen: 

mkdir /var/apache_pwd
chown www-data:www-data /var/apache_pwd

User test anlegen (für obiges Solarlog-Beispiel): 

htpasswd -c Apache_PWD_File User
htpasswd -c /var/apache_pwd/passwd.solarlog test

Es können auf diese Art und Weise beliebig viele User angelegt werden. Mit folgendem Befehl kann ein User wieder gelöscht werden, sodass dieser nicht mehr berechtigt ist auf die Webseite zu zugreifen: 

htpasswd -D Apache_PWD_File User
Abgerufen von „https://wiki.schiele.homelinux.org/index.php?title=Debian_Apache_Virtualhost_und_Proxy&oldid=1783“