Mic13710

Et voilà, ça commence ..... Allez voir ce sujet : Vous y trouverez un lien que j'ai donné pour retrouver les anciennes versions. Et par la même occasion je déplace le sujet qui n'a pas sa place dans les logiciels compatibles.

J'avoue ne pas comprendre l'ouverture du port 445. Si c'est pour des échanges entre tes NAS à travers le VPN, alors la première règle suffit.

J'avais bien vu qu'il était sur le paramétrage du LAN1 qui propose cette option par défaut. Néanmoins, deux précautions valent mieux qu'une, et en la mettant systématiquement, ça évite de l'oublier 😉. Mais tu as raison, elle n'est pas indispensable dans le cas présent. @StéphanH pour continuer avec les étrangetés, la dernière règle ouvre tout grand les vannes pour tous les pays de ta liste. Là je pense que tu pourrais être plus restrictif en autorisant l'accès seulement à certains ports.

@StéphanH ton parefeu est pour le moins étrange. Il me semblait que tu avait un VPN entre tes NAS. Or je ne vois pas de règle autorisant les IP en 10.x.x.x C'est quoi ce port 445 ? Ensuite, la règle 445 qui refuse tout ne sert à rien puisque tu filtres juste avant toutes les adresses qui viennent de France. Avec cette règle, les autres provenances sont implicitement rejetées. Il manque la règle de blocage finale qui refuse tous les ports de toutes les provenances

Et bien si. La panoplie Drive ne fonctionne qu'à travers ce port. Le seul moyen pour ne pas l'ouvrir vers l'extérieur serait d'avoir un VPN bi-directionnel qui donne accès aux deux réseaux privés, un serveur DNS local sur chaque NAS pour résoudre les ndd, et bien entendu, l'accès autorisé au port 6690 aux adresses privées dans le parefeu.

C'est loin d'être mon cas. J'optimise au mieux mon stockage sur mes 4To 😉 Je n'ai pas essayé de télécharger un pat à partir du site, aussi je ne peux pas dire quel est son débit. Ca fait quelques nombreuses années qu'il existe et il m'a parfois permis de retrouver de vieux sites et quelques fichiers disparus des radars. On peut espérer que les fichiers Syno ne disparaissent pas de si tôt. Et même si c'est lent, les fichiers pat sont là et en général on n'en télécharge qu'un seul pour ses besoins. Aussi le temps n'a guère d'importance.

@.Shad. pourquoi se casser la tête ? Le lien que j'ai donné n'est il pas suffisant ? 😉

C'est que les hackers en herbe ne se sont pas encore intéressés à ton 218. Perso, je n'ai pas de tentatives suspectes sur les comptes admin de tous les NAS dont je m'occupe, ce qui ne présage en rien que ça ne puisse pas arriver un jour. Et il n'y aurait rien d'anormal puisque ces NAS sont ouverts vers l'extérieur. Mais je suis serein : le compte admin est désactivé et le parefeu fait son boulot en bloquant le malotru qui se présente sans y être invité. Après, on n'est pas à l'abri d'une faille de DSM que certains pourraient exploiter.

Peut-être là : https://web.archive.org/web/20230000000000*/https://archive.synology.com/download

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.

A voir si cela peut vous aider ; https://kb.synology.com/fr-fr/DSM/tutorial/Unable_to_Locate_NAS

Faire un reset mode 1 : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS#x_anchor_id5

Aucun. Les disques n'apprécient pas d'être arrétés redémarrés. Il est préférable de les laisser tourner 24/7.

Apparemment non car si c'était le cas, le disque ne serait pas marqué "Désactivé" mais comme "initialisé" ou "non initialisé". S'il est marqué Désactivé, il ne peut pas être intégré au groupe. Votre disque n'est pas vieux (1120 heures), mais aussi je vois que les items 3, 4, 12, 192 et 193 sont à des niveaux élevés, ce qui indique clairement des arrêts et démarrages fréquents. Vous avez probablement activé la mise en veille des disques et du NAS. Je vous conseille de les désactiver.

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.

