Mic13710

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

@neo-noob que vient faire cette question dans la section "Nos membres racontent ?" Il y a un descriptif en tête de chaque section. Merci d'y porter attention avant de poster. Je déplace mais veillez à l'avenir respecter l'organisation de ce forum.

Pour pouvoir vous répondre, il faut fournir un capture d'écran de votre parefeu.

Tout d'abord, il ne peut y avoir qu'une seule instance wireguard sur un compte de l'Asus. Si vous pouvez utiliser les mêmes paramètres sur plusieurs clients, ils ne peuvent pas être connectés simultanément. Si vous voulez le faire, il faut alors paramétrer une connexion spécifique pour chaque client. Ensuite, ce n'est pas parce que le client indique que la connexion est activée qu'elle est réellement établie. Pour savoir si la connexion est effective, il faut regarder en bas de l'encadré "homologue" s'il y a des transferts. C'est la seule information fiable côté client qui permet de s'assurer que le lien est bien établi. S'il n'y a pas de transfert, il faut vérifier pourquoi et corriger. Attention aussi au point de terminaison de l'homologue. Si votre IP est dynamique, il faut impérativement indiquer votre DDNS en lieu et place de l'IP. Lors de la connexion, le DDNS sera remplacé par votre IP actuelle. Vérifiez aussi que les IP autorisées couvrent la totalité de votre plage d'IP privée. Vous devriez avoir quelque chose comme ça : 192.168.x.0/24

@guillb Le RT-AX58U est compatible avec Wireguard. S'il n'est pas installé sur votre routeur, il faut faire une mise à jour du firmware vers la version 3.0.0.4.388.xxxxx ou supérieure. Pourquoi ne pas utiliser cette solution qui est bien plus simple à mettre en oeuvre et beaucoup plus rapide qu'openVPN ?

Avec un 218+ ? Il me semble que le BTRFS était déjà le format par défaut sur ces modèles. Vos disques ont-ils été migrés d'un ancien NAS ? Si oui, alors vous avez importé du même coup les limitations sur le stockage du NAS d'origine. Je vous conseille de tout reprendre à zéro, y compris une réinstallation de DSM (la dernière version opère une augmentation de la partition système) pour que votre stockage soit en adéquation avec votre NAS. Pas forcément. On pourrait simplement supprimer volume et groupe et en recréer de nouveaux en BTRFS. Ceci dit tu as raison sur le fond puisqu'il faut aussi en profiter pour remettre à jour la partition système ce qui passe par une réinstallation de DSM.

Oui mais pas forcément un autre smartphone comme dit plus haut. Il n'y a pas non plus que Google Authenticator (que je n'utilise pas d'ailleurs) dans le monde de l'OTP. En dehors des smartphones, un PC sous Windows ou Linux, un MAC, tous sont à même de générer ces codes avec les outils appropriés.

Euh, il faudrait éviter de lire en diagonale.... Je ne vais pas tous les lister mais une simple recherche sur internet et on trouve quelques logiciels qui font ça. Ce lien par exemple en cite quelques uns : https://www.kaspersky.fr/blog/best-authenticator-apps-2022/18387/ Et moi je l'utilise pour tous les comptes administrateurs (et seulement ceux-ci), avec bien entendu les précautions qui s'imposent en ce qui concerne la clé et les supports. Il faut par contre s'assurer que les horloges (NAS, Smartphones, PC, autres...) soient à l'heure exacte sinon ça ne fonctionnera pas. Exception faite d'un problème de synchro d'horloge au tout début qui m'a contraint à passer par un reset, Je n'ai jamais eu de problème avec le 2FA. Quant à Secure sign-in, je ne peux rien dire, je ne l'utilise pas.

