oracle7

@Vista1967 Bonjour, Peut-être une mauvaise installation de ces paquets. Sans garantie : mais essaies de les désintaller et de les réinstaller ensuite. Puis redémarre ton NAS proprement. Ils devraient être alors actifs ... Les services de gestion et les ports associés (51966 & 51967) pour moi vont de paire avec les services Web que tu as définis pour DSM, dans le pare-feu ces sevices doivent être activés/autorisés pour que le flux à destination de DSM puisse passer. Du coup je ne comprend pas pourquoi cela passerait quand même lorsque tu dis les avoir désactivés dans le pare-feu. Bizarre, bizarre ... Donc lorsque ces régles de pare-feu sont désactivées, tu peux STP vérifier depuis l'extérieur (navigateur sur un Tél en 4G - pas de Wifi) avec un http://xxxx.synology.me:51966 et/ou https://xxxx.synology.me:51967 que tu atteins bien le NAS ? Normalement tu ne devrais pas ! Par contre si tu les actives, cela devrait passer. Après je ne sais que te dire de plus. Cordialement oracle7😉

@Vista1967 Bonjour, Je vais essayé de t'expliquer en espérant être clair. Du fait que tu as mis ton routeur en DMZ dans ta box, cela veux dire que ta box se comporte comme un simple modem ni plus ni moins. Donc tout ton flux Internet la traverse sans aucune restriction et arrive sur ton routeur qui avec son pare-feu bloque tout ce qui ne correspond pas à une règle définie (1 ère barrière de sécurité). Mais toi, tu as défini entre autres, deux règles qui autorisent du trafic (au passage elles sont grisées) au travers de ton routeur vers tes périphériques de ton réseau local, le NAS notamment. Pour mémoire, ces régles ont été créées automatiquement lorsque tu as mis en place un transfert (NAT) des ports 443 et 80 vers ton NAS. Donc, tout ton flux internet HTTPS (443) et HTTP (80) passe par ces deux ports respectivement et traverse alors ton routeur. Nota : Au passage, je vois que tu utilises aussi Synology Drive, alors il te faut aussi une règle de tranfert vers le NAS pour le port 6690. Ne pas modifier ce port ! sinon les synchros ne fonctionneront pas !!! Maintenant ce flux arrive sur ton NAS et si tu n'ouvres/autorises pas ces deux ports (idem pour 6690) dans le pare-feu du NAS, le flux sera bloqué au niveau du NAS (2ème barrière de sécurité mais limitée au NAS), donc inexploitable en aval par les services du NAS (photo, file, drive, reverse proxy, etc ...). ENsuite, ton reverse proxy écoute en permanence le port 443 et toute requête HTTPS qui arrive sur ce port via une URL avec nom de domaine spécifique ( tel que xyz.xxxx.synology.me) que tu as définie, est redirigé automatiquement vers l'@IP du service/machine concerné situé sur ton réseau local (en quelque sorte 3ème barrière de sécurité). Tout autre domaine non défini/répertorié par une règle sera rejeté. Enfin, saches que ton serveur DNS situé sur ton routeur, n'est là que pour rediriger toute URL émise en local (après traduction du domaine), vers la bonne @IP locale correspondante. Ainsi, plus besoin d'utiliser en local des URL avec une @IP. Voilà en gros comment cela marche. Donc, à part sur l'écran2 où à mon sens, il te faut cocher/activer tes deux règles nommées "reverse proxy", et ensuite sauf erreur de ma part, tout le reste me semble correct. Cordialement oracle7😉

@bliz Bonjour, Sauf erreur de ma part, le format iso est un fichier qui contient l'image d'un CD ou d'un DVD, non ? Arrêtes moi si je dis une co... ce n'est donc pas un format vidéo en tant que tel. Donc, cette image englobe, si je puis dire, des fichiers vidéos dont les formats sont propres aux mode d'enregistrement de ces films/séries qui y sont intégrés. Maintenant, très franchement je ne stocke pas de films/séries sous forme d'iso mais directement les fichiers vidéos (mpeg_x, ts, h264, h265, indeo, wmv, etc ...) dans des conteneurs très divers allant de l'AVI, au MKV, MPEG, FLV, Quictime, MP4, Ogg, etc ... Aussi je ne saurait te dire si KODI sait ouvrir un fichier iso pour le lire comme le fais un explorateur Windows par ex, je n'ai jamais essayé ! Sinon en ce qui concerne les formats que supporte KODI je te renvoie à son Wiki ici. Sans vouloir polémiquer sur ce point, je crois que KODI en supporte plus que PLEX mais peu importe ... voir ici pour PLEX si tu veux comparer. Le principal est et reste que les deux supportent les formats les plus courants. Cordialement oracle7😉

