Squid en mode Reverse Proxy

Fonctionnement, but et usage d'un Reverse Proxy

Le but premier de SQUID était de “cacher” les contenu web pour les petites infrastructure a l'époque ou les liaisons haut-débit étaient peu courante et coutaient aussi tres cheres. Ce soft permet aussi de faire l'inverse d'un proxy, a savoir cacher du contenu généré par un ou plusieurs serveur web pour des “clients” (comprendre visiteurs d'un site). L'apport premier de ce mode de fonctionnement est de permettre, par cette mise en cache, de soulager des serveurs web qui generent souvent le meme contenu pour different visiteurs. De fait le “temps processeur” n'est pas gaché a refaire continuellement les memes choses qui n'ont pas été modifié et peut etre employé a d'autre chose (d'autre page a generer), et permet de diminuer les couts serveurs.

Configuration Squid pour Reverse Proxy

Nous allons nous concentrer ici que sur ce qui permet de mettre en route SQUID en reverse proxy, le reste de la configuration sera donc ignoré.

http_port 80 vhost

Ici très simple, on indique a squid d'écouter sur le port 80 comme un serveur web Classique.

icp_port 3130

L'ICP est en gros (très gros) le mode de communication entre SQUID (je résume)

cache_peer 192.168.80.1 parent 80 0 round-robin no-query no-digest originserver login=PASS name=serveurweb1
cache_peer 192.168.80.2 parent 80 0 round-robin no-query no-digest originserver login=PASS name=serveurweb2
cache_peer 192.168.80.3 parent 80 0 round-robin no-query no-digest originserver login=PASS name=serveurweb3

Ces simples lignes definissent quels sont les serveurs web a contacter. Nous allons partir du principe que “serveurweb1” et “serveurweb2” distribuent les pages proprement dite et que “serveurweb3” distribue les “media”.

cache_peer 192.168.88.1 sibling 80 3130 round-robin no-digest name=squid1
cache_peer 192.168.88.2 sibling 80 3130 round-robin no-digest name=squid2

Et celle-ci pour indiquer quel sont les serveurs de cache, très utile en cas de load balancing sur ceux-ci. Attention il faut que chaque squid ne s'interroge pas lui même, commenter les lignes le concernant sont le plus efficace. Sinon nous auront de formidable boucle nommé “Forwarding Loop”.

acl acl_domain1                   dstdomain domain.ext .domain.ext

Ici nous definissons une ACL indiquant qu'il prend en charge domain.ext et *.domain.ext (vous noterez l'asbence du wildcard dans la syntaxe).

acl acl_mediadomain1                  dstdomain media.domain.ext

Et ici on definis une ACL prenant en charge “media.domain.ext”.

cache_peer_access squid1 allow acl_mediadomain1
cache_peer_access squid1 allow acl_domain1

cache_peer_access squid2 allow acl_mediadomain1
cache_peer_access squid2 allow acl_domain1

Tres important pour le “sibling”, il faut que chaque serveur de cache soit à même d'interroger ses petit copain, mais bien sur comme vu plus haut, il ne faut pas qu'il s'interroge lui même, il faut donc commenter la ligne concernant le serveur de cache en cours.

cache_peer_access serveurweb1 deny acl_mediadomain1
cache_peer_access serveurweb1 allow acl_domain1

cache_peer_access serveurweb2 deny acl_mediadomain1
cache_peer_access serveurweb2 allow acl_domain1

cache_peer_access serveurweb3 allow acl_mediadomain1
cache_peer_access serveurweb3 deny acl_domain1

L'ordre est tres important !

Nous allons donc dire a serveurweb1 et serveurweb2 de refuser de prendre en charge “media.domain.ext” _puis_ de gérer le wildcard “*.domain.ext” (et “domain.ext”). Les requetes a destination de “media.domain.ext” ne seront donc pas traité par serveurweb1 et serveurweb2 et toute les autres requetes qui ne sont pas “*.domain.ext” (et “domain.ext”) seront géré par serveurweb1 et serveurweb2.

/!\ Si nous inversons les deux lignes, que le allow du wildcard est avant le deny du sous-domaine, le wildcard aura precedence sur tout et ne prendra pas en compte le deni de prise en charge du sous-domaine. /!\

A l'inverse pour serveurweb3, nous l'autorisons a prendre en charge “media.domain.ext” mais lui refusons ensuite la gestion du wildcard “*.domain.ext” (et “domain.ext”). Les requetes a destination de “media.domain.ext” seront donc traité et aucune autre requete que celle-ci iront sur serveurweb3

/!\ Si nous inversons les deux lignes, que le deny du wildcard est avant le allow du sous domaine, il y aura un deni total de toute requete a destination de “*.domain.ext” (et “domain.ext”), mettant donc au rebut les requete du sous-domaine “media.domain.ext”. /!\

acl localnet src 192.168.0.0/255.255.0.0

http_access allow localnet

http_access allow acl_mediadomain1 all
http_access allow acl_domain1 all

http_access deny all

icp_access allow localnet
icp_access deny all

Ces lignes très simple permettent d'autoriser l'access HTTP a tout ce qui est demandé a destination des acl acl_domain1 et acl_mediadomain1 et autorise l'acl “localnet” au passage a acceder a l'http. Il y a une legere redondance mais pour que je sois certains que les squid demandent bien les pages a leur copain je l'ai laissé. On terme l'acces HTTP par un DENY sur absolument tout, cela permet d'eviter que l'on demande l'acces a google au squid et qu'ils demandent aux serveurs Web pour rien.

Ensuite pour l'ICP c'est notamment pour les SQUID, on les autorise via l'acl “localnet” a interroger l'icp et on refuse pour le reste.

wiki/squid_reverse_proxy.txt · Dernière modification: Monday 20 July 2009 par kathryl
Flux RSS du Blog Driven by DokuWiki Gentoo Powered Valid XHTML1.0 Powered by Apache PHP Powered Coffee Powered