Aller au contenu

Messages recommandés

Posté(e)

Bonsoir,

Euh oui j'ai les deux, je n'ai pas du comprendre le fonctionnement. Je pensais qu'il fallait créer le virtual host et ensuite configurer une entrée dans le reverse.

Ce n'est pas le cas ?

Posté(e)

C'est très simple :

  • Si Nextcloud est installé d'une façon traditionnelle et que donc il est dans le dossier "web" alors il faut passer par le virtual host.
  • Si c'est installé via un paquet ou Docker par exemple, alors il faut créer un reverse proxy depuis DSM et non dans le virtual host en précisant bien entendu le port d'écoute en local.

Tu l'as installé comment Nextcloud ?

Posté(e)

Ah oups 🙂

J'ai téléchargé l'archive, je l'ai copié dans le rep /volume1/web/nextcloud puis je suis allé terminer l'installation via la page web.

Je passe donc par les virtual host

test1.png.87c23bfdc50f9639d7c0a949caf24fdf.png

Je viens de tester mais j'ai une nouvelle fois 504 Gateway Time-out

Mais plus inquiétant, j'ai un processeur php-fm qui prend tout le processeur lorsque je demande l'adresse https://nextcloud.ndd.tld 

1__ssh.png.7b079819506b886271da9ebb557c8f2a.png

 

Posté(e)

Après je ne sais pas trop pour l'utilisation du proc car je l'ai testé via Docker pour ma part.

Vérifies aussi que tu as bien l'entrée CNAME dans ta zone DNS chez ton fournisseur de domaine et dans ton serveur DNS.

Posté(e)

De ce côté là c'est bon, merci.

Les autres sous-domaines, qui fonctionnent, sont configurés à l'identique.

Je pense que mon problème est lié à Nextcloud (le fichier de config ou le htaccess), si je configure exactement de la même manière avec un /web/test et une page à la cond dedans, ça fonctionne...

Posté(e)

Oui je me doute bien que c'est un htaccess lié à l'application. Mais il faut justement voir son contenu.

Mais fais déjà le test de suppression pour voir. Apres il peut être aussi à plusieurs endroits dans le script.


Envoyé de mon iPhone en utilisant Tapatalk

Posté(e) (modifié)

Problème résolu, mais alors là pourquoi, ben j'espère que des champions du dev pourrons me dire.

J'ai du personnaliser le open_basedir avec les deux chemins de mon Nextcloud (data et le chemin où se trouve l'application) dans le profile PHP que j'utilise :

/volume1/Nextcloud:/var/services/web/nextcloud

Et maintenant ça fonctionne ...

 

J'ai donc configuré un virtualhost basé sur le port et j'ai utilisé le port 444 et j'ai ensuite configuré une entrée dans le reverse proxy avec le nom d'hôte nextcloud.ndd.tld avec le port 443.

Et ça fonctionne.

 

Merci InfoYANN pour l'aide apportée 🙂 A bientôt pour de nouvelles aventures.

Modifié par czara
Posté(e)

Mais tu l'as installé par Docker là ?!
Parce que je vois pas pourquoi ce port si le script a été installé via le dossier web.


Envoyé de mon iPhone en utilisant Tapatalk

Posté(e)

Il me dit que le port 443 (dans la config du virtualhost) est déjà utilisé, alors je n'ai pas cherché j'en ai utilisé un autre.

Par contre je ne suis pas sur que la solution de l'open_basedir soit "normale", à part peut-être pour le chemin d'accès aux données qui est en dehors du répertoire web.

J'affinerai ça plus tard.

Posté(e)

Je réitère ce que j'ai dit cette nuit car tu n'as pas l'air de m'avoir lu ou compris.

Si installation de Nextcloud via un script php standart alors tu dois passer par le virtual host de Web Station ET PAS le reverse proxy.

Si installation via Docker, paquet etc... et que donc ce n'est pas dans le dossier "web", tu dois passer par le reverse proxy de DSM ET NON par le Virtual host.

 

Bref, si mes souvenirs sont bons, tu m'as dit avoir placé le script dans le dossier "web" et l'avoir installé manuellement comme n'importe quel autre script php. Tu dois donc supprimer ton entrée reverse proxy !

Posté(e)

Hello, 

Effectivement je n'avais pas compris, merci beaucoup pour ton aide. J'ai supprimé l'entrée du reverse proxy et modifié mon virtual host avec le nom complet du domaine et sous domaine en host et ça fonctionne !! 

Merci encore, impeccable !!

 

Christophe

Posté(e) (modifié)

Bonjour à tous ^^

Je viens de mettre en place mon premier reverse proxy pour file station (et ainsi reprendre la possibilité de faire des liens partagés pour éviter d'ouvrir le port 5001).

Enfin bref, tout à l'air de fonctionner, mais il y a un truc que je ne comprends pas.

Depuis iOS et l'app DS File, je dois me connecter via xxx.ndd.tld:443.

Depuis macOS, si dans un premier temps je tape xxx.ndd.tld j'ai une erreur 500, mais si je tape d'abords https://xxx.ndd.tld (connexion OK) et ensuite xxx.ndd.tld devient OK (macOS rajouter automatique https:// au début).

Depuis Windows, xxx.ndd.tld donne aussi une erreur 500, le https://xxx.ndd.tld fonctionne mais si retape xxx.ndd.tld ça me redonne une erreur 500.

 

Vous auriez une piste pour ce problème ?

 

Pour info, j'ai tout fait comme indiqué sur le tuto 

coté OVH (zone dns pour le cname)

- coté NAS (ports, web station, certificats, dns server pour le cname, portail des application et proxy inversé))

