oracle7

@TuringFan Bonjour, Un TLD, abréviation de Top Level Domain (domaine de premier niveau), est le dernier segment d’un nom de domaine – la partie qui vient après le point final. L’exemple le plus courant est le .com, mais il y a tout un monde de TLDs différents .... Oui du coup, Là je ne comprends pas car plus loin tu dis que tu constates le même comportement que moi en tapant l'@IP VPN du NAS en 10.x.0.x avec la connexion VPN établie vers le NAS ??? Cordialement oracle7😉 @TuringFan Au passage, je m’aperçois que l'on est en train de "polluer" le sujet initial sur le renouvellement du certificat LE. Je t'invite à poursuivre cet échange dans le sujet "VPN server" qui est plus approprié vu la tournure de nos échanges. Merci de ta compréhension. Cordialement oracle7😉

@TuringFan Bonjour, Recherches sur le présent forum, il me semble avoir déjà vu des discussions pour configurer avec "Download Station" (sur le NAS) avec des fournisseurs VPN tiers du style NordVPN et autres. Pour ma part, j'utilise NordVPN mais configuré à partir de mon PC sur le réseau local ( je vois pas l'intérêt de télécharger directement sur le NAS, au moins ce dernier n'est pas ouvert vers l'extérieur dans ce cas de figure). Cela marche nickel ! Attention pour une bonne compréhension, la machine où tu installes le serveur VPN permet à un client d'établir une connexion vers cette machine. Le tunnel est donc entre ce client et le serveur VPN. Donc : Si ce dernier est le NAS, ton client peut-être indifféremment : sur le réseau local (ce qui n'a pas de sens d'un point de vue confidentialité sauf en entreprise) ou à l'extérieur depuis n'importe où mais dans ce cas tu n’accèderas jamais au réseau local depuis l'extérieur, seulement au NAS et à ses dossiers partagés. Si ce dernier est sur le routeur, ton client peut-être indifféremment : sur le réseau local (mais quel intérêt de "confidentialiser" une liaison interne locale sauf en entreprise) ou à l'extérieur depuis n'importe où et dans ce cas tu pourras accéder via un tunnel confidentiel au réseau local derrière le routeur depuis l'extérieur. Cordialement oracle7😉

@sebiseba Bonjour, Et si tu essayais avec Synology Drive. Tu synchronises le dossier contenant tes fichiers vidéos sur le NAS avec ceux d'un même dossier sur le DD USB externe ? Je te renvoie vers la doc de Synology Drive pour les détails d'installation et de configuration. Cordialement oracle7😉

@cumuluss Comment te connectes-tu au NAS ? via l@IP:port ? ou via monNAS.ndd.tld ? Tout bêtement as-tu fait un reboot de l'ensemble routeur, Nas et PCs ? Cordialement oracle7😉

@Stigmate101 Pour te donner une idée, voilà une courbe d'autonomie typique pour un onduleur de 1200vA : Cordialement oracle7😉

@GrOoT64 Alors je t'invites à faire rapidement un calcul de puissance d'alimentation. Sais-tu ce que consomme un volet roulant ou un portail? Tu te rendras compte très vite que ton onduleur est largement sous dimensionné pour tous ces équipements même si tu ne les fermes pas tous en même temps. En première approximation, habituellement on évalue la puissance de l'onduleur à installer en multipliant par 1,6 la puissance totale des équipements qui lui sont raccordés. Cordialement oracle7😉

@GrOoT64 Ouaouhhh !!! ton installation doit être hyper sensible pour mériter un tel investissement ... Même si la sécurité n'a pas de prix, personnellement je ne pourrais pas à ce tarif ... Cordialement oracle7😉

@cumuluss Désolé mais c'est une très très mauvaise idée du point de vue sécurité. Nos NAS sont des cibles de choix des pirates chinois entre autres .... Maintenant c'est toi qui vois .... As-tu essayé avec le parefeu désactivé pour voir ? Cordialement oracle7😉

