Aller au contenu

Messages recommandés

Posté(e) (modifié)
il y a une heure, Mic13710 a dit :

On n'ouvre le port 80 que le temps du renouvellement. Le reste du temps on dévalide la règle.

J'ai l'impression que le renouvellement peut dorénavant s'effectuer via le port 443 et uniquement par celui-ci.

Ce week-end j'ai accidentellement cliquer sur "renouveler certificat" et sans avoir rediriger le flux HTTP vers le NAS sur le routeur, le renouvellement s'est bien effectué !?!

Ai-je fumé la moquette ? 😜🤪
Ou avez vous constaté la même chose ? (pour ceux n'utilisant pas acme)

Modifié par Diabolomagic
Posté(e)

@Kuchi69 Il y a moyen avec Filestation de générer des liens de partage fonctionnels avec le reverse proxy (en https et sans numérode  port) car ça fonctionne chez moi.

Je ne sais pas ce qui coince mais chez moi dans accès externe je n'ai rien renseigné dans le nom d'hôte, j'ai juste les ports renseignés http 80 / https 443.

 

Posté(e)
Il y a 14 heures, anorec a dit :

@Kuchi69 Il y a moyen avec Filestation de générer des liens de partage fonctionnels avec le reverse proxy (en https et sans numérode  port) car ça fonctionne chez moi.

Je ne sais pas ce qui coince mais chez moi dans accès externe je n'ai rien renseigné dans le nom d'hôte, j'ai juste les ports renseignés http 80 / https 443.

 

J'ai fait un test, j' ai vidé le champ "Nom d'hôte ou IP statique" et j'ai indiqué le port 80/443. Quand je génère un lien de partage, le lien se génère sous la forme "http://DDNS.com:port/sharing/XXX".
D'une part, le lien reste en http, j'ai toujours le port affiché dans le lien et le plus étrange, c'est que j'ai le nom d'hôte présent dans l'onglet Accès externe>DDNS qui apparaît au lieu de files.ndd.com...

Quelqu'un a une idée ?

  

Il y a 16 heures, .Shad. a dit :

Si tu peux le déplacer sur un autre port c'est tout aussi bien. Si pas, il faudra alors envisager que ton proxy inversé écoute sur un autre port, par exemple 9443. Tu gardes l'avantage du proxy inversé d'exposer la grande majorité de tes applications sur un unique port, mais tu perds l'avantage du port 443 dans le sens où là tu devras taper systématiquement 9443 dans ton URL.

Le système de création de liens de partage n'est pas très adapté avec l'utilisation d'un proxy inversé (pourtant fonctionnalité proposée par DSM nativement). Tu dois juste utiliser l'URL avec laquelle tu te connectes, donc https://files.ndd.com/sharing/...

Ca sert justement à créer une URL de partage, mais elle sera commune à tous les services, donc si tu y mets files.ndd.com / 80 / 443 (dans les trois champs disponibles) et que tu es connecté sur Filestation, tu vas générer un lien de la forme vue précédemment, ce sera également le cas si tu partages via Moments, DSM, etc... on voit très vite la limitation.

Pour moi c'est un gros point noir de DSM, qui ne sera pas corrigé aux dernières nouvelles à la sortie de DSM 7.

Merci pour toutes les précisions, si j'ai besoin de l'accès à distance de ma box internet, je changerai son port d'utilisation, c'est le plus simple et surtout pratique.

Vraiment étrange ce système de création de lien de partage qui semble peu flexible..

 

Posté(e)
Il y a 1 heure, anorec a dit :

@Kuchi69 Je n'ai pas de DDNS et il est donc probablement utilisé prioritairement à l'adresse indiquée dans le reverse proxy.

Si tu n'as rien dans DDNS, si jamais ton adresse publique change, tu dois faire la modification manuellement chez ton fournisseur de domaine et tout non ?

Posté(e)
Le 13/05/2021 à 13:42, MilesTEG1 a dit :

Je cherche à simplifier au max l'accès, pas forcément pour moi, mais pour les autres qui utilisent le service.
Je sais qu'on peut mettre en favoris l'url complète, mais quand tu dois taper l'url si tu n'as pas le favori, c'est plus simple de taper sans le /photo, ou même d'y penser.

Ce n'est pas parce que tu n'y vois pas d'intérêt que d'autres n'en ont pas.

Bonjour,

De retour chez moi je me rends compte que j'ai peut-être dit des bêtises concernant le port utilisé 😦

En résumé je tape photo.ndd  ou photo2.ndd pour arriver respectivement sur Synology Photo du nas1 avec DSM7 et Photostation du nas2 avec DSM6.

Les .htaccess sont les mêmes :

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

RewriteCond %{HTTP_HOST} ^photo.ndd$
RewriteRule ^$ https://photo.ndd/photo [L,R=301]

RewriteCond %{HTTP_HOST} ^photo2.ndd$
RewriteRule ^$ https://photo2.ndd/photo [L,R=301]

Les reverses proxies :

https://photo.ndd ==> http://ipdunas1

https://photo2.ndd ==> http://ipdunas2

 par contre dans le nas1 (dsm7) photo est déclaré en alias sinon ça ne fonctionne pas.

Je mets toutes mes photos dans le répertoire /photo. Dans synology photo il faut que j'aille dans l'espace partagé pour les voir.

Oui Synology Photo se rapproche plus de Moments que de Photostation mais il remplace les deux applications.

Voilà. Désolé pour le retard.

 

 

 

Posté(e)
il y a 1 minute, Jeff777 a dit :

 par contre dans le nas1 (dsm7) photo est déclaré en alias sinon ça ne fonctionne pas.

Heu c'est à dire ? (je n'ai pas utilisé DSM 7 suffisamment longtemps pour me rappeler ce que c'est...

il y a 1 minute, Jeff777 a dit :

Oui Synology Photo se rapproche plus de Moments que de Photostation mais il remplace les deux applications.

Voilà. Désolé pour le retard.

OK 🙂 Merci  et pas grave 😉 

Posté(e) (modifié)
Le 18/05/2021 à 22:30, MilesTEG1 a dit :

Heu c'est à dire ? (je n'ai pas utilisé DSM 7 suffisamment longtemps pour me rappeler ce que c'est...

C'est là (ça existe aussi sur DSM6 mais pas au même endroit) :

 

Capture.thumb.JPG.95bfd9526276fa2b5006504060f1148c.JPG

 

Modifié par Jeff777
Posté(e) (modifié)

Je l'avais momentanément retirée !😜

En fait c'est justement parce que j'ai mis mes photos dans le répertoire /photo qui est celui de photostation. Je pense que Photostation utilise l'alias photo par défaut.

 

 

Modifié par Jeff777
Posté(e)
Il y a 15 heures, anorec a dit :

@Kuchi69 En effet mais je n'ai pas ce problème car j'ai une IP fixe chez Free.

J'ai aussi une IP fixe chez Bouygues mais vu que je change chaque année de FAI...C'est plutôt pratique 🙂

 

Il y a 23 heures, Kuchi69 a dit :

J'ai fait un test, j' ai vidé le champ "Nom d'hôte ou IP statique" et j'ai indiqué le port 80/443. Quand je génère un lien de partage, le lien se génère sous la forme "http://DDNS.com:port/sharing/XXX".
D'une part, le lien reste en http, j'ai toujours le port affiché dans le lien et le plus étrange, c'est que j'ai le nom d'hôte présent dans l'onglet Accès externe>DDNS qui apparaît au lieu de files.ndd.com...

Quelqu'un a une idée ?

  

Merci pour toutes les précisions, si j'ai besoin de l'accès à distance de ma box internet, je changerai son port d'utilisation, c'est le plus simple et surtout pratique.

Vraiment étrange ce système de création de lien de partage qui semble peu flexible..

 

Quelqu'un a une idée afin d'avoir des liens de partages plus "propre" ?

Posté(e)

Bonjour,

Après avoir suivi le tuto, le fonctionnement est OK en interne et en externe sur toutes mes adresses en https.

Par contre, je n'arrive pas à faire fonctionner le "forçage" des adresses http vers https.

Lorsque je tape par exemple https://jeedom.mndd.fr j'accède bien à mon interface. De même avec l'IP en interne.

Mais lorsque l'adresse est http://jeedom.mndd.fr alors j'atterris sur une page de ce type:

image.thumb.png.100307ff18921567b27f475eba21b926.png

 

 

Vous savez où ai-je pu me manquer pour que la redirection forcée ne fonctionne pas ?

Posté(e)

Bonsoir,

Qu'est-ce que tu emploies pour la redirection http vers https ?

il y a 46 minutes, tsubasa37 a dit :

alors j'atterris sur une page de ce type:

c'est toujours la même page? Qu'entends tu par page de ce type ?

 

Posté(e) (modifié)

Oui c'est toujours cette même page sur toutes les url en http vers mon nom de domaine.

"Page de ce type" car je ne sais pas à quoi cela correspond. Est-ce bien mon serveur Apache qui renvoie cette page car il ne sait pas faire la redirection ?

J'ai installé webstation, Apache 2.2 et 2.4, installé PHP 5.2 et 7.4, puis créé à la racine du dossier "web" le fichier .htaccess avec les lignes suivantes:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Modifié par tsubasa37
Message incomplet
Posté(e) (modifié)
il y a une heure, tsubasa37 a dit :

{REQUEST_URI}

On dirait un l minuscule après le UR. C'est un i majuscule qu'il faut.

Si c'est bien le cas remplace par i majuscule et refais un test après avoir vider les caches DNS et navigateur.

C'est possible que ça ne fasse pas de différence. A voir.

Sinon c'est curieux que tu obtiennes cette page normalement si le proxy inverse ne fonctionne pas tu dois tomber sur la page d'accueil de webstation (index.htm à la racine de web). Vérifie ce fichier en tapant dans ton navigateur un proxy-inverse qui n'existe pas. Par exemple  tartanpion.ndd  ndd étant ton vrai nom de domaine.

Si la réponse à bien le cadenas https et que tu tombes sur la même page, la redirection fonctionne mais tu as un pb avec index.html. 

Modifié par Jeff777
Posté(e) (modifié)

@Jeff777

J'ai réécris au cas où, mais c'était bien un I majuscule dans la ligne du .htaccess

Concernant le test proposé, la même page "Full-Text RSS 3.3 -- From FiveFilters.org" s'affiche.

J'ai testé avec http://blablabla.monndd.fr -> Accès direct sur la page Full text RSS

Puis avec https://blablabla.monndd.fr -> Page "Votre connexion n'est pas privée" puis après avoir forcé l'accès j'attéris sur la page Full text RSS

J'ai dû passé à côté de quelque chose mais je n'arrive pas à trouver quoi.

Edit à 21h04: De plus en plus incompréhensible, après redémarrage du serveur et de mon pc, la redirection vers https semble être fonctionnelle mais depuis Chrome uniquement.
Testé depuis un autre navigateur sur l'ordi : échec
Testé depuis mon smartphone Android : Chrome OK et Firefox échec
PS: avant de redémarrer, j'avais créé un Virtual Host sur monndd.fr mais que j'ai supprimé par la suite.

Je suis de plus en plus perdu 🤪

Modifié par tsubasa37
Posté(e)

Pas besoin de faire un virtual host.

Pour le moment  fait tous tes essais en externe par exemple en 4G depuis ton smartphone.

Prend un proxy inversé simple comme filestation ou audiostation.

Si tu fais une requête externe https://file.mnndd.fr (en supposant que ce soit ton proxy inverse)  est-ce que cela fonctionne avec tous les navigateurs après avoir vidé les caches ? Si ce n'est pas le cas reprends le tuto point par point depuis le début.

 

Capture.JPG

Posté(e)
il y a 11 minutes, Jeff777 a dit :

Pour le moment  fait tous tes essais en externe par exemple en 4G depuis ton smartphone.

Oui je fais systématiquement les tests en 4G pour être certain d'attaquer depuis l'extérieur.

 

il y a 12 minutes, Jeff777 a dit :

Si tu fais une requête externe https://file.mnndd.fr (en supposant que ce soit ton proxy inverse)  est-ce que cela fonctionne avec tous les navigateurs après avoir vidé les caches ?

Je confirme, tous les proxy inversés créés fonctionnent nickel depuis tous les navigateurs dès l'instant où je suis en https (ex: https://fil.mndd.fr)
Si je tape http://file.mndd.fr alors ça ne fonctionne pas et je n'atterris pas sur la page index.html de WebStation mais sur cette fameuse page qui commence par "Full-Text RSS 3.3" (aucune idée d'où peut bien provenir cette page)

Posté(e)

Tu peux déjà regarder si c'est bien Webstation qui émet sur le port 80 sur ton NAS et que quelque chose d'autre n'a pas pris sa place. Tu peux commencer par taper en SSH sur ton NAS :

netstat -tunlp | grep 80

Tu dois également vérifier que ta box effectue bien une redirection du port 80 vers le NAS. Et que l'interface de la box n'est pas déjà sur le port 80 (HTTP).

Posté(e) (modifié)

Bonjour,

Je viens de voir qu'il y a une application Full-text RSS dans les paquets de la synocommunity. 

Tu n'aurais pas installé ce paquet?

image.thumb.png.43ff4f8cd3f02785c09e0b8623424cc1.png

Modifié par Jeff777
Posté(e) (modifié)

La page qui apparait par défaut en cas de non résolution du Reverse Proxy, c'est celle portée par le fichier /volume1/web/index.html.

Du moins c'est ce fichier que j'ai modifié pour ne plus avoir le message "Site en construction" ...

Donc l'installation d'un paquet qui aurait modifié ce fichier se tient ....

Modifié par Kramlech
Posté(e)
il y a 9 minutes, Kramlech a dit :

La page qui apparait par défaut en cas de non résolution du Reverse Proxy, c'est celle portée par le fichier /volume1/web/index.html.

oui je suis d'accord et il a dû se passer quelque chose avec l'appli Full-Text RSS installée (peut-être mal) volontairement ou involontairement.

 

Il y a 11 heures, tsubasa37 a dit :

en https (ex: https://fil.mndd.fr)
Si je tape http://file.mndd.fr 

Il n'y pas d'erreur : fil et file ?

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • 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.