.Shad.

@Tex5 Le tutoriel a été annoté mais pas corrigé intégralement. Quand tu ajoutes --set-default-CA tu définis le CA que tu vas utiliser par défaut (Letsencrypt dans ton cas et pas ZeroSSL qui est le CA par défaut d'acme.sh depuis quelques temps). Cette opération ne se fait qu'une fois, par la suite soit tu ne précises rien (plus de --set-default-CA --server Letsencrypt), soit tu enlèves juste --set-default-CA et laisse --server letsencrypt pour être sûr que c'est bien LE qui est utilisé (c'est ce que je fais chez moi). Concernant les fichiers dans /root, assure-toi que le chemin est bien défini, je crois que c'est la destination par défaut si le chemin que tu lui indiques n'est pas trouvé. Logiquement tu n'as pas à modifier le script, juste les variables éventuellement. Si elles ont changé de nom depuis le temps, il suffit de modifier le nom des variables que tu exportes dans le shell.

Généralement ce genre d'erreur est lié à un problème de token, est-ce que par hasard tu n'aurais pas mis une durée d'un an sur celui-ci et que du coup logiquement il n'est plus actif ? A moins de forcer la commande acme, avec le paramètre --force, il n'y a aucune raison que ça renouvelle plus tôt que tous les 60 jours. Car le script vérifie la date d'émission du certificat avant de le renouveler, s'il a moins de 60 jours il s'arrête automatiquement, sauf à le forcer. Voir la doc : https://github.com/acmesh-official/acme.sh/wiki/dnsapi#119-use-infomaniakcom-api

