Classement

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

Préambule Ce guide a pour but de permettre à tout un chacun de centraliser la gestion de ses conteneurs sur une seule et même instance Docker, et ce de manière sécurisée. Sur une distribution Linux classique ou même Windows il est possible d'exposer une instance Docker via TCP, donc le rendre accessible sur un port de la machine hôte, 2375 en non-sécurisé, 2376 par TLS. De manière générale c'est quelque chose qu'on évite, car Docker possède des privilèges élevés sur sa machine hôte, c'est donc une source de contamination potentiellement dévastatrice. En prenant soin de placer un certain nombre de garde-fous, et en maîtrisant les points de sécurisation abordés dans les tutoriels références du forum (en premier lieu celui sur la sécurisation), l'idée devient tout à fait envisageable. Il y a deux avantages majeurs à cette méthode : - Elle est applicable à n'importe quelle machine, votre NAS, un PC sous Linux, un micro-processeur type Raspberry, un VPS, un dédié, etc... - Elle permet de s'affranchir des limitations de certains OS, typiquement DSM. On peut tout à fait exposer le port 2376 d'un NAS Syno sans passer par un proxy sauf qu'à chaque redémarrage les modifications sont effacées et vous devrez de nouveau exposer le port. Un script pourrait sûrement tout à fait se charger de la tâche, reste que l'on touche à des fichiers systèmes sensibles, je suis partisan du fait de garder un DSM "stock" pour éviter des problèmes lors des mises à jour et des incompatibilités/bugs qui en découlent fréquemment. Pré-requis Savoir protéger ses périphériques (pare-feu) Savoir établir une connexion suffisamment sécurisée entre deux machines Savoir rediriger un port Avoir des bases concernant Docker (voir tutoriel introductif) Savoir se connecter en SSH à un périphérique Avoir défini un nom de domaine entièrement qualifié (FQDN en anglais - Fully Qualified Domain Name) pour l'instance Docker cible Difficulté : Moyenne Sécurisation Pour garantir un certain degré de sécurité, l'idée va être d'exposer le socket Docker via un proxy, ce qui sera réalisé par un conteneur sur l'hôte cible, avec lequel nous établirons une connexion TLS depuis l'instance centralisatrice. Sa localisation peut être quelconque : sur le même réseau local, accessible à distance par HTTPS ou encore par VPN. Le choix de la solution et la sécurisation de l'environnement sont à votre discrétion et découlent des pré-requis stipulés ci-dessus. Portainer Pour faciliter la visualisation de mes instances Docker (ou endpoint) et mes conteneurs, j'utilise l'application Portainer sur la machine qui va servir de centre névralgique pour toutes mes instances. Elle a l'avantage de fournir une interface claire, efficace et intuitive. (Notons qu'il est tout à fait possible de s'en passer et de se cantonner à de la ligne de commande, voir documentation Docker dont le lien est donné plus loin). Un fichier docker-compose modèle pour Portainer : version: "2" services: portainer: image: portainer/portainer container_name: portainer hostname: portainer network_mode: bridge volumes: - "path/to/portainer/data:/data" - "/var/run/docker.sock:/var/run/docker.sock" ports: - 9000:9000 restart: unless-stopped Via le Shell : docker create \ --name=portainer \ --hostname=portainer --net=bridge \ --restart=unless-stopped \ -v path/to/portainer/data:/data \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9000:9000 \ portainer/portainer NB : path/to/portainer/data est évidemment un placeholder et doit être adapté à votre besoin. Dans mon cas, c'est un sous-dossier data dans le dossier du conteneur Portainer. La première fois qu'on se connecte (via http://IP:9000), on est amené à choisir un login et un mot de passe admin. Ce faisant on arrive sur un écran demandant de choisir l'endpoint qu'on souhaite configurer, il faut choisir local et valider successivement les écrans. On arrive rapidement à un écran de la sorte : Je ne rentre pas dans le détail de l'utilisation de Portainer, on trouve des tutoriels relativement bien faits sur Youtube et Google, et c'est de toute façon assez simple à prendre en main : - https://www.youtube.com/watch?v=GNG6PDFxQyQ (à 1:36 on parle précisément de ce qu'on cherche à faire dans ce guide) - https://domopi.eu/ameliorer-la-gestion-de-vos-containers-docker-avec-portainer/ Mise en place Préparation Ici je vais prendre l'exemple d'un VPS OVH entrée de gamme, sur lequel je fais tourner un serveur VPN Wireguard et où je projette d'installer l'application d'hébergement drag & drop Jirafeau, tout ça sur Docker. La première étape consiste à se connecter en SSH avec l'utilisateur de notre choix sur la cible (le VPS en l'occurence pour moi) et de définir la variable HOST avec le FQDN de notre machine. Dans mon cas, j'utilise le nom de domaine que j'ai défini dans ma zone DNS OVH via un enregistrement A vers l'IP fixe de mon VPS. De manière générale, le FQDN peut être local ou externe, peu importe, car c'est un certificat auto-signé que nous allons générer pour l'atteindre, le tout étant que la résolution du FQDN soit adaptée à l'environnement (je ne peux pas utiliser vps.local si je passe par une résolution externe). Cela peut donc se faire comme moi avec un FQDN externe, si vous souhaitez gérer l'instance Docker d'un raspberry de votre réseau local, il peut s'agir de son enregistrement A correspondant dans votre serveur DNS local, ou simplement ce que vous avez renseigné dans le fichier /etc/hosts de votre instance centralisatrice. Pour l'exemple : HOST=target.ndd.tld En tapant : echo $HOST On doit obtenir le FQDN défini ci-avant. Création des certificats Partie serveur On se place dans le dossier /home de notre utilisateur et on commence à suivre (pas bêtement, mais presque) les consignes de la documentation Docker, les étapes étant parfaitement décrites, je ménage vos touches Alt+Tab ou vous évite un torticolis si vous êtes en double écran en recopiant les étapes ici. 😉 Si vous souhaitez plus de détail sur l'explication de chaque étape, Rendez-vous sur la page. openssl genrsa -aes256 -out ca-key.pem 4096 openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem openssl genrsa -out server-key.pem 4096 openssl req -subj "/CN=$HOST" -sha256 -new -key server-key.pem -out server.csr [[[ ATTENTION : Il se peut que vous obteniez l'erreur suivante : Il suffit dans ce cas-là de créer le fichier manquant : touch .rnd et de recommencer ]]] Arrive le passage le plus subtil, il va falloir définir les IP et les FQDN capables d'accéder à cette instance, ça se présente sous cette forme : echo subjectAltName = DNS:,IP: >> extfile.cnf Évidemment, il va falloir renseigner les valeurs de manière exhaustive, sous peine de devoir recommencer depuis cette étape. Ce passage permet de renforcer la sécurisation également, car tout nom de domaine (et donc IP associée) et IP non déclarés se verront refuser l'accès au socket (Connection refused sur Portainer). Il faudra au minimum ajouter $HOST (que l'hôte puisse accéder à sa propre instance, ça ne mange pas de pain), la boucle locale 127.0.0.1, et le FQDN et/ou l'IP de notre instance centralisatrice. Un exemple, où j'autorise en plus par exemple : - l'IP fixe publique de mon instance centralisatrice 51.25.152.236 (fictive) (en cas d'un problème de résolution DNS, je peux toujours y accéder) - l'enregistrement A qui lui est associé central.ndd.tld (ça peut également être mon dynhost pour les IP dynamiques) - l'IP privée de mon instance centralisatrice lorsque connectée au serveur VPN de mon VPS 10.0.0.2 echo subjectAltName = DNS:$HOST,DNS:central.ndd.tld,IP:51.25.152.236,IP:10.0.0.2,IP:127.0.0.1 >> extfile.cnf On poursuit : echo extendedKeyUsage = serverAuth >> extfile.cnf openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf . Partie client Par facilité, on va rester sur la machine hôte et créer les certificats et la clé privée client. openssl genrsa -out key.pem 4096 openssl req -subj '/CN=client' -new -key key.pem -out client.csr echo extendedKeyUsage = clientAuth > extfile-client.cnf openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf rm -v client.csr server.csr extfile.cnf extfile-client.cnf chmod -v 0400 ca-key.pem key.pem server-key.pem chmod -v 0444 ca.pem server-cert.pem cert.pem Récapitulatif Si tout s'est bien déroulé, un petit ls -lt devrait donner ceci : Création du proxy Il nous faut maintenant créer le conteneur servant de proxy, dont voici la page GitHub de l'image. Un modèle de fichier docker-compose : version: "2" services: docker-socket-proxy: image: sjawhar/docker-socket-proxy container_name: docker-socket-proxy hostname: docker-socket-proxy network_mode: bridge volumes: - "/path/to/the/server/certs:/run/secrets:ro" - "/var/run/docker.sock:/var/run/docker.sock:ro" ports: - 2376:2376 restart: unless-stopped Via le Shell : docker create \ --name=docker-socket-proxy \ --hostname=docker-socket-proxy \ --net=bridge \ --restart=unless-stopped \ -v /path/to/the/server/certs:/run/secrets:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -p 2376:2376 \ sjawhar/docker-socket-proxy Parmi les huit fichiers restants, trois nous intéressent pour ce conteneur : ca.pem, server-key.pem, server-cert.pem Ces trois fichiers doivent se trouver dans le chemin que vous aurez choisi pour /path/to/the/server/certs, pour ma part j'ai créé un sous-dossier certs dans le dossier du conteneur. Le port 2376 est à ouvrir (et rediriger si besoin) sur la machine cible, évidemment. Une fois le conteneur démarré, si tout va bien les logs du conteneur n'affichent rien. Ajout du endpoint sur Portainer On commence par rapatrier les trois fichiers utiles pour le client : ca.pem (le même que pour le serveur), cert.pem et key.pem. La sélection des fichiers se fera par une fenêtre de parcours, comme sur interface graphique classique Linux ou Windows. Pour ceux que ça n'aide pas, j'ai utilisé scp et ai mis les fichiers sur mon bureau Linux (attention à la majuscule, c'est -P, pas -p) scp -P <port-SSH> ca.pem cert.pem key.pem toto@central.ndd.tld:~/Bureau Le serveur est maintenant accessible, il ne reste plus qu'à se connecter à Portainer et ajouter l'endpoint. Dans le menu déroulant de gauche, on clique sur Endpoints, puis Add endpoint. Puis on complète de la sorte, en adaptant évidemment à ses propres données : On notera la sélection des certificats et de la clé en bas de la page. On clique ensuite sur "Add endpoint". Si tout s'est bien passé, l'instance cible apparaît maintenant dans la liste des endpoints et est éditable.

