Salut,
Envoyé par
furynick
Bonjour à tous, j'ai une problématique assez ardue à solutionner qui me résiste malgré toute la doc que j'ai pu compulser jusqu'à présent.
c'est le problème connu de "NAT Hairpinning".
Envoyé par
furynick
[Pistes déjà empruntées]
J'ai bien pensé à la chaine OUTPUT de la table nat mais je ne vois pas comment l'utiliser non plus vu que l'interface lo est déjà utilisée donc on reste chez les petits hommes verts.
J'ai également essayé de déplacer le proxy sur un autre serveur mais le proxy transparent pose alors d'autres problèmes (il faut natter le traffic du port 80 vers le proxy qui revient lui aussi à travers le port 80 d'une part et des erreurs relatives à l'indisponibilité d'iptables sur le serveur du proxy polluent les logs).
Bref, je suis un peu coincé et j'aimerais éviter les solutions merdiques du genre créer les entrées DNS en local pour les noms de domaine publics ou renseigner les hosts dans un proxy.pac pour contourner le proxy (et du coup éliminer le proxy transparent ce qui n'est pas non plus sans conséquences puisqu'il faut paramétrer et maintenir la conf du proxy sur tous les postes de travail hétérogènes). Je considère que ces pratiques sont ingérables sur le long terme et source de problèmes.
Perso, j'ai déjà testé des réglages d'iptables pour faire du NAT hairpinning mais ça n'était pas destiné à être forwardé vers un Squid embarqué sur la même machine. En revanche, as-tu essayé en manipulant la chaîne POSTROUTING de nat ? Ca devrait faire quelque chose comme
iptables -t nat -A POSTROUTING -s 172.17.32.0/24 -d 172.17.32.253 -p tcp --dport 80 -j SNAT --to-source 172.17.32.254
Je pensais à une autre chose... Si l'interface lo crée une "adhérence" qui empêche la mise en oeuvre du hairpinning, une autre idée à explorer consisterait à virtualiser le Squid pour essayer de le dissocier du stack du firewall.
Steph
Partager