.Shad.

Lecture & écriture sur le dossier qui contient les ebooks et la bdd Calibre.

Ne confond pas les DNS qu'utilise le routeur lui-même, et ceux qu'il dit à ses clients d'utiliser. C'est une préférence personnelle, tu fais comme tu veux, moi je sais que j'aime bien que mon routeur utilise des DNS upstream publiques. Rien ne t'y oblige. Les clients, eux, utiliseront le serveur DNS que le serveur DHCP leur dit d'utiliser, à savoir 192.168.167.1 => le routeur. Mais il faut comprendre ce qui se passe => Tu dis à tes clients d'utiliser 192.168.167.1 comme serveur DNS, donc tes clients s'exécutent. Ils arrivent sur la zone DNS locale que tu as configuré, qui réécrit les chemins relatifs à xxx.no-ip.org. C'est ça qui te permet d'utiliser un même nom de domaine localement et à distance, sans compter sur le loopback éventuel du routeur. Si la requête concerne nas-forum.com, ta zone DNS locale ne fait pas autorité pour répondre, elle doit donc transmettre la requête à un serveur plus à même de répondre. C'est la fonction des redirecteurs, dans un des menus de DNS Server. Ces IP sont interrogées pour tout ce qui n'est pas résolu dans les zones que tu as créées. Le DNS est peut-être le sujet qui demande le plus de temps, d'habitude et de lecture parmi les sujets abordés régulièrement sur ce forum. Ce n'est pas anormal que tu sois un peu perdu. Je ne sais pas si c'est judicieux de changer déjà de nom de domaine et de t'embrouiller avec la notion de wildcard, etc... Je ne suis pas forcément en accord avec les autres intervenants, donc je les laisserai réagir au besoin à tes questions. 🙂

Pour moi ça c'est ok, j'aurais aussi fait un enregistrement A pour la racine : xxx.no-ip.org A 192.168.167.1 Concernant ça : J'aurais évité de mettre 192.168.167.1 comme serveur DNS. Ici, il est question du serveur DNS que le routeur utilise, si le paquet DNS serveur déconne il fera rien. De plus j'espère que tu as reconfiguré des redirecteurs pour les requêtes non résolues par tes zones, donc a priori tout ce qui n'est pas en xxx.no-ip.org. Ces redirecteurs doivent être publiques, tu peux utiliser ceux de la FDN => 80.67.169.12 et/ou 80.67.169.40 Préférence personnelle, je préfère toujours que ma passerelle (le routeur ici) ne fasse pas appel au serveur DNS local, il n'en a pas besoin. Donc je remplirais ainsi : DNS Server 192.168.1.1 Par défaut, le routeur utilise les DNS de la box opérateur SAUF si tu configures manuellement DNS Server : Serveur DNS préféré 80.67.169.12 Serveur DNS de remplacement 9.9.9.9 Dans les faits ton routeur utilisera le serveur FDN primaire, et si FDN est down, tu pars sur Quad9. Utiliser 226 n'est pas un problème en soi, l'ennui c'est que 226 est dans la plage DHCP de ton routeur, plage que je trouve énorme au demeurant, 100 à 254 c'est vraiment conséquent. Pour info ma plage DHCP de mon réseau LAN principal va de 2 à 49. Au-delà, je trie les types de périphériques par dizaines ou vingtaines : Vu que tu as défini l'IP dans le NAS, et que l'IP n'est pas réservée sur le routeur, rien n'empêche le serveur DHCP de celui-ci d'attribué l'IP 226 à un périphérique qui fait la demande d'une IP. Tu essaies de te connecter à quoi déjà ? DSM ? Sur ton PC, si tu tapes : nslookup xxx.no-ip.org dans une invite de commandes, quel est le résultat ?

Je te dirai demain en MP 🙂

Excellente initiative !

Gênant, pas vraiment, idéal, non plus. Est-ce que le groupe users a des droits suffisants sur ce dossier ?

On peut regarder à l'occasion via Teamviewer, là comme ça je ne vois pas...

@Vista1967 J'aurais évité de placer le NAS (226) dans la plage du serveur DHCP (100 à 254). Ton OpenVPN il pointe vers quelle adresse ? une en no-ip ?

