PiwiLAbruti

On ne parlait pas de la même chose. Effectivement, ça peut être intéressant pour vérifier que la configuration réseau est Ok dans le sens sortant. Par contre, si tu fais [Suivant] et tu verras que ni la Freebox ni la Livebox ne sont listées.

Les logs montrent que 'utilisateur Somer se connecte depuis l'adresse IP 95.70.145.155 avec succès à VPN Server. Vérifie que les clients VPN que tu utilises sont bien déconnectés. Si l'adresse IP t'es inconnue, modifie le mot de passe du compte Somer car il serait alors compromis.

@morgyann La Freebox n'est pas compatible avec cette fonctionnalité, la Livebox non plus d'ailleurs. De toute façon, le problème ne vient pas de là. On a quelque chose qui fonctionnait bien avec une Livebox et qui pédale dans la purée avec une Freebox. Derrière une Freebox, je n'ai jamais constaté de débit élevé en Torrent sur une source unique. Je ferai un test en local entre le DS213j et un PC pour identifier ce qui réduirait le débit.

J'ai autre chose à faire que d'analyser du trafic légitime sur ton réseau local. Et apparemment tu as les compétences nécessaires pour faire cette analyse par tes propres moyens, donc fais nous un rapport détaillé du trafic illégitime provenant d'adresses de ton réseau local.

Il n'y a pas de règle absolue, ça dépend de l'aisance de la personne à utiliser les outils que tu as cités.

Pour rappel, voici un extrait des règles du forum : https://www.nas-forum.com/forum/guidelines/

J'aime bien l'efficacité 😄 Tu pourrais monter un dossier partagé du DS418 sur le DS218+, mais ce stockage ne sera pas considéré comme un volume interne. Donc les possibilités s'en trouveraient réduites. Dans l'idéal, il faudrait un client iSCSI pour monter un volume entier mais Synology n'a jamais proposé cette fonctionnalité.

Non, ce n'est pas possible.

Le paquet SynoCLi File Tools contient la très utile commande rhash permettant notamment de créer des liens magnet et/ou des fichiers Torrent à partir de fichiers locaux. Je n'ai pas utilisé de tracker, mais juste enrichi le fichier Torrent avec une section nodes pour indiquer le pair (peer) auquel se connecter. Jai donc testé avec un fichier de 465Mo partagé avec Transmission (DS213j) et téléchargé avec Download Station (DS718+). Le débit plafonne à ~3,2Mo/s (~25Mbit/s). Chaque NAS est derrière une fibre Free. Le débit est identique en désactivant le chiffrement.

Donc si on résume : les ports 16881 en TCP et UDP (c'est important) sont autorisés dans le pare-feu du NAS, ces mêmes ports et protocoles sont ouverts sur la box, et le NAS en est la destination, le panneau de configuration du NAS indique bien que la vitesse négociée par l'interface ethernet LAN est de 1Gbps (à confirmer), le NAS est connecté au port 1GbE de la Freebox Pop (le 2,5GbE pouvant poser problème), Malgré ça, les débits sont réduits sur les tâches Torrent de Transmission alors que ce même protocole (Torrent) sur ce même NAS (DS216j) atteignait des débits bien supérieurs via une Livebox. Je vais faire le test avec un DS213j, par curiosité. Tu utilises quel logiciel pour créer les fichiers Torrent ?

Dois-je comprendre que si le NAS tombe en panne, il n'y a actuellement aucune sauvegarde pour restaurer les données perdues ? Si les données du NAS sont importantes, il va falloir songer à y remédier. Cette page répondra à cette question : https://www.synology.com/en-us/products/status?tab=software DSM 5 est obsolète. DSM 6 le sera dans 1 an, le 1er octobre 2024.

Je me permets de rajouter quelques questions auxquelles je n'ai pas trouvé la réponse dans les précédents messages : Quel est le modèle de ton NAS ? Quelle est la vitesse de connexion négociée avec la box ? (voir l'onglet Network Interface de la précédente capture d'écran)

Attends les interventions d'autres membres du forum avant de te lancer, ça te laissera le choix entre plusieurs possibilités (réinitialisation en mode 2 ?). -------- De mon point de vue, il y a trop de versions d'écart entre la 4.3 et la 7.1 pour envisager une migration. Cela s'explique notamment par une différence au niveau de la taille de la partition système. Il faut aussi faire l'inventaire des paquets utilisés actuellement, car certains n'existent plus (ou ont été remplacés) dans les version ultérieures. Pour installer la version la plus récente de DSM, je te conseillerais les étapes suivantes : Sauvegarder les données du NAS sur un support externe (ça doit déjà être le cas), Réinitialiser le NAS, Installer directement la version 7.1.1 (puis l'update 6), Restaurer les données. -------- Si tu souhaites installer les versions telles qu'indiquées par Synology, tu peux récupérer les versions manquantes sur archive.org. J'ai aussi un DS213j depuis mars 2013 (encore merci Derren pour le cadeau 😉), je l'avais réinitialisé lors du passage à DSM 7 pour les raisons évoquées plus haut.

