[LinuxFocus-icon]
Home  |  Plan  |  Index  |  Suchen

Nachrichten | Archiv | Links | Über uns
Dieses Dokument ist verfübar auf: English  Castellano  Deutsch  Francais  Italiano  Nederlands  Turkce  Arabic  

convert to palmConvert to GutenPalm
or to PalmDoc

[Photo of the Author]
von Atif Ghaffar
<aghaffar(at)developer.ch>

Über den Autor:

Ich lebe in der Schweiz und arbeite als Webmaster und Unix Systemadministrator. Meine Leidenschaften sind unter anderem Linux, Unix, Perl, Apache und GPL Software allgemein. Weitere Informationen über mich gibt es auf meiner Homepage



Übersetzt ins Deutsche von:
Guido Socher <guido.socher(at)linuxfocus.org>

Inhalt:

 

Wie man mit Hilfe von Apache ProxyPass auf einen Server hinter einer Firewall zugreifen kann

[Illustration]

Zusammenfassung:

Ich habe zu Hause ein kleines Netzwerk mit Linux-masquarading und Ip-Firewall. Obwohl alle Maschinen in meinem Netzwerk auf das Internet zugreifen können, gibt es nur eine einzige Maschine, die im Internet sichtbar ist. Das ist die Maschine, auf der Ip masquarading läuft. In meinem letzten Apache Artikel , habe ich erklärt, wie man IP Adressen wiederverwendet. In diesem Artikel werde ich zeigen, wie man einen Webserver hinter einer Firewall im Internet sichtbar macht, ohne die Regeln für die Firewall zu ändern und die Sicherheit zu gefährden.

Wir benutzen dieses Mal Apache's ProxyPass Anweisung, um dieses Ziel zu erreichen.

Dieser Artikel ist für einen Systemadministratior oder jeden anderen, der ein kleines LAN zu Hause oder im Büro betreibt.



 

Probleme, die Ip masquarading mit sich bringt

Für lange Zeit arbeitete der Router in meinem LAN, die Maschine, auf der masquarating/Firewall lief, auch als Webserver, Mailserver, Ftp Server, DNS Server u.s.w.
Eines Tages mußte dann ein Webserver, der im LAN hinter dem masquarading Router saß, auch im Internet sichtbar werden.
Ich wollte auch einige Dokumente von einer SGI IRIX Kiste, die hinter dem Router war und als Video Server fungierte, zur Verfügung stellen. Diese Maschine hatte vollen Zugriff auf das Internet, aber aus dem Internet konnte man nicht auf sie zugreifen. Obwohl ich ursprünglich keine Absichten hatte, diese Maschine ins Internet zu stellen, war es plötzlich nötig, daß der Web-Service dieser Maschine nun im Internet zur Verfügung stand.

Auf der Arbeit wurde ich mit einem ähnlichen Problem wie zu Hause konfrontiert.
Jedes Mal, wenn ein Entwicklungswebserver auf dem Internet für Demo Zwecke zur Verfügung stehen sollte, mußte ich die Firewallregeln ändern, der Maschine eine externen IP Adresse geben und so die Sicherheit des Netzwerkes gefährden.

 

Apache, die Rettung: ProxyPass

Nachdem ich verschiedene Möglichkeiten studiert hatte, entschied ich mich für eine Lösung mit Apache und ProxyPass, die ich hier vorstellen möchte.
Für ProxyPass muß man mod_proxy mit Apache kompilieren und als Modul laden.
Die folgende Definition für ProxyPass ist dem Apache Handbuch entnommen.

ProxyPass

Syntax: ProxyPass <path> <url>
Default: None
Context: server config, virtual host
Override: Not applicable
Status: Base
Module: mod_proxy
Compatibility:

ProxyPass ist nur für Apache 1.1 und später verfügbar.

