[Tuto] Reverse Proxy

[Jeff777]

Je serai curieux de connaître l'avis de @.Shad. qui a écrit dans son tuto sur la sécurité (DSM7), à propos de la redirection forcée http=>https dans l'interface DSM  :

REMARQUE : Ne pas activer cette option si vous utiliser un proxy inversé pour accéder à vos services DSM.

[CyberFr]

Il y a 2 heures, PiwiLAbruti a dit :

Au final, selon le navigateur utilisé le .htaccess peut être nécessaire. Pour ma part, j'ai banni ce protocole et fermé le port tcp/80.

Idem chez moi, j'ouvre le port 80 uniquement lors du renouvellement des certificats Let's Encrypt.

Il y a 2 heures, PiwiLAbruti a dit :

Je viens de voir que Firefox fait toujours ses requêtes en HTTP par défaut 🤦‍♂️. Il faut aller dans sur la page de configuration about:config et passer le paramètre dom.security.https_first à true pour que HTTPS soit utilisé par défaut.

Ou plus simplement de se rendre dans Préférences > Vie privée et sécurité et cocher mode "HTTPS uniquement". C'est moins geek mais tout aussi efficace 😀

[Mic13710]

@Jeff777 si tu veux, je te donne le mien.

Ce problème d'incompatibilité de cette option avec le reverse proxy existe depuis ... tout le temps et @.Shad. n'a fait que reprendre ce que Fenrir avait mentionné dans son tuto.

De ce que je comprends, obliger le nas à basculer en https interfère avec les règles de transfert https vers le port correspondant de l'application en http.

Par exemple, une entrée https://nas.ndd qui est transférée vers le localhost:5000 (DSM) est contrecarrée par l'obligation de passer en https (donc 5001). Le transfert ne peut pas aboutir.

