Proxy transparant Squid + bridge

Support Debian
#1

Bonjour à tous,

Je me heurte à un problème que tout technicien de SSII doit avoir : j’ai fais l’installation d’une debian etch avec Squid en proxy, un bridge sur les 2 cartes réseaux présentes et une redirection de tout le flux vers le port 3128. Cela fonctionne sans aucun problème pendant mes test au bureau, mais plus rien une fois arrivé chez le client.

Situation initiale :
Le client désire voir exactement quel site sont visités et par quel utilisateur (machine). Il dispose d’un routeur cisco dont on ne peux rien faire (ne disposant d’aucun droit d’accès) et d’un réseau local dont on ne peux pas changer les paramètres TCP/IP. Donc il faut prévoir une solution qui ne fait que s’ajouter au réseau.

Situation finale :
Installation de Squid avec la création d’un bridge afin de pouvoir intercalé la machine entre le routeur et le réseau local et intercepté les flux de données. Le réseau est en 192.168.202.0 et le routeur à pour IP 192.168.202.1. Chez le client, le proxy ping le routeur d’un coté et les machines du réseau local de l’autre. Le proxy dispose d’internet. Les machines du réseau local ping le routeur a travers le proxy mais les machines ne disposent pas d’internet.

Voici les détails de ma configuration :

  • Fichier squid.conf

[code]

Squid normally listens to port 3128

http_port 192.168.0.200:3128 transparent
visible_hostname proxybridge.benetton.com

#We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

#We recommend you to use the following two lines.
acl QUERY urlpath_regex cgi-bin ?
cache deny QUERY

Apache to signal ETag correctly on such responses

acl apache rep_header Server ^Apache
broken_vary_encoding allow apache

cache_mem 16 MB

cache_dir ufs /var/spool/squid 100 16 256
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log

emulate_httpd_log on

hosts_file /etc/hosts

refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl LAN src 192.168.17.0/24
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
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 Safe_ports port 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager

http_access allow purge localhost
http_access deny purge

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost
http_access allow LAN
http_access allow all

##########################################################

And finally deny all other access to this proxy

#http_access deny all

##########################################################

http_reply_access allow all

icp_access allow all

cache_effective_group proxy

coredump_dir /var/spool/squid[/code]

  • Le script qui me crée mon bridge et mes règles Iptables :

[code]#!/bin/sh

brctl addbr br0

brctl addif br0 eth0

brctl addif br0 eth1

ifconfig eth0 0.0.0.0 promisc up

ifconfig eth1 0.0.0.0 promisc up

ifconfig br0 192.168.202.200 netmask 255.255.255.0 up

route add default gw 192.168.202.1 dev br0

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80:65000 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80:65000 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80:65000 -j REDIRECT --to-port 3128[/code]

J’aurai besoin d’une petite aide :slightly_smiling: Merci d’avance à tous

#2

Tu as d’autres options pour intercaler ton proxy en mode routé (au cas ou le pb viendrait du bridge), comme l’utilisation d’un proxy arp, pour spoofer le cisco avec sur le coté lan de ton routeur:
sjdjweis.com/linux/proxyarp/

Mais si ça marche chez toi, c’est que la config est bonne. Qu’est ce qui a chagé entre chez toi et chez le client ?

#3

Justement, je ne dois pas faire de routage. J’ai un réseau composé comme ce qui suit :

