dd5992

Dans la plupart des box, le pare feu n'est pas finement paramétrable. Pour vraiment contrôler les flux vers ton syno, il vaut mieux configurer le pare-feu de ce syno... et faire de même pour chacune des machines à protéger. Ou sinon, avoir un routeur en entrée de ton réseau local et y configurer un pare feu qui protège tout ton réseau local. @niklos0: Si quelqu'un arrive à se connecter sur ton réseau local (par exemple grâce à un piratage wifi), il fera partie de ton réseau local et pour lui interdire l'accès à ton syno par exemple, il faudra avoir établi des règles strictes sur le pare-feu de ton syno. Pas évident car usuellement, on permet un accès libre aux différents services du syno à l'ensemble du réseau local. Ça me parait plus simple de bétonner l'accès au réseau local, par exemple en implémentant un filtre par les adresses MAC.

Bonjour à tous les deux. Je me souviens avoir testé une connexion de mon DS411j via une clé wifi compatible. J'ai lu quelque part que ce n'allais plus être supporté dans le futur, mais ça marchait encore avec DSM 6.1 lors de mes tests. Le DS411j était relié à ma box.

Tu n'as pas compris comment fonctionne un reverse-proxy. L'objectif d'un reverse-proxy est de donner accès à plusieurs services de ton réseau local (DSM de ton syno, SRM de ton routeur, DownloadStation, ...) à partir d'internet en passant uniquement par le port 443 (le port par défaut de https). La différentiation entre les services se fait par le nom de domaine (dans ton cas, ce qui précède mondomaine.synology.me). Quand tu te connectes à DSM par l'adresse https://dsm.domaine.synology.me par exemple, sans préciser le port (et donc par le port 443), le flux entrant arrive sur ta box en mode bridge, puis sur ton routeur par le port 443. Dans ton routeur, tu dois avoir une transmission de port pour lui indiquer où diriger ce flux entrant (dans Centre réseau/Transmission de port) port 443 vers l'IP locale du syno, port 443. Ce flux arrive donc sur ton syno avec le port 443 où le reverse-proxy écoute. alors s'applique la règle correspondant au nom de domaine (partie source) que tu as utilisé dans ta requête extérieure (ici https://dsm.domaine.synology.me) qui redirige le flux entrant vers la destination, c'est à dire localhost (ton syno) par le port 1023 (c'est là et là seulement qu'intervient ce port). Comme DSM écoute le port 1023, ça se connecte sur le DSM. Toutes les connexions avec le reverse proxy fonctionnent comme ça. Tu peux mettre les couples (adresse de destination/port de destination) que tu veux. Ce n'est pas visible de l'extérieur, ou l'accès se fait toujours par https://xxx.domaine.synology.me. Transmissions de ports Dans le routeur rt2600ac, ils se définissent dans Centre réseau/transmission de port. il faut juste une règle pour le port 80 et une pour le port 443 Règle 1 : adresse IP privée : l'adresse locale de ton nas port public : 443 port privé : 443 protocole : TCP Règle 2 : le même avec 80 au lieu de 443 et c'est tout. Supprimes les autres transmissions de port. Il peut y avoir besoin d'autres transmissions de port pour des cas particuliers, mais pas pour ton utilisation actuelle. Pour le pare feu La règle pour le réseau local doit permettre à n'importe quel périph local de faire tout ce qu'il veut, soit : Protocole : les deux Source : IP spécifique, sous-réseau, adresse IP : 192.168.0.0, masque 255.255.0.0, ports : Tous Destination :Adresse IP : Tous, ports : Tous. Action : autoriser Remarques complémentaires : Tu veux dire renouveler lon certificat Let's Encrypt automatiquement. Il faut que tous les noms de domaines déclarés dans le certificat soient accessibles par le port 80. On verra plus tard. Faisons déjà fonctionner en https et on verra après pour la redirection de http en https. Certificats : Si tu retombes sur une connexion https "non sécurisée", merci de regarder les raisons en cliquant sur le > à droite de "connexion non sécurisée" pour comprendre. Tu peux nous envoyer une image du résultat si tu veux de l'aide.

