proxy transparent : rediriger le port 80

Pascal

27/06/2005 à 01:50

Salut,

Jean-Louis Louër a écrit :

Je souhaite mettre en place un proxy transparent avec squid sur une
machine qui sert également de desktop et donc à la consultation
internet.

Le proxy avec squidguard semble correctement configuré. Quand j'accède à
internet avec le proxy déclaré dans firefox, l'accès est bien filtré. Je
voudrais que le filtrage soit effectif sur tous les navigateurs, sans
paramètrage particulier. J'ai donc mis en place la règle iptables :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
--to-port 3128
ou bien :
iptables -t nat -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp
--dport 80 -j REDIRECT --to-port 3128

Une seule règle regroupant tous les critères suffirait.

La commande "iptables -t nat -n -L" me renvoie ceci :
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- 192.168.111.0/24 0.0.0.0/0 tcp dpt:80 redir ports 3128

^^^^^^^^^^^^^
M'étonnerait que la règle ci-dessus ait pu donner ça.

REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3128

Par contre, la redirection ne fonctionne pas et il n'y a aucun filtrage
si le port 3128 n'est pas spécifié dans les paramètres de connexion du
navigateur.

Pour la navigation depuis la machine proxy elle-même : AMA ça ne peut
pas marcher. La chaîne PREROUTING traite les paquets entrants, or il
s'agit d'une connexion sortante. Une règle similaire dans la chaîne
OUTPUT intercepterait aussi les connexions lancées par Squid lui-même.

Pour la navigation depuis les autres machines : la machine proxy
est-elle bien leur passerelle par défaut ?

--
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
with a subject of "unsubscribe". Trouble? Contact

Salut,

Jean-Louis Louër a écrit :

Je souhaite mettre en place un proxy transparent avec squid sur une
machine qui sert également de desktop et donc à la consultation
internet.

Le proxy avec squidguard semble correctement configuré. Quand j'accède à
internet avec le proxy déclaré dans firefox, l'accès est bien filtré. Je
voudrais que le filtrage soit effectif sur tous les navigateurs, sans
paramètrage particulier. J'ai donc mis en place la règle iptables :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
--to-port 3128
ou bien :
iptables -t nat -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp
--dport 80 -j REDIRECT --to-port 3128

Une seule règle regroupant tous les critères suffirait.

La commande "iptables -t nat -n -L" me renvoie ceci :
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- 192.168.111.0/24 0.0.0.0/0 tcp dpt:80 redir ports 3128

^^^^^^^^^^^^^
M'étonnerait que la règle ci-dessus ait pu donner ça.

REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3128

Par contre, la redirection ne fonctionne pas et il n'y a aucun filtrage
si le port 3128 n'est pas spécifié dans les paramètres de connexion du
navigateur.

Pour la navigation depuis la machine proxy elle-même : AMA ça ne peut
pas marcher. La chaîne PREROUTING traite les paquets entrants, or il
s'agit d'une connexion sortante. Une règle similaire dans la chaîne
OUTPUT intercepterait aussi les connexions lancées par Squid lui-même.

Pour la navigation depuis les autres machines : la machine proxy
est-elle bien leur passerelle par défaut ?

--
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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

DoMinix

27/06/2005 à 05:50

Jean-Louis Louër a écrit :

Bonjour,

Je souhaite mettre en place un proxy transparent avec squid sur une

...

Par contre, la redirection ne fonctionne pas et il n'y a aucun filtrage
si le port 3128 n'est pas spécifié dans les paramètres de connexion du
navigateur.

Qu'est ce que j'ai oublié ?

dans SQUID il faut mettre des options pour le faire fonctionner en
mode transparent.
genre:
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on

Merci

de rin

Jean-Louis Louër

--
dominix

--
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
with a subject of "unsubscribe". Trouble? Contact

Bruno Muller

27/06/2005 à 12:00

Bonjour,

Le lundi 27 juin 2005 à 01:27 +0200, a écrit :

Pour la navigation depuis la machine proxy elle-même : AMA ça ne peut
pas marcher. La chaîne PREROUTING traite les paquets entrants, or il
s'agit d'une connexion sortante. Une règle similaire dans la chaîne
OUTPUT intercepterait aussi les connexions lancées par Squid lui-même .

Bin si : squid tourne sou un utilisateur particulier, donc en ajoutant
'-m owner ! --uid-owner $SQUID_UID' dans la chaine OUTPUT ça le fait :)

