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 🙂

Je cherchais un truc dans l'aide du DSM (sur le "versionnage") et J'ai trouvé la dernière ligne un peu traduite "à l'arrache" ! En fait je ne vois pas le rapport avec DSM lol ! Il n'y a que le prix d'achat du matériel qui pourrait s'approcher et rendre cette option/fonction indispensable 🙂

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 !

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 😉

1. Qu'est-ce qu'Authelia ? Authelia est un serveur d'authentification open-source proposant une authentification unique ou à deux facteurs à la demande. C'est donc un moyen de venir appliquer une couche de sécurité supplémentaire sur une application critique ou sur une application qui en serait dépourvue d'élément d'authentification. L'authentification deux facteurs peut se faire via : TOTP (Time-based One-Time Password) : l'authentification à deux facteurs telle que Synology la propose, un code valable x secondes à valider après la saisie du mot de passe. Notifications PUSH : via l'application DuoAPI, on va pouvoir recevoir des notifications push sur notre téléphone pour valider la connexion. Clés de sécurité avec jeton type Yubikey. OpenID Connect (en beta) : Vous vous servez de votre ID OpenID pour vous connecter à vos applications. Seuls les points 1 et 2 seront développés dans ce tutoriel. 2. Prérequis Difficulté : moyenne-avancé Vous devez disposer d'un NAS compatible Docker, vous pouvez en retrouver la liste mise à jour à cette adresse : https://www.synology.com/fr-fr/dsm/packages/Docker Avoir mis en place SWAG (proxy inversé multi-fonctionnel) dont un tutoriel de mise en route est disponible sur ce forum : Disposer d'une instance MySQL (ou MariaDB) Savoir se connecter en SSH en root Savoir éditer les différents fichiers de configuration par la méthode de votre choix (nano, vim, WinSCP, File Station, etc...) Utiliser Docker-compose NOTE : Certaines notions sont longuement explicitées dans le tutoriel pour la mise en place de SWAG, une double astérisque ** sera présente à côté des points concernés. 3. Principe Lorsque Nginx reçoit une requête vers exemple.ndd.tld et que ce sous-domaine est l'objet d'une entrée de proxy inversé, il vérifie si un appel à Authelia est demandé. Si c'est le cas, la demande est transférée à ce dernier, qui va exiger une authentification (ou pas) afin de poursuivre. Suivant les ACL (Access Control Lists) qu'on aura défini dans sa configuration, l'accès peut être : refusé autorisé autorisé sous réserve d'authentification par login et mot de passe autorisé sous réserve d'authentification à deux facteurs On peut donc en résumer le principe suivant ce schéma (dans notre cas, nous détaillerons l'installation pour Nginx uniquement, mais Traefik et HAProxy sont également compatibles) : Authelia doit être vu comme un complément de Nginx, même si les deux permettent un filtrage par ACL (et Nginx un blocage GeoIP de surcroît, qu'Authelia n'intègre pas). Il utilise le port 9091, qui n'est pas un port utilisé par défaut par DSM, comme pouvaient l'être les ports 80 et 443, raison pour laquelle SWAG est déployé sur un réseau macvlan. Il sera donc déployé sur un réseau bridge. 4. Hypothèses Quelques conventions pour s'y retrouver par la suite : IP de l'hôte : 192.168.1.100 IP virtuelle de l'hôte : : 192.168.1.200 Réseau bridge personnalisé : 172.25.0.0 Les commandes via SSH sont exécutées en tant que root. 5. Création d'un réseau bridge personnalisé A priori, on pourrait utiliser le réseau bridge par défaut (172.17.0.0/16), néanmoins afin de garantir un minimum de changement au cas où vous souhaiteriez utiliser Redis (voir fonctionnalités avancées) en conjonction avec Authelia, on va créer un réseau bridge personnalisé qui facilitera la communication inter-conteneurs. mkdir -p /volume1/docker/networks && cd $_ nano net-db.sh On y insère le code suivant : docker network create -d bridge \ --subnet=172.25.0.0/16 \ --gateway=172.25.0.1 \ --opt "com.docker.network.bridge.name"="br_net-db" \ net-db On rend le script exécutable : chmod u+x net-db.sh On l'exécute : bash net-db.sh Si la commande se termine avec succès, un identifiant composé de lettres et de chiffres s'affiche à l'écran. 6. Installation 6-A. Fichier docker-compose Voici une proposition de fichier docker-compose adapté aux versions 2.x, libre à vous de vous inspirer de ce qui est recommandé dans la documentation d'Authelia : version: '2.1' services: authelia: image: authelia/authelia container_name: authelia networks: - net-db environment: - AUTHELIA_JWT_SECRET_FILE=/config/secrets/jwt - AUTHELIA_STORAGE_MYSQL_PASSWORD_FILE=/config/secrets/mysql - AUTHELIA_NOTIFIER_SMTP_PASSWORD_FILE=/config/secrets/smtp - AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE=/config/secrets/encryption - TZ=Europe/Brussels ports: - 9091:9091/tcp volumes: - /volume1/docker/authelia/config:/config restart: unless-stopped networks: net-db: external: true NOTE : Pour l'instant on ne crée pas le conteneur via la commande docker-compose, cela n'interviendra que bien plus tard. 6-B. Secrets Authelia ne permet pas de stocker des credentials (login et mot de passe) directement en clair dans les variables, ni même dans un fichier .env. On peut donc soit utiliser la fonctionnalité secrets de Docker (compatible sur les implémentations de Docker pour DSM 7 et +), soit définir les variables dans des fichiers et les monter au moyen de variables d'environnement, c'est cette seconde méthode que nous privilégierons (voir docker-compose ci-avant). On crée les dossiers où seront stockées nos données en s'y plaçant dans la foulée : mkdir -p /volume1/docker/authelia/config/secrets && cd $_ Puis on crée les fichiers contenant les mots de passe que le fichier de configuration d'Authelia utilisera. N'hésitez pas à utiliser des mots de passe longs (privilégiez la longueur du mot de passe sur la présence abusive de caractères spéciaux). 30 caractères par exemple est une valeur satisfaisante : echo 'MOT_DE_PASSE_1' > jwt echo 'MOT_DE_PASSE_2' > mysql ## Le mot de passe pour MySQL doit conteneur au moins 1 caractere special !! echo 'MDP_SMTP_MAIL' > smtp ## Correspond au mot de passe du serveur SMTP qu'Authelia utilisera echo 'MOT_DE_PASSE_3' > encryption ## Minimum 20 caracteres, idealement 64 On vérifie la présence de nos fichiers : ls -l Ce qui devrait vous donner ceci : total 12 -rwxr-xr-x+ 1 root root 31 Jul 25 00:15 jwt -rwxr-xr-x+ 1 root root 31 Jul 25 00:16 mysql -rwxr-xr-x+ 1 root root 14 Jul 26 00:09 smtp -rwxr-xr-x+ 1 root root 14 Jul 26 00:09 encryption Comme on peut le constater, malgré le fait que les fichiers appartiennent à l'utilisateur et au groupe root, DSM applique ses ACL (le "+" à la fin des permissions UNIX), ce qui fait que n'importe quel utilisateur possédant des droits de lecture et ou d'écriture dans le dossier partagé docker pourra consulter le contenu de ces fichiers. On sécurise donc les fichiers : chmod 660 ./* chown your-personal-user:root ./* NOTE : Il faut évidemment remplacer l'utilisateur your-personal-user par l'utilisateur dont vous souhaitez qu'il soit propriétaire des dits fichiers. 6-C. Configuration 6-C-1. Génération du fichier configuration.yml d'Authelia On va exécuter une première fois le conteneur, qui s'arrêtera aussitôt, mais dont l'exécution permettra de générer un fichier de configuration, il a l'avantage d'être entièrement commenté et vous sera d'une aide précieuse si vous souhaitez creuser plus amplement les possibilités d'Authelia. On exécute la commande suivante : docker run --rm -v /volume1/docker/authelia/config:/config authelia/authelia A la suite de quoi on a un fichier configuration.yml dans /volume1/docker/authelia/config 6-C-2. Préparation de SWAG Le cadre d'utilisation par défaut prévu pour SWAG est d'être dans le même réseau bridge personnalisé qu'Authelia, ce n'est pas le cas ici vu que SWAG est déployé sur un réseau macvlan. 6-C-2-a. Modification de la configuration serveur On va devoir éditer les fichiers de configuration pour Authelia dans SWAG, notamment le fichier authelia-server.conf : cd /volume1/docker/swag/config/nginx && nano authelia-server.conf Ce qui donne : ## Version 2021/05/28 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/authelia-server.conf # Make sure that your authelia container is in the same user defined bridge network and is named authelia location ^~ /authelia { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_authelia 192.168.1.200; ## On remplace "authelia" par l'IP virtuelle du NAS proxy_pass http://$upstream_authelia:9091; } location = /authelia/api/verify { internal; if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) { return 401; } include /config/nginx/resolver.conf; set $upstream_authelia 192.168.1.200; ## On remplace "authelia" par l'IP virtuelle du NAS proxy_pass_request_body off; proxy_pass http://$upstream_authelia:9091; proxy_set_header Content-Length ""; [...] } ATTENTION : Avec DSM 7, les appels API pour le bureau DSM comprennent des caractères normalement ignorés par Authelia (des accolades), il faut les ajouter dans la ligne : if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) { devient if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]\{\}]) { On valide les modifications. 6-C-2-b. Modification des entrées de proxy inversé** Pour que Nginx prenne Authelia en compte, il suffit d'éditer une entrée de proxy inversé existante, et de décommenter les deux lignes suivantes : #include /config/nginx/authelia-server.conf; [...] #include /config/nginx/authelia-location.conf; Il faudra ensuite que le domaine correspondant à cette entrée soit pris en charge dans les ACL d'Authelia (voir point 6-C-3-f.) 6-C-2-c. Création d'entrée pour Authelia** On va également en profiter pour créer une entrée de proxy inversé pour la page d'Authelia, dont on va se servir pour configurer nos accès : cd /volume1/docker/swag/config/nginx/proxy-confs cp authelia.subdomain.conf.sample authelia.subdomain.conf nano authelia.subdomain.conf Puis on adapte à notre besoin : ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. server { listen 443 ssl; listen [::]:443 ssl; server_name authelia.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.1.200; ## On utilise l'IP virtuelle du NAS set $upstream_port 9091; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } _______________________ Une fois ceci fait, on redémarre le conteneur SWAG, on n'aura plus besoin d'y toucher. docker restart swag 6-C-3. Personnalisation du fichier de configuration d'Authelia Le fichier regorge d'options, parcourons-le donc et voyons ce qu'il convient de faire au fur et à mesure. Les parties que je ne mentionne pas ne sont pas sensées être modifiées (du moins pour l'application qu'on en fera ici (voir la documentation pour une utilisation plus experte)) ou ont un intérêt évident/trivial (theme par exemple). 6-C-3-a. server # Configuration options specific to the internal http server server: [...] path: "authelia" Donner la valeur "authelia" à path est un prérequis du bon fonctionnement de l'application suivant la configuration embarquée dans SWAG. 6-C-3-b. log log: level: info [...] file_path: /config/logs/authelia.log keep_stdout: true Le niveau info est déjà suffisamment verbeux, n'utiliser debug ou trace qu'en cas de problème à résoudre. Pour file_path et keep_stdout : préférence personnelle, j'aime bien avoir un fichier log, et garder pour autant l'output sur les logs du conteneur. Faites comme il vous plaît. 6-C-3-c. jwt_secret jwt_secret: Il est important de noter que jwt_secret n'ait aucune valeur, afin que le secret défini dans le fichier jwt soit pris en compte. Si vous laissez la chaîne de caractères par défaut "a_very_important_secret", le contenu du fichier jwt ne sera pas utilisé. NOTE : Cette remarque est valable pour toutes les autres clés faisant appel au contenu des fichiers définis par avant (jwt, mysql, etc...). 6-C-3-d. default_redirection_url default_redirection_url: https://ndd.tld Authelia est directement accessible par proxy inversé, c'est un des templates de fichier conf de SWAG. Lorsque vous vous identifierez sur cette page, vous serez redirigé vers la page définie par default_redirection_url. 6-C-3-e. authentication_backend Deux possibilités existent : l'utilisation d'un annuaire LDAP ou un fichier d'utilisateurs défini localement. Nous utiliserons la seconde option. Il faut par conséquent commenter toutes les clés, listes, etc... liées à la configuration du serveur LDAP : ## ## LDAP (Authentication Provider) ## ## This is the recommended Authentication Provider in production ## because it allows Authelia to offload the stateful operations ## onto the LDAP service. # ldap: [...] # implementation: custom [...] # url: ldap://127.0.0.1 ## Use StartTLS with the LDAP connection. # start_tls: false # tls: [...] # skip_verify: false ## Minimum TLS version for either Secure LDAP or LDAP StartTLS. # minimum_version: TLS1.2 [...] # base_dn: dc=example,dc=com [...] # additional_users_dn: ou=users [...] # users_filter: (&({username_attribute}={input})(objectClass=person)) [...] # additional_groups_dn: ou=groups [...] # groups_filter: (&(member={dn})(objectclass=groupOfNames)) [...] ## The username and password of the admin user. # user: cn=admin,dc=example,dc=com # password: password Nous utiliserons la deuxième option disponible : la définition locale d'utilisateurs dans une liste, cela se fait au moyen d'un fichier users_database.yml. On utilise le modèle disponible sur GitHub : cd /volume1/docker/authelia/config wget https://raw.githubusercontent.com/authelia/authelia/master/examples/compose/local/authelia/users_database.yml Qu'on personnalisera de la sorte : --- ############################################################### # Users Database # ############################################################### # This file can be used if you do not have an LDAP set up. # List of users users: toto: displayname: "Thomas" password: "$argon2id$v=19$m=65536,t=1,p=8$VmFaM3FKckFRZVY5TUJ5eg$81mBJ3QSw8WQM2rm4yNJeS7j2YQMra183gHCxGALOAs" email: mail@ndd.tld groups: [] # - admins # - dev ... toto sera le nom d'utilisateur qui sera utilisé pour l'authentification simple ou double facteur. De préférence choisissez un nom d'utilisateur plus long et complexe. 🙂 Thomas sera le nom d'affichage. <PASSWORD> sera le mot de passe utilisé pour s'authentifier, mais il ne sera pas lisible en clair, Authelia utilise un algorithme de chiffrement en ce sens. On va utiliser la commande suivante : docker run --rm authelia/authelia:latest authelia hash-password 'MOT_DE_PASSE' Suivant votre modèle de NAS et la complexité de votre mot de passe, cette opération pourrait prendre un certain temps, mais à la fin de quoi vous devriez obtenir un renvoi de la sorte : $argon2id$v=19$m=65536,t=1,p=8$aC8raDhGRWh4eDlmRmp5aw$PsiuwaVbWsXkIThpLLeI3JZdT3NCe3CUeAXORQzsSpg C'est cette ligne qu'il vous faut mettre à la place de <PASSWORD>. Pour l'email, c'est l'adresse qui sera utilisée en cas de demande de renouvellement de mot de passe, etc..., à personnaliser. Pour les groupes, je conseille de ne pas vous en servir dans un premier temps, il vous suffit de modifier ainsi : groups: [] # - admins # - dev NOTE : Le fichier ne donnant pas d'information sensible, et afin de permettre aux différents utilisateurs de modifier éventuellement leur mot de passe, on peut laisser les permissions par défaut (celles de DSM avec les ACL). _______________________ On décommente la section file : authentication_backend: # Disable both the HTML element and the API for reset password functionality disable_reset_password: false [...] refresh_interval: 5m [...] file: path: /config/users_database.yml password: algorithm: argon2id iterations: 1 key_length: 32 salt_length: 16 memory: 1024 parallelism: 8 6-C-3-f. access_control Une des parties les plus importantes, elle concerne les contrôles d'accès et la manière dont Authelia va se comporter en fonction de l'IP d'origine et le domaine demandé lors de la requête. Pour plus d'information, la documentation est consultable à cette adresse. On va se placer dans le cas (pour exemple) où on autorise tous les accès en local et VPN, et on limite ensuite de façon granulaire au gré des sous-domaines : access_control: # Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'. # It is the policy applied to any resource if there is no policy to be applied # to the user. default_policy: deny networks: - name: local networks: # LAN network - 192.168.1.0/24 # Docker network - 172.16.0.0/12 - name: openvpn networks: # OpenVPN subnet - 10.0.8.0/24 rules: # Bypass 2FA when connected to VPN on pfSense or being connected to the LAN - domain: - ndd.tld - "*.ndd.tld" policy: bypass networks: - local - openvpn # Open public access - domain: - public.ndd.tld - public2.ndd.tld policy: bypass # Single authentication for applications lacking authentication system - domain: semi-private.ndd.tld policy: one_factor # 2FA for sensitive services - domain: private.ndd.tld policy: two_factor NOTES : Dans la partie networks, on définit des alias pour faciliter la définition des règles et rendre moins fastidieuse leur rédaction. Dans la partie rules, je définis les sites qui auront un accès publique (sans protection supplémentaire que celle dont ils disposent déjà), ceux qui devront faire l'objet d'une simple authentification, et ceux qui doivent être soumis à la 2FA. Si l'accès à un sous-domaine vous est refusé sans raison, c'est qu'aucune des règles définies ne répond à la situation présente, dans ce cas Authelia rejette la demande (par le paramètre default_policy: deny). Vous pouvez temporairement ne pas mettre "*.ndd.tld" dans les domaines by-passés, le temps de mettre en route Authelia. Ou alors faire le test d'authentification depuis une connexion 4G. 6-C-3-g. session session: ## The name of the session cookie. name: authelia_session [...] domain: ndd.tld On pensera à renseigner le domaine racine qu'on souhaite protéger dans la valeur de la clé domain. ATTENTION : Authelia ne peut pas protéger plusieurs domaines racines simultanément. La mise en place de Redis est détaillée dans la partie Fonctionnalités avancées, on va s'en passer pour notre cas d'utilisation et commenter les paramètres qui y ont trait : ## ## Redis Provider ## ## Important: Kubernetes (or HA) users must read https://www.authelia.com/docs/features/statelessness.html ## # redis: # host: 127.0.0.1 # port: 6379 ## Use a unix socket instead # host: /var/run/redis/redis.sock ## Username used for redis authentication. This is optional and a new feature in redis 6.0. # username: authelia ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html # password: authelia ## This is the Redis DB Index https://redis.io/commands/select (sometimes referred to as database number, DB, etc). # database_index: 0 ## The maximum number of concurrent active connections to Redis. # maximum_active_connections: 8 ## The target number of idle connections to have open ready for work. Useful when opening connections is slow. # minimum_idle_connections: 0 6-C-3-h. storage Depuis la version 4.33.0 d'Authelia, il est nécessaire de définir une clé de chiffrement (encryption key) pour éviter les corruptions de base de données. C'est la chaîne de caractères définie dans le fichier encryption créé plus tôt (voir les prérequis ici : https://www.authelia.com/configuration/storage/introduction/#encryption_key) storage: ## The encryption key that is used to encrypt sensitive information in the database. Must be a string with a minimum ## length of 20. Please see the docs if you configure this with an undesirable key and need to change it. encryption_key: ## ## MySQL / MariaDB (Storage Provider) ## mysql: host: 192.168.1.200 port: 3307 database: authelia username: authelia ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html password: Par défaut, Authelia suggère d'utiliser MySQL, ce que nous allons faire car le paquet MariaDB 10 est disponible dans le centre de paquets. On spécifie l'IP virtuelle du NAS, ainsi que le port de MariaDB (3307 pour MariaDB 10). On se connecte ensuite à phpMyAdmin (paquet) via le menu DSM avec le compte root, et on crée notre utilisateur : On choisit un nom d'utilisateur, on reprend le mot de passe défini dans le fichier mysql créé précédemment et on coche "Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base." On clique sur Exécuter en bas à droite de la page, si l'opération est un succès vous verrez le contenu de la requête affiché en vert dans le haut de la page. Notre base de données est maintenant prête à accueillir les données d'Authelia. 6-C-3-i. notifier notifier: ## You can disable the notifier startup check by setting this to true. disable_startup_check: false [...] smtp: username: mail@ndd.tld ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html password: host: ssl0.ovh.net port: 587 sender: mail@ndd.tld ## HELO/EHLO Identifier. Some SMTP Servers may reject the default of localhost. identifier: localhost ## Subject configuration of the emails sent. {title} is replaced by the text from the notifier. subject: "[Authelia] {title}" ## This address is used during the startup check to verify the email configuration is correct. ## It's not important what it is except if your email server only allows local delivery. startup_check_address: mail@ndd.tld disable_require_tls: false disable_html_emails: false [...] ## Sending an email using a Gmail account is as simple as the next section. ## You need to create an app password by following: https://support.google.com/accounts/answer/185833?hl=en # smtp: # username: myaccount@gmail.com # ## Password can also be set using a secret: https://www.authelia.com/docs/configuration/secrets.html # password: # sender: myaccount@gmail.com # host: smtp.gmail.com # port: 587 Authelia propose par défaut l'utilisation d'un SMTP externe (type OVH dans l'exemple ci-dessus) ou de passer par un compte Gmail. Dans ce dernier cas, pensez à autoriser les applications moins sécurisées dans les réglages de votre compte Google, sinon l'envoi de mails ne se fera pas. 7. Création et utilisation du code TOTP Le plus dur est fait, il reste maintenant à se logger avec le compte qu'on a créé, on va sur la page https://authelia.ndd.tld (on s'assurera que l'entrée DNS de type A ou CNAME existe déjà, en local ou/et publique) : On entre le nom de l'utilisateur, ici toto, et le mot de passe qu'on lui a attribué. On clique sur Sign In, on arrive sur la page suivante : En cliquant sur Not registered yet?, un email sera envoyé à l'adresse renseignée pour l'utilisateur toto dans le fichier users_database.yml. Dans ce mail, on clique sur l'hyperlien Register, qui nous amène à une page avec un QR-CODE. Si vous possédez déjà une application 2FA, il vous suffit de scanner le code. Sinon vous pouvez suivre les liens pour Play Store et iOS. A titre personnel, j'utilise andOTP sur Fdroid, le store alternatif pour Android. Une fois le code ajouté dans l'application, il suffit de cliquer sur Done et on peut se connecter : Si le code est bon, vous verrez le statut authentifié en vert, et vous serez redirigé vers la page que vous aviez précédemment définie dans default_redirection_url au point 6-C-3-d. Maintenant, vous pouvez accéder à toutes vos applications en choisissant vous-même le curseur de sécurité. 😉 8. Fonctionnalités avancées 8-A. Redis A venir... 8-B. DuoAPI A venir... 9. FAQ Q : J'ai perdu le mot de passe de mon utilisateur, comment retrouver l'accès à mes sous-domaines ? A : A l'écran de login, vous pouvez cliquer sur Reset password?. Q : J'ai perdu mon code accès TOTP, que faire ? A : Une fois loggé, vous pouvez cliquer sur Lost your device?. Vous recevrez alors un mail vous proposant un nouveau QR-CODE. Q : Puis-je désactiver la possibilité pour les utilisateurs de récupérer leur mot de passe ? A : Oui, il faut modifier la valeur de la clé disable_reset_password dans la section authentication_backend à true. Q : J'obtiens une erreur 502 en accédant à mes entrées de proxy inversé, pourquoi ? A : Il y a plusieurs raisons possibles, mais dans le cas présent il se peut que l'interface virtuelle du NAS ait disparu, suite à un arrêt, un redémarrage ou une mise à jour du paquet Docker. Vous avez normalement déjà mis en place un script qui permet de la recréer automatiquement au démarrage du NAS. Mais en cas de perte de l'interface il faudra simplement relancer la tâche manuellement depuis le planificateur de tâches. Màj : 07/08/2023

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 Oracle. La panne des processeurs C2000 vient à l'origine de la défaillance d'un transistor interne qui pilote la transmission d'un signal d'horloge en direction de l'Eprom du Bios du NAS. Quand ce transistor lâche, l'horloge s'arrête et empêche la lecture du Bios et donc le démarrage du NAS. En fait il y a deux transistors Mosfet (voir schéma ci-dessous) pour piloter ce signal. Celui du haut qui fait passer le signal à l'état haut (+3,3V), et celui du bas qui le fait passer à l'état bas (0v). Et c'est celui du haut qui est tombé en panne et ne conduit plus le courant. (cercle rouge) Mais on peu le remplacer partiellement par une résistance connectée au 3,3V, qui va tenir le signal au niveau haut, et seul le transistor du bas suffira à générer l'horloge en mettant alternativement la ligne à 0V ce qui récrée le signal carré nécessaire. Plus cette résistance est faible, plus le courant qui traverse le transistor du bas est fort, et risque à terme de le faire griller. En augmentant la valeur, on limite le courant dans le transistor restant et donc sa durée de vie. On sait que ça doit pouvoir fonctionner jusqu'à 750 ohms, mais avec 470, on a une bonne marge de sécurité pour que ça marche à tous les coups. Attention un Nas déjà réparé avec 100 ohms qui est retombé en panne définitivement ensuite ne pourra pas revenir à la vie avec cette autre résistance. Il y a une autre méthode que j'exposerai dans l'autre sujet: https://www.nas-forum.com/forum/topic/55281-soucis-sur-les-atom-c2000-panne-programmée-des-modèles-rs2416-rs2416rp-rs815rs815rp-ds2415-ds1815-ds1515-ds415/page/18/

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-04-25 - 4.3.0 : https://github.com/Gizmo091/synology_1fichier_hosting/raw/main/OneFichierCom(4.3.0).host 2024-03-25 - 4.2.0 Changelogs : - 4.3.0 : Définition du nom du fichier de destination dans les informations retournées au DL Station ( evite par exemple les _ indésirables ) - 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

