.Shad.

Voir le message de @Mic13710, je ne dis pas que c'est lié, je dis que ça commence à faire pas mal de retours concernant des problèmes avec OpenVPN depuis l'update 5. En l'état je t'invite à suivre le sujet et le forum officiel Synology : https://community.synology.com/enu/forum/1

Très intéressant, merci @maxou56 !

Tiens-nous au courant du résultat final, je suis étonné de voir qu'en supprimant récursivement dans / tu arrives à réinstaller DSM, c'est donc que la partition de démarrage est dans une partition autre, bonne nouvelle.

@baz1ga Salut, c'est bien tu te poses les bonnes questions ! Première remarque, ne pas jeter ton DS212+, il est encore tout à fait viable pour : - être un simple stockage - être une destination de sauvegarde Tu peux effectivement partir sur un NAS plus récent compatible Docker/VMM, vérifier si tu as besoin d'un iGPU ou pas (utilisation de plex/emby/... en transcodage par exemple). Tu devras alors faire une sauvegarde Hyper Backup de tes données pour ne pas simplement migrer mais reconfigurer ton système, afin de profiter des fonctionnalités apportées par le système de fichiers BTRFS vs EXT3 ou EXT4. Ou alors, tu achètes un mini-pc genre celui que je vends 😄 : https://www.nas-forum.com/forum/topic/76704-mini-pc-qotom-i3-pfsense-opnsense-etc/) ou bien sûr un autre type NUC, qui hébergera tes applications, et utilisera des montages réseau pour accéder aux données stockées sur les disques de ton NAS. C'est ce que je fais depuis plusieurs années maintenantavec un DIY sous Debian, j'en suis très satisfait. Attention qu'il faudra réfléchir à ta stratégie de sauvegarde, sachant qu'en DIY tu n'auras pas le même confort de configuration que sur DSM. Après, une fois que c'est en place, ça fonctionne tout aussi bien, ça demande juste de mettre un peu plus les mains dans le cambouis. Et tes Rpi pourront tout à fait servir pour faire la redondance des services hébergés sur ton nouveau NAS ou mini-pc, Pi-hole par exemple. 😉

Bienvenue par nous, je te conseille de jeter un oeil au sujet dédié à la sécurisation des accès au NAS :

En partant de quelle version ? Tu peux déjà essayer de modifier les DNS utilisés par le NAS, c'est dans Panneau de configuration -> Réseau -> Cocher Configurer manuellement le serveur DNS et tu peux mettre par exemple ces deux adresses : 9.9.9.9 1.0.0.1 Vérifier ensuite si tu as toujours des problèmes de connectivité.

C'est une erreur de résolution DNS. Le port 59999 c'est a priori le port sortant, tu n'as pas à t'en soucier, un périphérique choisi généralement le port sortant qu'il souhaite, plutôt dans les valeurs hautes que basses (qui sont réservées à des applications système et/ou bien définies). Je veux bien qu'on décortique ensemble en TeamViewer, Discord, Teams, etc... (envoie moi un MP avec tes dispos) mais t'expliquer ce que j'ai fait ne mènera pas à grand chose. Je pense que s'il y a un problème je le verrai bien plus rapidement de visu, qu'en échangeant encore X messages pour tenter de trouver l'aiguille dans la botte de foin. Et parce que c'est un forum, il faudra faire un debrief de la résolution du problème, histoire que ça profite au plus grand nombre.

Synology recommande de ne pas utiliser de bond avec le SMB Multichannel, visiblement ça marche quand même, au moins avec une seule autre connexion. Je ne vois pas l'intérêt de garder l'agrégation de liens avec le multichannel. L'activation des jumbo frames est à double tranchant, voir cet article : https://netcraftsmen.com/just-say-no-to-jumbo-frames/ Les disques et le schéma de RAID utilisé sont en effet des éléments limitants, un RAID 0 (ou 10) offira les meilleures performances car on écrit en // sur les disques. Un SHR2 sera le plus handicapant. Avec des disques mécaniques tu seras limité, sachant qu'un HDD suivant sa vitesse de rotation et sa qualité, acceptera entre 100 et 200 Mo/s en vitesse de transfert. Au-delà, il faudra utiliser des SSD à la place des HDD.

