Classement

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

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

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

Normal je ne sais pas, mais je ne suis pas surpris.

Voilà, opération terminée... J'ai suivi vos conseils : installation "propre" de mon 723 avec les anciens DD de mon 716 et idem pour ce dernier avec 2 DD WD de 500 gb non utilisés Effectivement avec Putty j'ai pu constater une plus grande taille des partitions système Restauration des données et des paramètres sur les 2 nas avec la sauvegarde .dss et adapations suivant chaque machine (nom, ip, etc..) Encore merci pour vos interventions et conseils 😃

Bonjour, J'ai remarqué que parfois, les téléchargements sont long à se lancer. Une fois lancés, ils sont rapides, mais le démarrage est long alors qu'en téléchargement direct, c'est immédiat. Auriez vous une explication à cette bizarrerie ? Merci

Bonjour @Maximus Avec putty : sudo df -h La seule solution c'est de tout réinstaller. 1/Bien sauvegarder toutes ses données, sur deux supports c'est mieux. 2/Réinitialiser le NAS en mode 2 (reset). https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS ou pour version de DSM 6.2.4 ou plus récente : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7 3/Réinstaller DSM 7.2 ou plus récent. Et vérifier la taille de la partition système md0 4/réinstaller les données à l'aide de la sauvegarde.

Parano on On peut toujours tout bloquer et la meilleure des défenses c'est de ne pas connecter le NAS vers l'extérieur. Ca limite pas mal les risques d'intrusion. Parano off Comme l'a dit @StéphanH, rares sont les ip publiques fixes. Seuls Free à ma connaissance donne des IP fixes à ses clients. Les autres les accordent parfois, moyennant quelques Euros et ce n'est pas valable pour tous les contrats. Par ailleurs, il est rare que des clients se connectent à partir d'un point unique. Les smart et tablettes, appareils nomades par excellence, peuvent aussi se connecter et ils auront forcément des ip différentes. Si vous voulez vous amuser à donner des droits à chaque ip à partir de laquelle vos clients se connectent, libre à vous, mais vous allez vite vous rendre compte que c'est ingérable. Il est bien sûr important de filtrer les IP et bloquer les zones géographiques est déjà une bonne approche, mais vous ne pouvez pas bloquer toutes les ip de la terre sans que vous ne vous retrouviez pas bloqué un jour ou l'autre. Ce qui est infiniment plus important c'est de mettre en place des règles de blocage qui interdiront automatiquement les IP dont les tentatives de connexion ont échoué. Certes, il y en aura qui voudront se connecter, mais il seront bloqués au bout de x tentatives. Tout ceci est expliqué et commenté dans le tuto sur la sécurisation. En clair, il faut être conscient que si vous ouvrez des accès au NAS, vous donnez des opportunités pour des tentatives d'intrusions. Le tout est de bloquer ces tentatives pour qu'elles n'aillent pas plus loin en bloquant les IP concernées. Et comme je l'ai dit plus haut, ça n'a rien à voir avec le mode de connexion (quickconnect ou Ip ou ndd). C'est à vous de soigner votre protection avec tout d'abord des mots de passe forts (c'est la première protection), un parefeu bien paramétré mais pas trop restrictif, et des règles de blocage plus ou moins sévères selon ce que vous souhaitez en terme de contrôle d'accès. Je ne vous conseille pas toutefois d'établir des règles qui bloquent à la première tentative échouée sinon vos clients se feront jeter à la moindre erreur de saisie.

J'étais le premier en France qui à eu son Ugreen NASync DXP480T Plus ! Pour remplacer mon antique DS620slim... Ça va faire un an maintenant. Le monde du silence !

Ca n'a pas de rapport. Le test badblocks permet de vérifier la surfacer du disque. Il est toujours préférable d'effectuer un test des disques, quelles que soient leurs marques, avant de les mettre en production.

Attention à l'erreur d'interprétation. Le RAID n'est absolument pas une sauvegarde. C'est seulement un assemblage de disques qui permet d'assurer la continuité de service en cas de perte d'un disque. C'EST TOUT ! Si vous partez sur un RAID1 (ou plutôt SHR si vous avez fait une installation par défaut) vous pouvez suivre cette procédure qui sera assez longue : faite d'abord des copies d'écran de vos différents paramètres. Ce sera toujours utile au cas ou vous auriez à en reprendre quelques uns. vous déplacez les dossiers partagés du volume 1 vers le volume 2. Ca se fait à partir de DSM, menu dossiers partagés où vous choisissez pour chaque dossier son emplacement. DSM se charge de faire le transfert du dossier et de son contenu. Toutefois cette méthode ne transfère pas les applications. Vous pouvez faire une sauvegarde de certaines des applications avec hyperbackup. A moins qu'il soit possible de choisir aussi l'emplacement des applications et de les transférer sur un autre volume ce que je ne sais pas n'ayant jamais effectué cette opération. A vous de vérifier dans le centre des paquets si c'est faisable. L'idée étant de déplacer un maximum de données et d'application du volume 1 vers le 2. lorsqu'il n'y a plus de données sur le volume 1 vous le supprimez ainsi que le groupe 1 dans le gestionnaire de stockage si le NAS n'est pas extractible à chaud, vous l'éteignez vous sortez le disque du groupe 1 et vous le remplacez par le nouveau 6 To vous créez un nouveau groupe 1 et volume 1 sur le nouveau disque vous déplacez à nouveau tous vos dossiers partagés, vos applications et vous restaurez vos sauvegardes hyperbackup s'il y en a. A ce stade, vous devriez avoir retrouvé le contenu de votre ancien groupe 1 et la majorité des applications. vous réinstallez les applications qui n'auraient pas été sauvegardées, vous vérifiez vos paramètres par rapport à vos captures. vous transférez vos dossiers partagés du volume 2 vers le 1. (vous pouvez le faire au point 7.) lorsque le volume 2 a été totalement transféré, vous le supprimez, ainsi que le groupe 2. inutile d'arrêter le NAS pour cette opération. Le disque est disponible pour être associé avec le groupe 1 Dans le gestionnaire de stockage, vous faite une augmentation du groupe 1 avec le disque disponible pour créer un RAID1 (ou SHR avec protection des données). Ce processus est assez long (quelques heures). A la fin vous aurez un groupe de 6To en RAID1 ou SHR.

Bonjour non , mon téléphone a sonné ça doit etre ça ::: J' avais aussi une instance docker avec home assistant , je préfére haut la main un raspberry avec un ssd pour bien scinder les appareils du réseau et ne pas trop encombrer le nas

Le firmware de ces disques est géré par Synology. Si tu as des doutes sur les valeurs S.M.A.R.T. des disques, contacte le support Synology depuis le Centre d'assistance inclus dans DSM. S'il y a effectivement une anomalie, ce sera corrigé par une mise à jour automatique du firmware dont tout le monde pourra bénéficier.

Bonjour @Vista1967, La procédure avec WDIDLE3 ne fonctionnaient que pour les disques dur de marque WD. Elle n'est plus d'actualité car le souci a été resolu depuis le temps ( cela date des disques GREEN plus de 10 ans voir 15). Ensuite a toi de voir si tu veux préparer les disques avant de les monter dans le nas. Je n'ai jamais fait de test badblock sur des disques Synology ( en réalité c'est des Toshiba).

