Reverse Proxy avec deux URL différentes pour deux serveurs

zob

Bonjour,

Je suis développeur, du coup je n'y connais pas grand chose en admin sys/réseau, d'où ce topic d'appel à l'aide!

Voici l'archi réseau:

J'ai installé le paquet "squid3" et j'ai mis un certificat SSL valide dans le Cert manager.

Ce que je veux faire c'est un reverse proxy HTTP et HTTPS qui sera mon pfsense.
Je veux que:
le domaine www1.mondomaine.fr pointe vers le Serveur Web 1
et le domaine www2.mondomaine.fr pointe vers le Serveur Web 2

J'ai bien fait les enregistrements dans le DNS public et ouvert les ports 80 et 443 dans les règles de parefeu pfsense.

Dans la config "Reverse Proxy", j'ai mis:

external FQDN: mondomaine.fr

J'ai activé le reverse HTTP et HTTPS et choisi mon certif.
J'ai laissé "reverse HTTP default site" vide pour HTTP et HTTPS.

J'ai ajouté mes deux serveurs web (qui écoutent tous les deux sur le port 80).

Dans le mapping, j'ai fait deux règles:
Une qui dirige vers Serveur Web 1 et qui match avec http://www1.mondomaine.fr/ ou https://www1.mondomaine.fr/
Une qui dirige vers Serveur Web 2 et qui match avec http://www2.mondomaine.fr/ ou https://www2.mondomaine.fr/

Les requête en HTTP font exactement ce que je veux, mais en HTTPS je n'accède à aucune page.
Le certificat semble fonctionner, mais j'ai une page Squid qui me dit:

The requested URL could not be retrieved

L'erreur suivante s'est produite en essayant d'accéder à l'URL : https://mondomaine.fr/

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 admin@localhost.

Le seul moyen pour que ça fonctionne c'est que dans "external FQDN" je mette soit www1.mondomaine.fr ou www2.mondomaine.fr, mais dans ce cas il n'y a qu'une des deux url qui fonctionne…

Je ne comprends pas d'où vient mon erreur de paramétrage, et surtout la différence de fonctionnement entre HTTP et HTTPS...

Est-ce que quelqu'un pourrait tenter d'éclairer ma lanterne? car cela me bloque beaucoup dans le développement de mon application et je ne connais aucun admin/ingé système ou réseau :(

Bonne journée à tous!

ccnet

et surtout la différence de fonctionnement entre HTTP et HTTPS…

clair, chiffré pour faire vite !

zob

@ccnet:

et surtout la différence de fonctionnement entre HTTP et HTTPS…

clair, chiffré pour faire vite !

Lol merci ça je sais :D
Je parlais de la différence de fonctionnement au niveau du résultat que j'obtiens avec ma config: HTTP ça fonctionne comme je veux et HTTPS non :(

Une idée?

jdh

Je ne vois pas les choses ainsi !
Et notamment je conseille de ne pas faire sur le firewall une tache pour lequel il n'est pas prévu !

Les serveurs web utilisant Apache, on peut envoyer tout le flux http (et http seulement) vers le premier.
Celui-ci peut utiliser la fonction reverse-proxy d'apache pour renvoyer le flux vers le second serveur en fonction du nom.

Cette solution (qui évite un squid inutile) ne fonctionne que pour http.
Il est peut-être possible d'utiliser un certificat "multiple" pour https qui permettrait aussi de fonctionner en https. (sous-réserves)

ccnet

@zob:

@ccnet:

et surtout la différence de fonctionnement entre HTTP et HTTPS…

clair, chiffré pour faire vite !

Lol merci ça je sais :D

Alors il faut en tirer les conséquences. Une solution : http://vulture.open-source.fr/wiki/ . Au delà du firewall applicatif, qui n'est pas superflu, il y a des pistes pour votre problème. Bien dommage que ce projet soit inactif depuis deux ans et demi.
Le placement d'un Squid sur le firewall est une fausse bonne idée.

PARN

Bonjour à tous,

Mais que non Vulture n'est pas inactif !!! : http://www.vultureproject.org

Et que oui c'est une très bonne solution de reverse proxy que j'utilise :)

