Index
Tag Cloud
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.
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.