Aller au contenu

Classement

Contenu populaire

Affichage du contenu avec la meilleure réputation depuis le 08/01/20 dans toutes les zones

  1. 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
    11 points
  2. 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 ….
    11 points
  3. 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 !
    8 points
  4. 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
    7 points
  5. 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.
    7 points
  6. 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 🙂.
    6 points
  7. 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 🙂
    5 points
  8. 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 🙂
    5 points
  9. 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
    4 points
  10. 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😉
    4 points
  11. 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:
    4 points
  12. 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
    4 points
  13. @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
    4 points
  14. 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
    4 points
  15. 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 :
    4 points
  16. 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.
    4 points
  17. 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 🙂
    4 points
  18. 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/
    4 points
  19. Ç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.
    4 points
  20. 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😉
    4 points
  21. 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).
    3 points
  22. 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
    3 points
  23. Bonsoir, DSM 7.2.1-69057 Update 4 est disponible. Version : 7.2.1-69057 Mise à jour 4 (2024-01-16) Notes IMPORTANTES 1 - Votre NAS Synology peut ne pas vous informer de cette mise à jour de DSM. Si vous souhaitez mettre à jour votre DSM vers cette version maintenant, veuillez cliquer ici pour le mettre à jour manuellement. ° Votre DSM fonctionne correctement sans avoir à le mettre à jour. Le système évalue les statuts des services et les paramètres du système pour déterminer s'il doit être mis à jour vers cette version. 2 - En fonction de votre modèle de NAS Synology, cette mise à jour redémarrera l'appareil. Problèmes résolus: 1 - Correction d'un problème où Cloud Sync et Drive ShareSync ne pouvaient pas fonctionner correctement lorsqu'Active Insight était exécuté sur Synology NAS. 2 - Correction de plusieurs vulnérabilités de sécurité Remarques : Cette version est publiée lors d'un déploiement par étapes. https://www.synology.com/fr-fr/releaseNote/DSM https://archive.synology.com/download/Os/DSM/7.2.1-69057-4 Installé sur DS718+ : RAS
    3 points
  24. Bonjour, Juste pour évoquer mes constats et retours d'expérience : L'application Synology Photos est très gourmande en RAM, notamment lorsque l'on y accède depuis un navigateur web avec des images larges à afficher. Avec une mémoire RAM insuffisante de l'ordre de 1 ou 2 Gb, le NAS risque de devenir très très lent, je pense sur beaucoup de modèles. C'est d'ailleurs un avertissement qu'avait fait Synology au moment de passer vers DSM7 et Synology Photos (versus les versions précédentes de DSM avec uniquement DS Photo ou Moments : la différence en besoin de ressources avec DSM7 et Synology Photos est sensible). Pourquoi ? Je pense en partie car contrairement aux fichiers standards (documents textes, tableurs, pdf, etc...) que l'on peut faire défiler dans File Station sans affichage complexe, les photos nécessitent pour être affichées d'avoir leurs miniatures en mémoire. Avec 1 ou 2Gb de RAM, le NAS est en permanence en train de décharger des fichiers en cache pour les remplacer par des miniatures - ou pire des photos - à afficher. Cela ralentit considérablement le système. A mon sens : la solution indispensable quand on veut faire un usage fluide de Synology Photos, c'est d'augmenter la RAM à 6 ou 8Gb (fonction de son NAS). 🎛 ➡️ Sur mon vieux DS216+ v1 avec 1Gb de RAM initiale, DSM 7 et Synology Photos étaient tellement lents qu'ils étaient inutilisables. ➡️ J'ai remplacé la barrette de RAM par une de 8GB : résultat j'ai un avion de chasse ! ✈️ Mon vieux DS216+ + 8GB de RAM est ultra-rapide ! Toutes les miniatures et photos s'affichent de façon quasi instantanée, et j'ai également noté un gain très sensible de rapidité avec les autres applis, ou ne serait-ce que pour consulter des fichiers avec File Station à distance ou en connexion locale SMB, qui ont énormément gagné en fluidité aussi. Nota : J'ai plus de 50 000 Photos (1To), dont plusieurs milliers au format RAW 24MP (=6K) assez lourd, et bien sûr des jpeg. Bref. Que ce soit pour nos NAS existants ou pour l'achat des prochains, je crois que l'ajout de RAM est souvent sous-estimé. En tout cas pour Synology Photos. Dans mon cas : une barrette de RAM à 35€ m'a changé la vie, et m'a évité d'avoir à remplacer un DS216+ qui tourne comme une horloge depuis 8 ans désormais. A+++++
    3 points
  25. Pour une raison obscure, Synology a récemment retiré des archives les anciennes versions de DSM, SRM et des applis. Si vous avez besoin des versions retirées, vous pouvez les retrouver sur ce site d'archivage (dernier snapshot du 31/05/2023) : https://web.archive.org/web/20230531230549/https://archive.synology.com/download
    3 points
  26. @firlin, @.Shad., @PiwiLAbruti J'ai déplacé la question de firlin sur le ping dans un autre sujet car il n'avait pas de rapport avec la sécurisation des NAS
    3 points
  27. Avec la source et quelques commentaires, ça aurait été mieux qu'un copier/coller. Comme pour DSM 7.2, cette version ne sera pas proposée en mise à jour automatique pour les NAS des séries '18 et antérieures. Il faudra donc la télécharger et l'installer manuellement pour pouvoir en bénéficier. Il est recommandé de l'installer car elle contient 4 corrections de vulnérabilités (CVE). Source : https://www.synology.com/fr-fr/releaseNote/DSM#7_2
    3 points
  28. Après le classement des meilleurs déterrages, on va lancer celui des présentations les plus courtes.
    3 points
  29. Re-bonjour a tousss, J'ai pris un peu de temps pour faire un test de performance sur mon 220+ - proc : Intel Celeron J4025 , 2-core 2.0 (base) / 2.9 (burst) GHz - Moteur de cryptage matériel (AES-NI) - RAM : 2 Go RAM - 2 DD WD Red de 3 To en RAID 1 J'ai créer 2 Volumes : - Vol_1 : 50 Go non-crypté Avec un dossier non crypté Avec un dossier crypté - Vol 2 : 50 Go crypté Avec un dossier non crypté Avec un dossier crypté J'ai mis sur mon pc un ensemble de fichier (42Go) : 2 * 15 Go 2 * 4.5 Go 13 * 400 Mo 83 * 5.8 Mo Voici les temps : 1) PC -> Syno Volume non crypté, Dossier non crypté : 434 secondes (limité par le Gibagit) 2) PC -> Syno Volume non crypté, Dossier crypté : 515 secondes 3) PC -> Syno Volume crypté, Dossier non crypté : 444 secondes 4) PC -> Syno Volume crypté, Dossier crypté : 696 secondes Ma conclusion 'rapide' : Sur un DS220+, un Dosier non-crypté sur un Volume crypté (DSM 7.2) est 15% + rapide qu'un Dossier crypté sur un Vomule non-crypté (ancien DSM). Je suis loin des 48% annoncé par Synology (en moyenne ?!?). Mais mon DS220+ est peut-être "trop" puissant avec une utilisation avec du DD "rotatif" et du Gigabit... Si je peux, je ferai un test avec un SSD dans le Syno (Volume en Basic), et un SSD en USB pour faire les copy. J'espère que je ne serais limité que par la CPU (et puissance de cryptage)... J'ai plus de vieux Syno supportant le DSM 7.2 (même mon DS114 est trop vieux). Stay tuned !!
    3 points
  30. Mise à jour ok sur 218+, et sur 918+. Particularité : le 918+ a deux nvme transformés en volume raid1 (et non en cache) qui sont toujours là.
    3 points
  31. 1. Préambule Ce tutoriel a pour but d'autoriser l'accès aux données du NAS via le protocole SMBv1 (ou NT1) sans pour autant impacter le niveau de sécurité d'accès au NAS. Cela permet d'assurer la compatibilité d'équipement qui n'auraient pas été mis à jour par leur fabricant. SMBv1 est un protocole déprécié et comportant des failles de sécurité. Lorsqu'il est possible de vous en passer, faites-le. 2. Prérequis Avoir un NAS compatible Docker, voir la liste ici. Savoir se connecter au NAS via SSH en root : Utiliser Docker-compose Avoir installé le paquet SynoCLI File Tools, pour ajouter le dépôt SynoCommunity voir la partie Easy Install sur cette page. IMPORTANT : Si vous souhaitez accéder aux dossiers partagés "music", "video", etc... à la racine tels quels, ça ne pourra pas fonctionner, il faudra monter des sous-dossiers de ces dossiers partagés. Autant prévenir de suite. 3. Principe Afin de ne pas devoir réduire drastiquement le niveau de sécurité du NAS en autorisant le protocole SMBv1, on va passer par un conteneur qui va monter uniquement les fichiers du NAS dont on a besoin, et qui lui, autorisera l'accès en SMBv1. Comme le NAS utilise déjà le port 445 pour parler SMB avec les autres périphériques du réseau, il n'est pas disponible, on va donc utiliser un réseau macvlan (voir point 11-A de mon tutoriel introductif à Docker). Ce réseau permet entre autre d'attribuer au conteneur une IP située sur le même sous-réseau que votre réseau local. En somme, il devient accessible comme n'importe quelle autre machine, avec une IP par exemple du 192.168.0.x. Comme il est fréquent de faire avec des machines virtuelles. Cela permet notamment d'utiliser des ports déjà utilisés sur le NAS, et facilite la détection par les autres appareils, car visible directement par tout le réseau. 4. Mise en place du réseau macvlan Je ne détaille pas cette étape, car elle est décrite avec précision au point 11-A-1 du tutoriel introductif. A noter dans ce tutoriel précis qu'il n'est pas nécessaire de mettre en application le point 11-A-2 qui s'attarde sur la création d'une interface virtuelle pour communiquer entre le NAS et le conteneur. Si vous avez déjà un réseau macvlan disponible, assurez-vous simplement de disposer d'une IP libre dans la plage utilisée. Et adaptez les hypothèses suivantes. 5. Hypothèses Je vais me baser sur la plage et le sous-réseau utilisés dans le tutoriel introductif : IP hôte (NAS) : 192.168.0.100 Passerelle : 192.168.0.1 Sous-réseau local : 192.168.0.0/24 (ou encore écrit 192.168.0.0/255.255.255.0) Plage macvlan : 192.168.0.144/28 (vous pouvez vérifier les IP que ça concerne ici : http://jodies.de/ipcalc) IP conteneur : 192.168.0.145 Les valeurs en orange sont directement héritées de la mise en place du réseau macvlan, et sont simplement répétées par rapport au tutoriel introductif dans un souci de contextualisation. Les valeurs en vert sont propres à votre installation et ce tutoriel. 6. Configuration 6-A. Fichier docker-compose On va créer le fichier docker-compose.yml qui va reprendre toute la configuration de notre conteneur. On va utiliser l'image servercontainers/samba. Elle met à disposition un serveur Samba entièrement configurable, accompagné d'Avahi et WSD pour qu'il s'annonce sur le réseau et le rendre consultable et visible dans Finder (Mac) et l'explorateur Windows. Il faut savoir que cette image a été améliorée suite à des propositions que j'ai faites à son créateur. Elle a été adaptée pour faciliter la compatibilité avec DSM et sa version particulière de Linux. Tout d'abord, on se connecte en SSH en root, puis on crée le dossier qui va contenir la configuration du conteneur mkdir -p /volume1/docker/samba/ && cd $_ mkdir conf On va ensuite créer le fichier docker-compose.yml en utilisant nano (ou le télécharger ici : docker-compose.yml et l'importer dans File Station au bon endroit). nano docker-compose.yml dont voici un modèle : version: '2.1' services: samba-nt1: image: servercontainers/samba container_name: samba-nt1 hostname: samba-nt1 networks: mac0: ipv4_address: 192.168.0.145 environment: ## Groups ## - GROUP_users=100 ## Accounts ## - ACCOUNT_media=motdepassemedia - UID_media=10XX - GROUPS_media=users ## Global variables ## - SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol=NT1 - SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth=ntlmv1-permitted - SAMBA_CONF_MAP_TO_GUEST=Never ## Shares ## - SAMBA_VOLUME_CONFIG_music=[music]; path=/shares/music; guest ok = no; read only = yes; browseable = yes; valid users = media; force group = users volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/docker/samba/conf:/etc/samba restart: unless-stopped networks: mac0: external: true 6-B. Personnalisation des paramètres 6-B-1. Général Dans un fichier docker-compose, il n'y a pas de tabulation, uniquement des espaces, et il est important de respecter l'indentation (l'alignement). Les sauts de lignes ou le nombre d'espaces que vous mettez pour décaler les items n'a en revanche aucun impact, assurez-vous juste que ce soit lisible. hostname : cette variable est importante ici car c'est le nom que vous verrez apparaître dans la découverte de réseau de Windows. Cette chaine de caractères est automatiquement convertie en majuscules sous Windows, évitez les caractères exotiques. ipv4_address : c'est l'adresse IP que j'attribue manuellement au conteneur, c'est la première disponible dans la plage que j'ai choisie pour mon réseau macvlan nommé mac0. GROUP_users : On va définir au sein du conteneur un group "users", celui-ci correspond au groupe auquel appartient naturellement votre/vos utilisateur(s) du NAS. On lui donne la valeur de 100 car c'est le gid du groupe users sur DSM également. Si pour une raison ou un autre vous utilisez un groupe personnalisé, vous devez déterminer le GID affilié à ce groupe. Pour cela, tapez en SSH : cat /etc/group | grep nom_du_groupe Il faudra utiliser le nombre à la fin de la ligne en sortie de commande. ACCOUNT_media, UID_media et GROUPS_media : Voir paragraphe 6-B-3. SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol : En lui donnant une valeur NT1 on autorise SMBv1 comme protocole minimal, depuis Samba 4.x le protocole minimal est SMB2. NT1 est le nom officiel de SMBv1. SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth : Il faut également autoriser l'authentification NT1. SAMBA_CONF_MAP_TO_GUEST : On ne souhaite pas que les utilisateurs soient automatiquement redirigés sur guest en cas de mauvais nom d'utilisateur ou de mot de passe. Donc on désactive la directive. SAMBA_VOLUME_CONFIG_music : voir 6-B-4. volumes : voir 6-B-2. restart: unless-stopped : Le conteneur redémarre quand il s'arrête suite à une erreur, si le service Docker ou le NAS redémarrent. Sauf si on l'a arrêté manuellement. networks : Je dois définir la nature du réseau mac0 invoqué plus haut pour le paramètre ipv4_address. Il a été créé extérieurement au conteneur, ce que je précise par le paramètre external: true. 6-B-2. Volumes Pour revenir au point abordé dans les pré-requis, et sans rentrer dans les détails, l'utilisation de cette image avec DSM possède quelques limitations : Il n'est pas possible de monter directement un dossier partagé à la racine : par exemple dans mon fichier docker-compose, je monte /volume1/music/bibliotheque et pas /volume1/music dans /shares/music. Cela vient des permissions UNIX qui sont inexistantes au niveau des dossiers partagés du point de vue de l'utilisateur root, c'est la surcouche d'ACL qui gère les permissions. Par conséquent, les permissions UNIX doivent être suffisantes pour garantir un fonctionnement adéquat. Prenons un exemple : ls -l /volume1/music Les permissions UNIX pour le dossier "bibliotheque" par exemple sont définies par les caractères qui se situent à gauche du "+" : drwxr-xr-x. Cas d'utilisation : Pour traverser les dossiers et lire en lecture seule avec un utilisateur authentifié, il faut a minima : dr-x------ pour un dossier (-r-x------ pour un fichier). Pour traverser les dossiers et lire/écrire avec un utilisateur authentifié, il faut a minima : drwx------ pour un dossier (-rwx------ pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire en lecture seule avec un utilisateur guest (non authentifié), il faut a minima : d------r-x pour un dossier (-------r-x pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire/écrire avec un utilisateur guest (non authentifié), il faut a minima : d------rwx pour un dossier (-------rwx pour un fichier). Je ne recommande pas les deux derniers cas d'utilisation, car SMBv1 est un protocole déprécié et ayant des failles de sécurité. Or SMB de manière générale est sûrement le moyen le plus simple d'infecter un NAS. Néanmoins, cela peut avoir son utilité par exemple pour des imprimantes d'ancienne génération, qui stocke des éléments scannés dans un répertoire du NAS via SMBv1. L'utilisation d'un guest doit rester exceptionnelle. NOTE : Avoir d------rwx n'implique pas qu'un guest aura forcément accès aux données du partage, on peut tout à fait désactiver l'accès guest par la configuration du partage (voir point 6-B-4), limiter l'accès à certains partages à certains utilisateurs uniquement, etc... c'est simplement une condition nécessaire, mais non suffisante. En revanche, si vous n'avez pas ces permissions a minima, activer le guest n'aura aucun effet. Voilà un type de montage qu'on pourrait vouloir faire : volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/video/films:/shares/films - /volume1/video/series:/shares/series - /volume1/famille/documents:/shares/documents On doit aussi s'assurer d'avoir monté le dossier dans lequel se trouvera le fichier de configuration smb.conf créé par le conteneur lors de sa mise en route : - /volume1/docker/samba/conf:/etc/samba 6-B-3. Utilisateur Pour faciliter le bon fonctionnement du conteneur, il est recommandé de créer des utilisateurs dont le nom existe déjà dans DSM. Dans mon cas, j'ai un utilisateur media qui est propriétaire de tous les fichiers multimédias (musique et vidéo). ls -l /volume1/music/bibliotheque Au sein d'un même partage (par exemple le contenu musical), il est recommandé qu'un seul et même utilisateur soit propriétaire de tous les fichiers. Ca ne changera rien dans DSM car le système a sa propre couche d'ACL qui détermine les permissions de chacun, et ça facilitera l'exploitation du conteneur. Pour unifier le propriétaire d'un ensemble de fichiers et dossiers, c'est très simple, on va dans File Station, on sélectionne les éléments dont on souhaite changer la propriété, clic droit, Propriétés. En bas de la fenêtre, on choisit le propriétaire. Si on a sélectionné un dossier, on peut cocher la case "Appliquer à ce dossier, ses sous-dossiers et ses fichiers" pour que les enfants héritent du même propriétaire. NOTE : Si vous sélectionnez à la fois des dossiers et des fichiers, il se peut que le cadre Propriétaire n'apparaisse pas. Limitez votre sélection et ça marchera. Je vais donc créer un utilisateur media dans le conteneur via la variable d'environnement : ACCOUNT_media. La valeur de cette variable est le mot de passe pour l'utilisateur media dans ce conteneur. NOTE : Ce mot de passe ne doit pas être le même que celui pour l'utilisateur media du NAS ! En effet, le conteneur aura ses propres accès. La documentation de cette image permet de chiffrer ce mot de passe, pour ma part je n'en vois pas l'intérêt. Car pour accéder à ce fichier, l'utilisateur doit déjà avoir infecté le NAS. Cacher ses clés dans la maison n'a pas d'intérêt s'il y a déjà effraction. Concernant la variable UID_media, il s'agit de l'ID de l'utilisateur. Il est pratique d'utiliser le même UID que celui de l'utilisateur du NAS. Pour récupérer cet UID, il suffit de taper en SSH : id media Dans mon cas c'est 1035, dans tous les cas c'est strictement supérieur à 1025. Enfin, pour GROUPS_media, on lui donne la valeur users, par défaut l'utilisateur appartient à un groupe identique à son nom d'utilisateur. Pour DSM, le groupe users est le groupe par défaut pour les utilisateurs. On s'assure une meilleure compatibilité avec les ACL. Au final, en configurant ces trois variables, on assure la création d'un utilisateur qui pourra se servir des droits utilisateurs accordés par les permissions UNIX et ne fâchera pas les ACL de DSM. REMARQUE : Il est tout à fait possible de créer plusieurs utilisateurs, par exemple si vous décidez de monter l'espace personnel d'un utilisateur du NAS, ou simplement parce que tous les fichiers de vos partages n'appartiennent pas à un seul et même utilisateur. Exemple : - ACCOUNT_media=motdepassemedia - UID_media=1035 - GROUPS_media=users - ACCOUNT_lolita=motdepasselolita - UID_lolita=1031 - GROUPS_lolita=users 6-B-4. Configuration des partages La configuration des partages se fait via la variable d'environnement SAMBA_VOLUME_CONFIG_music (pour un partage qui se nommerait "music"). La valeur associée peut paraître étrange avec ses points virgule, mais ça représente juste un saut de ligne dans ce qui correspond habituellement à la configuration d'un partage SMB. Voyons plus en détail : path=/shares/music : correspond à l'emplacement qu'on a indiqué dans le montage de volume, c'est le chemin DANS le conteneur. [music] : c'est le nom du partage tel que vous le verrez dans votre explorateur. Vous pouvez utiliser des majuscules et des espaces ici. guest ok : prend la valeur "yes" ou "no", dans le premier cas lorsque vous vous connecterez aucun mot de passe ne vous sera demandé. Valeur recommandée : no. read only : est assez explicite, prend la valeur "yes" ou "no". En SMBv1, préférez la lecture seule. browseable : permet de voir apparaître le partage dans les onglets de découverte du réseau. valid users : permet de définir quel(s) utilisateur(s) sont autorisés à accéder au partage. Pour ajouter plusieurs utilisateurs, les séparer par une virgule. Si tous les utilisateurs peuvent accéder au partage, il n'est pas nécessaire d'utiliser cette directive. force group : Par défaut, ce sera l'utilisateur media/media qui écrira quand on est connecté avec cet utilisateur, on souhaite que le groupe par défaut soit users, d'où la valeur forcée à "users" pour ce paramètre. Autres directives majeures disponibles : comment : permet de décrire notre partage, majuscules autorisées. directory mask : permet de définir quelles seront les permissions UNIX par défaut lors de la création d'un dossier. Exemple : create directory mask = 0755 => les dossiers auront les permissions suivantes : drwxr-xr-x. Voir la page Wikipédia (Fonctionnement - Représentation des droits) pour plus d'information : https://fr.wikipedia.org/wiki/Permissions_UNIX create mask : même chose pour un fichier. guest only : nécessite d'avoir réglé guest ok sur "yes" au préalable. Accès guest seulement (pas d'authentification). Il existe énormément de paramètres configurables pour un partage SMB, voir la liste ici : https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html Tout est maintenant configuré. On n'a plus qu'à sauvegarder le fichier docker-compose (sous nano, CTRL+O puis Entrée pour sauvegarder, CTRL+X pour sortir de l'éditeur). 7. Création du conteneur Pour créer le conteneur, on vérifie qu'on se trouve toujours dans /volume1/docker/samba et on tape : docker-compose pull Ce qui va télécharger la dernière version de l'image. Puis : docker-compose up -d Si pas d'erreur à la création (souvent dues à des caractères de tabulation, une directive dans le fichier docker-compose mal orthographiée ou désalignée, etc...), vous verrez un petit done apparaître en vert. Si browseable a été activé, on voit le partage dans la découverte réseau : Tous les autres moyens habituels pour accéder à un partage SMB sont actifs (connecter un lecteur lecteur réseau, smb:// via Finder, etc...). MàJ : 13/01/2022
    3 points
  32. Bonjour, avant de jeter je tente tout ce qui me vient à l'idée. Le DS212+ bip un matin car le HDD2 est "mourrant". (26 secteurs défectueux) C'est un WD RED NAs de 6To. Il est de décembre 2016 avec 47690 heures au compteur. Le DS212+ est monté en RAID0, il ne sert plus qu'aux sauvegardes. Il fonctionne H24. Je sors le HDD2 et je tente de le formater sur mon PC => impossible car le disque est "locked" ! Je ne peux plus l'utiliser. Je tente un smart => impossible Je passe l'utilitaire de WD => impossible J'essaye tout ce qui me vient à l'esprit: formatage bas niveau, badblocks, table de partition GPT, MSDOS, etc... Rien à faire c'est bloqué. Et... au fil de mes lectures je tombe sur la solution: DSM verrouille le disque avec un mot de passe lorsqu'il est jugé défaillant (conclusion personnelle) afin de ne plus l'utiliser. pour déverrouiller j'ai fait: hdparm --security-disable synology /dev/sdX 'synology' c'est le mot de passe qui débloque le HDD. Ensuite j'ai pu passer la commande qui va bien :=) dd if=/dev/zero of=/dev/sdx bs=4K status=progress depuis mon pc pour remplir le disque de zéros et faire un badblocks avec ZÉRO ERREURS ! Le disque est retourné dans le NAS, il est accepté et ne contient plus l'information des secteurs défectueux. Je ne sais pas combien de temps ça va durer mais là c'est OK. (je regrette simplement d'avoir acheté un disque de remplacement avant de trouver la solution et j'espère qu'à la réception ce sera un HDD avec la technologie CMR comme indiqué sur sa fiche...) Merci d'avoir tenu le coup jusqu'au bout 🙂 Bon dimanche.
    3 points
  33. Je n'ai toujours pas réussi à faire fonctionné les route statique mais j'ai trouvé une solution presque plus simple. Il faut ouvrir le fichier .ovpn fourni par votre VPN, et rajouté dedans : # PLEX over WAN route route plex.tv 255.255.255.255 192.168.1.1 Grace à ça, j'ai bien download station qui passe par le VPN mais plus Plex, j'ai donc récupéré l'accès à distance !
    3 points
  34. fc00::/7 est l'équivalent IPv6 de 10/8, 172.16/12 et 192.168/16, donc dédié aux réseaux privés non-routables sur internet. C'est un préfixe que tu ne rencontreras probablement jamais étant donné qu'il est utilisé dans des configurations professionnelles/spécifiques. Tu peux donc retirer la règle qui l'utilise. Pour information fe80::/10 est l'équivalent de 169.254/16 (adresses automatiques non routable).
    3 points
  35. Bonjour, Petit retour, la MAJ depuis la version 1.2.5-8227 Update 5 > 1.3.1-9316 c'est bien passée, avec un RT2600ac et 2*MR2200ac en ethernet 👍 Attention pour les RT2600ac, le mode "répéteur sans fil" est supprimé, donc si vous souhaitez utiliser ce mode il faudra rester sous SRM 1.2.x: Les clés USB 3G-4G sont toujours supportées: Sinon toujours pas de DoH si on utilise le serveur DNS. Nouveauté de SRM 1.3.1 La page de connexion reprend celle de DSM7 (mais on ne peut toujours pas enregistrer son navigateur pour la double authentification, comme avec DSM6 ou 7) Pour les nouveautés de SRM 1.3 le pare-feu fonctionne aussi pour les LAN: Le SSH ce comporte maintenant comme avec DSM 6 et 7, il faut d'abord ce connecter avec un utilisateur "administrateur" puis passer en root avec la commande "sudo -i", on ne peut plus ce connecté directement en root.
    3 points
  36. Après quelques tests rapides, il s'avère que la Livebox vérifie l'en-tête Host. En passant par un reverse proxy, la valeur de cet en-tête est le nom d'hôte affecté au reverse proxy (livebox.domain.tld par exemple). Hors, la Livebox n'accepte que son adresse IP comme valeur valide (192.168.1.1 par défaut, à adapter si votre réseau a un adressage différent). Donc j'ai forcé la valeur de cet en-tête à 192.168.1.1 dans l'onglet [En-tête personnalisé] du reverse proxy, et ça passe : 🥳 À tester avec ton matériel réseau @Finnithnel
    3 points
  37. https://www.facebook.com/synology/photos/a.274672852896/10158594756417897/
    3 points
  38. Bonjour, J'ai suivi vos recommandations. J'ai ajouté 8Go de ram à mon DS220+ Crucial CT8G4SFS8266 DDR4, 2666 MT/s, PC4-21300, Single Rank x8, SODIMM, 260-Pin Acheté sur Amazon 47€ Et ça fonctionne 😊
    3 points
  39. 3 points
  40. Bonjour, En complémentant de la discutions suivante : Et comme je regarde plus ou moins le prix des Boitiers USB, pour récupérer les disques dur dedans (en effet sur les disques de grande taille il est plus simple de les acheter dans un boitier usb ( je que j'ai fait pas 3 fois déjà avec des capacité différentes). Je suis tombé sur un site très bien fait sur les disques SMR et CMR Seagate Toshiba Western Digital Ensuite pour ceux qui vaudrai faire comme moi acheter un boitier usb pour récupérer le ou les disques voici des infos utiles. Boitier Seagate Boitier Western digital Comment démonter le disque d'un boitier WD, existe la même vidéo pour les boitiers Seagate (Google est ton amis) On peut trouver ces infos sur les sites suivant : satdream.tech et sur dealabs
    3 points
  41. Ne voulant pas traîner pour le remettre en service, je suis allé acheter une CR1220 puis direction chez mon père. Il avait une résistance de 330Ω en stock. Quitte à désosser le NAS, on l'a soudé sans attendre. L'ancienne pile avait une tension de 3,1V donc a priori elle n'était pas en cause. Le résultat ne s'est pas fait attendre : c'est reparti comme en 14 ! Reste à voir dans la durée. En tout cas merci à tous les intervenants sur le sujet qui permettent à chacun de de remédier à une bien triste obsolescence.
    3 points
  42. Bon, j'ai trouvé 😍 Aller dans "Panneau de configuration" Cliquer sur le dossier que vous voulez partager avec plex. Faire un clique droit et choisir "Modifier" Cliquer sur "Permission" En haut à gauche, la ou il est marquer utilisateur locaux, cliquer Choisir "Utilisateur du système interne" Rechercher dans la liste PlexMediaServer et lui donner les droits 🥰 Enjoy
    3 points
  43. Hello à tous 🙂 J'espère que je suis au bon endroit, mais je voulais partager un peu mon expérience. Comme je le disais dans ma présentation, je ne suis pas quelqu'un qui comprennent le réseau, mais je voulais absolument un NAS pour différentes raisons. Grâce à ce forum, j'ai pu m'engager dans cette voie en toute sécurité. Vérification des disques, sécurité, VPN, Reverse proxy, Antipub sont les premiers tuto que j'ai mis en place. J'ai eu quelques blocages, voir quelques incompréhensions mais j'ai toujours trouvé de l'aide (ou j'ai juste bien relu le tuto 😅). Mon seul échec est le Tuto DNS, je me rends compte du coup de ma limite. Mon prochain objectif, le tuto de MailPlus, car j'aimerai créer des boîtes mails pour ma famille. Par ailleurs, j'ai fait de la virtualisation, j'avais besoin d'une VM windows. J'ai pris la décision de changer de NAS, j'ai pris le 920+ et rendu le 420+. La migration c'est faite sans problème, j'ai juste dû modifier 2/3 endroits où l'adresse IP était écrit en dur. Voilà, je ne sais pas si ça se fait (j'avoue, je n'ai pas regardé), mais je voulais donner mon retour d'expérience quant à tout ce qui se trouve sur le forum.
    3 points
  44. Attention, car il y a eu un scandale l'année dernière à ce sujet : https://www.macg.co/materiel/2020/09/western-digital-reinvente-la-definition-de-tours-par-minute-pour-ses-disques-durs
    3 points
  45. Un grand merci à vous tous, vous êtes très serviable. Ça fait plaisir une communauté comme ça et pour votre peine, je vous offre une image que j'ai prise avec mon télescope il y a quelques semaine, c'est une nébuleuse, celle de la rosette, 2h30 de poses
    3 points
  46. Salut ! Comme dit plus haut, regarder uniquement le % de requêtes bloquées n'a pas de sens. Il faut regarder tes usages, les sites fréquentés, la composition de ton reseau local (périphériques, PC, smartphones/tablettes, objets connectés...), ta connexion internet et ton opérateur. Ce qui importe c'est l'efficacité des filtres, la presence de pubs/popups ou pas quand tu surfes, etc. De mon côté, avec quelques mois de recul, je n'ai pas de pub avec les filtres suivants :
    3 points
  47. Hello à tous, Bon, petite évolution, j'ai réussi à configurer OpenVPN, et je me connecte correctement depuis mon mac et mon iphone. Donc, on peut dire que le problème est résolu sans doute. Merci encore à tous pour votre aide.
    3 points
  48. Parce que chez toi, de ce que j'en déduis, c'est que NAS1 correspond à la page de login de NAS1, pareil pour NAS2 et NAS3. Donc là tu fais appel au backend, une application, en l'occurrence le bureau de DSM. Ca n'a rien à voir avec l'adresse, composé du nom d'hôte et du nom de domaine, que tu donnes à ton NAS. Exemple : nas1.ndd.tld. A 192.168.1.1 nas2.ndd.tld. A 192.168.1.2 nas3.ndd.tld. A 192.168.1.3 dsm-nas1.ndd.tld. CNAME nas1.ndd.tld. # pointe vers le proxy inverse dsm-nas2.ndd.tld. CNAME nas1.ndd.tld. dsm-nas3.ndd.tld. CNAME nas1.ndd.tld. audio-nas2.ndd.tld. CNAME nas1.ndd.tld. ... C'est plus clair ainsi, on fait bien la différence entre les adresses liées à des équipements, et celles liées à des services. Ainsi chaque entrée correspondant à un service pointe vers le frontend, le proxy inverse, qui renvoie vers le backend correspondant à l'adresse demandée et pour laquelle il est configuré pour répondre.
    3 points
  49. 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
    3 points
  50. 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
    3 points
Ce classement est défini par rapport à Bruxelles/GMT+01:00
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.