Classement

Pour beaucoup de personnes, les réseaux informatiques sont assez mystérieux. On connait notre box généralement fournie par notre fournisseur d’accès qui est connectée (à quoi ?) via le câble téléphonique ou la fibre. On branche notre ordinateur à cette box, soit par un câble ethernet, soit de plus en plus souvent en wifi … et on peut alors communiquer avec le monde entier. Bien souvent, ça s’arrête là. Alors l’arrivée d’un NAS dans un foyer va faire prendre conscience de l’étendue de notre ignorance sur le sujet. Ce petit guide, qui n’est pas un tutoriel au vrai sens du terme, doit vous permettre de vous familiariser avec un certain nombre de termes, et d’en comprendre le sens. Je n’ai pas pour ambition de faire de vous des spécialiste réseaux, mais simplement de faire en sorte que, grâce à quelques explications simples, les tutoriels présents dans ce forum ne soient un peu plus que de simples recettes de cuisines que vous suiviez à la lettre sans vraiment comprendre à quoi ça sert. Je suis conscient que les spécialistes « tiqueront » à la lecture de certaines définitions ou explications, mais c’est le prix à payer pour rendre les choses simples et compréhensibles. Réseau informatique, Serveurs et Clients Commençons par le début. Un réseau informatique est un ensemble d'équipements reliés entre eux pour échanger des informations. L’échange d’informations se fait généralement entre un Serveur et un Client. Le Client pose une question à un Serveur, le Serveur envoie la réponse au client. Par exemple, c’est que l’on fait quand on fait une recherche sur Google : depuis un navigateur (sur notre ordinateur, c’est le Client), on demande à Google (ou plutôt à un Serveur de la société Google) de faire une recherche, puis le Serveur renvoie la réponse vers notre ordinateur… Jusque-là, cela parait simple et assez intuitif. Là où cela commence à devenir intéressant, c’est lorsque l’on commence à s’intéresser à la manière dont le client identifie le serveur auquel il s’adresse parmi les millions de machines connectées sur le gigantesque réseau informatique mondial qu’est internet (que l’on confond parfois avec le WEB, qui n’en est qu’un pourtant qu’un composant). Adresse IP, et Nom de Domaine Il faut savoir que toute machine connectée à internet a un numéro d’identification qui lui est propre : son adresse IP. Ces adresses IP sont fournies par les fournisseurs d’accès. Une adresse IP est unique, en ce sens qu’à un instant donné, elle ne peut être attribuée qu’à une et une seule machine. Pour un particulier (en France), cette adresse IP est attribuée à sa box. Si cette adresse IP est toujours la même, on dit que c’est une adresse IP fixe. Si elle change au cours du temps, on dit que c’est une adresse IP dynamique. Seul FREE propose systématiquement et gratuitement à tous ses abonnés une adresse fixe. Les autres fournisseurs d’accès fournissent par défaut une adresse IP dynamique (il faut payer pour avoir une adresse fixe). NDLR : ceci était vrai il y a quelques temps. Depuis, avec la généralisation de la fibre et la pénurie d’adresse IP, les choses ont évoluées dans un sens ou dans l'autre… Il existe deux sortes d’adresse IP : les IP V4 (les plus utilisées, mais qui commencent à être en pénurie), et leurs successeurs les IP V6 (dont je ne parlerai pas ici car c'est un sujet que je suis loin de maitriser). Les adresses IP V4 sont représentées par une série de 4 chiffres compris entre 0 et 255 et séparés par des points (xxx.xxx.xxx.xxx). Et c’est là que je vais commencer une analogie : je vais comparer un serveur à un centre commercial. Si je veux me rendre dans un centre commercial, il faut que j’en connaisse sa situation géographique. Pour cela, il existe une codification comprise et interprétable de manière unique dans le monde entier : ses coordonnées GPS. En donnant une latitude et une longitude, on tombe sur un point unique à la surface du globe. L’adresse IP de notre serveur correspond aux coordonnées GPS de notre centre commercial. Mais on s’accordera tous pour dire que des coordonnées GPS sont difficilement mémorisables. Il est bien plus simple de retenir une adresse postale plus explicite comme par exemple « 25 rue Tabaga, 75250 Légume sur Seine, France ». Et bien pour notre serveur, c’est pareil : on peut définir un Nom de Domaine (NDD) qui correspondra à son adresse IP Et plutôt que de demander à accéder au serveur ayant l’adresse IP 172.217.22.142, il est plus simple de demander à accéder au serveur ayant le nom de domaine « google.com » !!! Et de la même manière qu’un GPS est capable de transformer une adresse postale en coordonnées GPS pour vous montrer où cela se situe sur une carte, il existe des serveurs que l’on appelle Serveur DNS (Domain Name System) qui permettent de transformer un NDD en adresse IP. Donc je pense que vous avez compris comment la saisie d’un Nom de Domaine dans la barre d’adresse d’un navigateur permet d’accéder à un unique serveur quelque part sur la terre. Les ports – Kesako ? Revenons à notre centre commercial. Le but n’est généralement pas simplement d’aller au centre commercial, mais d’aller dans une des nombreuses boutiques de ce centre commercial. Et comment trouve-t-on cette boutique ? En général, elle est identifiée par un numéro. Pour aller discuter avec le boucher de notre centre commercial, on va se rendre à la boutique 18 … Pour notre serveur, c’est pareil. Le serveur peut héberger de nombreux services qui vous attendent derrière ce que l’on appelle un port (on dit que le service écoute un port). Un serveur possède 65 536 ports, et donc potentiellement, il peut héberger autant de services…(ok, il faudrait quand même une « gooossse » machine !). Donc pour pouvoir discuter avec un service hébergé par un serveur, il faut aussi indiquer dans l’adresse le numéro de port écouté par ce service. Ceci se fait en ajoutant « :<port> » après le NDD. Par exemple, pour accéder au serveur WEB situé à l’adresse IP 172.217.22.142 (google.com pour ceux qui suivent), il faut saisir l’adresse « google.com:80 » C’est là que j’entends une rumeur venue du fond de la salle : « Mais quand je navigue sur internet depuis mon navigateur préféré, je n’ai jamais saisi de numéro de port comme cela !!! ». Vous avez raison. C’est tout simplement qu’il existe une normalisation de ces numéros de port, et que certains services écoutent toujours (par défaut) les mêmes ports. En particulier les serveurs Web, et ce sont ces serveurs qui sont interrogés par nos navigateurs. Depuis un navigateur, on peut interroger un serveur Web soit via le service « http », soit via le service « https » (qui est un service sécurisé, qui chiffre les données transférées entre le client et le serveur, ce qui peut éviter que par exemple, votre mot de passe transite en clair sur le réseau). Et bien par défaut, le service « http » écoute le port 80, alors que le service « https » écoute le port 443. Alors ce sont les navigateurs qui ajoutent la notion de port au NDD indiqué, sans vous le dire et sans vous demander votre avis… J’ai bien précisé « par défaut », car rien n’interdit de paramétrer un serveur web pour qu’il écoute sur d’autres ports que les ports standard. Et il en existe un que vous connaissez sans doute bien : le serveur Web qui vous permet d’accéder au DSM de votre NAS favori. En effet, ce serveur écoute le port 5000 en http, et il écoute le port 5001 en https. Vous comprenez maintenant pourquoi il faut que vous saisissiez une URL de type « http://<IP>:5000 » pour accéder au DSM de votre NAS… Réseau étendu (WAN) vs Réseau local (LAN) Le WAN (Wide Area Network, ou réseau étendu) désigne un réseau d'ordinateurs connectés les uns aux autres, à l'extérieur de votre propre réseau. Considérez le réseau WAN comme Internet. C’est un modem (on continue à utiliser ce terme, bien qu’il ne soit plus forcément en adéquation avec les technologies ADSL ou Fibre) qui reçoit et envoie des informations à Internet. Et c’est un routeur qui va distribuer ces informations vers les machines de votre réseau local. Le LAN (Local Area Network, ou réseau local) désigne les appareils connectés, par Wi-Fi ou connexion filaire, dans votre domicile ou bureau. Il s'agit de votre réseau personnel. Ensemble, votre ordinateur, votre téléphone, votre tablette, votre NAS, votre routeur, etc composent votre LAN. Le réseau local est mis en relation avec le WAN par la box fournie par votre opérateur. Cette box est un appareil multifonction qui joue plusieurs rôles : Modem Routeur Serveur DHCP Point d’accès Wifi Switch Ces différents composants peuvent faire l’objet d’appareils indépendants. C’est par commodité que les opérateurs ont tout regroupé dans le même appareil. Le modem sert de traducteur technique pour que le WAN et le LAN puissent se comprendre, quelle que soit la technologie employée (ADSL, fibre, satellite …) Le switch est une prise multiple qui permet de brancher plusieurs appareils sur notre réseau local. Le point d’accès Wifi permet de remplacer un câble Ethernet par une liaison sans fil. Le routeur est l’élément le plus important. C’est au niveau de ce composant que l’on va devoir faire une partie du paramétrage de notre réseau local. Le serveur DHCP va se charger d’attribuer une adresse IP unique à chacun des appareils du réseau local Rôle du routeur Si vous vous rappelez, j’ai indiqué plus haut que toute machine connectée à Internet possède une adresse IP qui lui est propre. Dans le cadre d’un réseau local, c’est la Box qui est connectée au réseau. Elle possède donc sa propre adresse IP (adresse externe), qui lui est fournie par l’opérateur. Les différentes machines connectées au réseau local ne sont donc pas connues par le WAN. Comment votre ordinateur va-t-il alors communiquer avec le WAN ? C’est le routeur qui va se charger de transmettre les demandes de l’ordinateur vers le WAN et de renvoyer les réponses du WAN vers l’ordinateur. Il sert de Passerelle. Comment cela se passe-t-il ? Comme sur le WAN, toutes les machines du réseau local disposent d’une adresse IP qui leur est propre. Cette adresse IP est généralement fournie par le « Serveur DHCP » (voir plus loin). présent dans le routeur. Il s’agit d’une adresse locale, qui n’est pas utilisable dans le WAN. C’est une adresse de type 192.168.xxx.xxx (il existe d’autres plages d’adresses locales, mais c’est celle-ci est généralement utilisée par les box). Donc quand l’ordinateur va vouloir interroger un serveur sur le WAN, cette demande va être envoyée vers le routeur, avec l’adresse IP de l’ordinateur dans l’entête de la demande. Le routeur va remplacer cette adresse IP (interne) par sa propre adresse IP externe (pour que la réponse du serveur puisse lui revenir). Mais il va aussi mémoriser de quelle machine du réseau interne cette requête provient. Quand la réponse du serveur va arriver, le routeur se chargera de la transmettre vers la machine qui a fait la demande. Ce type de translation d'adresse (plusieurs adresses privées remplacées par une seul adresse publique) s'appelle le NAT (Network Address Translation). Il n’y a rien à paramétrer, « ça marche tout seul » !!! Les redirections de port Jusque-là tout va bien. Vous avez peut-être appris des choses que vous ne connaissiez pas, mais ce sont des explications qui ne sont pas indispensables pour pouvoir utiliser votre ordinateur. Mais si vous êtes là, c’est que vous avez un NAS, et c’est là que les choses se compliquent. Car contrairement à un ordinateur qui est généralement utilisé comme client, un NAS est un serveur. C’est-à-dire que ce n’est pas lui qui initie une demande, mais il la reçoit. Il faut donc que le NAS puisse être joint depuis une autre machine. Il n’y a pas de problème tant qu’on reste dans le réseau local, car le NAS à sa propre adresse IP dans ce réseau local. Votre ordinateur peut envoyer une demande à un service du NAS via l’URL « http://<ip du nas>:<port>. Le problème se pose lorsque l’on veut accéder au NAS depuis le WAN. En effet, votre réseau local n’est connu de l’extérieur que via l’adresse IP de la BOX. Comment faire pour qu’une requête envoyée au routeur puisse être transmise vers le NAS ? Pour cela on va utiliser une fonctionnalité du routeur : le transfert de port (ou redirection de port, ou translation de port, ou Port Forwarding, ou NAT (Network Adress Translation), ou plus précisement PAT (Port Address Translation) selon les routeurs, selon les approximations de langage, selon que l’on veut parler français, anglais ou franglais !!!). Ces approximations se retrouvent jusque dans la configuration de certaines de nos box : la page qui permet de paramétrer les transferts de port s'appelle parfois NAT/PAT ... Cette fonctionnalité va permettre au routeur de savoir vers quelle machine il va envoyer une demande qui lui arrive de l’extérieur. Il s’agit d’une simple table de correspondance qui va lui permettre de connaitre, en fonction du port interrogé par la requête, quelle est la machine (IP) / port qui doit être interrogée. Dans cette table, on a donc un port source, un port cible, et une adresse IP. Cela signifie entre autres : Un port ne peut être redirigé que vers une seule machine Si on a plusieurs NAS dans son réseau local, ils ne pourront pas être interrogés via le même port. Remarque : A ce niveau, je n’aime pas parler « d’ouverture de ports ». Pour moi, ce terme devrait être réservé au pare-feu, ce qui éviterait bons nombres de quiproquos… Serveur DHCP Précédemment, j’ai parlé d’un composant de la box qui s’appelle Serveur DHCP (Dynamic Host Configuration Protocol). C’est un élément fondamental, car c’est lui qui permet d’attribuer la configuration IP des machines du LAN. Il permet d’attribuer une adresse IP pour la machine (en s’assurant qu’il n’y a pas de doublons). Il indique aussi quel Serveur DNS va devoir être utilisé par cette machine. Classiquement, les informations permettant de paramétrer le serveur DHCP sont les suivantes : · Plage d’adresses utilisables : Ce sont les adresses IP que le serveur DHCP va pouvoir attribuer aux machines du réseau local. Il y a plusieurs plages d'IP utilisables dans un réseau local. On appelle ces IP des IP non-routables. Ce sont les plages 10.0.0.0 à 10.255.255.255 (aussi notée 10.0.0.0/8), 172.16.0.0 à 172.31.255.255 (aussi notée 172.16.0.0/12) et 192.168.0.0 à 192.168.255.255 (aussi notée 192.168.0.0/16) En général, pour nos réseau locaux, on a va utiliser 254 adresses possibles : de 192.168.x.1 à 192.168.x.254. « x » est un nombre de 0 à 255, mais fixé par défaut au niveau de la box (généralement 0 ou 1 selon les fournisseurs d'accès). Ceci est lié à des notions de sous réseau (masques de sous réseau) que je n’aborderai pas ici. Traditionnellement, on limite cette plage en fonction du nombre de machines pouvant se connecter simultanément sur le réseau local (de 20 à 30 adresses peuvent suffire). · Serveur(s) DNS : On indique là les IP des serveurs DNS (qui permettent de transformer un NDD en adresse IP) qui vont être utilisées par le réseau local. On peut indiquer plusieurs serveurs, permettant de basculer du premier sur le suivant en cas d’attente trop longue. Le plus simple est d’indiquer l’IP locale du routeur, mais on peut utiliser les adresses des serveurs DNS de son fournisseur d’accès, ou d’autres serveurs DNS (une recherche internet « choisir son serveur DNS » vous donnera toutes les informations nécessaires). · Baux statiques : Les baux statiques permettent d’attribuer toujours la même IP à une machine physique du réseau local. Pour cela, la machine physique est identifiée par son adresse MAC. Il s’agit d’un « identifiant unique » (pour faire simple) qui est fourni par la carte réseau de cette machine. Il est impératif que le NAS ait toujours la même adresse IP, et que celle-ci ne puisse pas être changée en fonction des disponibilités d’adresses que peut distribuer le serveur DHCP. En effet, comment atteindre le NAS si son IP peut changer à chaque démarrage ? Il faut aussi que les adresses IP attribuées aux baux statiques soient en dehors de la plage d’adresses définies comme utilisables par le serveur DHCP. Cela permet d’éviter d’attribuer deux fois la même IP, dans le cas où l’IP définie dans le bail statique ait été précédemment déjà attribuée par le serveur DHCP. Les DynDNS et les Noms de Domaine (NDD) Un peu plus haut, j’ai indiqué que les serveurs DNS permettent de faire le lien entre un NDD et une adresse IP. Tout le monde peut acheter pour quelques euros par an un NDD qui lui permettra d’accéder à son NAS plus facilement qu’avec son adresse IP. J’ai aussi indiqué que votre fournisseur d’accès avait attribué une adresse IP à votre BOX, et que cette adresse IP pouvait soit être fixe (et donc toujours la même), soit dynamique (et qui peut donc varier au cours du temps). Mais se pose alors la question : peut-on mettre à jour automatiquement le lien NDD – adresse IP lorsque le fournisseur d’accès change l’adresse IP. Et bien fort heureusement pour nous, la réponse est OUI : c’est ce que l’on appelle le « Dynamique DNS ». Le principe est fort simple : sur nos NAS un petit logiciel est implémenté, qui vérifie régulièrement l’adresse IP (externe) sous laquelle est connecté le routeur. Et lorsque ce logiciel détecte un changement d’IP, il appelle une API fournie par votre fournisseur de DNS pour modifier ce fameux lien NDD – adresse IP. Pour que cela fonctionne il faut bien évidement que le fournisseur de DNS mette à disposition cette API. Ce n’est malheureusement pas le cas de tous les fournisseurs de DNS, et c’est pour cela qu’il existe des sociétés qui vous permettent d’utiliser (gratuitement ou non) un DynDNS pour faire le lien entre un NDD et votre adresse IP sans que vous soyez réellement le propriétaire du NDD. C’est ce que propose Synology en vous permettant d’utiliser gratuitement des nom de domaine DynDNS de type <xxxx>.synology.me. C’est bien pratique, cela fonctionne bien, et cela permet de «se faire les dents » sur les NDD sans trop se poser de questions …. Petite digression sur les noms de domaine : Il faut savoir que lorsqu’on achète un NDD (par exemple « monsite.fr »), on est aussi propriétaire de tous les NDD de la forme « xxx.monsite.fr », « xxx.yyy.monsite.fr », etc… Dans ce forum, on désigne souvent ces NDD comme des « sous domaines », bien que ce ne soit pas une désignation officielle, « xxx.monsite.fr » étant un domaine au même titre que « monsite.fr ». Mais c’est pratique, car cela désigne ainsi un domaine dérivé du domaine dont on est propriétaire. Bon je vais arrêter là ce petit guide qui, j’espère, vous aura permis de comprendre certaines notions… Si le besoin s’en fait sentir, je pourrai compléter ou préciser certains points, voir aborder d’autre sujets … C’est un peu le problème lorsque l’on veut vulgariser des sujets techniques : on ne sait jamais trop jusqu’où il faut aller ….

Pour qui ? Depuis plusieurs années, ce tutoriel rédigé par @Fenrir est LA référence en matière de sécurisation des accès à un NAS. C'est de loin le tutoriel le plus lu du forum, et c'est une bonne chose, car cela signifie que les utilisateurs de NAS Synology se préoccupent de sécuriser leurs données. Néanmoins, bien que le tutoriel soit toujours d'actualité, certaines sections de DSM sont organisées différemment depuis l'arrivée de DSM 7. En outre, certaines informations importantes se trouvent dans les innombrables pages de commentaires, ce qui ne facilite pas la tâche aux nouveaux venus. A l'usage, on remarque également qu'il peut : parfois aller trop vite sur certains points pour des néophytes être a contrario trop succinct pour des utilisateurs souhaitant aller plus loin dans la sécurisation des accès. Il a donc été convenu de rédiger deux versions du tutoriel : cette version, une version plus pas-à-pas, reprenant l'essentiel du tutoriel original, destinée à permettre une rapide mise en service d'un NAS de manière sécurisée. C'est l'objet du tutoriel que vous allez maintenant suivre. une version plus avancée, pour utilisateurs avertis Le tutoriel s'inspire grandement du tutoriel original, merci encore à @Fenrir son rédacteur. Préambule et recommandations Définition Mais commençons par un peu de vocabulaire, un produit labélisé NAS chez Synology est en réalité un serveur, disposant d'un OS, d'un processeur et de mémoire, permettant : La mise à disposition en réseau de données par de nombreux protocoles : HTTP, HTTPS, CIFS, NFS, SSH, etc... L'hébergement de services divers et variés : nativement (Centre de paquets) par conteneurisation (Container Manager) (plus d'info ici) par virtualisation (Virtual Machine Manager) Dans la suite du tutoriel, nous emploierons improprement le terme NAS par commodité. Cahier des charges Ce que ce tutoriel couvre : La configuration des protocoles utilisés pour les accès au NAS La configuration du pare-feu La mise en place d'un certificat TLS La configuration d'un service de notification La protection des accès utilisateurs La configuration des cartes réseau Ce que ce tutoriel ne couvre pas : La configuration de votre box pour un accès distant La mise en place d'un proxy inversé La mise en place d'un serveur VPN Le chiffrement de volume ou de dossier partagé La sauvegarde et la restauration de données (outre la configuration du système) // IMPORTANT \\ En appliquant ce tutoriel, vous coupez votre NAS de tout accès extérieur. Pour accéder à votre NAS à distance, il existe plusieurs méthodes : Utilisation du relais QuickConnect de Synology, point abordé dans la partie Accès externe. Accès par nom de domaine (point abordé dans la partie Accès externe également) + redirection de ports (avec ou sans proxy inversé) Utilisation d'un serveur VPN sur le NAS pour le transfert de fichiers uniquement : FTP, SFTP, WebDAV, etc... Veuillez vous référez aux liens fournis pour la mise en place d'un accès externe sécurisé. Prérequis et méthode Le vocabulaire dédié au monde du réseau est spécifique, il est conseillé de lire le sujet rédigé par @Kramlech, ces notions seront utiles pour la compréhension de la suite du tutoriel. De plus, ce tutoriel renverra vers d'autres tutoriels pour ceux qui souhaitent aller plus loin. Si une catégorie ou un onglet ne sont pas mentionnés, c'est qu'ils ne présentent pas d'intérêt dans le cadre de ce tutoriel. Lorsque des explications supplémentaires mais non nécessaires sont proposées, elles sont cachées dans des balises spoiler : Lisez ce tutoriel en diagonale une première fois pour avoir une vision globale des modifications que vous vous apprêtez à effectuer La plupart des fenêtres que vous ouvrirez dans DSM possède une aide intégrée, celle-ci est généralement bien documentée et traduite, cela vous permettra de connaître plus en détail les fonctionnalités offertes par les divers champs activables : Précautions Sauvegarde de la configuration Que vous veniez d'installer DSM sur votre NAS, ou que vous ayez déjà une instance de DSM en production, il est impératif de réaliser une sauvegarde de la configuration avant de commencer, pour cela, on va dans Démarrer -> Panneau de configuration -> Mise à jour et restauration -> Sauvegarde de configuration -> Exportation manuelle : Cliquez sur Exporter et sauvegarder le fichier sur votre ordinateur. En cas de problème, il sera possible de restaurer la configuration précédemment exportée en cliquant sur Restauration. J'ai tout cassé Si vous n'arrivez plus à avoir accès à votre NAS suite à un réglage effectué au cours du tutoriel, vous pouvez toujours effectuer un reset mode 1 du NAS. Celui-ci est suffisant dans l'extrême majorité des cas, et il a l'avantage de réinitialiser un nombre limité de réglages qui sont susceptibles de provoquer une perte d'accès à DSM. _________________________________________________________________________________________________________________________________________________________________________________________ Sécurité Cette section sera abordée plus en détail par après, mais dans un premier temps il est impératif de sécuriser les accès à votre NAS. Pare-feu - Accès locaux Par défaut, le pare-feu n'est pas activé, et donc tous les accès sont permis. L'idée générale est d'autoriser les accès depuis le réseau local, et de le fermer aux accès distants. Au fil des années, nous avons pu constater que la pratique habituelle de créer des règles pour toutes les interfaces pouvaient avoir des effets de bord indésirables, notamment dans le cadre de l'utilisation d'un serveur VPN, il est donc plus sécurisé de créer le minimum de règles pour chaque interface séparément. Et c'est la méthode que nous allons détailler. Pour configurer le pare-feu, il faut cocher Activer le pare-feu. Il est conseillé de laisser les notifications du pare-feu tout en les refusant quand elles apparaitront à l'installation de paquets, afin d'être informé des ports utilisés par les dits paquets. On va ensuite cliquer dans la liste déroulante contenant les profils de pare-feu, et cliquer sur Gérer le profil du pare-feu. On va cliquer sur Créer pour créer un nouveau profil, et on le nomme par-interface : On sélectionne l'interface qu'on souhaite configurer, ici pour l'exemple LAN 1. On va tout d'abord ajouter quatre règles garantissant un accès local complet à votre NAS : Pour ce faire, on procède ainsi : On clique sur Créer On coche IP spécifique puis on clique sur Sélectionnez On choisit Sous-réseau et on entre 192.168.0.0 dans Adresse IP, et 255.255.0.0 dans Masque de sous-réseau ATTENTION : si vous le souhaitez, vous pouvez restreindre à votre réseau local. Ici on couvre toute la plage locale possible en 192.168. Par exemple, si le réseau de votre box est 192.168.1.x, alors vous pouvez entrer 192.168.1.0/255.255.255.0 On valide : On répète la même opération pour les deux autres règles, 172.16.0.0/255.240.0.0 et 10.0.0.0/255.0.0.0 On ajoute une règle pour les accès locaux en IPv6 : A elles quatre, ces règles permettent à tous les clients utilisant des IP privées d'accéder à tous les services du NAS (attention, ils sont toujours toutefois soumis aux processus d'authentification, ces règles leur permettent uniquement de ne pas faire se refouler à l'entrée). Dernier point, mais le plus important, on choisit Refuser l'accès comme comportement du pare-feu en cas de requête non déclenchée par les règles précédemment ajoutées : _________________________________________________________________________________________________________________________________________________________________________________________ Notifications Celles-ci sont requise pour certaines fonctionnalités comme l'authentification à deux facteurs ou plus simplement pour que vous soyez prévenu dès qu'un problème survient dans le système. On va dans Panneau de configuration -> Notification : Dans Compte Synology, cochez Recevez des notifications directement dans votre compte Synology lorsque l'état du système change ou lorsque des erreurs se produisent En activant l'option, vous serez invité à vous connecter à votre compte Synology. Cela nécessite la création ou l'association à un compte Synology Dans Email, on clique sur Configurer, et on choisit un fournisseur SMTP ou on configure le sien si on en a un Dans Profils de destinataires, on peut choisir des adresses mail différentes suivant la criticité des événements. On clique sur Ajouter. On utilise la règle Warning et on entre l'email de destination, il peut être le même que l'expéditeur Dans Paramètres d'email, on peut personnaliser le préfixe de l'objet du mail On clique sur Envoyer un e-mail de test dans Profils de destinataires pour vérifier que tout fonctionne. Vérifier votre boîte de spam si rien n'arrive _________________________________________________________________________________________________________________________________________________________________________________________ Services de fichiers On va dans Panneau de configuration -> Services de fichiers SMB Général SMB (ou Samba dans sa déclinaison Linux) est le protocole utilisé par Windows lorsqu'on monte un lecteur réseau dans l'explorateur de fichiers. Mais même sous Linux, il est le protocole à privilégier lorsqu'on se connecte à un NAS. Dans Paramètres SMB, cochez Activez le journal des transferts On coche Masquer les dossiers partagés pour les utilisateurs ne disposant pas d'autorisation Dans WS-Discovery, on coche Activer la découverte de réseau Windows pour autoriser l'accès aux fichiers via SMB : On clique sur Paramères avancés et on définit le protocole SMB minimum sur SMB2 et Large MTU, SMB1 a de nombreuses failles de sécurité et n'est plus nativement par défaut activé dans DSM : Autres On coche les 3 options suivantes : Si on souhaite activer SMB3 multicanal, on doit cocher Activer SMB3 multicanal et Activer la lecture asynchrone, le service est ensuite redémarré. AFP, NFS, FTP, rsync et Avancés N'activez que les protocoles et options dont vous avez besoin, autrement laissez les réglages par défaut. _________________________________________________________________________________________________________________________________________________________________________________________ Utilisateur et groupe Utilisateur / Groupe Ce tutoriel n'aborde pas dans le détail la gestion des groupes et utilisateurs, gardez toutefois à l'esprit que : Rationalisez les permissions. Dans le cas d'utilisateurs similaires, créer un groupe reprenant les permissions partagées est plus élégant que de configurer manuellement les droits de chaque utilisateur Limitez les permissions d'un utilisateur ou un groupe au strict nécessaire Compte administrateur alternatif Lors du passage à DSM 7, ou lors d'une nouvelle installation, vous êtes invités à créer un nouveau compte administrateur si votre seul compte administrateur est le compte "admin". Cela permet d'avoir un compte administrateur avec des accès plus robustes (voir Politique de mot de passe), et de désactiver le compte "admin" par défaut, sur lequel vous ne pourrez plus vous connecter. /!\ CETTE ÉTAPE EST OBLIGATOIRE /!\ Configuration du mot de passe On se dirige vers l'onglet Avancé -> Configuration du mot de passe : Espace personnel de l'utilisateur Au bas du menu Avancé on coche Activer le service d'accueil de l'utilisateur, afin que chaque utilisateur dispose de son propre dossier personnel dans homes (homes n'est visible que des membres du groupe administrateurs). ATTENTION : Il est primordial de ne pas toucher aux permissions du dossier homes (visible uniquement par les administrateurs) et aux dossiers home (pour les utilisateurs non administrateurs). _________________________________________________________________________________________________________________________________________________________________________________________ Accès externe QuickConnect Si vous ne souhaitez pas accéder à votre NAS en dehors de votre domicile, désactivez Quickconnect. DDNS Si vous ne souhaitez pas accéder à votre NAS en dehors de votre domicile, vous pouvez ignorer ce passage. Configuration du routeur Ne cliquez pas ici, ça fait partie des options que Synology devrait vraiment retirer de ses boitiers. C'est très dangereux du point de vue sécurité. Ça sert à ouvrir automatiquement des ports dans votre routeur/box, ça peut paraitre sympa comme ça mais en pratique c'est une faille de sécurité très importante. Deux exemples pour essayer de vous convaincre : pour que cette fonction marche, votre routeur doit gérer l'UPnP, donc tous les équipements de votre réseau pourront faire de l'ouverture dynamique de port, le PC qui vient d'être vérolé pourra automatiquement, sans la moindre notification, ouvrir un port permettant à un attaquant d'entrer dans votre réseau de même, si vous avez configuré des redirections de ports pour plusieurs équipements, ces redirections risquent de sauter si une requête UPnP demande le même port Avancé Un onglet que beaucoup oublient de configurer, il n'est pas obligatoire et pas lié (pas directement du moins) à la sécurité mais ça permet d'éviter de chercher des heures la raison pour laquelle un lien de partage (par exemple) ne fonctionne pas : REMARQUE : si vous utilisez le proxy inversé ou le portail des applications de DSM, il n'est pas utilie de configurer ce menu. _________________________________________________________________________________________________________________________________________________________________________________________ Réseau L'onglet Réseau dans le panneau de configuration permet de régler la connectivité de votre appareil et ses interfaces. Interface réseau IPv4 Dans l'onglet Interface réseau, on sélectionne l'interface qu'on souhaite configurer et on clique sur Modifier : Pour obtenir une IP, deux méthodes existent : Le NAS acquiert son IP grâce au serveur DHCP, généralement votre box ou votre routeur. Pour s'assurer que cette IP ne change pas d'une fois à l'autre, il faut faire ce qu'on appelle une réservation statique d'IP dans votre serveur DHCP. Concrètement, cela signifie que pour une adresse MAC donnée (le numéro d'identité de votre carte réseau en quelque sorte), le serveur DHCP attribuera toujours la même adresse IP. On fixe l'IP du NAS directement sur celui-ci, pour cela on choisit Utiliser la configuration manuelle et on choisit une IP. ATTENTION : il faut que l'IP choisie : soit dans la plage IP de votre réseau local soit hors de la plage DHCP d'attribution de votre box/modem. La première méthode a l'avantage qu'en cas de : changement de box de modification de sous-réseau (passer de 192.168.1.0 à 192.168.10.0 par exemple) de déménagement Le NAS restera accessible car il obtiendra une IP dans tous les cas avec un nouveau modem, il ne vous restera plus qu'à le trouver via Synology Assistant. IPv6 A l'heure actuelle, l'IPv6 est bien plus prise en charge par les FAI qu'au temps de la rédaction du tutoriel original, certains mêmes ne proposent plus que de l'IPv6 nativement. Si vous souhaitez l'activer, choisissez Auto : Général Dans l'onglet Général de la catégorie Réseau : Dans Paramètres avancés : Cochez Répondre à la demande ARP si l'adresse IP cible est identique à une adresse locale configurée sur l'interface entrante, cela permet de faire en sorte que les données sortent par leurs interfaces respectives. Cochez Activer la détection des conflits IP, vous aurez des notifications dans DSM si votre NAS rencontre des problèmes de conflit d'IP. Connectivité Cochez Activer HTTP/2 _________________________________________________________________________________________________________________________________________________________________________________________ Sécurité A n'en pas douter la catégorie la plus importante de ce tutoriel ! Le pare-feu a été configuré pour un accès local en tout début de tutoriel. Général Vous pouvez laisser les réglages par défaut Compte Authentification à deux facteurs (2FA) L'authentification à deux facteurs apporte une couche de sécurité supplémentaire, mais elle n'est en aucun cas un remède palliatif à des accès utilisateurs trop faibles. L'authentification à deux facteurs est également plus contraignante en cas de perte du périphérique sur lequel elle est configurée, s'il s'avérait être le seul. Un code de récupération est fourni par DSM pour y retrouver accès, il est impératif de le noter. Si vous souhaitez activer l'authentification à deux facteurs, suivez les étapes suivantes : Adaptive MFA Cochez Activer l'authentification multifacteur adaptative pour les utilisateurs appartenant au groupe administrateurs (pour version de DSM > 7.2) Protection du compte Cochez Activez la protection du compte : Ajuster les valeurs proposées par défaut à votre convenance. Pare-feu - Accès distant Cette section est restreinte au minimum, car le but est ici de sécuriser les accès à votre NAS. A partir du moment où le NAS est accessible depuis l'extérieur, sa surface d'exposition est bien plus importante. Mais vu que nous allons voir comment obtenir un certificat pour votre NAS, il paraît naturel d'évoquer la mise en place d'un accès distant sur celui-ci, pour en savoir plus, c'est par ici : Protection Cochez Activer le blocage auto, ainsi que Activer l'expiration des blocages avec les réglages suivants : Cliquez ensuite sur Autoriser/Bloquer la liste, sélectionnez Créer -> Ajouter une adresse IP, choisissez Sous-réseau et ajouter les deux entrées suivantes : REMARQUE : Si vous avez mis un sous-réseau et masque plus restrictifs que 192.168.0.0/255.255.0.0 dans vos règles de pare-feu, par exemple pour vous conformer au réseau utilisé par votre box, supposons 192.168.1.0/255.255.255.0, vous pouvez dans ce cas spécifier 192.168.1.0/24 dans le menu ci-dessus. Enfin, cochez également Activer la protection DoS. Certificat La mise en place d'un certificat est utile pour : établir un accès distant sécurisé (chiffré) vers votre NAS la mise en place d'un serveur DNS local la mise en place d'un proxy inversé Si les uns et les autres ne vous sont d'aucune utilité, passez à la section suivante. Avancé Dans cet onglet, nous allons régler le niveau de sécurité de chiffrement des services systèmes : La compatibilité moderne correspond à TLS 1.3 qui est maintenant assez répandu, si vous avez des smartphones relativement récents vous ne devriez pas rencontrer de problème. La compatibilité intermédiaire prend en charge TLS 1.3 et 1.2, c'est le choix qui couvrira le plus de périphériques. Depuis la version 7.1 de DSM, il est possible via le menu Paramètres personnalisés de définir séparément le niveau de sécurité utilisé par les applications. _________________________________________________________________________________________________________________________________________________________________________________________ Terminal & SNMP Avancé Je recommande de cocher Activer le service SSH, cela vous donne une porte de secours en cas de problème d'accès à DSM. Si vous deviez rendre accessible le terminal de votre NAS depuis l'extérieur, je recommande très fortement de ne pas faire une simple redirection de port au niveau de votre box mais d'utiliser un serveur VPN, par exemple via le paquet VPN Server. _________________________________________________________________________________________________________________________________________________________________________________________ Portail de connexion DSM Vous pouvez cocher la case Rediriger automatiquement les connexions HTTP vers HTTPS pour le bureau DSM pour vous connecter automatiquement en HTTPS même si l'adresse entrée commence par HTTP. Il est préférable d'avoir mis en place un certificat avant d'activer cette option pour éviter les avertissements de sécurité du navigateur. REMARQUE : Ne pas activer cette option si vous utiliser un proxy inversé pour accéder à vos services DSM. _________________________________________________________________________________________________________________________________________________________________________________________ Options régionales Pour que l'authentification à deux facteurs fonctionne correctement, il est important que vos périphériques soient synchronisés temporellement. Assurez-vous de régler la synchronisation temporelle du NAS sur une source sure, dans Temps puis Paramètres de l'heure, cochez Synchroniser avec un serveur NTP et entrez manuellement l'adresse fr.pool.ntp.org par exemple si vous résidez en France, ou ntp.fdn.org. La liste complète des serveurs NTP peut se trouver à l'adresse suivante : https://www.ntppool.org/zone/@ _________________________________________________________________________________________________________________________________________________________________________________________ Mise à jour et restauration Mise à jour du DSM On clique sur Options de mise à jour, puis on choisit M'avertir et me laisser décider d'installer la nouvelle mise à jour : Synology est coutumière de déploiements erratiques de ses mises à jour, donc suivez ces quelques conseils : Prenez le temps de lire les notes de patch lors de la sortie d'une nouvelle version de l'OS, il se peut qu'elle n'apporte rien dans votre utilisation du NAS N'appliquez de préférence une mise à jour que si elle est proposée automatiquement par le système (évitez les mises à jour manuelles) Sauf correctifs de sécurité importants, ne vous précipitez pas pour appliquer une mise à jour, laissez le temps aux développeurs et aux autre utilisateurs le soin de se casser les dents dessus, il y en a suffisamment sur le forum. 😉 Sauvegarde de configuration Si vous avez lié votre compte Synology à votre NAS, par le biais de la configuration du DDNS ou via la section Compte Synology dans le panneau de configuration, vous avez la possibilité d'enregistrer automatiquement la configuration de votre NAS dans votre espace client Synology. C'est une option intéressante et je recommande de l'activer : IMPORTANT : Avoir une sauvegarde automatique de la configuration dans le cloud ne dispense pas de disposer d'une version locale de celle-ci. En cas de changement notable dans votre configuration, pensez à faire une Exportation manuelle de la configuration, et à la copier sur un ou plusieurs périphériques : PC, clé USB, disque externe, etc... _________________________________________________________________________________________________________________________________________________________________________________________ Privilèges d'application Pas de recommandation spécifique à ce sujet, vous pouvez décider de restreindre les privilèges accordés par défaut à TOUS les utilisateurs dans cette catégorie, ou bien laisser les autorisations et restreindre au niveau de permissions de groupe et d'utilisateur. A titre personnel, je trouve plus simple de régler de façon granulaire les accès des groupes et utilisateurs dans la catégorie Utilisateur et groupe. _________________________________________________________________________________________________________________________________________________________________________________________ MAJ : 07/11/2023

Un message pour rien. Enfin, pas tout à fait puisque celui-ci est mon 10 000 ème sur ce forum depuis mon inscription le 23/09/2007 🥂. Il méritait d'avoir son fil dédié. A l'époque, je venais d'acquérir mon tout premier NAS, un DS107 et je suis depuis resté fidèle à Synology. Après le 107 se sont succédé un deuxième et dernier monobaie, un DS110J, puis des deux baies DS710+, DS214+, DS713+, DS718+ et le tout dernier, un DS220+. Pas au delà des 2 baies car mes besoins en stockage sont somme toute assez limités. Mes disques de 4To font parfaitement le taf. Que dire. Dans ces 10 000 messages, il y a eu bien sûr beaucoup de demandes d'aide de ma part et je remercie chaleureusement ceux qui l'ont fait. Je n'en nommerai (presque) aucun pour ne pas en oublier bien que tous aient déserté le forum depuis bien longtemps..... ☹️. Je ferais toutefois une exception pour @Fenrir. J'ai tellement appris grâce à lui qu'il m'est impossible de ne pas le mentionner. Il a été une source inépuisable de connaissances dans de nombreux domaines, en témoignent tous les tutos qu'il a créé et qui sont encore aujourd'hui des références. Il a tiré ce forum vers le haut et je sais que ceux qui ont eu la chance de bénéficier de son aide partagent le même sentiment. Et puis est venu le temps où j'ai pu à mon tour aider modestement les autres, pas toujours de manière heureuse (j'ai mon lot de casseroles 😉). J'espère simplement que dans toute cette diarrhée messagère certains ont pu trouver des réponses à leurs questions. Vous l'avez probablement noté, je suis moins présent ces temps ci, du moins pas autant que je le voudrais. Je dois limiter mes interventions au strict minimum car je me suis lancé dans des travaux importants de rénovation qui occupent le plus clair de mon temps. J'essaye malgré tout de consacrer quelques minutes par jour pour garder le contact et répondre rapidement à quelques demandes. Longue vie au forum et merci à tous ses membres sans qui il ne pourrait exister. Le dinosaure 🙂.

Bon allez, promis, donc je le fais. Une présentation en mode speed dating car le temps est short pour moi, surtout côté boulot. Donc la bestiole est arrivée. Avant tout, ceux qui migre de Révolution ou pop ou autre, ce n'est pas un livreur UPS, mais un échangeur UPS, il repart donc avec votre ancien matos. On vous prévient de la date de livraison, mais c'est en fait un échange, sinon pas de box ! J'ai garder une jartière, le livreur m'a dit que ça ne posait pas de soucis. Voici donc le unboxing : C'est pas gros mais c'est propre... Dessous un emplacement M2, simple, mais utile pour toutes config, sans quoi, à priori, pas de sauvegarde.... Tout y est mais le câble réseau n'a pas de spec. Il supporte le 10 Gb, mais rien concernant la cat. du câble. Pas grave..... ça redémarre au moins 6 fois pour les MAJ, et on fini par y arriver. Magie, de la Révolution à l'ULTRA, les 8 GB sont reconnus. Donc oui, FREE à bien travaillé en amont sur son install réseau car tout est clean. Le connecteur SFP pour vous diriger vers un switch 10 Gb (administré ou pas) n'est pas fourni. Celui ci est recommandé par FREE, et il fonctionne du premier coup. Il doit surement en exister d'autres, peut être moins cher, mais celui là est nickel. Livraison en 4 jours ouvrés. https://www.fs.com/fr/products/74680.html La puissance donnée me parait correcte, je laisse les pro dans ce domaine me faire leurs retours..... Côté OS, c'est bien du 4.8, pas de soucis. L'état de la box est donné rien de neuf sous le soleil. A chaque accès à l'OS, vous aurez le droit aux tutos, ça va vite vous gaver.... Mais ça se décoche. On reste dans un esprit grand public. Le module SFP est géré, on peut juste pas en faire grand chose, en même temps, qu'est-ce qu'on pourrait en faire ? La POP est reconnue en 1 Gb, là également, 10 Gb ok, mais pour une pop.... Free bosse sur un player, à voir, pour l'instant c'est trop tôt.... Arrive le wifi 7, simple, propre et efficace. Le câble de quel cat. ???? J'en sais rien Malgré une grande maison construite en 1892 le flux passe entre les murs de 80 cm, et l'application Freebox Connect devient nécessaire. On va donc le gérer à sa sauce, mais rien de nouveau sauf peut être pour certains pro, des options qui peuvent devenir ultimes ? Je sais pas Un mode éco, à voir avec un contrôleur de conso watt/heure. Mais pour l'instant pas le temps..... Enfin la pop. Que du coup je ne connaissais pas, puisque j'ai migré d'une Révolution à une Ultra. C'est propre et simple façon FREE. Tout de suite, on comprends qu'on va avoir une box orientée VOD / Home Cinéma avec 4 boutons raccourcis en haut de la télécommande. Reste que là, je n'en suis qu'au début de mes surprises..... On y va pour un paquet de mise à jour. Si l'idée c'est de regarder le JT de France 2 de 13 H, mettez votre réveil vers 6H00.... Google s'invite, va falloir se connecter.... Bon bah, un petit Firmware, ça va nous faire du bien.... On revient sur la connexion GOOGLE ..... Et on se refait une petite mise à jour..... Là OQEE vous explique tout, sauf l'essentiel.... Pour la suite, je n'ai pas eu le temps, mais l'idée c'est de créer un profil pour pouvoir contrôler tout le player. Tout de suite on a accès au VOD et Streaming, mais les chaines classiques, c'est moins évident..... - Voilà déjà un premier aperçu de cette nouvelle petite bestiole qui mérite beaucoup d'attention. On va donc se ruer sur un disque M2, assez costaud pour gérer tout ça, car contrairement à la Delta, pas d'emplacement SATA SSD x 4.... Prévoir donc un petit budget pour le SFP+ et le M2. Reste l'install à passer en 10 Gb switch + carte réseau. Pour moi le switch c'est fait, j'attends la carte réseau. Vu ce qui est annoncé, prévoyez quand même des disques suffisamment rapides pour avaler le débit, le peu que j'ai vu vous met les cartes réseaux au taquet.... Je pense que là, FREE à manifestement tapé du poing sur la table, histoire de mettre Orange dans la cave ou au grenier, mais pas dans le séjour..... @ + et à très bientôt 🙂

Bonjour à tous, Nous allons voir dans ce tutoriel comment mettre en place rapidement un certificat Let's Encrypt avec la méthode acme.sh en utilisant l'api Ovh en Docker, si vous êtes rapide, en 10 minutes c'est en place. Pourquoi en docker ? Car je suis contre la pollution du DSM, des corruptions par update, mais aussi par simplicité et rapidité. 1) On commence par la création de clé d'api chez ovh : https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/* On remplit donc le formulaire, pour "Validity" (1) on choisit "Unlimited", pour "Rights" (2) on remplace dans les champs "mydomain.com" par le vôtre et dans "Restricted IPs" (3), on rajoute son IP afin qu'en cas de vol des clés, elles ne puissent être exploitées et votre domaine détourné. (NB : Si vous n'avez pas une IP fixe, on passe ce dernier point) On garde les clés retournées en résultat sous la main pour la suite. 2) Passons maintenant au docker : A) On commence par la création d'un dossier "Acme" dans le dossier docker. B) La création du fichier de config : On crée avec l'éditeur de texte du DSM (Codage UTF-8) le fichier "account.conf" à la racine de notre dossier "Acme" contenant : LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='XXXXXXX' SAVED_OVH_AS='XXXXXXX' SAVED_OVH_CK='XXXXXXX' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' On remplace dedans le contenu des 3 variables "SAVED_OVH_**" par nos clés obtenues précédemment par OVH. C) La création du docker : On va mettre un petit peu de code pour la création du docker et son actualisation journalière via le gestionnaire de tâche... Panneau de configuration / Planificateur de tâches / Créer / Tâche planifiée / Script défini par l'utilisateur Utilisateur : Root On programme pour une exécution par jour la nuit (5h c'est bien) Exécuter la commande : docker pull neilpang/acme.sh:latest docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart unless-stopped neilpang/acme.sh:latest daemon On exécute manuellement la tâche une première fois pour la création du docker. C Bis) Le docker-compose.yml : version: "2.1" services: acme: cpu_shares: 10 mem_limit: 128M container_name: Acme network_mode: bridge labels: - com.centurylinklabs.watchtower.enable=true volumes: - /volume1/docker/Acme:/acme.sh:rw restart: unless-stopped image: neilpang/acme.sh:latest command: daemon D) Création du certificat : Avec le planificateur de tâche en exécution unique (cf point 2C) ou en ssh (root) en remplaçant "mydomain.com" : docker exec Acme sh -c "acme.sh --issue --keylength 4096 -d 'mydomain.com' -d '*.mydomain.com' --dns dns_ovh" Il n'y a rien à détailler pour expliquer cette commande, le keylenght peut être, on double la valeur par défaut qui est aujourd'hui considérée comme faible à 2048. /!\ Renouvellement automatique du certificat sans action de votre part 3) Installation des certificats : A) Importation manuel : Vos certificats seront disponibles directement dans filestation "docker/Acme/votredomaine" et ce qui nous intéresse dedans : Certificat : mydomain.com.cer Clé privée : mydomain.com.key Certificat intermédiaire : ca.cer On va maintenant faire leur import manuellement, dans "Panneau de configuration/Sécurité/Certificat". En cas d'import manuel, vous pouvez activer la notification mail, mais cette action se réalise toujours 1 mois avant expiration : https://github.com/acmesh-official/acme.sh/wiki/notify B) Déploiement automatique : NB : Faire un premier déploiement manuel avant le déploiement automatique, afin de bien le mettre par défaut et supprimer celui de synology par défaut. 1) Création d'un compte que l'on rajoutera dans le groupe admin, on lui mettra aucun acces à tous les dossiers et refuser à toutes les applications, on active pas la double authentification qui sera inutile. 2) On ré édite notre fichier "account.conf" créé au point 2B, on y rajoute : SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='nom utilisateur' SAVED_SYNO_Password='le password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='description du certificat mise dans le DSM' 3) Ensuite une fois les modifications faites, avec le planificateur de tâche en exécution unique (Cf point 2C) ou en ssh (root) : docker exec Acme sh -c "acme.sh --deploy -d 'mydomain.com' --deploy-hook synology_dsm" Guide officiel : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide Pour d'autres API que ovh : https://github.com/acmesh-official/acme.sh/wiki/dnsapi 😉

Il te faut un wireguard-ui pour faciliter la gestion du serveur et des clients https://github.com/ngoduykhanh/wireguard-ui/releases Je vais essayer de faire un petit tuto pour l'installation de wireguard et wireguard-ui dans linuxserver/Wireguard vu que c'est exactement ce que j'utilise chez moi. En gros, ca donne cela en résultat:

@Jeff777@Pascalou59@MilesTEG1 Bon j'ai trouvé la solution au problème en cherchant sur le net. A priori c'est connu sur la dernière version du client OpenVPN Connect (3.3.6) A la création du serveur OpenVPN sur le NAS et quand on coche l'option Vérifier le CN du serveur. Dans le fichier de conf exporté, la ligne suivante est ajoutée en fin de fichier verify-x509-name 'mon.nom.domaine.fr' name ceci qui conduit au message d'erreur suivant lors de l'utilisation de cette conf sous OpenVPN Connect 3.3.6 Pour résoudre le problème il faut enlever les quote ou les remplacer par des doubles quote sur la ligne de commande dans le fichier de conf .opvn La ligne devient verify-x509-name mon.nom.domaine.fr name Et après ça marche !!! Merci pour votre aide à tous. Je laisse ici le fichier de config dev tun tls-client remote mon.nom.domaine.fr 1194 # The "float" tells OpenVPN to accept authenticated packets from any address, # not only the address which was specified in the --remote option. # This is useful when you are connecting to a peer which holds a dynamic address # such as a dial-in user or DHCP client. # (Please refer to the manual of OpenVPN for more information.) #float # If redirect-gateway is enabled, the client will redirect it's # default network gateway through the VPN. # It means the VPN connection will firstly connect to the VPN Server # and then to the internet. # (Please refer to the manual of OpenVPN for more information.) redirect-gateway def1 # dhcp-option DNS: To set primary domain name server address. # Repeat this option to set secondary DNS server addresses. #dhcp-option DNS DNS_IP_ADDRESS pull # If you want to connect by Server's IPv6 address, you should use # "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode proto udp script-security 2 reneg-sec 0 cipher AES-256-CBC data-ciphers 'AES-256-CBC' auth SHA512 auth-nocache auth-user-pass <ca> -----BEGIN CERTIFICATE----- # ici votre certificat -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- # ici votre certificat -----END CERTIFICATE----- </ca> key-direction 1 <tls-auth> # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- # ici votre clé -----END OpenVPN Static key V1----- </tls-auth> verify-x509-name mon.nom.domaine.fr name

Bonjour, La version finale de DSM 7.1.1 est disponible (7.1.1-42962) https://www.synology.com/fr-fr/releaseNote/DSM?#7_1 https://archive.synology.com/download/Os/DSM/7.1.1-42962 C'est une MAJ "importante" car elle corrige beaucoup de failles (a noter la version DSM 7.1.1-42951 RC corrigée déjà les failles) Attention cette version n'est plus compatible avec surveillance station 8.2.x

Un ransomware fait des ravages depuis juin sur les NAS QNAP dont la sécurité a été négligée par certains clients. Ceci s'est également produit chez Synology il y a quelques années. QNAP a publié un bulletin de sécurité avec des recommandations : https://www.qnap.com/fr-fr/security-advisory/QSA-22-19 Article relatif (En) : https://arstechnica.com/information-technology/2022/09/new-wave-of-data-destroying-ransomware-attacks-hits-qnap-nas-devices/ Un peu de lecture pour ceux qui seraient soucieux de la sécurité de leur NAS Synology :

C'est fait ! 🥳 ---- Synology annonce sur le forum officiel les nouvelles versions de Synology Photos, ainsi que les fonctionnalités en développement. On y voit d'ailleurs qu'une application pour les TV est en cours de développement : Pour rester informé des prochaines publications concernant Synology Photos, il suffit de suivre le profil de lesheng94.

Bonjour, je sais pas si cela arrive souvent chez vous mais depuis plusieurs semaines le forum est souvent down. La dernier fois c’était en début de cette semaine ( lundi je crois ) . Un des vous a une explication ? Ps : j'ai peut être pas posté dans la bonne section 🙂

Bonjour, Le topic originel https://www.nas-forum.com/forum/topic/37274-fichier-host-1fichier-host-file-1fichier/ n'étant plus mis à jour par son auteur @Souli, il m'a été demandé de créer un nouveau topic pour retrouver plus facilement l'information. J'ai l'intention de maintenant se fichier host si certain rencontre des bugs donc n'hesitez pas à me poser des questions. Si je ne répond pas sur le forum je suis aussi disponible par email, et mon email est indiqué sur mon compte github. L'ensemble du code est donc disponible sur un repo github : https://github.com/Gizmo091/synology_1fichier_hosting Lient de téléchargement du module premium + access ( utilisant la clé d'api ) 2024-03-25 - 4.2.0 : https://github.com/Gizmo091/synology_1fichier_hosting/raw/4.2.0/OneFichierCom(4.2.0).host Changelogs : - 4.2.0 : Prise en compte des liens avec un token de téléchargement : exemple : https://a-6.1fichier.com/p1058755667 - 4.1.0 : Le endpoint Account : Show n'est plus utilisé pour valider que la clé d'API peut être utilisée , on test plutot sur un fichier dont on connait l'existance (fichier sur mon compte) - 4.0.7 : Code rendu compatible à partir de php 5.6 pour être pleinement rétrocompatible. - 4.0.7 : Code rendu compatible à partir de php 5.6 pour être pleinement rétrocompatible. - 4.0.6 : Correction d'un problème si pas de paramètre passé à la place de l'username et correction d'un problème avec les logs - 4.0.5 : Le code est maintenant compatible php7 (des fonctionnements de php8 avait été inclus auparavant) - 4.0.4 : Ajout de la possibilité d'envoyer les logs sur un serveur externe (pour aider au debug) - 4.0.2 : Ajout de logs pour debugger - 4.0.1 : Utilisation du password pour l'apikey et non l'username - 4.0.0 : Attention, version utilisant l'API donc reservé au premium/access Problèmes connus : - [Corrigé depuis la 4.1.0] Le fait de verifier les identifants retourne parfois une erreur, si vous êtes sur de votre clé d'api, ignorez cette erreur. L'API de 1fichier peut parfois être capricieuse et leur politique de controle des requetes faites à l'API est un peut trop restrictive. L'API retourne alors une erreur de flood meme avec très peu de requete. - la version 4.3.0 ( et peut être d'autre) du host de alldebrid fait echouter le chargement des fichiers host des autres provider. ( je ne sais pas pourquoi mais je l'ai constaté ). Support : Soit sur le forum, soit sur Discord : gizmo091 Informations : - Ce fichier host se configure de la facon suivante : nom d'utilisateur : ce que vous voulez ( mais il ne faut pas que ce soit vide), peut contenir des variables de configurations password : votre apikey , récupérable sur le site de 1fichier : https://1fichier.com/console/params.pl section API Key. Notez la bien car elle ne sera plus visible par la suite, il faudra alors la desactivé et en générer une nouvelle si vous devez la saisir à nouveau. Configurations addionnelles : Le champ username/nom d'utilisateur peut donc contenir un ou plusieur configuration. Elle doivent être saisies de la façon suivante : <parametre1>=<valeur_param1>;<parametre2>=<valeur_param2>;... Paramètres disponibles : - local_log : activable en ajoutant local_log=1 dans le champ username Les fichiers de logs seront écrits dans le répertoire /tmp/1fichier_dot_com , un fichier sera créer par téléchargement avec l'id du lien ( exemple : lien = https://1fichier.com/?kitiwlyogv8uozsnfi&af=3108529, fichier de log = /tmp/1fichier_dot_com/kitiwlyogv8uozsnfi.log ) , si par d'identifiant dans le fichier sera /tmp/1fichier_dot_com/default.log Exemple avec local_log d'activé : - remote_log : activable en ajoutant remote_log=<serveur_de_log> dans le champ username. Les logs seront envoyé au serveur passé en paramètres via des requetes cURL. Vous pouvez heberger votre propre serveur de log en utilisant le code se trouvant dans le repertoire remote_log du repository git, ou alors vous pouvez utiliser mon serveur : https://vedie.fr/remote_log/log.php et vous pouvez consulter les logs ici : https://vedie.fr/remote_log/read.php Exemple avec remote_log d'activé : Hashtags : hostfile, host file, onefichier

Ce tutoriel nécessite DSM 6.2.4 ou une version ultérieure. Son but est de permettre à des clients macOS de se connecter à SSH sans avoir à fournir de mot de passe, que ce soit au niveau d'un compte administrateur ou du compte root. Ce tutoriel a été rédigé à partir de la contribution de référence du regretté unPixel : Et à partir d'une documentation émanant de Synology : Comment puis-je me connecter à DSM avec des paires de clés RSA via SSH ? Le tutoriel de unPixel est plutôt orienté PC et fait appel à des outils comme PuTTY, Pageant ou WinSCP totalement inconnus du monde Mac. Dans ce dernier on n'utilise qu'un seul outil, le Terminal. Il y a bien une partie consacrée aux environnements Mac et Linux ajoutée par @Fenrir mais toutes mes tentatives pour l'appliquer ont été vaines, du moins sous macOS Ventura. unPixel lui-même disait avec humour qu'il n'appliquait pas ce tutoriel sur son Mac et utilisait la bonne vieille méthode du mot de passe. C'est sans doute qu'il y avait quelque part un problème de mise en œuvre. Il est vrai qu'Apple, dont la dernière chimère est de de vouloir créer un système théoriquement inviolable, ne cesse de durcir de façon drastique les mesures de sécurité concernant macOS ce qui explique à mon avis les problèmes rencontrés qui sont des problèmes de droits. Bref, vous l'aurez compris, ce tutoriel est né d'une frustration. Pourquoi ça marche sur PC et pas sur Mac ? 😀 J'ai refondu la documentation de Synology et j'ai dû faire appel à leur support technique après avoir constaté qu'on ne pouvait pas l'appliquer en l'état. Le support a accepté d'ouvrir un ticket et a proposé des modifications qui se sont avérées déterminantes. Merci à eux. Facilité du tutoriel : FACILE si l'on maîtrise un peu l'interface en ligne de commande Durée : 20 minutes environ INTRODUCTION L’authentification par clés SSH (Secure Shell) fonctionne en utilisant une clé publique sur le NAS et une clé privée sur l'ordinateur local. La clé publique peut être placée sur n’importe quel serveur distant auquel on souhaite accéder. C'est d'ailleurs ce que nous ferons par la suite. La clé privée reste sur le Mac et n'est jamais communiquée à quiconque : lors du lancement de la session SSH le NAS envoie une requête à l'ordinateur local et c'est lui qui, en confrontant la clé publique transmise par le NAS et la clé privée qu'il détient, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non. Dans ce dernier cas l'ouverture de session est bien entendu refusée. Comme l'a dit @.Shad. que je me permets de citer « En gros la clé publique c'est ta réservation au restaurant, et la clé privée c'est le fait de prouver ton identité. ». SSH utilise des algorithmes de cryptage puissants pour sécuriser la communication entre le client et le serveur. Il garantit que les données transmises sur le réseau ne peuvent pas être interceptées ou modifiées par des entités malveillantes. Remarque : la mise en œuvre du tutoriel implique de faire des allers-retours constants entre le Mac (via l'application Terminal) et DSM. Suivez bien les instructions qui sont données car elles vous indiquent où vous vous trouvez et ne vous perdez pas ! N'hésitez pas à m'indiquer les difficultés que vous aurez pu rencontrer afin que j'améliore le tutoriel. De toute façon, si vous rencontrez des problèmes qui vous obligent à tout recommencer, la marche à suivre est décrite en fin de document. N'hésitez pas à m'en faire part là encore. Il est vivement recommandé pour des raisons de sécurité de changer le port par défaut de SSH dans le panneau "Terminal & SNMP" du Panneau de configuration. À chaque fois que vous verrez une commande "ssh ... -p XX" par la suite, remplacez XX par le port que vous avez spécifié. ATTENTION : N'ouvrez pas ce port sur votre box Internet car il doit être utilisé en local pour des raisons de sécurité une fois de plus. Si vous devez absolument vous connecter à SSH sur le NAS hors du réseau local utilisez un VPN. LANCEZ L'APPLICATION TERMINAL SUR LE MAC Inutile de la télécharger, elle est présente sur tous les Mac. Dans tout ce qui suit vous devrez remplacer "username" par par votre nom d'utilisateur sur le NAS et sur le Mac. Ils peuvent être différents (c'est le cas chez moi). Il faut faire attention au contexte dans ce cas afin d'appliquer la bonne substitution : Terminal Mac --> usernameX, SSH --> usernameY. GÉNÉRATION DES CLÉS On génère une paire de clés SSH à partir du Terminal du Mac avec la commande ssh-keygen en spécifiant l’algorithme de chiffrement désiré. J'ai retenu ed25519 qui est le plus sûr à ce jour : ssh-keygen -t ed25519 Vous êtes invité à saisir le chemin d'accès au dossier qui contiendra la clé publique et la clé privée. Laissez l’emplacement par défaut, à savoir : /Users/username/.ssh/id_ed25519 en appuyant sur Entrée. Vous êtes invité à saisir une phrase de passe (passphrase) pour la clé privée CE QUI EST VIVEMENT RECOMMANDÉ VOIRE INDISPENSABLE. Vous pouvez cependant l'ignorer en appuyant deux fois sur la touche Entrée si vous ne souhaitez pas saisir de passphrase à chaque fois que vous utilisez la clé. @Fenrir recommande, je cite « de protéger la clef avec un super mot de passe » et « de renouveler la clef de temps en temps (1 fois par an c'est largement suffisant) en pensant bien à supprimer la clef publique de l'ancienne ». La clé publique (id_ed25519.pub) et la clé privée (id_ed25519) ont été crées sur le Mac dans le dossier choisi plus haut. Il est possible de stocker la passphrase dans le Trousseau d'accès du Mac en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins : La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement tronquée à 10 caractères dans le Trousseau... Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté. Dans tous les cas de figure il est nécessaire pour se connecter à SSH de connaître la passphrase, il ne faut pas faciliter la tâche des intrus en la stockant quelque part sauf dans des coffres sécurisé comme Vaultwarden ou 1Password qui ont leur propre mot de passe et ne sont pas débloqués automatiquement à l'ouverture de session. Vous devrez par la suite copier la clé publique (id_ed25519.pub) dans le dossier home de votre compte administrateur sur le NAS en utilisant File Station. Cette clé se trouve actuellement dans un dossier masqué sur le Mac (.ssh est masqué car précédé d'un point). C'est pourquoi ce dossier n'apparaîtra pas dans la fenêtre de File Station. Pour contourner le problème, le plus simple est d'utiliser le terminal. Il faut se positionner dans le dossier .ssh sur le Mac : cd ~/.ssh puis copier la clé à la racine de son home sur le Mac : cp id_ed25519.pub ~/id_ed25519.pub ENREGISTREMENT DE LA CLÉ PUBLIQUE DANS VOTRE COMPTE ADMINISTRATEUR SUR LE NAS Connectez-vous à DSM avec votre compte administrateur. Accédez à File Station. Dans votre dossier home créez un sous-dossier nommé .ssh (n'oubliez pas le point au début de .ssh). Transférez la clé publique id_ed25519.pub (qui est désormais visible) dans le dossier .ssh en utilisant l'onglet "Charger" de File Station comme illustré ci-dessous (lionel est mon dossier home). Il faut ensuite accéder au dossier home sur le Mac avec le Terminal et supprimer la clé qui s'y trouve afin de faire le ménage (on l'avait déplacé là afin qu'elle soit visible). cd ~/ rm id_ed25519.pub CONNEXION SSH ADMINISTRATEUR AVEC LA PAIRE DE CLÉS Connectez-vous à SSH avec votre compte administrateur sur le NAS. Un message d'avertissement apparaît : The authenticity of host '[192.168.1.2]:22 ([192.168.1.2]:22)' can't be established. ED25519 key fingerprint is SHA256:4nLwr4EVpCwt/jjH9kIEXDUaILvWhVXCzbDCzJv4z66. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? Ce message apparaît lors de la première connexion SSH ce qui est normal. Répondez simplement 'yes'. Warning: Permanently added '[192.168.1.2]:22' (ED25519) to the list of known hosts. Après, vous pouvez être déconnecté auquel cas vous aurez le message : Connection closed by 192.168.1.2 port 22 Il vous faut vous reconnecter dans ce cas. Si vous avez le message : username@192.168.1.2's password: On vous demande simplement votre mot de passe à la suite de quoi vous serez déconnecté de toute façon ! Pour des raisons qui m'échappent, les deux cas se sont produits lors des tests que j'ai réalisés. Pour faire simple dans tous les cas de figure reconnectez-vous ! Accédez au dossier .ssh précédemment créé sur le NAS : cd ~/.ssh Ajoutez la clé publique à un fichier, authorized_keys qui sera créé à cette occasion : cat id_ed25519.pub >> authorized_keys Le dossier .ssh sur le NAS contient désormais deux fichiers : authorized_keys et la clé publique id_ed25519.pub. Se positionner dans son home sur le NAS cd ~/ Puis taper les instructions suivantes où 711 donne les droits en lecture et en écriture au seul propriétaire (vous) et le droit d'exécution à tout le monde : chmod 711 .ssh chmod 711 .ssh/authorized_keys chown -R username .ssh/ Où username est votre nom d'administrateur sur le NAS. Ceci afin d'être sûr que les droits sur ces dossiers sont conformes aux règles. Ces instructions sont très importantes. La première partie du tutoriel est terminée. Vous pouvez maintenant vous connecter à SSH à l'aide de votre compte administrateur sans avoir à saisir un mot de passe. Mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés (ce qui, je le rappelle, est vivement recommandé). Par exemple : ssh username@192.168.1.1 -p XX Enter passphrase for key '/Users/username/.ssh/id_ed25519':_ CONNEXION SSH ROOT AVEC LA PAIRE DE CLÉS Sur le NAS, se connecter à SSH en tant que root à partir de votre compte administrateur en tapant "sudo -i". Soyez conscients qu'en tant que root vous avez tous les droits sur le NAS et qu'une erreur sur une commande peut provoquer des dommages irrémédiables. En cas de doute, il est préférable de copier les commandes du tutoriel et de les coller dans la session SSH. Exécutez la commande mkdir /root/.ssh afin de créer le dossier .ssh s'il n'existe pas. Il peut avoir été créé auparavant si des clés d'administrateurs autres que vous ont été consignées. Vous aurez dans ce cas le message d'erreur : mkdir: cannot create directory ‘/root/.ssh’: File exists qui est sans gravité. Accédez à votre propre dossier .ssh sur le NAS qui se trouve dans votre dossier home : cd /volume1/homes/username/.ssh où volume1 est le volume dans lequel se trouve le fichier id_ed25519.pub et username votre nom d'utilisateur sur le NAS. On crée le fichier authorized_keys de root s'il n'existe pas et on ajoute la clé publique id_ed25519.pub. cat id_ed25519.pub >> /root/.ssh/authorized_keys Entrez la commande chmod 700 -R /root/.ssh afin d'être certain que tout ce qui se trouve dans le dossier .ssh n'est accessible qu'au compte root et ceci est très important (700 donne l'exclusivité de tous les droits à root). ON REDÉMARRE LE SERVICE SSH POUR QUE LES CHANGEMENTS SOIENT PRIS EN COMPTE DSM6 : synoservicectl --reload sshd DSM7 : systemctl restart sshd Vous pouvez maintenant vous connecter en tant que root sans avoir à saisir de mot de passe mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés comme indiqué plus haut. Par exemple : ssh root@192.168.1.1 -p XX Le tutoriel est terminé. MODIFIER LA PASSPHRASE Lancer le Terminal sur le Mac et taper : ssh-keygen -p -f ~/.ssh/id_ed25519 On demande l'ancienne phrase de passe puis la nouvelle. Il faut parfois relancer le service SSH pour que le changement soit pris en compte. Le plus simple est d'essayer de se connecter en tant que root avec la nouvelle passphrase et, si elle est refusée, de saisir l'ancienne. Les changements n'ont pas été pris en compte dans ce cas et il faut utiliser la commande de redémarrage du service SSH indiquée ci-dessus (celle-ci nécessite les droits root). EN CAS D'ERREUR LORS DE LA MISE EN ŒUVRE DU TUTORIEL QUI VOUS OBLIGE A TOUT RECOMMENCER NB : Ces instructions ne s'appliquent que si vous êtes le seul administrateur du NAS ou si vous avez créé une session SSH avec paire de clés pour la première fois. Si un historique préexiste n'hésitez pas à me contacter. Connectez-vous à SSH en tant que root sur le NAS et supprimez son dossier .ssh : rm -R .ssh Connectez-vous à SSH avec votre compte administrateur sur le NAS et supprimez le dossier .ssh qui se trouve dans votre dossier home : rm -R .ssh Lancez l'application Terminal et supprimez le dossier .ssh qui se trouve dans votre dossier home sur le MAC : rm -R .ssh VOUS AUREZ COMPRIS QUE CES ACTIONS SONT IRRÉVERSIBLES ! CRÉATION D'UN FICHIER DE CONFIGURATION SUR LE MAC Un fichier de configuration permet de définir des profils par défaut (hosts) en renseignant l'adresse IP du serveur, le nom d'utilisateur sur le serveur, le port utilisé par SSH et le chemin d'accès à la clé privée. Ainsi au lieu de taper ssh username@192.168.1.1 -p XX pour initier une session SSH, il suffit de taper ssh username Il est possible de créer dans le fichier de config plusieurs hosts avec des adresses IP différentes ce qui permet de se connecter à des serveurs distincts. Ne créez un fichier de config qu'après de la mise en œuvre complète du tutoriel lorsque vous serez sûr que tout fonctionne. # point d'entrée : tapez ssh server_1 pour vous connecter Host server_1 HostName 192.168.1.1 # nom d'utilisateur sur le serveur User username Port XXX # Chemin d'accès à la clé privée IdentityFile ~/.ssh/id_ed25519 Host nas HostName ndd.fr User cyberfr Port XXX IdentityFile ~/.ssh/id_ed25519 Host root HostName 192.168.1.2 User root Port XXX IdentityFile ~/.ssh/id_ed25519 Le fichier de configuration doit être placé sous le nom "config" (sans extension) dans le dossier .ssh de votre home où résident déjà les clés publiques et privées id_ed25519 et id_ed25519.pub. Le plus simple est de le rédiger dans un traitement de texte (TextEdit ou BBEdit) puis de le déplacer au bon endroit. Il vaut mieux respecter le canevas des exemples donnés ci-dessus et ne pas utiliser de tabulations (je n'ai pas essayé donc je ne sais pas si elles sont acceptées 😀).

Bonjour tout le monde, J'ai l'impression qu'il y a pas mal de monde intéressé par la possibilité d'utiliser un NAS Synology pour faire du Reverse proxy (depuis DSM 6.0). Je voulais ajouter ma pierre à l'édifice en complétant les tutos réalisés, sur ce topic ou ailleurs. Tout d'abord, je voulais remercier InfoYann pour son tuto et ses réponses à mes questions. Merci également à Fender, qui a écrit le 1er tuto sur le sujet. Pour finir, merci à Fenrir, pour son méga tuto de sécurisation d'un NAS (une vraie bible...), qui aborde le sujet du reverse proxy. LE REVERSE PROXY DE A à Z I. Utilité et intérêt d'un Reverse proxy Un Reverse proxy redirige des noms de domaines vers des équipements présents sur le réseau local ou des applications présentes sur le NAS. Cela permet de ne pas avoir à retenir et taper le port des différents services pour y accéder. Par conséquent, ça évite d'avoir à ouvrir sur l'extérieur autant de ports que de services : on se sert juste du port utilisé par défaut pour les connexions HTTPS, le port 443. Par exemple, si on a affecté le port 45000 à Audio Station et le 45001 à Video Station, il faut normalement taper https://nomdedomaine.fr:45000 ou https://nomdedomaine.fr:45001 pour accéder à ces 2 services. Ce n'est pas très explicite, et il faut que les ports 45000 et 45001 soient ouverts sur le routeur. Plus y il y a de services, pire c'est. Grâce à un reverse proxy, on se contente de taper https://music.nomdedomaine.fr ou https://video.nomdedomaine.fr, et tout passe par le port 443 utilisé par le protocole HTTPS. C'est beaucoup plus simple. Pour plus d'infos, consultez ce tuto et celui-là. Par contre, il faut absolument préciser https dans l'URL, sans quoi on utilise le HTTP par défaut et ça ne marche pas. Pour éviter ce problème, on va mettre en place une redirection automatique grâce à Web Station. II. Configuration du nom de domaine chez le registrar Je prends le cas d'une IP fixe car j'ai la chance de ne pas être confronté au problème des IP dynamiques ! Avoir son nom de domaine (NDD) va nous permettre d'accéder à notre réseau local depuis Internet. Une fois le NDD loué, il faut ajouter 2 entrées dans sa zone DNS : - une entrée de type A qui redirige le NDD vers l'IP fixe de la box (ndd.fr. => IP fixe) - une entrée de type CNAME qui redirigera l'ensemble des sous-domaines vers le NDD (*.ndd.fr. => ndd.fr.) Après cette étape, les tentatives de connexion à fichiers.ndd.fr, video.ndd.fr,… seront acheminées à la box. III. Configuration du routeur De l'extérieur, on a besoin que le port 443 soit ouvert pour pouvoir se connecter aux applications du NAS de manière simple (pas de port exotique à préciser) et sécurisée (car 443 = HTTPS). Let's Encrypt se connecte par le port 80 pour délivrer le certificat SSL et pour le renouveler. De plus, si on profite de Web Station pour créer un site web, il faut également ouvrir le port 80 pour autoriser les connexions à ce site en HTTP. Donc on va utiliser les ports externes 80 et 443. Du côté du NAS, le Reverse proxy "écoute" sur le port 443 ou sur le port DSM sécurisé. Vu que je ne trouve pas souhaitable d'exposer DSM sur internet, les connexions sécurisées seront redirigées vers le port 443 du NAS. Web Station utilise le port 80. On va donc rediriger les connexions externes non sécurisées vers le port 80 du NAS. En résumé, sur le routeur, il faut rediriger les ports externes 80 et 443 vers les ports internes 80 et 443 du NAS. Après cette étape, les connexions utilisant les ports 80 et 443 seront acheminées de la box au NAS. IV. Configuration du pare-feu du NAS Pour que les connexions ne soient pas rejetées par le NAS, il faut modifier son pare-feu. Plutôt que d'ouvrir complètement les ports 80 et 443 : - on ouvre les ports 80 et 443 pour le trafic en provenance de France, pour limiter les risques d'attaque. - on ouvre également le port 80 pour le trafic venant des 2 IP que Let's Encrypt utilise pour le renouvellement du certificat (64.78.149.164 et 66.133.109.36, cf ici). Correction de la modération : ces IP ne sont plus valides. Pour la création ou le renouvellement de vos certificats, il faut ouvrir le port 80 sans restriction géographique le temps du processus de création ou de renouvellement, le refermer par la suite pour bloquer les attaques sur ce port Ces règles sont à entrer dans le pare-feu du NAS (panneau de configuration/Connectivité/Sécurité/onglet "Pare-feu", puis "Modifier les règles"). NB : Les IP utilisées par Let's Encrypt peuvent changerLes IP ci-dessus ne sont plus valides. Il est donc conseillé d'ouvrir complètement le port 80 (au moins pour le trafic en provenance des Etats-Unis) avant la demande initiale de certificat ou en cas de problème de renouvellement de celui-ci. Après cette étape, les connexions pourront parvenir jusqu'au Reverse proxy du NAS (et jusqu'à WebStation). V. Configuration du portail des applications de DSM Il faut d'abord définir les ports HTTP qui seront utilisés par les applications auxquelles on veut accéder depuis l'extérieur. Pour ça, aller dans le panneau de configuration/Applications/Portail des applications/onglet "Application". NB : Il n'est pas nécessaire de définir un port HTTPS pour les applications vu que la connexion est déjà en HTTPS jusqu'au reverse proxy. En effet, il est inutile et contre-productif de doubler les chiffrements. Après cette étape, si on tape IP_locale_du_NAS:45000, on ouvre directement Audio Station. Il faut ensuite définir le reverse proxy à proprement parler, à savoir faire correspondre les différents sous-domaines avec les différentes applications. Ça se passe sur la même page, dans l'onglet "Proxy inversé". Pour chaque application, il faut renseigner : - la source (nom du sous-domaine, protocole (HTTPS) et port (443)) - la destination (nom d'hôte (localhost quand l'appli est sur le NAS, IP s'il s'agit d'un autre élément du réseau), protocole (HTTP) et port (défini à l'étape précédente)). NB : On utilise "localhost" pour désigner le NAS, car si celui-ci change d'IP, on n'aura pas besoin de reparamétrer le reverse proxy. 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é). Après cette étape, quand on tape https://music.ndd.fr, on est bien redirigé vers audio station, mais avec un avertissement de sécurité du navigateur comme quoi la connexion n'est pas sûre. VI. Obtention du certificat SSL pour le domaine et ses sous-domaines Il ne faut jamais utiliser de certificat auto-signé (comme celui installé par défaut dans la plupart des équipements), tout comme accepter des exceptions de sécurité (peut provoquer des interceptions de données même sur des sites protégés par de vrais certificats). Le mieux et le plus simple est de se tourner vers une autorité de certification comme Let's Encrypt, bien intégrée chez Synology. Dans le panneau de configuration de DSM, partie "Connectivité", section "Sécurité", onglet "Certificat", cliquer sur le bouton "Ajouter". A la 2e étape, choisir de se procurer un certificat auprès de Let's Encrypt. A la 3e étape, remplir le NDD et l'adresse mail. Dans le champ "Autre nom de l'objet", mettre le nom de tous les sous-domaines, séparés par des points-virgules. Enfin, cliquer sur "Appliquer". Après cette étape, le reverse proxy fonctionne sans avertissement de sécurité. Cependant, quand on tape music.ndd.fr dans un navigateur, celui-ci ne nous redirige pas automatiquement vers https://music.ndd.fr. A la place, il nous renvoie vers ndd.fr:port_DSM_non_sécurisé (même si la connexion n'aboutit pas). Le registrar ne peut pas mettre en place de redirection car seul le nom de domaine est loué chez lui, aucun site n'est hébergé. L'option de redirection présente dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM n'est pas envisageable car elle casse le mécanisme du reverse proxy. Pour éviter ça, on va créer un site web. Ça nous permettra la création d'un fichier .htaccess, qui redirigera automatiquement les requêtes en HTTPS. VII. Auto-hébergement d'un site web et mise en place des redirections Il faut installer Web Station. Une fois que c'est fait, ouvrir l'application. Dans la partie "Statut", il faut installer les 2 versions du serveur HTTP Apache et les 2 versions de PHP. Pour ça, cliquer sur les icônes de raccourci présentes dans la colonne "Gestion". Une fois que c'est fait, on passe à la partie "Paramètres généraux". On sélectionne les versions les plus récentes d'Apache et de PHP, puis on coche la case "Activer un site web personnel" (ce n'est possible que si on a installé les 2 versions d'Apache et de PHP à l'étape précédente). On n'a pas besoin de changer les paramètres PHP ou de créer un Virtual Host (à moins d'avoir plusieurs sites web à héberger sur le même NAS). Avec l'installation de Web Station, un dossier Web a été créé à la racine du volume. Le fichier index.html est la page d'accueil du site hébergé sur le NAS. On peut en profiter pour modifier ce fichier afin que notre page d'accueil présente plusieurs liens permettant de se connecter aux différents services présents sur le NAS. Pour mettre en place la redirection automatique, il faut créer un fichier .htaccess. Pour ça, il faut créer un fichier texte dans le dossier Web. A l'intérieur de ce fichier, on écrit le code suivant : RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} On enregistre sous ".htaccess" (donc sans nom mais juste avec l'extension htaccess). Il faut ensuite redemander un certificat à Let's Encrypt, en ajoutant www.ndd.fr dans le champ 'Autre nom de l'objet" (en plus des noms de tous les sous-domaines). Après cette étape, quand on tape music.ndd.fr dans un navigateur, celui-ci nous redirige automatiquement vers https://music.ndd.fr. NB : Il faut préciser le port 443 dans le formulaire de connexion des applications mobiles, sans quoi elles n'arrivent pas à se connecter (donc music.ndd.fr:443 et non music.ndd.fr pour se connecter à DS Audio). Voir un retour intéressant ici, concernant le reverse proxy et la certification par Let's Encrypt. Si quand on tape ndd.fr on est redirigé vers l'interface de connexion à DSM (ce que je ne veux pas), il faut vérifier que la case "Activer un domaine personnalisé" dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM est décochée (ou bien qu'on a mis un autre nom de domaine que ndd.fr dans ce champ, cf tuto DNS Server). Par contre, pour se connecter à l'interface de gestion du NAS, il faudra désormais taper l'IP locale du NAS + le port DSM non sécurisé dans la barre d'adresse du navigateur (à moins d'avoir mis en place une zone DNS locale, avec une adresse comme nas.super_nom.lan qui pointe sur le NAS). J'espère que ce tuto vous sera utile. Je suis preneur de tout retour, remarque ou suggestion !

Bonsoir, DSM 7.2.1-69057 Update 4 est disponible. Version : 7.2.1-69057 Mise à jour 4 (2024-01-16) Notes IMPORTANTES 1 - Votre NAS Synology peut ne pas vous informer de cette mise à jour de DSM. Si vous souhaitez mettre à jour votre DSM vers cette version maintenant, veuillez cliquer ici pour le mettre à jour manuellement. ° Votre DSM fonctionne correctement sans avoir à le mettre à jour. Le système évalue les statuts des services et les paramètres du système pour déterminer s'il doit être mis à jour vers cette version. 2 - En fonction de votre modèle de NAS Synology, cette mise à jour redémarrera l'appareil. Problèmes résolus: 1 - Correction d'un problème où Cloud Sync et Drive ShareSync ne pouvaient pas fonctionner correctement lorsqu'Active Insight était exécuté sur Synology NAS. 2 - Correction de plusieurs vulnérabilités de sécurité Remarques : Cette version est publiée lors d'un déploiement par étapes. https://www.synology.com/fr-fr/releaseNote/DSM https://archive.synology.com/download/Os/DSM/7.2.1-69057-4 Installé sur DS718+ : RAS

Génial que tout fonctionne normalement. On regardera prochainement pourquoi ce problème au bout de 10 fichiers.

Bonjour, Juste pour évoquer mes constats et retours d'expérience : L'application Synology Photos est très gourmande en RAM, notamment lorsque l'on y accède depuis un navigateur web avec des images larges à afficher. Avec une mémoire RAM insuffisante de l'ordre de 1 ou 2 Gb, le NAS risque de devenir très très lent, je pense sur beaucoup de modèles. C'est d'ailleurs un avertissement qu'avait fait Synology au moment de passer vers DSM7 et Synology Photos (versus les versions précédentes de DSM avec uniquement DS Photo ou Moments : la différence en besoin de ressources avec DSM7 et Synology Photos est sensible). Pourquoi ? Je pense en partie car contrairement aux fichiers standards (documents textes, tableurs, pdf, etc...) que l'on peut faire défiler dans File Station sans affichage complexe, les photos nécessitent pour être affichées d'avoir leurs miniatures en mémoire. Avec 1 ou 2Gb de RAM, le NAS est en permanence en train de décharger des fichiers en cache pour les remplacer par des miniatures - ou pire des photos - à afficher. Cela ralentit considérablement le système. A mon sens : la solution indispensable quand on veut faire un usage fluide de Synology Photos, c'est d'augmenter la RAM à 6 ou 8Gb (fonction de son NAS). 🎛 ➡️ Sur mon vieux DS216+ v1 avec 1Gb de RAM initiale, DSM 7 et Synology Photos étaient tellement lents qu'ils étaient inutilisables. ➡️ J'ai remplacé la barrette de RAM par une de 8GB : résultat j'ai un avion de chasse ! ✈️ Mon vieux DS216+ + 8GB de RAM est ultra-rapide ! Toutes les miniatures et photos s'affichent de façon quasi instantanée, et j'ai également noté un gain très sensible de rapidité avec les autres applis, ou ne serait-ce que pour consulter des fichiers avec File Station à distance ou en connexion locale SMB, qui ont énormément gagné en fluidité aussi. Nota : J'ai plus de 50 000 Photos (1To), dont plusieurs milliers au format RAW 24MP (=6K) assez lourd, et bien sûr des jpeg. Bref. Que ce soit pour nos NAS existants ou pour l'achat des prochains, je crois que l'ajout de RAM est souvent sous-estimé. En tout cas pour Synology Photos. Dans mon cas : une barrette de RAM à 35€ m'a changé la vie, et m'a évité d'avoir à remplacer un DS216+ qui tourne comme une horloge depuis 8 ans désormais. A+++++

Pour une raison obscure, Synology a récemment retiré des archives les anciennes versions de DSM, SRM et des applis. Si vous avez besoin des versions retirées, vous pouvez les retrouver sur ce site d'archivage (dernier snapshot du 31/05/2023) : https://web.archive.org/web/20230531230549/https://archive.synology.com/download

@firlin, @.Shad., @PiwiLAbruti J'ai déplacé la question de firlin sur le ping dans un autre sujet car il n'avait pas de rapport avec la sécurisation des NAS

@CyberFr Je vais essayer de tourner les explications de mes collègues différemment. C'est quoi un code TOTP ? C'est une clé qui, une fois entrée dans un logiciel d'authentification 2 facteurs (quelque soit la plateforme : PC, Android, iOS, Extension de navigateur, etc...) permet de générer un code à 6 chiffres, qui se renouvelle. On peut utiliser cette clé sur autant d'applications et périphériques qu'on veut. Le code généré sera le même et variera au même moment. Il est donc prudent d'avoir a minima deux sources d'authentification 2FA, dans mon cas j'utilise Aegis sur mon smartphone, et je l'ai aussi dans Bitwarden. Avantage de Bitwarden, c'est que même si le serveur est down, j'ai accès au cache du coffre depuis mes différents périphériques. Le code TOTP défini par DSM lorsqu'un utilisateur applique la 2FA à son compte n'est affiché qu'une seule fois. Il est donc important de : L'écrire manuellement sur papier et de le conserver en lieu sûr, sans indiquer ce que c'est, moi je le garde dans mon portefeuille. Configurer cet accès sur deux périphériques a minima. Secure Signin est une version intégrée à DSM, absolument pas obligatoire et plus contraignante selon moi, comme tu as pu le constater. J'ajouterai que les remarques de @Mic13710 sont pertinentes dans le sens où le plus important est d'avoir des credentials robustes conjointement avec les blocages correctement configurés sur le NAS. Le reste est intéressant mais dispensable.

Avec la source et quelques commentaires, ça aurait été mieux qu'un copier/coller. Comme pour DSM 7.2, cette version ne sera pas proposée en mise à jour automatique pour les NAS des séries '18 et antérieures. Il faudra donc la télécharger et l'installer manuellement pour pouvoir en bénéficier. Il est recommandé de l'installer car elle contient 4 corrections de vulnérabilités (CVE). Source : https://www.synology.com/fr-fr/releaseNote/DSM#7_2

Après le classement des meilleurs déterrages, on va lancer celui des présentations les plus courtes.

Re-bonjour a tousss, J'ai pris un peu de temps pour faire un test de performance sur mon 220+ - proc : Intel Celeron J4025 , 2-core 2.0 (base) / 2.9 (burst) GHz - Moteur de cryptage matériel (AES-NI) - RAM : 2 Go RAM - 2 DD WD Red de 3 To en RAID 1 J'ai créer 2 Volumes : - Vol_1 : 50 Go non-crypté Avec un dossier non crypté Avec un dossier crypté - Vol 2 : 50 Go crypté Avec un dossier non crypté Avec un dossier crypté J'ai mis sur mon pc un ensemble de fichier (42Go) : 2 * 15 Go 2 * 4.5 Go 13 * 400 Mo 83 * 5.8 Mo Voici les temps : 1) PC -> Syno Volume non crypté, Dossier non crypté : 434 secondes (limité par le Gibagit) 2) PC -> Syno Volume non crypté, Dossier crypté : 515 secondes 3) PC -> Syno Volume crypté, Dossier non crypté : 444 secondes 4) PC -> Syno Volume crypté, Dossier crypté : 696 secondes Ma conclusion 'rapide' : Sur un DS220+, un Dosier non-crypté sur un Volume crypté (DSM 7.2) est 15% + rapide qu'un Dossier crypté sur un Vomule non-crypté (ancien DSM). Je suis loin des 48% annoncé par Synology (en moyenne ?!?). Mais mon DS220+ est peut-être "trop" puissant avec une utilisation avec du DD "rotatif" et du Gigabit... Si je peux, je ferai un test avec un SSD dans le Syno (Volume en Basic), et un SSD en USB pour faire les copy. J'espère que je ne serais limité que par la CPU (et puissance de cryptage)... J'ai plus de vieux Syno supportant le DSM 7.2 (même mon DS114 est trop vieux). Stay tuned !!

Mise à jour ok sur 218+, et sur 918+. Particularité : le 918+ a deux nvme transformés en volume raid1 (et non en cache) qui sont toujours là.

Bonjour, avant de jeter je tente tout ce qui me vient à l'idée. Le DS212+ bip un matin car le HDD2 est "mourrant". (26 secteurs défectueux) C'est un WD RED NAs de 6To. Il est de décembre 2016 avec 47690 heures au compteur. Le DS212+ est monté en RAID0, il ne sert plus qu'aux sauvegardes. Il fonctionne H24. Je sors le HDD2 et je tente de le formater sur mon PC => impossible car le disque est "locked" ! Je ne peux plus l'utiliser. Je tente un smart => impossible Je passe l'utilitaire de WD => impossible J'essaye tout ce qui me vient à l'esprit: formatage bas niveau, badblocks, table de partition GPT, MSDOS, etc... Rien à faire c'est bloqué. Et... au fil de mes lectures je tombe sur la solution: DSM verrouille le disque avec un mot de passe lorsqu'il est jugé défaillant (conclusion personnelle) afin de ne plus l'utiliser. pour déverrouiller j'ai fait: hdparm --security-disable synology /dev/sdX 'synology' c'est le mot de passe qui débloque le HDD. Ensuite j'ai pu passer la commande qui va bien :=) dd if=/dev/zero of=/dev/sdx bs=4K status=progress depuis mon pc pour remplir le disque de zéros et faire un badblocks avec ZÉRO ERREURS ! Le disque est retourné dans le NAS, il est accepté et ne contient plus l'information des secteurs défectueux. Je ne sais pas combien de temps ça va durer mais là c'est OK. (je regrette simplement d'avoir acheté un disque de remplacement avant de trouver la solution et j'espère qu'à la réception ce sera un HDD avec la technologie CMR comme indiqué sur sa fiche...) Merci d'avoir tenu le coup jusqu'au bout 🙂 Bon dimanche.

Je n'ai toujours pas réussi à faire fonctionné les route statique mais j'ai trouvé une solution presque plus simple. Il faut ouvrir le fichier .ovpn fourni par votre VPN, et rajouté dedans : # PLEX over WAN route route plex.tv 255.255.255.255 192.168.1.1 Grace à ça, j'ai bien download station qui passe par le VPN mais plus Plex, j'ai donc récupéré l'accès à distance !

@Thierry66Même si c'est le bar, quel est l'intérêt de poster tes "trouvailles" ? On ne peut pas (souci technique) envoyer de message personnel en tant que modérateur, mais nous souhaiterions (moi et d'autres de l'équipe de modération) que tu postes à un rythme moins élevé ET des sujets plus en lien avec la thématique du forum (et que soit tu poses des questions, soit tu apportes des réponses, précises et argumentées...) Désolé de poster cela au vu de tous, mais comme expliqué pas d'autres moyens sauf à te "modérer" sans que tu comprennes pourquoi. Chaque forum a son mode de fonctionnement, et les nouveaux doivent se familiariser avec "l'ambiance" d'un forum quand ils arrivent.

Faut pas se plaindre...ça veut dire qu'il y a de nouveaux arrivants ! Faudrait une section FAQ

fc00::/7 est l'équivalent IPv6 de 10/8, 172.16/12 et 192.168/16, donc dédié aux réseaux privés non-routables sur internet. C'est un préfixe que tu ne rencontreras probablement jamais étant donné qu'il est utilisé dans des configurations professionnelles/spécifiques. Tu peux donc retirer la règle qui l'utilise. Pour information fe80::/10 est l'équivalent de 169.254/16 (adresses automatiques non routable).

Bonjour , C'est un comportement "normal" de drive , les liens partagés et envoyés sur smartphone ne peuvent pas s'afficher sur les navigateurs des smartphones. Il faut obligatoirement passer par l'application Synology Drive , donc il faut un ID et mdp. Cela fait plus de 3 ans que rien n'est fait pour corriger ça. https://community.synology.com/enu/forum/7/post/125064 Seule solution , vous partagez votre dossier via FileStation , les liens s'affichent sur téléphone. Bonne journée !

@CyberFr Alors, j'ai fait un dépôt GitHub pour les fichiers, et un tuto qui n'est pas encore écrit 😅 Dans l'ordre de ce qu'il faut faire : Lire les tuto de @.Shad. où il parle du macvlan, voir les liens mis dans cette section du tuto pas finalisé ^^ : https://github.com/MilesTEG1/Synology-Docker-Adguard-Home-in-a-macvlan-network#11-présentation-du-tutoriel-et-prérequis Le script pour créer le réseau macvlan (unique, tu ne peux pas en avoir plusieurs, donc planifie le bien, avec un certains nombre d'adresses IP disponibles :)) : https://github.com/MilesTEG1/Synology-Docker-Adguard-Home-in-a-macvlan-network/blob/main/docker_network_create_macvlan.sh Le script pour créer l'interface virtuelle permettant au NAS de communiquer avec le conteneur : https://github.com/MilesTEG1/Synology-Docker-Adguard-Home-in-a-macvlan-network/blob/main/bridgemacvlan-interface.sh Le fichier docker-compose.yml : https://github.com/MilesTEG1/Synology-Docker-Adguard-Home-in-a-macvlan-network/blob/main/docker-compose.yml Voilà, lis bien tous les commentaires des différents fichiers pour savoir comment modifier les valeurs en fonction de ton réseau ^^ Bon courage 🤪

Bonjour, Petit retour, la MAJ depuis la version 1.2.5-8227 Update 5 > 1.3.1-9316 c'est bien passée, avec un RT2600ac et 2*MR2200ac en ethernet 👍 Attention pour les RT2600ac, le mode "répéteur sans fil" est supprimé, donc si vous souhaitez utiliser ce mode il faudra rester sous SRM 1.2.x: Les clés USB 3G-4G sont toujours supportées: Sinon toujours pas de DoH si on utilise le serveur DNS. Nouveauté de SRM 1.3.1 La page de connexion reprend celle de DSM7 (mais on ne peut toujours pas enregistrer son navigateur pour la double authentification, comme avec DSM6 ou 7) Pour les nouveautés de SRM 1.3 le pare-feu fonctionne aussi pour les LAN: Le SSH ce comporte maintenant comme avec DSM 6 et 7, il faut d'abord ce connecter avec un utilisateur "administrateur" puis passer en root avec la commande "sudo -i", on ne peut plus ce connecté directement en root.

Après quelques tests rapides, il s'avère que la Livebox vérifie l'en-tête Host. En passant par un reverse proxy, la valeur de cet en-tête est le nom d'hôte affecté au reverse proxy (livebox.domain.tld par exemple). Hors, la Livebox n'accepte que son adresse IP comme valeur valide (192.168.1.1 par défaut, à adapter si votre réseau a un adressage différent). Donc j'ai forcé la valeur de cet en-tête à 192.168.1.1 dans l'onglet [En-tête personnalisé] du reverse proxy, et ça passe : 🥳 À tester avec ton matériel réseau @Finnithnel

@maxou56 Bonjour, Après leur avoir donné l’accès à mon routeur, Synology aurait compris le problème. Je fais une capture d'écran du mail qui m'a été envoyé cet après midi. Bon week-end à vous !

Bon, le [TUTO] Se connecter à SSH avec une paire de clé sur Mac est réapparu 😀

En complément de ce que dit @.Shad., tu peux confier la clé à un gestionnaire de clés intégré mais le problème est que le volume est monté automatiquement lors du démarrage de DSM. C'est pourquoi je préfère monter le volume lorsque j'en ai besoin. J'ai signalé il y a quelque temps qu'un container démarrait lorsque j'allumais le NAS alors qu'il était réglé sur "--restart never" qui est la valeur par défaut, valeur que je vois dans les propriétés du container. Mon problème venait justement du fait que ce container est associé à un volume crypté et que si ce dernier n'est pas monté, cela provoque bien entendu une erreur. C'est donc un bug de DSM et j'ai été obligé pour le contourner d'écrire un script pour arrêter manuellement le container. Suite à ce bug que j'ai signalé au support, "--restart never" s'est transformé en "--restart unless-stopped" dans Container Manager.

Dans un premier temps, le Tuto que j'ai fait permet de créer et gérer un wireguard configuré en Serveur, et non en client qui permettrait de te connecter à ton serveur distant. Concernant ta question : "pourquoi tu n'a as accès à l'interface Wireguard", la réponse est dans les deux premières lignes de ton log du même post: De plus, cette erreur est décrite dans mon tuto:

Le dossier /homes contient les dossiers à la racine de chaque utilisateur (chaque dossier porte le même nom que l'utilisateur) : /homes/Pierre /homes/Paul /homes/Jacques Le dossier /home est un lien virtuel pointant vers le dossier racine de l'utilisateur connecté. Par exemple, si Paul est connecté, /home pointera vers /homes/Paul : /home -> /homes/Paul Paul verra donc uniquement le contenu de /homes/Paul. Le contenu de ce dossier n'est pas visible des autres utilisateurs.

Tu as oublié un truc important : Acheter un onduleur 😉

Tu peux aussi apporter ton témoignage sur le sujet suivant, qui sait ce qui pourrait en ressortir :

Non ce qu'il dit c'est que ce genre de justification est idiote, on dirait un adolescent qui explique à ses parents qu'il a besoin de la toute dernière tablette 12" 250Hz 16Go RAM pour prendre des notes en cours. Que tu en aies envie par contre, c'est tout à fait compréhensible, on est adulte (je pense ?) et on a au moins l'avantage d'avoir la liberté d'acheter ce qu'on veut. 😉

Ah bon ! Et comment tu fais

Merci @MilesTEG1 il est bien en host ... Visiblement d'autres rencontrent le même problème plex token not written to preferences on first run · Issue #100 · linuxserver/docker-plex · GitHub Sans comprendre pourquoi j'ai suivi un des posts de cette page en utilisant http://<ip>/web/index.html et là ca a fonctionné !

Bonjour, Juste un petit message pour vous remercier. Grâce à vos échanges, j'ai pu régler mes soucis. Et c'est vraiment super!! Merci à tous et bonne année au passage!

1. Préambule Ce guide a pour but de permettre à tout un chacun de centraliser la gestion de ses conteneurs sur une seule et même instance Docker, et ce de manière sécurisée. Sur une distribution Linux classique ou même Windows il est possible d'exposer une instance Docker via TCP, donc la rendre accessible sur un port de la machine hôte, 2375 en non-sécurisé, 2376 par TLS. De manière générale c'est quelque chose qu'on évite, car Docker possède des privilèges élevés sur sa machine hôte, c'est donc une source de contamination potentiellement dévastatrice. En prenant soin de placer un certain nombre de garde-fous, et en maîtrisant les points de sécurisation abordés dans les tutoriels références du forum (en premier lieu celui sur la sécurisation), l'idée devient tout à fait envisageable. Il y a deux avantages majeurs à cette méthode : - Elle est applicable à n'importe quelle machine, votre NAS, un PC sous Linux, un micro-processeur type Raspberry, un VPS, un serveur dédié, etc... - Elle permet de s'affranchir des limitations de certains OS, typiquement DSM. On peut tout à fait exposer par TCP l'instance Docker d'un NAS Syno sans passer par un proxy sauf qu'à chaque redémarrage les modifications sont effacées et il faudra de nouveau modifier la ligne de commande de démarrage du démon Docker. Un script pourrait sûrement tout à fait se charger de la tâche, reste que l'on touche à des fichiers systèmes sensibles, je suis partisan du fait de garder un DSM "stock" pour éviter des problèmes lors des mises à jour et des incompatibilités/bugs qui en découlent fréquemment. 2. Prérequis Savoir protéger ses périphériques (pare-feu) Savoir établir une connexion suffisamment sécurisée entre deux machines Savoir rediriger un port Avoir des bases concernant Docker (voir tutoriel introductif) Savoir se connecter en SSH à un périphérique Avoir défini un nom de domaine entièrement qualifié (FQDN en anglais - Fully Qualified Domain Name) pour l'instance Docker cible Difficulté : Moyenne 3. Sécurisation Pour garantir un certain degré de sécurité, l'idée va être d'exposer le socket Docker via un proxy, ce qui sera réalisé par un conteneur sur l'hôte cible, avec lequel nous établirons une connexion TLS depuis l'instance centralisatrice. Sa localisation peut être quelconque : sur le même réseau local, accessible à distance par HTTPS ou encore par VPN. Le choix de la solution et la sécurisation de l'environnement sont à votre discrétion et découlent des pré-requis stipulés ci-dessus. 4. Portainer Pour faciliter la visualisation de mes instances Docker (ou environment) et mes conteneurs, j'utilise l'application Portainer sur la machine qui va servir de centre névralgique pour toutes mes instances. Elle a l'avantage de fournir une interface claire, efficace et intuitive. (Notons qu'il est tout à fait possible de s'en passer et de se cantonner à de la ligne de commande, voir documentation Docker dont le lien est donné plus loin). Un fichier docker-compose.yml adapté aux NAS pour Portainer : version: '2.1' services: portainer: image: portainer/portainer-ce container_name: portainer network_mode: bridge volumes: - /volume1/docker/portainer/data:/data - /var/run/docker.sock:/var/run/docker.sock ports: - 9000:9000 restart: unless-stopped Puis on se place dans le dossier où se trouve le fichier docker-compose.yml précédent et on tape la commande suivante : docker-compose up -d Ou on passe par lignes de commande : docker create \ --name=portainer \ --net=bridge \ --restart=unless-stopped \ -v /volume1/docker/portainer/data:/data \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9000:9000 \ portainer/portainer-ce Puis on tape : docker start portainer Remarque : /volume1/docker/portainer/data est un emplacement adapté pour un NAS Synology, il faudra auparavant créer le dossier portainer et data dans le dossier partagé docker dans File Station. La première fois qu'on se connecte (via http://IP:9000), on est amené à choisir un login et un mot de passe admin. Ce faisant on arrive sur un écran demandant de choisir l'environment qu'on souhaite configurer, il faut choisir local et valider successivement les écrans. On arrive rapidement à un écran de la sorte : Je ne rentre pas dans le détail de l'utilisation de Portainer, on trouve des tutoriels relativement bien faits sur Youtube et Google, et c'est de toute façon assez simple à prendre en main : - https://www.youtube.com/watch?v=GNG6PDFxQyQ (à 1:36 on parle précisément de ce qu'on cherche à faire dans ce guide) - https://domopi.eu/ameliorer-la-gestion-de-vos-containers-docker-avec-portainer/ 5. Méthodes au choix Plusieurs méthodes sont disponibles : 5-A. Portainer-agent Avantage : - Facile et rapide à mettre en place Inconvénients : - Utilisation de certificats client/serveur auto-signés - Fonctionne uniquement avec Portainer Utilisation recommandée : réseau local ou VPN Pour le mettre en place sur le serveur distant qu'on souhaite superviser via notre instance centralisatrice, on passera par Docker-compose ou par lignes de commande : Par docker-compose : version: '2.1' services: portainer-agent: image: portainer/agent container_name: portainer-agent network_mode: bridge volumes: - /var/lib/docker/volumes:/var/lib/docker/volumes - /var/run/docker.sock:/var/run/docker.sock ports: - 9001:9001 restart: unless-stopped Puis : docker-compose up -d Par lignes de commande : docker create \ --name=portainer-agent \ --net=bridge \ --restart=unless-stopped \ -v /var/lib/docker/volumes:/var/lib/docker/volumes \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9001:9001 \ portainer/agent Puis : docker start portainer-agent Remarques : On monte le dossier contenant les volumes Docker, dont le principe est repris dans le tutoriel introductif. Cela permettra de parcourir ces dossiers depuis l'interface Portainer, très pratique pour aller télécharger certains fichiers internes au conteneur (logs, fichiers de configuration, etc...) : On remplace /var/lib/docker/volumes:/var/lib/docker/volumes par /volume1/@docker/volumes:/var/lib/docker/volumes si l'agent est installé sur un NAS Synology. On remplace /var/lib/docker/volumes:/var/lib/docker/volumes par /volume1/.@plugins/AppCentral/docker-ce/docker_lib/volumes:/var/lib/docker/volumes si l'agent est installé sur un NAS Asustor (merci à @MilesTEG1) On expose le port 9001 du conteneur sur le port 9001 de l'hôte (ou un autre port quelconque non utilisé). Si la machine cliente est derrière un routeur, on pense à faire la redirection du port 9001 vers celle-ci. Et que son pare-feu autorise les connexions ce port. Rendez-vous au paragraphe 6-A pour l'ajout de notre agent dans l'interface Portainer. 5-B. Portainer Edge agent A venir. 5-C. Liaison TLS + Proxy 5-C-1. Préambule Avantage : - Sécurisé par certificat client/serveur auto-signé (mais généré par vous-même donc auto-signé). - Utilisable dans toutes les utilisations envisageables d'une liaison TLS entre un serveur et un client, pas seulement dans le cadre de Docker. Inconvénients : - Plus long à mettre en place Utilisation recommandée : réseau local / VPN ou serveur distant Ici je vais prendre l'exemple d'un VPS OVH entrée de gamme. 5-C-2. Préparation La première étape consiste à se connecter en SSH avec l'utilisateur de notre choix sur la cible (le VPS en l'occurence pour moi) et de définir la variable HOST avec le FQDN de notre machine. Dans mon cas, j'utilise le nom de domaine que j'ai défini dans ma zone DNS OVH via un enregistrement A vers l'IP fixe de mon VPS. De manière générale, le FQDN peut être local ou externe, peu importe, car c'est un certificat auto-signé que nous allons générer pour l'atteindre, le tout étant que la résolution du FQDN soit adaptée à l'environnement (je ne peux pas utiliser vps.local si je passe par une résolution externe). Cela peut donc se faire comme moi avec un FQDN externe, si vous souhaitez gérer l'instance Docker d'un raspberry de votre réseau local, il peut s'agir de son enregistrement A correspondant dans votre serveur DNS local, ou simplement ce que vous avez renseigné dans le fichier /etc/hosts de votre instance centralisatrice. Pour l'exemple : HOST=target.ndd.tld En tapant : echo $HOST On doit obtenir le FQDN défini ci-avant. 5-C-3. Certificat serveur On va créer un dossier docker_tls dans le /home de notre utilisateur et on commence à suivre (pas bêtement, mais presque) les consignes de la documentation Docker, les étapes étant parfaitement décrites, je ménage vos touches Alt+Tab ou vous évite un torticolis si vous êtes en double écran en recopiant les étapes ici. 😉 Si vous souhaitez plus de détail sur l'explication de chaque étape, Rendez-vous sur la page. mkdir docker_tls cd docker_tls Puis on poursuit avec les commandes fournies par le guide : openssl genrsa -aes256 -out ca-key.pem 4096 openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem openssl genrsa -out server-key.pem 4096 openssl req -subj "/CN=$HOST" -sha256 -new -key server-key.pem -out server.csr [[[ ATTENTION : Il se peut que vous obteniez l'erreur suivante : Il suffit dans ce cas-là de créer le fichier manquant : touch .rnd et de recommencer ]]] Arrive le passage le plus subtil, il va falloir définir les IP et les FQDN capables d'accéder à cette instance, ça se présente sous cette forme : echo subjectAltName = DNS:,IP: >> extfile.cnf Évidemment, il va falloir renseigner les valeurs de manière exhaustive, sous peine de devoir recommencer depuis cette étape. Ce passage permet de renforcer la sécurisation également, car tout nom de domaine (et donc IP associée) et IP non déclarés se verront refuser l'accès au socket (Connection refused sur Portainer). Il faudra au minimum ajouter $HOST (que l'hôte puisse accéder à sa propre instance, ça ne mange pas de pain), la boucle locale 127.0.0.1, et le FQDN et/ou l'IP de notre instance centralisatrice. Un exemple, où j'autorise en plus par exemple : - l'IP fixe publique de mon instance centralisatrice 51.25.152.236 (fictive) (en cas d'un problème de résolution DNS, je peux toujours y accéder) - l'enregistrement A qui lui est associé central.ndd.tld (ça peut également être mon dynhost pour les IP dynamiques) - l'IP privée de mon instance centralisatrice lorsque connectée au serveur VPN de mon VPS 10.0.0.2 echo subjectAltName = DNS:$HOST,DNS:central.ndd.tld,IP:51.25.152.236,IP:10.0.0.2,IP:127.0.0.1 >> extfile.cnf On poursuit : echo extendedKeyUsage = serverAuth >> extfile.cnf openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf . 5-C-4. Certificat client Par facilité, on va rester sur la machine hôte et créer les certificats et la clé privée client. openssl genrsa -out key.pem 4096 openssl req -subj '/CN=client' -new -key key.pem -out client.csr echo extendedKeyUsage = clientAuth > extfile-client.cnf openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf rm -v client.csr server.csr extfile.cnf extfile-client.cnf chmod -v 0400 ca-key.pem key.pem server-key.pem chmod -v 0444 ca.pem server-cert.pem cert.pem 5-C-5. Récapitulatif Si tout s'est bien déroulé, un petit ls -lt devrait donner ceci : 5-C-6. Proxy Il nous faut maintenant créer le conteneur servant de proxy, dont voici la page GitHub de l'image. Un modèle de fichier docker-compose : version: '2.1' services: docker-socket-proxy: image: sjawhar/docker-socket-proxy container_name: docker-socket-proxy network_mode: bridge volumes: - /path/to/the/server/certs:/run/secrets:ro - /var/run/docker.sock:/var/run/docker.sock:ro ports: - 2376:2376 restart: unless-stopped Puis : docker-compose up -d Ou par lignes de commande : docker create \ --name=docker-socket-proxy \ --net=bridge \ --restart=unless-stopped \ -v /path/to/the/server/certs:/run/secrets:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -p 2376:2376 \ sjawhar/docker-socket-proxy Puis : docker start docker-socket-proxy Remarques : - /path/to/the/server/certs représente le dossier dans lequel vous allez placer vos certificats, cela dépend de l'OS de la machine cliente. Sur une distribution Linux classique, ça peut être dans le /home d'un utilisateur, dans /root ou partout ailleurs. Parmi les huit fichiers restants, trois nous intéressent pour ce conteneur : ca.pem, server-key.pem, server-cert.pem Ces trois fichiers doivent se trouver dans le chemin que vous aurez choisi pour /path/to/the/server/certs, pour ma part j'ai créé un sous-dossier certs dans le dossier du conteneur et je les y ai copiés. Le port 2376 est à ouvrir (et rediriger si besoin) sur la machine cible, évidemment. Et que le pare-feu de la machine, s'il y en a un, autorise les connexions sur ce port. Une fois le conteneur démarré, si tout va bien les logs du conteneur n'affichent rien, on le vérifie en tapant : docker logs docker-socket-proxy 6. Ajout de l'environment sur Portainer 6-A. Portainer agent On va ajouter l'agent en cliquant simplement dans Environment dans le menu latéral, puis + Add environment. On sélectionne Agent, puis on complète de cette manière : L'IP 192.168.1.50 est un exemple évidemment, on pense à préciser le port. On peut éventuellement ajouter des tags pour trier facilement les environments (utile si on supervise beaucoup de machines). Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. 6-B. Proxy On commence par rapatrier les trois fichiers utiles pour le client : ca.pem (le même que pour le serveur), cert.pem et key.pem. La sélection des fichiers se fera par une fenêtre de parcours, comme sur une interface graphique classique Linux ou Windows. Pour ceux que ça n'aide pas, j'ai utilisé scp et ai mis les fichiers sur mon bureau Linux (attention à la majuscule, c'est -P, pas -p) scp -P <port-SSH> ca.pem cert.pem key.pem toto@central.ndd.tld:~/Bureau Pour Windows, vous pouvez récupérer les fichiers avec WinSCP par exemple via connexion SSH. Le serveur est maintenant accessible, il ne reste plus qu'à se connecter à Portainer et ajouter l'environment. Dans le menu déroulant de gauche, on clique sur Environment, puis + Add environment. Puis on complète de la sorte, en adaptant évidemment à ses propres données : On notera la sélection des certificats et de la clé en bas de la page. On clique ensuite sur "Add environment". Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. 7. Utilisation de Github comme source des fichiers compose Il est possible de créer un dépôt personnel sur Github (ou tout autre logiciel git-compatible type Gitea, etc... notamment auto-hébergé 😉) afin d'y stocker ses fichiers compose, au lieu de les stocker sur la machine cible ou en utilisant les outils de Portainer. L'avantage est d'avoir accès depuis n'importe où, avec le niveau de sécurité que l'on a établi pour sa connexion à Github (2FA par exemple), à l'ensemble des fichiers de configuration de ses applications. Mieux, si on modifie un fichier, Portainer le détectera ou en sera informé et recréera le conteneur avec ses nouveaux paramètres. Pour cela, on va devoir dans un premier temps créer un token d'accès à Github pour Portainer. 7-A. Génération d'un personal acces token Tout d'abord, il faut créer un compte Github. Une fois ceci fait, on clique sur son portrait, puis Settings : Puis Developer settings tout en bas du menu à la gauche de l'écran -> Personal access tokens -> Generate new token : Ce sont, de mes tests, les permissions minimales à accorder via ce token à Portainer pour pull correctement les fichiers lors du déploiement de la pile (stack). On clique ensuite sur Generate token. ON NOTE BIEN LE TOKEN, SI ON LE PERD IL N'Y A AUCUN MOYEN DE LE RECUPERER. Il faudra alors en recréer un. On va maintenant créer un dépôt pour stocker nos fichiers. 7-B. Création d'un dépôt On clique sur son portrait puis Your repositories. Puis New. Voici un exemple de dépôt : On clique sur Create repository. On arrive sur notre dépôt, vide de tout fichier sauf du README qui contient la description entrée ci-avant. On pourra évidemment en faire une documentation si on en éprouve le besoin. On va maintenant changer le nom de la branche principale, pour qu'il corresponde à celui pré-établi par Portainer lors de la création d'une pile git. On clique sur branch : Puis, on clique sur l'icône en forme de crayon tout à droite de la ligne de la branche "main". On la renomme en master et on valide. On revient sur la page d'accueil du dépôt en cliquant sur Code. On va maintenant pouvoir ajouter ou créer nos premiers fichiers. 7-C. Création & ajout d'un fichier compose On a plusieurs possibilités : On clique sur Add file (voir impression d'écran ci-avant) : On télécharge sur le dépôt un fichier compose existant via Upload files. On crée un nouveau fichier en cliquant sur Create new file. On utilise git depuis sa machine pour alimenter son dépôt (non traîté). On va ajouter un fichier docker-compose existant depuis mon PC. On clique sur Upload files, on peut déposer le fichier à la volée ou parcourir l'arborescence, puis on clique sur Commit changes. Une fois le fichier ajouté, il est à la racine du dépôt. Si on souhaite créer une arborescence, il n'y a pas de fonction créer un dossier dans Github. Pour ce faire il faut éditer le fichier en question, en cliquant sur le fichier nouvellement ajouté puis la même icône crayon en haut à droite du cadre contenant le code du fichier. Si vous regardez en haut de l'impression d'écran, j'ai créé un chemin synology/docker-compose_exemple.yml Pour cela, j'ai simplement ajouté synology/ devant le nom du fichier compose, Github reconnaît une arborescence dès qu'on ajouté un /. Je conseille également de renommer les fichiers docker-compose.yml en ajoutant l'application en question, ce sera nécessaire pour dissocier les fichiers les uns des autres. Remarques : Vous noterez que j'ai déposé le fichier compose de Portainer, c'est purement pour l'exemple. C'est évidemment le seul fichier compose qu'on ne pourra pas exploiter via Portainer. 😉 Il n'y a pas d'adaptation spécifique à faire au niveau du contenu des fichiers compose par rapport à ce que vous avez l'habitude de faire directement via Portainer à la création d'une pile ou en ligne de commande. Et maintenant direction Portainer ! 7-D. Création de la pile Dans Portainer, on sélectionne l'environnement où l'on souhaite déployer la pile, puis on clique sur Add stack. On lui donne un nom, puis on choisit l'option Git repository. On complète de la façon suivante : Repository URL : On y met l'adresse de notre dépôt, concaténé à partir du nom d'utilisateur Github et du nom du dépôt, à c/c depuis Github. Repository reference : c'est la raison pour laquelle je vous ai fait changer le nom de la branche, Portainer propose master par défaut. Compose path : le chemin du fichier compose sur le dépôt. Il est possible de le c/c directement depuis le fichier en question : Authentication : Vu qu'on est sur un dépôt privé, il faut s'authentifer, c'est ici qu'on entre notre nom d'utilisateur Github ainsi que le PAT (Personal access token) généré précédemment. Automatic updates : Gros intérêt de ce procédé, les conteneurs sont dynamiquement liés à leurs fichiers de configuration sur Github. Deux moyens de procéder : Polling : Par défaut, toutes les 5 minutes, Portainer ira vérifier si le fichier a changé, si oui, il recréer le conteneur. Méthode la plus simple et recommandée Webhook : C'est Github qui signalera à Portainer que le fichier a changé. Quand vous utilisez cette option, Portainer crée un lien vers son API, lien à renseigner dans Github. Cette méthode a plusieurs implications. Il faut que les IP suivantes puissent accéder à votre instance Portainer (donc attention au pare-feu et au géo-blocage) : - 192.30.252.0/22 - 185.199.108.0/22 - 140.82.112.0/20 - 143.55.64.0/20 - 2a0a:a440::/29 - 2606:50c0::/32 De plus, il faut aller renseigner le lien vers Portainer dans Github, pour cela on va sur notre dépôt : On clique sur Add webhook puis : On entre l'URL fournie par Portainer, pas besoin d'ajouter de secret. Si on utilise un proxy inversé ou le port sécurisé de Portainer, on laisse activée la vérification SSL. Des tests que j'avais faits, seuls les commit comments ont besoin d'être cochés. Si ça ne fonctionne pas, choisissez Send me everything et éventuellement procédez par élimination pour trouver les événements nécessaires. Je recommande la méthode du polling, pas de problème d'accès car la requête part de Portainer. Il ne vous reste plus qu'à déployer les piles. 🙂 7-E. Variables d'environnement Il est possible, comme avec les outils natifs Portainer, de spécifier la valeur de variables d'environnement lors du déploiement de la pile. Par exemple, dans le fichier compose : environment: - MYSQL_ROOT_PASSWORD = ${MYSQL_ROOT_PASSWORD} Au moment du déploiement : Pour les férus de sécurité uniquement. 😉 MàJ : 11/11/2022

Bonjour Stifler14, On aimerait bien savoir où tu en es. Car j'étais comme toi, il y a quelques années, à vouloir m'équiper pour rendre dispo ma vidéothèque à tout instant dans la maison. Pour ma part, j'ai un Syno 8 baies, avec un volume par disque. Et chaque disque est en RAID 1 (mode mirror), donc 2 disques pour un volume et un total de 4 gros volumes. Ca coûte, mais ça sécurise un peu plus. Et vu le budget mis dans le NAS à 8 disques, j'ai bien entendu un onduleur dessus ! (EATON ELLIPSE MAX USBS 1100) Le tout a été mis dans un placard aéré, à l'écart du salon, car effectivement trop bruyant, surtout avec 8 disques ! J'ai même eu des soucis de vibrations sur l'étagère où est posé le NAS, mais un peu de bidouille au niveau des pieds du Nas (tampons épais, etc.) a réussi à rattraper le coup ! Tout mon réseau est en câblé ethernet cat6, livebox, nas, tv etc. Et finalement pas de plex et cie, le NAS délivre en DLNA les vidéos. J'ai juste ordonné mes dossiers et fichiers, et j'ajoute une fichier .jpg au fichier vidéo pour avoir une jaquette qui apparaît dans le lecteur multimédia de ma TV.. D'ailleurs, le lecteur multimédia intégré à ma TV LG OLED joue parfaitement mes vidéos mkv jusqu'au 4K, pistes son AC3, AC3+ et DTS. Bien sûr, pas d'Atmos, mais je m'adapte et de toute façon je n'ai que du 5.1 d'installé chez moi ! Mon but était tant que possible de limiter le nombre d'appareils et de télécommandes 🙂 J'avoue que certains encodages de 4K ne passent pas sur le lecteur de la LG, mais comme dit plus haut dans le fil de discussion, un Shield ou autre rattrape la compatibilité possible, c'est dépendant du lecteur, pas du NAS. Le NAS délivre toujours les fichiers vidéo à bon débit, c'est tout ce qu'on lui demande. Bref, avec cette install, c'est moi aussi cinéma à la maison @Drayabob 😎

Bonjour, je ne sais pas si tu as déjà acheté ton NAS mais pour ma part, j’ai un NAS 218+ (2 baies) acheté initialement pour me faire la main qui me sert maintenant de sauvegarde. (J’ai recyclé un WD RED de 4To et un autre de 6To). Je pense les remplacer par un bundle de 2 disques de 20To chacun. En effet il y a une promotion sur le site de western Digital en ce moment ! les 2 disques pour 835€ cela me permettra de faire une sauvegarde complète de mon NAS (VIDÉOTHÈQUE comprise) car actuellement mon NAS est en hyperbackup pour les données, et la sauvegarde de la vidéothèque sur un HDD externe de 10To. sinon j’ai mon NAS de stockage un 920+ (4 baies avec 3 disques pour l’instant de 12To chacun, soit un volume de 20To en production avec tolérance de panne 1 disque). j’ai aussi une bibliothèque de film et j’utilise VIDÉO STATION avec lecture de films en1080p ou 4K et DTS (cf le tuto que j’ai mis en ligne). Ça passe nickel sur ma TV sous androïd (Sony). J’utilise aussi une Apple TV 4K a l’occasion avec Infuse Pro mais finalement c’est plutôt une question de navigation dans ma bibliothèque (soit pas Infuse soit par VIDÉO STATION) car niveau audio avec mon ampli Denon 4700h et mon installation 5.2.1, c’est cinéma à la maison. voilà, si cela peut t’aider ou aider la communauté…

Bon en suivant la procédure d'installation pour Ubuntu ça marche bien : Donc tu as juste à créer une VM avec VMM (tu as des tutos Synology assez bien faits sur le site officiel). Une fois ta VM crée tu suis toutes les étapes à ce lien : https://docs.mattermost.com/install/installing-ubuntu-1804-LTS.html#install-mattermost-server soit en te connectant en SSH à ta VM depuis Putty, soit directement via le guest agent si tu as installé un Linux avec interface graphique. Pour accéder au site via une URL sécurisée, tu dois utiliser un proxy inversé, celui du NAS fera l'affaire (voir tutoriel https://www.nas-forum.com/forum/topic/59108-tuto-reverse-proxy/), il te suffira de mettre l'url (Siteurl) que tu as choisi dans le JSON de Mattermost (c'est expliqué dans le tutoriel) comme adresse pour Mattermost : https://mattermost.ndd.tld -> http://IP_DE_LA_VM:8065 Et normalement tout devrait rouler. N'hésite pas si tu as des questions.

Ticket en cours chez Synology, le problème à réussis à être reproduit chez eux. Je fais beaucoup d'échanges avec le support, je vous résumerais les explications au fur et à mesure dans les prochains jours.

Merci Maxou56 , ca fait 2 fois que tes reponses pertinentes me depanent bien. Je ne sais pas ou tu te trouves mais si tu passes par Tournai un de ces 4, contactes moi et je te paie une bonne biere 😉