PiwiLAbruti

Sans WireGuard (qui est une bonne solution), voici une méthodologie pour restreindre l'accès à un opérateur mobile (Bouygues Telecom dans l'exemple ci-dessous) : Relever les adresses IPv4 et IPv6 d'un appareil mobile (Wi-Fi désactivé) depuis une site comme https://ip.lafibre.info, Récupérer les réseaux correspondants depuis un annuaire BGP comme bgp.tools ou bgp.he.net (pour Bouygues Telecom : https://bgp.tools/as/5410#prefixes), Créer une règle d'autorisation dans le pare-feu du NAS pour chaque réseau identifié. Afin mieux identifier ces réseaux, on peut temporairement ouvrir les accès à la France entière et identifier les adresses IP mobiles dans les logs de connexion du NAS. Contrairement à IPv6, il y aura probablement plusieurs réseaux IPv4 à renseigner. On peut encore aller plus loin pour restreindre aux plages réellement utilisées, mais ça ferait plutôt l'objet d'un tutoriel.

Tu peux créer une règle dans le pare-feu par pays pour autoriser toutes les adresses IP Françaises. Les adresses IPv4 et IPv6 de ton mobile y sont incluses. Si tu veux restreindre à ton opérateur uniquement, il faut autoriser uniquement les réseaux IP de ce dernier. Quel est ton opérateur mobile ?

Je suppose que tu as compris que le préfixe IPv6 2a01:e0a:3:a350::/64 de ta Freebox n'est pas autorisé dans le pare-feu du NAS, ce qui explique le message d'avertissement de DSM. Comme tu n'accèdes pas au NAS avec une adresse IP autorisée dans les règles de pare-feu, tu n'auras plus d'accès au NAS si ces règles sont appliquées. Pour les connexions locales au NAS, je déconseille d'utiliser un domaine *.synology.me car tu rends l'accès local à ton NAS dépendant du service DDNS de Synology alors qu'il n'y aucune raison pour que cet accès soit dépendant d'internet. Utilise plutôt l'adresse IP locale du NAS (https://92.168.1.*:35001 en IPv4, ou https://[fe80::*]:35001 en IPv6) qui fonctionnera quelque soit l'état de la connexion internet. Si toutefois tu souhaites continuer d'utiliser le domaine *.synology.me, il faut alors autoriser le préfixe 2a01:e0a:3:a350::/64 dans les règles de pare-feu du NAS.

Merci de ne pas citer le message précédent à chaque fois. Est-ce que le préfixe 2a01:e0a:3:a350::/64 est autorisé dans le pare-feu du NAS ?

Quelle adresse IP de client est indiquée dans Moniteur de ressources > Connexions ?

Quelle adresse est utilisée dans la barre d'adresse du navigateur pour se connecter au NAS et en faire la configuration ?

Avant de changer de disque, il faut impérativement disposer d'une sauvegarde à jour des données importantes du NAS. En cas de problème majeur pendant la reconstruction (défaillance du disque de 1To restant), il sera toujours possible de restaurer les données. Le changement de disque à chaud est possible sur un DS220+. Je recommande cependant de procéder à la désactivation du premier disque avant son retrait du boitier. Une fois le premier disque de 2To inséré à la place du 1To, il faut attendre la réparation du groupe de stockage (opération longue) et ne procéder au changement du deuxième disque que lorsque le groupe de stockage est de nouveau signalé comme "Sain".

D'après certains forums, c'est possible. Quelqu'un a réussi à installer DSM 7 sur un Netgear ReadyNAS RN316 : https://xpenology.com/forum/topic/56934-converting-a-netgear-readynas-to-xpenology/#comment-440076

Je ne l'ai pas constaté, et ce n'est pas mentionné dans l'historique des incidents : https://www.synology.com/en-global/support/synology_service/incident_history

Il faut donc remplacer le disque 4 qui est à l'origine des lenteurs.

C'est le premier point à vérifier car le plus probable vu les symptômes décrits.

