Squid est un serveur mandataire (proxy en anglais). Dans les réseaux locaux, il est utilisé pour des fonctions de filtrage d’URL ou en tant que cache. Les pages web sont stockées sur le serveur local, ce qui évite d’aller les recharger plusieurs fois et permet d’économiser de la bande passante Internet. Cet article décrit l’installation et la configuration de Squid sur un serveur sous Rocky Linux 8.
La configuration présentée ici concerne les seules connexions HTTP. Le traitement des connexions HTTPS fait l’objet d’un article à part. Cette façon de procéder est motivée avant tout par un souci pédagogique, étant donné que la gestion des connexions sécurisées par Squid est passablement complexe.
Le bac à sable
Pour cet atelier pratique, j’ai installé Rocky Linux 8 sur un vieux routerboard PC Engines trouvé dans mon stock de pièces, et qui relie mon réseau local 192.168.2.0/24 (microlinux.lan) au réseau 192.168.3.0/24 (sandbox.lan) :
# nmcli con show NAME UUID TYPE DEVICE WAN 78cf5531-6940-4f74-bd34-e772edd9d0a9 ethernet enp1s0 LAN e4efd1a0-0166-418b-9cbe-00f42ee0b0cf ethernet enp2s0 ... # ip -brief addr show enp1s0 enp1s0 UP 192.168.2.251/24 # ip -brief addr show enp2s0 enp2s0 UP 192.168.3.1/24 # ip -brief route show default via 192.168.2.1 dev enp1s0 proto static metric 101 ...
Prérequis
Dans la configuration par défaut, Squid utilise le port 3128 en TCP. Il faut donc songer à l’ouvrir dans le pare-feu :
# firewall-cmd --permanent --add-service=squid success # firewall-cmd --reload success # firewall-cmd --list-all internal (active) target: default icmp-block-inversion: no interfaces: enp2s0 sources: services: dhcp dns squid ssh ports: protocols: forward: no masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules:
Installation
Squid est officiellement supporté par Red Hat Enterprise Linux et Rocky Linux. On peut donc l’installer depuis les dépôts officiels :
# dnf install -y squid
Configuration
Squid se configure par le biais du fichier /etc/squid/squid.conf, qui est quasiment prêt à l’emploi, à quelques directives près.
Notons au passage que le répertoire offre déjà un fichier identique squid.conf.default, ce qui nous évite d’effectuer une copie de sauvegarde du fichier de configuration dans son état d’origine.
J’édite ce fichier par défaut en regroupant les directives existantes et en adaptant la configuration à mon réseau. Voici à quoi cela ressemble :
# /etc/squid/squid.conf # Allow access from local network acl localnet src 192.168.3.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # Access permissions http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access allow localnet http_access allow localhost http_access deny all # Listen to port 3128 http_port 3128 # Cache size cache_mem 256 MB # Write cache to disk # cache_dir ufs /var/spool/squid 100 16 256 # Leave coredumps in the first cache dir coredump_dir /var/spool/squid # Refresh patterns refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
Cette configuration mérite quelques remarques.
- Squid peut être utilisé par toutes les machines du réseau local
192.168.3.0/24. La directiveacl localnetdéfinit une variablelocalnetqui indique l’étendue du réseau local. - Cette directive fonctionne de pair avec
http_access localnet, qui autorise toutes les machines du réseau local à utiliser le cache. Le nomlocalnetest une convention, et on est libre d’en utiliser un autre. - Dans l’exemple ci-dessus, le cache est uniquement écrit dans la RAM du serveur. La directive
cache_mempermt de définir la taille du cache. Si l’on ne souhaite pas utiliser le disque dur pour le cache, il faut s’assurer de n’utiliser aucune directivecache_dir.
Mise en service
Activer et démarrer le service :
# systemctl enable squid --now
Vérifier si Squid tourne correctement :
# systemctl status squid
● squid.service - Squid caching proxy
Loaded: loaded (/usr/lib/systemd/system/squid.service; enabled;
vendor preset: disabled)
Active: active (running) since Fri 2024-03-08 07:20:05 CET; 21s ago
Configuration manuelle du navigateur web
Lorsque Squid n’est pas utilisé comme proxy transparent, il faut procéder à une configuration individuelle des navigateurs web sur les postes clients. Pour Firefox, ouvrir Paramètres réseau et indiquer le nom d’hôte ou l’adresse IP ainsi que le port du proxy :
Vérifier le fonctionnement
Pour voir si les postes clients utilisent effectivement le proxy, on peut afficher en direct le contenu du journal /var/log/squid/access.log :
# tail -f /var/log/squid/access.log ... 716 192.168.3.2 TCP_MISS/200 2830 GET http://www.slackware.com/index.php ... 30 192.168.3.2 TCP_MISS/200 1935 GET http://www.slackware.com/faq/ ... 29 192.168.3.2 TCP_MISS/200 2116 GET http://www.slackware.com/getslack/
Pour l’instant Squid ne gère que les connexions HTTP. On prendra donc soin de tester la configuration avec des sites qui n’utilisent pas le chiffrement, comme par exemple http://www.slackware.com ou http://www.faqs.org.
Configurer Squid comme proxy transparent
Jusqu’ici, l’utilisation du proxy cache s’effectue de manière volontaire, c’est-à-dire que Squid est utilisé si les postes clients ont configuré leurs navigateurs Web en conséquence, comme nous venons de le voir. Si cette configuration n’est pas effectuée, les utilisateurs vont simplement contourner le cache.
Pour éviter cela, on va tout simplement rediriger toutes les requêtes HTTP (port 80) vers le port 3128 pour obtenir un proxy transparent. Ce qui signifie que le cache est utilisé automatiquement, sans la moindre configuration de la part de l’utilisateur. Évidemment, cela suppose que Squid tourne sur la machine qui fait office de passerelle dans le réseau local.
En théorie, il suffirait de modifier une seule ligne dans le fichier /etc/squid/squid.conf :
# Listen to port 3128 http_port 3128 transparent
Le problème, c’est que l’ajout de cette option semble provoquer un plantage :
# systemctl restart squid Job for squid.service failed because the control process exited with error code. See "systemctl status squid.service" and "journalctl -xe" for details.
Une recherche sur le message d’erreur interne mimeLoadIcon: cannot parse internal URL me montre qu’il s’agit d’un bug répertorié, mais que les ingénieurs de chez Red Hat ont manifestement oublié de corriger.
Heureusement pour nous, il existe une bidouille assez simple pour éviter ce dysfonctionnement. Squid considère qu’il a besoin d’un port HTTP « classique » (c’est-à-dire non transparent) pour fonctionner correctement. On va donc lui en fournir un, même s’il est « bidon » :
# Listen to port 3128 http_port 3128 transparent http_port 3129
Prendre en compte les modifications :
# systemctl restart squid
Cette fois-ci, Squid a redémarré correctement. Il ne reste plus qu’à rediriger les paquets IP via le pare-feu. Voici à quoi cela peut ressembler :
# firewall-cmd --permanent \ --add-forward-port=port=80:proto=tcp:toport=3128:toaddr=192.168.3.1 # firewall-cmd --reload # firewall-cmd --list-all internal (active) target: default icmp-block-inversion: no interfaces: enp2s0 sources: services: dhcp dns squid ssh ports: protocols: forward: no masquerade: yes forward-ports: port=80:proto=tcp:toport=3128:toaddr=192.168.3.1 source-ports: icmp-blocks: rich rules:
Là aussi, il faut afficher les logs « à chaud » pour voir si le proxy transparent est effectivement utilisé par les postes clients :
# tail -f /var/log/squid/access.log
Une fois qu’on a opéré la transition vers une configuration transparente du proxy, il faudra évidemment songer à supprimer la configuration manuelle du proxy dans les navigateurs web des postes clients.
Dans notre prochain article, nous nous intéresserons de plus près à la gestion des connexions HTTPS avec Squid.
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
0 commentaire