.Shad.

Super ! 🙂

Je n'ai jamais eu le moindre souci avec ces règles.

192.168.0.0/255.255.0.0 te permet de couvrir la plage 192.168.0.0 ... 192.168.0.254 ... 192.168.1.0 ... 192.168.1.254 ... 192.168.254.254 192.168.0.0/255.255.255.0 te permet de couvrir la plage 192.168.0.0 ... 192.168.0.254 Toi seul sait quel sous-réseau tu utilises, si éventuellement tu prévois un réseau invité avec un plage différente, etc... Si tu n'utilises qu'un seul sous-réseau, disons que ta box a l'IP 192.168.1.254, alors 192.168.1.0/255.255.255.0 sera adapté. Le principe de ces règles est d'ouvrir tous les accès aux demandes émanant d'une source locale, qu'on considère sûre par postulat de départ. Tous tes périphériques ayant une IP autorisé pourront converser pleinement avec ton NAS. Tu n'as peut-être créé aucun transfert de port sur ta box, mais pour peu que l'UPNP soit activé sur ta box, un malware pourrait très bien exposer ton NAS au web en créant ses propres transferts. Erreur de ma part, je voulais dire vrai pare-feu à la place de routeur. Ce qui de toute façon ne correspond pas à ce que tu cherches. C'est une bonne chose, les box sont la plupart du temps très limitées dans leurs fonctionnalités et les possibilités de personnalisation. Tant que ton utilisateur a des droits limités sur le NAS, ce n'est pas dramatique. 🙂 Faut juste être conscient des risques.

Les règles en 10.x.x.x sont pour les clients VPN, si tu mets en place un VPN via le paquet VPN server. Les 172.16.x.x c'est pour des machines virtuelles ou des containers docker. Tu peux les enlever mais je ne pense pas que tu prennes grand risque à laisser ces règles si par ailleurs tu respectes les autres recommandations. Les NAT de ta box est très basique, il filtre uniquement entre l'extérieur et l'intérieur de ton réseau local. Or tu veux probablement pouvoir converser avec ton NAS à l'intérieur de ton réseau local ? 🙂 Serveur multimedia, DLNA, rsync vers un autre périphérique, et éventuellement accéder à DSM 😛 Si tu avais un vrai routeur derrière ta box en bridge (pfSense, OPNSense, DD-WRT pour ne citer que les plus connus), tu peux totalement contrôler qui peut parler à qui et comment, au sein de ton réseau local. Dans ton cas il y a effectivement un risque, je prends l'exemple d'un virus qui infecte un laptop par exemple, sur lequel tu montes des dossiers partagés de ton NAS via l'utilisateur admin. Tu vois le tableau ? Mais ça relève dans ce cas-là d'un autre sujet, qui est la sécurisation de ton réseau local, et des bonnes pratiques de l'internet en général. Personnellement, tous mes dossiers partagés montés sur mon laptop et mon ordinateur de bureau sont faits via un utilisateur en lecture seule. Je ne peux que te conseiller l'achat d'un onduleur, avec extinction automatique par USB en cas de panne. Tu trouveras sur le forum une liste d'onduleurs compatibles avec ton modèle de NAS. Plus que pour les données, car si tu es consciencieux tu feras des sauvegardes régulières de tes données importantes, c'est simplement d'éviter de cramer ton NAS ou ses disques, une centaine d'euros pour très potentiellement en sauver plusieurs centaines, moi je trouve ça intéressant. TL;DR : Lis les tutoriels, ça répondra à la majorité de tes questions et plus encore.

En effet, si tu penses que ton orangePi pourrait être éteint de temps à autre, alors il vaut mieux ajouter un 2ème redirecteur dans DNS serveur sur ton NAS, avec l'adresse primaire FDN, ce qui donne :

Il faut voir qu'ainsi, tu es certain que tes requêtes passent forcément par ton résolveur local puis par ton Pihole si nécessaire. En revanche, pour peu qu'un des deux soit désactivé/déconnecté/planté ou autre, tu n'auras plus de résolution DNS. Si tu fais comme tu as proposé, tu n'auras plus ce problème, par contre tu n'es pas sûr que tes requêtes passeront par ton résolveur local et encore moins par ton Pihole. La solution est de faire de la redondance, mais je ne m'étendrai pas là-dessus car il y autant de méthodes qu'on veut pour en faire, ça peut être matériel, logiciel, être coûteux ou pas, bref c'est un sujet à part entière. 😛

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