oracle7

@.Shad. Bonjour, Tu avoueras que l'explication de @CoolRaoul n'est pas complète et ne prends qu'un aspect du processus. En plus, plus trop d'actualité vis à vis du multiplexage des applications dans le tunnel. Non ? Personnellement, je préfère m'en tenir à la "White Paper" de Synology qui explique, elle, parfaitement le fonctionnement de Quickconnect. Cordialement oracle7😉

@Fanny Mae Bonjour, @PiwiLAbruti a raison, réfléchi bien à ton besoin avant de te lancer dans une quelconque configuration. Il y a tellement de variantes possibles ... Sinon une astuce : 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). Cordialement oracle7😉

@Pkoipas 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 ... Voici un TUTO dont tu devrais pouvoir t'inspirer en adaptant la partie routeur à ton matériel. Certes c'est basé sur un routeur Synology mais ton routeur ASUS doit avoir des fonctionnalités assez proches, donc facilement transposables. Lis le bien pour bien comprendre la démarche suivie. Cordialement oracle7😉

@Pandore62 Bonjour, Tout simplement parce que le reverse proxy "écoute" en permanence le port 443. Il redirige en suite vers l'application voulue sur son port dédié (par ex : FileStation via localhost sur le port 7000 ou DSM via localhost sur le port 5000). Maintenant par sécurité saches que l'on ouvre jamais les ports 5000 et 5001 de DSM vers l'extérieur. Donc c'est une mauvaise idée que tu as eu de le faire pour le 5001 ... Cordialement oracle7😉

@PiwiLAbruti En tous cas, même s'ils s'en gardent avec leurs déclarations d'intention : voir page 9 de la "White Paper" suscitée, le doute subsiste ... Cordialement oracle7😉

@Thierry94 Merci, comme cela c'est clair 😀 Cordialement oracle7😉

@PiwiLAbruti Merci pour ta réponse. C'est bien ce que je pensais, tout tient dans la confiance que l'on accorde aux serveurs Synology. Par ailleurs, j'ai lu dans plusieurs reprises sur la toile que le serveur relai déchiffrerait les données au passage. Info ou intox ? Cordialement oracle7😉

@Thierry94 Bonjour, OK mais pourquoi ? Juste pour comprendre : c'est le fait d'en cocher certaines qui provoque le phénomène constaté ? Cordialement oracle7😉

@Tiromino Bonjour, Quel intérêt de revenir au certificat d'origine (si tant est que ce soit possible sinon par une réinitialisation complète du NAS) ? Si tu as un certificat LetsEncrypt valide pour ton domaine, c'est parfait, pas besoin d'en changer. Tu te fais des "nœuds au cerveau" pour rien à mon humble avis. Mais bon, si c'est ton choix ... Cordialement oracle7😉

@darkneo Bonjour, Je constate aussi maintenant ce phénomène, malgré que la planification la détection de mouvent du mode home ne soit programmée que pour déclencher entre 19h00 et 07h00. Donc dans la journée si je suis présent j'ai tout de même ces notifications. Bizarre ? Sûrement j'ai comme toi raté un truc ? Cordialement oracle7😉

@kasimodem, @maxou56, @PiwiLAbruti J'ai trouvé cette "White Paper" de Synology qui explique parfaitement le fonctionnement de Quickconnect avec des synoptiques très clairs des flux échangés. Ce qui me gêne c'est dans le cas où le "Hole Puching" ne parvient pas à établir un tunnel virtuel entre le NAS et le client demandeur, un serveur relay de Synology est activé pour rediriger les flux de données dans un tunnel spécifique. Quelle confiance accorder à ce serveur relais qui voit passer alors les données même si celles sont cryptées, c'est quand même (si j'ai bien compris) le serveur Synology initial qui délivre lors du processus de connexion, les clés de chiffrement nécessaires pour cette communication "tunelisée". Je n'ai pas vu/compris qu'il utilisait les nôtres (privée/publique) d'où mon embarras ????? Si quelqu'un pouvait approfondir ce point en expliquant ce qu'il en est effectivement ... Cordialement oracle7😉

@pascalg57 Le problème n'est pas "à distance", il est dans le fait que tu utilises "nas.pascalg.net:443" comme URL de connexion. C'est cela qui ne va pas car je le répète "nas.pascalg.net" pointe sur ton @IP externe donc tu ne devrais pas pouvoir atteindre le NAS ainsi car ce dernier (ton NAS) est dans ton réseau local avec une @IP en 192.168.XXX.XXX. C'est tout. Cordialement 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😉