Classement

Ce tutoriel nécessite DSM 6.2.4 ou une version ultérieure. Son but est de permettre à des clients macOS de se connecter à SSH sans avoir à fournir de mot de passe, que ce soit au niveau d'un compte administrateur ou du compte root. Ce tutoriel a été rédigé à partir de la contribution de référence du regretté unPixel : Et à partir d'une documentation émanant de Synology : Comment puis-je me connecter à DSM avec des paires de clés RSA via SSH ? Le tutoriel de unPixel est plutôt orienté PC et fait appel à des outils comme PuTTY, Pageant ou WinSCP totalement inconnus du monde Mac. Dans ce dernier on n'utilise qu'un seul outil, le Terminal. Il y a bien une partie consacrée aux environnements Mac et Linux ajoutée par @Fenrir mais toutes mes tentatives pour l'appliquer ont été vaines, du moins sous macOS Ventura. unPixel lui-même disait avec humour qu'il n'appliquait pas ce tutoriel sur son Mac et utilisait la bonne vieille méthode du mot de passe. C'est sans doute qu'il y avait quelque part un problème de mise en œuvre. Il est vrai qu'Apple, dont la dernière chimère est de de vouloir créer un système théoriquement inviolable, ne cesse de durcir de façon drastique les mesures de sécurité concernant macOS ce qui explique à mon avis les problèmes rencontrés qui sont des problèmes de droits. Bref, vous l'aurez compris, ce tutoriel est né d'une frustration. Pourquoi ça marche sur PC et pas sur Mac ? 😀 J'ai refondu la documentation de Synology et j'ai dû faire appel à leur support technique après avoir constaté qu'on ne pouvait pas l'appliquer en l'état. Le support a accepté d'ouvrir un ticket et a proposé des modifications qui se sont avérées déterminantes. Merci à eux. Facilité du tutoriel : FACILE si l'on maîtrise un peu l'interface en ligne de commande Durée : 20 minutes environ INTRODUCTION L’authentification par clés SSH (Secure Shell) fonctionne en utilisant une clé publique sur le NAS et une clé privée sur l'ordinateur local. La clé publique peut être placée sur n’importe quel serveur distant auquel on souhaite accéder. C'est d'ailleurs ce que nous ferons par la suite. La clé privée reste sur le Mac et n'est jamais communiquée à quiconque : lors du lancement de la session SSH le NAS envoie une requête à l'ordinateur local et c'est lui qui, en confrontant la clé publique transmise par le NAS et la clé privée qu'il détient, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non. Dans ce dernier cas l'ouverture de session est bien entendu refusée. Comme l'a dit @.Shad. que je me permets de citer « En gros la clé publique c'est ta réservation au restaurant, et la clé privée c'est le fait de prouver ton identité. ». SSH utilise des algorithmes de cryptage puissants pour sécuriser la communication entre le client et le serveur. Il garantit que les données transmises sur le réseau ne peuvent pas être interceptées ou modifiées par des entités malveillantes. Remarque : la mise en œuvre du tutoriel implique de faire des allers-retours constants entre le Mac (via l'application Terminal) et DSM. Suivez bien les instructions qui sont données car elles vous indiquent où vous vous trouvez et ne vous perdez pas ! N'hésitez pas à m'indiquer les difficultés que vous aurez pu rencontrer afin que j'améliore le tutoriel. De toute façon, si vous rencontrez des problèmes qui vous obligent à tout recommencer, la marche à suivre est décrite en fin de document. N'hésitez pas à m'en faire part là encore. Il est vivement recommandé pour des raisons de sécurité de changer le port par défaut de SSH dans le panneau "Terminal & SNMP" du Panneau de configuration. À chaque fois que vous verrez une commande "ssh ... -p XX" par la suite, remplacez XX par le port que vous avez spécifié. ATTENTION : N'ouvrez pas ce port sur votre box Internet car il doit être utilisé en local pour des raisons de sécurité une fois de plus. Si vous devez absolument vous connecter à SSH sur le NAS hors du réseau local utilisez un VPN. LANCEZ L'APPLICATION TERMINAL SUR LE MAC Inutile de la télécharger, elle est présente sur tous les Mac. Dans tout ce qui suit vous devrez remplacer "username" par par votre nom d'utilisateur sur le NAS et sur le Mac. Ils peuvent être différents (c'est le cas chez moi). Il faut faire attention au contexte dans ce cas afin d'appliquer la bonne substitution : Terminal Mac --> usernameX, SSH --> usernameY. GÉNÉRATION DES CLÉS On génère une paire de clés SSH à partir du Terminal du Mac avec la commande ssh-keygen en spécifiant l’algorithme de chiffrement désiré. J'ai retenu ed25519 qui est le plus sûr à ce jour : ssh-keygen -t ed25519 Vous êtes invité à saisir le chemin d'accès au dossier qui contiendra la clé publique et la clé privée. Laissez l’emplacement par défaut, à savoir : /Users/username/.ssh/id_ed25519 en appuyant sur Entrée. Vous êtes invité à saisir une phrase de passe (passphrase) pour la clé privée CE QUI EST VIVEMENT RECOMMANDÉ VOIRE INDISPENSABLE. Vous pouvez cependant l'ignorer en appuyant deux fois sur la touche Entrée si vous ne souhaitez pas saisir de passphrase à chaque fois que vous utilisez la clé. @Fenrir recommande, je cite « de protéger la clef avec un super mot de passe » et « de renouveler la clef de temps en temps (1 fois par an c'est largement suffisant) en pensant bien à supprimer la clef publique de l'ancienne ». La clé publique (id_ed25519.pub) et la clé privée (id_ed25519) ont été crées sur le Mac dans le dossier choisi plus haut. Il est possible de stocker la passphrase dans le Trousseau d'accès du Mac en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins : La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement tronquée à 10 caractères dans le Trousseau... Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté. Dans tous les cas de figure il est nécessaire pour se connecter à SSH de connaître la passphrase, il ne faut pas faciliter la tâche des intrus en la stockant quelque part sauf dans des coffres sécurisé comme Vaultwarden ou 1Password qui ont leur propre mot de passe et ne sont pas débloqués automatiquement à l'ouverture de session. Vous devrez par la suite copier la clé publique (id_ed25519.pub) dans le dossier home de votre compte administrateur sur le NAS en utilisant File Station. Cette clé se trouve actuellement dans un dossier masqué sur le Mac (.ssh est masqué car précédé d'un point). C'est pourquoi ce dossier n'apparaîtra pas dans la fenêtre de File Station. Pour contourner le problème, le plus simple est d'utiliser le terminal. Il faut se positionner dans le dossier .ssh sur le Mac : cd ~/.ssh puis copier la clé à la racine de son home sur le Mac : cp id_ed25519.pub ~/id_ed25519.pub ENREGISTREMENT DE LA CLÉ PUBLIQUE DANS VOTRE COMPTE ADMINISTRATEUR SUR LE NAS Connectez-vous à DSM avec votre compte administrateur. Accédez à File Station. Dans votre dossier home créez un sous-dossier nommé .ssh (n'oubliez pas le point au début de .ssh). Transférez la clé publique id_ed25519.pub (qui est désormais visible) dans le dossier .ssh en utilisant l'onglet "Charger" de File Station comme illustré ci-dessous (lionel est mon dossier home). Il faut ensuite accéder au dossier home sur le Mac avec le Terminal et supprimer la clé qui s'y trouve afin de faire le ménage (on l'avait déplacé là afin qu'elle soit visible). cd ~/ rm id_ed25519.pub CONNEXION SSH ADMINISTRATEUR AVEC LA PAIRE DE CLÉS Connectez-vous à SSH avec votre compte administrateur sur le NAS. Un message d'avertissement apparaît : The authenticity of host '[192.168.1.2]:22 ([192.168.1.2]:22)' can't be established. ED25519 key fingerprint is SHA256:4nLwr4EVpCwt/jjH9kIEXDUaILvWhVXCzbDCzJv4z66. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? Ce message apparaît lors de la première connexion SSH ce qui est normal. Répondez simplement 'yes'. Warning: Permanently added '[192.168.1.2]:22' (ED25519) to the list of known hosts. Après, vous pouvez être déconnecté auquel cas vous aurez le message : Connection closed by 192.168.1.2 port 22 Il vous faut vous reconnecter dans ce cas. Si vous avez le message : username@192.168.1.2's password: On vous demande simplement votre mot de passe à la suite de quoi vous serez déconnecté de toute façon ! Pour des raisons qui m'échappent, les deux cas se sont produits lors des tests que j'ai réalisés. Pour faire simple dans tous les cas de figure reconnectez-vous ! Accédez au dossier .ssh précédemment créé sur le NAS : cd ~/.ssh Ajoutez la clé publique à un fichier, authorized_keys qui sera créé à cette occasion : cat id_ed25519.pub >> authorized_keys Le dossier .ssh sur le NAS contient désormais deux fichiers : authorized_keys et la clé publique id_ed25519.pub. Se positionner dans son home sur le NAS cd ~/ Puis taper les instructions suivantes où 711 donne les droits en lecture et en écriture au seul propriétaire (vous) et le droit d'exécution à tout le monde : chmod 711 .ssh chmod 711 .ssh/authorized_keys chown -R username .ssh/ Où username est votre nom d'administrateur sur le NAS. Ceci afin d'être sûr que les droits sur ces dossiers sont conformes aux règles. Ces instructions sont très importantes. La première partie du tutoriel est terminée. Vous pouvez maintenant vous connecter à SSH à l'aide de votre compte administrateur sans avoir à saisir un mot de passe. Mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés (ce qui, je le rappelle, est vivement recommandé). Par exemple : ssh username@192.168.1.1 -p XX Enter passphrase for key '/Users/username/.ssh/id_ed25519':_ CONNEXION SSH ROOT AVEC LA PAIRE DE CLÉS Sur le NAS, se connecter à SSH en tant que root à partir de votre compte administrateur en tapant "sudo -i". Soyez conscients qu'en tant que root vous avez tous les droits sur le NAS et qu'une erreur sur une commande peut provoquer des dommages irrémédiables. En cas de doute, il est préférable de copier les commandes du tutoriel et de les coller dans la session SSH. Exécutez la commande mkdir /root/.ssh afin de créer le dossier .ssh s'il n'existe pas. Il peut avoir été créé auparavant si des clés d'administrateurs autres que vous ont été consignées. Vous aurez dans ce cas le message d'erreur : mkdir: cannot create directory ‘/root/.ssh’: File exists qui est sans gravité. Accédez à votre propre dossier .ssh sur le NAS qui se trouve dans votre dossier home : cd /volume1/homes/username/.ssh où volume1 est le volume dans lequel se trouve le fichier id_ed25519.pub et username votre nom d'utilisateur sur le NAS. On crée le fichier authorized_keys de root s'il n'existe pas et on ajoute la clé publique id_ed25519.pub. cat id_ed25519.pub >> /root/.ssh/authorized_keys Entrez la commande chmod 700 -R /root/.ssh afin d'être certain que tout ce qui se trouve dans le dossier .ssh n'est accessible qu'au compte root et ceci est très important (700 donne l'exclusivité de tous les droits à root). ON REDÉMARRE LE SERVICE SSH POUR QUE LES CHANGEMENTS SOIENT PRIS EN COMPTE DSM6 : synoservicectl --reload sshd DSM7 : systemctl restart sshd Vous pouvez maintenant vous connecter en tant que root sans avoir à saisir de mot de passe mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés comme indiqué plus haut. Par exemple : ssh root@192.168.1.1 -p XX Le tutoriel est terminé. MODIFIER LA PASSPHRASE Lancer le Terminal sur le Mac et taper : ssh-keygen -p -f ~/.ssh/id_ed25519 On demande l'ancienne phrase de passe puis la nouvelle. Il faut parfois relancer le service SSH pour que le changement soit pris en compte. Le plus simple est d'essayer de se connecter en tant que root avec la nouvelle passphrase et, si elle est refusée, de saisir l'ancienne. Les changements n'ont pas été pris en compte dans ce cas et il faut utiliser la commande de redémarrage du service SSH indiquée ci-dessus (celle-ci nécessite les droits root). EN CAS D'ERREUR LORS DE LA MISE EN ŒUVRE DU TUTORIEL QUI VOUS OBLIGE A TOUT RECOMMENCER NB : Ces instructions ne s'appliquent que si vous êtes le seul administrateur du NAS ou si vous avez créé une session SSH avec paire de clés pour la première fois. Si un historique préexiste n'hésitez pas à me contacter. Connectez-vous à SSH en tant que root sur le NAS et supprimez son dossier .ssh : rm -R .ssh Connectez-vous à SSH avec votre compte administrateur sur le NAS et supprimez le dossier .ssh qui se trouve dans votre dossier home : rm -R .ssh Lancez l'application Terminal et supprimez le dossier .ssh qui se trouve dans votre dossier home sur le MAC : rm -R .ssh VOUS AUREZ COMPRIS QUE CES ACTIONS SONT IRRÉVERSIBLES ! CRÉATION D'UN FICHIER DE CONFIGURATION SUR LE MAC Un fichier de configuration permet de définir des profils par défaut (hosts) en renseignant l'adresse IP du serveur, le nom d'utilisateur sur le serveur, le port utilisé par SSH et le chemin d'accès à la clé privée. Ainsi au lieu de taper ssh username@192.168.1.1 -p XX pour initier une session SSH, il suffit de taper ssh username Il est possible de créer dans le fichier de config plusieurs hosts avec des adresses IP différentes ce qui permet de se connecter à des serveurs distincts. Ne créez un fichier de config qu'après de la mise en œuvre complète du tutoriel lorsque vous serez sûr que tout fonctionne. # point d'entrée : tapez ssh server_1 pour vous connecter Host server_1 HostName 192.168.1.1 # nom d'utilisateur sur le serveur User username Port XXX # Chemin d'accès à la clé privée IdentityFile ~/.ssh/id_ed25519 Host nas HostName ndd.fr User cyberfr Port XXX IdentityFile ~/.ssh/id_ed25519 Host root HostName 192.168.1.2 User root Port XXX IdentityFile ~/.ssh/id_ed25519 Le fichier de configuration doit être placé sous le nom "config" (sans extension) dans le dossier .ssh de votre home où résident déjà les clés publiques et privées id_ed25519 et id_ed25519.pub. Le plus simple est de le rédiger dans un traitement de texte (TextEdit ou BBEdit) puis de le déplacer au bon endroit. Il vaut mieux respecter le canevas des exemples donnés ci-dessus et ne pas utiliser de tabulations (je n'ai pas essayé donc je ne sais pas si elles sont acceptées 😀).