@Stigmate101 Bonjour, Tu peux regarder ce comparatif ici Tu trouveras ici de quoi vérifier la compatibilité des onduleurs avec tes NAS. L'outil WinNUT permet le pilotage de l'arrêt des PC. Recherches sur le présent site, il y a un intervenant qui avait posté un fichier Excel de calcul pour estimer la puissance de l'onduleur à installer en fonction des consommations des périphériques qui lui sont raccordés. En fonction de la puissance tirée par les périphériques, saches que la durée de maintient de l'alimentation chute vertigineusement. Mais ce qui importe à mon sens c'est qu'il faut pouvoir tenir au moins 20 minutes. C'est largement suffisant pour assurer l'arrêt en sécurité des NAS. Attention toutefois, plus c'est long plus le prix de l'onduleur est cher ! Il faut aussi bien regarder la possibilité de pouvoir assurer l'échange des batterie dans le futur (leur durée de vie reste limitée !) et surtout la facilité d'effectuer cet échange avec bien évidemment une disponibilité importante chez les fournisseurs. Personnellement, j'ai un Eaton ELP1200FR qui me donne entière satisfaction (pour toi je pense qu'il faudrait par ex la taille au dessus vu tes périphériques). En plus, il est hyper compact et peut fonctionner indifféremment verticalement ou horizontalement et il est aussi "rackable" dans une baie 19". Il n'est pas du tout bruyant contrairement à ce que tu entendras peut-être (en tout cas moins que moins PC déjà pourtant très discret !) sauf et c'est normal, durant la charge des batteries qui elle, n'arrive qu'à la première utilisation ou au retour du courant après une panne. Maintenant pour être honnête, il y a aussi la marque APC qui semble aussi assez appréciée. Voilà un avis qui vaut ce qu'il vaut ... Cordialement oracle7😉

@cumuluss Bonjour, @Thierry94 a raison, ton PC a sûrement son IP bloquée par le NAS, à partir d'un autre PC regardes dans "Panneau de configuration / Sécurité /Compte / Clients fiables / Gérer les clients fiables" pour voir si l'@IP de ton PC bloqué n'y serait pas présente. Au quel cas tu sélectionnes le PC et tu cliques sur "Débloquer". Cordialement oracle7😉

@Kramlech Bonjour, Pas de soucis, j'accède (hors connexion VPN) sans problème avec "xxxx.ndd.tld" à toutes les applications (DSM, File, Audio, etc ...) en local comme de l'extérieur. Le reverse proxy fait son job à merveille en liaison avec le DNS installé sur le NAS. Je viens de tester en tapant directement l'@IP du NAS (10.8.0.1:5000) depuis mon smartphone avec la connexion OpenVPN active, la liaison semble démarrer, mais l'indicateur d'avancement reste bloqué (après environ 2 minutes) à environ 85%. PAr ailleurs, dans VPN Serveur je me vois bien connecté avec l'@IP sur smartphone. Voilà où j'en suis. Cordialement oracle7😉

@TuringFan Bonjour, Non : Il faut que "passerelles multiples" soit décochée pour que d'une part la connexion VPN puisse s'établir D'autre part, une fois la connexion VPN établie depuis mon Smartphone par ex, impossible de se connecter en tapant "monNAS.ndd.tld". Cà n'aboutit pas ! Donc pour l'instant, la connexion VPN depuis l'extérieur semble inutilisable. 😩😩😩 même si elle est active. Je continue à chercher pourquoi. Cordialement oracle7😉

@Juan luis Lorsque le client se trouve comme tu dis sur le LAN distant coté serveur, il a effectivement une @IP "étrangère" ce qui masque sa réelle @IP de départ mais il n'empêche qu'à partir de là le reste de sa navigation n'est pas confidentielle. Par ailleurs, ce cas de figure suppose que le tunnel VPN est établit entre le routeur du client et le serveur VPN tiers situé je ne sais où (en fait si, on sait puisque que l'on choisit ce serveur au départ). Hors dans la discussion précédente il s'agit de sortir sur Internet de façon confidentielle à partir du serveur VPN installé sur le routeur du client et c'est là que je pense que cette façon de procéder n'est pas possible et qu'il faut obligatoirement passer par un serveur VPN Tiers externe. Cordialement oracle7😉

@TuringFan Oups je comprends que tu n'ai pas compris, désolé, je me suis effectivement mal exprimé. Dans le premier § quand je disais "le tunnel VPN n'est établit qu'entre le RT et le NAS" en fait c'est cela que je voulais dire : "le tunnel VPN n'est établit qu'entre le client via le RT et le NAS". La liaison VPN est bien comme cela : Client --> via RT --> NAS (support du serveur VPN). Dans le second § la liaison est bien : Client --> RT( support du serveur VPN) --- ........ --> Internet. Le NAS n'intervient pas. C'est plus clair maintenant ? J’édite mon post précédent dans ce sens pour ne pas perturber les autres lecteurs. Peux-tu aussi supprimer la citation à mon propos mal rédigé dans ta réponse précédente. Merci. Cordialement oracle7😉