@CyberFr et @cadkey, avant que ça dégénère, je vous conseille vivement d'en rester là. Pas de polémiques inutiles. C'est vrai que cette histoire de serveur DNS s'écarte du sujet initial mais comme il en a été question dès le premier message, on peut en parler sans toutefois en faire un sujet dans le sujet. Sinon ça devient confus. @cadkey, si vous avez un souci sur le serveur DNS, mieux vaut ouvrir un sujet dédié, ça fera plus sens. Je réponds toutefois à la dernière question : sur le NAS ou le routeur, peu importe où se situe le serveur. L'essentiel c'est qu'il soit correctement paramétré et surtout qu'il soit donné comme étant le serveur DNS principal sur le LAN. Et rien ne s'oppose à ce que vous utilisiez les deux avec un principal et l'autre secondaire.

Tu te glisses dans une conversation que j'ai initiée, dont le sujet n'a rien à voir avec ta demande et tu la pollues. Il est préférable dans ce cas d'ouvrir un autre fil de discussion. Je ne comprends pas ta démarche vu ton expérience sur le forum. D'autre part, tu disais dans un post du 2 mai dernier, donc tout récent : « Je ne parle pas de DNS Server, je ne l'ai pas. J'ai essayé mais je ne comprends pas, je n'ai pas eu d'amélioration en l'utilisant. J'ai suivi les tutos, en vain... ». Quand on émet des votes négatifs, ce que tu t'es permis de faire à mon égard, on respecte la charte du forum et on tient des propos cohérents. Parce que je comprends que tu ne sois pas enthousiaste à l'idée d'installer DSM Server puisque la citation indique que ta tentative de l'installer fût un échec. Mais ça, tu te gardes bien de le dire.

