Tunnel SSH et squid3

Support Debian
#1

Bonjour,

Squid3 en mode transparent ne semble pas intercepter les requettes http quand je me connecte sur mon serveur_chez_moi de l’extérieur via un tunnel SSH.
le circuit est le suivant :
Poste de travail distant(pas forcement au bouleau)–>Tunnel SSH–>monserveur–>navigation sur Internet.
La connexion fonctionne puisque j’arrive à naviguer sur Internet en passant par monserveur. Mais, pourquoi, il ne passe pas par squid ?
Le poste distant utilise Putty. ssh est configuré evec L’option D. Je fais faire les reqsuettes DNS à mon serveur, histoire de ne pas laisser de trace sur le serveur qui est dans le LAN où se trouve la station de travail…
Firefox est configuré pour utiliser le proxy socks v5.
Du coté monserveur_chez_moi, c’est le démon SSHD qui fait office de proxy socks et génère les resquettes comme si elle venait de monserveur même. Est ce la raison pour que squid en mode transparent ne les intercepte pas ?

Merci de votre aide.

#2

Comment fonctionne l’interception des paquets HTTP vers squid ? Avec des règles iptables ? Dans la chaîne PREROUTING, je suppose ? Les paquets émis par la machine elle-même ne passent pas dans cette chaîne mais dans la chaîne OUTPUT, il faut donc y dupliquer les règles d’interception.
Accessoirement,

  1. Quel est l’intérêt de passer par squid ?
  2. Si tu tiens absolument à passer par squid, pourquoi utilises-tu le proxy SOCKS de SSH plutôt que le proxy HTTP de squid explicitement dans ton navigateur ?
#3

Merci de ta réponse.

L’intérêt de passer par squid qui par ailleurs est chaîné à privoxy c’est d’augmenter quelque part le débit.
Ces deux proxy filtre un tas de choses que je ne veux pas forcément voir à l’écran et qui consomment quoi qu’il arrive de la bande passante. D’autant plus que le débit montant est déjà faible.

J’utilise socks v5 car c’est un bon moyen de faire passer dans le tuyeau SSH les requettes DNS. C’est mon serveur qui les traitera. Dans l’autre cas, le navigateur du dit poste de travail fera la requette à son serveur DNS et c’est ce que je veux éviter.

Il me semble que dans le passé, j’arrivais à faire passer par squid. La seule différence est que squid n’était pas en mode transparent.

Squid en mode non transparent peut écouter sur plusieurs ports.
Squid en mode transparent peut écouter sur un seul port.
Est ce qu’il n’y a pas un rapport avec ça ?

L’interception des packets par squid est faite par une redirection du firewall de toutes les requettes HTTP vers le port 3128. Si de commente cette redirection dans le firewall, les stations du LAN ne pourront pas naviguer sur le net.

#4

Quand un navigateur passe par un proxy explicite, il lui transmet directement l’URL demandé et n’a donc pas besoin de faire de requête DNS pour résoudre le nom du site. Je n’en mettrais pas ma tête à couper concernant l’utilisation d’un proxy SOCKS.

[quote=“Franck_FR”]Squid en mode transparent peut écouter sur un seul port.
Est ce qu’il n’y a pas un rapport avec ça ?[/quote]
Je n’ai pas touché à squid depuis longtemps, mais il n’y a pas une option pour fonctionner indifférement en mode transparent ou explicite ?

Il n’est pas question de supprimer la redirection mais d’en ajouter une dans la chaîne OUTPUT pour les connexions relayées par SSH, s’il n’est pas possible que squid fonctionne en proxy explicite. Il faut juste prendre garde à ne pas rediriger les connexions émises par squid lui-même, sinon ça va boucler. On peut utiliser l’UID du processus émetteur comme discriminant avec la correspondance “owner” d’iptables, soit en prenant tout sauf l’UID de squid, soit en prenant l’UID de l’utilisateur de la session SSH.

#5

J’ai noté que quand un navigateur passe par un proxy explicite, il lui transmet directement l’URL demandé. C’est donc le mandataire qui fait tout le bouleau.

Mon proxy n’est pour l’instant pas configuré pour accepter les connections de l’extérieur, mais simplement de l’intérieur.

A l’époque ou j’ai configuré la navigation par le tunnel SSH et le proxy sock v5, j’avais suivi les recommandations du site ci-dessous.

calomel.org/firefox_ssh_proxy.html
voire paragraphe
Optional Step: DNS proxying through SOCKS5 is highly recommended

J’avais vérifié avec un tcpdump du port 53 et ça marchait.

Non, je ne crois pas. Il faut le lui spécifier. En mode transparent l’utilisateur ne sait pas qu’il y a un proxy. Il ne le configure donc pas dans son navigateur Internet. Et dans ce cas, si squid fonctionne en mode non transparent, cet utilisateur n’a plus accès à Internet. C’est aussi pourquoi squid ne peut pas fonctionner indifféremment dans les deux modes.

J’ai le sentiment que la solution est là. On fait ça comment dans shorewall :slightly_smiling: ?
Je passerai sur Iptables volontier. Mais il faut que je trouve le temps de m’y mettre. Le problème est que l’humain dort environ 1/3 tier de sa vie :slightly_smiling:

C’est sure!
Il me semble, si je ne me trompe pas, que si la station qui veut naviguer sur le net fait aussi proxy et firewall alors la redirection est par exemple avec shorewall:
REDIRECT loc 3128 tcp www !proxy
Si le proxy est sur un serveur déporté alors il ne sera pas nécessaire de spécifier !proxy
proxy étant l’utilisateur sous lequel “tourne” squid.

