Hello,
Je possède une machine (sous Debian Squeeze) qui fait office de routeur au sein d'un réseau. Ce serveur possède 3 adresses IP publiques sur les interfaces wan-1, wan-2 et wan-3. L'interface réseau connectant cette machine au réseau local se nomme lan-1 et a pour adresse IP 192.168.3.1. Cette machine embarque également un proxy (Squid) qui permet aux machines du réseau local d’accéder au Web via ce proxy uniquement.
Au sein du réseau local, j'ai une machine qui héberge un service HTTP (via Apache2) sur les ports 80 et 443. Son IP est 192.168.3.4.
Le service HTTP doit être accessible depuis l’extérieur. J'ai tout d'abord décidé d'appliquer des règles iptables afin de rediriger le trafic entrant sur les ports 80 et 443 (de l'interface wan-2) vers la machine 192.168.3.4. Cette solution fonctionne pour tout le trafic extérieur. Néanmoins, si la requête provient d'une machine de l'intérieur, elle transitera par le proxy ce qui provoquera une tentative d'accès direct aux ports 80 ou 443 directement sur l'interface du serveur routeur. Ceci se soldera évidemment par une erreur du type "Connection refused" puisque les ports 80 et 443 ne sont pas réellement ouverts.
J'ai donc décidé de remplacer les règles iptables par le daemon xinetd qui ouvre les deux ports sur l'interface choisie puis redirige le trafic vers la bonne destination. Cette méthode règle alors le problème cité ci-dessus. Mais cette solution provoque un autre comportement gênant. Pour apache maintenant, toutes les requêtes proviennent de la machine routeur, soit l'intégralité des requêtes avec comme REMOTE_ADDR 192.168.3.1.
J'ai tenté de rediriger avec iptables le trafic local, mais la seule façon de faire du transfert d'adresse est la table nat et la directive PREROUTING, qui n'est pas utilisée dans le cas d'un trafic local...
Quelqu'un aurait-il une solution viable à proposer ?
Merci...
# Hein ?
Posté par Batchyx . Évalué à 2.
Comprend pas.
Si ton routage est bien fait, lorsque ton proxy va recevoir une requête pour http://192.168.3.4/truc, il va ouvrir une socket pour aller vers "192.168.3.4". Le noyau va tomber sur une route "192.168.3.4 dev eth0 src 192.168.3.1", et il doit normalement aller taper directement sur le lan sans que ça gène quoi que ce soit.
Si c'est un proxy transparant, alors normalement il filtre pas ce qui va vers 192.168.3.1/?. Soit il laisse les clients aller directement dessus, soit ce qui va vers ton serveur passe par un proxy configuré autrement, ou soit les clients ne passent même pas par ton proxy.
La j'ai l'impression que tu cherche à faire compliqué un truc qui normalement est simple.
[^] # Re: Hein ?
Posté par NeoX . Évalué à 2.
J'ajouterais que c'est meme plus simple que ca (ou pas)
tes machines locales, si elle accede au serveur local, ne doivent pas passer par le proxy, cela n'a aucun sens.
par contre, ce que tu essaie de faire c'est que les machines locales accedent au serveur INTERNE via son nom et son IP EXTERNE
et là c'est vraiment moche.
Idealement il faudrait juste un dns forwarder sur ton routeur
qui fait la resolution des noms qu'il connait et qui interroge des DNS externes sinon.
Ainsi quand tes machines locales demandent tonserveur.example.com
le routeur renvoie 192.168.3.4
au lieu de l'IP externe qui n'a rien à faire de ce coté du reseau.
en plus ca te permettrait d'avoir une gestion DNS interne à ton reseau, pour nommer les machines, les imprimantes...
[^] # Re: Hein ?
Posté par Batchyx . Évalué à 2.
Si le but est effectivement que les machines locales accèdent au serveur interne via le routeur, un petit -j DNAT dans PREROUTING lorsque le paquet viens de l'intérieur et arrive sur le routeur pour rediriger les requêtes vers le serveur interne et hop. Mais après le serveur interne va vouloir répondre directement au clients, et il va se faire jeter : si je contacte 192.168.3.4, c'est pas à 192.168.3.1 de répondre.
Ça veut dire qu'il faut que le serveur interne ai une table de routage qui fasse tout passer par le routeur. Après on peut faire en sorte que le serveur interne n'utilise que cette table de routage pour le trafic web, on peut faire plein de chose marrantes avec Linux.
C'est crade, mais moins que de bidouiller avec xinetd.
# Petites infos complémentaires
Posté par Thomas Bétrancourt (site web personnel) . Évalué à 0.
Je me rends compte que je n'ai pas donné assez d'infos pour que ma demande paraisse légitime.. lol
Le serveur routeur héberge également des serveurs VPN auxquels je me connecte depuis l'extérieur. Sur un client connecté au VPN (exemple, moi au travail), j'utilise le proxy Squid pour surfer sans subir les restrictions mises en place par le client chez qui je travaille. Et c'est quand j'essaie d'accéder à une application web hébergée sur le réseau (donc sur la machine 192.168.3.4) que le Squid n'y arrive pas. Car mon navigateur lui résouds les DNS via le DNS de mon poste (donc via le DNS interne du client chez qui je travaille), ce qui me donne l'IP publique de mon serveur routeur, donc finalement, Squid tente d'obtenir la page http:///mail.
C'est plus clair comme ça ?
[^] # Re: Petites infos complémentaires
Posté par nono14 (site web personnel) . Évalué à 2.
Un vpn correct te donne un dns permetant d'accéder aux machines internes.
Système - Réseau - Sécurité Open Source
[^] # Re: Petites infos complémentaires
Posté par Thomas Bétrancourt (site web personnel) . Évalué à -1.
Peut-être, mais je ne veux pas remplacer le DNS existant car cette connexion ne doit pas être une gêne pour le réseau existant (celui de chez les clients).
Mais bon, la façon dont fonctionne le VPN etc n'est pas trop le sujet à mon sens.
[^] # Re: Petites infos complémentaires
Posté par nono14 (site web personnel) . Évalué à 2.
Y'a moyen installer un dns en vue séparée ( split dns ) pour taper tel dns pour tel zone.
Système - Réseau - Sécurité Open Source
[^] # Re: Petites infos complémentaires
Posté par Batchyx . Évalué à 2.
Si ton navigateur à un proxy de configuré, il n'a pas besoin de serveur DNS, ça sera le proxy qui résoudra tout.
Si ton proxy est transparent, alors comme dit en dessous, il faut que ton DNS passe par le VPN. En fait, il faudrai que tout passe par ton VPN, sauf la liaison qui te permet d'accéder au VPN ;) Et j'espère que l'adresse du VPN n'est pas la même que l'adresse de ton service web, sinon tu va t'amuser avec les tables de routages.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.