Classement

Note du 08/10/2023 Ce tuto a été créé sous DSM 6.x et doit être appliqué par les utilisateurs utilisant cette version. Néanmoins, bien qu'il soit toujours d'actualité, certaines sections de DSM sont organisées différemment depuis l'arrivée de DSM 7, avec quelques nouveautés par rapport à la version précédente. C'est pour cette raison qu'un nouveau tuto spécifique à cette version a été élaboré par @.Shad. Les utilisateurs de DSM 7 peuvent bien entendu continuer à se référer au présent tuto pour notamment y trouver des explications plus fournies sur certains points qui ont été allégés dans le nouveau tuto pour des raisons de clarté. ____________________________________________________________________________________________________________ Préambule L'objectif de ce tutoriel est de vous aider à correctement sécuriser votre boitier et en particulier les accès à ce dernier. Il ne s'agira pas ici d'un guide permettant d'avoir un haut niveau de sécurité (il n'y a pas de qu'il faut dans nos boitiers), mais simplement d'une énumération des différentes étapes permettant de limiter les risques à un seuil acceptable. Tous les points ne sont pas nécessairement à suivre, chacun est libre d'appliquer ou non ces recommandations, l'important étant de comprendre de quoi il s'agit. Voyez ce TUTO comme une liste de restrictions qu'il est possible de mettre en place, selon vos besoins, certains réglages pourront ne pas convenir. Comme depuis quelques années le terme NAS est de moins en moins compris par la plupart des utilisateurs et est détourné par les fabricants, un petit rappel s'impose. Un NAS (Network Attached Storage ou boîtier de stockage en réseau) est un système permettant de stocker des fichiers et d'y accéder via le réseau. C'est tout, terminé. Si nos boitiers ne faisaient que ça, ce tutoriel aurait eu un tout autre aspect (on aurait parlé de RAID, de TRIM, d’instantanés, d'onduleur, ...), mais on constate que sous cette appellation se trouvent de nombreuses fonctions qui n'ont rien à voir avec un NAS, ce sont des fonctionnalités de serveur (hébergement de site, streaming, messagerie, applications, ...) et un serveur a souvent vocation à être consulté depuis n'importe où (ou presque). Il faut donc en sécuriser les accès. Notes de lectures Je fais emploi de la première personne du singulier dans de nombreux points pour indiquer qu'il s'agit d'avis personnels Par soucis de compréhension, malgré son utilisation impropre, le terme NAS sera employé par la suite Plusieurs liens sont présents dans ce tutoriel, je vous invite à les consulter au fur et à mesure Je vous recommande fortement de lire ce tutoriel en entier une première fois avant de commencer à faire des modifications, puis de le reprendre étape par étape par la suite. De même, faites une sauvegarde de la configuration avant de commencer Afin de limiter le texte, vous trouverez de nombreuses copies d'écran avec les réglages que je recommande. Enfin, vous avez parfaitement le droit de ne pas être d'accord avec mes recommandations, n'hésitez pas en m'en faire part dans les commentaires. Sécurité ? La sécurité est un domaine très vaste en informatique et probablement celui qui revêt le plus d'aspects, mais force est de constater que c'est aussi le sujet le moins prioritaire pour la plupart des utilisateurs. Je vois 2 raisons à ça : les consommateurs sont de plus en plus en attente de produits simples et prêts à l'emploi dès le déballage hors de question de lire la documentation => erreur hors de question de se former (ou pire, d'être formé) => erreur et de toute manière on ne court aucun risque => erreur la sécurité est perçue comme une contrainte que des empêcheurs de tourner en rond essayent d'imposer c'est trop compliqué => ce point est souvent vrai ça fait perdre trop de temps => erreur et de toute manière on ne cours aucun risque (bis) => erreur Ces points ne sont que des exemples qui concernent à peine 95% des acheteurs de matériel informatique en tout genre. Il est probable que "vous" qui lirez ces lignes êtes dans les 5% restant. Faites votre possible pour convaincre les autres. Un constat assez curieux, c'est que dès qu'on parle de sécurité dans un domaine non informatique (chambre de bébé, maison, compte en banque, ...), la plupart des personnes sont réceptives si ce n'est volontaires, mais dès que ça touche à l’informatique, il n'y a plus personne pour écouter et surtout entendre. C'est un vrai problème car de nos jours, nos bébés sont sous vidéo-surveillance, nos enfants ont des ordinateurs (une tablette est un ordinateur, même si très limité), notre maison dispose d'une alarme connectée et nos comptes en banque sont accessibles de partout. Mais curieusement, les gens ne font pas le rapprochement . Sans oublier la meilleure des réponses - "Je n'ai rien à cacher". Quoi sécuriser ? Vous êtes maintenant convaincu que la sécurité est un point à ne pas négliger, y compris en informatique ? Que devez-vous sécuriser ? Comme indiqué plus haut, en informatique, la sécurité couvre de nombreux domaines, dans le cas de nos NAS/serveurs, il y a 3 principaux domaines sur lesquels on peut agir : sécurité des accès physique : je serais surpris que votre boitier se trouve sur votre pas de porte de même, je pense que votre nas est au sec reste à gérer la problématique des vols, ou pire, des enfants, mais c'est un autre sujet sécurité des données : 2 mots => sauvegarde + chiffrement sauvegarde : ayez toujours vos données sur au moins 2 supports distincts (nas+disque externe par exemple) chiffrement : si vous avez des données privées et/ou confidentielles, le chiffrement des partages est à envisager sécurité des accès distants : c'est le sujet qu'on va aborder dès maintenant Comment faire ? La plupart des réglages sont à faire dans le panneau de configuration, donc commencez par l'ouvrir : nb : certaines applications disposent aussi de paramètres liés à la sécurité, il ne faudra pas oublier d'aller les vérifier ######################################### "Il nous baratine sur plusieurs paragraphes à propos de la sécurité et voilà qu'il commence à parler d'heure ?" En informatique et plus particulièrement sur l'aspect sécurité, l'heure est un maillon essentiel. Une machine qui n'a pas un système horaire fiable va rencontrer un jour ou l'autre les problèmes suivants : problèmes de connexion : les systèmes d’authentification et de chiffrement utilisent l'heure dans les plupart des traitements problèmes de mise à jour : l'heure est une composante importante pour les tâches planifiées et la gestion des caches problèmes de sauvegarde : comment savoir ce qui a changé depuis la dernière sauvegarde si l'heure n'est pas fiable problèmes de diagnostic : si l'heure du système n'est pas fiable, celle des journaux (logs) ne le sera pas non plus Notez bien que je parle d'heure fiable, pas nécessairement d'heure juste. L'important n'est pas d'être à la bonne heure, mais que la pendule avance à la bonne vitesse et soit en accord avec celle des autres systèmes qui y sont connectés (en gros votre pc, les serveurs de Synology, ...). Vous avez donc le choix de mettre une heure fantaisiste à la condition d'aller régler les horloges de tous les autres équipements liés (par effet ricochet, vous allez devoir régler l'heure des satellites en orbite autour de Mars ...). Le plus simple reste d'être à l'heure juste à mon avis Ça se passe ici : Sélectionnez bien votre fuseau horaire et entrez l'adresse d'un serveur de temps fiable (vous en trouverez plusieurs ici) ou choisissez en un dans la liste proposée. Comme cette synchronisation va passer par Internet, il est recommandé de choisir un serveur de sa zone géographique (pool.ntp.org le fait tout seul) : Vous pouvez aussi activer la fonction de serveur NTP de votre boitier si vous souhaitez que vos autres équipements (vos caméras de surveillance par exemple) s'en servent comme horloge de référence : Il suffira alors de les configurer pour utiliser votre NAS comme serveur de temps (ça peut aussi être fait via le DHCP, options 004 et 042). ######################################### En sécurité, une des règles d'or consiste à réduire la surface d'attaque. Moins il y a des programmes qui tournent, mieux c'est. Accessoirement ça libérera des ressources (donc il sera plus rapide, il consommera moins et il chauffera moins). Dans cette section, n'activez que les services que vous utilisez. Si vous n'utilisez pas le FTP ou le NFS ou ... désactivez les. À noter que certains protocoles disposent d'options liées au chiffrement ou à la sécurité en générale, par exemple choisir SMB3 (dans Service de fichiers Windows) permet de chiffrer la communication en AES (pour Windows 8 et plus récent, les distributions GNU/Linux avec un noyau > 3.12 et les dernières versions de MacOS) : ######################################### On peut lire un peu partout qu'il faut renommer ou désactiver le compte admin car il sera attaqué. La recommandation est, partiellement, valable, mais la raison est mauvaise. C'est une bonne chose de créer un (ou plusieurs) compte(s) d'administrateur(s) et de ne pas utiliser (ni modifier) celui par défaut : s'il y a plusieurs personnes amenées à administrer un équipement ça permet une meilleure traçabilité, ça évite de devoir se refiler le mot de passe et ça permet de couper un administrateur en particulier si besoin sans impacter les autres si vous êtes seul à administrer votre équipement ça a au moins le mérite de laisser intact le compte par défaut La raison est mauvaise car les attaques ne s’arrêtent pas si le compte admin ne marche pas, elles s’arrêtent lorsque l'attaquant a testé tous les login/password de sa liste. Un autre point qui est souvent oublié c'est que le compte admin reste obligatoire pour certaines opérations avec les anciennes versions de DSM (inférieurs à DSM6.0). nb : certaines applications ne sont pleinement fonctionnelles qu'avec des droits d'administrateurs (ce n'est pas normal mais c'est comme ça) Nous allons donc créer un nouvel administrateur, mais un peu particulier : Choisissez un login explicite mais pas celui que vous utilisez tous les jours : Il faut bien entendu qu'il soit membre du groupes "administrators" : Ici je bloque les accès à tous les partages, certains vont penser que ça ne sert à rien puisqu'un membre du groupe "administrators" peut toujours se remettre les droits et c'est vrai. L'intérêt est que, si pour une raison ou une autre, ce compte arrive à accéder une des applications de gestion des fichiers (FileStation par exemple), il ne puisse pas faire grand-chose. nb : si vous utilisez PhotoStation, vous ne pourrez pas changer les droits de ce dossier, il faut le faire directement depuis les paramètres de l'application avec un compte administrateur On ne peut pas placer de quota sur un admin, donc on passe : Comme plusieurs protections valent mieux qu'une, on peut aussi bloquer l'accès à toutes les applications, mais dans ce cas, vous ne pourrez plus les administrer (c'est logique !). Personnellement je n'ai coupé l'administration que pour les applications qui sont accessibles depuis Internet en direct (chez moi la liste est courte, il n'y en a qu'une) et quand je veux administrer cette application (c'est rare), je me connecte avec cet administrateur, je lui donne les droits, je fais mon réglage et je retire les droits. À adapter en fonction de vos besoins (au début c'est très contraignant, mais une fois que le NAS est bien configuré, on n'y prête plus vraiment attention). Dans tous les cas, autorisez l'accès au "Bureau" à votre super admin afin de conserver l'accès au panneau de configuration : Avec un peu de parano, on peut aussi ralentir les opérations sur les fichiers pour décourager l'attaquant (ça vous demandera d'activer le contrôle du trafic) : Et on applique : Une fois notre administrateur créé, on vérifie qu'il fonctionne, donc on se déconnecte et on se reconnecte avec ce nouveau compte. Si ça fonctionne et qu'il accède bien au panneau de configuration comme un administrateur on peut continuer en spécifiant une politique pour les mots de passe. Un bon mot de passe c'est un mot de passe facile à retenir ou à retrouver de tête (donc pas sur un post-it) et relativement long. On lit souvent qu'il faut utiliser des caractères spéciaux car ça rend les mots de passe plus complexe. C'est vrai si ces 3 conditions sont réunies : les utilisateurs arrivent à s'en souvenir sans le noter les utilisateurs arrivent à le taper (clavier mobile, braille, étranger, ...) sa longueur est d'au moins 12 caractères Je trouve pour ma part qu'il est plus facile d'utiliser un long mot de passe avec des lettres, des chiffres et des majuscules qu'un mot de passe avec des caractères spéciaux. Pour ce qui est de la sécurité, imposer des caractères spéciaux à un mot de passe ne le complexifie que d'un "bit" en équivalent cryptographique. Ajouter 2 caractères "normaux" le complexifie de 11 bits. Pour un humain, deviner une chaine de 10 caractères spéciaux est très complexe, pour une machine c'est plus facile qu'une chaine de 10 caractères "normaux". Je ne dis pas qu'il ne faille pas inclure des caractères spéciaux, je recommande juste de ne pas l'imposer car ça facilite la vie des utilisateurs : En activant la vérification en 2 étapes, un assistant va se lancer, suivez le guide : Je recommande FreeOTP pour gérer vos jetons (il fonctionne aussi pour FaceBook, Google, ...) mais il existe d'autres applications similaires. Entrez le code généré par l'application (si votre NAS ou votre client ne sont pas à la même heure, ça échouera probablement) : Renseignez une adresse fiable et sécurisée ici : Et on valide : Encore une fois, on teste avant de continuer, donc on se déconnecte et on se reconnecte : Cette fois ci avec une étape supplémentaire : C'en est terminé de la création de notre administrateur, on peut maintenant couper celui par défaut : Arrivez ici vous allez penser que ce compte (monadmin) est inutilisable. C'est faux, c'est un compte d’administrateur qui peut effectuer toutes les tâches d'administration, il n'a pas besoin de voir des vidéos, d'envoyer des photos, ... Donc maintenant vous pouvez/devez créer des comptes "normaux" (sans les droits d'administration) et le compte d'administration sera réservé aux tâches d'administration. Je recommande aussi de créer des comptes utilitaires pour les besoins spécifiques. À titre d'exemple, sur mes NAS j'ai créé plusieurs comptes de ce type, dont : routeur (non admin) : ce compte sert à mon routeur pour exporter les modifications de configuration, il a juste le droit de faire du FTPs dans un dossier spécifique sauvegarde (admin) : ce compte est dédié aux tâches de sauvegardes, il a un mot de passe de 64 caractères (merci Keepass) En complément j'ai plusieurs comptes "normaux" pour l'utilisation au quotidien (ma famille et moi). Ça peut paraitre contraignant, mais normalement, enfin je l'espère pour vous, vous ne passez pas votre temps à faire des tâches d’administration sur votre NAS, donc vous ne devriez pas en avoir besoin souvent. Encore une fois il ne s'agit là que de recommandations, vous êtes libres d'utiliser le login admin avec le mot de passe "1234" pour consulter vos données privées depuis la Chine. ######################################### Ici on va aller vite, je déconseille d'activer ce service si on tient un tant soit peu à la sécurité. Pour informations, voici comme fonctionne QuickConnect : votre NAS établi un tunnel OpenVPN avec un serveur tiers loué par Synology (donc de fait, ils ont un accès direct au NAS s'ils le souhaitent) en parallèle il créé et met à jour un enregistrement DNS avec votre IP public (comme un DynDNS) lorsque vous entrez l'adresse QuickConnect de votre boitier, votre client va essayer de déterminer si vous pouvez vous connecter en direct si ce n'est pas le cas, votre trafic sera dirigé sur un serveur de Synology qui se chargera de router le trafic dans le tunnel du point 1 (donc ils peuvent voir tout ce qui passe) Le résultat est un trafic souvent très lent, relativement instable et difficile à maitriser. Néanmoins, si vous souhaitez conserver QuickConnect, pensez à limiter les applications accessibles, en particulier, n'autorisez pas DSM (en pratique l'accès à DSM on s'en fiche, ce qui est important dans un NAS ce sont les fichiers, mais bloquer l'accès aux fichiers sur un NAS limite grandement son utilité ...). ######################################### Il y a 3 sections dans ce menu : Cette section vous permet de configurer un service de DNS dynamique, c'est pratique pour ceux qui n'ont pas d'adresse IP fixe, rien de compliqué ici : 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. Là on entre en plein dans les comportements que je décrivais au début de ce tutoriel : les gens veulent du "clef en main" et la sécurité ça complique les choses ! 2 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 de se prendre un virus 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 Un petit menu 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. Attention, il faut vider ces champs si vous utilisez des noms de domaine ou des ports spécifiques (portail des application, reverse proxy, ...). nb : si vous avez changé les ports de DSM (directement ou via votre routeur), il faut l'indiquer ici ######################################### On ne peut pas parler d'accès distant sans parler d'IP, donc allons y : Du point de vue confort, fiabilité et sécurité, l'attribution dynamique (DHCP) est recommandée, néanmoins, certains services nécessitent d'avoir une adresse IP fixe (c'est le cas du DKIM avec MailServer mais aussi du serveur DHCP et quelques autres applications), donc à choisir en fonction de vos besoins. Si vous choisissez DHCP, fixez l'adresse dans votre serveur DHCP (votre box probablement), si vous choisissez l'IP en dur, prenez une IP en dehors de la plage DHCP. Pour l'IPv6, même si je ne devrais pas le dire (car l'IPv6 c'est bien), du point de vue sécurité je vous recommande de le désactiver pour le moment. Le problème ne vient pas de Synology (qui permet de régler le pare-feu en IPv6), c'est plus général (j'en parle ici). Une fois que vous aurez bien compris ce que ça implique, vous pourrez revenir l'activer. Merci de ne pas changer les ports par défaut, ça n'apporte presque rien du point de vue sécurité (on gagne moins d'une seconde face à un scanner) et ça complique les usages. Si vraiment vous souhaitez les changer depuis Internet, faites-le sur votre box ou avec un "reverse proxy". Je ne redirige pas automatiquement les connexions HTTP vers HTTPS car je n'expose pas DSM directement sur Internet (il y a un serveur VPN pour ça), mais si vous le faites, activez la redirection. Attention, j'ai pu constater qu'activer la redirection HTTP vers HTTPS cassait certains mécanismes, au moins le reverse proxy pour les applications de base (audio/download/file/surveillance/video - station). Si vous souhaitez profiter de la redirection sans casser le reverse proxy, le plus simple est de créer un petit fichier php à la racine de Webstation (/web/index.php) pour gérer cette redirection : <?php $http_host = $_SERVER['HTTP_HOST']; // 307 Temporary Redirect header("Location: https://$http_host",TRUE,307); exit; ?> Vous pouvez bien entendu adapter le script pour utiliser des ports différents si besoin. Pour la dernière option, l'HSTS, ne l'activez que si vous n'accédez jamais à votre NAS autrement qu'en HTTPS (c'est votre navigateur qui enregistrera cette information et il ne vous laissera plus passer autrement qu'en HTTPS, même si ce dernier est coupé). ######################################### J'ai pris les menus dans l'ordre (ou presque), donc la section "Sécurité" n'arrive que maintenant, pourtant tout ce que l'on a vu précédemment est aussi lié à la sécurité ... Ces réglages devraient convenir à la plupart des utilisateurs : Pour le pare-feu, même si votre NAS n'est pas exposé sur Internet, activez-le, ça ne coute presque rien en ressources et ça limitera la casse si un jour il est exposé (une box qui passe en bridge, une erreur de manipulation, ...). Vous pouvez laisser les notifications activées, mais ne vous en servez pas (ne cliquez pas sur le bouton OK lorsqu'elles apparaissent), utilisez-les simplement comme un rappel que vous avez tel ou tel port à ouvrir. Les règles de pare-feu ci-dessous seront valable chez pratiquement tout le monde, en toute rigueur, il ne faudrait autoriser que les adresses "fiables" sur des services précis, mais sauf à avoir des espions dans son réseau, ça ne devrait pas poser de problèmes. On va dire que c'est un compromis entre confort et sécurité. nb : si vous souhaitez faire de l'IPv6, pensez à ajouter les adresses locales (fe80::/10 et ff00::/8) Dans un premier temps, je vous recommande vivement de configurer votre pare feu avec les 4 règles ci-dessous, à l'identique !! UPDATE: Dans chaque section d'interface modifier le paramètre : Si aucune règle n'est remplie : Refuser l'accès" ("Autoriser l'accès" par défaut). nb : dans les 3 premières règles, il faut bien choisir "Sous-réseau" et pas "Hôte unique" ni "Plage d'IP" ici j'utilise uniquement la table "Toutes les interfaces" car c'est plus simple à gérer et suffisant pour la plupart des besoins, si vous souhaitez utiliser les règles par interfaces, lisez ceci Une fois ces 4 règles en place, vous pourrez ajouter les autres règles dont vous avez besoin (il faut les ajouter juste avant la dernière règle) si vous souhaitez que certains services de votre NAS soient accessibles depuis Internet. Les règles ci-dessus n'autorisent que les réseaux locaux et bloquent tout le trafic venant d'Internet. Voici un exemple plus complet qui n'est pas à reprendre aveuglement, c'est juste pour illustrer : En plus des réseaux locaux (ou privés), j'autorise les services suivants : ports TCP 80 et 443 depuis l'adresse 192.0.2.3 (il s'agit d'une adresse IP public d'exemple, ce n'est pas une adresse privée => https://tools.ietf.org/html/rfc5737) port UDP 1194 (OpenVPN) uniquement depuis la France ports UDP 500, 1701 et 4500 (L2TP/IPSec) uniquement depuis la France et les ports TCP 7000 et 7001 que j'ai associé à une application, autorisés depuis la France la Guyane française nb : les règles sont évaluées dans l'ordre, de haut en bas ps : si votre NAS est derrière une Box, il faudra aussi transférer (forward) les ports sur cette dernière Une recommandation, n'autorisez pas l'accès en direct à DSM (ports TCP 5000 et 5001 par défaut) depuis Internet mais servez vous du portail des applications (cf plus bas) pour limiter les accès aux seules applications nécessaires. Si vous devez administrer votre NAS depuis Internet, l'utilisation du Serveur VPN est vivement conseillée. Une petite case à cocher pour limiter les chances que votre boitier soit rendu inaccessible suite à un certain type d'attaque : A adapter selon vos interfaces connectées. Cette fonction bloquera les adresses IP des personnes ayants fait trop d'erreurs d'authentification (ça ne fonctionne qu'avec certaines applications, mais c'est déjà ça). nb : n'ajoutez pas d'adresses dans la liste des autorisations, si vous vous bloquez vous même, changez juste l'adresse de votre poste pour le débloquer ou attendez l'expiration du blocage Un peu plus haut on a parlé d'HTTPS, or qui dit HTTPS dit certificat. Ici on se heurte à un vrai problème du point de vue de la sécurité. Il est assez difficile de l'expliquer sans en faire des pages, mais pour faire simple, n'utilisez jamais un certificat auto-signé (comme celui installé par défaut dans la plupart des équipements). La solution la plus sécurisée consiste à créer votre propre autorité de certification et à émettre vous-même vos certificats. Cette méthode présente quelques avantages mais aussi quelques inconvénients : Avantages : vous n'avez pas à faire confiance à une entreprise que vous ne connaissez pas vous n'avez pas à payer cette entreprise pour vos certificats (même si avec LetsEncrypt et quelques autres entités, c'est gratuit) vous pouvez émettre autant de certificats que nécessaire vous pouvez choisir ce qu'ils acceptent (wildcard ou multi domaine par exemple) Inconvénients : vous devez savoir le faire vous devez installer votre autorité partout où vous l'utilisez (dans vos navigateurs, smartphones, ...) La solution recommandée est donc d'utiliser un certificat signé par une autorité reconnue en standard (Synology vous permet de créer un certificat signé par LetsEncrypt, c'est gratuit et ça marche assez bien). Dans un cas comme dans l'autre, supprimez le certificat installé par défaut. Enfin, la solution qui n'en est pas une consiste à accepter les avertissements de sécurité, en faisant ça, vous installez dans votre navigateur des certificats qui n'ont été validés par personne. C'est très dangereux mais il est assez difficile de vous expliquer pourquoi en quelques mots, gardez juste à l'esprit qu'accepter un certificat non reconnu peut permettre à un attaquant d'intercepter toutes vos communications vers le site de votre banque, même si ce dernier est protégé par un vrai certificat. ps : en passant, 2 modules pour Firefox que je recommande : Y U no validate et SSleuth Donc pour la plupart d'entre vous, le bon choix est de passer par l'assistant pour créer un certificat signé par LetsEncrypt (le port 80 doit être ouvert le temps de la génération du certificat et tous les 3 mois pour son renouvellement). N'activez jamais la compression HTTP (il y a une faille de sécurité dans ce protocole qui rend l'HTTPS inefficace) et utilisez les suites de chiffrement "moderne". ######################################### Un point important en sécurité consiste à être prévenu lorsqu’un problème survient. Le paramétrage des notifications est fait pour ça. Ici j'ai configuré les notifications par mail, mais vous pouvez utiliser les SMS (si vous avez un abonnement compatible comme FreeMobile) ou encore par Push (je déconseille ce mode car il est peu pratique à l'usage). Dans le dernier onglet, vous pouvez choisir le type de notification à activer pour la plupart des événements pouvant se produire. Au début cochez tout, puis en fonction de votre usage, vous pourrez décocher certaines notifications (chez moi j'ai désactivé les notifications pour les sauvegardes réussies). ######################################### Maintenir ses équipements à jour est un moyen assez simple de limiter les problèmes de sécurité. Je recommande de laisser le NAS détecter et télécharger les mises à jour automatiquement mais de ne pas le laisser les installer tout seul. Synology sort des mises à jour de bonne qualité en général, mais il arrive, surtout pour les mises à jour majeurs, que des problèmes surviennent (en clair, elles sont parfois boguées). Laissez le NAS vous prévenir qu'une mise à jour est disponible et renseignez-vous sur d'éventuels soucis de compatibilité avant de l'installer. nb : désactivez aussi les mises à jour automatique dans le Centre de paquets pour la même raison Parmi les actions à effectuer de temps en temps, surtout lorsque vous vous apprêtez à faire de gros changements (comme en suivant ce tutoriel), la sauvegarde de la configuration n'est pas à omettre. ps : pour information, le fichier de sauvegarde est une archive tar.xz contenant une base sqlite, il est donc possible de le consulter pour récupérer un élément de configuration précis Notez en passant que seuls certains paramètres sont sauvegardés, pensez à sauvegarder le reste d'une manière ou d'une autre : ps : cette sauvegarde de la configuration du NAS n'est pas à sauvegarder sur le NAS lui-même ######################################### Ici vous avez la possibilité de restreindre l'accès à certaines applications pour certains comptes. Par exemple si vous vous servez de votre NAS comme d'un système de dépose de fichiers pour des clients, via FileStation, il n'est pas nécessaire de leur laisser accès à vos vidéos de vacances avec VideoStation. De même il est peut être utile de limiter les accès à certaines machines. Sélectionnez une application et cliquez sur Modifier, la suite est assez explicite. ######################################### Par défaut la plupart des applications sont accessibles via DSM (ports 5000 et 5001) et l'adresse de votre nas, mais si vous souhaitez que seule telle ou telle application soit accessible depuis Internet, ou dispose d'une adresse spécifique ou écoute sur un port particulier, ou encore tout ça à la fois, c'est ici qu'il faut se rendre. Vous avez 2 menus : Applications : ça permet de configurer l'adresse et le port d'écoute de certaines applications Synology Proxy Inversé : ça permet de faire la même chose pour les autres applications ou faire des configurations plus avancées Ces options vous permettent, par exemple, de faire écouter les différentes applications sur des ports précis et ainsi, grâce au pare-feu, de limiter leurs accès aux seules adresses autorisées. Ci-dessous un exemple un peu plus complexe (la seconde partie n'est réalisable qu'avec du loopback ou si vous avez un DNS en interne ou qui gère les vues, j'en parle à la fin du tuto VPN) Dans un premier temps j'ai déclaré des ports spécifiques pour chacune des applications que j'utilise : => depuis un navigateur, si j'entre l'adresse de mon nas en précisant le port 7043 je tombe directement sur Audio Station J'ai ensuite configuré le Proxy inversé pour faire correspondre les différentes applications avec des noms de domaine différents mais sur un seul port (tcp 443/https). J'ai aussi créé une entrée pour une application non Synology (il s'agit ici d'un Docker) : => depuis DSAudio, j'entre l'adresse dsaudio.mon.domaine:443 nb : dans les applications mobiles, il ne faut pas oublier le numéro de port dans l'adresse pour que ça fonctionne de partout (en interne comme depuis Internet), sinon certaines d'entre elles essayent systématiquement de trouver une configuration QuickConnect (qui n'existe pas chez moi) ps : cette configuration ne fonctionnera pas si vous avez activé la redirection HTTP vers HTTPS de DSM (cf remarque un peu plus haut) ######################################### Même si vous n'avez pas l'intention de vous en servir, activez le SSH. En cas de problème d'accès à DSM, c'est souvent la seule manière de débloquer la situation sans devoir faire un reset du NAS. Par contre ne l'ouvrez pas depuis Internet, limitez son accès à votre seul réseau local. Et en passant, choisissez le mode de chiffrement le plus élevé : ######################################### Synology a eu la bonne idée (de mémoire avec DSM 5.2) d'ajouter l'application "Conseiller en sécurité". Cette application analyse certains fichiers et certains réglages de votre NAS afin de vous prévenir en cas d'anomalies. Elle ne va pas encore assez loin à mon gout, d'où ce tutoriel, mais c'est déjà pas mal. Globalement elle fait bien son travail, donc il serait dommage de s'en passer (n'oubliez pas de planifier une analyse régulière) : Néanmoins je ne suis pas d'accord avec 3 des recommandations de Synology, celles concernant les changements de ports, donc je les désactive (tout le reste devrait être activé) : Lancez l'analyse une première fois, si vous avez suivi mes recommandations, tout devrait être au vert.

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

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, vous pouvez suivre les explications données plus loin, ou vous référer aux différents tutos qui traitent de cette question, ou bien encore utiliser le certificat fourni par Synology pour votre nom de domaine personnalisé (xxxx.synology.me) 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 !

Préambule L'objectif de ce tutoriel est de vous aider à mettre en place votre propre serveur DNS en interne (dans votre réseau local). Pour ce qui est de l’intérêt de disposer d'un serveur DNS en interne, voici quelques exemples : c'est plus fiable : vous n'êtes plus dépendant de la (non) fiabilité des DNS de votre opérateur (cf pannes d'Orange et de Free par exemple) c'est plus fiable (bis) : vous n'êtes plus soumis aux mensonges des DNS de votre opérateur (cf panne d'Orange et filtrage étatique) c'est plus rapide : grâce aux mécanismes de cache, vous ferez moins de requêtes DNS vers Internet c'est plus confortable : ça vous permet, par exemple, d'éviter de faire du loopback ou encore d'adresser vos équipements interne avec un nom au lieu d'une IP et enfin, ça vous permettra de remplacer une bonne partie des fonctions de QuickConnect (il faudra juste ouvrir les ports) et donc de couper ce dernier C'est surtout les 2 derniers points qui devrait vous intéresser car en remplaçant le loopback et Quickconnect vous gagnerez en sécurité, en fiabilité, en confort et en performances. Il ne s'agira pas d'un guide sur le protocole DNS, il y aurait beaucoup trop de choses à détailler (bien plus que sur mes précédents tuto combinés). Je vais donc prendre pas mal de libertés sur les termes employés afin de faciliter ma rédaction et votre compréhension. Pour la même raison, je serai assez avars en détails et en explications. Gardez juste à l'esprit qu'Internet repose sur 2 protocoles : BGP et DNS. Quand l'un des 2 attrape froid, tout Internet tombe malade (c'est déjà arrivé, y compris récemment). Si vous souhaitez gérer de A à Z vos DNS, renseignez-vous sur ces termes (c'est vraiment le strict minimum) : zone/resolver/XFER/glue/root/cache/split-horizon/pinpoint zone/DDNS/TTL/SOA/NS/A/AAAA/PTR/CNAME/TCP/UDP - et pour ceux qui s'intéressent à la sécurité : DNSSEC/DANE/HPKP/CAA. Petite précision tout de même, la notion de "sous-domaine" qu'on voit un peu partout n'existe pas. L'adresse www.nas-forum.com est un domaine au même titre que nas-forum.com. À la fin de ce tutoriel, vous aurez les éléments pour accéder à votre nas (ou à tout autre équipement) avec le même nom DNS que vous soyez chez vous, à distance via un VPN ou directement depuis Internet. Le DNS vous renverra à chaque fois la bonne adresse en fonction de votre emplacement. Mais je préfère vous avertir tout de suite, le DNS est un sujet bien plus complexe qu'il n'y parait. ###################################################################################### Notes de lecture Pour l'exemple, j'ai indiqué des valeurs fictives, il faudra donc les remplacer chez vous : fenrir.tuto : à remplacer par votre nom de domaine 192.168.0.2 : à remplacer par l'adresse IP privée de votre nas 192.0.2.3 : à remplacer par votre adresse IP publique (à ne pas confondre avec 192.168.x.y) www.fenrir.tuto : c'est un enregistrement d'exemple, vous pouvez en créer autant que nécessaire ns.registrar.externe : c'est le nom d'un serveur DNS qui fera office de serveur secondaire 1.2.3.4 : adresse IP d'un serveur qui fera office de serveur secondaire nb : les exemples sont en IPv4, mais le fonctionnement en IPv6 reste identique (il faut juste changer les adresses et remplacer les A par des AAAA). Ce tuto comporte 3 parties, par ordre croissant de difficulté : Cache DNS local : tout le monde devrait pouvoir y arriver en quelques cliques Zone DNS locale : cette partie devrait être abordable pour la plupart des utilisateurs Zone DNS publique : on change totalement d’échelle de difficulté ici, le principe est simple, mais la mise en œuvre peut être complexe Il n'y a aucune raison technique qui nécessite de faire la dernière partie, elle est là pour illustrer un peu plus le fonctionnement d'une architecture DNS, mais elle n'est en aucun cas nécessaire. Certains points ne seront pas abordés ou détaillés, mais il peut être utile, voir nécessaire de les mettre en œuvre, en particulier les zones de type "esclave" et inverses. Vous trouverez aussi pas mal d'informations complémentaires dans les commentaires, en particulier un retour très complet de @Mic13710 : --> cliquez ici <-- ###################################################################################### Pré requis Savoir faire des requêtes DNS, ça peut paraitre bateau dit comme ça, mais ce n'est pas aussi simple qu'un ping. Vous pouvez utiliser la commande "nslookup", elle est présente par défaut sur la plupart des systèmes (y compris les Synology). Je ne vais pas vous faire une doc, mais les 3 commandes importantes sont : demander les informations de zone : nslookup -querytype=SOA fenrir.tuto 192.168.0.2 demander la liste des serveurs de zone : nslookup -querytype=NS fenrir.tuto 192.168.0.2 demander la valeur d'un enregistrement : nslookup www.fenrir.tuto 192.168.0.2 Pour utiliser votre NAS comme serveur DNS, pour devrez modifier la configuration DNS de vos clients, le plus simple reste de le faire avec votre serveur DHCP, si vous utilisez une "box", ça ne sera surement pas possible, dans ce cas, utilisez le serveur DHCP du NAS (il est intégré par défaut dans tous les Synology depuis DSM 6.0 ou sous forme de paquet dans les versions précédentes). Si vous souhaitez héberger la résolution de votre domaine du point de vu d'Internet (donc être SOA et/ou NS), vous devez avoir une adresse IP fixe et disposer d'un second serveur DNS ailleurs. ###################################################################################### Cache DNS local Un cache DNS est un serveur DNS qui garde en mémoire les précédentes résolutions qu'il a du faire afin d'y répondre plus vite lors de nouvelles demandes. L'autre intérêt de disposer de son propre cache local et de s'affranchir des pannes et autres filtrages des serveurs DNS de votre opérateur Internet. Ce cache joue alors le rôle de "résolveur". C'est très rapide à mettre en place et ça consomme très peu de ressources, donc faites-le ! Commencez par installer et lancer le paquet DNS Server. Puis allez dans : Et configurez les options comme suit : nb : j'utilise les DNS de FDN comme "redirecteurs", car ils sont fiables et respectent votre vie privée (contrairement à ceux d'OpenDNS par exemple), mais vous êtes libre d'utiliser les serveurs de votre choix, voir aucun, votre serveur se chargera alors de l’ensemble des résolutions (ce n'est pas toujours très efficace). Alerte sur les DNS de FDN Edit du 04/03/2026 : Les résolveurs DNS de FDN ne sont plus accessibles en clair, sauf pour les membres de l'association. Voir le site de FDN. Les redirecteurs du tuto doivent être modifiés pour d'autres résolveurs. Voici une liste de résolveurs DNS accessibles en clair. Vous trouverez en fin de page des url vers d'autres sites proposant des serveurs alternatifs. Il est primordial de cocher la case "Limiter le service IP source" et de bien configurer son contenu. Si vous ne le faites pas, tout le monde pourra utiliser votre serveur DNS pour résoudre n'importe quel enregistrement, votre NAS en souffrira et sera peut-être utilisé pour des attaques vers d'autres cibles. Dans la "Liste d'IP source", mettez ces adresses : Maintenant il faut tester que ce serveur fonctionne correctement, le plus simple reste de lui poser une question : nslookup nas-forum.com 192.168.0.2 Vous devriez obtenir une adresse IP (au moment de la rédaction de ce tuto, c'est 5.196.244.24). Si vous n'obtenez pas de réponse ("timeout" ou encore "No response from server") c'est que vous n'arrivez pas à contacter le serveur DNS, dans ce cas il faut vérifier qu'il est bien lancé, que c'est la bonne IP, que le firewall autorise bien le trafic ...) Si vous obtenez une réponse du type "Query refused" c'est qu'il y a bien un serveur DNS en face, mais qu'il refuse votre question, donc soit vous lui parlez mal, soit il n'est pas autorisé à vous répondre (cf "Liste d'IP source" juste au dessus) Si le serveur vous répond correctement, vous en avez terminé pour le cache DNS et vous disposez maintenant d'un résolveur DNS local utilisable par tous vos clients (y compris ceux en VPN). N'oubliez pas de modifier votre serveur DHCP pour qu'il renseigne vos clients sur l'adresse de votre serveur DNS. ###################################################################################### Zone DNS locale Une zone DNS est un fichier dans lequel sont inscrits les enregistrements DNS d'un domaine. Un des avantages d'une zone locale c'est qu'elle n'a pas besoin d'exister sur Internet. Un usage courant de ce type de zone est de s'en servir pour donner des noms à ses équipements, plus simple facile à retenir que des adresses IP. Vous pouvez par exemple créer une zone "maison", elle sera fonctionnelle dans votre réseau pour faire nas.maison, routeur.maison, ... Vous pouvez aussi créer un domaine enfant du premier (par exemple cam.maison qui contiendrait vos caméras IP, comme salon.cam.maison) et qui sera soumis à d'autres restrictions. Néanmoins, je vous déconseille fortement d'utiliser un nom de domaine que vous ne possédez pas car ça risque de créer des problèmes de sécurité. Préférez l'usage d'un domaine que vous possédez, si vous n'en avez pas ça ne coute que quelques euros par an (on en trouve à 1€/an), même si vous n'avez pas prévu de vous en servir sur Internet. nb : il ne faut jamais utiliser le suffixe ".local", même en interne Si vous ne souhaitez pas acheter un nom de domaine, vous pouvez utiliser sans risques les noms suivants : .test, .example, .invalid et .localhost Pour la suite, j'ai utilisé le gTLD .tuto car il n'est pas enregistré au moment de la rédaction de cet article, mais rien ne dit qu'il ne le sera pas quand vous lirez ces lignes. Allez dans : Puis "Créez" => "Zone master" : Et configurez-la comme suit : Pour la "Liste d'IP source", mettez ceci : Puis sélectionnez votre zone et faites "Modifier" => "Enregistrement de ressource" : Enfin, créez une (ou plusieurs) ressource(s) du type CNAME : Par exemple : Vous devriez obtenir ça : Le nom www.fenrir.tuto renverra l'adresse de ns.fenrir.tuto, donc l'adresse IP privée de votre nas. Voici un exemple plus complet : Il se lit comme suit : fenrir.tuto de type NS : cet enregistrement indique que le serveur de nom (NS) pour le domaine "fenrir.tuto" est ns.fenrir.tuto ici j'ai gardé le nom créé par Synology, ns.fenrir.tuto, mais si vous souhaitez que votre NS s’appelle ratatouille.fenrir.tuto, aucun soucis (il faudra juste modifier le type A correspondant) nas.fenrir.tuto : il s'agit d'un "alias" qui renvoi la même chose que ns.fenrir.tuto c'est plus parlant que ns pour un nas wordpress.fenrir.tuto : un autre alias pour l'utiliser avec WebStation (vhost) ou avec un reverse proxy tv.fenrir.tuto : j'ai donné un nom à la tv on se demande bien pourquoi faire ? mail.fenrir.tuto : adresse du serveur de messagerie pour vos utilisateurs c'est un type A (pas un alias) car c'est important pour les enregistrements MX ns.fenrir.tuto : l'adresse du serveur DNS (l'enregistrement de la première ligne) il doit toujours s'agir d'un type A fenrir.tuto : il indique l'adresse du serveur de messagerie pour les autres serveurs de messagerie un MX doit pointer sur un type A Vous pouvez voir que j'ai indiqué plusieurs enregistrements avec le même nom mais un type différent ou encore plusieurs noms différents qui pointent sur la même IP, c'est parfaitement valable et ne pose aucun problème si vous restez cohérents. J'aurai aussi pu mettre des IP publique pour "nommer" des ressources externes (par exemple donner un nom à un autre nas hébergé je ne sais où). Notez aussi que les TTL ne sont pas tous les mêmes. nb : avant d'aller plus loin, faites des tests avec "nslookup" pour vérifier que tout fonctionne correctement. C'est terminé pour cette zone, mais nous allons lui associer une vue pour plus de sécurité et de contrôle. ###################################################################################### Vue DNS locale Pour simplifier, considérez qu'une vue DNS est un mécanisme permettent de donner des réponses différentes en fonction de l'adresse des clients. Ça revient à peu près à disposer de plusieurs serveurs DNS au même endroit, mais avec des données et des droits différents. Nous allons créer une vue pour nos clients locaux (ou vpn), ce n'est pas une obligation, mais ça simplifiera les choses pour la suite tout en ajoutant un peu de sécurité. Allez dans : Puis "Créer" : Ici on va limiter cette vue aux seuls clients locaux (ou vpn). Enfin, on sélectionne les zones qui seront dans cette vue : nb : encore une fois, il faut tester que tout fonctionne avant de continuer. Voilà, vous avez maintenant un serveur DNS local pleinement fonctionnel pour les rôles de cache, de résolveur et de serveur de zone. Mais vous pouvez faire pleins d'autres choses, tout dépend de votre niveau de connaissances et de compétences comme par exemple du filtrage de contenu indésirable (pub, facebook, malware, ...), du MitM, un annuaire, ... nb : vous pouvez aussi créer une vue dédiée à vos clients VPN afin qu'ils puissent atteindre votre nas via son adresse en 10.x (cf tuto vpn) simplement en entrant un nom DNS, il faudra juste bien penser à le limiter aux adresses VPN (en 10.x). ###################################################################################### Zone DNS publique Jusqu'à présent on ne s'est occupé que de nos clients locaux ou VPN mais pour permettre à un client sur Internet de résoudre une adresse, il faut créer une zone publique. Ici vous avez 3 possibilités. Utiliser des serveurs sur Internet, généralement ceux de votre bureau d'enregistrement, en tant que SOA et NS, dans ce cas la suite n'est pas nécessaire. Utiliser des serveurs sur Internet, généralement ceux de votre bureau d'enregistrement, en tant que NS, mais vous êtes SOA, ça peut être assez complexe à faire Être à la fois serveur SOA et NS, c'est le choix de l'indépendance, mais c'est aussi le plus complexe à faire Ici je vais prendre l'exemple d'un auto hébergement complet, vous êtes donc SOA et NS pour votre domaine. À ne faire que si vous commencez à être bien à l'aise avec les DNS ou pour tester et apprendre. Cette opération n'est pas triviale et nécessite plusieurs prérequis, pas toujours accessibles, je recommande donc de choisir la première option, elle devrait convenir à la plupart d'entre vous. Le résultat sera le même du point de vue résolution, cette étape n'est en aucun cas obligatoire pour se passer de QuickConnect ou pour avoir des réponses différentes entre le LAN et Internet. nb : il faut une adresse IP fixe et un autre serveur DNS pour la suite, si ce n'est pas votre cas, ceci ne fonctionnera pas, ou mal. Allez dans : Puis "Créez" => "Zone master" : Et configurez-la comme suit : nb : 192.0.2.3 est une adresse publique (réservée pour les documentations), à ne pas confondre avec 192.168.x.y On garde le même nom de domaine, mais on déclare l'IP publique pour le serveur DNS principal, par contre on ne limite pas le service à certaines IP source. Vous devriez obtenir ceci : La nouvelle zone est nommée fenrir.tuto(2). On va devoir faire un peu plus de réglages pour qu'elle soit fonctionnelle : Ici on doit bien faire attention aux différentes valeurs (par exemple l'adresse mail doit exister, mais attention, elle sera visible de tous) : nb : les valeurs ci-dessous peuvent ne pas convenir à tous les usages, adaptez-les si besoin Ensuite on procède comme précédemment pour créer les ressources : Cette fois ci, www.fenrir.tuto renverra l'adresse IP publique de votre NAS. (edit) : ce n'est pas dans la capture, mais il faut aussi créer un enregistrement pour le "naked domain", le domaine lui même, ça doit être un type A Nom : fenrir.tuto Type : A TTL : à vous de voir Information : 192.0.2.3 Quelques remarques sur le TTL : Un TTL (Time To Live) est la durée de validité d'une ressource, passé ce délai, les serveurs DNS vont supprimer cette entrée de leurs caches si vous mettez une valeur trop petite, vous ne profiterez pas du cache si vous mettez une valeur trop grande, les modifications mettront du temps à se propager ne mettez JAMAIS la valeur 0 sous peine de ne plus jamais pouvoir corriger un enregistrement ou qu'il ne fonctionne pas (selon les implémentations, 0 peut être considéré comme invalide, donc l'enregistrement sera rejeté ou pire, il sera considéré comme n'expirant jamais) ###################################################################################### Vue DNS publique Comme pour la zone locale, nous allons associer une vue à cette zone publique, cette fois-ci destinée à nos clients Internet. Allez dans : Puis faites "Créer" : Et sélectionnez bien la zone publique : Vous devriez obtenir ceci : Les clients avec des adresses privées se verront proposer le contenu de la vue LAN, donc de la zone fenrir.tuto Les autres clients se verront proposer le contenu de la vue WAN, donc de la zone fenrir.tuto(2) Il faut maintenant permettre aux clients sur Internet d'accéder à votre serveur. Ouvrez l'interface de votre routeur pour créer 2 règles de redirection de port : port 53 en TCP vers votre nas port 53 en UDP vers votre nas Il faudra aussi autoriser ces ports dans le firewall de votre NAS. Vous avez maintenant votre zone publique, que tout le monde peut consulter, sauf que personne n'en connait l'adresse ! ###################################################################################### NS public Pour que votre serveur DNS, donc votre NAS, soit référencé, il faut le déclarer dans les serveurs de votre TLD (pour un .fr, c'est l'AFNIC). C'est à faire auprès de votre bureau d'enregistrement (probablement là où vous avez acheté votre domaine). C'est une opération administrative, qui est soumise à certains contrôles techniques. Donc avant de commencer, vous devez vérifier que votre zone publique est bien configurée. Le plus simple et de faire le test sur https://www.zonemaster.fr/ Choisissez l'option "Test d'un domaine non délégué" et remplissez les différents champs comme suit : Vous ne devez avoir aucune erreur (les avertissements ne devraient pas être bloquants), mais si vous avez suivi le tuto, vous allez en avoir au moins une : Une architecture DNS se doit de disposer d'au moins 2 serveurs de nom (NS) pour une zone donnée. Il vous faut donc configurer un autre serveur DNS qui contiendra les mêmes valeurs que celles présentent dans votre NAS (le serveur secondaire recevra les données depuis votre NAS). nb : un DNS secondaire (on parle plutôt d'esclave ou slave en anglais) est un serveur qui contient une copie du fichier de zone, il ne peut pas en modifier le contenu Le plus simple pour ça et d'utiliser les serveurs DNS de votre bureau d'enregistrement, certains permettent de faire DNS "secondaire". Si ce n'est pas le cas il faudra trouver un autre serveur DNS acceptant de jouer ce rôle pour votre zone. Si vous avez plusieurs adresses IP publiques, il vous suffit de monter un autre serveur derrière l'une des autres adresses Vous pouvez aussi demander à un ami ou à de la famille de le faire (enfin, vous allez devoir le faire pour eux ), s'ils ont un Synology vous savez déjà comment vous y prendre Si vous êtes coincés, je peux faire office de NS secondaire, au moins le temps de la mise en place de votre architecture (envoyez moi un MP pour en discuter) Vous avez donc 3 choses à faire : Autoriser un autre serveur DNS à se synchroniser sur votre NAS (transfert de zone) L'ajouter comme serveur NS de la zone Et lui indiquer l'adresse de votre NAS pour qu'il se mette à jour (on parle ici de quelques ko maximum à transférer) Rendez-vous dans Sélectionnez la zone publique : Puis cliquez sur "Modifier" => "Paramètres de zone" : Activez le transfert de zone : Et spécifiez les adresses des serveurs qui vont faire office de DNS secondaire : Une fois ceci fait, il faut déclarer ces serveurs comme NS dans votre zone (toujours la zone publique de votre NAS) : Indiquez l'adresse du serveur secondaire : Vous devriez avoir ceci : Et enfin, configurez votre DNS secondaire pour qu'il se synchronise avec votre SOA (votre NAS), il suffit de créer une zone de type "slave" et de lui indiquer les bons paramètres. Une fois tout ceci en place, refaites le test zonemaster en indiquant vos 2 serveurs NS (votre NAS et le DNS de votre prestataire/ami/...) : Idéalement vous devriez obtenir un résultat similaire à celui-ci : nb : jusqu'à présent, tout ce que vous avez configuré n'est valable que pour vous et n'a aucun impact pour le reste des utilisateurs sur Internet, si vous avez un doute, c'est le moment ou jamais de faire pause. Si et seulement si le test est concluant (pas d'erreur bloquante), il faudra vous rendre une dernière fois sur l'interface de votre bureau d'enregistrement afin d'y spécifier les adresses de vos serveurs NS. L'opération prend en général quelques jours pour être appliquée partout. nb : vous serez peut être amenés à déclarer un enregistrement de type GLUE pour que ns.fenrir.tuto soit reconnu et puisse fonctionner comme NS de la zone fenrir.tuto, le problème est assez simple, si vous ne le voyez pas, documentez-vous avant de continuer Dernière précision, les vues isolent les zones, c'est le principe, donc si vous voulez voir apparaitre un même enregistrement dans les différentes vues, il faut le créer dans les différentes zones (comme le www.fenrir.tuto de mon exemple).

Bonjour, Vous venez d'acheter un NAS et vous ne savez pas par ou commencer, et bien nous allons voir ensemble les principales étapes les plus importantes et surtout prioritaires afin d'éviter de futurs problèmes ! Un NAS, c'est un serveur de stockage en réseau. Il est donc important que le système soit correctement installé et surtout sécurisé. Il est vivement recommandé de suivre toutes ces étapes ci-dessous et surtout d'essayer de les comprendre ! Si vous avez des questions, vous pouvez bien entendu les poser à la suite de ce tutoriel ou sur les tutoriels en question indiqués ci-dessous quand ça concerne un de ces derniers. INSTALLATION DE DSM Pour installer DSM, ce n'est pas compliqué et il suffit de suivre étape par étape ce qui est demandé sur votre écran. On va voir les grandes étapes ci-dessous : Recherche du NAS : On part du principe que vous avez déjà installer un (ou plusieurs) disques dur vierges dans votre NAS et que ce dernier est allumé. Vous avez même déjà entendu le bip sonore qui indique que le NAS est fonctionnel. Si vous ne savez pas comment aller consulter votre routeur pour connaitre l'adresse IP du NAS, je vous recommande de télécharger l'utilitaire "Synology Assistant" qui se chargera de trouver votre NAS sur votre réseau. https://www.synology.com/fr-fr/support/download Vous pouvez aussi essayer de le trouver en consultant ce lien : http://find.synology.com/ NOTE : certaines extensions de sécurité sur votre navigateur peuvent bloquer la recherche sur le réseau local ce qui a été mon cas sous Firefox ce qui m'a obligé à faire une recherche du NAS avec le navigateur Iridium pour ce tutoriel. Installation de DSM : (version 6.2.1 au moment de la rédaction de ce tutoriel) On a le choix entre l'installation de DSM en mode manuel ou en mode téléchargement. J'avais personnellement téléchargé le fichier .pat pour l'installer en local. Pour se faire, j'ai récupérer le fichier .pat sur mon ordinateur. Message d'avertissement qui préviens de la suppression des données sur les disques. On doit remplir ces champs qui sont dans l'ordre : nom du serveur > compte administrateur > mot de passe > confirmation du mot de passe. Ne mettez pas des noms génériques comme administrateur, administrator, admin etc... Et surtout utilisez un mot de passe long et compliqué. Le top étant une passphrase. Ex : Je suis allé avec ma femme chez le fleuriste en mai 2019. On nous demande si on veut utiliser le service QuickConnect. Je vous conseille de cliquer sur "Skip this step" (sauter cette étape). Comme expliqué un peu partout sur le forum, nous ne recommandons pas ce service ! En cliquant sur "Skip this step", nous obtenons ce message : "Si vous ignorez cette étape, vous devrez configurer la redirection de port pour accéder à distance à votre diskstation via Internet." Ca tombe bien, le tuto de Fenrir recommandé un peu plus loin dans ce tuto en parle de la redirection de ports 😜 L'installation de DSM commence. Une fois l'installation terminée, ça nous demande si l'on souhaite que le NAS sur le réseau soit reconnu pour le domaine find.synology.com Libre à vous de lire les conditions générales et d'accepter ou non. Perso, je refuse ! L'installation de DSM est persque terminée. On clique sur Got It. Et enfin, on nous demande si on veut partager des statistiques avec Synology (et peut-être avec d'autres partenaires de Synology comme Google). Libre à vous d'accepter ou refuser, perso, je refuse ! Voilà, DSM est installé 🙂 Nous recommandons aussi vivement de tester vos disques durs avant de les mettre en production. Pour se faire, je vous recommande ce très bon tuto. Choisir son RAID : Le système RAID (Redundant Array of Independent Disks) est une technologie de stockage qui permet de combiner plusieurs disques durs en un seul espace de stockage. Il existe différents types de RAID, chacun fournissant différents niveaux de performance, de capacité de stockage et de fiabilité. En gros car j'en ai certainement perdu quelques un d'entre vous, si on utilise par exemple un RAID 1 avec deux disques durs dans le NAS, ça veut dire que les premier disque dur est cloné sur le deuxième à l'identique. Si un des deux disque dur tombe en panne alors le serveur peut continuer à fonctionner sous réserve de remplacer rapidement le disque dur tombé en panne. NOTE : le système RAID est utilisé principalement pour de la continuité de service et en aucun cas comme de la sauvegarde ! Voici une page mise en place par Synology pour simuler/comparer un RAID. https://www.synology.com/fr-fr/support/RAID_calculator Pour choisir un type de RAID, vous pouvez aussi visiter ce lien : https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/StorageManager/storage_pool_what_is_raid En général, on appliquera un RAID 1 (SHR) pour deux disques durs et un RAID 5 (SHR) pour trois/quatre disques durs. Voici un guide qui en dira aussi pas mal sur les volumes, groupe de disques, RAID/SHR, système de fichiers etc... 😉 ALIMENTATION Onduleur : Il est important de prendre en compte que votre NAS contient de l'électronique et surtout des disques durs mécaniques. Ces disques durs et l’électronique n'aiment pas du tout les surtensions et encore moins les coupures de courant inopinées ! Nous vous recommandons donc vivement de mettre entre la prise électrique et le NAS ce qu'on appelle un onduleur afin d'éviter de subir des pertes de données et même pire votre matériel. Le but de l'onduleur sera de réguler correctement la tension mais aussi de prévenir en cas de soucis sur la ligne électrique. Dans ce cas, si c'est bien configuré, le NAS pourra passer en mode sans echec Pour plus d'explications sur le sujet, je vous renvoi vers cette page qui l'explique très bien : http://www.europ-computer.com/dossiers/dossier_6_18.html Dans le cas ou vous auriez un onduleur, il faut bien entendu l'ajouter au NAS. Il y a deux possibilités pour faire cela. Brancher l'onduleur sur le NAS directement Connecter le NAS à l'onduleur via son serveur si il est déjà sur un autre NAS par exemple. Nous allons voir la première possibilité. Branchez votre onduleur sur le NAS et rendez-vous sur : Panneau de configuration > Matériel et alimentation > UPS c'est ici que vous pourrez ajouter votre onduleur. Pour l'ajout d'un onduleur qui est en mode serveur, ça sera pratiquement la même chose. Extinction et/ou hibernation : Un NAS, ce n'est pas qu'un simple disque dur et nous ne recommandons pas d'éteindre votre NAS régulièrement. Nous sommes en 2019 et ces appareils ont été fabriqués pour tourner 7/7 H24. Le faite de redémarrer régulièrement un NAS (plusieurs fois par jour) peut user prématurément les disques durs. Quant à l'hibernation des disques durs, c'est vivement déconseillé de le faire sur un NAS ! Petite exception : Si comme moi ou d'autres membres, vous avez un NAS qui est destiné uniquement à recevoir et stocker des sauvegardes de temps en temps (une fois par jour par exemple), alors vous pouvez le configurer pour qu'il s'éteigne et s'allume automatiquement avant le lancement de la sauvegarde. Pour se faire, nous allons aller sur : Panneau de configuration > Matériel et alimentation > Planif. alim Sur cette fenêtre, on peut créer des règles pour éteindre ou allumer le NAS. On peut aussi laisser le NAS allumé en permanence et choisir uniquement de mettre en veille les disques durs (je rappelle que ce n'est pas conseillé de le faire régulièrement). Pour se faire, on se rend sur : Panneau de configuration > Matériel et alimentation > Hivernation du disque dur Et là, on peut choisir la durée de non utilisation des disques durs avant qu'ils ne passent en veille. Note : il faut prendre en compte que la sortie de veille peut prendre quelques instants. Pourquoi mes disques durs ne rentrent pas en hibernation ? Certains services désactivent l'hibernation des disques durs. Voici la liste de ces services : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Management/What_stops_my_Synology_NAS_from_entering_System_Hibernation SAUVEGARDE Il est aussi très important d'envisager un moyen de sauvegarde pour vos données. Pour se faire, je vous redirige vers ce tutoriel : SÉCURITÉ Sécurisation : Maintenant que votre NAS est installé et qu'il est fonctionnel, il faut penser en priorité à sa sécurisation. C'est le point le plus important avant de l'utiliser et vouloir le mettre en production ! Pour la sécurité de votre NAS, rien de mieux que de suivre le très bon tutoriel de Fenrir 😉 J'ajouterais que pour l'ouverture des ports, Synology répertorie tous les ports utilisés par défaut sur un NAS Synology. En voici le lien : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Network/What_network_ports_are_used_by_Synology_services Bien entendu, nous vous recommandons vivement d'utiliser uniquement les ports 80 (uniquement avec une redirection automatique) et 443 avec un Reverse Proxy d'installé (lien du tuto plus bas). Accès VPN : Si vous avez une bonne connexion internet et que vous voulez ouvrir votre NAS vers l'extérieur, nous vous recommandons aussi vivement d'utiliser un accès VPN. Pour se faire, autant continuer avec Fenrir et son super tuto 🙂 DIVERS Voici quelques petites astuces qui pourraient vous sauver la vie ou faciliter votre quotidien avec votre NAS. Journal : Pour avoir un aperçu de ce qui est fait sur le NAS, nous pouvons utiliser le paquet "Centre des journaux". Ce dernier se présente ainsi : On peut en cliquant sur l'onglet "Journaux" voir toute la journalisation du système sur le NAS. On peut aussi affiner une recherche : File Station : Pour la journalisation de ce qui est fait sur le NAS au niveau de la manipulation des fichiers, nous allons activer le journal de File Station. Ça aura pour conséquence de mémoriser dans le journal la création de répertoires/fichiers, modifications, suppressions etc... ce qui peut être pratique pour remonter à la source d'un problème rencontré. File Station > Paramètres Le journal se présentera comme ceci en détaillant ce qui a été fait et par qui. Corbeille : Je vous recommande vivement d'activer les corbeilles sur vos dossiers partagés. Ça aura pour conséquence qu'en cas de suppression accidentelle, vous pourrez avoir un moyen de récupérer ces données. Je pars du principe que si la corbeille n'est pas activée alors les données sont perdues définitivement. Il y a bien des moyens d'essayer de récupérer ses données mais ce n'est pas fiable à 100% et ça peut prendre beaucoup de temps. Autant l'appliquer de suite 🙂 NOTE : l'activation de la corbeille n'est pas généralisée pour tous les dossiers partagés. Il faut donc le faire pour chaque dossier partagé 😉 Dossier qu'on créer en direct : Dossier partagé déjà créé : Panneau de configuration > Dossier partagé > (clic droit sur un dossier partagé existant puis modifier) On peut ensuite aller voir notre dossier partagé et y trouver la corbeille. On peut bien évidemment consulter la corbeille et restaurer les données supprimées. Corbeille : On peut aussi programmer le vidage des corbeilles automatiquement. On se rend sur : Panneau de configuration > Dossier partagé > Action > Créer une planification de vidage de la Corbeille On est redirigé sur le planificateur de tâches et une nouvelle fenêtre s'ouvre. On lui donne un nom puis on se rend sur l'onglet "Programmer". On choisit la programmation souhaitée du lancement de la tâche puis on se rend sur "Paramètres de tâche". Ensuite, on a différent paramètres : Choix des corbeilles à vider. On peut choisir la corbeille d'un dossier partagé, de plusieurs dossiers partagés ou les corbeilles de tous les dossiers partagés. On peut appliquer une politique de conservation. Ex : pas de suppression des données ayant une ancienneté de moins de 7 jours. Nous avons aussi des paramètres avancés que je liste juste en dessous. Le bouton "Paramètres avancés" propose ceci comme options : Une fois validé, on retrouve la tâche dans le planificateur de tâche (désactivé pour le tuto) : Panneau de configuration > Planificateur de tâches Autres Nom de domaine Si vous comptez utiliser un nom de domaine, voici un sujet qui en parle : Avec ça, je vous recommande le tuto de Fenrir sur l'installation d'un serveur DNS : Puis pour aller un peu plus loin, l'utilisation d'un proxy inversé : FIN DU TUTO

