J’utilise Jeedom derriere un reverse proxy Nginx.
Malheureusement, Jeedom ne sait pas s’adapter et croit que l’adresse IP des utilisateurs est toujours celle du reverse proxy (adresse sur le reseau local).
Un effet de bord génant est que lorsqu’on rentre trop de mot de passes faux, Jeedom banni l’IP, et donc TOUS les utilisateurs (meme ceux légitimes) sont bloqués le temps du banissement.
Lorsqu’il est derriere un reverse proxy, Jeedom devrait se baser sur le header HTTP « X-Forwarded-For » (X-Forwarded-For - HTTP | MDN) pour obtenir l’adresse IP du client et ne pas s’arreter à celle du reverse proxy.
Est-il possible d’ajouter une option pour résoudre ce problème ?
Et c’est bien le cas, vérifiez votre config sur nginx.
Je pense que si ce n’était pas le cas ça ferait longtemps que beaucoup de personnes auraient remonté ce problème
Notamment tout ceux derrière les dns jeedom
ps: oui, je suis derrière un nginx en reverse proxy aussi
Avant de dire que Jeedom ne sait pas s’adapter, je regarderai la config du reverse proxy !
C’est vrai que la facilité est de dire c’est Jeedom, mais qu’en est-il du reste ?
Ca ne peut pas être autre chose car les gens font des configs parfaites et maitrisent…
Donc prouve nous que ta config est irréprochable sur le reste et ensuite on pourra mettre Jeedom en cause. D’ici là, je dirai aussi facilement que toi que le souci est sur ta config, ton install mais pas jeedom.
Restons un peu sérieux…
On voit de plus en plus de gens admin système et réseau car ils ont une box, un switch manageable et un pc sous linux/windows. Ils suivent des tutos mais au final…
Le pb semble plutôt venir du reverse proxy en effet.
Ceci étant, @hollowgood n’a pas évoqué le fait qu’il se pensait admin réseau.
Il tente juste une config un peu complexe et demande un coup de main. Ca tombe bien, il est sur un forum d’entraide
Sympa cet accueil chaleureux, ca donne une super image de la communauté
J’ai lu pas mal de tuto pour configurer Nginx en reverse proxy, je pense que ma config est correcte, mais effectivement, elle n’est peut etre pas parfaite.
J’utilise une image docker spécialisée pour le reverse proxy : SWAG (Introducing SWAG - Secure Web Application Gateway | LinuxServer.io) donc a priori, la conf est éprouvée.
Puisqu’apparement vous etes tous d’accord pour dire que ca vient de la config du proxy, pouvez-vous m’indiquer quel parametre est important pour que ca fonctionne bien avec Jeedom ?
Parce que au final, a part m’avoir mis des tacles, personne ne m’a aidé, ca aurait été plus constructif.
Plusieurs personnes tenteront de t’aider ici selon leurs connaissances cependant garde à l’esprit que c’est une communauté jeedom, pas ngnix; cela ne veut pas dire qu’il est interdit d’en parler
Je tombe sur le fil de discu un peu par hasard, mais la réponse est simple. Il n’y a pas que le reverse proxy que tu as monter à modifier, il faut aussi modifier le serveur apache du Jeedom car lui ne peut pas deviner qu’il est « masqué » par un reverse proxy.
En effet, si tu ne configures par l’apache, il ne prendra jamais en compte les headers X-Forwarded-For que tu as ajoutés et les logs qui en découleront seront faux (tu n’auras que l’IP du Nginx) et donneront de mauvaises infos au fail2ban qui utilise justement les logs d’apache pour réaliser les blocages.
Tu peux dire à apache de se baser soit sur X-Real-IP soit sur X-Forwarded-For, il y a plein de procédure sur le net pour ce faire.
Je ne vois pas comment le serveur Apache de Jeedom peut savoir que les requêtes qui arriveront proviennent d’un RP et qu’il doit exploiter le x-forwarded-for pour le logging qui sera utilisé par fail2ban…
Le software derrière en PHP le peut si c’est prévu dans le code mais Apache je ne vois pas comment. Et typiquement, ce qu’il explique en terme de comportement c’est exactement le problème.
Personnellement, j’ai dû adapter l’apache, ça ne s’est pas fait tout seul lors de l’installation.
Je confirme, rien n’est modifié par rapport à ça dans le script d’install de Jeedom. J’ai vite fait analysé le script d’install et les fichiers de configuration du GitHub poussés pour la configuration du daemon Apache.
Peut-être que Jeedom sait gérer les headers directement au niveau applicatif pour tracer les clients connectés, mais Apache ne le fait pas tout seul si on ne lui précise pas…
Il faut enable le module remoteip et également modifier le LogFormat pour remplacer la variable client ip classique (%h) par l’IP liée au header XFF (%a).
Sans ça, pas de logs Apache corrects et donc plantage de l’accès à l’interface garanti car f2b bloquera le reverse proxy s’il n’est pas en localhost ou si l’install RP n’est pas sur un net en 192.168.1.0/24 (cf config f2b Jeedom) ignoreip = 127.0.0.1/8 192.168.1.0/24
Je n’ai jamais fait de modif Apache sur ma machine Jeedom.
Depuis le LAN en passant par mon proxy inverse, j’ai l’lP privée du client et pas celle du proxy.
Depuis l’extérieur, en passant par le proxy, j’ai l’IP publique du client.
Oui c’est sûr que c’est plus logique d’utiliser le f2b sur le RP ^^
Mais bon, c’était pour répondre à la demande d’aide initiale et puis le F2B est activé par défaut dans l’installation de Jeedom, donc en soit, on n’a pas réellement d’installation personnalisée, il faut dans tous les cas « bidouiller » si on est hors cadre du Pack DNS Jeedom.
En tout cas, j’ai peut être pas assez fouillé dans le code, mais je ne vois pas de config qui modifie le Logformat et active l’analyse des headers à la place du client IP standard. Mais bon dans tous les cas c’est quand même plus sympa d’avoir les IPs réelles dans les logs Apache quand on est derrière un RP…