PiwiLAbruti

Le réseau est un sujet très vaste. Sur quel sujet veux-tu en savoir plus exactement ? L’adressage IP ? Certains protocoles ? Autre chose ? En quoi consisteraient les exercices ? Il y a pléthore de cours et d’exercices en ligne qui seront, de mon point de vue, plus efficaces qu’un livre (OpenClassroom, WayToLearnX, ...) Pour un particulier, je doute que des sujets comme le routage ou les protocoles de niveau 2 (802.3) soient vraiment pertinents. Avant de chercher à en savoir plus sur les réseaux IP, il faut déjà savoir ce qu’est une adresse IP (et son masque). Beaucoup pensent le savoir, mais après s’être un peu renseignés sur le sujet... https://fr.m.wikipedia.org/wiki/Adresse_IP Enfin bref, précise ton besoin et tes objectifs sinon tu vas te noyer avant même d’avoir sauté dans la piscine.

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.

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) 🤔

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.

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.

Petite correction : 😉 Non, il s'agit de réseaux.

Le temps que tu trouves comment faire via SSH, tu auras depuis longtemps rétabli la situation avec un simple reset.

Attention à Ubiquiti, c’est beaucoup moins user-friendly que Synology car ça reste malgré tout du (très bon) matériel professionnel. Avant d’acheter, je te conseille vivement de tester le contrôleur qui permet de gérer la gamme de produits Unifi (Unifi Controller). Ça te donnera déjà un bref aperçu qui t’aidera à faire ton choix (quel qu’il soit). J’ai profité d’une petite entité qu’il a fallu équiper pour tester cette marque avec 3x nanoHD et un contrôleur dans une VM Debian 9 LTS. Ça fonctionne pour l’instant très bien (et déjà deux mises à jour du contrôleur et les AP). Le suivi des mises à jour est exemplaire avec des notes de versions détaillées et une communauté très active.

Le moyen le plus efficace (mais probablement pas le plus simple) est d'utiliser la commande tcpdump via Telnet/SSH : # tcpdump not port '(22 or 23 or 5000 or 5001)' -nq La commande ci-dessus va exclure les ports Telnet, SSH et DSM de la capture et n'afficher que les autres protocoles/services.