Quelques remarques : Pare-feu : Vérifier que la règle "Local Network" permet bien un traffic de toutes les adresses en 192.168.*.* vers toutes les adresses 192.168.*.* pour tous les ports (ça ne se voit pas dans la capture, il faut ouvrir) La deuxième règle ouvre le port 80 à tout vent (la regle traffic France ne s'applique que pour les ports autres que 80 et 443). Tu peux restreindre plus selon ton strict besoin, par exemple en n'autorisant les ports 80 et 443 que vers ton syno (reverse-proxy) car les destinations sont atteintes à travers le réseau local, donc ta première règle s'applique.. mais rien qui empêche de fonctionner. Les règles du reverse-proxy semblent OK. Pour ton premier accès (rtam en http), la redirection ne fonctionne visiblement pas. Comment l'as-tu implémentée? Pour le deuxième, c'est bien en https, mais il y a visiblement un pb de certificat. tu peux en savoir plus en cliquant sur le > à droite de "connexion non sécurisée". Par contre, il ne faut pas donner le numéro de port 2314., C'est le port par défaut de https qui doit être utilisé, donc pas de port à préciser. Pour le troisième, ne mentionner aussi que https://rtan.domain.synology.me sans précision de port. Il est étonnant que ce troisième cas fonctionne. ça veut dire que ta box redirige ce port quelque part. Peux tu donner les redirections de port que tu as définies dans ta box et dans ton routeur? Il ne doit y avoir que celles pour les ports 80 et 443 et celles utiles pour les applis DS-... si tu en utilises. Au fait ta box est elle en mode routeur ou en mode bridge?

Oui, mais sur des équipements différents (routeur et syno). Peux tu poster exactement les règles de ton reverse-proxy (en masquant ton nom de domaine)? par exemple : https://syno.nomdedomaine:443 => http://localhost:5000 ou https://routeur.nomdedomaine:443 => http://IP_locale_du_routeur:8000 et dire ce que tu espères atteindre dans chaque cas.. Si https est précisé dans la source, ce sera forcément du https, à moins que la connexion n'arrive pas là! Pour le webservice du syno, je parle du serveur web si tu as installé le paquet WebStation.

Ce n'est toujours pas clair pour moi : Je suppose que tu veux dire DSM. Tu accèdes donc au DSM du syno, donc c'est OK. Que veux tu dire par (sans https)? C'est donc bon aussi. là, ça ne peut pas rediriger car rien avant "monNomDeDomaine" donc reverse-proxy inactif. Est-ce que ça redirige vers le WebService de ton syno? si oui, c'est normal aussi. tu veux dire quoi par mon_port_de_SRM ?

J'avais mal compris cette phrase. Tu veux dire qu'il redirige vers le routeur, qui est en amont de ton réseau local. J'ai déjà eu des problèmes de ce style, qui se sont résolus en rebootant le routeur et le nas. Pour rendre les choses symétriques pour tous les services, j'ajouterais aussi une règle de reverse-proxy pour le routeur : MonRouteur - Source : https://monRouteur.monNomDeDomain.synology.me (port 443) - Destination : http://IP_locale_du_routeur:mon_Port_de_SRM (port 8000) Dans ce cas tu peux décocher la case "Autoriser l'accès externe à SRM" dans Panneau de config/Paramètres de SRM" car l'accès est vu par le routeur comme venant du réseau local.

Tu veux dire que ta première règle de reverse-proxy est la redirection vers ton routeur? Peux tu nous donner la règle exacte? Note : dans le cas d'un reverse-proxy, le certificat qui s'applique pour la connexion de l'extérieur est celui du syno qui porte le reverse-proxy.

J'ai déjà eu plusieurs fois ce message, sur la page de connexion à DSM de l'extérieur par exemple. Ça correspondait au cas où je restais longtemps sur la page de connexion sans me connecter tout de suite (à cause d'une interruption). La solution que j'ai adopté : faire un rafraichissement de la page dans le navigateur et se connecter ensuite. Le message n'apparait plus. Note : J'utilise Firefox.

Pour FTP, ça ne doit pas fonctionner car le reverse-proxy ne s'applique que pour les protocoles http et https. Il faut aussi faire une transmission du port 443 vers le nas (à faire dans ta box).

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

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.

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

@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.

@D34 Angel: En fait les deux ont des utilisations différentes : Si l'objectif est de donner un accès sécurisé aux services de ton réseau pour un petit nombre pré-déterminé de personnes, alors le VPN est fait pour toi. Si tu souhaites ouvrir à un nombre indéterminé de personnes quelques services http et/ou https de ton réseau en n'utilisant que le port 443 et/ou le 80 ou que tes utilisateurs ont une contrainte de port utilisables de là où ils souhaitent se connecter (certains employeurs limitent volontairement l'utilisation d'Internet de chez eux à certains ports, dont le 443, et certains protocoles, dont le https, ce qui exclue de se connecter à un VPN), utilises plutôt le reverse-proxy. Pas besoin que l'application soit décrite dans le portail des applications. En fait, l'appli peut même être hébergée par une autre machine du réseau local et même encore plus large être accessible sur Internet. Ce qu'il te faut : que l'application soit accessible par le protocole http ou https. Par exemple, pas question d'accéder comme ça à un serveur FTP ou un serveur mail imap, mais OK pour un webmail. que tu connaisses l'adresse à utiliser et le port d'accès pour cette application. Si la machine qui héberge l'application est celle où est implanté le reverse-proxy, tu peux utiliser l'adresse "localhost". Cet éléments sont à renseigner dans les champs "Destination" de la règle du reverse-proxy. que de l'extérieur le port 443 renvoie dans ta box vers le port d'entrée du reverse-proxy

Ta config est proche de la mienne (routeur derrière la box, zone DNS locale, reverse proxy). Je n'utilise le reverse proxy que pour les accès depuis Internet. Les accès locaux se font en utilisant le DNS local qui comporte des entrées supplémentaires par rapport au DNS global qui gère mon nom de domaine (Bookmyname). Pour la config, ma box (une Freebox) est en mode routeur avec une DMZ vers le routeur Syno (le mode bridge induit un bug côté TV pour moi). Le routeur syno a une redirection du port 443 vers le port 6443 du NAS syno où écoute le reverse proxy qui redirige vers les différents services et machines. J'accède de l'extérieur par https://xxx.ndd avec un xxx par service ou machine. Ça fonctionne très bien. Note : dans la config du reverse-proxy sur le NAS Syno, les champs "destination" sont interprétés avec le DNS local, ce qui permet d'utiliser les entrées supplémentaires dont je parlais plus haut.

Si tu gères toi même tes redirections de port dans ta Bbox, il n'est pas utile de renseigner la "Configuration du routeur" dans le panneau de configuration de ton syno (sur le mien, cette page est vide). Tu peux toutes les faire sur ta Bbox. Si tu es connecté de l'extérieur via un VPN, est-il utile d'autoriser par ailleurs (via une redirection de port) l'accès à DSM via le port 5001? quand tu es connecté avec ton VPN, tout se passe comme si tu étais sur ton réseau local, donc tu peux te connecter directement sur ton syno avec le port 5000 ou 5001, les redirections de port ne servent pas. De plus, c'est plus sécurisé!

Oui, mais il faudra gérer toi même les redirections de ports, comme indiqué précédemment. Quickconnect fonctionne en utilisant un site de Synology en intermédiaire, d'où les réticences de sécurité. Il vaut mieux gérer soi même les accès (et donc les redirections de ports) et les réduire au strict minimum.

C'est en effet nécessaire. Le message de DSM "Aucun routeur uPnP n'a été trouvé" signifie que le syno n'est pas en mesure de programmer le routeur lui même (Il ne peut pas le faire pour la Freebox non plus). Il faut se connecter à l'interface de la Bbox (apparemment sur l'IP 192.168.1.254) à partir de ton réseau local et configurer les redirections de ports comme indiqué par @lauber972.

Un certificat certifie un nom de domaine (par ex www.toto.com), donc ton site doit être accessible avec un nom, soit issu d'un DDNS, soit d'un nom de domaine acheté. Tu as donc besoin de l'un des deux. Si ton certificat est déjà créé, utilise le nom qui va avec (tu peux le voir en ouvrant l'info du certificat à l'endroit que je t'ai indiqué tout à l'heure). Let's Encrypt ne fournit pas de DDNS à ma connaissance. Tu as dû utiliser l'encapsulation faite pas le syno. C'est suffisant. Si tu vois le certificat dans ton syno, c'est que ça s'est bien passé. Le cryptage se produit quand tu utilises pour te connecter une adresse du type https://xxx.toto.com. Si tu respecte ça, tu es en HTTPS. Le navigateur vérifie alors que le certificat de ton site (le syno) matche bien avec l' adresse que tu as faite. Il n'y a rien de plus à faire pour rendre le certificat authentique. Bien sûr, si tu joins ton syno avec un autre nom (ex: autre.nom.fr) le navigateur échouera dans sa vérification et émettra un message, même s'il accède à ton syno.

Certes ta connexion est toujours cryptée, mais comme dit @Mic13710, le certificat sert pour assurer les utilisateurs externes qu'ils se connectent bien à ton site et non à un "pirate" c'est donc utile! Regarde sur ton Syno dans "Panneau de configuration/sécurité/certificats" si tu as un ou plusieurs certificats et si c'est bien celui fourni par Let's Encrypt qui est utilisé. sinon corrige ça!

on peut aussi utiliser l'utilitaire Synology Assistant, disponible ici : https://www.synology.com/fr-fr/support/download/DS211#utilities en le lançant, il donnera les caractéristiques du NAS connecté (dont l'adresse IP) et en cliquant dessus puis sur "Connecter", il est possible d'accéder à l'interface (DSM) du Syno.

Bonjour @lauber972 , Comme tu as une IP fixe, il n'est pas indispensable d'utiliser un DDNS dont le but initial est d'avoir un nom de domaine quand on a une IP variable. Tu peux acquérir pour très peu d'argent un nom de domaine personnalisé (par ex chez OVH). Tu peux aussi utiliser un DDNS, mais alors ton nom de domaine sera moins personnalisé (par ex chez Syno tu pourras avoir xxx.synology.me). Pour ce qui est de sécuriser l'accès extérieur à ton NAS, le mieux est de suivre ce tuto : Si tu débutes avec les NAS Synology, tu as aussi ce tuto : Si, après avoir appliqué ces conseils, tu as d'autres questions, n'hésites pas à les poser ici. Note : Une présentation dans la section https://www.nas-forum.com/forum/forum/16-présentation/ nous aiderait à mieux te conseiller.

Bonjour, Je voudrais signaler un problème similaire à ceux mentionnés ici: J'ai un certificat Let's Encrypt généré avec les outils de mon DSM il y a quelques années. J'ai configuré mon firewall de manière à n'accepter l'accès au port 80 de mon syno qu'aux deux IP de Let's Encrypt et depuis lors, le certificat se renouvelle automatiquement tous les 2 mois. Mais ce week-end, je reçois un email de " Let's Encrypt Expiry Bot" me notifiant que le renouvellement n'a pas pu se faire. J'ai dû relancer manuellement le renouvellement après avoir désactivé temporairement mon firewall, ce qui a fonctionné. Les IPs de Let's Encrypt ont-elles changé? Ou est-ce que ça a pu être dû au passage à IPV6 de mon opérateur (Free)? Avez vous des idées? Merci d'avance.

Tout dépend de la manière dont tu auras fait tes sauvegardes sur le DS411. Si tu les fait avec Hyperbackup en mode sauvegarde (par Hyperbackup/Périphérique NAS distant), la sauvegarde n'est pas lisible directement: Après réinstallation et reconfiguration de ton DS1019, il faut faire une restauration (tu peux en même temps restaurer tes paramètres sauvegardés en même temps). Si tu as fait une image de tes partages (par Hyperbackup/Copie Rsync) l'image est lisible par FileStation ou un partage CIFS. Après réinstallation, reconfiguration de ton DS1019 et réinstallation des applications que tu utilises, tu peux utiliser FileStation pour copier tes fichiers de l'image vers leur place définitive. De toute façons, avant de réinitialiser ton DS1019, vérifie que ta sauvegarde a correctement fonctionné en restaurant des fichiers (pas tout bien sûr) dans une zone libre en utilisant le moyen proposé plus haut. Dans le cas 2, tu peux te contenter de parcourir l'arborescence de tes fichiers dans la sauvegarde et d'ouvrir certains fichiers pour voir si le contenu est correct. Inconvénient de la solution 2 : tu ne peux pas sauvegarder comme ça tes applications. Il faut les réinstaller et refaire la paramétrisation. L’intérêt respectif des solutions dépend des applications installées sur ton syno.