oracle7

@PPJP Il n'y a aucune raison de prendre ainsi la mouche. Bien au contraire, tes avis sont appréciés et utiles à la communauté. Je trouve seulement dommage de prendre cette position ... En espérant, pouvoir poursuivre ces échanges à toi. Cordialement oracle7😉

@Pinpon_112 Bonjour, NON, je pense qu'il sera différent mais je n'en suis pas sûr. Aussi, dans le doute on fait comme s'il était différent. Tu vas alors dans le fichier "/volume1/Certs/ndd.tld/ndd.tld.conf". Tu l'édites et là soit tu ajoutes une ligne (si elle n'existe pas) soit tu modifies la ligne : Avec xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx = le nouveau DID. Attention ce sont des simples cotes " ' " et PAS des guillemets " " " qui entourent la valeur du DID. Cordialement oracle7😉 @Audio Bravo, je vois que tu as réussis cette fois 😀😀😀. Tu sais on fait tous des erreurs, c'est notre nature d'humain qui veut cela. Le principal est d'apprendre de ces erreurs pour ne plus les refaire ... Voilà pour le 1/4 d'heure philo ... 😜 Cordialement oracle7😉

@PPJP Bonjour, Merci pour ton appréciation. Je vais essayer de répondre point par point à ta méthodologie. C'est un point de vue certes, c'est aussi pour cela que j'ai souhaité le détailler au maximum en apportant le plus d'explications possibles pour clarifier les manipulations afin que les utilisateurs comprennent bien ce qu'ils faisaient. Je suis d'accord, on trouve plus simple sur la toile, mais ces TUTO ne donnent pas entière satisfaction quand au résultat attendu et sa fiabilité. l'automatisation à un prix (au moment de l'installation) mais ensuite on n'en entendant plus parler ... Par ailleurs, même en voulant faire "simple" avec unPixel vous aviez, en son temps, rencontré un certain nombre de difficultés, non ? C'est ce que j'ai essayé initialement mais cela ne marchait pas, le wget ne permet que de récupérer le fichier tar du script (confirmé par diverses sources sur Github) et a priori ne permet pas de lancer directement l'installation. Où alors j'ai raté un truc ? Surtout pas car sinon le certificat est généré dans le répertoire "/root/.acme.sh" et sachant que le répertoire "root" n'est pas stable dans le temps, il est effacé en cas de mise à jour de DSM et on perd les fichiers du certificat. D'où l'usage de la variable CERT_HOME. idem pour la partie exécutable de acme.sh qui serait perdue aussi, ce qui serait encore plus dommageable pour assurer le renouvellement. D'où là encore d'usage de la variable ACME_HOME. De plus, par défaut c'est la méthode HTTP_01 qui est utilisée et qui elle, nécessite d'ouvrir les ports 80 et 443 sur le NAS (le problème principal est le port 80 du point de vue sécurité). D'où l'usage de la variable CERT_DNS = "dns_xxx" qui elle utilise la méthose DNS_01 et qui n'a pas besoin d'ouvrir un quelconque port et est bien plus sécuritaire. Tout l'intérêt du "deploy" est d'assurer la correcte mise à jour de l'environnement propre au NAS Synology. Je n'ai fait que reprendre en cela les préconisations des experts acme sur Github. En plus, on s'affranchit en l'automatisant, des problèmes liés à une double authentification qui serait en place. Pour mémoire, acme.sh est pour moi, assez "générique" quelque part et le "deploy" est là justement pour prendre en compte les spécificité du NAS Synology". Regardes le script "synology_dsm.sh" dans "/usr/local/share/acme.sh/deploy" pour t'en rendre compte si besoin en est. Comme tu le ferais à la main, mais là en plus, il n'y a pas besoin de getter la date de renouvellement pour ouvrir les ports 80 et 443. Tout est automatique, on n'ouvre aucun port, ce qui est parfait du point de vue sécurité. La recopie des fichiers du certificat est de plus COMPLÈTE grâce au script Python, ce que ne fait pas justement la seule commande de renouvellement de acme.sh comme tu le sais très bien. Certes, mais pour l'heure on aura utilisé les ressources minimales disponibles sur le NAS. @bruno78 seul peut le dire si une évolution à court terme du script vers Python 3 est envisageable. Pourquoi pas, a priori et sauf erreur de ma part, il marche déjà avec Python 3, donc il n'y aurait aucun problème mais je peux me tromper. Saches aussi, qu'à la base on ne souhaitait pas complexifier plus avant la procédure en faisant installer le package Python 3 (même si c'est simple au demeurant). Maintenant, en attendant que le serpent de mer qu'est DSM7 ne refasse surface pour de bon, cette procédure, dans l'état, répond au besoin. Il sera toujours temps d'évoluer alors, d'autant plus que cette version DSM7 pourrait bien aussi bousculer bien d'autres choses et notamment pourquoi pas, la façon dont sont gérés aujourd'hui les certificats. Donc wait and see... Maintenant si tu as d'autres suggestions d'améliorations, avec @bruno78 nous sommes preneurs dans juste mesure de nos capacités respectives. Cela doit pouvoir venir en complément des fonctions accessibles via le mode "manuel" du script. Si cela doit toucher la partie automatique, il faudra alors être très convainquant pour ne pas complexifier encore plus ... Cordialement oracle7😉

