Dans mes lectures du d=C3=A9but du w-end, je vois qu'il serait possible
d'avoir plusieurs serveurs web sur un m=C3=AAme LAN, derri=C3=A8re 1 seul=
visible
de l'ext=C3=A9rieur qui servirait de "passerelle". Mais je n'ai pas tout =
saisi !
Le cas :
Aujourd'hui il y a un Nginx qui fonctionne sur 1 serveur, accessible
depuis l'ext=C3=A9rieur, via exemple.fr (mon domaine)
Le copain Robert vient faire h=C3=A9berger sa machine avec serveur HTTP(S=
)
chez moi, directement sur mon LAN...:
- serait-il possible de rediriger exemple.fr/robert vers sa machine sur
le LAN ? A priori oui, c'est le but premier ?
- rediriger un autre nom de domaine, robert.fr
- aussi vers l'ext=C3=A9rieur ? genre un exemple.fr/nuage qui renverrait =
vers
une IP/domaine ou URL externe
Et tout ca avec juste 1 Nginx en fa=C3=A7ade ext=C3=A9rieure ?
Des services un peu "lourds" type Nextcloud, Yunohost, un NAS, etc sur
cette 2eme machine sur le LAN. ca ne poserait pas de souci ? (ex:
Nextcloud/Yunohost r=C3=A9pondent selon le domaine demand=C3=A9 par le cl=
ient,
faut pas que Nginx au milieu supprime cette info!)
Mat=C3=A9riellement, la machine Nginx n'est pas tr=C3=A8s sollicit=C3=A9e=
j'imagine ?
Vu que ce n'est pas elle qui bosse selon les requ=C3=AAtes des clients...=
Je pense qu'il faut se diriger vers le "reverse-proxy" si je ne me
trompe pas. Si c'est une fausse piste, ne pas h=C3=A9siter !
Ca a l'air assez dense, =C3=A0 tester !!
Merci d'avance pour vos retours d'exp=C3=A9riences :)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gabriel Moreau
Matériellement, la machine Nginx n'est pas très sollicitée j'imagine ? Vu que ce n'est pas elle qui bosse selon les requêtes des clients... Je pense qu'il faut se diriger vers le "reverse-proxy" si je ne me trompe pas. Si c'est une fausse piste, ne pas hésiter ! Ca a l'air assez dense, à tester !!
Dans mon labo, quasiment tous les services web sont derrière un reverse proxy, Apache dans mon cas. On est 130 utilisateurs... Sauf quelques cas, la plupart des services web se tournent les pouces ;-) Le plus difficile avec le reverse proxy est d'écrire les bonnes règles de ré-écritures. Selon les programmes, c'est plus ou moins bien ficelé et faisable. L'idéal sont ceux qui travaillent en adressage relatif en interne du coup, le passage par un reverse proxy est trivial ! gaby -- Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France mailto: tel:+33.476.825.015
Matériellement, la machine Nginx n'est pas très sollicitée j'imagine ?
Vu que ce n'est pas elle qui bosse selon les requêtes des clients...
Je pense qu'il faut se diriger vers le "reverse-proxy" si je ne me
trompe pas. Si c'est une fausse piste, ne pas hésiter !
Ca a l'air assez dense, à tester !!
Dans mon labo, quasiment tous les services web sont derrière un reverse
proxy, Apache dans mon cas. On est 130 utilisateurs...
Sauf quelques cas, la plupart des services web se tournent les pouces ;-)
Le plus difficile avec le reverse proxy est d'écrire les bonnes règles
de ré-écritures. Selon les programmes, c'est plus ou moins bien ficelé
et faisable. L'idéal sont ceux qui travaillent en adressage relatif en
interne du coup, le passage par un reverse proxy est trivial !
gaby
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:Gabriel.Moreau@legi.grenoble-inp.fr tel:+33.476.825.015
Matériellement, la machine Nginx n'est pas très sollicitée j'imagine ? Vu que ce n'est pas elle qui bosse selon les requêtes des clients... Je pense qu'il faut se diriger vers le "reverse-proxy" si je ne me trompe pas. Si c'est une fausse piste, ne pas hésiter ! Ca a l'air assez dense, à tester !!
Dans mon labo, quasiment tous les services web sont derrière un reverse proxy, Apache dans mon cas. On est 130 utilisateurs... Sauf quelques cas, la plupart des services web se tournent les pouces ;-) Le plus difficile avec le reverse proxy est d'écrire les bonnes règles de ré-écritures. Selon les programmes, c'est plus ou moins bien ficelé et faisable. L'idéal sont ceux qui travaillent en adressage relatif en interne du coup, le passage par un reverse proxy est trivial ! gaby -- Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France mailto: tel:+33.476.825.015
Pierre L.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ifrd8VIHjNoeORHtxW3pnSdWIdwToyKRb Content-Type: multipart/mixed; boundary="F20AO4mixp6su9YzZWVffXVuVvazbSvA3"; protected-headers="v1" From: "Pierre L." To: Message-ID: Subject: Re: Nginx reverse proxy ? Bon choix ? References:
In-Reply-To: --F20AO4mixp6su9YzZWVffXVuVvazbSvA3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: fr Désolé pour le bruit... Cette page a l'air assez explicite dans le cas de différents serveur sur le LAN, avec différents noms de domaine... https://www.it-connect.fr/configurer-nginx-en-tant-que-reverse-proxy/ A voir pour mixer ca avec d'autres types de config, dont le exemple.fr/robert qui renverra sur un "serveur 2"... Merci à vous, c'est parti pour potasser :) --F20AO4mixp6su9YzZWVffXVuVvazbSvA3-- --ifrd8VIHjNoeORHtxW3pnSdWIdwToyKRb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEqp6CU/crahjY2x3n6briFe8NSUUFAlpaA3MACgkQ6briFe8N SUWTYA//RbWL1b4/IFTJ62h9WssxspmPrTjRL7uMjFw63cPY4BViE5sdoNTICO6a QNjTayqhboqTmix8LAN3j3o/hkNWgijqUynw3ywCLgDsucRVArBwnUm+ah8Vbouq mO8HO3ylrCIeScmXctLf/lokf5p0trr72uoaK4bO399qiAgpImTlbL4KDeRzxZuo 2FV6dPinkoz2NSgQgUa4R236e/xg334KPyM4OO1CKoAh2qSt0hGxxwfpPLEnbM5+ snDjOK7cFqPtwTY7KpsCaKI1Q7kW91EK0QMUzAhoul8zzd9otHi8obBDWzNbuswF Y/1/8smjSg5oB3OA4GrpRozLP2xPOe8/mLyVNsHfZ6rwscsg/dGM+xMMtMT2c4cs STxjtfmKsFgFGF54TUhgBJ5AZnVMzI6xsgDQFyZr1jkykLGqeXyt6ns3lvBsmu7Z iBYrZB7hfiHG59fTxZlcldS6R8pwt/Wug+OO8oav2WwBuT9Ie2Z2CKwocPWub6YB eEaxWPlVPqZajn8D3cg0ieVfOGTPIMIeESmCUmgKGFD1uVwq5sPfKR7iPXNcdRC5 q6Xus4HmeSmAWGxfYKOn57zgP0MDEmU66cxzYnnvjm0gbNtaLPYnFQlQuCGgIF7L WE7kLA4G0DKChvSLGq1XI8aZGu3MmsrdGQiSW0VqPE73lvMyLx8 =jRFG -----END PGP SIGNATURE----- --ifrd8VIHjNoeORHtxW3pnSdWIdwToyKRb--
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ifrd8VIHjNoeORHtxW3pnSdWIdwToyKRb
Content-Type: multipart/mixed; boundary="F20AO4mixp6su9YzZWVffXVuVvazbSvA3";
protected-headers="v1"
From: "Pierre L." <petrus@miosweb.mooo.com>
To: debian-user-french@lists.debian.org
Message-ID: <097f5534-3d8c-2414-483f-0e349cc7ea5e@miosweb.mooo.com>
Subject: Re: Nginx reverse proxy ? Bon choix ?
References: <08c35e9b-b41a-40dc-adc3-8c9922e69d12@miosweb.mooo.com>
<fb71e9c0-8f37-30ea-fc8c-284b786e9ae1@legi.grenoble-inp.fr>
<64cb010c-e976-b430-7f9f-6d169be36b37@miosweb.mooo.com>
In-Reply-To: <64cb010c-e976-b430-7f9f-6d169be36b37@miosweb.mooo.com>
Cette page a l'air assez explicite dans le cas de différents serveur sur
le LAN, avec différents noms de domaine...
https://www.it-connect.fr/configurer-nginx-en-tant-que-reverse-proxy/
A voir pour mixer ca avec d'autres types de config,
dont le exemple.fr/robert
qui renverra sur un "serveur 2"...
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ifrd8VIHjNoeORHtxW3pnSdWIdwToyKRb Content-Type: multipart/mixed; boundary="F20AO4mixp6su9YzZWVffXVuVvazbSvA3"; protected-headers="v1" From: "Pierre L." To: Message-ID: Subject: Re: Nginx reverse proxy ? Bon choix ? References:
In-Reply-To: --F20AO4mixp6su9YzZWVffXVuVvazbSvA3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: fr Désolé pour le bruit... Cette page a l'air assez explicite dans le cas de différents serveur sur le LAN, avec différents noms de domaine... https://www.it-connect.fr/configurer-nginx-en-tant-que-reverse-proxy/ A voir pour mixer ca avec d'autres types de config, dont le exemple.fr/robert qui renverra sur un "serveur 2"... Merci à vous, c'est parti pour potasser :) --F20AO4mixp6su9YzZWVffXVuVvazbSvA3-- --ifrd8VIHjNoeORHtxW3pnSdWIdwToyKRb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEqp6CU/crahjY2x3n6briFe8NSUUFAlpaA3MACgkQ6briFe8N SUWTYA//RbWL1b4/IFTJ62h9WssxspmPrTjRL7uMjFw63cPY4BViE5sdoNTICO6a QNjTayqhboqTmix8LAN3j3o/hkNWgijqUynw3ywCLgDsucRVArBwnUm+ah8Vbouq mO8HO3ylrCIeScmXctLf/lokf5p0trr72uoaK4bO399qiAgpImTlbL4KDeRzxZuo 2FV6dPinkoz2NSgQgUa4R236e/xg334KPyM4OO1CKoAh2qSt0hGxxwfpPLEnbM5+ snDjOK7cFqPtwTY7KpsCaKI1Q7kW91EK0QMUzAhoul8zzd9otHi8obBDWzNbuswF Y/1/8smjSg5oB3OA4GrpRozLP2xPOe8/mLyVNsHfZ6rwscsg/dGM+xMMtMT2c4cs STxjtfmKsFgFGF54TUhgBJ5AZnVMzI6xsgDQFyZr1jkykLGqeXyt6ns3lvBsmu7Z iBYrZB7hfiHG59fTxZlcldS6R8pwt/Wug+OO8oav2WwBuT9Ie2Z2CKwocPWub6YB eEaxWPlVPqZajn8D3cg0ieVfOGTPIMIeESmCUmgKGFD1uVwq5sPfKR7iPXNcdRC5 q6Xus4HmeSmAWGxfYKOn57zgP0MDEmU66cxzYnnvjm0gbNtaLPYnFQlQuCGgIF7L WE7kLA4G0DKChvSLGq1XI8aZGu3MmsrdGQiSW0VqPE73lvMyLx8 =jRFG -----END PGP SIGNATURE----- --ifrd8VIHjNoeORHtxW3pnSdWIdwToyKRb--
Pierre L.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aTl83H3cs0Ks7vyy1CSV7OAQHBBwOTxpf Content-Type: multipart/mixed; boundary="M21tMLnjRVHwfnrU6TLADwjQfQjBb5cxc"; protected-headers="v1" From: "Pierre L." To: Message-ID: Subject: Re: Nginx reverse proxy ? Bon choix ? References:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aTl83H3cs0Ks7vyy1CSV7OAQHBBwOTxpf Content-Type: multipart/mixed; boundary="M21tMLnjRVHwfnrU6TLADwjQfQjBb5cxc"; protected-headers="v1" From: "Pierre L." To: Message-ID: Subject: Re: Nginx reverse proxy ? Bon choix ? References:
Le 13/01/18 à 13:31, "Ph. Gras" a écrit : PG> L'objectif du reverse proxy est de faire servir les fichiers statiques PG> (js, jpeg et autres) par l'un des serveurs, et les fichiers dynamiques PG> (php) par l'autre. Pas forcément, y'a plein d'autres usages pertinents. Ça peut être par ex pour avoir du https (éventuellement en h ttp/2) sur le frontal (reverse proxy), puis tout le reste en http 1.1 sur le lan. Ça peut aussi être pour sécuriser un peu mieux une appli un peu trop laxiste, dont on préfère ne pas modifier les réglages (sinon autant le faire sur le serveur de l'appli directement), par ex interdire l'accès à une partie admin depuis le net (ça ne pourra se faire que depuis le la n). J'utilise depuis longtemps l'archi suivante - frontal nginx en https (http/2) => varnish sur le lan pour mettre en cache le statique => backends divers ayant leur serveur http Ça permet de gérer les certificats sur moins de machines, et chan ger de backend(s) simplement (ou en démarre un nouveau, lui envoie des requêtes et vérifie que tout va bien, en cas de pb revenir à l'ancien qu'on a pas encore coupé est instantané). Mais c'est pas forcément pertinent dans tous les cas, pour qq applis a utant mettre le serveur web des applis directement sur le net (éventuellement avec du nat) plutôt que de maintenir 2 serveurs http. -- Daniel Il est difficile d'attraper un chat noir dans une pièce sombre, surtout lorsqu'il n'y est pas. Proverbe Chinois
Le 13/01/18 à 13:31, "Ph. Gras" <ph.gras@worldonline.fr> a écrit :
PG> L'objectif du reverse proxy est de faire servir les fichiers statiques
PG> (js, jpeg et autres) par l'un des serveurs, et les fichiers dynamiques
PG> (php) par l'autre.
Pas forcément, y'a plein d'autres usages pertinents.
Ça peut être par ex pour avoir du https (éventuellement en h ttp/2) sur le
frontal (reverse proxy), puis tout le reste en http 1.1 sur le lan.
Ça peut aussi être pour sécuriser un peu mieux une appli un peu trop
laxiste, dont on préfère ne pas modifier les réglages (sinon autant le
faire sur le serveur de l'appli directement), par ex interdire l'accès à
une partie admin depuis le net (ça ne pourra se faire que depuis le la n).
J'utilise depuis longtemps l'archi suivante
- frontal nginx en https (http/2)
=> varnish sur le lan pour mettre en cache le statique
=> backends divers ayant leur serveur http
Ça permet de gérer les certificats sur moins de machines, et chan ger de
backend(s) simplement (ou en démarre un nouveau, lui envoie des
requêtes et vérifie que tout va bien, en cas de pb revenir à l'ancien qu'on
a pas encore coupé est instantané).
Mais c'est pas forcément pertinent dans tous les cas, pour qq applis a utant
mettre le serveur web des applis directement sur le net (éventuellement
avec du nat) plutôt que de maintenir 2 serveurs http.
--
Daniel
Il est difficile d'attraper un chat noir dans une pièce sombre,
surtout lorsqu'il n'y est pas.
Proverbe Chinois
Le 13/01/18 à 13:31, "Ph. Gras" a écrit : PG> L'objectif du reverse proxy est de faire servir les fichiers statiques PG> (js, jpeg et autres) par l'un des serveurs, et les fichiers dynamiques PG> (php) par l'autre. Pas forcément, y'a plein d'autres usages pertinents. Ça peut être par ex pour avoir du https (éventuellement en h ttp/2) sur le frontal (reverse proxy), puis tout le reste en http 1.1 sur le lan. Ça peut aussi être pour sécuriser un peu mieux une appli un peu trop laxiste, dont on préfère ne pas modifier les réglages (sinon autant le faire sur le serveur de l'appli directement), par ex interdire l'accès à une partie admin depuis le net (ça ne pourra se faire que depuis le la n). J'utilise depuis longtemps l'archi suivante - frontal nginx en https (http/2) => varnish sur le lan pour mettre en cache le statique => backends divers ayant leur serveur http Ça permet de gérer les certificats sur moins de machines, et chan ger de backend(s) simplement (ou en démarre un nouveau, lui envoie des requêtes et vérifie que tout va bien, en cas de pb revenir à l'ancien qu'on a pas encore coupé est instantané). Mais c'est pas forcément pertinent dans tous les cas, pour qq applis a utant mettre le serveur web des applis directement sur le net (éventuellement avec du nat) plutôt que de maintenir 2 serveurs http. -- Daniel Il est difficile d'attraper un chat noir dans une pièce sombre, surtout lorsqu'il n'y est pas. Proverbe Chinois
