installation de deux serveurs webs derrière un routeur NAT

Soumis par anarcat le jeudi, 16 janvier, 2003 - 12:17 Remarque
L'Insomniaque

L'installation du serveur de l'Insomniaque fut un casse-tête technologique intéressant. La problématique initiale est que le routeur NAT original (un DLink DI704) derrière lequel le serveur était supposé rouler ne permettait pas de service sur le port 80, ce qui était pour nous inacceptable. Nous avons donc du transférer le serveur vers un autre endroit, où il y avait un routeur décent, plus configurable et fonctionel.

Le second problème qui est apparu est que l'emplacement en question possédait déjà un serveur web, et pour des raisons administratives, il était impossible de "fusionner" les deux machines (ou du moins leurs configurations ou leurs données). Il fallait donc pouvoir accéder les deux serveur indépendemment, de l'extérieur du routeur.

Ceux qui ont un peu de connaissance en ce qui a trait au protocole NAT voient déjà le problème: il est impossible de "router" un port (le port 80, HTTP) vers deux machines différentes au niveau du routeur NAT car ce dernier agit seulement au niveau IP et qu'il ne travaille que sur une seule adresse IP. Un port peut donc être routé vers une seule machine.

Il fallait donc trouver une solution à un niveau protocolaire plus élevé, c'est à dire au delà du protocole IP. En examinant le protocole HTTP, on note que les requêtes sous les protocoles HTTP matures (1.0 et 1.1) envoient un "header" Host, un "avancement technologique" qui a permis d'implanter le concept de virtual server sur des serveurs webs et qui est maintenant très répandu.

En d'autres termes, les protocoles HTTP récents permettent de servir plusieurs nom de domaines (les virtual servers) sur une seule adresse IP et sur une seule machine.

En utilisant ceci, il était donc possible de créer un genre de "reverse proxy" qui acheminerait traiterait toutes les requêtes envoyées du serveur NATs. Ce ne fut pas simple, car ce n'est pas une configuration comme les autres. En effet, les "reverse proxys", habituellement, sont dédiés au load balancing et servent toujours les mêmes pages, les mêmes noms de domaines. Ce n'était pas le but ici. Le proxy devait diriger les requêtes vers le serveur original si le nom de domaine demandé était reconnu comme appartenant au serveur en question.

Pour être plus précis, donnons les exemples réels. Le réseau en question comportait un serveur web, nommé "shall", servant anarcat.ath.cx ainsi que orangeseeds.org. Ainsi, le reverse proxy devait renvoyer les requêtes ayant trait à ces deux noms de domaines vers shall, mais sans faire un HTTP Redirect, car le réseau externe ne peut joindre le serveur shall à cause du routeur NAT.

Références bibliographiques:

Voici la configuration de apache (écourtée) nécessaire à cette configuration:

 # config du reverse proxy vers shall
 <IfModule mod_proxy.c>
 #
 # To enable the cache as well, edit and uncomment the following lines:
 # (no cacheing without CacheRoot)
 #
 #CacheRoot "/var/cache/apache"
 #CacheSize 5
 #CacheGcInterval 4
 #CacheMaxExpire 24
 #CacheLastModifiedFactor 0.1
 #CacheDefaultExpire 1
 #NoCache adomain.com anotherdomain.edu joes.garage_sale.com
 NoCache *
 ProxyPassReverse / http://anarcat.ath.cx/
 ProxyPassReverse / http://anarcat.dyndns.org/
 ProxyPassReverse / http://orangeseeds.org/
 RewriteEngine		on
 RewriteLogLevel		0
 #   make sure the status page is handled locally
 #   and make sure no one uses our proxy except ourself
 #RewriteRule    ^/apache-rproxy-status.*  -  [L]
 # XXX: is this really necessary?
 RewriteRule    ^(http|ftp)://.*          -  [F]
 # organseeds.org and .net
 RewriteCond	%HTTP_HOST	orangeseeds.(org)|(net)$
 RewriteRule    ^/(.*)$               to://orangeseeds.org/$1
 # anarcat.ath.cx, anarcat.dyndns.org and < HTTP/1.0 user agents
 # go through anarcat.ath.cx
 RewriteCond	%HTTP_HOST	anarcat.(ath.cx)|(dyndns.org)$ [OR]
 RewriteCond	%HTTP_HOST	=""
 RewriteRule    ^/(.*)$               to://anarcat.ath.cx/$1
 # rest stays on local server
 RewriteRule    ^/(.*)$               -  [L]
 # proxy rule that rewrites non-local patterns to remote ones 
 RewriteRule    ^to://([^/]+)/(.*)    Http://$1/$2   [E=SERVER:$1,P,L]
 #   and make really sure all other stuff is forbidden 
 #   when it should survive the above rules...
 RewriteRule    .*                    -              [F]
 </IfModule>
 # End of proxy directives.

Félicitation pour votre beau programme

by tatien on 16 janvier, 2003 - 22:58Score: 1

Wow! Ça c'est de la belle job! En passant, je ne sais pas si c'est une hallucination, mais il me semble que le site "roule" plus vite que quand il était sur l'ordinateur de Mathieu. Qu'en penses-tu?

 

améliorations?

by anarcat on 16 janvier, 2003 - 23:44Score: 0

c'est possible. C'est certain que le fait que la machine ait 2 CPUs aident beaucoup. C'est même vraiment important parce que, dans Drupal, apache et mysqld tirent pas mal de jus, les deux en même temps, souvent. Le fait qu'il y ait deux CPUs permet d'éviter des "context switchs" coûteux en temps de calcul.

On pourrait encore plus accélérer le tout en roulant mysql sur mon autre serveur.