J'ai de la domotique sur mon NAS, deCONZ en docker et plusieurs scripts pour les Api Legrand, Hue, etc. Ça fonctionne bien.

Certes, mais je n'ai pas vu qu'il devait être accessible de l'extérieur. Bon courage pour la sécurité…

Préparer mon passage chez UGREEN car je ne sais pas s'ils disposent d'un proxy inversé 😀

tout d'abord le serveur dns n'utilise pas le 443 mais le 53. ensuite, la vocation du serveur dns du NAS (s'il est bien paramétré selon le tuto) est de résoudre des ndd locaux sinon ça ne pourrait pas fonctionner, sauf si le routeur est capable de faire du loopback. Le serveur dns local n'intervient pas sur des requêtes externes. Si tu utilises un reverse proxy autre que celui du NAS, il est bien évident que c'est vers celui-ci qu'il faut diriger les requêtes qui arrivent par le 443 pour qu'elles soient orientées vers les services appelés. Peu importe finalement quel équipement assure le reverse proxy, c'est vers lui qu'il faut diriger le 443.

Lorsqu'une URL est entrée dans la barre d'adresse d'un navigateur, ce dernier a d'abord besoin de connaître l'adresse IP de la destination. C'est le rôle du résolveur DNS qui va retourner l'adresse IP vers laquelle pointe le nom de domaine renseigné dans l'URL, et c'est la seule chose qui est demandée au serveur DNS. L'enregistrement DNS correspondant doit donc nécessairement être (ou pointer vers) un enregistrement de type A (IPv4) et/ou AAAA (IPv6), peu importe les alias CNAME utilisés en amont. CNAME calendar.ndd.fr -> A ns.ndd.fr -> adresse IPv4 Le navigateur peut maintenant contacter l'adresse IP retournée par le serveur DNS pour communiquer avec la destination. Jusqu'ici, il n'est toujours pas question du proxy inversé. Le serveur DNS a donc un rôle complètement dissocié. Mais sans lui, impossible de savoir qui contacter. ──────────────────────────────── Une fois connecté à sa destination sur le port tcp/443 (HTTPS), le navigateur va envoyer une requête HTTP dont les en-têtes contiennent un champ Host avec comme valeur le nom de domaine de l'URL (Host: calendar.ndd.fr). C'est la valeur de ce champ qui permet au proxy inversé de diriger le trafic vers la destination finale (calendar.ndd.fr -> localhost:port). N'hésite pas à demander si certains points sont mal expliqués, c'est le b.a.-ba pour comprendre comment ça fonctionne.

Certes mais si on crée un site Web c'est pour qu'il soit accessible de l'extérieur et donc consultable par tout le monde, non ?

Je te conseille de passer par Home Assistant, sur Synology ou autre. Apparemment ton alarme utilise Tuya, et tu as une intégration Tuya dans Home Assistant. Tu as aussi Jeedom comme logiciel domotique, mais c'est en perte de vitesse.

Je ne connais pas ce tuto. Des reverse proxy permettent d'accéder aux applications hébergées sur le NAS par un nom de sous domaines via le port 443. Ça permet donc d'ouvrir un minimum de de port sur l'extérieur et de limiter les risques. Dans mon cas je n'ouvre que le port 443. Mon pare-feu autorise l'accès au port 443 au seules IP FR, règle que je modifie si je rends dans un autre pays et que je veux accéder à mon NAS.

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

Une petite parenthèse juridique. Synology risque d'être confronté au droit européen de la concurrence du fait qu'ils imposent leur marque de disques au détriment d'autres fabricants comme Western Digital ou Seagate. Les juges risquent de ne pas apprécier, d'autant plus que la Commission Européenne est très stricte en matière de respect de la concurrence. La restriction de la compatibilité chez Synology permettrait également à la marque d'augmenter le prix de ses disques à l'avenir s'il n'y a plus de concurrents ce qui, une fois de plus, les exposerait à des jugements antitrust. Et la Commission Européenne ne plaisante pas sur le sujet. À titre d'exemple elle a condamné en novembre 2024 Meta (maison mère de Facebook) à une amende de 800 millions d'euros pour violation des règles antitrust dans l'affaire Facebook Marketplace. Elle a aussi condamné Google à une amende de 2,42 milliards d’euros pour pratique anticoncurrentielle en septembre 2024. Elle a condamné en avril dernier Apple et Meta à respectivement à 500 millions d'euros et 200 millions d'euros d'amende. Synology risque d'être condamné aussi par l'Autorité de la concurrence en France parce que la marque impose une vente subordonnée qui sera alors considérée comme une pratique interdite. Sans compter qu'il pourrait y avoir une condamnation venant des autorités de la concurrence américaine que sont la a Federal Trade Commission et la division antitrust du Department of Justice. Sauf à subir de lourdes amendes et à être attaqué devant les tribunaux par les fabricants de disques concurrents, Synology sera obligé de créer une liste de compatibilité ouverte à d'autres constructeurs et faire disparaître les avertissements et autres limitations qu'ils imposent dans DSM. En attendant ils se comportent comme une PME dépourvue d'avocats. Si on ajoute à cela le mécontentement de leurs clients, on peut dire qu'ils ont créé une situation de crise qui risque de les faire tomber de leur piédestal.

Sauf si, comme je l'ai écrit plus haut, Synology persiste dans sa politique d'abandon progressif des particuliers. Dans ce cas, il va bien falloir se tourner ailleurs. Je suis un utilisateur fidèle de la marque depuis ses débuts. Cependant, si leurs produits ne correspondent plus à mes besoins, je n'hésiterai pas à leur tourner le dos. C'est comme les produits de la pomme. J'ai eu quelques Apple IIe, IIc sur lesquelles on pouvait bidouiller et se faire plaisir. Puis sont arrivés les MAC et consors qui ont enclenché le virage élitiste de la marque et le verrouillage progressif des accès. Beaux produits mais fermés et surtout bien trop chers (l'élitisme à un coût). Depuis, je n'ai plus un seul produit estampillé pomme. Synology est en train de prendre le même chemin.