@Audio Cela se confirme, tu as omis la variable CERT_HOME lors le la procédure. Tu n'as pas répondu : que contient le répertoire "/root/.acme.sh/" ? Il serait peut-être plus sage de reprendre à zéro la création de ton certificat lors que son échéance sera atteinte (avec le mode annule et remplace). Cette fois en pointant bien chaque opération pour ne pas en "oublier" ... Cordialement oracle7😉

@romain_syno Bonjour, Pour les deux premières, effectivement il faut les ignoer : voir dans le TUTO "Sécuriser les accès à son nas" (à la fin). Pour la 3ème "redirection automatique en https est désactivée" : Oui, il faut la désactiver dans "Conseiller de sécurité / Personnalisé / Personnaliser la liste de contrôles". Cordialement oracle7😉

@Terranon 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. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... Pour ton problème, je crains que tu ne mélanges les choses. Il y a le certificat LE pour certifier que tu es bien le propriétaire de ton domaine et qui est utilisé dans les connexions sécurisées HTTPS d'une part et le certificat intégré à OpenVPN et qui lui est propre pour certifier tes connexions VPN. Revois ta configuration OpenVPN et régénère le fichier de configuration que tu importeras sur tes clients. Ce fichier ".ovpn" contient le certificat en question. Edites-le et tu verras ... Cordialement oracle7😉

@Pinpon_112 Bonjour, As-tu bien créer dans la zone DNS de ton registar un enregistrement CNAME pour ton NAS : "nas.ndd.tld" vers "ndd.tld" ? Cordialement oracle7😉

@Audio Bonjour, Effectivement ce n'est pas normal que le variable d'environnement CERT_HOME n'apparaisse pas dans le fichier "account.conf". Dès qu'elle est définie, le script Shell "acme.sh" l'inscrit dans ce fichier. As-tu bien un répertoire "volume1/Certs" existant sur ton NAS ? Si ce n'est pas le cas alors je crains que pendant le déroulement de la procédure tu es omis la déclaration de cette variable. Du coup, regardes si tu as sur ton NAS un répertoire "/root/acme.sh/tonDomaine.tld" contenant les fichiers du certificat (tonDomaine. key, tonDomaine.cer, ca.cer, fullchain.cer). Si c'est le cas alors cela confirmerait la non création de la variable CERT_HOME. De plus, je trouve étonnant aussi la non présence de la variable OVH_CK dans ton fichier "account.conf". Là encore, très certainement une omission ... Au final, je crains qu'il y ait des soucismais je peux me tromper. As-tu conserver une copie des messages affichés lors de la création du certificat (cf §4 du TUTO) ? Si oui tu peux les montrer (après les avoir nettoyés de tes infos personnelles) ? Quel est le contenu de ton répertoire "volume1/Certs" ? Cordialement oracle7😉 @Pinpon_112 Bonjour, Pas d’inquiétude à avoir, "dxleo0" est le nom interne de ton certificat que lui a donné Synology. Le message est clair, rien a été fait car il est encore trop tôt ... Cordialement oracle7😉