Les cas d'usage que j'ai cités sont des exemples qui nécessitent une segmentation, et en aucun cas l'utilisation que j'ai de NAS Synology en entreprise. Synology a tout de même la prétention de vendre du matériel professionnel mais reste complètement sourd aux lacunes de DSM que je leur ai pourtant signalées à maintes reprises. À partir de ce constat le "bashing" est plutôt facile. Le montage de plusieurs VLAN est tout de même possible sur un NAS Synology via des scripts, mais une solution native est vraiment nécessaire. Surtout que le pare-feu du NAS s'y adapterait automatiquement (règles par interface). Après une brève recherche, il s'avère que QNAP supporte jusqu'à 16 VLAN par interface : https://www.qnap.com/en/how-to/faq/article/how-to-set-vlan-id-in-nas-lan-adapter

Sauf que quand je parle de 2x10G, il s'agit d'un bond réparti sur deux switches stackés. C'est un montage très courant en entreprise pour assurer la continuité de service. Concernant la politique de sécurité, iSCSI se déploie sur un réseau isolé (sans passerelle donc), SMB pour du trafic LAN uniquement, Synology Drive accessible depuis Internet (et je vais omettre Hyper Backup). Dans ces conditions, un NAS Synology est complètement à la ramasse.

Pour accéder à un NAS Synology 2x10G via différents protocoles à sécuriser différemment (SMB, iSCSI, Hyper Backup, Synology Drive, …), tu procéderais comment ?

Les VLAN c'est tout de même plutôt réservé aux professionnels ou aux utilisateurs particuliers avertis. J'ai ouvert deux demandes d'améliorations à ce sujet par le passé, à quelques années d'intervalle. Synology n'a jamais rien fait. Si l'utilisation de plusieurs VLAN est vitale pour ton infrastructure, je pense qu'un NAS Synology n'est simplement pas envisageable et qu'il est préférable de voir ce que fait la concurrence.

Alors pourquoi parler de DSM 7.2 ici ? Surtout pour une mise à jour mineure qui corrige une faille Telnet de presque 10 ans…

Le sujet parle de DSM 7.3 🙃

L'année n'a aucune importance puisque ces deux modèles sont toujours supportés par Synology même niveau de version de DSM.

Ces processeurs n'ont pas le même nombre de cores ni la même fréquence : DS918+ : 4C 1,5GHz (turbo 2,3GHz sur 1 core) DS420+ : 2C 2,0GHz (turbo 2,9GHz sur 1 core) Il n'y a aucune vérité absolue sur les performances. Certains programmes/services sont fortement multithreadés (besoin de cores), d'autres ne savent utiliser qu'un seul core (besoin de fréquence). Est-ce que le DS918+ est trop lent pour ton utilisation ?

Tu peux comparer les processeurs de ces NAS pour te faire une idée : DS918+ : Intel Celeron J3455 DS420+ : Intel Celeron J4025 Comparatif : https://www.cpubenchmark.net/compare/2875vs3668/Intel-Celeron-J3455-vs-Intel-Celeron-J4025

Tout est détaillé sur les pages de support de ces deux modèles : https://www.synology.com/fr-fr/support/download/DS1019+?version=7.3#system https://www.synology.com/fr-fr/support/download/DS415+?version=7.1#system

Pourquoi ne pas directement monter un conteneur en 9.6 pour récupérer la base ? https://hub.docker.com/r/postgresqlaas/docker-postgresql-9.6/

As-tu essayé de cliquer sur les sections CPL principale et CPL secondaire dans la liste à droite ? De même, est-ce que l'icône CPL+2 en haut à droite du schéma est cliquable ?

Si tu te poses cette question, c'est que tu n'as trouvé aucune raison suffisante pour le remplacer. De plus, et comme tu l'as très bien détaillé, ce NAS n'est pas un élément critique : il dispose de sauvegardes régulières, et une indisponibilité laisse le temps d'en acquérir un nouveau sans impact majeur sur ton utilisation. Je pousserais ce DS418 jusqu'à ce qu'une bonne raison de le remplacer se présente (panne matérielle, performance ou obsolescence logicielle pénalisante, …).

Toutes les versions de DSM : https://web.archive.org/web/20230510164622/https://archive.synology.com/download/Os/DSM DSM 6.2.3-25426 : https://web.archive.org/web/20230510164608/https://archive.synology.com/download/Os/DSM/6.2.3-25426 DSM_DS212+_25426.pat : https://web.archive.org/web/20230510164608/https://global.synologydownload.com/download/DSM/release/6.2.3/25426/DSM_DS212_25426.pat Le serveur archive.org peut retourner des erreurs HTTP par moment, mais en insistant ça passe.