Mic13710

Parce que l'adresse mise dans Accès externe, Avancé est monsyno.synology.me et que cette adresse renvoie vers DSM. Pour éviter cela, il faut utiliser le reverse proxy et utiliser des adresses pour chaque application : nas.monsyno.synology.me pour l'accès à DSM file.monsyno.synology.me pour l'accès à file station audio.monsyno.synology.me pour audio station etc... L'adresse à indiquer pour les liens doit être sur file.monsyno.synology.me Quant à monsyno.synology.me si elle n'est pas redirigée par le reverse proxy, elle aboutira à une erreur 404. Ainsi, chaque accès est cloisonné et si toutefois il y a une tentative sur un ndd résolu, c'est le parefeu qui agira pour bloquer les tentatives avec des identifiants erronés.

Pour clarifier ce point, il faut comprendre que le port utilisé pour les liens partagés est celui spécifié dans Accès externe, Avancé. Si le port indiqué en https est le 443, il est évident qu'il ne sera pas indiqué dans le lien puisqu'il s'agit du port https par défaut. Tout autre port sera forcément incorporé dans le lien. Pour en revenir à cette histoire d'accès DSM, je ne comprends pas bien où est le problème. Certes un lien créé dans file station (ou dans Drive) va utiliser une adresse correspondant au NAS (normal pour pouvoir télécharger). Cette adresse peut être simplifiée par l'utilisateur dans le navigateur pour accéder à la racine (https://file.ndd) mais ce n'est qu'un accès vers la page d'accueil de file station (qui ne mène à rien sans des identifiants), en aucun cas un accès à DSM, ou alors il faut m'expliquer comment de file station vous passez à DSM.

Le port des liens de partage est celui spécifié dans Accès externe, Avancé. Vous changez le port https par celui que vous voulez et vous dirigez ce port dans le routeur vers le NAS. Vérifiez aussi que le port en question soit ouvert dans le parefeu du NAS.

@JPnux votre question n'a pas de rapport avec le présent tuto. Merci de la poser dans la section réservée au serveur VPN.

Le 412+ ne servait pas de sauvegarde du 923+ ? Si vos sauvegardes sont faites ailleurs, il n'est peut-être pas utile d'investir dans un nouveau modèle, série + de surcroit, pour uniquement récupérer quelques données. Tout d'abord, êtes vous sûr que c'est bien la carte mère qui est HS et pas le bloc alimentation ? Si c'est le NAS, vous pouvez tenter cette autre solution : utiliser le 923 pour récupérer les données. Vous sortez les disques du 923 (en repérant leur ordre pour pouvoir les remonter dans les même baies), vous montez les disques du 412 dans le 923 dans le même ordre. Vous mettez à jour DSM à l'aide de Synology Assistant, vous sauvegardez les données restantes sur le 412 (hyperbackup, autre, peu importe) sur ce que vous avez sous la main. Vous remontez les disques du 923. Il ne vous reste plus qu'à y restaurer les données sauvegardées précédemment.

C'est une blague ? 🙃 Pour les migrations, tout et là : https://www.synology.com/fr-fr/dsm/feature/migration La migration des disques est envisageable lorsque les caractéristiques des NAS sont proches. Sinon, ce n'est pas une bonne opération car vous importez toutes les limitations du groupe et vous ne pouvez pas profiter de toutes les applications compatibles avec votre nouveau NAS. Je vous conseille plutôt de partir sur une solution de restaurations de vos sauvegardes.

Comme l'a dit @morgyann, le RAID et la sauvegarde n'ont aucun rapport l'un avec l'autre. Le RAID est un support de stockage qui combine un ou plusieurs disques dans un groupe. Hormis le JBOD et le RAID0, un groupe RAID de plusieurs disques assure la continuité de service en cas de perte d'un disque (ou deux pour certains RAID). C'est tout !!!! Le RAID N'EST PAS UNE SAUVEGARDE ! La sauvegarde est une copie des données à un instant T. Elle est déconnectée de la source (pas de synchronisation). Elle permet de restaurer des données, effacées, corrompues, cryptolockées du dossier source. Une sauvegarde peut être effectuée sur tout support de stockage (basic, RAID, DD externe, ...). La sauvegarde fait partie intégrante de la gestion des données. Il est suicidaire de mettre en place une gestion centralisée des données sur un serveur sans y adjoindre un plan de sauvegarde périodique des données.

Je comprends que vous puissiez douter mais soyons logiques. Vous ne pouvez pas créer un système de stockage de données en RAID1 ou RAID5, voire RAID6, pour assurer la continuité de service en cas de panne d'un disque, et ne pas en faire de même sur les partitions qui gèrent le fonctionnement du dit système. Ça ne serait pas cohérent. Depuis la nuit des temps, les NAS et autres serveurs fonctionnent sur le même principe : partitions système et swap sont en RAID1 pour pallier la panne d'un ou plusieurs disques.

