[Tuto] Reverse Proxy

[Kawamashi]

Bonjour tout le monde,

 

J'ai l'impression qu'il y a pas mal de monde intéressé par la possibilité d'utiliser un NAS Synology pour faire du Reverse proxy (depuis DSM 6.0). Je voulais ajouter ma pierre à l'édifice en complétant les tutos réalisés, sur ce topic ou ailleurs.

Tout d'abord, je voulais remercier InfoYann pour son tuto et ses réponses à mes questions. Merci également à Fender, qui a écrit le 1er tuto sur le sujet. Pour finir, merci à Fenrir, pour son méga tuto de sécurisation d'un NAS (une vraie bible...), qui aborde le sujet du reverse proxy.

 

LE REVERSE PROXY DE A à Z

I. Utilité et intérêt d'un Reverse proxy

Un Reverse proxy redirige des noms de domaines vers des équipements présents sur le réseau local ou des applications présentes sur le NAS. Cela permet de ne pas avoir à retenir et taper le port des différents services pour y accéder. Par conséquent, ça évite d'avoir à ouvrir sur l'extérieur autant de ports que de services : on se sert juste du port utilisé par défaut pour les connexions HTTPS, le port 443.

Par exemple, si on a affecté le port 45000 à Audio Station et le 45001 à Video Station, il faut normalement taper https://nomdedomaine.fr:45000 ou https://nomdedomaine.fr:45001 pour accéder à ces 2 services. Ce n'est pas très explicite, et il faut que les ports 45000 et 45001 soient ouverts sur le routeur. Plus y il y a de services, pire c'est. Grâce à un reverse proxy, on se contente de taper https://music.nomdedomaine.fr ou https://video.nomdedomaine.fr, et tout passe par le port 443 utilisé par le protocole HTTPS. C'est beaucoup plus simple. Pour plus d'infos, consultez ce tuto et celui-là.

Par contre, il faut absolument préciser https dans l'URL, sans quoi on utilise le HTTP par défaut et ça ne marche pas. Pour éviter ce problème, on va mettre en place une redirection automatique grâce à Web Station.

 

II. Configuration du nom de domaine chez le registrar

Je prends le cas d'une IP fixe car j'ai la chance de ne pas être confronté au problème des IP dynamiques !

Avoir son nom de domaine (NDD) va nous permettre d'accéder à notre réseau local depuis Internet. Une fois le NDD loué, il faut ajouter 2 entrées dans sa zone DNS :
   - une entrée de type A qui redirige le NDD vers l'IP fixe de la box (ndd.fr. => IP fixe)
   - une entrée de type CNAME qui redirigera l'ensemble des sous-domaines vers le NDD (*.ndd.fr. => ndd.fr.)

 
Après cette étape, les tentatives de connexion à fichiers.ndd.fr, video.ndd.fr,… seront acheminées à la box.

 

III. Configuration du routeur

De l'extérieur, on a besoin que le port 443 soit ouvert pour pouvoir se connecter aux applications du NAS de manière simple (pas de port exotique à préciser) et sécurisée (car 443 = HTTPS). Let's Encrypt se connecte par le port 80 pour délivrer le certificat SSL et pour le renouveler. De plus, si on profite de Web Station pour créer un site web, il faut également ouvrir le port 80 pour autoriser les connexions à ce site en HTTP. Donc on va utiliser les ports externes 80 et 443.

Du côté du NAS, le Reverse proxy "écoute" sur le port 443 ou sur le port DSM sécurisé. Vu que je ne trouve pas souhaitable d'exposer DSM sur internet, les connexions sécurisées seront redirigées vers le port 443 du NAS. Web Station utilise le port 80. On va donc rediriger les connexions externes non sécurisées vers le port 80 du NAS.

En résumé, sur le routeur, il faut rediriger les ports externes 80 et 443 vers les ports internes 80 et 443 du NAS. Après cette étape, les connexions utilisant les ports 80 et 443 seront acheminées de la box au NAS.

 