@Tex5 Le problème était dans le tutoriel, mauvaise indentation du paramètre external par rapport au reste (4 indentations dans la partie services entre les paramètres environment, volumes, etc... et les lignes commençant par un tiret, et 3 indentations dans le cas d'external). J'ai corrigé ça, assure-toi que l'indentation est ok de ton côté et ça devrait rouler.

Je suis en congés loin de chez moi, mais je regarderai sûrement dans les semaines qui viennent ou à la rentrée scolaire. Dur de libérer du temps avec les enfants. 😁

Tu as tous les fichiers de configuration pour acme ici par exemple : https://github.com/acmesh-official/acme.sh/tree/master/dnsapi Normalement tout est commenté. C'est la seule partie qui change du tutoriel. Et faut évidemment voir comment accéder à l'API du registrar ou hébergeur DNS concerné.

Ça ce n'est valable que si tu héberges ta zone DNS publique chez toi. Ce que globalement je déconseille si tu n'es pas préparé. Généralement, si tu héberges localement une zone DNS, c'est uniquement pour la résolution locale, quand tu veux éviter de passer par le net pour retourner chez toi. Ce que je disais concernant l'automatisation c'est que par défaut DSM permet de renouveler automatiquement un certificat pour un domaine Synology. Oui, tu peux renouveler automatiquement n'importe quel certificat sur ton NAS, mais ça ne passe pas par DSM. Ligne de commande, Docker, VM, etc... C'est hors du système d'exploitation de ton NAS. Si tu as une zone DNS locale, si la connectivité Internet plante, ton réseau local devrait rester accessible (que la zone soit hébergée sur le routeur ou sur le NAS). Sauf très bonne raison, laisse ta zone DNS publique sur OVH, l'API est bien foutue et prise en charge par acme, certbot, etc... Et l'uptime est excellent.

Et est-ce que tu sais de quelle plage de ports tu disposes ? Et est-ce que le NAT peut fonctionner chez tes parents sur ces ports à disposition ? A vérifier, mais il me semble que oui. Pas besoin de faire du NAT d'IPv6 en effet, tu disposes d'un pare-feu IPv6 configurable, tu peux donc autoriser les communications sur les ports qui t'intéressent pour les périphériques souhaités. Par contre, on voit que ton NAS backup est configuré en auto, or il doit être configuré en "DHCPv6-PD" car ta box te fournit un préfixe v6 en /56. A partir de là, la box prend un /64 parmi ce /56 pour attribuer des IP routables (publiques) à ce réseau. D'ailleurs tu peux voir dans ta liste de périphérique IPv6 que le NAS a une adresse stateless (SLAAC) qui n'est pas dans la plage DHCP (bd65:4772:65c3). Donc première chose, changer le mode d'attribution d'IPv6 du NAS. Ensuite dans le pare-feu de box IPv6, il faut ouvrir le port pour Hyper Backup Vault, le port 6281 en TCP, et s'assurer que tu aies une règle adéquate dans le pare-feu de ton NAS également. Mais il faut également vérifier qu'en IPv6 également tu disposes de tous les ports, donc tu ouvres le port 6281 TCP en question sur le pare-feu du NAS (pas de limitation géographique le temps du test), par exemple via : https://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-port-scanner.php

C'est gentil mais je n'ai pas créé le tutoriel dont tu parles. 😄 De manière générale, un nom de domaine acheté t'apporte plus de liberté au niveau du contrôle de la gestion DNS, et fait que tu dépends d'un registrar autre que Synology concernant l'hébergement de la zone DNS. Mais ça ne t'apporte pas plus d'automatisme, au contraire, car le renouvellement de certificat wildcard est totalement automatisé pour les domaines Synology via DSM. Par contre, dans ton cas, si tu veux utiliser le même domaine sur deux sites différents, tu n'as pas le choix de prendre un nom de domaine personnel, car le DDNS xxx.synology.me que met à disposition Synology est unique et donc lié à une IPv4 (et IPv6). On peut tout à fait faire pointer des sous-domaines vers des IP différentes dans une zone DNS classique : site1.xxx.ovh A IP1 site2.xxx.ovh A IP2

Oui c'est ça.

Salut @Jeff777 J'ai récemment domotisé ma maison via Jeedom. La base de données de Jeedom est hébergée sur mon NAS principal. Vu que le niveau de criticité est élevé (sécurité de l'habitat), je pensais mettre en place une réplication sur mon NAS secondaire, le DS118, qui ne sert habituellement que de support de sauvegarde de mes différents équipements. Comme ça en cas de défaillance du NAS principal, j'aurai simplement à changer l'adresse de l'hôte de la base de données dans Jeedom. Question, est-il possible d'avoir une réplication unilatérale ? je souhaiterais que tous les changements sur le DS918+ soient répercutés sur le DS118, mais interdire l'inverse. Pour autant, la base de données sur le DS118 ne doit pas être en lecture seule, en cas de bascule d'un NAS à l'autre Jeedom doit disposer de tous les droits nécessaires. Si possible sans autre intervention de ma part. Merci !

[troll] Sinon il est toujours temps d'acheter un vrai routeur 😄 [/troll]

Ca fait bien un ou deux ans que ce problème est présent je pense.

A moins de faire un caisson spécifique insonorisé pour ton NAS 4 baies, il sera forcément plus bruyant car deux disques de plus. Tes 20 To sont des RED Plus ou RED Plus Pro ? Les Pro ont une vitesse de rotation plus élevée, ils sont donc naturellement plus bruyants. Par contre je suis étonné, 4 disques de 20 To en miroir ? Donc un RAID 10 si je comprends bien. 40 To utiles pour 80 To de stockage. Ce genre de configuration est réservée aux cas critiques en terme de continuité et de performance, souvent pour des applications professionnelles. Tu sacrifies 20 To supplémentaires par rapport à un RAID-5 (ou SHR Synology) et pour le même stockage utile tu n'as pas le même niveau de continuité qu'avec un RAID-6 (ou SHR-2) qui propose deux disques de réserve.

C'est l'intérêt de ce tutoriel, pouvoir consolider les bases et se faire une piqûre de rappel. 😉 Je vais devoir améliorer 2-3 points où je me rends compte que je suis allé un peu vite. Si tu as des questions n'hésite pas.

C'est étrange, et ensuite le PC se connecte bien en SMBv3 une fois démarré ? Tu peux vérifier ça dans Powershell en l'exécutant en tant qu'administrateur : Get-SmbConnection Il faut regarder la propriété Dialect.

