Le 18 août 2023 à 10:50, didier gaumet <didier.gaumet@gmail.com> a écrit :
Bonjour,
rappel: je suis une truffe en réseaux, donc ne pas se fier à mes propos aveuglément
la doc officielle -donc celle qui fait référence- sur le reverse proxy nginx est là:
https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
si je comprends correctement (c'est loin d'être sûr) ça a l'air de dire que tu dois redéfinir la variable host (valeur $proxy_host par défaut) au moyen de la directive proxy_set_header?
mais je raconte peut-être de grosses bêtises.
Le 19 août 2023 à 12:12, François TOURDE <fra-duf-no-spam@tourde.org> a écrit :
Le 19587ième jour après Epoch,
yamo' écrivait:
Je lis dans la doc :
location /some/path/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://localhost:8000;
}
Il suffit donc dans ce cas d'interroger la valeur de "X-Real-IP".
Il y a aussi l'entête x-forwarded-for qui peut jouer ce rôle. Mais dans tous les cas, il faut que l'app derrière aille lire cette valeur.
Un début de réflexion à ce sujet là: https://security.stackexchange.com/questions/95865/difference-between-x-forwarded-for-ip-x-real-ip-vpns-and-tor
Mes 2©
--
Don't plan any hasty moves. You'll be evicted soon anyway.
<div><br></div><div>Voir <a href="https://community.home-assistant.io/t/trusted-networks-when-using-nginx-reverse-proxy/37836">https://community.home-assistant.io/t/trusted-networks-when-using-nginx-reverse-proxy/37836</a></div><div>Et la référence qui y est citée : <a href="https://sgrudadh.blogspot.com/2018/01/nginx-and-home-assistant.html?m=1">https://sgrudadh.blogspot.com/2018/01/nginx-and-home-assistant.html?m=1</a></div><div><br></div><div>Je crois qu’à défaut de savoir on
Le 19 août 2023 à 16:15, François TOURDE <fra-duf-no-spam@tourde.org> a écrit :
Le 19588ième jour après Epoch,
RogerT écrivait:
Bonjour,
C’est très discuté dans les forums.
Cette page que tu indiques semble confirmer que c’est assez flou (les
‘ X-*’ inventés pour faire des corrections rustines).
Disons que ce ne sont pas vraiment des "rustines", mais simplement des
façon de faire liées au cas de figure dans lequel tu te trouves.
Si tu utilises nginx comme reverse proxy, alors quoi qu'il arrive tu vas "perdre" l'IP d'origine. La jonction TCP va se faire entre l'IP
d'origine et ta machine nginx.
Dans ce cas, il faut établir une nouvelle jonction TCP entre ton serveur nginx et le serveur qui délivre le service. Ce dernier n'aura donc comme
IP entrante celle de ton nginx.
Dans le cas où tu souhaites préserver l'IP d'origine pour qu'elle arrive sur ton serveur final, il faudrait que tu passes par un mécanisme de
NAT, comme par exemple le fait un routeur ubiquiti. Dans ce cas, ce
n'est plus du proxy mais du NAT.
Le proxy et le routeur+NAT n'ont pas du tout les mêmes mécanismes d'établissement et de gestion de connection.
En espérant avoir été assez clair.
Le 19 août 2023 à 18:58, Michel Verdier <mv524@free.fr> a écrit :
Le 19 août 2023 RogerT a écrit :
Je sais qu’un reverse proxy peut réécrire les entêtes pour déjà faire >> passer l’adresse IP du client qu’il fait disparaître si on le laisse
faire.
Le problème que tu auras si ton proxy est transparent c'est que ton appli
va répondre vers l'IP du client et ça cassera la connexion. Il faut donc voir dans ton appli l'entête qui doit être utilisée pour stocker l'IP à vérifier.
Le 19 août 2023 à 22:00, François TOURDE <fra-duf-no-spam@tourde.org> a écrit :
Le 19588ième jour après Epoch,
RogerT écrivait:
[...]Le 19 août 2023 à 18:58, Michel Verdier <mv524@free.fr> a écrit :
Le problème que tu auras si ton proxy est transparent c'est que ton appli >>> va répondre vers l'IP du client et ça cassera la connexion.
Techniquement, le proxy transparent peut s'amuser à se faire passer pour l'IP externe, donc ça ne casserait pas la connection, mais je ne connais
pas d'outil qui fasse ça.
Serveur web Apache. https ou WebDAV.Si je comprends bien, il suffirait que le reverse proxy ajoute une
entête avec l’adresse IP du client qui sera lue par le serveur web,
qui répondra ensuite à la requêtes au reverse proxy qui routera au
client.
C’est ça ?
Oui, avec comme petit bémol que si tu t'adresses (ton reverse proxy) à
des services qui ne gèrent pas ça, tu ne vas pas pouvoir t'en sortir.
Par exemple, nginx, apache et d'autres vont pouvoir se baser sur
l'en-tête créé, mais si tu veux t'adresser à des service comme exim, mailman ou transmission, ça risque d'être impossible.
Perso j'utilise haproxy comme reverse (il y a aussi nginx, apache etComment le traites-tu ?
envoy qui font ça très bien), et je suis confronté parfois à ce même souci d'identification de l'adresse IP d'origine.
Le 20 août 2023 à 09:49, Michel Verdier <mv524@free.fr> a écrit :
Le 20 août 2023 RogerT a écrit :
Par exemple, nginx, apache et d'autres vont pouvoir se baser surServeur web Apache. https ou WebDAV.
l'en-tête créé, mais si tu veux t'adresser à des service comme exim, >>> mailman ou transmission, ça risque d'être impossible.
Pas de serveur de messagerie.
Donc positionne un entête comme on t'a suggéré avec proxy_set_header et teste cet entête sur l'apache qui traite la requête. Tu n'as pas besoin
de plus à priori non ?
Bonjour,
Avec nginx configuré en reverse proxy, j’ai un souci pour qu’il passe l’adresse IP du client au serveur web.
Il réécrit l’entête en y mettant son adresse IP (cad celle du serveur où est nginx). C’est cette adresse que voit le serveur web à qui il passe la requête et qui ne sait donc pas où se trouve le client (pour une vérification de sécurité).
Il y a plein de discussions sur les forums à propos d’ancienne et de nouvelle syntaxe nginx.
Vu de loin, ça a l’air simple : contrôler la réécriture des entêtes.
En pratique, comment configurer ? Quelle syntaxe ?
Merci
Le 21 août 2023 à 12:15, François TOURDE <fra-duf-no-spam@tourde.org> a écrit :
Le 19589ième jour après Epoch,
Michel Verdier écrivait:
Le 20 août 2023 RogerT a écrit :
Donc positionne un entête comme on t'a suggéré avec proxy_set_header et >>>> teste cet entête sur l'apache qui traite la requête. Tu n'as pas besoin >>>> de plus à priori non ?Non. Le serveur a juste besoin de lire l’adresse IP du client et de
retourner (au reverse proxy, pour routage) la réponse à la requête.
C'est exactement ce qu'on (moi et d'autres) t'explique. Donc pourquoi
dis-tu "non" ? Explique-nous pourquoi tu ne veux pas faire cette
solution ?
Je pense qu'il dit "non" à "Tu n'as pas besoin de plus à priori non ?"
:)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 299 |
Nodes: | 16 (2 / 14) |
Uptime: | 43:16:58 |
Calls: | 6,682 |
Files: | 12,225 |
Messages: | 5,343,654 |