.Shad.

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. 🙂

Il a quand même déjà mis un proxy inversé en place, même s'il est nouveau sur le forum il a probablement une petite connaissance du NAS, et peut-être une lecture de quelques tutos. Quant au port 80, c'est possible. Je sais juste que si je tente de créer un container utilisant un port déjà en cours dutilisation surnle NAS, il me dira que ce n'est pas possible. Un lien à me donner pour voir de quoi il est question avec le .htaccess ?

Ok merci de l'info 🙂

S'il a ouvert tous les ports vers son LAN, comme préconisé dans le tutoriel de la sécurisation du NAS, et qu'il utilise le proxy inversé du NAS (ce n'est pas dit explicitement mais j'imagine que oui), il n'a pas besoin d'ouvrir de port supplémentaire. En revanche oui, il faut éviter d'utiliser les ports 80 (utilité par Webstation) et 443 (utilisé par le proxy inversé). Erreur 504 en revanche c'est étrange, peux-tu poster le contenu de l'entrée de ton proxy inversé relative à Bitwarden ?

Je crois qu'il est prévu que Drive devienne l'unique solution de synchronisation à moyen terme, à la façon de la fusion de Photostation et Moments dans DSM 7. Pour ma part je ne suis pas du tout satisfait de Drive et j'utilise Syncthing sous Docker pour la synchronisation de mes fichiers sur les différents appareils. Et j'entends beaucoup parler de Nextcloud, il faudrait que je teste. 🙂

Oui j'ai pris ce modèle-là pour l'exemple il y a plusieurs modèles il faut trouver celui qui correspond au besoin. Et là dessus les autres intervenants s'y connaissent mieux. 🙂

Bienvenue !

Ce n'était pas spécialement à ton intention la suggestion de PyLoad, surtout si tu débutes dans le domaine. Docker demande pas mal d'apprentissage, tu as le temps. 🙂 C'est plus pour les autres qui rencontrent le même problème (et vous êtes nombreux) et qui ont déjà des bases solides. A partir de là il serait facile de faire un tutoriel si personne ne trouve comment régler ça en utilisant Download Station.

Il faudrait que quelqu'un utilisant les services de téléchargement en direct download teste pyLoad : https://hub.docker.com/r/writl/pyload Ça a l'air très simple d'utilisation, et ça permettrait de confirmer que ça vient bien de Download Station et rien d'autre. J'aurais bien essayé moi-même mais je n'utilise aucun de ces services.

Vérifie que tu as renseigné ça dans ton NAS :

Sûrement une lacune de ma part, je ne vois pas comment tu augmentes sensiblement les débits en augmentant le nombre de disques. En revanche, disposer de 4 prises RJ45 est un bon moyen de muscler le débit, séparer les services via VLAN par exemple.

Quand on a compris le principe ce n'est pas très long en effet. 🙂

En prenant pas forcément le moins cher : - https://www.ldlc.com/fr-be/fiche/PB00212227.html - https://www.ldlc.com/fr-be/fiche/PB00157997.html - https://www.ldlc.com/fr-be/fiche/PB00111362.html On est à moins de 300€. Honnêtement je pense que ça vaut le coup de partir sur une borne Unify, je n'en ai pas personnellement mais au boulot ils utilisent ça et ça marche d'enfer, plus énormément de personnalisation possible.

Normalement avec l'IGMP Snooping tu peux "canaliser" les trames multicast aux périphériques sensées les recevoir. La plupart des switchs administrables intègrent cette fonctionnalité.

Tout ce que je peux te dire c'est que ça ressemble à une adresse multicast, je ne saurais pas t'en dire plus je n'y connais pas grand chose dans ce domaine particulier. C'est peut-être une première piste de réflexion.

Paquet = Application Bienvenue sinon 🙂

Bienvenue 🙂

Tu pars sur un NAS avec un nombre énorme de baies pour ... 4 To de données ? même en SHR-2, tu n'as du coup pas besoin d'autant d'emplacements. A ta place je partirais plutôt sur une version rackable type : https://www.synology.com/fr-fr/products/RS1619xs+#specs 4 baies, 2 pour le SHR-2, et tu peux mettre deux HDD de 3 ou 4 To pour voir venir. Je ne partirais sur du SSD NVMe que pour le cache en lecture (emplacement prévu à cet effet). Processeur Intel Xeon, mémoire ECC, 16 Go seront amplement suffisants à mon avis. Tu prévois un deuxième NAS pour de la sauvegarde ? ou pour l'utilisation nominale ? Car il te faudra prévoir un plan de sauvegarde, tu peux le faire sur du disque externe ou mieux sur un 2ème NAS, qui te servira de destination de sauvegarde avec Hyper Backup.

Ajouter non, car tu auras déjà tes quatre emplacements utilisés, par contre tu pourras les remplacer par des disques de plus grosse capacité si tu choisis le système de raid SHR au moment de la création du volume.

Bienvenue !