Bonjour, EDIT 20/06/2021 §4 : Complément à la commande de création du certificat suite aux récentes évolutions du Shell script ACME. §6 : Ajout lié au renouvellement. Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu. EDIT 10/01/2021 § 5.1 : Ajout d’une astuce évitant un problème de renouvellement lié au cookie DID de la double authentification. EDIT 21/08/2020 § 6 : Évolution du script Python pour être aussi compatible de la dernière et actuelle version du langage Python : version 3.x.x § 10 : Mise à jour du texte d’aide associé à l’option « -h ». Suppression des fichiers de trace « cleanlog » et « cleanlogerr » qui n’apportaient rien de plus à la trace existante. Remaniement du fichier de trace pour que soit généré un nouveau fichier à chaque exécution du script. On dispose ainsi d’un historique « tournant » basé sur 9 fichiers : « acme_renew_python.log.1 » à « acme_renew_python.log.9 ». Le fichier à l’indice « 1 » étant toujours le dernier donc le plus récent. Nouvelle version v1.44 du script Python (à remplacer simplement dans le répertoire « /volume1/Scripts »). Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu. EDIT 11/08/2020 § 10 : Ajout d’une trace complète et systématique du processus de renouvellement. § 10 : Ajout de l’option « -f » au script Python de renouvellement. La partie configuration du renouvellement automatique du certificat au §6 a été revue grâce à l’aide de @bruno78 que je remercie vivement ici, pour prendre en compte une anomalie liée au Shell script « acme.sh » et à l’environnement particulier du NAS Synology. Cette anomalie ainsi que sa résolution, est décrite au § 10 ci-dessous. EDIT 01/06/2020 § 2 : Utilisation du "vrai" root pour la connexion SSH au lieu du "sudo -i" § 3.1 : Utilisation de l'Id principal de connexion OVH § 5.2.1 : Réaffectations de services à faire suite à la création du certificat en mode Ajout. Objectif de ce tutoriel : Créer un certificat « Wilcard » Let’s Encrypt (LE) afin : d’une part, de prendre en compte tous les domaines de second niveau de votre domaine personnel, et d’autre part, de s’affranchir de la limite fatidique de 256 caractères imposée par Synology pour les SAN (Subject Alternative Name – Autre nom de l’objet) lors de la création des certificats dans DSM. Pour mémoire, la méthode de création du certificat « wilcard » LE décrite dans le Tutoriel « Certificat TLS/SSL - Let's Encrypt "Wildcard" » de @unPixel utilisait le service ‘SSL For Free’. Malheureusement, ce service n’étant plus gratuit depuis le 18 mai 2020, il convenait alors pour moi de m’orienter sur un autre moyen pour obtenir un certificat « wilcard » LE et gratuit de surcroît. Nota : ‘SSL For Free’ fournit toujours gratuitement son service mais uniquement pour un seul nom de domaine du type « ndd.tld » (NomDeDomaine.Top-LevelDomain). En fouillant un peu la toile, j’ai fini par trouver cet autre moyen. Il est basé sur l’utilisation du client ACME via le Shell script « acme.sh » disponible sur GitHub. Je vous livre donc ci-après la méthode que j'ai suivie. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » 😊, mais pas que ... Sachez que c'est un mixte de différents tutoriels trouvés sur la toile, car aucun pris individuellement ne donnait complètement satisfaction vis-à-vis du but à atteindre et il fallait souvent s’adapter et/ou corriger en fonction de leurs contextes parfois légèrement différents. Je ne m’en cache pas, je n’ai pas réinventé la roue, vous retrouverez ici certaines explications directement extraites et traduites de ces tutoriels. Selon le cas, le lien vers l’original sera donné. Mais avant toutes choses, il convient pour mémoire, de faire un petit rappel contextuel. Depuis que Synology a introduit LE dans la gestion des certificats associés à ses NAS et Routeurs, beaucoup d'entre nous bénéficient du SSL gratuit et c’est très bien. D'un autre côté, beaucoup d'entre nous ne veulent pas exposer les ports 80 et 443 à Internet, y compris l'ouverture de ces ports sur le routeur. Malheureusement, l'actuelle implémentation Synology de LE ne prend en charge que la méthode de validation dite WEB, basée sur le protocole « HTTP-01 » qui nécessite d'exposer notamment le port 80 à Internet. Une alternative à cette non exposition est de passer par l’utilisation de la méthode de validation dite par DNS basée sur le protocole « DNS-01 ». Ce protocole présente l’avantage de ne pas avoir besoin d’ouvrir de ports lors de la création du certificat LE mais surtout lors de son renouvellement et là c’est le « plus » indéniable du point de vue sécurité qu’apporte cette méthode. Mais pour utiliser cette méthode de validation par DNS, il est obligatoire d’avoir la main sur la zone DNS du domaine concerné. En effet, LE vérifie la présence d’un enregistrement de type « TXT » sous la forme de « _acme‑challenge.votre-domaine.tld » contenant la valeur d’autorisation. Cet enregistrement permet de prouver que la personne qui demande le certificat, contrôle également la zone DNS du domaine en question. Il convient aussi de noter que le protocole « DNS-01 » est utilisé pleinement par les fonctions d’API (Application Programming Interface) développées par nos fournisseurs de domaines tels que OVH et que l’on va utiliser ici. Pour l’exemple, la méthode présentée ici, utilise les API de mon fournisseur OVH. Mais vous pouvez très bien utiliser les API d’un autre fournisseur car ACME prend en charge de nombreux autres services DNS. Il faudra alors adapter la méthode en fonction de ces autres fournisseurs. Rien de bien compliqué en soit, les paramètres diffèrent quelque peu mais le principe de mise en œuvre reste le même. Par ailleurs, l’utilisation du Shell script ‘acme.sh’ est rendu possible par le fait que nous pouvons accéder au NAS via une connexion SSH pour le configurer pour renouveler les certificats au lieu d'utiliser le tableau de bord WEB. Maintenant, cerise sur le gâteau si je puis dire, depuis peu Synology a introduit dans DSM le code nécessaire pour qu’il ne soit plus nécessaire d'exécuter le Shell script ‘acme.sh’ sur votre NAS pour renouveler le certificat. Le Shell script ‘acme.sh’ devra simplement être exécuté sur quelque chose (votre PC/Mac ou autre) qui a accès à l'interface d'administration de DSM. Du coup, les méthodes de déploiement du certificat généré sont considérablement simplifiées et c’est qui va être exploité dans la présente méthode. Voilà pour le discours préliminaire, on passe aux choses sérieuses … 1 Pré-requis · Disposer d’un nom de domaine personnel chez OVH. · Attribuer l’@IP externe de votre Box/Routeur à votre nom de domaine personnel. Pour cela, se rendre sur l'espace client d'OVH. Une fois connecté : Si vous avez une @IP fixe : aller dans l'onglet : « Web / Domaines / votre-domaine.tld / Zone DNS » vous devez avoir un enregistrement de type « A » dans le quel votre « votre-domaine.tld » pointe vers cette @IP fixe. Si vous avez une @IP dynamique : aller dans l'onglet : « Web / Domaines / votre-domaine.tld / DynHost » vous devez avoir une ligne avec « votre-domaine.tld » qui a pour cible votre @IP du moment (i.e. l’@IP externe de votre Box/Routeur). Ce même DynHost doit être également défini sur le NAS (« Panneau de configuration / Accès externe / DDNS » où le nom d’hôte est : « votre-domaine.tld ». 2 Installation du Shell script ‘acme.sh’ L’installation du Shell script ‘acme.sh’ doit s’effectuer dans un répertoire qui n’est pas modifié/réinitialisé lors des mises à jour de DSM. Pour ce faire, on va donc créer un répertoire spécifique d’installation « Certs/Acme_install » sous « /volume1 » et surtout pas sous le répertoire « /root » qui lui est régulièrement « nettoyé » par le système. Ce répertoire « /root » est également utilisé par défaut par ACME. Ceci expliquant cela. · Sous Windows ouvrir une session SSH sur le NAS (en tant qu’utilisateur « root ») avec « PuTTY » ou « WinSCP » · Sous Mac ouvrir une session SSH en lançant le « Terminal » puis tapez : ssh utilisateur-admin@ipdunas (si le port n'est pas 22 alors il faut rajouter « -pXXXXX » où XXXXX = No du port personnalié sudo -i (pour passer en « root » - c'est la procédure normale). · EDIT : Il s'avère que passer sous « root » via un « sudo -i» sur PC comme sur Mac, génère une erreur dans l'exécution de la commande « ./acme.sh». Aussi, je vous invite à suivre le Tuto sur les "Accès SSH et ROOT via DSM6" de @unPixel et ainsi de configurer un accès par le "vrai" « root ». Cela marche tout de suite bien mieux ... Nota 1 : Pour ma part sous Windows, je préfère l’utilisation de « WinSCP » à « PuTTY », tout simplement à cause de son interface graphique qui est très agréable de mon point de vue et aussi parce que l’on peut accessoirement directement sélectionner le texte affiché dans la Console pour le Copier/Coller ailleurs dans une autre application. C’est tout bête mais bien pratique au demeurant. Certes « PuTTY » le permet aussi mais je le trouve beaucoup moins souple de ce point de vue, et ce n’est que mon avis ... Nota 2 : Pour mémoire et ceci est valable pour toute la suite : le symbole « $ » présent en début des lignes de commandes Shell présentées ici, est ce qu’on appelle l’invite de commande du Shell. Dans le cas présent, il est propre à l’outil « WinSCP » que j’ai utilisé pour exécuter les différentes commandes Shell de cette procédure. Bien évidemment, il ne faut pas le sélectionner si vous faites des Copier/Coller du texte de ces commandes. Je préfère prévenir même si c’est évident pour certains initiés … · Tapez successivement les commandes suivantes : On crée le répertoire d’installation d’ACME : « /volume1/Certs/Acme_install » et on s’y place : $ cd /volume1 $ mkdir -p Certs/Acme_install $ cd Certs/Acme_install On télécharge ACME chez GitHub $ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz On décompresse le fichier téléchargé et on se place dans le répertoire qui a été automatiquement créé lors de la décompression : $ tar xvf master.tar.gz $ cd acme.sh-master On lance l’installation d’ACME (pensez avant à remplacer dans la commande : « email@gmail.com » par votre @Mail personnelle) $ ACME_HOME="/usr/local/share/acme.sh" $ CERT_HOME="/volume1/Certs" « CERT_HOME » est le répertoire où seront générés les fichiers du certificat. Vous pouvez l’adapter à besoins. $ ./acme.sh --install --nocron --home "$ACME_HOME" --cert-home "$CERT_HOME" --accountemail "email@gmail.com" --nocron : spécifie de ne pas installer par défaut le « cron job ». Vous comprendrez de vous-même pourquoi plus loin. --home : désigne le répertoire « customisé » d’installation du Shell script ‘acme.sh’. C’est un répertoire dit « invariant ». C’est-à-dire qu’il n’est pas modifié par les mises à jour de DSM. Sinon par défaut, le script aurait été installé dans « ~/.acme.sh » où « ~ » correspond au répertoire ‘home’ de l’utilisateur « root » en l’occurrence : « /root ». Pour mémoire le répertoire « /root » est lui, dit « variant », donc sujet à modifications par les mises à jour de DSM. --cert-home : désigne le répertoire où seront générés les fichiers du certificat « wilcard » LE. Cette disposition permet de les sécuriser d’une part et d’autre part permet de les rendre accessibles facilement sans avoir à replonger dans les acarnes de DSM pour les retrouver en cas de besoin autre. Nota :Pour votre information, ce répertoire n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ». Durant la courte installation, vous aurez certainement un message du style : It is recommended to install socat first. We use socat for standalone server if you use standalone mode. If you don't use standalone mode, just ignore this warning. Il faut savoir que ‘Acme.sh’ recommande l'installation du paquet « socat » pour gérer les certificats en mode standalone, mais comme nous n'allons pas utiliser ce mode, vous pouvez largement ignorer ce message. Vous trouverez donc, le dossier d'installation d’ACME dans le répertoire : « /usr/local/share/acme.sh ». Maintenant, il faut régénérer le fichier « .profile » de l'utilisateur courant (« root ») pour pouvoir utiliser immédiatement les commandes Shell. Pour cela, tapez simplement : $ source ~/.profile · Vérifier si besoin les droits d'exécution du fichier « acme.sh » : $ cd $ACME_HOME $ ls -al Normalement c’est bon mais si besoin, tapez : $ chmod a+x acme.sh · On active la mise à jour automatique du client (c’est préférable mais ce n’est pas une obligation) : $ ./acme.sh --upgrade --auto-upgrade Nota 1 : si vous souhaitez désactiver la mise à jour automatique d’ACME, tapez : $ ./acme.sh --upgrade --auto-upgrade 0 Comme vous pouvez aussi commenter manuellement la ligne : AUTO_UPGRADE="1" dans le fichier « /usr/local/share/acme.sh/account.conf » par l’ajout du caractère « # » en tout début de ligne. Nota 2 : Si vous êtes curieux et que vous souhaitez voir toutes les commandes disponibles pour ACME, tapez : $ ./acme.sh --help NE PAS quitter la session SSH 3 Configuration DNS 3.1 Création des clés Pour générer un certificat « wilcard » et pouvoir le renouveler automatiquement, on va donc utiliser l’API d’OVH. Pour ce faire, on va créer une application dans l’API qui va nous permettre de générer trois clés nommées respectivement : « application key », « application secret » et « consumer key ». Il est aussi une bonne pratique de sécurité que de limiter ce qu'une clé API donnée peut faire, dans le cas où elle serait perdue, volée ou que quelque chose de mal se produirait et ce, pour en limiter les dommages potentiels. Cela tombe bien, les clés API OVH peuvent être limitées à une zone de domaine spécifique à l'aide d'un mécanisme de modèle simple. On va donc en profiter pour restreindre une clé API OVH à la gestion de « votre-domaine.tld », en utilisant les paramètres suivants : GET=/domain/zone/votre-domaine.tld/* &POST=/domain/zone/votre-domaine.tld/* &PUT=/domain/zone/votre-domaine.tld/* &GET=/domain/zone/votre-domaine.tld &DELETE=/domain/zone/votre-domaine.tld/record/* Il est clair que cela peut facilement être personnalisé pour prendre en charge un ou plusieurs domaines si le besoin en est. Je vous renvoie à la documentation en ligne d’OVH pour plus de détails. · On se rend donc sur l’API d’OVH en saisissant l’URL suivante dans un navigateur WEB : https://api.ovh.com/createToken/?GET=/domain/zone/votre-domaine.tld/*&POST=/domain/zone/votre-domaine.tld/*&PUT=/domain/zone/votre-domaine.tld/*&GET=/domain/zone/votre-domaine.tld&DELETE=/domain/zone/votre-domaine.tld/record/* Nota : Dans le cas où vous ne souhaiteriez pas restreindre la gestion de la clé API OVH à votre domaine, il suffit simplement d’utiliser les paramètres suivants : ?GET=/domain/zone/* &POST=/domain/zone/* &PUT=/domain/zone/* &DELETE=/domain/zone/*/record/* o L’URL à utiliser pour aller sur l’API d’OVH, est alors : https://api.ovh.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/* · Donc avec le premier cas, on arrive sur l’écran suivant : Nota : Dans le second cas l’écran est très similaire, je vous laisse vous adapter. · On saisit les informations : o Account ID : votre identifiant principal de connexion chez OVH Nota : Si vous utilisez votre @Mail vous aurez un message d’erreur lors de la création des clés. o Password : votre mot de passe de connexion chez OVH. o Script name : Ce que vous voulez (par ex : « Synology_acme_sh ») mais avec que des caractères, pas d’espaces ni de points et pas de caractères spéciaux sinon cela bloque. o Script description : Ce que vous voulez (par ex : « Certificat wilcard LE – ACME ». o Validity : Dans le popup sélectionnez l’item « Unlimited ». · On clique en fin sur le bouton « Create keys ». · On obtient l’écran suivant, où il convient immédiatement de copier les clés et de les sauvegarder dans un fichier « .txt » : 3.2 Retour dans la session SSH · Taper successivement les commandes suivantes : $ export OVH_END_POINT=ovh-eu $ export OVH_AK="votre application key" $ export OVH_AS="votre application secret" $ export OVH_CK="votre consumer key" 4 Création du certificat Avant de créer effectivement le certificat il convient de préciser un point sur la méthode de chiffrement associée à la génération du certificat LE. Sans aucun paramètre spécifique, ACME utilise une clé de chiffrement de type RSA fixée à 2048 bits par défaut. Dans notre cas, on va directement forcer cette clé RSA à 4096 bits pour renforcer le niveau de sécurité, ce qui se fait par l’emploi du paramètre « -- keylength 4096 » dans la commande de création du certificat. Maintenant pour ceux qui le souhaitent, on peut aussi passer en mode « paranoïaque » et poussez plus loin les choses en adoptant un chiffrement basé sur une clé ECDSA qui elle s’appuie sur des courbes elliptiques. Malgré une faible longueur, ces clés sont très robustes et peut-être bien plus sécures que les clés RSA et sachant aussi que ces dernières sont déjà bien suffisantes pour nos besoins courants. Pour comparaison, une clé ECDSA 256 bits est équivalente à une clé RSA 3072 bits, et une clé ECDSA 384 bits est équivalente à une clé RSA 7680 bits ! À noter que LE reconnait les courbes elliptiques P-256 et P-384 mais le P-521 n'est pas encore reconnu. Donc dans ce dernier cas de figure, le paramètre à employer serait par exemple : « -- keylength ec-394 ». A vous de voir … Bon, il est maintenant vraiment temps de créer le certificat « wilcard » LE pour « votre-domaine.tld » : · Tapez successivement les commandes suivantes : $ cd $ACME_HOME $ export CERT_DOMAIN="votre-domaine.tld" $ export CERT_WDOMAIN="*.votre-domaine.tld" $ export CERT_DNS="dns_ovh" $ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt Edit du 20/06/2021 : Suite aux récentes évolutions du Shell script ACME la commande de création du certificat doit être complétée par deux options. En effet, dorénavant lors de la création d'un nouveau certificat, par défaut c'est un certificat ZeroSSL qui est créé par ACME. Donc dans notre cas, comme l'on veux générer un certificat LesEncrypt, on doit ajouter les options suivantes à la commande de création pour forcer la génération du certificat LE : --set-default-ca --server letsencryp ainsi le shell script ACME prendra en compte ce choix qu'il retiendra d'ailleurs par la suite lors du renouvellement du certificat. Le processus de création du certificat se déroule et affiche un message du type : /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" [Sun May 24 22:42:07 CEST 2020] Create account key ok. [Sun May 24 22:42:07 CEST 2020] Registering account [Sun May 24 22:42:08 CEST 2020] Registered [Sun May 24 22:42:08 CEST 2020] ACCOUNT_THUMBPRINT='l7IOxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfro' [Sun May 24 22:42:08 CEST 2020] Creating domain key [Sun May 24 22:42:13 CEST 2020] The domain key is here: /volume1/Certs/votre-domaine.tld/ votre-domaine.tld.key [Sun May 24 22:42:13 CEST 2020] Multi domain='DNS:votre-domaine.tld,DNS:*.votre-domaine.tld' [Sun May 24 22:42:13 CEST 2020] Getting domain auth token for each domain [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='votre-domaine.tld' [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='*.votre-domaine.tld' [Sun May 24 22:42:15 CEST 2020] Adding txt value: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:42:15 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:42:15 CEST 2020] Checking authentication [Sun May 24 22:42:16 CEST 2020] Consumer key is ok. [Sun May 24 22:42:16 CEST 2020] Adding record [Sun May 24 22:42:17 CEST 2020] Added, sleep 10 seconds. [Sun May 24 22:42:27 CEST 2020] The txt record is added: Success. [Sun May 24 22:42:27 CEST 2020] Adding txt value: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:42:27 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:42:27 CEST 2020] Checking authentication [Sun May 24 22:42:27 CEST 2020] Consumer key is ok. [Sun May 24 22:42:27 CEST 2020] Adding record [Sun May 24 22:42:28 CEST 2020] Added, sleep 10 seconds. [Sun May 24 22:42:38 CEST 2020] The txt record is added: Success. [Sun May 24 22:42:38 CEST 2020] Let's check each dns records now. Sleep 20 seconds first. [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld [Sun May 24 22:42:58 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success. [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld [Sun May 24 22:42:59 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success. [Sun May 24 22:42:59 CEST 2020] All success, let's return [Sun May 24 22:42:59 CEST 2020] Verifying: votre-domaine.tld [Sun May 24 22:43:02 CEST 2020] Success [Sun May 24 22:43:02 CEST 2020] Verifying: *.votre-domaine.tld [Sun May 24 22:43:06 CEST 2020] Success [Sun May 24 22:43:06 CEST 2020] Removing DNS records. [Sun May 24 22:43:06 CEST 2020] Removing txt: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:43:06 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:43:06 CEST 2020] Checking authentication [Sun May 24 22:43:06 CEST 2020] Consumer key is ok. [Sun May 24 22:43:09 CEST 2020] Removed: Success [Sun May 24 22:43:09 CEST 2020] Removing txt: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:43:09 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:43:09 CEST 2020] Checking authentication [Sun May 24 22:43:09 CEST 2020] Consumer key is ok. [Sun May 24 22:43:13 CEST 2020] Removed: Success [Sun May 24 22:43:13 CEST 2020] Verify finished, start to sign. [Sun May 24 22:43:13 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxx/xxxxxxxxxxxxxx [Sun May 24 22:43:14 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5c1f [Sun May 24 22:43:15 CEST 2020] Cert success. -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- [Sun May 24 22:43:15 CEST 2020] Your cert is in /volume1/Certs/votre-domaine.tld/votre-domaine.tld.cer [Sun May 24 22:43:15 CEST 2020] Your cert key is in /volume1/Certs/ votre-domaine.tld/votre-domaine.tld.key [Sun May 24 22:43:15 CEST 2020] The intermediate CA cert is in /volume1/Certs/votre-domaine.tld/ca.cer [Sun May 24 22:43:15 CEST 2020] And the full chain certs is there: /volume1/Certs/votre-domaine.tld/fullchain.cer Voilà déjà une bonne chose de faite … NE PAS quitter la session SSH 5 Déploiement du certificat Comme expliqué en préambule, Synology nous a facilité la vie pour le déploiement des fichiers du(des) certificat(s) généré(s). Cela se passe par l’emploi du « Synology DSM deployhook ». 5.1 Cas de la double authentification Si vous n’utilisez pas la double authentification pour vous connecter à votre NAS, passez directement au §5.2 ci-dessous. Mais avant de réaliser le déploiement effectif du certificat, il y a encore un point préciser car il y a un paramètre supplémentaire à prendre en compte dans le cas où, comme moi vous utilisez la double authentification pour vous connecter à votre NAS. En effet, si on ne renseigne pas ce paramètre, le processus de double authentification viendrait bloquer le déploiement du certificat tel qu’il sera décrit ci-après. Ce serait dommage convenez-en. Donc, habituellement lorsqu’on se connecte au NAS après avoir saisi son id/pseudo et son mot de passe, la double authentification réclame la saisie d’un code à six chiffres que l’on obtient à partir d’une application tierce installée idéalement sur un smartphone/iPhone. Pour n’en citer que quelques-unes, il y a : « FreeOTP Authenticator », « Google Authenticator », « Microsoft Authenticator », etc … (le choix est grand ! - pour la mise en place de la double authentification sur le NAS, reportez-vous à l’excellent Tutoriel de @Fenrir sur la sécurisation des accès au NAS). Bref, on récupère et on saisit donc ce code à six chiffres et on coche la case « Faire confiance à ce périphérique ». Cette dernière action a pour effet caché de créer un « cookie » dans votre navigateur qui lui, évite par la suite que ce code à six chiffres, ne vous soit systématiquement demandé à chaque connexion. Ce « cookie » stocke en interne un code nommé « DID » dont il nous faut récupérer la valeur pour alimenter le paramètre suscité. Pour récupérer la valeur de ce code « DID », normalement un simple clic gauche sur le cadenas situé à gauche de la barre d’URL du navigateur, suivi de la sélection de l’item « cookies » permet d’afficher ce code « DID ». Sauf que cela ne marche pas avec le navigateur FireFox. Pour contourner le problème, j’ai installé l’excellent module complémentaire « Cookie Quick Manager » dans FireFox. Ensuite on procède ainsi : · Se placer sur la page de connexion ou si déjà connecté, sur la page du navigateur affichant le bureau DSM de votre NAS. · Dans le popup de « Cookie Quick Manager », clic gauche et sélectionner l’item « Rechercher les cookies pour : URL de la page suscitée ». Cela peut-être selon : « https://nom-du-nas.ndd.tld » ou http://@IP_du_NAS:5000 ou encore « https://@IP_du_NAS:5001 ». · Une nouvelle page s’ouvre dans le navigateur, vous montrant tous le détail du cookie associé à la page du NAS. · Dans la partie droite de cette page, on trouve la valeur du fameux code « DID ». · Sélectionnez et Copiez cette valeur et refermez la page du cookie. · Revenez sur la session SSH et tapez la commande suivante en y collant la valeur du « DID » : $ export SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx Edit du 10/01/2021 Suite au retour de plusieurs utilisateurs dont le renouvellement du certificat avait échoué avec un message du style : « Tue Dec 15 15:58:28 CET 2020] Unable to authenticate to localhost:5000 using http. [Tue Dec 15 15:58:28 CET 2020] Check your username and password. » voici la « parade ». En fait, ce message survient parce que le cookie DID est périmé. Il s’avère qu’il n’a en fait qu’une durée de vie d’un mois et qu’il change donc tous les mois. Aussi, toute l’astuce va être d’aller éditer le cookie et de modifier sa date de péremption pour la repousser aux « calandres grecques ». Donc pour cela, comme expliqué ci-avant, vous éditez le cookie DID et vous modifiez le champ « expire » en indiquant une date en 2050 par exemple. Cela devrait suffire 😀. Dans le cas, où le cookie DID aurait changé, il vous faut alors aller modifier, dans une session SSH sous l’utilisateur « root » avec PuTTY ou WinSCP sur Windows ou dans un Terminal sur Mac, le fichier « /volume1/Certs/votre-domaine.tld/votre-domaine.tld.conf » pour mettre en accord la valeur de votre nouveau cookie DID avec le contenu de la variable « SAVED_SYNO_DID » sauvegardée par le système dans ce fichier. Ajout du 2021-02-15 : Il faut aussi mettre en accord la variable « SAVED_DID » qui se trouve elle, dans le fichier « /usr/local/share/acme.sh/account.conf ». Toujours pareil, attention lors du copier/coller de la valeur à ne pas prendre de caractères parasites ! N’oubliez pas aussi d’enregistrer le fichier à l’issue de vos modifications. Ainsi, plus de soucis de renouvellement à ce niveau … 5.2 Réalisation du déploiement du certificat Nota préliminaire : Tout ce qui suit présume que vous n’avez pas quitté la présente session SSH. Sinon, il faut réexporter toutes les variables définies précédemment. Sans quoi rien ne fonctionnera correctement ! Ce serait dommage, non ? Maintenant, deux cas de figure se présentent selon que l’on procède à un déploiement du nouveau certificat : · avec un mode « Annule et remplace » du certificat existant marqué « par défaut », · ou que l’on se contente d’ajouter simplement le nouveau certificat à la liste existante de vos certificats. Vous avez le choix, c’est vous qui décidez … 5.2.1 Mode « annule et remplace » du certificat par défaut Rappel : Ici on va ECRASER le certificat marqué par défaut dans le tableau de bord de DSM. Il n’existera plus !!! Vous êtes prévenus … · Dans la session SSH tapez successivement les commandes suivantes : o Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ». $ pwd o Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes : # export SYNO_Scheme="http" Par défaut : « http » mais on peut fixer à « https » # export SYNO_Hostname="localhost" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront. # export SYNO_Port="5000" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS. o On poursuit les définitions de variables d’environnement : Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse. $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123' La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir remplacer le certificat par défaut, il est nécessaire de spécifier une chaîne vide pour ce paramètre. Ne me demandez pas pourquoi ! (si un « initié » sait, je corrigerai en conséquence avec l’explication du pourquoi). $ export SYNO_Certificate="" · Et on déploie enfin le certificat … $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm 5.2.2 Mode « ajout » du nouveau certificat Ici, on va simplement ajouter le nouveau certificat à la liste des certificats éventuellement déjà présents sur le NAS. Le processus est sensiblement le même que celui décrit au §5.2.1 ci-dessus. · Dans la session SSH tapez successivement les commandes suivantes : o Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ». $ pwd o Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes : Par défaut : « http » mais on peut fixer à « https » # export SYNO_Scheme="http" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront. # export SYNO_Hostname="localhost" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS (dans ce dernier, il faut ajouter l'option "--insecure" à la commande de déploiement donnée plus loin). # export SYNO_Port="5000" o On poursuit les définitions de variables d’environnement : Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse. $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123' La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir ajouter le nouveau certificat, il est nécessaire de spécifier une chaîne non vide pour ce paramètre. Là, cela paraît évident … (Quoi que …) Vous nommez votre certificat comme bon vous semble. Pour ma part je lui donne le nom qui précise mon domaine « ACME_Wilcard_LE_*.ndd.tld » pour plus de clarté. Encore une fois, c’est vous qui voyez … $ export SYNO_Certificate="Nom_du_certificat" o Une dernière variable d’environnement : Par défaut : ce paramètre est sur « off » et n’est pas enregistré mais on peut le fixer à « 1 » pour indiquer au système de créer le certificat s’il n’existe pas déjà. $ export SYNO_Create=1 · Et on déploie enfin le certificat … $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm Dans cette commande, pour le cas où vous le souhaiteriez, on peut préciser un domaine de second niveau. La commande est alors : $ ./acme.sh --deploy -d "secondNiv.$CERT_DOMAIN" --deploy-hook synology_dsm Nota : On peut remarquer dans le message ci-dessus la ligne : « http services were NOT restarded », ne sachant pas ce qu’il faut en faire, je l’ai provisoirement ignorée. Je n’ai d’ailleurs pas constaté par la suite de disfonctionnements qui lui soient liés. Cela dit, je compte sur les « initiés » pour me dire s’il y a une quelconque action à exécuter vis-à-vis de ce message. D’avance merci, je mettrai à jour la présente procédure en conséquence. Toujours est-il, le nouveau certificat est maintenant visible dans « Panneau de configuration / Sécurité /Certificat » de DSM : Ici par défaut on constate que : · d’une part le nouveau certificat a été automatiquement marqué pour une utilisation « par défaut », · • et d’autre part là, deux cas de figures peuvent se présenter : Soit vous êtes dans le cas d’une toute première création du certificat i.e. aucun autre certificat pour « votre-domaine.tld » n’existait auparavant, alors il est obligatoire de réaliser une affectation manuelle du certificat aux services qui vont l’utiliser pour une bonne prise en compte de celui-ci. Pour cela : Sélectionnez le certificat. Cliquez sur le bouton « Configurer » et affectez le certificat aux services de votre choix en le sélectionnant dans le popup en regard du service concerné. Soit vous êtes dans le cas d’une nouvelle création du certificat avec déjà un certificat pour « votre-domaine.tld » existant auparavant, alors avec cette création, le constat est qu’il n’a pas repris les assignations aux services qui existaient pour le certificat précédemment marqué par défaut. Il vous faut alors reprendre ces assignations manuellement. Toujours pareil, vous adaptez à votre besoin … Nota : Dans ce dernier cas, sachez que ce comportement est normal puisque l’on crée le certificat. Un dernier constat : on ne le voit pas sur la copie d’écran, mais bien évidemment, le certificat précédemment marqué pour une utilisation par défaut, n’a pas disparu. Il est bien toujours présent dans la liste des certificats. Il n’est tout simplement plus marqué pour une utilisation par défaut. Rien n’a été perdu, c’est ce qui importe ! NE PAS quitter la session SSH 6 Configurer le renouvellement du certificat Maintenant que le certificat « wilcard » LE a été créé et déployé sur le NAS, il faut assurer son renouvellement à l’échéance fatidique de 3 mois. En fait, cette échéance est variable dans le sens où selon la date de génération du certificat il peut se passer entre 89, 90, 91 et 92 jours. Mais en pratique lors de son exécution, le script « acme.sh » contrôle par défaut si la date courante est supérieure de plus de 60 jours par rapport à la date de création du certificat avant de lancer ou non le renouvellement effectif de celui-ci. Par sécurité, on ne va pas « s’embêter », on va programmer tout simplement cette opération de contrôle du besoin de renouvellement, avec une exécution hebdomadaire à un horaire de faible charge du NAS (par exemple tous les Lundi et donc a priori la nuit soit à 00h00). Libre à vous de modifier cette périodicité selon vos propres besoins. C’est vous qui voyez … Mais avant toute choses, on va installer un petit programme/script écrit en langage Python (Encore MERCI à @bruno78 qui l’a développé) destiné à compléter l’action normale du script « acme.sh » en réalisant un certain nombre d’autres opérations spécifiques et rendues nécessaires par l’environnement du NAS Synology (pour les plus curieux, ces actions sont explicitées en détail au § 10 ci-dessous). Rassurez-vous, vous n’avez pas besoin de connaître le langage Python. Celui-ci est nativement géré par le NAS Synology au travers du package « Python module ». Vérifiez juste que ce package est bien installé sur votre NAS et auquel cas installez le via le centre de paquets. EDIT 21/08/2020 Le script Python est maintenant compatible de la dernière et actuelle version 3.x.x du langage Python. Si vous envisagez d’utiliser Python3 il vous faut alors installer le package « Python3 » disponible dans la rubrique « Outils de développement » dans le centre de paquets de DSM. Donc, le package « Python module » ou le package « Python3 » étant installé : Créez un répertoire spécifique pour accueillir ce script Python : On crée le répertoire : « /volume1/Scripts » et on s’y place : Nota 1 : Ce chemin peut être tout autre selon vos besoins, mais veillez à rester cohérent dans son utilisation par la suite. Nota 2 : Ce répertoire, tout comme le répertoire « Volume1/Certs » créé précédemment, n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ». $ cd /volume1 $ mkdir -p Scripts $ cd Scripts Téléchargez sur votre PC/Mac le fichier du script Python : acme_renew.py Copiez/Collez ce fichier sur le NAS dans le répertoire « /volume1/Scripts ». (via WinSCP c’est on ne peut plus simple !). Le script Python étant en place, on va programmer effectivement l’exécution périodique de ce script. Nota :En préalable et pour ceux qui seraient tentés de le faire, il faut également savoir qu’Il n'est pas conseillé de configurer directement un « cron job » personnalisé car le conseiller de sécurité DSM va rapidement vous rappeler à l’ordre et vous dira que vous avez un avertissement critique concernant un ou des cron job(s) inconnu(s). Donc pour ce faire, on va configurer une tâche dans le planificateur de tâches de DSM. · Dans « Panneau de configuration / Planificateur de tâches », cliquer sur le bouton « Créer » et sélectionner dans le popup : « Tâche planifiée / Script défini par l’utilisateur » · Dans la fenêtre « Créer une tâche » onglet « Général » nommez la tâche à exécuter périodiquement. Par exemple : « RenewCertif_W_LE ». L’utilisateur doit être « root » et la case « Activé » est cochée. · Dans l’onglet « Paramètres de la tâche » : o Pour la partie « Paramètres généraux » : si vous voulez recevoir par eMail les détails d’exécution de la tâche : cochez la case correspondante et saisissez votre @Mail. Vous pouvez aussi décider de ne recevoir ces eMails uniquement si l’exécution de la tâche se termine de façon anormale. Dans ce cas cochez la case correspondante. o Pour la partie « Exécuter la commande » : saisir la commande suivante : python /volume1/Scripts/acme_renew.py -l votre-domaine.tld Ou si vous souhaitez utiliser la version sous « Python3 » : python3 /volume1/Scripts/acme_renew.py -l votre-domaine.tld Dans cette commande : - Le chemin d’accès au script « acme_renew.py » (ici « /volume1/Scripts/ ») devra être modifié selon que vous en aurez défini un autre ci-avant. - Le paramètre « -l » est quant à lui optionnel. Libre à vous de l’indiquer ou pas. Néanmois je ne peux que vous conseiller de le mentionner pour le cas où … On n’est jamais trop prudent. Si vous l’indiquez explicitement, sachez qu’à chaque renouvellement, un fichier de « log » nommé « acmelog » sera automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew/ » lui-même créé automatiquement par le script Python. Donc si un quelconque problème survenait, vous disposerez alors d’une trace complète de toutes les opérations réalisées lors du processus de renouvellement du certificat« wilcard » LE. Si tout est OK, vous aurez tout de même une trace mais forcément « light ». - Le paramètre « votre-domaine.tld » est quant à lui OBLIGATOIRE et est bien évidemment à remplacer par l’intitulé de votre propre domaine pour lequel le certificat doit être renouvelé. · Dans l’onglet « Programmer » : o Sélectionner « Exécuter les jours suivants » o Dans le popup, cochez la case « Lundi ». o Dans la zone « Temps » : laisser les valeurs par défaut. · Valider l’ensemble de votre paramétrage en cliquant sur le bouton « OK ». EDIT du 20/06/2021 : Suite aux récentes évolutions du Shel script ACME (voir plus haut pour la commande de création du certificat) il n'y a normalement rien à faire si vous disposer déjà d'un certificat LE. Le Shell script ACME de lui même s'adapte et assure le rouvellement de votre certificat comme avant. Toutefois, afin de s'assurer et forcer ce renouvellement avec LetEncrypt, il convient d'ajouter (sous SSH à la fin du fichier) la ligne suivante dans votre fichier "account.conf" (/usr/local/share/acme.sh/account.conf) : DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' 7 En cas de problème suite à une mise à jour de DSM En cas de problème suite à une mise à jour de DSM, on peut réparer l’environnement ACME en exécutant les commandes suivantes dans une session SSH sous l’utilisateur « root » : $ cd /usr/local/share/acme.sh $ ./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh Vous pouvez aussi ajouter la ligne suivante dans le fichier « /root/.profile » et régénérer le « .profile » en tapant : . "/usr/local/share/acme.sh/acme.sh.env" $ source /root/.profile 8 Arrêter le renouvellement du certificat Pour arrêter le renouvellement d’un certificat, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes pour supprimer le certificat de la liste de renouvellement : $ cd /usr/local/share/acme.sh $ ./acme.sh --remove -d votre-domaine.tld Les fichiers « .cert » et « .key » de votre certificat ne sont pas supprimés du disque. Vous pouvez supprimer le répertoire correspondant (par exemple : « /volume1/Certs/votre-domaine.tld ») par vous-même. 9 Un dernier truc utile Vous pouvez éventuellement avoir besoin de convertir votre certificat en un fichier « .p12 » ou « .pfx » exploitable sous Android. C’est utile par exemple, pour un client VPN installé sur le smartphone. Dans ce cas, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes : $ ACME_HOME="/usr/local/share/acme.sh" $ CERT_HOME="/volume1/Certs" $ cd $ACME_HOME $ ./acme.sh --toPkcs -d votre-domaine.tld Enter Export Password: Verifying - Enter Export Password: [Mon May 25 20:00:28 CEST 2020] Success, Pfx is exported to: /volume1/Certs/votre-domaine.tld/votre-domaine.tld.pfx « Password » est le mot de passe utilisé pour ouvrir la session SSH. 10 Évolution du processus de renouvellement du certificat EDIT du 11/08/2020 et du 21/08/2020 Afin d’améliorer la recherche de la (les) cause(s) d’un éventuel dysfonctionnement dans le processus de renouvellement du certificat, la trace complète de toutes les opérations effectuées lors du déroulement de ce processus a été remaniée de façon à fournir un historique « tournant ». Ces informations sont inscrites dans un fichier nommé « acme_renew_python.log.x » qui est automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew ». Cette trace est systématiquement générée que vous utilisiez ou non l’option « -l » pour obtenir un « log » du processus. Au total, vous disposerez de neuf (9) fichiers de trace sachant que le fichier ayant l’indice « 1 » sera toujours celui correspondant à la dernière exécution du script, donc le plus récent. Si pour une quelconque raison vous aviez besoin de renouveler votre certificat LE avant sa date normale de renouvellement, une option dédiée à cet effet à été ajoutée au script Python (v1.40). Cette option « -f » ou « --force » doit toutefois être utilisée avec parcimonie. En effet, LetsEncript limite le nombre de modifications d’un certificat d’un même domaine à cinq (5) par semaines calendaires. Au-delà de ces cinq (5) modifications dans une même semaine, vous serez bloqués et ne pourrez pas renouveler votre certificat durant une semaine à compter de la dernière modification tentée. Vous êtes donc prévenus ... EDIT du 25/07/2020 Suite aux retours de plusieurs utilisateurs « initiés », il a été fait le constat que le processus de renouvellement du certificat tel qu’il existait, n’était pas pleinement satisfaisant. En effet, même si en apparence le certificat semblait renouvelé dans le « Panneau de configuration / Sécurité / Certificat » avec une nouvelle date d’expiration affichée en vert et qu’il était bien marqué « par défaut », en fait il ne l’était pas complétement. À l’usage il générait encore des messages liés à une connexion non sécurisée avec une erreur du type « SLL_ERROR_BAD_CERT_DOMAIN ». La raison en était que les fichiers « .pem » du nouveau certificat n’avaient en fait, pas été recopiés partout où ils auraient dû l’être et du coup les navigateurs Web utilisaient toujours les anciens fichiers. Pour les plus sceptiques vis-à-vis de cette apparence trompeuse et pour bien se rendre compte que c’était toujours l’ancien certificat qui était pris en compte par les navigateurs Web, il suffit effectuer les manipulations suivantes : Effacer le cache du navigateur Web. Recharger le site web consulté où l’erreur SSL était apparue. Examiner le certificat utilisé par le navigateur dans ce cas. On constate que c’est toujours l’ancien certificat à la vue de sa date d’expiration. On obtient aussi la preuve que le processus de renouvellement pour le cas particulier de l’environnement du NAS Synology n’était pas complet, en examinant via une connexion SSH sous « root », les fichiers « .pem » contenus dans le répertoire « /usr/local/etc/certificate/WebStation/vhost_xxxxxx ». Ces fichiers correspondaient exactement à l’ancien certificat. Par ailleurs, après sa création et/ou son renouvellement, il avait été constaté que le nouveau certificat n’était pas non plus, appliqué et/ou réappliqué aux services à l'image de ce qui existait pour le certificat précédemment actif et marqué par défaut. Il fallait alors reprendre manuellement via le menu « Configurer », toutes les affectations de ce nouveau certificat aux différents services qui l’utilisaient. Opération laborieuse s’il en était … Nota : Je vous rappelle si besoin en est, qu’après toute création du certificat (qu’il en existe déjà un ou non pour « votre-domaine.tld »), cette opération d’affectation du certificat aux services est obligatoire pour la bonne prise en compte de celui-ci. Vous en conviendrez donc, du point de vue automatisation ce n’était pas top ! 🤔 Ces différents problèmes nous ont donc conduits @bruno78 et moi-même à plancher sur une automatisation COMPLETE de la procédure de renouvellement du certificat et il faut bien le dire ici, sans les talents de développeur de @bruno78, nous n’aurions pas aujourd’hui une procédure pleinement fonctionnelle et efficiente. Donc, @bruno78 a développé un script en langage Python nommé « acme_renew.py » qui réalise maintenant correctement tout le « boulot » si je puis dire. À noter que ce script dispose également de certaines fonctionnalités disponibles uniquement dans le cadre une utilisation manuelle en mode SSH sous « root » que je vais vous détailler plus loin. Pour d’ores et déjà satisfaire la curiosité des utilisateurs « initiés », de façon succincte, ce script Python réalise les opérations suivantes : Lecture des fichiers « INFO » et « DEFAULT » (« /usr/syno/etc/certificate/_archive ») Vérification de l’atteinte ou non de la date de renouvellement (minimum T0+60 jours, valeur par défaut inscrite dans le code du Shell script « acme.sh »). Sauvegarde du répertoire « /usr/syno/etc/certificate/_archive » y compris des fichiers « INFO » et « DEFAULT » Récupération des services du certificat originel par défaut selon qu’il a été généré avec une clé de chiffrement de type RSA ou ECDSA. Renouvellement du certificat : On reprend ici la commande originelle de renouvellement du script « acme.sh » à laquelle on a ajouté des paramètres spécifiques (« /usr/local/share/acme.sh/acme.sh --cron –force –debug --log --home /usr/local/share/acme.sh/ ») : « --force » pour le forcer à renouveler le certificat (la simple option « –renew » n’est pas suffisante car elle génère un message d’erreur qui stipule de surcroît d’utiliser l’option « --force », donc on applique cette option directement). « --debug » pour avoir un maximum de messages de traçage des opérations réalisées. « --log » pour récupérer les messages générés dans un fichier « Log » de trace. Lecture des nouveaux fichiers « INFO » et « DEFAULT » générés suite au renouvellement. Mise à jour du fichier « INFO » en inscrivant les services sur le nouveau certificat « par défaut » Renommage de la description de l'ancien certificat en "xxx_old". Distribution les nouveaux fichiers du certificat dans les répertoires système du NAS « /usr/syno/etc/certificate » et « /usr/local/etc/certificate ». Recherche et constitution de la liste des packages et services qui utilisent le certificat. Redémarrage global de ces packages et services en incluant leurs dépendances. Donc comme évoqué précédemment, le script Python « acme_renew.py » peut être utilisé selon deux modes de fonctionnement : En mode dit « Standard ou automatique » : c’est celui qui est typiquement utilisé pour la commande de renouvellement intégrée à la tâche périodique que vous avez définie dans DSM au § 6 ci-dessus et dans lequel la description des paramètres que le script accepte, est précisée. Veuillez-vous y reporter. En mode dit « Manuel » : ce mode correspond à une utilisation directe en lignes de commandes dans une connexion au NAS via une session SSH sous l’utilisateur « root ». Donc, ouvrez une connexion SSH sous « root » et tapez les commandes suivantes : $ cd /volume1/Scripts $ python acme_renew.py -h Avec ce paramètre « -h » vous obtenez une aide sur tous les paramètres utilisables avec le script Python « acme_renew.py » : Les informations fournies par cette option « -h » se suffisent à elles-mêmes. Elles ne seront donc pas décrites/détaillées plus avant. Nota : Dans cette aide le paramètre « ndd.tld » correspond bien évidemment à « l’intitulé » de votre domaine soit « votre-domaine.tld ». Toutefois, dans le cas particulier d’une utilisation avec le paramètre « -c » il convient de préciser ceci : En aucun cas vous ne devez utiliser la commande « python acme_renew.py -c votre-domaine.tld » ou « python3 acme_renew.py -c votre-domaine.tld » dans une fenêtre de console sous WinSCP ! La raison en est, que la console de WinSCP ne supporte pas l’exécution de commandes dites « interactives ». Si d’aventure vous faisiez cette erreur, sachez que vous allez entrer dans une boucle sans fin et que le seul moyen d’en sortir sera de « tuer » le process WinSCP dans le gestionnaire de tâches de Windows. Maintenant vous êtes prévenus ! Par contre, il n’y a aucun souci pour exécuter cette commande interactive dans une fenêtre « Terminal » de PuTTY sur PC (même si celle-ci est lancée à partir de WinSCP) ou d’une fenêtre « Terminal » sur Mac. Voilà c’est fini, profitez bien de votre certificat « wilcard » Let’sEncrypt !!! GRATUIT !!! et ne nécessitant plus d’ouvrir les ports 80 et/ou 443 sur votre NAS pour son renouvellement. À l’usage, on en oublierait presque la chose … Le fichier ".pdf" de cette procédure : Création_Certif_Wilcard_LE_avec_ACME_20210215.pdf Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Merci à @maxou56 pour ses compléments d’informations liées au monde Mac. Cordialement Oracle7😉

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

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 😉

AVERTISSEMENT : Ce tutoriel est adapté à InfluxDB 1.8.x, qui n'est plus la dernière version d'InfluxDB qui existe maintenant en version 2.x, dont le fonctionnement est grandement différent. 1. Préambule Ce tutoriel est dédié à la mise en service de trois applications qui œuvrent de concert pour récolter (Telegraf), stocker (InfluxDB) et afficher (Grafana) sous la forme désirée des métriques liées à des équipements informatiques. Les applications sont extrêmement vastes, cela va de la surveillance d'un système domotique, un système d'arrosage piloté par une vanne intelligente par exemple, à la supervision d'une infrastructure réseau, d'un serveur VPS, etc... Ce trio d'applications va être mis en service par le biais de Docker, un paquet disponible dans le centre de paquets Synology pour les modèles "haut de gamme" du constructeur. Comme vous le constaterez si vous parcourez les nombreuses pages de commentaires de ce tutoriel, des membres du forum ont activement apporté leur contribution à l'amélioration de ce fil et je les en remercie tous grandement, nous avons tous appris les uns des autres. Pour illustrer le propos, quelques exemples de tableaux de bord qu'il est possible de réaliser via Grafana : Fig. 1 Supervision d'un serveur Linux sous Debian 10 Fig. 2 Mise en place d'un speedtest régulier pour mesurer les performances de sa connexion (@oracle7 @bruno78) Fig. 3 Supervision combinée d'un DS920+ et d'un RT2600AC (@MilesTEG1) Fig. 4 Supervision d'une Freebox (@bruno78) Fig. 5 Supervision du trafic Wifi d'un routeur RT2600AC (@oracle7) 2. Prérequis Difficulté : facile-moyenne Ce tutoriel prend le temps d'expliciter la très grande majorité des commandes, néanmoins, afin de mieux comprendre ce qui est expliqué ici, il est conseillé de prendre connaissance des bases du fonctionnement de Docker, un tutoriel introductif est disponible sur le forum : Il est également important de savoir se connecter en SSH : 3. Matériel nécessaire Docker est un logiciel multiplateforme : Linux, Mac, Windows Ce tutoriel aborde en particulier les spécificités liées à DSM et à son implémentation de Docker, mais il est transposable (surtout via docker-compose) à toutes les machines compatibles. Avoir un NAS n'est donc pas une obligation pour mener ce tutoriel à terme. Vous pouvez vérifier quels NAS Synology sont capables d'utiliser Docker à cette adresse. 4. Outils et informations utiles 4-A. Docker-compose Docker-compose est une commande embarquée avec le paquet Docker de Synology, codé en Python et disponible via SSH. Il permet de structurer, de manière plus analytique qu'un script docker en ligne de commande, les variables, volumes, etc... d'un conteneur au sein d'un fichier au format yaml/yml. Ce fichier reste après création du conteneur, on conserve ainsi les paramètres de personnalisation de notre image Docker à tout moment. Pour crée un fichier docker-compose.yml, c'est assez simple : 4-A-1. Linux Si vous utilisez une distribution avec interface graphique, vous pouvez utiliser l'éditeur de texte embarqué. Sur DSM, vous avez le paquet éditeur de texte qui convient parfaitement. En ligne de commande, utilisez l'outil qui vous convient le mieux : vi, vim, nano, emacs, etc... Conseil : nano est un des éditeurs les plus simples à prendre en main, pour l'installer sur votre NAS (DSM ne l'embarque pas par défaut), vous pouvez télécharger le paquet SynoCli File Tools du dépôt Synocommunity. Je recommande d'ailleurs vivement l'installation de la suite de paquets SynoCli, ils sont très pratiques dès que vous commencez à prendre vos aises avec l'interface en ligne de commande. 4-A-1. Mac La plupart des éditeurs de texte font l'affaire, sinon via le Terminal. 4-A-1. Windows Je vous conseille d'utiliser Notepad++ Une fois lancé, aller dans le menu Encodage et vérifier que "Encoder en UTF-8" est sélectionné. Une fois votre fichier prêt, Enregistrer sous pour nommer le fichier et choisir le type : YAML Ain't Makeup Language (fin de la liste déroulante). A des fins de simplification du tutoriel, veuillez toujours nommer le fichier docker-compose (hors extension), cela permettra d'exécuter la commande de création de conteneur avec le moins d'arguments possibles. 4-B. Persistance des données Afin de stocker de manière pérenne les données d'un conteneur, on va créer un dossier par conteneur (ou groupe de conteneurs travaillant ensemble). A l'installation de Docker sur DSM, un dossier partagé "docker" est automatiquement créé, donc autant l'utiliser pour y stocker nos différents dossiers. Par exemple, pour Telegraf, le chemin absolu de son dossier sera /volume1/docker/telegraf Rien ne vous oblige à respecter cette règle. Quelque soit le dossier choisi, on va généralement y placer le fichier docker-compose.yml 4-C. SNMP Aucune connaissance réellement nécessaire pour la stricte application du tutoriel, mais si vous comptez faire de la surveillance d'autres équipements réseaux, ce sera incontournable d'en comprendre le fonctionnement global. On trouve la plupart des informations sur la page wikipédia (notamment les deux premiers paragraphes). 4-D. Fichiers MIB Les fichiers MIB traduisent traduisent et mettent en forme pour les humains les données qui sont mises à disposition par un système pour sa supervision. Exemple : .1.3.6.1.4.1.6574.5 => synologyDiskSMART La suite de caractères à gauche de la flèche est un OID, et à droite son nom : synologyDiskSMART. L'OID se construit via une arborescence : pour inspecter les sous-catégories de synologyDiskSMART, l'OID va s'enrichir de nouveaux caractères : .1.3.6.1.4.1.6574.5.1 => diskSMARTInfoIndex .1.3.6.1.4.1.6574.5.7 => diskSMARTAttrThreshold .1.3.6.1.4.1.6574.5.9 => diskSMARTAttrStatus Ainsi de suite... Synology met à disposition un PDF comprenant la liste non exhaustive des OID principaux disponibles dans DSM. 5. Serveur SNMP Pour pouvoir récolter les informations mises à disposition par le NAS, il faut d'abord activer le serveur SNMP, désactivé par défaut. Pour y remédier, on va dans Panneau de configuration -> Terminal & SNMP -> SNMP pour arriver à l'écran suivant : Fig. 6 Activation du protocole SNMP Remarques : - SNMPv2 est parfaitement adapté à une utilisation locale. Si vous souhaitiez superviser un NAS distant depuis votre NAS local, SNMPv3 est un choix plus avisé de par sa sécurité renforcée. - Je vous recommande de changer le nom de la communauté, j'utilise la logique suivante pour nommer mes périphériques : <nom_du_périphérique><suite_de_chiffres_XYZ> Exemples : vpsXYZ, nas1XYZ, raspberrypiXYZ, etc... - Au niveau du pare-feu, veuillez vous assurer d'avoir autorisé la plage d'IP 172.16.0.0/255.240.0.0 à communiquer avec le NAS, c'est la plage d'IP utilisée par Docker. A minima, autorisez le port UDP 161 depuis cette plage IP, si vous ne souhaitez pas autoriser tous les ports. 6. Alchimie L'ensemble de ces trois applications, qu'on retrouve parfois sous l'appellation TIG (Telegraf InfluxDB Grafana), opère de la sorte : - Telegraf C'est un agent de récupération de métriques (entendez des données relatives au fonctionnement du système que vous souhaitez surveiller). - InfluxDB InfluxDB est une base de données qui va stocker les métriques recueillies par Telegraf. - Grafana C'est un outil de supervision et d'agrégation de métriques, ce qui va nous permettre de manipuler les données stockées dans InfluxDB. 7. Mise en place 7-A. Images On télécharge les trois images docker suivantes (voir tutoriel introductif) : telegraf influxdb:1.8 grafana/grafana ATTENTION : InfluxDB 2.x nécessite une configuration totalement et un usage au sein de Grafana totalement différents de ce qui est abordé par la suite. Ce tutoriel ne s'adresse donc qu'aux installations utilisant les versions 1.x de InfluxDB. 7-B. Création d'un réseau bridge personnalisé (user-defined bridge network) Pour permettre la communication entre deux conteneurs, on distingue deux méthodes : 7-B-1. Lien On utilise la fonction de lien (link) présente dans l'interface de création d'un conteneur sur DSM qui pointe vers le conteneur avec lequel on souhaite établir une communication. Cette méthode fonctionne encore, mais est dépréciée par Docker. 7-B-2. Réseau Il y a deux catégories de réseau bridge : le réseau bridge par défaut et le réseau bridge personnalisé. 7-B-2-a. Bridge par défaut Le conteneur est isolé dans le sous-réseau 172.17.0.0/255.255.0.0 Depuis le conteneur, le NAS est accessible à l'adresse 172.17.0.1, il est sa passerelle vers le monde extérieur. Un conteneur attaché à ce réseau est joignable uniquement par son IP (pas de résolution DNS possible). 7-B-2-b. Bridge personnalisé C'est un réseau créé par l'utilisateur. Tous les conteneurs qui feront partie de ce réseau pourront communiquer via leur nom de conteneur, cette résolution DNS est extrêmement pratique car elle ne fait pas intervenir les IP qui peuvent être amenées à changer d'une fois à l'autre. Via docker-compose, si on ne précise rien concernant le réseau dans le fichier docker-compose.yml, Docker créera un réseau bridge personnalisé dédié au(x) service(s) de façon automatique. C'est ce qu'on appelle un réseau interne, car il est créé dans la foulée de la mise en route d'un service Ici, nous allons créer un réseau externe, comme ça même si tous les conteneurs sont supprimés, le réseau persiste et est prêt à accueillir de nouveaux conteneurs. Remarque : Au sein d'un réseau bridge personnalisé, les ports des conteneurs sont intégralement exposés les uns envers les autres, il est donc primordial de ne placer dans un même réseau que des conteneurs qui ont vocation à communiquer entre eux. 7-B-2-b-1. Par DSM Pour créer un réseau bridge personnalisé sur DSM, c'est très simple, on clique sur le paquet Docker -> Réseau -> Ajouter -> Fig. 7 Création du réseau bridge personnalisé via DSM On peut tout à fait choisir d'obtenir une configuration automatique, mais cela ne coûte pas bien plus cher de définir la configuration de notre réseau. Tous nos conteneurs auront des IP dans la plage 172.18.0.1 à 172.18.0.254, l'adresse 172.18.0.1 étant réservée au NAS (passerelle), à la manière du réseau bridge par défaut. On valide, le réseau est maintenant créé, il suffira d'indiquer à nos conteneurs de s'y connecter à leur création. 7-B-2-b-2. Par ligne de commande (CLI) Alternative à l'interface DSM, via SSH, on tape la commande suivante : docker network create -d bridge \ --subnet=172.18.0.0/24 \ --gateway=172.18.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring L'avantage avec cette méthode est qu'on définit le nom de l'interface, sinon une suite de caractères aléatoires est générée, utiliser ifconfig pour le vérifier. Remarques : - Penser à ajouter "sudo" devant la commande si vous n'êtes pas connecté en root. - Il est possible de faire rejoindre d'autres réseaux à un conteneur après sa création, voir dans la documentation officielle de Docker. 7-C. Docker-compose : fichiers multiples ou fichier unique Un fichier docker-compose a l'avantage de pouvoir gérer plusieurs services simultanément (un service entrainant la création d'un conteneur), définir un ordre de démarrage, des paramètres (volumes et réseaux par exemple) communs, etc... La méthode du fichier unique est donc toute indiquée ici, car nos conteneurs sont dépendants les uns des autres. Cependant, à des fins didactiques, je proposerai pour chacune des applications un code autonome. Je présente dans un premier temps la méthode avec des fichiers séparés, rendez-vous au point 9. pour des détails concernant l'utilisation d'un fichier unique. 8. Création des conteneurs 8-A. InfluxDB 8-A-1. Configuration L'ordre dans lequel on ajoute les services dans le fichier docker-compose.yml n'a pas d'importance, c'est le paramètre "depends_on" qui permettra de définir un ordre de mise en route (uniquement pour un fichier unique, voir plus loin). Commençons par définir les paramètres de notre conteneur InfluxDB. La liste des variables d'environnement pour InfluxDB est disponible à cette adresse. Cela peut être utile si vous souhaitez définir une police de rétention des données. On crée un dossier influxdb dans le dossier partagé docker, soit par File Station, soit en SSH : mkdir /volume1/docker/influxdb Puis on va créer le fichier docker-compose.yml : IMPORTANT: Un fichier docker-compose.yml n'accepte pas les tabulations !!! Seuls les espaces sont acceptés !! version: '2.1' services: influxdb: image: influxdb:1.8 container_name: influxdb networks: - monitoring environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true - INFLUXDB_META_RETENTION_AUTOCREATE=false # ports: # Optionnel # - 8086:8086 # Optionnel volumes: - /volume1/docker/influxdb/data:/var/lib/influxdb restart: unless-stopped networks: monitoring: external: true Une fois ceci fait, on se place dans le répertoire d'InfluxDB : cd /volume1/docker/influxdb On va devoir créer un dossier data dans le dossier présent : mkdir data Puis : docker-compose up -d En cas d'erreur, pour supprimer un conteneur par docker-compose, c'est tout simplement : docker-compose down Remarques : Concernant la forme, le nombre d'espaces n'a pas d'importance, le tout étant de garder la même logique, et d'aligner les éléments comme proposé. Concernant le fond : - On a défini un nom pour notre conteneur : influxdb - On a créé une base de données par défaut => nas_telegraf - On a créé un utilisateur administrateur pour gérer l'ensemble des base de données dans InfluxDB => admin / admin - On a créé un utilisateur avec les droits de lecture et écriture sur la base de données nas_telegraf => nas_telegraf / nas_telegraf - On a activé l'authentification HTTP (nécessaire pour que les autres variables d'environnement soient prises en compte). - Le dossier data créé ci-avant comportera ce qu'on trouvera dans le conteneur dans son dossier /var/lib/influxdb. Autre remarque : Ici on n'utilise pas la dernière version d'InfluxDB mais on précise qu'on souhaite avoir la version 1.8 (dans image), car les versions 1.8.x sont les dernières supportées par ce tutoriel. ATTENTION : Il est important de noter que la translation de ports n'est nécessaire que si d'autres périphériques doivent accéder à cette instance d'InfluxDB. Par exemple un conteneur Telegraf sur un Raspberry Pi qui enverrait ses données vers InfluxDB. Par défaut, je commente (avec le # en début de ligne) les lignes relatives à la translation de ports. En effet, les trois applications étant dans le même réseau personnalisé, tous leurs ports sont exposés les uns aux autres, aucun besoin de redirection en ce cas. Si on souhaite que des instances Telegraf externes au NAS (sur une autre machine du réseau), décommentez la définition des ports (supprimez les #), supprimez le conteneur et recréez-le. 8-A-2. Définition de la police de rétention des données Par défaut, InfluxDB attribue des polices de rétention de données d'une durée d'un an si on ne lui dit pas de faire autrement. Or un an peut paraître excessif lorsque parfois seuls les derniers jours ou semaines nous intéressent. C'est le but de la variable d'environnement : - INFLUXDB_META_RETENTION_AUTOCREATE=false définie dans le fichier docker-compose ci-avant. En revanche, il est donc nécessaire d'en définir une manuellement après création du conteneur. Pour se faire, on va dans le terminal et ton tape la commande suivante : docker exec -it influxdb influx -username admin -password admin Ce qui va nous faire entrer dans l'interpréteur de requête propre au conteneur InfluxDB : On doit d'abord préciser quelle base de données utiliser : USE nas_telegraf Puis on va, par exemple, créer une police de rétention nommé rp_8w de 8 semaines pour notre instance nas_telegraf : CREATE RETENTION POLICY "rp_8w" ON "nas_telegraf" DURATION 8w REPLICATION 1 DEFAULT Pour s'assurer que ça a fonctionné, on tape la commande suivante : SHOW RETENTION POLICIES Qui doit renvoyer une liste de polices de rétention pour cette base de données : Pour sortir du conteneur, on tape simplement exit. Notre instance InfluxDB est donc maintenant prête à accueillir des données depuis Telegraf. 8-B. Telegraf MISE A JOUR : depuis la version 1.20.3 de Telegraf, il est nécessaire de créer un utilisateur dédié à Telegraf pour pouvoir l'exploiter de manière sécurisée. C'est donc la première étape à réaliser. 8-B-1. Création d'un utilisateur dédié On commence par se rendre dans DSM, et on va dans Panneau de configuration -> Utilisateur -> Créer. A l'écran de sélection des groupes, on l'adjoint au groupe docker. Fig. 8 Ajout de l'utilisateur telegraf au groupe docker On s'assure que cette appartenance lui confère les droits nécessaires sur le dossier partagé docker : On peut également lui refuser l'accès à toutes les applications de DSM : Fig. 9 Suppression des droits d'utilisation des applications Synology Ceci fait, on a un utilisateur dédié pour Telegraf. En réalité, cette étape n'était pas nécessaire pour son utilisation la plus basique, à savoir superviser les informations données par DSM. Ce sera nécessaire si l'on souhaite superviser Docker ou d'autres éléments du système non pris en charge nativement par les fichiers MIB de Synology (voir plus loin). On cherche à connaître les ID de l'utilisateur telegraf et du groupe docker : id telegraf Dans cet exemple, ce seraient les valeurs 1040 et 65536 qui nous intéressent. Prenez-en note. On les insèrera dans le fichier docker-compose (point 8-B-4). 8-B-2. Génération du fichier de configuration Telegraf utilise un fichier de configuration .conf, qu'on va générer en amont de la création du conteneur. Comme pour InfluxDB on crée un dossier telegraf : mkdir /volume1/docker/telegraf Puis on va dans le dossier de Telegraf : cd /volume1/docker/telegraf Puis : docker run --rm telegraf telegraf config > telegraf.conf Un fichier telegraf.conf va apparaître dans le dossier, avant de l'éditer je vous conseille d'en faire une copie, en SSH il suffit de taper la commande suivante (merci @unPixel pour la suggestion) : cp telegraf.conf telegraf.conf.back Maintenant qu'on a créé tous les fichiers dont on a besoin, on va lancer File Station, et se rendre dans le dossier partagé docker, on clic droit sur le dossier telegraf, puis on va successivement choisir, dans l'onglet Propriétaire, le groupe users (vérifiez bien que c'est un groupe, on distingue deux personnages au lieu d'un devant son nom) et l'utilisateur telegraf. L'option d'application à tous les dossiers et fichiers enfants doit également être cochée dans les deux cas. Fig. 10 & 11 Application des ACL au dossier telegraf Pour la suite, libre à vous d'éditer le fichier de configuration via File Station et le paquet Éditeur de texte, ou de le faire par le terminal via nano. 8-B-3. Paramétrage Le fichier de configuration de Telegraf se décompose en trois sections : - Les paramètres globaux de Telegraf - Les plugins de sortie - Les plugins d'entrée 8-B-3-a. Global Ce sont les paramètres globaux de Telegraf, c'est-à-dire ceux qui s'appliqueront si un plugin ne contient pas une directive contraire (intervalle de récolte des données par exemple). # Telegraf Configuration # # Telegraf is entirely plugin driven. All metrics are gathered from the # declared inputs, and sent to the declared outputs. # # Plugins must be declared in here to be active. # To deactivate a plugin, comment out the name and any variables. # # Use 'telegraf -config telegraf.conf -test' to see what metrics a config # file would generate. # # Environment variables can be used anywhere in this config file, simply prepend # them with $. For strings the variable must be within quotes (ie, "$STR_VAR"), # for numbers and booleans they should be plain (ie, $INT_VAR, $BOOL_VAR) # Global tags can be specified here in key="value" format. [global_tags] # dc = "us-east-1" # will tag all metrics with dc=us-east-1 # rack = "1a" ## Environment variables can be used as tags, and throughout the config file # user = "$USER" # Configuration for telegraf agent [agent] ## Default data collection interval for all inputs interval = "60s" ## Rounds collection interval to 'interval' ## ie, if interval="10s" then always collect on :00, :10, :20, etc. round_interval = true ## Telegraf will send metrics to outputs in batches of at most ## metric_batch_size metrics. ## This controls the size of writes that Telegraf sends to output plugins. metric_batch_size = 1000 ## For failed writes, telegraf will cache metric_buffer_limit metrics for each ## output, and will flush this buffer on a successful write. Oldest metrics ## are dropped first when this buffer fills. ## This buffer only fills when writes fail to output plugin(s). metric_buffer_limit = 10000 ## Collection jitter is used to jitter the collection by a random amount. ## Each plugin will sleep for a random time within jitter before collecting. ## This can be used to avoid many plugins querying things like sysfs at the ## same time, which can have a measurable effect on the system. collection_jitter = "0s" ## Default flushing interval for all outputs. Maximum flush_interval will be ## flush_interval + flush_jitter flush_interval = "10s" ## Jitter the flush interval by a random amount. This is primarily to avoid ## large write spikes for users running a large number of telegraf instances. ## ie, a jitter of 5s and interval 10s means flushes will happen every 10-15s flush_jitter = "0s" ## By default or when set to "0s", precision will be set to the same ## timestamp order as the collection interval, with the maximum being 1s. ## ie, when interval = "10s", precision will be "1s" ## when interval = "250ms", precision will be "1ms" ## Precision will NOT be used for service inputs. It is up to each individual ## service input to set the timestamp at the appropriate precision. ## Valid time units are "ns", "us" (or "µs"), "ms", "s". precision = "" ## Logging configuration: ## Run telegraf with debug log messages. debug = true ## Run telegraf in quiet mode (error log messages only). quiet = false ## Specify the log file name. The empty string means to log to stderr. logfile = "" ## Override default hostname, if empty use os.Hostname() hostname = "" ## If set to true, do no set the "host" tag in the telegraf agent. omit_hostname = false Les champs importants sont : - le champ interval dans la section [agent] : il définit à quel intervalle les données sont récoltées, 60s est un bon compromis. - le champ debug dans la même section : le passer à true passe le niveau de verbosité à debug, c'est un réglage que je conseille pour une première mise en route, cela vous aidera à diagnostiquer les dysfonctionnements. 8-B-3-b. InfluxDB ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls = ["http://127.0.0.1:8086"] urls = ["http://influxdb:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "nas_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. # database_tag = "" ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" ## Write consistency (clusters only), can be: "any", "one", "quorum", "all". ## Only takes effect when using HTTP. # write_consistency = "any" ## Timeout for HTTP messages. timeout = "5s" ## HTTP Basic Auth username = "nas_telegraf" password = "nas_telegraf" ## HTTP User-Agent # user_agent = "telegraf" ## UDP payload size is the maximum packet size to send. # udp_payload = "512B" ## Optional TLS Config for use on HTTP connections. # tls_ca = "/etc/telegraf/ca.pem" # tls_cert = "/etc/telegraf/cert.pem" # tls_key = "/etc/telegraf/key.pem" ## Use TLS but skip chain & host verification # insecure_skip_verify = false ## HTTP Proxy override, if unset values the standard proxy environment ## variables are consulted to determine which proxy, if any, should be used. # http_proxy = "http://corporate.proxy:3128" ## Additional HTTP headers # http_headers = {"X-Special-Header" = "Special-Value"} ## HTTP Content-Encoding for write request body, can be set to "gzip" to ## compress body or "identity" to apply no encoding. # content_encoding = "identity" ## When true, Telegraf will output unsigned integers as unsigned values, ## i.e.: "42u". You will need a version of InfluxDB supporting unsigned ## integer values. Enabling this option will result in field type errors if ## existing data has been written. # influx_uint_support = false Remarques : - urls = ["http://influxdb:8086"] -> Si vous avez bien suivi, notre conteneur Telegraf peut contacter InfluxDB directement par son nom de conteneur, et tous les ports étant exposés entre eux, on peut l'écrire de la sorte. - database = "nas_telegraf" -> c'est le nom qu'on a donné à notre base de données lors de la création du conteneur influxdb (variable d'environnement INFLUXDB_DB). - skip_database_creation = true -> créée en même temps que le conteneur influxdb, on peut régler cette option sur "true". - HTTP Basic Auth : on entre le nom d'utilisateur et le mot de passe (respectivement les variables d'environnement INFLUXDB_USER et INFLUXDB_USER_PASSWORD) qu'on a également définis dans notre fichier docker-compose pour InfluxDB : nas_telegraf / nas_telegraf En l'état, le fichier de configuration est suffisamment paramétré pour envoyer certaines données que Telegraf collecte par défaut à notre base de données InfluxDB : CPU, mémoire, kernel, etc... C'est là que vont intervenir les fichiers MIB, ceux-ci permettent une supervision plus poussée du NAS, mais pour cela il va falloir donner à Telegraf les OID relatifs aux informations que Synology fournit via SNMP. 8-B-3-c. SNMP Pour cela on peut se baser sur le travail de jperillo sur Github, notamment son listing des OID de DSM. Au fil des mois, les différents contributeurs de ce tutoriel ont fourni une aide précieuse pour compléter les OID liés au monitoring d'un onduleur branché au NAS, vous retrouverez dans le fichier suivant une version plus complète que ce proposé sur le lien ci-dessus : snmp-dsm.conf Le contenu de ce fichier est à placer juste après le début de la section INPUT PLUGINS. Il reste quelques champs à personnaliser. 8-B-3-c-1. agents agents = [ "xxx.xxx.xxx.xxx", "xxx.xxx.xxx.xxx" ] Ce sont les IP des NAS à superviser, vous pouvez parfaitement passer par l'IP passerelle du NAS sur lequel Telegraf est installé : 172.18.0.1 (si le réseau bridge utilisé est 172.18.0.0, à adapter au besoin). Si vous souhaitez superviser d'autres NAS, il faut entrer l'IP par laquelle vous-même les contacteriez : IP locale si sur le réseau local, IP publique si NAS à distance, etc... Si vous ne supervisez qu'un seul NAS, pensez à supprimer la virgule et le deuxième bloc IP : agents = [ "xxx.xxx.xxx.xxx" ] 8-B-3-c-2. community On pense à changer le nom de la communauté si on l'a modifié dans DSM. 8-B-3-c-3. interval Intervalle entre chaque récolte de données (écrase la valeur donnée dans les paramètres généraux de Telegraf pour ce plugin uniquement). 8-B-4. Fichier docker-compose version: '2.1' services: telegraf: image: telegraf container_name: telegraf networks: - monitoring user: 1040:65536 # A adapter suivant vos valeurs # ports: # Optionnel # - 8125:8125 # Optionnel # - 8092:8092/udp # Optionnel # - 8094:8094 # Optionnel volumes: - /volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro - /etc/localtime:/etc/localtime:ro - /etc/TZ:/etc/timezone:ro restart: unless-stopped networks: monitoring: external: true On vérifie qu'on se trouve bien dans /volume1/docker/telegraf puis : docker-compose up -d Remarques : - Le suffixe ":ro" à la fin du montage de volume signifie read-only (lecture seule), pour éviter toute modification indésirable des fichiers par le conteneur. - Les fichiers MIB de Synology sont déjà présents sur le NAS, on va donc monter le dossier dans le conteneur pour que Telegraf y ait accès. - Si votre instance Telegraf collecte les données d'un NAS distant, et que l'hôte de Telegraf n'est pas un NAS Synology, il aura besoin des fichiers MIB disponibles à cette adresse. - Une fois de plus je n'expose aucun port sur le NAS même, ce serait utile uniquement si je souhaitais qu'un script envoie des données à Telegraf par exemple. - On spécifie pour le paramètre user les ID relevées au point 8-B-1. Telegraf va dorénavant envoyer périodiquement les métriques à InfluxDB, on peut le vérifier en tapant dans le dossier de Telegraf : docker-compose logs -f telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 109.726214ms telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 144.489076ms telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:52Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 145.368898ms telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 119.228603ms telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics et vérifier dans InfluxDB également en se plaçant dans son dossier et en utilisant la même commande : [httpd] 172.18.0.3,172.18.0.2 - nas_telegraf [08/Jan/2021:23:59:07 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.16.3 Go/1.15.2" 7e616302-520d-11eb-aead-0242ac130002 15706 8-C. Grafana 8-C-1. Fichier docker-compose Il ne reste plus qu'à configurer Grafana pour pouvoir visualiser les données stockées dans InfluxDB. Comme pour les deux autres conteneurs, on crée un dossier dédié pour Grafana, et un dossier data dans ce dernier. version: '2.1' services: grafana: image: grafana/grafana container_name: grafana networks: - monitoring volumes: - /volume1/docker/grafana/data:/var/lib/grafana ports: - 3000:3000 restart: unless-stopped networks: monitoring: external: true A la différence des autres logiciels, on va devoir ici étendre les permissions du dossier contenant les données de Grafana à tous les utilisateurs : cd /volume1/docker/grafana chmod 777 data Puis : docker-compose up -d Remarques : - Ici je suis forcé de translater le port correspondant à l'interface de Grafana si je souhaite pouvoir y accéder d'une autre machine que le NAS, ce qui sera nécessairement le cas. - Il est possible d'accéder à Grafana au travers d'un proxy inversé. 8-C-2. Création de la source de données On se rend sur la page http://IP_DU_NAS:3000 (ou le port qu'on a choisi) pour accéder à Grafana : Fig. 12 Page d'authentification de Grafana Les accès par défaut sont admin/admin, la première fois qu'on se connecte on nous invite à changer le mot de passe du compte admin. Fig. 13 Écran d'accueil de Grafana On suit les indications de Grafana et on commence par ajouter la source de données, ici notre conteneur InfluxDB. On clique sur Add data source. On choisit InfluxDB. On remplit ensuite l'écran suivant de la sorte : Fig. 14 Configuration de la source de données InfluxDB pour les données du NAS Remarques : - On donne un nom à notre datasource, ici j'ai choisi NAS_InfluxDB. - influxdb dans http://influxdb:8086 représente le nom que vous avez donné au conteneur. - On coche Basic Auth car on a activé l'authentification http à la création du conteneur InfluxDB. - Les informations à entrer dans "InfluxDB Details" correspondent aux variables d'environnement du conteneur InfluxDB : Database : INFLUXDB_DB User : INFLUXDB_USER Password : INFLUXDB_USER_PASSWORD - Basic Auth Details : User : INFLUXDB_USER Password : INFLUXDB_USER_PASSWORD On clique sur Save & Test, on obtient un message écrit en vert Datasource is working si tout est bien paramétré. 8-C-3. Création d'un tableau de bord (dashboard) On peut soit créer son propre tableau de bord, soit en importer un, pour cela il suffit d'aller sur le site de Grafana, plus précisément sur cette page. En tapant Synology dans le cadre de recherche, on peut par exemple choisir le tableau de bord de Yann Bizeul. Fig. 15 Page du tableau de bord publique de Yann Bizeul sur le site de Grafana On clique sur "Copy ID to Clipboard", on retourne sur notre instance de Grafana et on clique sur import dans le menu rapide à la gauche de l'écran : Fig. 16 Importation d'un tableau de bord 1/2 Dans l'écran suivant on colle dans "Grafana.com dashboard" le numéro de du tableau de bord qu'on a choisi. On valide en cliquant sur "Load" et on arrive sur l'écran suivant : Fig. 17 Importation d'un tableau de bord 2/2 Dans InfluxDB on choisit la datasource définie ci-avant, on valide en cliquant sur "Import". Il est aussi possible d'importer des tableaux de bord depuis un fichier JSON, n'hésitez pas à en demander sur ce fil, plusieurs des participants sont prêts à partager les leurs (impressions d'écran en début de tutoriel). 9. Fichier docker-compose unique Si on avait voulu le définir en un seul fichier, on aurait pu faire ainsi : - Créer un dossier monitoring dans /volume1/docker : cd /volume1/docker mkdir monitoring Puis créer des dossiers data pour InfluxDB et Grafana : mkdir influxdb-data grafana-data telegraf-data Et créer enfin un fichier docker-compose.yml : version: '2.1' services: influxdb: image: influxdb:1.8 container_name: influxdb networks: - monitoring environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true - INFLUXDB_META_RETENTION_AUTOCREATE=false # ports: # Optionnel # - 8086:8086 # Optionnel volumes: - /volume1/docker/monitoring/influxdb-data:/var/lib/influxdb restart: unless-stopped grafana: image: grafana/grafana container_name: grafana networks: - monitoring volumes: - /volume1/docker/monitoring/grafana-data:/var/lib/grafana ports: - 3000:3000 depends_on: - telegraf - influxdb restart: unless-stopped telegraf: image: telegraf container_name: telegraf networks: - monitoring user: 1040:65536 # A adapter suivant vos valeurs # ports: # Optionnel # - 8125:8125 # Optionnel # - 8092:8092/udp # Optionnel # - 8094:8094 # Optionnel depends_on: - influxdb volumes: - /volume1/docker/monitoring/telegraf-data/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro - /etc/localtime:/etc/localtime:ro - /etc/TZ:/etc/timezone:ro restart: unless-stopped networks: monitoring: external: true __________________________________________ 10. Supervision de Docker La manipulation est très simple, dans le fichier telegraf.conf, il suffit de décommenter les options qui nous intéressent. Il y a possibilité de trier les conteneurs dont on souhaite réaliser la surveillance suivant différents critères : nom, état, label... # # Read metrics about docker containers [[inputs.docker]] # ## Docker Endpoint # ## To use TCP, set endpoint = "tcp://[ip]:[port]" # ## To use environment variables (ie, docker-machine), set endpoint = "ENV" endpoint = "unix:///var/run/docker.sock" # # ## Set to true to collect Swarm metrics(desired_replicas, running_replicas) # gather_services = false # # ## Set the source tag for the metrics to the container ID hostname, eg first 12 chars # source_tag = false # # ## Containers to include and exclude. Globs accepted. # ## Note that an empty array for both will include all containers # container_name_include = [] # container_name_exclude = [] # # ## Container states to include and exclude. Globs accepted. # ## When empty only containers in the "running" state will be captured. # ## example: container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] # ## example: container_state_exclude = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] container_state_include = [ "created" , "restarting" , "running" , "removing" , "paused" , "exited" , "dead" ] container_state_exclude = [] # # ## Timeout for docker list, info, and stats commands # timeout = "5s" # # ## Specifies for which classes a per-device metric should be issued # ## Possible values are 'cpu' (cpu0, cpu1, ...), 'blkio' (8:0, 8:1, ...) and 'network' (eth0, eth1, ...) # ## Please note that this setting has no effect if 'perdevice' is set to 'true' perdevice_include = [ "cpu" , "blkio" , "network" ] # # ## Specifies for which classes a total metric should be issued. Total is an aggregated of the 'perdevice' values. # ## Possible values are 'cpu', 'blkio' and 'network' # ## Total 'cpu' is reported directly by Docker daemon, and 'network' and 'blkio' totals are aggregated by this plugin. # ## Please note that this setting has no effect if 'total' is set to 'false' total_include = [ "cpu" , "blkio" , "network" ] # # ## Which environment variables should we use as a tag # ##tag_env = ["JAVA_HOME", "HEAP_SIZE"] # # ## docker labels to include and exclude as tags. Globs accepted. # ## Note that an empty array for both will include all labels as tags # docker_label_include = [] # docker_label_exclude = [] # # ## Optional TLS Config # # tls_ca = "/etc/telegraf/ca.pem" # # tls_cert = "/etc/telegraf/cert.pem" # # tls_key = "/etc/telegraf/key.pem" # ## Use TLS but skip chain & host verification # # insecure_skip_verify = false Une étape supplémentaire est nécessaire, il faut qu'on donne accès au fichier docker.sock en lecture seule à Telegraf, il suffit pour cela de rajouter dans le fichier docker-compose de Telegraf (ou pour le fichier unique, le service telegraf) le volume suivant : - /var/run/docker.sock:/var/run/docker.sock:ro On relance le conteneur, en SSH via la commande suivante : docker restart telegraf 11. Supervision de Raspi OS (ou tout autre distribution Linux) Dans mon cas, j'ai choisi de continuer à utiliser l'instance InfluxDB du NAS et avoir une instance de Telegraf sur le Raspberry Pi, pourquoi ? Vous aurez pu remarquer qu'InfluxDB est friand de mémoire vive. Donc autant limiter la charge sur le Raspberry Pi, dont les performances sont généralement en deçà d'un modèle de NAS "+". 11-A. Docker ATTENTION : Si vous n'avez pas activé l'accès SSH sur votre Raspberry Pi, c'est une option à cocher sur le bureau, le service SSH est désactivé par défaut à l'installation depuis 2016, voir guide ici. Pour installer Docker sous Raspbian, on passe par le script tout-en-un. Si vous n'utilisez pas Raspbian, mais une Debian, Ubuntu, ou autre... sélectionnez votre système d'exploitation sur cette page et suivez le guide. Si vous avez une installation précédente de Docker et que vous ne seriez pas passé par cette méthode, vous risquez de vous retrouver avec des versions obsolètes du Docker Engine et donc potentiellement de Docker-compose (merci @Jeff777), veuillez donc avant tout désinstaller Docker et ses reliques en suivant ces étapes. Remarques : On n'oublie pas d'ajouter notre utilisateur au groupe docker, ça évitera par la suite de devoir utiliser "sudo" pour chaque commande liée à Docker, pour l'utilisateur "pi" par exemple : sudo usermod -aG docker pi Pour que la modification soit effective, il faut redémarrer sa session SSH. 11-B. Docker-compose Pour installer Docker-compose, on va utiliser la source la plus à jour : pip3 Toujours en SSH : sudo apt-get install -y libffi-dev libssl-dev python3 python3-pip sudo pip3 install docker-compose 11-C. Telegraf On télécharge l'image de Telegraf : docker pull telegraf Comme précédemment on va créer un dossier dans lequel stocker notre fichier telegraf.conf, personnellement j'ai utilisé le dossier /opt qui est généralement réservé aux applications tierces : sudo mkdir -p /opt/containers/telegraf On va générer le fichier originel telegraf.conf : cd /opt/containers/telegraf docker run --rm telegraf telegraf config | sudo tee telegraf.conf Une fois la configuration faite, on va créer le fichier docker-compose.yml pour Telegraf. On s'inspire du fichier docker-compose qu'on a utilisé pour le NAS, en opérant quelques modifications : version: '2.1' services: telegraf: image: telegraf container_name: telegraf hostname: raspberrypi network_mode: bridge environment: - HOST_PROC=/hostfs/proc - HOST_MOUNT_PREFIX=/hostfs # ports: # Optionnel # - 8125:8125 # Optionnel # - 8092:8092/udp # Optionnel # - 8094:8094 # Optionnel volumes: - /opt/containers/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /proc:/hostfs/proc:ro - /run/udev:/run/udev:ro - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro restart: unless-stopped Remarques : - Pour plus d'info sur les variables et volumes avec "hostfs", voir : https://github.com/influxdata/telegraf/blob/master/docs/FAQ.md - On remarquera l'ajout du paramètres hostname, qui permettra de voir un nom à la place d'une suite de chiffres dans Grafana. - On remarquera également le paramètre network_mode: bridge => Ici je n'ai pas créé de réseau bridge personnalisé, mon conteneur telegraf est tout seul, il peut être donc être dans le réseau bridge par défaut. Pour l'instant on ne démarre pas le conteneur, il va falloir créer la base de données dans laquelle stocker nos informations. 11-D. Création d'une base de données dans InfluxDB Rappelez-vous, sur le NAS nous avions précisé dans le fichier telegraf.conf un nom de base de données à utiliser, ainsi que les données d'identification pour les droits d'écriture. Cette base de données avait été créée à la création du conteneur influxdb, donc il n'y avait rien eu à configurer manuellement. Ici on va stocker les données dans une base de données séparée, donc il va falloir créer un nouvel utilisateur, et une nouvelle base de données. Pour cela il faut se connecter directement dans le conteneur influxdb du NAS. Donc retour en SSH sur celui-ci. On se connecte en root et on entre la commande suivante : docker exec -it influxdb influx -username admin -password admin Remarques : docker exec -it influxdb permet la connexion au conteneur influxdb, influx c'est la commande ouvrant la base de données, si on avait écrit bash à la place on serait arrivé sur l'invite de commande propre au conteneur et on aurait pu écrire influx pour faire la même chose, mais en plus long. 😛 Vu qu'on a activé l'authentification HTTP dans notre conteneur, si on ne précise rien à la connexion, toute tentative de modification se soldera pas un échec dû à un défaut de permission. De plus, vu qu'on souhaite créer de nouveaux éléments, il faut que le compte utilisé ait les pouvoirs d'administration. Il faut donc préciser les données d'authentification administrateur au lancement de la commande influx. Ces données sont celles que l'on avait renseignées à la création du conteneur InfluxDB, dans le tutoriel on a choisi admin / admin comme username / password. Fig. 14 Connexion à InfluxDB par ligne de commande Première étape : on crée la base de données, il suffit de taper la commande suivante : CREATE DATABASE raspi_telegraf puis on sélectionne la base de données qu'on vient juste de créer : USE raspi_telegraf On crée maintenant l'utilisateur dédié au raspberry : CREATE USER raspi_telegraf WITH PASSWORD 'raspi_telegraf' On peut également choisir sa police de rétention de données (voir point 8-A-2) : CREATE RETENTION POLICY "rp_8w" ON "raspi_telegraf" DURATION 8w REPLICATION 1 DEFAULT Remarques - Si on s'est trompé dans l'écriture, il est toujours possible de supprimer un utilisateur ou une base de données avec les commandes DROP USER nom_utilisateur et DROP DATABASE nom_bdd. On peut vérifier à ce stade que tout se passe bien, il suffit de taper les commandes SHOW DATABASES et SHOW USERS : Fig. 15 Listing utilisateurs et bases de données dans InfluxDB La dernière étape consiste à donner des droits à notre utilisateur raspi_telegraf sur la base de données du même nom, ce qui se fait par la commande : GRANT ALL ON raspi_telegraf TO raspi_telegraf On tape ensuite exit pour sortir de influx (gestion de la base de données). On relance ensuite le conteneur pour s'assurer que les modifications ont été prises en compte : docker restart influxdb On peut maintenant quitter la session SSH sur le NAS et revenir sur celle du Raspberry Pi. A ce stade, notre base de données est prête à l'emploi, il suffit maintenant de renseigner dans notre fichier telegraf.conf sur le Raspberry Pi les données d'exportation vers influxdb sur le NAS. On peut le faire avec la commande nano ou vi : cd /opt/containers/telegraf nano telegraf.conf ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls = ["http://127.0.0.1:8086"] urls = ["http://192.168.0.51:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "raspi_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. database_tag = "" ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" ## Write consistency (clusters only), can be: "any", "one", "quorum", "all". ## Only takes effect when using HTTP. write_consistency = "any" ## Timeout for HTTP messages. timeout = "5s" ## HTTP Basic Auth username = "raspi_telegraf" password = "raspi_telegraf" Notes : - Dans urls, on doit entrer l'adresse IP locale du NAS (ou son nom NetBios), et préciser le port sur lequel InfluxDB est exposé, par défaut 8086 dans notre installation précédente. - On s'assure d'avoir exposé le port 8086 du conteneur influxdb sur le NAS (ce qui était optionnel ne l'est plus). - On pense bien à préciser le nom de la base de données dans database et les login/password de notre utlisateur dans la partie HTTP Basic Auth. - On passe skip_database_creation à true. Tout est maintenant configuré sur le Raspberry Pi, il suffit de lancer le conteneur Telegraf : docker-compose -f /opt/containers/telegraf/docker-compose.yml up -d L'argument -f permet de créer un conteneur depuis un fichier compose n'importe où, et avec un nom différent de "docker-compose.yml". Cela permet d'éviter de devoir se placer dans le dossier du fichier docker-compose.yml avant d'exécuter la commande. 11-D. Création de la source de données Direction Grafana => panneau latéral : Configuration (roue dentée) => Datasources On clique sur Add data source : Fig. 16 Configuration de la source de données InfluxDB pour les données du Raspberry Pi On valide, si tout a bien été configuré, on verra le message "Datasource is working" apparaître en vert au moment du clic. 11-D. Création d'un tableau de bord Il s'agit juste ici de vérifier que les données sont accessibles : Fig. 17 Exemple de configuration d'une requête Ici j'ai créé un graphique pour suivre l'état d'utilisation de la mémoire vive : - On notera le choix de la datasource relative au raspberry. - Dans la liste "host" vous devriez voir le nom que vous avez précisé dans le champ hostname du script de création du conteneur. Si vous avez laissé le réglage par défaut, il affichera la valeur hostname du système. MàJ : 29/03/2022

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 maintenir ce fichier host si certains rencontrent des bugs, donc n'hésitez 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 ) 2025-10-07 - 4.6.0 : https://github.com/Gizmo091/synology_1fichier_hosting/raw/refs/heads/main/OneFichierCom(4.6.0).host Changelogs : - 4.6.0 : L’URL du fichier "verify" sur 1fichier, utilisée pour vérifier le bon fonctionnement de la connexion, est récupérée depuis le dépôt GitHub. Comme je n’ai plus de compte premium, cette URL est susceptible de changer régulièrement. - 4.5.0 : Mise en place d'un coutournement lorsque la recuperation du nom du fichier par l'api est impossible - 4.4.0 : Suppression du controle du certificats SSL sur les appels à l'API - 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. - Conflit avec alldrebrid : 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é ). - Verification du login : Depuis le 10 octobre 2025, je n’ai plus de compte premium. Par conséquent, je dois régulièrement télécharger un fichier sur 1fichier et mettre à jour le lien dans le dépôt GitHub pour que la vérification des identifiants fonctionne. Une erreur peut survenir lors de la vérification, mais si vous êtes sûr de votre clé API, les téléchargements ne devraient pas être affectés. 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

