.Shad.

Tu peux montrer tes informations de connexion dans Synology Drive, l'agent Windows (à quelle IP il se connecte, ou nom d'hôte) ? Est-ce que tu utilises un VPN sur ton NAS (en tant que client) ?

Maintenant, si tu veux avoir les noms d'hôte plutôt que les IP, tu vas dans Settings -> DNS -> tu vas tout en bas dans conditional forwarding. Là tu rentres les 3 informations qu'il te demande, tu valides et tu attends quelques minutes, tu devrais voir les noms d'hôte apparaître à la place des IP.

Non normalement c'est bon, car chez toi le port 53 est redirigé depuis la box vers ton serveur DNS qui héberge ta zone publique, et pas pi-hole, donc pas de risques. Cela dit les 2 premières options suffisent normalement dans ton cas. J'avais dans l'idée que en changeant le réglage ici, tu pouvais voir un "hop" plus loin que le serveur DNS, car oui là il voit tout arriver depuis le serveur DNS, vu qu'il intervient avant dans la chaîne de résolution. C'était une solution que je proposais à @oracle7 car il n'arrive pas à se défaire de sa case grisée. Dans ton cas tu as tout intérêt à faire intervenir Pi-hole en premier dans la chaine de résolution : Périphérique => Pi-hole => Serveur DNS => Redirecteurs Ainsi tu verras la liste de tous les périphériques de ton réseau, enfin les IP car il faut aussi configurer le conditional forwarding dans le même onglet Settings -> DNS de Pi-hole pour voir les noms d'hôte tels qu'enregistrés dans le serveur DHCP. Ou alors tu passes des variables dans le fichier compose, comme tu peux le voir sur l'exemple que j'avais donné de mon fichier compose pour Pi-hole un peu plus haut.

Alors le fail2ban je ne l'ai pas installé sur le NAS, car je me connecte en SSH chez moi depuis l'extérieur uniquement via mon serveur debian, qui n'accepte qu'une clé publique. Et lui possède les clés pour mes différents NAS et périphériques du réseau. Par contre je l'utilise sur mon VPS, et là en faisant une configuration identique : On voit bien les IP publiques qui sont bannies dans les logs remontés par Loki. Pour les applications, où tu passes par le proxy inversé, normalement /config/nginx/proxy.conf contient : proxy_set_header X-Real-IP $remote_addr; Et les fichiers de configuration dans /config/nginx/proxy-confs/ y font appel via un include : # for Synology DSM GUI server { listen 443 ssl; listen [::]:443 ssl; server_name dsm-ds918.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app ds918.ndd.tld; set $upstream_port 5000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Si je regarde les logs d'Emby, en me connectant en 4G avec mon smartphone : 2020-12-10 22:42:53.392 Info Server: http/1.1 Response 200 to 178.144.167.69. Time: 4ms. http://emby.ndd.tld/Items/49541/Images/Thumb?maxWidth=509&tag=29287fdde9c02f68f2e9d1928219d32a&quality=90 2020-12-10 22:42:53.468 Debug ImageProcessor: Image encoding to /config/cache/images/resized-images/1/14c9ca76-8074-cb88-71f7-6d6f09060a08.webp took 75ms for /config/metadata/library/df/df0881c61686b56c0fd4a14516bb68f8/landscape.jpg 2020-12-10 22:42:53.468 Info Server: http/1.1 Response 200 to 178.144.167.69. Time: 76ms. http://emby.ndd.tld/Items/49525/Images/Thumb?maxWidth=509&tag=dd3e4629b2a834901fc1372408ed0966&quality=90 Les logs de pfSense : Dec 10 23:55:24 php-fpm 43363 /index.php: Successful login for user 'username' from: 192.168.100.105[178.144.167.69] (Local Database) Dans tous les cas on voit l'IP réelle, vérifie donc déjà que tu inclus bien cette directive dans ta config Nginx, mais par défaut c'est le cas normalement. J'avoue que je ne vois pas le rapport avec Synology, car ici tu translates directement depuis ton routeur vers ton conteneur swag, pour moi c'est transparent.