Bruno

--
PLANÈTE MARRON
P : Formidable ! On a découvert de l'eau sur Mars ! Tu sais ce que ça
veut dire ?
M : Oui? Ça veut dire que dans pas longtemps l'eau de Mars sera polluée
au lisier de porc...

Jean-Louis Louër

27/06/2005 à 20:00

On Mon, Jun 27, 2005 at 11:57:52AM +0200, Bruno Muller wrote:

Bonjour,
Le lundi 27 juin 2005 à 01:27 +0200, a écrit :
> Pour la navigation depuis la machine proxy elle-même : AMA ça ne peut
> pas marcher. La chaîne PREROUTING traite les paquets entrants, or il
> s'agit d'une connexion sortante. Une règle similaire dans la chaîne
> OUTPUT intercepterait aussi les connexions lancées par Squid lui-même.
Bin si : squid tourne sou un utilisateur particulier, donc en ajoutant
'-m owner ! --uid-owner $SQUID_UID' dans la chaine OUTPUT ça le fait :)
Bruno

Bonjour,

Ce que je cherche à faire est bien un proxy transparent squid+squidguard
sur un pc isolé. Quand je fais une recherche avec "iptables" "output"
"redirect" "to-port", j'obtiens en général la syntaxe correspondant à
une passerellei, du genre :

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
--to-port 3128

J'ai essayé des syntaxes du genre :
# iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

mais évidemment ça ne marche pas. Si quelqu'un a une adresse avec des
exemples pour ce cas de figure, ça m'aiderai bien.

Merci encore
Jean-Louis Louër

--
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
with a subject of "unsubscribe". Trouble? Contact

Bruno Muller

28/06/2005 à 11:50

Bonjour,

Le lundi 27 juin 2005 à 21:59 +0200, Jean-Louis Louër a écrit :

Ce que je cherche à faire est bien un proxy transparent squid+squidguar d
sur un pc isolé. Quand je fais une recherche avec "iptables" "output"
"redirect" "to-port", j'obtiens en général la syntaxe correspondant à
une passerellei, du genre :

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
--to-port 3128

J'ai essayé des syntaxes du genre :
# iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

REDIRECT n'est applicable que dans la table nat...

mais évidemment ça ne marche pas. Si quelqu'un a une adresse avec des
exemples pour ce cas de figure, ça m'aiderai bien.

Pour commencer, un petit schéma expliquant les relations entre les
tables et les chaînes "built-in" d'un firewall Netfilter :

*<--réseau
****************************|****************************
* ______|_____ *
* |mangle | *
* |PREROUTING| *
* ======|===== *
* |nat | *
* |PREROUTING| *
* ___________ ======|===== *
* |mangle |_________: routage :_________ *
* |INPUT | :..........: | *
* =====|===== | *
* |filter | | *
* |INPUT | _____|_____ *
* =====|===== |mangle | *
* | |FORWARD | *
* /////0///// =====|==== = *
* /processus/ |filter | *
* / local / |FORWARD | *
* /////0///// =====|==== = *
* .....|..... | *
* . routage . | *
* .....|..... | *
* _____|_____ | *
* |mangle | | *
* |OUTPUT | | *
* =====|===== | *
* |nat | | *
* |OUTPUT | | *
* =====|===== | *
* |filter |______________________________| *
* |OUTPUT | | *
* =========== _______|_____ *
* |mangle | *
* |POSTROUTING| *
* =======|===== *
* |nat | *
* |POSTROUTING| *
* =======|===== Une machine *
* | ----------- *
****************************|****************************
*<--réseau

- Le paquet ce déplace du haut vers le bas.

- Il faut distinguer les paquets générés en local et les paquets
seulement routés par le firewall.

- Pour faire un proxy transparent, il faut rediriger les paquets à
destination des ports 80/443/21/... sur le port 3128 de la machine
faisant tourner squid.

- Les choses peuvent être plus ou moins complexes selon que :
- le firewall est (ou non) également proxy
- on veut (ou non) surfer à partir du firewall et/ou du proxy
Selon les cas, il faudra jouer avec différentes chaînes iptables.

- Si tu as une machine routeur/firewall/proxy à partir de laquelle il
n'y a pas besoin de surfer, cela se passe dans nat/PREROUTING.

- Si tu veux en plus pouvoir surfer (et passer pas le proxy transparent)
à partir de cette machine routeur/firewall/proxy, il faut aussi toucher
à nat/OUTPUT (et différencier les paquets venant de squid de ceux de to n
browser ; voir mon mail précédent).

