Aller au contenu

configuration reverse proxy avancé


alexb81

Messages recommandés

Bonjour ,

Je débarque sur la sphère synology avec un DS718+. 😄

Il me sert de backup pour un serveur ovh.

Pour le moment j'y ai installé mes container docker en https sans aucun soucis 😀 le reverse et simple à configurer.

A coté de cela, j'ai installé une vm debian qui auto-héberge un site cozy et là ça se gâte. Une semaine  que creuse internet sans succès.🥵

Je m'explique ce site est normalement conçu pour fonctionner sur une URL https. Hors je n'arrive pas à transférer l'URL source vers ma vm les logs nginx de la vm voit arriver l'IP privé du NAS. du coup mon certificat n'est pas reconnu.

Lors de la configuration du reverse j'ai pourtant ajouté dans les paramètres avancés les directive:

        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            $scheme;

        proxy_set_header        Host            $http_host;

        proxy_set_header        X-NginX-Proxy            true;

J'ai besoin d'aide je ne m'en sors pas

 

merci à tous

Lien vers le commentaire
Partager sur d’autres sites

Bonjour et merci

Effectivement je ne comprends pas voici ce que je peux ajouter

Voici la configuration actuel du reverse
 
Syno_2502498_1.png.5907f46943a13494f0f876158692dc4d.png
 
Chaque règles est configurée de la façon suivante:
Syno_2502498_2.png.3d7fa0edb6750c5fe4a05936b177b2c0.png
 
Syno_2502498_3.png.d5888b13315eef6aea1ad764e4e83e8f.png
Le serveur nginx hébergé par debian réceptionne l'ip 192.168.0.1 (IP du NAS)
 
Extrait des logs:
192.168.0.1 - - [17/Apr/2020:16:07:53 +0200] "GET /realtime/ HTTP/1.1" 400 12 "-" "Mozilla/5.                        0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 S                        afari/537.36"
 
config nginx de la vm au cas ou je l'aurais mal paramétrée pour être derrière un reverse:
server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name cosy.NDD.ovh *.cosy.NDD.ovh;
        return 302 https://$server_name$request_uri;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        ssl_certificate /etc/ssl/private/fullchain.pem;
        ssl_certificate_key /etc/ssl/private/privkey.pem;

        include snippets/ssl-params.conf;
        server_name *.cosy.NDD.ovh cosy.NDD.ovh;
        access_log /var/log/nginx/cosy.NDD.ovh.log;
        error_log /var/log/nginx/cosy.NDD.ovh.error.log;

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;";
        client_max_body_size 1g;

        location / {
                proxy_pass http://localhost:8080;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $remote_addr;
        }
}

 

Voila en espèrant avoir été plus explicite

 

Lien vers le commentaire
Partager sur d’autres sites

Ok au fait je n'avais pas compris ton infrastructure, c'est très brouillon pour le coup.
Première remarque qui me vient à l'esprit, pourquoi faire 6 entrées de proxy inversé qui amènent au même backend ?
Pourquoi ne pas juste garder cosy.ndd.ovh, et faire des CNAME (alias) avec un serveur DNS (celui du Synology par exemple) de ce domaine ?

home.cosy.ndd.ovh               CNAME               cosy.ndd.ovh
photos.cosy.ndd.ovh             CNAME               cosy.ndd.ovh
...

Faire ce que tu fais c'est utiliser un taille-haie pour rafraîchir un géranium.

Deuxième remarque, plus sur le fond de ta question, pourquoi mettre deux proxy inversés en série ? Car si je comprends bien, quand tu renvoies vers 192.168.0.4, c'est ta VM avec un serveur nginx en frontend.
Ça complexifie, ça ralentit et ça n'apporte rien. Un proxy inversé va travailler en parallèle, c'est tout son intérêt, surtout quand on veut faire de la répartition de charge (load balancing).

Ne garde qu'un seul des deux, et si tu sais te servir de nginx, privilégie-le il est plus complet et surtout beaucoup mieux documenté.
Tu gères aussi beaucoup mieux une redirection http vers https que celle que tu as faite là.