Bon, le [TUTO] Se connecter à SSH avec une paire de clé sur Mac est réapparu 😀

En complément de ce que dit @.Shad., tu peux confier la clé à un gestionnaire de clés intégré mais le problème est que le volume est monté automatiquement lors du démarrage de DSM. C'est pourquoi je préfère monter le volume lorsque j'en ai besoin. J'ai signalé il y a quelque temps qu'un container démarrait lorsque j'allumais le NAS alors qu'il était réglé sur "--restart never" qui est la valeur par défaut, valeur que je vois dans les propriétés du container. Mon problème venait justement du fait que ce container est associé à un volume crypté et que si ce dernier n'est pas monté, cela provoque bien entendu une erreur. C'est donc un bug de DSM et j'ai été obligé pour le contourner d'écrire un script pour arrêter manuellement le container. Suite à ce bug que j'ai signalé au support, "--restart never" s'est transformé en "--restart unless-stopped" dans Container Manager.

Refonte du tutoriel prévue pour Pâques je pense, j'ai revu le compose et l'architecture pour faire quelque chose de beaucoup plus simple. La nouvelle version sera plus directe, et à l'image de mon récent tutoriel de sécurisation pour DSM 7, j'intégrerai des balises spoilers pour ceux qui veulent plus de détails et remarques.

