PiwiLAbruti

Merci @Einsteinium, @bliz avait également déjà confirmé.

On ne s'en sort pas avec les quantités de RAM 😄 (14Go ?)

D'après les commentaires Amazon, certains semblent y être parvenus avec 2x 32Go : Le problème du DS920+ (par rapport au DS918+) est que les 2Go 4Go de RAM d'origine sont soudés à la carte-mère. D'après Synology, il faut de la DDR4 2666MHz non-ECC Unbeffered. Par contre, je ne sais pas si elle doivent être single ou dual ranked.

Donc tu accèdes à ton NAS avec une adresse du type https://sub.domain.tld:5001/ ? As-tu vérifié avec nslookup si la résolution du FQDN fonctionnait ? Un enregistrement de type A ou AAAA fraîchement créé n'est pas toujours immédiatement opérationnel.

Tu l'as déclaré où dans DSM le FQDN ? (je ne l'ai déclaré que dans le proxy inversé et ça fonctionne très bien).

Il n'y a pas de mal à ça 😆

Pour l'enchaînement des versions de DSM, le plus sécurisant est de passer par chaque première et dernière version mineure publiée : 2.2-0965 : https://global.download.synology.com/download/DSM/release/2.2/0965/synology_88f6281_210j_0965.zip 2.3-1139 2.3-1157 3.0-1334 3.0-1354 3.1-1594 3.1-1748 ... Toutes les versions sont visibles ici : https://archive.synology.com/download/Os/DSM