Bonjour, Quelqu'un aurait-il un lien pour télécharger un fichier host (download station) pour le site Updloady.io s'il vous plait ? Ou un tuto sur comment en créer un ? J'ai vu sur Google qu'il y avait un topic à ce sujet sur le forum mais je n'y ai pas accès : https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.nas-forum.com/forum/topic/81968-fichier-host-pour-uploadyio/%3Fdo%3DfindComment%26comment%3D1319513384&ved=2ahUKEwiKuK_mrpWLAxXZ3AIHHQ3lJ0gQFnoECAcQAQ&usg=AOvVaw1KQ-cOebOdNKcHwwUFaVT8 Merci d'avance

Bonjour, Nous allons voir dans ce petit tuto les quelques règles importantes pour configurer correctement son routeur Synology afin d'éviter qu'il ne soit ouvert aux quatre vents et par la même occasion protéger aussi notre réseau local du monde extérieur. Quelques règles importantes : S'assurer que le compte "admin" et le compte "guest" sont désactivés. Voir en image S'assurer que notre compte administrateur a un mot de passe fort. Voir recommandations de l'ANSSI S'assurer que notre routeur à l'heure à jour et qu'il est bien configuré. Voir en image S'assurer que la double authentification est activée. Voir en image S'assurer que l'accès à distance au routeur est désactivé. Voir en image S'assurer que DoH est activé (DNS via HTTPS). Voir en image (On en parle ci-dessous 🙂) Dans le cas ou vous voudriez tout de même accéder à votre routeur de l'extérieur ce qui n'est pas recommandé pour des questions de sécurité, je vous recommande vivement de : Passer par votre serveur VPN (voir tuto de Fenrir)voir tuto de Fenrir Éventuellement passer par un domaine personnalisé via votre proxy inversé sur le port 443. Pas de nom générique du type "routeur" dans votre domaine... Lexique abrégé : Transfert de port unique (Single Port Forwarding) : lorsqu'un accès entrant doit atteindre une application particulière (programme serveur). Il faut indiquer dans le routeur un numéro du port et l'adresse IP du PC serveur. Transfert d'un ensemble de ports (Port Range Forwarding): lorsque plusieurs ports sont nécessaires pour une même application. Déclenchement de ports (Port Triggering) : pour les applications qui nécessitent que les ports soient ouverts à la demande sans pour autant préciser un appareil contrairement au port forwarding. DMZ (DeMilitarized Zone) : on autorise tous les ports à être ouvert en permanence. A ne jamais employer pour un non connaisseur en réseau. On peut éventuellement activer ce paramètre quand nous avons derrière un autre routeur qui fera le travail. UPnP (Universal Plug and Play) : on permet à n'importe quoi/qui d'ouvrir automatiquement des ports sans l'approbation du routeur/administrateur. A ne pas activer pour un non connaisseur en réseau. Vous pourrez lire sur ce forum des membres qui recommandent d'activer l'option DMZ sur un modem routeur d'un opérateur internet comme Orange ou SFR par exemple. Cela peut être utile mais c'est souvent suivi de ces deux conditions obligatoirement : Le modem routeur en question ne peut être mit en mode "bridge". Vous avez déjà un routeur derrière ce modem routeur qui fera le boulot à sa place. Partie local : Principe : encapsuler une requête DNS dans une requête HTTP/2 et l’envoyer à un serveur HTTPS qui va faire la résolution et renvoyer la réponse en HTTPS Pour ceux qui voudraient en savoir plus sur DNS DoH, je vous recommande cette vidéo très instructive : https://tube.benzo.online/videos/watch/756a8447-5a27-408d-a513-611f0288e1dd On va configurer le serveur DNS DoH ici : Centre réseau > Réseau local > Options avancées Je vous recommande de passer par le serveur DNS (DoH) de quad9 qui est un peu plus soucieux de votre vie privée que ne l'est Google ou Cloudflare par exemple... Serveur DNS DoH de Quad9 : https://dns.quad9.net/dns-query Liste des serveurs publiques DNS DoH : https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers Partie internet : Il n'y a pas grand chose à configurer sur cette partie à part les serveurs DNS. Sécurité : Protection DoS On active la protection DoS si elle ne l'ai pas déjà. Pour les petits curieux, je vous laisse découvrir ce que c'est sur la page Wikipedia. Centre réseau > Sécurité > Général Nous ne recommandons pas la modification des Paramètres avancés si vous n'êtes pas connaisseur car ça pourrait causer des soucis sur le routeur et les appareils du réseau. DMZ On vérifie que DMZ est bien désactivé. Centre réseau > Transmission de port > DMZ Bannir un appareil Certains appareils connectés sont un peu trop bavards avec des serveurs du fabricant ou des serveurs tiers et/ou sont vendus avec des failles de sécurité comme des caméras IP, des imprimantes etc... Il peut donc être utile de leur interdire de discuter avec internet. Si on veut bannir un appareil pour qu'il ne communique pas avec internet comme une imprimante en réseau, il faut aller sur : Centre réseau > Contrôle du trafic > Généralités Là, on coche le petit globe barré afin qu'il ne soit plus grisé. Ainsi l'appareil ne peut plus communiquer avec l'extérieur ou recevoir des informations. ATTENTION : ça bloquera toutes communication entre l'appareil et internet donc ça bloquera aussi les mises à jour automatique de l'appareil. A prendre en compte ! Partie ethernet : Ne mettez sur votre réseau local câblé QUE des appareils/personnes de confiance. Une personne mal intentionnée n'aura aucun mal à récupérer vos informations en étant sur le même réseau que vous. Exactement comme un réseau wifi public (aéroports par exemple). Adresses IP privées des principaux FAI FR : B-Box > 192.168.1.254 Free-Box > 192.168.0.254 Live-Box > 192.168.1.1 SFR-Box > 192.168.1.1 En sachant celà, on va éviter de donner à notre routeur la même adresse IP privée que le modem-routeur de notre opérateur. Il est plus facile de procéder ainsi que de vouloir changer l'adresse IP privée du modem-routeur du FAI. Voici ma configuration : Pour en savoir plus sur l'IGMP, je vous laisse consulter ce lien qui sera bien plus parlant que moi. https://fr.wikipedia.org/wiki/IGMP_snooping Fixer une adresse IP privée à un appareil : Je recommande vivement d'attribuer une IP privée à votre NAS afin que ce dernier garde toujours la même adresse IP. Quoi de mieux que de laisser faire le routeur et qu'ensuite, le NAS soit configuré sur automatique ?! Pour se faire, nous nous rendons sur : Centre réseau > Réseau local > Clients DHCP Nous pouvons y voir nos appareils connectés. Il nous suffit de sélectionner le NAS puis de cliquer sur "Ajouter à la réservation d'adresse". Résultat visible ici : Centre réseau > Réseau local > Réservation DHCP On peut bien entendu ajouter manuellement un appareil si on le souhaite. Ca sera toujours sur : Centre réseau > Réseau local > Réservation DHCP On clique sur le bouton "Ajouter" puis on rempli manuellement les informations. Il faudra redémarrer l'appareil ajouté pour qu'il prenne en compte les éventuels changements. Attention : SRM est un peu capricieux avec le nom d'hôte. Il n'accepte pas certains caractères comme les espaces. Partie WIFI : Pareil que pour la partie ethernet à la différence qu'on peut activer le wifi invité pour ..... les invités 🤣 Ma configuration WIFI : NOTE : pour le canal 2.4GHz, on vous recommande de mettre 20MHz. Le 40MHz est instable ! Options avancées (reprit du site Synology) : Rotation des clés : Saisissez le nombre de secondes entre chaque rotation des clés. Largeur de canal : Sélectionnez une largeur de canal. Remarque : Cette option devient individuelle pour les différentes bandes sans fil lorsque la fonctionnalité Connexion intelligente est utilisée. Prise en charge de PMF : Choisissez parmi Désactivé, Désactivé - optionnel et Activé - requis pour permettre à votre périphérique de modifier les paramètres internes afin de répondre aux conditions de configuration. Puissance de transmission : Entrez une longueur de signal pour le réseau sans fil. Remarque : Cette option est toujours configurée sur Élevée lorsque le produit Synology rejoint un réseau mesh. DTIM : Spécifiez l'intervalle de synchronisation entre Synology Router et les clients Wi-Fi. Extended NSS : Permet d'améliorer le traitement des paquets (à activer uniquement sur RT2600AC du faite de son processeur quad core). AMPDU : Activez cette option pour que plusieurs données envoyées vers la même destination soient empaquetées ensemble. Cela contribue à améliorer les performances lorsqu'il existe de nombreux petits paquets. 802.11r : Activez cette option pour une itinérance rapide entre différents points Wi-Fi (Failles connues sur les serveurs et les clients. Résolu côté Synology mais ne le sera certainement jamais sur les clients.) Autoriser la commutation automatique sur les canaux DFS (disponible uniquement pour les bandes 5 GHz) : Activer Dynamic Frequency Selection (DFS) pour réduire le risque d'interférence des signaux. Isolement du PA : sélectionnez cette option pour activer ou désactiver cette fonctionnalité afin d'empêcher les clients connectés au réseau Wi-FI d'interagir avec d'autres périphériques connectés. MU-MIMO (disponible uniquement pour les bandes à 5 GHz) : Autoriser les périphériques clients à se connecter au réseau sans fil avec la prise en charge de MU-MIMO. Translation de multidiffusion : Activez cette option pour traduire plusieurs paquets de multidiffusion en paquets de monodiffusion pour de meilleures performances en ce qui concerne les services de diffusion. Remarque : Cette option est toujours configurée sur Activée lorsque le produit Synology rejoint un réseau mesh. Partie WIFI invité : Je vous recommande aussi de vérifier que le réseau local n'est pas accessible pour les appareils se connectant sur le réseau invité. Transmission de port et Sécurité (Pare-feu) : SRM a un ordre de priorité sur les paquets entrants qui sont : Règles de déclenchement des ports Règles de transmission des ports Règles UPnP Règles DMZ C'est ici que l'on va autoriser le transfert d'une demande d'accès sur un autre appareil du réseau local. Je m'explique... Centre réseau > Transmission de port > Transmission de port Imaginons que l'on veuille de l'extérieur de chez nous atteindre notre NAS sur le port 443, alors c'est ici qu'on donnera au routeur la règle l'autorisant. Exemple :  Un autre exemple : Il est fréquent de voir un éditeur de jeux vidéo demander que certains ports soient ouverts pour une meilleure communication entre leurs serveurs et l'appareil utilisé. Pour cette raison, je vais donc ouvrir les ports demandés pour éviter un NAT (strict) qui pourrait me porter préjudice dans mes parties de jeu comme dans la recherche de serveurs disponibles par exemple. Je pense que là, tout le monde a compris l'intérêt et surtout comment on autorise le routeur à accepter les entrées sur tel port pour tel appareil. Mais ce n'est pas tout. Sur nos routeurs Synology, on peut aussi restreindre un peu plus l'ouverture de ces ports en y ajoutant des conditions. Et là, ça se passera dans l'onglet Sécurité > Pare-feu 🙂 Pare-Feu : NOTE : en dehors de l'ouverture de ports pour le routeur uniquement, il faudra toujours ajouter les ports à la transmission de port ! On retrouve les règles de transmission de port que l'on a vu ci-dessus et on peut y trouver d'autres règles. On peut comme je l'ai dit juste avant restreindre un peu plus l'autorisation d'une règle de transmission. Exemple : Reprenons notre règle sur les ports 80 et 443 qui autorise l'accès à distance à un serveur nommé Zeus sur ces deux ports. Je voudrais par contre limiter cet accès uniquement à la FRANCE et que l'accès ne soit pas autorisé pour les autres pays. Et bien on va créer une règle pour faire ça :   Ordre de priorité : Le routeur Synology et son Pare-feu prennent en compte la priorité donnée par un administrateur. Si SRM reçoit un ordre et trouve une règle correspondante alors il arrête sa recherche et exécute l'ordre. On peut donc organiser les priorités que l'on veut voir appliquer par le système en faisant un glisser-déposer d'une règle à une autre : Protection générale du réseau : Dans les Paramètres, voici ce qu'on doit avoir : On va en profiter pour tout cocher dans le Pare-feu dans les conditions ou aucune règle n'existerait. N'oubliez pas de sauvegarder vos changements ! Surveillance du trafic en temps réel : Si on veut savoir les communications dont celles que l'on ne voit pas directement sur un appareil, il suffit d'aller sur : Centre réseau > Contrôle du trafic > Surveiller Il faut activer sur "Paramètres" les options comme ci-dessous. Pour la durée de conservation, je vous laisse juger en fonction de vos besoins et votre mémoire. Là, on peut sélectionner en haut à droite "Domaine" puis un appareil : En cliquant sur le petit +, on peut ajouter ce domaine dans les blocages de Safe Access 🙂 ATTENTION : faites bien attention à ce que vous bloquez. Autant on peut bloquer des services de publicité comme de télémétrie, autant on peut aussi bloquer un site complet ou un service de mise à jour. Divers : Blocage auto On peut comme sur nos NAS bloquer automatiquement une IP qui serait un peu trop curieuse. Perso, je fonctionne avec 2 tentatives sous 1 minute ce qui peut faire peu si vous n'êtes pas doués pour taper vos mots de passe. Vous pouvez toujours changer cette valeur mais ne la mettez pas trop haute. Centre réseau > Sécurité > Blocage auto Nous pouvons aussi enregistrer des adresses IP privées ou publiques (local ou internet) afin d'éviter qu'une personne se bannisse d'elle même. Ex : on peut mettre son smartphone ou son ordinateur. Pour des raisons de maintenance en cas de problème, nous pouvons activer le protocole de communication SSH. Pour des raisons de sécurité, je ne vous recommande pas d'ouvrir le port dans votre Pare-feu ! Panneau de configuration > Services > System Services Petite astuce en cas de faille ou si on est un peu trop parano, on peut rediriger le port SSH sur une adresse IP privée non attribuée. Ajout d'un compte administrateur : Prérequis : avoir déjà créé un compte utilisateur à qui l'on souhaite octroyer les droits "admin". Par défaut, Synology n'autorise que deux administrateurs sur le routeur à savoir le compte par défaut "admin" qui est désactivé et le compte créé lors de l'installation du routeur. Grâce à l'astuce proposée par @maxou56, nous allons pouvoir ajouter autant de compte administrateur que l'on souhaite. Perso, j'aime avoir en permanence un compte administrateur système de secours. Pour se faire, on doit se connecter en SSH : ssh root@192.168.x.x Le mot de passe demandé sera celui du compte utilisateur "admin". Si vous avez changé le port par défaut qui est 22 alors tapez la commande ci-dessous en modifiant le port par le votre (port 1234 dans cet exemple) : ssh root@192.168.x.x -p 1234 On passe ensuite en compte "root" avec la commande : su root su root AVERTISSEMENT : à partir de maintenant, vous avez tous les droits en SSH. Une commande mal tapée pourrait vous coûter cher ! Pour obtenir la liste des administrateurs, on tape la commande : synogroup --get administrators Résultat : ~ # synogroup --get administrators Group Name: [administrators] Group Type: [AUTH_LOCAL] Group ID: [101] Group Members: 0:[admin] 1:[xxxxxxxxxxx] Pour ajouter un utilisateur au groupe "administrateur", il vous faut l'ajouter via une commande sans omettre les comptes administrateurs déjà en place. synogroup --member administrators admin xxxxxxxxxxx nouvel_utilisateur (en rouge, ce sont les comptes admin qui étaient déjà en place). synogroup --member administrators admin xxxxxxxxxxx nouvel_utilisateur Pour retirer un utilisateur du groupe "administrateur", il faut taper la même commande mais sans l'utilisateur qu'on désire retiré. N'étant pas dans la commande tapée, il sera enlevé du groupe. synogroup --member administrators admin xxxxxxxxxxx (en rouge, ce sont toujours les comptes administrateurs qui étaient déjà en place et que je veux garder). synogroup --member administrators admin xxxxxxxxxxx Je ne suis pas un expert en réseau mais juste un passionné d'informatique. C'est pourquoi si vous constatez des erreurs ou que vous voudriez apporter votre pierre à ce petit édifice, vous serez les bienvenus 🙂 Merci à Einsteinium pour l'aide apportée dans l'édition de ce tuto 😉

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