Bonjour, j'ai donc continué à chercher ... . Premier constat : l'exit code n'est pas fiable. Certains containers le positionnent, d'autre non; difficile de se baser dessus. Par ailleurs, il faut laisser remonter tous les états de containers via telegraf. Donc : modification du fichier de configuration de telegraf : telegraf.conf. la section "input plugin" / # # Read metrics about docker containers / [[inputs.docker]], décommenter la ligne contenant les états à charger : container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] sur grafana, on crée une requête chargeant le PID, le uptime et l'exitcode. On obtient quelque chose comme ceci (après mise en forme des colonnes) avec le PID entre autre. Ensuite je stoppe manuellement 2 containers (pour montrer la différence de comportement de l'exit code) On voit que l'exit code reste à 0 pour l'un, alors qu'il est positionné à 137 pour l'autre. Par contre les 2 remontent "0" comme PID On peut agrémenter d'un petit recap, par exemple : Je relance les 2 containers : et je retrouve bien mon affichage complet, sans doublon, avec les nouveaux PID pour les containers relancés. Bruno78

Je crois bien (à faire valider par de plus compétents que moi sur ce sujet) que le HSTS est un peu une vacherie. S'il a été activé une fois, certains navigateurs le mémorisent, et n’acceptent de connexions non sécurisées pour ce site... Tu as essayé avec un autre navigateur ? PS : je viens de trouver ceci : Effacer le cache HSTS de votre navigateur Dans Chrome, taper chrome://net-internals/#hsts Entrer le nom de domaine dans le champ texte de la section "Delete domain security policies" Cliquer sur le bouton Delete Entrer le nom de domaine dans le champ texte de la section "Query HSTS" Cliquer sur le bouton Query La réponse doit être "Not found" (non trouvé) Avec Safari, commencer par fermer le navigateur Effacer le fichier ~/Library/Cookies/HSTS.plist Rouvrir Safari Avec Firefox, fermez tous les onglets Ouvrir le menu de Firefox et cliquer sur Historique / Afficher l’historique. Rechercher la page dont vous voulez supprimer les préférences HSTS Effectuer un clic droit sur une des entrées lui correspondant Choisir Oublier ce site