Bonjour @Shino, soyez le bienvenu sur ce forum. Pour bien commencer, il faudrait en priorité appliquer le tuto sur la sécurisation de votre NAS (section des tutoriels). Vous êtes sûrement tombé dessus si vous avez parcouru le forum et peut être déjà mis en application.

Salut, Je ne pense pas car il avait toujours le statut "démarré depuis 45 jours" alors que les autres avaient bien sûr +/- 1 minute. Finalement, j'ai redémarré le NAS qui... n'a pas redémarré. Ensuite un shutdown comme un bourrin avec le bouton Power. Finalement, après une petite suée ;-), il a redémarré et... Flaresolverr aussi ! Ouf. Georges

Welcome 🙂

Bienvenue parmi nous !

Bonjour et bienvenue sur le forum @Cindy Sauvage ! Belle machine que ce DS 423. N'hésite pas à poser des questions si nécessaire.

Bonjour et bienvenue sur le forum @Will31 !

Je réponds à mon post car j'ai enfin trouvé mon erreur!! Comme souvent c'était une simple erreur et je cherchais compliqué... J'ai tout désinstallé et réinstallé. J'ai procédé par étape en vérifiant que mon raspberry envoi bien une donnée $_POST avec la librairie resquests. import requests url = 'http://monsite.com/mon_fichier_qui_gere_l_insertion_BDD.php' myobj = {'temperature':'46.4', 'humidite': '55.4'} # Utilisez des points au lieu de virgules pour les décimales x = requests.post(url, data=myobj) print(x.text) J'ai affiché cette valeur sur la page web. <?php // ici on récupère la variable passée en $_POST ou en $_GET echo $_POST [ 'temperature' ] ; echo $_POST [ 'humidite' ] ; print_r($_GET); print_r($_POST); ?> Une fois cela fait, l'erreur ne pouvait-être que côté serveur. En me disant ça j'ai compris que même si l'information vient d'un raspberry, elle est traité en "localhost" par le serveur. Donc il ne faut pas mettre autre chose que "localhost" dans le nom de l'host lors de la connexion à la BDD... Même l'adresse IP publique du serveur ne fonctionne pas pour info. Voila voila...