Refonte du tutoriel pour la V6, amélioration du fichier compose et mise à jour des impressions d'écran.

Installation du firmware Qnap (QTS) sur NAS Fujitsu Celvin via SSH Rappel: La majorité des serveurs NAS Fujitsu Celvin sont fabriqués par QNAP (Produits OEM ou Co-branding) ce qui signifie que les modèles Fujitsu sont des versions reconditionnées de modèles QNAP, avec un design légèrement modifié (logo, couleur) et un firmware spécifique. Le firmware de Fujitsu (Celvin OS) est très proche de celui de Qnap (QTS). Fujitsu assure la totalité des services comme pour tous produits Fujitsu: Support client, mise à disposition de mises à jours et d'applications qui lui sont propres, même si elles sont identiques à celles du Qnap. Parfois Fujitsu ne fait que changer le nom de l'application. Fujitsu dispose de ses propres serveurs pour les mises à jours et pour "app center". Pourquoi migrer de Fujitsu à Qnap? Fujitsu a cessé le support des NAS CELVIN. Par exemple les NAS sortis entre 2009 et 2012 ne sont plus pris en charge par Fujitsu depuis 2018. En 2025, Fujitsu a arrêté le serveur d'app center, Plus aucune application n’apparaît dans le magasin d'applications. La seule manière d'installer des applications est l'installation manuelle. En 2020 Fujitsu et Qnap ont décidé que Qnap poursuive le support pour les NAS concernés. Une fois le NAS migré, il est pris en charge par Qnap et bénéfice de tous les services et supports de Qnap. La migration permet de bénéficier des mises à jours de sécurité du firmware Qnap. Elle permet de retrouver un app center fonctionnel et permet d'installer les anciennes applications qui y sont proposées. Même chez Qnap, pour le vieux matériel certaines applications ne bénéficient plus de mise à jours, ce qui limite de l'utilisation des applications officielles. Mais beaucoup d'applications non officielles sont disponibles en paquets (qpkg), notamment sur le site myqnap.org. L'intérêt de la migration est essentiellement d'obtenir les mises à jours de sécurité de QTS. Pour bénéficier d'applications récentes, l’utilisation d'applications tiers est la meilleurs solution. Comment migrer? En accord avec Qnap, Fujitsu propose pour certains modèles une méthode automatisée par l'installation d'un paquet officiel (qpkg) qui permet d'installer le firmware QNAP (QTS) à la place de celui de Fujitsu par l'interface de gestion du NAS comme si on faisait une simple mise à jour. Le paquet modifie tout simplement le nom du modèle du NAS pour que la mise à jour vers le firmware équivalent de chez Qnap fonctionne Les modèles concernés sont les suivants:Q805, Q905, QR806, QR1006, QE705, QE805, QE707, QE807. L'autre moyen de migrer est d'utiliser la méthode manuelle par SSH présentée ici. Pour les modèles qui ne bénéficient pas de la méthode automatique, SSH est la seule méthode possible. Migration manuelle par SSH: Prérequis: Avoir un NAS fonctionnel: Avec au moins un disque dur configuré dans le NAS, qu'il soit accessible depuis votre PC avec l'interface de gestion Web et avec accès aux dossiers partagés depuis votre PC. A savoir: Les systèmes d'exploitation des NAS Qnap (et Fujitsu), sont basés sur un noyaux Linux. Vous y retrouverez donc des programmes et structures similaires. Il est même possible d'installer une distribution Linux comme Debian sur le NAS. La méthode SSH utilise une procédure d'installation manuelle du firmware fournie par Qnap. Elle est réservée aux utilisateurs avertis, car elle permet d'installer un firmware dont le nom de modèle ne correspond pas à celui installé sur le NAS. Il faut être sûr d'avoir le firmware du modèle Qnap correspondant à votre NAS Fujitsu. Si vous installez le mauvais firmware, vous pouvez rendre votre NAS inutilisable! Vérifiez bien sur le site de Qnap si les caractéristiques sont les mêmes que votre modèle Fujitsu. Après installation, le nom de modèle de votre NAS sera celui de Qnap, il sera reconnu comme tel par Qnap et app center proposera les applications compatibles avec votre modèle. Vous trouverez des ressources (Aides - How to) en français sur le site de QNAP https://www.qnap.com/fr-fr/how-to/search Il existe un wiki plus complet en anglais https://wiki.qnap.com/wiki/Main_Page Procédure: Télécharger le firmware QNAP correspondant à votre modèle. Le firmware se présente comme une image de disque (.img) qui est compressée au format zip (.zip): Allez dans le Centre de téléchargement QNAP: https://www.qnap.com/fr-fr/download Sous "Type de produit", sélectionnez "NAS / Extension". Sous "Baie", sélectionnez le nombre de baies de lecteur pour votre NAS. Sous "Modèle", sélectionnez le nom du modèle Qnap correspondant à votre NAS Fujitsu. Dans la section "Télécharger les éléments", cliquez sur "Système d’exploitation". La liste qui apparait est celle du firmware (Système d'exploitation) avec le plus récent en haut. Téléchargez le fichier en cliquant sur le lien dans la colonne "Lien de téléchargement". Décompressez le fichier zip. Copiez le firmware dans le dossier Public du NAS: Vous pouvez renommer le ficher image (.img) que vous venez de décompresser. J'ai effectué la migration d'un Q703. Je prends donc ce modèle comme exemple. J'ai renommé le ficher image en "TS-221.img". Remplacer "TS-221.img" par le nom que vous avez choisi dans le reste du tutoriel. Par l'explorateur de fichiers de votre système, copiez le fichier image dans le dossier Public du NAS. Autoriser la connexion SSH dans le NAS: SSH, pour Secure Shell, est un protocole de communication réseau qui permet d’établir une session chiffrée entre deux machines, typiquement un client et un serveur. Si la connexion au NAS par SSH n'est pas activée, vous devez l'activer soit par l'interface du NAS, soit avec Qfinder. Si besoin aller voir l'aide QNAP: https://www.qnap.com/fr-fr/how-to/faq/article/comment-acc%C3%A9der-%C3%A0-mon-nas-qnap-en-utilisant-ssh Accédez à votre NAS avec SSH: Vous devez ouvrir une console (un terminal) prenant en charge SSH. Sous MacOS et Linux, cette fonctionnalité est généralement activée par défaut. Sous Windows, elle n'est pas toujours disponible. Sous Windows 10 ou 11, Vous devez activer le "client OpenSSH" dans les paramètres de Windows. Si vous ne savez pas comment faire, vous trouverez des tutos sur internet. Une fois fait, les consoles de Windows prendrons en charge SSH. Il vous suffit alors d'ouvrir une console, soit par l’invite de commandes Windows (CMD), soit par PowerShell. Sinon, vous pouvez installer un programme comme "Git Bash" ou "PuTTY". La page d'aide indiqué précédemment montre la méthode pour MacOS et pour Windows avec "PuTTY". Installer le firmware avec l'image: Dans la console que vous venez d'ouvrir, saisissez les commandes suivantes et terminez par la touche "Enrtée" pour validez (exécutez) les commandes. Vous pouvez les copier-coller. N'oubliez pas d'adapter les valeurs à votre cas (adresse IP du NAS, nom de l'image). Code: ssh Code: ssh admin@ipRemplacez « ip » par l'adresse IP de votre NAS. Le système vous demande ensuite le mot de passe. Celui par défaut est « admin ». [Par cette commande, vous vous connectez au NAS à distance en vous identifiant comme l'utilisateur "admin", comme vous le faites lorsque vous accédez à l'interface de gestion du NAS avec votre navigateur, mais ici vous le faites en ligne de commande par le protocole SSH.] Saisissez ensuite les commandes suivantes: Code: mkdir /mnt/HDA_ROOT/update[Cette commande créé le répertoire "update" dans le répertoire HDA_ROOT.] Code: rm -rf /mnt/update[Cette commande efface le contenu du répertoire "update" au cas où il ne soit pas vide.] Code: rm -f /tmp/update_process[Cette commande efface un éventuel fichier temporaire qui serait resté d'une précédente mise à jour] Code: ln -sf /mnt/HDA_ROOT/update /mnt/update[Cette commande créé un lien symbolique entre les deux emplacements.] Code: /etc/init.d/update.sh /share/Public/TS-221.img[Cette commande lance le "script" (ou programme) d'installation du firmware (update.sh) et lui indique ne nom de l'image ("TS-221.img" dans mon cas) et son emplacement (dossier Public du NAS).] Le processus d'installation se déroule et des informations apparaissent dans le terminal tout au long du processus. Le processus peut prendre un certain temps. Vous verrez apparaitre le nom du modèle d'origine du NAS, Q703 dans mon cas : "model name = Q703". Une ligne plus bas vous indiquera le nouveau nom de modèle qui sera attribué au NAS: TS-221 dans mon cas. Si tout se déroule correctement, la procédure se termine par le message : « Mise à jour terminée ». Saisissez ensuite : Code: rebootAprès le redémarrage, qui est assez long, vous trouverez la nouvelle interface sous QTS en vous connectant au NAS avec votre navigateur ! Dans mon cas, tout était intact : mes applications et mes données étaient toujours présentes. [Pour information, après la migration j'ai voulu faire une réinitialisation sans formatage des disques, Mais lors du redémarrage, le système m'a forcé à réinstaller le firmware. Il suffit de sélectionner le fichier image (TS-221.img dans mon cas) et de laisser le processus se faire.] Il est alors possible de créer un compte sur le site de QNAP, d'enregistrer le NAS et d'utiliser tous les services QNAP. N'hésitez pas à partager vos expériences de migration de votre NAS ou à les publier sur le forum! Je suppose que cette méthode fonctionne avec tous les modèles QNAP, car la documentation QNAP ne mentionne aucun modèle particulier. - Page de l'aide du site QNAP pour la mise à jour par SSH: Comment mettre à jour manuellement le firmware par SSH ? - Page du site Wiki QNAP pour la mise à jour par SSH: : Manually Updating Firmware Au cas où votre NAS ne démarre plus: Récupérer un NAS ARM ancienne génération Récupérer un NAS X86 ancienne génération