@rotou Bonjour, Dans ta box à tu bien transféré (Reseau - NAT/PAT) le port 1194 vers l'@IP de ton NAS ? As-tu un client VPN (sous OpenVPN) actif sur ton NAS avec une connexion sortante vers l'extérieur vers un fournisseur VPN Tiers lorsque tu montes ton VPN ? Si d'aventure la réponse est OUI alors saches que tu ne pourras alors pas te connecter depuis l'extérieur vers ton NAS sous VPN. Il y a interférence entre les deux connexion OpenVPN et du coup le VPN "entrant" ne peut fonctionner. Cela pourrais être une explication. As-tu aussi tout simplement arrêtée et redémarrée proprement ta LiveBox ? Si non fais-le, cela peut éventuellement aider ... Cordialement oracle7😉

@Vinky Bonjour, C'est bon maintenant, j'ai trouvé mon erreur. En fait c'était dans la définition du NS en ressources. Il ne fallait pas mettre l'@IP inversée complète mais juste les 3 premiers "octets". Soit "2.168.192.in-addr.arpa NS 86400 ns.ndd.tld" et là çà passe. La résolution inverse marche : Cordialement oracle7😉

@PiwiLAbruti Bonjour, J'ai configuré une zone DNS inverse dans DNS Serveur sur mon routeur RT2600ac telle que : Quand je teste avec nslookup cela ne semble pas marcher : Edit : J'ai aussi ajouté une ressource : "1.2.168.192.in-addr.arpa NS 86400 ns.ndd.tld" J'ai dû raté quelque chose, mais je ne vois pas quoi ? Cordialement oracle7😉

@romain_syno Bonjour, As-tu suivi le conseil de @maxou56 ? As-tu essayé d'ajouter un CNAME de toto.com vers ton DynDNS (serveur.toto.com) ? Sinon d'une façon générale, il aurait été plus cohérent de définir ton domaine "toto.com" plutôt que "serveur.toto.com" dans ton DynDNS chez OVH car maintenant dans l'état actuel, si tu veux ajouter d'autres sous domaines ils seront obligatoirement du type "xxxxx.serveur.toto.com" au lieu de plus naturellement "xxxxx.toto.com". Maintenant ce que j'en dis, c'est à toi de voir ... De plus, cela faciliterait aussi les choses du coté du certificat LE car tu pourrais ainsi définir un wilcard sur ton domaine en "*.toto.com" qui couvrirait automatiquement (sans limitation de nombre !) tous tes sous domaines à venir sans autres modifications à faire. Réfléchis-y ... Cordialement oracle7😉

Bonjour, Personne n'a d'idée d'où ce trouvent ces fichier ? Cordialement oracle7😉

@rotou Bonjour, Depuis l'extérieur, pour les applications DSxxx, il faut obligatoirement ajouter le port à l'@ de connexion. Pour DSFile, le port n'est pas 5001 comme tu sembles faire mais 7000, donc 10.8.0.1:7000. Dans ton fichier de configuration OpenVPN ".ovpn", essaie avec l'option "dhcp-option DNS 10.8.0.1". Dans DSM "Reseau/Général/paramètres avancés" as-tu coché "Activer les passerelles multiples" ? Cordialement oracle7😉

@rotou Bonjour, Dans les options OpenVPN de VPN Server, as-tu autorisé l'accès aux ressources locales ? Cordialement oracle7😉

@romain_syno Bienvenue à toi sur ce forum 😉

@romain_syno Tu as répondu pendant que j'éditais mon post précédant. Regardes le PS.

@romain_syno Bonjour, Si tu veux de connecter en tapant simplement "serveur.toto.com" il te faut configurer le reverse proxy (voir TUTO) avec une redirection du type : "https://serveur.toto.com:443" vers "http://localhoste:40000". Mais je te le répète, modifier les ports standard du NAS n'est pas une bonne idée ... A voir aussi : que donne "nslookup serveur.toto.com" ? (dans une fenêtre de CMD Win en mode admin) ca devrait te renvoyer ton @IP externe. C'est bien le cas ? PS : Tu peux montrer une copie d'écran de ta zone DNS chez OVH en masquant juste ton domaine ? Cordialement oracle7😉

@romain_syno Bonjour, Au fait, 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. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... OUI, cà c'est normal puisque ton certificat n'est pas défini pour l'@IP xxx.xxx.x.xx. Cordialement oracle7😉