ccnet

Bonne et interessante nouvelle. Il faudrait que l'url que j'ai donné soit inactivée ou redirigée. Voilà qui va me faire reconsidérer Vulture dans le portefeuille des mes solutions.

krominet

CCNET , JDH, pourquoi vous préférez donner votre (docte) avis au lieu de répondre à la question ?

il y a une grosse différence entre essayer de comprendre pourquoi ça marche, ou pas et faire tourner un réseau en production en respectant les "bonnes" pratiques de sécurité…

ccnet

Ce que je veux faire c'est un reverse proxy HTTP et HTTPS qui sera mon pfsense.

C'est qui est demandé par l'auteur du post.
Une solution donnée c'est Vulture. Pourquoi pas une solution avec Pfsense ? Parce que ce n'est pas le bon outil pour faire ce qui est demandé. Parce qu'un reverse proxy http - https ce n'est pas complètement trivial loin s'en faut. Donc Vulture reste une très bonne solution. Il y en a d'autres, chères ou très chères. Vulture est gratuit.
L'auteur du post ne tire manifestement pas les conséquences de la présence de ssl, c'est à dire qu'il faut déporter le gestion du chiffrement sur le reverse avec toutes les complexités que cela apporte. On ne l'en blâmera pas parce que c'est loin d'être simple. Vulture le fait et masque une bonne partie de cette complexité.

Je vais essayer de répondre à votre question :

CCNET , JDH, pourquoi vous préférez donner votre (docte) avis au lieu de répondre à la question ?

Le but n'est pas de donner un avis, mais d'éviter à des personnes, plus ou moins expérimentées, de se fourvoyer. La quasi totalité des personnes qui viennent ici, avec ce type de demande, on une solution technique en tête a priori au lieu de partir d'un besoin fonctionnel à partir duquel on devrait envisager des solutions. Et presque chaque fois leurs connaissances sont incomplètes et la solution qu'ils ont imaginé soit ne peut pas fonctionner, soit est mauvaise pour toute une série de raisons qu'ils n'ont pas envisagé. Voilà pourquoi, peut être, les réponses vous semblent être des avis.

Un exemple récent : cet utilisateur qui n'arrivait à faire fonctionner le nat outbound comme il l'imaginait alors qu'il n'en avait pas besoin.
ou encore l'utilisation d'un esx (avec du iscsi) avec une seule et unique interface réseau alors que le produit n'est pas conçu pour fonctionner ainsi. Il se trouve que cela fonctionne néanmoins.

Vous donneriez une solution à celui qui veut faire rouler une Smart à 250km/h ?

Cela répond peut être à votre question que je ne suis pas certain de bien comprendre.

jdh

@krominet:

CCNET , JDH, pourquoi vous préférez donner votre (docte) avis au lieu de répondre à la question ?

il y a une grosse différence entre essayer de comprendre pourquoi ça marche, ou pas et faire tourner un réseau en production en respectant les "bonnes" pratiques de sécurité…

Sans connaitre physiquement ccnet, je suis assez proche de lui dans la compréhension des problématiques réseaux et dans la pratique professionnelle dans diverses entreprises. Je n'ai pas mémoire d'avoir été en conflit sur un point de vue.

Je crois pouvoir dire que nous sommes 2 professionnels aguerris et nous avons une certaine expérience due aux nombres d'années et à la diversité des situations rencontrées. Nous avons acquis une pratique qui a affiné notre formation initiale.

Je crois que ccnet donne de plus des formations.

Le fait d'avoir fait tourner pas mal de réseaux en production, de firewalls, de serveurs nous rend habitué à l'analyse du pourquoi ça fonctionne ou pas !

Aussi, nos réponses peuvent éclairer celui qui a posé une question parce que, quelque fois, notre vision est différente.
C'est l'intérêt de nos réponses : pratiques, opérationnelles, vécues ou non, mais très souvent dans la bonne pratique !

Personnellement, je trouve très préférable de répondre par la bonne pratique quand on on voit la direction prise.
Je ne comprends pas ceux qui disent "l'autopsie me donnera raison" !