Classement

Bonjour, Pour tous ceux d'entre vous qui sont intervenus dans mon post "[TUTO]Création d'un certificat "wilcard" Let'sEncrypt avec la méthode "acme.sh" " : @alan.dub @Jeff777 @.Shad. @CyberFr @GrOoT64 @PPJP @_Megalegomane_ @TuringFan @zerda @oudin @vincentbls @Einsteinium @kerod @Jz84 @jo.p @Pinpon_112 et pour tous les autres membres qui liront ce post, j'ai le plaisir de vous informer que la procédure de renouvellement du certificat "wilcard" Let'sEncrypt est maintenant totalement opérationnelle et efficiente. Grâce aux talents de développement de @bruno78 qui a fourni un remarquable travail et que je remercie encore vivement ici, cette procédure est entièrement automatisée. Oubliés les ports à ouvrir pour le renouvellement ainsi que les problèmes de certificat non réaffecté aux services, plus besoin de getter la date du renouvellement, TOUS les services et packages (avec leurs dépendances) sont maintenant bien relancés après un renouvellement. Je vous invite donc à consulter le TUTO pour prendre connaissance des modifications apportées à la procédure. Bonne lecture ... Cordialement oracle7😏

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 au réseau Internet, le proxy inversé permet à un utilisateur d'Internet d'accéder à des serveurs internes. Un proxy inversé écoute sur un port donné, sécurisé ou pas, toutes les requêtes à destination de ces services. Habituellement, pour accéder à un service donné depuis une autre machine que son hôte, il faut que le port de l'hôte soit exposé. Le proxy inversé aura pour tâche de rediriger le trafic depuis un port unique (généralement le port 443) vers le bon service en fonction des paramètres d'entrée (typiquement l'URL, mais pas uniquement). Pré-requis - Comprendre le fonctionnement de Docker (voir tutoriel introductif) - Savoir se connecter en SSH à son hôte - Rediriger le port TCP 443 vers l'adresse IP du conteneur (OPTIONNEL : Rediriger le port TCP 80 vers l'adresse IP du conteneur si validation par HTTP-01) - Être un peu curieux Difficulté : moyenne 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 Nginx, via l'image linuxserver/letsencrypt. Cette solution comprend : - letsencrypt & certbot : les deux gèrent l'obtention et le renouvellement des certificats - nginx : serveur web qu'on utilise ici pour faire office de proxy inversé en présentant le certificat précédemment obtenu Avec cette solution, on remplace avantageusement le Portail des Applications le proxy inversé intégré à DSM. 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 du conteneur letsencrypt : 192.168.1.150 (en dehors de la plage DHCP mentionnée ci-dessus) - IP de l'hôte : 192.168.1.100 (peut être inclus dans la plage DHCP ou non, cela n'a pas d'incidence notable, c'est un choix personnel de votre part) - eth0 est le nom de mon interface physique 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. 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, alors on peut créer notre conteneur sur un réseau bridge (c'est possiblement le cas sur un hôte qui ne serait pas votre NAS). S'ils ne le sont pas, 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 Elle se comporte globalement comme un périphérique à part entière relié à votre routeur. Ses ports 80 et 443 sont donc libres. Plus d'informations sur ce qu'est le pilote macvlan dans le tutoriel introductif. Dans la suite je m'attarderai sur la deuxième méthode, la première devant être à votre portée si vous avez un peu d'expérience dans Docker et que vous avez lu le tutoriel cité plus avant. C'est également la méthode à appliquer si vous comptez utiliser ce conteneur sur votre NAS, ce qui est bien probablement le cas sur ce forum 😛 N'hésitez pas à lire simultanément aussi ce magnifique guide, beaucoup plus complet que le mien, 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, etc... Réseaux Dans la suite, nous allons créer deux réseaux externes : un réseau macvlan et un réseau bridge défini par l'utilisateur. Un réseau peut être défini de manière externe à un conteneur, ou interne à un conteneur. Dans le premier cas, celui-ci est toujours présent lorsque vous supprimez le conteneur et/ou l'image, dans le second cas, il disparaît avec. Pourquoi rejoindre deux réseaux simultanément ? Les détails seront abordés plus loin dans le tutoriel, mais globalement voilà l'idée : Il existe une limitation liée aux conteneurs rattachés à un réseau macvlan, ceux-ci ne peuvent communiquer avec l'adresse physique de l'hôte. Dans mon exemple, mon conteneur avec une adresse 192.168.1.150 ne pourra plus communiquer du tout (ping, http, etc...) avec son hôte (192.168.1.100), et vice-versa. Intuitivement, on se rend vite compte que ça va poser problème pour un proxy inversé. Si par exemple l'hôte est mon NAS, que j'utilise Moments derrière le proxy inversé, et bien mon conteneur letsencrypt ne pourra pas faire de redirection de type : https://moments.ndd.tld vers http://IP_du_NAS:Port_de_Moments, l'IP du NAS renvoyant un timeout car inaccessible par essence. La solution classique à ce problème est de créer une interface virtuelle (comprendre par là une deuxième adresse IP pour l'hôte, par exemple 192.168.1.200) qui se comportera exactement comme la vraie IP 192.168.1.100 En plus de complexifier l'ensemble, cette interface cirtuelle doit être recréée à chaque redémarrage, on utilise généralement une tâche planifiée dans ce but. Dans ce cas-là, l'entrée du proxy inversé pour Moments serait fonctionnelle, on aurait https://moments.ndd.tld vers http://IP_virtuelle_du_NAS:Port_de_Moments Ici, je propose une manipulation plus simple, car la solution précédente assure une bidirectionnalité dont on n'a pas besoin ici. En effet, le seul sens qui nous intéresse est le sens proxy inversé -> service interne. Pour faire cela, nous allons demander à notre conteneur de rejoindre un deuxième réseau externe en bridge. On aura donc un autre chemin pour communiquer avec l'hôte, car sur un réseau bridge, supposons un réseau bridge de plage réseau 172.x.0.0/24, l'adresse 172.x.0.1 fera toujours référence à l'hôte. Ainsi mon entrée de proxy inversé pour Moments pourra s'écrire : https://moments.ndd.tld vers http://172.x.0.1:Port_de_Moments, la communication pourra se faire sans encombre. Création du réseau macvlan On va donc se connecter en SSH, et on tape : docker network create -d macvlan \ --subnet=192.168.1.0/24 \ --ip-range=192.168.1.150/32 \ --gateway=192.168.1.254 \ -o parent=eth0 \ macvlan_net Une série de caractères s'affiche si tout s'est correctement déroulé. Notes : - Penser à utiliser sudo devant les commandes docker (valable pour toute la suite du tutoriel) si pas connecté en root - la plage IP du réseau est ici volontairement réduite à une seule IP (car /32), ainsi on est sûr que le conteneur ne pourra prendre que cette IP. - si on a un réseau macvlan pré-existant (pour un pi-hole, un jeedom, etc...), on risque d'avoir une erreur en voulant en créer un autre avec la même passerelle, en revanche j'ai remarqué que le conteneur prendra systématiquement la première IP disponible dans la plage. Pour profiter de certaines facilités ultérieurement je ne recommande pas de fixer l'IP du conteneur dans son script de création (Docker ou docker-compose). - macvlan_net peut être remplacé par le nom de votre choix. - pour connaître le nom de l'interface physique de sa machine (il varie suivant les machines), en SSH on peut taper : ifconfig ou ip addr show Il suffit alors de repérer l'interface ayant pour adresse IP l'adresse physique du NAS (ici 192.168.1.100). On peut vérifier que le réseau existe bien en tapant : docker network ls Création du réseau bridge défini par l'utilisateur Pour contrecarrer les limitations des réseaux macvlan (communication impossible entre le conteneur et son hôte), on va dans ce cas précis contourner le problème en rejoignant un réseau bridge personnalisé. Pourquoi ne pas utiliser le réseau bridge par défaut ? Car un conteneur ne peut pas rejoindre par docker-compose un réseau macvlan et le réseau bridge par défaut, ce dernier étant exclusif. En revanche il peut très bien rejoindre conjointement un réseau maclvan et bridge personnalisé simultanément. Pour en créer un rien de plus simple : docker network create letsencrypt_bridge Notes : - letsencrypt_bridge peut être remplacé par le nom de votre choix. On a donc maintenant deux réseaux externes, un macvlan et un bridge défini par l'utilisateur. Pour supprimer un réseau car vous souhaitez en changer la configuration, il suffit d'écrire : docker network rm <nom_du_reseau> Création du conteneur 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-letsencrypt Je n'aborderai pas dans ce tutoriel l'utilisation de fail2ban, qui permet de bloquer les IP qui échouent à se connecter au bout de X essais en Y secondes. Libre à vous de vous y plonger et d'en proposer un guide si le cœur vous en dit. 😉 Cas d'utilisation pour l'exemple : - Domaine OVH - Validation par DNS-01 Toutes les infos pour adapter à votre besoin sont listées ici : https://github.com/linuxserver/docker-letsencrypt Mais dans nos hypothèses, voici l'architecture du fichier docker-compose : version: '2.1' services: letsencrypt: image: linuxserver/letsencrypt container_name: letsencrypt hostname: letsencrypt networks: - macvlan_net - letsencrypt_bridge 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 letsencrypt_bridge: external: true Notes : - Vous remarquerez que je ne translate aucun port, 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 réellement "d'hôte" sur ce réseau. 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.150 (Redirection du port 80 nécessaire également si on n'utilise pas un renouvellement DNS-01 mais HTTP-01). - On remarque que mon conteneur rejoindra les deux réseaux externes créés précédemment. - Si d'aventure vous n'utilisiez pas un réseau macvlan mais bridge pour héberger votre conteneur, il faut penser dans ce cas à faire une redirection des ports sur l'hôte, ça se traduit par l'ajout du bloc suivant (par exemple entre les blocs environment et volumes) : ports: - 443:443 - 80:80 # si validation http-01 seulement 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 En bout de chaîne il vous faut disposer d'un accès à durée illimitée à l'API OVH avec les 3 champs : application key, application secret et consumer key. 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. Ainsi lorsqu'on créera le conteneur, il n'y aura pas à l'arrêter pour modifier le fichier qu'il aura créé puis le redémarrer. En SSH, 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, prenons (au hasard 😛) l'exemple d'un NAS Synology : cd /volume1/docker/letsencrypt/ Ensuite : mkdir -p config/dns-conf/ cd config/dns-conf/ curl -s https://raw.githubusercontent.com/linuxserver/docker-letsencrypt/master/root/defaults/dns-conf/ovh.ini -o ./ovh.ini Évidemment le chemin proposé est indicatif, à vous d'adapter suivant votre organisation. On édite ensuite le fichier, avec son éditeur préféré (vim, nano, WinSCP, File Station, etc...) et on remplit les champs, on obtient quelque chose de la sorte : Pour éviter un message lié aux permissions laxistes du fichier, on tape : chmod 600 ovh.ini Si en revanche vous obtenez plus tard une erreur de lecture du fichier, remplacez 600 par 640 pour être un peu plus permissif. 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 Pour vérifier qu'on est bien connecté aux deux réseaux, on peut taper la commande : docker exec -it letsencrypt ifconfig On observe 3 interfaces : la boucle locale (127.0.0.1), l'IP sur le réseau physique (192.168.1.150) et l'IP dans le réseau bridge (172.x.0.2) Note : dans la commande précédente "letsencrypt" est le nom du conteneur. Normalement à ce stade vous disposez d'un certificat fonctionnel dans /volume1/docker/letsencrypt/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 ! Il reste maintenant la partie proxy inversé à configurer. Configuration du proxy inversé Communication Il est trivial de configurer une entrée de proxy inversé avec cette image, c'est très rapide et sans douleur. Mais il est nécessaire de comprendre comment rediriger vers un service donné. Dans la pratique : - letsencrypt peut communiquer avec le conteneur Calibre-web par son nom de conteneur, et son IP. Tous les ports sont exposés entre les deux conteneurs car ils sont dans le même réseau. - letsencrypt ne peut pas contacter directement le conteneur Nextcloud, par contre il peut l'atteindre via l'IP du NAS 172.19.0.1:9443 (le NAS est la passerelle de chaque réseau sur la première IP disponible de la plage). - letsencrypt ne peut pas contacter le conteneur Grafana, car il est dans un réseau différent (isolation mutuelle d'un réseau défini par l'utilisateur à un autre) et qu'il n'y a pas de translation de ports avec son hôte. Seul l'hôte et les conteneurs telegraf et influxdb peuvent le joindre. - letsencrypt peut contacter Moments sur l'hôte sur le port 10004 via 172.19.0.1:10004 - letsencrypt peut joindre Emby Media Server via 192.168.1.101:8096 - Nextcloud peut ping Deluge par son IP, pas par son nom. Cela va permettre de mieux appréhender la suite du tutoriel, et la nature des redirections que vous devrez configurer pour accéder aux services par le proxy inversé. ATTENTION : Habituellement sur DSM, on utilise localhost pour les services hébergés sur le NAS, ici si vous avez bien suivi ça ne marchera pas, car localhost c'est le conteneur. Configuration d'une entrée Maintenant qu'on sait comment faire communiquer les services entre eux, voyons comment configurer l'entrée du proxy inversé, c'est ... trivial. Nginx est une application assez dense, et demande de comprendre les procédés à l'oeuvre, 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 correspondant au volume "/config" du conteneur, et voyons ce qu'on y trouve : Analysons une entrée de type "subdomain" : Je n'ai jamais utilisé Plex donc je découvre en même temps que vous. Je n'y connais quasiment rien en Nginx, pourtant je peux déjà comprendre assez facilement ce qui se passe ici : listen 443 ssl; listen [::]:443 ssl; Le proxy écoute sur le port 443, en IPv4 et IPv6. server_name plex.*; Le proxy appliquera les procédures qui suivent s'il reçoit une URL du type plex.ndd.tld, plex.coucou.tuto, plex.jaiplusdiday.lol, etc... à adapter suivant le sous-domaine utilisé 😉 include /config/nginx/ssl.conf; Là au lieu de copier toutes les données relatives au certificat, il va les inclure depuis un autre fichier, si la curiosité vous en dit, allez y jeter un œil. 😉 S'en suit une suite de blocs facultatifs (ils sont commentés par défaut) concernant l'authentification LDAP et Authelia. On rentre ensuite dans le vif du sujet : include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app plex; set $upstream_port 32400; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Plex-Client-Identifier $http_x_plex_client_identifier; proxy_set_header X-Plex-Device $http_x_plex_device; proxy_set_header X-Plex-Device-Name $http_x_plex_device_name; proxy_set_header X-Plex-Platform $http_x_plex_platform; proxy_set_header X-Plex-Platform-Version $http_x_plex_platform_version; proxy_set_header X-Plex-Product $http_x_plex_product; proxy_set_header X-Plex-Token $http_x_plex_token; proxy_set_header X-Plex-Version $http_x_plex_version; proxy_set_header X-Plex-Nocache $http_x_plex_nocache; proxy_set_header X-Plex-Provides $http_x_plex_provides; proxy_set_header X-Plex-Device-Vendor $http_x_plex_device_vendor; proxy_set_header X-Plex-Model $http_x_plex_model; } } On voit qu'il va inclure de nouveaux paramètres liés à la configuration du proxy, puis il fait appel au résolveur interne du conteneur. Ce résolveur s'occupe des requêtes locales et transmet à l'hôte les requêtes auxquelles il n'a pas accès, par exemple un autre réseau physique dans votre LAN ou Internet. Les 3 champs suivants sont ceux qu'on va devoir adapter. set $upstream_port 32400; Le port de l'application en question. set $upstream_proto http; Le protocole lié au port, souvent http, mais parfois https, à vous d'adapter en fonction du besoin. set $upstream_app plex; Ah... c'est là qu'il faut se poser la question : comment j'accède au service depuis mon conteneur letsencrypt ? Par défaut, cette image met le nom du conteneur qui hébergerait l'application, donc cela implique que le conteneur letsencrypt et le service ciblé soit sur le même réseau. Ce n'est pas forcément le cas. À vous d'utiliser le schéma en début de chapitre pour savoir comment accéder au service souhaité. set $upstream_app plex; set $upstream_port 32400; 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. Reste tout un tas d'entêtes pré-configurés dans le cas de Plex, je fais confiance à Linuxserver pour avoir paramétré ça correctement. Si vous souhaitez ajouter les applications Synology par exemple, trouvez un exemple d'entrée qui soit le plus simple possible (pas Plex, mais Heimdall par exemple 😛) dans la liste et adaptez les variables. Si vous rencontrez des problèmes, renseignez-vous sur la signification des entêtes et voir s'ils pourraient vous être utiles. L'avantage avec Nginx, c'est que lorsque le créateur d'une application propose une configuration pour reverse proxy dans son README, à 95% s'il y en a une il s'agit d'Nginx. 😉 Une fois toutes nos entrées configurées, on redémarre le conteneur : docker restart letsencrypt Et normalement, tout devrait être fonctionnel. Redirection http vers https La mise en place de cette redirection est abordée dans le tutoriel de @Einsteinium. Validation par HTTP-01 Il se peut que votre héberger 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.150 Un fichier docker-compose type pour un renouvellement HTTP-01 pourrait être le suivant : version: '2.1' services: letsencrypt: image: linuxserver/letsencrypt container_name: letsencrypt hostname: letsencrypt networks: - macvlan_net - letsencrypt_bridge cap_add: - NET_ADMIN environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris - URL=ndd.tld - SUBDOMAINS=plex,wordpress,moments,dsfile, - VALIDATION=http - DHLEVEL=2048 - EMAIL=mail@ndd.tld - ONLY_SUBDOMAINS=false - STAGING=false volumes: - ./config:/config restart: unless-stopped networks: macvlan_net: external: true letsencrypt_bridge: external: true Notes : - On notera la présence de la virgule à la fin de la variable d'environnement SUBDOMAINS, elle est obligatoire. - Si notre certificat root est déjà géré ailleurs, mais qu'on souhaite avoir un deuxième proxy inversé sur une autre machine (un VPS par exemple), on peut passer la variable ONLY_SUBDOMAINS à true. Ainsi le certificat ne sera généré que pour les sous-domaines. 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).

Bonsoir à tous, Je souhaite simplement vous dires merci pour l'aide apporté car aujourd'hui encore je savoure les possibilitées que mon NAS m'offre grâce à vos aides pour la configuration. Il à remplacé chez moi beaucoup d'outils qui ne m'inspiraient pas confiances comme "onedrive et google drive". Il heberge ma base de donnée "Enpass Password Manager" (similaire à keepass). Il me sert de sauvegarde rassurante des archives familiales (photos, vidéos, documents administratifs), J'ai un disque dur externe de sauvegarde stocké ailleurs au cas ou. Prochainement j'acheterais un autre Nas pour le configurer soit chez ma mère, soit chez mon frère pour créer une sauvegarde distante. Il n'a pas encore remplacé mon google agenda, car pour synchroniser calendar avec android il faut une application de synchronisation caldav (certaines payantes) mais aucunes ne m'inspirent confiance pour le moment et je devrais l'installer sur 4 téléphones portables. Je compte prochainement, installer un systeme de video surveillance et j'ai hâte d'essayer "surveillance station". En tout cas merci à vous tous et longue vie au Forum.

Suite à un déménagement, plus d'Internet, plus de fibre, plus de NAS. Mon logement a été recâblé hier. Aujourd'hui je constate que mon IP fixe publique a changé, je fais donc un petit tour chez OVH pour mettre à jour mes enregistrements. Et maintenant, après propagation de la nouvelle IP rattachée à mon nom de domaine tout fonctionne comme avant. Il me reste plus qu'à mettre à jour mon certificat Let's Encrypt. Je suis heureux 😉

Bonjour, Quel est l'intérêt de PuTTY sur Linux?

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

Bonjour aux contributeurs et merci @Fenrir pour son tuto VPN. J'utilisais le VPN de mon entreprise (LT2P) il y a encore quelques mois, et j'ai suivi à la lettre le tuto de Fenrir. Je n'ai installé que le serveur LT2P pour accès à mon DS 415+. Fonctionnement au poil! 👌 Au passage j'ai fait un tour sur le tuto Sécuriser son NAS (merci @Fenrir) ça mange pas de pain! Cordialement Audio

@Antimousse Oulà ! Si tu as des problèmes à régler, merci de ne pas les faire sur ce fil ou avec moi. Si ce fil ne t'intéresse pas, n'y reviens plus. Je suis toujours d'accord pour m'occuper de gens qui sont d'accord pour que je les soigne, mais si d'emblée il y a malaise, j'oublie direct. Ton argumentaire de lutte des classes est incongru. Juste dire "Et ?" n'est pas explicitement une question précise. Tu ne peux dés lors pas te plaindre si la réponse ne te satisfait pas. Je suis un bénévole. Je ne suis pas payé pour faire du support si tu as un problème, mais j'y veillerai cependant selon mon temps libre par pur plaisir d'aider. Tâches donc de ne pas abuser du second degré pénible. J'ai déjà développé mon propos. Je vais le refaire. Si tu as un ou deux disques en Raid1 sur un NAS d'entrée de gamme, (c'est aussi vrai avec les mêmes disques en RAID1 logiciel sous Linux) ton débit maximal va être limité par le matériel et le nombre total de disques en lecture. Le port réseau GbE pourra cependant déjà saturer avec un Seagate Ironwolf un peu dodu (8 voire 14To) en lecture simple et dans certaines conditions (données contiguës, en périphérie de disque, par exemple) Sur un NAS un peu plus dodu comme un DS1819+, 8 baies, avec une grappe à 5 disques, alors les lectures seront parallèles, et le débit peut très facilement atteindre plus de 500Mo/s en lecture, et là, le GbE sature complètement. Ce que je fais avec mes données ne regarde que moi, mais je n'ai pas commencé à jouer avec de grosses quantités de données la semaine dernière. J'ai quelques corpus de données. Je datamine sur des données épidémiologiques, depuis 19 ans, et ça commence à faire. J'ai aussi abordé la notion de routeur. Un routeur se trouve, en gros, dans chaque box ADSL/VDSL/fibre. Hélas, pour se connecter de façon sûre quelques équipements à un réseau professionnel, il faut ouvrir quelques tunnels VPN, et là, les routeurs Orange sont à la rue. Pour faire pire, les routeurs Orange ne savent pas faire de mode bridge. Impossible de le faire se comporter comme un simple modem. Parfois, comme avec les box Free, c'est prévu, et ça fonctionne. Parfois, ce n'est pas même envisagé, comme chez Orange. Donc, j'ai interposé un routeur Ubiquity EdgeRouteur 5 PoE entre l'arrivée de ma fibre (le convertisseur optique/RJ54) et ma livebox. Un sniff des paquets (avec wireshark) m'a permis de trouver des motifs qui m'ont conduit chez https://lafibre.info où j'ai découvert ce fil fleuve. Par chance, depuis mi 2014, un gars avait déjà tout défriché, tout réverse ingéniéré. Un mec dont c'est le métier, éventuellement socialement inadapté, mais juste techniquement brutal, et qui a quitté la scène en question depuis. Le fil comporte 386 pages. Le niveau fluctue jusqu'à des levels d'ingé réseau de pointe. Il y a là bas des gars qui maîtrisent toutes les RFC en détail, capables également de patcher un logiciel client DHCP pour que ça code une sous option 90 rare du protocole DHCP, en y ajoutant un niveau de priorité réseau plus élevé comme attendu par Orange, de façon à pouvoir obtenir la liaison IPv4 et IPv6 avec les DNS ad hoc pour garder la TV, sur 3 voire 4 réseaux virtuels, comme cache habituellement la box. Plus fort encore, ils le compilent sur une autre architecture (Mips) comme on se lave les dents le matin. J'ai commis un tuto https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti- edgemax/msg228041/#msg228041 pour que chacun puisse le faire dans une infrastructure en accès PPPoE avec conservation de la Livebox. J'ai lu les 386 pages. J'y passe une fois par mois pour suivre ce qui s'y passe. Depuis, l'infrastructure Orange a basculé en IPv6 et mon tuto n'est plus utilisé que par une frange mineure de la population qui tient à garder un accès PPPoE ( certains accès Pro par exemple). Si un routeur dispose de sorties à 1Gbps, en GbE avec un accès fibre de maximum 1GbE, tout va bien. Si un accès fibre jouit d'une liaison de plus de 1Gbps, ici 2Gbps, avec de simples ports de 1Gbps en GbE, ça coince. C'est pour ça que je cherche d'autres options, c'est pour ça que je cherche un routeur qui tienne des débits de connexion de plus de 1Gbps, avec des ports MultiGig. Un autre fil recueille tous les équipement qui peuvent reconnaître le module Sercomm FGS202. Ce module est intercalé entre le brin de fibre et une livebox v4. Il n'y a pas de petite gens, ni de gens d'en haut. Le monde est plat sur internet. En posant des questions, en lisant, on thésaurise la connaissance. J'ai installé mon premier modem à partir d'un coupleur acoustique, en 1985, en donnant des cours de maths pour payer une rare et coûteuse interface RS232 à mon Amstrad CPC464, en écrivant le pilote qui n'existait pas, et en écrivant moi même l'émulateur VT52. Internet n'existait pas encore pour le grand public, alors j'ai rôdé à la bibliothèque municipale, puis à celle de la fac du coin. Internet est une source colossale de connaissances, il suffit de s'y mettre, et de commencer par le point de limite de ses connaissances, pour en rajouter. Si tu poursuis avec ce ton de clivage, je n'y pourrai rien, et je ne ferai personnellement plus d'effort à ton égard. Je reçois le switch 10GbE tout à l'heure, et les modules SFP+ - 10G-BaseT sont arrivés hier. J'ai hâte de le brancher.

Bonjour, il faut rediriger le port 6690 dans le routeur vers le nas.

@Chrisyno Si ton réseau est "sûr" (UPnP désactivé dans la box, Par-feu activé) Que tu n'as pas de périphérique douteux... Le HTTP suffit (en prennent en compte que tous ce qui est transmit est en clair donc potentiellement récupérable par un personne ou un logiciel malveillant sur le réseau local).

Merci beaucoup pour votre réponse 🙂 Je suis occupé à le faire . Il faut de la patience ! hhihihi

sinon, pour un particulier ignare comme nous..... .....je réitère mon message précédent... 'et ?' vous m'apportez rien de concret et de précis dans votre choix mis à part le fait de vouloir surclasser et "écraser les ' sans dents' que nous sommes". s'il vous plait, développez vos propos en les appuyant sur des faits, des calculs pour nous, incultes. au grand plaisir de vous lire... pardon, je reformule...: ...à l'immense joie de nous éclairer "de votre grande science"

@.Shad., @oracle7, du coup, pour prendre en compte le répertoire ~/photo, mon .htaccess est comme suit : RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] RewriteCond %{HTTP_HOST} ^photo.ndd.tld$ RewriteRule ^$ https://photo.ndd.tld/photo [L,R=301] Cdt Bruno78

Free propose aussi d’autres trucs qu’Orange ne fait pas, comme l’ouverture du port 25 et le reverse DNS. Interessant pour ceux qui (comme moi et bien d’autres) veulent mettre en place un serveur mail.

Bonjour, Ça dépend si tu l'as activé ou non. C'est dans "Panneau de configuration > Réseau > Interface réseau > Gérer > Paramétre d'Open vSwitch" C'est disponible sur les NAS compatible Virtual Station Manager. Et il faut activer Open vSwitch pour héberger des machines virtuels. A noter que si Open vSwitch est activé, Adaptive Load Balancing devient Balance-SLB, IEEE 802.3ad Dynamic Link Aggregation > Balance-TCP...

Bonjour, 👍 J’utilise ce kit depuis plus d’un an sur DS918+ RAS.

Bonjour la compagnie! Je reviens avec des billes. J'ai installé Windows 10 pro sur Mac, et tout fonctionne à merveille!!! Concernant l'autre ordinateur Thinkpad, j'ai totalement supprimé les partitions du SSD, et utilisé l'outil de reformatage ultime fourni par le fabricant de mon PC. Et miracle, tout roule nickel. J'avais très certainement des fichiers corrompus même lors d'une réinstallation propre par Windows. Comme quoi, ce problème plus qu'ennuyeux est désormais résolu !!!

Ah ! Tu m’as grillé 😅

Bonjour, il faut faire un "simple reset" (mode1): https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS

Bonjour a tous ! Ci-dessous un petit tuto pour pouvoir securiser sa connexion ssh sur un NAS synology avec authy Afin de pouvoir faire fonctionner votre authentification double facteur sur il vous faudra avoir installé bootstrap (IPKG) créé un compte authy créé une application authy-ssh : 9c6772a078870c470de0a32a1865743c dans cette exemple Installation des paquets IPKG nécessaire Commencez par vous loger en root (root et pas admin) sur votre NAS via votre client ssh préféré, puis installer le paquet ipkg bash ipkg install bash Téléchargement et configuration d’authy-ssh Une fois que vous avez installe bash, téléchargez authy-ssh cd /tmp curl -O 'https://raw.githubusercontent.com/authy/authy-ssh/master/authy-ssh' Si curl vous retourne une erreur “curl: (1) Protocol ‘https not supported or disabled in libcurl” utilisez la commande suivante curl -O 'https://raw.githubusercontent.com/authy/authy-ssh/master/authy-ssh' --insecure Maintenant éditez la configuration du script nano authy-ssh Remplacez #!/usr/bin/env bash (1ere ligne) par #!/opt/bin/bash et ajoutez avant export TERM=”xterm-256color” export PATH=$PATH:/opt/bin Voici a quoi devrait ressembler les 13 premières lignes du script authy-ssh une fois ces deux modifications terminées #!/opt/bin/bash VERSION="1.4" AUTHY_URL="https://api.authy.com" APP_ROOT=`dirname $0` CONFIG_FILE="$APP_ROOT/authy-ssh.conf" UPSTREAM_URL="https://raw.github.com/authy/authy-ssh/master/authy-ssh" READ_TIMEOUT=60 OK=0 FAIL=1 export PATH=$PATH:/opt/bin export TERM="xterm-256color" Rendez le script exécutable et lancez l’installation chmod +x authy-ssh ./authy-ssh install /usr/local/bin/ L’installation devrait se passer correctement DS_Test> ./authy-ssh install /usr/local/bin Copying ./authy-ssh to /usr/local/bin/authy-ssh... Setting up permissions... Enter the Authy API key: 9c6772a078870c470de0a32a1865743c Default action when api.authy.com cannot be contacted: 1. Disable two factor authentication until api.authy.com is back 2. Don't allow logins until api.authy.com is back type 1 or 2 to select the option: 2 Generating initial config on /usr/local/bin/authy-ssh.conf... Adding 'ForceCommand /usr/local/bin/authy-ssh login' to /etc/ssh/sshd_config MAKE SURE YOU DO NOT MOVE/REMOVE /usr/local/bin/authy-ssh BEFORE UNINSTALLING AUTHY SSH To enable two-factor authentication on your account type the following command: sudo /usr/local/bin/authy-ssh enable root <your-email> <your-numeric-country-code> <your-cellphone> Example: sudo ./authy-ssh enable root myuser@example.com 1 401-390-9987 To enable two-factor authentication on user account type: sudo /usr/local/bin/authy-ssh enable <local-username> <user-email> <user-cellphone-country-code> <user-cellphone> To uninstall Authy SSH type: sudo /usr/local/bin/authy-ssh uninstall Restart the SSH server to apply changes Configuration d’authy-ssh pour les utilisateurs admin et root L’installation d’une authentification double facteur pour un utilisateur se fait sur le modèle suivant /usr/local/bin/authy-ssh enable <utilisateur> <email> <code pays> <numero-de-telephone> Dans notre cas pour admin (commencez par l’utilisateur admin, si tout fonctionne correctement vous pourrez implémenter cette solution pour root) /usr/local/bin/authy-ssh enable admin chuck@norris.com 33 666666666 Authy-ssh se configure alors DS_Test> /usr/local/bin/authy-ssh enable admin chuck@norris.com 33 666666666 Username: admin Cellphone: (+33) 666666666 Email: chuck@norris.com Do you want to enable this user? (y/n) y User was registered DS_Test> authy-ssh lors de la configuration ne modifie le fichier de configuration ssh que pour l’utilisateur root, puisque nous nous occupons d’admin il faudra que vous le fassiez vous même nano /etc/ssh/sshd_config Une fois le fichier de configuration de ssh ouvert rendez vous a la fin du fichier et vous verrez qu’authy a ajoute la ligne ForceCommand /usr/local/bin/authy-ssh login au block Match User root # Example of overriding settings on a per-user basis Match User root # X11Forwarding no AllowTcpForwarding yes # ForceCommand cvs server ForceCommand /usr/local/bin/authy-ssh login Créez le meme block pour l’utilisateur admin, de sorte que vous ayez # Example of overriding settings on a per-user basis Match User root # X11Forwarding no AllowTcpForwarding yes # ForceCommand cvs server ForceCommand /usr/local/bin/authy-ssh login Match User admin ForceCommand /usr/local/bin/authy-ssh login Redémarrez le service ssh killall sshd Reconnectez vous en ssh cette fois en avec l’user admin, voici ce que vous devriez voir login as : admin admin@192.168.1.190's password: Authy Token (type 'sms' to request a SMS token): Si et seulement si tout fonctionne lors de la connection ssh admin vous pouvez configurer authy sur root, reconnectez vous en root et lancez le script de configuration /usr/local/bin/authy-ssh enable root chuck@norris.com 33 666666666 Source

Salut, pourquoi dans ton serveur DNS sur le NAS tu n'as aucune entrée music, filestation, etc... ? De plus, assure-toi que chaque requête suive bien un de deux chemins que j'explicite dans le post ci-dessous : Il y a forcément quelque chose qui ne va pas dans ta config, à commencer par la première remarque de mon post.

Oui l'Apple TV 4K fonctionne très bien en 1080p 👍

la voila !!!! tout chaude du synology developer au départ pour eux (avec test sur m'on NAS) c'etait du a Symfony. Apres avoir passé 4 semaines de contact par email, une 10em de "remonte contrôle" .... Dear Customer, Thank you for your reply. We found the problem is libsodium does not match, we are trying to help with it. We'll keep you posted if there's any update from the team. If there is any problem, please feel free to contact us. Sincerely, Technical Support bon ben il y a pulque a attendre.

C'était pareil pour moi ! Tu remplace juste : "devices" : null, par : "devices" : [ { "CgroupPermissions" : "rwm", "PathInContainer" : "/dev/dri", "PathOnHost" : "/dev/dri" } ],

C’est un peu le principe du reverse proxy. Accéder à plusieurs périphériques depuis l’extérieur via un seul port et une seule ip externe. pour preuve, cela doit fonctionner en local comme à l’extérieur du réseau. Sinon cela ne pourrait pas fonctionner si tu pointes systématiquement avec une IP locale. le reverse proxy doit aussi fonctionner en 4G ou depuis une connexion externe. Pour que cela fonctionne, le dns doit bien indiquer l’ip externe. d’ailleurs, cela semble fonctionner pour @Stegnot actuellement. Comme vu plus haut, l’intérêt de pointer via DNS local sera éventuellement d’accélérer un peu le processus, mais cela ne sera pas transcendant. Apriori, vu que cela fonctionne actuellement, le loopback semble fonctionner sur sa box. C’est bien ce que fait le reverse proxy. Il transfert au bon endroit. le DNS local ne fera gagner que le temps du loopback. (Ce qui est toujours ça de pris)

@Stegnot Essai de désactiver la case de nom de domaine personnalisé pour voir si celui-ci ne te met pas le bazar ? (tu n'aurais pas fait la même chose sur le nouveau par hasard ?) Pour le DNS, si quand tu le ping, tu as bien ton ip, cela veut dire que ça arrive à ton NAS et qu'il doit reconnaître ton nom de domaine et te rediriger. Autre question, tu as fait l'agrégation de lien ? Si oui, tu l'as bien configuré pour qu'une seule IP ne "sorte" en local ?

Je viens de verifier j'ai le firmware 3.73.10 Ce qu'il faudrait reussir à faire serait d'avoir 2 serveurs dhcp actifs, celui de la box qui ne gérerait que le décodeur tv et celui du nas qui prendrait en charge le reste du réseau ... mais je n'ai pas encore trouvé si faisable et comment paramétrer tout ça !

Merci @Einsteinium pour ce tuto. Je viens de le mettre en place, c'est top. Efficace et fonctionnel. De même pour le transcodage Hardware (transcodage de vidéos 4k sur smartphone à distance en 4G alors que le NAS est sur une connexion en ADSL, ça fonctionne pas mal (pas très beau mais fluide !)) Juste une petite info si certains ont besoin, les procs intel J4**** ont un bug logiciel, il faut modifier les préférences et après ça repart : https://forums.plex.tv/t/migration-issue-4k-not-working-well-on-ds920/607862/11 :

Bonjour, La version 1.19.5.3112 est sortie (et est compatible). Essaye de faire la mise à jour en manuel avec celle-ci. Georges.

Bonjour Jules Perrelet, La version que tu as installé de façon manuelle n'est pas dans la liste des paquet pour les nas. en clair elle n'est pas compatible encore d’où ton problème. Question pourquoi ne pas avoir installer plex en docker ? Avec un DS918+ c'est le top ( après il te faudra peut être ajouter de la ram), cela permet de mettre a jour celui-ci de façon simple et si cela "merde" tu peux supprimer le docker de façon transparente. https://www.nas-forum.com/forum/topic/59118-tuto-plex-via-docker-avec-ou-sans-transcodage-matériel/

Oui, mais malheureusement tu aurais dû chercher un peu plus... Moi aussi comme un bon gros couillon j'ai failli faire la même erreur que toi 😉 Donc à Rodrigue, apprendre à communiquer est étant sourd et muet, je dis BRAVO ! 😉

Bonjour, Ne serait t'il pas utile de créer un catégorie pour SRM. Car le système est commun aux RT1900ac, RT2600ac et MR2200ac. Et les informations, solutions, problémes sont donc actuellement éparpillés dans les 3 catégories. Or beaucoup d'entre eux sont lié à SRM plus qu'aux différents modèles de routeur.

Bref... tout ça pour que le client achète de nouvelles solutions encore et toujours 😅

@G38SMH Bonjour, Pour SMB1 quoiqu'on en dise vis à vis de la sécurité, cela reste sur ton réseau local et à partir du moment où tu as bien suivi le TUTO sur la sécurisation des accès au NAS, il ne devrait pas y avoir de Pbs de ce coté là (SMB1). C'est vrai que parfois une remise à plat est nécessaire pour repartir sur des bases saines ... Bon courage à toi pour toutes ces "longues" manipulations. Cordialement oracle7😏

@G38SMH Comme il faut tout envisager voilà en vrac quelques pistes non exhaustives à tester pour le cas où tu ne les auraient pas déjà faites (çà vaut quand même le coup de les repasser) : J'imagine que tu as réinitialisé le réseau (Winsock et tout le toutim) dans WIN (Paramètres/ Etat/Réinitialisation du réseau) + reboot PC ? As-tu vérifié tout ce qui concerne le "Centre Réseau et partage" notamment "Partage avancé" ? As-tu ajouté au fichier hosts une ligne du type : "@IPduNAS Nom_du_NAS" ? As-tu forcé l'@IP DNS sur par exemple les DNS FND ou Google dans les paramètres IPv4 de ta carte réseau sur le PC ? idem NetBIOS sur TCPIP ? Cordialement oracle7😏

Sauf que dans le conteneur, le chemin c'est /etc/pihole et /etc/dnsmasq.d, toi tu as mis /pihole et /dnsmasq.d (à droite des ":"). Ça ne peut pas marcher.

Qu'est-ce que Docker ? Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur. On ne parle pas ici de virtualisation mais de conteneurisation, une forme plus légère, qui s'appuie sur certaines parties de la machine hôte pour son fonctionnement. En effet, une machine virtuelle nécessite son propre système d'exploitation et nécessite donc une certaine quantité de mémoire dédiée, tout cela parfois dans le but de faire tourner une seule application. Synology fournit sa propre version du moteur Docker via le centre de paquets. Pré-requis Les modèles compatibles sont : Les modèles + Les modèles RS, FS, SA Le DS620slim Seuls les NAS Synology de série 10 et plus peuvent en bénéficier. Pourquoi utiliser Docker sur un NAS Synology ? DSM est un système basé sur un noyau Linux, cependant c'est un système propriétaire et si certains éditeurs de logiciels font l'effort et ont les ressources pour développer un paquet adapté, force est de reconnaître que ça reste limité. SynoCommunity fournit certains paquets très utiles, mais les paquets étant maintenus sur la base du volontariat, les mises à jour sont fréquemment en retard. DSM fournit une interface relativement claire et épurée pour Docker, bien que limitée pour certains cas d'utilisation. Vous pouvez a priori exécuter n'importe quelle application disponible pour une distribution Linux classique. Enfin, le point le plus intéressant, le système n'est en rien affecté et aucune dépendance n'a besoin d'être installée. Vous ne risquez donc pas (du moins sans le vouloir) de planter votre installation DSM et les mises à jour de ce dernier n'ont que très peu de chances d'impacter l'exécution de vos conteneurs. Aller plus loin J'ai réalisé quelques autres tutoriels sur le forum qui permettent une fois les bases acquises, de mettre en place quelques outils intéressants, que ce soit par la réflexion que ça amène ou leur finalité, souvent les deux 😉 - Mise à jour automatisée de ses images et conteneurs : https://www.nas-forum.com/forum/topic/63740-tuto-mise-à-jour-automatique-des-containers-docker/ - Centralisation de la gestion de plusieurs instances Docker : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ - Monitoring du réseau : https://www.nas-forum.com/forum/topic/63273-tuto-monitoring-nas-et-réseau/ (pour le monitoring de la Freebox voir le tutoriel de @bruno78 : https://www.nas-forum.com/forum/topic/66394-tuto-monitorer-sa-freebox-revolution/) - Gestion de certificat SSL et proxy inversé : https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ Comment utiliser Docker ? Nous verrons trois méthodes pour créer des conteneurs : Par l'interface intégrée à DSM via SSH par ligne de commande via SSH en utilisant Docker-compose Les deux dernières méthodes, bien qu'un peu moins accessibles pour des images simples à configurer, se révèlent plus efficaces lorsqu'on sort des sentiers battus. Installation de Docker et recommandations Pour installer Docker, il suffit de se rendre dans le centre de paquets et de chercher Docker dans la liste des paquets tiers, on clique sur Installer. Done ! Mais avant de commencer le tutoriel et de télécharger vos premières images, quelques précautions, pour les besoins du tutoriel j'utiliserai comme exemple Heimdall, qui est une dashboard permettant de créer des liens rapidement vers ses applications via des épingles. Docker Hub est un centre de dépôts où la qualité des images peut varier très fortement, dès lors à moins de ne pas avoir le choix, évitez les images qui ne fournissent aucune documentation Parfois, la page Docker Hub d'une image ne fournit pas beaucoup d'information, vous trouverez généralement plus d'informations concernant la dite image sur GitHub (page GitHub / page DockerHub) En cas de difficulté pour créer un conteneur fonctionnel, il est toujours intéressant d'aller consulter les pages relatives au support et aux soucis techniques sur GitHub (https://github.com/linuxserver/Heimdall/issues) Il n'est pas toujours plus simple d'utiliser la version conteneurisée d'une application que sa version classique. Si pour x ou y raisons il existe des incompatibilités avec un NAS Synology ou si les difficultés sont trop nombreuses, si la documentation fait cruellement défaut, ou encore que l'image est à l'abandon, je vous conseiller d'opter pour une machine virtuelle et réaliser une installation classique. C'est du temps gagné et des cheveux épargnés. 🙂 Interface de Docker dans DSM On clique sur Docker pour arriver sur cette interface : On peut voir l'utilisation générale du processeur et de la mémoire, ainsi que l'utilisation des ressources pour chaque conteneur créé. Dans l'onglet Conteneur, on peut venir éditer nos différents conteneurs : les arrêter et les démarrer (interrupteur à droite), les modifier, les supprimer, etc... L'onglet Registre est celui qui permet de télécharger les images des applications qui nous intéressent : L'onglet Image liste les images qu'on a téléchargées sur le NAS et la taille qu'elles occupent dans l'espace de stockage : L'onglet Réseau définit les réseaux sur lesquels nos conteneurs seront actifs. L'onglet Journal est un fichier log des différentes actions réalisées (création et suppression de conteneurs, téléchargement d'images, etc...) Chronologie La logique est la suivante : On télécharge l'image d'une application qui nous intéresse. On crée un conteneur basé sur cette image en personnalisant les données à notre utilisation : les variables (un login/mdp, l'utilisateur du NAS qui va exécuter l'application, un fuseau horaire, etc...), les ports (comment on y accède), les volumes (souhaite-t-on stocker des données de manière persistente?), les réseaux (liés à l'accessibilité et à la communication), etc... On démarre le conteneur. Exemple Image Je reprends l'exemple de l'image linuxserver/heimdall (le terme à gauche est le nom de l'éditeur de l'image, à droite le nom de l'application). Par défaut, toutes les images qu'on peut rechercher dans l'interface Docker de DSM correspondent aux images hébergées sur Docker Hub. Il est possible d'ajouter des registres supplémentaires (GitLab et d'autres). Dans 99% des cas Docker Hub est la seule source dont vous avez besoin. Pour notre image en question, on trouve différentes informations : Le tag latest correspond à la dernière version stable en date, development parle d'elle-même, vous pouvez également avoir des numéros de version spécifique, si vous ne souhaitez pas que l'image se mette à jour. La plupart du temps, c'est la version latest qui nous intéressera. Par convention (respectée dans l'immense majorité), si le tag n'est pas précisé, on parle de la version latest. On retourne dans l'onglet Registre, et on double-clique sur l'image une fois trouvée via le champ de recherche : On sélectionne le tag latest. L'image se télécharge, on peut voir l'avancement dans l'onglet Image, à droite la taille que l'image occupe sur votre NAS : L'image est téléchargée, on va maintenant pouvoir créer le conteneur. Paramétrage du Conteneur On va donc créer notre conteneur, ce sera la version exécutée de notre image. Pour en créer un, il suffit de double-cliquer sur l'image qu'on a fini de télécharger : Un nom nous est proposé par défaut, on peut évidemment le modifier pour quelque chose de plus simple. On laisse décocher Exécuter le conteneur à l'aide de privilèges élevés car cela revient à donner un accès root au conteneur, sauf cas très précis c'est déconseillé. C'est une des rares options dans Docker qui peut compromettre l'intégrité de votre NAS si mal utilisée. Si un tutoriel demande à cocher cette option, prenez le temps de comprendre pourquoi et vous demander si c'est vraiment utile. On peut limiter la quantité de mémoire que le conteneur utilisera pour s'exécuter. On clique ensuite sur Paramètres avancés pour poursuivre la configuration du conteneur. Conditions d'exécution En cas d'arrêt inopportun du NAS ou du paquet Docker, on peut autoriser le redémarrage automatique, suivant l'application concernée c'est généralement un paramètre intéressant, on le coche donc. On peut créer un raccourci sur le bureau si on le souhaite. D'autres comportements que le redémarrage automatique sont disponibles mais à ma connaissance, non sélectionnables via l'interface graphique Docker de DSM. Volumes Un conteneur, lorsqu'il est créé, écrit des données sur votre NAS. Par défaut, si rien n'est précisé, les données seront écrites dans des dossiers cachés relativement peu exploitables. Lorsqu'on supprime un conteneur, les données y affairant sont également supprimées. C'est un gros avantage de Docker, rien n'est éparpillé et ne viendra polluer DSM ou votre stockage. En revanche, en cas de suppression involontaire ou d'un bug nécessitant la recréation du conteneur, il est très vite arrivé d'en perdre toute la configuration. Le montage d'un volume permet de s'affranchir de ces limitations en localisant des données (dossiers ou fichiers) à un endroit précis du NAS. Outre l'accessibilité rendue aisée, ces données ne disparaîtront pas lors de la suppression du conteneur, ou même de l'image dont il est tiré, on parle de données persistantes. A l'instar de tout système d'exploitation, il est tout à fait possible d'explorer l’arborescence d'un conteneur comme on le ferait pour notre NAS ou n'importe quelle autre machine. Ci-dessous, l’arborescence à la racine du NAS (à gauche) et l'arborescence du conteneur (à droite). Reprenons les directives du créateur de l'image : On s'intéresse aux paramètres précédés d'un -v, ici on nous dit que /config (chemin dans le conteneur, que les plus observateurs auront vu dans l'arborescence du conteneur sur l'image de droite un peu plus haut) peut être monté vers le NAS si on souhaite faire persister les données (on le veut dans ce cas, on n'a pas envie de tout reconfigurer à chaque redémarrage du conteneur). On va donc dans l'onglet Volume : Et on clique sur Ajouter un dossier. On est alors amené à choisir le dossier dans lequel on va monter /config. Par commodité, j'ai créé un dossier partagé docker dans lequel je crée un dossier pour chaque conteneur, libre à vous de vous organiser de la manière qui vous conviendra le mieux. Je choisis mon dossier et valide : Dans la colonne Chemin d'accès, je suis venu écrire manuellement le chemin absolu du dossier à monter. Réseau Pour l'accessibilité du tutoriel, je ne mentionne dans cette partie que deux types de réseau : le mode bridge (défaut) et le mode host. Le fonctionnement avancé des réseaux faisant l'objet d'une description plus exhaustive en fin de tutoriel pour ceux que ça intéresse. Par défaut, le mode bridge est sélectionné. Dans ce mode, lorsqu'un conteneur est créé, il obtient une adresse IP privée libre dans le sous-réseau 172.17.0.0/24. La passerelle de ce conteneur sera toujours 172.17.0.1, qui est une des nouvelles interfaces du NAS (consécutivement à l'installation de Docker). Pour s'en assurer, connectez-vous en SSH sur votre NAS et tapez : ifconfig Vous verrez une interface docker0 avec l'IP 172.17.0.1, c'est la porte vers le monde extérieur (LAN + WAN) pour tous les conteneurs dans le réseau bridge 172.17.0.0/24 En mode bridge, si les ports ne sont pas translatés de la passerelle (le NAS) vers le conteneur, le conteneur n'est pas accessible depuis votre réseau local (hormis le NAS). On a un fonctionnement similaire à un routeur auquel on dit de translater certains ports vers une machine de notre réseau pour y accéder de l'extérieur. Le mode host permet lui d'exposer directement le conteneur sur le NAS, à la manière de n'importe quel paquet Synology. En gardant l'avantage de conserver les dépendances en son sein et de ne pas impacter le système d'exploitation. Il n'y a dans ce cas aucune redirection de ports à effectuer, ils sont directement joignables sur l'IP du NAS (sous réserve que le pare-feu l'autorise). Dans l'onglet Réseau, on va donc laisser tel quel pour rester en mode bridge : Si on veut passer en mode host, il faut cocher l'option Utiliser le même réseau que Docker host. On notera en dernier lieu qu'il est possible par l'intermédiaire du "+" de créer des réseaux bridge différents de celui par défaut, cela peut avoir un certain intérêt lorsqu'on souhaite faire communiquer des conteneurs entre eux (voir fin du tutoriel). Ports Si on a choisi le mode bridge, Docker liste par défaut les différents ports qu'utilise le conteneur, en proposant la valeur Auto pour le port du NAS. Si vous laissez Auto, alors un port libre aléatoire sera choisi par le système. Dans l'extrême majorité des cas, on préfère définir nous même les ports à exposer, il faut simplement s'assurer qu'ils ne sont pas déjà en cours d'utilisation par un autre service (auquel cas DSM nous préviendra au moment de valider le choix des ports). On aurait pu garder les mêmes ports que dans le conteneur, mais dans le cas présent, 80 est le port utilisé par Web Station, et 443 peut servir pour la mise en place d'un proxy inversé, donc j'ai préféré en choisir d'autres qui, eux, sont libres : Note : Lorsque la documentation ne précise pas le protocole du transport des données par le dit port, c'est TCP qui est concerné. Si on a choisi le mode host, on n'a pas besoin de faire de redirection de ports (voir partie précédente) Liens Les liens permettent de connecter plusieurs conteneurs entre eux, dans la partie de gauche on choisit un autre conteneur, dans la partie de droite un alias, qui permettra de personnaliser des variables d'environnement dans le conteneur lié. Cette fonctionnalité étant dépréciée, je ne m'étendrai pas plus dessus, voir le chapitre Réseau en fin de tutoriel pour une méthode alternative. Variables d'environnement Elles permettent de personnaliser le conteneur pour notre utilisation personnelle. Dans l'image ci-dessus, elles sont identifiées par le -e, on en identifie donc trois : PUID, PGID et TZ Dans l'onglet correspondant, je crée ces trois variables en utilisant le "+" en haut à gauche du cadre : Concernant les variables PUID et PGID, elles vont permettre de définir l'utilisateur du NAS qui exécutera le conteneur. On les retrouve par exemple, mais pas seulement, dans toutes les images Linuxserver, qui est un collectif de développeurs réalisant le portage d'applications phares vers des images Docker standardisées et surtout NAS friendly. Lorsque vous cherchez une application, je vous conseille en premier lieu d'aller jeter un oeil à la liste de leur releases, les ajouts sont fréquents et les mises à jour encore plus. Pour connaître les valeurs numériques à entrer, il faut se connecter en SSH sur le NAS, et taper : id user user étant l'utilisateur qu'on souhaite employer. On obtient plusieurs valeurs, un UID >= 1026, un GID = 100 ou plus, d'autres valeurs de GID dont on ne se servira pas ici. On fait correspondre le PUID au UID et le PGID au GID. Il faut également remplir deux autres conditions pour ne pas avoir de problème de permissions d'écriture dans nos volumes : que l'utilisateur choisi a des droits suffisants dans les dossiers partagés qui seront utilisés, dans mon cas le dossier partagé docker que l'utilisateur soit idéalement propriétaire du dossier heimdall, dans lequel j'ai décidé de monter /config du conteneur. Ces conditions sont très importantes pour que tout fonctionne sans accroc. Pour TZ, c'est une variable permettant de définir le fuseau horaire à l'intérieur du conteneur, vous pouvez trouver sur cette page une liste des valeurs à entrer suivant votre localisation. Création du conteneur On valide les Paramètres avancés, et on clique sur Suivant, un dernier écran propose un récapitulatif de la configuration du conteneur, on applique. On peut vérifier dans l'onglet Conteneur que le conteneur est en cours d'exécution. Il ne reste plus qu'à aller sur notre navigateur et entrer l'adresse du NAS suivi du port HTTP qu'on a translaté depuis le conteneur vers le NAS : Et pour la version HTTPS : Aperçu et Logs du conteneur Dans notre cas c'est merveilleux tout marche bien, mais il faut savoir que toutes les images ne sont pas aussi bien documentées, et qu'on n'est jamais à l'abri d'une erreur. Dans l'onglet Conteneur, si on en sélectionne un et qu'on clique sur Détail, on peut avoir un aperçu des statistiques du conteneur, et surtout les logs du conteneur dans l'onglet Journal, c'est la première chose à regarder en cas de conteneur non fonctionnel (accès impossible, redémarrage en boucle, etc...). ________________________________________ Ceci conclut la partie destinée à l'interface Docker de DSM, elle conviendra pour la majorité de vos besoins mais peut clairement révéler des insuffisances dans des cas plus poussés. Docker via SSH Un des principaux problèmes qu'on peut rencontrer avec l'interface de DSM c'est l'impossibilité de choisir des dossiers sur le NAS en dehors de /volume1, or Docker s'appuyant sur le système d'exploitation de l'hôte, il peut avoir besoin d'accéder à ses ressources. il est possible de contourner ce problème avec l'interface DSM de Docker via des liens symboliques (symlink) mais je trouve ça plus personnellement plus compliqué qu'un bête script. Par chance, pour les images comportant peu d'infos, il y a souvent a minima le script de démarrage du conteneur, exemple avec l'image utilisée ci-avant : On comprend assez vite la correspondance entre ce qu'on a fait précédemment et ce qu'on lit ici, quelques remarques tout de même : les \ permettent d'effectuer un retour à la ligne et de rendre le script présentable, il est tout à fait possible d'écrire tout à la suite. si j'écris -p 8080:80, je demande de faire correspondre le port 8080 de l'hôte avec le port 80 du conteneur, l'ordre est donc primordial. de la même manière qu'on peut mapper les ports, on peut mapper les volumes : /volume1/docker/heimdall est ici mon dossier sur le NAS, /config mon dossier dans le conteneur, j'écrirai donc ça : -v /volume1/docker/heimdall:/config on voit qu'ici il est possible de définir un autre type de comportement pour le redémarrage (celui qu'on avait validé dans l'interface correspondant à --restart always), ici on empêche le redémarrage automatique si le conteneur a été stoppé correctement. la dernière ligne reprend le nom de l'image, si aucun tag n'est précisé alors latest est implicite. il n'est pas nécessaire de télécharger l'image au préalable, au lancement du script il va aller chercher la version la plus récente du tag demandé, la re-télécharger si l'image est obsolète et enchaîner sur la création du conteneur. il faut ajouter sudo en début de commande si on n'est pas connecté en root au terminal. Cette commande permet de créer le conteneur, on doit ensuite taper : docker start heimdall pour exécuter le conteneur (pensez à ajouter sudo aux commandes docker si vous n'êtes pas connecté en root). Assez intuitivement, pour arrêter le conteneur on tape : docker stop heimdall Pour supprimer le conteneur : docker rm heimdall Pour voir la liste des conteneurs actifs, on écrit la commande : docker ps Pour voir les logs d'un conteneur en direct, on écrit (CTRL+C pour arrêter la visualisation) : docker logs -f heimdall Pour gérer les réseaux, reportez-vous à l'aide via la commande : docker network --help Enfin, ça peut être parfois très utile, il est possible de se connecter à l'intérieur d'un conteneur, pour cela : docker exec -it heimdall bash Notes : En général, le paquet bash est présent dans la plupart des images que vous utiliserez. Parfois, si bash ne fonctionne pas, essayez ash. Si bash n'est pas disponible, rien ne vous empêche de taper directement la commande qui vous intéresse, par exemple : docker exec -it heimdall ls -la /etc Pour sortir du conteneur, tapez exit. A vous d'explorer l'ensemble des commandes à votre disposition en consultant le manuel d'aide : docker --help En dernier lieu, je vous invite à parcourir la documentation de Docker, bien que touffue elle est extrêmement claire : https://docs.docker.com/ Comme je disais au début du chapitre, le gros avantage de cette méthode est qu'elle permet de définir des chemins absolus hors /volume1 pour nos volumes. Rien ne m'empêcherait d'aller mapper /var/lib/temperature pour un dossier quelconque du conteneur. Cette possibilité est particulièrement utile quand une application va devoir utiliser le cœur de docker, le fichier /var/run/docker.sock. Ce fichier est particulièrement important, car à partir du moment où on le mappe en tant que volume vers un conteneur, on peut prendre le contrôle de Docker avec cette application. Typiquement, Portainer est une interface graphique à la manière de l'interface Docker de DSM pour gérer ses conteneurs, ses images, et toutes les infos exploitables (mais en mieux 😛). Avertissement !! A partir du moment où vous donnez accès à d'autres dossiers que ceux dans /volume1, le conteneur sera nécessairement lancé avec l'utilsateur root du NAS, car seul lui a accès à cette partie du système. Soyez donc attentifs aux nécessaires précautions que cela implique. Docker-compose via SSH Docker-compose vient compenser les lacunes de la création de conteneur par Docker : Ça permet entre autre d'adopter une forme plus analytique et donc plus lisible, on peut également définir plusieurs "services" (voir image ci-dessus) au sein d'un même fichier docker-compose.yml Concrètement, je pourrais vouloir créer un fichier docker-compose reprenant trois services : une application, une base de données, un client syslog. Aucun des trois n'a vocation à fonctionner seul, il est donc pratique de les réunir vu qu'ils forment une entité à part entière. Je pourrais également définir directement des réseaux dans ce fichier, et que ceux-ci soient créés de manière concomitante à la création des conteneurs. Il suffit de placer ce fichier dans un dossier, d'en faire le répertoire de travail dans son terminal, et de taper : docker-compose up -d Si je souhaite supprimer les conteneurs (et les éventuels réseaux définis dans le fichier), il me suffit de taper : docker-compose down Ça a également l'avantage de garder la configuration du conteneur au sein d'un fichier. Ce fichier docker-compose.yml peut être créé par Notepad++ sous Windows, ou via l'éditeur de texte sous Linux. Attention !! le fichier ne doit pas contenir de tabulation, tous les décalages sont réalisés à partir d'espace !! Plus d'infos sur Docker-compose à cette page. Quelques autres commandes utiles docker stats Affiche les ressources utilisées par vos conteneurs, se rafraîchit constamment. docker network inspect <nom_du_réseau> Permet d'avoir toutes les informations relatives à un réseau donné. docker rmi <nom_image> Permet de supprimer l'image avec le nom spécifié. Informations complémentaires Réseaux Le mode bridge par défaut (c'est-à-dire si on utilise le driver bridge, et qu'on ne rattache le conteneur à aucun réseau bridge particulier) n'est pas idéal si l'on souhaite isoler les conteneurs les uns des autres. Tous les conteneurs appartenant au réseau bridge par défaut peuvent communiquer les uns avec les autres par leur IP, et se situent sur un même sous-réseau (par exemple 172.17.0.0). Si on souhaite s'affranchir des adresses IP (qui peuvent changer entre chaque création et suppression de conteneur) et utiliser plutôt le nom du conteneur pour communiquer avec, il existe deux méthodes : Les liens (évoqués plus avant) : c'est une fonctionnalité officiellement dépréciée dans les nouvelles versions de Docker, elle est cependant présente dans l'inteface Docker de DSM, dans l'onglet Lien lorsqu'on crée ou modifie un conteneur. En précisant le nom d'un autre conteneur, on autorise la communication notre conteneur en devenir et celui-ci. Les réseaux bridge définis par l'utilisateur : la commande docker network permet de gérer les réseaux docker et donc d'en créer de nouveaux. Lorsqu'on crée un réseau bridge, celui-ci aura la propriété intrinsèque que tous les conteneurs qui y sont connectés pourront communiquer entre eux via leurs noms de conteneur. Le réseau 172.17.0.0/24 étant réservé au réseau bridge par défaut, le premier réseau disponible est le 172.18.0.0/24, et ce jusqu'à 172.32.0.0/24. Un réseau de type bridge créé dans l'interface Docker de DSM est un réseau de cette catégorie. Il existe un autre type de réseau appelé macvlan : il permet de donner une IP sur le réseau physique à un conteneur, donc par exemple 192.168.0.0/24, et sera donc directement accessible par les autres périphériques de votre réseau local. Merci à @bruno78 pour son apport sur ce sujet en particulier, la suite est très largement inspirée de ses commentaires, et @Didier3L dont les questions ont permis de défricher le terrain. Ce driver possède de gros avantages et un gros défaut : Si le conteneur a une IP sur le réseau physique, elle est directement accessible via tous ses ports. C'est excessivement pratique si certaines applications de l'hôte, ici le NAS, utilisent déjà certains ports : 80, 443, 53, etc... Prenez l'exemple parlant de Pihole, ce dernier utilise le port 80 pour plusieurs tâches, ainsi que le port 53 qui est le port DNS non sécurisé. Si vous utilisez le paquet DNS Server du NAS, le port 53 est déjà en écoute, pareil avec le port 80 si Webstation est exécuté. Nous avons précédemment vu qu'il était possible de translater, sauf que certains ports comme le port 53 ne sont pas réellement déplaçables sur un autre port. Je n'ai donc aucune redirection à faire, j'accéderai à mon application via par exemple 192.168.0.101:80, tout simplement, sans me soucier de ce que le NAS utilise. Attention cependant, en macvlan, l'hôte ne peut plus communiquer, via son interface physique, avec le conteneur !! Ce n'est pas gênant dans le cas du contrôleur Unifi d'Ubiquity, mais beaucoup plus dans le cas de Pihole par exemple. Pour créer un réseau macvlan, on peut le créer de manière externe, via docker network via ligne de commande ou de manière interne lors de l'écriture d'un script ou dans un fichier docker-compose. Dans ce cas, on va créer le réseau macvlan toto de façon externe : docker network create -d macvlan \ --subnet=192.168.0.0/24 \ --ip-range=192.168.0.144/28 \ --gateway=192.168.0.254 \ -o parent=ovs_eth0 \ toto Notes : (les valeurs sont données à titre d'exemple évidemment) - subnet => on choisit le sous-réseau physique, celui de nos machines. - ip-range => on va définir la plage d'IP couverte par le réseau, un calculateur d'IP sera d'une grande aide pour définir le nombre d'IP qu'on réserve et ajuster à notre besoin. Important !! Il est fortement recommandé que la plage d'IP couverte par le serveur DHCP de votre réseau soit dissociée de la plage d'IP allouée au réseau macvlan. - gateway => c'est notre passerelle, vu qu'on est sur le réseau physique c'est généralement votre box ou votre routeur. - parent => c'est le nom de l'interface physique (tapez ifconfig pour vérifier) On valide et notre réseau est créé. Maintenant, il reste un problème à résoudre ; comme évoqué plus haut, tout conteneur dans ce réseau ne sera pas joignable par l'hôte, quelque soit le protocole (ICMP, TCP, UDP, HTTP, etc...) Une solution existe toutefois, il suffit de créer une nouvelle interface sur le NAS, une interface virtuelle, par lequel il sera aussi normalement accessible que par son interface physique. Pour illustrer, si j'accède à DSM via 192.168.0.100:5000 en temps normal, je pourrai créer une interface avec l'IP 192.168.0.140 tel que DSM sera également accessible à l'adresse 192.168.0.200:5000 Le conteneur pourra donc communiquer avec le NAS via cette nouvelle interface. Pour cela, il suffit de taper quelques lignes de commande en SSH : ip link add <nom_interface_macvlan> link <interface_physique> type macvlan mode bridge ip addr add <IP_virtuelle>/32 dev <nom_interface_macvlan> ip link set dev <nom_interface_macvlan> address <adresse_MAC> ip link set <nom_interface_macvlan> up ip route add <Plage_DHCP_réseau_macvlan> dev <nom_interface_macvlan> Si on veut faire correspondre à l'exemple du réseau ci-dessus : - <nom_interface_macvlan> => un nom au hasard, pas de caractères spéciaux, macvlan_int par exemple, peu importe - <interface_physique> => ovs_eth0 - <IP_virtuelle> => on avait choisi arbitrairement l'adresse 192.168.0.140, on vérifie que cette IP n'est pas dans la plage couverte par le réseau macvlan toto - <adresse MAC> => on peut définir une adresse MAC pour notre interface - <Plage_DHCP_réseau_macvlan> => ça correspond à --ip-range dans le script plus haut Vous devriez maintenant avoir maintenant une nouvelle interface visible en tapant ifconfig en SSH. Vous verrez également cette interface sur l'assistant Synology par exemple. Si vous tentez un ping depuis votre NAS vers un conteneur sur le réseau macvlan, cela devrait marcher. Inconvénient majeur : Au reboot, l'interface sera supprimée et le code précédent devra être réintroduit. Pour éviter cela, on peut créer une tâche dans le planificateur de tâches, à exécuter au démarrage du NAS, qui exécute un script comprenant toutes les commandes ci-dessus (celles commençant par IP). On peut également ajouter un sleep 60 pour temporiser 60 secondes avant l'exécution du script, on s'assure ainsi que la machine a bien démarré avant toute chose. En dernier lieu, il existe un driver dhcp, qui se comporte vraiment comme un périphérique physique, dans le sens où, contrairement au driver macvlan où la plage d'IP est pré-déterminée, le conteneur ira chercher son IP auprès du serveur DHCP du réseau, très probablement la box ou le routeur. On a donc les avantages du driver macvlan sans les inconvénients. Ce driver reste toutefois à l'heure actuelle à l'état de beta, mais affaire à suivre... MàJ : 14/07/2020

Bonjour @Dimebag Darrell, pourras-tu stp nous montrer ton fichier docker-compose.yaml ? j'ai un script qui me fait l'update automatique du pihole 1 fois par mois, il est passé en 5.0 sans même que je n'y prête attention (mais il faut avoir les bons volumes déclarés dans le docker-compose ainsi que les variables d'environnement) ! Le script enchaine dans l'ordre les 4 commandes suivantes : docker-compose pull pihole docker stop pihole-pihole1 docker rm pihole-pihole1 docker-compose up -d pihole Ça doit surement pouvoir s'optimiser, mais cela fonctionne parfaitement. Si nouvelle image pihole:latest il y a , alors elle sera téléchargée et utilisée par le docker au redemarrage.

Finalement une belle réduction sur des IronWolf 4T auront facilité mon choix

Je te conseil de faire quelques recherches sur le fonctionnement des réseaux. Là tu parle de ton réseau local. Or les message ci-dessus parle de ton IP publique. (Je te donne une analogie, Tu souhaites aller dans un hôtel dont tu as réservé la Chambre 201 (IP local), il faut que tu connaisse son adresse (IP Public). Car rentrer "Chambre 201" dans ton GPS (WebDAV sur MAC) ne va pas fonctionner) Pour connaitre ton IP publique, il y a des sites (tape mon ip dans un moteur de recherche) ou dans ta box dans la partie internet... Mais cette IP est souvent dynamique (elle change donc régulièrement) voir les messages précédent. Donc soit ton opérateur te fourni un IP fixe comme par exemple free, Bouygues (Merci @CyberFr)... Soit il faut mettre en place un DynDNS qui va faire le lien avec l'IP dynamique. Ensuite quand tous est en ordre (NAT/PAT dans la box Pare-feu dans le NAS) il faut depuis l'extérieur ce connecter en indiquant comme expliqué dans ton lien: "https://" et suivi de ":5006" (ou du numéro de port que vous avez spécifié lors de l'activation du service WebDAV). donc par ex: https://80.67.169.12:5006 Ou: https://safis.synology.me:5006

Bonsoir, Oui ça doit changer 😉. Le DS209+ peut par exemple être recycler en sauvegarde pour le DS720+ via le paquet Hyper Backup et le protocole R-Sync sur l'ancien NAS. Tu as configuré le Volume en Btrfs? https://www.synology.com/fr-fr/dsm/Btrfs Et si tu veux faire de la visualisation c'est obligatoire. Pour la taille c'est la même chose (il y a le même nombres d'octets, juste la manière de compté qui est différente) Il faut activer le SMB dans "Panneau de configuration > Services de fichiers > SMB/AFP/NFS" (mettre SMB2 (sauf si tu as de vieux OS alors mettre SMB1) en minimum et SMB3 en max) Non tu ne perd pas la garantie. https://www.cachem.fr/ram-nas-synology-ds220-ds720-ds420-ds920/ Tu peux par exemple dans le DS720+ faire un montages des dossier partagé du DS209+ Dans File Station > Outils > Monter le dossier distant > Dossier partagé CIFS Puis copier les données sur le nouveau NAS. Réellement utile? non pas vraiment. Si tu en as besoin, tu le mettre en place plus tard. https://www.cachem.fr/installer-ssd-nvme-nas-synology/ Si c'est le protocole DNLA dont tu parle, Il faut installer le paquet Serveur Multimédia.

Oui les Green sont "increvable" (WD30EZRX) mais il ne sont plus disponible. j'en ai deux de 72000 Heures sans aucune erreur. Il y a aussi la durée de la garantie, 3ans pour les RED. A noter que les gold, sont généralement moins cher que les RED Pro et sont aussi prévu pour tourné en RAID. Et ont une garantie de 5 ans.

Salut @Permafrost et bienvenue 👍

Bonjour @Permafrost, bienvenue à toi sur le forum!

C'est pourtant la fonctionnalité la plus essentielle !

C'est vrai que c'est (très) lourd comme solution pour un petit utilitaire. Il est possible d'installer windows 10 "gratuitement" en téléchargent les .iso chez microsoft (https://www.microsoft.com/fr-fr/software-download/windows10ISO), il fonctionnera sans licence de manière bridé (par exemple tu ne pourras pas changer le fond d'écran🤪😄...), mais parfaitement suffisante. Pour la virtualisation il y a "VirtualBox" qui est gratuit, par contre c'est pas aussi perfectionné/User Friendly que VMware, Parallels Desktop

Bonjour Gourdieu, Deux remarques : Pour un post sur le forum il est conseille de passer par la case présentation, certains ici y sont sensibles. Ensuite ici c'est un Forum Synology et pas Western digital, donc pour avoir des question a tes réponse cela va être compliqué. Mais d’après ce que je sais on peut monter ce que l'on veux comme disque dans ce type de boitier du moment que c’est des WD.

Le port tcp/22 est ouvert si SFTP est activé même si SSH est désactivé. Je ne sais pas si la règle de blocage fonctionne pour "Toutes les interfaces" (sélectionné en haut à droite). Je préfère créer les règles de pare-feu directement sur l'interface concernée ("LAN 1") et ne rien mettre dans "Toutes les interfaces".

Bonjour avec drive il faut ouvrir le port tcp 6690 dans le routeur sinon ça ne marche pas...

Bonsoir , L'application Drive pour PC/MAC utilise le port tcp 6690. Transférez le de votre box a votre NAS et ouvrez le dans le parf-feu du NAS et celà devait fonctionner.