.Shad.

Il faut activer le pare-feu et de créer uniquement les règles suivantes : Cette image est tirée du topic que tu mentionnes dans ton post, tout sera plus clair à sa prochaine lecture. 🙂 Deuxième chose, tu désactives QuickConnect, et tu ne te connectes qu'avec ton user/password. Dernière recommandation, je t'invite après la lecture du dit tutoriel, à envisager la mise en place d'un serveur VPN, c'est la solution la plus sûre pour accéder à son réseau depuis l'extérieur. Il y a beaucoup d'autres choses à faire, mais celles-là me semblent les plus cruciales.

On s'entend, je parle de RAID 5 / SHR indifféremment. 😉

Ca me semble un peu paranoïaque du RAID 10 pour son utilisation ? même du RAID 6 ça me semble trop. J'aurais dit plutôt RAID 5... ?

Pour moi le serveur DHCP de la Freebox n'envoie que 192.168.1.21 comme serveur DNS à ses clients via son serveur DHCP. Ainsi tous tes périphériques seront obligés de passer par le serveur DNS sur le NAS. J'imagine que c'est pour ça que tu l'utilises, chaque périphérique pourra faire de la résolution locale d'adresse. A partir du moment où tes périphériques demandent une adresse internet, il faut que le serveur DNS local passe la main à Pihole, donc dans ses redirecteurs tu mets une seule adresse, celle du Pihole, 192.168.1.27 Dans Pihole, tu peux donner deux adresses IPv4 ou IPv6 (Custom DNS 1 et 2), tu y mets les adresses FDN : 80.67.169.12 et 40 En reprenant ton schéma j'enlève donc ce qui est en rouge et laisse ce qui est ok en vert : Attention que par Freebox je parle de son serveur DHCP, donc celui qui distribue les IP à tes autres périphériques. La Freebox a ses propres DNS, généralement ceux du FAI. Si tu peux les changer, mets ceux de FDN.

En effet, tu ne fais plus intervenir ton serveur dans ton circuit. Attention qu'il ne faut pas confondre ce que ton serveur DHCP attribue comme serveur DNS à ses clients, et ses propres DNS, qu'il reçoit normalement du FAI. Ce que je te conseille, c'est de dire au serveur DHCP de ta Freebox d'attribuer comme serveur DNS à ses clients ton résolveur local (192.168.1.21), et dans DNS Serveur (Synology) tu fais pointer tes redirecteurs vers ton Pihole (192.168.1.27), et seulement lui (pas de deuxième serveur). Ainsi, quand tu cherches à joindre un domaine local, tu laisses le pihole en dehors du circuit, ça n'a pas d'intérêt vu que tu restes chez toi. Si ton résolveur ne trouve pas d'enregistrement correspondant à ta demande, ça t'envoie vers le Pihole, pour lequel tu peux renseigner en DNS1 et 2 les IP de FDN comme tu l'as fait. Il y a un inconvénient à cette architecture, c'est que les deux périphériques (pihole et NAS) doivent être connectés en permanence. Par contre, pourquoi renseigner le Pihole comme serveur DNS pour la Freebox ? Même si ça doit marcher, ça crée une sorte de boucle, pour moi ça n'a pas de sens, on indique à un périphérique en amont un serveur DNS en aval... EDIT : Propos plus clair

As-tu essayé le tutoriel suivant :

Une Nvidia Shield (ou autre box) fera l'affaire.

Tu remplaces la commande pihole -a -p par bash ou ash, suivant ce qui donne un résultat 😮

Je ne me sers plus de Pihole depuis un petit temps. Que ce soit en physique ou virtualisé. La commande que je t'ai donnée permet d'exécuter une commande donnée dans un container donné, donc : Oui 🙂 (tu peux enlever sudo si tu te connectes directement en root)

Il faudrait que je l'installe chez moi, je ne m'en sers plus, la commande pihole -a -p permet de changer le password de la WebUI sur une installation classique hors Docker, je pensais que dans le container c'était une installation classique, du coup je t'ai filé la commande permettant d'exécuter cette commande dans le container directement. Est-ce que tu arrives à te connecter au container déjà avec : sudo docker exec -it pihole bash Si ça ne marche pas avec bash ça devrait fonctionner avec ash. Une fois connecté au container tu tapes : pihole Dis-moi ce que ça te dit.

Tu es en SHR, équivalent Synology du RAID 1, ça veut dire que ton deuxième disque est un miroir du premier. En cas de défaillance d'un disque, il n'y aura pas de discontinuité de service et ton NAS continuera de fonctionner. Ça implique que pour deux disques de capacité égale, tu ne pourras utiliser que la capacité d'un seul disque. Ceci n'est pas une sauvegarde !! Une sauvegarde implique qu'en cas de perte des données, tu puisses les restaurer, ça n'a rien à voir avec le RAID 1. Ce que tu avais l'air de vouloir c'est deux volumes distincts, un utilisable et l'autre servant de destination de sauvegarde. Ce n'est pas du tout la même chose.

@Varx Tu ne créerais pas un nouveau sujet ? C'est compliqué de retrouver ta liste, et ce sera de pire en pire avec le temps... Je pense que ce serait pas mal qu'un modérateur dés-épingle le sujet présent d'ailleurs, vu que l'initiateur n'est plus actif pour l'étoffer (dernier message en 2015).

Normalement dans la partie WAN des box/routeur, il n'y a pas besoin d'utiliser Pihole, c'est le serveur DHCP qui se charge de distribuer son adresse. Tu es resté sur le driver macvlan ? ou tu es passé en host ?