- Si le proxy n'est pas sur la même machine que le firewall, il faut
toucher à mangle/PREROUTING en plus.

- ...

En espérant que ça t'aide...

Bruno

--
DARWIN
P : Un jour, le chat sera une espèce tellement évoluée... que ses
griffes disparaîtront !
M : Et vous aurez des ongles...
P : Non ! Des magnum 45 !

Bonjour,

Le lundi 27 juin 2005 à 21:59 +0200, Jean-Louis Louër a écrit :

Ce que je cherche à faire est bien un proxy transparent squid+squidguar d
sur un pc isolé. Quand je fais une recherche avec "iptables" "output"
"redirect" "to-port", j'obtiens en général la syntaxe correspondant à
une passerellei, du genre :

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
--to-port 3128

J'ai essayé des syntaxes du genre :
# iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

REDIRECT n'est applicable que dans la table nat...

mais évidemment ça ne marche pas. Si quelqu'un a une adresse avec des
exemples pour ce cas de figure, ça m'aiderai bien.

Pour commencer, un petit schéma expliquant les relations entre les
tables et les chaînes "built-in" d'un firewall Netfilter :

*<--réseau
****************************|****************************
* ______|_____ *
* |mangle | *
* |PREROUTING| *
* ======|===== *
* |nat | *
* |PREROUTING| *
* ___________ ======|===== *
* |mangle |_________: routage :_________ *
* |INPUT | :..........: | *
* =====|===== | *
* |filter | | *
* |INPUT | _____|_____ *
* =====|===== |mangle | *
* | |FORWARD | *
* /////0///// =====|==== = *
* /processus/ |filter | *
* / local / |FORWARD | *
* /////0///// =====|==== = *
* .....|..... | *
* . routage . | *
* .....|..... | *
* _____|_____ | *
* |mangle | | *
* |OUTPUT | | *
* =====|===== | *
* |nat | | *
* |OUTPUT | | *
* =====|===== | *
* |filter |______________________________| *
* |OUTPUT | | *
* =========== _______|_____ *
* |mangle | *
* |POSTROUTING| *
* =======|===== *
* |nat | *
* |POSTROUTING| *
* =======|===== Une machine *
* | ----------- *
****************************|****************************
*<--réseau

- Le paquet ce déplace du haut vers le bas.

- Il faut distinguer les paquets générés en local et les paquets
seulement routés par le firewall.

- Pour faire un proxy transparent, il faut rediriger les paquets à
destination des ports 80/443/21/... sur le port 3128 de la machine
faisant tourner squid.

- Les choses peuvent être plus ou moins complexes selon que :
- le firewall est (ou non) également proxy
- on veut (ou non) surfer à partir du firewall et/ou du proxy
Selon les cas, il faudra jouer avec différentes chaînes iptables.

- Si tu as une machine routeur/firewall/proxy à partir de laquelle il
n'y a pas besoin de surfer, cela se passe dans nat/PREROUTING.

- Si tu veux en plus pouvoir surfer (et passer pas le proxy transparent)
à partir de cette machine routeur/firewall/proxy, il faut aussi toucher
à nat/OUTPUT (et différencier les paquets venant de squid de ceux de to n
browser ; voir mon mail précédent).

- Si le proxy n'est pas sur la même machine que le firewall, il faut
toucher à mangle/PREROUTING en plus.

- ...

En espérant que ça t'aide...

Bruno

--
DARWIN
P : Un jour, le chat sera une espèce tellement évoluée... que ses
griffes disparaîtront !
M : Et vous aurez des ongles...
P : Non ! Des magnum 45 !

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Le lundi 27 juin 2005 à 21:59 +0200, Jean-Louis Louër a écrit :

Ce que je cherche à faire est bien un proxy transparent squid+squidguar d
sur un pc isolé. Quand je fais une recherche avec "iptables" "output"
"redirect" "to-port", j'obtiens en général la syntaxe correspondant à
une passerellei, du genre :

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
--to-port 3128

J'ai essayé des syntaxes du genre :
# iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

REDIRECT n'est applicable que dans la table nat...

mais évidemment ça ne marche pas. Si quelqu'un a une adresse avec des
exemples pour ce cas de figure, ça m'aiderai bien.

Pour commencer, un petit schéma expliquant les relations entre les
tables et les chaînes "built-in" d'un firewall Netfilter :