Merci bcp @shad j'ai regardé et modifié attentivement tous les paramètres et...ca remarche. Je crois que j'avais fait une erreur ds le paramétrage du pare feu et ca bloquait tout. Merci merci 🙂

Salut @Jeff21 Bienvenue sur ce forum où tu ne te sentiras pas seul. Il y a bien une dizaine de Jeff 😅

Tu as essayé de taper admin comme log sans mot de passe ?

@GrOoT64 Pas de problème, c'est fait... Cordialement oracle7😉

Ça, c'est parce qu'en raison de la pénurie d'IP V4, depuis quelques temps Free partage une même IP entre plusieurs utilisateurs (en attribuant des plages de ports à chaque utilisateur). Donc si tu n'a pas la chance d'avoir la plage de début, tu ne peux pas utiliser les ports 80 et 443... Mais ce problème est facile à régler : dans ta console d'administration, tu peux demander une IP "full- stack", c'est à dire avoir une IP pour toi tout seul ... (attention, cela va modifier l'IP fixe qui t'était attribuée).

Bonjour @Sylvainfx bienvenue à toi sur le forum!

Après changement du port SFTP ainsi que rajout des règles dans le pare-feu, plus aucune tentative d'intrusion !

Non parfait, c'est mon Syno qui fait office de client et tout fonctionne 🙂 Par contre, je pense virer les fichiers car si besoin je recommencerais à 0 finalement 🙂

C'est le principe du SHR en même temps (ou du RAID5). Faire du SHR avec seulement 2 disques est une hérésie si le but est la pérennité des données (c'est très bien pour la continuité de service par contre), autant faire une copie d'un disque vers l'autre. Non tu n'es pas absolument pas "plus" protégé comme ça. C'est du pareil au même sauf dans le cas où tu aurais 2 disques qui tombent en panne en même temps ET que c'est un de chacun des 2 SHR qui tombe en panne. Par contre, tu perds bien 4To.

Tu risques de perdre tes données si le NAS se coupe (panne de courant sans onduleur) pas si tu l'arrêtes correctement car il démonte le RAID/SHR avant de s'éteindre. Je rajouterai que le cache se vide à chaque reboot -->

Bonjour Le disque est vendu

Bonjour, En vente sur un autre support , il y a un contact en cours. Pour la garantie constructeur, pour moi le numéro de série suffit. Je mettrai un message dans le forum sur le forum pour confirmer sa dispo.