@CyberFr, j'abonde dans le sens de @.Shad.. Ce n'est parce qu'un tuto n'a pas de réponse qu'il n'est pas lu ou qu'il n'a pas été mis en pratique par certains, membres ou pas. Et dans le cas présent, il aurait été au moins utile @MilesTEG1.

@CyberFr C'est très dommageable, parfois certains tutos mettent du temps à trouver leur public, d'autres ne le trouvent jamais. Pourtant je ne vois pas pourquoi priver la communauté d'un travail qui m'a pris du temps, ici 0 réponse 1900 vues 😄 :

Bon j'ai finalement récupérer l'accès internet, j'ai fait une mise a jour manuel mais cela n'a rien changé, j'ai remis mes paramètre DNS en DHCP puis passer la date et heure en manuel et après plusieurs tentative de sycro avec les serveur time cela a fini par fonctioner et la connexion est revenue. Je ne sais pas réellement si c'est la maj qui a régler le problème, je vais remettre toute ma config réseau comme je l'avais avant en espérant que je n'ai pas de nouveau problème 🙂

OK, mais comme tu me le fais justement remarquer dans les infos Donc, Je vais pas tenter le diable, on va suivre les conseils de M Syno😉, bien que connecté pour recevoir les mises à jour, il me sert uniquement de sauvegarde horaire/journalière perso et je n'ai pas envie de me retrouver dans la situation de mon 210 qui faisait semblant de fonctionner alors qu'il se vérolait pour cause de carte mère endommagée. Merci pour ta réponse.

Ou pour l'update 6 😅

