Classement

1. Préambule Pi-Hole est un logiciel libre permettant le blocage de publicités sur les périphériques qui l'utilisent en tant que serveur DNS. Il sert aussi à contrôler les données de télémétrie que vos appareils envoient, parfois (souvent ? ) de manière non-désirée. Vu que le blocage s'effectue au niveau de la résolution DNS, il a l'avantage de pouvoir s'appliquer à tous les types de périphériques, contrairement aux bloqueurs de navigateurs qui se limitent souvent aux ordinateurs. Le tutoriel sera découpé de la sorte : - STANDARD - Utilisation et déploiement de Pi-Hole via Docker - AVANCÉ - Ses différentes utilisations en tant que serveur DNS local La personnalisation du blocage suivant les périphériques Quelques commandes utiles 2. Prérequis Difficulté : facile-moyenne Vous devez disposer d'un NAS compatible Docker, vous pouvez en retrouver la liste mise à jour à cette adresse : https://www.synology.com/fr-fr/dsm/packages/Docker Au niveau des connaissances : Avoir une idée de ce qu'est Docker, voir tutoriel introductif. Savoir se connecter via SSH avec un utilisateur ayant des privilèges d'administrateur ou root directement, voir tutoriel. OPTIONNEL : je conseille d'installer le paquet SynoCLI File Tools de Synocommunity disponible dans le centre de paquets. Pour ajouter le dépôt Synocommunity au centre de paquets, se référer à ce tutoriel : https://sys-advisor.com/2017/11/05/tuto-synology-comment-ajouter-le-depot-synocomunity/. Après cela, la commande nano, certes moins complète que vi, mais beaucoup plus accessible pour les non-initiés, permettra d'éditer facilement les fichiers en console. 3. Méthode d'installation Il existe plusieurs méthodes pour installer Pi-Hole, préférentiellement je conseille : l'utilisation d'un matériel dédié type Raspberry Pi quand on en a un sous la main et sur lequel il est facile de l'installer nativement, la procédure est très simplement décrite ici une machine virtuelle (avec le paquet Virtual Machine Manager, les prérequis de compatibilité étant les mêmes que pour Docker), avec une installation minimale de Debian avec 512Mo de mémoire vive et un cœur est amplement suffisante un conteneur Docker. Il faut savoir que l'utilisation via Docker demande certains ajustements, et ce pour plusieurs raisons : Pi-Hole utilise les ports 80 et 443, qui sont utilisés par DSM pour Webstation et Nginx (notamment le proxy inversé). Si le conteneur est en mode bridge, les requêtes DNS passant alors par l'hôte (le NAS) avant d'arriver au conteneur, vous verrez l'ensemble des requêtes provenant de l'IP passerelle du NAS dans le réseau bridge par défaut, donc 172.17.0.1. Ce qui posera très vite problème si on souhaite différencier le comportement de blocage pour sa tablette, pour sa TV, etc... (voir à la fin du tutoriel) On privilégiera donc l'utilisation d'un réseau macvlan, celui-ci a entre autres l'avantage de pouvoir donner une IP du réseau local à votre conteneur, par exemple 192.168.100.161, il est donc joignable par les périphériques de votre réseau comme n'importe quelle autre machine. Il y a cependant un écueil à l'utilisation d'un réseau macvlan : tous les conteneurs qui en font partie sont incapables de communiquer avec leur hôte par leur IP physique. Concrètement mon NAS sera incapable de joindre Pi-Hole, donc sa résolution DNS sera non fonctionnelle. Pour pallier ce problème, on va créer une interface virtuelle sur le NAS. En gros si la porte est fermée, on passe par la fenêtre. 🙂 C'est une manipulation très simple, qui ne survit toutefois pas à un redémarrage du NAS, on exécutera donc un script au démarrage pour recréer automatiquement cette interface. L'ensemble de cette procédure est décrite dans le tutoriel introductif, et est, par commodité, reprise dans la partie suivante. 4. Hypothèses Pour faciliter la lecture du tutoriel, on définira un certain nombre d'IP et de notations, vous devez évidemment adapter ces valeurs à votre propre installation, notamment les sous-réseaux. Les IP : de l'interface physique du NAS : 192.168.100.100 de l'interface virtuelle du NAS : 192.168.100.200 du conteneur pi-hole : 192.168.100.161 de la passerelle du réseau (votre box ou votre routeur) : 192.168.100.1 de votre serveur DNS local (si vous n'en avez pas mis en place, c'est l'IP de votre passerelle) : 192.168.100.120 Les sous-réseaux : de votre réseau local : 192.168.100.0/24 (correspond à 192.168.100.0/255.255.255.0). du réseau macvlan : 192.168.100.160/28 (correspond à une plage utilisable de 14 IP allant de 192.168.100.161 à 192.168.100.174). Voir ce site qui permet de calculer les masques. Les notations : macvlan-network : c'est le nom du réseau docker macvlan. mac0 : c'est le nom de l'interface virtuelle du NAS. ovs_eth0 : le nom de l'interface qui a pour IP l'IP physique de votre NAS, 192.168.100.100 dans notre exemple. Pour trouver le nom de l'interface en SSH : ifconfig | grep -B 1 192.168.100.100 C'est le nom qui apparaît à gauche de l'écran sur la première ligne : REMARQUE : ovs s'ajoute automatiquement au nom de l'interface lorsqu'on a activé Open vSwitch sur son NAS (automatique lors de l'installation de Virtual Machine Manager) - STANDARD - 5. Création du réseau et de l'interface virtuelle 5-A. Création du réseau macvlan On commence par se connecter via SSH avec un utilisateur admin ou root sur le NAS pour créer notre réseau macvlan. On va se placer dans le dossier partagé docker : cd /volume1/docker/ On y crée un dossier "networks" et y commencer l'édition du script : mkdir networks && cd $_ nano macvlan-network.sh S'ouvre une fenêtre dans laquelle on va pouvoir rédiger notre script, en voici un canevas : docker network create -d macvlan \ --subnet=192.168.100.0/24 \ --ip-range=192.168.100.160/28 \ --gateway=192.168.100.1 \ -o parent=ovs_eth0 \ macvlan-network Notes : subnet : correspond à votre sous-réseau local. ip-range : correspond à la portion de ce sous-réseau qu'on se réserve pour le réseau macvlan, les 14 adresses IP définies dans les hypothèses. Ces 14 IP permettront d'accueillir d'autres conteneurs éventuels. Par conséquent, la plage du serveur DHCP et du réseau macvlan ne doivent absolument pas se chevaucher ! gateway : c'est notre passerelle. parent : l'interface physique à laquelle on rattache notre réseau. _________________________ Pour sauvegarder les modifications effectuées, on fait CTRL+O, on valide en appuyant sur Entrée puis CTRL+X pour sortir de l'éditeur et revenir sur le prompt. On va maintenant régler les permissions : chmod 740 macvlan-network.sh Le script est prêt, on peut l'exécuter : bash macvlan-network.sh Si tout va bien, on obtient une suite de caractères, cela signifie que le réseau est créé. On peut vérifier en tapant : docker network ls Et vérifier qu'il apparaît bien dans la liste. En cas d'erreur dans la transcription, il suffit de supprimer le réseau malformé pour recommencer : docker network rm macvlan-network 5-B. Création de l'interface virtuelle On va créer un second script dans le dossier courant : nano mac0-interface.sh Le contenu du script : ip link add mac0 link ovs_eth0 type macvlan mode bridge ip addr add 192.168.100.200/32 dev mac0 ip link set dev mac0 address 5E:11:4F:AF:D6:D2 ip link set mac0 up ip route add 192.168.100.160/28 dev mac0 Notes : Concernant l'adresse MAC 5E:11:4F:AF:D6:D2 : c'est une adresse que j'ai choisie, sous les conditions suivantes : - Elle n'existe pas déjà sur mon hôte et sur mon réseau. - Elle respecte la base hexadécimale, les notations allant de 0 à F. - Le premier nombre doit être pair, ici 5E = 94 en base 10, c'est donc OK (vous pouvez utiliser ce convertisseur en ligne, ou faire vos divisions euclidiennes 😄). S'il est impair, vous aurez un message : RTNETLINK answers: Cannot assign requested address Merci à @bruno78 pour la précision. _________________________ On valide et on sort du fichier. On accorde les permissions : chmod 740 mac0-interface.sh On exécute le script : bash mac0-interface.sh Sauf erreur, rien n'indiquera que le script a bien fonctionné, on vérifie en tapant : ifconfig | grep -A 9 mac0 Ce qui doit donner un résultat du type : Un autre moyen de vérifier que ça a marché est de lancer Synology Assistant, l'interface virtuelle devrait dorénavant apparaître en plus de l'interface physique du NAS. 5-C. Création de la tâche de rétablissement de l'interface virtuelle au redémarrage Comme dit plus avant, cette interface ne persiste pas au redémarrage du NAS, on va pour cela définir une tâche planifiée, il faut aller dans DSM -> Panneau de configuration -> Planificateur de tâches -> Créer -> Tâche déclenchée : Puis on valide. REMARQUE : Lorsqu'on stoppe docker, ou qu'on le met à jour, l'interface disparaît également. La tâche n'étant lancée qu'au démarrage, vous devrez réexécuter la tâche manuellement pour rétablir l'interface. 6. Création des volumes On va créer un dossier pour le conteneur et s'y placer, on va également créer deux dossiers pour la persistance des données de configuration de Pi-Hole : mkdir -p /volume1/docker/pi-hole && cd $_ mkdir etc-pihole etc-dnsmasq.d Ainsi, même si le conteneur est supprimé, les données seront conservées. 7. Création d'utilisateurs et groupes dédiés et octroi de propriété Pi-Hole permet depuis quelques versions d'exécuter le conteneur par le biais d'un utilisateur non privilégié. Autrefois, c'était root qui exécutait l'application, et root dans le conteneur correspondait à root sur le NAS, ce qui en cas de faille au niveau de l'image Docker représentait une faille de sécurité potentielle. Nous allons créer deux utilisateurs ainsi que deux groupes, un tandem pour l'exécution de Pi-Hole, l'autre pour les services web qu'utilise Pi-Hole. Dans DSM : Panneau de configuration -> Utilisateur et groupe -> Groupe -> Créer. 1er groupe : Nom : pihole Description : Exécute le conteneur Pi-Hole Autorisations dossiers partagés : Aucun accès pour tous les dossiers sauf docker (Lecture/Ecriture) et homes (on ne coche rien) Autorisation applications : Tout refuser 1er utilisateur : Nom : pihole Appartient au groupe : pihole Tout le reste est issu des permissions liées au groupe 2ème groupe : Nom : pihole-www Même chose que pour pihole 2ème utilisateur : Nom : pihole-www Appartient aux groupes : pihole-www et pihole Tout le reste est issu des permissions liées aux groupes En SSH, on va attribuer la propriété des deux dossiers de configuration créés dans la section précédente à l'utilisateur pihole et au groupe pihole : cd /volume1/docker chown -R pihole:pihole pi-hole/ On vérifie que les permissions sont ok : Avant de clôturer cette partie, nous allons vérifier les uid et gid de nos utilisateurs et groupes nouvellement créés, nous en aurons besoin pour personnaliser notre fichier compose : REMARQUE : les valeurs ci-dessus sont propres à votre installation, ne les recopiez pas bêtement ! 7. Configuration et initialisation 7-A. Création du fichier compose On va utiliser Docker-compose pour créer notre conteneur. Docker-compose est une manière alternative de créer un conteneur qui possède de nombreux avantages par rapport à la ligne de commande et à l'interface proposée par DSM. De plus Docker-compose vient avec le paquet Docker de Synology, donc aucune installation supplémentaire n'est nécessaire. Venons-en à la création de notre fichier compose : nano docker-compose.yml On y colle le contenu suivant, il suffit de copier les données suivantes, revenir dans l'éditeur nano, et faire un clic droit. version: '2.1' services: pi-hole: image: pihole/pihole container_name: pi-hole hostname: pi-hole networks: macvlan-network: ipv4_address: 192.168.100.161 environment: # General - ADMIN_EMAIL=xxx@yyy.zzz - TZ=Europe/Paris - PIHOLE_DNS_=80.67.169.12;9.9.9.9 # IP des serveurs DNS FdN et Quad9 - DNSSEC=false - DNS_BOGUS_PRIV=true - DNS_FQDN_REQUIRED=true - DNSMASQ_LISTENING=local - INTERFACE=ovs_eth0 - FTLCONF_LOCAL_IPV4=192.168.100.161 # IP du conteneur Pi-hole - VIRTUAL_HOST=pi-hole.ndd.tld # Si on souhaite acceder a Pi-hole par un nom de domaine (proxy inverse par exemple) - WEBPASSWORD=xxxxxxxxxxxxxxxxxxxx # Mapping utilisateurs et groupes - PIHOLE_UID=1045 # pihole UID - PIHOLE_GID=65548 # pihole GID - WEB_UID=1044 # pihole-www UID - WEB_GID=65547 # pihole-www GID # Conditional forwarding - REV_SERVER=true # Permet de recuperer les hostnames des peripheriques du reseau - REV_SERVER_TARGET=192.168.100.xxx # Voir paragraphe CONDITIONAL FORWARDING - REV_SERVER_CIDR=192.168.100.0/24 # Votre sous-reseau local - REV_SERVER_DOMAIN=ndd.tld # Domaine local # Personnalisation interface - TEMPERATUREUNIT=C - WEBTHEME=default-darker - WEBUIBOXEDLAYOUT=boxed volumes: - /volume1/docker/pi-hole/etc-pihole:/etc/pihole/ - /volume1/docker/pi-hole/etc-dnsmasq.d:/etc/dnsmasq.d/ dns: - 127.0.0.1 - 80.67.169.12 restart: unless-stopped networks: macvlan-network: external: true REMARQUES : Il est important de respecter l'indentation (l'alignement des paramètres). Si vos serveurs publiques définis dans PIHOLE_DNS_ prennent en charge DNSSEC, vous pouvez passer cette dernière variable à true. On a défini ici 2 serveurs publics différents, pour limiter les risques d'indisponibilité (merci à @Einsteinium pour sa suggestion). Si vous n'utilisez pas de proxy inversé, il n'est pas nécessaire de définir la variable VIRTUAL_HOST. Ce fichier permet de définir dès le lancement avec précision la valeur de la plupart des paramètres, pour la liste exhaustive de toutes les variables d'environnement disponibles, consultez cette page. 7-B. Conditional forwarding Si vous pouvez vous contenter de l'affichage des IP au lieu des noms d'hôte des périphériques, vous pouvez vous abstenir de définir les quatre variables d'environnement REV_SERVER_ dans le fichier compose. Sinon : 7-C. Création du conteneur Il n'y a plus qu'à créer le conteneur, pour cela on a juste à taper : docker-compose pull && docker-compose up -d Docker va télécharger l'image, et créer le conteneur. Attendez une minute ou deux au premier lancement, Pi-hole met un peu de temps pour démarrer. On peut ensuite se rendre sur l'adresse IP du conteneur (ou le nom de domaine défini dans VIRTUAL_HOST si on a défini cette variable), si tout va bien on arrive sur la page d'accueil de Pi-Hole. 8. Résolution locale L'étape ultime, mais la plus importante, est de faire en sorte que votre serveur DHCP envoie à ses clients l'adresse IP de Pi-hole comme serveur DNS primaire. Pour le vérifier, il suffit de taper dans une invite de commande Windows par exemple : nslookup nas-forum.com Si les deux premières lignes du résultat sont équivalentes à : Serveur : pi.hole Address: 192.168.100.161 Félicitations, votre Pi-Hole est fonctionnel ! Pour vérifier que le blocage de publicités est actif, essayez d'aller sur http://doubleclick.net, si le nom de domaine ne peut être résolu, c'est que Pi-Hole a filtré la demande (veillez à désactiver tout bloqueur de pubs intégré au navigateur en amont). Quid du serveur DNS secondaire ? Bien qu'il puisse être rassurant d'envoyer comme serveur DNS secondaire l'IP d'un serveur DNS publique, pour qu'en cas d'indisponibilité de Pi-Hole, la résolution DNS globale soit toujours active sur le votre réseau local, il arrive qu'un périphérique préfère s'adresser au DNS secondaire plutôt que primaire, et dans ce cas-là les requêtes n'étant accessibles que localement échoueront. Pour éviter ces désagréments, on peut mettre en place un deuxième serveur Pi-Hole sur un périphérique simple comme un Raspberry Pi, une machine virtuelle sur un autre serveur ou un autre NAS compatible Docker si on en possède un. La suite s'adresse aux utilisateurs souhaitant pousser plus avant la configuration de Pi-Hole. - AVANCÉ - 9. Modes d'utilisation 9-A. Pi-Hole + serveur DNS local + serveur DHCP Ce point n'est pas abordé dans le tutoriel, je ne trouve pas ça prudent de laisser un conteneur du NAS gérer le serveur DHCP, c'est beaucoup moins stable qu'un périphérique dédié comme un routeur, avec une installation native. Et sans DHCP, vos périphériques ne pourront non seulement pas discuter entre eux, mais pas accéder à Internet non plus. 9-B. Pi-Hole + serveur DNS local Dans le cas où vous avez déjà un serveur DNS local actif sur votre NAS ou tout autre périphérique, vous pouvez placer Pi-Hole en amont du serveur DNS local. Il faudra alors donner comme valeur à la variable d'environnement DNS1 l'IP de l'hôte du serveur DNS. Si vous avez une redondance de serveurs DNS local, pensez à compléter DNS2 de manière analogue. Vos périphériques interrogeront d'abord Pi-hole, qui transmettra ensuite la requête à votre serveur DNS local, lui-même transmettra aux redirecteurs que vous lui avez précisés si la requête n'est pas résoluble localement. Périphérique -> Pi-Hole -> Serveur DNS local -> Serveur publique "upstream" ATTENTION : Si vous utilisez un serveur DNS sur l'hôte même (par exemple DNS Server), il faut utiliser l'IP virtuelle du NAS, pas son IP physique habituelle (merci à @anorec). 9-C. Pi-Hole en tant que serveur DNS local 9-C-1. Ajout des enregistrements Il est possible d'utiliser directement Pi-Hole comme résolveur DNS local. C'est extrêmement pratique si vous n'avez encore mis aucune résolution locale en place (avec DNS Server par exemple). ATTENTION : Pi-Hole n'est pas en mesure d'être source d'autorité pour une zone publique, il faut pour cela passer par exemple par des logiciels comme BIND ou DNS Server de DSM, qui n'en est qu'une surcouche. Pour se faire on se rend sur la page d'accueil de Pi-Hole, on se connecte en cliquant sur Login, on utilise le mot de passe précédemment défini dans le fichier compose. Dans le menu latéral apparaît l'onglet Local DNS, deux sous-menus apparaissent : DNS Records et CNAME Records : Le premier permet de définir les enregistrements A pour le domaine et les périphériques de votre réseau. Le second permet de définir des alias pour les domaines précédemment définis. Une image est plus parlante qu'un long discours : Notes : Depuis mon réseau local, taper domaine1.fr dans mon navigateur m'amènera sur l'IP de ma passerelle. Si ma box ou mon routeur expose son interface sur le port 80, j'arriverai dessus. J'ai volontairement donné à domaine2.fr une IP inexistante sur le réseau, Pi-Hole ne vous indiquera aucune erreur, il se contente de vous indiquer la direction, même s'il y a un fossé trois mètres plus loin. 😉 C'est votre navigateur qui y sera confronté et vous renverra une erreur. nas.domaine1.fr pointe sur mon NAS, sur lequel par exemple je pourrais utiliser un proxy inversé. Et maintenant dans CNAME Records, je vais par exemple définir des alias pour mes périphériques et pour mon proxy inversé : REMARQUE : La seule règle doit être que la cible de l'enregistrement CNAME (le contenu de la colonne Target) doit avoir été préalablement définie dans la partie DNS records. Le rafraichissement de la zone se faisant à chaque nouvel ajout, il faut qu'il soit valide. 9-C-2. Vérification On peut vérifier par acquis de conscience que la résolution est bien effective : docker exec -it pi-hole bash En tapant ceci on se connecte directement dans le conteneur, à la suite de quoi on réalise quelques tests de résolution DNS : nslookup domaine1.fr nslookup domaine2.fr nslookup nas.domaine1.fr nslookup bitwarden.domaine1.fr nslookup nas.fauxdomaine.fr On peut ainsi vérifier qu'un ensemble d'enregistrements existent dans notre zone locale de Pi-Hole, et même d'autres qui n'existent pas pour lesquels Pi-Hole devrait nous renvoyer une valeur NXDOMAIN (Non-existent domain). 10. Blocage différencié Un des gros avantages de Pi-Hole face à la concurrence est la possibilité de créer des groupes de périphériques pour lesquels on peut personnaliser les listes de blocage, ou même désactiver Pi-Hole complètement. Ou a contrario d'être beaucoup plus restrictif. Quelques exemples concrets : Jeux mobiles : certains jeux gratuits nécessitent de visionner des vidéos pour pouvoir continuer de jouer. Il y a des grandes chances que Pi-Hole bloque ces publicités et altère en conséquence votre expérience de jeu. Il n'est pas rare qu'on souhaite contrôler strictement ce que du matériel domotique (caméra, détecteur, etc...) peut envoyer sur la toile. En ajoutant certaines listes de blocage pour cette catégorie d'équipements, on peut avoir la maîtrise des données transférées sans pour autant générer un nombre importants de faux-positifs sur les autres périphériques du réseau. On peut laisser actif Google Shopping pour madame. 🙂 C'est dans l'onglet Group Management que ça se passe, lequel comprend quatre sous-menus : Groups, Clients, Domains et Adlists. On se dirige en premier lieu dans Groups, dans lequel j'ai ajouté un groupe pour mon smartphone : Si je clique sur Enabled, la valeur passera à Disabled et Pi-Hole sera désactivé pour ce groupe, les requêtes seront directement transmises au(x) redirecteur(s). Dans Clients, je peux choisir dans la liste déroulante un des périphériques vus par Pi-Hole par son adresse MAC (ainsi que l'IP et éventuellement le nom d'hôte s'il en a connaissance). Il faut également choisir à quel groupe le périphérique appartient dans la cellule Group Management, et penser à appuyer sur Apply une fois le choix effectué : Dans Domains, je peux ajouter des domaines (liste blanche ou noire) manuellement (avec ou sans wildcard), ici j'utilise une chaîne regex pour autoriser certaines publicités pour un jeu installé sur mon smartphone : Dans le dernier sous-menu Adlists, je n'ai rien touché aux listes, j'ai laissé celles par défaut pour tous mes périphériques : 11. Commandes utiles Pour redémarrer le conteneur : docker restart pi-hole où pi-hole est le nom donné au conteneur. ____________________________ Pour l'arrêter et le supprimer : docker-compose -f /volume1/docker/pi-hole/docker-compose.yml down L'argument -f permettant de spécifier un fichier en dehors du dossier courant. ____________________________ Pour supprimer toutes les données de Pi-Hole (pour refaire une installation propre par exemple), il suffit de supprimer les dossiers dans le dossier du conteneur : cd /volume1/docker/pi-hole docker-compose down rm -ri etc-pihole etc-dnsmasq.d ____________________________ Pour le mettre à jour et le reconstruire : cd /volume1/docker/pi-hole docker-compose pull docker-compose up -d MàJ : 20/01/2023