Bonjour à tous, Voici mon retour d’expérience et donc un tuto sur la mise en place de Adguard Home via docker (Synology) avec un réseau macvlan sur une Livebox 6. Avec pour but que les DNS soit automatiquement affecter aux périphériques via le serveur DHCP. Contexte : La livebox 6 (idem sur les anciennes box) ne permet pas de modifier les DNS dans son serveur DHCP. Il faut donc passer le serveur DHCP sur un autre équipement. Inconvénient le décodeur TV Orange s'attend à communiquer avec le DHCP de votre Livebox et aucun autre serveur DHCP. Du coup, vous allez avoir un message d'erreur sur votre box TV et vous n'aurez accès à aucun service. Pour résoudre ce problème, il faut ajouter une configuration spéciale (option 125) au nouveau serveur DHCP, afin d’émuler le comportement de la Livebox et faire croire à votre box TV que tout va bien. Si vous ne faites pas cela vous allez obtenir, par exemple, une erreur G03 (ou un écran tout blanc) lors du démarrage de votre décodeur TV UHD. Prérequis : Une livebox avec sa box TV Un NAS Synology Docker sur le NAS Synology (Je n’ai pas Container Manager mais cela sera fonctionnel avec) Un logiciel pour se connecter en SSH au NAS ( PuTTY ) Un éditeur de texte (Exemple : Notepad++) Installation : Installation via Docker sur mon Nas Synology (DS415+) Installation du réseau MacVLAN pour le futur conteneur AdGuard Home AdGuard Home avec DHCP et règle 125 via docker sur le Synology Je n’utilise pas le serveur DHCP du Synology, car je ne sais pas modifier la règle 125 sur ce serveur. Avant de rentrer dans le vif du sujet, je voudrais remercier toutes les personnes qui ont partagées leurs connaissances pour arriver à mes fins. Je n’ai rien inventé, j’ai juste compilé les informations glanées à droite et à gauche. Vous pouvez reprendre toutes mes infos pour les partager au monde entier. Merci à @.Shad. pour ces deux tutos (Docker) et (MACVLAN). Merci à @MilesTEG1 qui partage ces scripts et le docker-compose dans le topic de Adguard (ici) fait par @CyberFr Et surtout merci à LapinFou et JPA54 du forum framboise314.fr qui explique l’option 125 du DHCP (ici), sans qui la box TV ne serait pas en fonction. Sommaire : Installation de réseau MACVLAN Création du réseau MACVLAN Création de l'interface virtuelle Création de la tâche de rétablissement de l'interface virtuelle au redémarrage Création de l’instance Adguard Home Création du docker-compose Lancer le docker-compose Faire fonctionner la BoxTV. Création du DHCP dans AdGuard Home Modification du fichier .yaml (Regle 125 du DHCP) Désactiver le DHCP de livebox Réserver l’IP dans le DHCP d’AdGuard Home Paramètre du client (BoxTV) dans AdGuard Home Paramétrage de Adguard Home Paramétrage des périphériques AdGuard Home + DOCKER + MACVLAN + LIVEBOX Installation du réseau MACVLAN Création du réseau MACVLAN Je vous conseil d’aller lire le tuto de @.Shad. dans la partie 11 pour en apprendre plus : [TUTO] Docker : Introduction - Tutoriels - NAS-Forum Je ne vais pas refaire l’explication, tout est dit par @.Shad. Le but est de créer un fichier script qu’on va activer via Putty. Vous pouvez récupérer le fichier à modifier sur le GITUB de MilsTEG1 : Synology-Docker-Adguard-Home-in-a-macvlan-network/docker_network_create_macvlan.sh at main · MilesTEG1/Synology-Docker-Adguard-Home-in-a-macvlan-network · GitHub Où créer un fichier que vous nommez ainsi docker_network_create_macvlan.sh Puis vous l’éditer avec Notepad++ avec cela : #!/bin/bash ##========================================================================================## ## Script macvlan-network.sh ## ## ## ## Script de création d'interface virtuelle pour le conteneur AdGuardHome_macvlan ## ## Voir tuto : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/ ## ## ## ##========================================================================================## echo "$(date "+%R:%S - ") Script de création de réseau macvlan pour DOCKER" echo "$(date "+%R:%S - ") Un réseau macvlan-network sera créé avec cinq IP macvlan de 192.168.1.145 à 192.168.1.150" echo "$(date "+%R:%S - ") avec la commande suivante :" echo "$(date "+%R:%S - ") docker network create -d macvlan \ " echo "$(date "+%R:%S - ") --subnet=192.168.1.0/24 \ " echo "$(date "+%R:%S - ") --ip-range=192.168.1.144/29 \ " echo "$(date "+%R:%S - ") --gateway=192.168.1.1 \ " echo "$(date "+%R:%S - ") -o parent=eth0 \ " echo -e "$(date "+%R:%S - ") macvlan-net\n" docker network create -d macvlan \ --subnet=192.168.1.0/24 \ --ip-range=192.168.1.144/29 \ --gateway=192.168.1.1 \ -o parent=eth0 \ macvlan-network echo -e "\n\n$(date "+%R:%S - ") Liste des réseaux docker : docker network ls\n" docker network ls echo -e "\n$(date "+%R:%S - ") Script terminé\n" exit Notes : - 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 peut vous aider à trouver la plage que vous voulez. Voici mon exemple : IPv4/IPv6 – Subnet Calculator | CIDR/EU Ainsi j’aurai 5 IP de disponible dans le réseau MACVLAN qui seront de 192.168.1.145 à 192.168.1.1.150. On expliquera plus tard comment affecter l’IP au conteneur via le docker-compose. 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. Mon DHCP est et sera de 192.168.1.50 à 192.168.1.65 et la plage de MACVLAN 192.168.1.145 à 192.168.1.150 Adapter ces valeurs en fonction de votre réseau. - gateway => c'est notre passerelle, vu qu'on est sur le réseau physique c'est généralement votre box ou votre routeur. En l’occurrence pour une livebox : 192.168.1.1 - parent => c'est le nom de l'interface physique. Pour la connaitre, lancer putty : Taper l’adresse IP de votre NAS et cliquer sur OPEN (Penser à activer pour les manipulations le service SSH dans le DSM de votre NAS = PanneauConfiguration\Terminal & SNMP) Entrer votre login administrateur du Synology, valider avec la touche entrée. Taper le mot de passe administrateur (il n’apparait pas quand vous taper, cela est normal) , valider avec la touche entrée. Taper ifconfig, valider avec la touche entrée. Chercher le nom du réseau qui correspond à l’IP de votre NAS. Sur mon exemple et mon NAS Synology DS415+, le nom est donc eth0 Enregistrer ce fichier puis connectez vous au DSM de votre NAS et lancer File Station. Dans le dossier docker, je vous conseil de créer un dossier FICHIERS puis 2 sous dossiers SCRIPTS & COMPOSE. Placer le fichier fraichement créer dans /volume1/docker/FICHIERS/SCRIPTS Lancer PuTTY et connectez-vous en root. Pour cela taper cela sudo -i Ensuite il faut se placer dans le dossier où est le script : cd /volume1/docker/FICHIERS/SCRIPTS On accorde les permissions (pas sûr que cela soit nécessaire) chmod 740 docker_network_create_macvlan.sh On exécute le script bash docker_network_create_macvlan.sh Si tout va bien, on obtient une suite de caractères, cela signifie que le réseau est créé. Et vérifier qu'il apparaît bien dans la liste. En cas d'erreur dans la transcription, il suffit de supprimer le réseau malformé pour recommencer : docker network rm macvlan-network 2. Création de l'interface virtuelle On va créer un second script. Vous pouvez récupérer le script orignal toujours sur le GITHUB de MilesTEG1 : Synology-Docker-Adguard-Home-in-a-macvlan-network/bridgemacvlan-interface.sh at main · MilesTEG1/Synology-Docker-Adguard-Home-in-a-macvlan-network · GitHub Où créer un fichier que vous nommez ainsi bridgemacvlan-interface.sh Puis vous l’éditer avec Notepad++ avec cela : #!/bin/bash ##===========================================================================================## ## Script bridgemacvlan-interface.sh ## ## ## ## Script de création d'interface virtuelle pour les conteneurs en macvlan ## ## Voir tutos : ## ## https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/ ## ## https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ ## ## ## ## Vérifier la bonne création de l'interface avec la commande suivante : ## ## ifconfig | grep -A 9 macv0 ## ## ## ##============================================================================================= # Set timeout to wait host network is up and running sleep 60 echo "$(date "+%R:%S - ") Script de création d'une interface virtuelle pour le NAS" echo "$(date "+%R:%S - ") Exécution des commandes..." ip link add macv0 link eth0 type macvlan mode bridge # macv0 : est le nom données à l'interface virtuelle # eth0 : est l'interface réseau utilisée sur le NAS (lorsque VMM n'est pas utilisé) # si VMM est utilisé, ce sera ovs_eth0 ip addr add 192.168.1.200/32 dev macv0 # Adresse IP virtuelle 192.168.x.zzz/32 -- Il faut que cette adresse soit libre dans le réseau # et qu'elle ne fasse pas partie du DHCP du routeur/box ip link set dev macv0 address 5E:11:4F:AF:D6:D2 # MAC adresse pour l'adaptateur ayant l'IP virtuelle # Il faut que l'adresse MAC respecte ces conditions : # - Elle n'existe pas déjà sur mon hôte et sur mon réseau. # - Elle respecte la base hexadécimale, les notations allant de 0 à F. # - Le premier nombre doit être pair, ici 5E = 94 en base 10, c'est donc OK (vous pouvez # utiliser un convertisseur en ligne, ou faire vos divisions euclidiennes). # S'il est impair, vous aurez un message : # RTNETLINK answers: Cannot assign requested address ip link set macv0 up ip route add 192.168.1.144/29 dev macv0 # 192.168.xxx.MMM/29 : Plage d'adresse macvlan # IP réellement disponible : voir les calculateurs internet # /29 = 5 IP - /32 = 1 IP #### Dans mon cas, c'est cette commande : #### ip route add 192.168.1.144/29 dev macv0 echo "$(date "+%R:%S - ") Script terminé" exit Notes : 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, macv0 par exemple, peu importe - <interface_physique> => eth0 / idem que sur le premier script - <IP_virtuelle> => il l faut que cette adresse soit libre dans le réseau et qu'elle ne fasse pas partie du DHCP du routeur/box et du réseau MACVLAN. Je choisi la 192.168.1.200 qui se traduit par 192.168.1.200/32. - <adresse MAC> => on peut définir une adresse MAC pour notre interface. Il faut que cette adresse soit libre dans le réseauet qu'elle ne fasse pas partie du DHCP du routeur/box. - <Plage_DHCP_réseau_macvlan> => ça correspond à --ip-range dans le script plus haut Enregistrer le fichier et placer le, toujours avec File Station dans /volume1/docker/FICHIERS/SCRIPTS Revenez dans putty et placer vous dans ce dossier cd /volume1/docker/FICHIERS/SCRIPTS On accorde les permissions (pas sûr que cela soit nécessaire) chmod 740 bridgemacvlan-interface.sh On exécute le script bash bridgemacvlan-interface.sh On vérifie en tapant : ifconfig | grep -A 9 mac0 Ce qui doit donner un résultat du type : 3. Création de la tâche de rétablissement de l'interface virtuelle au redémarrage L’interface ne persiste pas au redémarrage du NAS, on va pour cela définir une tâche planifiée, il faut aller dans DSM -> Panneau de configuration -> Planificateur de tâches -> Créer -> Tâche déclenchée : Puis on valide. REMARQUE : Lorsqu'on stoppe docker, ou qu'on le met à jour, l'interface disparaît également. La tâche n'étant lancée qu'au démarrage, vous devrez réexécuter la tâche manuellement pour rétablir l'interface. 2. Création de l’instance Adguard Home 2.1. Création du docker-compose Le fichier docker-compose est encore est toujours récupérable sur le GITHUB de MilesTEG1 : Synology-Docker-Adguard-Home-in-a-macvlan-network/docker-compose.yml at main · MilesTEG1/Synology-Docker-Adguard-Home-in-a-macvlan-network · GitHub On le modifie avec notepad++. Je n’indique que les parties que j’ai modifié hostname: AdGuard-Home--DS415+ Permet d'avoir un nom pour le conteneur dans AdGuard lui-même (sinon c'est une chaine aléatoire) Environment: PUID=1*** PGID=1** Pour récupérer l’info, voici un excellent tuto : NAS Synology - Récupérer l'UID et le GID d'un utilisateur (it-connect.fr) #volumes: Je n’ai pas touché au volume. Cependant j’ai créé les dossiers /volume1/docker/adguardhome_macvlan/work & /volume1/docker/adguardhome_macvlan/conf avant de lancer le fichier docker-compose.yml networks: macvlan-network: ipv4_address: 192.168.1.150 Mettre ici l'IP macvlan dans la plage définie dans les scripts. Pour rappel ma plage MACVLAN est 192.168.1.145 à 192.168.1.150 networks: macvlan-network : # Le nom du réseau créer via le script docker_network_create_macvlan.sh (ligne 27) Ce qui donne pour moi (il faut modifier PUID & PGID) : ##============================================================================================== ## ## ## Fichier docker-compose.yml pour Adguard-Home en macvlan ## ## ## ##============================================================================================== ##============================================================================================## ## ## ## Attention, il faut créer le réseau macvlan à l'aide du script : macvlan-network.sh ## ## Ce dernier va créer un réseau macvlan ayant comme IP unique 192.168.1.150 ## ## Cette IP doit être dans la plage d'IP mavclan définie dans le script de création du réseau.## ## Le conteneur sera donc vu comme une machine sur le réseau LAN, mais ne pourra pas être ## ## joint par le NAS lui-même. ## ## Pour celà, il faut utiliser le second script : boot-bridgemacvlan-interface.sh ## ## Ce dernier va créer une IP-interface virtuelle qui pourra être accessible par le NAS. ## ## Cette interface ne persiste pas au démarrage, il faudra mettre le script en tâche ## ## planifiée avec le planificateur de tâches dans DSM. ## ## ## ## Voir tuto : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/ ## ## ## ## Attention ! ## ## ## ## Ces deux scripts ne sont à utiliser qu'une seule fois, quelque soit le nombre de ## ## conteneurs qui en bénéficieront. ## ## Par exemple, si vous utilisez 2 conteneurs en macvlan, une fois le réseau macvlan créé ## ## pour le 1er, il est inutile (et impossible) de le recréer. ## ## Le script boot-bridgemacvlan-interface.sh ne doit être lancé qu'une seule fois, et à ## ## chaque reboot. L'IP virtuelle est unique, il ne faut pas en recréer une seconde. ## ## ## ##============================================================================================== --- version: "2.4" services: adguardhome_macvlan: image: adguard/adguardhome:latest # https://github.com/AdguardTeam/AdGuardHome # https://github.com/AdguardTeam/AdGuardHome/wiki/Docker container_name: adguardhome_macvlan hostname: AdGuard-Home--DS415+ # Permet d'avoir un nom pour le conteneur dans AdGuard lui même (sinon c'est une chaine aléatoire) environment: - PUID=1*** # Utiliser la commande (en SSH) : id NOM_UTILISATEUR - PGID=1** # Utiliser la commande (en SSH) : id NOM_UTILISATEUR - TZ=Europe/Paris - LANG=fr_FR.UTF8 - LANGUAGE=fr_FR.UTF8 volumes: - "/volume1/docker/adguardhome_macvlan/work:/opt/adguardhome/work" - "/volume1/docker/adguardhome_macvlan/conf:/opt/adguardhome/conf" # La déclaration des ports n'est pas utile lors d'une installation en macvlan, car tous les ports seront directement accessible # avec l'IP virtuelle. # ports: # - "953:53" # - "967:67/udp" # - "968:68" # - "8080:80/tcp" # - "9443:443/tcp" # - "9853:853/tcp" # - "3030:3000/tcp" networks: macvlan-network: ipv4_address: 192.168.1.150 # Mettre ici l'IP macvlan dans la plage définie dans les scripts # Dans mon cas c'est 192.168.1.150 restart: unless-stopped healthcheck: test: "/bin/netstat -pant | /bin/grep 53" interval: 45s timeout: 30s retries: 3 networks: macvlan-network: # Ce réseau devra bien entendu être créé avant avec le script annexe ligne27 external: true Enregistrer le fichier. Placer le, toujours avec File Station, dans /volume1/docker/FICHIERS/COMPOSE/ADGUARD. Créer le dossier ADGUARD s’il n’existe pas. 2.2. Lancer le docker-compose Revenez dans PuTTY, placer vous dans le dossier : cd /volume1/docker/FICHIERS/COMPOSE/ADGUARD Création du conteneur docker-compose up -d Attendre quelques secondes/minutes (en fonction de la puissance de votre NAS). Félicitations, votre Adguard Home est fonctionnel ! Vous pouvez y accéder via un navigateur dans votre réseau local en http://192.168.1.150:3000 Il n’est pas accessible en https. Sélectionner l’interface d’écoute par l’IP choisi dans le docker-compose en l’occurrence pour nous 192.168.1.150. Ne pas toucher au port. Ne pas toucher au serveur DNS et cliquer sur Suivant Créer un utilisateur avec son mot de passe puis toujours suivant. Vous êtes maintenant sur votre instance AdGuard Home. 3. Faire fonctionner la BoxTV Afin de faire fonctionner la box TV nous réaliser ces actions : Création du DHCP dans AdGuard Home Modification du fichier .yaml pour la règle 125. Désactiver le DHCP de livebox Réserver l’IP dans le DHCP d’AdGuard Home Paramètre du client (BoxTV) dans AdGuard Home 3.1. Création du DHCP dans AdGuardHome Cliquer sur Paramètres Cliquer sur Paramètres DHCP Rentrer l’IP de la passerelle de votre livebox (d’origine 192.168.1.1) Rentrer l’IP du début de la plage IP de votre DHCP (pour moi 192.168.1.50) Rentrer l’IP de la fin de la plage IP de votre DHCP (pour moi 192.168.1.65). J’aurai donc 15 périphériques qui pourront se connecter sur mon DHCP. A vous d’adapter ces chiffres en évitant ces IP (192.168.1.145 à 192.168.1.150 & 192.168.1.200) Rentrer 255.255.255.0 Sauvegarder la configuration 3.2. Modification du fichier .yaml pour la règle 125. Afin d’ajouter l’option 125 dans le fichier AdGuardHome.yaml qui permettra de faire croire à la BoxTV que son IP soit fourni par la Livabox, il faut créer la bonne ligne. Tout est super bien expliquer dans le tutorial de LapinFou : [Tuto] Pi-Hole, Livebox et décodeur TV Orange - framboise314.fr Je vous conseil de le suivre à la lettre pour créer votre ligne. Voici ma ligne : Les chiffres en blanc ne sont pas à changer. Ceux en couleurs oui. 343444343534 = les 6 premiers caractères de l'adresse MAC (44D454) de la Livebox convertie en "Hexa" C4B32**********50393939383035 = Le numéro de série (LK*****DP999805) de la Livebox convertie en "Hexa" 36 = Le modèle de la box (ici Livebox 6) convertie en "Hexa" Toutes ces informations sont disponible depuis son interface web (http://livebox/ ou http://192.168.1.1) "Informations système" → "Général" → "1.5 Adresse MAC" / "1.4 Numéro de série" / "1.2 Modèle" Voici le site pour convertir en "Hexa" : https://string-functions.com/string-hex.aspx Après avoir récupérer le HEX, il faut l’ajouter en option dans le AdGuardHome.yaml. Retour sur le NAS et on procède ainsi 1. On arrête l’instance dans docker 2. On télécharge le fichier AdGuardHome.yaml qui ce trouve dans /volume1/docker/adguardhome_macvlan/conf/ 3. On le modifie avec Notepad++ On ajoute la ligne après option comme dans mon exemple : dhcp: enabled: true interface_name: eth0 local_domain_name: lan dhcpv4: gateway_ip: 192.168.1.1 subnet_mask: 255.255.255.0 range_start: 192.168.1.50 range_end: 192.168.1.65 lease_duration: 86400 icmp_timeout_msec: 1000 options: - '125 hex 00000DE9240406343444343534050F4C4B3232303636445039393938303506094C697665626F782036' 4. On enregistre le fichier et on le place dans /volume1/docker/adguardhome_macvlan/conf/ pour remplacer l’ancien 5. On relance l’instance adguardhome_macvlan 3.3. Désactiver le DHCP de livebox Revenez sur votre interface de votre BOX et désactiver le DHCP. Si vous voyer l’adresse MAC de votre box TV, noter là pour plus tard. 3.4. Réserver l’IP dans le DHCP d’AdGuard Home Revenez sur l’interface graphique de AdGuard Home (http://192.168.1.150) Toujours dans Paramètres / Paramètres DHCP, aller tout en bas dans Baux statiques DHCP et cliquer sur "Ajoutez un bail statique" et rentrer ces informations : L’adresse MAC du boitier TV L’IP que vous voulez lui allouer. Exemple 192.168.1.66 Un nom. Exemple BoxTV Enregistrer Maintenant il va falloir un paramétrage persistant pour ce client. 3.5. Paramètre du client (BoxTV) dans AdGuard Home Maintenant aller dans Paramètres / Paramètres du client et "Ajouter un client" avec ces infos : Paramètres Le nom que vous voulez Mots clés : ne pas toucher Identifiant L’IP de la box La MAC de la box Protection : tout décocher Blocage des services spécifiques Tout débloquer Suspendre le blocage des services Ne pas toucher Serveurs DNS upstream Passerelle de la box : 192.168.1.1 Indiquer les DNS de la box (Info trouvable sur l’interface de la box dans Paramètres avancés\Informations système\Internet\4.12 & 4.13 Pour moi : 80.10.246.132 & 81.253.149.2 Enregistrer. A partir de maintenant le paramétrage est fini vous pouvez rallumer la box tv et vérifier si cela fonctionne. Si oui, félicitation !! 😇🤩🍾 Il nous reste plus qu'à peaufiner les paramétrages d’AdGuard Home et des périphériques. 4. Paramétrage de AdGuard Home Présentation et explication faite plus tard Paramètres Paramètres généraux J'ai tout coché (sauf youtube) Paramètres DNS Serveur DNS upstream https://family.cloudflare-dns.com/dns-query tls://family.cloudflare-dns.com https://family.adguard-dns.com/dns-query tls://family.adguard-dns.com Serveurs DNS d'amorçage 1.1.1.3 1.0.0.3 2606:4700:4700::1113 2606:4700:4700::1003 Filtres Liste de blocage DNS filters: - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_1.txt name: AdGuard DNS filter id: 1 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_2.txt name: AdAway Default Blocklist id: 2 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_50.txt name: uBlock₀ filters – Badware risks id: 1715176311 - enabled: true url: https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV-AGH.txt name: Perflyst and Dandelion Sprout's Smart-TV Blocklist id: 1603827714 - enabled: false url: https://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblockplus&showintro=1&mimetype=plaintext name: Peter Lowe's List id: 1603827715 - enabled: true url: https://raw.githubusercontent.com/hoshsadiq/adblock-nocoin-list/master/nocoin.txt name: NoCoin Filter List id: 1603827716 - enabled: true url: https://raw.githubusercontent.com/durablenapkin/scamblocklist/master/adguard.txt name: Scam Blocklist by DurableNapkin id: 1603827717 - enabled: true url: https://raw.githubusercontent.com/Spam404/lists/master/main-blacklist.txt name: Spam404 id: 1603827718 - enabled: true url: https://sebsauvage.net/hosts/hosts-adguard name: sebsauvage.net hosts-adguard id: 1603827720 - enabled: true url: https://gitlab.com/quidsup/notrack-blocklists/raw/master/notrack-blocklist.txt name: firebog.net - NoTrack-blocklist id: 1603827721 - enabled: true url: https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV.txt name: firebog.net - SmartTV id: 1603827722 - enabled: true url: https://raw.githubusercontent.com/DandelionSprout/adfilt/master/GameConsoleAdblockList.txt name: Game Console Adblock List id: 1614201141 - enabled: true url: https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt name: WindowsSpyBlocker - Hosts spy rules id: 1614201143 - enabled: true url: https://raw.githubusercontent.com/mitchellkrogza/The-Big-List-of-Hacked-Malware-Web-Sites/master/hosts name: The Big List of Hacked Malware Web Sites id: 1614201145 - enabled: true url: https://adaway.org/hosts.txt name: AdAway Default Blocklist id: 1657191092 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_18.txt name: Phishing Army id: 1715209163 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_8.txt name: NoCoin Filter List id: 1715209164 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_31.txt name: Stalkerware Indicators List id: 1715209165 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_30.txt name: Phishing URL Blocklist (PhishTank and OpenPhish) id: 1715209166 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_10.txt name: Scam Blocklist by DurableNapkin id: 1715209167 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_42.txt name: ShadowWhisperer's Malware List id: 1715209168 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_9.txt name: The Big List of Hacked Malware Web Sites id: 1715209169 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_11.txt name: Malicious URL Blocklist (URLHaus) id: 1715209170 - enabled: true url: https://adguardteam.github.io/HostlistsRegistry/assets/filter_12.txt name: Dandelion Sprout's Anti-Malware List id: 1715209171 - enabled: true url: https://dl.red.flag.domains/adguard/red.flag.domains.txt name: Nicolas Pawlak id: 1715209172 - enabled: true url: https://dl.red.flag.domains/adguard/red.flag.domains_fr.txt name: Nicolas Pawlak FR id: 1715209173 - enabled: true url: https://dl.red.flag.domains/adguard/red.flag.domains_ovh.txt name: Nicolas Pawlak OVH id: 1715209174 - enabled: true url: https://dl.red.flag.domains/adguard/red.flag.domains_yt.txt name: Nicolas Pawlak YT id: 1715209175 Services Bloqués Faites vos choix Règles de filtrage personnalisées ||example.org^ :bloque l’accès au domaine example.org et à tous ses sous-domaines ; @@||nas-forum.com^ :débloque l’accès au domaine nas-forum.com et à tous ses sous-domaines ; Attention cette option ne permet pas de débloquer un site bloqué par les Serveurs DNS upstream. Pour bloquer les publicités sur youtube, facebook ou autre via un PC, je vous conseil d'ajouter un bloqueur de publicités à votre navigateur. Style : Ublock Origin. N'oublier pas de passer un liste blanche vos sites préférés comme www.nas-forum.com 5. Paramétrage des périphériques Windows Laisser en DHCP pour vos équipement ainsi il prendra automatiquement les bon paramètres Si vous optez de paramétrer un périphérique en manuel rentrer dans le DNS principal et secondaire l'IP de votre instance AdGuard Home. Pour moi : 192.168.1.150 Android Laisser en DHCP et modifier le DNS avec celui paramétrer dans les serveurs DNS upstream de AdGuard Home. Pour moi cela sera : https://family.cloudflare-dns.com/dns-query Apple Je n'ai pas de produit Apple, je vais m'abstenir d'en parler. Merci à tous de m'avoir lu, j'arrive au bout de ce long tuto. Je reste disponible pour vous aider. Sources : [TUTO] Docker : Introduction - Tutoriels - NAS-Forum [TUTO] [Docker - macvlan] Pi-Hole - Tutoriels - NAS-Forum [TUTO] Certificat SSL & reverse proxy via Docker - Tutoriels - NAS-Forum Installation d'AdGuard, c'est fait ! - Installation, Démarrage et Configuration - NAS-Forum [Tuto] Pi-Hole, Livebox et décodeur TV Orange - framboise314.fr

Il n'y a plus de mise à jour automatique des versions mineures de DSM pour les modèles des séries ´16 à ´19 depuis DSM 7.2. Elles ne peuvent donc être faites que manuellement.

Il s'agit ici de présenter un tuto pour monitorer sa Freebox, avec les outils telegraf / influxdb / grafana, en complément du [TUTO] Monitoring NAS et Réseau qui reste la référence. En conséquence, je suppose déjà opérationnelle chez vous une chaine complète telegraf / influxdb / grafana pour la supervision de votre NAS Il faudra bien entendu faire les adaptations spécifiques à votre environnement. Principe : Le docker telegraf va utiliser un script python pour récupérer les infos de la Freebox. Limites : je n'ai pu valider cette méthode que sur ma Freebox, et donc pour les autres modèles et/ou configuration ... ? Freebox Révolution au dernier Firmware (4.0.7) à ce jour. Accès réseau fibre ftth (et donc pas testé les compteurs xDSL) Chaine existante (hypothèse) : je suppose donc que vous avez une chaine telegraf / influxdb / grafana opérationnelle pour votre NAS, en docker mode bridge. Ajout Freebox : On va rajouter un second docker telegraf, qui portera le script Python. Ce docker telegraf dédié Freebox va transmettre ses données vers une seconde database que l'on va créer dans le docker Influx Sur grafana, on créera une nouvelle source de données (la nouvelle database d'influx) qui nous permettra d'afficher les données Freebox. Voir schéma de principe ci-dessous : Configuration des dockers existants : subnet: 172.20.0.0/29 gateway: 172.20.0.1 ip_range: 172.20.0.0/29 Adressage existant grafana d2:ca:ab:cd:00:02 172.20.0.2 influxdb d2:ca:ab:cd:00:03 172.20.0.3 nas_telegraf d2:ca:ab:cd:00:04 172.20.0.4 Création du nouveau docker : fbx_telegraf Adressage sur le réseau bridge : fbx_telegraf d2:ca:ab:cd:00:05 172.20.0.5 Déclaration du service fbx_telegraf dans le docker-compose.yaml (extrait): EDIT du 02/septembre 2020 : la dernière branche de developpement du docker telegraf, 1.15.x, semble poser problème avec Python. Il faut donc se limiter au max à la version 1.14.5. L'image à charger sera donc telegraf:1.14.5 au lieu de telegraf:latest EDIT du 08/septembre 2020 : installation résolue pour python sur la branche telegraf 1.15.x (i.e. tag : latest). Voir détails plus bas. services: fbx_telegraf: image: telegraf:latest container_name: fbx_telegraf hostname: fbx_telegraf mac_address: d2:ca:ab:cd:00:05 networks: monitoring: ipv4_address: 172.20.0.5 environment: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src - TZ=CET mem_limit: 75M volumes: - "/volume1/docker/monitoring/fbx_telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" # pour le fichier de commande python d'acces a la freebox, # pour le fichier de commande python, # pour le fichier get-pip.py (install module pip puis requests) - "/volume1/docker/monitoring/fbx_telegraf/py:/usr/local/py" # pour le fichier log si on le met en place - "/volume1/docker/monitoring/fbx_telegraf/log:/usr/local/log" ports: - 9125:8125/udp - 9092:8092/udp - 9094:8094 restart: unless-stopped On notera la création et le mapping de 2 répertoires pour le docker fbx_telegraf: un répertoire pour le fichier Python et le fichier d'installation de l'utilitaire python "pip" : /usr/local/py un répertoire pour d’éventuels logs : /usr/local/log Création et démarrage du docker fbx_telegraf: docker-compose pull fbx_telegraf docker-compose up -d fbx_telegraf Via un accès ssh sur le NAS : mise à jour du docker fbx_telegraf docker exec -it fbx_telegraf apt update docker exec -it fbx_telegraf apt upgrade docker exec -it fbx_telegraf apt install -y software-properties-common Installation de python3 dans le docker telegraf télécharger get-pip.py (https://bootstrap.pypa.io/get-pip.py) dans le répertoire /usr/local/py installation des modules pip et requests docker exec -it fbx_telegraf wget https://bootstrap.pypa.io/get-pip.py docker exec -it fbx_telegraf python3 get-pip.py --prefix=/usr/local docker exec -it fbx_telegraf python3 -m pip install requests docker exec -it fbx_telegraf pip install unidecode EDIT du 08/septembre 2020 : installation Python sur la branche telegraf:1.5.x (i.e. tag latest) Au lieu des 7 commandes ci-dessus, on procèdera de la sorte : docker exec -it fbx_telegraf apt update docker exec -it fbx_telegraf apt upgrade docker exec -it fbx_telegraf dpkg --configure -a docker exec -it fbx_telegraf apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common docker exec -it fbx_telegraf wget https://bootstrap.pypa.io/get-pip.py docker exec -it fbx_telegraf apt-get install python3-distutils docker exec -it fbx_telegraf python3 get-pip.py --prefix=/usr/local docker exec -it fbx_telegraf python3 -m pip install requests docker exec -it fbx_telegraf pip install unidecode Il se peut que vous ayez une erreur du type : E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem Dans ce cas, .... suivre à la lettre la consigne et lancer donc la commande # dpkg --configure -a . Puis poursuivre normalement Script Python : On place le script Python fbx_telegraf_059.py dans le répertoire /usr/local/py (ce script a été mis à jour pour mes propres besoins. N’hésitez pas à le reprendre, en particulier en fonction de l'API Freebox si il vous manque des éléments) EDIT du 27/04/2021 : mise à jour du fichier python en version ed061. version basée sur l'API V8 de FreeboxOs compatibilité avec Freebox POP je conseille de repartir d'une database InfluxDB vierge cf message en page 9 pour plus de détails c'est par ici : https://github.com/bruno78310/Freebox-Revolution-Monitoring.git Modification du fichier de configuration telegraf : 1) Dans la section "Input Plugin" : ############################################################################### # INPUT PLUGINS # ############################################################################### ############################################################################### # INPUT PLUGINS FREEBOX # ############################################################################### # Read metrics from one or more commands that can output to stdout [[inputs.exec]] ## Commands array # commands = [ "python3 /usr/local/py/freebox_059.py -SPHDIWX" ] ## Timeout for each command to complete. timeout = "5s" ## Data format to consume. ## Each data format has it's own unique set of configuration options, read ## more about them here: ## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md # data_format = "graphite" data_format = "influx" A noter : le script python "freebox_059.py" est lancé avec un certain nombre d'options, chacune correspondant à un groupe de données récupérées. Si on n'a pas besoin de toutes ces données, selon les besoins, il est tout à fait possible de supprimer les options que l'on ne souhaite pas grapher. freebox_059.py -SPHDIWX : S : état du switch 4 ports X : liste les hosts connectés P : état des ports du switch H : system status D : status disque interne I : status des interfaces LAN W : status du Wifi 4 : status aggregation xdsl / 4g 2) modification de la base influxdb cible, section "Output Plugins" : On va envoyer nos données vers une base de données du nom de fbx_database, user fbx_databse, password fbx_database De plus, on va créer nous même cette database => skip_database_creation = true ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] urls = ["http://influxdb:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "fbx_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. database_tag = "" ## If true, the database tag will not be added to the metric. # exclude_database_tag = false ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" ## Write consistency (clusters only), can be: "any", "one", "quorum", "all". ## Only takes effect when using HTTP. write_consistency = "any" ## Timeout for HTTP messages. timeout = "30s" ## HTTP Basic Auth username = "fbx_telegraf" password = "fbx_telegraf" ## HTTP User-Agent # user_agent = "telegraf" On redémarre le docker fbx_telegraf pour prise en compte Création de la database fbx_telegraf sur influxdb Se connecter en console sur le docker influxdb, puis créer la database : root@influxdb:/# influx -username admin -password admin Connected to http://localhost:8086 version 1.7.9 InfluxDB shell version: 1.7.9 > show databases name: databases name ---- _internal nas_telegraf > create database fbx_telegraf > use fbx_telegraf Using database fbx_telegraf > create user fbx_telegraf with password 'fbx_telegraf' > grant all on fbx_telegraf to fbx_telegraf > > show databases name: databases name ---- _internal nas_telegraf fbx_telegraf > show users user admin ---- ----- admin true nas_telegraf false fbx_telegraf false > On redémarre le docker influxdb pour prise en compte. Autorisation de l'application sur le Freebox. il faut autoriser l'application sur la Freebox. Pour cela se placer dans une console fbx_telegraf et aller dans le dossier /usr/local/py root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -h usage: freebox_050.py [-h] [-s] [-r] [-n app_name] [-i app_id] [-d device_name] [-f format] [-e endpoint] [-S] [-P] [-H] [-D] [-L] [-W] [-I] [-X] optional arguments: -h, --help show this help message and exit -s, --register-status Get register status -r, --register Register app with Freebox API -n app_name, --appname app_name Register with app_name -i app_id, --appid app_id Register with app_id -d device_name, --devicename device_name Register with device_name -f format, --format format Specify output format between graphite and influxdb -e endpoint, --endpoint endpoint Specify endpoint name or address -S, --status-switch Get and show switch status -P, --status-ports Get and show switch ports stats -H, --status-sys Get and show system status -D, --internal-disk-usage Get and show internal disk usage -L, --lan-config Get and show LAN config -W, --wifi-usage Get and show wifi usage -I, --lan-interfaces Get and show lan interfaces -X, --interfaces-hosts Get and show interfaces hosts On va demander d'enregistrer notre application sur la Freebox: root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -r => il faut valider sur l'ecran LCD de la Freebox. => le nom de l'application codée dans le fichier fbx_telegraf_059.py est : grafanamonitor. => controler sur la Freebox que l'application a bien été acceptée : Paramètres / Gestion des Accès / Applications on peut aussi vérifier sur la console fbx_telegraf : root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -s Status: auth already done root@fbx_telegraf:/usr/local/py# root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -r Already registered, exiting root@fbx_telegraf:/usr/local/py# Vous trouverez alors un fichiers .credentials dans le répertoire /usr/local/py . A partir de là, fbx_telegraf est en mesure de collecter les données sur la Freebox, et de les envoyer sur la base de données fbx_telegraf du docker influxdb. on peut contrôler à la main que les valeurs sont bien accessibles, par exemple : root@fbx_telegraf:/usr/local/py# python3 freebox_059.py -H | grep System freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL sys_uptime_val=2787529 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL uptime="32 jours 6 heures 18 minutes 49 secondes" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL firmware_version="4.2.5" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL board_name="fbxgw2r" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL disk_status="active" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL user_main_storage="Disque dur" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_ext_telephony=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_speakers_jack=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL wifi_type="2d4_5g" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL pretty_name="Freebox Server (r2)" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL customer_hdd_slots=0 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL name="fbxgw-r2/full" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_speakers=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL internal_hdd_size=250 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_femtocell_exp=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_internal_hdd=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=NULL,tag3=NULL has_dect=True freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Fan,tag3=NULL id="fan0_speed" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Fan,tag3=NULL name="Ventilateur 1" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Fan,tag3=NULL value=2436 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_hdd id="temp_hdd" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_hdd name="Disque dur" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_hdd value=36 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_sw id="temp_sw" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_sw name="Temperature Switch" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_sw value=48 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpum id="temp_cpum" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpum name="Temperature CPU M" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpum value=58 freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpub id="temp_cpub" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpub name="Temperature CPU B" freebox,endpoint=mafreebox.freebox.fr,tag1=System,tag2=Sensor,tag3=temp_cpub value=53 root@fbx_telegraf:/usr/local/py# Dans la console du docker influxdb, on verifie que l'on recoit bien les données de nas_telegraf et fbx_telegraf Grafana : sur grafana, definir une nouvelle source de données : Name : InfluxDB-1 Freebox (example) URL : http://@NAS:8086 (comme pour le nas_telegraf,car c'est le même docker influxdb) Access : serveur Basic auth : yes Basic auth details : user : fbx_telegraf password : fbx_telegraf Database : fbx_telegraf User : fbx_telegraf password : fbx_telegraf http method : GET On valide (SAVE & TEST) et ce doit être OK. Il ne reste plus qu'à créer le ou les Dashboard souhaités ! => Ne pas oublier de préciser l'origine des données : InfluxDB-1 Freebox Pour ma part, j'ai réalisé: un Dashboard général (trafic, CPU, status des ports du switch, températures ....) un Dashboard listant les stations actives (globales et Wifi) Resterait à faire : l'API de la Freebox est accessible ici en http. Je n'ai pas réussi par manque de connaissances à passer en https je n'ai pas regardé du tout le cas d'un accès xDSL .... le script python s'appuie sur l'API V8 de la Freebox, et est donc compatible avec les Freebox Revolution et POP. La description de cet API peut se trouver ici : https://dev.freebox.fr/sdk/os/# Enfin, tous les paramètres disponibles n'ont pas forcement été implémentés dans le script. Mais les principaux sont là. SI il y avait un besoin particulier, faites le moi savoir. Freebox-1585840825569.json Liste stations FreeBox-1585840845020.json freebox_054.py freebox_058.py