On ne cesse de le répéter, il ne faut surtout pas se limiter à un seul support pour la génération des codes 2FA sinon on s'expose à ce qui est précisément l'objet de ce message. Le 2FA fonctionne sur une base temps et une clé. Cette clé est générée lors de la mise en place du 2FA. Elle peut être récupérée via un QR code ou en alphanumérique au choix. On en parle dans le tuto sur la sécurisation de nos NAS. D'une part, il est fortement conseillé de sauvegarder cette clé, sur un gestionnaire de mdp par exemple, ensuite on peut utiliser tout logiciel d'OTP pour générer le code. Par exemple sur Android il y a FreeOTP, et les gestionnaires de mdp multi plateformes ont aussi cette possibilité soit en natif, soit avec un addon comme par exemple KeeOTP sur keepass. Bref, ceci pour dire que la double authentification est sécurisante du point de vue accès, encore faut-il s'assurer de pouvoir récupérer les codes avec la clé ou le QR code, et sur des supports différents.

Pour des raisons qui le regarde, c'est bliz lui-même qui a supprimé tous ses messages ce qui rend le sujet un peu décousu. Vous avez compris que les dossiers ou fichiers qui n'apparaissent pas sont liés à l'indexation. Il faut la relancer pour remettre à jour les vignettes.

Sur quel modèle de NAS ? Si vous utilisez synology drive, c'est probablement son dossier caché qui occupe de la place. Pour lister les dossiers et leurs poids, vous activez le SSH de votre NAS, vous ouvrez un terminal (sous windows vous avez putty que vous trouverez facilement sur internet), vous vous connectez avec les mêmes identifiants que ceux du compte administrateur du NAS et vous lancez la commande suivante : df -h Il faut patienter un moment pour obtenir le résultat.

Que votre opérateur soit orange, rouge, vert ou arc-en-ciel ne change rien à l'affaire. Il vous donne une IP privée interne (celle que vous voyez de votre smartphone) qui est associée avec plusieurs autres à une seule IP publique (celle de votre DDNS). Le seul moyen à ma connaissance pour y palier et de passer par un VPS. Il y a un tuto qui traite de ce sujet dans la partie tutoriels.

J'avoue être un peu perplexe. D'un côté il n'y a pas d'utilité d'un wildcard, de l'autre on parle de Reverse Proxy. Si Reverse Proxy il y a, il y a aussi des ndd pour chaque application sinon je ne vois pas son utilité. DSM ne sait pas gérer des wildcard autres que ceux associées aux ndd synology.me. Pour les autres ndd, il faut lister chaque ndd associé dans la section "autre nom" ce qui oblige à bien étudier le besoin pour n'en oublier aucun. Mais une fois que les noms sont en place, DSM doit être capable d'assurer le renouvellement automatique du certificat. Et si ce renouvellement automatique fonctionne et que l'accès au NAS par le port 80 est bien encadré, je ne vois pas de problème particulier pour qu'il soit fait via DSM.

Pour les alertes de sécurité sur les ports par défaut, vous pouvez sans problème les désactiver. Ce n'est qu'un conseil, pas une obligation. Ça n'a strictement aucune importance du point de vue sécurité, surtout si vous passez par le reverse proxy. Il faut simplement s'assurer que ces ports ne soient pas ouverts vers l'extérieur dans le routeur (sauf bien entendu les ports propriétaires)

Vous n'avez besoin que d'un seul DynHost ! Celui-ci doit être établi sur le ndd principal, les autre domaines qui en dérivent font l'objet d'un enregistrement wildcard dans la zone DNS. Dans le DynHost, votre entrée est faite sur le ndd que vous avez choisi pour joindre votre routeur. Si vous n'avez qu'un seul site, il faut laisser vide la case "sous-domaine". Vous créez ensuite une entrée CNAME dans la zone DNS, dans la partie sous-domaine vous entrez "*" (sans les guillemets), et dans la cible le domaine du DynHost. Vous ne pouvez gérer qu'un seul DynHost par Registrar. C'est donc obligatoirement et seulement celui que vous avez créé chez OVH. Les ndd dérivés seront résolus par l'entrée CNAME.

@Flamby55 si vous avez fait plusieurs demandes de certificat, ça peut être la cause du refus de renouvellement. En effet, Let's Encrypt limite le nombre de demandes de duplicata (cad sur le même ndd racine) à 5 par semaine. https://letsencrypt.org/fr/docs/duplicate-certificate-limit/

