iptables, squid transparent et apache natté

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

[Planté de décor]

• un firewall sous Linux avec deux interfaces réseau : eth0 (172.17.32.254) sur le LAN(172.17.32.0/24) et eth1 connecté au Net (75.75.75.75 par ex.) et qui est donc la passerelle par défaut. Ce firewall est également un proxy squid pour lequel une IP virtuelle lui est associée (172.17.32.253) pour faciliter le filtrage.
• un serveur apache (172.17.32.101)
• autres serveurs et postes de travail sur le même (windows/linux/android)
• pas de DMZ

[Problématique]
Les règles de routage sont toutes Ok (les services autorisés traversent bien le FW, le proxy transparent est fonctionnel, les requêtes Web externes sont bien nattées vers le serveur apache) mais il est impossible d'accéder aux sites hébergés en local depuis le réseau local en utilisant l'URL publique.

La raison de cette impossibilité est la suivante : squid reçoit les requêtes des clients (à travers la chaine INPUT), la résolution du nom de domaine abouti sur l'adresse Internet (75.75.75.75) qui est connue du firewall donc les paquets sortent sur l'interface de loopback et là, pas moyen de nater sous peine de filtrage des martiens (src ip = 127.0.0.1, dst ip = 172.17.32.x).

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

Si un gourou passe par la et a une idée, je suis preneur et lui en serait très reconnaissant.

[IP_Steph]

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

Code :

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

[furynick]

Il me semble avoir essayé le SNAT mais j'ai essayé tellement de trucs que j'ai un doute. Je (re)tenterai ça demain.

La virtualisation (ou le déplacement sur un autre host) me posera d'autres problèmes comme déjà énoncé ... mais si c'est la seule solution il faudra bien que je passe par là.

En tous cas merci pour la réponse, s'il y a d'autres avis n'hésitez pas