Autre solution : en IPv6, chaque NAS a sa propre adresse IP publique, et est donc adressable sans souci, sur tous les ports.

Hello, j'ai aussi fait la migration il y a quelques semaines et ça s'est très bien passé. Je vais essayer de trouver le temps de mettre à jour le tutoriel, je devrais retrouver des disponibilités à partir de fin juin...

cd /volume1/@appdata Un simple cd / est plus efficace.

Il y a aussi Domoticz que j'utilise sur un Rasp PI4. A mon avis, que ce soit home assistant, jeedom ou domoticz ou d'autres, mieux vaut ne pas solliciter le NAS pour ces applications qui sont en général nativement adaptées et parfaitement intégrées sur des plateformes type Rasp.

Par défaut, un paquet WoL n'est diffusé que sur le segment réseau de l'émetteur. Dans le cas présent, le smartphone n'émet ce paquet que sur le réseau 192.168.68.0/24 (broadcast à destination de 192.168.68.255 ou 255.255.255.255). Le paquet ne peut donc pas parvenir au NAS situé sur un autre segment (192.168.1.0/24). Il est très peu probable que le routeur Mesh propose un proxy WoL pour propager la diffusion du paquet sur les autres segments qui y sont connectés. La solution la plus simple est de connecter le NAS derrière le routeur mesh (attention au changement d'adressage IP). La solution la plus propre est de configurer un unique segment réseau en configurant les appareils réseau du réseau mesh en points d'accès Wi-Fi.

Bonjour, Je n'ai pas tout compris...

Re-bonjour, J'ai trouvé ma réponse : mon mot de passe contient des caractères spéciaux dont la saisie est mal interprétée dans drive client ubuntu. En saisissant le mot de passe dans un éditeur quelconque, puis en le copiant dans le mot de passe de la connexion drive client, Ö miracle, ca fonctionne. bien à vous

Attention toutefois, dans le tuto donné par @firlin, la résistance est à 100ohm. Il faut remplacer cette valeur par 300ohm environ pour limiter le courant dans le transistor (voir ce fil de discussion)

@Sun880 Tu es mal placé pour faire le malin... De plus tu as posté dans une autre rubrique la même question à 2 reprises. Je te laisse une semaine de vacances pour t'approprier le fonctionnement du forum