Tu peux faire une impression d'écran de ton pare-feu ? Tu n'as besoin que d'une règle, celle qui autorise Hyper Backup Vault : C'est encore mieux si tu peux limiter à une seule IP si tu as la chance d'avoir une IP fixe sur la connexion de ton NAS principal. Là je parle en IPv4. Si tu veux fonctionner en IPv6, et que le préfixe de ta connexion IPv6 est fixe (les xx premiers octets de ton adresse IP, également appelé le préfixe), tu peux autoriser l'IPv6 du NAS principal, exemple : Je ne veux pas t'embrouiller avec le préfixe qui permet d'identifier ton réseau IPv6 sur le réseau de ton NAS principal, sache juste que si tu autorises ce réseau, c'est un fonctionnement équivalent à l'IPv4 et ton IP publique au niveau de la box. En revanche, dans ton cas présent, si tu essaies d'atteindre ton NAS distant via son IPv6, tu dois être certain que : - tu aies une connectivité IPv6 au niveau de ton NAS principal - que le pare-feu de la box du réseau distant autorise les connexions entrantes sur le NAS en IPv6 Suivant les box, tu auras plus ou moins la possibilité de modifier le pare-feu IPv6 (qui se contente parfois d'avoir uniquement un niveau de réglage Faible - Moyen - Fort plutôt que de donner la possibilité d'ajouter des règles personnalisées). Si ton pare-feu IPv6 n'est pas configurable sur ta box, tu devras passer par l'IPv4, pas le choix. @Mic13710 Le port 6281 d'HBK s'expose de façon chiffrée si on a un certificat valide associé au service Hyper Backup Vault dans DSM.

Hello ! Bienvenue parmi nous 🙂

@Dimebag Darrell Ah ? moi, même en root (quand je ne précise pas de user dans le fichier compose), ça ne fonctionne pas. En revanche j'ai procédé autrement, pour éviter de devoir toucher aux permissions du socket docker. J'ai utilisé l'image https://github.com/sjawhar/docker-socket-proxy qui permet d'exposer via un conteneur un socket docker. Et ce conteneur est dans un réseau uniquement composé de telegraf et lui-même. Ainsi Telegraf accède au socket via les permissions natives, et je n'utilise pas de certificat TLS (contrairement à ce que je fais dans ce tutoriel) car seul Telegraf peut avoir accès au socket, ce que j'estime ne pas représenter de danger outre-mesure. Mon fichier compose pour le proxy : version: "2.1" services: docker-socket-proxy: image: sjawhar/docker-socket-proxy container_name: docker-socket-proxy hostname: docker-socket-proxy networks: - net-dsp environment: - LISTEN_SECURE=false - LISTEN_PORT=2375 volumes: - /var/run/docker.sock:/var/run/docker.sock:ro labels: - "com.centurylinklabs.watchtower.enable=true" restart: unless-stopped networks: net-dsp: external: true net-dsp est le réseau qui accueille également Telegraf, dont le compose est le suivant chez moi : version: "2.1" services: telegraf: image: telegraf container_name: telegraf networks: - net-dsp # non-root user needed since 1.20.3 user: telegraf:65536 volumes: # config - /volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro # additional MIBs - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro # local time preset - /etc/localtime:/etc/localtime:ro - /etc/TZ:/etc/timezone:ro # docker socket mounting - /var/run/docker.sock:/var/run/docker.sock:ro labels: # watchtower label only monitoring - "com.centurylinklabs.watchtower.enable=true" restart: unless-stopped networks: net-dsp: external: true Remarque : C'est normal que Telegraf ne partage pas de réseau commun avec InfluxDB et Grafana, ces derniers sont sur un VPS dans mon cas, il accède donc à InfluxDB via son entrée de proxy inversé sur le VPS directement.

Je serais étonné qu'un reset fonctionne si tu as vraiment supprimé tout le contenu de ta racine. Car je pense que la partition de boot est incluse dans / A vérifier mais j'ai des gros doutes...

Le résultat est le même, c'est l'accessibilité qui change. L'avantage d'avoir une authentification par clé, c'est que ça exclut d'emblée tous les périphériques dont les clés publiques n'ont pas été ajoutées au fichier authorized_keys. L'autre intérêt d'une clé (mais sans mot de passe) est de permettre l'exécution de scripts à distance.

Welcome !