Impossible. Il faut bien que le système soit installé et il ne l'est que sur le disque. Sans disque, le NAS est une boite inutile.

😉 Synology sont en retard sur tout.... Vus mes besoins, je n'envisage pas pour le moment de passer en multigig. Wireguard est encore relativement récent et n'est donc pas dispo sur tous les équipements en natif. Ceci dit, Synology devrait se bouger pour l'introduire sur son serveur VPN. Ca devient une priorité si on considère le nombre croissant d'utilisateurs. Mais quand on a le choix, il est évident qu'un serveur VPN a plus sa place sur le routeur que sur un équipement du réseau.

Correctif : En dehors des AllowedIPs, toute IP dans la plage du réseau local du client sera traitée localement, les autres seront dirigées vers le net. Il en est (presque) de même pour les ndd: ceux qui sont dans le périmètre du serveur DNS du réseau distant transitent par le tunnel. Les autres qui sont résolus via les redirecteurs de ce même serveur DNS sont directement renvoyés sur le net. Ce qui de facto élimine un éventuel serveur DNS local. C'est en tout cas ce qui se passe chez moi. Lorsque j'établis un tunnel vers un réseau distant, mon serveur DNS local est inopérant car mes adresses locales ne peuvent plus être résolues localement. Seule mon IP publique est renvoyée. Pas encore essayé, il faudrait que je rajoute une zone esclave de ma zone locale sur le serveur DNS distant pour que ce soit l'adresse IP locale qui soit renvoyée.

Non, cette ip est celle que je demande à Wireguard, qui est associée aux clés publiques et privées du serveur et qui sera attribuée au PC. Les AllowedIPs sont les adresses ou plages d'adresses autorisées dans le tunnel. C'est ce qui permet de faire du split tunneling. Si je veux joindre mon NAS en 192.168.1.101 (qui est aussi le serveur DNS), il faut bien que l'IP soit autorisée à transiter par le tunnel. Dans le cas de mon exemple, 192.168.1.0/24 couvre toutes les IP privées du réseau local de destination. Toute autre IP sera rejetée et envoyée vers le net. Par défaut les allowedIPs est 0.0.0.0 qui fait tout passer par le tunnel.

Le partage de dossiers/fichiers n'a rien à voir avec le VPN. Le lien est créé par DSM et si le paramétrage de votre NAS est correct, ce lien permettra à vos utilisateurs externes d'accéder au seul dossier/fichier à partir de file station avec un mdp ou pas si vous n'en avez pas indiqué. Je ne connais pas nextcloud....

Le paramétrage d'un de mes clients : [Interface] PrivateKey = "Ma clé très privée" Address = 10.6.0.2/32 'mon IP de connexion au serveur Wireguard' DNS = 192.168.1.101 'le serveur DNS local du NAS' (on peut en spécifier plusieurs, les IP séparées par des virgules) [Peer] PublicKey = La clé publique du serveur Wireguard' AllowedIPs = 192.168.1.0/24 'plage d'IP du réseau de destination' Endpoint = NDDDuDomaineDeDestination:51820 'c'est le port de destination par défaut mais on peut en choisir un autre' PersistentKeepalive = 25

Il vous faut quand même cette règle mais en la limitant comme je l'ai indiqué pour pouvoir utiliser vos applications en dehors du VPN. Si par exemple vous voulez utiliser Synology Drive, il faudra bien ouvrir le port 6690 sinon l'appli ne pourra pas fonctionner en dehors du VPN. Et s'agissant d'un cloud, ça peut devenir gênant.Il vous faudra de toute manière ouvrir au moins le port 443 pour l'utilisation du reverse proxy dont je parle plus bas. Vous en avez un, c'est xxx.synology.me. A partir de là, vous pouvez créer autant de domaines de second niveau que vous voulez comme par exemple video.xxx.synology.me, nas.xxx.synology.me. Pour simplifier et ne pas avoir a saisir un CNAME pour chaque domaine, vous pouvez faire une entrée unique CNAME en wildcard *.xxx.synology.me. Cette entrée couvrira tous les domaines yyy.xxx.synology.me. Mais pour que chaque domaine yyy.xxx.synology.me soit dirigé vers la bonne appli, il faudra paramétrer le reverse proxy du NAS qui pour un domaine donné dirigera la requête vers la bonne application. Par exemple, pour le ndd https:\\nas.xxx.synology.me, le reverse proxy redirigera la requête vers http://localhost:5000 où localhost est le NAS et 5000 le port http de DSM. Vous avez un tuto de kawamashi qui traite du reverse proxy. Sans reverse proxy, si vous n'utilisez pas audio station par exemple, inutile d'ouvrir le port correspondant. De même, vous n'ouvrez pas vers l'extérieur des ports http. Uniquement du https.

