Reverse Proxy problème
-
Bonjour,
Contexte :
- milieu pro
- Test de pfsense avant une éventuelle mise en production.
- Compétence firewall sur Fortinet mais débutant sur pfsense.
Besoin :
- J'ai actuellement une cinquantaine de serveurs web hébergés (+ 50 serveurs erp accessibles via ssh) sur une infra virtualisée. Chaque serveur a sa propre IP publique et son firewall (Iptables + fail2ban). Cela fonctionne bien mais ce n'est vraiment pas souple à gérer.
Je veux donc faire évoluer mon infra et c'est pourquoi je teste pfsense installée sur une VM. Mon besoin concerne donc le reverse proxy pour pouvoir joindre mes serveurs webs via une ip publique unique en filtrant sur l'URL.
Schéma :
- Pour mon test mon schéma est très simple, j'ai installé pfsense 2.2.2 sur une VM qui a 2 interfaces (WAN + LAN).
- Packages ajoutés : squid3
- Pour la configuration du revers proxy j'ai suivit ce tuto :
http://www.ophyde.com/reverse-proxy-avec-pfsense/
La configuration est assez basique
Pfsens Wan : IP publique X.X.X.X
Pfsense Lan : IP privé 172.16.2.X
Web server : Ip privé 172.16.2.X- Mon revers proxy est bien bindé sur l'interface wan et écoute sur le port 80
- Dans l'onglet Web servers du reverse proxy j'ai bien ajouté mon serveur web
- Dans l'onglet mappings j'ai indiqué l'URL test.mondomaine.fr (sur mon dns j'ai bien ajouté un enregistrement de test.mondomaine.fr vers l'IP publique wan du pfsense).
- J'ai également ajouté une règle pour autoriser le port 80 vers l'interface WAN du pfsense
Toubleshooting :
- Via tcpump sur le serveur web je ne vois aucun paquet arrivé quand je lance une connexion vers test.mondomaine.fr (iptable est désactivé)
- Sur le pfsense la règle laisse bien passé la requête sur le port 80.
J'ai essayé divers changements sans succès. Je dois rater quelques choses mais je ne comprends pas quoi.
Est-ce que vous avez une piste ? Via le shell de pfsense je pensais trouvé des logs du revers proxy mais je n'ai rien trouvé.Merci d'avance pour votre aide.
-
1 - avant de regarder sur le serveur web, as-tu fait un tcpdump sur pfSense ?
2 - rien à voir avec ton problème immédiat mais probablement utile: avec le changement de design, si tu n'y prêtes pas attention, tu vas perdre l'IP source, ce qui peut être gênant si tu fais des stats sur tes serveurs Web. Je suppose que la directive x-forwarded-for fonctionne également en mode reverse proxy avec Squid (j'utilise habituellement plutôt Nginx que Squid pour du reverse) -
Reverse proxy c'est comme proxy mais avec reverse devant non ? Je commente une fois pour toute ce que je pense de cette solution, ensuite chacun fait ce qu'il veut.
L' idée de base me semble parfaitement justifiée. Je ne partage pas les modalités de mise en œuvre. Avec une cinquantaine de serveurs webs les composants firewall et reverse proxy devraient être séparés et physique. Une segmentation réseau rigoureuse devrait être mise en place. J'en ai terminé. -
Reverse proxy c'est comme proxy mais avec reverse devant non ? Je commente une fois pour toute ce que je pense de cette solution, ensuite chacun fait ce qu'il veut.
L' idée de base me semble parfaitement justifiée. Je ne partage pas les modalités de mise en œuvre. Avec une cinquantaine de serveurs webs les composants firewall et reverse proxy devraient être séparés et physique. Une segmentation réseau rigoureuse devrait être mise en place. J'en ai terminé.Oui j'ai fait un tcpdump sur le pfsense, j'ai bien des paquets qui arrivent avec comme destination l'ip publique du pfsense sur le port 80.
Merci pour tes conseils, je vais sans doute étudier le possibilité de segmenter mon réseau pour gérer mes serveurs web.
Pour le moment je voulais simplement utiliser cette fonctionnalité de pfsense à des fins de tests.tcpdump -n port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
capability mode sandbox enabled
11:31:22.328133 IP X.X.X.X.57285 > Y.Y.Y.Y.80: Flags , seq 3902237954, win 65535, options [mss 1420,nop,wscale 8,nop,nop,sackOK], length 0
11:31:23.321011 IP X.X.X.X.57285 > Y.Y.Y.Y.80: Flags , seq 3902237954, win 65535, options [mss 1420,nop,wscale 8,nop,nop,sackOK], length 0
11:31:25.329360 IP X.X.X.X.57285 > Y.Y.Y.Y.80: Flags , seq 3902237954, win 65535, options [mss 1420,nop,nop,sackOK], length 0
11:31:29.358651 IP X.X.X.X.57286 > Y.Y.Y.Y.80: Flags , seq 974242012, win 65535, options [mss 1420,nop,wscale 8,nop,nop,sackOK], length 0
11:31:30.359544 IP X.X.X.X.57286 > Y.Y.Y.Y.80: Flags , seq 974242012, win 65535, options [mss 1420,nop,wscale 8,nop,nop,sackOK], length 0
11:31:32.360147 IP X.X.X.X.57286 > Y.Y.Y.Y.80: Flags , seq 974242012, win 65535, options [mss 1420,nop,nop,sackOK], length 0 -
Dans votre démarche cette solution pourrait vous intéresser : https://www.vultureproject.org/ D'autant qu'une nouvelle version très prometteuse s'annonce.
-
Dans votre démarche cette solution pourrait vous intéresser : https://www.vultureproject.org/ D'autant qu'une nouvelle version très prometteuse s'annonce.
Merci pour l'info je vais regarder.
Sinon pour mon problème de reverse avec pfsense une idée ? -
Quelques infos pourraient être collecté sur Pfsense avec une capture sur chaque interface. Activez aussi les logs sur pfsense sur la règle qui accepte le trafic pour voir ce qu’il en est des paquets reçus.
Squid 3 sur Pfsense, je ne sais pas où ça log. -
le log de Squid est dans /var/squid ;)
-
et dans l'option "realtime", tu devrais peut-être avoir quelque chose lorsque tu essaies de te connecter… je n'ai pas ça sous la main pour tester mais intuitivement...
-
le log de Squid est dans /var/squid ;)
Merci pour l'info !
J'ai sans doute une piste, quand je démarre le reverse proxy j'ai le message :Cannot bind socket FD 18 to "my wan ip:80" : (13) Permission denied :
==============
Message from syslogd@test1 at Apr 23 16:34:48 …
test1 php-fpm[247]: /pkg_edit.php: Successful login for user 'admin' from: 172.16.2.80
FATAL: Received Segment Violation…dying.
CPU Usage: 10.037 seconds = 7.083 user + 2.953 sys
Maximum Resident Size: 82336 KB
Page faults with physical i/o: 0
2015/04/23 16:34:58 kid1| Starting Squid Cache version 3.4.10 for amd64-portbld-freebsd10.1...
2015/04/23 16:34:58 kid1| commBind: Cannot bind socket FD 18 to Y.Y.Y.Y:80: (13) Permission denied
2015/04/23 16:34:58| pinger: Initialising ICMP pinger ...
2015/04/23 16:34:58| icmp_sock: (1) Operation not permitted
2015/04/23 16:34:58| pinger: Unable to start ICMP pinger.
2015/04/23 16:34:58| icmp_sock: (1) Operation not permitted
2015/04/23 16:34:58| pinger: Unable to start ICMPv6 pinger.
2015/04/23 16:34:58| FATAL: pinger: Unable to open any ICMP sockets.
2015/04/23 16:35:00 kid1| Starting Squid Cache version 3.4.10 for amd64-portbld-freebsd10.1...
2015/04/23 16:35:00 kid1| commBind: Cannot bind socket FD 18 to Y.Y.Y.Y:80: (13) Permission denied
2015/04/23 16:35:00| pinger: Initialising ICMP pinger ...
2015/04/23 16:35:00| icmp_sock: (1) Operation not permitted
2015/04/23 16:35:00| pinger: Unable to start ICMP pinger.
2015/04/23 16:35:00| icmp_sock: (1) Operation not permitted
2015/04/23 16:35:00| pinger: Unable to start ICMPv6 pinger.
2015/04/23 16:35:00| FATAL: pinger: Unable to open any ICMP sockets.=================
Je vais creuser de se côté là.
Encore merci -
C'est parce qu'il faut que tu configures net.inet.ip.portrange.reservedhigh dans system/advanced/system tunables sans quoi tu ne peux lancer de services sur un port inférieur à 1024 (sauf erreur de ma part)
-
après vérification, c'est plutôt: net.inet.ip.portrange.first désolé :-[
-
après vérification, c'est plutôt: net.inet.ip.portrange.first désolé :-[
[/quote]Merci mais cela ne fonctionne pas.
J'ai essayé de passé à 0 ou a rien la valeur de net.inet.ip.portrange.first mais j'ai toujours le même message.
De plus, quand je force le reverse proxy avec le port 80 il m’indique le message suivant :============
The following input errors were detected:
The field 'reverse HTTP port' must contain a port number higher than net.inet.ip.portrange.reservedhigh sysctl value(1023).
To listen on low ports, change portrange.reservedhigh sysctl value to 0 on system tunable options and restart squid daemon.============
J'ai 'ajouté net.inet.ip.portrange.reservedhigh avec la valeur 0 mais toujours le même message.
Pour mes tests j'ai donc changé le port de squid avec le port 8080 dans un premier temps. Je n'ai plus l'erreur avec le bind mais les autres oui :2015/04/23 16:59:55 kid1| Starting Squid Cache version 3.4.10 for amd64-portbld-freebsd10.1…
2015/04/23 16:59:55| pinger: Initialising ICMP pinger ...
2015/04/23 16:59:55| icmp_sock: (1) Operation not permitted
2015/04/23 16:59:55| pinger: Unable to start ICMP pinger.
2015/04/23 16:59:55| icmp_sock: (1) Operation not permitted
2015/04/23 16:59:55| pinger: Unable to start ICMPv6 pinger.
2015/04/23 16:59:55| FATAL: pinger: Unable to open any ICMP sockets.=================
Mais maintenant le reverse proxy fonctionne :D :D :D
Par contre je ne comprends pas pourquoi ça ne fonctionne pas avec le port 80..
-
L'interface web du pfsense ne doit pas être sur le port de base aussi …
(Mais ça c'est évident que vous y avez déjà pensé ...) -
et tu as bien sur redémarré Squid après avoir ajouté net.inet.ip.portrange.reservedhigh ?
-
et tu as bien sur redémarré Squid après avoir ajouté net.inet.ip.portrange.reservedhigh ?
Je n'avais pas redémarré squid après avoir ajouté net.inet.ip.portrange.reservedhigh.
C'est ok maintenant avec le port 80.Un grand merci a vous tous, cela fait quelques heures que je me cassais le nez dessus.
-
un thread qui peut t'intéresser ;)
-
Maintenant que ça fonctionne (ce qui était la question initiale), il y a probablement de la place pour un réflexion plus large 8)
Compte tenu du nombre de serveur que tu décris et de leur usage (ERP), j'imagine qu'il y a des problématiques spécifiques liées à la haute disponibilité, éventuellement des aspects spécifiques de réécriture d'URL, de load balancing etc…
Le simple déploiement d'un reverse proxy sur pfSense ne répond pas à cette problématique. De plus c'est un package, avec des risque évidents de dysfonctionnement comme tu peux le lire sur le lien que j'ai mis un peu plus haut.
Compte tenu de la nature commerciale de ton environnement, selon le SLA que tu as, il est peut-être nécessaire de mettre en place une infrastructure à tolérance de panne (i.e. une paire de pfSense avec CARP).
Au lieu de faire tourner un reverse proxy directement sur pfSense, j'opterai plutôt pour le service "load balancer" de pfSense, pour conserver l'objectif de "une adresse IP externe unique" (même si c'est ici une VIP) pour rediriger les requêtes en failover vers une paire de reverse proxy installés sur une DMZ, lesquels accéderont aux serveurs en interne.
Voila pour la base de réflexion ;)
-
Le choix du reverse proxy est un vaste débat ::)
Il faut d'abord bien définir les fonctionnalités que tu veux couvrir. Il y a des solutions simples (simplistes) et des truc plus évolués et spécialisés comme le lien proposé par ccnet.
- Les aspects de charge ne posent normalement pas de problème (à ne pas négliger cependant: comme pour le serveur web, un reverse proxy Nginx est plus rapide et léger que Apache ;D mais pas avec les mêmes fonctionnalités)
- les aspects failover sont également assez bien couverts mais il peut y avoir des pièges avec les applications qui maintiennent des sessions. Il convient de bien s'assurer de ces aspects de bout en bout lors du PoC.
- attention également aux aspect d’authentification: normalement, ton application demande à l'utilisateur de s'authentifier. certains reverse proxy offrent une fonction de SSO (like) qui consiste souvent à stocker le crédential de l'utilisateur pour le rejouer ultérieurement. Tout le monde n'est pas fanatique de ce mode de fonctionnement (moi par exemple :-) )
A discuter ;) (mais est-ce que ça n'est pas largement HS par rapport à pfSense ?)
-
Pour illustrer ce propos et rester dans le cadre de pfSense, si la haute disponibilité fait partie du SLA, il conviendrait de déployer une paire de pfSense avec CARP.
pfSense contrôle l'accès à la DMZ sur laquelle sont installés 2 reverse proxy, accédés via le load balancer, en mode load balancer ou failover selon les besoins. Ces reverse proxy accèdent ensuite aux serveurs web installés sur le LAN (1)
Avec ce design, les utilisateurs venant d'internet ne pénètrent pas plus loin que la DMZ où l'appli (reverse proxy) prend le relais.
Attention: ça reste malgré tout un design que je qualifie de slideware ;D car il ne décrit que le principe. De nombreux aspects supplémentaires doivent être pris en compte avant de fournir une architecture qui pourrait être déployée:
- les aspects connectivité internet sont ignorés (edge routers, redondance des ISP, liens internet)
- redondance des serveurs web (indispensable si on fait l"effort de rendre l'infra y donnant accès elle même tolérante aux pannes)
- réseau d'administration
- et enfin, très important mais en dehors du cadre de pfSense, choix et fonctionnalités des reverse proxy
(1): "sur le LAN" est ici un raccourci. Le déploiement des serveurs dans l'infrastructure est un autre sujet, à prendre en compte dans le design cible. Ce peut être des serveurs sur un segment dont l'accès est contrôlé par un FW dédié, un segment directement attaché aux 2 pfSense décrits au dessus. Il y a plein de designs possibles dépendants de l'existant et des objectifs. C'est un autre débat et un sujet à part entière ;)
