Chapitre 29. Squid du serveur proxy

Table des matières

29.1. Quelques faits concernant les caches de proxy
29.2. Configuration système requise
29.3. Démarrage de Squid
29.4. Le fichier de configuration /etc/squid/squid.conf
29.5. Configuration d'un proxy transparent
29.6. cachemgr.cgi
29.7. squidGuard
29.8. Génération du rapport de cache avec Calamaris
29.9. Pour plus d'informations

Résumé

Squid est un cache de proxy très utilisé pour les plates-formes Linux et UNIX. Cela signifie qu'il stocke les objets Internet demandés, tels que les données d'un serveur Web ou FTP, sur une machine plus proche du poste de travail demandeur que le serveur. Ce chapitre aborde sa configuration, les paramètres requis pour le faire fonctionner, comment configurer le système pour le traitement proxy transparent, comment rassembler des statistiques concernant l'utilisation du cache à l'aide de programmes, tels que Calamaris et cachemgr, et comment filtrer le contenu Web avec squidGuard.

Squid agit comme un cache de proxy. Il redirige les demandes d'objets des clients (dans ce cas des navigateurs Web) vers le serveur. Lorsque les objets demandés arrivent du serveur, il fournit les objets au client et en conserve une copie dans le cache du disque dur. L'un des avantages de la mise en cache est que plusieurs clients demandant le même objet peuvent être servis à partir du cache du disque dur. Cela permet aux clients de recevoir les données beaucoup plus rapidement que depuis Internet. Cette procédure réduit en outre le trafic réseau.

Outre la mise en cache réelle, Squid offre une gamme étendue de fonctions telles que la distribution de la charge sur des hiérarchies de serveurs proxy qui communiquent entre elles. L'objectif est de définir des listes strictes de contrôle d'accès pour tous les clients qui accèdent au proxy, de permettre ou de refuser l'accès à des pages Web spécifiques avec l'aide d'autres applications, et de générer des statistiques concernant les pages Web fréquemment visitées afin d'évaluer les habitudes des internautes. Squid n'est pas un proxy générique. Il ne traite normalement par proxy que les connexions HTTP. Il prend également en charge les protocoles FTP, Gopher, SSL et WAIS, mais pas les autres protocoles Internet, tels que Real Audio, les news ou les vidéo-conférences. Du fait que Squid ne prend en charge que le protocole UDP pour permettre la communication entre différents caches, un grand nombre d'autres programmes multimédia ne sont pas pris en charge.


29.1. Quelques faits concernant les caches de proxy

En tant que cache de proxy, Squid peut s'utiliser de plusieurs manières. Combiné à un pare-feu, il peut contribuer à la sécurité. Plusieurs proxy peuvent être utilisés simultanément. Il peut également déterminer les types d'objets qui doivent être mis en cache et pendant combien de temps.

29.1.1. Squid et sécurité

Il est possible d'utiliser Squid avec un pare-feu pour sécuriser des réseaux internes de l'extérieur en utilisant un cache de proxy. Le pare-feu refuse tous les accès clients aux services externes excepté Squid. Toutes les connexions Web doivent être établies par le proxy. Avec cette configuration, Squid contrôle complètement l'accès au Web.

Si la configuration du pare-feu inclut une zone démilitarisée, le proxy doit fonctionner dans cette zone. La Section 29.5, « Configuration d'un proxy transparent » décrit comment implémenter un proxy transparent. Cela simplifie la configuration des clients. Ils n'ont en effet pas besoin d'informations concernant le proxy dans ce cas.

29.1.2. Caches multiples

Plusieurs instances de Squid peuvent être configurées pour échanger des objets entre eux. Cela réduit la charge totale du système et accroît les chances de trouver un objet existant déjà dans le réseau local. Il est également possible de configurer des hiérarchies de cache, de sorte qu'un cache puisse envoyer des demandes d'objets à des caches frères ou à un cache parent, ce qui permet de récupérer des objets d'un autre cache dans le réseau local ou directement à partir de la source.

Le choix de la topologie appropriée pour la hiérarchie du cache est très important. Il n'est en effet pas souhaitable d'augmenter le trafic global sur le réseau. Pour un très grand réseau, il est judicieux de configurer un serveur proxy pour chaque sous-réseau et de les connecter à un proxy parent, qui est à son tour connecté au cache de proxy de l'ISP.

Toute cette communication est gérée par ICP (Internet cache protocol) exécuté par dessus le protocole UDP. Les transferts de données entre caches sont gérés en utilisant HTTP (hypertext transmission protocol) basé sur TCP.

Pour trouver le serveur le plus approprié à partir duquel récupérer les objets, un cache envoie une requête ICP à tous les proxy frères. Ceux-ci répondent aux requêtes via des réponses ICP avec un code HIT si l'objet a été détecté ou MISS dans le cas contraire. Si plusieurs réponses HIT ont été trouvées, le serveur proxy décide à partir de quel serveur effectuer le téléchargement, selon des facteurs tels que quel cache a envoyé la réponse la plus rapide ou lequel est le plus proche. Si aucune réponse satisfaisante n'est reçue, la requête est adressée au cache parent.

[Tip]Astuce

Pour éviter la duplication d'objets dans différents caches du réseau, d'autres protocoles ICP sont utilisés, tels que CARP (cache array routing protocol) ou HTCP (hypertext cache protocol). Plus le nombre d'objets gérés sur le réseau est élevé, plus la probabilité de trouver celui que l'on cherche est grande.

29.1.3. Mise en cache d'objets Internet

Tous les objets disponibles sur le réseau ne sont pas statiques. Il y a un grand nombre de pages CGI générées de façon dynamique, de compteurs de visiteurs et de documents au contenu SSL codé. Ces types d'objets ne sont pas mis en cache car ils changent chaque fois qu'on y accède.

La question demeure tant que tous les autres objets stockés dans le cache doivent y rester. Pour déterminer cela, il est attribué à tous les objets du cache un état parmi plusieurs possibles. Les serveurs Web et proxy trouvent l'état d'un objet en y ajoutant un en-tête, tel que « Last modified » ou « Expires » avec la date correspondante. D'autres en-têtes spécifiant que les objets ne doivent pas être mis en cache sont également utilisés.

Les objets du cache sont normalement remplacés, du fait d'un manque d'espace disque disponible, en utilisant des algorithmes tels que LRU (last recently used - le plus récemment utilisé). En fait, cela signifie que le proxy purge les objets qui n'ont pas fait l'objet de demandes pendant la période la plus longue.