Mic13710

Ce n'est pas celui du syno qu'il faut renseigner mais le ndd qui permet d'atteindre le routeur. Ensuite, la redirection du port 1194 vers le NAS se charge de transmettre la demande de connexion au serveur VPN.

Je ne sais pas sur quelle page tu travailles, mais si c'est sur la création d'une interface réseau, alors les choses ont beaucoup évolué sur 7.2 par rapport à 7.1. Apparemment, il faut maintenant importer le certificat comme à l'ancienne. Si l'import du certificat associé à DSM ne fonctionne pas, je ne sais pas quoi te dire pour t'aider.

@StéphanH, oui mais il n'est pas nécessaire à partir du moment où tu importes le fichier ovpn qui contient déjà le certificat. C'est expliqué si tu cliques sur le "i" à côté de la zone de saisie du Certificat CA.

??? Nous n'avons aucune action sur les signatures. C'est entièrement sous votre gestion. C'est dans Paramètres du compte - Signature.

Il faut d'abord choisir dans DSM le certificat à appliquer au serveur VPN. Le certificat sera intégré au fichier de config openVPN. Il n'y a rien à importer sur le client comme c'était le cas il y a quelques années.

Bonjour @AxL93, soyez le bienvenu.

@benworld changer la pile interne peut-être ?

@falcon1, super. Il faudrait aussi mettre à jour votre signature : RS815+ + RX415 : WesternDigital RED 2"1/2 et 3"1/2 + WD Scorpio Black n'est plus d'actualité 😉

Si c'est le cas (renouvellement LE) alors il y a une forte probabilité que ce soit ça. Si tu veux ne pas avoir de problème à chaque renouvellement, il faut plutôt associer le serveur VPN au certificat synology.com par défaut qui lui a une validité bien plus grande que celle des certificats LE. Si tu n'as plus ce certificat, tu peux en créer un autosigné (avec openssl par exemple) d'une durée de validité de 15 ans pour être tranquille.

Je pense que vous devriez relire le tuto. Il y a bien deux zones, une locale et une publique, mais elles ne sont pas toutes à mettre en oeuvre. Le seul tuto de Fenrir que nous connaissons ici est celui-ci : Et ce qu'il dit en préambule est assez explicite : "Il n'y a aucune raison technique qui nécessite de faire la dernière partie, elle est là pour illustrer un peu plus le fonctionnement d'une architecture DNS, mais elle n'est en aucun cas nécessaire. " Cette dernière partie qui traite de la zone publique, ne vous concerne pas. Et, sans vouloir être désobligeant, vu comment vous l'avez abordée, elle ne risque pas de fonctionner. Contentez vous de la zone DNS locale et tout ira bien.

Jamais fait ça et je ne peux même pas essayer car mes NAS sont tous en simple volume, mais je ne pense pas que ça soit possible en local. S'il s'agit de synchro, pourquoi ne pas tout simplement utiliser Drive ? Vous avez ainsi un Cloud entre votre NAS et votre PC, et en inhibant la syncho à la demande, vous avez vos fichiers à l'identique sur le NAS et sur le PC. Attention, cette solution n'est en aucun cas une sauvegarde qu'il faudra de toute façon mettre en place par ailleurs. De ce que j'ai compris, vous avez déjà prévu une sauvegarde distante, donc pas de souci de ce côté là.

Problème aussi ici : Tout ça devrait s'améliorer avec le temps.

OK merci. Du coup, tout ce qui est en couleur est beaucoup moins visible. Par exemple, les signatures ou encore les pseudos d'admin ou des modos.

Il faut partir d'un dossier vide.

Intéressant. Question bête: comment passe t'on au mode sombre ?

Vous pouviez conserver le SHR et monter deux groupes SHR sans protection des données. En fait vous avez deux types de RAID sur les NAS synology : le RAID classique et le SHR. Le RAID classique comprend le basic, RAID1, RAID5, RAID6, et plus selon le modèle de NAS. Le SHR sans protection des données est équivalent au basic. Le SHR avec protection des données est un RAID hybride qui combine RAID1 et RAID5. Le SHR2 quant à lui est un RAID qui peut comprendre un ou plusieurs RAID6. Le choix du type de RAID (classique ou SHR) se fait au départ. Il n'y a pas de passerelle possible entre les deux.

Faites bien attention au montage de bien séparer vos disques car par défaut DSM installera un SHR avec protection des données. Soyez vigilant. Par ailleurs et comme je l'ai dit, un groupe de 1 disque sera toujours géré par un système RAID. Même si par convention on parle d'un disque en basic, il s'agit en réalité d'un RAID monodisque. La notion de basic n'existe pas sur un NAS multibaie.