Tu as "2 durées" de garantie Si tu as la facture, c'est 2 ans à partir de la date d'achat. Si tu n'as pas la facture, on se base sur la date de fabrication donné par le numéro de série. C'est 2 ans à partir de cette date. @David P

Et une bonne chose de faite (en plus de ma signature) : Ok je ferme. Mon DNS est sur mon RT Erreur : c'est maintenant fermé. Ok, le mieux est de fermer alors pour un accès en local uniquement ? Je pensais que comme bloqué par le RT, il n'y avait pas de risque. Je sais que c'est mentionné dans le tuto DNS au même titre que les IP locales ou VPN, je pensais donc qu'il fallait avoir le même comportement. Ok du coup pour la même raison, je peux faire sauter toutes les règles d'autorisation de mes IP locales / VPN dans mon pare-feu NAS alors ? Pourquoi certains tuto préconisent la création de ces dites règles justement ?

Oui, tu as raison. Mais on dit bien lire, pas décoder. Un fichier word, c'est le NAS qui le décode ? Non, c'est le word installé sur l'hôte qui le décode. Pour la vidéo, c'est pareil. Tu as un stockage d'un coté, et le programme de l'autre qui le décode. Si tu utilises un lecteur réseau, un ordinateur ou un smartphone, leur hardware le fera facilement. Contrairement à un NAS (même si indiqué comme faisant du transcodage) ou une TV (même si connectée blablabla...), leur hardware est... insuffisant. Et je ne reviens pas sur l'impossibilité sur ces écrans de lire la plupart des conteneurs et codecs utilisés dans le monde de la vidéo/audio. Si ça c'est du chinois... quelles sont tes connaissance en réseau ?