Tu as quoi dans Settings -> DNS ->

Càd ? Tu ne vois que l'IP des serveurs DNS locaux dans tes clients sur Pi-hole ?

Honnêtement pas la moindre idée, l'autorité de certification qui délivre le certificat n'entre pas dans la ronde d'acme normalement (du script j'entends).

A partir du moment où tu ajoutes un fichier, et que tu n'édites pas un fichier existant, je pense que ça devrait tenir d'une màj à l'autre (en tout cas pour les mineures, pour les sauts de version c'est effectivement moins certain 🙂).

J'ai trouvé ça, si ça peut t'aider (mais ce n'est pas très exhaustif non plus) : https://community.synology.com/enu/forum/17/post/2623 EDIT : Encore mieux : https://www.synology.com/fr-fr/knowledgebase/DSM/help/WebStation/application_webserv_general (à la fin de l'article)

Comme dit @Jeff777, c'est qui tu veux, ça peut être FdN et Cloudflare aussi. Tant que c'est dans le domaine publique. En fait rien ne t'empêche de mettre l'adresse du RPI pour les DNS du RT même, mais dès que ton RPI sera déconnecté ou en train de rebooter, il ne pourra plus résoudre les adresses. Je ne vois pas l'intérêt, à moins que tu veuilles filtrer ce qu'envoie éventuellement ton routeur vers Synology. Selon moi c'est plus de problèmes potentiels qu'autre chose.

Ajout d'un guide succinct pour fail2ban et de remarques suite à celles de @Einsteinium

Une seule et même application peut écouter sur un port donné. Il faudra donc que NextDNS écoute sur un autre port que le 53.

Un lien intéressant pour connaître la différence entre DoT (DNS-over-TLS) et DoH (DNS-over-HTTPS) : https://www.cloudflare.com/learning/dns/dns-over-tls/ Si on héberge déjà une zone locale (ce qu'on appelle faire du split horizon) il faudra que NextDNS écoute sur un autre port que le 53 si sur le même hôte, sinon sur un autre périphérique, dans une VM ou un conteneur en macvlan, ça devrait le faire. 😉

Tu devrais pouvoir trouver des choses intéressantes par ici : https://github.com/search?q=synology+downloadstation

