oracle7

@Juan luis C'est sûr que mettre en place un routeur pour faire ce travail est une très bonne chose en soi (indépendamment du coût d'investissement), il peut même suppléer la box en faisant encore mieux le travail dévolu habituellement à celle-ci et ce avec bien plus de fonctions de paramétrage qu'elle, offrant ainsi une plus grande souplesse d'utilisation. Cela dit, n'oublies pas qu'un NAS est conçu pour fonctionner h24. Si tu l'arrêtes, tu n'auras plus accès à tes données et autres fonctionnalités bien utiles comme par exemple la surveillance vidéo de ta maison justement lorsque tu es absent, ce qui apporterait des preuves aux autorités les cas échéants. Mais c'est toi qui vois ... et puis on s'écarte du sujet initial et du problème de @Comess. Cordialement oracle7😉

@comess Bonjour, Pour activer un VPN sur ton NAS (pour sécuriser les connexions de l'extérieur vers le NAS et ton réseau local), il est impératif que tu commences déjà par sécuriser les accès "normaux" à ton NAS (voir le tuto idoine). Ensuite seulement, tu prolongeras cela avec un l'utilisation d'un nom de domaine associée à un serveur DNS et un reverse proxy ainsi ton utilisation du NAS sera grandement facilité. Le seul changement à tes habitudes résidera uniquement dans une plus grande simplicité de ta façon de te connecter. De plus, toutes tes connexions seront vraiment sécurisées. Par ailleurs, ces conditions étant remplies, la mise en place d'un VPN de type NordVPN pour sécuriser les connexions depuis ton NAS et/ou ton réseau local vers l'extérieur ne sera qu'un jeu d'enfant. Je ne peux que te conseiller de lire tranquillement déjà tous les tutos correspondants à ces fonctions pour bien en appréhender et maitriser le jargon des notions mises en oeuvre et tout cela complété par une recherche personnelle sur la toile pour de plus amples détails. Et là tu seras bien armé pour installer de façon sereine ces fonctions sur ton NAS. Cela te demandera certes un petit effort et investissement personnel, mais crois moi le jeu en vaut la chandelle car tu va ainsi découvrir d'autres facettes et possibilités offertes par ton NAS que tu n'imagines peut être même pas aujourd'hui ... Bonne lecture et n'hésites pas à revenir poser tes questions ici, il y aura toujours un membre pour te répondre 😀 Cordialement oracle7😀

@TuringFan Bonjour, Ok, alors je crois alors qu'il y a un bémol avec ton fichier "ca.cer", il a dû être endommagé pour x raisons. Pour le vérifier: avec WINSCP recherche dans "/usr/syno/etc/certificate/_archive" le dossier "XyzWTu" de ton dernier certificat (en principe le plus récent mais en tout cas celui qui est cohérent avec la date de génération du certificat) ouvre ce dossier et récupère sur ton PC une copie du fichier "chain.pem" qui s'y trouve. compare en visualisant en cote à cote ce fichier avec une copie du "ca.cer" pris dans "volume1/Certs/ndd.tld" pour t'assurer qu'ils sont en principe identiques dans leur contenu (mis à part d'éventuels caractères parasites invisibles qui pourraient s'y trouver) ensuite sur le PC tu renommes le fichier "chain.pem" en "ca.cer" puis refait un import dans le RT du certificat "ndd.tld.key", "ndd.tld.cer" et en fichier intermédiaire le "nouveau "ca.cer" Si cela passe alors BINGO ! Sinon là je sèche et je vais tout de même pas te dire de relancer une génération complète... Cordialement oracle7😉

@Juan luis Bonjour, Effectivement, je me suis mal exprimé, désolé. Ce que j'ai voulu dire en fait, c'est qu'il me paraît plus pertinent d'utiliser un nom de domaine pour se connecter que d'utiliser une URL de type QuickConnect. L'usage d'un nom de domaine, sous entend aussi l'usage derrière de mécanismes et/ou d'outils qui sont eux même sécurisés et/ou sécurisant pour la connexion. En quelque sorte c'est pour cela que je pense qu'il concoure indirectement à un premier niveau de sécurisation et d'autant plus que l'on vient encore par dessus rajouter l'usage d'un certificat pour ce domaine afin d'en garantir l'authenticité. Un autre exemple, est l'usage d'un reverse proxy sur le NAS, qui impose de passer par une liaison sécurisée HTTPS qui est elle-même écoutée sur le port 443 lui-même sécurisé avant que ne soit traduit le nom de domaine et que la connexion soit redirigée au bon endroit sur le NAS ou le réseau local. C'est donc aussi cet "empilement" de sécurité autour qui me fait dire (peut-être par erreur et/ou abus de langage) qu'un nom de domaine est sécurisant même si, et j'en conviens volontiers, le terme est un peu fort, mal adapté ou pas le bon tout simplement. Maintenant tu as raison pour verrouiller complétement les choses la meilleure solution c'est d'utiliser un VPN pour sécuriser la connexion. Cordialement oracle7😉

@PPJP Bonjour, Effectivement ce serait vraiment sympa de ta part car il ne nous manque pas grand chose manifestement pour avoir une procédure complète, de bout en bout, pour générer, renouveler et gérer sur nos NAS ce fameux certificat wilcard LE. Cordialement oracle7😉

@comess Bonjour, Désolé pour mon délai de réponse, j'ai pas mal d'affaires sur le feu en ce moment... En tout cas Merci, avec ta dernière réponse, c'est bien plus exploitable. Bon maintenant je crains que ton problème vienne en fait de ta connexion via QuickConnecct. Je te dis cela sous toutes réserves car je n'en suis pas sûr (ne pas hésiter à me corriger au besoin). Je peux me tromper mais j'ai l'impression que la connexion via Quickconnect semble faire abstraction du paramétrage du pare-feu dans le sens où ton @IP de départ ne serait pas en fait celle à ton arrivée sur le NAS puisque cette connexion directe au NAS repose sur un VPN. Ce qui expliquerait que tu arrives à te connecter malgré les réglages que tu as mis en place sur celui-ci pour bloquer cette @IP de départ. A confirmer par un expert de QuickConnect. Par ailleurs, tu verras/liras partout sur ce forum que l'utilisation de QuickConnect n'est pas du tout recommandée du point de vue sécurité parce que tout ton trafic (donc tes données) passe par les serveurs de Synology. A moins que tu ne leur fasses une totale confiance à ton niveau, saches que ce n'est pas le cas pour un nombre d'utilisateurs ici. Pour mémoire voici un extrait du tuto sur la sécurisation des accès écrit par un expert reconnu à propos de QuickConnect : A toi de voir et d'y réfléchir mais une solution bien plus sécuritaire pour toi serait de prendre un nom de domaine personnalisé (environ 10€ par an chez OVH par ex) et de configurer ton NAS (une fois les accès sécurisés) avec un serveur DNS et un reverse proxy . Les Tutos pour faire cela sont disponibles sur le forum et c'est relativement facile à faire. Ainsi tu pourrais de connecter en tapant simplement une URL du type "xxxxxx.mondomaine.tld" avec un "xxxxxx" correspondant à chacun de tes périphériques et/ou applications/services de ton NAS. Cordialement oracle7😀

@bruno78 Bonjour, Je viens de re balayer le Tuto de UnPixel, aux pages 6-7 il évoque bien le même problème de non prise en compte du certificat que tu cites. Mais il n'indique pas vraiment de solution palliative. En plus ce n'est pas clair car ensuite il dit que le problème est réglé mais rien de plus. Par ailleurs, quand on observe le contenu du répertoire "/usr/syno/etc/certificate" on y trouve aussi un répertoire "system/default" qui contient les fichiers du certificat mais au format ".pem". Finalement je me demande s'il n'y aurait pas un lien entre ces fichiers et le problème que tu évoques. De plus je ne saurais dire à quoi correspondent ces fichiers ".pem" vu qu'ils sont cryptés : l'ancien ou le nouveau certificat par défaut ? Une autre piste à regarder : il semblerait que les fichiers du certificat soient aussi dupliqués dans tous les répertoires inclus dans le répertoire ""/usr/syno/etc/certificate/ReverseProxy". Du coup en plus de modifier les fichiers INFO et DEFAULT, ne faudrait-il pas faire une conversion des fichiers du certificat (".key', ".cert", etc ...) en ".pem" et les recopiier par remplacement dans chacun des dossiers du répertoire "ReverseProxy" suscité ? Ton avis STP ? Cordialement oracle7😀

@TuringFan Bonjour, C'est une belle colle que tu me poses là. J'avoue ne pas trop savoir. Pour ma part j'avais procédé comme je te l'ai indiqué précédemment en important les 3 fichiers issus de la génération. Force est de constaté que je n'ai pas rencontré les problèmes que tu évoques. Du coup je suis un peu sec pour te répondre. A tout hasard, as-tu essayé d'arrêter proprement le RT, de le débrancher électriquement, attendre au moins une minute et de le redémarrer tout aussi proprement, histoire que tous les caches mémoire soient bien vidés. Ensuite, tu réimportes les trois fichiers du certificat . Cela ce coûte rien d'essayer et peut être que ... Cordialement oracle7😉

@comess Ne le prends pas mal mais ce serait bien que tu sois STP plus explicite dans tes réponses car il faut deviner ce qui se cache derrière et cela ne facilite pas les choses pour t'aider. Par ex tu dis "ai fixé l'adresse ip de mon PC à ...88" : je crois comprendre que tu as défini un bail statique sur cette @IP dans ta box. Mais cela pourrait être une chose façon d'attribuer une @IP, l'impact de l'une ou l'autre peut être bien différent selon ... Comprends-tu ? En tout cas, pour bien comprendre ce qui se passe et pourquoi le blocage pare-feu mis en place n'est pas effectif, il faut que tu me dises aussi STP : Comment tu te connectes ? via un navigateur Web, une application client spécifique , etc ... Si c'est un navigateur Web, qu'est-ce que tu tapes précisément comme URL de connexion sur ton PC et/ou Tél ? Si tu es gênè du point de vue sécurité, dans ta réponse remplace l'@IP réelle par 1.2.3.4 si c'est ton @IP externe, pour les @IP locales que tu citerais, tu peux les laisser en clair car de toutes façon elles ne sont pas joignables hors de ton réseau local et si c'est ton domaine alors remplace le par "ndd.tld". Cordialement oracle7😉

@comess Je ne te dérange pas plus alors, on en reparle plus tard si tu as des questions ... Cordialement oracle7😉

@comess Ok donc tu es en DHCP sur la Livebox. Donc, c'est elle qui défini automatiquement l'@IP de ton PC, de ton NAS et de tous tes autres périphériques (bien évidemment s'ils sont configurés aussi en DHCP automatique comme ton PC). Alors en allant dans l'interface d'administration de la LB, dans "Mes équipements connectés" peux-tu regarder quelle @IP est affectée actuellement à ton PC ? Est-ce 192.168.1.28 ou pas ? Par ailleurs, dans ce cas il serait quand bien de figer au moins l'@IP de ton NAS par un bail statique dans la LB (dans Réseau / DHCP). Au moins tu seras ainsi sûr que ton NAS sera lui toujours à la même adresse et t'évitera ainsi des désagréments si par ex un reboot de la LB intervenait pour X raisons. En effet à cause du DHCP il pourrait y avoir une réaffectation totale ou partielle des @IP de tes périphériques. Cordialement oracle7😉

@comess Bonjour, Pourrais-tu STP préciser quelques points pour bien comprendre le contexte : As-tu un serveur DHCP d'activé et sur quoi ? ton NAS ou ta box ? L'@IP de ton PC est-elle fixe via un bail DHCP sur ta box ou l'as-tu fixée directement sur l'adaptateur réseau de ton PC (paramètres carte réseau) ? Est-tu sûr que l'@IP de ton téléphone n'a pas changé entre temps ? Par ailleurs, j'espère que ton pare-feu ne reste pas dans cet configuration (copie d'écran) en fonctionnement normal. Je ne peux que trop t'inviter à lire et à suivre le Tutoriel "[TUTO] Sécuriser les accès à son nas" sur le présent forum. Cordialement oracle7😉

@niklos0 Alors, désolé je ne vais pas t'être d'un grand secours sur ce coup là. Tu aurais eut une Livebox, j'avais en magasin la solution immédiate à ton problème car avec elle on peut interdire ou restreindre l'accès à Internet de façon individuelle, pour chaque périphérique qui lui est connecté. Fouilles quand même la doc de ton routeur, ce serait bien le diable s'il n'y avait pas une fonctionnalité qui te permette ce blocage individuel par @IP ou par @MAC. Bon courage pour la suite . Cordialement oracle7😉

@niklos0 Bonjour, Sauf que si tu bloques les ports 80 et 443 (d'ailleurs où ?) car si c'est sur la box, adieu à toute navigation Internet. C'est toi qui vois ... Cordialement oracle7😉

@Thierry94 Cela me paraît normal et très bien mais toutefois pas comparable vu que tu es maintenant passé au relais SMTP OVH. Pour info voici mes enregistrements SPF (qui me permet de garder les serveurs OVH en secours); DKIM et DMARC : SPF : ndd.tld. 0 SPF "v=spf1 a mx a:ndd.tld ip4:80.12.242.123 ip4:80.12.242.124 ip4:80.12.242.125 ip4:80.12.242.126 ip4:80.12.242.127 ip4:80.12.242.128 ip4:80.12.242.129 ip4:80.12.242.130 ip4:80.12.242.131 ip4:80.12.242.132 ip4:80.12.242.133 ip4:80.12.242.134 include:mx.ovh.com -all" DKIM : prefixe._domainkey.ndd.tld. 0 TXT "v=DKIM1; q=*; p=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" DMARC : _dmarc.ndd.tld. 0 TXT "v=DMARC1; p=quarantine; rua=mailto:admin@ndd.tld; ruf=mailto:admin@ndd.tld; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject" Cordialement oracle7😉

@pluton212+ Cela ne s'invente pas, la preuve en image : et j'utilise le smtp.orange.fr Cordialement oracle7😉

@pluton212+ Bonjour, Je suis chez Orange et je n'ai pas pu modifié le rDNS car inaccessible chez eux pour devancer ta question. C'est d'ailleurs ce que me dit le rapport de mail-tester.com dans un message tagué orange mais non bloquant Cordialement oracle7😉

@.Shad. A mon humble avis, ce n'est pas ce qui manque ici, il faut juste qu'un d'entre eux accepte d'y consacrer un peu de son précieux temps 😏 Cordialement oracle7😉

@Thierry94 @PiwiLAbruti a raison, j'ai mis personnellement l'@Mail que j'utilise (configurée) sur le serveur MailPlus Server. Cela marche nickel. En ce qui concerne l'enregistrement SPF, je te conseille d'y inclure toutes les @IP du serveur SMTP relais que tu utilises. Comme cela il n'y a plus de messages dans mail-tester.com comme quoi ton serveur SMTP n'est pas authentifié pour utiliser ton @MAIL. Par ailleurs si cela peut aider, voici 3 sites (il y en a sûrement d'autres) qui permettent respectivement de tester individuellement les enregistrements SPF, DKIM et DMARC. Après ces tests et ajustements éventuels, pour ma part, j'ai obtenu du premier coup un 10/10 avec mail-tester.com. SPF : https://www.kitterman.com/spf/validate.html? DKIM : https://www.dmarcanalyzer.com/fr/dkim-4/verification-de-dkim-record/ DMARC : https://www.dmarcanalyzer.com/fr/dmarc-4/verification-de-dmarc-record/ Le dernier site permet aussi la vérification SPF mais le premier suscité me paraît mieux. Ce n'est que mon avis ... Cordialement oracle7😉

@.Shad. Bonjour, Tu as sans doute lu un peu trop rapidement ma précédente réponse, aussi je ferai juste une petite mise au point : Je tiens à préciser que ne n'ai jamais laisser entendre que leur tutoriel était obsolète, je ne me permettrais pas. Je parlais seulement du script d'automatisation qu'ils avaient produit et me basant sur les propos explicites de @PPJP lui même , je le cite pour mémoire : Là on est bien d'accord, c'est aussi ce que j'avais dis à @Jeff777 dans une réponse en date du 31/05/2020 dernier. Effectivement, à moins de développer ta propre API à l'image de celle d'OVH (mais là il y a du boulot !) je ne vois pas de solution dans ton cas. Désolé de t'avoir donné de faux espoirs avec ma méthode. Cordialement oracle7😉

@TuringFan Là il te faut utiliser "WinSCP" sous Windows (je ne lui connais pas d'équivalent sur Mac, désolé). C'est en tous cas, le plus facile à mettre en œuvre car il a une interface graphique contrairement à PuTTY. Je te laisse le découvrir. Rien de compliqué rassures toi. Cordialement oracle7😉

@TuringFan J'ai eut aussi ce soucis. Il ne faut pas exporter ton certificat depuis le NAS. Ne pas utiliser non plus de fichiers ".pem". C'est bizarre mais cela ne marche pas ! Tu dû voir ... Tu copies les fichiers qui ont générés dans "Volume1\Certs\ndd.tld" sur ton PC/Mac. Sur le RT tu importes directement cette copie ( ndd.tld.key, ndd.tld.cer et l'intermédiaire ca.cer). Cordialement oracle7😉

@.Shad. et @Jeff777 Pour votre info si besoin en est, @unPixel et @PPJP avaient décrit ce processus d'automatisation dans les 12 ou 13 pages du Tuto de @unPixel au travers d'un script qui a priori est obsolète maintenant mais dont on doit pouvoir s'inspirer et remettre au gout du jour. Cordialement oracle7😉

@TuringFan Ta question est arrivée pendant que je rédigeais ma précédente réponse. Oui il y a de grandes chances que ce soient des caractères dits spéciaux qui gênent le processus. Saches que l'on peut faire des mots de passes tout aussi forts sans avoir recours à ces caractères. Je ne sais plus si c'est @Fenrir ou @unPixel qui expliquaient cela dans un de leurs tutos. Donc, normalement et justement dans la syntaxe Shell script, l'usage des "simples cote" (ou apostrophes en français) : " ' " permet de ne pas tenir compte (si je puis dire) de ces caractères spéciaux (par ex ? / \ : " * < > . ). On dit alors que l'on les "échappent" (ce qui n'est pas forcément la meilleure traduction du terme anglais "escape"). Certains processus les remplacent même automatiquement et de façon transparente par l'équivalent de leur code ASCII, par ex "%2A" pour une " * " afin de poursuivre leur exécution sans erreurs. C'est aussi ce que l'on fait sous Windows dans les noms de fichiers. Cordialement oracle7😉

@bruno78 Bonjour, Merci de ce premier retour qui est très encourageant. Cela ne m'étonne qu'à moitié que tu ai fait ce choix, une de mes connaissance m'en avait parlé et pour lui c'était le meilleur moyen d'attaquer un parseur JSON pour manipuler le fichier INFO. Bon courage à toi pour la suite ... 😉 @TuringFan Bonjour, a priori (du moins de ce que j'ai pu en comprendre) c'est utilisé pour de l'authentification dans le processus. l'@MAIL quant à elle, comme elle apparaît dans le fichier "account.conf" lui même situé dans "/usr/local/share/acme.sh", devrait pouvoir être modifié/remplacée si besoin (dans le futur comme tu dis). Oui en quelque sorte. Lors du déploiement, le script déroule une procédure de connexion au NAS ce qui déclenche automatiquement le processus de double authentification qui lui, renverait une interface à l'utilisateur pour saisir son code à 6 chiffres. C'est donc en positionnant la variable d'environnement "SYNO_DID" avec la bonne valeur, on "courcircuite" ce processus d'affichage en transmettant directement les éléments nécessaires d'authentification au NAS. Ainsi le déploiement devient "transparent" pour l'utilisateur. Tu installes la double authentification tout simplement et une bonne fois pour toute. Comme cela tu es toujours sécurisé au moins pour la connexion au NAS. Je ne sais te répondre par rapport au certificat. mais pourquoi attendre, mets là en place maintenant et plus de prise de tête à se faire, non ? Cordialement oracle7😉