@TuringFan Bonne question à laquelle je ne sais répondre, effectivement le tuto de Fenrir ne concerne pas ce type de configuration (VPN sur le RT directement). Là il faut l'avis d'un expert réseau/NAS ce qui ne manque pas sur ce forum. @DaffY, @Mic13710 au secours !! Vos avis SVP. Par ailleurs, ce que je ne comprends pas quand on active un VPN entre le client (via le Routeur) et le NAS support du seveur VPN (accessoirement c'est alors un tunnel parallèle à la liaison standard du réseau local qui se trouve établit, cette dernière étant "bypassée"), comment font alors certains qui disent accéder par ce VPN à Internet. En toute logique le tunnel VPN n'est établit qu'entre le client (via le RT) et le NAS. Si, en plus le NAS est derrière le RT dans le réseau local du RT, je ne vois pas comment il pourrait faire remonter ses paquets de données vers Internet. Là il faut m'expliquer ????? De plus, que je saches, c'est toujours le client qui initie la connexion VPN en s'adressant au serveur VPN et pas l'inverse, ou alors je n'ai rien compris. Donc, le client est sur le réseau local du routeur et le serveur VPN sur le routeur, lorsque le client établit la connexion VPN c'est entre lui et le routeur seulement. Ce que je ne sais pas dans ce cas lorsque cette liaison est établie si le client demande une URL sur Internet est-ce qu'il bénéficie alors du tunnel VPN jusqu'à cette URL voyant ainsi sa navigation vers cette URL "confidentialisée". Mais j'en doute fortement. Je crois que le tunnel VPN s'arrête au serveur VPN donc au RT et ensuite la liaison n'est plus sécurisée entre le RT et l'URL sur Internet. Ton avis STP, je délire ou pas ? Cordialement oracle7😉

@TuringFan Il faut suivre ce qu'a dit Fenrir : Donc , sur le parefeu du NAS : sur le parefeu du RT : rien sur le port 1701. Cordialement oracle7😉

@TuringFan Comme cela remplit ma boîte à bons points 😂😂😂 Pour moi, il faut les laisser actives dans le RT pour que le mécanisme de reverse proxy puisse fonctionner, sinon par ex pour le port 443, tu ne pourrais plus accéder de l'extérieur avec un simple "monsousdomaine.ndd.tld" et sûrement d'autres services qui utilisent ce port 443 seraient alors bloqués. C'est quand même le port de communication sécurisé par essence me semble-t-il. Non ? PS : Attention j'ai édité ma précédente réponse. Cordialement oracle7😉

@TuringFan Bonjour, Voilà comment j'ai organisé mes règles de transfert de ports sur le RT : Chez moi, après validation elles se retrouvent automatiquement (*) (je ne les ai pas créées manuellement dans le parefeu) dans le parefeu du RT "en grisé" telles que : (*) c'est d'ailleurs le cas de toutes les règles de transfert que j'ai créées dans l'onglet adéquat. Edit2 : pour la création automatique des règles de transfert dans le parefeu j'ai coché cela : Je ne comprends pas non plus pourquoi dans le parefeu tu as limité les ports 80 et 443 aux @IP sources de LE et aux ports source qui devraient être eux sur "Tous". De plus, le port 443 doit être séparé du port 80 (une règle chacun), LE n'en fait pas le même usage d'une part et d'autre part le port 80 n'est utilisé QUE lors du renouvellement du certificat LE, le reste du temps il est fermé, règle désactivée (sauf cas d'usages particuliers). Edit : idem dans le parefeu du NAS, sépares les règles sur ces ports. Par ailleurs, saches que les @IP 66.133.109.36 et 64.78.149.144 ne sont à priori plus opérationnelles. Elles l'ont été quelques années durant mais plus maintenant depuis le changement de politique de LE. Pour le renouvellement du certificat LE , tout semble passer par le port 443 seul selon certains ici. Dans l'attente de confirmation, il semble qu'il faille tout de même ouvrir le port 80 au moment du renouvellement. Cordialement oracle7😉 Cordialement

@alan.dub +1 😉

@Juan luis Ah bon ? Et que crois-tu que fasse l'application DSFile ? Cordialement oracle7😉

@Gibson ba oui ... mais commence avant par celui sur la sécurisation des accès, à moins que tu ne l'ai déjà fait ... Dans tous les cas, lis et relis bien ces tutos pour bien comprendre ce qu'il y a à faire avant de mettre les mains dans le cambouis ! Cordialement oracle7😉

@Gibson Donc, parfait, tu n'as plus qu'à suivre les Tutos DNS Serveur, Reverse Proxy sans oublier celui sur la Sécurisation des accès. Bonnes installations et n'hésites pas à revenir poser tes questions. Cordialement oracle7😉

@Gibson Bonjour, Peux-tu STP préciser ton souhait car pour moi accéder à distance au NAS, l'extérieur s'entend, c'est utiliser : un navigateur web : dans ce cas cela se complique quelque peu car il te faut un nom de domaine personnalisé (pris par ex chez OVH pour environ 10€/an), installer un serveur DNS sur le NAS et enfin paramétrer un reverse proxy sur le NAS pour accéder à tes fichiers via un simple "fichier.domaineperso.tld" tapé dans un navigateur web ou directement dans un explorateur WIN. ou par exemple utiliser l'application DSfile disponible sous Android (Mac je ne sais pas) pour accéder à tes fichiers mais là encore pour la connexion ce serait mieux d'utiliser un nom de domaine personnalisé. A moins que tu n'ai une @IP fixe ce qui simplifierait le problème. Cordialement oracle7😉

@Thierry94 Enregistrements MX pour serveurs de secours faits en corrigeant les priorités. Soit dit en passant, au début de nos échanges, mon domaine ndd.tld avait une priorité inférieure à celle des serveurs mail OVH. Du coup je comprends mieux pourquoi, tous les mails I/O restaient en fait chez OVH. Bien vu pour MailPLus Synoology sur Android, je viens d'installer et c'est nickel ! Cordialement oracle7😉

@Thierry94 Bonjour, Eh bien, c'est bien le paramètre "Activer la protection postscreen contre les spams" ou DNSBL, ce tu appelles chez toi la liste Blackhole, qui pose problème, je te le confirme. Penses-tu que cela mérite un ticket pour informer le support Synology de ce bug et/ou problème ? Pour le reste, je suis conforme à tes recommandations de réglages divers et effectivement cela fonctionne. J'hésite encore à rétablir les enregistrements MX pour les serveurs de secours OVH. Je vais peut-être prendre le risque ... Dans tous les cas, je te remercie encore vivement pour toute ta patience à bien vouloir m'aider pour résoudre cette installation. Merci aussi @Jcdusse44 pour ses pistes qu'il a indiquées. Ce qui est aussi parfait pour moi dans cette affaire, c'est qu'avec le reverse proxy, j'arrive à me connecté à distance à MailPlus pour consulter les mails avec un navigateur lambda sur n'importe quel type de périphérique en saisissant simplement "mail.ndd.tld". Par ailleurs en observant le contenu de ma zone DNS chez OVH je constate la présence de deux enregistrements CNAME : "imap.ndd.tld 0 CNAME ssl0.ovh.net." et "smtp.ndd.tld 0 CNAME ssl0.ovh.net." D'où ma question, ne faudrait-il pas les modifier en : "imap.ndd.tld 0 CNAME ndd.tld." et "smtp.ndd.tld 0 CNAME ndd.tld." ou bien je les laisses tels quels ??? Enfin, lorsque (sur le conseil de @Jcdusse44) je teste la boite mail "userNAS@ndd.tld" sur le site , j'ai en réponse une anomalie trouvée qui dit ceci : "[SPF] ndd.tld n'autorise pas votre serveur xxx.yyy.zzz.www à utiliser userNAS@ndd.tld" et en conséquence m'invite à modifier l'enregistrement SPF présent dans la zone DNS de OVH (pour y ajouter @IP du serveur xxx.yyy.zzz.www qui est en fait le serveur smtpXX.smtpout.orange.fr du moment avec XX variable donc une @IP variable). Faut-il finalement et comment éventuellement tenir compte de cette suggestion de https://www.mail-tester.com pour améliorer le score puisqu'en définitive l'@IP du serveur en question n'est jamais la même ? dilemme ... Cordialement oracle7😉