Là non. Vous devez avoir un certificat valide sur votre ndd dans la section des certificats, et il faut aussi que ce certificat couvre la ou les applications dans les paramètres des certificats. Tout ceci est expliqué dans le tuto.

@Flamby55, une adresse IP ne peut pas avoir de certificat. Il est donc normal que votre navigateur vous indique que la connexion n'est pas sécurisée. Néanmoins, la connexion est bien chiffrée de bout en bout.

@Jeff777 si tu veux, je te donne le mien. Ce problème d'incompatibilité de cette option avec le reverse proxy existe depuis ... tout le temps et @.Shad. n'a fait que reprendre ce que Fenrir avait mentionné dans son tuto. De ce que je comprends, obliger le nas à basculer en https interfère avec les règles de transfert https vers le port correspondant de l'application en http. Par exemple, une entrée https://nas.ndd qui est transférée vers le localhost:5000 (DSM) est contrecarrée par l'obligation de passer en https (donc 5001). Le transfert ne peut pas aboutir. Ceci dit, il est possible que Syno aient revu leur copie et que ce dysfonctionnement ait été corrigé dans les dernières versions de DSM. Je n'ai pas essayé et je n'ai pas l'intention de le faire car je ne vois pas d'intérêt pour mon usage de forcer le https en interne (je n'ai pas de http ouvert vers internet).

@KIKI LE BARBU c'est bon. Vous aurez bien 2 volumes de 7.3To chacun, mais aussi, la perte de toutes les données d'un volume en cas de perte d'un disque et des applications si c'est le volume 1 qui tombe en panne. Même si ça fait partie intégrante d'une gestion normale des données, il faudra particulièrement bien soigner vos sauvegardes périodiques pour faire face à toute perte de données.

Il me semble que votre mémoire physique est un peu juste. A pleine charge elle devrait être à 75% or vous êtes à 100% en permanence ce qui sollicite le swap et occupe pas mal de CPU. Il faudrait à mon avis envisager d'upgrader votre RAM à 16Go, voire 32Go pour alléger la charge de travail. VCi-après un fil de discussion sur les mémoires compatibles https://www.nas-forum.com/forum/topic/13929-mémoire-vive-ram/#comment-75711

Bonjour @Dominique Leroy, soyez le bienvenu sur ce forum.

Déjà commencer par poster dans la bonne rubrique. Votre question n'a aucun rapport avec "Avis et critiques des consommateurs". Je déplace. Merci de faire attention la prochaine fois. Dans votre cas, seul un reset mode 1 vous permettra d'accéder au NAS. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t1

Pour commencer, il faut mettre à jour vos sauvegardes. Faire une sauvegarde de la configuration de DSM (menu Mise à jour et restauration). Activer l'accès SSH et vérifier que le parefeu autorise le port 22 aux IP privées. Si l'accès au NAS est impossible après installation, le SSH permet d'accéder à DSM en mode terminal ce qui peut s'avérer utile pour résoudre un problème. Attention de ne pas ouvrir le port 22 vers l'extérieur ! Si vous changez de box et/ou d'opérateur, il faut impérativement vérifier que la connexion LAN soit en DHCP (menu Réseau, Interface réseau, sélectionner le LAN connecté au réseau, bouton modifier, la configuration automatique DHCP doit être activée). C'est le point le plus important pour être sûr de pouvoir accéder au NAS car si l'IP du LAN n'est pas dans la plage du DHCP du routeur, votre NAS ne sera pas visible sur le réseau. Une fois le NAS installé dans votre nouveau logement, Il faudra bien évidemment attribuer une IP fixe pour le NAS dans le DHCP du routeur. Cette IP devra autant que possible être identique à celle que vous avez actuellement pour que vos différents réglages faisant appel à l'IP du NAS puisse continuer de fonctionner. Sinon, il va falloir corriger vos paramètres. Pour info, votre NAS est compatible DSM7.x

Il faudrait commencer par regarder du côté du moniteur de ressources pour voir quels processus utilisent du CPU.