*<--réseau
****************************|****************************
* ______|_____ *
* |mangle | *
* |PREROUTING| *
* ======|===== *
* |nat | *
* |PREROUTING| *
* ___________ ======|===== *
* |mangle |_________: routage :_________ *
* |INPUT | :..........: | *
* =====|===== | *
* |filter | | *
* |INPUT | _____|_____ *
* =====|===== |mangle | *
* | |FORWARD | *
* /////0///// =====|==== = *
* /processus/ |filter | *
* / local / |FORWARD | *
* /////0///// =====|==== = *
* .....|..... | *
* . routage . | *
* .....|..... | *
* _____|_____ | *
* |mangle | | *
* |OUTPUT | | *
* =====|===== | *
* |nat | | *
* |OUTPUT | | *
* =====|===== | *
* |filter |______________________________| *
* |OUTPUT | | *
* =========== _______|_____ *
* |mangle | *
* |POSTROUTING| *
* =======|===== *
* |nat | *
* |POSTROUTING| *
* =======|===== Une machine *
* | ----------- *
****************************|****************************
*<--réseau

- Le paquet ce déplace du haut vers le bas.

- Il faut distinguer les paquets générés en local et les paquets
seulement routés par le firewall.

- Pour faire un proxy transparent, il faut rediriger les paquets à
destination des ports 80/443/21/... sur le port 3128 de la machine
faisant tourner squid.

- Les choses peuvent être plus ou moins complexes selon que :
- le firewall est (ou non) également proxy
- on veut (ou non) surfer à partir du firewall et/ou du proxy
Selon les cas, il faudra jouer avec différentes chaînes iptables.

- Si tu as une machine routeur/firewall/proxy à partir de laquelle il
n'y a pas besoin de surfer, cela se passe dans nat/PREROUTING.

- Si tu veux en plus pouvoir surfer (et passer pas le proxy transparent)
à partir de cette machine routeur/firewall/proxy, il faut aussi toucher
à nat/OUTPUT (et différencier les paquets venant de squid de ceux de to n
browser ; voir mon mail précédent).

- Si le proxy n'est pas sur la même machine que le firewall, il faut
toucher à mangle/PREROUTING en plus.

- ...

En espérant que ça t'aide...

Bruno

--
DARWIN
P : Un jour, le chat sera une espèce tellement évoluée... que ses
griffes disparaîtront !
M : Et vous aurez des ongles...
P : Non ! Des magnum 45 !

Pascal

28/06/2005 à 13:40

Bruno Muller a écrit :

Le lundi 27 juin 2005 à 21:59 +0200, Jean-Louis Louër a écrit :

mais évidemment ça ne marche pas.

Avec si peu d'information ça ne va pas être facile de trouver ce qui ne
va pas...

Pour commencer, un petit schéma expliquant les relations entre les
tables et les chaînes "built-in" d'un firewall Netfilter :

En voici un autre un peu plus complet, montrant des opérations
effectuées par Netfilter qui ne sont pas directement visibles dans les
chaînes :
http://www.plouf.fr.eu.org/bazar/netfilter/schema_netfilter.txt

[HS] On peut y constater des choses pas vraiment cohérentes (euphémisme)
concernant la gestion de la fragmentation entre Netfilter et la pile IP.

- Pour faire un proxy transparent, il faut rediriger les paquets à
destination des ports 80/443/21/... sur le port 3128 de la machine
faisant tourner squid.

- Les choses peuvent être plus ou moins complexes selon que :
- le firewall est (ou non) également proxy
- on veut (ou non) surfer à partir du firewall et/ou du proxy
Selon les cas, il faudra jouer avec différentes chaînes iptables.

[...]

- 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.

--
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
with a subject of "unsubscribe". Trouble? Contact

Bruno Muller

28/06/2005 à 14:30

Bonjour,

Le mardi 28 juin 2005 à 13:18 +0200, 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

Bruno

--
POISON
M : ROOOT !
P : C'est dégueulasse, le coca, ça fait roter !
M : C'est peut-être dégueulasse de roter, mais c'est bon signe... Si tu
rotes pas après un coca, c'est que t'es mort...

Pascal

29/06/2005 à 21:20

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
with a subject of "unsubscribe". Trouble? Contact

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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vous avez filtré cet utilisateur ! Consultez son message

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
with a subject of "unsubscribe". Trouble? Contact

proxy transparent : rediriger le port 80

8 réponses

Veuillez sélectionner un problème