Tu ne perds aucun blocage, car ce qui se passe c'est éventuellement qu'une application X envoie des données au périphérique Y depuis le périphérique Z, tout ça en local. Dès que ça doit accéder au domaine public, ça passera forcément par Pi-hole, car ton DNS local ne saura pas résoudre (à condition de bien avoir défini des redirecteurs dans DNS Serveur, ce qui est normalement le cas, sans redirecteur le serveur résout récursivement les domaines et donc n'a pas plus besoin de passer par Pi-hole).

A ta place je ne fixerais pas l'IP WAN du RT mais je ferais une réservation d'IP dans la Livebox pour lui attribuer l'IP en question. Pour le sous-réseau 192.168.2.0/24, si tu n'arrives pas à libérer la case DNS du serveur DHCP, je laisserais tel quel, donc le RT pousserai sa propre IP comme serveur DNS à ses clients, dans DNS Server je mettrais l'IP du Pi-hole comme redirecteur. Dans Pi-hole, je mettrai les upstream DNS (FdN et Cloudflare dans ton cas) dans DNS 1 et 2.

La convention de nommage n'est peut-être pas la même, voir ce lien qui décrit comment nommer ses fichiers pour maximiser les chances d'identification automatique : https://support.plex.tv/articles/naming-and-organizing-your-tv-show-files/

C'est un peu réducteur de dire ça. Si j'ai juste besoin d'un NAS qui fait simplement office de serveur de fichiers, ou de destination de sauvegarde, un J conviendra tout à fait... Il faut juste connaître son besoin. Récemment j'ai pris un DS118 pour en faire une destination de sauvegarde car j'ai trouvé cette occasion à 40€, ce qui était une très bonne affaire, sinon j'aurais sûrement pris un J neuf. 🙂

A toi. Pour ta question, c'est assez simple. Tu n'as visiblement pas laissé la box attribuer une IP sur le WAN de ton RT, tu l'as configuré en manuel. Et tu as mis l'IP de la box pour les DNS du routeur. Donc quand il cherche à résoudre un domaine, il demande à la box. Sauf qu'en-dessous tu as décidé de configurer manuellement les DNS, donc il ne va pas demander à la box, mais à FdN puis Cloudflare si FdN ne répond pas suffisamment vite. Et le DHCP dit aux clients sur l'interface LAN d'utiliser le routeur comme serveur DNS, donc ce qu'il y a sur 192.168.2.1:53, a priori ta zone DNS locale via DNS Serveur qui occupe ce port.

Aucune idée, n'ayant pas de RT je ne peux pas t'aider. Sinon tu fais : DNS local -> Pi-hole -> Internet au lieu de Pi-hole -> DNS local -> Internet.

Un renouvellement tous les mois c'est étrange, un certificat Let's Encrypt c'est tous les trois mois que ça se renouvelle, si laissé en automatique. Pour ma part je n'ai pas de souci avec Drive, qui utilise un certificat wildcard Let's Encrypt avec le NDD Synology renouvelé automatiquement dans DSM. Pas de message qui me précise que le certificat a changé. Sinon tu peux créer un certificat autosigné, ils peuvent avoir une durée "éternelle" (plusieurs années), la première fois il te dira que le certificat n'est pas fiable, car non émis par une autorité de certification (vu que c'est toi qui le crée). Pour une utilisation locale c'est amplement suffisant.

Pourquoi tu passes le DHCP sur le NAS alors que ta box est totalement paramétrable ? La discussion d'avant concernait un utilisateur dont la box est totalement bridée (comme la vaste majorité des box FAI), tu peux très bien laisser la Freebox gérer tout ça.

C'est ce que donne Pi-hole quand il bloque une pub, il ne modifie pas la mise en page comme le fait un adblocker sur navigateur. Les Upstream DNS sont les redirecteurs, Pi-hole consulte ses listes de blocage, bloque ce qu'il doit, puis transfère la requête aux upstream DNS. Pi-hole ne fait pas de résolution récursive, il ne va pas lui-même interroger les serveurs DNS racine pour connaître l'IP d'un domaine, il transfère à l'upstream DNS qui se charge du reste. Si tu as une zone locale, je te conseille de mettre : - l'IP du pi-hole comme serveur DNS pour le DHCP. - Mettre en Upstream DNS 1 l'IP du NAS qui héberge ta zone locale (dans ton cas, vu que tu as une zone esclave sur ton autre NAS, tu peux mettre en DNS 2 l'IP du deuxième NAS). - Dans DNS Server, mettre en redirecteur les DNS dont tu te sers pour la résolution publique (FdN, Cloudflare, Google, ton FAI, etc...). PS : Je ne vois rien d'anormal sur les graphiques et les valeurs renvoyées.

Dans l'ultra majorité des cas on va effectivement s'en servir ainsi, mais pourquoi l'obliger ? je pourrais très bien vouloir que cela ne serve qu'à certains périphériques (qui rentreraient manuellement l'adresse du routeur comme serveur DNS). J'insiste, l'obliger c'est clairement un raccourci à ne pas emprunter, on devrait être libre de mettre ce qu'on veut. Plus globalement, je ne comprends pas le succès qu'ont les routeurs Synology. Le rapport fonctionnalités/prix est risible. Pour le même prix on peut avoir un vrai pare-feu et une borne Unifi. 😕 @oracle7 Est-ce que tu as essayé de stopper le paquet DNS Server pour voir si la case était toujours grisée comme l'a suggéré @Jeff777 ?

Regarde dans ce fil de discussion le message de johnk.dev.null : https://community.synology.com/enu/forum/17/post/69726 Essaie via Telnet les commandes qu'il donne. Synology garde dans /etc.defaults les fichiers de configuration originaux en cas de problème. Donc il fait un backup de l'existant au cas où, l'écrase par le fichier par défaut, et tue le processus SSH. Essaie ensuite de te connecter en SSH via ton utilisateur ou root.