@Pout Comment peut-on poster un sujet dans la section seagate qui n'a strictement aucun rapport avec la question posée ? Je déplace. On ne peut pas dissocier les tâches sur un même compte d'un même client. On ne peut pas non plus spécifier différents nombres de versions. Le nombre de versions s'applique à l'ensemble.

Ces 2 VPN sont dans la même plage ? Il faudrait en changer une. Il semblerait que ce soit un problème de serveur DNS. Lesquels avez-vous indiqués ? Est-ce que vous arrivez à pinger l'IP 8.8.8.8 ? Que donne un nslookup 8.8.8.8 ?

@Pommefrais3 l'Ip dans l'account.conf n'est pas correcte. Elle devrait être celle de docker 172.17.0.1. Je suppose que le port 5050 est le http de DSM. Sinon il faut le changer. Supprimer le Saved_Syno_Certificate (il ne fallait pas copier exactement ce qui est écrit dans le tuto mais mettre le nom qui est donné au certificat dans DSM). De toute façon, il fait doublon avec celui en base64 qui est dans le ndd.conf

Je n'ai pas dit que ça règlerait quoi que ce soit. C'est tout bonnement une question de sécurité. Vous n'avez pas répondu à cette question : En migrant les disques ? Si c'est le cas, vous auriez du nous demander, on vous l'aurait fortement déconseillé car votre 923 fonctionne maintenant en mode dégradé, tout du moins, vous ne pouvez pas pleinement l'exploiter (taille maxi d'un volume, pas de btrfs ni snapshot ni virtualisation, des applications inaccessibles). De plus, cette migration peut très bien avoir cassé des mécanismes. Je ne saurais trop vous conseiller de mettre à jour vos sauvegardes, de casser le groupe actuel, de recommencer une installation à partir de zéro et de restaurer vos sauvegardes Un peu de lecture : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_migrate_between_Synology_NAS_DSM_6_0_HDD Si c'est vers l'IP du NAS, ce n'est pas une bonne idée : tous les ports ouverts dans le parefeu du NAS sont accessibles de l'extérieur.

Et si vous lisiez ce que je vous ai écrit ? Il faudrait aussi commencer par faire ce que dit le message de la vue 2, à savoir : Désactiver le disque (bouton action). Attention de bien choisir le disque en panne. Si vous vous trompez, vous perdrez toutes vos données. Vous sortez le disque et le réinsérez à chaud (votre NAS le permet). Vous réparez le groupe. Si le disque est encore bon, le RAID devrait se reconstruire.

Je parlais du parefeu du NAS...

Déjà, vous pouvez supprimer la redirection de ces deux ports, surtout le 5000. Le 5001 n'a pas d'utilité dans la mesure où vous avez une règle de proxy qui fait le taf (la première de votre capture ci-dessus) Dans votre proxy inversé, inutile de mettre des ports https pour la destination. Utilisez les ports http correspondants aux services, par exemple 5000 au lieu de 5001. A moins que vous n'ayez aucune confiance dans les utilisateurs de votre propre réseau, il n'est pas nécessaire de chiffrer les transmissions internes. Avez-vous activé la redirection automatique des connexions http vers https dans l'onglet DSM du portail des connexions ? Si oui, il faut le désactiver car cette option casse le mécanisme du reverse proxy.

C'est probablement un blocage au niveau du parefeu du port 6690 vers l'IP du NAS. Essayez en désactivant le parefeu.

Est-ce que SDC se connecte bien en local avec l'IP locale ?

Depuis le gestionnaire de stockage, HDD, Disque 1, bouton infos sur la santé, onglet SMART, bouton Détails en bas de page. Si vous n'avez pas fait de test étendu : Test étendu, bouton démarrer.