IV. Configuration du pare-feu du NAS

Pour que les connexions ne soient pas rejetées par le NAS, il faut modifier son pare-feu. Plutôt que d'ouvrir complètement les ports 80 et 443 :
   - on ouvre les ports 80 et 443 pour le trafic en provenance de France, pour limiter les risques d'attaque.
   - on ouvre également le port 80 pour le trafic venant des 2 IP que Let's Encrypt utilise pour le renouvellement du certificat (64.78.149.164 et 66.133.109.36, cf ici). Correction de la modération : ces IP ne sont plus valides. Pour la création ou le renouvellement de vos certificats, il faut ouvrir le port 80 sans restriction géographique le temps du processus de création ou de renouvellement, le refermer par la suite pour bloquer les attaques sur ce port

Ces règles sont à entrer dans le pare-feu du NAS (panneau de configuration/Connectivité/Sécurité/onglet "Pare-feu", puis "Modifier les règles").

NB : Les IP utilisées par Let's Encrypt peuvent changerLes IP ci-dessus ne sont plus valides. Il est donc conseillé d'ouvrir complètement le port 80 (au moins pour le trafic en provenance des Etats-Unis) avant la demande initiale de certificat ou en cas de problème de renouvellement de celui-ci.

Après cette étape, les connexions pourront parvenir jusqu'au Reverse proxy du NAS (et jusqu'à WebStation).

 

V. Configuration du portail des applications de DSM

Il faut d'abord définir les ports HTTP qui seront utilisés par les applications auxquelles on veut accéder depuis l'extérieur. Pour ça, aller dans le panneau de configuration/Applications/Portail des applications/onglet "Application".

NB : Il n'est pas nécessaire de définir un port HTTPS pour les applications vu que la connexion est déjà en HTTPS jusqu'au reverse proxy. En effet, il est inutile et contre-productif de doubler les chiffrements.

Après cette étape, si on tape IP_locale_du_NAS:45000, on ouvre directement Audio Station.

Il faut ensuite définir le reverse proxy à proprement parler, à savoir faire correspondre les différents sous-domaines avec les différentes applications. Ça se passe sur la même page, dans l'onglet "Proxy inversé".

Pour chaque application, il faut renseigner :
   - la source (nom du sous-domaine, protocole (HTTPS) et port (443))
   - la destination (nom d'hôte (localhost quand l'appli est sur le NAS, IP s'il s'agit d'un autre élément du réseau), protocole (HTTP) et port (défini à l'étape précédente)).

NB : On utilise "localhost" pour désigner le NAS, car si celui-ci change d'IP, on n'aura pas besoin de reparamétrer le reverse proxy.

Il faut activer le HTTP/2. Par contre, je déconseille le HSTS (c'est le navigateur qui enregistre cette information et il ne laissera plus passer autrement qu'en HTTPS, même si ce dernier est coupé).

Après cette étape, quand on tape https://music.ndd.fr, on est bien redirigé vers audio station, mais avec un avertissement de sécurité du navigateur comme quoi la connexion n'est pas sûre.

 

VI. Obtention du certificat SSL pour le domaine et ses sous-domaines

Il ne faut jamais utiliser de certificat auto-signé (comme celui installé par défaut dans la plupart des équipements), tout comme accepter des exceptions de sécurité (peut provoquer des interceptions de données même sur des sites protégés par de vrais certificats). Le mieux et le plus simple est de se tourner vers une autorité de certification comme Let's Encrypt, bien intégrée chez Synology.

Dans le panneau de configuration de DSM, partie "Connectivité", section "Sécurité", onglet "Certificat", cliquer sur le bouton "Ajouter". A la 2e étape, choisir de se procurer un certificat auprès de Let's Encrypt. A la 3e étape, remplir le NDD et l'adresse mail. Dans le champ "Autre nom de l'objet", mettre le nom de tous les sous-domaines, séparés par des points-virgules. Enfin, cliquer sur "Appliquer".

Après cette étape, le reverse proxy fonctionne sans avertissement de sécurité.

