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>.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
