Bruno Muller a écrit :
- Si le proxy n'est pas sur la même machine que le firewall, il faut toucher à mangle/PREROUTING en plus.Pourrais-tu développer ce dernier point STP ? Même si cette situation ne rentre pas dans le cadre de la demande initiale, c'est pour ma culture personnelle.Je n'ai pas vraiment le temps de détailler maintenant, mais tu trouveras des infos dans le paragraphe 6.2 de http://www.tldp.org/HOWTO/TransparentProxy-6.html
Merci, c'était suffisant comme point de départ pour creuser. :)Voici ce que j'en retiens : le but du recours à la chaîne mangle sur le firewall est de marquer les paquets HTTP avec une règle MARK afin de leur appliquer une routage spécifique vers le proxy avec iproute sans devoir faire de NAT destination (DNAT).
Deux observations toutefois.1) Ce n'est nécessaire que dans un cas bien particulier : quand les requêtes sont à l'ancien format HTTP/1.0 sans en-tête "Host" spécifiant le nom de domaine du site cible. Dans ce cas l'adresse IP destination d'origine est la seule information permettant d'identifier le serveur cible. Cependant, à l'heure actuelle tout client HTTP digne de ce nom doit être capable de formuler des requêtes au format HTTP/1.1 avec l'en-tête Host. Autrement il serait incapable d'accéder aux sites web mutualisés hébergés sur un même serveur, qui sont légion. Or avec l'en-tête Host dans la requête, la connaissance de l'adresse destination d'origine de la connexion TCP n'est pas nécessaire pour que Squid puisse relayer la requête puisque le nom de domaine du site cible permet de la retrouver. Utilité marginale, donc.
2) Le HOWTO néglige de mentionner un détail important AMA : Ne pas faire de DNAT sur le firewall n'est pas suffisant. En effet, pour que les requêtes HTTP, une fois reçues par la machine proxy, arrivent au processus local Squid, on a toujours besoin de la classique règle iptables REDIRECT dans la chaîne PREROUTING de la machine proxy. Or la cible REDIRECT modifie automatiquement l'adresse destination (on peut dire que c'est à la cible DNAT ce que MASQUERADE est à SNAT). Comme dans la méthode du § 6.1, Squid reçoit donc les connexions HTTP avec une adresse de destination différente de l'adresse réelle du serveur cible. Afin que Squid puisse retrouver cette adresse telle qu'elle était avant d'être modifiée par Netfilter, il doit avoir été compilé avec l'option spéciale "--enable-linux-netfilter". Cf. le point 17.4 "Interception caching with Linux 2.4 and netfilter" de la FAQ de Squid <http://www.squid-cache.org/Doc/FAQ/FAQ-17.html#ss17.4> (note: la FAQ fournie avec le paquetage Squid de Sarge est moins à jour que sur le site). D'après usr/share/doc/squid/README.Debian.gz, le paquetage Squid de Debian Sarge est bien compilé avec cette option. Effectivement ça marche en local avec ma Sarge, les requêtes HTTP/1.0 sans Host interceptées par la règle iptables REDIRECT sont bien relayées.
Je ne sais pas comment cela fonctionne, je ne peux que supposer que cette option permet à Squid d'avoir accès à la table de suivi des états de connexions de Netfilter, par exemple par /proc/net/ip_conntrack qui contient les adresses avant et après NAT pour chaque connexion suivie.
Voilà, tout ça était peut-être évident pour tout le monde mais pas pour moi. :-D
P.S. à Jean-Louis si tu lis toujours ce fil : au cours de mes lectures j'ai vu que des règles iptables applicables à ton cas étaient exposées au point 17.17 de la FAQ de Squid, "Interception on Linux with Squid and the Browser on the same box" <http://www.squid-cache.org/Doc/FAQ/FAQ-17.html#ss17.17>.