Non, pas nécessaire. Oui, mais commence par utiliser le port par défaut 1194 en UDP. Si ça fonctionne tu pourras essayer de changer. ??? Non tu laisses faire tu ajoutes un 6 après proto udp donc proto udp6

Aucun des deux. Le système le plus sûr pour protéger les données est la sauvegarde. btrfs t'apportera plus de souplesse pour les snapshots (si utilisés). Il n'y a pas de contrôleur RAID sur les NAS Synology, c'est juste du RAID logiciel. Prends le temps de t'informer sur le RAID : https://fr.m.wikipedia.org/wiki/RAID_(informatique) Le plus important dans tes choix est de savoir quel système de sauvegarde tu vas utiliser.

Comme ça, le jour où ton NAS se prend un cryptolocker, tous les fichiers du disques 1 et leurs sauvegardes sur le disque 2 sont cryptés 😅 Utilise un disque USB externe pour faire les sauvegardes, et déconnecte-le du NAS entre les sauvegardes.

ça ne fonctionne que si tu fais du DHCPv6. Normalement il faut mettre son préfixe à cet endroit mais en SLAAC tu ne peux pas le rentrer. En tout cas chez moi cette cette case n'est pas cochée et je me connecte en IPV6 sur Openvpn.

Bienvenue @maximax88

Bienvenue parmi nous, projet super sympa, au plaisir de pouvoir t'aider.

Bonsoir, Je ne savais pas qu'il y avait des FAI qui ne faisait que l'IPV6 publique. Je ne suis pas certain de pouvoir t'aider mais ce qui m'étonne c'est que ton test IPV6 montre une IPV4 et je ne pense pas qu'il affiche ton IPV4 privée. Sinon personnellement j'essaierai ceci : 1 / utilise le port UDP 1194 pour Openvpn (autorise ce port dans ton pare feu) 2/sur le nas tu décoches le serveur DNS, c'est celui du DHCP qui sera utilisé (configuré dans ta box) et au dessus tu renseignes l'IPV6 privée de ta box. 3/Une fois la config exportée tu la renseignes avec : remote "MonIPV4publique" 1194 remote "MonIPV6publique" 1194 et proto udp proto udp6 Si ça ne marche pas avec l'IPV4 indiquée par le test IPV6 tu attends plusieurs minutes et le VPN basculera tout seul vers l'IPV6. Si c'est le cas tu ne garderas que l'IPV6. Je ne te garantie pas que ça fonctionnera mais ça vaut la peine d'essayer. Bonne chance

@skelton Pas de problème, vous pouvez créer un nouveau groupe et un nouveau volume sur votre disque de 4To. A charge ensuite de créer de nouveaux dossiers partagés sur ce nouveau volume, ou de déplacer des dossiers existants du volume 1 vers le volume 2.

Votre disque est bien là, et votre stockage total est réparti sur 2 volumes de 7To chacun. Vous ne pouvez pas voir les disques dans File Station. Seulement les dossiers partagés. C'est à vous à répartir vos dossiers partagés sur les volumes à partir du panneau de configuration.

RESOLUE excellent merci pour tous sa marche et sa va vite... Meme plus le temps d'attendre... 😄

Bonjour @Darkangel, on peut mettre 16Go de Ram sur un DS918+ d'après certain site, exemple https://www.cachem.fr/16go-ram-synology-ds918/