Ton lien ne fonctionne pas chez moi non plus. D'après Google ça a été renommé Sickchill. Et Synocommunity a un paquet à jour nommé Sickchill : https://synocommunity.com/package/sickchill Il existe aussi une image Linuxserver pour ce soft si tes NAS supportent Docker.

https://www.kwartz.com/fr/questions-frequentes/ressources-windows/213-windows-10-smb1 Vérifie quand même, peu probable que le PC se connecte en SMBv1 si pas autorisé dans ses paramètres.

Pour ceux que ça intéresse, la version 1.3.0-0317 permet de partager des fichiers avec un nom de domaine personnalisé (typiquement un proxy inversé par exemple) autre que celui défini dans DSM -> Panneau de configuration -> Accès externe -> Avancé. En effet, à partir du moment où on renseigne domaine et port dans cette fenêtre, c'est le lien qui sera utilisé par toutes les applications DSM lors du partage. https://www.synology.com/fr-fr/releaseNote/SynologyPhotos Pour ajouter ce domaine personnalisé, dans DSM 7 il faut aller dans Panneau de configuration -> Portail de connexion -> Applications -> Synology Photos et mettre le domaine en question dans le champ domaine : A noter que si vous tentez de faire pareil avec les autres applications, ça ne fonctionnera pas, ça continue d'utiliser le domaine renseigné dans Accès externe.

Ce que ne fait pas Adguard, c'est être SOA (start of authority) pour un domaine, et ça n'a son importance que si tu héberges ta zone DNS publique (comme le fait ton hébergeur DNS, qui est souvent mais pas obligatoirement le registrar). Car Adguard se contente simplement de réécrire des IP pour des domaines, ou des domaines vers d'autres domaines, comme tu pourrais le faire sur Windows ou Linux en ajoutant des entrées manuellement dans le fichier hosts. La deuxième chose que fait DNS Server, et que je pense qu'Adguard n'intègre pas (si c'est comme Pihole), c'est le système des vues. En gros si tu lui dis que coucou.tuto pointe vers 192.168.0.252, ce sera le cas pour tout le monde, tu ne peux pas différentier la destination en fonction de l'IP source (par exemple que les clients VPN avec des IP en 10 qqch voient coucou.tuto pointer vers une IP différente). Si tu n'es dans aucun de ces cas-là, DNS Server selon moi ne t'apporte rien de plus (à moins que tu ne fasses de la réplication maître-esclave sur un autre NAS, mais c'est faisable avec Adguard-sync) par rapport à ce que peut t'apporter Adguard. Et dans ce cas-là, pas besoin de passer par la case macvlan comme l'a justement fait remarquer @PiwiLAbruti, car tu peux te mettre en bridge ou host car si DNS Server n'est pas actif, le port 53 est libre. Concernant DoH, le trafic sortant est noyé dans le 443 donc tu ne devrais rencontrer aucun problème. C'est simple à mettre en oeuvre sur un Raspberry ou dans une VM, sur un NAS Synology c'est souvent plus complexe dès lors qu'on veut éviter de toucher au système, car les ports standards sont la plupart du temps déjà occupés. Voir ma question au-dessus concernant l'intérêt de DNS Server dans ton cas. C'est le principe de tout bloqueur de pub local, il faut que le serveur DHCP attribue comme DNS primaire à ses clients l'IP d'Adguard, celle du NAS si le conteneur est en bridge ou en host, celle du conteneur si tu utilises le driver macvlan.

@CyberFr Pourquoi ne pas mettre en place une solution type Adguard (ou équivalent) qui permet d'utiliser DoH pour tout ton réseau, sans passer par ton navigateur ?

Question bête, mais si tu le désactives tu arrives à te connecter ? Histoire de s'assurer que le problème prend bien sa source avec l'activation de DoH.

Bienvenue parmi nous !

Tu as mis quoi au début de ton script ?

S'il a mémorisé les credentials ça ne le demande plus, mais dans l'absolu oui, s'il ne coche pas la case ça le demandera à chaque fois, ce qui n'est visiblement pas le cas dans lequel il se trouve.

Tu peux demander à la première connexion avec un utilisateur de ne pas mémoriser normalement (sur Windows du moins).