Jeedom derriere un reverse proxy

Bonjour,

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 ?

2 « J'aime »

Bonjour,

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 :wink:
Notamment tout ceux derrière les dns jeedom :wink:

ps: oui, je suis derrière un nginx en reverse proxy aussi

1 « J'aime »

Salut !

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 :wink:

5 « J'aime »

Sympa cet accueil chaleureux, ca donne une super image de la communauté :slight_smile:

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.

2 « J'aime »

Essaye de faire une recherche avec ces termes:

Upgrade $http_upgrade
Connection $connection_upgrade
X-Real-IP $remote_addr
X-Forwarded-For $proxy_add_x_forwarded_for
X-Forwarded-Proto $proxy_x_forwarded_proto

Merci Jeandhom

La conf nginx contient ca :
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Ssl on;

Ce qui a mes yeux est suffisant, c’est pour ca que je comprends pas que Jeedom indique l’IP du proxy comme étant l’IP de connection des utilisateurs

Oui il demande de l’aide, sans trop connaitre et en disant Jeedom devrait s’adapter…

Je dis juste avant de ‹ taper › sur Jeedom, faut être sur de ce qu’on avance.

Re-bonjour,

Pour ma part je n’ai que répondu à ta « question » de savoir si jeedom supportait ce type de config.

Si tu as d’autres questions, je t’invite à lire ce poste Comment nous aider à vous aider - ou Comment poser une bonne question?

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 :wink:

1 « J'aime »

Salut,

Essaye peut être de réduire un peu le nombre de réécriture de header pour voir et en ne gardant que ce que Jeandhom indique :

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;

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.

Bonjour,
L’install par défaut de jeedom gère déjà cela et jeedom récupère l’ip comme il faut dans ce cas.

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 vérifierai demain, plus le courage ajd.
Sinon en cas de reverse proxy fail2ban est là, pas sur jeedom.

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 :slight_smile: 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…

1 « J'aime »

Dans les access logs d’Apache (/var/log/apache2/access.log) ?

ls -la /var/log/apache2/access.log
-rw-r----- 1 root adm 0 mai   22  2020 /var/log/apache2/access.log

Non, dans Réglages, Système, Utilisateurs.

Oui donc cela n’a bien rien à voir :slight_smile:

Dans l’interface Jeedom, c’est PHP qui interprète les Header afin d’avoir l’info si elle est présente dans la requête :

public static function getClientIp() {
		if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
			return $_SERVER['HTTP_X_FORWARDED_FOR'];
		} elseif (isset($_SERVER['HTTP_X_REAL_IP'])) {
			return $_SERVER['HTTP_X_REAL_IP'];
		} elseif (isset($_SERVER['HTTP_CLIENT_IP'])) {
			return $_SERVER['HTTP_CLIENT_IP'];
		} elseif (isset($_SERVER['REMOTE_ADDR'])) {
			return $_SERVER['REMOTE_ADDR'];
		}
		return '';
	}

Là on parle d’un paramétrage system lié au serveur lui même et non à l’applicatif PHP :slight_smile: