Ce document détaille la configuration du proxy cache Squid sur sila

Ce document décrit la configuration de Squid sur sila. Il ne s'agit pas d'expliquer comment monter un proxy Squid, mais simplement de détailler la configuration et les choix effectués. Le site de Squid contient des docs plus complètes.

1. Qu'est-ce que Squid ?

Squid est avant tout un proxy, en français, un serveur mandataire, c'est-à-dire un mandataire. Au lieu d'interroger directement un serveur Web, on interroge le proxy qui va lui même interroger le serveur cible et faire passer la réponse. Vu comme ça, l'intérêt est faible. Squid permet de restreindre les accès selon l'origine, la cible, l'heure, la taille, etc. On n'utilise rien de tout ça.

Le second intérêt de Squid est qu'il mémorise les pages qu'il va chercher sur le disque. Ainsi, si un autre utilisateur lui demande la même page, il n'est pas obligé d'aller la chercher.

2. Les commandes de base

De base, Squid est quasi configuré. Il n'y a pas grand chose à changer. Lors du premier lancement, il faut lui passer le paramètre -z pour qu'il construise la structure de répertoires contenant les fichiers cachés (=mémorisés). Les lancements ultérieurs se font normalement.

Après chaque modification du fichier de config, on utilisera la commande squid -k reconfigure pour forcer Squid à relire son fichier de config et à répercuter les changements.

Squid maintient trois fichiers de logs :

/var/log/squid/cache.log contient les logs à propos de Squid lui même. S'il ne démarre pas ou si on obtient un comportement erratique, c'est ce fichier qu'il faut surveiller.
/var/log/squid/access.log contient les demandes effectuées par les utilisateurs, c'est-à-dire l'ensemble des URL demandées. Il convient de limiter au strict minimum la lecture de ce fichier.
/var/log/squid/store.log indique quels sont les fichiers dans le cache et où ils sont. Sa lecture est difficile et son contenu est éminemment temporaire. Je ne vois pas d'utilité pratique à aller regarder ce fichier. Squid dispose d'un mode "off-line" permettant de consulter directement le cache et il respecte le chargement forcé d'une page.

3. Les possibilités de Squid

Squid dispose d'un certain nombre de fonctionnalités. Il supporte les protocoles HTTP et FTP. Il reconnaît HTTPS (mais ne cache pas le résultat). Il est capable de cacher les requêtes DNS pour les minimiser (ce qui est un peu redondant avec un DNS local), il sait agir en cache transparent (la connexion est détournée vers le proxy) soit avec l'aide d'un programme extérieur qui identifie la connexion originale, soit sans, avec l'aide du champ Host (utilisé sur la quasi-totalité des clients actuels).

De plus, il est capable de travailler en coopération dans une hiérarchie d'autres proxies. Il met de plus en oeuvre des mécanismes avancés pour optimiser les requêtes aux voisins et aux parents.

4. La configuration

Toute la configuration de Squid se trouve dans le fichier /etc/squid.conf qui est extensivement commenté. Il est quasiment inutile de se reporter à une quelconque doc pour configurer Squid, tout est expliqué dans ce fichier.

Les paramètres importants

Squid se configure rapidement en précisant quelques paramètres importants.

