Classement

Edition du 11/01/2023 : Veillez noter que ce fil à été créé il y a 5 ans. Certains chapitres sont maintenant obsolètes, notamment la partie concernant le certificat qui accepte le wildcard ce qui simplifie grandement sa mise en oeuvre. Les images ne sont plus accessibles car l'hébergeur a fermé ses portes. Ce descriptif étant ancien et quelque peu dépassé, je les mettrai à jour seulement si quelqu'un m'en fait la demande. J'ai conservé l'hébergement de ma zone publique à titre de test pendant quelque temps. Aujourd'hui cet hébergement est à nouveau chez OVH. Pour info, lors du rapatriement de ma zone chez OVH, je n'ai pas réussi à supprimer l'enregistrement GLUE à partir de mon interface client. Il a fallu pour cela que je contacte OVH. Mic13710 ________________________________________ Après quelques semaines d’utilisation, je viens vous faire part de ma petite expérience pour la mise en place de mon serveur DNS et de ce qui en a découlé. Tout d'abord je remercie Fenrir pour cet excellent tuto, et aussi (et surtout) pour son assistance lors de sa mise en oeuvre sans laquelle j'aurais sûrement abandonné. Il lui aura fallu beaucoup de patience et de bienveillance pour supporter un boulet tel que moi. Il est vrai que le sujet n'est pas des plus faciles quand on n'est pas de la partie. C'est mon cas. Bref, j'ai voulu aller au bout de la démarche. Possédant un nom de domaine chez OVH et une IP fixe (Free), j'avais les ingrédients nécessaires pour me lancer dans l'aventure. Mon objectif était de : pouvoir utiliser les mêmes url côté WAN et côté LAN, héberger mon propre serveur DNS, par la suite pouvoir m'affranchir des contraintes de ports en utilisant le reverse proxy qui est dispo en natif sur nos NAS depuis DSM 6.0. Il ne me restait plus qu'à trouver le courage et le temps, puis je me suis lancé. Je ne vais pas m'étendre sur la zone DNS locale qui est largement documentée sur le tuto (mais j'y reviendrai plus loin) pour passer sur la partie publique. L'idée étant de tester le tuto jusqu'au bout, j'ai opté pour la troisième possibilité : Être à la fois serveur SOA et NS c'est à dire le point 2 de mon objectif. Tant qu'à être dans la mouise, autant s'y mettre carrément. Mon compte chez OVH étant très basique (juste le nom de domaine) je n’ai pas la possibilité de créer un DNS secondaire. Et comme je n'ai pas non plus la possibilité de l'héberger ailleurs, c'est Fenrir qui m’a permis d'utiliser temporairement son domaine, le temps de la mise en place de mon serveur. Merci à lui. Après quelques errements sur des problèmes de NS, A et CNAME qui bloquaient le processus (Fenrir saura de quoi je parle), j’ai enfin réussi à passer le test Zonemaster pour nos deux serveurs DNS. Ne restait plus qu’à officialiser ces serveurs pour les faire connaître au monde entier. Pour ceux qui sont chez OVH, il suffit d’aller dans l’onglet Serveurs DNS du domaine, de cliquer sur "Ajouter un serveur DNS", de rentrer l’adresse du serveur principal (c’est l’adresse de l’enregistrement NS de la zone publique), d’indiquer son IP publique fixe puis de valider. Faire de même pour le serveur DNS secondaire. La procédure devrait être similaire chez les autres fournisseurs. Personnellement, j’ai rencontré un problème pour la mise en place du serveur de Fenrir. En effet, je n’ai pas pu faire l’enregistrement avec le nom du DNS et son adresse IP, chaque tentative se soldant par un échec. Il m’a fallu faire l’enregistrement en utilisant uniquement le DNS (sans l’adresse IP) et là c’est passé. Je n'ai pas compris pourquoi, mais si ça vous arrive vous pouvez essayer de faire de même. Enfin, j’ai fait un enregistrement GLUE de mon serveur DNS pour qu’il soit diffusé all over the world. Chez OVH, onglet GLUE, bouton "DNS Ajouter". On renseigne les informations du DNS principal (les mêmes que précédemment) et on valide. Une fois les serveurs DNS actifs, je n’avais plus besoin ni des enregistrements de zone que j’avais créé chez OVH ni des serveurs DNS d’OVH. Pour ces derniers, il m’a suffi de les supprimer dans l’onglet DNS (dans mon cas, il s’agissait de ns200.anycast.me et dns200.anycast.me). J’ai tout de même conservé les enregistrements de zone (juste au cas où j’aurais besoin de revenir en arrière ). Mes enregistrements Serveurs DNS ressemblent maintenant à ça : Pour info : puisque j’ai gardé mes anciens enregistrements, j’ai aussi un message dans la page Zone DNS qui m’informe gentiment que j'utilise les serveurs DNS que je viens d’activer (c’est rassurant) et que la zone que j’ai conservée n'est utilisable que si j’active les serveurs DNS d’OVH. A noter que la mise en place définitive des serveurs est quasi immédiate chez OVH mais peut prendre quelques jours pour être diffusée. J’ai dû attendre 3 à 4 jours pour qu’ils soient enregistrés partout. A ce stade, le tuto a été testé, le serveur DNS est fonctionnel et les points 1 (utilisation des mêmes url) et 2 (hébergement de mon serveur DNS) de mon objectif sont atteints. Premières conclusions Tout ça c’est très bien et à condition d’avoir correctement fait les redirections de ports du NAS et du routeur, ça fonctionne à merveille. Mais ça m’avance à quoi par rapport au loopback en natif chez free ? Certes, je ne passe plus par le routeur (loopback) pour mes requêtes sur le LAN (qui se limitaient en réalité à CloudStation), mais en pratique ça n’a rien changé côté utilisation. Si j’indique mondomaine:5001 de l’intérieur ou de l’extérieur j’accède bien en https à mon NAS, comme avant. Pareil pour CloudStation et toutes les autres applis. J'utilise les mêmes url qu'avant et je suis toujours obligé d’indiquer des ports pour accéder aux différents services. Oublier Quickconnect ? Je ne m’en servais pas de toute façon, donc sans intérêt pour moi. Bref, il n'y a aucune différence palpable sur l'utilisation de mon NAS. En l’état, et exception faite qu'il s'agissait aussi de tester le tuto, le serveur DNS ne me sert à rien. Pour que tout ce travail puisse avoir un impact concret sur mon utilisation de tous les jours, il fallait pousser plus loin la démarche en s'affranchissant notamment des contraintes de ports (point 3 de mon objectif). En parallèle, j’avais aussi un soucis à résoudre avec les certificats Domoticz de mes deux Raspberry qui ne sont pas bien reconnus par mon navigateur, ce qui m'obligeait à faire des exceptions pour pouvoir m'y connecter. Et tant qu'à faire, c’eut été bien de pouvoir aussi y apporter une solution. Et c‘est là qu’intervient le reverse proxy. Reverse proxy Une version simplifiée du proxy inversé (reverse proxy) est incluse dans DSM depuis la version 6.0. Elle se trouve dans le portail des Applications et elle est bien suffisante pour mon utilisation. Pour commencer, j’ai modifié et complété mes enregistrements DNS pour y intégrer un certain nombre de domaines. Voici une partie de ces enregistrements. DNS local : DNS publique : Je n’ai pas mis tous mes enregistrements publiques car ça n’apporte rien pour la suite. A noter : hormis le premier enregistrement NS dans la zone publique qui est l’adresse du DNS secondaire (Fenrir), tout ce qui est caché correspond à mon nom de domaine chez OVH. Pour ceux qui suivraient ce tuto et qui utilisent le DNS publique de leur bureau d'enregistrement (points 1 et 2 du DNS publique du tuto de Fenrir), la démarche est la même : les enregistrements sont à faire dans la zone DNS du bureau d'enregistrement (internet). Quelques explications sur les noms de domaine : audio, video, file, cam, get sont les noms que j’ai attribués pour accéder aux applications du NAS. Pour que ces noms soient utilisables à la fois sur le LAN et le WAN, ils sont enregistrés dans les deux zones DNS. domo accède à Domoticz sur le NAS, domo.s1 et domo.s2 à mes deux Raspberry sur lesquels tourne Domoticz. Ces noms sont enregistrés eux aussi dans les deux zones DNS pour être accessibles côté LAN et côté WAN. cam.bureau, cam.cuisine etc… sont les adresses pour accéder à mes caméras. Elles ne sont accessibles que sur le LAN (enregistrements dans le DNS local uniquement). sauvegarde c’est pour mon NAS de sauvegarde, routeur est suffisamment explicite, nas aussi, quant à tv1 c’est ma télé. Ces noms ne sont enregistrés que dans le DNS local. A noter que domo.s1 et domo.s2 ne pointent pas vers des adresses IP de mon LAN mais vers mon nom de domaine. C’est important pour la suite. Dans le portail des applications, j’utilisais jusqu'à présent les alias côté LAN (très pratique) mais c’est incompatible avec le DNS et le reverse proxy de DSM qui n'acceptent que des noms de domaine ou des IP. Je les ai donc désactivés et j’ai activé les ports DSM par défaut pour chaque application. J'aurais pu les modifier, mais ça n'aurait rien apporté en terme de sécurité, d'autant qu'ils ne sont pas accessibles de l'extérieur. A noter qu’il n’est pas utile d’activer les ports https pour le proxy inversé comme nous le verrons par la suite. Puis j’ai rempli les sources et destinations du proxy inversé comme ceci : Côté source, exception faite de video, toutes les adresses en http sont uniquement sur le LAN. Elles utilisent le port standard (80). Les autres (https) sont dispos des deux côtés, LAN et WAN. Elles utilisent le port standard (443). Côté destination, les adresses sont exclusivement en http vers les IP et les ports correspondants aux applications du NAS et aux autres équipements du réseau local (NAS de sauvegarde, Raspberry). Il est en effet inutile et contreproductif de doubler les chiffrements (une fois à la source, une autre fois à la destination). Et pour que ça puisse fonctionner, j’ai dirigé dans le routeur le port 443 vers le NAS, et je l’ai ouvert dans le pare-feu du NAS. Et là j’ai rempli mon dernier objectif : plus besoin d’indiquer des ports puisque tout passe par les ports standards http (80) ou https (443). Maintenant, quand je rentre par exemple https:\\file.mondomaine côté LAN ou WAN, j’accède à File Station via l’adresse http:\\localhost:7000. De même, avec https:\\audio.mondomaine, j’accède à Audio Station via l’adresse http:\\localhost:8800. Mais un des gros avantages que j’ai trouvé au serveur DNS combiné au reverse proxy c’est la possibilité d'accéder à mes Rasp en https sans utiliser leurs certificats. En effet, si je rentre https:\\domo.s1.mondomaine, j’accède bien à Domoticz sur mon Raspberry 1, sans passer par le certificat Domoticz puisque le reverse proxy communique avec lui via une adresse en http. Le serveur DNS transfère l’adresse https non pas vers le Rasp mais vers le NAS comme on l’a vu plus haut et de là, c’est le reverse proxy qui met en relation le NAS avec le Rasp. C’est donc le certificat du NAS qui est sollicité. Et voilà, tout devrait maintenant fonctionner comme prévu. Hélas non. Il reste encore une dernière action à mener, c’est justement sur les certificats : ils ne fonctionnent pas correctement ! Certificats Comme beaucoup ici, je suis chez Let’s Encrypt via le NAS et on ne peut pas dire que la documentation Synology soit foisonnante sur la manière de gérer ces certificats. Il faut d'abord commencer par comprendre comment se comporte DSM avec les noms de domaine nouvellement créés. Lorsqu’une nouvelle source en https est créée dans le proxy inversé, DSM inscrit automatiquement le nom du domaine dans la rubrique "Pour" du certificat par défaut. On pourrait croire que ce nouveau domaine est pris en compte par le certificat, or il n’en n’est rien. Il s'agit seulement pour DSM d'associer un domaine à un certificat et en l'occurrence, c'est celui défini par défaut qui est choisi. Ce n'est en aucun cas une validation. Les seuls domaines couverts par le certificats restent le domaine principal et ceux inscrits dans le SAN (rubrique "Autre nom de l’objet"). Il n'y a aucun changement ni sur la validité, ni sur le périmètre de couverture du certificat. Il faut donc éditer le certificat existant pour y inclure les nouveaux domaines, et comme DSM6.0 et au-delà permet de faire cohabiter plusieurs certificats, il sera peut-être nécessaire d’en rajouter. En effet, alors que chaque certificat Let’s Encrypt peut gérer jusqu’à 100 SAN en natif, la rubrique "Autre nom de l’objet" du NAS n'accepte pas plus de 256 caractères ce qui peut être rapidement atteint selon le nombre de noms à saisir et leurs longueurs. D’où la nécessité de devoir créer plusieurs certificats. Cette limite est semble t'il contournable mais il faut pour cela passer en SSH pour modifier les paramétrages. Je ne le conseille pas. On peut aussi les créer en externe (PC, MAC, Rasp, autre) et les importer dans le NAS, mais on perd du même coup le renouvellement automatique et il faudra alors le faire manuellement tous les 3 mois ou moins. Pour ma part, j’ai utilisé ceux proposés par DSM. Et puisque c'est possible et pour que ce soit plus clair, j’ai créé 3 certificats : un par défaut que j'ai appelé "Principal" qui couvre les applis de base (CloudStation, VPN, mail serveur, ..), un autre que j'ai appelé "Applications" qui couvre les applis DS (audio, video, file, cam, get ...), et un autre que j'ai appelé "Domoticz" pour la domotique. A partir de l'onglet "Certificats" du module "Sécurité" du panneau de configuration (vue ci-dessus), on peut soit créer un certificat, soit éditer un certificat existant. Dans les deux cas, il faut cliquer sur le bouton "Ajouter" et dans la page qui apparait on choisit soit "Ajouter un certificat", soit "Remplacer un certificat" et on sélectionne celui à remplacer. Selon le choix, sur la page suivante on rempli ou on modifie la description du certificat puis on choisi "Procurez-vous un certificat auprès de Let’s Encrypt". Dans l’exemple ci-dessous, j’ai choisi de modifier mon certificat Domoticz. En cliquant sur suivant, on arrive à la page des paramétrages. C’est la même, que ce soit pour une création ou une modification (les champs ne sont pas renseignés avec les données de l’ancien certificat). Après avoir complété le nom de domaine (mondomaine) et l’adresse email valide, il faut renseigner la rubrique "Autre nom de l’objet" (le fameux SAN) avec tous les noms de domaine complets à couvrir, séparés par des " ; " . Exemple pour mon certificat Domoticz : domo.mondomaine;domo.s1.mondomaine;domo.s2.mondomaine Important : il faut que tous les noms de domaine soient valides. Pour cela, ils doivent impérativement avoir un enregistrement A ou CNAME dans le serveur DNS publique car Let's Encrypt vérifie l'existence de chaque nom. Si on indique dans le SAN un nom de domaine qui n’existe pas ou pas encore, le certificat ne sera pas créé. A ce sujet, le message renvoyé par DSM en cas d’échec est assez déroutant. Au lieu de signaler qu'il y a un ou plusieurs domaine(s) qui n'existe(nt) pas, le message indique qu’il y a un problème sur le port 80 qui n'est pas ouvert. Comprend qui peut. Une fois tous les certificats créés, il reste une ultime étape : leur attribution pour chaque nom de domaine et chaque application. Pour cela, dans la page des certificats, il suffit de cliquer sur le bouton "Configurer", de choisir pour chaque ligne quel certificat est applicable puis de valider. Cette opération terminée, tout fonctionne correctement, je n’ai plus de soucis avec mes connexions https. Conclusion La mise en oeuvre a été longue et laborieuse, avec beaucoup d'erreurs de ma part, d'incompréhensions parfois car le sujet est assez complexe, mais au final je suis très satisfait du résultat. Objectif atteint. Voilà. Je suis sûr qu’il y a beaucoup à redire sur ce que j’ai fait, qu’il y a certainement mieux à faire. Certes, je suis ouvert à toute proposition d’amélioration. Je souhaite en tout cas que ça puisse aider la communauté.