#6

[quote=“Franck_FR”]A l’époque ou j’ai configuré la navigation par le tunnel SSH et le proxy sock v5, j’avais suivi les recommandations du site ci-dessous.
calomel.org/firefox_ssh_proxy.html
voire paragraphe
Optional Step: DNS proxying through SOCKS5 is highly recommended[/quote]
C’est bien ce qu’il me semblait avoir constaté, par défaut Firefox fait la résolution DNS lui-même et envoie l’adresse au proxy SOCKS au lieu d’envoyer le nom de domaine directement au proxy. Je ne connaissais pas cette option, merci.

Je trouve ton explication douteuse. D’après la documentation de squid, un port configuré pour le proxy transparent accepte aussi l’utilisation en proxy standard (explicite).

Je ne connais pas shorewall, je travaille directement avec iptables.

devrait faire l’affaire.

#7

Tu as raison. Au temps pour moi.

J’essaye ta ligne de commandes iptables.
Merci

#8

J’ai essayé la ligne de commande iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --gid-owner proxy -j REDIRECT --to 3128

On y est presque. C’est squid qui a répondu mais avec une erreur.

ERROR
The requested URL could not be retrieved

L’erreur suivante s’est produite en essayant d’accéder à l’URL : debian-fr.org/

Accès interdit.

La configuration du contrôle d’accès, empêche votre requête d’être acceptée. Si vous pensez que c’est une erreur, contactez votre fournisseur d’accès.

Votre administrateur proxy est webmaster ou pascal le contributeur méchant.

Générer le Tue, 17 Dec 2013 09:09:40 GMT par localhost (squid/3.1.20)

J’ai essaye de me connecter sur un moteur de recherche et en faisant tail -f /var/log/squid3/access.log, j’obtiens les lignes suivantes :

1387271800.813 1 mon_IP_public TCP_DENIED/403 4058 GET google.com/ - NONE/- text/html
1387271801.213 0 mon_IP_public TCP_DENIED/403 3822 GET squid-cache.org/Artwork/SN.png - NONE/- text/html
1387271801.454 1 mon_IP_public TCP_DENIED/403 4091 GET google.com/favicon.ico - NONE/- text/html
1387271801.693 1 mon_IP_public TCP_DENIED/403 4091 GET google.com/favicon.ico - NONE/- text/html

C’est peut être ma config squid dans
acl localnet src 192.168.2.0/24
http_access deny !localnet

#9

Je viens de recevoir un SMS me disant qu’il n’y a plus Internet sur le LAN :laughing: Toutes les requettes http redirigées vers la chaine output…
J’ai refais service shorewall restart pour remettre comme c’était pour l’instant.

#10

Ton serveur proxy, je suppose qu’il fait aussi routeur pour le LAN ?
Quand il se connecte à une adresse extérieure, il utilise l’adresse IP de son interface externe comme adresse source. Or cette adresse n’est pas modifiée par la règle de redirection et ne fait pas partie de l’ACL de squid.
Soit tu ajoutes une ACL pour cette adresse si elle est fixe, soit tu ajoutes une autre règle iptables pour modifier l’adresse source des connexions sortantes rebouclées vers le proxy :

où 192.168.2.x est l’adresse du proxy dans le LAN. Ainsi les connexions arriveront à squid avec cette adresse source qui est acceptée par l’ACL.
(Pas sûr qu’on puisse faire ce genre de cochonneries avec shorewall.)

Pas normal, il faudrait vérifier que le groupe propriétaire des paquets émis par squid est bien “proxy”. En attendant tu peux remplacer ! --gid-owner proxy par --uid-owner <user> où est l’utilisateur avec lequel tu te connectes en SSH.
(EDIT : correction erreur de syntaxe)

#11

root@srv-deb:~# netstat -etupal (lire dans le bon sens) |grep squid
tcp 0 0 *:3128 : LISTEN root 97256 7711/(squid)
udp 0 0 :57144 : proxy 97043 7711/(squid)
udp6 0 0 [::]:59152 [::]: proxy 97042 7711/(squid)

J’opte pour la solution qui consiste à rajouter une ACL pour mon ip publique (fixe). Je testerai en passant par la 3G pour arriver de l’exterieur…

#12

On voit que squid écoute sur le port 3128 avec l’UID root et non l’UID proxy. Mais on ne voit pas le GID, et cela ne détermine pas non plus forcément les UID et GID des paquets émis par squid quand il se connecte à un serveur web distant. Pour être sûr, il suffit de les afficher dans les logs du noyau avec la règle iptables suivante :

Ensuite, naviguer en passant par le proxy puis examiner la fin des logs du noyau avec

#13

Merci Pascal de ton aide précieuse.
J’arrive au stade ou je suis obligé d’apprendre à manipuler l’outil IPtables avant de continuer.
Je me documente en détail sur le fonctionnement du firewall (Netfilter) pour mieux comprendre les commandes que je rentre au clavier.

#14

Bon courage. Ce n’est pas simple à appréhender, mais je ne sais pas comment on peut s’en passer. Mon conseil : ne pas commencer directement par la page de manuel d’iptables mais par l’architecture générale de netfilter, le cheminement des paquets dans les tables et chaînes en fonction de leur point d’entrée et de sortie. C’est indispensable pour comprendre où ajouter la règle dont on a besoin.

#15

Oui, je compte bien commencer par netfilter.
upload.wikimedia.org/wikipedia/c … t-flow.svg
Je vais me documenter sur chacune des étapes. RDV en l’an 2900 :slightly_smiling: