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.

Préambule Le but de ce tutoriel est de vous aider à mettre en place un réseau privé virtuel (VPN) entre vous et votre NAS depuis Internet. nb : il ne s'agit pas ici de "masquer" votre adresse IP pour effectuer des opérations illicites ou de manière anonyme, l'adresse IP qui sera visible depuis Internet sera celle de votre NAS (ou de votre box) Si vous ne savez pas ce qu'est vraiment un VPN, vous devriez vous renseigner avant de lire la suite. Mais comme peu de personnes feront cette démarche, en voici une description très approximative : c'est un ensemble de techniques permettant de relier 2 équipements réseau, par exemple votre PC et votre NAS généralement, il fonctionne au dessus du protocole IP et peut donc passer par Internet le tout saupoudré de diverses techniques de chiffrement (plus ou moins efficace) =>on peut donc voir ça comme un très grand câble réseau avec des barbelés autour À quoi cela peut-il servir ? Quelques exemples : Accéder de manière sécurisée à votre NAS et/ou à d'autres équipements de votre réseau local depuis Internet par exemple aux services d'administration du nas (DSM, ssh, ...) aux caméras IP à l'alarme de la maison connecter 2 nas distants entre eux ... Accéder à Internet en passant par votre connexion Internet lorsque que vous êtes en déplacement pour profiter de l'antipub que vous avez installé à la maison (par exemple avec le proxy du nas) pour surfer de manière plus "privée", ce qui est très utile dans certains pays où la notion de vie privée est pire qu'en France (ça existe, croyez moi) ou en cas d'utilisation d'un réseau "inconnu" (les HotSpot WIFI sont souvent plein d'indiscrets) à passer outre certaines restrictions en entreprise (il ne s'agit pas de faire n'importe quoi non plus, respectez les règlements intérieurs) ... ###################################################################################### À lire avant d'aller plus loin Le fait de passer par un VPN n'est pas un gage de sécurité en soit. L'utilisation d'une connexion VPN en entreprise peut mener lieu à des sanctions disciplinaires L'utilisation d'une connexion VPN peut être passible de prison (voir pire) dans certains pays (Chine, Corée du Nord, Émirats arabes unis, Iran, Russie, Turquie ...) Si la sécurité générale de votre NAS est mauvaise, ne faites pas de VPN, ça ne fera qu'augmenter les risques (vous trouverez un tuto ici) ###################################################################################### Le VPN par Synology Ce guide est valable pour les versions DSM5.0 à DSM 6.1, mais en fonction des mise à jour de Synology, certaines options peuvent évoluer. Synology fourni un paquet qui installe tout le nécessaire pour créer son serveur VPN à la maison : VPN Server Il existe de nombreux types de tunnel, plus ou moins simples à mettre en place et plus ou moins sécurisés. Le paquet VPN Server en propose 3 (en pratique il y en a 4, on le verra plus tard) : PPTP : créé par Microsoft, ce protocole souffre de nombreux problèmes de sécurité et ne devrait plus être utilisé authentification client : login + mot de passe avantages : simple à configurer et disponible sur la plupart des clients mais il tend à disparaitre (il n'est plus disponible sur iOS 10 par exemple) inconvénients : chiffrement très faible et facile à attaquer OpenVPN : c'est un tunnel SSL, libre, très souple et sécurisé authentification client : certificat + login + mot de passe avantages : chiffrement fort et possibilité de choisir le port et le protocole inconvénient : rarement supporté par défaut (mais il existe des clients pour tous les systèmes) L2TP/IPSec : il s'agit de 2 protocoles normalisés, imbriqués l'un dans l'autre, c'est un ancien standard encore très répandu authentification : secret partagé + login + mot de passe avantages : c'est un standard bien sécurisé supporté par tous les clients ou presque inconvénients : plus complexe à comprendre donc souvent mal configuré Il est généralement plus simple de se limiter au L2TP/IPSec car il est en standard sur tous les clients (Android, iOS, Linux, MacOS, Windows, ...) et souvent autorisé dans les pare-feu. nb : les descriptions précédentes correspondent à la manière dont Synology a implémenté les protocoles, pas à ce qu'ils savent faire (on peut allez beaucoup plus loin avec OpenVPN et L2TP/IPSec, comme utiliser des certificats clients, de l'OTP, ...) ###################################################################################### Prérequis La première chose à faire avant de rendre tout ou partie de votre NAS accessible depuis Internet (indépendamment du VPN), c'est la sécurisation de votre NAS. Il existe de nombreux posts sur ce sujet et même un tuto, mais le minimum devrait être : Protection DOS, blocage auto et pare-feu correctement configurés et activés (un exemple est présent plus bas pour le pare-feu) Aucun compte avec un mot de passe faible sur le NAS : minimum 12 caractères avec MAJUSCULES, minuscules, chiffres et si possible des caractères spéciaux "Configuration du routeur" désactivée, il ne faut surtout pas utiliser cette fonctionnalité des Synology, c'est une faille de sécurité Configuration de la box correcte (pas de DMZ ni d'UPnP autorisé) Ensuite vous devez savoir comment transférer des ports de votre routeur vers votre NAS (on dit couramment : forwarder des ports). Enfin, il vous faut quelques notions réseau de base (adresse IP, adresse réseau, port, route, NAT et DNS), elles ne sont pas toutes nécessaires pour configurer le serveur VPN, mais indispensable pour bien comprendre ce qu'on fait et comment ça fonctionne (je suis certain que beaucoup vont sauter ce point, pensant bien connaitre ces notions, la plupart se trompent). ###################################################################################### Installation du paquet VPN Server Dans le Centre des paquets, on cherche le paquet VPN Server et on l'installe. => À la fin de l'installation, vous aurez probablement une "Notification du pare-feu". De manière générale, il vaut mieux ne pas utiliser ce système de notification et créer les règles manuellement, mais si vous préférez utiliser ce système, décochez le port 1723 (PPTP) comme ci-dessous : Que vous utilisiez ou non cet assistant, allez dans la configuration du pare-feu et affinez les règles (pour limiter l'accès à certains pays par exemple). Un point important qui risque d’empêcher le VPN de fonctionner correctement chez certains utilisateurs (@Vinky) : il faut autoriser la connexion VPN et le trafic VPN. Si vous n'autorisez que les ports du VPN mais pas le trafic réseau qui va passer dans le tunnel, ça ne fonctionnera pas. Votre client et le nas diront - "Connecté" - mais vous n'aurez accès à rien. Gardez en tête que se connecter à un VPN c'est comme brancher un câble réseau (le VPN c'est le câble), si vous n'autorisez pas le trafic dans le câble, ça ne sert pas à grand chose. Voici un exemple de configuration du pare-feu Synology, il devrait fonctionner chez presque tout le monde (au moins en France) : tous les réseaux privés (donc qui ne peuvent pas venir d'Internet) sont autorisés : même si vous changez d'opérateur, les règles resteront valables ça permet aussi d'autoriser le trafic du tunnel VPN (par défaut il s'agit de réseaux en 10.x.0.x) les ports des protocoles VPN dont on a besoin sont autorisés : si vous n'utiliser pas OpenVPN, inutile d'ouvrir le port udp 1194 (idem pour L2TP/IPsec) on limite l'accès aux pays dont on a besoin (pas la peine de laisser toute la planète tenter de se connecter à votre nas) Notez bien qu'ici il s'agit des règles de la section "Toutes les interfaces", si vous utilisez des règles par interface il faudra adapter. nb : je vous recommande fortement de créer les 3 premières règles et la dernière à l'identique, ça ne posera aucun problème de sécurité chez 99% d'entre vous (pour le 1% restant on peut en discuter) ###################################################################################### Configuration globale Au lancement de VPN Server, cet écran apparait : Comme pour la plupart des applications Synology, l'écran est divisé en 2 avec la liste des rubriques à gauche. On commence par aller dans "Paramètres généraux" : Interface réseau : si votre NAS a plusieurs connexions réseau, il faut choisir celle qui convient, la plupart des utilisateurs pourront laisser le choix par défaut Type de compte : Utilisateurs locaux - sauf si vous avez intégré votre NAS à un annuaire (AD/LDAP) Accorder le privilège VPN aux utilisateurs locaux nouvellement ajoutés : il ne faut pas cocher cette case Blocage auto : il doit être activé, sinon il faut le faire avant de continuer => Puis dans "Privilèges" vous pouvez choisir les utilisateurs qui pourront utiliser tel ou tel type de tunnel VPN. Par défaut tout est autorisé pour tout le monde, ce qui n'est probablement pas une bonne idée. Dans l'exemple ci-dessous, certains utilisateurs peuvent utiliser plusieurs types de tunnel en fonction des besoins et des contraintes (un pare-feu d'entreprise qui ne laisse pas passer l'un ou l'autre des VPN par exemple). D'autres comptes n'ont tout simplement pas le droit pas se connecter en VPN. Ensuite on peut configurer les différents types de tunnel VPN en fonction des besoins. ###################################################################################### Serveur PPTP Ça va aller vite => il ne faut pas s'en servir Il est encore plus fiable et plus sûr de se connecter directement à son NAS en HTTP (même sans le s). ###################################################################################### Serveur OpenVPN Avant de rentrer dans la configuration, un petit mot sur OpenVPN. Il s'agit d'un projet libre et OpenSource de serveur VPN SSL/TLS, il utilise donc un certificat (et quelques autres mécanismes) pour chiffrer la communication, d'une manière très similaire à ce qui est fait par un site en HTTPS. Ce mode de fonctionnement lui permet une grande souplesse de configuration. À titre d'exemple, on peut le configurer pour écouter sur le le port TCP 443, comme le ferait un serveur HTTPS. Cette possibilité peut être utile si les ports standards sont fermés par un pare-feu. On peut aussi l'utiliser à travers un serveur proxy. Néanmoins, et cela est valable pour tous les protocoles : un bon équipement réseau sera toujours capable de faire la différence entre une connexion normale et une connexion VPN il est nettement plus efficace (en terme de débit et de stabilité) d'utiliser le protocole UDP Commencez par activer le serveur OpenVPN, vous pouvez laisser tous les réglages par défaut sauf éventuellement le cadre rouge : Par défaut le serveur ne vous laisse accéder qu'au NAS. Si vous cochez cette case, vos clients VPN pourront aussi accéder aux autre ressources de votre réseau (une imprimante réseau par exemple, un autre nas, ...) mais leur accès à Internet passera aussi par le nas. C'est à activer en connaissance de cause. Vous pouvez aussi ajuster les options de chiffrement et d'authentification, les options de la capture ci-dessus sont un compromis entre sécurité/performances et compatibilité (testé avec le client officiel sous Windows et Android). Votre NAS sera directement accessible à l'adresse 10.8.0.1. Cliquez sur "Appliquer" pour obtenir une petite notification : Comme indiqué ici, il faudra autoriser et transférer le port UDP 1194 sur votre routeur ou votre MachinBOX. Une fois la configuration terminée et enregistrée, vous devez cliquer sur "Exporter la configuration" pour obtenir les certificats et le fichier de configuration des clients. Sauvegardez le zip et ouvrez le, il contient 4 fichiers : README.txt : ce fichier contient les instructions de configuration pour Windows et MAC openvpn.ovpn : c'est le fichier de configuration qu'il faudra importer dans votre client OpenVPN ca.crt : c'est l'autorité de certification racine utilisée par OpenVPN (c'est la même que pour votre nas) ca_bundle.crt : en général c'est la même chose, mais si vous utilisez une sous autorité, il contient la chaine complète de certification nb : dans les versions récentes du paquet, le certificat est directement inclus dans le fichier .ovpn. Comme indiqué dans le README.txt, il faut éditer le fichier de configuration avant de l'importer, les lignes importantes sont : remote YOUR_SERVER_IP 1194 il faut remplacer YOUR_SERVER_IP par l'adresse IP publique utilisée pour joindre votre nas (c'est probablement votre IP publique) même si c'est déconseillé, vous pouvez spécifier un nom de domaine à la place de l'adresse IP #redirect-gateway def1 selon que vous avez ou non coché la case entourée de rouge (cf plus haut), il faut enlever ou laisser le caractère de commentaire (le #) en début de ligne #dhcp-option DNS DNS_IP_ADDRESS si vous n'avez pas dé-commenté l'option précédente, dans certaines conditions particulière, il faut préciser l'adresse d'un serveur DNS accessible depuis le client (@titis14) Notez la ligne "ca ca_bundle.crt", elle indique où trouver le certificat par rapport au fichier de configuration (par défaut il s'attend à tout avoir au même endroit, laissez comme ça c'est plus simple). nb : dans les versions récentes du paquet, le certificat est directement inclus dans le fichier .ovpn. Enregistrez le fichier et copiez le avec le fichier ca_bundle.crt sur tous vos clients (c'est le même fichier et le même certificat pour tous vos clients). C'est terminé pour la configuration du serveur OpenVPN, normalement les étapes se résument à : activer le serveur OpenVPN exporter un zip modifier la configuration pour ajouter votre adresse IP autoriser le port UDP 1194 sur le NAS ouvrir et transférer le port UDP 1194 sur le routeur ###################################################################################### Serveur L2TP/IPSec En préambule vous avez pu lire que L2TP/IPSec était un standard mais était aussi complexe. Rassurez vous, la configuration est en réalité très simple. Il faut simplement ne pas suivre une des indications de Synology ! Une petite précision avant d'aller plus loin. L2TP/IPSec englobe 2 protocoles de tunnel. On peut le lire autrement, L2TP sur IPSec ou plus clairement L2TP dans IPSec. En pratique, votre client va créer un tunnel sécurisé par IPSec et créer un tunnel L2TP à l'intérieur. IPSec : c'est ce protocole qui assure le chiffrement de votre communication L2TP : il se contente de gérer l'authentification et de transporter les données, mais sans rien chiffrer (c'est important pour la suite) Commencez par activer le serveur L2TP/IPSec, vous pouvez laisser tous réglages par défaut sauf le cadre rouge : Il faut créer et confirmer la clef pré-partagée. Cette clef va servir de mot de passe secret entre votre client et votre serveur pour authentifier les 2 extrémités. Utilisez une clef assez robuste (pas moins de 16 caractères) et ne la perdez pas (KeePass est parfait pour ça et plein d'autres choses). nb : le secret partagé ne doit contenir que des caractères ASCII, mais avec le jeu des langues et des claviers, mieux vaut se limiter aux caractères alpha numériques (a-z A-Z 0-9) nb : par défaut c'est le serveur DNS configuré dans votre NAS qui est utilisé, mais vous pouvez le changer si besoin (attention, certains clients n'en tiennent pas compte) En passant, notez l'adresse IP en haut : 10.2.0.0 Ici ça sera l'adresse du serveur VPN (ils auraient pu faire pareil qu'avec OpenVPN, mais non), votre NAS sera donc directement accessible à cette adresse. Dans le cas présent, votre NAS sera aussi accessible avec son adresse habituelle car, par défaut, tout le trafic de votre client pourra passer dans le tunnel L2TP/IPSec (il n'y a d’ailleurs pas d'option pour ça), ça dépend du client (c'est généralement le cas par défaut sous Android, iOS et Windows mais pas avec MacOS). Cliquez sur Appliquer pour obtenir une petite notification, mais attention, il y a une erreur : Il faut bien ouvrir le port UDP 1701 sur votre NAS s'il est derrière un routeur, mais il ne faut pas l'ouvrir ni le transférer sur votre routeur. Si vous ouvrez ce port sur votre routeur, vous autorisez les connexions L2TP direct. Le soucis est que certains clients testent plusieurs protocoles (iOS et Windows 10 par exemple), selon la priorité de leurs tests, s'ils voient le L2TP d'ouvert, il vont tenter de s'y connecter sans monter le tunnel IPSec. Du point de vue du client ça fonctionne et c'est rapide, mais en pratique, il n'y a aucun chiffrement de la connexion. Si vous êtes connecté en filaire sur un réseau de confiance, ce n'est pas forcement trop grave, mais si vous voulez accéder à votre NAS depuis un HotSpot, sachez que TOUT ce que vous ferez sera en clair et lisible par n'importe qui. Un pirate pourra facilement (vraiment très facilement, environ 10sec de travail) espionner votre trafic (donc vos mots de passe), se connecter à votre PC, à votre nas et à tout ce qu'il y a derrière. Il est donc important de ne pas ouvrir ni transférer le L2TP (UDP 1701) sur votre routeur. Par contre il doit être autorisé sur le NAS. Pour ceux qui n'ont pas suivi : on interdit le port sur le routeur mais on l'autorise sur le nas =>comment le client peut il atteindre le nas par ce port ? Rappelez vous, L2TP est dans le tunnel IPSec, donc votre routeur ne verra pas le L2TP passer, mais votre NAS oui. C'est terminé pour la configuration du serveur L2TP/IPSec, normalement les étapes se résument à : activer le serveur L2TP/IPSec créer un secret pré-partagé autoriser les ports UDP 500, 1701 et 4500 sur le NAS ouvrir et transférer les ports UDP 500 et 4500 sur le routeur ou la MachinBOX nb : en L2TP/IPSec, il n'est pas possible d'avoir plusieurs clients connectés en même temps s'ils sont derrière le même routeur NAT ###################################################################################### Compatibilité des clients OpenVPN : Android : aucun soucis iOS : non testé Linux : aucun soucis MacOS : aucun soucis avec El Capitan (pas testé avec Sierra) Synology : aucun soucis (merci @StéphanH) Windows : aucun soucis L2TP/IPSec : Android : ça peut ne pas fonctionner certaines versions récentes d'Android, mais c'est simple à corriger iOS : iOS 9 et 10 aucun soucis Linux : aucun soucis MacOS : aucun soucis Synology : aucun soucis Windows : ça peut ne pas fonctionner selon le type de réseau (si le NAS n'a pas d'adresse public), mais c'est simple à corriger ###################################################################################### Notes communes sur les clients Si votre client vous demande de renseigner une adresse de serveur, c'est l'adresse Internet de votre box qu'il faut saisir. Dans certains cas on peut utiliser un nom DNS, mais ce n'est pas recommandé. Si vous avez configuré votre client pour ne pas envoyer tout le trafic vers le VPN, votre NAS ne sera pas accessible depuis son adresse habituelle (192.168.x.x en général). Il faudra donc utiliser l'adresse de terminaison (celle en 10.x.x.x). Si vous avez configuré votre client pour envoyer tout le trafic vers le VPN, votre NAS sera accessible depuis son adresse habituelle (192.168.x.x en général) et votre client sera vu avec l'adresse de votre NAS depuis le reste de votre réseau (le NAS fait routeur+NAT). ###################################################################################### Configuration des clients OpenVPN Android : OpenVPN Connect Configuration : après l'import du certificat, vous aurez peut être une notification de sécurité iOS : OpenVPN Connect Configuration : rien de particulier Linux : utilisez apt/dnf/emerge/yum/zipper ou les sources (si vous utilisez network manager, network-manager-openvpn-gnome est sympa) Configuration : rien de particulier MacOS : OpenVPN Connect Configuration : parfois il faut jouer avec les routes pour que ça fonctionne Synology : Configuration : ne cochez pas la 2ème case (Use default gateway on remote network) sauf si vous savez ce que vous faites Windows : OpenVPN Configuration : rien de particulier L2TP/IPSec Android : Configuration : (cliquez pour zoomer) par défaut tout le trafic passera par le VPN mais vous pouvez ajouter des routes pour changer ce comportement dans les options avancées avec certaines versions d'Android, il faut modifier le fichier /var/packages/VPNCenter/etc/l2tp/ipsec.conf sur le NAS et remplacer sha2_truncbug=no par sha2_truncbug=yes, puis on relance le paquet (merci @CoolRaoul) iOS : Configuration : (cliquez pour zoomer) (merci @StéphanH) par défaut tout le trafic passera par le VPN, la case "Tout envoyer" permet de changer ce comportement Linux : il existe plein de clients mais j'ai une préférence pour strongswan Configuration : rien de particulier MacOS : Configuration : Il faut créer un nouvel adaptateur dans Préférences Système -> Réseau : Dans Avancé, la case entourée en rouge permet de choisir ce qu'on envoi dans le VPN (dernière capture) Synology : Configuration : Il faut créer un nouveau profil réseau dans les paramètres : Sur le 3ème écran, ne cochez pas la première case sauf si vous savez ce que vous faites Vos 2 nas pourront alors discuter entre eux directement en utilisant les adresses de terminaison en 10.2.0.x (pour faire une sauvegarde distante par exemple) Windows : Configuration : Commencez par créer la connexion VPN avec le Wizard Sous Windows 10 il ressemble à ça : ou à ça (selon par où vous passez) Que vous soyez sous Windows 7, 8 ou 10, ça va vous créer un nouvel adaptateur réseau sur lequel vous pourrez modifier les paramètres comme suit si besoin : Si votre NAS est derrière un routeur-NAT (une box par exemple), il faut créer la valeur de registre suivante : https://support.microsoft.com/en-us/kb/926179 Clef : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent Valeur DWORD32 : AssumeUDPEncapsulationContextOnSendRule Donnée de la valeur : 2 et on reboot le PC ###################################################################################### Configuration des routeurs La première chose à faire consiste à s'assurer que l'adresse IP de votre NAS ne change pas, vous avez 2 manières de procéder : la bonne : vous configurez votre DHCP (celui de la box par exemple) pour qu'il attribut toujours la même adresse au NAS (association MAC ADDRESS <-> adresse IP) la mauvaise : vous entrez une IP fixe dans la configuration réseau de votre nas Voici à quoi devrait ressembler les redirections de ports dans votre routeur dans le cas d'un VPN L2TP/IPSec, à chaque fois il faut bien renseigner l'adresse IP locale de votre nas : Freebox V5 : accessible depuis l'interface Free (merci @Mic13710) Ma Freebox->Configurer mon routeur Freebox->Redirections Livebox 4 : accessible depuis l'interface de la box (merci @StéphanH) configuration avancée->NAT/PAT EdgeRouter : vous avez plusieurs manières de faire, ici c'est la méthode pour les débutants (non recommandé) : sélectionnez bien votre interface WAN (celle connectée à Internet) : autres modèles : consultez la documentation de votre routeur, ça devrait être similaire aux exemples ci-dessus ###################################################################################### Que faire si ça ne marche pas ? La première chose à faire est de relire attentivement le tutoriel, en entier, tous les problèmes rencontrés jusqu'à présent pas les autres utilisateurs ont été traités à un endroit ou à un autre (j'actualise le post de temps en temps). Les erreurs classiques sont : mauvaises règles de pare-feu erreur de login/password erreur de secret partagé N'hésitez pas à repartir de zéro (supprimez la configuration et recommencez). Vérifiez aussi l'adresse IP public de votre connexion, avec certains FAI elle change régulièrement, même chose si vous avez utilisé un nom DNS, il faut vérifier qu'il est valide. Si vraiment vous êtes certains que tout est bon de votre coté, regardez les journaux sur le Synology, ils sont dans /var/log/auth.log Pour L2TP/IPSec vous pouvez aussi activer le debug dans le fichier /var/packages/VPNCenter/etc/l2tp/ipsec.conf : il faut dé-commenter les instructions : plutodebug=all plutostderrlog=/var/log/pluto.log puis on relance le paquet (synoservice --restart pkgctl-VPNCenter) les détails de la connexion seront visibles dans /var/log/pluto.log pensez à désactiver le debug après avoir trouvé le problème Si la connexion n’aboutit toujours pas, il faut vérifier que le VPN est bien autorisé entre le client et le serveur. Il est possible qu'un pare-feu ou que votre FAI (voir votre box) bloque ce trafic. Le plus simple pour le vérifier est de faire une capture de trames sur le Synology (à faire en root) : tcpdump -n -q "udp dst port 500 or udp dst port 4500 or udp dst port 1194" si vous ne voyez pas de trafic sur les port 500 et 4500 ou 1194 (pour OpenVPN), il y a un filtrage entre le client et votre nas Vous pouvez aussi tester avec un autre client, une autre connexion Internet, un autre nas (demandez à des amis par exemple, ça sera l'occasion de leur montrer comment ça fonctionne). ###################################################################################### Utilisation avancée En plus des paramètres présentés ci-dessus, vous pouvez faire plusieurs ajustements coté client et serveur afin de mieux correspondre à vos besoins. Pour la suite, il faut avoir un minimum de notions en réseau (minimum ne veut pas forcement dire la même chose pour tout le monde, cf Prérequis). Les points présentés ici ne sont pas limités au VPN et peuvent être utilisés dans un cadre plus général. Les tables de routage En réseau, une route c'est simplement l'itinéraire que doivent emprunter les paquets pour aller du point A au point B. Comme une route pour les voitures. Pour voir les différentes routes configurées sur votre système, "la table de routage", une commande à retenir : netstat -nr Vous connaissez tous la "route par défaut/Passerelle par défaut". Elle est matérialisée dans la table de routage de votre équipement par quelque chose ressemblant à ça : Windows : 0.0.0.0 0.0.0.0 <adresse de votre routeur> <adresse de l'interface> <métrique> le reste du monde : 0.0.0.0 <adresse de votre routeur> 0.0.0.0 UG 0 0 0 <nom de l'interface> Les 2 séries de 0.0.0.0 au début servent à définir l'adresse du réseau de destination (respectivement l'adresse de destination et le masque de sous réseau). Ce qui donne donc 0.0.0.0/0.0.0.0 ou encore 0.0.0.0/0. Pour information, l'adresse d'un réseau s'obtient en multipliant (en binaire) une adresse par son masque (ici c'est facile, ça donne 0 partout). Maintenant à quoi ça sert de savoir ça ? On a vu plus haut qu'on avait 2 types de configuration pour le trafic : tout doit passer par le VPN ou seulement le trafic entre le client et le serveur VPN (ici le nas). Si vous souhaitez, par exemple, que tout le trafic à destination d'Internet passe en direct (pas par le VPN) mais que tout le trafic à destination des adresses de votre réseau local passe par le VPN, vous devez le dire à votre client. Donc il faut créer des routes. Pour la suite, on va considérer que votre réseau est configuré comme suit : adresse de votre réseau : 192.168.0.0/24 (/24 ça veut dire 255.255.255.0) adresse de votre NAS : 192.168.0.2/24 adresse de terminaison VPN de votre NAS : 10.2.0.0 (il n'y a pas de masque ici, c'est normal) adresse d'un site Internet accessible uniquement depuis chez vous : 1.1.1.1/32 Si vous souhaitez pouvoir accéder à votre NAS, une imprimante IP, une caméra de surveillance, ... via le VPN, vous avez 2 possibilités : vous définissez la connexion VPN comme itinéraire par défaut : c'est simple mais tout le trafic passera par là, avec une connexion fibre à la maison ce n'est pas trop grave, mais en ADSL c'est lent vous spécifiez que tout le trafic à destination de votre réseau local, mais pas le reste, doit passer par le VPN => il faut ajouter une route dans la configuration de votre client Android : c'est à faire dans la configuration de la connexion VPN (tout en bas dans les paramètres de la connexion) iOS : ce n'est pas possible sauf en jailbreak Linux/MacOS : ip route add 192.168.0.0/24 via 10.2.0.0 Windows : route add 192.168.0.0 mask 255.255.255.0 10.2.0.0 Et pour le fameux site privé sur Internet ? C'est la même chose. Android : c'est à faire dans la configuration de la connexion VPN (tout en bas dans les paramètres de la connexion) iOS : ce n'est pas possible sauf en jailbreak Linux/MacOS : ip route add 1.1.1.1/32 via 10.2.0.0 Windows : route add 1.1.1.1 mask 255.255.255.255 10.2.0.0 Ici on a ajouté des routes en indiquant au système d'envoyer les paquet à 10.2.0.0, à lui de trouver la meilleur interface réseau à utiliser. On peut le faire différemment, au lieu de spécifier une adresse de routeur (10.2.0.0), on peut indiquer au système de passer par une interface bien précise (ici ça serait l'interface de VPN). Petite précision, avec des routes on défini un itinéraire, il est tout à fait possible de définir plusieurs étapes sur cet itinéraire, on peut par exemple indiquer : pour aller sur 192.168.1.0/24 il faut passer par 192.168.0.1 pour aller sur 192.168.0.1/32 il faut passer par 10.2.0.0 =>votre paquet empruntera donc le chemin suivant : [client]-------[10.2.0.0-192.168.0.2]-------[192.168.0.1-XXXXX]---????---[192.168.1.0/24] Ça c'est la théorie, pour la mise en pratique il existe plusieurs manière de gérer tout ça et de l'automatiser. À titre personnel j'utilise des scripts pour me connecter/déconnecter du VPN, j'ai donc ajouté les commandes de gestion des routes dans ces scripts (et plein d'autre choses mais ce n'est pas le sujet). Par exemple : Linux : #!/bin/sh nmcli con up id <id de connexion dans network-manager> #avec OpenVPN c'est : openvpn /fichier/de/conf.ovpn #on ajoute les routes ip route add 192.168.0.0/24 dev <nom de l'interface vpn> exit 0 Windows : rem "il faut remplacer VPN1 par le nom de l'interface VPN" rasdial "VPN1" rem "il faut remplacer XX par le numéro de l'interface VPN" route add 192.168.0.0 mask 255.255.255.0 10.2.0.0 IF XX @PiwiLAbruti a une autre approche (techniquement plus propre que la mienne), vous la trouverez ici : vpn-route.ps1 En version courte, il demande au système (via les taches planifiées) d'exécuter ses commandes de gestion de routes lorsqu'il détecte que l'interface VPN se connecte/déconnecte. Les enregistrements DNS Pour vous connecter à votre nas, la plupart d'entre vous font ceci (pour simplifier on va oublier l'https, le netbios, le changement de ports ... car ça n'a aucune importance pour la suite) : à la maison : http://192.168.0.2:5000 depuis Internet : http://<nom de domaine>:5000 via le VPN : http://10.2.0.0:5000 (ou http://192.168.0.2:5000 en fonction de vos routes) Personnellement je fais ceci : à la maison : http://<nom de domaine>:5000 depuis Internet : http://<nom de domaine>:5000 via le VPN : http://<nom de domaine>:5000 (peu importe mes routes) Je trouve ça légèrement plus simple Vous avez plusieurs méthodes pour arriver à ce résultat mais je ne vais en présenter qu'une, par contre comme c'est très long à expliquer en détails (mais simple à faire), je vais fortement abréger.. Le plus propre et de loin le plus efficace c'est de configurer votre serveur DNS pour gérer les "vues" (view) : vous demandez simplement à BIND de donner la bonne réponse en fonction de l'adresse IP du client : si le client a une IP qui vient d'Internet on renvoi l'adresse de la box si le client a une IP qui vient du LAN on renvoi l'adresse du NAS si le client a une IP qui vient du VPN on renvoi l'adresse de terminaison du NAS Tout ce qu'il reste à faire c'est d'indiquer au client d'utiliser votre serveur DNS : à la maison : via votre DHCP depuis Internet : rien à faire normalement via le vpn : en le configurant comme indiqué plus haut Vous trouverez plus de détails dans le [TUTO] DNS Server. En creusant un peu, vous trouverez d'autres techniques (loopback, cascade DNS, LLA, prerouting iptables, ...), mais aucune n'est aussi efficace du point de vue des performances et de la souplesse. La MTU et le MSS Clamping Si vous ne savez pas de quoi je parle, passez votre chemin, vous allez faire de la casse. D'ailleurs je ne vais pas en parler pour éviter les accidents, c'est juste un mémo pour rappeler aux utilisateurs les plus avancés que ces paramètres peuvent être configurés et ne doivent pas être négligés du point de vue des performances, surtout en IPv6 (même si la théorie voudrait que ça soit mieux géré en IPv6).

J'ai développé ce fichier host qui permettra à Download Station de télécharger sur 1fichier en gratuit et premium Il fonctionne avec les URL sous la forme http(s)://blabla.1fichier.com et http(s)://1fichier.com/?blabla Cliquez sur suivre ce sujet en haut à droite pour recevoir les notifications de mises à jours. Téléchargement module gratuit + premium 2.0.1 https://1fichier.com/?bht462waff 2.2 https://1fichier.com/?o5efxrcn5y 2.2.1 https://1fichier.com/?tao7iz27w3 2.4 https://1fichier.com/?0k8x5swylm 2.5 https://1fichier.com/?9hf3iuix1i 2.6 https://1fichier.com/?4073fzh6u6 2.7 https://1fichier.com/?crn251z11r 2.7.1 https://1fichier.com/?9vuldwduwh 2.7.3 https://1fichier.com/?bvk6o45nx0 2.8 https://1fichier.com/?ll3lw2aur9 2.8.1 https://1fichier.com/?kepc3qxn4p 2.8.2 https://1fichier.com/?64ycvwkjox 2.9 https://1fichier.com/?0egei1mkmd 3.2.5 https://1fichier.com/?07iuyct5dethfvtd32ha (Developpé par @badasss38) Changelogs 2.5 Authentification basique faite en PHP au lieu dêtre faite par le navigateur. Plus fiable. D'autres corrections sont faite dans cette version. 2.6 Fonctionne en gratuit avec les changements de code source sur 1fichier.com 2.7 Corrige une erreur de code pour les comptes premium par rapport à la 2.6 2.7.1 Optimisation du code + conversion en UTF8 (conseillé par synology) 2.7.3 Lorsqu'un compte est bloqué par 1fichier, le NAS télécharge comme ci l'utilisateur n'avait pas de compte. 2.8 Correction d'un bug lorsque l'on utilise un compte gratuit. (Avant cela n'utilisait pas le compte pour lancer le téléchargement). Fonctionne en premium avec le menu de téléchargement. (Je conseille toutefois de le laissé activé) 2.8.1 Prise en charge des comptes payant non premium 2.8.2 Corrige un bug d'attente dans download station 2.9 Fonctionne avec la maj fichier pour les gratuits + mode debug 3.2.5 Fonctionne avec les CDN, premium et gratuit (Developpé par @badasss38) Informations Avec DSM 5.1 le module n'attends pas entre les téléchargements. Vous pouvez activer le mode debug en ajoutant /debug à la fin de l'URL. Le log sera stocké dans /tmp/1fichier.log. Un reboot du nas supprime le log Comptes premium : Le Menu de téléchargement doit être désactivé dans les paramètres du compte sur 1fichier. Comptes gratuit : Si le nas est réglé sur plusieurs téléchargement en même temps et que vous téléchargez plusieurs fichiers à la fois sur 1fichier Mettez 1 lien 1fichier, attendez 10 secondes et mettez tous les autres d'un coup si vous le souhaitez. Le NAS lance tous les fichiers en même temps, cela veux dire que tous les fichiers peuvent etre téléchargé au moment ou le module fait le scan sur 1fichier, mais après le lancement du 1er fichier, les autres ne sont plus et les fichiers suivants peuvent planter. Ne vous trompez pas lors de l'ajout de votre compte / mot de passe sinon 1fichier peut vous bloquer durant 1 heure. Installation Lisez la partie Informations Connectez vous sur votre NAS Synology Ouvrez Download Station Allez dans la partie paramètres Allez dans Hebergement de fichier Cliquez sur Ajouter et selectionnez votre fichier Host Une fois ajouté, cliquez sur modifier et ajouter votre compte si vous en avez un. Problèmes connus Si le module ne fonctionne pas, faites ces tests avant de poster Lisez la partie Informations Faites vos tests avec des liens différents. Supprimez le module, redémarrez votre NAS et remettez le. Vérifiez que vous avez bien la dernière version du module. (Essayez une version antérieure si la dernière version est boggué) Désactivez tous les autres modules, redémarrez votre NAS et réessayez. Faites vos tests sans extensions. Passer directement par Download Station. Si le module verrouille votre compte 1fichier Vous devez désactiver tous les téléchargements 1fichier qui ne sont pas en cours. Attendez que votre compte soit debloqué (1heure en général) et remettez votre compte / mot de passe sur le fichier host dans download station. Si les téléchargements sont trop lents : HTTPS doit être désactivé dans les paramètres du compte sur 1fichier. Par défaut il est activé. Les lenteurs de téléchargements ne viennent pas de ce module. Celui-ci ne fait qu'envoyer une URL à download station.

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

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

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

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

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, Je vois encore trop de personnes cherchant de l'aide sur l'utilisation de leurs adresses IP pour se connecter à leurs serveurs à distance ou pour partager des données. Je vais donc vous expliquer ci-dessous pourquoi je vous recommande vivement de prendre un nom de domaine. D'abord, on va casser le mythe tout de suite, un nom de domaine, c'est pas cher quand on prend en compte qu'on vient de dépenser pas mal d'argent dans un NAS et des disques durs ainsi qu'un onduleur et un moyen de sauvegarde. Le site OVH (français) par exemple, propose sa propre extension (.ovh) pour moins de 4 euros par an. Je paie moins de 10 euros par an pour un .fr chez eux par exemple. Il existe beaucoup de "registrar" mais je recommande toujours OVH parce qu'il est français, fiable et qu'il permet de travailler avec une IP dynamique via un service DDNS. Il propose aussi différentes API qui peuvent plaire à certains. J'utilise par exemple une API OVH pour la validation de mes certificats Wildcard de Let's Encrypt. Pourquoi ne pas utiliser Quickconnect ? Vous pourriez le lire assez souvent sur le forum, nous ne conseillons pas du tout la fonction QuickConnect intégrée au NAS Synology et en voici les raisons principales. Tout le trafic lié à votre NAS passe par des serveurs tiers. La qualité de connexion et de transit des données est lié au bon fonctionnement des serveurs tiers or on constate régulièrement chez les membres qui utilisent QuickConnect que ça ne fonctionne pas si bien que ça. C'est souvent très lent quand ça fonctionne. On ne contrôle absolument pas ce moyen de connexion et de communication. Adresse IP fixe et adresse IP dynamique : Une adresse IP, c'est un peu comme votre numéro de sécurité sociale. Elle est liée à un propriétaire (le client déclaré chez l'opérateur). C'est d'ailleurs comme ça que fonctionne la fameuse HADOPI quand ils attrapent quelqu'un sur la toile. Ils contactent l'opérateur en fournissant l'adresse IP, la date et l'heure et l'opérateur sait tout de suite quel client avait cette adresse IP à ce moment précis. Ils se fichent par contre de savoir QUI exactement utilisait la connexion à ce moment là. Ils partent du principe que le responsable, c'est le client déclaré chez l'opérateur. Aujourd'hui, il existe trois types d'adresses IP qui nous concerne quand on prend un abonnement internet chez un opérateur. IP fixe IP dynamique IP fixe partagée L'IP fixe (aussi appelée IP statique), c'est ce que tout le monde voudrait. Une IP qui ne change jamais est idéale pour héberger des services sur lesquels on voudrait un accès externe. L'IP dynamique, elle change régulièrement et ça sans prévenir. Mais on peut travailler avec un service DDNS qui sera chargé de surveiller ces changements d'IP régulièrement pour mettre à jour le système automatiquement. L'IP fixe partagée, c'est une plaie mais à ma connaissance, seul Free le fait pour certains clients et les clients peuvent facilement demander une IP fixe via le site internet de Free. Elle a pour conséquence de partager la même IP fixe entre plusieurs clients mais en séparant en plusieurs parties la plage de ports. Un premier client aura la chance d'avoir par exemple les ports 22, 80, 443 etc... quand les autres devront faire sans. La plupart des clients ne voient pas le soucis quand ils ne font que de la visite de sites/blogs ou du visionnage youtube mais pour quelqu'un utilisant ces ports pour de l'hébergement, ça devient tout de suite problématique si il a pas la chance de les avoir. D'autres soucis peuvent s'ajouter à ça comme le bannissement sur un jeu ou un site internet de l'IP à cause d'un client et c'est tous les autres clients ayant cette IP partagée qui seraient punis. Voici en gros les principaux opérateurs français et si ils offrent une IP fixe, dynamique ou partagée. Orange : IP fixe (option chère) et IP dynamique d'office (fibre et ADSL) SFR : IP fixe (fibre) et IP dynamique (ADSL) Free : IP fixe (fibre et ADSL) et IP partagée (fibre et ADSL) Bouygues : IP fixe (fibre, ADSL), IP dynamique (câble) Si vous avez une adresse IP partagée, vous pouvez demander une adresse IP fixe fullstack rien que pour vous 🙂 Pour se faire, il vous suffit d'en faire la demande sur votre espace client sur free.fr Voir ce site qu'il l'explique un peu plus en détail : https://www.freenews.fr/freenews-edition-nationale-299/fibre-optique-125/loption-ip-fixe-finalement-disponible-freebox-fibre-zmd Pourquoi prendre un nom de domaine ? Un nom de domaine est plus facile à retenir et donc à partager qu'une adresse IP. D'autant plus si cette dernière n'est pas fixe ! Un nom de domaine ne fait pas peur au grand public contrairement à une adresse du type : 98.172.34.29 On peut utiliser plusieurs domaines différents sur une même IP alors que vous ne pourrez pas utiliser plusieurs IP sur une même IP. (mondomaine1.fr, mondomaine2.com) On peut utiliser d'autres domaines sur son propre domaine (ndd.tld, video.ndd.tld, mail.ndd.tld etc...). Ça fait quand même plus professionnel. Votre adresse IP peut changer même dans le cas d'une IP fixe (changement d'opérateur ou déménagement par exemple) mais pas votre nom de domaine. On peut cacher les ports des différents services (5000, 5001, 8080 etc...) qu'on met en ligne en utilisant les ports connus 80 et 443 via un proxy inversé ou virtual host. On peut obtenir un certificat SSL pour son domaine. Est-ce facile à mettre en place ? Oui, c'est très facile à faire et ça ne prend que quelques minutes maximum. Un peu long à se valider (24h max en général et en 2h chez OVH) parce qu'il faut que votre nouveau domaine créé se propage (se fasse connaître en gros) partout sur la planète à travers une multitude de serveurs DNS. Voici la procédure : Rendons-nous sur la page officielle d'OVH pour choisir notre nouveau nom de domaine : https://www.ovh.com/fr/domaines/ Une fois le domaine libre choisi, on passe commande comme on passerait une commande sur Amazon. Pour les options, à vous de voir ce dont vous avez besoin 😉 Une fois la commande passée et finalisée, on va se rendre sur la page de configuration : https://www.ovh.com/manager/web/index.html#/configuration Le nom de domaine dans ce tuto n'est plus utilisé et sera résilié dans le courant de l'année 2019. Merci donc de ne pas le spammer par respect du potentiel prochain acquéreur. Pour une IP FIXE : Nous allons nous rendre sur notre nom de domaine puis sur notre zone DNS Il suffit d'indiquer son IP fixe dans la cible et valider. On laisse vide le champ "sous-domaine". Pour obtenir votre adresse IP fixe, on peut visiter ce site par exemple : https://mon-ip.io/ Une fois cettre entrée validée, on peut surveiller la propagation DNS afin de s'assurer qu'elle a bien été prise en compte. https://www.whatsmydns.net/ Selon les registrars, la propagation peut durer 24h environ. Chez OVH, je n'ai jamais dépassé les deux heures. Pour une IP DYNAMIQUE : C'est légèrement différent pour une IP dynamique puisqu'il faudra passer par le service DDNS. Premièrement, nous allons supprimer l'entrée A si il en existe une qui aurait été créé par OVH pendant la mise en place du domaine. C'est ici que ça se passe : Ensuite, nous allons créer une règle DynHost. Il suffit d'indiquer un domaine et son IP dynamique dans la cible et valider. Pour obtenir votre adresse IP, on peut visiter ce site par exemple : https://mon-ip.io/ Ensuite il faut créer un identifiant afin qu'il puisse gérer les changements d'IP. On indique les informations en prenant en compte ce qu'on avait déjà rempli précédemment. Maintenant, on va se rendre sur le NAS dans "Panneau de configuration > Accès externe > DDNS" puis on clique sur Ajouter : On a plus qu'à entrer ce qu'on a fait précédemment sur notre compte OVH. On teste la connexion et on devrait obtenir un statut "normal" comme ci-dessous. On clique sur Ok pour valider. Pareil que pour l'IP FIXE, on va pouvoir surveiller la propagation de notre domaine dans le monde avec le lien ci-dessous : https://www.whatsmydns.net/ Voilà, maintenant que l'on a configuré son IP avec son domaine, on peut créer le transfert de port sur notre routeur et l'ouverture sur le pare feu du NAS. Vous avez deux possibilités : Ouvrir chaque port pour chaque service et ainsi vous devrez taper votre domaine suivi du port (ex : ndd.tld:8888). Un peu chiant si on a pas mal de services... Ou alors ouvrir un seul port qui sera le port 443 (et éventuellement le port 80 avec une redirection auto vers le 443) et ça pour que ce soit fonctionnel pour chaque domaine. Pour la première option, je vous laisse vous tourner vers votre moteur de recherche préféré pour savoir comment transférer un port de votre modem/routeur à votre NAS. Pour la partie NAS, le tuto de sécurité de Fenrir parle de l'ouverture de port. Si vous avez choisi comme la plupart des membres d'accéder à tous vos services par l'unique port 443, alors il vous faudra suivre le tuto de @Kawamashi 🙂

J'ai développé ce fichier host qui permettra à Download Station de télécharger sur uptobox avec un compte gratuit et premium Cliquez sur suivre ce sujet en haut à droite pour recevoir les notifications de mises à jours. Telechargement module gratuit + premium 1.0. 0 http://uptobox.com/dj8ax5u03s6y 1.0.1 http://uptobox.com/2fc41tqhfrz9 1.0.2 http://uptobox.com/xrvgfuvdpvjl 1.0.3 http://uptobox.com/s1grchgp1rl4 1.1 http://uptobox.com/9c79m39h9j3w 1.2 http://uptobox.com/3h4354l4wme2 1.3 http://uptobox.com/8lgsvbhx9sm9 1.4 http://uptobox.com/0ephe1kjt4kj 1.5 http://uptobox.com/ie5ohsim8q37 1.5.1 http://uptobox.com/imm8s8h5h2pm 1.5.2 http://uptobox.com/6jvrwscs57vg 1.6 http://uptobox.com/wyvqgnrtx3s7 1.6.1 http://uptobox.com/8wfc8qsghv0d 1.6.2 http://uptobox.com/fwphcvmjfcvr 1.6.3 http://uptobox.com/kn2qhnnnj6jz 1.6.4 http://uptobox.com/pcv0vmy2rtov 2.0 http://uptobox.com/dhafyx2l2jf0 Fonctionne uniquement avec un token. Voir section informations et changelog. Offrez moi un café ou une bière 😉 Faire un don. Lien direct Changelog 1.0.1 Fonctionnel avec les changements fait sur Uptobox 1.0.2 Ne télécharge plus de fichier 404.html s'il le lien entré n'est pas valide / Lit totalement la page en anglais au lieu de mixer français et anglais 1.0.3 Fonctionne avec les petits changements de code source 1.1 Mise à jour pour les comptes gratuits suite à de petits changement sur uptobox.com. Mise à jour de la fonction d'attente car elle devenait obsolète et refaisait un scan toutes les minutes. 1.2 Mise à jour pour fonctionner avec le nouveau mode de telechargement pour les comptes premiums 1.3 Pour les comptes gratuit, le temps d'attente est detecté avec le nouveau message d'attente. Si le module ne detecte pas le temps d'attente, il re-essayera 30 min plus tard 1.4 L'URL d'authentification à changé 1.5 La vraie URL des fichiers (généré aléatoirement par le serveur) a changé. 1.5.1 Quelques ajustements sur la détection du nom pour les compte gratuit. Détection plus fiable du l'URL du lien. 1.5.2 Suppressions de parties de code inutiles. Charge 1 fois la page au lieu de 2 fois à chaque fichier. 1.6 Nouveau code source pour les comptes gratuits. Ajout d'un mode debug. 1.6.1 Corrige un bug qui generait un caractere invisible a la fin 1.6.2 Mise à jour de l'URL de connexion. 1.6.3 Corrige un bug de la 1.6.2 1.6.4 Prend en charge le SSL 2.0 Code entièrement refait pour utiliser les API uptobox. Un compte gratuit ou premium est désormais obligatoire pour fonctionner avec cette version. Informations Pour entrer votre compte sur la version 2.0 dans le module sur le NAS Allez dans la partie Mon compte sur Uptobox et cliquez sur le logo à droite de Token pour le copier. Allez ensuite sur le module dans Download Station, sur le champ Utilisateur écrivez token et dans les 2 champs mots de passe collez le token copié précédemment. Version antérieure à la 2.0 Comptes premium : Allez dans la partie Mon compte sur Uptobox et cochez Téléchargement direct Vous pouvez activer le mode debug en ajoutant /debug à la fin de l'URL. Le log sera stocké dans /tmp/uptobox.log. Un reboot du nas supprime le log Avec DSM 5.1 le module n'attends pas entre les téléchargements. https://github.com/warkx/Synology-DownloadStation-Hosts Si le module ne marche pas : Vérifiez que le token est le bon (le token peut changer si vous changez de mot de passe ou si vous changez un réglage sur uptobox) Téléchargez la dernière version du host Supprimez les téléchargement en attente dans Download Station Supprimez le fichier host du NAS Déconnectez vous du site uptobox sur votre PC et reconnectez vous pour être sur que votre compte n'est pas bloqué Attendez 1 heure Redémarrez le NAS Stoppez et re-lancer downloadstation Ajoutez le fichier host (téléchargé précédemment) et validez votre compte (si vous en avez un) Si ça marche toujours pas, il faudra surement redemarrer une 2e fois puis stopper et re-lancer downloadstation Vous pouvez également développer votre fichier host, ou mettre à jour le mien, voici la documentation fourni par synology.

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😉

Maintenant, la partie MailServer ! Celle que vous attendiez tous avec impatience ! (Ou pas ? ) Lancez le gestionnaire de paquets. Dans la barre de recherche (Chez moi en haut à gauche), tapez "MailServer" : Ne pouvant pas le désinstaller, je vous ai fait une capture d'écran lorsqu'il l'est déjà. Donc cliquez dessus, et installez le. Une fois installé, démarrez-le et ouvrez-le. Vous arriverez ici : Bien sûr, votre graphe sera vide. Allez dans l'onglet SMTP : Vous allez arriver sur la page de configuration. Cochez la case "Activer SMTP", vérifiez que le type de compte soit réglé sur "Utilisateurs Locaux" La case "Le nom de l'expéditeur et le nom de connexion doivent être identiques" doit aussi être cochée. Mettez votre nom de domaine dans la boîte "Nom de domaine" (Logique non ? La vie est bien faite quand même ) et cliquez sur "OK" pour valider : Maintenant rendez-vous dans la section IMAP / POP3. Faites les réglages conformes à la capture d'écran ci-dessous : C'est tout vous pensez ? Quand il y en a plus, y'en a encore ! Et oui, maintenant, il vous faut ouvrir les ports 25, 143, 993 et (Le sera pour le WebMail que nous verrons après) de votre routeur et les rediriger sur le Synology pour que les mails puissent passer. Nous allons maintenant passer à une étape EXTRÊMEMENT importante ! Votre adresse IP, jeune, joviale, et DYNAMIQUE, est pour le moment considérée comme spam sur l'ensemble des infrastructures réseaux dans le monde entier (La pauvre ) C'est pourquoi nous allons la débloquer grâce à SpamHaus. SpamHaus est utilisé dans le monde entier pour répertorier les adresses IP spammeuse. Donc rendez vous sur http://www.spamhaus.org/lookup/ et entrez votre adresse IP dans la boîte au centre. Si elle est bloquée, vous serez prié de suivre conformément les instructions mises à disposition. ATTENTION : SpamHaus va vous demander une adresse mail. Mettez celle que vous avez configurée sur le Synology ! Maintenant vous allez me dire : C'est bien beau... Mais comment je crée des adresses Mail ? C'est tout simple ! Il vous suffit de créer un utilisateur dans les paramètres du Synology et l'adresse sera automatiquement créée avec le même mot de passe ! Maintenant nous allons installer un WebMail (Oui on a presque fini, vous serez bientôt le maître du monde !) Tout d'abord, activez les services Web dans les paramètres du Synology. Ouvrez le panneau de configuration, et sélectionnez "Services Web". Une fois dedans, cochez la case "Activer WebStation" (Je ne vous fais pas de captures d'écran, car étant sous DSM 5.0, le menu a changé) Ensuite, cliquez sur "Hôtes Virtuels" : Vous verrez ensuite une fenêtre. Cliquez sur "Créer" et mettez la même configuration que moi (Vérifiez que vous avez bien ouvert le port dans votre routeur) : Si vous voulez installer un WebMail, il faudra l'installer dans le dossier "webmail" qui se trouvera normalement dans : Un lecteur partagé doit s'être créé lors de l'activation des services Web. Il se situe à la racine du Synology, en tant que dossier partagé. À l'intérieur se trouvera le dossier "webmail". Si il n'y est pas, refaites l'étape de la configuration des Hôtes Virtuel. Maintenant, lancez encore une fois le Centre de Paquets. Tapez "WebStation" dans la barre de recherche. Premier le premier paquet : Une fois installé, vous pourrez vous rendre sur http://votrenomdedomaine/mail. Ou http://IPDUSYNOLOGY/mail Pour vous logger : Utilisateur : utilisateur (sans le @nomdedomaine !) Et votre mot de passe Pour ajouter un sous domaine, il vous faudra ajouter des enregistrements de type "A" partout. C'est-à-dire dans CloudFlare, et dans le DNS Server ! Maintenant, votre serveur est prêt à envoyer et recevoir des mails ! Nous allons maintenant tester. Créez-vous une adresse autre, de type Gmail. Envoyez-vous un mail à vous-même et regarder si ça passe ! Effectuez aussi le test dans l'autre sens. MIRACLE ! Ça marche ! Si c'est le cas, c'est que vous avez bien suivi ce tutoriel ! Vous pouvez être fier de vous et maintenant allez vous la péter devant vos copains pour leur dire "Je sais configurer un serveur Mail Synology !" En tout cas, je vous remercie de m'avoir lu, en espérant que ça vous sera utile pour la suite ! N'oubliez pas qu'un petit "J'aime" fait toujours plaisir Vous avez encore des problèmes ? Postez sur le forum et avertissez-en moi en MP, je vous répondrai le plus tôt possible Cordialement, Zegorax

1. Préambule Pi-Hole est un logiciel libre permettant le blocage de publicités sur les périphériques qui l'utilisent en tant que serveur DNS. Il sert aussi à contrôler les données de télémétrie que vos appareils envoient, parfois (souvent ? ) de manière non-désirée. Vu que le blocage s'effectue au niveau de la résolution DNS, il a l'avantage de pouvoir s'appliquer à tous les types de périphériques, contrairement aux bloqueurs de navigateurs qui se limitent souvent aux ordinateurs. Le tutoriel sera découpé de la sorte : - STANDARD - Utilisation et déploiement de Pi-Hole via Docker - AVANCÉ - Ses différentes utilisations en tant que serveur DNS local La personnalisation du blocage suivant les périphériques Quelques commandes utiles 2. Prérequis Difficulté : facile-moyenne Vous devez disposer d'un NAS compatible Docker, vous pouvez en retrouver la liste mise à jour à cette adresse : https://www.synology.com/fr-fr/dsm/packages/Docker Au niveau des connaissances : Avoir une idée de ce qu'est Docker, voir tutoriel introductif. Savoir se connecter via SSH avec un utilisateur ayant des privilèges d'administrateur ou root directement, voir tutoriel. OPTIONNEL : je conseille d'installer le paquet SynoCLI File Tools de Synocommunity disponible dans le centre de paquets. Pour ajouter le dépôt Synocommunity au centre de paquets, se référer à ce tutoriel : https://sys-advisor.com/2017/11/05/tuto-synology-comment-ajouter-le-depot-synocomunity/. Après cela, la commande nano, certes moins complète que vi, mais beaucoup plus accessible pour les non-initiés, permettra d'éditer facilement les fichiers en console. 3. Méthode d'installation Il existe plusieurs méthodes pour installer Pi-Hole, préférentiellement je conseille : l'utilisation d'un matériel dédié type Raspberry Pi quand on en a un sous la main et sur lequel il est facile de l'installer nativement, la procédure est très simplement décrite ici une machine virtuelle (avec le paquet Virtual Machine Manager, les prérequis de compatibilité étant les mêmes que pour Docker), avec une installation minimale de Debian avec 512Mo de mémoire vive et un cœur est amplement suffisante un conteneur Docker. Il faut savoir que l'utilisation via Docker demande certains ajustements, et ce pour plusieurs raisons : Pi-Hole utilise les ports 80 et 443, qui sont utilisés par DSM pour Webstation et Nginx (notamment le proxy inversé). Si le conteneur est en mode bridge, les requêtes DNS passant alors par l'hôte (le NAS) avant d'arriver au conteneur, vous verrez l'ensemble des requêtes provenant de l'IP passerelle du NAS dans le réseau bridge par défaut, donc 172.17.0.1. Ce qui posera très vite problème si on souhaite différencier le comportement de blocage pour sa tablette, pour sa TV, etc... (voir à la fin du tutoriel) On privilégiera donc l'utilisation d'un réseau macvlan, celui-ci a entre autres l'avantage de pouvoir donner une IP du réseau local à votre conteneur, par exemple 192.168.100.161, il est donc joignable par les périphériques de votre réseau comme n'importe quelle autre machine. Il y a cependant un écueil à l'utilisation d'un réseau macvlan : tous les conteneurs qui en font partie sont incapables de communiquer avec leur hôte par leur IP physique. Concrètement mon NAS sera incapable de joindre Pi-Hole, donc sa résolution DNS sera non fonctionnelle. Pour pallier ce problème, on va créer une interface virtuelle sur le NAS. En gros si la porte est fermée, on passe par la fenêtre. 🙂 C'est une manipulation très simple, qui ne survit toutefois pas à un redémarrage du NAS, on exécutera donc un script au démarrage pour recréer automatiquement cette interface. L'ensemble de cette procédure est décrite dans le tutoriel introductif, et est, par commodité, reprise dans la partie suivante. 4. Hypothèses Pour faciliter la lecture du tutoriel, on définira un certain nombre d'IP et de notations, vous devez évidemment adapter ces valeurs à votre propre installation, notamment les sous-réseaux. Les IP : de l'interface physique du NAS : 192.168.100.100 de l'interface virtuelle du NAS : 192.168.100.200 du conteneur pi-hole : 192.168.100.161 de la passerelle du réseau (votre box ou votre routeur) : 192.168.100.1 de votre serveur DNS local (si vous n'en avez pas mis en place, c'est l'IP de votre passerelle) : 192.168.100.120 Les sous-réseaux : de votre réseau local : 192.168.100.0/24 (correspond à 192.168.100.0/255.255.255.0). du réseau macvlan : 192.168.100.160/28 (correspond à une plage utilisable de 14 IP allant de 192.168.100.161 à 192.168.100.174). Voir ce site qui permet de calculer les masques. Les notations : macvlan-network : c'est le nom du réseau docker macvlan. mac0 : c'est le nom de l'interface virtuelle du NAS. ovs_eth0 : le nom de l'interface qui a pour IP l'IP physique de votre NAS, 192.168.100.100 dans notre exemple. Pour trouver le nom de l'interface en SSH : ifconfig | grep -B 1 192.168.100.100 C'est le nom qui apparaît à gauche de l'écran sur la première ligne : REMARQUE : ovs s'ajoute automatiquement au nom de l'interface lorsqu'on a activé Open vSwitch sur son NAS (automatique lors de l'installation de Virtual Machine Manager) - STANDARD - 5. Création du réseau et de l'interface virtuelle 5-A. Création du réseau macvlan On commence par se connecter via SSH avec un utilisateur admin ou root sur le NAS pour créer notre réseau macvlan. On va se placer dans le dossier partagé docker : cd /volume1/docker/ On y crée un dossier "networks" et y commencer l'édition du script : mkdir networks && cd $_ nano macvlan-network.sh S'ouvre une fenêtre dans laquelle on va pouvoir rédiger notre script, en voici un canevas : docker network create -d macvlan \ --subnet=192.168.100.0/24 \ --ip-range=192.168.100.160/28 \ --gateway=192.168.100.1 \ -o parent=ovs_eth0 \ macvlan-network Notes : subnet : correspond à votre sous-réseau local. ip-range : correspond à la portion de ce sous-réseau qu'on se réserve pour le réseau macvlan, les 14 adresses IP définies dans les hypothèses. Ces 14 IP permettront d'accueillir d'autres conteneurs éventuels. Par conséquent, la plage du serveur DHCP et du réseau macvlan ne doivent absolument pas se chevaucher ! gateway : c'est notre passerelle. parent : l'interface physique à laquelle on rattache notre réseau. _________________________ Pour sauvegarder les modifications effectuées, on fait CTRL+O, on valide en appuyant sur Entrée puis CTRL+X pour sortir de l'éditeur et revenir sur le prompt. On va maintenant régler les permissions : chmod 740 macvlan-network.sh Le script est prêt, on peut l'exécuter : bash macvlan-network.sh Si tout va bien, on obtient une suite de caractères, cela signifie que le réseau est créé. On peut vérifier en tapant : docker network ls 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 5-B. Création de l'interface virtuelle On va créer un second script dans le dossier courant : nano mac0-interface.sh Le contenu du script : ip link add mac0 link ovs_eth0 type macvlan mode bridge ip addr add 192.168.100.200/32 dev mac0 ip link set dev mac0 address 5E:11:4F:AF:D6:D2 ip link set mac0 up ip route add 192.168.100.160/28 dev mac0 Notes : Concernant l'adresse MAC 5E:11:4F:AF:D6:D2 : c'est une adresse que j'ai choisie, sous les conditions suivantes : - 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 ce convertisseur en ligne, ou faire vos divisions euclidiennes 😄). S'il est impair, vous aurez un message : RTNETLINK answers: Cannot assign requested address Merci à @bruno78 pour la précision. _________________________ On valide et on sort du fichier. On accorde les permissions : chmod 740 mac0-interface.sh On exécute le script : bash mac0-interface.sh Sauf erreur, rien n'indiquera que le script a bien fonctionné, on vérifie en tapant : ifconfig | grep -A 9 mac0 Ce qui doit donner un résultat du type : Un autre moyen de vérifier que ça a marché est de lancer Synology Assistant, l'interface virtuelle devrait dorénavant apparaître en plus de l'interface physique du NAS. 5-C. Création de la tâche de rétablissement de l'interface virtuelle au redémarrage Comme dit plus avant, cette 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. 6. Création des volumes On va créer un dossier pour le conteneur et s'y placer, on va également créer deux dossiers pour la persistance des données de configuration de Pi-Hole : mkdir -p /volume1/docker/pi-hole && cd $_ mkdir etc-pihole etc-dnsmasq.d Ainsi, même si le conteneur est supprimé, les données seront conservées. 7. Création d'utilisateurs et groupes dédiés et octroi de propriété Pi-Hole permet depuis quelques versions d'exécuter le conteneur par le biais d'un utilisateur non privilégié. Autrefois, c'était root qui exécutait l'application, et root dans le conteneur correspondait à root sur le NAS, ce qui en cas de faille au niveau de l'image Docker représentait une faille de sécurité potentielle. Nous allons créer deux utilisateurs ainsi que deux groupes, un tandem pour l'exécution de Pi-Hole, l'autre pour les services web qu'utilise Pi-Hole. Dans DSM : Panneau de configuration -> Utilisateur et groupe -> Groupe -> Créer. 1er groupe : Nom : pihole Description : Exécute le conteneur Pi-Hole Autorisations dossiers partagés : Aucun accès pour tous les dossiers sauf docker (Lecture/Ecriture) et homes (on ne coche rien) Autorisation applications : Tout refuser 1er utilisateur : Nom : pihole Appartient au groupe : pihole Tout le reste est issu des permissions liées au groupe 2ème groupe : Nom : pihole-www Même chose que pour pihole 2ème utilisateur : Nom : pihole-www Appartient aux groupes : pihole-www et pihole Tout le reste est issu des permissions liées aux groupes En SSH, on va attribuer la propriété des deux dossiers de configuration créés dans la section précédente à l'utilisateur pihole et au groupe pihole : cd /volume1/docker chown -R pihole:pihole pi-hole/ On vérifie que les permissions sont ok : Avant de clôturer cette partie, nous allons vérifier les uid et gid de nos utilisateurs et groupes nouvellement créés, nous en aurons besoin pour personnaliser notre fichier compose : REMARQUE : les valeurs ci-dessus sont propres à votre installation, ne les recopiez pas bêtement ! 7. Configuration et initialisation 7-A. Création du fichier compose On va utiliser Docker-compose pour créer notre conteneur. Docker-compose est une manière alternative de créer un conteneur qui possède de nombreux avantages par rapport à la ligne de commande et à l'interface proposée par DSM. De plus Docker-compose vient avec le paquet Docker de Synology, donc aucune installation supplémentaire n'est nécessaire. Venons-en à la création de notre fichier compose : nano docker-compose.yml On y colle le contenu suivant, il suffit de copier les données suivantes, revenir dans l'éditeur nano, et faire un clic droit. version: '2.1' services: pi-hole: image: pihole/pihole container_name: pi-hole hostname: pi-hole networks: macvlan-network: ipv4_address: 192.168.100.161 environment: # General - ADMIN_EMAIL=xxx@yyy.zzz - TZ=Europe/Paris - PIHOLE_DNS_=80.67.169.12;9.9.9.9 # IP des serveurs DNS FdN et Quad9 - DNSSEC=false - DNS_BOGUS_PRIV=true - DNS_FQDN_REQUIRED=true - DNSMASQ_LISTENING=local - INTERFACE=ovs_eth0 - FTLCONF_LOCAL_IPV4=192.168.100.161 # IP du conteneur Pi-hole - VIRTUAL_HOST=pi-hole.ndd.tld # Si on souhaite acceder a Pi-hole par un nom de domaine (proxy inverse par exemple) - WEBPASSWORD=xxxxxxxxxxxxxxxxxxxx # Mapping utilisateurs et groupes - PIHOLE_UID=1045 # pihole UID - PIHOLE_GID=65548 # pihole GID - WEB_UID=1044 # pihole-www UID - WEB_GID=65547 # pihole-www GID # Conditional forwarding - REV_SERVER=true # Permet de recuperer les hostnames des peripheriques du reseau - REV_SERVER_TARGET=192.168.100.xxx # Voir paragraphe CONDITIONAL FORWARDING - REV_SERVER_CIDR=192.168.100.0/24 # Votre sous-reseau local - REV_SERVER_DOMAIN=ndd.tld # Domaine local # Personnalisation interface - TEMPERATUREUNIT=C - WEBTHEME=default-darker - WEBUIBOXEDLAYOUT=boxed volumes: - /volume1/docker/pi-hole/etc-pihole:/etc/pihole/ - /volume1/docker/pi-hole/etc-dnsmasq.d:/etc/dnsmasq.d/ dns: - 127.0.0.1 - 80.67.169.12 restart: unless-stopped networks: macvlan-network: external: true REMARQUES : Il est important de respecter l'indentation (l'alignement des paramètres). Si vos serveurs publiques définis dans PIHOLE_DNS_ prennent en charge DNSSEC, vous pouvez passer cette dernière variable à true. On a défini ici 2 serveurs publics différents, pour limiter les risques d'indisponibilité (merci à @Einsteinium pour sa suggestion). Si vous n'utilisez pas de proxy inversé, il n'est pas nécessaire de définir la variable VIRTUAL_HOST. Ce fichier permet de définir dès le lancement avec précision la valeur de la plupart des paramètres, pour la liste exhaustive de toutes les variables d'environnement disponibles, consultez cette page. 7-B. Conditional forwarding Si vous pouvez vous contenter de l'affichage des IP au lieu des noms d'hôte des périphériques, vous pouvez vous abstenir de définir les quatre variables d'environnement REV_SERVER_ dans le fichier compose. Sinon : 7-C. Création du conteneur Il n'y a plus qu'à créer le conteneur, pour cela on a juste à taper : docker-compose pull && docker-compose up -d Docker va télécharger l'image, et créer le conteneur. Attendez une minute ou deux au premier lancement, Pi-hole met un peu de temps pour démarrer. On peut ensuite se rendre sur l'adresse IP du conteneur (ou le nom de domaine défini dans VIRTUAL_HOST si on a défini cette variable), si tout va bien on arrive sur la page d'accueil de Pi-Hole. 8. Résolution locale L'étape ultime, mais la plus importante, est de faire en sorte que votre serveur DHCP envoie à ses clients l'adresse IP de Pi-hole comme serveur DNS primaire. Pour le vérifier, il suffit de taper dans une invite de commande Windows par exemple : nslookup nas-forum.com Si les deux premières lignes du résultat sont équivalentes à : Serveur : pi.hole Address: 192.168.100.161 Félicitations, votre Pi-Hole est fonctionnel ! Pour vérifier que le blocage de publicités est actif, essayez d'aller sur http://doubleclick.net, si le nom de domaine ne peut être résolu, c'est que Pi-Hole a filtré la demande (veillez à désactiver tout bloqueur de pubs intégré au navigateur en amont). Quid du serveur DNS secondaire ? Bien qu'il puisse être rassurant d'envoyer comme serveur DNS secondaire l'IP d'un serveur DNS publique, pour qu'en cas d'indisponibilité de Pi-Hole, la résolution DNS globale soit toujours active sur le votre réseau local, il arrive qu'un périphérique préfère s'adresser au DNS secondaire plutôt que primaire, et dans ce cas-là les requêtes n'étant accessibles que localement échoueront. Pour éviter ces désagréments, on peut mettre en place un deuxième serveur Pi-Hole sur un périphérique simple comme un Raspberry Pi, une machine virtuelle sur un autre serveur ou un autre NAS compatible Docker si on en possède un. La suite s'adresse aux utilisateurs souhaitant pousser plus avant la configuration de Pi-Hole. - AVANCÉ - 9. Modes d'utilisation 9-A. Pi-Hole + serveur DNS local + serveur DHCP Ce point n'est pas abordé dans le tutoriel, je ne trouve pas ça prudent de laisser un conteneur du NAS gérer le serveur DHCP, c'est beaucoup moins stable qu'un périphérique dédié comme un routeur, avec une installation native. Et sans DHCP, vos périphériques ne pourront non seulement pas discuter entre eux, mais pas accéder à Internet non plus. 9-B. Pi-Hole + serveur DNS local Dans le cas où vous avez déjà un serveur DNS local actif sur votre NAS ou tout autre périphérique, vous pouvez placer Pi-Hole en amont du serveur DNS local. Il faudra alors donner comme valeur à la variable d'environnement DNS1 l'IP de l'hôte du serveur DNS. Si vous avez une redondance de serveurs DNS local, pensez à compléter DNS2 de manière analogue. Vos périphériques interrogeront d'abord Pi-hole, qui transmettra ensuite la requête à votre serveur DNS local, lui-même transmettra aux redirecteurs que vous lui avez précisés si la requête n'est pas résoluble localement. Périphérique -> Pi-Hole -> Serveur DNS local -> Serveur publique "upstream" ATTENTION : Si vous utilisez un serveur DNS sur l'hôte même (par exemple DNS Server), il faut utiliser l'IP virtuelle du NAS, pas son IP physique habituelle (merci à @anorec). 9-C. Pi-Hole en tant que serveur DNS local 9-C-1. Ajout des enregistrements Il est possible d'utiliser directement Pi-Hole comme résolveur DNS local. C'est extrêmement pratique si vous n'avez encore mis aucune résolution locale en place (avec DNS Server par exemple). ATTENTION : Pi-Hole n'est pas en mesure d'être source d'autorité pour une zone publique, il faut pour cela passer par exemple par des logiciels comme BIND ou DNS Server de DSM, qui n'en est qu'une surcouche. Pour se faire on se rend sur la page d'accueil de Pi-Hole, on se connecte en cliquant sur Login, on utilise le mot de passe précédemment défini dans le fichier compose. Dans le menu latéral apparaît l'onglet Local DNS, deux sous-menus apparaissent : DNS Records et CNAME Records : Le premier permet de définir les enregistrements A pour le domaine et les périphériques de votre réseau. Le second permet de définir des alias pour les domaines précédemment définis. Une image est plus parlante qu'un long discours : Notes : Depuis mon réseau local, taper domaine1.fr dans mon navigateur m'amènera sur l'IP de ma passerelle. Si ma box ou mon routeur expose son interface sur le port 80, j'arriverai dessus. J'ai volontairement donné à domaine2.fr une IP inexistante sur le réseau, Pi-Hole ne vous indiquera aucune erreur, il se contente de vous indiquer la direction, même s'il y a un fossé trois mètres plus loin. 😉 C'est votre navigateur qui y sera confronté et vous renverra une erreur. nas.domaine1.fr pointe sur mon NAS, sur lequel par exemple je pourrais utiliser un proxy inversé. Et maintenant dans CNAME Records, je vais par exemple définir des alias pour mes périphériques et pour mon proxy inversé : REMARQUE : La seule règle doit être que la cible de l'enregistrement CNAME (le contenu de la colonne Target) doit avoir été préalablement définie dans la partie DNS records. Le rafraichissement de la zone se faisant à chaque nouvel ajout, il faut qu'il soit valide. 9-C-2. Vérification On peut vérifier par acquis de conscience que la résolution est bien effective : docker exec -it pi-hole bash En tapant ceci on se connecte directement dans le conteneur, à la suite de quoi on réalise quelques tests de résolution DNS : nslookup domaine1.fr nslookup domaine2.fr nslookup nas.domaine1.fr nslookup bitwarden.domaine1.fr nslookup nas.fauxdomaine.fr On peut ainsi vérifier qu'un ensemble d'enregistrements existent dans notre zone locale de Pi-Hole, et même d'autres qui n'existent pas pour lesquels Pi-Hole devrait nous renvoyer une valeur NXDOMAIN (Non-existent domain). 10. Blocage différencié Un des gros avantages de Pi-Hole face à la concurrence est la possibilité de créer des groupes de périphériques pour lesquels on peut personnaliser les listes de blocage, ou même désactiver Pi-Hole complètement. Ou a contrario d'être beaucoup plus restrictif. Quelques exemples concrets : Jeux mobiles : certains jeux gratuits nécessitent de visionner des vidéos pour pouvoir continuer de jouer. Il y a des grandes chances que Pi-Hole bloque ces publicités et altère en conséquence votre expérience de jeu. Il n'est pas rare qu'on souhaite contrôler strictement ce que du matériel domotique (caméra, détecteur, etc...) peut envoyer sur la toile. En ajoutant certaines listes de blocage pour cette catégorie d'équipements, on peut avoir la maîtrise des données transférées sans pour autant générer un nombre importants de faux-positifs sur les autres périphériques du réseau. On peut laisser actif Google Shopping pour madame. 🙂 C'est dans l'onglet Group Management que ça se passe, lequel comprend quatre sous-menus : Groups, Clients, Domains et Adlists. On se dirige en premier lieu dans Groups, dans lequel j'ai ajouté un groupe pour mon smartphone : Si je clique sur Enabled, la valeur passera à Disabled et Pi-Hole sera désactivé pour ce groupe, les requêtes seront directement transmises au(x) redirecteur(s). Dans Clients, je peux choisir dans la liste déroulante un des périphériques vus par Pi-Hole par son adresse MAC (ainsi que l'IP et éventuellement le nom d'hôte s'il en a connaissance). Il faut également choisir à quel groupe le périphérique appartient dans la cellule Group Management, et penser à appuyer sur Apply une fois le choix effectué : Dans Domains, je peux ajouter des domaines (liste blanche ou noire) manuellement (avec ou sans wildcard), ici j'utilise une chaîne regex pour autoriser certaines publicités pour un jeu installé sur mon smartphone : Dans le dernier sous-menu Adlists, je n'ai rien touché aux listes, j'ai laissé celles par défaut pour tous mes périphériques : 11. Commandes utiles Pour redémarrer le conteneur : docker restart pi-hole où pi-hole est le nom donné au conteneur. ____________________________ Pour l'arrêter et le supprimer : docker-compose -f /volume1/docker/pi-hole/docker-compose.yml down L'argument -f permettant de spécifier un fichier en dehors du dossier courant. ____________________________ Pour supprimer toutes les données de Pi-Hole (pour refaire une installation propre par exemple), il suffit de supprimer les dossiers dans le dossier du conteneur : cd /volume1/docker/pi-hole docker-compose down rm -ri etc-pihole etc-dnsmasq.d ____________________________ Pour le mettre à jour et le reconstruire : cd /volume1/docker/pi-hole docker-compose pull docker-compose up -d MàJ : 20/01/2023

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

Bonjour, Nous allons voir ensemble comment configurer le paquet "MailPlus Server" sur un nas Synology tournant sur DSM6 afin d'héberger soit même son propre serveur mail. Cette procédure permettra d'envoyer mais aussi de recevoir des mails à n'importe qui avec son propre ndd (Par exemple prenom@ndd.fr). Ce tuto est fait par un débutant pour les débutants Conditions pour ce tutoriel : - Avoir une IP fixe. - Que votre FAI ne bloque pas le port 25 (smtp). Chez Free, il l'est mais on peut décocher l'option dans l'interface web de notre compte. - Avoir un serveur DNS (voir tuto de Fenrir sur le forum) - Un nom de domaine avec zone DNS personnalisable Difficulté du tuto : facile Temps de mise en place : 20-30 minutes max Bien entendu, il vous faut installer MailPlus Server via le centre de paquets sur votre nas Synology avant de suivre ce tuto. ATTENTION : tous les nas Synology ne sont pas compatibles. Veuillez vérifier pour le votre via ce lien ou regarder ci-dessous. Liste des compatibilités mises à jour ce 26.08.2017 Modèles compatibles Série 17: FS3017, FS2017, RS18017xs+, RS4017xs+, RS3617xs+, RS3617xs, RS3617RPxs, DS3617xs, DS1817+, DS1517+ Série 16: RS18016xs+, RS2416+, RS2416RP+, DS916+, DS716+II, DS716+, DS416play, DS216+II, DS216+ Série 15: RS815+, RS815RP+, RC18015xs+, DS3615xs, DS2415+, DS1815+, DS1515+, DS415+ Série 14: RS3614xs+, RS3614xs, RS3614RPxs, RS2414+, RS2414RP+, RS814+, RS814RP+ Série 13: RS10613xs+, RS3413xs+, DS2413+, DS1813+, DS1513+, DS713+ Série 12: RS3412xs, RS3412RPxs, RS2212+, RS2212RP+, RS812+, RS812RP+, DS3612xs, DS1812+, DS1512+, DS412+ Série 11: RS3411xs, RS3411RPxs, RS2211+, RS2211RP+, DS3611xs, DS2411+, DS1511+ **************************************************** - Configuration DNS Server : Nous allons tout de suite ajouter les deux entrées dans DNS Server. 1. Rendez-vous dans votre application "DNS Server" puis double cliquer sur votre zone créée. 2. Créer deux entrées supplémentaires comme ci-dessous. Une en MX et une autre en A. L'entrée A servira pour la redirection de votre ndd vers votre client mail en ligne et l'entrée MX servira à la communication avec votre serveur de mail. mail.ndd.xx. A 3600 iplocaledunas ndd.xx. MX 3600 10 mail.ndd.xx. **************************************************** - Configuration SMTP : Le serveur SMTP est en gros un facteur sur internet qui va permettre la bonne livraison de vos mails aux autres serveurs mail. Si l'adresse du destinataire n'est pas bonne, alors votre facteur serveur SMTP ne pourra pas livrer le courrier mail. Pareil pour l'inverse. Si le serveur SMTP n'est pas bon, alors votre courrier mail ne sera pas non plus livré. 1. Allez dans la colonne de gauche sur "remise de message" puis "général". 2. Cochez "activer l'authentification SMTP". 3. Entrez votre nom de domaine et votre nom d’hôte. Le nom d'hôte sera mail.ndd.xx Le nom d'hôte FQDN sera votre nom de domaine pleinement nommé pour le serveur mail. Exemple : mail.site.fr 4. Allez sur "Distribution". 5. Activez le SMTP et SMTP-TLS. Leurs ports respectifs seront 25 et 587 (TCP). 6. Cochez "Activer IMAP SSL/TLS" ce qui permettra à un client mail de pouvoir communiquer avec le serveur mail en sécurité et ainsi afficher les mails reçus, envoyés etc... Pensez à ouvrir les ports TCP 25, 587 et 993 dans le pare feu du nas et dans votre routeur et sans règle de localisation ! A moins que vous ne vouliez recevoir des mails que depuis les serveurs situés France (exit Gmail, Hotmail, Yahoo, Protonmail etc...) **************************************************** - Configuration de la sécurité sur votre serveur mail : La sécurité sur votre serveur mail est primordial. A la fois pour éviter de recevoir des virus et autres me*des mais aussi pour gérer les SPAMS. Ces bêtises immondes qui vous propose du viagra alors que vous n'avez que 20 ans... 1. Allez sur "Sécurité" puis l'onglet "Spam". 2. Cochez "Activer le moteur anti-spam (recommandé". 3. Faites la mise à jour manuellement. Pour les autres options, je vous laisse juge par rapport à vos choix/besoins. 4. Toujours dans "Sécurité", allez sur l'onglet "Antivirus". 5. Cochez "Activer le moteur antivirus", sélectionnez l'antivirus que vous désirez et faites la mise à jour manuelle. Pour les autres options, je vous laisse juge par rapport à vos choix/besoins. 6. Toujours dans "Sécurité" allez sur l'onglet "Authentification". 7. Cochez : "Activer la vérification SPF" "Activer la vérification DKIM sur les messages entrants" "Activer la vérification DKIM sur les messages sortants" "Activer DMARC" 8. Choisissez un préfixe du sélecteur et générez la clé publique DKIM. 9. Copiez cette clé publique. **************************************************** - Sélection des comptes qui auront droit à une boite mail : Nous allons voir comment sélectionner des comptes utilisateurs qui auront une boite mail. ATTENTION : Synology limite depuis "MailPlus Server" à 5 comptes gratuits. Il vous faudra acheter des licences supplémentaires si vous avez beaucoup d'utilisateurs... Vous pouvez aussi utiliser Mail Server (ancienne version de Synology mais toujours en fonction) qui lui ne limite pas le nombre de compte mais qui est moins complet en possibilités. Pour que chaque utilisateur puisse lire et envoyer des mails, il faut leur donner l'autorisation sur l'application "MailPlus Server". Ne vous inquiétez pas, celle-ci sera limitée pour les comptes n'étant pas administrateur. Il faut aussi donner l'autorisation dans les permissions d'utilisateur en écriture sur le dossier MailPlus pour que ça fonctionne sinon le compte ne pourra pas envoyer et recevoir les mails. Normal puisque le compte n'aura pas les autorisations pour aller écrire les données du dossier MailPlus stocké dans le NAS. Pour ma part et afin de jouer la sécurité, je préfère créer un compte email séparé du compte normal et lui interdire l'accès partout sauf pour MailPlus et MailPlus Server. Comme ça, pas d'accès au bureau ou à FileStation pour voir le contenu du dossier MailPlus qui contient les mails de tout le monde y compris des autres comptes autorisés. Exemple : prénom => compte normal qui a des accès à FileStation mais pas au dossier MailPlus. prénom.nom => compte pour boite mail qui a des accès autorisés uniquement à MailPlus Server et MailPlus en application et MailPlus en dossier. Mais il ne peut pas y accéder puisque pas d'accès autorisé à FileStation. Depuis MailPlus, un compte peut (selon ses autorisations sur les dossiers du NAS) envoyer des pièces jointes. A vous de donner les autorisations nécessaires pour que l'utilisateur ai accès au dossier ou se trouve la pièce jointe qu'il veut envoyer. 1. Rendez-vous dans "Compte" puis l'onglet "Utilisateur". Il vous suffit ensuite de cocher ou non les utilisateurs qui auront accès à une boite mail. Si un compte coché s'appelle "prenom", alors son adresse mail sera "prenom@ndd.xx". Si un compte coché s'appelle "prenom.nom", alors son adresse mail sera "prenom.nom@ndd.xx". Etc... 2. Faites encore une fois attention à la limite imposée par Synology des 5 comptes possibles et gratuits. Sinon, achetez des licences supplémentaires. Je ne crois pas qu'il y ai une limite en nombre d'alias ou identité ! **************************************************** - Configuration de la zone DNS dans le nas : Nous allons ajouter à notre serveur DNS les entrées de la zone DNS. 1. Rendez-vous dans "DNS Server" sur votre nas. 2. Sélectionnez votre zone et ouvrez la. 3. Ajoutez l'entrée MX et l'entrée A (pas de CNAME). **************************************************** - Configuration de la zone DNS chez notre provider : 1. Rendez-vous dans votre zone DNS sur votre provider (OVH pour moi). 2. Créez une entrée DNS avec un type MX avec ceci comme commande : Attention faute de frappe : Il manque le "t" à flouté dans l'image 3. Créez une entrée DNS avec un type A avec ceci comme commande : 4. Créez trois entrées dans la zone DNS avec un type TXT comme ci-dessous : 1ère entrée dans la zone : Inscrivez en valeur : "v=spf1 a mx ip4:votreippublique include:mx.ovh.com ~all" "v=spf1 a mx ip4:votreippublique include:mx.ovh.com ~all" 2ème entrée dans la zone : Inscrivez "selector1._domainkey" dans le sous-domaine. N'oubliez pas de changer le préfixe si vous n'avez pas écrit le même que moi dans votre nas. selector1._domainkey Inscrivez "v=DKIM1; q=*; p=suividevotreclépubliquedkim" dans valeur v=DKIM1; q=*; p=votreclépubliquedkim 3ème entrée dans la zone : Inscrivez "_dmarc" dans le sous-domaine _dmarc et inscrivez dans valeur "v=DMARC1; p=reject; rua=mailto:***@gmail.com; ruf=mailto:***@gmail.com; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject" v=DMARC1; p=reject; rua=mailto:***@gmail.com; ruf=mailto:***@gmail.com; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject Ce qui donnera ceci normalement : Au cas ou il y aurait un soucis de compréhension, l'IP fixe et l'IP publique, c'est pareil. Je me suis juste emmêlé les pinceaux... N'oubliez pas d'ouvrir les ports 25, 993 et 587 sur votre routeur et dans le pare feu du nas !!! Pour voir l'état de votre serveur, vous pouvez aussi aller sur "MailPlus Server" et aller sur "Administration du serveur" puis "Liste des serveurs". Vous devriez y trouver votre serveur en fonctionnement avec tout en vert. C'est terminé. Nous allons donc maintenant voir si tout fonctionne correctement. A savoir qu'il faut laisser un peu de temps quelques instants que tout se mette en place. **************************************************** - Configuration du client mail : 1. Ouvrez votre client mail préféré. Perso, je ferai le tuto sur Thunderbird qui est gratuit, open source et qui a fait ses preuves. 2. Création d'un compte courrier et remplissez les champs. Ensuite, cliquez sur "continuer". 3. Comme vous pouvez le voir, il y a une petite erreur car Thunderbird n'arrive pas à trouver lui même les paramètres du serveur IMAP et du serveur SMTP. C'est pas grave, il suffit de modifier le nom d'hôte comme on l'a configuré précédemment et d'indiquez les bons ports. 4. Ce qui donne ceci. 5. Testez à nouveau et voyez le résultat. 6. Vous n'avez plus qu'à cliquer sur "Terminé" et vous aurez accès à votre boite mail. ---FIN DU TUTORIEL--- Si vous remarquez des erreurs ou vous avez des suggestions, n’hésitez pas à l'écrire dans les commentaires afin que je puisse améliorer/corriger le tuto 😉 Merci à Fenrir qui indirectement aura aidé grandement à la réalisation de ce tuto dans ses explications et son aide à la mise en place de mon serveur. EDIT septembre 2018 : Après mûre réflexion, j'ai décidé de déménager mon serveur mail et de ne plus utiliser MailPlus Server sur mon NAS Synology et ça pour diverses raisons. Je ne suis donc plus à même de pouvoir répondre au sujet de cette application. Je continuerai le maintien du tuto si les membres apportent leurs contributions sur les nouveautés, modifications etc... Merci de votre compréhension !

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

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

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

Bonjour, Objectif de ce tutoriel : S’affranchir des problèmes de gestion de réseaux inhérents à la LiveBox 4 Fibre et du fait que l’on ne peut pas passer celle-ci en mode « bridge », en installant un routeur Synology RT2600ac dans la DMZ (DeMilitarized Zone) de cette LiveBox. Cette installation en DMZ va donc nous permettre de rediriger directement tous les flux de données entrants issus d’Internet vers le routeur qui lui, va assurer tout le travail de sécurisation des accès et de gestion du/des sous-réseaux locaux bien mieux que ne le fait la LiveBox. En effet, cette dernière possède un serveur DHCP très capricieux à l’usage, qui d’une part au-delà d’une quinzaine de périphériques se « mélange les pédales » ce qui rend la LiveBox instable (avec des reboot fréquents nécessaires) et d’autre part qui nécessite aussi le reboot de la Livebox à chaque changement de paramétrage du DHCP pour voir une correcte prise en compte de ces derniers. Tout cela sans parler du fait très important, qu’il est impossible de modifier les serveurs DNS de la LiveBox (Orange a bloqué cette possibilité il y a maintenant quelques années). D’où l’idée de s’affranchir le plus possible de la LiveBox, même si elle reste quasiment incontournable pour la majorité des utilisateurs, en transférant ses activités sur un routeur digne de ce nom et de surcroît paramétrable à souhait. Par ailleurs, avec cette configuration, l’ensemble des périphériques des sous-réseaux seront gérés par le serveur DHCP du routeur, la LiveBox quant à elle, ne servant alors plus que de modem pour à la fois la liaison vers Internet, le téléphone fixe sur IP et le décodeur TV d’Orange (i.e. si on dispose de ces deux derniers). J’attire tout de même votre attention sur le fait que mettre la LiveBox en DMZ, signifie qu’elle sera « transparente » à tous les flux de données avec donc toutes les conséquences inhérentes sur la sécurité que cela recouvre. Mais heureusement, on aura le routeur derrière pour veiller aux grains et nous protéger. Ci-après le schéma de principe de la configuration qui va être décrite dans le présent tutoriel : Une fois cette configuration en place et fonctionnelle, il sera alors temps pour vous de sécuriser le routeur ainsi que le/les NAS du réseau local et ensuite d’ajouter selon vos besoins, par exemple, un serveur DNS avec vos propres DNS, un serveur VPN, un Reverse Proxy, un certificat Let’sEncrypt, etc… Pour réaliser tout cela, sachez qu’il y a sur le présent forum tous les tutoriels nécessaires pour vous aider. A vous de les appliquer ou non. Voilà pour le discours préliminaire, on passe aux choses sérieuses … EDIT du 31/12/2020 : Le présent TUTO est aussi applicable dans le principe à une LiveBox 5, au détail près des écrans de l'interface qui peuvent être légèrement différents de ceux d'une LiveBox 4. A vous d'adapter/transposer en conséquence. Prérequis logiciels : · « Synology Assistant» ou « Advanced IP Scanner » (disponible sur Windows) ou « LanScan » (disponible sur Mac). 1 Préliminaires sur la LIVEBOX 4 Fibre Avant toutes choses, il convient d’initialiser correctement la LiveBox. Pour cela : · Connectez un PC/Mac sur le port LAN2 de la LiveBox. Laissez « libre » pour le moment, le port LAN1 de la LiveBox. Le sous-réseau « 192.168.1.0/24 » étant par défaut le sous-réseau LAN de la LiveBox, sur le PC/Mac, fixez manuellement l’@IP du PC/Mac sur ce sous-réseau (par ex : « 192.168.1.12 ») afin qu’il puisse s’y connecter. Ouvrez un navigateur WEB, connectez-vous en mode administrateur à la LiveBox en saisissant l’URL : « http://192.168.1.1 ». Par sécurité, on commence par effectuer une sauvegarde en local sur le PC/Mac, des paramètres de configuration existants de la LiveBox. Cliquez sur le bouton « Sauvegarder en local ». · Désactivez la sauvegarde automatique sinon la configuration actuelle sera automatiquement rétablie après l’opération suivante de réinitialisation. Cliquez sur le bouton « Sauvegarde automatique » pour le faire basculer sur « OFF ». · Réinitialisez la LiveBox avec les paramètres « usine ». Quand vous êtes prêt, cliquez sur le bouton « Redémarrer ». La réinitialisation s’effectue et la LiveBox redémarre à l’issue. Dès que la LiveBox a redémarré, ouvrez un navigateur WEB et depuis le PC/Mac connectez-vous en mode administrateur à la LiveBox en saisissant l’URL : « http://192.168.1.1 ». Menu « Réseau - DHCP » de la LiveBox : Conservez la plage d’@IP du serveur DHCP affectée par défaut, soit : de « 192.168.1.10 » à « 192.168.1.150 ». Cette plage vous laisse la possibilité future de pouvoir connecter directement à la LiveBox un nouveau périphérique. Laissez le service « DHCP » activé car il est nécessaire pour la connexion du décodeur TV si vous en utilisez un. Dans le cas contraire, vous pouvez alors désactiver le service « DHCP ». Menu « Réseau-NAT/PAT » de la LiveBox : assurez-vous qu’aucun transfert de ports n’est défini. Menu « Réseau – UpnP » de la LiveBox : Laissez le service « UpnP IGD » activé car il est nécessaire pour la connexion du décodeur TV si vous en utilisez un. Dans le cas contraire, vous pouvez alors désactiver le service « UpnP IGD ». Menu « Pare-feu » de la LiveBox : Réglez le niveau de sécurité sur « Faible ». Nota : Le pare-feu de la Livebox ne peut pas être complétement désactivé, tout au mieux on le règle le niveau de sécurité au minimum soit « Faible ». Toutefois, vous pouvez aussi personnaliser son action. Dans le cas présent, veillez à ce qu’il n’y ait aucune « règles de filtrage spécifiques » actives. Éventuellement vous pouvez à ce niveau autoriser le « ping ». Cela peut être utile en cas de problèmes réseaux. Menu « Wi-Fi » de la LiveBox : Désactiver les deux antennes 2,4 GHz et 5 GHz. On utilisera la fonction Wi-Fi du routeur bien plus stable et plus puissante. · Ne pas quitter l’interface d’administration de la LiveBox. 2 Connexion du routeur RT2600ac On procède maintenant à l’installation du routeur : Déballez le routeur. Installez les antennes Wi-Fi sur le routeur. Connectez le port WAN du routeur au port LAN 1 de la LiveBox. Branchez l’alimentation électrique du routeur. ⚠ Assurez-vous au préalable que le bouton On/off du routeur est bien sur « Off ». Démarrez le routeur en plaçant le bouton (On/Off) sur « On ». ⚠ Patientez … plusieurs minutes. Pour être sûr de partir sur une base saine, on va réinitialiser le routeur avec ses paramètres « usine » : pour cela, appuyez sur le bouton « reset » situé à l’arrière du routeur durant 10 sec et relâchez le. Le routeur redémarre. ⚠ Patientez … plusieurs minutes. Nota : A l’usage, il s’avère que le reset « usine » du routeur soit quelque peu capricieux. Il est fréquent d’avoir à le refaire plusieurs fois consécutives pour qu’il soit effectif. Ne soyez donc pas surpris de ce comportement ! Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé à l’@IP « 192.168.1.x ». Notez cette @IP pour mémoire. Vérifiez que l’@MAC du routeur est bien : « 00 :11 :22 :33 :44 :55 » (i.e. la même que celle indiquée sur la boite d’emballage du routeur et qui sera appelée @MAC0 dans la suite). 3 Configuration de la LiveBox 4 Fibre Le routeur étant connecté à la LiveBox, on peut maintenant configurer correctement celle-ci : Menu « Mes équipements connectés » de la LiveBox : vérifiez la présence du routeur. Il est nommé par défaut « SynologyRouter ». Vous pouvez le renommer si nécessaire. Pour cela : Cliquer sur l’icône du routeur dans l’onglet « Carte ». L’onglet « Liste » s’affiche. Renommez le routeur, éventuellement modifiez le type d’équipement en sélectionnant le type voulu dans le popup. Bien évidemment la case « Autoriser en permanence » pour l’accès à Internet est cochée et enfin validez en cliquant sur le bouton « Enregistrer ». Menu « Réseau - DHCP » de la LiveBox : Afin de pouvoir intégrer le routeur à la DMZ de la LiveBox, il est nécessaire de lui attribuer un bail statique sur l’@IP de votre choix, par exemple « 192.168.1.2 ». Sélectionnez dans le popup : « SynologyRouteur ». Saisissez l’@IP du routeur : « 192.168.1.2 ». Saisissez l’@MAC0 du routeur : « 00 :11 :22 :33 :44 :55 ». Validez en cliquant sur « Ajouter ». Redémarrez la LiveBox afin de prendre en compte les modifications apportées au service « DHCP ». Quand le LiveBox est opérationnelle, redémarrez le routeur. ⚠ Patientez … plusieurs minutes. Ce redémarrage permet au routeur de récupérer sa nouvelle @IP. Ouvrez un navigateur WEB et connectez-vous en mode administrateur à la LiveBox en saisissant l’URL : « http://192.168.1.1 ». Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé à l’@IP « 192.168.1.2 » avec l’@MAC0. Menu « Réseau - DMZ » de la LiveBox : intégrez le routeur à la DMZ. Sélectionnez dans le popup le « SynologyRouteur » et cliquez sur le bouton « Enregistrer ». Se déconnecter de l’interface d’administration de la LiveBox. 4 Configuration du Routeur RT2600ac On procède maintenant à la configuration proprement dite du routeur : Déconnectez le câble réseau du PC/Mac du port LAN2 de la LiveBox et connectez-le sur le port LAN1 du routeur. Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé à l’@IP « 192.168.1.1 » avec l’@MAC1 : « 00 :11 :22 :33 :44 :66 » (@MAC1 du port LAN1 du routeur). ⚠ Cette @IP est définie dans les paramètres « usine » du routeur et ne peut être modifiée. Pour mémoire, Il existe une @MAC pour chacun des ports LAN physiques du routeur et une pour chaque réseau Wi-Fi configuré. · Ouvrez un navigateur WEB, connectez-vous au routeur en saisissant une des URL suivantes : « http://192.168.1.1 ». « http://router.synology.com » Une fois connecté, cliquez sur « Démarrer » pour lancer l'assistant de configuration de « Synology Router Manager » (SRM). Renseignez les informations pour configurer le compte administrateur et cliquez sur « Suivant ». o Nom : « votrePseudo ». o Mot de passe : « votre_mot_de_passe_fort ». o Confirmer Mot de passe : « votre_mot_de_passe_fort ». Renseignez les informations pour configurer le réseau WiFi et cliquez sur « Suivant ». o Nom (SSID) : « votre_réseau_WIFI ». o Mot de passe : « votre_mot_de_passe_fort ». o Confirmer Mot de passe : « votre_mot_de_passe_fort ». o Pays : « France ». Sélectionnez le mode de fonctionnement « Routeur sans fil », comme l’indique @unPixel dans son tutoriel sur la sécurisation et le paramétrage du routeur, d’ors et déjà par sécurité désactivez « Accès externe à SRM » et cliquez sur « Suivant ». Sélectionnez le type de connexion Internet « IP Manuelle » et saisir : Adresse IP : « 192.168.1.2 » Masque de sous-réseau : « 255.255.255.0 » Passerelle : « 192.168.1.1 » (@IP de la LiveBox). DNS Server : « 192.168.1.1 » (@IP de la LiveBox). Définir comme valeur par défaut : « Activé » Cliquer sur « Appliquer ». Un message de notification de l’assistant SRM indique alors que les sous-réseaux WAN et LAN spécifiés se recouvrent, ce qui peut bloquer la connexion à Internet. Pour mémoire, cette alerte est normale et logique puisque l’actuelle @IP de connexion pour la configuration du routeur est « 192.168.1.1 » et que l’on est en train de définir l’@IP « 192.168.1.2 » comme @IP de connexion à Internet, ces deux @IP appartenant au même sous-réseau « 192.168.1.0/24 », d’où le recouvrement. L’assistant SRM propose alors de corriger cette anomalie en créant lui-même un autre sous-réseau LAN. Cliquez sur « OUI » pour accepter la correction de configuration. L’assistant poursuit la configuration du routeur. ⚠ Patientez plusieurs minutes … jusqu’à la fin de la configuration. Une fois la configuration terminée, cliquez sur « Lancer le Synology Router ». Le sous-réseau LAN du routeur étant différent du sous-réseau LAN courant du PC/Mac, l’interface SRM ne s’affiche pas. C’est à la fois normal et logique ! SRM a affecté le routeur à un autre sous-réseau LAN. Il faut donc trouver ce nouveau sous-réseau pour s’y connecter et poursuivre la configuration. Dans la suite, adaptez les @IP données ici en exemple en fonction de votre cas particulier. Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé avec l’@IP du sous-réseau LAN que l’assistant SRM lui a donc attribué, par exemple : « 10.0.14.1 » avec l’@MAC1 : « 00 :11 :22 :33 :44 :66 » (@MAC1 du port LAN1 du routeur). Sur le PC/Mac, fixez manuellement l’@IP du PC/Mac (par ex : « 10.0.14.12 ») sur le sous-réseau LAN du routeur (« 10.0.14.0/24 »). Ouvrez un navigateur WEB, connectez-vous au routeur avec le compte administrateur SRM spécifié précédemment, en saisissant l’URL : « http://10.0.14.1:8000 ». Ouvrez « Centre réseau – Statut » et vérifiez que le routeur est bien connecté à Internet. ⚠ L’affichage de l’état de la connexion n’est pas instantané il faut patienter quelques secondes. Ouvrez « Centre réseau – Internet » et vérifiez que le routeur utilise bien l’@IP qui lui a été attribué dans le sous-réseau de la LiveBox : « 192.168.1.2 ». Ouvrez « Centre réseau – Réseau local » et modifiez les paramètres de sous-réseau local du routeur pour lui attribuer l’@IP : « 192.168.2.1 ». Renseignez en corrélation du sous-réseau « 192.168.2.0/24 », les @IP de la plage du « serveur DHCP » (fixées de « 192.168.2.150 » à « 192.168.2.254 ») ainsi que celle de la passerelle (« 192.168.2.1 »). Nota : Dans cette configuration, les @IP inférieures à 150 sont réservées pour les « Réservations DHCP » (@IP fixe de certains périphériques). Indiquer également l’@IP de votre serveur DNS (ici dans l’exemple (« 192.168.2.10 ») mais si vous n’en avez aucun de configuré, saisissez simplement « 192.168.2.1 » (dans ce cas c’est votre routeur est votre serveur DNS par défaut). Modifiez l’@IP du « serveur DHCP invité » pour lui attribuer l’@IP « 192.168.3.1 ». De même, renseignez en corrélation du sous-réseau « 192.168.3.0 », les @IP de la plage du « serveur DHCP invité » (fixées de « 192.168.3.2 » à « 192.168.3.254 ») ainsi que celles de la passerelle (« 192.168.3.1 ») et du serveur DNS principal (« 192.168.3.1 » - votre routeur fait office de serveur DNS pour ce sous-réseau invité). Cliquez sur « Appliquer » pour enregistrer les modifications. Pour le réseau local, vous devriez obtenir un écran similaire à celui-ci, aux @IP près bien entendu : Redémarrez une dernière fois le routeur : Ouvrez un navigateur WEB, connectez-vous au routeur avec le compte administrateur SRM spécifié précédemment, en saisissant une de ces deux URL : « http://192.168.2.1:8000 ». « http://router.synology.com ». Poursuivre le paramétrage et la sécurisation du routeur sur la base du tutoriel de @unPixel « [TUTO] Sécuriser et paramétrer son routeur Synology ». Voilà, c'est un peu long, il faut beaucoup "jongler" avec les sous-réseaux, mais si vous êtes attentif cela ne devrait pas vous poser de problèmes. Sachez que depuis que j’ai mis en place cette configuration (cela fait bientôt 6 mois), je n’ai eu à faire AUCUN reboot de la LiveBox. J’en arrive presque à oublier cette dernière, donc pour moi le but initial est atteint 😊😊😊 Le fichier « .pdf » de ce tutoriel : [TUTO] RT2600AC en DMZ derrière Livebox4_20200604.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😉

Mise à jour du tuto pour DSM 7 faite par Mic13710 le 18/02/2023 Bonjour, Nous allons voir ensemble aujourd'hui comment se connecter en SSH et ROOT avec DSM6 et 7. Ensuite, vous n'aurez plus besoin de login et mot de passe sur PuTTY et WinSCP. Idée du tutoriel : je cherchais moi même à me connecter en SSH et ROOT pour suivre un tuto mais la méthode avait changée à partir de DSM6. En faisant des recherches sur la toile, je suis tombé sur toutes sortes de tutos donc la plupart étaient mal traduit, mal écrit, plus à jour, pas assez précis pour un novice (noob) comme moi etc... Et puis en poussant mes recherches un peu plus loin, je suis tombé sur une réponse de Fenrir à un membre du forum qui répondait en très grande partie à mes questions. J'ai donc décidé de me baser sur son savoir afin de créer ce tutoriel et que ça puisse aider les plus démunis sans passer trois heures sur internet pour trouver la bonne solution. Il est vrai que lorsqu'on ne manipule pas SSH tous les jours (je suis pas admin réseau moi lol), il est compliqué de s'y retrouver et encore plus de connaitre et mémoriser toutes ces informations. Surtout les commandes à taper... Pour suivre ce tutoriel, nous aurons besoin du programme PuTTY (sous Windows) et éventuellement le second programme qu'est WinSCP si vous souhaitez aussi avoir accès à votre NAS via un explorateur de fichier (plus précisément un client SFTP graphique). - Téléchargement de PuTTY : https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html - Téléchargement de WinSCP (facultatif) : https://winscp.net/eng/download.php Pour la création des clés sous MAC et Linux, se reporter directement à la partie du tuto ci-dessous et sauter les étapes concernant PuTTY sous Windows. On va aussi partir du principe que vous avez déjà activé SSH et personnalisé votre port dans DSM. Si ce n'est pas le cas, rendez-vous dans "Panneau de configuration" et "Terminal & SNMP". Facilité du tutoriel : FACILE Durée : 10 minutes maximum. Message de Fenrir : À toutes fins utiles, une clef SSH c'est comme un très gros mot de passe, si elle est compromise, tous les endroits où elle est installées le sont potentiellement, c'est pour ça qu'on recommande : de protéger la clef avec un super mot de passe (pageant permet d'éviter de le retaper 15 fois par jours) de renouveler la clef de temps en temps (1 fois par an c'est largement suffisant) en pensant bien à supprimer la clef publique de l'ancienne et de la conserver à l'abri (la clef publique vous pouvez la coller sur google, mais la clef privée c'est comme votre carte bancaire) *********************************************** - Création de la clé privée et la clé publique : 1. Une fois PuTTY installé, rendez-vous dans "tous les programmes" sous Windows et "PuTTY (64-bit)" puis lancez PuTTYgen qui est un générateur de clé. 2. Une fois lancé, vérifiez bien que le protocole de chiffrage RSA (ou ED25519) en bas à gauche soit coché et indiquez 4096 au lieu de 2048. 3. Cliquez simplement sur le bouton "Generate" pour générer les clés. Une fois cliqué, vous aurez un message vous demandant de balader votre souris sur la fenêtre afin de faciliter le hasard du chiffrage. 4. Une fois les clés générées, vous verrez en clair la clé publique affichée comme ci-dessous (copier la). Cliquez sur "Save private key". Enregistrez ou bon vous semble la clé privée sur votre ordinateur. 5. Vous aurez donc ce fichier sur votre ordinateur à l'endroit que vous aurez choisi : 6. La clé privée servira pour Pageant qui est l'agent d'authentification de PuTTY. A noter que si pour une raison ou pour une autre, vous devez retrouver la clé publique, il vous suffit de réouvrir PuTTYgen et de cliquer sur "Load" puis d'indiquer le chemin de votre clé privée pour la voir de nouveau s'afficher dans la fenêtre. *********************************************** - Création des clés sur un PC Linux ou Mac (de Fenrir) : ssh-keygen -t ed25519 -C commentaire ou ssh-keygen -t rsa -b 4096 -C commentaire Exemple sur un poste Linux : fenrir@machine:~# ssh-keygen -t ed25519 -C "Clef ssh pour le tuto" Generating public/private ed25519 key pair. Enter file in which to save the key (/home/fenrir/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/fenrir/.ssh/id_ed25519. Your public key has been saved in /home/fenrir/.ssh/id_ed25519.pub. The key fingerprint is: db:b5:12:69:c0:39:35:78:02:29:8c:32:3e:f0:6b:24 Clef ssh pour le tuto The key's randomart image is: +--[ED25519 256]--+ | o .o .o | |+ . o ..oo.. | |o+ . =o | |Eoo o . | | o.. S + . | | o + o . | | . . o . | | . | | | +-----------------+ Vous retrouverez donc vos clés dans le dossier .ssh de votre "home" (~/.ssh). L'équivalent de pageant se nomme ssh-agent (il faut le lancer). Pour lui ajouter une clé : ssh-add ~/.ssh/id_ed25519 nb : si la clé privée est accessible par d'autres personnes, ssh refusera normalement de l'utiliser, par défaut les droits sont bons, sinon : chmod 600 ~/.ssh/id_ed25519 *********************************************** - Enregistrement de la clé publique dans le NAS : 1. Ouvrez le logiciel PuTTY (64-bit) sur votre ordinateur puis entrez les informations demandées à savoir l'IP locale du NAS et son port que vous aurez personnalisé puis cliquez sur "Open" : 2. Vous avez une nouvelle fenêtre qui s'est ouverte. A partir de là, les étapes sont simples. Entrez votre login (admin) et appuyez sur "entré". Entrez votre mot de passe et appuyez sur "entré". Copiez et collez la commande "sudo su -" puis appuyez sur "entré". sudo su - ATTENTION : à partir de maintenant, vous êtes connecté en ROOT ; une mauvaise manipulation et ça pourrait être dramatique pour votre nas et entrainer par exemple, une perte des données ou une inaccessibilité totale de votre nas. Copiez et collez la commande "mkdir /root/.ssh" puis validez en appuyant sur "entrée". mkdir /root/.ssh Copiez et collez la commande "vi /root/.ssh/authorized_keys" puis validez en appuyant sur "entrée". vi /root/.ssh/authorized_keys Arrivé ici, appuyez sur la touche i pour entrer en mode édition puis collez ici la clé publique que vous avez obtenue. Une fois la clé collée, appuyez sur "echap" et taper ":wq" puis faite "entré". :wq Tapez exit puis "entrée" deux fois afin de quitter PuTTY. Voilà, vous avez collé votre clé publique dans votre NAS. On peut donc en principe se connecter en tant que ROOT et SSH via PuTTY. Mais avant ça, il faut configurer PuTTY. *********************************************** - Configuration de PuTTY pour obtenir une connexion ROOT et SSH : Ouvrez PuTTY (64-bit) à nouveau puis suivez la procédure en image détaillées : Ça vous demande votre mot de passe pour la clé privée. Entrez le et voyez le résultat 😉 Vous êtes maintenant connecté en ROOT et SSH ! *********************************************** - Connexion rapide à votre NAS avec Pageant : Pageant est un utilitaire fourni avec PuTTY et qui va vous permettre d'accéder rapidement à votre NAS. En double cliquant sur votre clé privée stockée sur votre PC, une icône avec un petit ordinateur va apparaitre dans votre barre des tâches à droite. Si vous double cliquez sur cette icône, ça vous ouvre une fenêtre qui récapitule les clés enregistrées. Si vous faites un clic droit sur l'icône, vous verrez un menu s'afficher. Vous pouvez maintenant cliquer directement sur votre NAS répertorié et y accéder en ROOT et SSH via la fenêtre de PuTTY qui s'ouvre. Astuce : on va faire en sorte que Pageant prenne en compte votre clé privée au démarrage sinon il faudra l'importer manuellement à chaque démarrage de ce dernier. On va faire un clic droit sur Pageant puis "Propriétés" puis on va ajouter dans le raccourci de lancement un espace puis l'adresse exacte ou se trouve la clé privée. Ex : C:\PuTTY\pageant.exe D:\cléprivée.ppk *********************************************** - Autoriser l'accès SSH uniquement avec un clé : Pour renforcer un peu plus la sécurité, nous pouvons désactiver l'authentification par mot de passe comme on s'est connecté au début du tutoriel. Ceci va avoir pour conséquence d'autoriser uniquement les connexions SSH avec une clé et la passphrase associée. On édite le fichier "sshd_config" pour lui indiquer que l'on n'accepte pas l'authentification par mot de passe. vi /etc/ssh/sshd_config On modifie (touche i pour "insert") la ligne "PasswordAuthentification yes" en "PasswordAuthentification no" et pour enregistrer la modification, on appuie sur la touche ECHAP (ESC) et on tape la combinaison ":wq!" (sans les guillemets). On redémarre le service SSH pour que le changement soit prit en charge. DSM6 : synoservicectl --reload sshd DSM7 : systemctl restart sshd A partir de maintenant, il faudra obligatoirement avoir sa clé enregistrée dans le serveur mais aussi sa clé privée et la passphrase pour se connecter en SSH. Si on veut ajouter un utilisateur, il faudra revenir dans ce fichier afin d'autoriser temporairement l'authentification par mot de passe le temps que l'utilisateur créer sa connexion par une clé. *********************************************** - Supprimer vos clés sur votre NAS : Pour supprimer votre clé enregistrée sur votre NAS, tapez cette commande : "rm /root/.ssh/authorized_keys" rm /root/.ssh/authorized_keys ATTENTION : cette commande supprimera toutes vos clés ! *********************************************** - Configuration de WinSCP (client SFTP graphique) pour une connexion en ROOT et SSH : 1. Ouvrez WinSCP et suivez les images ci-dessous. Et voilà, vous pouvez maintenant vous connecter via ROOT et SSH avec WinSCP. Soyez prudent ! Merci à Mic13710 et Fenrir pour leurs contributions. Si vous constatez des erreurs dans ce tutoriel, merci de me le faire savoir pour que je corrige rapidement afin de ne pas induire en erreur les membres du forum n'y connaissant pas grand chose.

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

Pour les intéressés voici un fichier récapitulant les compatibilités RAM / Syno testé par les membres. Connaitre les caractéristiques de la RAM d'un SYNO => https://www.synology.com/fr-fr/products/accessories/ram_railkit * info @maxou56 Commande ssh pour connaitre les info sur la RAM (en root sudo -i ou mettre sudo devant la commande) dmidecode -type memory (pour tout) dmidecode -t 16 (pour la RAM max du modèle) dmidecode -t 17 (pour la RAM installées) Connaitre la capacité mémoire maxi supporté par un processeur -> voir chez le fabricant. Exemple avec un Intel Celeron J4125 Update : 11/01/2023 NAS-Compatibilite_RAM.pdf

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 😉

Bonjour, Un petit tuto pour préparer ces disques durs avec la fonction badblocks, en vue de les monter dans le nas. Pour ma part il existe deux façon de faire : soit en ligne de commande ou au travers une tache. Pré requis : Un nas (minimum 2 baies) avec un DSM installé dessus (sur un seul disque). Et crée un volume avec ce disque. En effet si vous faite Install du nas avec deux disques ou plus, configuration de base ou autre(SHR, raid1 etc.. ) Le DSM s’installe sur tous les disques dans ce cas il n’est pas possible de faire le test sur les disques monté dans le nas. Par contre si vous êtes à l’aise avec les lignes de commandes sous putty, vous pouvez installer le DSM sans vous préoccuper de son installation sur tous les disques. Car il est possible de déclarer le disque on l’on va faire le test comme « Fail » et de le réintégrer à la fin du test. Sujet traité dans la 2eme méthode comme variante. (vue que c’est bien décrit cela doit être à la porter de tous ) Pas la peine de faire le volume dans ce cas Wincp et ou Putty. Télécharger Wincp à l adresse suivante https://winscp.net/eng/download.php Télécharger putty à l adresse suivante http://www.putty.org/ Ps: toto est un nom générique de répertoire Début Monter le disque à tester dans le nas. Activer le service SSH, pour cela aller dans le Panneau de configuration, onglet Terminal & SNMP pour activé le service SHH. Faire Appliquer Désactiver le service SSH une fois le badblocks fini (Si vous souhaitez le laisser ouvert, je vous conseille de lire le tuto Sécuriser les acces à son nas) . 1er méthode par une Taches : En premier lieu il faut Crée un dossier partager dans le quel le fichier log sera crée (il sert a voir l avancement du badblock. Pour cela : Panneau de configuration\ Dossier partagé J’ai mis comme nom toto car c’est à lui que je fais référence plus loin (vous pouvez changer mais faudra penser à le changer partout) Pour cela il faut aller Panneau de configuration\ planificateur de tache (sans date de lancement pour lancer le badblocks, on la lance manuellement) . Cliquer sur Créer pour la créer et sélectionner Script défini par l'utilisateur Dans la 1er fenêtre enlever la sélection sur Activé, ensuite aller sur Paramètre de tache Dans celle-ci à la partie Script défini par l'utilisateur mettre cette ligne de commande : (commande non destructive argument -n). Le tutos est expliqué avec celle-ci Par contre on peut faire un test plus poussé avec une commande dite destructive (écriture sur le disque ) argument –w ; pour cela cas on remplace l’argument –n par –w. Dans ce cas le test met 3 fois plus de temps ce qui peut être problématique dans certains cas (disque de gosse capacité ex >10to, voir cas un grosse quantité de disque à tester). badblocks -nvs -c 98304 /dev/sdX > /volume1/toto/sdX.log 2>&1 & Option –c 98304 sert à définir le nombre de bloc testé par passe, la valeur de 98304 correspond à 1Go de Ram. Sans valeur c’est 64 par défaut (dans tous les cas il faut un multiple de 64). Si vous avez un nas avec peu de RAM le -c 98304 peu être problématique réduisait la valeur. Pour savoir comment calculer la valeur de l'argument -c voir en fin de tutos. On peut rajouter option –f aussi pour les périphérique déjà monter. Dans notre cas un disque initialisé. Cela donne badblocks -nvsf -c 98304 /dev/sdX > /volume1/toto/sdX.log 2>&1 & Idem pour l’option –b qui permet de spécifier la taille des blocs testé par passé, par défaut elle est de 1024 si l’on ne spécifie pas cet argument. En règle générale on met comme valeur 4096, cela donne. badblocks -nvs -c 98304 –b 4096 /dev/sdX > /volume1/toto/sdX.log 2>&1 & Le X correspond à la lettre du disque que l on veut tester. Dans le NAS les disques sont nommé comme suivant sd + une lettre de l’alphabet : Disque 1 : sda Disque 2 : sdb Disque 3 : sdc Disque 4 : sdd Par contre à partir des versions des nas DSx20 et suivant sauf sur les versions J (à confirmé) les disques ne sont plus nommé sdX mais sataY ou la valeur Y est un chiffre de 1 à 9 puis de a à z. Autre point leur nom ne dépend plus de leur emplacement dans le nas. Et pour connaitre le nom d’un disques (sataY) il faudra taper un commande en ligne de commande. fdisk -l | grep '/dev/[sh]d\|sata[[0-9]\|[a-z]]' Si vous êtes dans ce cas il faudra modifier la ligne de commande en conséquence. badblocks -nvs -c 98304 –b 4096 /dev/sataY > /volume1/toto/sataY.log 2>&1 & Ici je fait le test sur le disques N°2 Faire Ok ensuite Puis sélectionner le script et cliquer sur Exécuter. Pour savoir, ou en est le badblock: Il faut lancer wincp et renseigner les cases : Non d'hôte, Nom d'utilisateur et Mot de passe. Puis cliquer sur connexion Si tout ce passe bien on doit avoir cette fenêtre Ensuite double cliquer sur le répertoire Volume1 Idem pour le répertoire toto Faire un double clique sur le fichier sdX.log pour voir l’avancement. Quand c’est fini la dernière ligne doit indiquer 100% et bad blocks found. (0/0/0 errors ) Remarque : Dans certain cas cela ne fonctionne pas, dans ce cas il faut crée le répertoire toto avec wincp et lui conférer les bons droits Pour cela création de répertoire, pensez à être sur le volume1 Puis remplir la boite de dialogue comme suit. 2eme méthode en ligne de commande Se connecter sur le nas avec Putty, définir l’adresse Ip du nas On arrive à une fenêtre de ce type : A login as. Au password Ensuite il faut passer en mode Root pour cela il faut taper dans celle-ci : sudo –i Et mettre la password du compte admin Dans cette nouvelle fenêtre taper la commande suivante pour lancer le badblocks badblocks -nvs -c 98304 /dev/sdX > /volume1/toto/sdX.log 2>&1 & Pour les explications (argument, etc.. ) voir plus haut. Si vous avez le message d'erreur suivent suite à la commande badblock "/dev/sdb is apparently in use by the system; it's not safe to run badblocks!" Essayer cette commande badblocks -nvsf /dev/sdX > /volume1/toto/sdX.log 2>&1 & Voir la progression du test il faut lancer la commande suivante dans le terminal tail -f /volume1/toto/sdX.log Variante pour déclare le disque « fail » Affaire avant de lancer le test pour déclare le disque « Fail » taper cette commande dans la fenêtre de putty : mdadm /dev/md0 --fail /dev/sdX1 Puis mdadm /dev/md0 --remove /dev/sdX1 ensuite mdadm --zero-superblock /dev/sdX1 Le 0 correspondent à la partition sur les disques, pour le X voir plus haut. Faire de même pour la partition 1 et 2 (en effet il existe 3 partition sur un disque monter dans le nas : 0 pour le DSM, la 1 pour le swap et la 2 pour les volumes c’est celle-là qui est monté en raid). Ensuite on peut passer au lancement de la commande badblocks. A la fin du test il faut répare le DSM, pour cela gestionnaire de stockage \volumes \ réparer. Fin de la variante. Badblocks et les disques USB Pour faire simple ce n’est pas plus compliquer que la description ci-dessus Dans un premier temps il faut brancher le boitier du disque USB au nas (en USB3 si possible) Par défaut le disque est déclaré en sdq . Pour ceux qui ne sont pas sûr, vous pouvez vérifier cette info en ligne de commande avec Putty (voir explication plus haut) Ensuite il vous faut taper cette ligne de commande dans la fenêtre : fdisk –l Ensuite a vous de voir si vous voulez lancer le badblock au moyen d’une tache ou en ligne de commande. Dans tous les cas celle-ci sera du type : badblocks -nvs -c 98304 /dev/sdq > /volume1/toto/sdq.log 2>&1 & On peut mettre l’argument f pour forcer le démontage de la/les partitions ce qui donne : badblocks -nvsf -c 98304 /dev/sdq > /volume1/toto/sdq.log 2>&1 & Voir l'argument -b (explication en 1er partie de tutos) Ensuite le badblocks se comporte comme décrit plus haut. Remarque pour les versions Série + et Série XS+/XS Cette remarque n’est valable que pour les personnes qui on des nas avec pas mal de RAM (2Go et plus). Par contre il y a une limitation de la mémoire alloué à l’argument –c, on ne peut pas dépasser la valeur de 491520. Donc si vous avez un nas avec 5Go et plus de ram pas besoin de faire la calcul la valeur de l’argument est la suivant –c 491520 On peut accélère le badblocks en modifiant la mémoire allouer a celui-ci (l’argument –c 98304) Pour cela il faut calculer cette valeur Max elle dépend de la RAM installer sur le nas. (on n’est pas obligé de prendre le max de mémoire au final a vous de voir) Exemple d’un nas avec 4Go : Exemple d’un nas avec 4Go : 4*1024=4096Mo (4096 x 3)/32 =394Mo Il faut encore la convertir en Ko ce qui donne 384 x 1024 = 393216Ko Le 393216Ko c’est la valeur max pour un disque, si on lance le badblock sur 3 disques il faut la diviser par 3. Donc cela donne pour un disque l’argument suivant : -c 393216 => ( badblocks -nvs -c 393216 /dev/sdq > /volume1/toto/sdq.log 2>&1 & ) Pour plus d’explication voir ici https://www.pantz.org/software/badblocks/badblocksusage.html Tous sur la commande Badblocks http://manpages.ubuntu.com/manpages/xenial/fr/man8/badblocks.8.html

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

RAID n'est pas une sauvegarde ! Ça c'est fait Bonjour, Dans ce tuto, nous allons comprendre pourquoi et comment sauvegarder ses données stockées sur un nas. Un NAS (Network Attached Storage) c'est quoi ? Comme son nom l'indique en anglais, c'est un serveur de stockage en réseau. Par exemple, tout ce que vous pouvez visionner, écouter ou lire sur internet est stocké sur des serveurs professionnels ou particuliers et ils vous donnent un accès en lecture voir écriture un peu comme vous le faites avec votre propre serveur. Depuis quelques années maintenant, nous avons de plus en plus de données importantes qui sont numériques comme par exemple, des vidéos, des photos numériques, des documents numérisés, divers fichiers etc... Tous ces fichiers sont stockés sur des supports physiques comme disques dur, clés usb, DVD et/ou CD (pas bien), NAS etc... Même sur des disquettes 3,5". Bon d'accord, on peut même pas y stocker une musique mp3 dessus mais je le cite car j'ai un petit coup de nostalgie quand il n'y avait que ça Bref, vous l'aurez compris, c'est bien d'avoir un serveur maison pour avoir un accès illimité à ses données et pouvoir les partager mais il ne faut pas oublier une chose essentielle : la sauvegarde ! La sauvegarde de ses données est ce qui doit être pensé en premier lorsque l'on utilise un ordinateur, smartphone, serveur etc... à qui on confie des données importantes. Eux ne sont pas là pour garder vos données en toute sécurité mais ils sont là pour vous y donner accès facilement. Passer directement au tuto sur Hyper Backup : Pourquoi faire une sauvegarde ? Voici quelques raisons possibles. Causes humaines : - Parce que vous pouvez être victime d'un vol suite à un cambriolage. - Parce que votre NAS peut très bien planter suite à une mauvaise manipulation. - Parce qu'un méchant hacker a décidé de chiffrer vos données et vous demande maintenant de l'argent pour les retrouver. Causes naturelles : - Parce que vous pouvez avoir dans votre logement une inondation, un incendie, une surtension etc... Causes matérielles : - Parce que votre NAS peut très bien tomber en panne et foirer le volume installé (vécu sur un de mes nas de backup). - Parce qu'une mise à jour de l'OS a planté le système (déjà vu sur Windows par exemple). Les conséquences : Financières : si vous êtes une petite entreprise par exemple, vous pourriez ne pas vous en relever ! Si vous êtes un particulier, préparez le chéquier (ça coute très cher) pour qu'une entreprise spécialisée essaie de récupérer vos données perdues. Sentimentales : si vous avez des photos de votre mariage ou de la naissance de votre enfant, ça peut être très dur émotionnellement de savoir ces photos/vidéos perdues. Temps : si vous n'êtes pas organisé, vous allez perdre énormément de temps à chercher des solutions pour rattraper les pertes occasionnées. Etc... Critères d'une sauvegarde : obligatoire ou recommandé - Elle doit être faite de manière automatique. Au moins, pas d'oubli de votre part. - Elle doit être faite de façon régulière et en fonction des changements ou ajouts effectués sur vos dossiers/fichiers. - Elle doit être à un endroit différent des données que vous voulez sauvegarder. Disque dur externe branché sur le nas, serveur pro, nas du voisin, dans le cloud etc... - Elle doit être vérifiée et testée par vous et non par un ordinateur. Soyez comme Saint Thomas. - Utiliser un système de "versionning", c'est utile si on veut retrouver un fichier d'une ancienne sauvegarde qu'on aurait supprimé et qui ne se trouverait pas sur la dernière sauvegarde. - Utiliser un système de "rotation des sauvegardes", c'est utile pour que le programme de sauvegarde gère le stockage de la cible. - Elle peut être chiffrée, c'est toujours plus prudent surtout si la sauvegarde est envoyée en dehors de chez vous. - Elle peut être faite sur plusieurs supports ou services afin d'avoir une redondance. C'est plus rassurant si un service cloud ferme par exemple ou si le disque dur externe plante. Critères de ce qui n'est pas une sauvegarde : - L'utilisation d'un service comme Dropbox, OneDrive (Microsoft), GDrive (Google), iCloud (Apple) etc... N'EST PAS une sauvegarde ! C'est de la synchronisation de données entre un serveur et un ou plusieurs appareil(s). Si l'un deux perd un fichier alors l'autre aussi. Si l'un des deux a un crypto programme qui se lance, alors tous les fichiers dans les deux sens seront perdus (c'est des services bi-directionnel). Elle peut être une sauvegarde mais sous certaines conditions comme par exemple avoir la possibilité de désactiver le bi-directionnel ou une option qui permet de garder une copie d'un fichier sur le service cloud si il était supprimé localement mais en sus avec une sauvegarde faite ailleurs. - Une sauvegarde non vérifiée et non testée. - Une sauvegarde sur un disque dur externe qui resterait branché en permanence à votre nas. Si vous partez deux semaines en vacances, emmenez votre disque dur avec vous et si possible avec une sauvegarde chiffrée en cas de vol. - La copie d'un dossier de votre nas dans un autre dossier de votre nas. Il vaut mieux le préciser Comment faire une sauvegarde avec les outils Synology : Vous pouvez soit utiliser les outils mis à votre disposition par Synology, soit utiliser vos propres outils. Ici, je vais surtout parler des outils Synology et ensuite, je citerai quelques alternatives. - Hyper Backup vous permet de sauvegarder des dossiers, fichiers et applications de votre nas vers un autre périphérique ou service en ligne. Je vous le recommande car il donne la possibilité de chiffrer, faire du versionning, faire de la rotation de sauvegarde etc... - Cloud Station Backup vous permet de sauvegarder des dossiers et fichiers de votre ordinateur sur votre nas (pas très personnalisable et limité). Je lui préfère et de loin Syncback ! - Glacier backup vous permet de sauvegarder vos données sur un compte Amazon Glacier. Voici en gros les outils mit à votre disposition par Synology. ATTENTION : Cloud Station Server avec Cloud Station et/ou Drive n'est pas une sauvegarde. C'est similaire à Dropbox, GDrive, iCloud etc... Je le cite ici pour être sûr que vous ne confondiez pas les programmes. Cloud Sync non plus n'est pas une sauvegarde ! Autres possibilités en dehors des outils de Synology : - SyncBack (Windows uniquement) : http://www.syncback.fr/ Attention à bien le configurer pour de la sauvegarde et non de la synchronisation. - UrBackup : https://www.urbackup.org/ Avantage, il est multi plateforme. Merci à Winpoks (forum HFR) pour l'info. - Duplicati (payant) : https://www.duplicati.com/ Avantage, il est multi plateforme. Merci à Winpoks (forum HFR) pour l'info. Autre précaution à prendre sur votre nas Synology, la corbeille ! Elle est importante car si quelqu'un supprime un fichier, celui-ci sera récupérable pendant un certain temps. Chaque dossier partagé avec la corbeille activée contiendra un dossier nommé "#Recycle" avec une icône de poubelle. Un fichier supprimé dans le dossier X sera dans la corbeille du dossier X etc... Personnellement, mes utilisateurs sont prévenus de l’existence de cette corbeille mais n'y ont pas accès. J'ai préféré donner les droits uniquement à l'administrateur qui pourra récupérer le fichier supprimé qu'un utilisateur voudrait récupérer. Ma stratégie de sauvegarde si ça peut vous donner des idées : Sauvegarde incrémentale chiffrée toutes les trois heures sur un compte GSuite (environ 30 To). Sauvegarde incrémentale chiffrée toutes les six heures sur une baie USB3 de 2x2 To. Sauvegarde de mes données les plus importantes via Rsync sur un vieux DS107+ (1 To). Comme on peut le voir ci-dessus, je fais donc trois sauvegardes locales et une sauvegarde dans le cloud. Et si vous vous posez la question, oui, je prends le temps de temps en temps de tester mes sauvegardes en faisant des tests de restauration 🙂 Fin du tutoriel, si vous constatez des erreurs ou que vous voudriez apporter vos connaissances, alors n'hésitez pas et j'éditerai le tuto.

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

Un petit tuto rapide pour vous indiquer les étapes à effectuer lors du remplacement d'un disque dur sur un NAS avec 2 disques en SHR, la procédure est la même pour le raid1, le raid5, le raid6 et le SHR2. ######################## Mon DS712+ était monté en SHR avec un disque de 3To et un disque de 4To => 3To de disponibles. Comme il commençait à être très rempli (moins de 1% d'espace disponible) et que j'avais un disque de 4To en spare, j'ai décidé de lui donner un peu d'air. C'était l'occasion de vous faire les captures d'écran des différentes étapes à réaliser. nb : vous l'aurez compris, ici je n'ai pas eu de panne disque, je souhaitais juste augmenter l'espace disponible, mais les premières étapes sont les mêmes. ######################## Tester le disque en spare Il est recommandé de tester les disques avant de les utiliser, il existe plusieurs manières de faire. Certains recommandent d'utiliser les outils du constructeurs, d'autre de faire un formatage de bas niveau et les derniers d'utiliser le programme badblock présent sur les Synology. Je n'ai pas de méthode préférée, chacun fait comme il veut, l'important est de s'assurer de ne pas installer un disque défaillant. ######################## Identifier le disque à remplacer Afin d'être certain de retirer le bon disque (enfin celui qui est mauvais ), surtout si les disques sont du même modèle, le plus fiable est de relever le numéro de série dans le Gestionnaire de stockage : Ici les 2 disques sont sains, pour la suite on va dire que le disque 2 était en panne, donc je relève son numéro de série. On peut aussi se fier à la numérotation des disques (vous trouverez des exemples dans les commentaires), mais l'utilisation du numéro de série ne devrait pas laisser de place au doute. ######################## Vérifier que les sauvegardes sont à jour Comme toujours, il faut s'assurer d'avoir des sauvegardes des données du NAS, on n'est jamais à l'abri d'un problème, surtout en cas de reconstruction d'un raid comme ici. La réparation d'un volume est une opération assez intense pour les disques. ######################## Couper proprement le NAS Certains NAS permettent le remplacement d'un disque à chaud (c'est le cas des miens), mais si c'est possible, il vaut mieux éteindre proprement le NAS et débrancher son cordon secteur pour faire la manipulation. ######################## Remplacer le disque à changer On retire le disque à changer et on contrôle que c'est bien lui grâce au numéro de série. Il serait dommage de retirer le disque qui fonctionne. C'est un des avantages de faire la manipulation NAS coupé : si on retire le mauvais disque (enfin celui qui va bien ), il suffit de le remettre à sa place. On insère le nouveau disque dans son emplacement et on rallume le NAS. nb : si votre disque était stocké dans un endroit froid (en hiver dans le garage par exemple), attendez qu'il soit revenu à température ambiante avant d'allumer le NAS, dans le cas contraire, la dilatation des composants (plateaux et têtes de lecture) risque de l'endommager définitivement. ######################## Volume dégradé Au démarrage (qui sera peut être un peu plus long que la normal), votre NAS va se mettre à biper. En vous connectant à l'interface, le Gestionnaire de stockage et le Panneau de configuration vont s'ouvrir. Le panneau de configuration vous servira juste à couper le bip s'il est gênant. Dans le gestionnaire de stockage vous aurez quelque chose comme ceci : Comme indiqué dans le message, le nouveau disque doit avoir une taille minimale (ici il doit faire au moins 2794 Go). Notez en passant le taux de remplissage. Ne laissez pas votre NAS se remplir autant, c'est mal, ça ralenti tout le système et ça peut même créer des pannes (ça faisait très longtemps que je devais m'occuper de ça, j'ai trop trainé). Ici vous devez cliquer sur le bouton Gérer (suivez la flèche). ######################## Réparation du volume Un nouvel écran apparait, il vous propose de Réparer le volume : Lisez le message (contrairement à ce que j'avais fait, je viens de m'en rendre compte en me relisant), validez le choix et faites Suivant. Le NAS vous indique le disque qu'il va utiliser pour faire cette réparation (c'est le nouveau disque). Choisissez le disque à utiliser (ici je n'ai pas le choix) puis faites Suivant. Le NAS vous rappel une dernière fois que le disque sélectionné sera effacé : Si vous êtes certain d'avoir choisi le bon disque, validez avec OK Vérifiez que tout est conforme puis appliquez la configuration avec le bouton Appliquer. ######################## Contrôle de l'avancement Dans le gestionnaire de volume, vous pourrez contrôler l'avancement de la réparation : Si vous avez configuré les notifications, vous recevrez ceci : Puis ceci : À partir de ce moment, même si ce n'est pas recommandé, vous pourrez utiliser votre NAS normalement, même l'éteindre si besoin (la réparation recommencera au démarrage suivant). Par contre toutes les opérations seront fortement ralentis. Je vous recommande de laisser le NAS faire sa réparation tranquillement (ce n'est pas le moment d'aller y recopier des Giga de données). ######################## Contrôle de l'avancement en SSH Si vous souhaitez avoir plus de détails sur l'avancement de la réparation, connectez vous en ssh et entrez la commande : cat /proc/mdstat fenrir@nas:~$ cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid1 sdb5[2] sda5[3] 2925531648 blocks super 1.2 [2/1] [U_] [>....................] recovery = 2.7% (79955328/2925531648) finish=614.9min speed=77126K/sec md1 : active raid1 sdb2[1] sda2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sdb1[1] sda1[0] 2490176 blocks [2/2] [UU] unused devices: <none> Ici la vitesse est cohérente par rapport au taux de remplissage de mon NAS, à sa charge et à la vitesse des disques. ######################## Accélérer la vitesse de réparation La reconstruction d'un raid c'est toujours long, surtout avec des disques de plusieurs To et avec les raid de parité (raid5 ou 6) c'est encore plus long, donc il faut prendre son mal en patience. Avec mes 2 disques de 4To, mon NAS m'annonce environ 10h, il va bosser toute la nuit. La meilleur des actions à effectuer consiste à ne rien faire sur le NAS : laissez le tranquille. Néanmoins, dans certains cas, il arrive que la vitesse soit anormalement basse, il peut y avoir 3 causes : l'un des disque est fatigué ou défaillant : comme indiqué précédemment, la reconstruction d'un raid est une opération lourde pour les disques, d'où l'importance des sauvegardes votre NAS est trop sollicité : coupez les applications non essentiels, mettez vos téléchargement en pause, reportez votre soirée ciné ... la réparation est bridée Pour le dernier cas, il faut vérifier les 3 valeurs suivantes : La vitesse en dessous de laquelle la réparation ne doit pas aller (par défaut c'est 10000) : cat /proc/sys/dev/raid/speed_limit_min La vitesse au dessus de laquelle la réparation ne doit pas aller (par défaut c'est 200000) : cat /proc/sys/dev/raid/speed_limit_max La vitesse maximal autorisée dans la limite de la valeur précédente (par défaut c'est "max") cat /sys/block/md?/md/sync_max Si vous constatez des valeurs différentes chez vous, postez le résultat sur le forum, on vous indiquera si oui ou non c'est normal et si vous devez ou non modifier ces valeurs. ######################## Résultat final Une dernière notification pour indiquer que l'opération est terminée : Au final l'opération aura pris 12h chez moi, par contre je ne m'attendais pas à ça (mais j’aurais du puisque c'était indiqué dans le message dès le début) : Mon Syno a décidé tout seul d'agrandir le volume agrandi le volume comme annoncé, sans aucune intervention de ma part (je pense qu'il a fait ça en 2h, après les 10h estimées pour la réparation du raid). On appréciera ou non, perso, même si c'est ce que je comptais faire, j'aurai préféré qu'il laisse le choix (pour créer un nouveau volume par exemple). En pratique il a créé un nouveau volume physique LVM (pv) qu'il a associé au groupe (vg) afin d'agrandir le volume logique (lv) : fenrir@nas:~$ cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md3 : active raid1 sdb6[1] sda6[0] 976646528 blocks super 1.2 [2/2] [UU] md2 : active raid1 sdb5[2] sda5[3] 2925531648 blocks super 1.2 [2/2] [UU] md1 : active raid1 sdb2[1] sda2[0] 2097088 blocks [2/2] [UU] md0 : active raid1 sdb1[1] sda1[0] 2490176 blocks [2/2] [UU] unused devices: <none> On voit bien l'apparition de md3 (environ 1To).

TUTO Hyper Backup sur un NAS Synology (écrit sous DSM 6.1.4) Nous allons voir dans ce tutoriel comment utiliser Hyper Backup afin de faire une sauvegarde de ses données stockées sur un NAS Synology. Les possibilités avec Hyper Backup : Hyper Backup vous permet de faire des sauvegardes de plusieurs façons. "Stockage partagé local et stockage externe" permet des sauvegardes gérées par le NAS. Vous aurez besoin d'Hyper Backup pour restaurer les données et elle ne seront pas visibles directement sur la cible. "Synology NAS distant" permet de faire des sauvegardes sur un autre NAS. "WebDAV" permet des sauvegardes sur un serveur distant avec le protocole WebDAV. "Serveur Rsync distant" permet des sauvegardes via Rsync sur un serveur distant. Copie de données locales permet de faire une copie simple des données sans compression, chiffrage et autres en local. Les données sont lisibles et exploitables sans nas. Copie de données distantes permet de faire une copie simple des données sans compression, chiffrage et autres sur un périphérique distant via RSync. Les données sont lisibles et exploitables sans nas. "Services Cloud" permet de faire des sauvegardes sur des services proposés dans Hyper Backup comme Synology C2, Dropbox, Google Drive, Amazon Drive etc... (chiffrement vivement recommandé) Prérequis : Pour ce tutoriel, nous allons faire une sauvegarde en local sur un disque dur externe branché en USB sur le NAS. Installer le paquet Hyper Backup depuis le Centre de paquets. Brancher un disque dur externe en USB et s'assurer qu'il est bien reconnu par DSM. Configuration d'une sauvegarde sur un disque dur externe branché en USB sur le NAS : 1. On ouvre l'application Hyper Backup sur DSM. L'icône de ce paquet ressemble à ceci : 2. Une fois l'application ouverte, on va créer une nouvelle tâche de sauvegarde comme ci-dessous. 3. Puis une nouvelle fenêtre s'ouvre et nous demande la destination de la sauvegarde. 4. Ensuite, on indique le disque dur externe (reconnu comme un dossier partagé) qui devrait être nommé "usbshareX" (X étant un chiffre chez vous) puis on indique le nom que portera la sauvegarde dans le disque dur (ex : Documents). 5. Ensuite, il faut cocher le ou les dossier(s) puis la ou les application(s) que l'on souhaite sauvegarder pour cette tâche. Note : vous pouvez choisir un dossier partagé complet comme choisir uniquement un ou plusieurs sous dossier(s) d'un dossier partagé (cliquer sur les petites flèches noires pour voir les choix disponibles). ATTENTION : certaines applications sauvegardent aussi leurs dossiers respectifs (ex : PhotoStation et Moments sauvegardent aussi le dossier "photo" et Drive sauvegarde les dossier "Homes" et "web"). 6. Ensuite, on doit donner un nom à cette tâche que l'on lira dans l'interface principale d'Hyper Backup dans la colonne de gauche (ex : Documents). On peut aussi choisir d'autres options. A vous de voir ce qu'il vous convient. NOTE : pour ceux qui veulent un peu plus de personnalisation sur le calendrier de sauvegarde, on verra ça un peu plus loin et pour ejecter automatiquement le disque dur après la sauvegarde effectuée, il suffit de cliquer sur "Supprimer la destination de l'appareil externe etc..." ! ATTENTION : tout en bas de ces options se trouve le paramètre qui permet de chiffrer la sauvegarde. Je vous recommande vivement de la cocher puis d'entrer un mot de passe "fort" que vous n'oublierez pas. En cas d'oubli, il vous restera toujours la clé de sécurité fournie qui devra être stockée dans un endroit sécurisé pour qu'elle ne tombe pas entre de mauvaises mains. Libre à vous de ne pas la garder mais alors n'oubliez jamais votre mot de passe sinon vous ne pourrez pas accéder aux données sauvegardées... 7. Ensuite, on passe aux options de sauvegardes incrémentales et différentielles. Pour ne pas faire un pavé et afin que vous sachiez ce que ça veut dire, je vous renvoie directement sur la page wiki parlant de ce sujet. Je vous recommande cependant de travailler avec ces options afin d'optimiser la place de vos sauvegardes mais aussi vous assurer une restauration des fichiers qui auraient pu être supprimées entre deux sauvegardes. https://fr.wikipedia.org/wiki/Sauvegarde_(informatique) ATTENTION : une fois la configuration terminée sur cette fenêtre, répondre "NON" à la petite fenêtre qui s'est ouverte vous demandant si vous voulez "sauvegarder maintenant" SI vous souhaitez personnaliser plus précisément la planification de cette sauvegarde ! 8. Nous allons maintenant et rapidement voir comment configurer plus précisément la planification de cette sauvegarde. 9. Comme on peut le voir sur l'image ci-dessous, il y a plus de possibilités sur la planification. A vous de voir selon vos besoins ce qu'il faut régler 😉 10. Une fois cette planification configurée, on peut enfin lancer manuellement la première sauvegarde. ************************************************************* Pour finir, voici un récapitulatif de l'interface principale d'Hyper Backup : Voilà, vous savez tout sur l'application Hyper Backup EDIT du 24.08.2018 : Voici comme demandé dans un autre topic comment monter automatiquement un disque dur externe afin d'ajouter une sécurité supplémentaire. Se connecter en SSH à son NAS avec le disque dur branché dans un port USB. Taper le commande "lsusb" qui permet de lister les périphériques branchés en USB. Retenir le numéro du disque. Aller dans le planificateur de tâche puis créer une tâche. Programmer la tâche pour que le disque soit monté quelques minutes avant la sauvegarde. (Ex: sauvegarde à 23h, on programme le montage auto du disque dur pour 22h55). En script, on va mettre ceci avec bien entendu le numéro de disque si il ne correspond pas à ce que j'ai de mon côté : EDIT du 13.06.2019 : Procédure pour monter et démonter automatiquement un disque dur externe afin d'ajouter une sécurité supplémentaire. Monter le disque dur : 1. Brancher son disque dur externe sur le port USB du NAS. 2. Pour connaitre le port USB reconnu par le système ou se trouve le disque dur, on tape en SSH la commande : lsusb Résultat pour moi : 3. La commande pour monter automatiquement le disque dur sera donc : echo usb2 > /sys/bus/usb/drivers/usb/unbind && echo usb2 > /sys/bus/usb/drivers/usb/bind Cette commande est à entrer dans votre planificateur de tâches. Démonter le disque dur : 1.Pour démonter le disque dur proprement et sans recevoir une alerte du système, on doit d’abord connaitre le volume du disque dur utilisé par ce dernier. Pour ça, on tape la commande : /usr/syno/bin/synousbdisk -enum Résultat pour moi : Pour résumer, j'ai branché une baie de deux disques durs sur un port USB (usb2) du NAS. Les deux volumes pour mes deux disques durs de ma baie sont reconnus comme "sdq" et "sdr". 2. Pour démonter proprement les disques, je vais donc utiliser la commande : /usr/syno/bin/synousbdisk -umount sdq && /usr/syno/bin/synousbdisk -umount sdq Résultat pour moi : puis : echo usb2 > /sys/bus/usb/drivers/usb/unbind Ces commandes sont à entrer dans votre planificateur de tâches.

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 ) 2024-07-31 - 4.5.0 : https://github.com/Gizmo091/synology_1fichier_hosting/raw/main/OneFichierCom(4.5.0).host Changelogs : - 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. - la version 4.3.0 ( et peut être d'autre) du host de alldebrid fait echouter le chargement des fichiers host des autres provider. ( je ne sais pas pourquoi mais je l'ai constaté ). Support : Soit sur le forum, soit sur Discord : gizmo091 Informations : - Ce fichier host se configure de la facon suivante : nom d'utilisateur : ce que vous voulez ( mais il ne faut pas que ce soit vide), peut contenir des variables de configurations password : votre apikey , récupérable sur le site de 1fichier : https://1fichier.com/console/params.pl section API Key. Notez la bien car elle ne sera plus visible par la suite, il faudra alors la desactivé et en générer une nouvelle si vous devez la saisir à nouveau. Configurations addionnelles : Le champ username/nom d'utilisateur peut donc contenir un ou plusieur configuration. Elle doivent être saisies de la façon suivante : <parametre1>=<valeur_param1>;<parametre2>=<valeur_param2>;... Paramètres disponibles : - local_log : activable en ajoutant local_log=1 dans le champ username Les fichiers de logs seront écrits dans le répertoire /tmp/1fichier_dot_com , un fichier sera créer par téléchargement avec l'id du lien ( exemple : lien = https://1fichier.com/?kitiwlyogv8uozsnfi&af=3108529, fichier de log = /tmp/1fichier_dot_com/kitiwlyogv8uozsnfi.log ) , si par d'identifiant dans le fichier sera /tmp/1fichier_dot_com/default.log Exemple avec local_log d'activé : - remote_log : activable en ajoutant remote_log=<serveur_de_log> dans le champ username. Les logs seront envoyé au serveur passé en paramètres via des requetes cURL. Vous pouvez heberger votre propre serveur de log en utilisant le code se trouvant dans le repertoire remote_log du repository git, ou alors vous pouvez utiliser mon serveur : https://vedie.fr/remote_log/log.php et vous pouvez consulter les logs ici : https://vedie.fr/remote_log/read.php Exemple avec remote_log d'activé : Hashtags : hostfile, host file, onefichier

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

Bonjour, En répondant à plusieurs sujets relevant du choix de nouveaux disques et du remplacement de disques HS, je me suis rendu compte à la lecture de certains articles en anglais que des références bien connues utilisées dans nos NAS (ex: WD40EFRX) devenaient introuvables et étaient remplacées sans que cela soit clairement exposé dans leurs caractéristiques techniques, par de nouvelles références (ex: WD40EFAX) utilisant la technologie d'écriture SMR, permettant le doublement du nombre de pistes au détriment entre autres de leurs performances en écriture aléatoire. C'est pourquoi je vous suggère de regrouper ici (à déplacer éventuellement dans une autre rubrique) les informations concernant ces nouveaux disques indépendamment de leurs marques, en recensant les articles de presse, les informations données par Synology et les fabricants, les posts sur le sujet de Nas-forum.com, les trouvailles et problèmes techniques constatés et le recensement des disques concernés. Je m'efforcerai de compléter et regrouper régulièrement dans ce premier message, les liens et posts pertinents donnés dans vos réponses. Si vous voulez savoir quel est le problème avec ces disques, allez directement au chapitre: 3) Articles de presse et autres forums Attention les ajouts apparaissent dans l'ordre chronologique de leur arrivée. Les données techniques et commerciales ont pu évoluer et certains articles de presse ont pu être remis à jour depuis leur date de parution. C'est donc en bas de chaque paragraphe que vous trouverez les informations les plus "fraiches". Vous trouverez une synthèse des derniers recensements des disques SMR, et des disques USB pouvant être mis dans les NAS à moindre coût, dans ce message: https://www.nas-forum.com/forum/topic/68071-savoir-si-votre-disque-est-du-type-smr-ou-cmr/ 1) Liens et communiqués des fabricants. Que sont les disques durs PMR(CMR) et SMR ? FAQ par Synology https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/PMR_SMR_hard_disk_drives Sur le tableau de compatibilité des disques du site Synology : https://www.synology.com/fr-fr/compatibility?search_by=category&category=hdds_no_ssd_trim Vous constaterez que les références WD20EFAX et WD60EFAX comportent la Mention SMR dans l'avant dernière colonne à droite et la note suivante. - Ce pilote (disque) n'a pas de capteurs de vibration et peut ne pas s'adapter pour un fonctionnement 24h24 -7/7j dans un environnement rack - Veuillez noter que le firmware des HDD/SSD peut être mis à jour ou modifié par son fabricant sans avis préalable. Synology peut seulement s'assurer que les firmwares répertoriés sont compatibles avec les produit Synology. - En raison des caractéristiques des SMR, ce lecteur SMR peut avoir un temps de réponse plus long qu'un lecteur PMR. Il est fortement recommandé de ne pas mélanger les disques SMR et PMR dans un type de RAID. Communiqué de presse WD du 16/4/2020 (traduit) L'enregistrement magnétique Shingled (SMR) est une technologie de disque dur qui augmente efficacement la densité surfacique et la capacité des utilisateurs qui gèrent des quantités croissantes de données, réduisant ainsi le coût global des opérations. Il existe à la fois des types de gestion de périphérique et de gestion d'hôte, chacun pour différents domaines d'application. Tous nos disques WD Red sont conçus pour respecter ou dépasser les exigences et spécifications de performances pour le travail NAS typique et prévu pour les petites entreprises et les bureaux à domicile. Les disques durs WD Red d'une capacité de 2 à 6 To utilisent actuellement la technologie SMR de gestion des périphériques (DMSMR) pour augmenter la densité et la capacité de la surface. Les disques WD Red de 8 à 14 To utilisent la méthode d'enregistrement conventionnelle CMR (CMR = conventionnel Magnetic Recording). DMSMR ne doit pas être confondu avec la technologie SMR de gestion d'hôte (HMSMR). Ceci est conçu pour les applications dans le centre de données avec des exigences correspondantes pour la charge de travail et l'intégration d'hôte. DMSMR est conçu pour gérer le placement intelligent des données dans le lecteur au lieu de compter sur l'hôte. Cela permet une intégration transparente pour les utilisateurs finaux. L'intensité des données des charges de travail NAS typiques dans les petites entreprises ou au bureau à domicile est minime, laissant suffisamment de temps d'inactivité aux disques DMSMR pour effectuer des tâches de gestion des données en arrière-plan en cas de besoin et continuer à fournir aux utilisateurs des performances optimales. Les disques WD Red sont conçus et testés pour un taux d'utilisation annuel pouvant atteindre 180 To. Cependant, Western Digital a vu des rapports sur l'utilisation de disques durs WD Red dans des charges de travail qui vont bien au-delà des spécifications et des recommandations de l'entreprise. Si les cas d'utilisation des utilisateurs dépassent la charge de travail prévue, nous recommandons les disques WD Red Pro ou Ultrastar pour les centres de données. Western Digital travaille en étroite collaboration avec ses clients ainsi qu'avec les fournisseurs de NAS et les communautés partenaires afin d'optimiser en permanence notre technologie et nos produits pour des applications courantes. En collaboration avec les principaux fournisseurs de NAS, nous nous efforçons toujours de garantir que les disques durs WD Red (et SSD) de toutes capacités sont compatibles avec une large gamme de systèmes hôtes. Lors de nos tests des disques WD Red, nous n'avons trouvé aucun problème de récupération RAID dû à la technologie DMSMR. L'expérience de nos clients est importante pour nous. Nous continuerons d'écouter et de travailler avec la vaste communauté de clients et de partenaires. Notre objectif est de développer des technologies innovantes qui permettent de meilleures expériences avec, une gestion plus efficace et des décisions plus rapides sur les données. Communiqué de presse Seagate du 17/4/2020 (traduit) Nous optimisons la conception et les spécifications de nos disques pour être cohérents avec le positionnement et la charge de travail prévue pour chaque disque. Nos descriptions de produits et notre documentation fournissent les informations nécessaires pour choisir le bon lecteur pour la bonne application. « Seagate confirme ne pas utiliser la technologie Shingled Magnetic Recording (SMR) dans les disques IronWolf ou IronWolf Pro, qui sont spécialement conçus pour les solutions NAS ». Western Digital blog: Tech & Products - On WD Red NAS Drives https://blog.westerndigital.com/wd-red-nas-drives/ Communiqué de presse Toshiba (traduit) https://toshiba.semicon-storage.com/ap-en/company/news/news-topics/2020/04/storage-20200428-1.html Utilisation de la technologie SMR (Shingled Magnetic Recording) dans les disques durs grand public Toshiba. 28 avril 2020 Toshiba Electronic Devices & Storage Corporation L'introduction de la technologie SMR (Shingled Magnetic Recording) a permis aux fabricants de disques durs, tels que Toshiba, d'augmenter la capacité de leurs disques durs au-delà des approches existantes. La technologie SMR est reconnue comme ayant un impact sur les vitesses d'écriture dans les lecteurs où cette technologie est utilisée, en particulier dans le cas de l'écriture aléatoire continue. C'est pourquoi les produits Toshiba sont soigneusement adaptés aux charges de travail et aux cas d'utilisation spécifiques. Par exemple, dans des cas d'utilisation tels que le stockage en réseau (NAS), où l'écriture aléatoire continue est régulière, la gamme actuelle de produits Toshiba destinés aux consommateurs comprend le N300, qui n'utilise pas la technologie SMR. Le site Western Digital indique maintenant clairement sur la page de ses disques Nas, quels modèles sont SMR ou CMR: (en bas de page) https://www.westerndigital.com/fr-fr/products/internal-drives/wd-red-hdd Idem pour les disques Black et Blue: (pas encore pour les disques Gold) https://www.westerndigital.com/fr-fr/products/internal-drives/wd-black-hdd https://www.westerndigital.com/fr-fr/products/internal-drives/wd-blue-hdd Western Digital réorganise sa gamme de disques RED et introduit la série "Plus" pour différencier les disques SMR et CMR 23 juin 2020, WD Red pour NAS - Maintenant plus de choix pour les clients (🤣marketing inside 🤑) https://translate.google.com/translate?hl=fr&sl=auto&tl=fr&u=https://blog.westerndigital.com/wd-red-nas-drives/ 2) Posts sur le sujet sur ce forum (remplacement, pannes et problèmes techniques) Remplacement de disque WD Red -changement de capacité de mémoire https://www.nas-forum.com/forum/topic/66359-remplacement-de-disque-wd-red-changement-de-capacité-de-mémoire/#comment-1319398863 Cohabitation WD40EFRX et WD40EFAX https://www.nas-forum.com/forum/topic/66303-cohabitation-wd40efrx-et-wd40efax/ 3) Articles de presse et autres forums Gare au SMR incognito chez les constructeurs de disques durs ? https://www.comptoir-hardware.com/actus/stockage/41383-gare-au-smr-incognito-chez-les-constructeurs-de-disques-durs-.html Western Digital s'incline: certains disques durs de la série RED utilisent une technologie SMR lente sans divulgation (© Foksadure) https://www.tomshardware.com/news/wd-fesses-up-some-red-hdds-use-slow-smr-tech Seagate est également coupable de SMR non divulgué sur certains modèles de disques durs internes : http://www.pc-boost.com/pages/news_1587362556_seagate-est-egalement-coupable-de-smr-non-divulgue-sur-certains-modeles-de-disques-durs-internes-rapport.html Western Digital et Seagate livrent des disques SMR lents sans en informer les clients. (mal traduit) https://www.breakingnews.fr/science/western-digital-et-seagate-livrent-des-disques-smr-lents-sans-en-informer-les-clients-rapports-444882.html Notez que les disques durs WD Red de 2 à 6 To ont un enregistrement SMR secret (mal traduit) http://frenews24h.com/notez-que-les-disques-durs-wd-red-de-2-a-6-to-ont-un-enregistrement-smr-secret/ WD Red 6tb WD60EFAX SMR??? https://community.synology.com/enu/forum/1/post/127228 Seagate introduit en sous-main des disque SMR dans sa gamme Barracuda et Desktop https://blocksandfiles.com/2020/04/15/seagate-2-4-and-8tb-barracuda-and-desktop-hdd-smr/ Des fabricants de disques durs ont introduit les disques de type SMR dans les modèles standards en CMR, réduisant ainsi les performances des périphériques https://hardware.developpez.com/actu/300859/Des-fabricants-de-disques-durs-ont-introduit-les-disques-de-type-SMR-dans-les-modeles-standards-en-CMR-reduisant-ainsi-les-performances-des-peripheriques/ WD community forum: PMR and SMR question https://community.wd.com/t/pmr-and-smr-question/249745/5 IronWolf (Pro) : Seagate affirme ne pas utiliser la technologie SMR dans ses HDD pour NAS https://www.inpact-hardware.com/article/1788/ironwolf-pro-seagate-affirme-ne-pas-utiliser-technologie-smr-dans-ses-hdd-pour-nas Seagate refuse de détailler la présence du SMR dans l'ensemble de ses disques durs (© Firlin) https://www.inpact-hardware.com/article/1805/seagate-refuse-detailler-presence-smr-dans-ensemble-ses-disques-durs Disques durs SMR : Toshiba clarifie à son tour sa position (© Firlin) https://www.inpact-hardware.com/article/1810/disques-durs-smr-toshiba-clarifie-a-son-tour-sa-position Un article très intéressant qui compare les performances des WD40EFRX et WD40EFAX en cas de remplacement d'un disque dans une grappe raid. ("resilvering" en format ZFS/Freenas) On peut supposer que passer de 17h à 230h pour un échange de disque CMR par un SMR dans une grappe Raid sera proportionnellement identique en durée dans un Nas Synology. (voir page 2) Article en anglais: https://www.servethehome.com/wd-red-smr-vs-cmr-tested-avoid-red-smr/ Traduction Google: https://translate.google.com/translate?hl=fr&sl=auto&tl=fr&u=https://www.servethehome.com/wd-red-smr-vs-cmr-tested-avoid-red-smr/ Western Digital pourrait faire face à la justice pour avoir caché des disques SMR dans ses NAS https://www.comptoir-hardware.com/actus/business/41680-western-digital-pourrait-faire-face-a-la-justice-pour-avoir-cache-des-disques-smr-dans-ses-nas.html Synology ne considère plus les disques durs WD-Red SMR comme compatibles avec ses NAS. (© maxou56, © Foksadure) https://www.cachem.fr/smr-synology-incompatible-nas/ https://www.en24.news/2020/06/nas-hard-drives-synology-now-lists-wd-red-hdds-as-incompatible-with-smr.html Western Digital réorganise sa gamme de disques RED et introduit la séries "Plus" pour différencier les disques SMR et CMR (© Brunchto) https://translate.google.com/translate?hl=fr&sl=auto&tl=fr&u=https://www.anandtech.com/show/15878/western-digital-cleans-up-the-red-smr-nas-hdd-mess SMRgate : Western Digital réorganise sa gamme WD Red: https://www.silicon.fr/smrgate-western-digital-wd-red-341917.html Des WD Red mal étiquetés et toujours mal emballés chez Amazon ? (© Firlin) https://www.comptoir-hardware.com/actus/stockage/41898-des-wd-red-mal-etiquetes-et-toujours-mal-emballes-chez-amazon-.html Disques durs Red pour NAS : Western Digital nous confirme que certains modèles sont SMR https://www.inpact-hardware.com/article/1780/disques-durs-red-pour-nas-western-digital-nous-confirme-que-certains-modeles-sont-smr 4) Recensement des disques en technologie SMR Un site intéressant qui rassemble des informations pour chaque modèle et série de disques et donne la technologie employée: Nbr de plateaux et têtes, SMR/PMR. The HDD Platter Capacity Database https://rml527.blogspot.com/ Témoignage perso Hors NAS: je confirme que le SEAGATE ST2000DM008 utilisé sur mon PC. (2To, acheté en Aout 2019) est bien un modèle SMR. Fonction Trim présente et cache doublé (256Mo). Suite à de nombreux secteurs en erreur, et échec des diags Seagate, il a été échangé sous garantie en novembre 2019 par un modèle reconditionné. Suite à de nouvelles erreurs et échec diags, un nouvel échange a eu lieu mi-mai 2020. Il semble que la gamme Ironwolf de Seagate ne soit pas encore touchée par ce problème, mais par un autre, qui devrait donner lieu à une mise à jour firmware: Seagate 12TB Ironwolf ST12000VN0007 has write cache disabled. https://community.synology.com/enu/forum/1/post/122610 Disques SMR confirmés pour Seagate: Seagate Barracuda 2TB ST2000DM008 (3,5 pouces, 7200 tr / min, SATA) Seagate Barracuda 4TB ST4000DM004 (3,5 pouces, 5400 tr / min, SATA) Seagate Barracuda 8TB ST8000DM004 (3,5 pouces, 5400 tr / min, SATA) Seagate Desktop 5 To ST5000DM000 (3,5 pouces, 5900 tr / min, SATA) Disques SMR confirmés pour Western Digital: Western Digital Red 2TB WD20EFAX (3,5 pouces, 5400 tr / min, SATA) Western Digital Red 3TB WD30EFAX (3,5 pouces, 5400 tr / min, SATA) Western Digital Red 4TB WD40EFAX (3,5 pouces, 5400 tr / min, SATA) Western Digital Red 6TB WD60EFAX (3,5 pouces, 5400 tr / min, SATA) Le site Western Digital indique maintenant clairement sur la page de ses disques Nas, quels modèles sont SMR ou CMR: (en bas de page) https://www.westerndigital.com/fr-fr/products/internal-drives/wd-red-hdd Idem pour les disques Black et Blue: (pas encore pour les disques Gold) https://www.westerndigital.com/fr-fr/products/internal-drives/wd-black-hdd https://www.westerndigital.com/fr-fr/products/internal-drives/wd-blue-hdd Disques SMR confirmés pour Toshiba: Toshiba P300 desktop 4TB (HDWD240UZSVA) Toshiba P300 desktop 6TB (HDWD260UZSVA) Toshiba L200 et MQ04 de 1 et 2 To, 2,5" Toshiba DT02 et DT02-V de 4 et 6 TB Tableau des disques SMR recensés, tous fabricants: (© Satdream/Dealabs) 5) Technologies utilisées dans les disques et aspects techniques: ***Traduction d'un article sur Reddit donnant des pistes pour détecter un disque SMR et explique que l'acronyme CMR (= pistes conventionnelles) serait préférable à PMR (= technologie des têtes) pour les différencier des disques SMR. (= double de pistes avec recouvrement) https://www.reddit.com/r/DataHoarder/comments/ewwkll/are_the_seagate_ironwolf_nas_drives_pmr_or_smr_im/ Quelques définitions: - Le terme "marketinge" préféré pour les lecteurs "normaux" est maintenant "CMR" - Enregistrement magnétique conventionnel. - PMR signifie "Perpendicular Magnetic Recording" (la façon dont les domaines magnétiques sont disposés sur le plateau, par opposition aux domaines magnétiques longitudinaux d'autrefois) - Le Shingled PMR (SMR) est une évolution de la technologie PMR, avec un recouvrement en écriture sur deux pistes lues séparément (largeur têtes d'écriture = 2X tête de lecture) - La TGMR (Tunneling Giant Magneto-Resistive) est une technologie de tête nécessaire pour la PMR et est la même pour la SMR ou la CMR - TDMR (Two Dimensional Magnetic Recording) est une façon détournée de dire "médias zonés" et la seule raison pour laquelle vous avez zoné des médias est.... parce que c'est du SMR (vous avez besoin de zones temporaires pour pouvoir faire des réécritures) - Les disques remplis d'hélium n'implique pas de CMR ou de SMR. Vous pouvez trouver des disques dans les deux formats,- CEPENDANT, vous pouvez déduire qu'il s'agit d'un SMR probable pour les disques remplis d'air au-dessus de 4 To en 3,5" et 2 To en 2,5". Tous les disques mécaniques sur le marché utilisent la PMR, qu'il s'agisse de la CMR ou de la SMR et quelle que soit la vitesse. En effet, les trois fabricants utilisent les mêmes plateaux et les mêmes têtes, chacun d'eux étant fabriqué par un seul fabricant. Quelques autres points : - Les disques dont les fiches techniques indiquent qu'ils sont nettement plus légers que leurs prédécesseurs sont probablement des SMR - Les disques avec un grand cache (256 Mo+) sont très probablement des disques SMR - ils en ont besoin pour fonctionner. (il y a des fonctions de hiérarchisation des données dans les disques SMR gérés (DM-SMR) semblables à celles que l'on trouve dans les SSD TLC/QLC - mais beaucoup plus lentes...) - Les lecteurs qui rapportent des fonctions de "trim" sont SMR, même s'ils n'indiquent pas des médias zonés (le rapport de zonage est une fonction ACS-4 - bien que cela ait été codifié en 2016, de nombreux lecteurs ne sont encore qu'ACS-3 qui ne supporte pas cette fonction de rapport.... hmmmmm... Je me demande pourquoi ?) - CEPENDANT - Tous les lecteurs SMR ne rapportent pas les fonctions de trim et la seule façon de le savoir est de faire une analyse comparative des choses - (Seagate barracuda ST3000DM003 étant un bon exemple) - FAITES ATTENTION AUX SUFFIXES, LISEZ LES FICHES TECHNIQUES. - COMPARER AVEC LES MODÈLES PRÉCÉDENTS - un changement de génération (de 003 à 004, ou de EFRX à EFAX) peut très bien signifier qu'un changement a été fait en sous-marin dans le canal. Vérifiez le poids. La perte d'un plateau de la même taille est un signe certain que cela s'est produit. Avant tout : Plaignez-vous vivement auprès des autorités locales de réglementation du marketing au sujet de ce comportement trompeur. WD et SG SAVENT que nous ne voulons pas de du SMR, c'est pourquoi ils font tout leur possible pour ne pas l'inscrire sur leurs fiches techniques. (les autorités de réglementation européennes et chinoises devraient être particulièrement réceptives aux plaintes pour marketing frauduleux et comportement d'entente) *** Traduction d'un article qui explique les problèmes de compatibilités posés par les disques SMR avec les Raid au format ZFS (= Freenas, à priori il n'y pas ce problème sur Synology, sauf pour les performances en écriture aléatoire, et éventuellement l'ajout d'un disque à une grappe raid) https://www.ixsystems.com/blog/library/wd-red-smr-drive-compatibility-with-zfs/ .... 1. Certains lecteurs SMR sont en effet compatibles avec le ZFS, bien qu'en raison de l'absence d'une mise en œuvre de la technologie conforme aux normes industrielles ratifiées, ils ne se comportent pas tous nécessairement de la même manière. Une étude plus approfondie est nécessaire pour déterminer la compatibilité de chaque implémentation avec le ZFS. Pour l'instant, nous nous concentrons sur le test de l'implémentation du WD Red DM-SMR. 2. En général, les lecteurs SMR sont utilisés pour leur efficacité énergétique et leur prix abordable. En ce qui concerne les performances, les vitesses d'écriture séquentielles peuvent être plus rapides, mais les vitesses d'écriture aléatoires sont plus faibles et ralentissent les opérations telles que l'ajout d'un disque à une grappe Raid. Nous recommandons les lecteurs CMR pour des performances plus uniformes. Pour une liste des lecteurs SMR, voir le post communautaire de Yorick. 3. Les disques WD Red DM-SMR utilisent un modèle d'adressage de bloc logique indirect, qui est similaire aux SSD. Après des écritures aléatoires sur le disque, les disques doivent effectuer une réécriture des données en arrière-plan, ce qui réduit leurs performances d'écriture aléatoire. Lorsque l'on ajoute un lecteur DM-SMR à un pool ZFS, il est préférable que le lecteur soit effacé au préalable. 4. Au moins un des modèles WD Red DM-SMR (le WD40EFAX 4 To avec firmware rev 82.00A82) présente un problème de compatibilité ZFS qui peut le faire entrer dans un état défectueux sous de fortes charges d'écriture, y compris l'ajout d'un disque à une grappe Raid. Cela a été confirmé dans nos laboratoires cette semaine au cours des tests, ce qui a entraîné la disqualification de ce modèle de lecteur de nos produits. Nous pensons que les autres disques WD Red DM-SMR avec le même micrologiciel auront le même problème, mais les tests sont toujours en cours pour valider cette hypothèse. 5. En cas de panne, le disque WD Red DM-SMR renvoie des erreurs IDNF, devient inutilisable et est traité comme une panne de disque par ZFS. Dans cet état, les données de ce disque peuvent être perdues. Les données d'un vdev ou d'un pool peuvent être perdues si plusieurs lecteurs tombent en panne. 6. L'incompatibilité ZFS causant une panne de disque est un événement rare. Bien que nous ayons livré une centaine de systèmes FreeNAS Mini avec les disques DM-SMR de 2 To et 6 To, nous n'avons eu qu'un seul problème signalé. D'autres tests seront effectués pour comprendre les problèmes de compatibilité ZFS et comment les éviter. 7. Parmi les produits d'iXsystems, la série FreeNAS Mini est la seule ligne de produits qui utilise des disques WD Red. La plupart des systèmes FreeNAS Mini livrés n'ont pas utilisé de disques DM-SMR. Seuls les systèmes expédiés avec des disques de 2 ou 6 To depuis septembre 2019 peuvent être équipés de disques DM-SMR. SMRgate : cette technologie que les fabricants de disques durs ont passée sous silence: https://www.silicon.fr/smrgate-disques-durs-339085.html A voir dans cet article outre les explications techniques sur le SMR, la vidéos de Manfred Berger, Ex. de la division disques IBM, rachetée par Hitachi/HGST, aujourd'hui propriété de WD. Il explique déjà en 2015 les inconvénients de la technologie SMR appliquée aux Nas: https://www.youtube.com/watch?v=a2lnMxMUxyc à 13mn 30 > "drive managed behaviors".

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

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 😉

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

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

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

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

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

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

Ça c'est le point de vue du technicien qui sait de quelles informations il a besoin pour avancer. C'est rarement le cas d'un utilisateur non-technicien qui vient exposer son problème. Personnellement ça ne me dérange pas de poser les questions nécessaires. Bon ceci dit, c'est qu'on a eu quelques cas de "ça marche pas" sans plus de précision, mais ça reste assez rare, heureusement 😅 @Einsteinium Rien ne t'oblige à répondre à tous les problèmes. Quand je vois un gros manque d'effort, je ne réponds pas car je sais que d'autres le feront. Et c'est probablement la meilleure des réponses à faire.

/! Mise à jour Importante !! Depuis 2013 le script (version 1.9), a été directement intégré dans SynoCommunity SABnzbd (Merci Diaoul !! ). Pour ceux qui n'ont encore rien installé, vous pouvez directement allé à la section 8. Le répertoire "Script" avec l'installation par défaut est: /usr/local/sabnzbd/var/scripts Cependant le package SynoCommunity va installé le script uniquement si SABnzbd n'est pas déjà installé !! Si vous faites une mise à jour d'une version existante, alors vous devez suivre le tuto en entier!!! Ou tout désinstaller puis tout réinstaller.... C'est vous qui voyez... /! Fin de mise à jour Au cas où vous considéreriez que les heures passées méritent quelque chose: MAIS, merci de faire un don à SABnzbd et SynoCommunity d'abord et si il vous reste quelques piécettes alors vous pouvez penser à moi. Ce que ce script peut faire pour vous: Le script permet de corriger les problèmes d'accents lorsque SABnzbd tourne sur un NAS Synology. Il inclue aussi les options suivantes (le script doit être édité pour les activer/désactiver): Fonction pour décompresser les archives .7z (Activer par défaut) Fonction pour déplacer le répertoire vers une destination au choix: 2 modes possible, un mode qui écrase, un mode qui fusionne. (Désactiver par défaut) Fonction pour indexer automatiquement le répertoire dans le DLNA du Syno. (Désactiver par défaut) Fonction pour envoyer le répertoire vers SickBeard (NB: le script sabToSickBeard.py doit être configuré et fonctionnel). (Désactiver par défaut) Attention: les options DLNA/SickBeard sont exclusive. C'est soit l'une, soit l'autre. Si vous voulez les 2 en même temps, il faut configurer l'indexeur DLNA dans l'interface de SickBeard. [Edit du 2 Octobre 2013] Correction d'un problème de post-processing avec Sickbeard quand le répertoire contient un caractère spécial. La version du script est maintenant affiché pour faciliter le suivi pour le debug. Cette version n'est pas inclus dans le package SynoCommunity SABnzbd Il faut suivre le tuto, puis aller dans la section options pour activer celles qui vous intéresse. Si vous utilisez déjà ce script, il faut suivre les étapes 1 à 6 pour mettre à jour. Depuis le début d'année j'ai reçu 1 seul et unique don par un Hollandais. Alors soyez sympa pensez à moi! Surtout que je viens de me faire licencier économique depuis 1mois... D'un autre côté le script ne représente pas grand chose par rapport au boulot que doit fournir l'équipe SABnbzd et Diaoul, mais il rend quand même bien service... [Edit du 2 Octobre 2013] [Edit du 19 Février 2013] Ajout d'une option pour activer le post-processing Sickbeard. Fonction 'Move' plus évolué (2 modes). Rajout d'une fonction que je n'aurai pas dû retirer. Utilisation du code page cp850 au lieu de cp437. Cette version est inclus dans le package SynoCommunity SABnzbd à partir de la version 0.7.14 [Edit du 19 Février 2013] TIP: Vous pouvez utiliser le package de Mertymade pour éditer vos fichier de config: Config File Editor Lancer l'application depuis DSM, puis sélectionnez Config File Editor dans la list, ajoutez la ligne suivante au début ou à la fin (exemple pour le package SynoCommunity): /usr/local/sabnzbd/var/scripts/CharTranslator.py,CharTrans Cliquez sur "Save", quittez, puis relancez l'application Config File Editor et voilà! Le script est éditable depuis DSM. J'utilise les SPKs fournis par www.synocommunity.com, en particulier SABnzbd. Oui mais voilà, il y a une problème ennuyeux avec les fichiers français: quand il y a des accents on ne peut pas accéder aux fichiers avec Samba (disque réseau du Syno). Il faut alors tout renommer par SSH avant de pouvoir s'en servir. Voici ma solution basée sur un script Python utilisant le post-processing sous SABnzbd. 1- Téléchargez le script: 2- Sauvez le fichier sur le NAS. 3- Connectez-vous sur votre NAS avec Telnet en tant que root (pas admin) et allez dans le répertoire où le fichier ZIP a été enregistré. Par ex: cd /volume1/public 4- unzipper le fichier. Sous telenet unzip CharTranslator_1v5.zip /! Attention /! Si vous utilisez une autre source que synocommunity.com vous devez mettre à jour la 1er ligne du script, afin d'indiquer le chemin où se trouve la commande python. SynCommunity (par défaut dans fichier ZIP): #!/usr/local/python/bin/python -OO SPK MertyMade: #!/var/packages/pythonutils/target/utils/bin/python -OO ou #!/volume1/@appstore/sab2/utils/bin/python -OO A vous de vérifier avec une session Telenet SPK Zebulon: #!/usr/local/python26/bin/python -OO 5- Mettez les bons droits Unix. Sous telenet: chmod 777 CharTranslator.py 6- Déplacez le script dans le répertoire (N'oubliez pas de créer le répertoire... ) où le script va être stocké. Par ex: mkdir /volume1/download/SABnzbdScripts mv CharTranslator.py /volume1/download/SABnzbdScripts Si vous utilisez la version SynoCommunity, écrasez la version existante cp -rf CharTranslator.py /usr/local/sabnzbd/var/scripts/CharTranslator.py Config -> Folder, spécifiez le répertoire où le script va être stocké (c'est la champ Post-Processing Scripts Folder). Par ex dans mon cas /volume1/download/SABnzbdScripts. Cliquez sur le bouton Save Changes. 8- Finalement allez dans: Config -> Categories. Vous pouvez mettre à jour la catégorie par défaut. En effet une colonne script est disponible, afin de sélectionner le script CharTranslator.py.Cliquez sur le bouton à droite Save. /! Attention /! le fichier doit être au format Unix! Si vous voulez modifier le fichier depuis Windows, vous pouvez utiliser le super éditeur Notepad++. N'oubliez pas de sauvegarder le fichier au format Unix (Edit -> EOL Conversion -> Unix). Si vous avez un message d'erreur du genre: -ash: CharTranslator.py: not found le fichier est certainement au format Windows. Pour rappel: les retours à la ligne sont différent dans le monde Unix. Et voilà !! Le script est récursif, donc tous les fichiers et sous répertoire vont être scannés et modifié si nécessaire. Si tout se passe correctement, vous devriez obtenir le message suivant: Character encoding translation done! (More) Décompresser les fichiers au format .7z: Le répertoire va être scanné de façon récursive et tous les fichiers .7z vont être décompressés. Cette option est activée par défaut. Si vous ne voulez pas de cette option, alors vous devez modifier la ligne suivante: Ligne 76: Unpack7z = True doit être modifié par: Unpack7z = False Ajouter lindexation DLNA avec synoindex: J'ai eu une demande sur le forum officiel de SABnzbd; un des membres utilise le répertoire de téléchargement de SABnzbd comme destination finale pour ces fichiers vidéo/audio. Il m'a demandé comment lancer l'indexation DLNA, car SABnzbd ne permet pas de lancer 2 post-processing. Pour ceux qui seraient aussi intéressé par cette caractéristique, voici la procédure à suivre: Ligne 68: IndexInSynoDLNA = False doit être modifié par: IndexInSynoDLNA = True Le répertoire de destination spécifié par Sabnzbd va être automatiquement indexé dans le DLNA. Attention: cette fonction ne peut pas être utilisé en même temps que l'option SickBeardPostProcessing Envoyer un téléchargement fini vers SickBeard: NB: le script sabToSickBeard.py doit être configuré et fonctionnel Activer cette option permet d'envoyer le téléchargement vers le post-processing de ScikBeard Ligne 72: SickBeardPostProcessing = False doit être modifié par: SickBeardPostProcessing = True Attention: les options DLNA/SickBeard sont exclusive. C'est soit l'une, soit l'autre. Si vous voulez les 2 en même temps, il faut configurer l'indexeur DLNA dans l'interface de SickBeard. Interface graphique SickBeard -> Config -> Notifications -> Enable 'Synology Indexer' Déplacer un téléchargement fini: Vous pouvez déplacer le répertoire dans une autre destination. Ligne 51: MoveToThisFolder = '' doit être modifié par: MoveToThisFolder = 'Chemin de destination des downloads' par ex: MoveToThisFolder = '/volume1/video/news' Le déplacement a 2 modes possibles: Le déplacement par défaut est l'équivalent d'un mv -f. C'est un genre de copie incrémental: rien n'est effacé, seul les fichiers portant le même nom sont écrasés par les plus récents (équivalent au déplacer/remplacer de Windows) Si vous voulez qu'en cas de conflit, le sous-répertoire soit entièrement remplacé par le nouveau (équivalent a un déplacement sous MacOSx), alors il faut désactiver l'option suivante. Ligne 62: MoveMergeSubFolder = True doit être modifié par: MoveMergeSubFolder = False Évidemment ces 3 options peuvent être cumulées. 1- Unpack les fichier .7z 2- Corrige les problèmes d'accents 3- Déplace le répertoire dans la destination spécifiée 4- Ajout des fichiers multimedia dans le DLNA du Syno. Finalement pour ceux qui sont intéressé uniquement pout la fonction 7z unpack avec SickBeard: Si seul la décompression 7z vous intéresse en particulier avec SickBeard, alors voici un mini Tuto: 1- Téléchargez le script: 2- Sauvez le fichier sur le NAS. 3- Connectez-vous sur votre NAS avec Telnet et allez dans le répertoire où le fichier ZIP a été enregistré. Par ex: cd /volume1/public 4- unzipper le fichier. Sous telenet unzip sabToSickBeard_1v1.zip /! Attention /! Si vous utilisez une autre source que synocommunity.com vous devez mettre à jour la 1er ligne du script, afin d'indiquer le chemin où se trouve la commande python (Voir début du tuto). 5- Mettez les bons droits Unix. Sous telenet: chmod 777 sabToSickBeard.py 6- Si vous utilisez la version SynoCommunity, écrasez la version existante cp -rf sabToSickBeard.py /usr/local/sickbeard/share/SickBeard/autoProcessTV/sabToSickBeard.py Et voilà les NZB au format .7z vont être décompressé avant d'être envoyé à SickBeard. Have fun folks !! Je suis preneur de tout les commentaires. PS: Le script peut être exécuté en commande en ligne sous une session telenet à condition qu'aucune option n'est été activée . Par ex: /volume1/download/SABnzbdScripts/CharTranslator.py "Nom du répertoire qui doit être corrigé" Si vous exécutez depuis le répertoire où le script est, la commande est: ./CharTranslator.py "Nom du répertoire qui doit être corrigé" /! Attention /! Ce script est a utilisé à vos risques et périls. Cependant, même si le script se trompe sur le format d'encodage, les fichiers seront tout de même lisible par Samba. Donc, au pire, vous devrez renommer manuellement les fichiers/répertoires.

Bonjour, @alan.dub @Jeff777 @.Shad. @CyberFr @GrOoT64 @PPJP @_Megalegomane_ @TuringFan @zerda @oudin @vincentbls @Einsteinium @kerod @Jz84 @jo.p @Pinpon_112 @Audio @bruno78 Pour vous informer qu'une évolution a été apportée au TUTO. § 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. Nouvelle version v1.40 du script Python (à remplacer simplement dans le répertoire « /volume1/Scripts »). Cordialement oracle7😉

Bonjour, Dans ce mini tutoriel, nous allons voir comment gérer les droits avec Photo Station 6 sur DSM 6. En effet, on constate de plus en plus de membres sur le forum qui se questionnent quand au fonctionnement et surtout la gestion des droits sur Photo Station. 1. Installer Photo Station depuis le centre de paquets. En plus d'installer "Photo Station", ça va créer le dossier "photo" dans File Station. Les photos sont à mettre dedans avec l'arborescence que l'on désire. 2. Ouvrir Photo Station comme sur la capture d'écran ci-dessous. Une nouvelle fenêtre s'ouvrira pour la connexion. Se connecter avec un compte administrateur. 3. Une fois dans Photo Station, cliquer sur "Paramètres" qui se situe en haut à gauche. 4. Dans cette nouvelle fenêtre, cliquer sur "Photos" dans le menu de gauche puis ensuite, cliquer sur "Permission d'accès". 5. Dans cette petite fenêtre qui s'est ouverte, on peut voir l'arborescence de nos dossiers. Nous avons trois choix possibles : Public : n'importe qui (même les non membres) peuvent accéder aux photos. Privé : seuls les membres (selon les autorisations définies) peuvent accéder aux photos. Mot de passe : seuls les personnes ayant le mot de passe (même les non membres) peuvent accéder aux photos. Une fois nos choix cochés, cliquer sur "sauvegarder" puis "fermer". 6. Une fois cette fenêtre fermée, on clique sur "Comptes utilisateur" puis on sélectionnes un membre et on clique sur "modifier". 7. Dans cette nouvelle petite fenêtre, on clique sur "Attribuer des privilèges". 8. Une nouvelle fenêtre s'est ouverte par dessus la petite dernière. C'est ici qu'on gère tous les droits sur un membre pour chaque dossier et sous dossier. Comme on peut le voir sur l'image ci-dessous, il y a plusieurs choix possibles pour chaque dossier : Parcourir l'album : permet au membre de visualiser les photos du dit dossier. Chargement de fichiers : permet au membre de charger des photos dans ce dossier. Gérer : permet au membre de gérer complètement le dossier en question (supprimer, créer sous dossier, renommer etc...). Ne pas oublier de sauvegarder les changements avant de fermer en cliquant simplement sur le bouton "Sauvegarder". Ce petit tuto est terminé

Bonjour, Dans ce tuto, je vais vous montrer la "petite" manipulation à faire pour désactiver Universal Search. On peut voir ici ou là sur la toile beaucoup de personnes se plaindre de ce paquet qui prend pas mal de ressources surtout sur des NAS de petites configurations et malheureusement, on ne peut pas à ce jour le désactiver. Mais avec cette petite manipulation, ça sera le cas ! ATTENTION : depuis une mise à jour récente d'Universal Search, ce dernier dépend entièrement des paquets Drive et Office. C'est pourquoi vous ne pourrez le désactiver si vous utilisez un de ses paquets ! Nouvelle méthode simplifiée : On se rend dans Panneau de configuration > Planificateur de tâches puis on créer une nouvelle tâche avec comme script : sed -i 's/ctl_stop="no"/ctl_stop="yes"/g' /var/packages/SynoFinder/INFO Le fichier INFO est ainsi modifié et on peut ensuite stopper UNIVERSAL SEARCH Si en plus on veut pouvoir le désinstaller on ajoute cette ligne : sed -i 's/ctl_uninstall="no"/ctl_uninstall="yes"/g' /var/packages/SynoFinder/INFO Source : @daffy Ancienne méthode : Prérequis : Accès root en SSH à votre NAS. Durée : Deux minutes maximum. ATTENTION : ni moi, ni le staff ne pourront être tenus pour responsables de ce que vous faites avec votre NAS ! 1. Se rendre sur son NAS via SSH (connecté en root) puis taper la commande : vi /var/packages/SynoFinder/INFO 2. Ensuite, on entre en mode éditeur en tapant la lettre "i" puis on se rend sur la ligne ctl_stop="no". Là, on met yes à la place de no puis on quitte le mode éditeur en tapant sur la touche "Echap" puis on tape ensuite ":wq" pour enregistrer le changement effectué puis on tape "exit" pour quitter. Résultat ci-dessous : On peut maintenant se rendre dans le Centre de paquets puis sur le paquet "Universal Search" et arrêter le paquet comme n'importe quel autre. Si comme sur la capture ci-dessus, vous voulez avoir la possibilité de désinstaller Universal Search, alors il vous suffit de commenter la ligne ctl_uninstall="no" en yes ! ---------------------------------------------------------------- Si vous ne savez pas comment vous connecter en ROOT SSH, alors voici le tuto : Source : forum officiel

Non c est possible, et de façon tres simple!!!! Tu va dans les réglage avancés du réseaux. Tu t 'assure d etre en multiple gateway seulement. Tu lance ton vpn. Tu retourne sur le multiple gateway tu décoche, tu valide , tu applique. Tu refais la meme manip ( et oui!!!!) et tu le coche, valide, et applique. Ton DSDowloand restera sur le vpn et toutes tes autres applications seront sur l ip de chez toi. Vous pouvez vérifier avec un torrent ip =)

Certains vont tout à coup comprendre la différence entre RAID et sauvegarde... Quoi qu'il puisse se passer sur le NAS, mon disque de sauvegarde USB au fond du tiroir se porte à merveille.

Bonjour, J'utilise en permanence les deux outils : TimeBackup et "Sauvegarder et Restaurer", j'ai aussi utilisé TimeMachine sur OsX. Je vais essayer de détailler les avantages et les inconvénients de chaque méthode : 1. Choix des éléments à sauvegarder Là le top c'est TimeMachine car : le système est sauvegardé les applications sont sauvegardées les données sont sauvegardées, en plus il permet d'exclure certains dossiers. "Sauvegarder et Restauter" est très bon aussi, car : le système n'est pas totalement sauvegardé, mais on peut sauvegarder la configuration. Donc si on change de DSM on ne peut pas récupérer sa version de DSM, mais on peut restaurer tous ces groupes, partages, ... les applications (bases MySQL, Photo Station, ...) sont sauvegardées les données sont sauvegardées et on peut choisir d'exclure des fichiers et des dossiers TimeBackup est le moins complet (mais aussi le plus jeune) : les données sont sauvegardées, mais on ne peut que choisir d'exclure ou d'inclure des dossiers partagés (impossible de choisir un sous-dossier ou même un fichier !!). C'est très énervant surtout quand vous activez la corbeille, car un fichier est sauvegardé une fois à son emplacement d'origine puis une autre fois dans la corbeille ... enfin vous pouvez limiter cet effet grâce à des scripts () MAIS le système ne peut pas être sauvegardé MAIS les applications ne peuvent pas être sauvegardées 2. Restauration des données TimeMachine permet de restaurer des données de 2 façons : sur un Mac vierge avec un disque bootable on peut restaurer tout le système, les applications et même les données directement dans l'OsX on peut accéder à un "explorateur de fichier temporel" qui permet de restaurer des fichiers ou dossiers tel qu'ils étaient à une date précise MAIS si on explore une sauvegarde TimeMachine sur un autre système on ne peut rien en faire : multitude de fichiers de 8Mo sans signification (peut-être existe-t-il des applications pour les interpréter, mais je n'en connais pas) Pour "Sauvegarder et Restaurer", on peut restaurer les données : avec l'outil intégré au DSM : vous pouvez choisir les paramètres de configuration (1 à 1 : on n’est pas obligé de tout restauré à l'identique) et les dossiers à restaurer. avec un simple explorateur de fichier, vous pouvez aussi restaurer vos données, car les images respectent l'arborescence d'origine (par contre attention à la méthode de copie si vous voulez conserver les métadonnées). Pour TimeBackup : on peut parcourir les fichiers dans "un explorateur de fichier temporel" et choisir très facilement (clic droit : Restaurer) de les restaurer tel qu'ils étaient à une date précise. Par contre on ne peut pas restaurer un dossier partagé, mais seulement des sous-dossiers. On peut aussi parcourir ces images avec un simple explorateur de fichier, car TimeBackup utilise des Hard links (http://fr.wikipedia.org/wiki/Lien_mat%C3%A9riel) pour pointer sur des fichiers qui n'ont pas été modifiés. Donc lorsque parcours l'arborescence d'une sauvegarde TimeMachine on a un dossier par image avec l'arborescence complète de la sauvegarde : la taille de ces dossiers correspond à la taille totale de la sauvegarde, mais vous pouvez en avoir plus de 100 et l'espace utilisé sur votre disque correspond seulement à une sauvegarde complète plus la taille des fichiers modifiés. Vous pouvez donc restaurer des données aussi très facilement sur n'importe quel système. 3. Programmation des sauvegardes Pour la programmation des sauvegardes on peut avec chacun de ces 3 programmes choisir précisément la date et l'heure à laquelle réaliser ces images. TimeBackup permet d'utiliser SmartRecycle qui va supprimer "intelligemment" des sauvegardes ce qui est plutôt nécessaire : ma tâche de sauvegarde représente environ 400Go et je fais 2 images par jour depuis 2010 ... je vous laisse faire le calcul, résultat : 700Go utilisé sur mon disque ! et je peux toujours avoir accès à mes fichiers tels qu'ils étaient en 2010 (où il ne reste plus qu'une image tous les 10 jours grâce à SmartRecycle). Conclusion J'espère vous avoir donné assez d'information pour vous faire une bonne idée de l'utilisation de TimeBackup. Je pense que si on veut obtenir une sauvegarde aussi complète que TimeMachine, il faut utiliser "Sauvegarder et Restaurer" pour la configuration et les applications; et en parallèle TimeBackup pour les données. Après chacun à des besoins différents, donc en fonction de ce qu'on veut comme sauvegarde l'un où l'autre peut être suffisant, mais moi j'ai choisi d'utiliser les 2 de façon complémentaire sur un disque externe eSata que je prends avec moi pendant les congés (au cas ou). J'utilise aussi une sauvegarde distante via lftp (http://www.cobestran.com/actualite/synology-sauvegarde-site-web-par-ftp-avec-lftp/) chez mon hébergeur qui ne propose pas rsync, mais c'est une autre histoire que je détaillerais quand j'aurais plus de temps.

J'ai eu le même soucis au boulot car deux proxy et quand je switch de proxy l'IP extérieur n'est plus la même. J'ai corrigé le soucis en allant dans panneau de configuration -> paramètres de DSM -> onglet sécurité, et j'ai coché "Améliore la compatiblité du navigateur en ignorant la vérification de l'IP"

Bonjour a tous pour information j'ai réussi a migrer mon DS1010+ sous DSM 6.2 très facilement grâce a ce post du coup la traduction : installer le dernier DSM sur le DS1010+ (5.2) Activer le SSH se connecter en SSH au système en tant que root vi /etc.defaults/synoinfo.conf i pour entrer en mode insert Changer unique="synology_x86_1010+" en unique="synology_x86_1511+" Faire esc pour sortir du mode insert :wq pour sauvegarder et quiter Updater le bootloader (Voir en dessous) - Sinon vous allez tomber sur l'assitant d'installation vous disant que vous migrer d'un DS1010+ vers un DS1010+ Reboot du DS1010+ et l'assisant vous dis que vous migrer les disques d'un DS1010+ vers un DS1511+ J'ai laissé l'assistant installer directement la dernière version de DSM (6.2.4-25556 update 2) et tout fonctionne sans problèmes même si je n'utilise ce nas que pour synchroniser mon nas principal Pour la partie sensible l'upgrade du bootloader , il faut commencer par le sauvegarder toujour en ssh en tant que root dd if=/dev/synoboot of=/volume1/synoboot.img Sauvegarder le fichier /volume1/synoboot.img sur une autres machine , vous en aurez besoin en cas d'erreur apres monter le synoboot ( pour un raison bizarre il faut rentrer dans /dev pour pouvoir le faire) mkdir /mnt/boot cd /dev mount synoboot1 /mnt/boot vi /mnt/boot/boot/grub/grub.conf Éditer grub.conf et ajouter le bon hw_model et syno_hw_version et surtout ajouter les 2 # serial --unit=0 --speed=115200 terminal serial default 1 timeout 3 hiddenmenu fallback 0 title SYNOLOGY_1 root (hd0,0) hw_model=DS1511+ kernel /zImage root=/dev/ram0 ihd_num=0 netif_num=1 syno_hw_version=DS1511+ initrd /rd.gz title SYNOLOGY_2 root (hd0,1) # cksum /grub_cksum.syno vender /vender show # hw_model kernel /zImage root=/dev/md0 ihd_num=0 netif_num=1 syno_hw_version=DS1511+ initrd /rd.gz sauvegarder et démonter umount /mnt/boot