Durch diese Anweisungen werden andere Webserver in den Adreßraum eines lokalen Servers abgebildet. Der lokale Proxy arbeitet dabei nicht als Proxy in konventionellen Sinne, sondern ist vielmehr ein Mirror eines anderen Servers. <path> ist dabei der Pfad des lokalen virtuellen Pfades. <url> ist der gemeinsame Teil der Pfade, die zu den Webseiten eines anderen Webserver führen.

Angenommen, der lokale Server hat die Adresse http://wibble.org/, dann wird durch folgende Anweisung

   ProxyPass /mirror/foo/ http://foo.com/
eine Anfrage für <http://wibble.org/mirror/foo/bar> intern in eine Proxy-Anfrage für <http://foo.com/bar> konvertiert.

 

Ein echtes Beispiel

Ich möchte den internen Videoserver auf den externen Webserver abbilden.
Internes Netzwerk: hometranet.home 192.168.1.0/255.255.255.0
(Im Stil von Internet, Intranet, Extranet nenne ich mein Netz zu Hause einfach Hometranet)
Externes Netz: developer.ch 193.192.254.50

Der interne Videoserver läuft auf cam.hometranet.home und bietet Videostreams unter dem URL
http://cam.hometranet.home:5555/cams/sony/stream Es gibt außerdem stehende Bilder unter
http://cam.hometranet.home:5555/cams/sony/image
Diese beiden URLs sollen extern unter
http://mozilla.developer.ch/stream
und
http://mozilla.developer.ch/image
zu finden sein.
Unter Verwendung von Apache ProxyPass kann man das sehr leicht erreichen, indem man die folgenden Zeilen in httpd.conf oder srm.conf einfügt

ProxyPass /video http://cam.hometranet.home:5555/cams/sony/stream
ProxyPass /video http://cam.hometranet.home:5555/cams/sony/stream

Nachdem der Webserver neu gestartet ist, und falls mod_proxy erfolgreich geladen wurde kann man den cam-Webserver jetzt unter
http://mozilla.developer.ch/image
finden. Für den Betrachter von außen ist absolut nicht zu sehen, daß diese Seiten in Wirklichkeit von einem internen Server stammen. Durch diese Lösung ist die Sicherheit praktisch nicht beeinflußt. Eine totale Sicherheit gibt es natürlich nie im Internet :)

 

Virtuelle Server abbilden

Den Proxypass Trick kann man auch benutzen, um eine Virtuelle Maschine vollständig auf einen anderen Server abzubilden.
Hier ein Beispiel:
docs.sun.developer.ch mapped to solsparc.hometranet.home

NameVirtualHost 193.192.254.50
<VirtualHost 193.192.254.50>
     ServerName sun.docs.developer.ch
     ProxyPass / http://solsparc.hometranet.home/
     TransferLog /net/www/logs/sun.docs.access
     ErrorLog    /net/www/logs/sun.docs.errror
</VirtualServer>
Man kann ProxyPass auch auf die IP Adressen der Maschine anwenden.
<VirtualHost 193.192.254.50>
     ServerName sun.docs.developer.ch
     ProxyPass / http://192.168.1.7/
     TransferLog /net/www/logs/sun.docs.access
     ErrorLog    /net/www/logs/sun.docs.errror
</VirtualServer>
 

Die Nachteile

Da der Hauptserver proxy Anfragen zu dem internen Server schickt, kann man in den Logfiles des internen Servers keine sinnvollen Informationen mehr finden. Es sieht immer so aus, als ob dieselbe Person auf den Webserver zugreift. Man kann die Anfragen aber natürlich in den Logs des Hauptservers finden.
Die Anfragen für den internen Host solsparc.hometranet.home finden sich nun auf dem Hauptserver sun.docs.developer.ch:
Auszüge aus den Logfiles von sun.docs.developer.ch

