.Shad.

Ce n'est que pour du téléchargement qu'il te faut un VPN ? Si oui il vaut mieux utiliser Docker.

https://help.dreamhost.com/hc/en-us/articles/215747748-How-can-I-redirect-and-rewrite-my-URLs-with-an-htaccess-file-

👌 Et tu ajusteras la RAM allouée à la VM suivant la consommation effective.

C'est juste pour le Pi 1 apparemment que ça pose problème. Sur les autres il n'y a aucun problème.

Bienvenue parmi nous !

Avec iptables on peut à peu près tout faire, mais bon faut déjà être pas mal averti. Pourquoi ne pas créer un vDSM, et y réserver par exemple tout ce qui est sensé passer au travers d'un VPN ?

@Jeff777 Je viens de voir ça : Il faudrait confirmer l'information mais apparemment il y aurait des problèmes de compatibilité de Docker avec le Rpi 1st gen.

Hello, aucun champ de l'UPS n'est remonté par Telegraf ? Pour ton autre question : https://docs.influxdata.com/influxdb/v1.8/administration/config/#reporting-disabled-false

Le changer dans la box n'a pas le moindre petit effet, Drive continue d'utiliser le port 6690 pour le transfert de données. C'est hardcodé dans l'application sur ton NAS, et dans les clients. Ce que tu peux changer via le portail des applications c'est le port sur lequel est exposé l'interface d'administration utilisateur de Drive. Le transfert de données est basé sur une connexion TLS entre le client et le serveur, c'est chiffré et sécurisé, tu peux très bien après limiter l'ouverture des ports en fonction des IP ou de la géolocalisation par exemple. Un NAS bien configuré (voir tutoriel sur la sécurisation) sera bien plus vulnérable à ce qu'il se passe dans ton réseau local qu'à ce qui vient de l'extérieur : montage SMB/NFS, disque externe, etc... Donc je te conseille simplement d'utiliser le port 6690 pour le transfert de données, pour te connecter à ton interface Drive sur le NAS tu peux choisir le port que tu veux, ou passer par un proxy inversé.

Ton NAS est dans la liste des modèles équipés des puces Intel défectueuses. Tu trouveras les tests à faire sur ce forum.

Je ne vois pas le rapport entre tes impressions d'écran et mes questions, j'ai bien compris que tu faisais du NAT x6690 -> 6690. De plus tu ne réponds pas à ma question :

En plus de la sauvegarde cloud je te conseillerais d'avoir un disque dur externe, pour restaurer rapidement au besoin, que tu aies une connexion Internet ou non. Suivant le budget, un DS218 pourrait convenir, éventuellement un DS220+ si les finances le permettent (je conseille malgré tout toujours les modèles "+" pour ne pas avoir de regret par après parce qu'on est limité par la gamme du NAS). Les modèles "+" ont l'avantage de pouvoir faire de la virtualisation et de la conteneurisation. Si un jour tu souhaites mettre en place une application qui n'existe pas sur DSM, ou qu'un paquet natif Synology n'est plus mis à jour tu pourras tout à fait émuler un système Linux classique ou directement l'application dont tu as besoin.

Oui enfin à partir du moment où on souhaite y accéder de l'extérieur, il faut que les accès à ton NAS soient sécurisés. Et ca va te demander un peu de lecture et de temps quand même. 😉 Pour le modèle de NAS, si c'est juste pour du stockage tu n'as pas besoin d'un modèle haut de gamme, sauf si tu désires utiliser ton NAS à d'autres fins par la suite (bloqueur de pubs, gestionnaire de mots de passe, home theater, etc...). Pense aussi à la sauvegarde de tes données, et la nécessité ou pas d'avoir une redondance de disques pour éviter les temps d'indisponibilité en cas de panne d'un disque. Et bienvenue 🙂

Tu as sûrement écrit les données du speedtest dans cette partition. Tu as bien tenté le reset mode 2 ? https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS#t3