Moi je t'aurais conseillé d'utiliser l'image docker linuxserver/letsencrypt, elle embarque un serveur nginx pour la partie proxy inversé, et le renouvellement automatique de tes certificats.
Mais surtout, ne pas mettre deux proxy inversés en série. Je pense que ton problème de certificat vient surtout de là.

Lien vers le commentaire
Partager sur d’autres sites

Merci pour ces information.

 

Effectivement j'ai conscience de 'aspect brouillon😆.

l'image docker linuxserver/letsencrypt c'est elle que j'utilise pour mon serveur distant ovh. Je pensais me simplifier la vie en utilisant le reverse de dsm. 😡. si je l'installe sur mon NAS comment je redirige les flux entrant vers le container?

Pour la configuration de mon domaine j'avoue être un peu juste en compétences.

Donc actuellement ma zone DNS est NDD.ovh dont l'enregistrement point vers mon IP.

Tu me conseille de créer les enregistrement suivant:

type A cozy.NDD.ovh

type cname home.cosy.NDD.ovh

type cname settings.NDD.ovh

...

Quand j'ai fait les modifications, je recrée le certificat et je change la configuration du nginx de la vm cozy afin qu'il ne serve plus de reverse proxy?

Je te remercie encore pour tes réponses elles m'aideront à y voir plus clair.😄

 

Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, alexb81 a dit :

l'image docker linuxserver/letsencrypt c'est elle que j'utilise pour mon serveur distant ovh. Je pensais me simplifier la vie en utilisant le reverse de dsm. 😡. si je l'installe sur mon NAS comment je redirige les flux entrant vers le container?

Le proxy inversé de DSM est effectivement plus simple à configurer.
Il te suffit de rediriger chacune de tes entrées vers le service (backend) que tu veux exposer, comme tu le fais avec 192.168.0.1 pour Piwigo et Nextcloud.
Donc si tu voulais exposer un Piwigo sur ta VM il suffirait de créer une entrée avec comme backend https / 192.168.0.4 / 8081, et pareil pour tes autres services.

Il y a 1 heure, alexb81 a dit :

Tu me conseille de créer les enregistrement suivant:

Tu t'inspires de ce que j'ai proposé dans mon message précédent.

Il y a 1 heure, alexb81 a dit :

Quand j'ai fait les modifications, je recrée le certificat et je change la configuration du nginx de la vm cozy afin qu'il ne serve plus de reverse proxy?

Pourquoi recréer un certificat ? A moins que tu aies besoin de nouveaux sous-domaines, tu n'en as pas besoin.
Tu n'as pas non plus besoin de bouger ta configuration pour l'instant, le proxy inversé de ta VM écoute sur le port 443, si tu ne lui renvoies rien dessus il ne fera rien.
Au moins si tu n'arrives pas à améliorer ta configuration, tu peux toujours récupérer l'actuelle.

Lien vers le commentaire
Partager sur d’autres sites

Le pense que le problème vient aussi du fait qu'il y a un empilement de https, ce qui est proscrit pas les navigateur actuels. Un fois le proxy atteint, inutile de poursuivre sur une nouvelle connexion https. Il faut repartir sur de l'http.

Petite question : est-ce que vous avez validé le transfert http vers https dans DSM ? Si c'est le cas, il faut le supprimer car il altère le fonctionnement du reverse proxy.

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

merci à vous 2, je vais regarder tout cela. ce qui m’ennuie dans cette histoire d'https c'est que les développeurs de l'application cosy disent qu'elle ne fonctionne qu'avec de l'https.

Je suis tombé sur ce post sur leur forum:

Citation
salut aeris et merci pour la réponse
j’aurais une autre question , est-il possible d’utiliser cozy sans les certificats TLS ,en local pour que cozy soit atteignable avec une ip et port local du style 192.168.1.60:9874 , car dans ce cas c’est mon serveur A qui assurera le https avec let’s encrypt vers internet et nginx sur le serveur A qui redirigera le nom de domaine que j utilise pour cozy vers 192.168.1.60:9874