Bien sur, c’était même le but ; ) Alors rapidement, pour expliquer comment cela fonctionne (ceux qui connaissent ou on lu les guides d'administration du DVA sur le site Synology peuvent passer directement à la partie remarques personnelles ou je donne MON avis tiré de MON experience) Le module DVA propose de créer des taches (détection de mouvement, détection d'intrusion, zone de non activité et décompte de personnes) Il n'est possible d'avoir que 4 taches actives à la fois mais on peut en paramétrer d'avantage et les désactiver/activer au besoin. La limite étant 4 actives maximum à la fois. Chaque tache déclenche le cas échéant un enregistrement qui sera visualisable dans le module DVA. Selon les taches, certaines options sont disponibles ou pas (je ne liste que celles qui me semblent importantes, il y en a d'autres) : - Possibilité que le DVA marque automatiquement les vidéos avec un ou plusieurs tag selon ce qui s'y trouve (Personne, animal, véhicule, sabotage ou les quatre). - Possibilité de forcer la détection uniquement lorsqu'un type de "détection" est reconnu (Personne, animal, véhicule ou les trois). NOTE : il ne semble pas y avoir de lien ni de corrélation entre la manière dont le DVA assigne un TAG et la manière dont il défini le type de détection. - Possibilité de créer des zones de détection avec des paramètres différents pour une même tache (genre premier plan et arrière plan ou zone inclue versus zone exclue pour la détection) - On peut - et c'est en lien avec la ligne du dessus - définir une taille minimum pour les objets à détecter (plus petit pour l’arrière plan par exemple ou éliminer les chat et chiens) - On peut choisir de notifier la détection comme une "détection de mouvement"' sous SS (Pour marquer le timecode ou déclencher une règle indépendante du DVA) - On peut choisir d'ignorer la détection de perturbations comme la pluie/neige, les changements de lumière naturelle et les mouvements courts. - On peut choisir le flux video de la caméra utilisé pour l'analyse (si elle en possède plusieurs). D’après Syno, plus c'est élevé, mieux c'est) Il y a également un module d'ajustement de paramètres dont je cherche encore l’intérêt en l’état : ) Remarques personnelles : J'ai n'ai fait des tests qu'en extérieur, ce qui me semble le pire cas de figure, sur 4 cameras a 2.5m du sol environ. 2 Zavio 3MP, 1 Zavio 5MP et une Trendnet 3MP. Les résultats sont excellents si des elements perturbateurs ne viennent pas trop embrouiller notre DVA (voile de tonnelle ou arbustes souples comme des bambous en pots qui bougent un peu trop par grand vent, ou tres gros nuage qui obscurcit la scène d'un coup). Il gère bien mieux ce genre de choses que la détection classique (par caméra ou live view analytics) mais il reste pas mal de faux positifs. Selon mes tests on va dire qu'il y en a entre 80 et 90% de moins par rapport à la détection classique qui sont dus à ces événements. Mais il reste délicat d'envisager du 100% sur si l'on n'est pas sur un terrain dégagé par ciel bleu. C'est parfait sur ma façade avant, portail et bout de terrain mais injouable sur le jardin - avec du vent - avec la tonnelle et les arbustes. Les options disponibles pour ignorer les éléments naturels ou les mouvement rapides me semblent d'une inefficacité relative en ce sens. De plus elles ne sont disponibles qu'avec la tache de détection de mouvement. Et c'est la un autre problème. Certaines options ne sont pas disponibles en fonction de la tache choisie. Par exemple, pour une detection de mouvement, on peut demander à ce que soit automatiquement tagué le type de modèle détecté (Personne, Animal etc) mais on ne peut pas limiter la détection a ce type de modèle : un chien produira le même effet qu'une personne. Même s'il est possible de définir une taille minimum pour la détection, un gros chien, ça passe laaaarge. Idem un nuage ou un oiseau ou une abeille qui vient voir de trop près la camera. Pour la zone interdite, on ne peut pas non plus en profiter, mais on ne peut pas non plus définir une taille minimum de détection. Bref des manques , peut être explicables par la techno utilisée mais qui permettraient de réduire je pense les faux positifs. Concernant la detection d'intrusion, celle qui fonctionne le mieux, on ne peut pas non plus profiter d'ignorer les mouvements courts ou les intempéries. Néanmoins, en forçant sur la détection de personnes, et en "recoupant" le perimetre de détection, les résultats sont excellents depuis une semaine. Pour l'histoire du recoupement, je vous joins une photo, j'ai remarqué que parfois le DVA ne détectait pas la personne entrant dans le perimetre. d'ou l'idée de lui faire faire des zigzag et de demander une détection entrante ET sortante. Sur l'image, le perimetre est symbolisé par la ligne violette. Après, il est dommage également de ne pouvoir activer ou désactiver les taches via les règles. On ne peut que par un agenda. Comme pour l'enregistrement des cameras. De même, s'il est possible de programmer des règles d'action dans SS utilisant les résultats du DVA cela n'est possible que sur le nas qui utilise le package (en l’occurrence le 3219). Si vous utilisez le CMS de surveillance station pour régir vos taches, si le DVA est un serveur esclave, vous ne pourrez accéder qu'à la détection de mouvement (générée par la tache du DVA comme une détection classique) comme déclencheur. Mais sans doute ce nas/nvr a t'il été conçu dans l'optique d’être le serveur CMS maitre (je n'ai pas testé). Mais dans ce cas quid si l'on en possède deux ? Cela lui permettrait peut être de traiter des flux de cameras installées sur d'autres NAS (en tant que CMS esclave le DVA ne gère que les flux des cameras configurées sur lui mème) Enfin la limite à 4 taches est un chouia limitative... On peut en configurer tant qu'on veut, mème utilisant plusieurs fois la mème caméra, mais ça reste un peu limité puisque seules 4 d'entre elles peuvent être actives en même temps, et qu'on ne peut pas activer/désactiver ces taches de manière automatique (Via les règles d'action en fonction de ça ou ça...). Je ne connais pas les tarifs de produits équivalents sur le marché. La on est à 1400HT avec 8 licences sans les disques. Mais seulement 4 taches : ) C'est peut être bon marché, compte tenu de ce que j’évoque avant. Je ne sais pas : ) Dernière chose, Synology lui donne le terme de NVR d'apprentissage. bon soyons clairs tout de suite, et le support me l'a confirmé, sauf mise à jour logicielle, à l'heure actuelle, il n'apprend RIEN DU TOUT. Pas d'option pour corriger les erreurs ou autre. Pour conclure, mème si ça n'est pas évident quand je me relis, je suis très satisfait de ce produit. Cependant SELON MOI le module DVA doit progresser encore, mieux s’intégrer à SS et l'idée qu'il puisse un jour apprendre de ses erreurs tout seul le rendrait TRÈS attrayant ! Je l'ai intégré à ma domotique avec Jeedom et il sert d'alarme "préventive" en plus de l'alarme Hard. Et ça marche plutôt pas mal...sur la façade avant : D (il déclenche deux gyrophares et les lumières. Peut être bientôt du son !) (C'est terminé, j’espère que tout le monde n'est pas mort et que j'ai pu en éclairer certains ! il y a un distributeur de Doliprane sur votre gauche à la sortie) [edit pour cause de fotes]

Salut @Derski et bienvenue: en effet un peu de fraîcheur fera du bien:) !

Bienvenue @Derski Super, tu vas faire baisser la moyenne d'âge des membres 😄

Bienvenue !

Bonjour @Derski bienvenue à toi sur le forum! N'hésite surtout pas à nous poser tes question dans la rubrique qui a bien. Nous nous ferons un plaisir d'y répondre!

Salut, tu as 512 Go de stockage, j'ai du mal à croire que tu modifies 512 Go de fichiers excel doc ou autre dans la journée...

Ce que dit @Jeff777 ou alors effectivement le menu où tu te trouves : Tu peux t'inspirer du tutoriel sur la sécurisation pour les adresses IP privées à autoriser : 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 127.0.0.0/8 Attention que le 10.0.0.0/8 couvre le VPN, ça c'est l'ensemble des adresses privées, après tu peux restreindre et adapter à ton infrastructure.

@Jeff777, intéressant le problème ! Je parie que dans tes données (noms de stations, ...) tu as des caractères accentués .... ? 🙂 Je te propose alors la choses suivante : dans ton docker telegraf, il faut installer le module python unidecode : # pip install unidecode root@fbx_telegraf:/usr/local/py# pip install unidecode Collecting unidecode Downloading Unidecode-1.1.1-py2.py3-none-any.whl (238 kB) |################################| 238 kB 2.9 MB/s Installing collected packages: unidecode Successfully installed unidecode-1.1.1 root@fbx_telegraf:/usr/local/py# tu utilises le script suivant : freebox_053_d1.pyfreebox_053_d1.py avant de le configurer dans telegraf.conf, tu peux déjà simplement le charger dans /usr/local/py et le lancer à la main comme pour les tests précédants: python3 freebox_053_d1.py -XW ce script contient la suppression des caractères accentués selon ton retour, je l'intègrerai (ou pas) dans une nouvelle version de script

