oracle7

@GrOoT64 Oui, le relais de QuickConnect est activé (il l'est en fait depuis la première installation du NAS1). Par contre, à chaque fois que j’accède à l'onglet QuickConnect dans le Panneau de configuration de DSM, j'ai une notification du parefeu qui me demande d'ouvrir les ports 5000 et 5001. Ce que j'annule systématiquement car je ne veux pas exposer ces ports à Internet conformément à ce qui est dit et rabâché sur le présent forum quant à l'ouverture de ces ports. Tu crois que le problème viendrait de là ? Cordialement oracle7😉

@Thierry94 Bonjour, Puisque la dernière mise à jour d'OpenVPN Connect a mis le bazar, encore une idée "bête" (j'en ai plein comme celle là ! 😛) et si tu désinstallais OpenVPN Connect, reboot smartphone et réinstallation propre toute "fraîche" d'OpenVPN Connect ? On ne sait jamais, çà vaut le coup d'essayer non ? A moins que tu ne l'ai déjà fait ... PS: Comme toi, j'aurais quelques réticences à utiliser un client tiers en lieu et place de l'officiel OpenVPN Connect. Pas vraiment confiance. Cordialement oracle7😉

@GrOoT64 Bonjour, Oui pour les deux questions. Tout est vert, normal. Cordialement oracle7😉

@Vinky Bonjour, Je ne saurais te dire, c'est mon destinataire (un membre du forum qui n'est pas en ligne actuellement) qui m'a retourné l'info via MP, telle que je l'ai mentionnée. Sur le NAS (client du routeur) le port 80 est actuellement ouvert uniquement sur les @IP des serveurs de Let'sEncript. Sur le routeur, le port 80 est transmis, donc ouvert. Cordialement oracle😉

@Chapstm Bonjour, effectivement pour convertir un fichier ".crt" ou ".pem" en ".p12", il faut passer par un outil comme OpenSSL sur Windows en ligne de commandes. Installer OpenSSL pour Windows Win + X : CMD en mode Admin CD le répertoire contenant les fichiers .pem openssl pkcs12 -export -out certificat.p12 -inkey privkey.pem -in cert.pem -certfile chain.pem Cordialement oracle7😉

Bonjour, J'ai mis en partage un fichier sur mon NAS via File Station. J'ai transmis le lien de partage "http://gofile.me/xxxxx/xxxxxxxxx" associé à mon correspondant mais celui-ci ne peut y accéder. il a ce message "Impossible de télécharger le(s) fichier(s)." Avez-vous une idée de ce qui bloquer ? Ai-je omis quelque chose dans le partage ? Cordialement oracle7😉

@Thierry94 et @Chapstm Là les gars, je ne comprends pas car j'ai eu aussi la dernière mise à jour de OpenVPN Connect et il a bien pris mon certificat (c'était un ".p12") quand il me la demandé. Je peux me connecté en OpenVPN sans problème depuis mon smartphone Android. Il y a autre chose sur vos "bécanes" qui bloque/interfère je ne sais. Et avec un certificat ".p12" ou ".pfx" cà donne quoi ? Cordialement oracle7😉

@Thierry94 Quand tu dis "j'ai mis un .crt", comment exactement tu as fait ? Tu as juste déposé le fichier .crt dans un répertoire sur le smartphone? ou l'as-tu importé par la fonction "Installer depuis stock.périph." dans "Autres paramètres de sécurité". Excuses moi pour ces questions, mais c'est pour bien comprendre le contexte ... Cordialement oracle7😉

@Thierry94 Bonjour, En re-générant un certificat wilcard LE avec acme.sh, je me suis aperçu que le dit certificat était constitué de fichiers ".cer". De coup cela m'a mis la puce à l'oreille car les fichiers de type ".cer" sont bien visibles par OpenVPN sur le smartphone tout comme aussi les fichiers de type ".crt". Voilà donc une nouvelle piste à explorer pour toi ... Cordialement oracle7😉

