.Shad.

D'après ce lien, cette faille est corrigée depuis un bail, et un DS218+ vient de base avec DSM 6.x je crois. C'est très étonnant, si tu n'as pas exposé dangereusement ton NAS avant d'avoir bouclé la partie sécurisation, d'être victime de ce genre de chose. A ta place je vérifierais mon réseau local, car dans le tuto on ouvre tous les ports vers le LAN, et il est beaucoup plus facile d'être infecté sur un PC que sur un NAS.

Alors une possibilité serait aussi un problème d'identifiant DynHost. Peut-être en as-tu créé deux, donc vérifier que celui sur OVH correspond à celui entré dans accès externe. Parce que dans ce cas-là tu peux avoir tout qui semble bon sur le NAS, mais n'utilisant pas le même identifiant, OVH met à jour une entrée DynHost n'existant pas/plus. Tout ça de manière totalement transparente.

Bienvenue 🙂

C'est ça qu'il te faut à ce niveau-là :

2 pistes : - Regarder dans le paquet Centre de journaux de Synology si tu vois quelque chose d'intéressant dans les logs. - Voir ce que contient le fichier /var/log/messages en SSH.

La récurrence de 48h des déconnexions me fait penser à un bail DHCP arrivant à terme et un conflit d'IP en conséquence. Vu que ton NAS est en IP fixe, as-tu pris soin de lui attribuer une adresse IP en dehors du DHCP range de ta box ? Le mieux étant quand même de ne pas fixer l'IP sur le NAS, mais de faire une réservation d'adresse IP en fonction de l'adresse MAC de ton interface réseau dans la partie DHCP de ta box.

Dans Panneau de configuration -> Accès externe, est-ce que le statut de ton DDNS est sur Normal, ou une erreur au sujet de DSN ?

Bienvenue 🙂

Bonjour Taolinou, Tu peux t'aider du sujet ci-dessous, sinon sur le site de Synology : https://www.synology.com/fr-fr/compatibility Il est intéressant de désactiver le compte admin par défaut, tout simplement car admin c'est évident comme login, le scanneur n'aura plus qu'à trouver le mot de passe. Donc désactiver le compte admin par défaut après avoir créé un compte administrateur personnalisé. Tu peux ensuite créer des comptes utilisateurs qui n'auront que des droits en lecture seule. Je reconnais que c'est quelque chose qui manque sur le forum, un guide des bonnes pratiques concernant la gestion des utilisateurs, je me lancerais bien mais je ne suis moi-même pas sûr de le faire dans les règles de l'art. Les services du NAS sont disponibles via des ports, ce sont des portes si tu veux pour rentrer dans le NAS. Si tu désactives ou si tu l'actives mais que tu ne refuses aucun accès au NAS c'est comme si toutes les portes étaient ouvertes. En général, on donne aux autres périphériques un accès total au NAS en local (tous les ports ouverts), et on bloque un maximum de ports vers l'extérieur, en ouvrant seulement ce pour quoi on n'a pas le choix. On peut fortement limiter le nombre de ports ouverts vers l'extérieur avec une connexion VPN sur ne NAS. Ce sont beaucoup de notions d'un coup, j'ai vraiment surnagé un petit temps avant de comprendre comment tous les paramètres étaient reliés. Bon courage 🙂

De ce que j'ai lu, oui, mais avec moins de probabilité. Après, si tu cumules la durée de vie de tes deux 1815+, tu arriveras à quelque chose de raisonnable. 😉 Assures-toi juste d'avoir un plan de sauvegarde plus fréquent, et vérifie de temps à autre que ta sauvegarde fonctionne en faisant une restauration.

