JB76 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 @Zeus merci de ta réponse. Mon souci reste toujours le même : impossible de me connecter en sécurisé. Je ne peux actuellement accéder à mon NAS que par l'ip locale ET par le port 5000. Tout le reste me donne en local la capture d'écran que j'ai postée plus haut (qui précise que le site n'est pas configuré totalement). La bizarrerie est que je peux accéder à mes applications (drive, audio station, etc...) depuis mon mobile par les applis DS correspondantes sans problèmes, avec l'adresse audio.ndd.ovh:443 (pour audio station), en précisant connexion https dans la page de connexion de l'appli. Tout accès extérieur m'amène invariablement vers une page d'avertissement de sécurité, même si je tape https://appli.ndd.ovh Pour le certificat, il est par défaut, je peux donc supprimer l'autre, j'imagine (le certificat autosigné de synology). Je vais essayer de refaire le fichier .htaccess depuis textedit (je l'ai fait depuis l'éditeur pages sur mac os). Il est bien dans le dossier web de mon NAS, à côté du fichier index.html. Je ne comprends vraiment pas d'où peut venir l'erreur. Merci d'avance pour toute personne qui aurait une suggestion... 0 Citer
dd5992 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 @Jeanbagnès: Dans ta box, vers quelle machine et quel port renvoie le port 443 venant de l'extérieur? Est-ce qu'il s'agit du port qu'écoute le reverse proxy (celui indiqué dans les champs "Source" des règles du reverse-proxy). Je conseille que ce port ne soit pas le 443, mais un port dédié à cet effet (par ex le 6443) pour éviter les interactions avec le service Web du Syno en https. 0 Citer
JB76 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) Merci de ta réponse! Effectivement, j'avais routé vers le port 443 puisque c'est ce que recommande Kawamashi. Je route donc actuellement depuis la box les ports 80 et 443 vers les mêmes ports de mon NAS. Je vais donc essayer de changer ça et de remplacer le port 443 par le 6443 depuis ma box et dans le paramétrage de mon reverse proxy. Je ne dois remplacer le port que dans la redirection vers le NAS, c'est bien ça? Et laisser 443 en entrée sur la box? Sinon, j'ai quand-même un peu progressé : je peux actuellement accéder à mes applis depuis l'extérieur avec l'adresse https://appli.ndd.ovh sans aucun avertissement de sécurité. En revanche, si je tente de me connecter en précisant l'en-tête https vers mon nom de domaine, j'obtiens une page vide avec un gros numéro 500 au milieu et ce texte : "une erreur s'est produite lors du traitement de cette demande". Je ne sais toujours pas pourquoi la redirection en https ne fonctionne pas... Modifié le 12 juillet 2019 par Jeanbagnès 0 Citer
dd5992 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) il y a 22 minutes, Jeanbagnès a dit : Je ne dois remplacer le port que dans la redirection vers le NAS, c'est bien ça? Et laisser 443 en entrée sur la box? Oui. C'est pour éviter les conflits si tu te connectes de l'intérieur de ton réseau vers https://ton-nas. D'autant plus que tu peux héberger là un site Web que tu peux vouloir accéder avec https://web.ndd.ovh. il y a 22 minutes, Jeanbagnès a dit : si je tente de me connecter en précisant l'en-tête https vers mon nom de domaine, j'obtiens une page vide avec un gros numéro 500 au milieu et ce texte : "une erreur s'est produite lors du traitement de cette demande". Je ne sais toujours pas pourquoi la redirection en https ne fonctionne pas... http plutôt je suppose. En fait, je n'utilise pas cette fonction. Je trouve que de mettre l'entête https:// n'est pas vraiment contraignant, c'est vite mis dans les favoris de ton navigateur. Modifié le 12 juillet 2019 par dd5992 0 Citer
JB76 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 @dd5992 merci de ta réponse. En fait, pour être parfaitement sûr que je comprends bien, ma box ouvre les ports 443 et 80. Elle redirige le 443 vers le 6443 de mon NAS, et laisse le 80 vers le 80 du NAS. En incluant la modification correspondante du pare feu de mon NAS, j'ai bon? Pour la redirection, je viens de revérifier, mais c'est bien lorsque je tape https://www.ndd.ovh que j'ai ce message d'erreur. Je l'obtiens aussi lorsque je tape http://www.ndd.ovh. Ca ne concerne que l'accès au ndd, tou les sous domaines fonctionnent en https depuis l'extérieur. La redirection ne fonctionne toujours pas pour l'instant... J'aimerais bien arriver à régler le problème, mais si vraiment ça déclenche des migraines, je lâcherai l'affaire. 0 Citer
unPixel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Pas eu le temps de tout lire mais c'est quoi cette histoire de port 6443 ?! 😳 Pour ton reverse proxy, il n'y a que le port 443 qui rentre en jeu et qui va vers les services. Ensuite, c'est le NAS qui redirige selon le domaine que ce soit en virtual host ou reverse proxy ! 0 Citer
D34 Angel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Merci @Mic13710, @Zeus et @dd5992 ; vos réponses combinées répondent parfaitement à mes deux premières questions. Concernant la troisième question (appli non présente dans portail des applis) : Il y a 2 heures, Zeus a dit : Pour l'utilisateur, ça sera sur le port 443 qui aura été redirigé avec le domaine (mail.ndd.tld) sur le port de ce dernier. il y a 30 minutes, dd5992 a dit : que tu connaisses l'adresse à utiliser et le port d'accès pour cette application. Comment puis-je connaître le port d'accès à mon appli (Mail Station en l'occurrence) ? Où vais-je trouver cette info ? => Je veux y accéder en webmail. Merci d'avance PS : @Mic13710 , stp, arrête de me vouvoyer (cf. ma signature) 0 Citer
Mic13710 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Moi non plus, je ne vois pas l'intérêt de translater le 443. Le but du reverse proxy c'est bien d'orienter les requêtes vers les applications. Les services web ne sont pas altérés si le 443 est utilisé par le reverse proxy. Ce n'est qu'une question de paramétrage. En plus, l'idée du reverse proxy c'est aussi de pouvoir utiliser la même adresse sur le LAN et sur le WAN. Si on fait une translation 443 WAN vers 6443 LAN, il faut alors modifier l'url selon qu'on se connecte à partir du WAN ou du LAN. Je laisse imaginer la complication. il y a 6 minutes, D34 Angel a dit : PS : @Mic13710 , stp, arrête de me vouvoyer (cf. ma signature) Désolé, je suis peut-être vieux (et probablement vieux jeu), mais sur ce forum c'est comme dans la vie, je ne tutoie que les familiers. Je devrais peut-être moi aussi l'indiquer dans ma signature 😉 0 Citer
unPixel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Citation Comment puis-je connaître le port d'accès à mon appli (Mail Station en l'occurrence) ? Où vais-je trouver cette info ? Si tu ouvres Mail Station depuis DSM, ça te donne pas le port dans la barre d'adresse ? Je n'ai pas ce paquet donc je ne peux pas regarder. il y a 10 minutes, Mic13710 a dit : Je devrais peut-être moi aussi l'indiquer dans ma signature 😉 Plus assez de place 😂 0 Citer
dd5992 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) il y a 50 minutes, Jeanbagnès a dit : Pour la redirection, je viens de revérifier, mais c'est bien lorsque je tape https://www.ndd.ovh que j'ai ce message d'erreur. Je l'obtiens aussi lorsque je tape http://www.ndd.ovh. Ca ne concerne que l'accès au ndd, tou les sous domaines fonctionnent en https depuis l'extérieur. OK. Il faut être clair. www.ndd.ovh est un nom de domaine au même titre que syno.ndd.ovh ou même ndd.ovh. La notion de sous-domaine n'apporte rien. As-tu un enregistrement du reverse-proxy pour https://www.ndd.ovh ? vers quoi celà redirige-t-il? Si tu veux pointer avec cette adresse vers un site web qui écoute sur le port 443 de ton syno, c'est là qu'intervient cette histoire du port 6443 (que j'ai trouvé dans le tuto de @CoolRaoulsur le reverse-proxy avec nginx avant que le reverse-proxy ne soit intégré dans DSM V6): Exemple : disons que tu as un syno, accessible de l'extérieur, avec un reverse-proxy qui écoute le port 443 et une box qui redirige de l'extérieur le port 443 vers le même port de ton nas. Ton nas fournit un service web sur le port 443 et DSM sur le port 5001 en local. Tu veux utiliser les noms de domaine www.ndd.ovh pour le site web et syno.ndd.ovh pour DSM. De l'extérieur tu arrives sur la box, puis sur le syno avec le port 443. Si tu veux atteindre le service web avec https://www.ndd.ovh, ton reverse proxy recevra la demande, mais l'application de la règle https://www.ndd.ovh => https://localhost se mordra la queue. De même si la règle est https://www.ndd.ovh => http://localhost avec un renvoi automatique vers https. Si tu utilises le port 6443 par ex comme port d'entrée du reverse-proxy, ce problème n'existe pas. Tu peux utiliser de l'extérieur comme de intérieur https://www.ndd.ovh pour accéder à ton site web. Modifié le 12 juillet 2019 par dd5992 0 Citer
D34 Angel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 il y a 17 minutes, Zeus a dit : Si tu ouvres Mail Station depuis DSM, ça te donne pas le port dans la barre d'adresse ? Je n'ai pas ce paquet donc je ne peux pas regarder. Non, j'ai http://192.168.0.51/mail/ il y a 31 minutes, Mic13710 a dit : Désolé, je suis peut-être vieux (et probablement vieux jeu), mais sur ce forum c'est comme dans la vie, je ne tutoie que les familiers. Il y a 3 ou 4 mois, dans un topic, j'ai lu Zeus qui avait écrit : "on se vouvoie, maintenant ?". En effet, son interlocuteur l'avait d'abord tutoyé puis était passé au vouvoiement. C'est d'ailleurs ce qui m'avait incité à modifier ma signature. Perso, je trouve bête de devoir, pour ne pas commettre d'impair, se poser des questions du genre "Qui tutoie-je ? Qui vouvoie-je ?". Quand tout le monde se tutoie, comme entre amis/potes/collègues, c'est beaucoup plus simple. Dans le topic A lire avant de vous présenter :) , on peut lire Citation Ce qu’on attend dans une belle présentation : - Votre âge : utile pour plusieurs raisons, on aura plus tendance à adapter nos réponses en fonction de celui ci. Cette phrase de @Einsteinium était-elle une référence au tutoiement/vouvoiement ? J'ai 58 ans et ça ne me dérange pas d'être tutoyé (quel que soit l'âge de mon interlocuteur). Par ailleurs, je vous lis (tous) dans tant de messages que, désormais, vous m'êtes familiers 0 Citer
unPixel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) Citation Si tu utilises le port 6443 par ex comme port d'entrée du reverse-proxy, ce problème n'existe pas. Tu peux utiliser de l'extérieur comme de intérieur https://www.ndd.ovh pour accéder à ton site web. J'avoue que je me perds à te lire. Il n'y a absolument pas besoin de passer par un port tiers. Au jour d'aujourd'hui, on peut uniquement utiliser le port 443 et tout rediriger dessus à une exception près (Drive qui demande aussi l'ouverture d'un autre port pour fonctionner en reverse proxy). Logiquement et en suivant les tutos sur le forum, on doit être amené à ça comme résultat : https://ndd.tld vers Webstation https://nas.ndd.tld vers le port 5000 https://autre.ndd.tld vers autre service Quant au domaine www.ndd.tld, il suffit pour cela d'aller dans sa zone DNS sur son fournisseur de domaine et d'indiquer vouloir une entrée CNAME qui fait www.ndd.tld vers ndd.tld Modifié le 12 juillet 2019 par Zeus 0 Citer
Mic13710 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Une adresse en www.ndd sera résolue par le serveur web sans passer par le reverse proxy. Mais il ne faut surtout pas mettre une règle pour le www.ndd dans le dit reverse proxy, sinon effectivement il ne saura pas quoi en faire. Il n'y a aucun problème à utiliser le 443 pour quasiment tous les services. Je l'utilise même pour OpenVPN en lieu et place du 1194 pour pouvoir l'utiliser de partout (pas de blocage en entreprise par exemple). Ce n'est encore une fois qu'une question d'adressage. Il y a 1 heure, dd5992 a dit : Si tu veux pointer avec cette adresse vers un site web qui écoute sur le port 443 de ton syno, c'est là qu'intervient cette histoire du port 6443 (que j'ai trouvé dans le tuto de @CoolRaoulsur le reverse-proxy avec nginx avant que le reverse-proxy ne soit intégré dans DSM V6): Oui, mais ça c'était avant. 0 Citer
dd5992 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) Tu n'es pas le premier à me challenger sur ce point. Donc il y a quelques mois j'ai revérifié ce que je viens de décrire car je pensais que peut-être le comportement pouvait avoir changé du fait de l'intégration du reverse-proxy dans DSM. J'avais constaté qu'il n'y avais pas de changement de comportement. Je n'ai pas essayé avec ndd.tld vers Webstation et c'est peut être là qu'est l'explication. Donc si tout fonctionne pour vous, je m'incline. il y a 16 minutes, Zeus a dit : Quant au domaine www.ndd.tld, il suffit pour cela d'aller dans sa zone DNS sur son fournisseur de domaine et d'indiquer vouloir une entrée CNAME qui fait www.ndd.tld vers ndd.tld en fait l'utilisation d'un enregistrement CNAME vers ndd.tld plutôt que A pour déclarer "www.ndd.tld" dans la zone DNS ne change rien pour la config du reverse-proxy. Dans les deux cas, c'est le nom "www..ndd.tld" que verra le reverse-proxy, je l'ai testé. Modifié le 12 juillet 2019 par dd5992 0 Citer
Mic13710 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 il y a 3 minutes, dd5992 a dit : c'est le nom "www..ndd.tld" que verra le reverse-proxy, je l'ai testé. si le www n'est pas dans le reverse proxy (où il n'a rien à faire), il ne sera pas résolu par le reverse proxy mais par le serveur web. 0 Citer
unPixel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) En faite, j'ai dit une bêtise. Pas besoin d'ajouter une entrée CNAME ou même A pour www.ndd.tld dans mon cas personnel. Je viens de vérifier et ce domaine m'amène bien à Webstation alors qu'il n'est configuré nulle part pour moi. C'est certainement parce que je résous tout par une entrée *.ndd.tld et qu'ensuite, c'est mon virtual host et reverse proxy qui font leurs travails sur les domaines que je configure. Modifié le 12 juillet 2019 par Zeus 0 Citer
Mic13710 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Oui, c'est normal dans ton cas puisque tu as un wildcard qui renvoie tout sur ton routeur. Si tous les noms sont définis dans ta zone DNS (mon cas), il faut bien une entrée CNAME vers ton ndd ou ns.ndd pour rediriger une requête en www.ndd ou tout autre domaine.ndd En fait, toute requête sur le port 443 qui n'est pas traitée soit par le reverse proxy, soit par le serveur VPN (mon cas) ou tout autre service utilisant ce port est automatiquement dirigée vers le serveur web qui ouvrira le serveur si l'adresse peut être résolu, ou qui renverra une erreur. 0 Citer
unPixel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) En effet, je parlais dans mon cas perso 🙂 Modifié le 12 juillet 2019 par Zeus 0 Citer
D34 Angel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 J'ai voulu tester l'accès à Mail Station en passant par DSM (via https://nas.ndd.tld ) mais je n'ai pas réussi à atteindre Mail Station ; la fenêtre du navigateur s'ouvre mais suis resté sur une page blanche. Il y a 2 heures, Zeus a dit : Si tu ouvres Mail Station depuis DSM, ça te donne pas le port dans la barre d'adresse ? Il y a 1 heure, D34 Angel a dit : Non, j'ai http://192.168.0.51/mail/ Ça m'a donné l'idée de tester : https://ndd.tld/mail/ ... et ça fonctionne nikel Du coup, pour mon Mail Station, pas besoin de passer par le reverse proxi. Par ailleurs, lors du test de https://nas.ndd.tld, j'ai eu la mauvaise surprise de ne pas pouvoir me connecter. Dès la première tentative (avec un autre utilisateur que l'admin), j'ai eu un message m'indiquant que l'adresse IP était bloquée. Je suis donc allé consulter la liste des IP bloquées et, là, surprise ! il s'agissait de l'adresse locale de ma box (192.168.0.254 - spécifiée "privée") J'ai trouvé ça très curieux car je n'ai pas eu plusieurs tentatives de connexion loupées mais bon ... certaines choses me dépassent. Bref, j'ai retiré l'adresse de la liste des IP bloquées et j'ai pu accéder à dsm avec https://nas.ndd.tld. Mais, du coup, je me suis dit que c'était pour cela que mon accès VPN ne marchait plus depuis deux semaines maintenant (les dates de blocage IP et de non fonctionnement VPN coïncidaient) et là BINGO ! ma connexion VPN depuis mon Mac refonctionne ... reste plus qu'à la faire refonctionner depuis mon Linux. Je vais commencer à chercher et, selon le cas, vous rappellerai (Zeus et MIC) sur l'autre topic. Bref, suis super content de mes journées d'hier et d'aujourd'hui. J'ai compris/appris plein de choses (y compris avec des messages s'adressant à d'autres que moi). Grand merci à @Zeus, à @Mic13710 et à @dd5992 0 Citer
JB76 Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Un grand merci à @dd5992, @Zeus et @Mic13710 pour vos réponses et votre intérêt pour mes incompréhensions. J'ai grâce à vous compris des choses et avancé dans ma config. Actuellement, je peux accéder à n'importe quel service en https depuis l'extérieur, sans message d'erreur par le biais de https://service.ndd.ovh Donc, on progresse! Les points à améliorer : - Pas de redirection automatique vers https - Un message d'erreur lié à https://ndd.ovh, mais vu que j'ai absolument rien fait dans webstation (hormis ajouter le fichier .htaccess qui ne semble pas servir à quoi que ce soit pour l'instant), ça ne me semble pas incohérent! Il y a 6 heures, Zeus a dit : https://nas.ndd.tld vers le port 5000 Ca ne fonctionne pas chez moi. A la place, j'accède à mon NAS en local grâce à son ip locale et par le port 5000 uniquement. Ce qui n'est pas grave en soi, puisque je peux quand-même accéder à DSM et qu'à force de la rentrer dans mon navigateur, je la connais par coeur, mais je ne comprends pas pourquoi! Et une question : est-il possible depuis l'extérieur d'accéder à DSM? Si oui, je n'ai pas trouvé comment... Merci encore à tous de votre aide, j'ai compris plein de choses grâce à vous! 0 Citer
unPixel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 Citation - Pas de redirection automatique vers https Regarde si dans Web Station, tu es bien configuré sur Apache et non sur Nginx sinon ça ne fonctionnera pas 😉 Citation Et une question : est-il possible depuis l'extérieur d'accéder à DSM? Si oui, je n'ai pas trouvé comment... Oui mais non recommandé sauf via un accès VPN. Pour ça, je te recommande les tutos sur DNS et VPN de Fenrir 🙂 0 Citer
alan.dub Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) Tu déconseilles aussi via reverse proxy pour accéder au DSM ? Perso même si je l’ai d’activé sur reverse proxy... j’utilise plutôt le VPN Server pour me connecter (service critique), certainement une ancienne habitude ^^ Par contre en LAN, je l’utilise (je ne passe plus par son IP locale), comme pour tous mes autres services d’ailleurs. Modifié le 12 juillet 2019 par alan.dub 0 Citer
unPixel Posté(e) le 12 juillet 2019 Posté(e) le 12 juillet 2019 (modifié) Je passe moi même par tous mes domaines pour mes différents services. En local, tout est accessible et fonctionnel. Par contre, à l'extérieur de chez moi, certains services ne tournent que si je suis sur mon serveur VPN. Modifié le 13 juillet 2019 par Zeus 0 Citer
JB76 Posté(e) le 13 juillet 2019 Posté(e) le 13 juillet 2019 Il y a 15 heures, Zeus a dit : Citation - Pas de redirection automatique vers https Regarde si dans Web Station, tu es bien configuré sur Apache et non sur Nginx sinon ça ne fonctionnera pas 😉 Je viens de vérifier, j'ai configuré Apache HTTP server 2.4 Je cale un peu là dessus, j'ai vérifié et il me semble que chaque point correspond au tuto de Kawamashi... Merci pour la réponse, j'irai voir les tutos de Fenrir que tu me recommandes. 0 Citer
D34 Angel Posté(e) le 13 juillet 2019 Posté(e) le 13 juillet 2019 Bonjour Il y a 14 heures, Zeus a dit : Je passe moi même pas tous mes domaines pour mes différents services. En local, tout est accessible et fonctionnel. Par contre, à l'extérieur de chez moi, certains services ne tournent que si je suis sur mon serveur VPN. C'est une faute de frappe ? Tu voulais bien écrire "par" ? Quand tu es connecté en VPN (de l'extérieur), tu accèdes à DSM via https://nas.ndd.tld ? Si oui, es-tu obligé, pour cela, d'envoyer tout le trafic dans le VPN ? 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.