L'update 1 a été intégrée à la version 7.2.1-69057 de base aujourd'hui même :

Aucune idée. Tu peux regarder dans les autres fichiers de configuration présents aux mêmes emplacements que ceux cités précédemment.

Ouais en fin là, sans plus analyser l'origine, ça n'a aucun sens. L'un des cas d'utilisation du réseau 0/8 est DHCP où le client utilise une adresse de ce réseau comme source (par ce qu'il en faut bien une) pour broadcaster sa demande d'adressage. Si tu utilises DHCP pour adresser une partie des machines de ton réseau local, les 6075 drops proviennent des demandes DHCP des différents appareils de ton réseau local. Je ne vais pas m'étendre sur le reste des blocages dont les origines sont tout aussi légitimes que celle expliquée ci-dessus. Si les origines ne le sont pas, le réseau 0/8 n'étant pas routable, le réseau local serait alors complètement compromis. L'analyse est un des gros blocs de la SSI sur la sécurisation des réseaux. C'est grâce à ça qu'on dimensionne des moyens de sécurité pertinents à mettre en face. Sans ça, on se retrouve à mettre de la sécurité à outrance là où ce n'est pas utile et à titrer des conclusions farfelues.

N'ayant jamais configuré de client VPN (type NordVPN, …) sur le NAS, la section VPN du pare-feu est restée telle quelle ("Autoriser l'accès" par défaut). Si on passe en "Refuser accès", les clients VPN de VPN Server n'ont plus accès aux ressources locales. Quand on autorise l'accès aux ports locaux dans cette section, ça l'autorise pour tout le réseau local. Par exemple, le port tcp/80 permet aux clients VPN d'accéder aussi bien à WebStation qu'aux autres serveurs web du réseau local. C'est là qu'on voit les limites du pare-feu du NAS (absence de destination dans les règles). J'ai vaguement fouillé la doc de Synology pour trouver des explications à ce comportement étrange (et apparemment global quelque soit le type de VPN client/serveur, sans distinction d'interface), et je n'ai rien trouvé. Dans tous les cas, restreindre cette section dans le cadre de l'utilisation de VPN Server uniquement n'apporte pas rien de plus à la sécurité étant donné que les adresses IP utilisables sont définies dans VPN Server et que leur obtention est soumise à authentification. Ce n'est pas du tout applicable à la sécurité d'un NAS. La source que tu cites précise d'ailleurs que c'est à appliquer sur l'interface publique de routeur : C'est pour éviter le spoofing sur une interface publique de type CG-NAT.

Consommer des ressource ne veut pas dire les saturer. Dans le cas présent c'est de la consommation inutile vu les autres politiques de sécurité appliquées.

Il me semble que la section VPN du pare-feu concerne les connexions VPN clientes crées sur le NAS (NordVPN, ...). Elle n'aurait donc rien à voir avec VPN Server.

Les listes d'adresses IP suspectes sont excessivement longues et impliquent que ton NAS va systématiquement vérifier chaque adresse IP source avec toutes celles renseignées, ce qui demande des ressources. En plus, la fréquence à laquelle peuvent bouger ces listes font qu'elles sont inexploitables. Le blocage IP automatique du NAS est suffisant pour bloquer les tentatives d'authentification échouées à condition de bien le paramétrer.

@alan.dub Oui, c'est ce que je préconise car ces ports (465, 587, 993, et 995) ne sont utilisés qu'entre le client et le serveur (MUA). Le port tcp/25 est utilisé par les serveurs SMTP pour communiquer entre eux (MTA). Tu as la source de cette information ? Le port tcp/587 utilise TLS par défaut, c'est moins sécurisé que SSL ? C'est exactement ce qu'il ne faut pas faire car c'est totalement contre-productif.

D'après les fichiers de configuration nginx (/var/packages/WebStation/target/misc/syslog.conf) et Apache (/var/packages/WebStation/target/misc/apache24_service_template.mustache), les logs se trouvent dans /var/packages/WebStation/var/log.

Comme le dit le message, ton NAS a subit une coupure électrique et a redémarré automatiquement lorsque le courant est revenu.

N'utilisant plus QuickConnect depuis un paquet d'années, je ne saurai pas dire si c'est plus fiable aujourd'hui.

En espérant que la disponibilité du service QuickConnect se soit améliorée.