Finnithnel
Membres-
Compteur de contenus
13 -
Inscription
-
Dernière visite
À propos de Finnithnel
Visiteurs récents du profil
Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.
Finnithnel's Achievements
-
[TUTO] Centralisation des instances Docker
Finnithnel a répondu à un(e) sujet de .Shad. dans Tutoriels
Je vais essayer d'apporter ma petite pierre à l'édifice Pour l'histoire du GIT, j'ai rencontré le même dilemme que MilesTEG1, à savoir que si on se sert de portainer pour héberger les serveurs, du coup on ne sait pas y héberger le GIT qui va héberger les config (inception @.@) Du coup, ma solution la moins invasive a été de me servir du serveur nginx (histoire de n'avoir quasi rien à installer) avec un git bare (je pourrai détailler si ça intéresse quelqu'un) J'ai installé portainer manuellement, et m'en suis servit pour initialiser une nouvelle instance sur le même emplacement (ce qui me permet de gérer tous les container avec portainer, lui inclus) Résultat au démarrage du serveur : - 1 script qui s'assure que le git bare est bien installé, configure nginx, et copie les compose des images - portainer qui démarre et initialise les stacks dans l'ordre - stack 1 : portainer, et un proxy pour le socket < à partir de là je peux lancer des nouveaux containers centralisés par portainer > - stack 2 : bind (dns authoritative) & adguard (dns cache + adblock) < à partir de là j'ai accès à internet et aux machines du réseau local par leurs noms de domaine > - stack 3 : acme.sh (pour les certifs) & traefik (reverse dns) < à partir de là j'ai accès à toutes mes machines et services à partir d'internet et du réseau local > A noter que dans l'histoire je me sers d'une astuce pour utiliser mes noms de domaine dans la première stack : networks: <nom du network>: ipv4_address: <adresse ip> aliases: - <nom de la machine.ndd> d'où l'intéret de créer une seconde image portainer par dessus la première -
[TUTO] Centralisation des instances Docker
Finnithnel a répondu à un(e) sujet de .Shad. dans Tutoriels
Nope Chez moi, j'ai en gros la structure suivante au niveau du NAS : /volume1/docker/commun <= répertoire qui contient toute la config commune aux stacks (/scripts, /certs, /repo.git, ...) /volume1/docker/stack1 <= répertoire qui contient toute le data de la stack (les volumes mapés dans docker) .... /volume1/docker/stack20 au démarrage de mon NAS, j'ai différents scripts qui se lancent (routes vers les macvlan, alias, drivers usb zigbee, customisation du ssh, création d'un repo git bare, relance temporisée de traefik...) dans portainer, j'ai créé des stacks fonctionnelles (dns, reverse proxy, databases, etc) qui contiennent n containers avec chacun leurs paramétrage spécifique, et variables d'environnement spécifiques mon soucis, c'est que j'ai des "variables" que je souhaite rendre communes à mes différentes stacks. par exemple, dans ma stack dns, je définis l'ip du serveur DNS local, et m'en sert ensuite pour chaque container de toutes les stacks (qui vont réutiliser cette ip) ou encore, dans mon reverse proxy (traefik), je définis des noms de routes et valeurs de ports que je réapplique dans pas mal de stacks le jour où j'ai envie de changer une valeur, plutôt que de me rééplucher les docker-compose de mes 20 containers, j'ai "juste" à modifier une variable d'environnement (celles de portainer, pas celles des container) et je sais que mes compose seront toujours bons le hic, c'est que ça m'impose de mettre à jour les variables de chaque stacks (les stack.env de portainer) manuellement et comme tout bon informaticien qui se respecte, je suis une grosse faignasse, donc je cherche à automatiser la chose 😄 pour le moment je passe par des scripts qui vont répliquer et remplacer les stack.env de chaque folder dans portainer, mais c'est un poil crade, et pas très pratique à maintenir j'ai remarqué que quand les stacks sont descendues d'un repository git (local dans mon cas), portainer importe tout ce qu'il trouve dans le chemin, pas juste le compose.yml donc dans mon cas, les folder git contenant et le compose et le .env, portainer descend les 2 fichiers, mais il ignore royalement le .env, et s'obstine à le recréer à la racine de sa stack en docker-compose on peut simplement référencer des env_file dans les services, ce qui est un début mais déjà trop bas pour moi (j'aimerais en bénéficier au top-level du compose) mais j'ai l'impression que si portainer repère et importe le .env, c'est qu'il y a moyen de le lui faire utiliser je ne sais juste pas trop comment (règle de nommage ? conf quelque part ?) -
[TUTO] Centralisation des instances Docker
Finnithnel a répondu à un(e) sujet de .Shad. dans Tutoriels
Hello, De mon côté je m'interrogeais sur la manière dont vous vous y preniez pour gérer les variables d'environnement J'ai une bonne vingtaine de containers, que j'ai cloisonnés par stacks fonctionnelles Mais j'ai pas mal de "variables" que je réutilise dans mes différents docker-compose, et je trouve ça ultra pénible de devoir me coltiner d'éditer toutes les stacks quand je souhaite modifier quelques variables d'environnement (exemple, l'IP du serveur DNS local, ou encore le port du socket proxy pour docker, ou même des ports pour traefik) De plus, regrouper tous les docker-compose sur une seule stack ne me satisfait pas non plus puisque modifier une seule variable d'environnement relancerait la totalité des containers J'ai constaté que quand on était rattaché à un repository git (j'en ai créé un --bare sur le NAS, pour rester en local sans avoir besoin d'installer autre chose que GIT, en servant les fichiers avec nginx déjà présent sur DSM), portainer copiait également les fichiers .env dans les stacks qu'il crée, mais pas moyen des les référencer ensuite (sans compter les limitations inhérentes à docker sait gérer -au mieux- des env_file qu'au niveau des services (donc adios les variables aux top-levels) J'ai l'impression qu'il faudrait que je rebascule sur des scripts pour le déploiement et ne garder portainer que pour les GUI permettant de debug/monitoring et autre, ce qui réduit considérablement son intérêt Peut-être que de manipuler dynamiquement les yml en injectant les variables avant de les envoyer sur le repo permettrait de contourner le problème, mais je trouve ça assez sale, et pas très sécure Des idées ? ^^ -
D'autres appareils le font Pour ma part, j'utilise pas mal d'appareils Netgear, et la plupart m'envoient bouler si je passe par un reverse proxy - Switch GS724Tv4 => 403 forbidden sur toutes les ressources - Switch GS108Tv2 => même combat - Point d'accès sans fil WAX214 => même combat Par contre, contre intuitivement : - Switch GS108PE => ça marche - Switch GS116E => ça marche - Orbi RBR850 => ça marche - Orbi RBS850 => ça marche De ce que j'ai vu des logs (pour ceux auxquels j'ai pu accéder), c'est implémenté en interne dans la couche logicielle du noyau linux de leur firmware : s'ils détectent une connexion qui ne leur plait pas, ils la referment aussitôt (nom dns qui ne correspond pas à leurs attentes, comme la bbox bouygues qui va try hard pour rediriger sur son nom dns même si tu tapes son ip, ou détection que la connexion est initialement émise depuis internet pour le point d'accès, ou encore parce que la connexion vient du reverse proxy alors qu'elle est initiée par une ip différente dans le cas des switch)
-
Hello, je souhaitais savoir si l'un de vous avait expérimenté des problèmes avec la combo DNS Server + Reverse Proxy ? Pour ma part, après avoir tout configuré, tout fonctionne presque parfaitement en dehors d'un détail : lorsque je reboot le NAS, tous les entrées de reverse proxy associées à des alias définis dans le server DNS tombent Il suffit alors de modifier/ajouter/supprimer une entrée au reverse proxy pour qu'il utilise de nouveau les alias du serveur DNS Je me demande si c'est un problème de cache/réglage raté quelque part dans le serveur DNS J'ai vu que pas mal d'entre vous utilisaient ce genre de combo, donc je m'explique mal pourquoi je constate ce bug chez moi (sur 2 NAS différents j'ai le même problème)
-
Configuration d'un serveur DNS
Finnithnel a répondu à un(e) sujet de Finnithnel dans Installation, Démarrage et Configuration
Oui, je l'ai réalisé en tombant au hasard sur le journal du serveur DNS du synology De manière totalement contre intuitive, la configuration mise en place était acceptée... mais pas effective ! En fait le serveur NAS indiquait dans ses logs que les NS étaient définis par des CNAME ce qu'il jugeait illégal, du coup il appliquait la dernière configuration jugée "valide" tout en laissant en apparent mes settings qu'il jugeait "invalides" En rebasculant sur des IP fixes, avec des A, ça refonctionne Mais ça ne résoud pas mon problème puisque je me retrouve à devoir définir sur mon registrar les IP fixes de mes 2 NAS, et à devoir les redéfinir sur chaque vue publiques de mes NAS maîtres (soit au minimum 4 fois par IP, et dans 3 interfaces différentes, la grosse loose si je dois les éditer à chaque changement...) J'ai étudié la proposition de @.shad. consistant à utiliser Cloudfare comme proxy DNS Ca a l'avantage de me permettre d'utiliser leur API pour mettre à jour les IP fixes... ça résout donc le problème sur 1 des 4 configurations, mais ça pose la contrainte de devoir désactiver DNSSEC que je comptais mettre en place une fois tout le bouzin fonctionnel et ça ne résoud pas l'impossibilité d'avoir recours à des CNAME sur les serveurs DNS des 2 NAS synology y'a aucun autre moyen ? J'avoue être assez septique sur le fait d'avoir été le seul zozo à avoir eu l'envie de déléguer des sous domaines à coup de noms canoniques au lieu d'IP plus ou moins fixes -
Configuration d'un serveur DNS
Finnithnel a répondu à un(e) sujet de Finnithnel dans Installation, Démarrage et Configuration
Mon problème c'est que d'une part, cela ne semble pas fonctionner, et d'autre part j'ai trouvé assez peu d'exemples liés à cet approche sur le net, le peu que j'ai trouvé semblant au contraire m'indiquer que c'est une idée vouée à l'échec : https://blog.mikejmcguire.com/2014/06/06/dns-delegation-intermittently-failing-due-to-cname-based-ns-records/ Pour le moment, dans mon interface LWS, j'ai définis ces règles (je ne garde que les plus appropriées) : Type / Nom / Valeur NS / @ / ns1.lwsdns.com NS / @ / ns2.lwsdns.com A / @ / W.X.Y.Z CNAME / www / @ NS / m1 / ns1.m1.ndd.tld NS / m1 / ns2.m1.ndd.tld CNAME / ns1.m1 / nas1.synology.me. CNAME / ns2.m1 / nas2.synology.me Sur le NAS1, fichier zone.conf : [m1.ndd.tld] host_name="ns1.m1.ndd.tld." allow-update-key="" type="master" allow-transfer="" notify_enable="no" allow-query="" allow-query-subnet="" also-notify="" allow-query-ip="" domain_type="forward" limit_update="yes" forward="" zonename="m1.ndd.tld" slavekey="" allow-transfer-ip="" allow-update="" also-notify-ip-raw="" enable_tsig="no" allow-transfer-subnet="" forwarders="" enable_auto_update_iface_ip="no" allow-transfer-key="" allow-update-subnet="" allow-update-ip="" zone_enable="yes" domain="m1.ndd.tld" serial_format="date" org_mail="m1@ndd.tld." masters="" host_mail="m1.ndd.tld." listen-interfaces="" limit_transfer="no" limit_query="no" Sur le NAS1, fichier m1.ndd.tld : $ORIGIN m1.ndd.tld. $TTL 86400 m1.ndd.tld. IN SOA ns1.m1.ndd.tld. m1.ndd.tld. ( 2021101502 43200 180 1209600 10800 ) m1.ndd.tld. 600 A A.B.C.D m1.ndd.tld. 600 NS ns1.m1.ndd.tld. ns1.m1.ndd.tld. 600 A A.B.C.D *.m1.ndd.tld. 600 CNAME m1.ndd.tld. Avec A.B.C.D : IP publique du NAS1 / BOX de la M1 et W.X.Y.Z : IP publique du serveur chez LWS -
Configuration d'un serveur DNS
Finnithnel a posté un sujet dans Installation, Démarrage et Configuration
Bonjour, Voici l'architecture que je souhaite mettre en place avec les explications qui vont bien juste dessous Je dispose donc : - d'un nom de domaine public, ndd.tld , acheté chez LWS qui me met du coup également à disposition une interface pour configurer la partie DNS de ce domaine - d'un accès admin aux réseaux de 3 maisons distinctes (M1, M2 et M3), dans lesquels on retrouve : M1 : box adresse publique 217.1.1.1 adresse privée 192.168.1.254 DMZ sur le routeur routeur adresse dans la DMZ : 192.168.1.253 adresse dans le réseau privé : 192.168.11.253 serveur DHCP NAS1 (DS1819+) adresse 192.168.11.250 DDNS : nas1.synology.me serveur DNS serveur de fichiers reverse proxy périphérique lambda adresse 192.168.11.X M2 : box adresse publique 217.2.2.2 adresse privée 192.168.22.254 NAS2 (DS1819+) adresse 192.168.22.250 DDNS : nas2.synology.me serveur DHCP serveur DNS serveur de fichiers reverse proxy périphérique lambda adresse 192.168.22.X M3 : box adresse publique 217.3.3.3 adresse privée 192.168.33.254 serveur DHCP serveur DNS périphérique lambda adresse 192.168.33.X Mon souhait (si on oublie les caches DNS pour simplifier les explications bien évidemment) : - une requête de type *.ndd.tld doit arriver sur le serveur DNS de LWS, puis : une requête de type *.m1.ndd.ltd doit être redirigée sur le serveur DNS du NAS1 (NAS2 fait office de slave pour ce sous domaine) une requête de type *.m2.ndd.ltd doit être redirigée sur le serveur DNS du NAS2 (NAS1 fait office de slave pour ce sous domaine) une requête de type *.m3.ndd.ltd doit être redirigée sur le serveur DNS du NAS1 (NAS2 fait office de slave pour ce sous domaine) les autres requêtes ne doivent pas être redirigées, et donc afficher la page ndd.tld - je ne veux pas retrouver les IP publiques de mes BOX/NAS dans l'interface LWS : elles ont vocation à changer régulièrement, et le DDNS des NAS permet d'avoir une IP dynamique associée à un nom DNS fixe (nas1.synology.me et nas2.synology.me) <= est-il possible avec les services DDNS des box d'assigner directement mes noms de domaine public à ces IP (style m1.ndd.tld et m2.ndd.tld) ? -
J'en ai un, je vais arrêter de faire le schema par informatique et en faire un rapidement à la main, le temps de lancer le sujet, puis remettrai ça au propre chose dite, chossette :
-
Si, bien sûr, mais c'est l'utilisation du DDNS dans la définition de mon DNS qui pose problème Tous les tutos relatifs à la délégation de DNS indiquent sommairement qu'il faut spécifier 2 serveurs DNS avec l'option "NS" (pour avoir un fallback), mais aussi qu'il faut spécifier l'IP de ces DNS avec l'option "A", pour que le DNS sur lequel arrive la requête initiale sache vers quelle IP rediriger Je suppose que de ne pas spécifier du tout de "A" et utiliser un "CNAME" à la place (pour faire référence à mon DDNS au lieu de mon IP fixe) n'est pas la bonne approche (que ce soit dans la configuration du DNS qui délègue ou de celui qui prend en charge la délégation) Techniquement tu as entièrement raison, mais comme concrètement chacun de mes NAS se trouve derrière une BOX différente, ils sont chacun accessibles par une IP publique différente J'essayais de simplifier le modèle, puisque concrètement chacun de mes NAS est situé derrière un routeur qui est dans la DMZ d'une BOX différente C'est déjà le cas, chaque NAS dispose d'un DDNS(ceux que dans ma question initiale, visiblement mal tournée ^^, j'appelais M1.synology.me et M2.synology.me) Justement c'est ce que je ne veux pas En suivant le tuto, toujours en simplifiant, on en revient à dire, quand on se connecte au DNS publique : hey moi je ne m'occupe pas de ce domaine, va chercher bonheur sur le NAS du monsieur Moi ce que je souhaite c'est que le serveur DNS "racine" (celui du fournisseur du domaine), on renvoie sur un serveur DNS différent suivant le sous domaine demandé, autrement dit avant même d'arriver sur un des 2 NAS, je souhaite déjà choisir le NAS qui va traiter la demande, en fonction du sous domaine demandé Ensuite chaque NAS devra gérer son sous domaine (avec des sous-sous domaines gérés par les CNAME) Et comme tu l'indique toi même, tu associes un enregistrement NS à un enregistrement de type A avec une IP, là ou moi j'aimerais idéalement avoir un enregistrement NS couplé avec un type CNAME, mais j'ignore si c'est faisable, à défaut de litérrature sur le sujet J'ouvre le nouveau topic dès que j'ai terminé mon schema, je pense que ça sera plus clair que mes explications
-
Désolé pour la présentation, j'avoue que je lis ce forum depuis tellement longtemps maintenant que j'ai l'impression de connaître pas mal de monde, mais la réciproque est on ne peut plus fausse, j'ai donc rectifié le tir ! J'ai déjà installé le DNS sur un seul NAS, et m'en servais jusqu'à présent pour gérer le réseau local à priori avec succès, c'est vraiment le passage au "publique" qui me pose problème (le côté VPN je m'y intéresserai à des fins d'optimisation dans un second temps) Je suis conscient que je simplifierais les choses à utiliser des IP fixes, mais j'ai déjà changé 4 fois d'IP en 3 mois, et ne me vois pas trop faire ce genre de maintenance à long terme : c'est rébarbatif, inintéressant, et je m'imagine bien découvrir une fois à distance de chez moi que j'ai oublié de mettre à jour les IP après leur dernier changement, ce qui rendrait tout mes services innaccessibles tant que je ne rectifie pas le tir... mon but final c'est les 2 questions de la fin de mon long post : - avoir plusieurs subdomains gérés par des serveurs DNS différents, dont les adresses soient dynamiques (DDNS) et donc définis par leur DNS ( CNAME ) au lieu de leur IP ( A ) ? - faire en sorte que le serveur DNS situé dans le VPN contacté soit utilisé par défaut, plutôt que celui dans la zone de départ sans avoir à customiser la connexion VPN ok, je vais essayer de faire quelques schémas visuels pour mieux expliquer vu que ça n'a pas l'air compréhensible, et je ferai un sujet dédié
-
Bonjour à tous, J'ai 40 ans, et baigne dans l'informatique depuis une trentaine d'années J'en fais au quotidien de par mon métier d'ingénieur, mais également dans mes loisirs : très geek, j'ai eu jusqu'une quinzaine d'ordi à la maison, ce qui implique d'acquérir des connaissances basiques en maintenance aussi bien hardware que software (je me qualifierais donc de moyen à expert suivant les nombreux domaines de l'informatique) Il y a environ 3 ans j'ai commencé à m'intéresser aux architectures Home Office, et ai investi dans un NAS Synology DSM 1819+ (avec 8 HDD bien gras), puis un switch Netgear GS724T, un routeur ORBI RBR 850, et m'initie tant bien que mal aux différentes possibilités qui s'ouvrent maintenant à moi (VPN, reverse proxy, firewall, DNS, DHCP, etc, je n'ai pas assez de temps pour "jouer" à tout 😞 ) A noter que j'ai également "convaincu" mes parents d'installer un NAS chez eux (également un DSM 1819+) dont je me sert pour sauvegarder leurs données, et répliquer le mien Niveau services, je me sers donc du serveur DHCP, des différents services de synchro (rsync, Synology Drive ShareSync, Hyper backup, Cloud Sync), File Station, WebDAV, Docker (pour VaultWarden), Reverse Proxy
-
Bonjour, Je m'incruste dans ce topic avec mes gros sabots car je patauge un peu dans les différentes notions et bloque sans trop réussir à comprendre ce que je fais mal Pour commencer, ma situation : - J'ai acheté un nom de domaine publique, et bénéficie par la même occasion d'un serveur DNS (chez LWS) publique - Je gère 3 maisons qu'on appellera M1 (la mienne), M2 (mes parents), M3 (frangin) - Je gère 2 NAS : NAS1 dans M1, et NAS2 dans M2 - sur chaque NAS? l'ip dynamique est attribuée à un dns synology.me Ce que je souhaite mettre en place c'est donc : - que ndd.tld renvoie uniquement sur le DNS public chez LWS (en gros, serve à récupérer toutes les requêtes DNS envoyées au mauvais endroit) - que le sous domaine m1.ndd.tld soit délégué au serveur DNS installé sur le NAS 1, et que le serveur DNS du NAS2 serve de backup (donc toutes les requêtes type *.m1.ndd.tld soient gérées par le NAS1 en prio (sinon NAS2), et acheminées sur l'ip publique de la M1 avant d'être rerootées par le reverse proxy) - inversement, que m2.ndd.tld soit délégué au serveur DNS installé sur le NAS2, et que le serveur DNS du NAS1 serve de backup (requêtes *.m2.ndd.tld gérées par NAS2, et acheminées sur l'ip publique de M2) - que m3.ndd.tld soit géré par NAS1 puis NAS2 sur le même principe d'après ce que je comprends, je dois donc me retrouver avec : - NAS publique : A @ ip_LWS NS @ DNS_LWS NS m1 ns.m1.ndd.tld NS m1 ns.m2.ndd.tld CNAME m1 m1.synology.me <= mis à jour automatiquement par le NAS1 NS m2 ns.m2.ndd.tld NS m2 ns.m1.ndd.tld CNAME m2 m2.synology.me <= mis à jour automatiquement par le NAS2 - NAS 1 : 1 zone master : m1.ndd.tld NS ns.m1.ndd.ltd ns.m1.ndd.tld CNAME m1.synology.me *.m1.ndd.ltd CNAME m1.ndd.ltd périph1.m1.ndd.tld A 192.168.1.1 ... 1 zone slave qui importe la zone master de NAS2 - NAS 2 : 1 zone master : m2.ndd.tld NS ns.m2.ndd.ltd ns.m2.ndd.tld CNAME m2.synology.me *.m2.ndd.ltd CNAME m2.ndd.ltd périph1.m2.ndd.tld A 192.168.2.1 ... 1 zone slave qui importe la zone master de NAS1 pour la M3, je suppose que je n'ai qu'à reprendre le principe de la zone master de M1, à la différence que je n'aurai qu'une vue (celle pour l'extérieur) Pour gérer l'aspect connexion locale, VPN et internet, je suppose que j'ai ensuite à dupliquer les différentes zones en me contentant de modifier les IP et les remplacer par des IP cohérentes (publiques pour celle utilisée par la vue publique, IP VPN pour la vue VPN, et ip locales pour la vue locale) Mes 2 problèmes sont les suivants (au delà du fait que ça ne marche pas encore, j'imagine que j'ai mal renseigné certains paramètres ^^) - dans beaucoup de tutos expliquant comment mettre en place un serveur DNS (y compris celui ci) on utilise des entrées de type A pour définir le naked domain et le ns délégué. Est-ce qu'il est possible d'utiliser un cname à la place (pour utiliser l'ip dynamique renseignée par le NAS, au lieu de devoir éditer manuellement les IP partout à chaque fois que j'en change) ? J'ai l'impression que c'est la cause de la plupart de mes échecs, mais ça me parait vraiment pas pratique si on ne peut pas faire comme ca - comment faire en sorte qu'une machine située sur le réseau M1 se connectant via VPN au réseau M2 se serve bien du serveur DNS situé sur le NAS2 pour résoudre les noms, plutôt que de passer par internet (et donc utiliser les ip publiques) ?