Vous n'êtes pas identifié(e).
L'icône rouge permet de télécharger chaque page du wiki visitée au format PDF et la grise au format ODT →
Ceci est une ancienne révision du document !
Voir : le site de squid
proxy transparent
Voir aussi : http://www.sput.nl/software/squid33.html
http://www.linux-france.org/prj/edu/archinet/systeme/ch40s02.html
Lorsqu'un serveur mandataire est installé, on configure souvent le routage du réseau pour que l'utilisateur final soit orienté vers le serveur mandataire sans avoir à modifier sa configuration. On parle alors de « proxy transparent ». Cette configuration est obtenue par translation d'adresse IP.
Un serveur DNS est installé sur la passerelle.
La passerelle est mise en place avec masquerade :
(eth0 est la carte ethernet vers le web)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 iptables -t mangle -A PREROUTING -p tcp --dport 3128 -j DROP
Voir un autre exemple : http://sourcelinux.wikidot.com/setting-up-squid-in-gateway-as-a-transparent-proxy
Pour mangle, une petite citation extrait du site officiel de squid :
Due to the NAT security vulnerabilities it is also a very good idea to block external access to the internal receiving port. This has to be done in the mangle part of iptables before DNAT happens so that intercepted traffic does not get dropped.
iptables-save > /etc/iptables.squid echo "post-up iptables-restore < /etc/iptables.squid" >> /etc/network/interfaces
La première ligne est probablement déjà configurer tel que ce-dessous. Modifier aussi la seconde
# Controls IP packet forwarding net.ipv4.ip_forward = 1 # Controls source route verification net.ipv4.conf.default.rp_filter = 0
sysctl -p
apt-get install squid3
apt-get build-dep squid3
Squid permet options et modules :
Néanmoins un proxy transparent permettra de ne rien avoir à configurer dans le navigateur du client qui “ignorera” qu'il passe par un proxy quand il navigue. Cela place donc hors sujet la question l'accès par login et mot de passe…
Le fichier est commenté quasiment entièrement, et contient tous les paramètres de lancement de Squid ainsi qu’une description très complète de chacun d’eux.
C'est très important pour la suite !
cp /etc/squid3/squid.conf /etc/squid3/squid.conf_back
On supprime toutes les lignes commentées et vides du fichier original, et on le recrée afin qu'il contienne uniquement les lignes du fichier original dé-commentées par défaut.
echo "`grep -v "^#" /etc/squid3/squid.conf | sed -e '/^$/d'`" >/etc/squid3/squid.conf
Rappel de la configuration:
eth0 (vers internet) : 192.168.0.1
eth1 (vers lan) : 192.168.1.1
acl localnet src 192.168.1.0/24
: le réseau qui doit avoir accès au serveur proxy
acl lan src 192.168.0.1 192.168.1.0/24
: Liste de contrôle : le lan seulement utilise squid
http_access allow localhost
: accès à squid permis au localhost
http_access allow lan
: idem
http_port 3128
: “http_port 3128” devient “http_port 3128 transparent”
access_log /var/log/squid3/access.log squid
: le fichier de log est commenté, on récupère la ligne dans le fichier sauvegardé et on l'ajoute.
On récupère le concernant, et on l'ajoute aussi dans le fichier /etc/squid3/squid.conf
less /etc/squid3/squid.conf
acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl localnet src 192.168.0.0/24 # RFC1918 possible internal network 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 acl lan src 192.168.0.1 192.168.1.0/24 http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access allow localnet http_access allow lan http_access deny all http_port 3128 transparent #hierarchy_stoplist cgi-bin ? cache allow LocalNet #cache deny QUERY # MEMORY CACHE OPTIONS #Default: #cache_mem 256 MB cache_mem 8 MB #Default: maximum_object_size_in_memory 256 KB #memory_replacement_policy lru # DISK CACHE OPTIONS # Décommentez et régler les éléments suivants pour ajouter un répertoire de cache disque: cache_dir ufs /var/spool/squid3 100 16 256 #Default: #store_dir_select_algorithm least-load # A value of 0 indicates no limit. #Default: max_open_disk_fds 0 # TAG: minimum_object_size (bytes) # Objects smaller than this size will NOT be saved on disk. The # value is specified in kilobytes, and the default is 0 KB, which # means there is no minimum. #Default: minimum_object_size 0 KB #Default: maximum_object_size 10 KB # LOG_FILE OPTIONS #Default: access_log /var/log/squid3/access.log squid #Default: cache_log /var/log/squid3/cache.log # Leave coredumps in the first cache dir #coredump_dir /var/spool/squid3 # OPTIONS FOR TUNING THE CACHE cache allow all 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 hosts_file /etc/hosts
Avec squid3 le cache n'est pas activer.
Pour l'activer, il va falloir aller chercher dans le fichier original ce qui concerne la mise en cache !
En voilà un résumé
http_port
: permet de définir le port sur lequel se lance Squid.
Par défaut, Squid se lance sur le port 3128. Il est également possible de définir plusieurs ports.
http_port 3128 8080
cache_dir
: permet d’indiquer où stocker les données mises en cache sur le disque.
Squid est conçu pour travailler en mémoire afin de charger plus rapidement les données mises en cache.
Toutefois, lorsque la mémoire est insuffisante ou que le serveur doit être stoppé, Squid va basculer les données en cache mémoire sur le disque afin de pouvoir en charger d’autres ou les recharger par la suite.
Pour mettre en place cette politique de remplacement des données en cache lorsque la mémoire est insuffisante, (algorithme de type LRU (Least Recently Used)), il faut utiliser l’option cache_dir qui permet de spécifier au serveur où stocker les données de cache sur le disque et de quelle façon.
Le premier argument correspond à l’emplacement disque, le second à l’espace alloué (100 Méga-octets dans l’exemple ci-dessous), le troisième au nombre de répertoires racine, et le dernier au nombre de sous-répertoires. Cette arborescence permet de constituer un index rapide d’accès.
Par exemple :
cache_dir ufs /usr/local/squid/var/cache/ 100 16 256
“Remarque : Le type ufs de magasin:
“ufs” est l'ancien format de stockage Squid bien connu qui a toujours été là.”
http_access
, icp_access
: permettent de restreindre l’accès HTTP et ICP en spécifiant des règles de contrôle d’accès (ACls pour access control lists).
Chaque requête HTTP ou ICP provoque la vérification de ces règles d’accès. Cet aspect lié à la sécurité est un des points très importants dont il faut se soucier dès l’installation et la mise en route de Squid.
Ci-dessous les paramètres par défaut contenus dans le fichier de configuration qui restreignent l’utilisation du serveur au poste local :
acl localhost src 127.0.0.1/32
http_access allow localhost
http_access deny all
Concernant la mise en cache les résolutions DNS :
positive_dns_ttl
: permet de définir la limite supérieure au-delà de laquelle le serveur invalidera une résolution DNS positive mise en cache.
Par défaut cette option est positionnée à 6 heures (360 minutes). Cette valeur doit être plus grande que celle de l’option negative_dns_ttl.
negative_dns_ttl
: permet de définir la durée pendant laquelle une résolution DNS négative sera gardée en cache. La valeur minimale est de 1 seconde et il n’est pas recommandé d’aller au-delà de 10 secondes.
Concernant l'affichage des traces de debug :
log_mime_hdrs
: permet d’afficher les en-têtes HTTP des requêtes et des réponses dans les logs d’activité.
debug_options
: cette option permet d’afficher les différentes informations de debug de Squid. Le système de log du serveur est décomposé en sections. Il est donc possible de paramétrer le niveau de log de chacune de ces sections en fonction de ce que l’on souhaite étudier.1) Voici une configuration qui permet d’avoir un peu plus d’informations sur les traitements réalisés par Squid en interne 2) :
debug_options ALL,1 17,2 55,2 56,2 57,2 58,2
section 17 Request Forwarding 2
section 55 HTTP Header 2
section 56 HTTP Message Body 2
section 57 HTTP Status-line 2
section 58 HTTP Reply (Response) 2
#Default:
# cache_mem 256 MB
#Default:
# maximum_object_size_in_memory 512 KB
# Décommentez et régler les éléments suivants pour ajouter un répertoire de cache disque:
#cache_dir ufs /var/spool/squid3 100 16 256
#Default:
# store_dir_select_algorithm least-load
# A value of 0 indicates no limit.
#Default:
# max_open_disk_fds 0
# TAG: minimum_object_size (bytes)
# Objects smaller than this size will NOT be saved on disk. The
# value is specified in kilobytes, and the default is 0 KB, which
# means there is no minimum.
#Default:
# minimum_object_size 0 KB
#Default:
# maximum_object_size 4096 KB
cache
: pour déterminer l'utilisation du cache
cache allow LocalNet
; elle doit remplacerno_cache
# cache_mem 256 MB
#cache_dir ufs /var/spool/squid3 100 16 256
⇒ La définition de la mémoire cache (256 MB) serait plus large que l'espace disque défini (100MB) !
Donc attention en dé-commentant !
df -h /var Sys. fich. Taille Util. Dispo Uti% Monté sur /dev/mapper/systeme-var 2,8G 1,0G 1,7G 39% /var
>cache_dir ufs /var/spool/squid3 100 16 256
Et quand on re-démarre squid3 :
/etc/init.d/squid3 restart
2014/10/17 16:29:49| Creating Swap Directories 2014/10/17 16:29:49| /var/spool/squid3 exists 2014/10/17 16:29:49| Making directories in /var/spool/squid3/00 2014/10/17 16:29:49| Making directories in /var/spool/squid3/01 2014/10/17 16:29:49| Making directories in /var/spool/squid3/02 2014/10/17 16:29:49| Making directories in /var/spool/squid3/03 2014/10/17 16:29:49| Making directories in /var/spool/squid3/04 2014/10/17 16:29:49| Making directories in /var/spool/squid3/05 2014/10/17 16:29:49| Making directories in /var/spool/squid3/06 2014/10/17 16:29:49| Making directories in /var/spool/squid3/07 2014/10/17 16:29:49| Making directories in /var/spool/squid3/08 2014/10/17 16:29:49| Making directories in /var/spool/squid3/09 2014/10/17 16:29:49| Making directories in /var/spool/squid3/0A 2014/10/17 16:29:49| Making directories in /var/spool/squid3/0B 2014/10/17 16:29:49| Making directories in /var/spool/squid3/0C 2014/10/17 16:29:49| Making directories in /var/spool/squid3/0D 2014/10/17 16:29:49| Making directories in /var/spool/squid3/0E 2014/10/17 16:29:50| Making directories in /var/spool/squid3/0F . ok
/etc/init.d/squid3 stop
(S'il vous plaît servez-vous de l'auto-complétion, surtout ici)
cd /var/spool/squid3/
rm -rv 0*
rm -v swap.state*
/etc/init.d/squid3 start
Dans le fichier de configuration /etc/squid3/squid.conf :
Pour vérifier que le sous-réseau qui est connecté au web via la passerelle, passe bien de même par le proxy.
Il faut :
Tout bêtement, de côté du lan, on navigue !
le fichier /var/log/squid3/access.logdes logs d'accès :
tail -f /var/log/squid3/access.log
Puis côté du Lan, on navigue, il y a alors du mouvement de le fichier de log :
1413554295.061 138 192.168.1.2 TCP_MISS/200 13345 GET http://debian-facile.org/ - DIRECT/212.129.32.102 text/html 1413554295.098 36 192.168.1.2 TCP_MISS/200 8320 GET http://debian-facile.org/style/Kao.css - DIRECT/212.129.32.102 text/css 1413554295.108 59 192.168.1.2 TCP_MISS/200 950 GET http://debian-facile.org/nono.css - DIRECT/212.129.32.102 text/css <...> 1413554299.083 32 192.168.1.2 TCP_MISS/200 554 GET http://debian-facile.org/style/Air/img/asterisk.png - DIRECT/212.129.32.102 image/png 1413554301.463 74 192.168.1.2 TCP_MISS/200 1391 POST http://debian-facile.org/login.php? - DIRECT/212.129.32.102 text/html <...>
Ci-dessus, nous avons observé que les connexions passaient par le proxy.
Pour vérifier que squid sert au client une page de son cache, il faut visiter le même URL plusieurs fois.
La 1ère fois on a normalement dans /var/log/squid3/access.log, TCP_MISS
, mais après on doit obtenir TCP_HIT
.
On peut trouver d'autres indications :
Se connecter plusieurs fois et tenter la commande :
tail -f /var/log/squid3/cache.log | grep TCP_HIT
Server: ECS (cdg/D62E)\r\nX-Cache: HIT\r\nContent-Length: 471\r\n\r] 1413884011.978 66 192.168.1.2 TCP_MISS/200 919 POST http://ocsp.digicert.com/ - DIRECT/93.184.220.29 application/ocsp-response [Host: ocsp.digicert.com\r\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.2.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nAccept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3\r\nAccept-Encoding: gzip, deflate\r\nDNT: 1\r\nContent-Length: 83\r\nContent-Type: application/ocsp-request\r\nConnection: keep-alive\r\n] [HTTP/1.1 200 OK\r\nAccept-Ranges: bytes\r\nCache-Control: max-age=514328\r\nContent-Type: application/ocsp-response\r\nDate: Tue, 21 Oct 2014 09:32:42 GMT\r\nETag: "5445fdee-1d7"\r\nExpires: Mon, 27 Oct 2014 21:32:42 GMT\r\nLast-Modified: Tue, 21 Oct 2014 06:32:14 GMT\r\nServer: ECS (cdg/4484)\r\nX-Cache: HIT\r\nContent-Length: 471\r\n\r]
On trouve dans ce fichier beaucoup d’informations allant du nombre de descripteurs de fichiers ouverts jusqu’à la mémoire allouée. Il est possible de se référer à la documentation officielle pour obtenir plus de détails sur ce fichier.
2014/10/16 13:11:45| Process ID 3735 2014/10/16 13:11:45| With 65535 file descriptors available 2014/10/16 13:11:45| Initializing IP Cache... 2014/10/16 13:11:45| DNS Socket created at [::], FD 7 2014/10/16 13:11:45| DNS Socket created at 0.0.0.0, FD 8 2014/10/16 13:11:45| Adding domain mondomaine.hyp from /etc/resolv.conf 2014/10/16 13:11:45| Adding domain mondomaine.hyp from /etc/resolv.conf 2014/10/16 13:11:45| Adding nameserver 127.0.0.1 from /etc/resolv.conf 2014/10/16 13:11:45| Adding nameserver 192.168.0.1 from /etc/resolv.conf 2014/10/16 13:11:45| Adding nameserver 212.27.40.240 from /etc/resolv.conf 2014/10/16 13:11:45| Adding nameserver 212.27.40.241 from /etc/resolv.conf 2014/10/16 13:11:45| Unlinkd pipe opened on FD 13<...>
On y retrouve tous les accès faits au serveur, c’est-à-dire toutes les requêtes HTTP reçues et la façon dont elles ont été traitées. Le format de ce fichier est paramétrable via l’option access_log du fichier squid.conf. Le format natif d’une entrée de log est le suivant :
time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type
time
: le temps UTC (en ms) auquel la requête a été reçue.
elapsed
: le temps de traitement par le serveur de la requête (en ms). Ce temps de traitement diffère selon le mode utilisé (connecté ou déconnecté) :
remotehost
: l’adresse IP du client. Cette donnée peut être cachée pour rendre les logs anonymes.
code/status
: le code résultat de la transaction. Ce champ est composé de deux entrées séparées par un slash : le code de statut de Squid et le code HTTP de la réponse du serveur d’origine. La plupart de ces codes sont détaillés plus bas.
bytes
: la taille de la donnée livrée au client.
method
: la méthode utilisée pour récupérer la ressource (GET, HEAD, etc.).
URL
: l’URL de la ressource demandée.
rfc931
: les informations utilisateurs (désactivé par défaut).
hierarchy code
: un code permettant de savoir comment la requête a été traitée. Ce code peut être suivi par l’adresse IP vers laquelle la requête a été redirigée.
type
: le type de contenu issu du header HTTP de la réponse (Les échanges ICP ne contiennent pas cette information).