@CyberFr, les paramètres de connexion sont à faire côté client. C'est là qu'on défini la plage d'IP autorisée ainsi que les serveurs DNS faisant autorité. P.S. : cette discussion s'éloigne fortement du sujet initial. Elle devrait se poursuivre sur un sujet dédié à Wireguard.

Si le 5001 est dirigé vers le NAS dans le routeur, il n'y a rien d'anormal puisque vous avez ouvert tous les ports vers l'extérieur (avant dernière règle de votre parefeu). Je vous conseille vivement de revoir cette règle pour limiter l'accès aux seules applications que vous utilisez. Et si vous paramétrez le serveur DNS local, vous pourrez même désactiver le plupart des ports pour ne garder que l'essentiel : 443 et les ports spécifiques à certaines applications (6690 par exemple pour Synology Drive)

@CyberFr petite discussion concernant wireguard et le split tunneling

Si vous voulez utiliser votre ndd, il faut commencer par mettre en oeuvre un serveur DNS local comme expliqué plus haut (voir tuto de Fenrir sur le serveur DNS). Ceci ne garantie pas que ça fonctionnera car windows a ses propres modes obscurs de résolution de ndd qui contournent (ou pas) le VPN. Par exemple, mes deux PC sous win10 avec la même configuration et le serveur DNS du NAS en service, l'un passe bien par le DNS local, l'autre passe par le net et je n'ai jamais pu résoudre ce comportement.

Le port 5001 est en TCP ! Pas sûr que vous passiez par le net. Lorsque vous êtes connecté au VPN, qu'elle IP renvoie en ligne de commande tracert VotreDDNSSynology ?

Je ne comprends pas bien cette phrase. Si vous voulez utiliser votre domaine pour vous connecter au NAS par VPN, c'est avec remote VotreDDNSSynology 1194 dans le fichier de configuration du client. Si par contre, vous voulez utiliser votre domaine une fois la connexion VPN établie, sauf à utiliser un serveur DNS local (autre tuto de Fenrir), ce n'est pas possible. Il faut dans ce cas utiliser les adresses IP locales (192.168.x.x)

Est-ce que vous comprenez ce qu'est un RAID1 ? Si oui, alors vous comprenez que de retirer un disque n'a pas d'impact, le système continuant de fonctionner sur le ou les disques restants. Par contre, vous perdrez bien évidemment les données du volume 1. Je vous invite à relire ce que j'ai écrit plus haut à ce sujet. Retirer le disque du volume 1 ne détruit pas le volume 2. Il n'y a aucun risque pour les données. Par contre, il vous faudra réinstaller HyperBackup Vault après avoir retiré le disque puisque toutes les applications sont installées sur le volume 1 par défaut. Il faudra peut-être recréer vos tâches de sauvegardes en les reconnectant à des sauvegardes existantes. D'où l'importance de d'abord sauvegarder vos applications à l'aide de Hyperbackup avant de détuire votre volume. P.S. : mis à part votre méprise concernant le disque système, je ne comprends pas pourquoi vous voulez à tout prix réinstaller un nouveau disque pour remplacer celui du volume 1. Ce volume semble avoir peu ou pas de données et ce peu de données peut aisément être transféré sur le volume 2. Vous vous épargnez ainsi l'achat inutile d'un disque.

@dadoupipo Chaque compte utilisant le 2FA (admin ou utilisateur) a sa propre clé aléatoire et unique et donc le code généré est différent pour chaque compte. Pour ne pas vous trouver bloqué en cas de perte ou de vol de votre smartphone, je vous conseille fortement de sauvegarder la clé que vous pourrez ensuite utiliser sur toute application OTP. Je vous invite à consulter (et mettre en pratique) le tuto sur la sécurisation de nos NAS. Vous y trouverez toutes les explications pour la sauvegarde de la clé.

@CyberFr, c'est dispo sur toutes les freebox. Je ne sais pas pour les autres FAI, mais quel qu'il soit, on peut rajouter son propre routeur pour s'affranchir des limitations des box. Je signalais juste que même si le VPN fonctionne bien sur le NAS, ce n'est pas l'équipement le plus approprié pour cette fonction. Ca reste toutefois une excellente solution quand il n'y a pas d'autre possibilité. Avec le VPN installé sur le routeur, on n'est pas tributaire du fonctionnement du NAS et on peut intervenir plus facilement sur ce dernier.