Préambule L'objectif de ce tutoriel est de vous aider à mettre en place votre propre serveur DNS en interne (dans votre réseau local). Pour ce qui est de l’intérêt de disposer d'un serveur DNS en interne, voici quelques exemples : c'est plus fiable : vous n'êtes plus dépendant de la (non) fiabilité des DNS de votre opérateur (cf pannes d'Orange et de Free par exemple) c'est plus fiable (bis) : vous n'êtes plus soumis aux mensonges des DNS de votre opérateur (cf panne d'Orange et filtrage étatique) c'est plus rapide : grâce aux mécanismes de cache, vous ferez moins de requêtes DNS vers Internet c'est plus confortable : ça vous permet, par exemple, d'éviter de faire du loopback ou encore d'adresser vos équipements interne avec un nom au lieu d'une IP et enfin, ça vous permettra de remplacer une bonne partie des fonctions de QuickConnect (il faudra juste ouvrir les ports) et donc de couper ce dernier C'est surtout les 2 derniers points qui devrait vous intéresser car en remplaçant le loopback et Quickconnect vous gagnerez en sécurité, en fiabilité, en confort et en performances. Il ne s'agira pas d'un guide sur le protocole DNS, il y aurait beaucoup trop de choses à détailler (bien plus que sur mes précédents tuto combinés). Je vais donc prendre pas mal de libertés sur les termes employés afin de faciliter ma rédaction et votre compréhension. Pour la même raison, je serai assez avars en détails et en explications. Gardez juste à l'esprit qu'Internet repose sur 2 protocoles : BGP et DNS. Quand l'un des 2 attrape froid, tout Internet tombe malade (c'est déjà arrivé, y compris récemment). Si vous souhaitez gérer de A à Z vos DNS, renseignez-vous sur ces termes (c'est vraiment le strict minimum) : zone/resolver/XFER/glue/root/cache/split-horizon/pinpoint zone/DDNS/TTL/SOA/NS/A/AAAA/PTR/CNAME/TCP/UDP - et pour ceux qui s'intéressent à la sécurité : DNSSEC/DANE/HPKP/CAA. Petite précision tout de même, la notion de "sous-domaine" qu'on voit un peu partout n'existe pas. L'adresse www.nas-forum.com est un domaine au même titre que nas-forum.com. À la fin de ce tutoriel, vous aurez les éléments pour accéder à votre nas (ou à tout autre équipement) avec le même nom DNS que vous soyez chez vous, à distance via un VPN ou directement depuis Internet. Le DNS vous renverra à chaque fois la bonne adresse en fonction de votre emplacement. Mais je préfère vous avertir tout de suite, le DNS est un sujet bien plus complexe qu'il n'y parait. ###################################################################################### Notes de lecture Pour l'exemple, j'ai indiqué des valeurs fictives, il faudra donc les remplacer chez vous : fenrir.tuto : à remplacer par votre nom de domaine 192.168.0.2 : à remplacer par l'adresse IP privée de votre nas 192.0.2.3 : à remplacer par votre adresse IP publique (à ne pas confondre avec 192.168.x.y) www.fenrir.tuto : c'est un enregistrement d'exemple, vous pouvez en créer autant que nécessaire ns.registrar.externe : c'est le nom d'un serveur DNS qui fera office de serveur secondaire 1.2.3.4 : adresse IP d'un serveur qui fera office de serveur secondaire nb : les exemples sont en IPv4, mais le fonctionnement en IPv6 reste identique (il faut juste changer les adresses et remplacer les A par des AAAA). Ce tuto comporte 3 parties, par ordre croissant de difficulté : Cache DNS local : tout le monde devrait pouvoir y arriver en quelques cliques Zone DNS locale : cette partie devrait être abordable pour la plupart des utilisateurs Zone DNS publique : on change totalement d’échelle de difficulté ici, le principe est simple, mais la mise en œuvre peut être complexe Il n'y a aucune raison technique qui nécessite de faire la dernière partie, elle est là pour illustrer un peu plus le fonctionnement d'une architecture DNS, mais elle n'est en aucun cas nécessaire. Certains points ne seront pas abordés ou détaillés, mais il peut être utile, voir nécessaire de les mettre en œuvre, en particulier les zones de type "esclave" et inverses. Vous trouverez aussi pas mal d'informations complémentaires dans les commentaires, en particulier un retour très complet de @Mic13710 : --> cliquez ici <-- ###################################################################################### Pré requis Savoir faire des requêtes DNS, ça peut paraitre bateau dit comme ça, mais ce n'est pas aussi simple qu'un ping. Vous pouvez utiliser la commande "nslookup", elle est présente par défaut sur la plupart des systèmes (y compris les Synology). Je ne vais pas vous faire une doc, mais les 3 commandes importantes sont : demander les informations de zone : nslookup -querytype=SOA fenrir.tuto 192.168.0.2 demander la liste des serveurs de zone : nslookup -querytype=NS fenrir.tuto 192.168.0.2 demander la valeur d'un enregistrement : nslookup www.fenrir.tuto 192.168.0.2 Pour utiliser votre NAS comme serveur DNS, pour devrez modifier la configuration DNS de vos clients, le plus simple reste de le faire avec votre serveur DHCP, si vous utilisez une "box", ça ne sera surement pas possible, dans ce cas, utilisez le serveur DHCP du NAS (il est intégré par défaut dans tous les Synology depuis DSM 6.0 ou sous forme de paquet dans les versions précédentes). Si vous souhaitez héberger la résolution de votre domaine du point de vu d'Internet (donc être SOA et/ou NS), vous devez avoir une adresse IP fixe et disposer d'un second serveur DNS ailleurs. ###################################################################################### Cache DNS local Un cache DNS est un serveur DNS qui garde en mémoire les précédentes résolutions qu'il a du faire afin d'y répondre plus vite lors de nouvelles demandes. L'autre intérêt de disposer de son propre cache local et de s'affranchir des pannes et autres filtrages des serveurs DNS de votre opérateur Internet. Ce cache joue alors le rôle de "résolveur". C'est très rapide à mettre en place et ça consomme très peu de ressources, donc faites-le ! Commencez par installer et lancer le paquet DNS Server. Puis allez dans : Et configurez les options comme suit : nb : j'utilise les DNS de FDN comme "redirecteurs", car ils sont fiables et respectent votre vie privée (contrairement à ceux d'OpenDNS par exemple), mais vous êtes libre d'utiliser les serveurs de votre choix, voir aucun, votre serveur se chargera alors de l’ensemble des résolutions (ce n'est pas toujours très efficace). Il est primordial de cocher la case "Limiter le service IP source" et de bien configurer son contenu. Si vous ne le faites pas, tout le monde pourra utiliser votre serveur DNS pour résoudre n'importe quel enregistrement, votre NAS en souffrira et sera peut-être utilisé pour des attaques vers d'autres cibles. Dans la "Liste d'IP source", mettez ces adresses : Maintenant il faut tester que ce serveur fonctionne correctement, le plus simple reste de lui poser une question : nslookup nas-forum.com 192.168.0.2 Vous devriez obtenir une adresse IP (au moment de la rédaction de ce tuto, c'est 5.196.244.24). Si vous n'obtenez pas de réponse ("timeout" ou encore "No response from server") c'est que vous n'arrivez pas à contacter le serveur DNS, dans ce cas il faut vérifier qu'il est bien lancé, que c'est la bonne IP, que le firewall autorise bien le trafic ...) Si vous obtenez une réponse du type "Query refused" c'est qu'il y a bien un serveur DNS en face, mais qu'il refuse votre question, donc soit vous lui parlez mal, soit il n'est pas autorisé à vous répondre (cf "Liste d'IP source" juste au dessus) Si le serveur vous répond correctement, vous en avez terminé pour le cache DNS et vous disposez maintenant d'un résolveur DNS local utilisable par tous vos clients (y compris ceux en VPN). N'oubliez pas de modifier votre serveur DHCP pour qu'il renseigne vos clients sur l'adresse de votre serveur DNS. ###################################################################################### Zone DNS locale Une zone DNS est un fichier dans lequel sont inscrits les enregistrements DNS d'un domaine. Un des avantages d'une zone locale c'est qu'elle n'a pas besoin d'exister sur Internet. Un usage courant de ce type de zone est de s'en servir pour donner des noms à ses équipements, plus simple facile à retenir que des adresses IP. Vous pouvez par exemple créer une zone "maison", elle sera fonctionnelle dans votre réseau pour faire nas.maison, routeur.maison, ... Vous pouvez aussi créer un domaine enfant du premier (par exemple cam.maison qui contiendrait vos caméras IP, comme salon.cam.maison) et qui sera soumis à d'autres restrictions. Néanmoins, je vous déconseille fortement d'utiliser un nom de domaine que vous ne possédez pas car ça risque de créer des problèmes de sécurité. Préférez l'usage d'un domaine que vous possédez, si vous n'en avez pas ça ne coute que quelques euros par an (on en trouve à 1€/an), même si vous n'avez pas prévu de vous en servir sur Internet. nb : il ne faut jamais utiliser le suffixe ".local", même en interne Si vous ne souhaitez pas acheter un nom de domaine, vous pouvez utiliser sans risques les noms suivants : .test, .example, .invalid et .localhost Pour la suite, j'ai utilisé le gTLD .tuto car il n'est pas enregistré au moment de la rédaction de cet article, mais rien ne dit qu'il ne le sera pas quand vous lirez ces lignes. Allez dans : Puis "Créez" => "Zone master" : Et configurez-la comme suit : Pour la "Liste d'IP source", mettez ceci : Puis sélectionnez votre zone et faites "Modifier" => "Enregistrement de ressource" : Enfin, créez une (ou plusieurs) ressource(s) du type CNAME : Par exemple : Vous devriez obtenir ça : Le nom www.fenrir.tuto renverra l'adresse de ns.fenrir.tuto, donc l'adresse IP privée de votre nas. Voici un exemple plus complet : Il se lit comme suit : fenrir.tuto de type NS : cet enregistrement indique que le serveur de nom (NS) pour le domaine "fenrir.tuto" est ns.fenrir.tuto ici j'ai gardé le nom créé par Synology, ns.fenrir.tuto, mais si vous souhaitez que votre NS s’appelle ratatouille.fenrir.tuto, aucun soucis (il faudra juste modifier le type A correspondant) nas.fenrir.tuto : il s'agit d'un "alias" qui renvoi la même chose que ns.fenrir.tuto c'est plus parlant que ns pour un nas wordpress.fenrir.tuto : un autre alias pour l'utiliser avec WebStation (vhost) ou avec un reverse proxy tv.fenrir.tuto : j'ai donné un nom à la tv on se demande bien pourquoi faire ? mail.fenrir.tuto : adresse du serveur de messagerie pour vos utilisateurs c'est un type A (pas un alias) car c'est important pour les enregistrements MX ns.fenrir.tuto : l'adresse du serveur DNS (l'enregistrement de la première ligne) il doit toujours s'agir d'un type A fenrir.tuto : il indique l'adresse du serveur de messagerie pour les autres serveurs de messagerie un MX doit pointer sur un type A Vous pouvez voir que j'ai indiqué plusieurs enregistrements avec le même nom mais un type différent ou encore plusieurs noms différents qui pointent sur la même IP, c'est parfaitement valable et ne pose aucun problème si vous restez cohérents. J'aurai aussi pu mettre des IP publique pour "nommer" des ressources externes (par exemple donner un nom à un autre nas hébergé je ne sais où). Notez aussi que les TTL ne sont pas tous les mêmes. nb : avant d'aller plus loin, faites des tests avec "nslookup" pour vérifier que tout fonctionne correctement. C'est terminé pour cette zone, mais nous allons lui associer une vue pour plus de sécurité et de contrôle. ###################################################################################### Vue DNS locale Pour simplifier, considérez qu'une vue DNS est un mécanisme permettent de donner des réponses différentes en fonction de l'adresse des clients. Ça revient à peu près à disposer de plusieurs serveurs DNS au même endroit, mais avec des données et des droits différents. Nous allons créer une vue pour nos clients locaux (ou vpn), ce n'est pas une obligation, mais ça simplifiera les choses pour la suite tout en ajoutant un peu de sécurité. Allez dans : Puis "Créer" : Ici on va limiter cette vue aux seuls clients locaux (ou vpn). Enfin, on sélectionne les zones qui seront dans cette vue : nb : encore une fois, il faut tester que tout fonctionne avant de continuer. Voilà, vous avez maintenant un serveur DNS local pleinement fonctionnel pour les rôles de cache, de résolveur et de serveur de zone. Mais vous pouvez faire pleins d'autres choses, tout dépend de votre niveau de connaissances et de compétences comme par exemple du filtrage de contenu indésirable (pub, facebook, malware, ...), du MitM, un annuaire, ... nb : vous pouvez aussi créer une vue dédiée à vos clients VPN afin qu'ils puissent atteindre votre nas via son adresse en 10.x (cf tuto vpn) simplement en entrant un nom DNS, il faudra juste bien penser à le limiter aux adresses VPN (en 10.x). ###################################################################################### Zone DNS publique Jusqu'à présent on ne s'est occupé que de nos clients locaux ou VPN mais pour permettre à un client sur Internet de résoudre une adresse, il faut créer une zone publique. Ici vous avez 3 possibilités. Utiliser des serveurs sur Internet, généralement ceux de votre bureau d'enregistrement, en tant que SOA et NS, dans ce cas la suite n'est pas nécessaire. Utiliser des serveurs sur Internet, généralement ceux de votre bureau d'enregistrement, en tant que NS, mais vous êtes SOA, ça peut être assez complexe à faire Être à la fois serveur SOA et NS, c'est le choix de l'indépendance, mais c'est aussi le plus complexe à faire Ici je vais prendre l'exemple d'un auto hébergement complet, vous êtes donc SOA et NS pour votre domaine. À ne faire que si vous commencez à être bien à l'aise avec les DNS ou pour tester et apprendre. Cette opération n'est pas triviale et nécessite plusieurs prérequis, pas toujours accessibles, je recommande donc de choisir la première option, elle devrait convenir à la plupart d'entre vous. Le résultat sera le même du point de vue résolution, cette étape n'est en aucun cas obligatoire pour se passer de QuickConnect ou pour avoir des réponses différentes entre le LAN et Internet. nb : il faut une adresse IP fixe et un autre serveur DNS pour la suite, si ce n'est pas votre cas, ceci ne fonctionnera pas, ou mal. Allez dans : Puis "Créez" => "Zone master" : Et configurez-la comme suit : nb : 192.0.2.3 est une adresse publique (réservée pour les documentations), à ne pas confondre avec 192.168.x.y On garde le même nom de domaine, mais on déclare l'IP publique pour le serveur DNS principal, par contre on ne limite pas le service à certaines IP source. Vous devriez obtenir ceci : La nouvelle zone est nommée fenrir.tuto(2). On va devoir faire un peu plus de réglages pour qu'elle soit fonctionnelle : Ici on doit bien faire attention aux différentes valeurs (par exemple l'adresse mail doit exister, mais attention, elle sera visible de tous) : nb : les valeurs ci-dessous peuvent ne pas convenir à tous les usages, adaptez-les si besoin Ensuite on procède comme précédemment pour créer les ressources : Cette fois ci, www.fenrir.tuto renverra l'adresse IP publique de votre NAS. (edit) : ce n'est pas dans la capture, mais il faut aussi créer un enregistrement pour le "naked domain", le domaine lui même, ça doit être un type A Nom : fenrir.tuto Type : A TTL : à vous de voir Information : 192.0.2.3 Quelques remarques sur le TTL : Un TTL (Time To Live) est la durée de validité d'une ressource, passé ce délai, les serveurs DNS vont supprimer cette entrée de leurs caches si vous mettez une valeur trop petite, vous ne profiterez pas du cache si vous mettez une valeur trop grande, les modifications mettront du temps à se propager ne mettez JAMAIS la valeur 0 sous peine de ne plus jamais pouvoir corriger un enregistrement ou qu'il ne fonctionne pas (selon les implémentations, 0 peut être considéré comme invalide, donc l'enregistrement sera rejeté ou pire, il sera considéré comme n'expirant jamais) ###################################################################################### Vue DNS publique Comme pour la zone locale, nous allons associer une vue à cette zone publique, cette fois-ci destinée à nos clients Internet. Allez dans : Puis faites "Créer" : Et sélectionnez bien la zone publique : Vous devriez obtenir ceci : Les clients avec des adresses privées se verront proposer le contenu de la vue LAN, donc de la zone fenrir.tuto Les autres clients se verront proposer le contenu de la vue WAN, donc de la zone fenrir.tuto(2) Il faut maintenant permettre aux clients sur Internet d'accéder à votre serveur. Ouvrez l'interface de votre routeur pour créer 2 règles de redirection de port : port 53 en TCP vers votre nas port 53 en UDP vers votre nas Il faudra aussi autoriser ces ports dans le firewall de votre NAS. Vous avez maintenant votre zone publique, que tout le monde peut consulter, sauf que personne n'en connait l'adresse ! ###################################################################################### NS public Pour que votre serveur DNS, donc votre NAS, soit référencé, il faut le déclarer dans les serveurs de votre TLD (pour un .fr, c'est l'AFNIC). C'est à faire auprès de votre bureau d'enregistrement (probablement là où vous avez acheté votre domaine). C'est une opération administrative, qui est soumise à certains contrôles techniques. Donc avant de commencer, vous devez vérifier que votre zone publique est bien configurée. Le plus simple et de faire le test sur https://www.zonemaster.fr/ Choisissez l'option "Test d'un domaine non délégué" et remplissez les différents champs comme suit : Vous ne devez avoir aucune erreur (les avertissements ne devraient pas être bloquants), mais si vous avez suivi le tuto, vous allez en avoir au moins une : Une architecture DNS se doit de disposer d'au moins 2 serveurs de nom (NS) pour une zone donnée. Il vous faut donc configurer un autre serveur DNS qui contiendra les mêmes valeurs que celles présentent dans votre NAS (le serveur secondaire recevra les données depuis votre NAS). nb : un DNS secondaire (on parle plutôt d'esclave ou slave en anglais) est un serveur qui contient une copie du fichier de zone, il ne peut pas en modifier le contenu Le plus simple pour ça et d'utiliser les serveurs DNS de votre bureau d'enregistrement, certains permettent de faire DNS "secondaire". Si ce n'est pas le cas il faudra trouver un autre serveur DNS acceptant de jouer ce rôle pour votre zone. Si vous avez plusieurs adresses IP publiques, il vous suffit de monter un autre serveur derrière l'une des autres adresses Vous pouvez aussi demander à un ami ou à de la famille de le faire (enfin, vous allez devoir le faire pour eux ), s'ils ont un Synology vous savez déjà comment vous y prendre Si vous êtes coincés, je peux faire office de NS secondaire, au moins le temps de la mise en place de votre architecture (envoyez moi un MP pour en discuter) Vous avez donc 3 choses à faire : Autoriser un autre serveur DNS à se synchroniser sur votre NAS (transfert de zone) L'ajouter comme serveur NS de la zone Et lui indiquer l'adresse de votre NAS pour qu'il se mette à jour (on parle ici de quelques ko maximum à transférer) Rendez-vous dans Sélectionnez la zone publique : Puis cliquez sur "Modifier" => "Paramètres de zone" : Activez le transfert de zone : Et spécifiez les adresses des serveurs qui vont faire office de DNS secondaire : Une fois ceci fait, il faut déclarer ces serveurs comme NS dans votre zone (toujours la zone publique de votre NAS) : Indiquez l'adresse du serveur secondaire : Vous devriez avoir ceci : Et enfin, configurez votre DNS secondaire pour qu'il se synchronise avec votre SOA (votre NAS), il suffit de créer une zone de type "slave" et de lui indiquer les bons paramètres. Une fois tout ceci en place, refaites le test zonemaster en indiquant vos 2 serveurs NS (votre NAS et le DNS de votre prestataire/ami/...) : Idéalement vous devriez obtenir un résultat similaire à celui-ci : nb : jusqu'à présent, tout ce que vous avez configuré n'est valable que pour vous et n'a aucun impact pour le reste des utilisateurs sur Internet, si vous avez un doute, c'est le moment ou jamais de faire pause. Si et seulement si le test est concluant (pas d'erreur bloquante), il faudra vous rendre une dernière fois sur l'interface de votre bureau d'enregistrement afin d'y spécifier les adresses de vos serveurs NS. L'opération prend en général quelques jours pour être appliquée partout. nb : vous serez peut être amenés à déclarer un enregistrement de type GLUE pour que ns.fenrir.tuto soit reconnu et puisse fonctionner comme NS de la zone fenrir.tuto, le problème est assez simple, si vous ne le voyez pas, documentez-vous avant de continuer Dernière précision, les vues isolent les zones, c'est le principe, donc si vous voulez voir apparaitre un même enregistrement dans les différentes vues, il faut le créer dans les différentes zones (comme le www.fenrir.tuto de mon exemple).

WATCHTOWER 1. Préambule Le but de ce tutoriel est de mettre en place une application, containrrr/watchtower (Docker Hub, Github) qui va vérifier suivant un intervalle que vous définirez la présence d'une nouvelle version pour totalité ou partie de vos images Docker. C'est un fork de v2tec/watchtower qui n'est maintenant plus mis à jour depuis près de deux ans. Ce tutoriel se basait historiquement sur l'image pyouroboros/ouroboros, qui n'est plus maintenue. NOTES : Les commentaires concernant watchtower (et pas ouroboros) commencent au milieu de la page 2. Avantages : - Plus besoin de vérifier via Docker Hub si une mise à jour est disponible - Processus entièrement automatisé - Ne consomme quasi aucune ressource Inconvénients : - Nécessite un accès à docker.sock, d'un point de vue sécurité ça peut être gênant pour certains - Suivant l'intervalle de vérification que vous définissez, la quantité de données échangée peut être importante, à surveiller si vous avez un quota - On ne peut l'installer par l'interface Docker de DSM (en fait si, mais c'est fastidieux). Je pondérerai le volet concernant la sécurité, si vous avez bien respecté les conseils de sécurité développés dans les tutoriels de référence de ce forum vous ne devriez pas avoir de souci à vous faire. 2. Prérequis - Savoir se connecter en SSH (root) - Avoir Docker installé sur son NAS C'est parti ! On commence par se connecter en SSH avec l'utilisateur root (voir le tutoriel [TUTO] Accès SSH et ROOT via DSM 6). On télécharge l'image : docker pull containrrr/watchtower Il ne reste plus qu'à créer le conteneur, mais il est avant tout intéressant de voir les fonctionnalités que l'application propose dans la documentation, et en particulier sur cette page. C3es paramètres sont personnalisés par l'ajout de variables d'environnement à la création du conteneur. 3. Configuration 3-A. Fréquence de mise à jour - INTERVAL : Définit un intervalle de mise à jour en secondes. Ex : WATCHTOWER_POLL_INTERVAL=300 - SCHEDULING : Le plus intéressant pour des particuliers je trouve, cron permet de définir une périodicité très personnalisable : tous les x jours, tous les mardi, 3 fois par jour le mercredi et le vendredi, à telle heure, x fois par mois, etc... la documentation de l'image renvoie vers ce site, mais je trouve ce générateur ou celui-ci très pratiques. L'image utilise un format CRON à 6 champs, contrairement aux liens ci-avant qui n'utilisent que 5 champs, en réalité, tous les champs sont décalés vers la droite pour proposer un réglage sur les secondes. Donc au lieu d'avoir : minutes | heures | jour du mois | mois | jour de la semaine vous avez secondes | minutes | heures | jour du mois | mois | jour de la semaine Ex : WATCHTOWER_SCHEDULE=0 0 5 * * 6 Cela correspond à une exécution hebdomadaire, tous les samedi matin à 5:00 Un conseil : Évitez d'utiliser 2:00 ou 3:00, à cause des changements d'heure 😉 Ces deux méthodes sont exclusives, c'est donc l'une ou l'autre. 3-B. Tri sélectif Par défaut, watchtower surveille tous les conteneurs. Mais on ne souhaite pas spécialement mettre à jour tous ses conteneurs automatiquement, certains sont gérés par des scripts de mise à jour (Bitwarden par exemple), d'autres sont peu maintenus, et il est plus risqué de mettre à jour aveuglément ce type d'images que celles issues de collectifs reconnus (Linuxserver, Bitnami, etc...). Plusieurs méthodes de tri sont proposées : - LABEL ENABLE : Permet d'utiliser les labels (des tags en quelque sorte) comme signes de distinction. Lorsqu'on crée un conteneur, on peut décider de lui ajouter un label, composé d'un intitulé et d'une valeur de type chaîne ou entier. Pour permettre à watchtower de mettre à jour un conteneur donné, il doit avoir parmi ses labels : com.centurylinklabs.watchtower.enable=true L' avantage énorme c'est que le nom du conteneur cible n'a pas d'importance, le fait qu'il n'existerait plus à un instant t n'a pas davantage d'incidence. Pour faire en sorte que la sélection des conteneurs à surveiller se fasse par label, il faut ajouter la variable suivante à la création du conteneur watchtower : WATCHTOWER_LABEL_ENABLE=true - FULL EXCLUDE (Ce n'est pas une variable d'environnement !!) : L'approche est exclusive au lieu d'être inclusive, elle se base sur le comportement par défaut de watchtower (surveillance de tous les conteneurs), mais il n'y a ici aucune variable d'environnement à préciser à la création du conteneur watchtower, en revanche les conteneurs que vous ne souhaiteriez pas surveiller doivent avoir le label suivant : com.centurylinklabs.watchtower.enable=false Notes : - Il n'est pas possible d'ajouter un label à un conteneur déjà existant. Il faut le recréer et insérer le label dans le script de création du conteneur. Si vous savez les recréer facilement (peu de paramètres à entrer, vos volumes sont persistants et les fichiers de configuration sont maintenus à la suppression du conteneur, ou si vous utilisez docker-compose) alors je préconise la méthode des labels, dans le cas contraire préférez la méthode FULL EXCLUDE. - La documentation est particulièrement claire à ce sujet. 3-C. Gestion des images - CLEANUP : Supprime la version précédente de l'image quand une plus récente a été téléchargée et qu'un nouveau conteneur a été créé. Cette fonctionnalité est désactivée par défaut. Ex : WATCHTOWER_CLEANUP=true - ROLLING RESTART : Par défaut, watchtower met à jour toutes les images avant de relancer les conteneurs, cette variable d'environnement permet de relancer les conteneurs au fur et à mesure, utilise si on souhaite réduire les périodes d'indisponibilités. Ex : WATCHTOWER_ROLLING_RESTART=true - WAIT UNTIL TIMEOUT : Par défaut, watchtower attend 10 secondes qu'un conteneur s'arrête une fois le signal d'extinction transmis. Certaines applications lourdes nécessitent plus de temps, cette variable permet d'ajuster ce délai. Ex : WATCHTOWER_TIMEOUT=30s Notes : - On notera la présence du "s" pour "seconde". - LINKED CONTAINERS : Certains conteneurs peuvent nécessiter que d'autres conteneurs soient opérationnels avant d'être créés, on prend souvent comme exemple le cas typique d'une application et d'une base de données. Afin d'éviter des erreurs, on souhaite que la base de données soit disponible avant l'application à la création, et inversement à la suppression. Ces relations existent par exemple lorsqu'on utilise l'argument --link en ligne de commande, ou avec l'instruction depends_on via docker-compose. On peut écraser ces réglages via le label : com.centurylinklabs.watchtower.depends-on tel que par exemple, si on applique ce label à un conteneur MariaDB : com.centurylinklabs.watchtower.depends-on=wordpress,caldav En cas de mise à jour disponible pour ce dernier, watchtower arrêtera au préalable les conteneurs wordpress et caldav. 3-D. Autres paramètres - DEBUG : Augmente le niveau de verbosité du stdout dans les logs du conteneur. Ex : WATCHTOWER_DEBUG=true - TRACE : Un debug encore plus verbeux, attention les credentials éventuels sont en clair ! Ex : WATCHTOWER_TRACE=true - TZ : Permet de définir le fuseau horaire, assure le lien entre la variable CRON si vous l'utilisez et votre fuseau horaire. La liste des timezone est disponible à cette adresse. Ex : TZ=Europe/Brussels Il y a encore énormément de fonctionnalités que je n'aborderai pas ici, citons parmi les plus notables : - les notifications => https://containrrr.dev/watchtower/notifications/ - La supervision de plusieurs instances Docker via un seul conteneur watchtower => https://containrrr.dev/watchtower/remote-hosts/ et https://containrrr.dev/watchtower/secure-connections/ (pour une connexion sécurisée (TLS), une lecture de https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ peut être instructive 😉) - la possibilité d'exécuter des scripts avant et après la mise à jour (par l'utilisation de labels) => https://containrrr.dev/watchtower/lifecycle-hooks/ - la possibilité d'utiliser d'autres dépôts que Docker Hub, ouvrant la voie à des dépôts privés => https://containrrr.dev/watchtower/private-registries/ Au final ce tutoriel se contente de traduire et de mettre en valeur les variables importantes, la documentation (je crois que je me répète 😛) est très complète. 4. Création du conteneur On a maintenant tous les outils en main, on va pouvoir créer notre conteneur. Pour se faire, plusieurs possibilités : 4-A. En lignes de commande (SSH) Voici un exemple de configuration : docker create --name=watchtower \ --hostname=watchtower-nas --restart=unless-stopped \ --label "com.centurylinklabs.watchtower.enable=true" \ -e WATCHTOWER_CLEANUP=true \ -e WATCHTOWER_DEBUG=true \ -e WATCHTOWER_LABEL_ENABLE=true\ -e WATCHTOWER_TIMEOUT=30s \ -e WATCHTOWER_SCHEDULE="0 0 5 * * 6"\ -e TZ=Europe/Brussels \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower Notes : - On est obligé de monter en volume le socket Docker au vu des opérations que doit pouvoir effectuer watchtower sur les autres conteneurs. - On peut tout à fait demander via le label de mise à jour que watchtower se mette lui-même à jour. Si tout a bien fonctionné, vous devriez avoir comme retour une suite de chiffres et de lettres (correspondant à l'ID du conteneur), il ne reste plus qu'à le démarrer : docker start watchtower 4-B. Par Docker-compose (SSH) Une autre personnalisation de l'image au format docker-compose : docker-compose.yml version: '2.1' services: watchtower: image: containrrr/watchtower container_name: watchtower hostname: watchtower-nas network_mode: bridge environment: - WATCHTOWER_NOTIFICATIONS=email - WATCHTOWER_CLEANUP=true - WATCHTOWER_DEBUG=true - WATCHTOWER_LABEL_ENABLE=true - WATCHTOWER_TIMEOUT=30s - WATCHTOWER_SCHEDULE=0 0 5 * * 6 - TZ=Europe/Brussels env_file: - /volume1/docker/watchtower/watchtower.env labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - /var/run/docker.sock:/var/run/docker.sock - /volume1/docker/watchtower/config.json:/root/.docker/config.json restart: unless-stopped Notes : - J'ai cette fois-ci ajouté les notifications par mail, mais on remarque qu'on ne retrouve pas les autres variables qui sont liées au relais SMTP (https://containrrr.dev/watchtower/notifications/#email). En réalité, pour des raisons de confidentialié, j'ai regroupé les variables qui sont plus "sensibles" dans un fichier .env qui est invoqué par : env_file: - /volume1/docker/watchtower/watchtower.env Fichier qui se présente sous la forme, et dont les permissions sont correctement réglées pour assurer le niveau de confidentialité désiré : WATCHTOWER_NOTIFICATION_EMAIL_FROM=... WATCHTOWER_NOTIFICATION_EMAIL_TO=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=... WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=... - J'ai monté le fichier config.json pour y ajouter des credentials pour des dépôts privés. Pour créer le conteneur, on se place (cd) dans le dossier où se trouve le fichier docker-compose.yml et on tape : docker-compose up -d 5. Configuration Ci-après un exemple de logs suite à un déclenchement programmé de Watchtower : 2020-11-14 05:01:31 (info): Found new grafana/grafana:latest image (sha256:68f75fcab5a9372fb0844f5898c65a40b0ca34cff4176e269bade17ddb17ee75) 2020-11-14 05:01:48 (info): Found new telegraf:latest image (sha256:146c415345a26f48f8ef06c2f62ebde90c8ca4ca518db5d88137e60eeb0abeec) 2020-11-14 05:01:59 (info): Found new authelia/authelia:latest image (sha256:d05b2f15beecd4c164a861e0464ddfef1d574b1c67f8e343779daec26c7bbde9) 2020-11-14 05:03:17 (info): Found new linuxserver/mariadb:latest image (sha256:f48f265a3ed8b786973e85c2c681f2f79db1b64d38660c43900bfc48651c6f83) 2020-11-14 05:03:19 (info): Stopping /grafana (bfdbba3a284d51c1a5c5c807f8583857a0c6a03718a083e93e5bcf9671f7130f) with SIGTERM 2020-11-14 05:03:21 (info): Stopping /telegraf (56e1c8624a98344cba07ca6f745c0cd8a93d66b36ebc0af8992cac210c8e0d51) with SIGTERM 2020-11-14 05:03:22 (info): Stopping /authelia (6d4202898398cf0b46886d38c6591a15b83334e00fe20a0025fcd4437747f84c) with SIGTERM 2020-11-14 05:03:23 (info): Stopping /mariadb (763aeebe73c029c20de2a15d114c054ba70b26879fdaf82b3019944179f31573) with SIGTERM 2020-11-14 05:03:27 (info): Creating /mariadb 2020-11-14 05:03:31 (info): Creating /authelia 2020-11-14 05:03:34 (info): Creating /telegraf 2020-11-14 05:03:40 (info): Creating /grafana 2020-11-14 05:03:42 (info): Removing image sha256:ec8e3ebf50429170fa6387bb04e64e5b5f3d87f3221c42750b7fb5d922c5e978 2020-11-14 05:03:43 (info): Removing image sha256:48121fbe19c845fa401be9fdbf3cbeef50840b7537d8a0b9ca2eab081117beb6 2020-11-14 05:03:43 (info): Removing image sha256:7606d5ee069fcab20036c4bd521e1133ac8ca31e44f7d241f0d83a36315d6ca6 2020-11-14 05:03:43 (info): Removing image sha256:900b03b57e41a8bf7f43b8979872bb2d6642d9a4bcb738d053fb67e1d989e926 MàJ : 10/04/2021

Fin de semaine au besoin on peut se faire un vocal et TeamViewer.

Les amis, j'ai réussi, grâce à vous !!!! J'aimerais sincèrement vous remercier! Pas parce que c'est important pour moi, non, parce que c'est essentiellement grâce à des gens comme vous que la plupart des personnes arrivent à résoudre leurs soucis. Merci à ce forum et surtout merci au membre actif qui gères ça. 😘 Ps: La solution étais décrite par @.Shad. et j'ai du mettre le chemin /home/xteve/.xteve/tv.m3u pour pointer vers le fichier.

@MilesTEG1 Bonjour, C'est sûr que j'ai essayer de transcrire quelque chose qui n'est déjà pas clair déjà dans mon esprit. 😳 Regardes le lien sur la doc que j'ai donné. Si j'ai bien compris c'est possible de relire un fichier "config.json" qui contient une valeur cryptée pour le couple "user:passwrd". Voilà ce que j'essaie de transposer à l'ensemble des données d'environnement de watchtower. Ni plus ni moins. Cordialement oracle7😉

Oui c'est ça 🙂 @.Shad. a donné la solution, et surtout une recommandation qui est selon moi un impératif : changer d'image.

Ok je viens de voir ce que tu as fait, tu as créé une référence circulaire. Pour tes volumes (ta première impression d'écran), fais juste un montage ainsi : docker/xteve/config /home/xteve/.xteve D'après la documentation tu auras des problèmes de permission. Concrètement l'image n'est pas correctement maintenue, peu de retard de l'auteur, tu devrais plutôt t'orienter vers https://hub.docker.com/r/alturismo/xteve qui est l'image conseillée officiellement par Xteve. Si tu souhaites persister quand même, il te faudra te connecter en SSH et taper la commande suivante : sudo chmod 777 -R /volume1/docker/xteve/config Dans l'absolu ce n'est pas souhaitable, donc je t'invite à changer d'image.

DNS Server c'est une interface pour BIND, avec des fonctionnalités en moins. Après si tu te sers de DNS Server juste pour une zone locale, autant basculer tes enregistrements sur Adguard qui possède cette fonctionnalité si je ne m'abuse. SWAG c'est prévu pour Docker, Adguard pas forcément, ça c'est à toi de voir, j'aime bien le côté libre de dépendances sur l'hôte avec Docker.

Ma suggestion était de mettre juste SWAG, mais rien ne t'empêche de mettre Adguard aussi. DNS Server tu vas avoir du mal c'est un paquet DSM. Ca consomme rien ces applications là, les données ne transiteront pas par le PI non plus. Je disais ça dans le cas où tu ne le gardais pas.

@Macman Bonjour, OUI bien sûr. Regardes ce TUTO : DNS Server et restes en à a zone locale. C'est suffisant pour te permettre d'utiliser tes sous-domaines en local comme depuis l'extérieur. En plus si d'aventure ta box ne gère pas le loopback cela y palliera. Bonne lecture Cordialement oracle7😉

@Macman Bonjour, Surtout qu'il crée bien un "wilcard" (*.ndd.tld) ce sera plus simple pour toi après. Cordialement oracle7😉

On peut raisonnablement penser que si tu te connectes en 2FA avec un périphérique, tu peux accéder à tous les autres sites nécessitant le même niveau de sécurité, ça ne me choque pas. Sinon dans la partie session, tu peux ajuster la durée du cookie d'authentification, etc... Oui c'est root c'est normal.

Oui, c'est un bête fichier, auquel tu essaies par contre d'appliquer des permissions strictes, ça évite d'avoir le mot de passe dans le fichier de configuration directement. Comme pour les autres secrets en fait. 😉

Salut, Chez moi pas de souci : Tu peux : vérifier qu'il n'y a pas une tabulation parasite au niveau du champ password vérifier que le chemin indiqué pour AUTHELIA_NOTIFIER_SMTP_PASSWORD_FILE est le bon dans le fichier compose. vérifier que les droits en lecture sont OK https://www.authelia.com/docs/configuration/session/ A priori c'est au niveau du paramètre samesite que tu règles ça. Par défaut c'est le fonctionnement normal.

En fait chez moi le fichier n'existait pas et je l'avais créé juste avec des règles map ... donc il manquait le début. Tout est bien qui finit bien mais ce fut laborieux lol

Bonsoir @maxou56 Je viens seulement de comprendre... que je pouvais réutiliser la Time Capsule (simplement comme disque dur) 🙃 Donc pas besoin de mettre un disque dur sur le routeur Synology 🙂 C'est le but, que ce soit sauvegardé sur le NAS. Pour autant que je puisse le faire sans souci (Mac OS Monterey, Puce M1) Je testerai... Effectivement. Et à l'inverse, est-ce possible que deux macbook (le mien et celui de mon fils) puissent faire les sauvegardes sur le même disque dur (Time Machine)? Le câblage reste identique à celui que j'avais pour l'Airport Time? Box (wifi coupé) -> MR2200ac (wifi) J'ai passé un peu (beaucoup) de temps pour faire un plan du réseau internet de la maison (voir le fichier ci-joint) L'Airport Time Capsule serait remplacé par le Synology MR2200ac Je ne suis pas une spécialiste. Je me suis fait aider par plusieurs personnes au fil du temps. Il est fort probable que cela ne soit pas "correct"... Si vous voyez des choses à modifier, à corriger... Merci.

Bonjour Oracle. La panne des processeurs C2000 vient à l'origine de la défaillance d'un transistor interne qui pilote la transmission d'un signal d'horloge en direction de l'Eprom du Bios du NAS. Quand ce transistor lâche, l'horloge s'arrête et empêche la lecture du Bios et donc le démarrage du NAS. En fait il y a deux transistors Mosfet (voir schéma ci-dessous) pour piloter ce signal. Celui du haut qui fait passer le signal à l'état haut (+3,3V), et celui du bas qui le fait passer à l'état bas (0v). Et c'est celui du haut qui est tombé en panne et ne conduit plus le courant. (cercle rouge) Mais on peu le remplacer partiellement par une résistance connectée au 3,3V, qui va tenir le signal au niveau haut, et seul le transistor du bas suffira à générer l'horloge en mettant alternativement la ligne à 0V ce qui récrée le signal carré nécessaire. Plus cette résistance est faible, plus le courant qui traverse le transistor du bas est fort, et risque à terme de le faire griller. En augmentant la valeur, on limite le courant dans le transistor restant et donc sa durée de vie. On sait que ça doit pouvoir fonctionner jusqu'à 750 ohms, mais avec 470, on a une bonne marge de sécurité pour que ça marche à tous les coups. Attention un Nas déjà réparé avec 100 ohms qui est retombé en panne définitivement ensuite ne pourra pas revenir à la vie avec cette autre résistance. Il y a une autre méthode que j'exposerai dans l'autre sujet: https://www.nas-forum.com/forum/topic/55281-soucis-sur-les-atom-c2000-panne-programmée-des-modèles-rs2416-rs2416rp-rs815rs815rp-ds2415-ds1815-ds1515-ds415/page/18/

Bonjour, Le Wifi MESH fonctionne avec le principal configuré en Point d'accès (Bridge) au lieu de routeur.