1. Qu'est-ce qu'un proxy inversé ? Un proxy inversé (reverse proxy) est un type de serveur, habituellement placé en frontal de serveurs web. Contrairement au serveur proxy qui permet à un utilisateur d'accéder à un environnement depuis un point unique, le proxy inversé permet à un utilisateur d'accéder depuis un environnement à des serveurs internes via un point d'entrée unique. Un proxy inversé écoute sur un port donné, sécurisé ou pas, toutes les requêtes à destination de ces services. Au lieu donc d'avoir de multiples portes (les ports des applications auxquelles ont souhaite accéder depuis l'extérieur), on en a une seule qui s'occupera de rediriger les requêtes vers le bon service. 2. Prérequis - Comprendre le fonctionnement de Docker (voir tutoriel introductif) - Savoir se connecter en SSH à son hôte - Savoir rediriger un port depuis sa box - Être un peu curieux Difficulté : Moyenne 3. Pourquoi ? Des solutions de proxy inversé, il en existe des tas, toutes ont leurs avantages et inconvénients. DSM utilise Nginx, mais il existe aussi entre autres HAProxy, Apache, Squid, etc... Dans notre cas ce sera également Nginx, mais via l'image Docker linuxserver/swag, car elle embarque tout un ensemble de fonctionnalités supplémentaires qui agissent en synergie. Cette solution comprend notamment : Certbot : utilitaire permettant l'obtention et le renouvellement automatique de certificats Let's Encrypt. Fail2ban : Script permettant le bannissement d'IP ayant réalisé un nombre donné de tentatives de log infructueuses. Authelia (fichiers de configuration seulement) : Logiciel d'authentification deux facteurs hautement personnalisable et applicable à n'importe quelle application. Nginx : Serveur web qu'on utilise ici pour faire office de proxy inversé. L'intérêt majeur est de pouvoir appliquer des fonctionnalités existantes dans DSM mais réservées à celui-ci, à n'importe quelle application. Et de disposer d'un serveur Nginx entièrement paramétrable a contrario de celui intégré à DSM. ATTENTION : Cette image ne permet pas de déployer automatiquement le certificat obtenu dans DSM à la manière dont le fait acme.sh (voir tutoriel de @Einsteinium pour une utilisation via Docker ou le tutoriel de @oracle7 pour les NAS incompatibles). Vous devrez l'installer manuellement dans DSM si vous souhaitez l'utiliser et le faire tous les 3 mois. Pour ma part je ne m'embête pas, j'utilise l'interface DSM pour obtenir un certificat wildcard avec le nom de domaine Synology qui se renouvelle tout seul tous les 2 mois. Ainsi, j'utilise le nom de domaine Synology pour les services comme Hyper Backup, Drive, etc... tout ce qui est intrinsèquement lié à DSM et qui n'est pas gérable au travers d'un proxy inversé. Tout le reste passe par le certificat OVH que ce conteneur va générer. 4. Hypothèses Pour mieux illustrer le propos, je conviendrai d'un certain nombre d'adresses qui faciliteront l'identification des consignes à l'application du tutoriel : Adressage réseau "physique" : 192.168.1.0/255.255.255.0 (/24 en notation CIDR) Le serveur DHCP ne couvre qu'une partie de la plage 192.168.1.0/24, par exemple 192.168.1.1 à 192.168.1.99 Passerelle (routeur ou modem) : 192.168.1.254 IP (physique, pour utilisation avec réseau macvlan) du conteneur swag : 192.168.1.145 (voir plus loin). IP de l'hôte (le NAS ici, mais ça pourrait être une autre périphérique) : 192.168.1.100 (Je pars du principe que votre hôte a une IP définie en dehors de la plage d'attribution du serveur DHCP, ce n'est pas obligatoire (mais conseillé)). IP virtuelle de l'hôte (voir plus loin) : 192.168.1.200 eth0 est le nom de mon interface physique. 5. Principe L'idée générale de ce que l'on s'apprête à mettre en place peut être résumée de la sorte : Le port 443/tcp (par défaut) est le port d'écoute du proxy inversé. Le port 80 est le port utilisé par Let's Encrypt pour renouveler les certificats si on choisit la méthode de validation HTTP-01 et/ou pour faire une redirection HTTP -> HTTPS. Deux cas de figure se présentent, soit les ports sont libres sur l'hôte, soit ils ne le sont pas : S'ils sont libres, ce qui est le cas si vous décidez d'utiliser SWAG sur une autre machine que le NAS (un Raspberry Pi fait tout à fait le job), alors on peut créer notre conteneur sur un réseau bridge. Dans ce cas-là, la lecture du tutoriel introductif devrait suffire pour la mise en place de swag. S'ils ne le sont pas, ce qui est très probablement le cas sur votre NAS (Webstation installé, Nginx en sous-main) on le rattachera à un réseau macvlan. Un réseau macvlan permet de donner une adresse IP au conteneur sur le réseau physique, par exemple ici 192.168.1.150 Il s'émancipe d'une certaine manière de l'hôte et se comporte globalement comme un périphérique à part entière relié à votre routeur. Il pourra donc utiliser tous les ports dont il a besoin. Au prix d'une impossibilité de communication avec l'IP de l'hôte (limitation intrinsèque au pilote macvlan). Mais il existe une manière de contourner le problème de communication via une interface virtuelle du NAS, vous trouverez plus de détail dans le tutoriel introductif. C'est la méthode que j'ai décidé de privilégier ici, car plus difficile d'accès que via le réseau bridge, et qu'elle permet de ne pas toucher à la configuration du NAS. Je reprendrai principalement ce qu'on peut trouver dans mon tutoriel sur Docker, en l'appliquant à notre cas d'utilisation. En parallèle; n'hésitez pas à parcourir ce magnifique guide, dont ce tutoriel est un bon complément, sur la mise en route de ce conteneur. Vous y trouverez notamment beaucoup plus d'informations sur la partie hébergement de sites, la configuration d'Nginx ; des thèmes que je n'aborderai pas dans le présent tutoriel. 6. Création du réseau macvlan Note : Si vous avez déjà créé un réseau macvlan, rendez-vous au paragraphe 7. Si en plus vous avez déjà créé une interface virtuelle pour la communication NAS <-> conteneur(s) en macvlan, rendez-vous au paragraphe 8. Pour créer le réseau macvlan, il faut définir une portion libre de l'adressage du réseau physique de notre LAN dans laquelle nous pourrons adresser notre (et éventuellement nos futurs) conteneurs. Cet outil est très pratique pour calculer des plages IP, je vois par exemple que si je choisis 192.168.1.144/28, je dispose d'un pool d'IP allant de 192.168.1.145 à 158, ce qui est je pense amplement suffisant, on peut passer le masque à /29 à la place de /28 pour réduire cette plage à 150 au lieu de 158. On peut également décider que ce sera notre seul conteneur en macvlan, pour réduire l'espace à une seule IP il suffit d'utiliser le masque /32. Ici pour couvrir le cas d'utilisation le plus général, on choisira le masque /29. Afin de garder une trace de la configuration du réseau, je vous conseille de créer un fichier macvlan_net.sh. On se rend dans le dossier de notre choix, par exemple chez moi j'ai un dossier networks dans mon dossier partagé docker : cd /volume1/docker/networks touch macvlan_net.sh nano macvlan_net.sh La commande nano est disponible sur vos NAS via les excellents paquets SynoCLI de Synocommunity, en l'occurence SynoCLI Files ici. On entre le script suivant : docker network create -d macvlan \ --subnet=192.168.1.0/24 \ --ip-range=192.168.1.144/29 \ --gateway=192.168.1.254 \ -o parent=eth0 \ macvlan_net On le rend exécutable et l'exécute : chmod u+x macvlan_net.sh ./macvlan_net.sh Une série de caractères s'affiche si tout s'est correctement déroulé. Notes : Pensez à utiliser sudo devant les commandes docker (valable pour toute la suite du tutoriel) si vous n'êtes pas connecté avec l'utilisateur root. ip-range correspond à la plage qu'on a choisie ci-avant. Sur le NAS, si on a activé open vswitch (automatique si par exemple on utilise Virtual Machine Manager), l'interface parente n'est plus eth0 (ou eth1, eth2, ..., ethX) mais ovs_eth0 (respectivement ovs_eth1, etc...). Pour connaître le nom de l'interface physique de sa machine (il varie suivant les machines), en SSH on peut taper : ifconfig | grep -C 3 192.168.1.100 ou ip addr | grep -C 3 192.168.1.100 Il suffit alors de repérer l'interface ayant pour adresse IP l'adresse physique du NAS (ici 192.168.1.100). On peut maintenant vérifier que le réseau existe bien en tapant : docker network ls 7. Création de l'interface virtuelle 7-A. Création du script Comme dit en introduction, il y a un inconvénient majeur à utiliser le réseau macvlan car il n'est plus possible de communiquer entre l'IP de l'hôte, 192.168.1.100 et le conteneur swag dont l'IP sera sur le réseau macvlan. Pour pallier ce défaut, on va créer une interface virtuelle, un autre chemin par lequel le NAS pourra communiquer avec le(s) conteneur(s) sur le réseau macvlan. Cette interface disparaîtra à chaque redémarrage du NAS, on créera donc une tâche planifiée pour la monter automatiquement. __________________ ATTENTION (merci @EVOTk) : L'interface disparaît également lorsque vous : arrêtez désinstallez mettez à jour le paquet Docker. Il faudra donc exécuter ce script manuellement depuis l'interface DSM si cela se produit. __________________ Toute cette procédure est explicitée dans le tutoriel introductif, mais on la reprendra pas à pas ici en personnalisant les commandes à notre besoin. On peut se placer dans un dossier interfaces dans le dossier partagé docker : cd /volume1/docker/interfaces touch mac0.sh nano mac0.sh Puis de manière similaire à ce qu'on a fait pour le script du réseau macvlan, on crée un script pour la création de l'interface : #!/bin/sh # Script permettant la communication entre # un conteneur appartenant a un reseau macvlan et son hote # A lancer au demarrage de l'hote # Temporisation #sleep 60 # Creation de l interface macvlan sur l hote ip link add mac0 link eth0 type macvlan mode bridge # Configuration de l interface avec l adresse reservee ip addr add 192.168.1.200/32 dev mac0 ip link set dev mac0 address AA:BB:CC:DD:11:45 ip link set mac0 up # On fait une route entre les IPv4 du reseau mac0 et l'interface ip route add 192.168.1.144/29 dev mac0 Notes : L'adresse 192.168.1.200/32 correspond à l'IP virtuelle du NAS, le NAS sera accessible et visible également avec cette nouvelle adresse comme avec son IP réelle 192.168.1.100. Mais a contrario de cette dernière, le conteneur peut tout à fait communiquer avec. Vous noterez la présence d'une temporisation commentée de 60 secondes. Si vous rencontrez des problèmes de création de l'interface au démarrage du NAS, n'hésitez pas à décommentez, le script sera décalé d'une minute (ce qui peut permettre d'initialiser la connexion réseau, etc...). On rend le script exécutable et on l'exécute : chmod u+x mac0.sh ./mac0.sh On vérifie maintenant que l'interface est bien active : ifconfig | grep -A 5 mac0 7-A. Création de la tâche On va maintenant créer une tâche planifiée dans DSM pour exécuter ce script à chaque redémarrage du NAS. Direction Panneau de configuration -> Tâches planifiées -> Créer -> Tâche déclenchée -> Script défini par l'utilisateur On est maintenant prêt à passer à la création du conteneur. 8. Création du conteneur 8-A. Fichier docker-compose Il ne reste plus qu'à créer le conteneur, on passera par un fichier docker-compose. La documentation très complète de Linuxserver est disponible à l'adresse : https://github.com/linuxserver/docker-swag Hypothèses : Utilisation d'un nom de domaine OVH Délivrance du certificat par DNS-01 La méthode DNS-01 implique que votre certificat sera validé au niveau de votre hébergeur de zone DNS (OVH par défaut) et non votre NAS comme avec la méthode HTTP-01. DNS-01 est obligatoire en cas de demande d'un certificat wildcard. Si vous souhaitez utiliser la méthode HTTP-01, il faudra prévoir une redirection (NAT) du port 80 de votre box vers l'IP du conteneur. Plus d'information à cette adresse : https://github.com/linuxserver/docker-swag Dans le cadre de nos hypothèses, voici l'architecture du fichier docker-compose : version: '2.1' services: swag: image: linuxserver/swag container_name: swag networks: macvlan_net: ipv4_address: 192.168.1.145 cap_add: - NET_ADMIN environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris - URL=ndd.ovh - SUBDOMAINS=wildcard - VALIDATION=dns - DNSPLUGIN=ovh - DHLEVEL=2048 - EMAIL=mail@ndd.tld - ONLY_SUBDOMAINS=false - STAGING=false volumes: - ./config:/config restart: unless-stopped networks: macvlan_net: external: true Notes : Vous remarquerez que je ne translate aucun port entre le NAS et le conteneur, pourquoi ? N'oubliez pas que ce conteneur sera une machine à part entière sur le réseau physique, dès lors elle n'a pas "d'hôte" à proprement parler. J'aurai simplement mon routeur ou mon modem qui redirigera son port public 443 vers le port 443 de l'adresse IP physique du conteneur (192.168.1.145), comme il le ferait vers n'importe quelle autre machine En amont, une translation de ports depuis le modem/routeur doit être faite pour les ports : TCP 443 pour que le proxy inversé reçoive les requêtes. TCP 80 si vous validez par HTTP-01 OU si vous souhaitez avoir une redirection HTTP -> HTTPS pour vos entrées de proxy inversé (si vous tapez exemple.ndd.tld dans votre navigateur, vous serez rediriger vers https://exemple.ndd.tld). Le PUID proposé correspond à mon utilisateur admin personnalisé, et le PGID de 100 correspond au groupe users par défaut. Vous pouvez définir un utilisateur et un groupe spécifiques qui ne possèderont des droits que sur les dossiers du conteneur. Le paramètre cap_add est utile seulement si vous souhaitez utiliser fail2ban (conseillé), car le conteneur devra modifier ses iptables (pas celles de l'hôte). Notes (2) : Si vous avez utilisé la méthode réseau bridge, il faut penser dans ce cas à faire une redirection des ports sur l'hôte, ça se traduit par l'ajout du bloc "ports" suivant (par exemple entre les blocs "environment" et "volumes") : ports: - 443:443/tcp # Ecoute proxy inverse - 80:80/tcp # Redirection HTTP vers HTTPS 8-B. API OVH Je ne m'attarderai pas sur cette partie, tout est parfaitement décrit dans le tutoriel de @oracle7 sur la génération d'un certificat wildcard par acme.sh J'ajouterai simplement une nuance sur les accès API à donner, ceux-ci me semblent plus restrictifs et préférables : GET /domain/zone/ GET: /domain/zone/ndd.ovh/ GET /domain/zone/ndd.ovh/status GET /domain/zone/ndd.ovh/record GET /domain/zone/ndd.ovh/record/* POST /domain/zone/ndd.ovh/record POST /domain/zone/ndd.ovh/refresh DELETE /domain/zone/ndd.ovh/record/* Également, on peut limiter l'utilisation de l'API à une ou des IP prédéfinies, particulièrement pratique si on dispose d'une IP fixe. En bout de chaîne vous obtiendrez 3 clés permettant un accès à l'API OVH : l'application key, l'application secret et la consumer key. 8-C. Création du fichier ovh.ini Avant la création du conteneur, on va créer en amont le fichier ovh.ini et le préremplir avec vos accès OVH obtenus ci-avant. Ainsi lorsqu'on créera le conteneur, on évitera le message d'erreur comme quoi le conteneur ne dispose pas des accès à l'API. En SSH, connecté avec de préférence l'utilisateur dont on reprendra le PUID/PGID dans les variables d'environnement du fichier docker-compose.yml, on se place dans le dossier destiné à accueillir la configuration du conteneur : cd /volume1/docker/swag Ensuite : mkdir -p config/dns-conf/ cd config/dns-conf/ curl -s https://raw.githubusercontent.com/linuxserver/docker-swag/master/root/defaults/dns-conf/ovh.ini -o ./ovh.ini On édite ensuite le fichier, avec son éditeur préféré (vim, nano, WinSCP, File Station, etc...) et on remplit les champs avec les accès API d'OVH obtenus précédemment : # Instructions: https://github.com/certbot/certbot/blob/master/certbot-dns-ovh/certbot_dns_ovh/__init__.py#L20 # Replace with your values dns_ovh_endpoint = ovh-eu dns_ovh_application_key = VALEUR_APPLICATION_KEY dns_ovh_application_secret = VALEUR_APPLICATION_SECRET dns_ovh_consumer_key = VALEUR_CONSUMER_KEY Pour éviter un message lié aux permissions laxistes du fichier, on va le chmoder : chmod 600 ovh.ini Si en revanche vous obtenez plus tard un erreur due à un des permissions insuffisantes, exécutez de nouveau la commande en remplaçant 600 par 640. 8-D. Création du conteneur Une fois le fichier ovh.ini correctement complété, on peut créer le conteneur, on se place dans le dossier où se trouve le fichier docker-compose et on écrit : docker-compose up -d On peut suivre l'évolution de l'initialisation du conteneur via : docker-compose logs --follow (CTRL+C pour arrêter le défilement des logs en direct). Ou alors via le paquet Docker de DSM ou encore Portainer (voir tutoriel). Normalement à ce stade vous disposez d'un certificat fonctionnel dans /volume1/docker/swag/config/keys/letsencrypt. Il sera tout à fait possible des copier les fichiers ou de créer des liens symboliques pour d'autres applications vers ces fichiers. 🙂 Autre possibilité, monter ce dossier en tant que volume pour un service qui nécessiterait ses propres certificats, bref ils sont à vous, faites-en ce que bon vous semble ! Passons à la configuration du proxy inversé. 9. Configuration du proxy inversé 9-A. Configuration d'une entrée Nginx est une application assez dense, et demande de comprendre les procédés à l'œuvre, le tutoriel sur la mise en place d'un VPS comme frontend de @Einsteinium entre plus en détail dans le sujet, dans notre cas, on a la chance que Linuxserver propose dans son image toute une liste d'applications grand public préconfigurées, dirigeons-nous pour cela dans le dossier suivant : cd /volume1/docker/swag/config/nginx/proxy-confs Et voyons ce qu'on y trouve : ls -l On voit tout un tas d'entrée préconfigurées, qui se classent en deux catégories : subdomain et subfolder. Le proxy inversé peut fonctionner soit en fonction du sous-domaine sollicité, soit du "path" (chemin) après le nom de domaine. Dans notre cas on s'intéressera aux entrées de type subdomain, exemple avec une entrée pour Resilio-sync : Faisons un rapide tour des directives, les champs en vert sont ceux que vous êtes a priori susceptibles de modifier : server { => on commence la définition d'une entrée du proxy inversé listen 443 ssl; et listen [::]:443 ssl; => le proxy inversé va écouter sur le port 443 les requêtes en IPv4 et IPv6 de toutes les sources disponibles. server_name resilio-sync.*; => la condition pour que le proxy inversé réagisse est que l'adresse commence par resilio-sync, exemple -> resilio-sync.ndd.ovh. include /config/nginx/ssl.conf; => à l'exécution, nginx va importer tous les paramètres définis dans le fichier ssl.conf, entre autre le chemin du certificat à utiliser, les algorithmes de chiffrement, etc... #include /config/nginx/ldap.conf; => pour ceux qui souhaitent s'authentifier au travers du proxy à partir d'un serveur d'authentification LDAP. Cette image n'embarque pas de serveur LDAP, elle permet juste de l'intégrer facilement au proxy inversé. Commenté par défaut. #include /config/nginx/authelia-server.conf; => permet d'intégrer une authentification deux facteurs ou simple facteur conditionnelle, fera l'objet d'un autre tutoriel. Cette image n'embarque pas de serveur Authelia, elle permet juste de l'intégrer facilement au proxy inversé. Commenté par défaut. location / { : on définit le comportement de Nginx pour la racine ("/") du sous-domaine. Viennent ensuite trois blocs (de la ligne 21 à 30) affiliés respectivement à une authentification http (l'explorateur demandera un identifiant et un mot de passe au chargement de la page), des paramètres liés à l'authentification par LDAP, et des paramètres liés à Authelia. On n'y touchera pas ici. include /config/nginx/proxy.conf; => Importation d'en-têtes (timeouts, transmission des IP, gestion des cookies, etc...) include /config/nginx/resolver.conf; => Le résolveur DNS utilisé sera le résolveur Docker embarqué dans chaque conteneur. La partie suivante est la partie la plus importante, elle définit comment le conteneur swag va accéder à l'application qu'on souhaite dissimuler derrière le proxy inversé. Il faut garder à l'esprit que la façon dont le conteneur accède au réseau peut être bien différente de la façon dont vous, vous accédez à vos applications par le navigateur. Dans notre cas, vu que le conteneur est sur le réseau macvlan, donc sur le réseau physique, comme la machine depuis laquelle vous tentez d'accéder à ces applications. A une différence près, si vous avez bien suivi, c'est que le conteneur ne pourra pas accéder à son hôte via son IP physique, mais seulement par son IP virtuelle, donc dans notre cas 192.168.1.200 au lieu de 192.168.1.100. Voyons la signification des trois champs : 9-A-1. $upstream_app set $upstream_app resilio-sync; Ici c'est très trompeur, ce que vous lisez là, "resilio-sync", c'est le nom du conteneur. Cette résolution par nom de conteneur, donc ici que le conteneur de nom "swag" cherche à contacter le conteneur de nom "resilio-sync" ne peut s'opérer que si les deux conteneurs se trouvent dans le même réseau. Dans notre cas, si on avait bien un conteneur resilio-sync, il serait probablement en bridge sur son hôte. Par défaut inaccessible au conteneur Let's Encrypt sauf si on a translaté le port du conteneur sur celui du NAS. Dans ce dernier cas on peut tout à fait y accéder en entrant l'adresse IP ou le nom DNS du NAS : 192.168.1.200 (rappelez-vous, IP virtuelle). 9-A-2. $upstream_port set $upstream_port 8888; Il s'agit du port tel qu'il sera accessible pour le conteneur SWAG. Si par exemple sur votre NAS vous avez un conteneur Bitwarden, que par défaut l'interface est émise sur le port 8080 dans le conteneur, mais que vous avez décalé le port pour une raison qui vous appartient, disons vers 5080, il faudra alors utiliser 5080 et pas 8080. 9-A-3. $upstream_proto set $upstream_proto http; Le protocole lié au port, souvent http (on évite de chiffrer entre le NAS et lui-même), mais parfois https (certaines applications comme Unifi-controller n'expose leur interface que via HTTPS), à vous d'adapter en fonction du besoin. 9-A-4. Récapitulatif Prenons le cas de l'application Resilio-sync qu'on aurait installé sur notre NAS, via le centre des paquets (sans Docker donc), j'utiliserai la configuration suivante : set $upstream_app 192.168.1.200; set $upstream_port 8888; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; La ligne proxy_pass construit l'URL à partir des variables précédemment définies, on n'a pas à y toucher. D'autres exemples : Moments set $upstream_app 192.168.1.200; set $upstream_port 10004; # Port personnalisé de Moments dans Portail des applications set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; Jeedom auquel j'accède via un nom de domaine local : set $upstream_app raspberrypi.local; set $upstream_port 8088; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; Mon routeur, dont l'interface émet sur le port sécurisé 8443 : set $upstream_app 192.168.1.1; set $upstream_port 8443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; Une fois toutes nos entrées configurées, on redémarre le conteneur : docker restart swag Et normalement, tout devrait être fonctionnel. 9-B. Redirection HTTP -> HTTPS Par défaut, SWAG écoute sur le port 80. Si vous souhaitez que SWAG fasse une redirection automatique 80 -> 443 pour les requêtes extérieures, il faut faire une redirection du port 80 depuis votre box vers le port 80 de l'IP (192.168.1.145) du conteneur. Si vous aviez l'habitude de faire une demande de certificat depuis DSM via HTTP-01, vous risquez d'être embêté car une seule redirection simultanée du port 80 est possible. 9-C. Validation par HTTP-01 Il se peut que votre hébergeur DNS n'ait pas d'API pour permettre une validation du certificat à son niveau, dans ce cas-là vous pourriez vouloir utiliser un certificat délivré par HTTP-01. Il faut dans ce cas-là rediriger le port 80 de votre box/routeur vers le port 80 de l'IP du conteneur 192.168.1.145 Un fichier docker-compose type pour un renouvellement HTTP-01 pourrait être le suivant : version: '2.1' services: swag: image: linuxserver/swag container_name: swag networks: macvlan_net: ipv4_address: 192.168.1.145 cap_add: - NET_ADMIN environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris - URL=ndd.ovh - SUBDOMAINS=plex,bitwarden,wordpress,dsm, # on liste les sous-domaine, attention à la virgule finale - VALIDATION=http # on remplace dns par http et on supprime la variable DNSPLUGIN - DHLEVEL=2048 - EMAIL=mail@ndd.tld - ONLY_SUBDOMAINS=false - STAGING=false volumes: - ./config:/config restart: unless-stopped networks: macvlan_net: external: true Remarque : Si notre certificat racine (ndd.ovh) est déjà géré ailleurs, mais qu'on souhaite avoir un deuxième proxy inversé sur une autre machine (un VPS par exemple) avec le même domaine, on peut passer la variable ONLY_SUBDOMAINS à true. Ainsi le certificat ne sera généré que pour les sous-domaines. 10. Fail2ban 10-A. Configuration Fail2ban est une application très pratique qu'on retrouve dans DSM, c'est le service qui permet de bannir une personne tentant de se logger plusieurs fois d'affilée de manière infructueuse à un service Synology. Ici, on va pouvoir l'appliquer à ce qu'on veut. Dans DSM c'est configurable dans l'onglet "Blocage". Il y a cependant une condition, fail2ban se base sur la lecture de logs, et en les analysant il va identifier des IP et des résultats de login : échec ou succès. La plupart des logs d'accès sont lisibles par fail2ban, car il embarque tout un set d'expressions régulières lui permettant d'analyser les logs, mais c'est un point à vérifier en amont. Fail2ban se base sur ce qu'on appelle des prisons, ou "jails" en anglais. Allons donc dans le dossier de fail2ban : cd /volume1/docker/swag/config/fail2ban && ls -l $_ filter.d comprend les fichiers de configuration permettant d'analyser et filtrer le contenu des logs en extrayant les informations utiles au moyen d'expressions régulières. action.d comprend les actions à entreprendre quand une analyse répond à un critère de filtrage. Ces dossiers comprennent un grand nombre de fichiers de configuration prédéfinis propres à tout un ensemble d'applications. Remarque : Si l'application que vous souhaitez protéger n'est pas incluse, il faudra alors créer vos propres filtres. fail2ban.sqlite3 est la base de données embarquée. jail.local est le fichier qui nous intéresse en particulier : La section [DEFAULT] définit le comportement global, il peut être écrasé au sein des sections suivantes qui définissent chaque service qu'on souhaite surveiller (maxretry, etc...). Intéressant, et qui n'apparaît pas dans l'impression d'écran, il est possible d'ajouter une directive ignoreip qui permet de whitelister des plages d'IP : ignoreip = 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 Ici je whitelist les IP pivées qui peuvent vouloir se connecter, pas de risque de me verrouiller du coup. Le fichier jail.local surveille par défaut les 4 services Nginx. On a également un bloc ssh désactivé par défaut. Pour l'activer c'est assez simple : [ssh] enabled = true port = ssh filter = sshd logpath = /log/host_ssh_auth.log Notes : port : ssh représente ici le port SSH par défaut (22), dans les faits si vous avez changé le port SSH sur votre hôte, mettez directement son numéro. filter : cela correspond au nom du fichier .conf qu'on trouvera dans le dossier filter.d, ici on appellera donc le fichier sshd.conf logpath : normalement le contenu des logs SSH se trouve dans /var/log/auth.log, pourquoi ne pas mettre ça ? Si vous écrivez /var/log/auth.log, vous allez surveiller le log d'accès SSH ... au conteneur. A priori ça ne nous intéresse pas, on cherche à lire les logs SSH de l'hôte. Pour que le conteneur y ait accès, il faut les monter via un volume. Il suffit pour cela d'éditer le fichier docker-compose.yml et d'y monter les logs de l'hôte dans un fichier à l'intérieur du conteneur, qu'on définit arbitrairement : version: '2.1' services: swag: image: linuxserver/swag container_name: swag networks: macvlan_net: ipv4_address: 192.168.1.145 cap_add: - NET_ADMIN environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris - URL=ndd.ovh - SUBDOMAINS=wildcard - VALIDATION=dns - DNSPLUGIN=ovh - DHLEVEL=2048 - EMAIL=mail@ndd.tld - ONLY_SUBDOMAINS=false - STAGING=false volumes: - ./config:/config - /var/log/auth.log:/log/host_ssh_auth.log:ro # on ajoute ro pour read-only (lecture seule) restart: unless-stopped networks: macvlan_net: external: true On recrée le conteneur : docker-compose down && docker-compose up -d On aura maintenant fail2ban qui pourra analyser les connexions SSH sur l'hôte. Quelques commandes utiles pour vérifier le bon fonctionnement des prisons : Pour renvoyer la liste des prisons : docker exec -it swag fail2ban-client status Pour afficher le statut d'une prison en particulier, ici ssh : docker exec -it swag fail2ban-client status ssh le terme swag dans les commandes précédentes correspond au nom que vous avez donné au conteneur SWAG. 10-B. Proxy fiable Par défaut, DSM empêche l'identification de l'IP source, sauf si on a précisément ajouter à la liste des proxy fiables l'IP de notre conteneur swag. Pour cela, Panneau de configuration -> Sécurité -> Proxies fiables et on ajoute l'IP du conteneur: On valide, maintenant ce sera l'IP source qui sera lue et non plus l'IP du conteneur SWAG. Ce qui revêt son importance pour fail2ban, sinon vous allez simplement bannir votre proxy inversé, ce serait bête non ? 🙂 Pour ceux qui souhaitent pousser la configuration de fail2ban plus en profondeur : https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/ https://manpages.debian.org/testing/fail2ban/jail.conf.5.en.html (très intéressant) https://github.com/linuxserver/docker-swag#using-fail2ban (commandes utiles) 11. Conclusion Ce conteneur est un package tout-en-un pour la gestion de vos certificats de vos accès externes et internes. Et il est assez facile à manipuler une fois qu'on a compris le principe. Il a surtout l'avantage de ne pas toucher au système, qu'il s'agisse de DSM ou d'une distribution Linux autre. Dans le cas de DSM particulièrement, il est possible de réaliser ce genre de manipulations car DSM utilise Nginx pour son proxy inversé, mais chaque mise à jour de paquet ou d'OS supprimera toutes vos modifications. Il existe un ancien tutoriel de @CoolRaoul pour proxy inversé sur le forum qui explorait justement une solution à ce problème, mais à l'époque le portail des applications DSM n'existait pas encore. 😉 Enfin c'est tout à fait portable, le jour où vous souhaitez héberger le proxy inversé sur un Raspberry Pi, un VPS, ou tout autre périphérique, il n'y aura qu'à copier vos fichiers de configuration d'une machine à l'autre, et faire les quelques adaptations nécessaires (adresses des services internes + redirection des ports). Màj : 22/07/2021

1. Qu'est-ce que Docker ? Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur. On ne parle pas ici de virtualisation mais de conteneurisation, une forme plus légère, qui s'appuie sur certaines parties de la machine hôte pour son fonctionnement. En effet, une machine virtuelle nécessite son propre système d'exploitation et nécessite donc une certaine quantité de mémoire dédiée, tout cela parfois dans le but de faire tourner une seule application. Synology fournit sa propre version du moteur Docker via le centre de paquets. 2. Prérequis On peut trouver la liste des modèles compatibles sur le site de Synology. 3. Pourquoi utiliser Docker sur un NAS Synology ? DSM est un système basé sur un noyau Linux, cependant c'est un système propriétaire et si certains éditeurs de logiciels font l'effort et ont les ressources pour développer un paquet adapté, force est de reconnaître que ça reste limité. SynoCommunity fournit certains paquets très utiles, mais les paquets étant maintenus sur la base du volontariat, les mises à jour sont fréquemment en retard par rapport aux versions officielles. DSM fournit une interface relativement claire et épurée pour Docker, mais limitée pour certains cas d'utilisation. Vous pouvez a priori exécuter n'importe quelle application disponible pour une distribution Linux classique. Enfin, le point le plus intéressant, le système n'est en rien affecté et aucune dépendance n'a besoin d'être installée. Corollairement, sous réserve que le paquet Docker soit implémenté correctement par Synology, les mises à jour de DSM (même majeures) ne devraient poser aucun problème de compatibilité. 4. Aller plus loin J'ai réalisé quelques autres tutoriels sur le forum qui permettent une fois les bases acquises, de mettre en place quelques outils intéressants via Dcker, que ce soit par la réflexion que ça amène ou leur finalité, souvent les deux 😉 Mise à jour automatisée de ses images et conteneurs (en cours d'adaptation pour watchtower au lieu d'ouroboros) : https://www.nas-forum.com/forum/topic/63740-tuto-mise-à-jour-automatique-des-containers-docker/ Centralisation de la gestion de plusieurs instances Docker : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ Monitoring du réseau via Telegraf - InfluxDB - Grafana : https://www.nas-forum.com/forum/topic/63273-tuto-monitoring-nas-et-réseau/ (pour le monitoring de la Freebox voir le tutoriel de @bruno78 : https://www.nas-forum.com/forum/topic/66394-tuto-monitorer-sa-freebox-revolution/) Gestion de certificat SSL et proxy inversé : https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ Mise en place du serveur d'authentification Authelia : https://www.nas-forum.com/forum/topic/71875-tuto-docker-authelia-serveur-dauthentification/ Installation de Pi-hole via réseau macvlan sur un NAS (ou tout autre périphérique) : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/ Utilisation de SMBv1 de manière sécurisée : https://www.nas-forum.com/forum/topic/72162-tuto-docker-smbv1/ Audio multiroom avec Mopidy/Iris/Snapcast : https://www.nas-forum.com/forum/topic/77063-tuto-audio-multiroom-mopidyirissnapcast/ 5. Comment utiliser Docker ? Nous verrons trois méthodes pour créer des conteneurs : Par l'interface intégrée à DSM via SSH par ligne de commande via SSH en utilisant docker-compose La première peut paraître séduisante mais on est vite limité dans nos possibilités, dans les faits l'utilisation de docker-compose (qui permet une sorte de mise en forme analytique de la ligne de commande) est un excellent compromis entre de la ligne de commande pure et dure et une interface graphique. Pour ceux qui tiennent absolument à avoir une interface graphique, il peut être intéressant de s'orienter vers Portainer, dont je propose un guide d'installation dans mon tutoriel sur la centralisation des instances Docker. 6. Installation de Docker et bonnes pratiques 6-A. Installation et mise en place de Docker Pour installer Docker, il suffit de se rendre dans le centre de paquets et de chercher Docker dans la liste des paquets tiers, on clique sur Installer. Done ! Suite à une remarque de @oracle7, assurez-vous de ne pas avoir créé de dossier partagé "docker" en amont de son installation, cela peut amener à des erreurs dûes au fait que le dossier existe déjà. Il est aussi recommandé de créer un groupe "docker" auquel on pourra ajouter des utilisateurs pour lesquels on souhaite autoriser son utilisation. Direction DSM -> Panneau de configuration -> Groupe (ou Utilisateur & Groupe sous DSM7) -> Créer groupe. On y ajoute les utilisateurs qu'on souhaite voir accéder au dossier partagé créé ci-avant. On autorise également l'accès en lecture/écriture pour ce dossier. On valide. 6-B. Recommandations Avant de commencer le tutoriel et de télécharger vos premières images, quelques recommandations : Docker Hub est un centre de dépôts où la qualité des images peut très fortement varier, dès lors à moins de ne pas avoir le choix, évitez les images qui ne fournissent aucune documentation. Parfois, la page Docker Hub d'une image ne fournit pas beaucoup d'information, vous trouverez généralement plus d'informations concernant la dite image sur GitHub (page GitHub / page DockerHub). En cas de difficulté pour créer un conteneur fonctionnel, il est toujours intéressant d'aller consulter les pages relatives au support (généralement appelé "wiki" et dont le lien est rapidement donné dans le Readme, ou la page liée aux soucis techniques sur GitHub (https://github.com/linuxserver/Heimdall/issues). Il n'est pas toujours plus simple d'utiliser la version conteneurisée d'une application que sa version native (paquet DSM ou paquet Linux classique). Si pour X ou Y raisons il existe des incompatibilités avec un NAS Synology, s'il y a des problèmes de droit d'écriture (ça représente une bonne partie des difficultés qu'on peut rencontrer avec Docker sur un NAS), si les difficultés sont trop nombreuses, si la documentation fait cruellement défaut, ou encore que l'image est à l'abandon, je vous conseille d'opter pour une machine virtuelle et réaliser une installation classique. Ou déporter l'ensemble sur un Raspberry Pi par exemple. C'est du temps gagné et des cheveux épargnés. 🙂 Pour illustrer le tutoriel j'utiliserai comme exemple Heimdall, qui est une dashboard permettant de créer des liens rapidement vers ses applications via des épingles. 7. Interface de Docker dans DSM On clique sur Docker pour arriver sur cette interface : On peut voir l'utilisation globale du processeur et de la mémoire, ainsi que l'utilisation des ressources pour chaque conteneur créé. Dans l'onglet Conteneur, on peut venir éditer nos différents conteneurs : les arrêter et les démarrer (interrupteur à droite), les modifier, les supprimer, etc... L'onglet Registre est celui qui permet de télécharger les images des applications qui nous intéressent. Ce sont les images que l'on trouve dans le dépôt publique d'images Docker, disponible ici, il peut être intéressant d'y faire un tour. L'onglet Image liste les images qu'on a téléchargées sur le NAS et la taille qu'elles occupent dans l'espace de stockage dédié : L'onglet Réseau définit les réseaux (ou interfaces) sur lesquels nos conteneurs seront actifs. L'onglet Journal est un fichier log des différentes actions réalisées (création et suppression de conteneurs, téléchargement d'images, etc...) 7-A. Chronologie La logique est la suivante : On télécharge l'image d'une application qui nous intéresse. Cette image correspond à notre application, qu'on va adapter à nos besoins en 2). On crée un conteneur basé sur cette image en personnalisant les données à notre utilisation : les variables (un login/mdp, l'utilisateur du NAS qui va exécuter l'application, un fuseau horaire, etc...), les ports (comment on y accède), les volumes (souhaite-t-on stocker des données de manière persistante? par défaut, Docker supprime les données lorsqu'un conteneur est arrêté ou supprimé), les réseaux (liés à l'accessibilité et à la communication), etc... On démarre le conteneur. 7-B. Exemple 7-B-1. Image Je reprends l'exemple de l'image linuxserver/heimdall : le terme à gauche est le nom de l'éditeur de l'image, à droite le nom de l'application. Par défaut, toutes les images qu'on peut rechercher dans l'interface Docker de DSM correspondent aux images hébergées sur Docker Hub. Il est possible d'ajouter des registres supplémentaires (GitLab et d'autres). Il suffit de cliquer sur Paramètres puis Ajouter. Dans 99% des cas Docker Hub est la seule source dont vous avez besoin. Pour notre image en question, on trouve différentes informations : Le tag latest correspond à la dernière version stable en date, development parle d'elle-même, vous pouvez également avoir des numéros de version spécifique, si vous ne souhaitez sur une version bien précise de l'image. La plupart du temps, c'est la version latest qui nous intéressera. Par convention (respectée dans l'immense majorité), si le tag n'est pas précisé, on parle de la version latest. On retourne dans l'onglet Registre, et on double-clique sur l'image une fois trouvée via le champ de recherche : On sélectionne le tag latest. L'image se télécharge, on peut voir l'avancement dans l'onglet Image, à droite la taille que l'image occupe sur votre NAS : L'image est téléchargée, on va maintenant pouvoir créer le conteneur. 7-B-2. Paramétrage du Conteneur On va donc créer notre conteneur, ce sera la version exécutée de notre image. Pour en créer un, il suffit de double-cliquer sur l'image qu'on a fini de télécharger : Un nom nous est proposé par défaut, on peut évidemment le modifier pour quelque chose de plus simple. On laisse décoché Exécuter le conteneur à l'aide de privilèges élevés car cela revient à donner un accès root au conteneur, sauf cas très précis c'est déconseillé. C'est une des rares options dans Docker qui peut compromettre l'intégrité de votre NAS si mal utilisée. Si un tutoriel demande à cocher cette option, prenez le temps de comprendre pourquoi et vous demander si c'est vraiment utile. On peut limiter la quantité de mémoire que le conteneur utilisera pour s'exécuter. On clique ensuite sur Paramètres avancés pour poursuivre la configuration du conteneur. 7-B-2-a. Conditions d'exécution En cas d'arrêt inopportun du NAS ou du paquet Docker, on peut autoriser le redémarrage automatique, suivant l'application concernée c'est généralement un paramètre intéressant, on le coche donc. On peut créer un raccourci sur le bureau si on le souhaite. D'autres comportements que le redémarrage automatique sont disponibles mais à ma connaissance, non sélectionnables via l'interface graphique Docker de DSM. 7-B-2-b. Volumes Pour utiliser une application via Docker, les données de cette application doivent bien être écrites quelque part. Précisions : Il n'est pas possible de gérer cet aspect de Docker via l'interface de DSM, uniquement en ligne de commande ou par Docker-compose. Sans aucune précision de votre part concernant l'emplacement de ces données, elles sont écrites, sur nos NAS, dans /volume1/@docker/volumes/ (à ne pas confondre avec /volume1/docker, le premier étant un dossier "caché" dans File Station (visiblement uniquement via SSH/Telnet), le deuxième visible, accessible et créé par nos soins), et sur une distribution Linux classique, /var/lib/docker/volumes/. Si l'image prévoit la création de volumes (visible dans le Dockerfile d'une image via la commande EXPOSE volume), Docker les créera, si vous les déclarez vous pourrez choisir leur emplacement, dans le dossier partagé docker ou ailleurs, si vous ne les déclarez pas, ils seront créés dans les dossiers mentionnés dans le paragraphe précédent. Dans le deuxième cas, si vous supprimez le conteneur, les données ne seront pas effacées, mais les volumes seront laissés à l'abandon (dangling en anglais), et ne seront pas réutilisés en cas de recréation ultérieure. Le plus simple est donc de les déclarer, qu'on souhaite les mettre dans un dossier accessible via File Station, ou non. On assure ainsi la persistance des données. En ce cas, trois méthodes sont possibles : On définit un volume au moment de la création du conteneur, voir ici. Ce volume ne sera pas supprimé à la suppression du conteneur, en revanche il n'est utilisable que par le conteneur en question. => Pratique pour l'essai rapide d'une application On définit un volume indépendamment d'un conteneur. Il est donc autonome des conteneurs qui l'utilisent, car en effet n'importe quel conteneur peut décider d'accéder son contenu en son sein à sa création. => Intéressant si on souhaite que plusieurs applications partagent un même volume On demande au conteneur d'utiliser des dossiers existants du NAS pour y lire ou écrire des données existantes. Ce ne sont pas des volumes Docker à proprement parler. Donc toutes les opérations disponibles via la commande docker volume ne sont pas disponibles pour ce procédé, on appelle plus généralement ces volumes des bind pour les différencier des volumes Docker. => Cette troisième solution est celle qui est le plus souvent utilisée car généralement, on souhaite que l'application qu'on déploie puisse mettre à disposition soit le contenu de dossiers déjà peuplés du NAS, soit permettre que les données générées par l'application ou envoyées vers celle-ci écrivent dans un dossier du NAS accessible par File Station Pour illustrer ce que contient un conteneur, à l'instar de tout système d'exploitation, il est tout à fait possible d'explorer l’arborescence d'un conteneur comme on le ferait pour notre NAS ou n'importe quelle autre machine. Ci-dessous, l’arborescence à la racine du NAS (à gauche) et l'arborescence du conteneur (à droite) : Reprenons les directives du créateur de l'image : On s'intéresse aux paramètres précédés d'un -v, ici on nous dit que /config (chemin dans le conteneur, que les plus observateurs auront vu dans l'arborescence du conteneur sur l'image de droite un peu plus haut) peut être monté vers le NAS si on souhaite assurer la persistance (on le veut dans ce cas, on n'a pas envie de tout reconfigurer à chaque redémarrage du conteneur). On va donc dans l'onglet Volume : Et on clique sur Ajouter un dossier. On est alors amené à choisir le dossier dans lequel on va monter /config. Lorsqu'on installe Docker sur son NAS, un dossier partagé docker est créé, libre à vous de vous organiser de la manière qui vous conviendra le mieux. Souvent, on crée un dossier par conteneur. Je choisis mon dossier et valide : Dans la colonne Chemin d'accès, je suis venu écrire manuellement le chemin absolu du dossier dans lequel je vais monter mes données. 7-B-2-c. Réseau Pour l'accessibilité du tutoriel, je ne mentionne dans cette partie que deux types de réseau : le mode bridge (défaut) et le mode host. Le fonctionnement avancé des réseaux faisant l'objet d'une description plus exhaustive en fin de tutoriel pour ceux que ça intéresse. 7-B-2-c-1. Bridge Par défaut, le mode bridge est sélectionné. Dans ce mode, lorsqu'un conteneur est créé, il obtient une adresse IP privée libre dans le sous-réseau 172.17.0.0/16. La passerelle de ce conteneur sera toujours 172.17.0.1, qui est une des nouvelles interfaces du NAS (consécutivement à l'installation de Docker). Pour s'en assurer, connectez-vous en SSH sur votre NAS et tapez : ifconfig Vous verrez une interface docker0 avec l'IP 172.17.0.1, c'est la porte vers le monde extérieur (LAN + WAN) pour tous les conteneurs dans le réseau bridge 172.17.0.0/24 : c'est l'équivalent de votre box par rapport à Internet. En mode bridge, si les ports ne sont pas translatés de la passerelle (le NAS) vers le conteneur, le conteneur n'est pas accessible depuis votre réseau local (hormis le NAS). On a un fonctionnement similaire à un routeur auquel on dit de translater certains ports vers une machine de notre réseau pour y accéder de l'extérieur. 7-B-2-c-2. host Le mode host permet lui d'exposer directement le conteneur sur le NAS, à la manière de n'importe quel paquet Synology. En gardant l'avantage de conserver les dépendances en son sein et de ne pas impacter le système d'exploitation. Il n'y a dans ce cas aucune redirection de ports à effectuer, ils sont directement joignables sur l'IP du NAS (sous réserve que le pare-feu l'autorise). Dans l'onglet Réseau, on va donc laisser tel quel pour rester en mode bridge : Si on veut passer en mode host, il faut cocher l'option Utiliser le même réseau que Docker host. On notera en dernier lieu qu'il est possible par l'intermédiaire du "+" de créer des réseaux bridge différents de celui par défaut, on appelle ça des réseaux bridge personnalisés ou définis par l'utilisateur. Les réseaux bridge personnalisés font l'objet de remarques supplémentaires en fin de tutoriel. 7-B-2-d. Ports Si on a choisi le mode bridge, Docker liste par défaut les différents ports qu'utilise le conteneur, en proposant la valeur Auto pour le port du NAS. Si vous laissez Auto, alors un port libre aléatoire sera choisi par le système. Dans l'extrême majorité des cas, on préfère définir nous même les ports à exposer, il faut simplement s'assurer qu'ils ne sont pas déjà en cours d'utilisation par un autre service en utilisant via SSH en root la commande : sudo netstat -tulpn | grep LISTEN Autrement, DSM nous préviendra au moment de la création du conteneur que le ou les ports choisis sont déjà utilisés et la création échouera. On aurait pu garder les mêmes ports que dans le conteneur, mais dans le cas présent, 80 est le port utilisé par Web Station, et 443 est utilisé par Nginx, donc j'en ai choisi d'autres qui, eux, sont libres : NDLR : Lorsque la documentation ne précise pas le protocole du transport des données par le dit port, on parle du port TCP par défaut. NOTE : Si on a choisi le mode host, on n'a pas besoin de faire de redirection de ports 7-B-2-e. Liens Les liens permettent de connecter plusieurs conteneurs entre eux, dans la partie de gauche on choisit un autre conteneur, dans la partie de droite un alias, qui permettra de personnaliser des variables d'environnement dans le conteneur lié. Cette fonctionnalité étant dépréciée, je ne m'étendrai pas plus dessus, voir le chapitre Réseau en fin de tutoriel pour une méthode alternative. 7-B-2-f. Variables d'environnement Elles permettent de personnaliser le conteneur pour notre utilisation personnelle. Dans l'image ci-dessus, elles sont identifiées par le -e, on en identifie donc trois : PUID, PGID et TZ Dans l'onglet correspondant, je crée ces trois variables en utilisant le "+" en haut à gauche du cadre : Concernant les variables PUID et PGID, elles vont permettre de définir l'utilisateur du NAS qui exécutera le conteneur. On les retrouve par exemple, mais pas seulement, dans toutes les images Linuxserver, qui est un collectif de développeurs réalisant le portage d'applications phares vers des images Docker standardisées et surtout NAS friendly. Lorsque vous cherchez une application, je vous conseille en premier lieu d'aller jeter un oeil à la liste de leur releases, les ajouts sont fréquents et les mises à jour encore plus. Pour connaître les valeurs numériques à entrer, il faut se connecter en SSH sur le NAS, et taper : id user user étant l'utilisateur qu'on souhaite employer. On obtient plusieurs valeurs, un UID >= 1026, un GID = 100 ou plus, d'autres valeurs de GID dont on ne se servira pas ici. On fait correspondre le PUID au UID et le PGID au GID. Il faut également remplir deux autres conditions pour ne pas avoir de problème de permissions d'écriture dans nos volumes : que l'utilisateur choisi a des droits suffisants dans les dossiers partagés qui seront utilisés, dans mon cas le dossier partagé docker que l'utilisateur soit idéalement propriétaire du dossier heimdall, dans lequel j'ai décidé de monter /config du conteneur. Ces conditions sont très importantes pour que tout fonctionne sans accroc. Les NAS sont généralement assez capricieux au niveau des permissions, car les dossiers sont régis par des ACL (Access Control List), ce qui correspond à l'onglet Utilisateur et Groupe dans le panneau de configuration de DSM. On rencontre beaucoup moins de problèmes sur une distrubition Linux classique. Pour TZ, c'est une variable permettant de définir le fuseau horaire à l'intérieur du conteneur, vous pouvez trouver sur cette page une liste des valeurs à entrer suivant votre localisation. 7-B-3. Création du conteneur On valide les Paramètres avancés, et on clique sur Suivant, un dernier écran propose un récapitulatif de la configuration du conteneur, on applique. On peut vérifier dans l'onglet Conteneur que le conteneur est en cours d'exécution. Il ne reste plus qu'à aller sur notre navigateur et entrer l'adresse du NAS suivi du port HTTP qu'on a translaté depuis le conteneur vers le NAS : Et pour la version HTTPS : 7-B-4. Aperçu et Logs du conteneur Dans notre cas c'est merveilleux tout marche bien, mais il faut savoir que toutes les images ne sont pas aussi bien documentées, et qu'on n'est jamais à l'abri d'une erreur. Dans l'onglet Conteneur, si on en sélectionne un et qu'on clique sur Détail, on peut avoir un aperçu des statistiques du conteneur, et surtout les logs du conteneur dans l'onglet Journal, c'est la première chose à regarder en cas de conteneur non fonctionnel (accès impossible, redémarrage en boucle, etc...). ________________________________________ Ceci conclut la partie destinée à l'interface Docker de DSM, elle conviendra pour la majorité de vos besoins mais peut clairement révéler des insuffisances dans des cas plus poussés. 8. Docker via SSH 8-A. Analyse Un des principaux problèmes qu'on peut rencontrer avec l'interface de DSM c'est l'impossibilité de choisir des dossiers sur le NAS en dehors de /volume1, or Docker s'appuyant sur le système d'exploitation de l'hôte, il peut avoir besoin d'accéder à ses ressources. il est possible de contourner ce problème avec l'interface DSM de Docker via des liens symboliques (symlink) mais je trouve ça plus personnellement plus compliqué qu'un bête script. Par chance, pour les images comportant peu d'infos, il y a souvent a minima le script de démarrage du conteneur, exemple avec l'image utilisée ci-avant : On comprend assez vite la correspondance entre ce qu'on a fait précédemment et ce qu'on lit ici, quelques remarques tout de même : les \ permettent d'effectuer un retour à la ligne et de rendre le script présentable, il est tout à fait possible d'écrire tout à la suite. si j'écris -p 8080:80, je demande de faire correspondre le port 8080 de l'hôte avec le port 80 du conteneur, l'ordre est donc primordial. de la même manière qu'on peut mapper les ports, on peut mapper les volumes : /volume1/docker/heimdall est ici mon dossier sur le NAS, /config mon dossier dans le conteneur, j'écrirai donc ça : -v /volume1/docker/heimdall:/config on voit qu'ici il est possible de définir un autre type de comportement pour le redémarrage (celui qu'on avait validé dans l'interface correspondant à --restart always), ici on empêche le redémarrage automatique si le conteneur a été stoppé correctement. la dernière ligne reprend le nom de l'image, si aucun tag n'est précisé alors latest est implicite. il n'est pas nécessaire de télécharger l'image au préalable, au lancement du script il va aller chercher la version la plus récente du tag demandé, la re-télécharger si l'image est obsolète et enchaîner sur la création du conteneur. il faut ajouter sudo en début de commande si on n'est pas connecté en root au terminal. Cette commande permet de créer le conteneur, on doit ensuite taper : docker start heimdall pour exécuter le conteneur (pensez à ajouter sudo aux commandes docker si vous n'êtes pas connecté en root). 8-B. En détail Voyons plus en détail les possibilités pour chaque paramètre. Lorsqu'un paramètre n'est pas précisé lors de la création du conteneur, Docker regarde dans son démon, à savoir un fichier qui contient des directives à utiliser par défaut sans précision contradictoire de la part de l'utilisateur. Ce fichier se trouve à l'emplacement : /var/packages/Docker/etc/dockerd.json 8-B-1. Restart policies L'argument restart permet de définir le comportement de redémarrage du conteneur : --restart=no : C'est le comportement par défaut, le conteneur ne redémarrera pas s'il s'arrête, que ce soit proprement ou à cause d'une erreur. --restart=always : A contrario, le conteneur tente continuellement d'être redémarré, sauf s'il a été stoppé manuellement. Par contre, en cas de redémarrage du service Docker ou du NAS, le conteneur sera redémarré. --restart=unless-stopped : En cas d'erreur, le conteneur tentera de redémarrer indéfiniment. S'il est arrête manuellement, le conteneur ne sera pas relancé. En cas de redémarrage du service Docker ou du NAS, le conteneur ne sera pas redémarré. --restart=on-failure[:4] : Le conteneur ne sera redémarré qu'en cas d'arrêt pour cause d'erreur, et ce par exemple ici dans une limite de quatre fois. 8-B-2. Network L'argument network permet de définir la connectivité d'un conteneur par rapport à son environnement : --network=none : le conteneur est totalement isolé et autonome, le seul moyen d'y accéder est par terminal. --network=my-network : permet de se connecter à un réseau bridge personnalisé ou macvlan nommé my-network. Si on ne précise rien, le conteneur rejoint le réseau bridge par défaut (voir 7-B-2-c-1). 8-B-3. Ports La gestion des ports permet de rendre une application dans un conteneur accessible sur son hôte via des ports spécifiques. C'est indispensable si on souhaite accéder à un conteneur sur un réseau bridge. Un conteneur sur réseau macvlan a tous ses ports exposés sur sa propre IP, il est comme une machine à part entière sur le réseau, tous ses ports sont accessibles sur le réseau sur lequel il se trouve. 8-B-3-a. Interfaces Pour translater un port, on désigne le port sur lequel l'application est exposée dans le conteneur ainsi que le port sur l'hôte par lequel on accède à cette application. Par exemple : -p 8080:80 L'application disponible sur le port 80 dans le conteneur est translatée sur le port 8080 de l'hôte. -p 0.0.0.0:8080:80 Écrire 8080:80 revient à écrire 0.0.0.0:8080:80 0.0.0.0:8080 signifie l'application est disponible sur le port 8080 de l'hôte sur toutes ses interfaces. Que ce soit localhost (127.0.0.1 => seul l'hôte peut y accéder), l'IP local (par exemple 192.168.0.10), l'IP passerelle bridge 172.17.0.1 ou encore l'IP VPN. Je voudrais par exemple pouvoir vouloir n'accéder à une application que lorsque la requête arrive sur l'IP VPN de l'hôte : -p 10.0.8.1:8080:80 http://10.0.8.1:8080 aboutira, alors que 192.168.0.10:8080 ne donnera rien. 8-B-3-b. Protocoles Si on souhaite autoriser uniquement un protocole, il suffit de le préciser à la fin de l'argument : -p 8080:80/tcp -p 1194:1194/udp 8-B-4. Commandes utiles Assez intuitivement, pour arrêter le conteneur on tape : docker stop heimdall Pour supprimer le conteneur : docker rm heimdall Pour voir la liste des conteneurs actifs, on écrit la commande : docker ps Pour voir les logs d'un conteneur en direct, on écrit (CTRL+C pour arrêter la visualisation) : docker logs -f heimdall Pour gérer les réseaux, reportez-vous à l'aide via la commande : docker network --help Enfin, ça peut être parfois très utile, il est possible de se connecter à l'intérieur d'un conteneur, pour cela : docker exec -it heimdall bash Notes : En général, le paquet bash est présent dans la plupart des images que vous utiliserez. Parfois, si bash ne fonctionne pas, essayez ash. Si bash n'est pas disponible, rien ne vous empêche de taper directement la commande qui vous intéresse, par exemple : docker exec -it heimdall ls -la /etc Pour sortir du conteneur, tapez exit. A vous d'explorer l'ensemble des commandes à votre disposition en consultant le manuel d'aide : docker --help En dernier lieu, je vous invite à parcourir la documentation de Docker, bien que touffue elle est extrêmement claire : https://docs.docker.com/ Comme je disais au début du chapitre, le gros avantage de cette méthode est qu'elle permet de définir des chemins absolus hors /volume1 pour nos volumes. Rien ne m'empêcherait d'aller mapper /var/lib/temperature pour un dossier quelconque du conteneur. Cette possibilité est particulièrement utile quand une application va devoir utiliser le cœur de docker, le fichier /var/run/docker.sock. Ce fichier est particulièrement important, car à partir du moment où on le mappe en tant que volume vers un conteneur, on peut prendre le contrôle de Docker avec cette application. Typiquement, Portainer est une interface graphique à la manière de l'interface Docker de DSM pour gérer ses conteneurs, ses images, et toutes les infos exploitables (mais en mieux 😛). Avertissement !! A partir du moment où vous donnez accès à d'autres dossiers que ceux dans /volume1, le conteneur sera nécessairement lancé avec l'utilsateur root du NAS, car seul lui a accès à cette partie du système. Soyez donc attentifs aux nécessaires précautions que cela implique. 9. Docker-compose via SSH Docker-compose vient compenser les lacunes de la création de conteneur par Docker, dont voici un exemple : Les points forts de docker-compose sont : - écriture analytique, plus lisible qu'un script - possède beaucoup plus de fonctionnalités (dont on n'aborde ici qu'une infime partie) - possibilité de définir plus applications (appelés services) au sein d'un même fichier Dans un fichier docker-compose.yml, on peut définir 3 types d'objets : - des services : ce sont les applications en elles-mêmes - des volumes : ce sont des dossiers dans lesquels on va pouvoir écrire des données de manière persistante - des réseaux (networks) : ils définissent la manière dont sont exposés les conteneurs Il suffit de placer ce fichier dans un dossier, d'en faire le répertoire de travail dans son terminal, et de taper : docker-compose up -d Si je souhaite supprimer les conteneurs (et les éventuels réseaux définis dans le fichier), il me suffit de taper : docker-compose down Ça a également l'avantage de garder la configuration du conteneur au sein d'un fichier. Ce fichier docker-compose.yml peut être créé par Notepad++ sous Windows, ou via l'éditeur de texte sous Linux. Attention !! le fichier ne doit pas contenir de tabulation, tous les décalages sont réalisés à partir d'espace !! Plus d'infos sur Docker-compose à cette page. 10. Quelques autres commandes utiles docker stats Affiche les ressources utilisées par vos conteneurs, se rafraîchit constamment. docker network inspect <nom_du_réseau> Permet d'avoir toutes les informations relatives à un réseau donné. docker rmi <nom_image> Permet de supprimer l'image avec le nom spécifié. 11. Informations complémentaires 11-A. Réseaux Le mode bridge par défaut (c'est-à-dire si on utilise le driver bridge, et qu'on ne rattache le conteneur à aucun réseau bridge particulier) n'est pas idéal si l'on souhaite isoler les conteneurs les uns des autres. Tous les conteneurs appartenant au réseau bridge par défaut peuvent communiquer les uns avec les autres par leur IP, et se situent sur un même sous-réseau (par exemple 172.17.0.0). Si on souhaite s'affranchir des adresses IP (qui peuvent changer entre chaque création et suppression de conteneur) et utiliser plutôt le nom du conteneur pour communiquer avec, il existe deux méthodes : Les liens (évoqués plus avant) : c'est une fonctionnalité officiellement dépréciée dans les nouvelles versions de Docker, elle est cependant présente dans l'inteface Docker de DSM, dans l'onglet Lien lorsqu'on crée ou modifie un conteneur. En précisant le nom d'un autre conteneur, on autorise la communication notre conteneur en devenir et celui-ci. Les réseaux bridge définis par l'utilisateur : la commande docker network permet de gérer les réseaux docker et donc d'en créer de nouveaux. Lorsqu'on crée un réseau bridge, celui-ci aura la propriété intrinsèque que tous les conteneurs qui y sont connectés pourront communiquer entre eux via leurs noms de conteneur. Le réseau 172.17.0.0/24 étant réservé au réseau bridge par défaut, le premier réseau disponible est le 172.18.0.0/24, et ce jusqu'à 172.32.0.0/24. Un réseau de type bridge créé dans l'interface Docker de DSM est un réseau de cette catégorie. 11-A-1. Création du réseau macvlan Il existe un autre type de réseau appelé macvlan : il permet de donner une IP sur le réseau physique à un conteneur, donc par exemple 192.168.0.0/24, et sera donc directement accessible par les autres périphériques de votre réseau local. Merci à @bruno78 pour son apport sur ce sujet en particulier, la suite est très largement inspirée de ses commentaires, et @Didier3L dont les questions ont permis de défricher le terrain. Ce driver possède de gros avantages et un gros défaut : Si le conteneur a une IP sur le réseau physique, elle est directement accessible via tous ses ports. C'est excessivement pratique si certaines applications de l'hôte, ici le NAS, utilisent déjà certains ports : 80, 443, 53, etc... Prenez l'exemple parlant de Pihole, ce dernier utilise le port 80 pour plusieurs tâches, ainsi que le port 53 qui est le port DNS non sécurisé. Si vous utilisez le paquet DNS Server du NAS, le port 53 est déjà en écoute, pareil avec le port 80 si Webstation est exécuté. Nous avons précédemment vu qu'il était possible de translater, sauf que certains ports comme le port 53 ne sont pas réellement déplaçables sur un autre port. Je n'ai donc aucune redirection à faire, j'accéderai à mon application via par exemple 192.168.0.101:80, tout simplement, sans me soucier de ce que le NAS utilise. Attention cependant, en macvlan, l'hôte ne peut plus communiquer, via son interface physique, avec le conteneur !! Ce n'est pas gênant dans le cas du contrôleur Unifi d'Ubiquity, mais beaucoup plus dans le cas de Pihole par exemple. Pour créer un réseau macvlan, on peut le créer de manière externe, via docker network via ligne de commande ou de manière interne lors de l'écriture d'un script ou dans un fichier docker-compose. Dans ce cas, on va créer le réseau macvlan toto de façon externe : docker network create -d macvlan \ --subnet=192.168.0.0/24 \ --ip-range=192.168.0.144/28 \ --gateway=192.168.0.254 \ -o parent=ovs_eth0 \ toto Notes : (les valeurs sont données à titre d'exemple évidemment) - subnet => on choisit le sous-réseau physique, celui de nos machines. - ip-range => on va définir la plage d'IP couverte par le réseau, un calculateur d'IP sera d'une grande aide pour définir le nombre d'IP qu'on réserve et ajuster à notre besoin. Important !! Il est fortement recommandé que la plage d'IP couverte par le serveur DHCP de votre réseau soit dissociée de la plage d'IP allouée au réseau macvlan. - gateway => c'est notre passerelle, vu qu'on est sur le réseau physique c'est généralement votre box ou votre routeur. - parent => c'est le nom de l'interface physique (tapez ifconfig pour vérifier) On valide et notre réseau est créé. Maintenant, il reste un problème à résoudre ; comme évoqué plus haut, tout conteneur dans ce réseau ne sera pas joignable par l'hôte, quelque soit le protocole (ICMP, TCP, UDP, HTTP, etc...) 11-A-2. Création de l'interface virtuelle Une solution existe toutefois, il suffit de créer une nouvelle interface sur le NAS, une interface virtuelle, par lequel il sera aussi normalement accessible que par son interface physique. Pour illustrer, si j'accède à DSM via 192.168.0.100:5000 en temps normal, je pourrai depuis un conteneur sur le réseau macvlan y accéder via l'adresse 192.168.0.200:5000 Le conteneur pourra donc communiquer avec le NAS via cette nouvelle interface. Pour cela, il suffit de taper quelques lignes de commande en SSH : ip link add <nom_interface_macvlan> link <interface_physique> type macvlan mode bridge ip addr add <IP_virtuelle>/32 dev <nom_interface_macvlan> ip link set dev <nom_interface_macvlan> address <adresse_MAC> ip link set <nom_interface_macvlan> up ip route add <Plage_DHCP_réseau_macvlan> dev <nom_interface_macvlan> Si on veut faire correspondre à l'exemple du réseau ci-dessus : - <nom_interface_macvlan> => un nom au hasard, pas de caractères spéciaux, macvlan_int par exemple, peu importe - <interface_physique> => ovs_eth0 - <IP_virtuelle> => on avait choisi arbitrairement l'adresse 192.168.0.140, on vérifie que cette IP n'est pas dans la plage couverte par le réseau macvlan toto - <adresse MAC> => on peut définir une adresse MAC pour notre interface - <Plage_DHCP_réseau_macvlan> => ça correspond à --ip-range dans le script plus haut Vous devriez maintenant avoir maintenant une nouvelle interface visible en tapant ifconfig en SSH. Vous verrez également cette interface sur l'assistant Synology par exemple. Si vous tentez un ping depuis votre NAS vers un conteneur sur le réseau macvlan, cela devrait marcher. Inconvénient majeur : Au reboot, l'interface sera supprimée et le code précédent devra être réintroduit. Pour éviter cela, on peut créer une tâche dans le planificateur de tâches, à exécuter au démarrage du NAS, qui exécute un script comprenant toutes les commandes ci-dessus (celles commençant par IP). On peut également ajouter un sleep 60 pour temporiser 60 secondes avant l'exécution du script, on s'assure ainsi que la machine a bien démarré avant toute chose. MàJ : 08/07/2023

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

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

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

1. Préambule Ce tutoriel a pour but d'autoriser l'accès aux données du NAS via le protocole SMBv1 (ou NT1) sans pour autant impacter le niveau de sécurité d'accès au NAS. Cela permet d'assurer la compatibilité d'équipement qui n'auraient pas été mis à jour par leur fabricant. SMBv1 est un protocole déprécié et comportant des failles de sécurité. Lorsqu'il est possible de vous en passer, faites-le. 2. Prérequis Avoir un NAS compatible Docker, voir la liste ici. Savoir se connecter au NAS via SSH en root : Utiliser Docker-compose Avoir installé le paquet SynoCLI File Tools, pour ajouter le dépôt SynoCommunity voir la partie Easy Install sur cette page. IMPORTANT : Si vous souhaitez accéder aux dossiers partagés "music", "video", etc... à la racine tels quels, ça ne pourra pas fonctionner, il faudra monter des sous-dossiers de ces dossiers partagés. Autant prévenir de suite. 3. Principe Afin de ne pas devoir réduire drastiquement le niveau de sécurité du NAS en autorisant le protocole SMBv1, on va passer par un conteneur qui va monter uniquement les fichiers du NAS dont on a besoin, et qui lui, autorisera l'accès en SMBv1. Comme le NAS utilise déjà le port 445 pour parler SMB avec les autres périphériques du réseau, il n'est pas disponible, on va donc utiliser un réseau macvlan (voir point 11-A de mon tutoriel introductif à Docker). Ce réseau permet entre autre d'attribuer au conteneur une IP située sur le même sous-réseau que votre réseau local. En somme, il devient accessible comme n'importe quelle autre machine, avec une IP par exemple du 192.168.0.x. Comme il est fréquent de faire avec des machines virtuelles. Cela permet notamment d'utiliser des ports déjà utilisés sur le NAS, et facilite la détection par les autres appareils, car visible directement par tout le réseau. 4. Mise en place du réseau macvlan Je ne détaille pas cette étape, car elle est décrite avec précision au point 11-A-1 du tutoriel introductif. A noter dans ce tutoriel précis qu'il n'est pas nécessaire de mettre en application le point 11-A-2 qui s'attarde sur la création d'une interface virtuelle pour communiquer entre le NAS et le conteneur. Si vous avez déjà un réseau macvlan disponible, assurez-vous simplement de disposer d'une IP libre dans la plage utilisée. Et adaptez les hypothèses suivantes. 5. Hypothèses Je vais me baser sur la plage et le sous-réseau utilisés dans le tutoriel introductif : IP hôte (NAS) : 192.168.0.100 Passerelle : 192.168.0.1 Sous-réseau local : 192.168.0.0/24 (ou encore écrit 192.168.0.0/255.255.255.0) Plage macvlan : 192.168.0.144/28 (vous pouvez vérifier les IP que ça concerne ici : http://jodies.de/ipcalc) IP conteneur : 192.168.0.145 Les valeurs en orange sont directement héritées de la mise en place du réseau macvlan, et sont simplement répétées par rapport au tutoriel introductif dans un souci de contextualisation. Les valeurs en vert sont propres à votre installation et ce tutoriel. 6. Configuration 6-A. Fichier docker-compose On va créer le fichier docker-compose.yml qui va reprendre toute la configuration de notre conteneur. On va utiliser l'image servercontainers/samba. Elle met à disposition un serveur Samba entièrement configurable, accompagné d'Avahi et WSD pour qu'il s'annonce sur le réseau et le rendre consultable et visible dans Finder (Mac) et l'explorateur Windows. Il faut savoir que cette image a été améliorée suite à des propositions que j'ai faites à son créateur. Elle a été adaptée pour faciliter la compatibilité avec DSM et sa version particulière de Linux. Tout d'abord, on se connecte en SSH en root, puis on crée le dossier qui va contenir la configuration du conteneur mkdir -p /volume1/docker/samba/ && cd $_ mkdir conf On va ensuite créer le fichier docker-compose.yml en utilisant nano (ou le télécharger ici : docker-compose.yml et l'importer dans File Station au bon endroit). nano docker-compose.yml dont voici un modèle : version: '2.1' services: samba-nt1: image: servercontainers/samba container_name: samba-nt1 hostname: samba-nt1 networks: mac0: ipv4_address: 192.168.0.145 environment: ## Groups ## - GROUP_users=100 ## Accounts ## - ACCOUNT_media=motdepassemedia - UID_media=10XX - GROUPS_media=users ## Global variables ## - SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol=NT1 - SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth=ntlmv1-permitted - SAMBA_CONF_MAP_TO_GUEST=Never ## Shares ## - SAMBA_VOLUME_CONFIG_music=[music]; path=/shares/music; guest ok = no; read only = yes; browseable = yes; valid users = media; force group = users volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/docker/samba/conf:/etc/samba restart: unless-stopped networks: mac0: external: true 6-B. Personnalisation des paramètres 6-B-1. Général Dans un fichier docker-compose, il n'y a pas de tabulation, uniquement des espaces, et il est important de respecter l'indentation (l'alignement). Les sauts de lignes ou le nombre d'espaces que vous mettez pour décaler les items n'a en revanche aucun impact, assurez-vous juste que ce soit lisible. hostname : cette variable est importante ici car c'est le nom que vous verrez apparaître dans la découverte de réseau de Windows. Cette chaine de caractères est automatiquement convertie en majuscules sous Windows, évitez les caractères exotiques. ipv4_address : c'est l'adresse IP que j'attribue manuellement au conteneur, c'est la première disponible dans la plage que j'ai choisie pour mon réseau macvlan nommé mac0. GROUP_users : On va définir au sein du conteneur un group "users", celui-ci correspond au groupe auquel appartient naturellement votre/vos utilisateur(s) du NAS. On lui donne la valeur de 100 car c'est le gid du groupe users sur DSM également. Si pour une raison ou un autre vous utilisez un groupe personnalisé, vous devez déterminer le GID affilié à ce groupe. Pour cela, tapez en SSH : cat /etc/group | grep nom_du_groupe Il faudra utiliser le nombre à la fin de la ligne en sortie de commande. ACCOUNT_media, UID_media et GROUPS_media : Voir paragraphe 6-B-3. SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol : En lui donnant une valeur NT1 on autorise SMBv1 comme protocole minimal, depuis Samba 4.x le protocole minimal est SMB2. NT1 est le nom officiel de SMBv1. SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth : Il faut également autoriser l'authentification NT1. SAMBA_CONF_MAP_TO_GUEST : On ne souhaite pas que les utilisateurs soient automatiquement redirigés sur guest en cas de mauvais nom d'utilisateur ou de mot de passe. Donc on désactive la directive. SAMBA_VOLUME_CONFIG_music : voir 6-B-4. volumes : voir 6-B-2. restart: unless-stopped : Le conteneur redémarre quand il s'arrête suite à une erreur, si le service Docker ou le NAS redémarrent. Sauf si on l'a arrêté manuellement. networks : Je dois définir la nature du réseau mac0 invoqué plus haut pour le paramètre ipv4_address. Il a été créé extérieurement au conteneur, ce que je précise par le paramètre external: true. 6-B-2. Volumes Pour revenir au point abordé dans les pré-requis, et sans rentrer dans les détails, l'utilisation de cette image avec DSM possède quelques limitations : Il n'est pas possible de monter directement un dossier partagé à la racine : par exemple dans mon fichier docker-compose, je monte /volume1/music/bibliotheque et pas /volume1/music dans /shares/music. Cela vient des permissions UNIX qui sont inexistantes au niveau des dossiers partagés du point de vue de l'utilisateur root, c'est la surcouche d'ACL qui gère les permissions. Par conséquent, les permissions UNIX doivent être suffisantes pour garantir un fonctionnement adéquat. Prenons un exemple : ls -l /volume1/music Les permissions UNIX pour le dossier "bibliotheque" par exemple sont définies par les caractères qui se situent à gauche du "+" : drwxr-xr-x. Cas d'utilisation : Pour traverser les dossiers et lire en lecture seule avec un utilisateur authentifié, il faut a minima : dr-x------ pour un dossier (-r-x------ pour un fichier). Pour traverser les dossiers et lire/écrire avec un utilisateur authentifié, il faut a minima : drwx------ pour un dossier (-rwx------ pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire en lecture seule avec un utilisateur guest (non authentifié), il faut a minima : d------r-x pour un dossier (-------r-x pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire/écrire avec un utilisateur guest (non authentifié), il faut a minima : d------rwx pour un dossier (-------rwx pour un fichier). Je ne recommande pas les deux derniers cas d'utilisation, car SMBv1 est un protocole déprécié et ayant des failles de sécurité. Or SMB de manière générale est sûrement le moyen le plus simple d'infecter un NAS. Néanmoins, cela peut avoir son utilité par exemple pour des imprimantes d'ancienne génération, qui stocke des éléments scannés dans un répertoire du NAS via SMBv1. L'utilisation d'un guest doit rester exceptionnelle. NOTE : Avoir d------rwx n'implique pas qu'un guest aura forcément accès aux données du partage, on peut tout à fait désactiver l'accès guest par la configuration du partage (voir point 6-B-4), limiter l'accès à certains partages à certains utilisateurs uniquement, etc... c'est simplement une condition nécessaire, mais non suffisante. En revanche, si vous n'avez pas ces permissions a minima, activer le guest n'aura aucun effet. Voilà un type de montage qu'on pourrait vouloir faire : volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/video/films:/shares/films - /volume1/video/series:/shares/series - /volume1/famille/documents:/shares/documents On doit aussi s'assurer d'avoir monté le dossier dans lequel se trouvera le fichier de configuration smb.conf créé par le conteneur lors de sa mise en route : - /volume1/docker/samba/conf:/etc/samba 6-B-3. Utilisateur Pour faciliter le bon fonctionnement du conteneur, il est recommandé de créer des utilisateurs dont le nom existe déjà dans DSM. Dans mon cas, j'ai un utilisateur media qui est propriétaire de tous les fichiers multimédias (musique et vidéo). ls -l /volume1/music/bibliotheque Au sein d'un même partage (par exemple le contenu musical), il est recommandé qu'un seul et même utilisateur soit propriétaire de tous les fichiers. Ca ne changera rien dans DSM car le système a sa propre couche d'ACL qui détermine les permissions de chacun, et ça facilitera l'exploitation du conteneur. Pour unifier le propriétaire d'un ensemble de fichiers et dossiers, c'est très simple, on va dans File Station, on sélectionne les éléments dont on souhaite changer la propriété, clic droit, Propriétés. En bas de la fenêtre, on choisit le propriétaire. Si on a sélectionné un dossier, on peut cocher la case "Appliquer à ce dossier, ses sous-dossiers et ses fichiers" pour que les enfants héritent du même propriétaire. NOTE : Si vous sélectionnez à la fois des dossiers et des fichiers, il se peut que le cadre Propriétaire n'apparaisse pas. Limitez votre sélection et ça marchera. Je vais donc créer un utilisateur media dans le conteneur via la variable d'environnement : ACCOUNT_media. La valeur de cette variable est le mot de passe pour l'utilisateur media dans ce conteneur. NOTE : Ce mot de passe ne doit pas être le même que celui pour l'utilisateur media du NAS ! En effet, le conteneur aura ses propres accès. La documentation de cette image permet de chiffrer ce mot de passe, pour ma part je n'en vois pas l'intérêt. Car pour accéder à ce fichier, l'utilisateur doit déjà avoir infecté le NAS. Cacher ses clés dans la maison n'a pas d'intérêt s'il y a déjà effraction. Concernant la variable UID_media, il s'agit de l'ID de l'utilisateur. Il est pratique d'utiliser le même UID que celui de l'utilisateur du NAS. Pour récupérer cet UID, il suffit de taper en SSH : id media Dans mon cas c'est 1035, dans tous les cas c'est strictement supérieur à 1025. Enfin, pour GROUPS_media, on lui donne la valeur users, par défaut l'utilisateur appartient à un groupe identique à son nom d'utilisateur. Pour DSM, le groupe users est le groupe par défaut pour les utilisateurs. On s'assure une meilleure compatibilité avec les ACL. Au final, en configurant ces trois variables, on assure la création d'un utilisateur qui pourra se servir des droits utilisateurs accordés par les permissions UNIX et ne fâchera pas les ACL de DSM. REMARQUE : Il est tout à fait possible de créer plusieurs utilisateurs, par exemple si vous décidez de monter l'espace personnel d'un utilisateur du NAS, ou simplement parce que tous les fichiers de vos partages n'appartiennent pas à un seul et même utilisateur. Exemple : - ACCOUNT_media=motdepassemedia - UID_media=1035 - GROUPS_media=users - ACCOUNT_lolita=motdepasselolita - UID_lolita=1031 - GROUPS_lolita=users 6-B-4. Configuration des partages La configuration des partages se fait via la variable d'environnement SAMBA_VOLUME_CONFIG_music (pour un partage qui se nommerait "music"). La valeur associée peut paraître étrange avec ses points virgule, mais ça représente juste un saut de ligne dans ce qui correspond habituellement à la configuration d'un partage SMB. Voyons plus en détail : path=/shares/music : correspond à l'emplacement qu'on a indiqué dans le montage de volume, c'est le chemin DANS le conteneur. [music] : c'est le nom du partage tel que vous le verrez dans votre explorateur. Vous pouvez utiliser des majuscules et des espaces ici. guest ok : prend la valeur "yes" ou "no", dans le premier cas lorsque vous vous connecterez aucun mot de passe ne vous sera demandé. Valeur recommandée : no. read only : est assez explicite, prend la valeur "yes" ou "no". En SMBv1, préférez la lecture seule. browseable : permet de voir apparaître le partage dans les onglets de découverte du réseau. valid users : permet de définir quel(s) utilisateur(s) sont autorisés à accéder au partage. Pour ajouter plusieurs utilisateurs, les séparer par une virgule. Si tous les utilisateurs peuvent accéder au partage, il n'est pas nécessaire d'utiliser cette directive. force group : Par défaut, ce sera l'utilisateur media/media qui écrira quand on est connecté avec cet utilisateur, on souhaite que le groupe par défaut soit users, d'où la valeur forcée à "users" pour ce paramètre. Autres directives majeures disponibles : comment : permet de décrire notre partage, majuscules autorisées. directory mask : permet de définir quelles seront les permissions UNIX par défaut lors de la création d'un dossier. Exemple : create directory mask = 0755 => les dossiers auront les permissions suivantes : drwxr-xr-x. Voir la page Wikipédia (Fonctionnement - Représentation des droits) pour plus d'information : https://fr.wikipedia.org/wiki/Permissions_UNIX create mask : même chose pour un fichier. guest only : nécessite d'avoir réglé guest ok sur "yes" au préalable. Accès guest seulement (pas d'authentification). Il existe énormément de paramètres configurables pour un partage SMB, voir la liste ici : https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html Tout est maintenant configuré. On n'a plus qu'à sauvegarder le fichier docker-compose (sous nano, CTRL+O puis Entrée pour sauvegarder, CTRL+X pour sortir de l'éditeur). 7. Création du conteneur Pour créer le conteneur, on vérifie qu'on se trouve toujours dans /volume1/docker/samba et on tape : docker-compose pull Ce qui va télécharger la dernière version de l'image. Puis : docker-compose up -d Si pas d'erreur à la création (souvent dues à des caractères de tabulation, une directive dans le fichier docker-compose mal orthographiée ou désalignée, etc...), vous verrez un petit done apparaître en vert. Si browseable a été activé, on voit le partage dans la découverte réseau : Tous les autres moyens habituels pour accéder à un partage SMB sont actifs (connecter un lecteur lecteur réseau, smb:// via Finder, etc...). MàJ : 13/01/2022

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 !

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 !

Hello ! Après une dizaine de jours d'utilisation, quelques retours : - venant d'un RT2600AC, je n'ai pas été trop perdu 🙂 Néanmoins j'ai trouvé dommage que les fichiers de backup du RT2600AC et de ses paquets ne puissent pas être importés. Le fichiers de configuration principal n'est pas compatible avec le RT6600AX et les fichiers de sauvegarde de Safe Acess et Threat Prevention n'ont jamais pu être restaurés. - le stockage sur SD manque un peu et j'ai eu peur que le seul port USB3 présent soit un peu limite : le palliatif a été d'utiliser un petit hub USB me permettant d'accueillir ma clé USB et ma clé 4G - l'interface est très réactive et le boot du routeur est bien plus rapide que sur le RT2600AC - j'ai utilisé le port 2.5 Gbps en port WAN principal pour ma freebox pop : la synchro sur ce débit se fait bien et est bien remontée par la freebox. - j'ai eu la chance d'obtenir un 2e RT6600AX grâce à mon taf (merci patron) puis un 3e sur le bon coin (!!??) et j'ai été en mesure de tester les fonctionnalités mesh : bien que l'interface indique que c'est possible, je n'ai pas été en mesure d'aller au bout d'un ajout de point d'accès en filaire. J'ai du à chaque fois réaliser l'ajout d'un PA en wifi et ensuite brancher le câble comme au tout début sur le RT2600AC avec le MR2200AC (à l'ancienne quoi). - je trouve qu'il ont fait un sacré boulot d'ergonomie sur la mise en œuvre et la présentation de la segmentation des réseaux (aka les fameux VLAN de SRM 1.3). C'est vraiment intuitif et une fois un sous-réseau créé, on peut lui affecter un port et/ou un SSID Wifi spécifique, de sorte que les périphériques connectés à ce SSID ou ce port se rattachent automatiquement à ce VLAN (plage d'IP spécifique, isolation possible des autres périphériques et réseaux). - une fois qu'on introduit les VLAN sur son architecture réseau, les choses se compliquent (pas tant que ça) : si jamais vos autres points d'accès sont connectés en filaire au RT6600AX principal par l'intermédiaire de switch, il faudra bien que ces switch soient en mesure de tagger les ports associés à ces VLAN pour garantir que les trames soient bien acheminés. C'est logique mais dans mon emballement j'ai zappé ce détail et je me suis retrouvé avec des périphériques devant se connecter au réseau invité (VLAN 1733) qui n'arrivaient pas à se connecter en Wifi sur la borne située à l'autre bout de l'appartement. Une fois ce fameux VLAN 1733 taggé sur le port du switch auquel était raccordé ce point d'accès, le devices ont dans la foulée obtenu une IP sur le réseau invité. - les perfs sont très bonnes. Les devices compatibles se synchronisent à 10 mètres en dégagé sur chaque borne en 1.2 Gbps sans problème et de manière stable. J'ai pu lancer simultanément des téléchargements d'ISO depuis mon smartphone perso et celui du boulot, ma tablette et mon NUC (carte wifi Intel AX210) pendant 5mn et j'arrive bien à saturer le débit permis par le port 2.5 Gbps de la freebox pop : les 4 appareils tiennent du 600 à 700 Mbps en descendant de manière constante. Par contre, ce test m'a permis de faire chauffer la freebox pop et d'entendre pour la première fois son ventilateur interne se déclencher à fond ! 🙂 J'avais auparavant un RT2600AC (dans une baie réseau avec antennes déportées) et 4 MR2200AC pour couvrir de manière très efficace mon logement : je dirais que les 3 RT6600AX offrent une couverture bien meilleure avec des débits utiles sensiblement plus élevés. - la configuration Wifi n'a pas beaucoup changé à ceci près qu'on peut désormais créer des SSID multiples. J'ai lu qu'on pouvait monter à 15 (3 SSID par VLAN en sachant que 5 VLAN peuvent être créés). Ce que je trouve top c'est qu'on peut créer des listes de filtrages MAC distinctes pour chaque VLAN/SSID ! - la configuration internet/réseau local est quasi identique : DoH, IPV6, VPN, Dual WAN, SmartWan sont toujours là tout comme les chemins de stratégie pour faciliter la création de routes. Bref, ce n'est pas forcément le hardware le plus "up to date" et j'avoue que je trouve que l'absence d'un 2e port multigig est vraiment chiche. Mais à côté de ça, je dois dire que SRM 1.3 est une réussite en matière d'ergonomie pour la configuration. La partie monitoring est toujours un peu en retrait : les stats, logs éparpillés dans différents menus/sous menus et les paquets gagneraient à être centralisés au même endroit et à pouvoir être croisés/combinés avec des filtres et critères. Après un RT1900AC et un RT2600AC épaulés par des MR2200AC, je repars pour un tour avec SRM, après avoir fait des incartades chez Microtik et leur RouterOS que j'ai trouvé imbuvable, des systèmes Netgear Orbi et Amazon Eero pro à l'inverse totalement anémiques en terme de configuration et fonctionnalités (il faut passer à la caisse pour intégrer de la sécurité et du contrôle parental plus poussés...)

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