Bienvenue parmi nous !

Merci pour ta contribution tout au long de ces années, 4 ans que je suis là et tes interventions sont toujours dans le respect de l'interlocuteur, c'est aussi ce qui fait de ce forum un lieu où il fait bon lire.

No-IP c'est très bien, suivant le cas d'emploi. Et No-IP propose des ndd avec certificats SSL au besoin (19$/an, c'est pas très cher pour une solution clé en main). Sans certificat, c'est parfaitement adapté pour des sites sur des ports non sécurisés, ou pour une seedbox par exemple, etc... Pour le reste, tu ne sais pas définir des sous-domaines de ton ndd xxxx.noip.tld, tu n'as aucun contrôle sur la zone DNS publique, donc avec un proxy inversé sur port 443, ben tu es vite limité. Une solution est de passer par des subfolders au lieu de subdomains, car le FQDN ne change pas, tu peux avoir par exemple https://xxx.noip.tld/nextcloud,https://xxx.noip.tld/adguard, etc... Mais vu la facilité d'obtenir un certificat LE, il est préférable d'utiliser le NDD Synology ou d'acheter son propre NDD pour quasi rien par an.

Une réécriture DNS ne gère pas les ports. Et tu ne peux pas spécifier des ports pour rediriger vers des services différents. Il te faut un proxy inversé pour cela, mais ça ne sera pas faisable avec un nom de domaine no-ip. Il te faut un nom de domaine personnel ou utiliser celui fourni par Synology qui fonctionne très bien.

Essaie de ne pas définir d'adresse MAC dans le montage d'interface virtuelle de ton premier NAS.

Bienvenue!

J'espère que tes données sont sauvegardées, ton NAS a déjà un petit âge et fait partie de la série maudite. Probable que ça ne dure pas indéfiniment.

Bienvenue parmi nous

Ton script ressemble à quoi ?

La bonne pratique c'est que chaque réseau macvlan sur chaque périphérique ait une plage d'IP unique et non partagée. Rien n'empêche de faire ce que tu as fait, tant que tu vérifies que l'IP attribuée à un conteneur est unique sur ton réseau. En définissant des plages différentes tu préviens la duplication d'IP. Autre question, je vois que tu mets 192.168.1.167 dans REV_SERVER_TARGET, cette IP correspond à quoi ? Je m'attends à voir l'IP de la passerelle OU l'IP d'un des deux NAS, vu que de souvenir tes deux NAS hébergent une zone locale (maître et esclave) OU rien du tout si Pi-Hole devient ton serveur DNS local. De prime abord je dirais que 192.168.1.167 c'est l'IP d'un conteneur en macvlan, mais lequel... ? Relire peut-être le point 5-C-2.

Welcome !

Salut et bienvenue, crée un fil à part pour ton problème.

C'est moi ou c'est dans Komga cette erreur ? Je ne connais pas l'application désolé, je suis tombé sur ça, j'imagine que toi aussi : https://www.authelia.com/integration/openid-connect/komga/ En dernier recours, tu peux toujours aller sur le Discord d'Authelia, les gars sont très dispos, ils m'ont bien dépanné à l'époque.

Mon Pi-hole sur le NAS fonctionne bien avec les variables d'UID et GID. Pour celui sur Debian le problème se pose moins car on est moins embêté avec les permissions. Cool si ça fonctionne bien en l'état alors, tu as utilisé les variables d'UID et GID comme précisé dans ce message ?

Pour l'erreur 1, est-ce que tu as testé de mettre le hmac_secret dans un fichier aux droits d'accès limités comme pour les autres clés ? - AUTHELIA_IDENTITY_PROVIDERS_OIDC_HMAC_SECRET_FILE=/config/secrets/oidc Pour les secrets c'est ici : https://www.authelia.com/configuration/methods/secrets/ Et du coup ne rien mettre en regard de hmac_secret dans le fichier de configuration ? le message laisse supposer que tu l'as défini aux deux endroits. Erreur 2, a priori le hmac_secret est bien importé, mais comment savoir dans quel ordre les données sont traitées, l'erreur 1 aurait peut-être pu surgir juste après.

Bienvenue !

Welcome back alors !