@Jeff777 Bonjour, J'en suis resté là moi aussi et idem pour le .htaccess. Cordialement oracle7

@kevfou Bonjour, Même si HA prend peu de puissance (à moins d'avoir des centaines de capteurs IOT), si c'était moi je partirai sur un second RPI dédié au multimédia. Personnellement, sur mes 4 RPI j'ai un RPI2 et un RPI3 et cela le fait très bien, ils sont juste un peu plus lents que mes deux autres RPI4 lors de la navigation parmi les films/séries mais ensuite en cours de lecture je n'ai aucun soucis, cà défile sans arrêts c'est parfaitement fluide. En plus scotchés à l'arrière des TV ils ne prennent pas de place ... Cordialement oracle7😉

@kevfou Oui, car le couple Libreelec+KODI est un ensemble OS+APP qui ne peut cohabiter avec HA. En plus il est préférable de séparer les genres : Domotique et Multimédia même s'il existe un addon Kodi pour HA. Mais vu le prix d'un RPI, tu peut bâtir une solution sur cette base (2 ème RPI) à un très faible coût. Et en plus tu connais déjà le RPI donc pas un soucis pour toi pour en gérer un second ... A toi de voir ... Cordialement oracle7😉

@kevfou Bonjour, A mon tour aussi de mettre mon grain de sel 😁, pour ton info, il y a aussi la solution de passer par KODI (c'est unique client "lourd" par rapport à Plex où il faut un Server ET un client) installé via la distribution Libreelec (voir ici aussi )sur un simple Raspberry 2, 3B, 3B+ et 4B au choix connecté en suite par HDMI à ta TV. J'ai personnellement 4 RPI (un / TV) qui attaquent une seule et même base de données centralisée de films, séries, photos, et musiques. KODI lit tous les formats de fichiers Vidéo/Audio et avantage : pas de transcodage à faire. Dans ce cas, ton NAS joue son rôle premier de serveur de données et pas plus. KODI lit les fichiers via le réseau local soit en SAMBA soit en NFS (ce qui est mieux à mon humble avis). A toi de voir ... Enfin, KODI associé à un outil tel que TinyMédiaManager te permettra avantageusement de gérer ta BdD de Films/Séries. Cordialement oracle7😉

@Vista1967 Bonjour, Juste autoriser les ports de DSM dans le pare-feu du routeur. OUI Oui il faut ajouter le port au domaine dans l'URL de connexion, mais ceci n'est valable UNIQUEMENT que pour les application Synology DSxxxx. Si tu veux atteindre par exemple une autre machine ou un autre service non Synology, ton URL n'est alors constituée que du domaine pas besoin de port car en HTTPS c'est le port 443 qui est sous-entendu et qui est mis de façon transparente pour toi par ton navigateur. Cordialement oracle7😉

@Vista1967 Bonjour, Désolé, je n'ai pas percuté mais dans Ecran5 dans l'onglet Applications du reverse proxy pour filestation et surveillance station, tu n'as pas renseigné le domaine : file.xxxx.synology.me et ip.xxxx.synology.me, du coup effectivement tu retombais sur DSM car dans DSM il y a un mécanisme automatique qui fait que si on appelle le NAS (par son @IP ou par un nom de domaine) sans préciser le port (80 si HTTP et 443 si HTTPS) ET que l’on n’a pas installé le package Web Station, alors on est automatiquement redirigé vers DSM du NAS (donc vers le port 5000 ou 5001 ou autres si modifiés). Sous DSM7, il faut en plus dans Portail de services Web > Modifier serveur par défaut et remplacer Nginx par Apache HTTP Server 2.4. SInon Apache HTTP serveur 2.4 est suffisant si pas de version 2.2. Ne confond pas Pare-feu et reverse proxy. Même avec le reverse proxy si tu ne donnes pas accès au NAS sur ses ports (5000 , 5001) dans le pare-feu, ce dernier bloquera le requêtes qui arrivent sur ces ports. En fait dans le TUTO de mémoire il est dit de créer un fichier ".htaccess" tout court ! pas avec l'extension .txt en plus (.htacces.txt). Essaies avec ce code à la place : RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Cordialement oracle7😉

@Vista1967 Bonjour, Ecran1 : Par soucis de clarté, je décomposerai ta règle de transmission de port nommée "reverse proxy" en deux. Une pour le port 443 et une pour le port 80 afin de bien les séparer. Ecran2 : Sur le principe, c'est bien car cela force à n'utiliser que le HTTPS, mais il faut savoir aussi que cela demande d'avoir un certificat valide .... Donc, le moindre problème lors du renouvellement de certificat, et ton HTTPS n'est plus accessible (le navigateur ne te propose pas de forcer le certificat). Du coup, le HSTS est une option pas du tout recommandée (voir le TUTO ReverseProxy) car c'est le navigateur qui enregistre cette information pour le site visité et il ne laissera plus passer autrement qu'en HTTPS, même si ce dernier est coupé (HSTS coché puis décoché). Si on veut forcer le https, il vaut mieux passer par le fichier .htaccess via web station comme indiqué dans le TUTO ReverseProxy. Donc pour un particulier, le HSTS est plus une source de problème qu'autre chose ... Seule solution pour supprimer l’information HSTS du navigateur, il faut vider le cache HSTS du navigateur, pour réaliser cela : Dans Chrome, taper chrome://net-internals/#hsts Entrer le nom de domaine dans le champ texte de la section "Delete domain security policies" Cliquer sur le bouton Delete Entrer le nom de domaine dans le champ texte de la section "Query HSTS" Cliquer sur le bouton Query La réponse doit être "Not found" (non trouvé) Avec Safari, commencer par fermer le navigateur Effacer le fichier ~/Library/Cookies/HSTS.plist Rouvrir Safari Avec Firefox, fermez tous les onglets Ouvrir le menu de Firefox et cliquer sur Historique / Afficher l’historique. Rechercher la page dont vous voulez supprimer les préférences HSTS Effectuer un clic droit sur une des entrées lui correspondant Choisir Oublier ce site Ecran3 : Il faut activer/cocher les deux règles de pare-feu pour l'interface de gestion des ports DSM. Ecrans4,5 : Tout semble OK. Ecran6 : La règle de ReverseProxy pour FileStation est redondante avec celle déjà existante pour FileStation dans l'onglet "Application". Supprimes donc la règle de ReverseProxy https file.xxxx.synology.me 443 ---> http localhost 7000, idem pour celle sur Surveillance Station https ip.xxxx.synology.me ---> http loc5alhost 12345. Ecran7 : Tout semble OK. Au final, sauf erreur de ma part ou un autre paramètre qui serait mal configuré, avec ce que tu montres cela devrait le faire. Mais si après ces corrections (ci-dessus), il y a toujours un problème avec tes domaines en local, il faut retourner vérifier la configuration de ton DNS Server. Cordialement oracle7😉

@Vista1967 Bonjour, Q1 : A partir du moment où tu as défini un DDNS sur le NAS, lorsque ton FAI change ton @IP externe, alors le DDNS du NAS le détecte et informe automatiquement les serveurs Synology.me pour qu'ils prennent en compte ta nouvelle @IP externe. Ainsi ton domaine xxxx.synology.me pointe toujours sur la bonne (et nouvelle) @IP externe. Ton DDNS fait exactement le même travail que le programme DUC de NO-IP. Q2 : Dans quel cas ? je crains que tu ne mélanges les notions. Le reverse proxy te permet d'atteindre depuis l'extérieur (mais aussi en local) de façon "protégée" des services sur ton NAS ou des machines sur ton réseau local, en utilisant un domaine spécifique et en passant par un port unique (en l'occurence le port 443 HTTPS). Ce qui offre l'avantage de ne pas avoir besoin d'ouvrir d'autres ports sur ta box/routeur et du coup ce qui sécurise quelque part tes accès. Q3 : Le wilcard sur ton domaine (i.e. *.xxxx.synology.me) te permet d'utiliser n'importe quel domaine de ton choix (i.e. du type xyz.xxxx.synology.me) sans avoir besoin de définir un enregistrement CNAME spécifique dans ta zone DNS. Bien entendu, il faut que tu précises cela dans le champ "Autre nom de l'objet" lorsque tu crées ton certificat Let'sEncrypt pour ton domaine xxxx.synology.me. Q4 : Oui tu peux rajouter la couche Adguard sans problème, cela complique un peu la configuration DNS mais cela marche très bien. Q5: Avec le reverse proxy plus besoin de faire une transmission de port comme tu l'indiques. Pour atteindre ton NAS par ex il suffit juste de faire une règle reverse proxy telle que : https monnas.xxxx.synology.me 443 ---> http localhost 5000 Cordialement oracle7😉

@coolman92 Bonjour, Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit, rassures-toi il n'est pas trop tard pour bien faire ... Regardes ce TUTO : RT2600ac en DMZ derrière Livebox4, tu y trouveras tout pour faire ce que tu souhaites ... Cordialement oracle7😉

@Vista1967 Bonjour, Dans le TUTO le sous-réseau 192.168.0.0:255.255.0.0 autorise 65534 @IP soit 65534 machines sur en gros 255 sous-réseaux (192.168.0.0 à 192.168.255.0). Donc vis à vis de ce sous-réseau 192.168.0.0 et par soucis de sécurité, je le restreint aux seuls sous-réseaux LAN utiles : celui de la box 192.168.1.0/24 et celui du RT 192.168.167.0/24. Voilà la différence mais tu peux laisser comme le TUTO, c'est toi qui voit ... De plus saches que : le sous-réseau 10.0.0.0/255.0.0.0 n'est utile que si tu utilises un VPN tel que openVPN. le sous-réseau 172.16.0.0/255.240.0.0 lui c'est pour si tu utilises docker. Donc éventuellement tu peux t'en passer si tu n'en as pas besoin. Le but est de limiter et en fait n'autoriser que les sous-réseaux nécessaires à ton besoin. Cordialement oracle7😉

@Vista1967 Bonjour, Bon bah on avance bien ! Cela me semble correct. Juste deux trucs : Dans DNS Server, la liste des IP sources dans les paramètres de la zone DNS est bien comme celle-ci ? Dans tes réservations DHCP sur le routeur RT, pour tes périphériques pour les quels tu veux qu'ils aient toujours la même @IP (donc fixe) tu ne dois avoir que des @IP en dehors de la plage automatique DHCP. C'est à dire donc dans ton cas @IP < 192.168.167.100 (pour mémoire ta plage DHCP auto est de 192.168.167.100 à 254). Sinon tu risques des conflits d'@IP et des problèmes de réseau. SAuf autre erreur (pas vue encore) il ne reste plus qu'à configurer des règles de reverse proxy. Voir le TUTO : Reverse Proxy. Exemple : Après tu devrais pouvoir utiliser en local un domaine du type srweb.xxxx.synology.me pour te connecter à lui. Cordialement oracle7😉

@Vista1967 Bonjour, Si tu veux bien, il ne faut pas superposer trente six choses à la fois, on essaie déjà de configurer correctement DNS Server pour que comme tu le souhaites, tu puisses utiliser un domaine pour tes connexions locales. Ensuite il sera temps de modifier pour ajouter une couche adguard ... Chaque chose en son temps, on y va étape par étape... OUI Il faut que tu ailles dans Centre réseau / Réseau local / Réservation DHCP et là tu crées/ajoutes une ligne avec l'@MAC, l'@IP locale (192.168.67.10 par ex) pour ton NAS et le nom d'hôte de ton NAS. C'est tout. Après cela, ton NAS aura une @IP locale fixe en dehors de la plage auto du DHCP. Pour résumer normalement tes @IP locales sont : Box telenet : 192.168.1.1 (passerelle) Routeur RT : 192.168.1.2 coté réseau local box et 192.168.167.1 coté réseau local LAN du RT NAS : 192.168.167.10 DNS server : 192.168.167.1 (idem que le RT) Autre périphériques : 192.168.167.xxx C'est bien cela ? Cordialement oracle7😉

@Vista1967 Bonjour, Désolé mais NON, les redirecteurs (@IP des serveurs DNS tiers) sont à saisir dans le package DNS Server ici : Ensuite sur le routeur RT tu indiques pour le DNS serveur l'@IP de ton routeur RT puisque c'est lui qui supporte ton DNS Server : Ensuite c'est OK pour ta copie d'écran n°2. Cordialement oracle7😉

@Vista1967 Bonjour, Pas de soucis, je t'explique : 1 - Sur ta box, tu définis une @IP locale fixe (via un bail DHCP) pour ton routeur RT à l'aide de son @MAC soit par exemple : Routeur RT = 192.168.1.2 (je suppose que le réseau local de ta box est en 192.168.1.0/24). A toi d'adapter selon ... 2 - Sur le routeur RT, tu vas dans Centre réseau / Réseau local / Réservation DHCP et tu réserves une @IP fixe pour ton NAS (toujours avec son @MAC) sur ton réseau local soit par exemple 192.168.167.10. 3 - Sur le NAS, pour l'interface réseau IPv4 tu coches DHCP automatique. Toujours sur le NAS, assures-toi que ton DDNS est du type xxxx.synology.me et qu'il pointe bien sur ton @IP externe (celle de ta box) et Normal. 4 - Tu redémarres proprement ton NAS pour qu'il prenne sa nouvelle @IP locale. 5 - Dans DNS Serveur sur le routeur RT, tu définis a minima les ressources suivantes : xxxx.synology.me. A 86400 192.168.167.10 ---> ton domaine qui pointe sur l'@IP de ton NAS support de ton DDNS puisque tu as une @IP externe dynamique *.xxxx.synology.me. CNAME 86400 xxxx.synology.me. ---> Le wilcard de ton domaine qui pointe sur ton domaine xxxx.synology.me. NS 86400 ns.xxxx.synology.me. ---> ton domaine qui pointe sur ton DNS Server ns.xxxx.synology.me. A 86400 192.168.167.1 ---> ton DNS serveur qui pointe sur ton RT qui le supporte 3 - On est bien d'accord que l'installation du package DNS Server avec sa zone DNS locale n'est faite que pour compenser le fait que ta box ne gère pas le loopback. Ainsi tu peux utiliser un domaine au lieu d'une @IP pour tes connexions en local comme tu le souhaites. 4 - Comme te l'a dit @.shad., pour les redirecteurs il faut mettre des serveurs DNS tiers de confiance tels que Cloudfare, FND, Quant, etc... car ce sont eux qui redirigeront les requêtes DNS que ton serveur DNS local ne saura réssoudre. Cela a aussi l'avantage de ne pas passer par les serveurs DNS (192.168.1.1) de ton FAI qui sont en général réputés "menteurs" et aussi "bloqueurs" pour certains sites. Cordialement oracle7😉

@RastaWelt Bonjour, Bienvenue à toi sur ce forum, tu verras c'est une mine d'informations. Cordialement oracle7😉

@TuringFan Bonjour, De mémoire je t'avais répondu sur ce point dans notre dernier échange en MP. Dans tous les cas, il n'y a pas à ma connaissance de procédure auto pour déployer le certificat sur les autres périphériques que le NAS. Il faut le faire manuellement tous les 3 mois ! Ce n'est pas une erreur, mais juste un "warning" qui est envoyé par le NAS lorsque l'image docker d'acme est mise à jour par watchtower. Il y a un arrêt puis un redémarrage du conteneur. Rien de plus. Juste bizarre, cela ne le fait pas avec mes autres conteneurs ... Cordialement oracle7😉

@Vista1967 Bonjour, Désolé mais NON ce n'est pas sur le NAS que l'on défini l'@IP du NAS pour qu'elle soit fixe mais sur ta box. Donc sur le NAS dans Réseau / Interface réseau / Ipv4 tu coches "Définir la configuration réseau automatiquement (DHCP)" Ensuite tu vas dans l'interface d'administration de ta box et là dans la partie réseau tu devrais avoir une partie DHCP. C'est normalement à ce niveau que tu peut définir un bail DHCP statique donc une @IP fixe pour ton NAS et ton routeur RT mais pour cela il te faut récupérer avant leurs @MAC (a1:b2:c3:d4:e5:f6). Tu définis alors les @IP que tu veux pour chacun d'eux soit par exemple respectivement 192.168.167.10 et 192.168.167.1 A titre d'exemple avec ma Livebox et une @IP fixe pour mon routeur, cela ressemble à ceci : Un fois les baux créés, tu redémarres ton NAS et ton routeur RT. Il te faut avant corriger pour l'@IP de NAS. Cordialement oracle7😉

@MilesTEG1 Bonjour, Oulala !!! Non tu as parfaitement compris et il a parfaitement raison, c'est moi qui me fourvoie avec le xxxx.no-ip.org qui est effectivement un cas spécifique. J'ai malheureusement réagi de façon générique et trop rapide ... 😪 mais qui reste vraie avec un ndd.tld "standard" ! Moralité, il lui faut abandonner ce no-ip.org de m... au profit d'un ndd en xxxx.synology.me ou d'un ndd.tld "privé" pris chez OVH par exemple ou ailleurs ... Cordialement oracle7😉

@Vista1967 Bonjour, ndd = nom de domaine .tld = top level domain Donc dans ton cas cela se traduit ainsi : ndd = xxxx.no-ip (xxxx = ce que tu as masqué !) tld = org Attention, dans la copie d'écran n°2, ton NAS semble toujours avoir l'@IP en 192.168.167.226. Tu ne l'as pas changé pour une @IP locale fixe comme préconisé précédemment ? Sinon dans tes ressources, pourquoi n'as tu pas défini un domaine wildard (*.xxxx.no-ip.org) ? Ainsi avec une simple et unique ligne du type : *.xxxx.no-ip.org. CNAME 86400 xxxx.no-ip.org. tu couvres TOUS les domaines (www.xxxx.no-ip.org, toto.xxxx.no-ip.org, titi.xxxx.no-ip.org, tutu.xxxx.no-ip.org, etc ...) que tu as besoin et/ou que tu pourrais créer à l'avenir sans avoir besoin de rajouter une ligne "CNAME" pour chacun d'eux dans tes ressources. Tu me suis ? Cordialement oracle7😉

@vaneck Bonjour, Accessoirement, cela vaut ce que cela vaut, mais il faut savoir que l'extension "Remote-SSH" ne s'active pas lorsqu'elle est installée sur vscode serveur installé sous docker (par exemple lscr.io/linuxserver/code-server). On obtient ceci : Il semble qu'il faille utiliser un VS Code installé autrement qu'en docker càd directement sous Linux ou Windows ou Mac. @MilesTEG1 Bonjour, Regardes ces liens : https://hub.docker.com/r/codercom/code-server https://hub.docker.com/r/linuxserver/code-server Mais il semblerait que cela ne vaille pas une bonne version desktop, à voir ... Cordialement oracle7😉

@Vista1967 Bonjour, Mes remarques : Ecran 1 : pour la 4ème ligne www.ndd.tld tu dois pointer sur ton domaine ndd.tld. et pas sur ton name server ns.ndd.tld. Ecran 2 : normalement la case serveur DNS préféré devrait être grisée (non accessible) et renseignée avec l'@IP de ton serveur DNS donc celle de ton routeur RT soit 192.168.167.1 @.Shad. a raison, tu devrais définir une @IP locale fixe pour ton NAS via un bail statique dans ta box. Cette @IP est à prendre en dehors de la plage d'adressagage automatique du DHCP soit par exemple 192.168.167.2 (soit 1 < @IP < 150) et pas 192.168.167.226. Si tu ne fais pas cela, lors d'un arrêt de ton NAS pour une quelconque raison le DHCP pourrait très bien donné l'@IP 192.168.167.226 à un nouveau périphérique qui démarrerrait sur ton réseau local, ce qui engendrerait un conflit d'@IP lors du démarrage ensuite de ton NAS. Donc pas bon du tout. C'est pour cela que l'on donne en général (bonne pratique) une @IP locale fixe aux périphériques importants qui soit en dehors de la plage auto du DHCP. Ecran 3 : OK Cordialement oracle7😉

@Vista1967 Bonjour, Sur quelle @IP as-tu installé le package DNS Server sur le routeur RT ? C'est quoi cette machine 192.168.167.226 ? ton PC local ou autre chose ? EDIT : Ok je n'avais pas vu ta réponse précédente pendant que je te répondais. Car dans tous les cas : l'@IP du serveur DNS déclarée dans la config Internet du routeur RT devrait être la même @IP que celle de ton routeur RT soit 192.168.167.1 C'est pareil dans la config Réseau local du routeur RT, pour le DNS principal tu dois indiquer l'@IP du routeur RT puisque c'est lui qui porte le DNS Server. tu me suis ? Une fois tout cela corrigé, si ta définition de ressources de ta zone DNS locale est conforma à l'exemple que je t'ai déjà tranmis précédemment, il ne devrait plus y avoir de problèmes et tu devrais pouvoir utiliser un nom de domaine pour tes connexions locales. Cela veut dire que tu doit avoir a minima dans celle-ci quatre enregistrements du type : ns.ndd.tld. A 86400 192.168.167.1 ---> ton DNS serveur qui pointe sur ton RT qui le supporte ndd.tld. NS 86400 ns.ndd.tld. ---> ton domaine qui pointe sur ton DNS Server *.ndd.tld. CNAME 86400 ndd.tld. ---> Le wilcard de ton domaine qui pointe sur ton domaine ndd.tld. A 86400 192.168.167.x ---> ton domainte qui pointe sur l'@IP de ton NAS support de ton DDNS puisque tu as une @IP externe dynamique Cordialement oracle7😉