Cependant, quand on tape music.ndd.fr dans un navigateur, celui-ci ne nous redirige pas automatiquement vers https://music.ndd.fr. A la place, il nous renvoie vers ndd.fr:port_DSM_non_sécurisé (même si la connexion n'aboutit pas). Le registrar ne peut pas mettre en place de redirection car seul le nom de domaine est loué chez lui, aucun site n'est hébergé. L'option de redirection présente dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM n'est pas envisageable car elle casse le mécanisme du reverse proxy.

Pour éviter ça, on va créer un site web. Ça nous permettra la création d'un fichier .htaccess, qui redirigera automatiquement les requêtes en HTTPS.

 

VII. Auto-hébergement d'un site web et mise en place des redirections

Il faut installer Web Station. Une fois que c'est fait, ouvrir l'application. Dans la partie "Statut", il faut installer les 2 versions du serveur HTTP Apache et les 2 versions de PHP. Pour ça, cliquer sur les icônes de raccourci présentes dans la colonne "Gestion".

Une fois que c'est fait, on passe à la partie "Paramètres généraux". On sélectionne les versions les plus récentes d'Apache et de PHP, puis on coche la case "Activer un site web personnel" (ce n'est possible que si on a installé les 2 versions d'Apache et de PHP à l'étape précédente).

On n'a pas besoin de changer les paramètres PHP ou de créer un Virtual Host (à moins d'avoir plusieurs sites web à héberger sur le même NAS).

Avec l'installation de Web Station, un dossier Web a été créé à la racine du volume. Le fichier index.html est la page d'accueil du site hébergé sur le NAS. On peut en profiter pour modifier ce fichier afin que notre page d'accueil présente plusieurs liens permettant de se connecter aux différents services présents sur le NAS.

Pour mettre en place la redirection automatique, il faut créer un fichier .htaccess. Pour ça, il faut créer un fichier texte dans le dossier Web. A l'intérieur de ce fichier, on écrit le code suivant :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

On enregistre sous ".htaccess" (donc sans nom mais juste avec l'extension htaccess).

Il faut ensuite redemander un certificat à Let's Encrypt, en ajoutant www.ndd.fr dans le champ 'Autre nom de l'objet" (en plus des noms de tous les sous-domaines).

Après cette étape, quand on tape music.ndd.fr dans un navigateur, celui-ci nous redirige automatiquement vers https://music.ndd.fr.

NB : Il faut préciser le port 443 dans le formulaire de connexion des applications mobiles, sans quoi elles n'arrivent pas à se connecter (donc music.ndd.fr:443 et non music.ndd.fr pour se connecter à DS Audio).
Voir un retour intéressant ici, concernant le reverse proxy et la certification par Let's Encrypt.

Si quand on tape ndd.fr on est redirigé vers l'interface de connexion à DSM (ce que je ne veux pas), il faut vérifier que la case "Activer un domaine personnalisé" dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM est décochée (ou bien qu'on a mis un autre nom de domaine que ndd.fr dans ce champ, cf tuto DNS Server). Par contre, pour se connecter à l'interface de gestion du NAS, il faudra désormais taper l'IP locale du NAS + le port DSM non sécurisé dans la barre d'adresse du navigateur (à moins d'avoir mis en place une zone DNS locale, avec une adresse comme nas.super_nom.lan qui pointe sur le NAS).

J'espère que ce tuto vous sera utile. Je suis preneur de tout retour, remarque ou suggestion ! 

[Mic13710]

C'est un bon complément à mon tuto dont il est fait référence à la fin. Le truc en plus c'est le htaccess que je n'ai pas encore implémenté et que j'essayerai à l'occasion.

Je ne suis pas fana du caractère générique côté registar. Je préfère nommer chaque domaine. Ainsi j'ai le contrôle sur les enregistrements.

[Jojo (BE)]

Je termine de mettre en place la bible sur la sécurité du NAS.,puis m'attaque à cet aspect