Vous faites des confusions entre volume et groupe. Un groupe est comme son nom l'indique, un groupe de disques. Ils fonctionnent ensemble et sont contrôlés par un RAID logiciel qui peut être du RAID0, JBOD, RAID1,5,6 etc... Sur un groupe, vous pouvez monter un ou plusieurs volumes. La notion de groupe s'entend pour un ensemble de disques de 1 à plusieurs disques. Exception faite du groupe de 1 disque, les disques ne sont pas indépendants. Et donc si vous montez vos disques dans un seul groupe, vous ne répondez pas aux critères que vous avez définis en préambule. Pour faire ce que vous souhaitez, la seule possibilité qui répond à vos critères c'est de créer deux groupes, un par disque, et sur chaque disque vous pourrez monter un ou plusieurs volumes. Mais je pense qu'un seul volume par groupe sera suffisant. Chaque groupe étant indépendant, la perte d'un disque n'entraine pas de perte du deuxième. Vous pourriez créer un groupe en RAID0 ou en JBOD sur lequel vous montez plusieurs volumes pour avoir la totalité du stockage. Le problème avec cette configuration c'est que la perte d'un disque entraine la perte de la totalité des données si RAID0, de celles du disque en panne, sans savoir lesquelles si JBOD et de grandes difficultés pour récupérer les données du disque sain.

@rodo37 Est-ce que c'est possible ?

C'est un peu ce que j'ai sous entendu. Le seul accès à DSM lorsque je suis à l'extérieur se fait via le VPN. Cependant, sur les NAS distants dont je m'occupe, j'ai rajouté mon IP fixe dans le profil de contrôle. Je m'y connecte toujours via le VPN, mais en cas de dysfonctionnement, je me réserve la possibilité d'y accéder en https.

Pourquoi vouloir augmenter la RAM si votre utilisation se borne à du stockage de fichiers ? Dans ce type d'utilisation, la mémoire d'origine est largement suffisante. Vous pourrez voir par la suite si le besoin s'en fait sentir à rajouter de la mémoire.

A quoi sert le reverse proxy alors ? Par ailleurs, l'accès à DSM est assez limité en règle générale. Il sert en principe pour faire des paramétrages et des mises à jours de DSM et des applications, des opérations de sauvegarde/restauration. Il est toujours préférable de faire ce genre de manips à partir du réseau du NAS, ne serait-ce que pour pouvoir intervenir physiquement au cas où ça se passe mal. Dans ce cas, l'ouverture du 5001 vers l'extérieur n'est pas utile. Et si vous utilisez le reverse proxy, vous pouvez créer une règle pour l'accès à DSM du genre nas.ndd en https qui vous redirige vers l'IP du NAS port 5000, et vous appliquez un profil de contrôle d'accès qui n'autorise que les adresses ip privées, et éventuellement quelques IP publiques dont vous êtes absolument sûrs de leur propriétaires.

Désolé @ml78 mais ce n'est pas ce que vous avez dit. Par cette méthode, il s'agit ni plus ni moins d'une migration de disques du 216J vers le 218. Donc perte du BTRFS et de ses avantages, et import des limitations du 216j.

Vous ne pourrez jamais résoudre des ip privées chez OVH. Vous ne pouvez mettre dans la zone OVH que des ip publiques. Dans votre cas, il s'agit de l'IP publique de votre routeur que vous associez à votre nom de domaine, soit à un enregistrement A si votre IP publique est statique, soit en passant par le DynHost d'OVH que vous associez au NAS à partir de l'onglet DDNS du menu accès externe de DSM si votre IP est dynamique Il faut comprendre que toute requête effectuée sur internet sur votre ndd sera résolue à l'aide des serveurs DNS répartis dans le monde. Ces serveurs ne connaissent que ce qui est inscrit dans la zone d'OVH, a savoir pour simplifier, votre IP Publique. La requête sera lors dirigée vers votre routeur et c'est ensuite à vous de diriger cette même requête vers votre NAS en faisant un transfert du port 443 vers celui du NAS. La suite est affaire de serveur DNS et de reverse proxy qu'il faut paramétrer dans le NAS. Comme vous l'a dit @PiwiLAbruti, vous ne pouvez pas faire cohabiter deux zones sur le serveur DNS qui utilisent le même ndd et les mêmes IP privées. Un ndd,une seule zone pour la partie privée.

Parce qu'en restaurant sur le serveur, tu as encore la version sur le client. Si tu supprimes des deux côtés avant restauration, tu élimines la probabilité que le client prenne le dessus sur le serveur. Ca fonctionnait il y a peu de temps. Mais comme j'ai désactivé cette fonction car il y avait trop de notifications et que ça me saoulait grave, je ne sais pas si ça fonctionne encore. Vérifie que tu n'as pas inhibé les notifs dans tes paramètres.