@romain_syno Bonjour, Tu ne lis pas bien les indications de l'interface DSM : pour le nom d'hôte il faut saisir normalement l'@IP statique PUBLIQUE de ton NAS comme ton @IP externe (i.e. publique) est dynamique vu que tu as configuré un DDNS, il te faut alors saisir "serveur.tot.com" (cible de ton DDNS). Malheureux ! On n'expose JAMAIS son NAS en direct à l'internet. Donc supprimes les règles NAT/PAT pour les ports 40000 et 40001. Par ailleurs, cela n'apporte rien de plus du point de vue sécurité, de modifier les ports par défaut, tu ne fais que retarder d'une minute au plus une éventuelle attaque et cela complexifie ensuite la gestion courante. Mais c'est toi qui voit ... Décoche cette option. Coches dans "Reseau/paramètres DSM" : "Activer un domaine personnalisé" et renseignes le champ "Domaine" avec "serveur.toto.com" Il te faut aussi ouvrir le port 443 dans le pare-feu du NAS. Maintenant, tu te connectes comment depuis l'extérieur ? en tapant quoi ? Je t'invites si ce n'est déjà fait à lire puis à suivre les TUTOs suivants :"Sécuriser les accès à son NAS" et "Reverse proxy" Cordialement oracle7😉

@unPixel Bonjour, Toutes les images de ton TUTO sont inaccessibles (liens morts) ce qui rend la compréhension plus difficile, est-ce qu'il te serait possible STP de les régénérées ? Merci d'avance Cordialement oracle7😉

@Shasdo Bonjour, Alors envoies un petit mot à unPixel dans ce sens puisqu'il est l'auteur du TUTO. Cordialement oracle7😉

@Pinpon_112 Bonjour, Je vais supposer que ton réseau est comme ceci : Internet _____________10.20.30.40 _ BOX _192.168.1.1____________192.168.1.2 _ ROUTEUR _ 192.168.10.1 _____________192.168.10.100 _ NAS Dans le Reverse proxy du NAS il faut une redirection "https://routeur.ndd.tld" vers "http://192.168.10.1:8000". Cela ne sert à rien de faire une destination en HTTPS sur le port 8001 comme dans ta copie d'écran : sur sécurisation inutile vu que tu es déjà en https à l'entrée. Maintenant, dans ton Serveur DNS Local, as-tu aussi un CNAME "routeur.ndd.tld" pointant sur "192.168.10.1" ? Cordialement oracle7😉

@Shasdo Bonjour, Je t'invites à lire le TUTO dont je t'ai donné le lien précédemment. Il y a 3 phases de configuration. Tu ne parles jusqu'à présent ici que de la 1ère et de la 3ème. Visiblement tu omets la 2ème. Dans la 1ère (Btn Ajouter un DynHOST) on est d'accord, tu n'as pas le choix que de renseigner un sous-domaine (quelque soit son nom ou "*") pour pouvoir créer l'Identifiant DynHost. De toutes façons, ce sous-domaine n'est pas utilisé, cela reste chez OVH. Donc quelque qu'il soit on s'en f... Dans la 2ème (Btn Gérer les accès) , il faut laisser le champ "sous-domaine" vide pour ajouter un nom dynamique (DynHost). C'est juste cela qui permet de saisir uniquement la racine de ton domaine dans la 3 ème phase pour le DDNS sur le NAS (comme tu le souhaites). Je te l'accorde unPixel dans son TUTO préconise de saisir "tuto" (ou un autre nom) mais cela fige alors le DDNS sur "tuto.ndd.tld" ce que tu ne veux pas. C'est pour cela que je dis qu'il ne faut rien saisir pour ce champ "sous-domaine" dans la 2ème phase et je m'appuie en cela sur ce post ici. J'ai configuré comme cela mon DDNS et je n'ai aucun soucis. Mon domaine "ndd.tld" pointe bien sur mon @IP externe à chaque mise à jour de celle-ci par mon FAI. Cordialement oracle7😉

@Pinpon_112 Oups, désolé 😪, j'ai regardé trop vite ta copie d'écran dans l'autre post. Dans le reverse proxy, pour la redirection vers ton routeur dans le champ "Destination / Nom d'hôte" ce n'est pas "localhost" qu'il faut mettre mais l'@IP locale de ton routeur. Cordialement oracle7😉