Si je suis cette vidéo, c'est un virtual server que tu dois créer du coup, et pas un port triggering comme dans ton impression d'écran. Il ne faut rien mettre dans la DMZ du routeur en effet. Vu de loin oui, vu de près non. Quand tu es en bridge mode, ce n'est plus juste un transfert de toutes les règles NAT vers le périphérique mis dans la DMZ. C'est la possibilité d'obtenir directement sur la patte WAN une IP publique de la part de ton FAI. Le modem n'est vraiment plus que là pour la connectivité avec le FAI, tout le reste est délégué au routeur en aval. Ils sont encore meilleurs en Belgique. 😉 La règle avec le port source n'a pas lieu d'être, car le client utilisera le port qu'il veut au sortir de sa machine. Tu peux également limiter à TCP au lieu de TCP/UDP. Je ne vois le 32401 nulle part dans leur doc : What network ports do I need to allow through my firewall? | Plex Support A priori, en l'état, si ton serveur est déjà configuré (il faut se connecter à l'UI la première fois localement pour "claim" le serveur), tu devrais pouvoir y accéder via http://IP_PUBLIQUE:32400 Remarques : Il est plus pratique d'avoir un petit nom de domaine pour atterrir chez soi, Synology en fournit un gratuitement, ou tu peux en acheter un pas cher (quelques € par an) Pas de chiffrement des données en l'état Oui, il faut un peu de temps pour bien comprendre comment ça fonctionne, donc pas de précipitation. 😉

Bienvenue parmi nous !

Hello, Si tu parcours le sujet sur la sécurité donné par @Mic13710 dans ta présentation, tu y liras que la "configuration du routeur" une fonction à proscrire car faille de sécurité majeure. N'importe quel malware pourrait ouvrir ton NAS à tous les vents. La redirection de port ou port forwarding est quelque d'assez simple à mettre en place. Est-ce que ton routeur vient se placer derrière ta box ? Si oui, je te conseille de placer ton routeur dans la DMZ de la Livebox, et tu pourras supprimer tes redirections de port dans celle-ci. Car c'est vers le routeur que tous les ports seront automatiquement redirigés. Dans ton routeur TP-Link, ce n'est pas du port triggering que tu dois mettre en place mais du port forwarding. Le port triggering est une ouverture qui se déclenche à la demande, mais la demande doit venir de l'intérieur du réseau et pas de l'extérieur. La règle est sensiblement la même que celle dans ton port triggering. Donc DMZ Livebox -> Routeur + règle de port forwarding du port 32400 => tu arrives aux portes du NAS. A ce niveau-là, il te faudra autoriser le port 32400 pour les IP qui t'intéressent, donc j'imagine les IP locales + par exemple une géolocalisation française. Normalement, tu seras en mesure d'accéder à ton NAS à distance en liaison directe après avoir vérifié tous ces points. En l'état, ce sera une connexion HTTP, pas HTTPS, ce qui présuppose qu'un Man In The Middle (MITM) pourrait intercepter tes identifiants, même si c'est peu probable. Si vraiment tu veux avoir un accès distant robuste, mes conseils : Te concentrer sur la sécurité et la surface d'exposition de ton NAS via le tutoriel : [TUTO] Sécuriser les accès à son nas - Tutoriels - NAS-Forum Appliquer ce que je t'ai dit plus avant, et vérifier que l'accès distant est fonctionnel Désactiver l'accessibilité du port de Plex à distance temporairement dans le pare-feu du NAS Mettre en place le proxy inversé pour sécuriser ton accès distant : [Tuto] Reverse Proxy - Tutoriels - NAS-Forum

Bienvenue parmi nous ! 🙂

Tu peux aussi apporter ton témoignage sur le sujet suivant, qui sait ce qui pourrait en ressortir :

Si tu es prêt à mettre les pieds dans Docker, tu peux très bien créer un conteneur intégrant un soft de download (Deluge, qBittorrent, etc...) couplé à un client VPN. Par exemple : binhex/arch-delugevpn - Docker Image | Docker Hub Et niveau ressources c'est peanuts.

@MilesTEG1 Beau boulot, remarques : Avoir UseTLS et UseSTARTTLS simultanément est contradictoire. Si tu utilises le port 587 c'est STARTTLS et tu peux désactiver UseTLS. Attention aux droits lorsque tu montes le fichier ssmtp.conf sur ton NAS Ajouter des DNS n'est utile que s'ils diffèrent de ceux utilisés par la résolution DNS Docker, qui se base sur celle de l'hôte.

Bienvenue parmi nous !

Cette suggestion n'avait rien à faire là. On n'installe pas des paquets sur un SSD externe, ni sur un HDD d'ailleurs. Il parlait d'un volume de SSD. C'est une discussion complètement différente qui n'a rien à faire ici. Si tu m'envoies un lien TeamViewer par MP je veux bien regarder. La discussion tourne en rond ici.

Voir mon impression d'écran et mes explications dans mon message de 21h21 hier. Ce serait bien de créer un autre sujet non ?

@ewfzapp J'ai rien pigé rien ne fonctionne c'est un peu vague. Ca coince où ? Qu'est-ce que tu ne comprends pas ?