- coté Freebox (ports)

Modifié par alan.dub
Posté(e)

Ah mais non je suis bête, je croyais que le reverse proxy permettait de virer et le port et le https:// de l'adresse du service.

Genre au début on a https://xxx.ndd.tld:1234 pour terminer avec xxx.ndd.tld.

Alors qu'en faite, il ne retire que le port (c'est le navigateur qui choisi le https://).

 

Chez moi (macOS 10.13 / Safari), si je tape xxx.ndd.tld, Safari ajoute de lui même le https://

A mon boulot (win 7 / Chrome), si je tape xxx.ndd.tld, Chrome n'ajoute pas de lui même le https://

 

Comme indiqué dans ce tuto :

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é).

Comme indiqué dans le tué sur la sécurité des NAS :

Pour la dernière option, l'HSTS, ne l'activez que si vous n'accédez jamais à votre NAS autrement qu'en HTTPS (c'est votre navigateur qui enregistrera cette information et il ne vous laissera plus passer autrement qu'en HTTPS, même si ce dernier est coupé).

 

Donc comme je ne veux pour l'instant que du https, je le coche et tout va mieux ^^

Posté(e)

Bon...

Le HSTS ne marche pas non plus, et le .htaccess ne semble pas faire son boulot (écrit tel quel).

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

Pour info, dans l'onglet proxy inversé je n'ai pas indiqué localhost mais bien l'IP fixe de mon NAS.

Genre https://192.169.0.100:1234

Cela peut-il poser problème ?

Normalement non temps que le NAS ne change pas d'IP local...

Posté(e)

Décidement 😞 

 

Au boulot, sur woindows 7 avec Chrome ou Internet Explorer (en vidant le cache), ça me donne :

https://xxx.ndd.tld : ça marche (logique...)

http://xxx.ndd.tld : ça ne bascule pas en https://

xxx.ndd.tld : ça ne bascule pas en https://

 

Chez moi, sur macOS avec Safari (en vidant le cache), ça me donne :

https://xxx.ndd.tld : ça marche (logique...)

http://xxx.ndd.tld : ça bascule en https://

xxx.ndd.tld : ça bascule en https://

 

Je n'ai rien trouvé sur une quelconque une redirection automatique PHP et NGINX, non plus 😞

C'est lourd 🤪

 

EDIT :

Je viens de faire un essai en supprimant purement et simplement le fichier .htaccess du dossier web.

Chez moi, sur macOS avec Safari (en vidant le cache), ça me donne :

https://xxx.ndd.tld : ça marche (logique...)

http://xxx.ndd.tld : ça bascule en https://

xxx.ndd.tld : ça bascule en https://

Je ne comprends plus 🤣

 

Posté(e) (modifié)

EDIT (encore...) :

Ca a l'air de fonctionner si je le fais à l'unité :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^xxxxxx.ndd.tld$
RewriteRule (.*) https://xxxxxx.ndd.tld/$1 [L,R=301]

Si je dois forcer le https sur une autre page je devrais rajouter, je pense, ses lignes correspondantes :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^xxxxxx.ndd.tld$
RewriteRule (.*) https://xxxxxx.ndd.tld/$1 [L,R=301]

RewriteCond %{HTTP_HOST} !^yyyyyy.ndd.tld$
RewriteRule (.*) https://yyyyyy.ndd.tld/$1 [L,R=301]

 

Il y a certainement des simplifications à faire ^^

Je vais travailler le sujet ^^

Modifié par alan.dub
Posté(e) (modifié)

Ca aussi ça marche ^^

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule (.*) https://xxxxxx.ndd.tld [R=301,L]

Mais, il me faudra ajouter des lignes pour chacune de mes pages (pas bien grave) ^^

Modifié par alan.dub
Posté(e) (modifié)

Bonsoir,

Je me permets de revenir vers vous pour deux ou trois questions concernant le reverse proxy 🙂 

 

1) Tout d'abords, est-il normal avec le reverse proxy, que toutes mes plate-formes aient la même IP visible dans DSM ?

Pour info, elles prennent toutes l'IP locale du NAS, que ce soit en LAN qu'en WAN 😞 

Pas simple pour voir qui est connecté au NAS ou pas 😞 

Mais bon... quelque part il me semble logique que, si on utilise Proxy et Reverse Proxy, tout le ait l'IP du NAS.

 

2) Ensuite, j'ai besoin d'accéder à DSM de l'extérieur via l'app iOS, mais pour ce faire je dois passer par le port https 443 (http 5000 coté local).

Est-ce si dangereux que cela ?

Avant j'utilisais le VPN avec les app iOS (DS Finder, File et Get) lorsque j'étais à l'extérieur et ça marchait aussi très bien.

 

3) Dernière question... mais peut être complètement idiote ^^

Lorsque j'utilise en local le reverse proxy, donc les adresses indiquées dans les options de DSM pour chaque app (dont DS Finder), mon flux de données reste-t-il en local... ou fait-il une boucle en sortant de chez moi pour revenir par le modem ?

Parce qu'en gros, maintenant j'appelle une adresse web (en lien avec l'IP locale et l'IP de la box via OVH), et non plus une simple IP locale...

Conté Finder je reste en AFP://IPLOCALE, donc full local.

Mais ma question tient toujours lorsque je passe via Safari (en local) par DSM, File Station et Download Station.

 

4) Je ne sais pas si je suis clair 😞 

Si ce n'est pas le cas, dites le moi, je tenterais de faire plus... compréhensible 😞 

Modifié par alan.dub

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.