Je veux bien voir un screen de l'endroit où tu modifies le port de transfert de données de Drive. 🙂 Si c'est dans Portail des Applications tu n'as pas compris ce que je t'ai dit alors. Ton plan marcherait si tu pouvais définir un port personnalisé de manière bilatérale. Vu qu'on parle de synchronisation avec Drive, comment le serveur en retour sait-il qu'il doit contacter ton périphérique sur le port 26690 ? Lui il cherche le port 6690 de ton périphérique, quand il tombe sur le pare-feu du service informatique, il est bloqué actuellement. De plus, un intérêt particulier à changer le port ? Imposé par le service informatique ? Il n'y a aucun gain de sécurité à faire cela. Pour vérifier l'ouverture d'un port, tu peux utiliser nmap ou telnet.

Il y a deux choses différentes : l'interface Drive accessible depuis DSM, via port personnalisé ou proxy inversé. Ça on peut le modifier. Puis tu as le transit des données, qui se fait via le port TCP 6690 comme l'a dit @pluton212+. Pour synchroniser à distance ce port doit être redirigé vers ton NAS depuis ta box. Et ouvert dans le pare-feu du NAS. Pour une utilisation locale, il suffit qu'il soit ouvert dans le pare-feu. L'adresse à entrer dans Synology Drive Client est juste l'IP publique ou le DDNS ou nom de domaine qui pointe vers cette IP, sans préciser de port. EDIT : A noter que pour une utilisation combinée locale et externe, tu peux utiliser un serveur DNS local pour ne pas avoir à changer l'adresse du NAS.

Non pas forcément. Autant c'est très utile en macvlan, autant en bridge je suis plus dubitatif, mais ça ne mange pas de pain, tu peux le faire si tu le souhaites. 😛

Wilkommen !

@oracle7 Pour ma part je n'ai jamais besoin d'utiliser les IP, car dans un réseau bridge personnalisé j'utilise uniquement les noms de conteneurs. Et dans le réseau bridge par défaut, 172.17.0.1, ce sont généralement des conteneurs qui : - n'ont pas d'interface (watchtower) - ont leur ports translatés sur l'hôte si je dois y accéder depuis l'extérieur (calibre-web, emby, etc... la plupart des applications) Donc pour moi ça n'intervient jamais. Dans quel cas as-tu l'utilité de contacter un conteneur par son IP ?

Moi non plus, j'ai modifié le tutoriel pour ne pas limiter la plage IP, ça n'a de toute façon pas beaucoup d'intérêt de le faire pour une utilisation en tant que particulier.

@RF-Atomik Tu peux essayer de supprimer le réseau monitoring actuel (il faut arrêter et supprimer tous les conteneurs qui en font partie avant via docker-compose down), via SSH c'est : docker network rm monitoring Puis tu le recrées mais cette fois-ci tu ne précises pas d'IP range, donc : docker network create -d bridge \ --subnet=172.19.0.0/24 \ --gateway=172.19.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring Et tu recrées tes conteneurs. C'est peut-être l'IP range qui fait déconner le truc, pour une raison obscure car chez ça marche, mais je vois dans tes commandes que les IP attribuées au conteneur sont dans la plage /24 au lieu de /28. @Jeff777 Là comme ça je n'ai plus d'idée, il faudrait que je prenne la main via Teamviewer à l'occasion.

Ce n'est pas sensé avoir de conséquence. Tu peux taper en SSH sur le NAS : docker network inspect monitoring et docker container inspect telegraf et poser le résultat ici.

Je n'ai pas compris ta phrase. Ah si, tu veux dire que ton PC a une adresse en 10.0.10.x ?

@MilesTEG1 Ce n'est pas le même volume, le volume qui se monte dans les dossiers cachés de Docker c'est un volume qui est exposé dans le Dockerfile et que tu n'as pas précisé dans le fichier docker-compose, va voir sur Github dans le Dockerfile de l'image concernée, tu verras sûrement d'autres volumes à la fin du Dockerfile, outre celui que tu as monté dans /volume1/docker/....

Bah ça vient avec l'expérience ça 😉 Ca n'a juste rien à voir avec ce que je t'ai proposé. Là tu utilises un volume de type "bind" sur l'hôte, moi je te parle d'un volume docker : https://docs.docker.com/storage/volumes/