modem ADSL ------- routeur (202.1) ----(proxy)---- Réseau local (202.0

Et mon proxy doit se caler entre le routeur et le réseau local sans changer les paramètres réseaux. Ce qui veut dire pas de routage.

Ce qui a changer entre le bureau et chez le client : adresse du bridge crée ainsi que la gw de la route par défaut(le tout dans le script de démarrage).

#4

Je te dis que le proxy arp >si besoin< peut te permettre >justement< de faire du routage, dans la situation ou te trouve, avec comme je te l’ai dit la machine que tu installe en plus qui usurpe l’identité arp (au niveau de la couche liaison OSI, avant même les questions d’ip et de routage) et joue le role de proxy du routeur cisco qui est de l’autre coté, en lui retransmettant les paquets comme si elle était à sa place et en retransmettant ce qui revient. C’est presque un fonctionnement de bridge. Si tu ne me crois pas, lis l’article que je t’ai indiqué.

Maintenant, ce n’est pas forcément nécessaire, puisque ta maquette fonctionne chez toi, mais de ce que tu me dis des différences, à moins d’avoir oublié quelquechose dans les différences de contexte en transposant auquel ni toi ni moi ne pensons (d’aprés ce que tu donnes comme éléments), pas de raison particulière que ça ne marche pas.

Ton cisco, il n’a pas de fonctionnalités de vlan (802.1Q ou ISL) ?

Quand tu actives ton bridge étape par étape, l’apprentissage lors de l’integration de l’interface vers le cisco (port X(ethY) entering learning state) se termine rapidement sans autre message ?

Sinon, pourquoi tout ce script compliqué pour monter ton bridge ?
le simple ajout dans /etc/network/interfaces de:

auto br0 iface br0 inet static bridge-ports eth0 eth1 address 192.168.202.200 netmask 255.255.255.0 gateway 192.168.202.1 up iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80:65000 -j REDIRECT --to-port 3128 up iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80:65000 -j REDIRECT --to-port 3128 up iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80:65000 -j REDIRECT --to-port 3128 est parfaitement identique.

Sinon, encore quelques remarques:
pourquoi tu rediriges tous les ports au dessus de 80 ? Squid ne gère que le protocole http et ftp, et je ne suis pas sûr qu’il gère même le ftp en proxy transparent sans frox.
D’ailleurs, tu sais que le proxy transparent interdit l’autentification et que tu n’auras que l’adresse ip comme info ? Si le réseau est en dhcp, ça va pas donner grand chose de savoir de quelle ip ça vient, sauf à rapprocher les logs du dhcp avec les heures de visites fournies par les logs de squid.

pourquoi tu mets des règles sur les eth participant au bridge ? Elles n’existent plus quand le bridge se monte. A la limite, ça peut valoir le coup de mettre une règle moins restrictive (une seule règle REDIRECT vers le port squid, mais sans préciser par quelle interface ça rentre avec le -i).

Pour finir, bêtement, les trucs simples:

  • tu es certain que l’adresse .200 est libre ?
  • les cables sont vérifiés, tu as bien les loupiottes des cartes qui s’allument ?
    :smt003
#5

Au fait, ta liaison avec le cisco est sur un hub ou avec un cable croisé ? Tu es bien sûr d’avoir pris un cable croisé pour ta connection, sinon ?
Enfin j’imagine que si tu as fait l’experience chez toi, tu as dû reproduire le cablage…

#6

Alors pour te répondre étape par étape (j’espere ne pas oublier de détails) :

  • je suis certain du fonctionnement des cartes réseaux sachant que les ping s font dans tous les sens sans problème.
  • le bridge passe effectivement en learning mode et ensuite en forwarding mode (je sais pas si c’est bon signe)
  • ensuite la redirection de toutes les cartes réseaux est une sécurité que mon collegue a voulu que je mette et la redirection des ports au dessus de 80 est lié a l’explication qui suit :

la société est une multinationale dont je je citerai pas le nom qui est italienne a la base. Elle a un VPN mondiale ou tous les pays se connecte. Le matériel est inconnu au battaillon, sachant qu’on a aucune information pour s’y connecter, ou pour voir les parametres. On ne pas pas également quel est le fournisseur internet, ni quel systeme (vlan, ou autre) sont utilisé. Tout ce qu’on connait est l’adressage réseau, et on m’a demandé de faire avec :frowning:

Voila un pe la situation, j’espere que tu vois un peu le foutoire. Je n’ai le droit de toucher a RIEN. L’italie ne répond pas, elle ne donne aucune info (surement par mesure de securité) donc je dois arrivé avec un boitier, le brancher et faire comme si de rien était.

Je commence a me demander s’il serait pas mieux que je prenne un bon switch qui ferait lui meme des analyses de trames et des logs.

#7

C’est dur de devoir remettre en cause le cablage ou les parametres TCP/IP quand le ping passe des 2 coté :
proxy ===> routeur
proxy ===> machine du Lan
machine du Lan ===> proxy

#8

ben tu peux sniffer avec … zut, grave trou. je ne retrouve plus le nom de celui que j’utilise d’habitude, c’est un classique.
Bon, tu en as quelques autres:

roc@ROC:~/tmp$ aptitude search snif p dsniff - Divers outils pour écouter le trafic réseau pour des insécurités de texte en cl p imsniff - Simple program to log Instant Messaging activity on the network i ksniffer - Analyseur de trafic réseau pour KDE p libphp-phpsniff - a HTTP_USER_AGENT Client Sniffer for PHP p php-codesniffer - tokenises PHP code and detects violations of a defined set of coding standards p sniffit - packet sniffer and monitoring tool
Mais pour les vlan, à priori, si tu pinge le cisco…

Sinon, machine du lan ===> routeur (si tu as activé le forwarding) ?

Par ailleurs, rediriger autrechose que le port 80 et les ports ftp et ftp-data éventuellement ne sert à rien, et va savoir, même ça peut gèner. Si tu veux que ça marche, débloques.

Pour finir, tu as toujours l’option du proxy arp.

#9

justement Lan ===> routeur sa fonctionne !! mais meme en entrant les parametres du proxy en dur, y’a rien.

Je vais jeter un coup d’oeil au proxu arp mais je manque de temps, on m’a mis sur 1 milliard de projet de ce type. Sympa ma premiere semaine de boulot dans cette boite…

#10

Il y a juste une ambiguité: quand je dis lan->routeur, je parle du routeur cisco. Tu dis bien que ça ping ?

Petite question: si tu essayes >depuis le proxy< d’accèder à une page web extérieure avec un browser, en utilisant le squid comme proxy dans ton browser, ou pas est ce que ça fonctionne ?

#11

effectivement, je ping bien le routeur DEPUIS le lan et donc a TRAVERS le proxy. Mais les machines du lan n’ont pas acces à internet. Par contre, en testant un wget, j’ai pu télécharger un fichier sans probleme, donc accès a internet.

Je n’avais pas mis d’interface graphique sur la machine, et je n’ai pas pu couper longtemps mes clients du réseau internet.

#12

Ben puisque tu pingue au travers, si tu n’actives pas la redirection par le proxy transparent, les machines de ton réseau fonctionneront comme avant sans savoir que ton proxy est au milieu, et tu pourra faire tes tests en attaquant par le 3128.
Sinon, ton wget, tu l’as tenté en utilisant le proxy, et sans ?

Et encore une question idiote: tu as reconfiguré tes clients en leur disant que la gateway etait le .200 au lieu du .1 ?

Parceque si tu dois le faire pour 100 machines, je te conseille plutôt d’étudier la mise en place du proxy arp :smt005

#13

le wget je l’ai fait sur le proxy lui meme.

Concernant le changement de gw pour les machines : je ne dois justement pas toucher a leur configuration, d’ou le faite de faire un proxy transparent.

#14

Même à une, pour voir si ça vient de là ?
Parceque si c’est le cas (et ça sent bon de ce coté là je pense), tu te retrouve à devoir cette fois obligatoirement un proxy arp. Un peu de théorie en plus à te taper, mais aprés, tu connaitra mieux l’arp et le fonctionnement de la couche liaison :wink:

Sinon, je t’avoue que je ne vois plus trop ou peut se situer le problême.

#15

Salut,

# Squid normally listens to port 3128 http_port 192.168.0.200:3128 transparent
Si l’adresse de la machine est 192.168.202.200, ça risque de beaucoup moins bien marcher.

[quote=“dinomoi”]la redirection des ports au dessus de 80 est lié a l’explication qui suit :

la société est une multinationale dont je je citerai pas le nom qui est italienne a la base. Elle a un VPN mondiale ou tous les pays se connecte. Le matériel est inconnu au battaillon, sachant qu’on a aucune information pour s’y connecter, ou pour voir les parametres. On ne pas pas également quel est le fournisseur internet, ni quel systeme (vlan, ou autre) sont utilisé. Tout ce qu’on connait est l’adressage réseau, et on m’a demandé de faire avec :frowning:[/quote]
Je ne vois pas le rapport avec la redirection de tous les ports au-dessus de 80, et je suis d’accord avec Matt.

#16

Tout ça pour ça. Toujours l’oeil vif, PascalHambourg, quand tu nous survoles. :mrgreen:

#17

En même temps c’était seulement dans la deuxième ligne du fichier de conf, je n’ai pas de mérite.

J’en profite pour clamer haut et fort que faire de la redirection de port ou tout autre forme de NAT avec iptables sur un pont est une bidouille immonde.

#18

Sauf quand tu manques d’IPs, et que tu veux faire un proxy transparent.

#19

J’insiste : peu importe la justification, ça reste une bidouille immonde.
De même qu’en généralisant, on peut aussi dire que le NAT dans son ensemble est une bidouille immonde, quelle que soit son utilité et sa justification. Mais sur un pont, c’est pire.

Quant au manque d’IP, je regrette mais il en faut au moins une pour le pont, et ta solution avec proxy ARP ne demande pas plus d’adresses IP en évitant le recours à un pont. Ceci dit, le proxy ARP est aussi une bidouille bien crade.

#20

Mais pourquoi tu dis ça ? Bon, pour le proxy arp, je suis d’accord que c’est super tiré par les cheveux, et qu’il faut vraiment maitriser pour comprendre. Pour le NAT (ou pire, je sais que tu déteste encore plus, le masquerading), c’est OK il y a une charge de traitement ajoutée, et des délais avec.
Mais en quoi tu trouves ça “crade” ?
Et puis quand tu n’as pas le choix, tu n’as pas le choix.