Donc ceci explique pourquoi la connexion en IPv6 au NAS n'est pas possible depuis l'extérieur. Ça dépend de la façon dont tu utilises ton NAS à l'extérieur. Étant également chez Free et n'utilisant que mon téléphone depuis l'extérieur, je n'ai autorisé que les plages IP de l'opérateur : 37.160/12 pour Free mobile en IPv4, 2a01:e00::/26 pour toutes les adresses IPv6 Free. Je n'ai pas activé la règle IPv6 pour le moment car je n'ai pas activé IPv6 sur mon abonnement mobile. Il faudra d'ailleurs que j'identifie plus précisément l'espace IPv6 attribué à Free mobile pour restreindre au mieux la surface d'exposition. On trouve les réseaux attribués ici : https://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt (fr.proxad pour Free) C'est une mauvaise idée si on n'en maîtrise pas les conséquences. l'abscence d'un pare-feu IPv6 paramétrable est l'un des plus grand reproche fait aux box de Free, surtout qu'un tel pare-feu existe depuis longtemps chez certains concurrents (Orange et SFR notamment). Justement c'en est un, mais la seule action possible est d'autoriser ou d'interdire tout le trafic entrant IPv6, c'est qui n'est pas d'une grande utilité quand on héberge des services chez soi. Je ne vais pas faire un exposé sur IPv6 ici. Ce qu'il faut retenir c'est que par défaut un pare-feu IPv6 est présent sur n'importe quel appareil compatible IPv6 (que ce pare-feu soit paramétrable ou non), et qu'il doit bloquer tout le trafic entrant depuis l'espace publique (2000::/3). C'est précisément là que le niveau de confiance tombe à quelque chose proche de zéro chez les plus sceptiques (dont je fais parti). Concernant les appareils sur lesquels j'ai des doutes, j'ai simplement désactivé IPv6 dessus. Après il faut relativiser, les scans de ports tels qu'on les connaît en IPv4 sont inexistants en IPv6 (en tout cas, tcpdump ne m'en a remonté aucun depuis 2 mois sur un NAS exposé). @.Shad. Ton NAS a déjà bloqué des tentatives de connexions sur IPv6 ?

Attention à n'autoriser le port udp/1701 que dans le pare-feu du NAS et de ne pas l'ouvrir sur le routeur.

Je parlais de l'adresse que tu as entrée dans l'application Synology Drive sur Android pour te connecter à ton NAS. Comme tu es chez Free, vérifie que le pare-feu IPv6 est bien désactivé sur la box, et que le pare-feu du NAS laisse bien passer les IPv6 nécessaires.

Je m'étais arrêté à Cloud Station qui n'utilisait que le port tcp/6690, mais Synology Drive utilise en plus les ports de DSM (tcp/5000-5001) : https://kb.synology.com/fr-fr/DSM/tutorial/What_network_ports_are_used_by_Synology_services Quelle adresse utilise sur l'application Synology Drive ? (une adresse de la forme drive.domain.tld:443 en reverse proxy de DSM ?)

Je n'avais pas de problème pour migrer en suivant les instructions de Synology : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_migrate_Synology_Mail_Server_to_MailPlus_Server

Aucune idée, je n'utilise pas Synology Drive. Essaye déjà de voir comment ça se comporte avec un client desktop en local pour analyser le trafic (sur le client).

Alors la question "Et j'attends combien de temps qu'il se passe quelque chose?" ne se pose pas 😉

Cette commande affiche le moindre paquet qui transite par le port 6690. Si ton NAS a plusieurs interfaces réseau, il faut alors la préciser : $ sudo tcpdump -nqi {ovs_}eth<n> 'tcp port 6690' Le préfixe ovs_ doit être utilisé si VMM est installé sur le NAS afin de préciser l'interface virtuelle rattachée à l'interface physique. n est le numéro de l'interface.

Essaye avec tcpdump : $ sudo tcpdump -nq 'tcp port 6690'

@oracle7 Une tâche planifiée au démarrage, et c'est réglé.

Cette mise à jour est importe car la sécurité de DSM est compromise : https://www.synology.com/fr-fr/security/advisory/Synology_SA_22_03 Un correctif arrivera prochainement pour DSM 7.0. @maxou56 Tu peux modifier le lien pour qu'il pointe directement sur le bon onglet ? Il y a juste à rajouter #6_2 à la fin de l'URL : https://www.synology.com/fr-fr/releaseNote/DSM#6_2

Merci pour le retour 👍 N'oublie de mettre la valeur à "no" ou de commenter/supprimer la ligne le jour où tu voudras faire un reset. 😅

@CoolRaoul Je ne parle pas de HTTPS mais des profils enregistrés de connexion dans l'application. Certain ont résolu des problème de connexion similaires en supprimant les profils enregistrés et en les recréant. Maintenant comme je disais, c'est peut-être propre à la version iOS de l'application.

Sur la page de connexion, il y a une roue crantée en bas à gauche (sur la version iOS, je ne sais pas pour Android).

Essaye de désactiver le chiffrement pour tester, et ensuite de supprimer le profil de connexion dans les paramètres. Il me semble avoir déjà vu un problème similaire avec Cloud Station Drive. SyncThing est aussi disponible sans Docker (mais il n'est pas plus simple à utiliser pour autant 😅) : https://synocommunity.com/package/syncthing

Un système de spam n'a pas besoin de s'installer sur le serveur attaqué, c'est un simple programme lancé à distance qui détecte et utilise les serveurs qui sont mal configurés, notamment par l'absence des enregistrements DNS cités précédemment. D'où l'urgence de les mettre en place rapidement (au moins SPF). Pour les explications, il suffit de se référer à Wikipedia : SPF : https://fr.wikipedia.org/wiki/Sender_Policy_Framework DKIM : https://fr.wikipedia.org/wiki/DomainKeys_Identified_Mail DMARC : https://fr.wikipedia.org/wiki/DMARC Tant que ces mécanismes ne seront pas configurés, ton NAS continuera d'envoyer du spam.

Si le NAS n'est dédié qu'à cette fonction (UniFi Controller), quel serait l'intérêt de choisir un NAS ? Est-ce que Ubiquiti fournit des spécifications matérielles selon la charge du contrôleur ?

[Ctrl] + [F5] ?