Du bon et du moins bon. Ce qui est bien c'est que je suis arrivé au bout du tuto , que mon dasboard nas fonctionne toujours et que influxdb reçoit bien de nas_telegraf et fbx_telegraf le tout avec un seul conteneur telegraf : [httpd] 172.18.0.4 - nas_telegraf [09/May/2020:08:59:00 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 52b773e6-91d3-11ea-81bc-0242ac120003 638407 [httpd] 172.18.0.4 - fbx_telegraf [09/May/2020:08:59:00 +0000] "POST /write?consistency=any&db=fbx_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 52b6a9dd-91d3-11ea-81bb-0242ac120003 643651 [httpd] 172.18.0.4 - fbx_telegraf [09/May/2020:08:59:10 +0000] "POST /write?consistency=any&db=fbx_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 58abe7a6-91d3-11ea-81bd-0242ac120003 909981 [httpd] 172.18.0.4 - nas_telegraf [09/May/2020:08:59:10 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.14.2" 58ad605c-91d3-11ea-81be-0242ac120003 901069 Ce qui est moins bien c'est que le dashboard freebox affiche toujours nodata🙄 Et là au moment où j'écris, en vérifiant une dernière fois, je reçois enfin des données ! Pourtant telegraf dans les log affiche toujours une erreur : 2020-05-09T09:18:51Z E! [inputs.exec] Error in plugin: exec: exit status 1 for command 'python3 /usr/local/py/freebox_053.py -SPHDIWX': Traceback (most recent call last):... 2020-05-09T09:19:01Z E! [inputs.exec] Error in plugin: exec: exit status 1 for command 'python3 /usr/local/py/freebox_053.py -SPHDIWX': Traceback (most recent call last):... 2020-05-09T09:19:11Z E! [inputs.exec] Error in plugin: exec: exit status 1 for command 'python3 /usr/local/py/freebox_053.py -SPHDIWX': Traceback (most recent call last):... Mias ça s'est un peu décoincé et je me souviens que j'avais eu le même phénomène avec le dashboard du NAS. 😎 A partir de là je crois que je vais m'en sortir. Merci à @bruno78 et @.Shad. . Super forts !

Bonjour , Je vous conseillerais de ne pas ouvrir trop de ports sur votre box. Je serais vous , je ferais uniquement du port forwarding 80/443 de votre box vers NAS1 , et sur NAS1 dans "Portail des Applications" je ferais 2 règles proxy inversé pour renvoyer les requetes destiné a NAS2. De cette façons vous n'exposez qu'un seul NAS directement sur internet , et en plus vous n'aurez plus a taper vos port dans vos URLs.

Pas de problème. Je m'absente jusqu'en fin de matinée ....

@CyberFr On autorise la communication sur tous les ports dans un réseau local. Les adresses qui sont reprises (10.x.x.x, 192.168.x.x, 172.16.x.x) sont des sous-réseaux réservés à l'utilisation privée, donc par définition elles n'existent pas sur Internet, c'est ce que tu trouveras dans tous les réseaux internes (derrière un routeur, pare-feu, modem, etc... ), particuliers ou entreprises. C'est la RFC1918 qui définit cela (comme une norme DIN ou ISO par exemple). On part du postulat que le réseau local est sûr, et qu'on n'a pas besoin de s'en protéger, ça part du principe que : - on soit prudent sur l'utilisation des autres périphériques locaux. - on soit plus prudent que ça en entreprise. Pour un utilisateur un peu au fait d'un comportement responsable sur Internet et des bonnes pratiques à adopter, ces règles facilitent grandement la vie et ne représentent qu'un très faible danger, surtout si on applique toutes les règles édictées dans ce tutoriel. Séquentiellement dans ton pare-feu, tu vas donc définir des règles, qui vont analyser chaque requête entrante. Tant que la requête ne correspond pas à une règle, elle continue de descendre dans la liste. Si aucune règle ne correspond à la requête, par précaution, on la bloque avec la règle "tous" "tous" "refuser". On est sûrs ainsi que rien qu'on ait explicitement autorisé ne puisse accéder au NAS. A toi après d'ajouter les règles pour utiliser tes services à distance par exemple. Par défaut ce tutoriel incite à utiliser le VPN, ce qui est une bonne chose, en revanche si tu souhaites accéder à ton NAS depuis le travail, la plupart du temps il n'est pas possible d'installer un client VPN sur ton poste de travail, et dans ce cas-là il te faudra exposer ce service sur le web, la plupart des règles énumérées ici permettent entre autres de donner un maximum de sécurité à cette connexion externe (Blocage sur tentative de brute force, possibilité de géobloquer les connexions entrantes, etc...) J'espère t'avoir un minimum éclairer, mais tu verras avec un peu d'habitude ça vient vite 🙂