Bonjour à tous, Comme le veut la coutume je me présente. Gérant d'un bureau d'étude en sécurité incendie, j'ai fêté mes 45 printemps cette année. J'ai eu mon premier PC en 92, et depuis j'ai passé beaucoup (trop?) de temps sur un PC. Je dirais pourtant que mon niveau en informatique est "satisfaisant". Je suis le genre de personne à me passionner pour quelque chose et y passer des heures avant de m'en désintéresser aussi vite que c'est venu, ce qui fait que j'ai des connaissances dans des tas de domaines mais que je ne maitrise rien vraiment. J'ai déjà eu un nas y a une dizaine d'années (un Syno 212j je crois) mais je ne m'en suis pas servi plus que ça. Aujourd'hui j'en ai racheté un (un Syno 224+ avec 2 HDD Seagate BarraCuda 2To) principalement dans une optique de sauvegarde, mais aussi pour m'amuser avec ce qu'on peut faire avec un nas moderne, VM, serveur multimédia, et autres. J'ai commencé à suivre les tutos de démarrage, en commençant par "Débuter avec un NAS Synology.", puis j'ai enchainé avec "Sécurisation du NAS - pour DSM 7", que je viens de terminer. Voilà voilà. J'aurais surement des tas de questions à vous poser, alors merci d'avance à ceux qui prendrons le temps de me répondre 🙂

Bonjour @kiyii Après quelques tâtonnements j'ai réussi une synchronisation entre dossiers de DS218+ dsm7 vers DS212+ dsm6 . J'ai utilisé Cloud Sync sur le DS218+ et Webdav serveur sur le DS212+ Une fois les deux applications installées on crée une tâche de synchro sur Cloud Sync et on choisie Webdav comme fournisseur de cloud. Tu le fais dans ce sens mais on peut choisir la direction de synchro. Attention de lancer la synchro du dossier que l'on veut copier vers un dossier vide; une fois les deux dossiers synchronisés on peut basculer en synchro bidirectionnelle si l'on veut. Pour l'instant il y a un petit bug, pas très gênant, que j'ai décrit ici (le 16/1/2021):

Bonjour J'

On ne peut pas deviner que tu n'as pas les droits nécessaires pour créer les. dossiers et, partant de la, ta question n'a aucun sens ! D'où l'intérêt de passer par le forum PRÉSENTATION pour décrire ton environnement.