Envoyé de mon Nexus 5 en utilisant Tapatalk

[Skylnex]

Super tuto.

Si je souhaite héberger plusieurs sites sur mon NAS à l'aide du paquet Web Station. A quel endroit je doit mettre le .htaccess ?

Je pense qu'il faut faire comme ça : avoir une config "générique" dans web/.htaccess puis créer des virtualhost pour web/monsite1, web/monsite2 etc

De plus, est-ce que c'est possible de réaliser ce tuto dans cocher la case "Activer un site Web personnel". Pour simplement utiliser le dossier web à la racine de volume1 et non des dossier www dans les dossiers des utilisateurs ? Merci

Merci

Modifié le 2 mars 2018 par Skylnex

[Nafel]

Merci pour ce tutos.
A mettre en place simplement ! 

Je rajouterai juste le www.ndd.fr lors de la première création du certificat Let's encrypt, pour éviter de refaire la manip.

 

[Kawamashi]

Le 02/03/2018 à 19:28, Skylnex a dit :

Super tuto.

Si je souhaite héberger plusieurs sites sur mon NAS à l'aide du paquet Web Station. A quel endroit je doit mettre le .htaccess ?

Je pense qu'il faut faire comme ça : avoir une config "générique" dans web/.htaccess puis créer des virtualhost pour web/monsite1, web/monsite2 etc

De plus, est-ce que c'est possible de réaliser ce tuto dans cocher la case "Activer un site Web personnel". Pour simplement utiliser le dossier web à la racine de volume1 et non des dossier www dans les dossiers des utilisateurs ? Merci

Merci

Merci de ton retour. A vrai dire, je ne peux pas te répondre pour l'utilisation du .htaccess avec un virtualhost.

Je viens de tester, et effectivement il est possible de compléter le tuto sans cocher la case "Activer un site Web personnel". C'est bizarre, je suis sûr d'avoir essayé sans la case cochée pendant mes tâtonnements, et que ça ne marchait pas sans.

Bref, preneur d'un retour chez quelqu'un d'autre !

Modifié le 12 mars 2018 par Kawamashi

[yeric79]

Bonjour,

Après avoir participer au tuto haproxy, puis nginx avant la mise en place par syno de la fonction Reverse Proxy, je rencontre un problème que je n'arrive pas a résoudre seul.

C'est pourquoi je vous demande de l'aide :-)

Historique :

Depuis l'intégration du reverse proxy par synology, j'ai reparamété l'ensemble de mes redirections via le Portail des applications,

Tout est fonctionnel pour les fichiers, musique, photos, box, Owa Exchange 2016 , Activesync pour mobile.guacamole installe en chroot debian...

Tout sauf la partie Mapi over Http d'Exchange 2016.

En effet l'Autodiscover semble fonctionner, mais après l'authentification échoue.

Si je redirige mon port 443 directement sur mon serveur Exchange tout fonctionne, c'est donc bien le reverse proxy qui pose un problème.

 

Je trouve sur le net différentes confs pour régler ce problème mais toute liées a nginx-extras, non pris en charge par syno.

 

Quelqu’un a t'il testé cela ou est-il dans le même cas, et si oui quelle configuration a t'il adoptée pour résoudre ce problème ?

 

D'avance merci pour votre aide

 

[Avogadro]

Bonjour,

J'utilise le reverse proxy qui fonctionne bien, mais j'aimerais savoir si il était possible d'ajouter une page de login pour accéder au site redirigé comme lorsqu'on accède aux applications (vidéo station, DSM, etc)

Je sais qu'il est possible d'ajouter une authentification minimaliste avec auth_basic mais ça ne me conviens pas, et on ne peut pas y ajouter des règles de sécurité comme l'équivalent de fail2ban du DSM pour bannir

 au bout d'un certain nombre de tentatives, ou bien encore personnaliser l'image d’accueil comme pour video station.

C'est vraiment la seule chose qui manque au reverse proxy je trouve, et si quelqu'un à déjà pensé à implémenter ça en bidouillant, je suis preneur.