Jusque-là tout va bien. 🙂 Oui pour InfluxDB et Grafana, pas besoin pour Telegraf. Si tu regardes le script du docker-compose de Telegraf : version: "2" services: telegraf: image: telegraf container_name: telegraf hostname: telegraf volumes: - "/volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/proc:/host/proc:ro" - "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro" ports: - 8125:8125/udp - 8092:8092/udp - 8094:8094 restart: unless-stopped networks: default: external: name: data_export On ne monte nulle part un dossier data, on monte par contre le fichier telegraf.conf, pour que les données persistent. Si tu ne fais pas ça, à la moindre màj ou suppression du container, tu seras bon pour tout recommencer, car Telegraf aura généré un nouveau fichier au sein du container. Là on lui dit que celui dans le container, c'est celui qu'on a dans notre dossier. Oui, en effet 😛 Tu dois faire correspondre les champs suivants : influxdb: image: influxdb container_name: influxdb hostname: influxdb environment: - INFLUXDB_DB=nas_telegraf # InfluxDB Details : Database - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf # InfluxDB Details & Basic Auth Details : User - INFLUXDB_USER_PASSWORD=nas_telegraf # InfluxDB Details & Basic Auth Details : Password - INFLUXDB_HTTP_AUTH_ENABLED=true ... Ce qui est en majuscule, c'est le nom de la variable, après le signe égal, c'est sa valeur, et c'est toujours la valeur qui nous intéresse. INFLUXDB_DB => Nom de la variable nas_telegraf => Valeur N'hésite pas à relire le tutoriel à tête reposée, il n'est pas des plus simples et vérifie que tu as bien validé chaque étape avant Grafana, car cette dernière est triviale par rapport à ce qui la précède.

Je cite le préambule du tutoriel : En se basant sur l'exemple que je donne avec telegraf, tu pourrais très bien créer un dossier influxdb dans un dossier partagé docker qui reprend les données persistantes de tous tes containers. Si ce n'est toujours pas clair n'hésite pas. Nulle part pour l'instant, tu vas le créer à partir de l'image que tu as normalement déjà téléchargée à ce stade :

Oui c'est la limite des NAS de manière générale, si on veut pouvoir transcoder c'est plutôt un serveur déporté suffisamment puissant pour la tâche qu'il faut employer, un bon i5 peut faire l'affaire.

Salut, Merci du retour, c'est en effet le genre de chose que je ne peux pas vérifier, je vais mettre un commentaire à ce sujet.

Bienvenue 🙂

Est-ce qu'en copiant un fichier via un mappage de lecteur réseau sur un laptop ou un fixe vous rencontrez aussi ce problème ? ou juste via navigateur ? Avez-vous essayé un autre navigateur pour comparer ?

Les dernières màj ont apporté un certain nombre de changements vis-à-vis des API Google, je traîne pas mal sur le subreddit Synology et tu n'es pas le seul à avoir rencontré des problèmes à ce sujet. 🙂

Bienvenue !

Fallait tenter 😄 Sinon tu peux toujours essayer de revendre ton NAS "neuf" et te racheter un 1819+ 😛 On notera quand même la prise en charge très professionnelle de la part de Synology, ils auraient pu être beaucoup plus tatillon.

Regarde peut-être dans un premier temps si le processus s'exécute toujours ou pas en arrière-plan dans le gestionnaire de tâches (sûrement un nom du type drive.exe ou synologydrive.exe)

Bienvenue parmi nous ! 😉

Le NAT remplit cette fonction là, à partir du moment où tu ne le rediriges pas de ta box vers ton NAS il est bloqué à l'entrée de ton réseau local. Mais le NAT n'est pas un pare-feu, il te permet simplement d'exposer ou non le port d'un périphérique donné vers l'extérieur. Et cela est également très bien expliqué dans le tuto : IPSec (500 et 4500) c'est le tunnel externe, l'enveloppe, c'est lui qui doit être redirigé via le routeur. Dans ce tunnel, tu as L2TP (1701), non chiffré, qui contient tes données, le routeur ne voit rien de tout ça, lui se contente d'ouvrir une porte à IPSec, ce qui est dedans ne le regarde pas. Et si tu veux tester pour être sûr, tu règles l'ouverture du port 1701 sur le NAS pour le monde entier (pas d'emplacement dans la règle du pare-feu) et tu fais un scan du port 1701 sur un des nombreux sites proposant ce service. Tu auras ta réponse. Et tu penses à restreindre l'emplacement juste après ton test hein 😛

Ben tout était dit dans le tuto en fait 😮

Tant mieux si ça vous débloque ! Je ne pourrais pas t'en dire plus au sujet des websockets, je sais en revanche que j'ai dû parfois ajouter des headers personnalisés pour faire fonctionner certaines redirections. Et sur ce point très difficile de trouver des infos pour le proxy inversé de DSM contrairement à HAProxy ou Nginx.

Je n'ai pas de camera mais j'ai trouvé ça sur Reddit :