Reverse Proxy problème
-
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 ;)
-
et je me rends compte (désolé :-[) que j'ai oublié le lien vers la fonctionnalité que j'introduis sur pfSense pour supporter ce design: le [url=https://doc.pfsense.org/index.php/Inbound_Load_Balancing]load balancer
-
Merci beaucoup pour tous ses conseils précieux chris4916.
Je vais prendre le temps d'étudier tous mes besoins et de me construire une architecture digne de ce nom.Pour l'instant il est donc fort probable que je parte sur un cluster de pfsense avec CARP.
Des reverse proxy sur une DMZ (Cluster ou loadbalancergérer par le pfsense). D'ailleurs est-ce que c'est une fonction qui est bien implémenté dans le pfsense ? Est-ce que c'est stable et bien éprouvé ?J'ai également bien pris en compte les autres aspects à prendre en compte (Lien WAN, réseau ….)
En tout cas, j'ai bien hâte de faire évoluer mon infra actuelle. ;D
-
Pas de précipitations ;D n'hésite pas à prendre d'abord d'autres avis car cette vision "high level" est juste la mienne ;)
Elle me semble correspondre à ton besoin mais il y a probablement d'autres approches possibles.Un point important, dans ce type de design ou les services sont redondants, c'est de bien s'assurer du fonctionnement de bout en bout, entre le client et le serveur lorsqu'il y a des switch d'un composant à l'autre dans les différentes couches.
- Y a t-il des pertes de session, est-ce critique ?
- comment synchroniser les configurations reverse proxy ?
- gestion des certificats (c'est un point potentiellement délicat qui requiert toute ton attention 8)) la terminaison se fait-elle au niveau des reverse proxy ? quel type de certificat utiliser ? Bref, un sujet intéressant, mais en dehors de pfSense.
-
salut salut
Réfère toi à un de nos file récent qui traite de pourquoi ne pas mettre un proxy sur pf et dans quel cadre le faire avec les restrictions qui en découle.
Les informations de chris son pertinente pour le moins mauvaise solution à développer en virtualisation, à laquelle je rajouterais un proxy du coté de ton lan et bien évidement les clients paramétrés pour passer par le proxy lan qui lui va interroger le revers.
Sauf erreur (pas mis en place pour l'instant) il faut dire à pf de ne pas laisser passer les requêtes de sortie envoyer par un client et forcer le passage par le proxy.
de tel sorte tu auras un filtrage sur les protocoles pris en charge par tes proxy qui passeront et pas le reste, sauf applications autorisées.
si un de nos grands gourous pouvaient nous le confirmer.
Cordialement.
-
…/... à laquelle je rajouterais un proxy du coté de ton lan et bien évidement les clients paramétrés pour passer par le proxy lan qui lui va interroger le revers.
j'avoue ne pas bien comprendre la finalité :-[ si tu pouvais développer un peu ;) il y a peut-être quelque chose que j'ai raté.
[quote]Sauf erreur (pas mis en place pour l'instant) il faut dire à pf de ne pas laisser passer les requêtes de sortie envoyer par un client et forcer le passage par le proxy.
Si je comprends bien la description initiale, il s'agit de clients "externes" (et donc pas sur le LAN) qui accèdent à des applications exposées par l'infrastructure de mamatov. Dans ce que je décris, l'objectif est justement de faire en sorte que ces utilisateurs n'accèdent pas au LAN mais que la requête soit faite, de manière contrôlée, par le reverse proxy.
si un de nos grands gourous pouvaient nous le confirmer.
D'autres perceptions que la mienne seraient en effet les bienvenues :)
-
Une petite précision suite à un échange privé sur un sujet en marge de celui-ci:
si il n'y a qu'un seul reverse proxy ou si celui-ci est installé sur un cluster, la fonction de load balancer de pfSense est bien sûr inutile ;)