http_port Il s'agit du port sur lequel Squid attend les requêtes. Traditionnellement, il s'agit du port 3128, parfois du port 8080.
cache_peer Cette option (qui peut être répétée aussi souvent que nécessaire) permet d'indiquer les proxies frères et parents. Un frère est un proxy de même niveau que l'on peut consulter sous certaines conditions. Un père est un proxy auquel on passe la requête si on ne connaît pas la réponse. Au CRANS, on n'utilise aucun voisin.
cache_mem Cette option permet de moduler la mémoire nécessaire pour Squid. Il s'agit d'indiquer la quantité de mémoire que va utiliser Squid pour cacher certains objets (ceux en transit, ceux très demandés et ceux qui ne peuvent pas être placés dans le cache). Sur une machine dédiée, on met habituellement le tiers de sa mémoire vive. Squid va en réalité utiliser beaucoup plus.
cache_dir Cette ligne peut être répétée autant de fois que nécessaire. Elle indique un emplacement du disque pour cacher les objets. Les objets sont stockés dans une hiérarchie à deux niveaux et on doit spécifier la taille des deux niveaux. Les paramètres sont très dépendants des performances du système de fichiers (il faut tenter de minimiser les deux nombres s'il ne sait pas gérer les répertoires avec beaucoup de fichiers). Si la machine a plusieurs disques, il est préférable de répartir le cache sur ces disques.
acl Ces lignes définissent des entités auxquelles on attachera des droits. C'est expliqué un peu plus loin.

Le moyen le plus simple de configurer Squid est de lire le fichier de haut en bas. La plupart des paramètres peuvent être laissés en commentaire.

Les ACL

Le point le plus délicat de la configuration de Squid est la gestion des ACL. Toute une section de la FAQ y est consacrée.

Le point crucial est de bien comprendre dans quel ordre ça marche. Si on donne plusieurs critères pour une ligne acl, ceux-ci sont combinés dans un ou logique. Ensuite, si on donne plusieurs ACL à une règle, ceux-ci sont combinés par un et logique. Enfin, les règles sont essayées dans l'ordre et on s'arrête dès qu'on a trouvé une règle qui convient. C'est le point très important de cette section. Relisez bien deux ou trois fois.

La première tâche consiste à construire les ACL, c'est-à-dire les entités qui auront des droits ou pas. La syntaxe est la suivante :

acl nom [element1 [element2 ... ] ]

Les commentaires du fichier /etc/squid.conf indiquent les éléments possibles. On aura par exemple :

acl CRANS src 138.231.136.0/255.255.248.0
acl SSL_ports port 443 563
acl weekend AS

L'ACL CRANS définit la zone CRANS comme source. Elle sera utilisée pour indiquer que l'on donne l'accès pour les machines venant de la zone CRANS. L'ACL SSL_ports indique quels sont les ports securisés tandis que l'ACL weekend indique si on est samedi ou dimanche, elle pourrait aussi être utilisée pour restreindre les accès.

Les ACL ainsi définies peuvent ensuite être utilisées à divers endroits. La FAQ indique quelles sont toutes les listes d'accès possibles. A priori, http_access est la liste la plus importante. always_direct et never_direct ne servent que quand il y a des voisins de configurés. On utilisera alors également cache_peer_access si tous les voisins ne sont pas susceptibles de recevoir toutes les requêtes.

Rappelons d'abord que pour une liste d'accès, les règles sont testées dans l'ordre. Si arrivé à la fin, aucune règle ne convient, Squid prend l'inverse de la dernière règle. Il est donc préférable de l'expliciter, par exemple en plaçant à la fin des règles pour http_access :

http_access deny all

Ensuite, c'est libre. Les règles suivantes permettent de n'autoriser que la zone CRANS et seulement sur les ports correspondant à l'HTTP :

http_access allow CRANS Safe_ports
http_access allow CRANS SSL_ports
http_access deny all

Par contre, ces règles, on n'obtient pas la même chose :

http_access deny !Safe_ports
http_access deny !SSL_ports
http_access allow CRANS
http_access deny all

En effet, si quelque chose arrive sur le port 443 (SSL), il vérifiera !Safe_ports et sera donc rejeté. De même, il faut éviter des choses de ce genre :

http_access allow CRANS Safe_ports SSL_ports
http_access deny all

En effet, dans ce cas, on demande à ce que le port soit dans Safe_ports et dans SSL_ports, ce qui risque d'être difficile si les ports sont disjoints.

Encore une fois, la FAQ est très précieuse pour comprendre les ACL. Il faut la lire. D'ailleurs, je vais le faire, ce serait bête de laisser des erreurs dans ce document ! ;-)

Le reste

Nous utilisons en plus de squid un programme de redirection appellé Jesred. Ce programme prend en fait en entrée toutes les URL demandées à squid par les clients et les modifie en conséquence selon ce que l'on a mis dans le fichier de conf. Cela permet par exemple de détecter que quelqu'un demande le fichier debian-30r0-i386-binary-1.iso et de le rediriger automatiquement vers une page lui proposant de télécharger la copie de ce fichier que nous maintenons localement. Cela permettrait en théorie également de détecter les bandeaux publicitaires et de les remplacer par un pixel blanc, à la manière de Privoxy (le nouveau nom ridicule de Junkbuster, car Junkbuster à proprement parler n'est plus maintenu). En pratique deux paramètres interviennent dans le fichier de conf de squid en ce qui concerne le redirecteur : ce sont le path du programme de redirection, et le nombre d'instances de ce programme à lancer.

redirect_program /usr/lib/squid/jesred
redirect_children 15

Le nombre 15 est issu de l'expérimentation ; sur sila, si on met moins de 10 instances, squid râle parce qu'il n'y en a pas assez, et s'il y en a 20, plusieurs instances ne servent pas du tout et ça charge inutilement la machine.

5. En pratique, comment ça marche ?

Quand on interroge Squid, on peut obtenir plusieurs réponses.

TCP_HIT indique que la page a été trouvée dans le cache et qu'elle est valable, c'est-à-dire qu'elle n'a pas expirée.
TCP_MISS indique que la page n'est pas dans le cache.
TCP_REFRESH_HIT indique que la page était dans le cache, mais elle n'est plus à jour. Squid a interrogé le site pour savoir si la page a été modifiée et le site lui a dit que non.
TCP_REF_FAIL_HIT indique la même condition mais le site n'a pas répondu et donc l'ancienne page a été donée.
TCP_REFRESH_MISS indique que la page était dans le cache, mais que le site a indiqué qu'elle n'était plus à jour, on a donc renvoyé la nouvelle version.
TCP_IMS_HIT indique que le client a demandé si la page était à jour, or elle était dans le cache et considérée comme à jour.
TCP_SWAPFAIL_MISS indique que la page était normalement dans le cache mais en fait que non (ça arrive quand on efface manuellement les fichiers).
TCP_NEGATIVE_HIT indique que la page est dans le cache, qu'elle ne devrait pas y être car le site ne désire pas qu'elle y soit (page dynamique), mais que Squid a de bonne raison de croire qu'elle est toujours valide (car c'est par exemple une erreur 404 ; Squid ne respecte pas les indications du site quant à la durée de validité d'une page dans les quelques cas pertinents, dans tous les autres, y compris les pages statiques faussement dynamiques car remplies de pubs, Squid respecte le fait que le site ne veut pas qu'on reserve la copie du cache).
TCP_MEM_HIT indique qu'on a un coup de bol pas possible, la page est justement en mémoire.
TCP_DENIED indique que l'accès n'est pas autorisé (cf les ACL).
TCP_OFFLINE_HIT indique que Squid est en mode off line (hors ligne) et qu'il a bien la page dans son cache.
TCP_CLIENT_REFRESH_MISS indique que le client a forcé le rechargement de la page et donc que Squid est obligé d'aller la récupérer, quel que soit l'état de ce qu'il a en mémoire.

Squid obéit à plusieurs principes pour cacher des pages. Le serveur peut lui donner une durée de validité de la page. Tant que cette durée ne s'est pas écoulée, Squid considère la page comme valide et ne la rafraîchit que si le client l'y force. Cette durée peut être négative et dans ce cas, Squid ne cachera pas la page (ou de manière très brève, ça se règle). Quand la durée s'est écoulée, Squid va demander si la page a changé depuis la dernière fois. Si le serveur répond par l'affirmative, Squid ira rechercher la page.

Squid est, au contraire des navigateurs, très respectueux de la validité d'une page. Il ne transgresse que très rarement les souhaits d'un serveur et jamais celui d'un client. L'avantage, c'est qu'on ne se paie jamais les résultats d'il y a trois jours pour Roland Garros (pas comme chez certains providers). L'inconvénient, c'est que certains serveurs aiment indiquer que leurs pages sont "dynamiques" et ne doivent pas être cachées afin de pouvoir maximiser le nombre de "hits" sur un bandeau publicitaire. C'est une vraie plaie. Mais c'est comme ça (Squid dispose toutefois de moyens pour filtrer ces pubs).

6. Pour aller plus loin

La FAQ de Squid est très complète et contient beaucoup de réponses à beaucoup de questions (et les réponses sont mises en correspondance avec les questions, c'est dire si ça a été bien pensé).

top

documents

home

dernière modif le 03.09.02 par Nico.

Doc originale par Vincent Bernat et Nicolas Stransky.