Proxy transparent

par **WilliamG** » 17 Déc 2009 18:28

Bonjour,

J'utilise le proxy transparent de l'IPCOP et un VPN IPCOP entre deux sites. Je n'arrive pas à accéder aux applications Web qui sont sur le port 80. Les autres applications web qui sont sur d'autres ports sont accessibles.

Avez-vous une solution ?

William

par **policeip** » 17 Déc 2009 19:19

Un proxy transparent NE FONCTIONNE QU'AVEC http... C'est pour ça que tes autres applications sur d'autres ports restent accessibles !
Ensuite, le proxy d'IpCop utilise le port 800. Donc...

Quoi qu'il en soit, et pour citer jdh et d'autre, un proxy est mal placé sur un firewall !

par **jdh** » 17 Déc 2009 20:20

J'ai voulu répondre mais je ne veux pas écrire de bêtises.

Le problème gagnerait à être précisé : qui fait quoi et quel message ?
- qui : quels micros ? ou sont -ils placés ?
- fait quoi : accèdent à quel serveurs ? qui sont placés ou ? avec quels ports ?
- message : y a-t-il un message ?

Effectivement un proxy est mal placé et effectivement en transparent cela ne fonctionne que pour http (et sans authentification).

Mais il faut de plus comprendre comment un proxy transparent fonctionne :
-1, il faut quelques lignes supplémentaires dans la config de Squid pour qu'il puisse aussi fonctionner en transparent.
-2, il faut une règle (iptables) de redirection.

Si la règle est mal écrite .. cela peut ne pas bien fonctionner ...

Sinon policeip donne une bonne piste : pourquoi ne pas configurer le poste client avec un proxy défini, et voir ce qu'il se passe ...

par **WilliamG** » 17 Déc 2009 21:13

Je complète ma question :

J'utilise 2 IPCOP pour créer un VPN entre deux sites. J'ai activé la fonctionnalité proxy sur mes deux IPCOP et j'ai activé également le mode transparent.

Depuis le site 1, je ne peux pas accéder aux applications web qui sont hébergées sur un serveur du site 2. Le ping fonctionne mais impossible d'atteindre l'application. exemple : http://xxx.xxx.xxx.xxx/nom de l'application
En revanche, je peux accéder aux applications des autres serveurs hébergés sur le site 2 car ce n'est pas le port 80 qui est utilisé. Exemple : http://xxx.xxx.xxx.xxx.:numéro du port.

J'espère avoir été plus précis.

par **Franck78** » 17 Déc 2009 23:49

c'est parfaitement clair.
Mais ca demanderait a être finement 'tracé' sur IPCop:

pourquoi la requète 'http' sortant de squid (si elle en sort) ne prend
pas la route 'vpn' par ipsec.

Et si par hazard elle empruntait correctement le vpn, même combat de l'autre coté.

un bon exercice de tcpdump ou de lecture du code ipcop ou des acl squid en somme.

Soit un bug soit un cas non rencontré (et facile à fixer).

par **WilliamG** » 18 Déc 2009 11:08

Ce sont bien les applications web qui sont sur le port 80 qui sont inaccessibles. Quand je réalise un VPN entre un IPCOP et un routeur cela fonctionne bien. Le problème se situe bien au niveau de l'IPCOP.

par **jdh** » 18 Déc 2009 11:28

Franck78 (qui connait dans les moindres détails Ipcop) donne une idée d'analyse qu'il faudrait explorer ...

Sur le site 2, le trafic http sortant (et venant de Green) est redirigé sur le proxy (2).
Le proxy doit alors accéder au vrai serveur ... en passant donc par le tunnel ipsec.
Sur le site 1, si la règle de redirection n'est pas correcte (de mon point de vue), il est possible que le trafic soit à nouveau redirigé sur le proxy (1), qui peut lui ne pas pouvoir traiter ...

En tout état de cause, il faut tracer ce qu'il se passe :
- tail -f (...)access.log : pour voir en temps réel ce qui est traité par les proxy Squid
- tcpdump -ln -i eth? 'port 80' : pour voir en temps réel les flux

Sans analyse, pas de solution ...

Perso, je regarderais les règles précises de redirection par "iptables -vn -L" (avec peut être "-t nat"). La logique serait que ces règles fussent conditionnées par l'interface de départ ...

par **WilliamG** » 18 Déc 2009 12:55

Voici l'analyse de la commande : tcpdump -i eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
11:49:01.074612 IP MFLA218.localdomain.c1222-acse > xxx.xxx.xxx.xxx.http: S 956909519:956909519(0) win 65535 <mss 1460,nop,nop,sackOK>
11:49:03.965884 IP MFLA218.localdomain.c1222-acse > xxx.xxx.xxx.xxx.http: S 956909519:956909519(0) win 65535 <mss 1460,nop,nop,sackOK>
11:49:10.001114 IP MFLA218.localdomain.c1222-acse > xxx.xxx.xxx.xxx. http: S 956909519:956909519(0) win 65535 <mss 1460,nop,nop,sackOK>

par **jdh** » 18 Déc 2009 21:51

Je crois que cela ne va pas avancer vite ...

Il faut agir à TOUS les niveaux : là il y a un tcpdump (sans le -n) sur le premier icop. Ca ne suffira pas pour tracer ! Tracer cela veut dire suivre à la trace, c'est à dire pas à pas ...

par **Franck78** » 19 Déc 2009 01:17

qui connait dans les moindres détails Ipcop)

cela s'évapore petit à petit quand même!

Cette trace indique qu'il n'y a pas de réponse. Point. Il faut le faire 'partout': ppp0? ipsec0?

Proxy transparent

Proxy transparent

Qui est en ligne ?