Ça me semble bon, pense bien à créer les dossiers py et log dans le dossier telegraf. Et t'assurer que ton NAS accepte les connexions depuis le sous-réseau de ta Freebox.

Pour info j'ai aussi depuis vendredi un WD red 4To provenant de LDLC pour remplacer un de mes disques tombé en panne (qui avait près 50000h quand même) et bien ce disque neuf bloque aussi à 90% du smart étendu. J'avais de toute facon prévu de le retourner à cause de leur technologie SMR qu'il vaut mieux éviter de mixer avec des disques conventionnels mais c'est une coïncidence étrange.

Chez moi tout fonctionne en LAN et WAN (le tout via reverse proxy), aussi bien sous iOS que sous iPadOS.

Je vais ajouter ton post dans le tuto même si ça me paraissait évident 🤔 Va voir tes subvolumes et tu auras une belle surprise 😉 La suppression d'un container ne fais pas tout le ménage derrière. Il ne supprime que le container et volume principal mais il reste toujours des merdes qu'on peut nettoyer de cette façon : Supprimer toutes les images qui n'ont pas de conteneurs associés : docker image prune -a Supprimer les conteneurs stoppés, les volumes non utilisés, les networks non utilisés et les images "dangling" : docker system prune Supprimer les containers arrêtés : docker rm $(docker ps -a -q) Supprimer les volumes orphelins : docker volume rm $(docker volume ls -qf dangling=true) Suivre les tutos qui sont sur le forum 🙂 En particulier le reverse proxy par exemple.

@AngesMortel Bonsoir, Tu te connectes en mode admin à la LB Dans Réseau - NAT/PAT : Tu sélectionnes dans le popup, le service pour le quel tu veux ouvrir le port ou bien tu sélectionnes 'nouveau' et tu donnes un nom à ta convenance. Puis dans l'ordre port interne, port externe : tu sais le N° du port (le même pour les deux !). Tu sélectionnes ensuite le protocole à appliquer : TCP ou UDP ou les Deux Enfin tu saisis l'@IP de ton NAS ou son nom si tu l'as auparavant nommé dans 'Mes Équipements connectés' TU cliques sur créer pour valider ta saisie. Tu refais cela pour chaque port à ouvrir. Ce n'est pas plus compliqué ... Cordialement oracle7😉

Ah si tu as un htaccess qui fait la redirection c'est sûr que tu es coincé 🙂

Voilà les prix à Taiwan : https://ecshweb.pchome.com.tw/search/v3.3/?q=synology&scope=all Conversion en € pour la France du DS920+ = 521 euros + 20% (taxe française) = 625 € minimum 🤣