Bonjour à tous, Nous allons voir dans ce tutoriel comment mettre en place rapidement un certificat Let's Encrypt avec la méthode acme.sh en utilisant l'api Ovh en Docker, si vous êtes rapide, en 10 minutes c'est en place. Pourquoi en docker ? Car je suis contre la pollution du DSM, des corruptions par update, mais aussi par simplicité et rapidité. 1) On commence par la création de clé d'api chez ovh : https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/* On remplit donc le formulaire, pour "Validity" (1) on choisit "Unlimited", pour "Rights" (2) on remplace dans les champs "mydomain.com" par le vôtre et dans "Restricted IPs" (3), on rajoute son IP afin qu'en cas de vol des clés, elles ne puissent être exploitées et votre domaine détourné. (NB : Si vous n'avez pas une IP fixe, on passe ce dernier point) On garde les clés retournées en résultat sous la main pour la suite. 2) Passons maintenant au docker : A) On commence par la création d'un dossier "Acme" dans le dossier docker. B) La création du fichier de config : On crée avec l'éditeur de texte du DSM (Codage UTF-8) le fichier "account.conf" à la racine de notre dossier "Acme" contenant : LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='XXXXXXX' SAVED_OVH_AS='XXXXXXX' SAVED_OVH_CK='XXXXXXX' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' On remplace dedans le contenu des 3 variables "SAVED_OVH_**" par nos clés obtenues précédemment par OVH. C) La création du docker : On va mettre un petit peu de code pour la création du docker et son actualisation journalière via le gestionnaire de tâche... Panneau de configuration / Planificateur de tâches / Créer / Tâche planifiée / Script défini par l'utilisateur Utilisateur : Root On programme pour une exécution par jour la nuit (5h c'est bien) Exécuter la commande : docker pull neilpang/acme.sh:latest docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart unless-stopped neilpang/acme.sh:latest daemon On exécute manuellement la tâche une première fois pour la création du docker. C Bis) Le docker-compose.yml : version: "2.1" services: acme: cpu_shares: 10 mem_limit: 128M container_name: Acme network_mode: bridge labels: - com.centurylinklabs.watchtower.enable=true volumes: - /volume1/docker/Acme:/acme.sh:rw restart: unless-stopped image: neilpang/acme.sh:latest command: daemon D) Création du certificat : Avec le planificateur de tâche en exécution unique (cf point 2C) ou en ssh (root) en remplaçant "mydomain.com" : docker exec Acme sh -c "acme.sh --issue --keylength 4096 -d 'mydomain.com' -d '*.mydomain.com' --dns dns_ovh" Il n'y a rien à détailler pour expliquer cette commande, le keylenght peut être, on double la valeur par défaut qui est aujourd'hui considérée comme faible à 2048. /!\ Renouvellement automatique du certificat sans action de votre part 3) Installation des certificats : A) Importation manuel : Vos certificats seront disponibles directement dans filestation "docker/Acme/votredomaine" et ce qui nous intéresse dedans : Certificat : mydomain.com.cer Clé privée : mydomain.com.key Certificat intermédiaire : ca.cer On va maintenant faire leur import manuellement, dans "Panneau de configuration/Sécurité/Certificat". En cas d'import manuel, vous pouvez activer la notification mail, mais cette action se réalise toujours 1 mois avant expiration : https://github.com/acmesh-official/acme.sh/wiki/notify B) Déploiement automatique : NB : Faire un premier déploiement manuel avant le déploiement automatique, afin de bien le mettre par défaut et supprimer celui de synology par défaut. 1) Création d'un compte que l'on rajoutera dans le groupe admin, on lui mettra aucun acces à tous les dossiers et refuser à toutes les applications, on active pas la double authentification qui sera inutile. 2) On ré édite notre fichier "account.conf" créé au point 2B, on y rajoute : SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='nom utilisateur' SAVED_SYNO_Password='le password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='description du certificat mise dans le DSM' 3) Ensuite une fois les modifications faites, avec le planificateur de tâche en exécution unique (Cf point 2C) ou en ssh (root) : docker exec Acme sh -c "acme.sh --deploy -d 'mydomain.com' --deploy-hook synology_dsm" Guide officiel : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide Pour d'autres API que ovh : https://github.com/acmesh-official/acme.sh/wiki/dnsapi 😉

Bonjour, Je viens de prendre un compte premium 1fichier. Je viens d'installer le fichier host sur mon ds223 avec clé api et ça marche impec 😊. Je poste donc pour dire merci Mathieu et longue vie à ton appli.

Salut, Alors les détails : J'ai paramétré la sécurité du Nas : (anti-brut force, double authentification, et deux trois réglages) Pour l'accès j'ai activé Quickconnect, j'ai fait une redirection dyndns avec un domain.synolgy.me et changer les port par defaut de dsm Cela fonctionne bien je peux accéder à dsm depuis l'exterieur avec domain.synology.me ou avec une redirection dns sur un nom de domain perso. DSM et les outils audio station, synology contacts, note station, synology calendar pas de problème, je fais des partages entre utilisateurs c'est assez intuitif Mias dès que j'installe Plex ou une appli doker comme vaultwarden j'ai beau m'accompagner des tutos, (les étapes semble logiques), impossible d'accéder à ces briques : la page repond pas PUNAISE : En revérifiant dans sécurité j'avais activé ou c'était par défaut le firewall, ba forcement avec une règle ca marche mieux !! Désolé: les gens vérifié le firewall, dans les paramétrages - sécurité

Le fichier host ne gère aucun téléchargement, la seul chose qu'il fait c'est fournir une url de téléchargement à l'application DL Station. Si il y a un problème c'est entre DL Station et les serveurs de 1fichier Si ça te dit on peut debuger en MP. Si tu n'a pas de fichier perso sur ton compte tu peux me donner ta clé d'API en message privé pour que je fasse des essayé, tu en génereras une nouvelle une fois que nous aurrons trouvé. On peut sa caller une scéance de debug par discord aussi si nécéssaire.

@Steph Bollo merci de ne pas intervenir dans une discussion sans prendre le soin de lire les réponses et en comprendre le contexte. Par ailleurs, je vous invite à ouvrir un sujet dédié à votre problème. @Darkangel Les disques sont bien extractibles à chaud.

Il faut désactiver le disque défectueux dans le gestionnaire de stockage avant de le retirer.

Pour ma part, j'ai effectué aujourd'hui la réinitialisation en configuration usine de mon RS422+. J'avais une grosse sauvegarde Hyper Backup de 1.5 To de données "importantes", tout a été restauré sans erreur (sauf le service d'application Synology, mais ça n'a pas eu l'air d'avoir la moindre incidence car le service tourne normalement). Pour les données dispensables, elles étaient stockées sur des disques externes, en format brut, là ça copie... c'est long 😄 Première chose que j'ai vérifiée, la taille de la partition, c'est ok de ce côté-là, 7.9Go, je devrais être tranquille de ce côté-là. Et j'ai profité de la réinitilisation pour chiffrer mon volume. Ah, mes tâches récurrentes de tests SMART avaient disparu, alors que j'avais coché la restauration de la configuration du planificateur de tâches, étrange.

et on s'y prend comment pour modifier les autorisations d'un compte dans MySQL ? (j(utilise phpMyAdmin pour l'administration) Evidemment puisque mon instance FreshRSS hébergée en direct sur le NAS fonctionne Ah je vais tester ça de suite je n'ai utilisé que des connexion locale jusqu'ici **** EDIT **** Ah non c'était déjà coché. A la réflexion le socket était en écoute sinon je ne pouvais pas me connecter même en localhost. La preuve : ~> sudo lsof -i :3307 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mariadbd 18603 mysql 26u IPv4 131189062 0t0 TCP *:3307 (LISTEN) Et j'ai bien pensé à ajouter une règle dans le firewall pour autoriser les connexions entrantes en provenance de l'IP du container Docker

Bonsoir, Ayant formaté les disques de mon Syno pour gagner une partition root de 8Go au lieu des 2 pauvres giga, j'ai du refaire mes conteneurs, dont ACME. Et à l'étape 3B, j'ai une erreur : 20:08:56 - Script pour paramétrer le déploiement automatique des certificats sur le Syno. 20:08:56 - Exécution de la commande... [Mon Mar 25 19:08:56 UTC 2024] Logging into 172.20.0.1:19810 [Mon Mar 25 19:08:57 UTC 2024] Getting certificates in Synology DSM [Mon Mar 25 19:08:57 UTC 2024] Unable to find certificate: mon-ndd.ovh - Certificat Wildcard Lets Encrypt & $SYNO_Create is not set [Mon Mar 25 19:08:57 UTC 2024] Error deploy for domain:mon-ndd.ovh [Mon Mar 25 19:08:57 UTC 2024] Deploy error. 20:08:57 - Script de création du certificat wildcard terminé En regardant les réponses du sujet, je me suis dit que ça devait être un problème de nom de certificat. Et oui, le nom de la variable SYNO_Certificate doit être identique au nom mis dans DSM, sinon on a l'erreur précédente. Bref, tout fonctionne bien maintenant 😉 Pour le peu que je vais me servir du certificat de mon .ovh dans DSM 😅

À chaque fois que j'ai contacté le support Synology pour signaler un bug dans DSM ça a été la même chanson. Monsieur, c'est à vous de faire les tests, Monsieur, mettez le NAS à disposition de nos équipes, Monsieur, envoyez-nous vos journaux, etc. Je ne trouve pas normal, et d'ailleurs je l'ai signalé, que suite à la découverte d'un bug, ce soit au client de faire le boulot.

Je viens de faire le contrôle chez moi, et j'ai un md0 à 2,3 Go, donc je pense que pour toi c'est bon

Désolé d'avoir contrarié Lelolol !! voilà c'est fait

@MilesTEG1, sisi je garde le macvlan, pas le choix sur DSM, mais j'intégre SWAG aussi dans un bridge personnalisé dans lequel se trouve Authelia, ainsi rien à changer dans les fichiers de configuration d'authelia, on peut continuer à utiliser le nom de conteneur.

Epilogue... Tout d'abord merci @firlin pour l'aide apportée. Mais de 1) oui j'étais pressé, et de 2) je tenais à rester le plus loin possible du support Synology, car c'est grâce à leurs "bons conseils" que mes dernières opérations (principalement la migration de mon DS920+ vers un DS923+) ont failli tourner au désastre. Je me suis donc lancé dans la reconstruction totale, méthodique et manuelle de mon DS923+, sans importer le moindre paramètre du DS920+. Et là, question taux de transfert, je n'ai pas été déçu: on est à 500Mb/s minimum entre PC et NAS, avec des pointes à plus de 1Gb/s alors que mes valeurs MTU sont encore à 1500... ça promet ! J'étais ravi, et évidemment restaurer mes données à cette vitesse n'a été qu'une formalité. J'ai finalisé ma configuration en réinstallant Tailscale et en relançant un backup distant. Je sauvegarde mes données sur un site externe, sur un DS218Play qui est derrière un routeur 5G. Mon opérateur ne me permettant pas de faire du port forwarding, j'utilise Tailscale pour contourner le problème. Et ça marche plutôt bien ! Tailscale est installé sur le DS218Play qui reçoit le backup, sur mon PC (pour administrer le DS218Play distant), et donc pour terminer, sur le DS923+ pour lui permettre de communiquer avec la cible du backup. Mais deux jours plus tard, j'ai failli m'étrangler lorsqu'en voulant relancer une copie du PC vers NAS, j'ai constaté que mon débit maximum en copie était retombé à 140Mb/s... Qu'est-ce qui avait changé entre temps ? Rien, à par Tailscale... Et là instantanément je me suis rappelé que 140Mb/s devait plus ou moins être le débit maximum lorsque l'on passe à travers les serveurs Tailscale, mais en ne comprenant pas comment la présence de Tailscale pouvait être en mesure d'impacter une copie locale entre un PC et le NAS ? Et pourtant cela semble bien être le cas, lorsque Tailscale est installé sur les deux machines source/cible. Tailscale semble littéralement prendre ma copie locale "en otage", et cela se complique encore avec un problème qui relève manifestement du DNS... Tout ça pour dire que: Copie du PC vers \\DS923\Video ==> débit maximum de 140Mb/s Copie des mêmes données du PC vers \\[IP.DE.MON.NAS]\Video ==> débit maximum de 1000Mb/s CQFD. J'ai simplement adapté mes mappings pour résoudre le problème (en utilisant l'IP du NAS plutôt que son nom DNS).

@MilesTEG1 Si Portainer central est installé sur A, et que tu te connectes à B via Portainer agent, les données sont stockées sur B. Portainer n'est qu'une interface plus évoluée de Container Manager. Ce que tu pourrais rencontrer par contre ce sont des stacks orphelines lors de la restoration, si Portainer n'arrive pas à refaire lui-même le lien avec un dépôt Git.

Petite MAJ 🙂 J'ai lancé les sauvegardes temporaires, ça prend du temps 😅 Cependant, je n'ai pas eu d'erreurs sur les sauvegardes à destination de l'Asustor, seules les sauvegardes à destination du cloud K-Drive me font une erreur de partition système : Je ne comprends pas trop pourquoi... Ça m'a l'air assez aléatoire en prime, car parfois je n'ai pas d'erreurs... Bref, j'ai coupeécertains services comme Synology Photos, et Surveillance Station, pour éviter les données de dernières minutes à sauvegarder. Faudra que je fasse pareil avec Container Manager, pour faire la sauvegarde des conteneurs. J'ai aussi remarqué que quand Vitual Machine Manager est installé, avec donc Open vSwitch activé, la sauvgegarde de la configuration du Syno ne contient pas tout : Dès lors que Open vSwitch est désactivé, tout est bien sauvegardé. Pour ne pas être embêté, la semaine dernière j'ai déplacé le reverse proxy SWAG sur un NUC, et aussi Vaultwarden. Il va me falloir faire de même pour ma deuxième instance de Adguard Home. Ainsi je n'aurais plus besoin de macvlan sur le NAS, et ça m'ôtera un problème potentiel après. J'ai aussi sorti le disque 3 du NAS, celui qui contient les sauvegardes des instances proxmox, et aussi celui qui potentiellement à une partition système de 8Go. Voilà voilà @+ quand j'aurais d'avantage de nouvelles

Je viens de regarder ton lien et ce que je lis me fait dire que ça ne peut en aucun cas venir des disques. Il est absolument impossible que 6 disques tombent en panne simultanément sans qu'il y ait une cause externe. Problème de NAS ? d'alimentation (surtension) ? C'est beaucoup plus probable. Tu ne devrais pas trop t'inquiéter pour tes disques.

Merci pour votre aide. Finalement j'ai essayé de télécharger et mettre à jour à nouveau la dernière version DSM 7.1.1-42962 update 6 ..... SURPRISE !! tout s'est bien déroulé avec mises à jour des paquets et tout semble refonctionner maintenant ... ouf !! Merci encore et bon courage à vous

Si ej me trompe pas tu as un DS723+ donc les chariot de ceux-ci sont compatible avec un SSD. En effet sur les chariot tu as 4 trous pour fixer les SSD dessus, à vérifier mais cela doit fonctionner

Bonjour à tous Je viens de m'inscrire sur le forum. En fait, ça fait quelques années déjà que je le parcours, mais j'ai décidé de m'inscrire car j'ai une question (j'ai déjà créé un post). Donc voilà, j'ai la quarantaine, je vis dans le sud de la France. J'ai un Synology DS118 depuis 6 ans, avec un HDD WD 6 To, et je vais avoir un DS224+ dans très peu de temps. Mon métier ne conserne pas le milieu de l'informatique, mais c'est un domaine qui me plait et j'adore apprendre plein de trucs/bidouiller. Actuellement, je me sers de mon NAS principalement pour du stockage de données perso et pour PLEX. Je vais bientôt me lancer dans Docker et Home Assistant. Au plaisir de vous lire.

En voici un archive.zip

@Vista1967 En temps normal j'essaie de lancer les images de mon côté, mais je ne le fais pas avec des conteneurs qui demandent des privilèges élevés et pour des images aussi peu répandues. Si tu cherches un soft qui permet de faire du boot network PXE sous Docker, regarde du côté de netbootxyz par Linuxserver : https://docs.linuxserver.io/images/docker-netbootxyz/ Beaucoup mieux documenté et pour l'avoir installé chez moi ça fonctionne très bien.

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