oracle7

@pascalg57 je crains que OUI. Donc redirection à créer dans le reverse proxy pour un accès local comme de l'extérieur. Je suis étonné qu'avec DSFinder tu puisses accéder à DSM avec un nas.pascalg.net:443 parce que nas.pascalg.net pointe sur ton @IP externe (voir le nslookup précédent) et donc pas sur l'@IP LOCALE de ton NAS. Là il faudrait une copie d'écran de ta zone DNS sur le NAS pour confirmer ou non, mais il y a de fortes chances que Oui. Cordialement oracle7😉

@pascalg57 Ah voilà une nouvelle information, je comprends mieux maintenant. Donc ton domaine à prendre en compte est bien "nas.pascalg.net" (c'est moins simple mais bon, ce sera comme cela). Donc tous tes sous-domaines devront alors être du type "xxxxxx.nas.pascalg.net". Par conséquent tu as raison pour accéder au NAS il faudra utiliser quelque chose comme "dsm.nas.pascalg.net". Voilà pourquoi cela clochait avec ton certificat : tu omettais "dsm." pour le sous domaine lié à ton NAS. A toi maintenant d'être aussi cohérent partout où tu utilises ton domaine "nas.pascalg.net". Pour l'obtention du certificat, il te faut donc donner : Domaine : nas.pascalg.net Autre nom : fichiers.nas.pascalg.net; dsm.nas.pascalg.net Maintenant cela devrait le faire ... Cordialement oracle7😉

@Fanny Mae Bonjour, Le nom d'hôte peut être efectivement n'importe quoi d'autre que tutonas, si bien que le nom retenu et qui est visible sur ton réseau domestique, est parfait pour la gestion générale (surtout il est facile à retenir et bien plus parlant pour toi !) Il faut indiquer ton @IP externe donc celle de ta box. 1.1.1.1 du TUTO n'est qu'un exemple d'@IP externe. OUI. Bon choix. Dans le doute abstient-toi. Ce n'est pas utile ... Cordialement oracle7😉

@pascalg57 Chez OVH tu mets une étoile " * " dans les champs "sous domaine" et ainsi ce sera sur "pascalg.net" (ton domaine) que pointera alors ton DynDNS. Bien évidemment ensuite, il te faudra être cohérent avec cette nouvelle définition et mettre à jour : d'une part ta zone DNS chez OVH, et d'autre part sur le NAS : ta zone DNS locale dans ton serveur DNS et éventuellement le reverse proxy dans les redirections déjà existantes plus quelques paramètres de DSM. Je ne te caches pas que cela représente pas mal de manipulations mais avec un peu de méthode et surtout beaucoup d'attention tu devrais y arriver sans problèmes (surtout prends ton temps pour bien réfléchir à chaque action ...). Bon courage. Cordialement oracle7😉 @pascalg57 OUI pour les deux question. Cordialement oracle7😉

@kasimodem Dans le cas de @pascalg57 , il a déjà un serveur DNS de configuré mais manifestement celui-ci ne l'est pas bien. C'est ce que @PiwiLAbruti a voulu faire comprendre en relevant l'anomalie de résolution du domaine. Cordialement oracle7😉

@pascalg57 Désolé, tu n'as pas compris ma remarque : il faut MASQUER ton domaine (ainsi que ton @IP externe) quand tu diffuses des copies d'écrans. C'est pour ta sécurité ! Puisque tu as configuré ton serveur DNS local, maintenant pour réaliser ta demande, dans le reverse proxy du NAS il te faut une redirection du type : "https://nas.p*******g.net:443" vers "http://localhost:5000". Maintenant, je crois aussi que tu te compliques la vie à la vue de la définition de ton domaine. Ton domaine est p*******g.net et non pas nas.p*******g.net (à moins que tu ne veuilles cette dernière notation expressément !). Je pense que cette confusion met le cirque ! Mais ce n'est que mon avis..... A mon sens tu devrais avoir ceci dans la définition de ton certificat : Domaine = p*******g.net Autre nom de l'objet : fichiers.p*******g.net; nas.p*******g.net Ainsi tu accèderais simplement à : ton NAS en tapant : nas.p*******g.net à FileStation en tapant en local : fichiers.p*******g.net en de l'extérieur (avec le smartphone) avec DS file en tapant fichiers.p*******g.net:443 Bien évidemment avec les bonnes redirections correspondantes dans le reverse proxy : "https://nas.p*******g.net:443" vers "http://localhost:5000" "https://fichiers.p*******g.net:443" vers "http://localhost:7000" @kasimodem Sauf que ainsi tu passes par les serveurs de Synology et que tu leur donnes un accès total à ton NAS. En terme de sécurité on fait mieux .... Cordialement oracle7😉

@pascalg57 Bonjour, ????? Ton domaine n'est pas masqué !!!!! Si tu accèdes avec "https://192.168.x.xxx:5001/" c'est normal que tu ais cette alerte de sécurité vu que ton certificat n'est pas défini pour :'@IP en question. Il faudrait que tu accédes avec un "nas.ndd.net" Par ailleurs, je relève une incohérence que je ne comprends pas, entre la définition du certificat que tu donnes et ta copie d'écran. Sur la copie d'écran, ton domaine est "nas.ndd.net" et tu dis avoir défini le certificat pour le domaine "ndd.net" (nas.ndd" <> "ndd") et en plus tu répètes "nas.ndd.net" dans autre nom de l'objet ??? (pas facile d'expliquer en masquant ton domaine !). Cordialement oracle7😉

@Einsteinium Bonjour, Oui tu as raison, sauf que là le serveur principal est bien en ligne car il reçoit sans problèmes des mails gMail. C'est juste que les mails d'Orange restent sur les serveurs de secours d'OVH. Ce qui n'est pas normal pour ceux là. Cordialement oracle7😉

@Thierry94 Bonjour, Suite à ticket ouvert chez OVH pour demander pourquoi certains mails n'étaient pas correctement redirigés vers mon serveur mail, voici la réponse édifiante qui m'a été faite par le support OVH : Moralité je crois que je vais abandonner cette idée d'utiliser les serveurs MX d'OVH en secours. Ton avis STP ? Cordialement oracle7😉

@dric67 Bienvenue à toi sur ce forum, n'hésites pas à consulter la rubrique [TUTORIELS] c'est une mine d'or ...😀 Cordialement oracle7😉

@dric67 Bonjour, Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait). a priori, je dirai qu'il te suffit d'utiliser DRIVE Serveur sur le NAS et d'installer une bonne fois sur chaque PC le client Drive pour Windows disponible ici (NAS / modèle / Utilitaires de bureau). Et tu configures le serveur Drive pour tes "Dossiers de l'équipe". A voir aussi (à vérifier la possibilité de cette piste mais là je ne suis pas sûr), en utilisant un domaine "xxxx.tondomaine.tld" et via le reverse proxy du NAS (port 443) en redirigeant sur l'application Drive du NAS, càd une redirection du type : "https://xxxx.tondomaine.tld" vers "http://localhost:10002". Cordialement oracle7😉

@dric67 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 ... Tu donnes tout seul la solution. Il te suffit de faire cela au niveau du dossier partagé en question sur le NAS. Tu crées un groupe d'utilisateurs avec les bons droits sur le NAS que tu affectes à ton dossier partagé, etc ... Ton lecteur réseau Windows pointant normalement sur le dossier partagé. Il faut cependant que les utilisateurs Win et NAS soient les mêmes (Id, Mdp). Cordialement oracle7😉

@rotou Bonjour, Maintenant que tu le dis, je ne voudrais pas trop m'avancer mais il est fort possible que ce soit ta connexion 4G en hotspot qui pose problème. Je ne pense pas que ce soit un problème d'instabilité car sinon la connexion OpenVPN "décrocherait" ce qui n'est pas le cas. Très succinctement : par nature et conception, UDP est très largement plus rapide que TCP car il admet de perdre des paquets en route puisque c'est un mode dit "non connecté". A l'inverse, TCP est un mode dit "connecté" de bout en bout. En gros, il établit une connexion avec le destinataire avec lequel il vérifie que chaque paquet est bien arrivé sinon il assure son renvoi. Du coup cela ralenti la communication mais c'est fiable contrairement à UDP. Cordialement oracle7😉

@Audio Bonjour, Je viens de revérifier mon propre domaine et effectivement "dmarcanalyser.com" me renvoie bien qu'il trouve une clé 1024 bits alors que comme toi j'ai généré une clé 2048 bits sur le NAS. Bug chez Dmarcanalyser ou sur le NAS ? Je ne saurais dire ... Cela dit, même si ce n'est pas bloquant, bizarre quand même. Cordialement oracle7😉

@Doludo 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 ... Tout dépend du niveau de confiance auquel tu apportes à ton prestataire VPN. Dans le cas de Synology, avec Quickconnect (même si c'est une forme de VPN) tout ton trafic vers ton NAS passe d'abord par les serveurs de Synology, donc ils voient tout ... En plus, ainsi tu leur donnes un accès direct à ton NAS et tout son contenu. Personnellement c'est hors de question, même si je n'ai rien à cacher ... Je préfère utiliser le revers proxy du NAS et j'ai essayé à l'aide des conseils trouvés sur le présent forum de configurer au mieux mon NAS pour le sécuriser. Je sais très bien que cela n'arrêtera pas un pro mais déjà je bloque pas mal de "bricolos en herbe" ! Cordialement oracle7😉

Bonjour, @alan.dub @Jeff777 @.Shad. @CyberFr @GrOoT64 @PPJP @_Megalegomane_ @TuringFan @zerda @oudin @vincentbls @Einsteinium @kerod @Jz84 @jo.p @Pinpon_112 @Audio @bruno78 Pour vous informer qu'une évolution a été apportée au TUTO. § 10 : Ajout d’une trace complète et systématique du processus de renouvellement. § 10 : Ajout de l’option « -f » au script Python de renouvellement. Nouvelle version v1.40 du script Python (à remplacer simplement dans le répertoire « /volume1/Scripts »). Cordialement oracle7😉

@rotou Bon eh bien tant mieux, content pour toi. Affaire (presque) résolue. Je dis "presque", car c'est quand même étonnant que cela ne marche pas en UDP qui est et reste quand même le protocole STANDARD pour OpenVPN. Cela dit, au pire, tu risques seulement de constater des performances de transfert bien moindre en TCP qu'avec UDP. A mon humble avis, il conviendrait que tu investigues encore un peu pour pouvoir fonctionner en UDP. A toi de voir ... Cordialement 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😉