PiwiLAbruti

J’utilise du Stormshield (fusion Netasq/Arkoon) depuis quelques années en milieu professionnel. Ça devrait couvrir tes besoins. Je te laisse découvrir les produits : https://www.stormshield.com/products-services/products/network-security/

Essaye spksrc, l’outil de cross-compilation de SynoCommunity. https://github.com/SynoCommunity/spksrc

La validation par DNS a l'avantage de ne pas avoir besoin d'ouvrir de port pour créer et renouveler les certificats. Il y a des scripts qui vont jusqu'à automatiser l'installation du certificat dans DSM, mais ça ne me semble pas être une solution pérenne (surtout avec DSM 7). Le mieux est de faire ce que tu as fait : générer le certificat et l'ajouter manuellement. Je n'ai pas utilisé l'API OVH pour le renouvellement automatique car j'utilise mes propres serveurs DNS.

As-tu essayé d'utiliser un certificat wildcard pour domain.tld et *.domain.tld ? Ainsi ton domaine et tous ses sous-domaines directs sont couverts par le certificat. J'en ai mis en place récemment sur mes NAS, ça fonctionne très bien.

Tu peux utiliser tcpdump directement en SSH sur le NAS. # tcpdump -nq "not tcp port 22" Sinon, si ce n’est pas assez user-friendly, il faut suggérer l'idée à Synology (comme je l’ai déjà dit).

Si tu as de la chance, ce sera peut-être disponible avec DSM 7.

Même avec cette correction, ce n’est toujours pas bon : m : milli M : mega Promis, je m'arrête là 😇

Tu vas réussir à l’embrouiller encore plus @niklos0 car tu confonds toi-même les bits (b) et les bytes (B) 🤔

En iSCSI, le cluster est obligatoire pour pouvoir écrire depuis différents hôtes en même temps. S’il n’y a pas de cluster, il y a un fort risque d’incoherence des données. Si les hôtes n’en sont jamais utilisés simultanément, ça peut être jouable mais ça reste risqué. Si un seul des hôtes est utilisé en écriture (masking), pas de problème.

Quel est le modèle de ton NAS ? Quel est le débit de ta connexion internet ? Quel gain y aurait-il à asset par le NAS pour accéder à internet ? Le NAS n’est pas prévu pour ça. Le paquet Proxy Server permet de relayer les communications HTTP uniquement mais n’est plus maintenu par Synology.

Il s'agit de connexions sortantes et non entrantes. Pour voir les programmes qui utilisent ces connexions, utilise la commande netstat -netpal.

Si tu as un nom de domaine chez un registrar qui propose du DDNS (comme OVH), tu peux t’en sortir très simplement.

Et il y a un client iOS contrairement à Syncthing. Syncthing reste excellent (open source, forte communauté), surtout avec son API gratuite (vs. Resilio Connect) qui permet de gérer une multitude de noeuds de manière centralisée. Malheureusement, ce n'est pas encore assez mature pour être adopté par n'importe qui.

Resilio Sync : https://www.resilio.com/individuals/ Synology devrait d’ailleurs s’en inspirer.

Après avoir lu le problème je ne voyais pas ce que ça aurait pu être d’autre. N'hésite pas à abuser de cette commande (nslookup) pour vérifier les enregistrements DNS que tu crées, aussi bien pour vérifier l’enregistrement en lui-même que sa propagation.

Utilise la commande nslookup pour vérifier que les résolutions se font bien vers la bonne adresse IP.

La solution de @maxou56 est effectivement la plus simple. Concernant l’autre solution, il faut également modifier les valeurs dans /etc.defaults/synoinfo.conf pour que la modification persiste après une mise à jour de DSM.

Le serveur ne dispose d’aucun codec. Il ne fait que servir le contenu au client qui va lui-même décoder la vidéo. Essaye d’attribuer un profil au client détecté dans le NAS.

Il n’y a rien de ridicule à utiliser un NAS pour ce qu’on en a besoin. C’est toujours mieux que d’autres qui tentent désespérément de faire marcher un truc qui ne leur sert à rien sur leur NAS.

Si tu as besoin d’une granularité au niveau de chaque partage, ce n’est pas possible (à moins que j’aie loupé des ACLs par IP au niveau des partages). Par contre tu peux interdire l’accès aux partages au niveau service dans le pare-feu du NAS.

Pour compléter la réponse de @firlin, il faut créer un compte Synology dans lequel il faut ajouter le NAS concerné grâce à son n° de série et ouvrir un ticket de support.

Aucun client iSCSI n'est inclus dans DSM.

Par exemple, stopper les mises à jour peut te permettre de faire des tests sur ton DNS principal sans impacter les clients qui utilisent les DNS esclaves. C’est très pratique et pour passer en production il suffit de rétablir les mises à jour vers les DNS esclaves. Il y a probablement d’autres cas d’utilisation.

Les explications de l'interface me paraissent pourtant suffisamment explicites. Je ne peux que paraphraser ce qui est déjà expliqué : Le transfert de zone sert à définir quels clients peuvent demander le contenu intégral de la zone principale (ou master) pour en faire une copie dans une zone esclave (ou slave). La mise à jour de zone sert à définir les zones esclaves qui peuvent se mettre à jour depuis la zone principale. Sans ce réglage, la zone esclave ne peut pas demander à se mettre à jour avec les modifications faites à la zone principale. Un client est un serveur DNS qui va communiquer avec le serveur DNS principal. Une zone esclave (ou slave) est une copie de la zone master du serveur DNS principal. Elle est créée sur le client. C'est la même chose.

Si l’option 4 (Limiter la mise à jour de zones) n’est pas cochée, il n’y a aucune restriction IP pour les mises à jour des clients.