Merci.

 

[unPixel]

Bonjour,

Il est bienvenue qu'un nouveau membre fraichement inscrit se présente dans la bonne catégorie du forum avant de demander de l'aide ;)

Maintenant pour te répondre, tu veux ça pour quelle application ?! Car je vois pas bien comment on pourrait faire en dehors de recompiler le paquet à sa sauce. Et encore faut-il en avoir les connaissances...

Normalement, tu as un accès sécurisé à tout. Non ?

[Avogadro]

Merci d'avoir répondu quand même, désolé pour les présentations.

L'idée était de savoir s'il y avait la possibilité d'en quelque sorte associer la fonctionnalité des "styles de connexions" dans le portail des applications avec les fonctions de reverse proxy,

donc pouvoir ajouter une belle page d'authentification à n'importe quelle règle de proxy inversé pour les redirections. Pour une redirection proxy inverse vers un domaine qui n'est pas ou mal protégé par login (du style vieux CRM), pouvoir ajouter une couche de protection en profitant des styles de connexion du synology serait un énorme plus.

Avec le module auth_basic et le fichier .htaccess ajouté au fichier de configuration server.ReverseProxy.conf on est très limité, c'est pas au top niveau sécurité et pourrait être plus esthétique.

Alors je me disais que peut-être il existait un autre module qui permettrait d'implanter les styles de login de Synology avec la protection ban, à travers les redirections du reverse proxy.

 

[unPixel]

Non, je ne crois pas que ce soit faisable ou alors pas sans se prendre la tête et surtout avec un risque de recommencer après une MAJ du paquet ou de DSM.

[Avogadro]

Il y a 23 heures, InfoYANN a dit :

Non, je ne crois pas que ce soit faisable ou alors pas sans se prendre la tête et surtout avec un risque de recommencer après une MAJ du paquet ou de DSM.

Ok, merci.

[yeric79]

Bonjour

 

Personne pour m'aider?

[alcyon]

Bonjour,

Petite remarque concernant les redirections des services source en HTTPS vers leur destination en HTTP. 

Pas de problème sur les applis Synology (note, drive, etc).

Néanmoins, avec les navigateurs récent, la résolution est bloqué avec une jolie erreur ERR_TOO_MANY_REDIRECTS ... je n'ai pas trouvé de solution pour le moment.

Donc pour le moment je garde le reverse proxy en redirigeant les HTTPS => HTTPS ...

Donc si  @Mic13710 et toi @Kawamashi avait une solution je suis preneur :)

Bon week-end.

Modifié le 29 avril 2018 par alcyon

[Jojo (BE)]

bonsoir,

J'ai mis en place le reverse proxy sur mon Syno principal => merci à TOUS (ils se reconnaitront, car j'en ai mis beaucoup à contribution 🤣)

Et mes 2 syno secondaires sont maintenant également accessibles par le reverse proxy installé sur le syno principal (normal, c'est le principe ...).
Mon seul soucis c'est que depuis lors (j'ai également mis en place le DNS serveur) mes 3 synos ne savent plus envoyer de mail (même le mail de test depuis la config des notifications ne passe plus). Je ne vois vraiment aucune raison, mais c'est la seule chose que j'ai changée sur mon syno principal, et je n'ai RIEN changé sur les 2 synos secondaires.

Si vous avez une piste ...

Modifié le 9 mai 2018 par Jojo (BE)

[flodus]