Hello ! Une rubrique dédiée ne serait-elle pas adaptée ? Les 1eres commandes devraient être livrées à partir de la semaine prochaine et les retours d'utilisateurs pourraient arriver vite ! La modération étant très à cheval sur les hors sujet, une section centralisant tous les posts et remarques sur le RT6600AX serait bienvenue.😆

https://www.facebook.com/synology/photos/a.274672852896/10158594756417897/

c'est chouette ! à l'intention des modos, il faudrait créer une rubrique : "on se la montre"......... cela permettrait aussi de donner des idées d'agencement à ceux qui voudraient 'mais qui n'osent pas' 😊 anti🍺

Bonjour, L’update 5 est disponible: (A noter pas de redémarrage) https://www.synology.com/fr-fr/releaseNote/DSM#6_2 https://archive.synology.com/download/Os/DSM/6.2.4-25556-5

Moi j'ai fait la MAJ hier 🙂 Je suis un OUF des tests 😄 L'interface est un peu plus sobre, et sombre enfin 😄 Mais au-delà de ça, j'ai pas trop constaté de gros changements.

Bonjour, J'ai suivi vos recommandations. J'ai ajouté 8Go de ram à mon DS220+ Crucial CT8G4SFS8266 DDR4, 2666 MT/s, PC4-21300, Single Rank x8, SODIMM, 260-Pin Acheté sur Amazon 47€ Et ça fonctionne 😊