197.0.22.3 - - [05/Nov/1999:22:09:04 +0100] "GET /index.html HTTP/1.0" 304 -
187.0.45.67 - - [05/Nov/1999:22:09:04 +0100] "GET /navi.html HTTP/1.0" 304 -
177.0.5.45 - - [05/Nov/1999:22:09:04 +0100] "GET /entrees.html HTTP/1.0" 304 -
227.0.9.67 - - [05/Nov/1999:22:09:15 +0100] "GET /complets.html HTTP/1.0" 304 -
137.0.7.23 - - [05/Nov/1999:22:09:19 +0100] "GET /menu_poisson.html HTTP/1.0" 200 841
193.192.245.73 - - [05/Nov/1999:22:09:25 +0100] "GET /volailles.html HTTP/1.0" 304 -
192.167.0.1 - - [05/Nov/1999:22:09:44 +0100] "GET /agneau.html HTTP/1.0" 304 -
Auf solsparc.hometranet.home findet man
192.168.1.1 - - [05/Nov/1999:22:09:04 +0100] "GET /index.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:04 +0100] "GET /navi.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:04 +0100] "GET /entrees.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:15 +0100] "GET /complets.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:19 +0100] "GET /menu_poisson.html HTTP/1.0" 200 841
192.168.1.1 - - [05/Nov/1999:22:09:25 +0100] "GET /volailles.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:44 +0100] "GET /agneau.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:09:56 +0100] "GET /desserts_ind.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:10:00 +0100] "GET /cocktails.html HTTP/1.0" 304 -
192.168.1.1 - - [05/Nov/1999:22:10:10 +0100] "GET /cgi-bin/commande.cgi HTTP/1.0" 200 2146

Die gleichen Einschränkungen gelten auch für Namen basierte oder Ip basierte ACLs (access control lists) Tabellen für die Zugriffskontrolle. Will man den Zugriff auf bestimmte Seiten einschränken, dann sollte man das auf dem Hautpserver tun.

Man kann jedoch die Location, Files oder FilesMatch Anweisungen benutzen, um den Zugriff auf bestimmte Seiten zu verhindern.
Hier ein Beispiel:
<VirtualHost 193.192.254.50>
     ServerName sun.docs.developer.ch
     #this rule only allows users from good.host.com domain
     <Location /private>
          order deny,allow
          deny from all
          allow from good.host.com
     </Location>
     #This rule deny's the uncool Microsoft's monopoly helper browser.
     BrowserMatch MSIE uncool_browser
     <Location /coolpages>
         order allow,deny
         allow from all
         deny from env=uncool_browser
     </Location>
     #This rule only allows users that are in your passwd.httpd file
     <Location /coolpages>
         AuthName "only for registered users"
         AuthType Basic
         AuthUserFile "/etc/httpd/passwd.httpd"
         <Limit GET>
              require valid-user
         </Limit>
     </Location>

     ProxyPass / http://192.168.1.7/
     TransferLog /net/www/logs/sun.docs.access
     ErrorLog    /net/www/logs/sun.docs.errror
</VirtualServer>

 

Zusätzliche Referenzen

[Apache mod_proxy Dokumentation]
http://www.apache.org/docs/mod/mod_proxy.html
[Apache name-based Virtual Host Support]
http://www.apache.org/docs/vhosts/name-based.html
[Apache Virtual Host Dokumentation]
http://www.apache.org/docs/vhosts/index.html
 

Talkback für diesen Artikel

Jeder Artikel hat seine eigene Seite für Kommentare und Rückmeldungen. Auf dieser Seite kann jeder eigene Kommentare abgeben und die Kommentare anderer Leser sehen:
 Talkback Seite 

Der LinuxFocus Redaktion schreiben
© Atif Ghaffar, FDL
LinuxFocus.org

Einen Fehler melden oder einen Kommentar an LinuxFocus schicken
Autoren und Übersetzer:
en --> -- : Atif Ghaffar <aghaffar(at)developer.ch>
en --> de: Guido Socher <guido.socher(at)linuxfocus.org>

2002-02-24, generated by lfparser version 2.25

mirror server hosted at Truenetwork, Russian Federation.