EDIT: Problème résolu, il a fallu attendre plus de 8 jours pour refaire les certificats, la limite Let's Encrypt était dépassé, mais Synology ne l'indique pas. (vérification du nombre de certificats sur https://crt.sh/)

Bonjour,

Tout d'abord merci à la communauté !!!

J'ai suivi ton tuto ainsi que les 2 de FENRIR sur le reverse proxy et la sécurité.

Franchement je pense pas avoir loupé 1 seule étape (à part sur le tuto de sécurisation de FENRIR où je n'ai pas créé de 2ème compte admin)

J'ai mon domaine synology.me, j'ai créé mes sous-domaines (https wan >> http lan) que j'ai bien indiqué lors de ma création de certificat, toutes les applis sont liés à ce certificat, j'ai supprimé le certificat par défaut du syno, car sur un autre topic j'ai cru comprendre que ça pouvait poser des problèmes, et j'ai coché compatibilité moderne pour le SSL/TLS. 

J'ai réussi à accéder à mes url mais ça n'a pas duré... je crois pas avoir changer quoique ce soit sur le routeur ou sur le syno avant que ça n'arrive mais depuis j'ai beau supprimer et recréer mes certificats, changer de domaine (j'ai un autre nom de domaine chez duckdns, et créer et lier de nouvelles règles en reverse proxy)

J'ai toujours le même problème tous les navigateurs me font une erreur de version de ssl,

sur chrome ça donne : 

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

et sur firefox : 

Informations avancées : SSL_ERROR_UNSUPPORTED_VERSION

 

Quelqu'un a déjà rencontré ce problème ? Ou un début d'explication peut-être ????

 

Merci d'avance !!!

Modifié le 11 juin 2018 par flodus

[yeric79]

Bonjour,

 

je vois que mon problème à déchainé les foules ! 😉 

Bon la solution pour ceux que cela intéresserait.

 

Ce n'est pas possible ! car le reverse proxy n'est pas compatible avec le protocole Mapi over Https 

il faut donc soit avoir Nginx-extras, soit repasser le client Outlook en Rpc over Https (via cle de registre).

 

Voilou.

 

A+

 

 

 

 

 

Modifié le 21 mai 2018 par yeric79

[jfamiens]

Un grand merci à Kawamashi pour ce tutoriel qui m'a pris au moins 4 heures aujourd'hui après avoir galéré pour créer mon certificat Let's encrypt (j'ai du ouvrir le port 80 à tout le monde le temps de faire le certificat). Pour info, je suis en IP dynamique avec fibre orange (Livebox 4), un NDD chez OVH - mon NAS a été configuré en suivant le tuto de FENRIR.

J'ai juste un souci de à partir de la fin de la partie VI. 

Citation

Cependant, quand on tape music.ndd.fr dans un navigateur, celui-ci ne nous redirige pas automatiquement vers https://music.ndd.fr. A la place, il nous renvoie vers ndd.fr:port_DSM_non_sécurisé (même si la connexion n'aboutit pas). Le registrar ne peut pas mettre en place de redirection car seul le nom de domaine est loué chez lui, aucun site n'est hébergé. L'option de redirection présente dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM n'est pas envisageable car elle casse le mécanisme du reverse proxy.

 

De mon côté, je ne rencontre pas ce phénomène , j'arrive bien sur ma page sécurisée "service audio" (personnalisée via la page des applications) sans que le port ne soit visible. Quelqu'un peut il m'expliquer la raison SVP ?

Sur la partie VII, j'ai galéré pour créer le fichier .htaccess jusqu'à comprendre qu'il faille renommer le fichier texte .TXT via file station - impossible à faire sur l'explorateur windows. Enfin, je n'ai pas trouvé sur la racine du dossier WEB de fichier "index.htm", j'ai surement du le supprimer (mais je ne m'en souviens pas) quand j'ai installé mes 2 sous dossiers (un blog Wordpress et un site).

Mon gros problème à l'heure actuelle : je m'aperçois que je ne suis plus en mesure d'accéder à mon interface  via  https://ndd.fr:5001 (mais uniquement via IP_LOCALE:5001) Quelqu'un peut il me dire ce qu'il faut faire SVP ?

Modifié le 18 juin 2018 par jfamiens

[jfamiens]

il y a 37 minutes, jfamiens a dit :

 

Mon gros problème à l'heure actuelle : je m'aperçois que je ne suis plus en mesure d'accéder à mon interface  via  https://ndd.fr:5001 (mais uniquement via IP_LOCALE:5001) Quelqu'un peut il me dire ce qu'il faut faire SVP ?

 

Je me réponds tout seul :dans l'onglet proxy inversé j'ai rajouté une nouvelle ligne "Interface" (source = nas.NDD.fr et destination =localhost:5001 en HTTPS) puis j'ai rechargé le certificat et cela fonctionne dorénavant!

[legrandhuit]

Bonjour,

Je n'arrive pas à faire fonctionner le reverse proxy, j'ai l'impression que mes régles ne sont pas prises en compte.

J'ai configuré mon domaine et mes sous domaines chez OVH, et lorsque j'essaye d'accéder à un équipement par son sous domaine configuré dans le reverse proxy, j'arive sur le nas et pas sur l'équipement.

Est-ce qu'il y a autre chose à faire que la config du reverse proxy?

Merci d'avance

[legrandhuit]

Autant pour moi, il me manquait l'étape du htaccess.

Merci pour le tuto

[czara]

Bonjour à tous, 

J'ai installé NC13 sur mon syno et il y a quelques mois que je l'utilise. Il fonctionne à merveille mais ... Et oui il y a un mais. J'aimerais m'y connecter en utilisant un sous domaine et ça ne semble pas fonctionner.

Aujourd'hui j'y accède par https://ndd.fr/nextcloud.

Pour ce qui est de Webstation j'ai installé et configuré un profil avec Apache 2.4 et PHP7 et configuré un virtualhost. 

 ou 

Pour le reverse proxy 

ou

Mon domaine est configuré avec un champ A qui pointe vers mon IP (qui est fixe) et j'ai créer un champ CNAME qui pointe vers le champ A.

Pour ce qui est du sous domaine fichiers, il pointe vers filestation, c'est ok, pour le sous domaine home il pointe vers jeedom sur une autre pc c'est ok, mais pour le dernier (je précise que l'ip 192.168.1.102 est l'IP du NAS, je l'ai changé juste pour être sur que ce n'était pas le localhost qui embêtait le monde), ça ne fonctionne pas.

J'arrive sur une erreur 400 :

400 Bad Request

Request Header Or Cookie Too Large

J'ai supprimé les cookies liés au site et là je tombe sur une erreur 500, Aïe !

Si j'utilise la config avec le port 444, j'arrive sur une erreur 504 Gateway Time-out

Pour faire un test j'ai créé un seconde virtualhost "test" sur le port 447 et j'ai modifié l'entrée Nextcloud, et ça a fonctionné. Je pense donc que ça vient de Nextcloud, mais il fonctionne. ça ne marche pas si je cumule le reverseproxy et Nextcloud.

Peut-être que vous avez un indice, ou des question à me poser pour m'aider, si c'est le cas n'hésitez pas.

Il y a un fichier htaccess dans le répertoire de Nextcloud, mais je ne maitrise pas assez pour en conclure quoi que ce soit.

Merci pour l'aide que vous pourrez m'apporter.

Bonne soirée/journée

Christophe

[unPixel]

Bonjour,

Et bien dis donc, presque 10 ans sur le forum et seulement deux messages...😯

Il faudrait que tu penses aussi à poster ta présentation comme demandé par le staff.

 

Maintenant, pour répondre à ton soucis, essais de mettre non pas nextcloud mais nextcloud.ndd.tld dans le nom d'hôte de virtual host dans WebStation. Ca devrait je pense régler ton soucis.

[czara]

Bonsoir, 

Je suis les produits Syno et je les utilise depuis plus de 10 ans, mais jusque là je ne rencontrais pas de problème.

Je vais aller faire ma présentation.

Je suis allé modifié, comme indiqué, mais le champ devient rouge et il est indiqué que le nom de domaine existe déjà ...

Merci pour la réponse apportée, et celles à venir 🙂

 

Christophe

[unPixel]

Tu as donc déjà un virtual host avec nextcloud.ndd.tld d'inscrit ? Ou tu as aussi essayé en passant par le proxy inversé dans DSM ?