@LeMorse Bonjour, Désolé pour toi mais c'est normal que çà bloque. C'est Synology qui a limité la longueur de la chaine de caractères des SAN (autres noms d'objet) à 256 caractères. Cela même si Let's Encrypt accepte jusqu'à 100 domaines maxi pour les SAN. Moralité pour t'affranchir de cette limitation tu n'as pas d'autre choix que d'utiliser un certificat wilcard du type "*.ndd.tld". Pour ma part j'en utilise un et j'ai bien une bonne vingtaine de domaines de second niveau. je n'ai aucun problème pour les gérés. Enfin, pour mémoire la notion de sous-domaine n'existe pas, c'est un abus de langage !. Cordialement oracle7😉

@Alp.Laurent Bonjour, C'est un problème de droits mals définis sur ton NAS que tu as. Vérifie toutes les permissions accordées à chacun de tes utilisateurs sur tes dossiers partagés. Seul ton administrateur doit avoir l'accès au dossier Homes en L/E. Pour Kodi, il faut lui associer un utilisateur spécifique qui n'aura accès qu'aux dossiers partagés de types Films, séries, photos par ex. Et si tu utilises une base de données centralisée pour ta médiathèque, c'est ce même utilisateur qui apparaîtra dans le fichier advancedsetting dans le dossier userdata de Kodi. Cordialement oracle7😉

@Thierry94 Merci de ton retour pour le test, tu m'as pris de vitesse. Effectivement alors là on est mal et j'avoue ne pas savoir faire autrement. Cela dit je me console, si je puis dire, en me disant elle est tout de même encapsulée et cryptée dans le fichier ".p12". Mais est-ce suffisant ? Je ne saurais le dire. Maintenant il n'y a plus qu'à espérer qu'un ou des experts sur ce forum, pourra(ons) nous donner une solution rassurante. Cordialement oracle7😉

@GrOoT64 As-tu le module complémentaire "Ublock Origin" d'installé dans FireFox ? Si oui, as-tu essayé de le désactiver pour la fenêtre/onglet "Vidéo Station". Je sais qu'il me met le "cirque" avec "Surveillance Station" d'où qu'il fasse pareil avec Vidéo Station ne me surprendrais pas ! A voir ... Cordialement oracle7😉

@Thierry94 Parfait, content d'avoir pu t'aider à mon tour ... 😀 Tu as raison, en y réfléchissant bien la clé privé devrait rester chez toi. J'avoue que je n'y avais pas pensé auparavant. En conséquence, il faudrait faire le test de conversion en omettant le paramètre "-inkey privatekey.pem" et recharger le nouveau certificat ".p12" dans le smartphone. A voir donc ... Cordialement oracle7😉

@Thierry94 Sous quelle forme as-tu rechargé le certificat LE sur le smartphone ? Si ce sont des fichiers ".pem" cela ne marche pas. Il te faut convertir les fichiers ".pem" en ".p12". Pour cela il faut : installer sur le PC "OpenSSL". Touche Win + X : et ouvrir une fenêtre de CMD en mode Admin Faire un "cd" sur le répertoire contenant les fichiers .pem Taper la commande : "openssl pkcs12 -export -out certificat.p12 -inkey privkey.pem -in cert.pem -certfile chain.pem" Ensuite tu importe ton certificat ".p12" sur le smartphone et là il devrait être reconnu par OpenVPN client. Cordialement oracle7😉

@Thierry94 J'ai eut aussi ce message et j'ai simplement sélectionné mon certificat wilcard LE. Cordialement oracle7😉

@Outimeme Bonjour, Personnellement j’accède à DSM depuis mon PC via un "nom-du-nas.ndd.tld" ce qui est plus facile (et à retenir aussi) que de taper une @IP:NumPort. J'ai en plus la double authentification qui elle s'applique à chaque connexion (sauf si tu as coché faire confiance au périphérique) qu'elle soit en local ou de l'extérieur (ce qui est la plus intéressante dans ce dernier cas, du point de vue sécurité d'accès). Cordialement oracle7😉

@Thierry94 Tout bêtement, et en supprimant ton profil OpenVPN sur le smartphone et en le recréant avec un nouvel export du fichier .ovpn ... (+ reboot du Tél). Des fois, cela tiens à pas grand chose ... Cordialement oracle7😉

@GrOoT64 En fait, oui on peux, il suffit de modifier l'objet OpenVPN. Cordialement oracle7😉

@Thierry94 Bonjour, Tu peux essayer de régénérer (exporter) ton fichier de configuration .opvn depuis ton serveur VPN puis de le recharger dans ton profil de connexion sur ton smartphone. Normalement ce fichier contient les clés du certificat (plus simple que d'utiliser un fichier externe à pointer par "ca_bundle"). Je peux me tromper mais il y a dû avoir sur le serveur VPN une modification de configuration ou autre (suite à une Mise à jour peut-être) qui a eut pour impact de modifier la clé privée dans le certificat d'où la discordance annoncée dans ton message d'erreur. C'est une interprétation du message qui en vaut une autre sûrement ... Cordialement oracle7😉

@GrOoT64 J'aurais besoin de tes lumières STP. Comme je le présentais, en connexion OpenVPN, c'est bien un problème de reverse proxy qui bloque l'accès aux ressources via un "https://xxxxx.ndd.tld". En creusant un peu, je me suis aperçu que le problème venait en fait du contrôle d'accès ajouté à certaines redirections. Pour les redirections sans contrôle d'accès ajouté, c'est OK la connexion de fait bien. Pour les autres donc, j'ai bien essayé de rajouter et d'autoriser dans les paramètres de ce contrôle d'accès, le sous-réseau en 10.8.0.0/24 mais cela ne marche pas mieux et là je sèche vraiment. Il doit pas manquer grand chose que je ne vois pas ... D'où ma demande d'éclairage. Une idée peut-être ? Cordialement oracle7😉

@TuringFan Avec le recul, maintenant que j'ai testé la connexion OpenVPN, je dirais qu'il n'y a pas photo pour moi, avec "SSLVPN" et donc avec le VPN dans la plage d'@IP locales, j'ai bien accès à TOUS mes périphériques et applications des NAS depuis l'extérieur en connexion VPN. Connexion que j'estime sécurisée car seul moi avec des "xxxxx.ndd.tld" peut accéder à toutes ces ressources grâce au reverse proxy qui lui marche dans cette configuration. Il est vrai que je ne peux en dire autant sous OpenVPN, mais c'est sûrement un problème de configuration que je n'ai pas encore identifié. Excuses-moi de ne pas être d'accord, le client lourd d'OpenVPN n'a de lourd, selon moi, qu'en ce qu'il lui faut en plus un fichier de configuration pour fonctionner. Certes ce fichier permet plus de réglages mais pour une utilisation lambda comme nous le faisons, cela me paraît suffisant. A part cela, ce n'est jamais aussi qu'une interface de connexion et en cela, "SSLVPN" est plus simple car ce n'est qu'une interface très dépouillée qui fait la même chose : réaliser la connexion VPN. Pas besoin de plus ... Normalement ce sera réglé lorsque tu auras configuré le reverse proxy. Rien de compliqué, le Tuto est vraiment bien fait et clair. Tu t’apercevras aussi qu'il est d'une redoutable puissance mais je te laisse le découvrir. Cordialement oracle7😉

@TuringFan et pour info @GrOoT64 Juste une remarque quant à la configuration d'Open VPN sous VPN Plus. C'est peut-être l'origine du problème mais sans aucune garantie ! Je m'explique : Si tu configures OpenVPN en choisissant le protocole TCP (*) (comme j'ai cru le comprendre au travers de tes copies d'écrans précédentes), il te faut alors dans le parefeu modifier la règle système installée par défaut avec VPN Plus sur le RT. C'est à dire pour cette règle : Sélectionner la ligne correspondante dans le parefeu et modifier (ou 2xClic) Dans "Destination / ports / Sélectionner dans une liste d'applications intégrées", cliquer sur Sélectionner Désactiver la ligne correspondant au port 1194 et valider 2 x OK Dans le parefeu, créer un règle nommée par ex "1194_TCP" Dans "Protocole" sélectionner "TCP" Dans "Destination / Adresse IP" : sélectionner SRM Dans "Destination / Port / Personnalisé" : saisir 1194 et valider 2 x OK Voilà c'est tout. Pourquoi cette manipulation ? Essaies de créer un règle dans le parefeu en activant uniquement (ne pas faire d'autres réglages que celui-ci) dans "Destination / ports / Sélectionner dans une liste d'applications intégrées" la ligne correspondant au port 1194 pour l'application VPN Plus. Tu verras alors de retour dans le parefeu que le port 1194 est ouvert pour le protocole UDP et non pas en TCP comme tu le voulais initialement : Cela est à ajouter aussi au fait que si tu veux utiliser le protocole TCP pour OpenVPN, il te faut aussi modifier le fichier de configuration "VPNconfig.ovpn" et adapter la commande "proto" pour remplacer "proto udp" par "proto tcp". Voilà si çà peut t'aider à avancer. (*) Deux liens d'information vis à vis du choix de protocole TCP/UDP pour OpenVPN : Le premier un peu simpliste et le second beaucoup plus détaillé (mais en anglais, c'est pas ma langue maternelle et c'est plus dur 🤪), qui expliquent pourquoi choisir l'un plus que l'autre. Sachant que par défaut c'est UDP qui est proposé à l'installation du protocole OpenVPN par les applications. Dans le cas du NAS, je crains que l'encapsulation de TCP sur TCP ne soit la source des problèmes rencontrés mais ce n'est que mon interprétation .... Je te laisses en tirer les conclusions qui s'imposent. Mais les deux utilisations sont possibles. __________________________________ EDIT_1 : Comme je suis aussi un peu joueur et curieux à la fois, je viens d'installer OpenVPN pour voir. Voici mon retour : 1er constat : impossible de choisir la plage d'@IP local. j'ai le message : "Les sous-réseaux 'OpenVPN' et 'Local Network' se recouvrent" lorsque j'essaie d'affecter la plage d'@IP locale à l'objet 'OpenVPN'. Du coup, je lui ai affecté la plage "10.8.0.0/24". 2 ème constat : par rapport à la configuration initiale du fichier "VPNconfig.opvn" j'ai dû rajouter la commande "dhcp-option dns 10.8.0.1" 3 ème constat : pour la première connexion depuis mon smartphone android, lors de la création du profil de connexion OpenVPN, j'ai du indiquer un certificat et j'ai donc sélectionné mon certificat wilcard LE. Enfin, la connexion OpenVPN s'établit sans problème (vue sur VPN Plus serveur avec une @IP en 10.8.0.6), j'arrive à me connecter sur mes NAS 1&2 en tapant simplement "nom-du-nas1/2.ndd.tld" dans un navigateur sur le smartphone. Mais, eh oui il y a un mais, cela n'aurait pas été drôle sinon 🤥, je n'arrive pas à me connecter directement aux applications des NAS (file, surv, audio, ou même directement aux caméras, etc...) via "xxxxx.ndd.tld". Tout se passe comme si le reverse proxy ne fonctionnait pas et là je sèche ... Donc pour ce dernier cas, je reste ouvert à toutes suggestions de résolution. EDIT_2 : Détail intéressant à relever, ce qu'auparavant, j'avais interprété et donc pris pour un bug, n'en serait, peut-être bien au final, pas un (le doute reste toutefois). En effet, durant mes tests de connexion, j'ai eu aussi bien des connexions (vues sur le smartphone) en IPv4 et UDPv4 qu'en IPv6 et UDPv6 et ce sans rien modifier mais toujours avec une @IPv4 privée en 10.8.0.6 affichée et dans les deux cela marche. Allez comprendre ... Cordialement oracle7😉

@GrOoT64 Pas de problème, c'est fait... Cordialement oracle7😉

@Jeff777 Bonjour, IL y a une solution au problème pour générer un wilcard Let'sEncrypt "GRATUIT", c'est la méthode dite "acme" que j'ai décrit ici et qui marche chez moi. Seul truc pour l'instant, c'est qu'il faut surveiller la date de renouvellement pour faire celui-ci "à la main" et recharger ensuite le certificat sur le NAS/Routeur. De toutes façons, mis à part que SSLforFree nous prévenait par mail de l'échéance, il fallait avec eux aussi re-générer le certificat pour le recharger manuellement après. Donc pas de changement notable avec "acme" dans la pratique. Y-a plus qu'à attendre qu'une bonne âme fasse un script qui automatise cela. Cela dit il y avait bien une base de script initiée et décrite ci-avant dans le Tuto par @unPixel et @PPJP qu'il suffirait de reprendre et d'adapter, pour ma part mes connaissances du moteur du NAS sont encore trop insuffisantes pour réaliser cela même si je me débrouille en shell. Donc s'il y a des amateurs ... @.Shad. Tu ne pourrais pas nous faire un Tuto (au moins une trame de principe, détaillée) sur ta méthode (qui semble intéressante au demeurant) car rien que le mot "Docker" pour sa mise en œuvre, en effraie encore plus d'un ici. Moi le premier ... Cordialement oracle7😉