[LinuxFocus-icon]
Home  |  Map  |  Index  |  Zoek

Nieuws | Archieven | Links | Over LF
Dit document is beschikbaar in: English  Castellano  Deutsch  Francais  Italiano  Nederlands  Turkce  Arabic  

convert to palmConvert to GutenPalm
or to PalmDoc

[Foto van de Auteur]
door Atif Ghaffar
<aghaffar/at/developer.ch>

Over de auteur:
Ik woon en werk in Zwitserland als web- en Unixbeheerder. Mijn interesses zijn onder andere Linux, Unix, Perl, Apache en GPL-software. Meer informatie over mijzelf is te vinden op mijn homepagina

Vertaald naar het Nederlands door:
Tom Uijldert <Tom.Uijldert/at/cmgplc.com>

Inhoud:

 

Servers benaderen achter een machine met Masquerading (via Apache ProxyPass)

[Illustratie]

Kort:

Thuis heb ik een klein Linux netwerk dat gebruik maakt van IP Masquerading (of Network Address Translation, NAT) en een IP firewall (een machine voor de beveiliging van Internet-toegang). Hoewel alle machines in het netwerk volledige toegang hebben tot het Internet, is alleen de machine die de IP-Masquerading doet toegankelijk vanaf het Internet. In mijn laatste artikel over Apache heb ik laten zien hoe je IP-adressen kunt hergebruiken. In dit artikel zal ik laten zien hoe je een webserver achter een firewall beschikbaar kunt maken voor toegang vanuit het Internet zonder de firewall te veranderen of de beveiliging te compromitteren. In dit artikel zullen we laten zien hoe we het ProxyPass commando hiervoor kunnen gebruiken. Dit artikel is voor systeembeheerders en eenieder die een klein of middelgroot netwerk aan het bouwen is voor thuis of op het werk.

_________________ _________________ _________________

 

Het IP Masquerading probleem

Op mijn netwerk was het lange tijd zo dat de router (de machine die de masquerading/firewall werkzaamheden uitvoerde) ook actief was als webserver, mail-server, ftp-server, dns-server enzovoorts.
Op een dag had ik de behoefte om een andere machine achter de firewall als webserver te laten fungeren.
Ook wilde ik een aantal documenten beschikbaar maken vanaf een SGI IRIX doos die achter het netwerk zat (een video server met daarop bewegende beelden). Deze machine had volledige toegang tot het Internet maar Internet-gebruikers konden niet naar de machine. Hoewel het niet mijn bedoeling was om deze IRIX doos op het netwerk beschikbaar te maken, was het wel noodzakelijk voor mensen om contact te kunnen leggen met de webserver op deze machine.

Op het werk had ik een probleem wat er op leek met een gelijkend netwerk en een firewall.
Iedere keer als iemand toegang wilde hebben tot een ontwikkel-webserver vanuit het Internet voor demonstratiedoeleinden, moesten de regels op de firewall worden gewijzigd en de betreffende machine worden uitgerust met een bestaand extern IP-adres, waarmee dus de beveiliging werd omzeild.

 

Apache, de reddende engel: ProxyPass

Na overweging van verscheidene alternatieven heb ik gekozen voor de oplossing met Apache en zijn ProxyPass commando.
Voor ProxyPass is het nodig dat mod_proxy mee wordt gecompileerd of als module in wordt geladen bij je Apache server.
Hieronder de definitie van ProxyPass uit de Apache handleiding.

ProxyPass
Syntax: ProxyPass <path> <url>
Default: None
Context: server config, virtual host
Override: Not applicable
Status: Base
Module: mod_proxy
Compatibility: ProxyPass is only available in Apache 1.1 and later.

Dit commando beeldt adressen van externe servers af op de lokale adresruimte; de lokale server treedt niet op als gevolmachtigde (proxy) in de gebruikelijke zin maar lijkt op een afspiegeling van de externe server. <path> is de naam van het lokale, virtuele, pad; <url> is een stuk URL voor de externe server.

Laten we even aannemen dat de lokale server het adres http://wibble.org/ heeft; dan zal

	ProxyPass /mirror/foo/ http://foo.com/
een lokale referentie naar <http://wibble.org/mirror/foo/bar> intern omzetten in een proxy referentie naar <http://foo.com/bar>.

 

Praktijkvoorbeeld

Het afbeelden van de interne video server op de externe webserver.
Interne netwerk: hometranet.home 192.168.1.0/255.255.255.0
(Voortbordurend op het thema internet, intranet, extranet, heb ik mijn netwerk thuis hometranet gedoopt).
Extern netwerk: developer.ch 193.192.254.50

De (interne) video server zit op machine cam.hometranet.home te bereiken voor videobeelden via http://cam.hometranet.home:5555/cams/sony/stream en stilstaande beelden via http://cam.hometranet.home:5555/cams/sony/image.
Deze beelden wilde ik extern kunnen bekijken via de URL's http://mozilla.developer.ch/stream en http://mozilla.developer.ch/image.
Dit is eenvoudig te doen met het gebruik van het ProxyPass commando van Apache door de volgende regels toe te voegen aan het bestand httpd.conf of sm.conf

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

Wanneer nu de webserver wordt herstart (als mod_proxy is geladen), zal http://mozilla.developer.ch/image een reactie opleveren van de cam webserver.
De bezoekende gebruiker ziet het verschil niet en er is bijna* geen verzwakte beveiliging met deze methode.
* Ik gebruik hier met opzet het woord bijna omdat er niet zoiets is als volledige beveiliging op het Internet :)

 

Virtuele servers afbeelden

De truc met ProxyPass kan worden gebruikt om een complete virtuele machine af te beelden op een heel andere machine. Bijvoorbeeld: docs.sun.developer.ch, afgebeeld op 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>
je kan ook verkeer doorsturen naar machines via hun IP-adres
<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>
 

Problemen

Omdat je primaire webserver refereert aan interne webservers namens je gebruikers, kun je geen behoorlijke logging doen op de daadwerkelijk gerefereerde machine. In plaats daarvan zul je alle logging op de machine moeten doen die de referentie doet.
In bovenstaand geval log ik op de primaire machine sun.docs.developer.ch in plaats van op solsparc.hometranet.home.
Logging uitvoer op sun.docs.developer.ch (voorbeelduitvoer)
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 -
Logging uitvoer op solsparc.hometranet.home
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
Hetzelfde geldt voor ACL's (Access Control Lists) die gebaseerd zijn op namen of IP-adressen.
Als je machines/IP-adressen wilt blokkeren of juist toegang verlenen dan zul je dit op de primaire server moeten regelen (de externe) in plaats van de lokale server.
Verder kun je gebruikers niet blokkeren op directory.
Hiervoor zou je echter één van de commando's Location, Files of FilesMatch kunnen gebruiken.
De volgende voorbeelden gaan hierop in:
<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>
 

Verdere referenties

[Apache mod_proxy documentatie]
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 documentatie]
http://www.apache.org/docs/vhosts/index.html
 

Talkback voor dit artikel

Elk artikel heeft zijn eigen talkback pagina. Daar kan je commentaar geven of commentaar van anderen lezen:
 talkback pagina 

Site onderhouden door het LinuxFocus editors team
© Atif Ghaffar, FDL
LinuxFocus.org
Vertaling info:
en --> -- : Atif Ghaffar <aghaffar/at/developer.ch>
en --> nl: Tom Uijldert <Tom.Uijldert/at/cmgplc.com>

2004-06-30, generated by lfparser version 2.36