Tu peux très bien te connecter en local sur ton NAS via ton navigateur. Dans ce cas-là les données ne transiteront pas par l'extérieur. Ou faire comme a dit @EVOTk PS : On aime bien que les gens se présentent dans la section appropriée avant de poser leurs questions 🙂

Plex par Docker c'est sur le 218+ uniquement. Par le package officiel c'est tous les modèles je pense.

Oui pardon, je ne l'ai pas précisé.

Variable d'environnement WEBPASSWORD dans ton script de création du container. Sinon, si tu ne veux pas le recréer, tu dois te connecter au container et entrer la commande pour ça : sudo docker exec -it pihole pihole -a -p Le premier pihole c'est le nom du container, à adapter à ton cas.

Bienvenue !

127.0.0.1 c'est localhost c'est pareil. Ça permet que s'il change son IP locale, il n'y ait pas d'impact. Ok pour 172.28.0.0/24, par contre t'es parti pour faire une règle de pare-feu pour chaque container avec lequel tu dois communiquer, ça me semble fastidieux. Tu chiffres deux fois, une fois pour arriver à ton proxy inversé, là c'est bien, et une fois entre ton proxy inversé et ton container, là il n'y a aucun intérêt. Le HTTPS est utile si tu dois directement accéder à Bitwarden de manière sécurisée sans passer par un proxy inversé.

Si tu es en mode host, tu ne peux pas, tout simplement car Pihole utilise les ports du NAS directement, il est installé sur l'hôte, donc il n'y a pas de mappage de ports possible. Je sais très bien quelle méthode tu as utilisé, j'ai bien vu quand tu lui demandes dans les commentaires s'il a une solution au fait de voir juste l'IP de la passerelle, il a répondu à côté (incompréhension ou il botte en touche, je ne sais pas). Regarde cette discussion : https://github.com/pi-hole/docker-pi-hole/issues/135 Personne n'a trouvé de solution. Hormis celle de passer en mode host, et cette méthode a les gros inconvénients cités plus hauts. Essaie ce que je t'ai dit dans un premier temps. Une idée : je n'ai aucune expérience avec les VM classiques, est-il possible quand on crée une VM que ce soit le serveur DHCP qui lui attribue une adresse IP ou elle doit être rentrée manuellement ? Car si c'est possible, alors le serveur DHCP donnera toutes les infos nécessaires à la VM faisant tourner Pi-Hole, et le conditional forwarding devrait permettre de voir en plus le nom des appareils à la place de leurs IP.

Dans ton pare-feu, tu autorises l'accès aux adresses 172.28.0.1 à 172.28.0.254, es-tu sûr que le container bitwarden de l'interface a cette adresse-là ? Remplace cette règle par 172.16.0.0/255.240.0.0 Ça autorisera tous les containers créés en mode bridge à discuter avec ton NAS. Et dans ta règle, tu n'as pas besoin de passer deux fois par du HTTPS, dans destination tu mets HTTP / 127.0.0.1 (ou localhost) / 81 (si tu as bien renseigné le mapping du port 81 lors du script d'installation de Bitwarden). Ensuite si tu n'as pas d'ouverture vers le réseau local sur le port 81, crée une règle pour ce port, et teste si ça marche. Pour moi c'est ta règle de pare-feu qui n'est pas bonne.

En macvlan, avec une adresse IP sur la plage de ton réseau local, ou en bridge avec une adresse en 172.x.0.1, la passerelle est le NAS, tout passe par celui-ci avant d'aller à ton container. Un peu comme internet passe par ton routeur avant d'arriver à ton périphérique. Le driver macvlan permet non pas de changer les ports, tu peux déjà le faire avec un driver bridge, mais justement d'utiliser les ports par défaut de Pihole (80 et 53), sans être en conflit avec le NAS car le container a sa propre adresse IP "physique". En bridge, le container en 172.x.0.1 n'est accessible à aucun autre périphérique que son hôte le NAS, on contourne le problème en exposant les ports qu'utilise le container sur des ports libres du NAS ; par exemple le port 80 (WebUI) du container peut être associé au port 8080 du NAS. Quand on installe le container sur l'hôte directement (paramètre --net=host en ligne de commande ou network_mode: host via docker-compose v2.x), il n'y a plus de passerelle, le container s'exécute directement sur le NAS. Donc normalement, tu devrais être capable de voir la liste des clients. Ça ne diffère d'une installation classique (sans docker) que dans le sens où le container embarque ses propres dépendances, quand tu supprimes ton container ça ne touche à rien de ce qui est installé sur le NAS (et de facto tu n'as rien à installer en plus). Mais le problème de ce mode est que tu utilises les ports par défaut, et ceux-ci sont utilisés par Webstation et DNS serveur. Tu peux faire un test, désactiver les deux paquets, créer ton container en mode host et voir si ça fonctionne comme tu le souhaites.

La meilleure solution reste de loin de l'installer sur un périphérique tiers, sur l'hôte directement. Ou alors, il faut désactiver les paquets DNS serveur et Webstation, pour libérer les ports 53 et 80, et utiliser le driver net=host lors de la création du container. mais ça peut être handicapant pour ceux qui ont besoin de ces paquets. Après c'est surtout au niveau de l'analyse et le traitement des métriques que ça pose problème d'avoir un seul client dans les dashboard. D'un point de vue fonctionnalité c'est parfaitement opérationnel.

Si tu peux répondre à ma question stp 🙂

@unPixel Ok en effet on ne s'était pas compris. 🙂