@EVOTk Merci beaucoup. Tout à fonctionné comme tu l'as dis ! Merci beaucoup. Pour résumé : Etape 1 : Sauvegarde => Copier le dossier partagé docker/emby Arrêté le conteneur. Exporté le conteneur (contenu + paramètre) Etape 2 : supprimer l'image linuxserver/emby:latest (si ce n'est déjà fait) de docker à partir du menu "image" de docker Etape 3 : télécharger la nouvelle image de linuxserver/emby:latest à partir du registre docker (on a à nouveau l'image dans le menu "image" Etape 4 : à partir du menu conteneur, clic droit sur le conteneur (qui est arrêté je le rappel) action => effacer Etape 5 : à partir du menu conteneur, clic droit sur le conteneur (qui est arrêté je le rappel) action => démarrer On attend quelques minutes que le conteneur démarre puis, à partir de l'interface d'administration de emby (http://IPduNAS:8096/ par défaut), cliquer sur la petit roue dentée, en haut à droite, dans le menu de gauche, il indique qu'il veut un redémarrage pour appliquer la MAJ. On lui dit de redémarrer (désolé, j'ai plus les termes exactes sous les yeux) Etape 6 : Après quelques minutes de démarrage, on retourne dans ce même menu (à partir de l'interface d'administration de emby (http://IPduNAS:8096/ par défaut), cliquer sur la petit roue dentée, en haut à droite,) et on contrôle qu'à gauche, on a bien le bon numéro de version. Etape 7 (indispensable !!!) : On se prend une petite bière parce qu'on l'a bien mérité ! edit : @unPixel si jamais tu veux ajouté cette partie "update" dans ton tuto n'hésites pas à copier coller !

Perso, je sauvegarde aussi le dossier présent dans docker, mais périodiquement en cas de soucis, mais pas spécifiquement pour les MAJs. Quand il y a MAJ du docker, le dossier config se retrouve modifié par les fichiers nouveau ou les modif du a la MAJ mais les fichiers comportants tes réglages, ... ne sont ( sauf bug, qui m'est déja arrivé avec plex 1 fois ) pas touché.

C'est simple. On y pense pas forcement mais le RAID1 est "une copie" à un instant T donc plusieurs choses : 1/ Le RAID te protège en cas de panne d'un disque pas en cas de panne du contrôleur RAID. 2/ Pas de sécurité en cas d'erreur de ta part (suppression d'un fichier) 3/ Pas de protection contre les virus/ransomware &co. En gros, tout ce qui va affecter un disque, affectera systématiquement le second sauf une panne d'un disque.

Ah bon ?

Merci, concernant mon installation j'ai un nas synology ds218+ avec 2 disques de 2to relié à ma live box orange. Le nas est branché derrière un onduler. J'ai une connexion en fibre à très haut débit.

Parfois si tu as atteints le maximum de renouvellement autorisés (5) dans la semaine écoulée tu ne peux plus créer de nouveaux certificats et effectivement le message n'est pas toujours clair sur le motif de refus. Si c'est le cas, il ne te reste plus qu'a attendre et réessayer plus tard. https://letsencrypt.org/docs/rate-limits/

Je n'ai pas tout compris sur ton problème mais l'essentiel est que tu as pu le résoudre. Bonne continuation

Bonsoir, Je ne suis pas complétement sur qu'il y ait vraiment un problème de compatibilité entre les Nas Synology et les disques WD40EFAX, car dans l'autre sujet, ce semble plutôt être à cause du Nas. En effet, même si le modèle WD40EFAX n'est pas sur le tableau de compatibilité du DS918+, les WD20EFAX, WD60EFAX, WD80EFAX sont bien présents, donc je pense plus à un oubli. (à confirmer auprès de Synology) Ce qui distingue cette série EFAX, vient de la technologie d'écriture SMR qui permet de doubler la densité de pistes et d'améliorer les accès en lecture, mais malheureusement divise par deux la vitesse d'écriture, malgré le cache plus gros. En effet, comme c'est décrit ici, ces disques doivent réécrire les pistes contigües, surtout en écriture aléatoire. https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/PMR_SMR_hard_disk_drives Une autre caractéristique est qu'il utilisent la fonction TRIM comme les SSD, du fait de la réécriture des pistes déjà présentes. De toute façon Synology déconseille d'utiliser dans la même grappe Raid, un mélange de disques SMR (EFAX) et PMR (EFRX) Ce mélange pourrait avoir un impact négatif durant la reconstruction d'un raid, et puis ce n'est jamais bon de mélanger des disques aux performances différentes, qui vont toujours fonctionner en Raid comme le moins rapide. Cette perte de performance peut de plus être gênante en fonction de l'utilisation du NAS, si il y a beaucoup d'écritures. Pour de la sauvegarde, c'est moins grave. Donc monter un 6 GO pourquoi pas, mais à condition qu'il soit de la série EFRX. En ce qui concerne la disparition des WDXXEFRX (qui ne doivent plus être fabriqués), c'est surtout un changement (très) discret de technologie permettant de baisser les coûts, car si on double le nombre de cylindres (pistes), on peut diviser par deux le nombre de plateaux et de têtes. C'est une façon de mieux lutter contre la concurrence croissante des SSD qui vont finir par prendre le marché des disques "mécaniques". Malheureusement les constructeurs restent très peu bavards sur ce changement et ses conséquences en terme de performances. https://zfsonlinux.topicbox.com/groups/zfs-discuss/T759a10612888a9d9-Me469c98023e1a2cb059f9391 Au moins, chez WD on peut distinguer les 2 technologies car il y a des références différentes, mais ce n'est plus du tout le cas chez Seagate qui ne parle jamais de SMR ou PMR dans les caractéristiques, mais seulement de TGMR (Tunneling Giant Magneto-Resistive) qui correspond à la technologie des têtes, sans jamais parler de la géométrie des pistes qui passent en SMR. ( @seagate_surferpourrait peut être confirmer ?) Pour info, un site intéressant qui rassemble des informations pour chaque modèle et série de disque et donne la technologie employée: Nbr de plateaux et têtes, SMR/PMR The HDD Platter Capacity Database https://rml527.blogspot.com/

Bonjour. Envoie ton adresse en mp, je t'envoie une impression par courier

Bonjour, En ce qui concerne l'autonomie, on peut extrapoler des informations données pour certains appareils aux caractéristiques proches. ex: Eaton 5E 500VA 300W (celui-ci étant line interactive+AVR, il y a peut être une diminution d'autonomie par rapport à un offline comme l'APC) Si le logiciel de l'onduleur permet de mesurer la puissance consommée, on peut en déduire une durée approximative, sous réserve que les deux utilisent la même batterie. Un dépannage est toujours possible, mais sans avoir les plans, ni être sur du symptôme, ce n'est pas simple. Changer la carte ne sera surement pas rentable par rapport à un neuf. Il faudrait déjà vérifier visuellement si un composant a chauffé, ou si un condensateur chimique est gonflé ou a fuit. Si c'est une panne moins évidente, par exemple celle d'un composant du voltmètre/ampèremètre interne qui sert à évaluer l'autonomie, c'est peine perdue. Bonne chance.

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

Où as-tu lu ça ? D'après Synology c'est faisable : https://www.synology.com/fr-fr/dsm/feature/active_directory https://www.synology.com/fr-fr/knowledgebase/DSM/help/ActiveDirectoryServer/activedirectory_desc Il y a également des ressources sur le forum officiel : Rubrique : https://forum.synology.com/enu/viewforum.php?f=284 Guide : https://forum.synology.com/enu/viewtopic.php?f=284&t=132330