Hello à tous ! La béta du service de DNS personnalisés/paramétrables de Adguard est lancée. J'ai eu la chance de recevoir une invit' pour la béta et j'ai donc franchi le pas ce matin. L'outil se met en oeuvre de manière très similaire à NextDNS : une fois le compte créé et un profil généré pour son routeur, on récupère un lien DoH personnalisé à renseigner dans son routeur Synology. Il faut créer ensuite un profil pour chaque périphérique pour disposer à chaque fois d'un lien spécifique DoH, DoT, Quic ou une adresse DNS IPV4/IPV6 classique. En ce sens, la personnalisation et la remontée de stats était un peu plus facile à obtenir dans NextDNS. A l'inverse, on peut aisément supprimer/éditer un périphérique et les logs associés contrairement à NextDNS qui conservait, il me semble, les anciennes entrées même pour un appareil plus présent sur le réseau domestique. La remontée de stats/infos/logs se fait dans la foulée et il me semble ne pas rencontrer la latence que l'on a habituellement sur NextDNS. On retrouve des classiques sur l'exploitation des stats : vue globale par geotagging des requetes, classement du traffic par entreprises (GAFAM, par exemple), requêtes bloquées. J'ai l'impression que le surf est un chouilla plus rapide : c'est peut-être psychologique, le traffic étant encore modéré sur l'outil, ou alors c'est tout bêtement lié au fait que Adguard exploite bien les infrastructures DNS de Cloudlare et dispose de plus de serveurs.🙂 https://www.cloudflare.com/fr-fr/case-studies/adguard/ Inutile de présenter l'efficacité de Adguard sur le filtrage antipub/anti tracking : c'est très bon. On peut de surcroit ajouter d'autres listes voire intégrer des règles personnalisées. Le contrôle parental est de la partie mais c'est vraiment sommaire par rapport à NextDNS. On peut exporter tous les logs qui se limitent néanmoins à 90j dans cette béta. En résumé, c'est très efficace, savoir faire de Adguard oblige, c'est fluide et simplissime à déployer sur nos routeurs Synology. Le surf semble plus rapide. Cependant à côté de NextDNS, c'est un peu pauvre encore en fonctionnalités 😞 Par contre, si ça reste gratuit, l'outil aura une grosse carte à jouer face à NextDNS. Je reste sur Adguard pour l'instant pour voir comment ça évolue. Mon abo à NextDNS arrive à expiration à la fin du mois de toute façon et j'ai désactivé le renouvellement automatique.