aerisCozy Team member

Oct '18

 

Non. Cozy nécessite HTTPS pour fonctionner correctement.
En plus, Cozy nécessite obligatoirement un nom de domaine, ça n’est pas utilisable avec une IP, chaque application tournant sur un sous-domaine différent.

Je vais déjà regarder pour prendre en compte vos remarques.

Lien vers le commentaire
Partager sur d’autres sites

Merci vraiment pour ton aide,

Je l'avais vu aussi et j'ai également posté sur leur forum pour voir ce qu'ils en pensaient.

Sur chaque VHost, j'ai remis les prérogatives suivantes (car si j'ai bien compris mes différentes lectures, elles permettraient de se présenter à la VM avec NDD.ovh et non l'IP du NAS.)

X-Real-IP $remote_addr

X-Forwarded-For $proxy_add_x_forwarded_for

X-Forwarded-Proto $scheme

Host $http_host

X-NginX-Proxy true

Peux-tu me confirmer que ma config reverse semble correcte?

Pour la partie VM, je vais creuser sur le forum de l'application et reviendrai expliquer la conf quand elle sera fonctionnelle.

Encore merci à toi.

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...

Bonjour,

Au cas ou d'autre chercherai. J'ai pu faire fonctionner l'application Cozy sur mon Syno. Pour ce faire, j'ai viré le Nginx installé de base sur la Vm et redirigé mes flux cers l'ip de la vm. la seule entête spécifique à utilisé été Host.

Merci pour votre aide.

Lien vers le commentaire
Partager sur d’autres sites

  • 4 semaines après...

Salut Alexb81. Je suis novice en la matière et j'ai essayé l'installation de cozy cloud via docker mais j'ai merdé à un moment. Pourrais-tu faire un tuto si possible de la marche à suivre stp ? En regardant chez Cozy, ils disent qu'ils n'ont pas développé d'image pour NAS bizarrement.

Lien vers le commentaire
Partager sur d’autres sites

Salut

Personnellement je n'utilise pas docker pour mon cozy mais une VM Debian hébergé par mon NAS.

Pour ce faire, j'ai installé une Debian puis j'ai suivi la doc suivante que tu as du déjà voir:

https://docs.cozy.io/en/tutorials/selfhost-debian/

j'ai créé ma stack cosy puis supprimé Nginx.

J'ai modifié le fichier de paramètre cozy afin qu'il écoute sur l'ip du serveur et pas la 127...

J'ai créé mes Vhost dans syno directement qui pointent vers: http://ip:port et qui n'ont qu'une variable dans l'entête: Host:$host

Voila. Si tu as besoin de plus de précision n'hésites pas. Pour le moment, je n'ai pas le temps pour le tuto mais il est prévu. Je suis juste en train de finir ma conf et rencontre des problèmes avec collabora online

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...
Le 01/06/2020 à 06:47, alexb81 a dit :

Salut

Personnellement je n'utilise pas docker pour mon cozy mais une VM Debian hébergé par mon NAS.

Pour ce faire, j'ai installé une Debian puis j'ai suivi la doc suivante que tu as du déjà voir:

https://docs.cozy.io/en/tutorials/selfhost-debian/

j'ai créé ma stack cosy puis supprimé Nginx.

J'ai modifié le fichier de paramètre cozy afin qu'il écoute sur l'ip du serveur et pas la 127...

J'ai créé mes Vhost dans syno directement qui pointent vers: http://ip:port et qui n'ont qu'une variable dans l'entête: Host:$host

Voila. Si tu as besoin de plus de précision n'hésites pas. Pour le moment, je n'ai pas le temps pour le tuto mais il est prévu. Je suis juste en train de finir ma conf et rencontre des problèmes avec collabora online

Merci beaucoup pour tes explications ! Je vais tenter le coup voir si j'arrive à quelque chose.

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.