Ceci dit, il est possible que Syno aient revu leur copie et que ce dysfonctionnement ait été corrigé dans les dernières versions de DSM. Je n'ai pas essayé et je n'ai pas l'intention de le faire car je ne vois pas d'intérêt pour mon usage de forcer le https en interne (je n'ai pas de http ouvert vers internet).

[PiwiLAbruti]

Que je choisis "Activer le mode HTTPS uniquement dans toutes les fenêtres", le paramètre dom.security.https_first reste à false 🤔

Bref, je n'utilise pas Firefox, et l'important est que ça fonctionne.

----

Pour ceux qui veulent en savoir plus, tout est expliqué ici :

https://support.mozilla.org/fr/kb/mode-https-uniquement-dans-firefox

Dommage que ce ne soit pas activé par défaut sur Firefox.

Modifié le 12 juin par PiwiLAbruti

[alan.dub]

Bien le bonjour tout le monde,

Aujourd'hui (pour je ne sais quelle raison) j'ai vérifié les ports des app synology sur leur site web.

Et... j'ai remarqué que maintenant la quasi totalité des services passaient par le port de DSM (5000 / 5001) 🫤

https://kb.synology.com/fr-fr/DSM/tutorial/What_network_ports_are_used_by_Synology_services

Pour info, mes services n'utilisent pas du tout ces ports mais ceux-ci :

Disk Station : disk.ndd.tld : 5000

Synology Calendar : cal.ndd.tld : 20002
Synology Contacts : card.ndd.tld : 25555

Synology Drive : drive.ndd.tld : 10002
Synology Photos : photo.ndd.tld : 5080
Synology Chat : chat.ndd.tld : 20000

DS / File Station : file.ndd.tld : 7000
DS / Audio Station : music.ndd.tld : 8800
Download Station : down.ndd.tld : 8000
WebDAV Server : web.ndd.tld : 5005
 

Malheureusement je ne retrouve pas les pages reprenant les anciens ports (ou alors il y a un truc que je ne comprend pas).

Voir mes captures ICI, ICI et ICI ^^

Dois-je tout (enfin ceux concernés) basculer en 5000 ? Comprends pas tout là 😅

Modifié le 13 juin par alan.dub

[.Shad.]

@Jeff777 @Mic13710 Comme l'a dit @CoolRaoul, cette redirection s'applique à DSM et aux applications natives faisant l'objet d'un alias personnalisé. Le reverse proxy reste nécessaire pour des applications non natives. Il n'y a pas vraiment de différence, c'est la façon dont les blocs server et location sont créés qui diffère légèrement de l'un à l'autre.

Je pense qu'on peut laisser la remarque telle qu'elle, ça évitera des questionnements inutiles par la suite concernant le pourquoi du je n'arrive pas à me connecter à DSM en HTTPS.

Modifié le 13 juin par .Shad.

[CyberFr]

Il y a 14 heures, alan.dub a dit :

Pour info, mes services n'utilisent pas du tout ces ports mais ceux-ci :

Dés lors que tu as fixé manuellement les ports utilisés par les applications dans le Portail de connexion puis dans les divers reverse proxy, il n'y a aucun changement même si Synology leur a attribué par la suite des ports différents.

Il y a 14 heures, alan.dub a dit :

Dois-je tout (enfin ceux concernés) basculer en 5000 ? Comprends pas tout là 😅

Je n'ai rien changé sur mon NAS et tout fonctionne correctement.

[alan.dub]

Tout fonctionne aussi de mon côté. 
Là dessus pas de problème.

Autres points, sur Synology Contacts et Synology Calendrier, les adresses de connexion proposées ne passent plus par les adresses indiquées dans mon reverse proxy, mais par l’adresse du DSM indiqué sur le reverse proxy (disk.ndd.tld au lieu de card.ndd.tld et cal.ndd.tld).

Malgré cela… ça fonctionne quand même ^^

Il fait que je regarde tout ça. 

Modifié le 14 juin par alan.dub

[CyberFr]

il y a 26 minutes, alan.dub a dit :

Autres points, sur Synology Contacts et Synology Calendrier, les adresses de connexion proposées ne passent plus par les adresses indiquées dans mon reverse proxy, mais par l’adresse du DSM indiqué sur le reverse proxy (disk.ndd.tld au lieu de card.ndd.tld et cal.ndd.tld).

Pas chez moi. Peut-être un problème au niveau de la définition des reverse proxy. Si tu utilises DNS Server, il faut également renseigner les zones CNAME.

[alan.dub]

C'est fait depuis longtemps.

Mais chose "amusante", avant Synology Calendrier et Contacts donnaient bien :

- cal.ndd.tld...

- card.ndd.tld...

Mes deux iPhones et Macbook sont renseignés ainsi et fonctionnent parfaitement.

D'ailleurs avant ces app Synology proposaient aussi deux adresse différentes suivant si c'était pour macOS ou iOS : mais plus maintenant.

Par exemple, pour l'app Calendrier sous iOS c'était :

https://cal.ndd.tld/caldav.php/user

La grande question c'est : pourquoi maintenant ces deux app Synology proposent le disk.ndd.tld (normalement utilisé pour accéder à mon DMS) au lieu des deux autres cal.ndd.tld /card.ndd.tld ^^

Je vais regarder ça.

[alan.dub]

Bon, j'ai testé en utilisant les ports indiqués sur la page de Synology et comme prévu, chaque *.ndd.tld envoi sur DSM (port 5000 donc, port utilisé sur mon disk.ndd.tld pour accéder à mon DSM) 😅

https://kb.synology.com/fr-fr/DSM/tutorial/What_network_ports_are_used_by_Synology_services

J'ai donc tout remis comme c'était, en utilisant les port indiqués en "gris" dans les cellules HTTP de chaque application : ICI

Me reste à voir cette histoire de disk.ndd.tld que Synology Calendrier et Contacts utilisent maintenant.

EDIT : Trouvé 😅

Si je passe par la page de DSM pour ouvrir Synology Calendrier / Contacts, l'adresse pour les app macOS / iOS indique disk.ndd.tld

Mais si je passe directement par la page cal.ndd.tld, l'adresse pour les app macOS / iOS indique cal.ndd.tld (idem pour disk.ndd.tld versus card.ndd.tld.

En gros, tout va bien en faite... je file me recoucher pour quelques jours 😅

 

[miniil]

Bonjour,

Quelqu'un peut m'aider? J'ai suivi toutes les étapes du tuto sauf la dernière qui est de rediriger sous.domaine.xx vers https en plaçant le fichier .htaccess 

Si je mets un fichier .htaccess apparemment il y a trop de redirection (boucle infinie) mais soit mes problèmes sont d'abord les suivants :

1. J'ai essayé pour l'application  File Station sur un port http 45002 avec un reverse proxy https://fiches.domaine.xx:443 redirigé vers http://localhost:45002...  Ca tourne, ça tourne et puis ERR_CONNECTION_REFUSED

2. Pour un autre site web personnel (PHP) hébergé sur mon nas je crée le Web Portal et lui assigne un port en HTTP, pareil, reverse proxy https://xxx.domaine.xx:443 vers http://localhost:monport
Puis création du certificat que j'assigne à ce sous-site.  Là j'arrive a y accéder mais j'ai toujours l'avertissement "Non Sécurisé".

Donc, pourquoi mon reverse proxy ne fonctionne pas pour l'application File Station, et pourquoi ça fonction pour mon sous domaine mais avertissement 🙂

Merci de votre aide.