Bonjour, J'ai trouvé à quoi cet appareil correspond. C'est d'ailleurs assez inattendu... Donc, pour rappel, j'ai un objet connecté en wi-fi fabriqué par Dexatec technology. Après enquête, il s'avère que c'est un appareil Eve (marque allemande) pour ma domotique (bien vu @oracle7). Le sujet est donc résolu.

Welcome among us !

Ne voulant pas traîner pour le remettre en service, je suis allé acheter une CR1220 puis direction chez mon père. Il avait une résistance de 330Ω en stock. Quitte à désosser le NAS, on l'a soudé sans attendre. L'ancienne pile avait une tension de 3,1V donc a priori elle n'était pas en cause. Le résultat ne s'est pas fait attendre : c'est reparti comme en 14 ! Reste à voir dans la durée. En tout cas merci à tous les intervenants sur le sujet qui permettent à chacun de de remédier à une bien triste obsolescence.

Bon, j'ai trouvé 😍 Aller dans "Panneau de configuration" Cliquer sur le dossier que vous voulez partager avec plex. Faire un clique droit et choisir "Modifier" Cliquer sur "Permission" En haut à gauche, la ou il est marquer utilisateur locaux, cliquer Choisir "Utilisateur du système interne" Rechercher dans la liste PlexMediaServer et lui donner les droits 🥰 Enjoy

Bonjour a tous, En date de ce jour, Mais apparemment pas encore téléchargeable ... pour CPU Intel Atom C2538

Attention, car il y a eu un scandale l'année dernière à ce sujet : https://www.macg.co/materiel/2020/09/western-digital-reinvente-la-definition-de-tours-par-minute-pour-ses-disques-durs