Mic13710

Ca n'a pas de rapport à mon sens. Le lien généré dans file station utilise uniquement les paramètres des options avancées. Par contre, le rapport avec le reverse proxy peut être lié à l'url qui permet de rejoindre file station. Raison pour laquelle j'avais dit de donner un nom d'hôte plus explicite qui soit relié à file station (file.xxxxx.synology.me) et de paramétrer ce nom dans le portail des applications pour qu'il soit associé à file station. Mais comme visiblement ça n'a intéressé personne...

Désolé mais ce n'est pas très clair. Quelle synchro ? quelle sauvegarde ? Avec quel(s) paquet(s) ? Vers quels clients ?

Non, carrément vous ne suivez pas ce que je vous ai dit. Cette liste n'est que le résumé d'un post précédent où je donne exactement ce que vous devez faire. Donc, non, vous ne faites pas ce qu'il faut pour que ça marche. Comme il a été dit par les intervenants ci-dessus, le 443 est le port https invoqué par défaut en l'absence de port spécifique. Donc, normalement, le 443 ne devrait pas être intégré dans le lien. S'il l'est, c'est que vous avez forcé un autre port pour l'https. Comme je vous l'ai dit dans mon premier message, ça ne sert pas à grand chose si ce n'est à se compliquer la vie. Mais vous pouvez les changer si ça vous rassure. Et de grâce, épargnez moi la musique du non sachant. Quand la marche à suivre vous est donnée avec tous les emplacements où vous devez intervenir, ça ne tient pas la route. Vous savez ce qu'il vous reste à faire... Une question, comment testez vous vos liens, à partir de votre LAN ou à partir de l'extérieur ?

Je me demande pourquoi je me tue à expliquer trois ou quatre fois la même chose si vous vous évertuez à faire différemment ☹️ Je vous parle du port 443, vous vous entêtez à continuer avec un port exotique. Désolé mais tant que vous ne suivrez pas à la lettre ce que je vous ai dit, j'abandonne.

Normal que le lien avec le numéro de port fonctionne si vous ne l'avez pas supprimé et remplacé par le 443. C'est que vous avez oublié des paramétrages. 443 vers NAS dans le routeur 443 autorisé dans le parefeu du NAS Nom d'hôte file.blabla.synology.me et port https 443 file.blabla.synology.me comme nom de domaine pour file station dans le portail de connexion Avec cela, je ne vois pas pourquoi ça ne fonctionnerait pas

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Bonjour @ScamPs , soyez le bienvenu sur ce forum.

Votre lien ne fonctionne pas mais peu importe. Est-ce que xplanepilotecontrole.synology.me est le nom de domaine enregistré chez synology ? Si vous ne voulez pas que le port apparaisse dans le lien, le seul moyen direct est de passer par le port https par défaut (443). Il faut dans la box diriger le port 443 vers le NAS et autoriser ce port dans le parefeu. Pour le nom d'hôte, il est préférable de donner un nom spécifique. Je vous avais proposé file.xplanepilotecontrole.synology.me parce que le lien est rattaché à file station mais vous pouvez choisir un autre nom lié au domaine enregistré chez synology :<le nom que vous voulez>.xplanepilotecontrole.synology.me - Port https : 443. Rien dans http ou bien le 80 mais surtout ne pas l'ouvrir de l'extérieur vers le NAS et ne pas l'autoriser dans le parefeu. Et pour que ce nom d'hôte soit lié à file station, il faut l'indiquer dans DSM. Panneau de configuration/Portail de connexion onglet Applications. Pavé File Station. Domaine personnalisé : vous mettez le nom d'hôte complet que vous avez donné (<le nom que vous voulez>.xplanepilotecontrole.synology.me) et vous enregistrez. Normalement, tous les liens que vous créerez seront de la forme : https:\\<le nom que vous voulez>.xplanepilotecontrole.synology.me\sharing\abcdefghi Erratum : contrairement à ce que j'avais supposé plus haut, les liens existants ne peuvent toujours pas être modifiés dans DSM mais il fonctionnent quand même en remplaçant l'ancienne en-tête par la nouvelle, par exemple : ancien lien : https://xplanepilotecontrole.synology.me:1235/sharing/BjGRzcpo5 nouveau lien https://<le nom d'hôte>/sharing/BjGRzcpo5

Les liens partagés existants ne sont pas modifiés après la manip. Ce n'est pas dynamique. Ce seront seulement les nouveaux liens qui le seront. Vous ne pouvez pas non plus modifier les liens déjà créés directement dans DSM mais normalement, si vous modifiez l'appel de vos liens existants en conservant la suite /sharing/xxxxx ça devrait fonctionner. Par exemple votre ancien lien https://tuile.synology.me:1234/sharing/PiLu1Ntr devrait fonctionner en https://file.tuile.synology.me/sharing/PiLu1Ntr Edit : Après vérification, DSM autorise maintenant la modification des liens dans le gestionnaire. Vous pouvez donc corriger les en-têtes de chacun des liens existants, mais si vous en avez beaucoup, le travail risque d'être fastidieux. Si la modification de l'en-tête fonctionne côté client, il ne sera pas nécessaire de la faire dans le gestionnaire ou du moins de la faire en urgence. Ou alors vous supprimez les anciens liens et vous les recréez avec les réglages donnés plus haut. Cela revient au même car il faudra de toute manière modifier les liens clients. Edit 2 : liens accessibles mais non modifiables

Pas plus que le 443. Tout port ouvert expose le point terminal (ici le NAS). Ce n'est pas le port le problème. Ce qui est important c'est d'abord que les ports ouverts vers l’extérieur soient chiffrés (https, sftp, ..) et que les protections soient mises en place pour bloquer toute tentative. Cette idée que changer les numéros de ports par défaut protège des attaques relève du voeux pieux. Il est très facile de trouver les ports ouverts pour une ip donnée. Personnellement j'ai conservé les ports par défaut et je n'ai pas plus de tentatives d'intrusion que n'importe qui. Si vous ne voulez pas voir le numéro de port et avoir une adresse du style https://file.tuile.synology.me/sharing/PiLu1Ntr il faut modifier l'en-tête de vos liens. Pour cela, Panneau de configuration/Accès externe/Avancé : nom d'hôte : file.tuile.synology.me ou un autre ndd (toto.tuile.synology.me) - port https : 443 Il faudra bien évidemment ouvrir dans le routeur le 443 vers le NAS et modifier le parefeu pour qu'il autorise ce port.

Bonjour @Karnagy, soyez le bienvenu sur ce forum.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Belle initiative 👌 C'est tout de même bien dommage de cantonner le NAS à cette seule tâche. Un modèle J eut été largement suffisant et aussi moins gourmand en énergie. Vous pouvez lui en demander beaucoup plus sans que cela ait un impact sur les téléchargements dont la seule vraie limitation sera votre connexion internet. Je ne saurais trop vous recommander de vous intéresser aux nombreuses possibilités offertes par votre NAS. Photo, musique, cloud, docker, serveurs VPN, DNS, multimedia, applications de sauvegarde et tant d'autres choses, je suis sûr que vous découvrirez des fonctionnalités qui faciliteront la gestion et l'utilisation de vos données personnelles et celles de votre famille. A vous de voir.

Je viens de voir que vous aviez rajouté après coup la capture d'écran demandée dans le message du deuxième pdf. Je ne l'avais pas vue lors de ma première lecture (logique puisqu'elle n'y était pas à ce moment là). La seule interface qui m'intéressait était celle qui comportait les règles. Si les seuls ports utilisés sont les 1234, 4567 et 15231 et qu'ils sont bien redirigés dans le routeur vers le NAS alors c'est bon. Petite remarque tout de même, vu le peu de services sollicités, votre DS723+ va tourner plus qu'au ralenti. Tant de puissance pour quelques téléchargements épisodiques, c'est un peu comme prendre la Ferrari pour aller chercher sa baguette de pain à la boulangerie du coin de la rue. Va falloir lui donner du grain à moudre sinon il va s'ennuyer grave 😉

Je ne vois pas ce qu'il y a de difficile à comprendre. Vous savez faire une capture d'écran (vous en avez fait plusieurs dans ce fil). Vous ouvrez la page de vos règles pour le LAN1 et vous faite une capture de l'ensemble de la page comme ceci : que vous postez ici.

Ce document est votre pense bête, il ne répond pas à ma demande.

Les images du pdf sont illisibles. Ce que je voulais voir c'est une copie d'écran de votre parefeu.

Vous faites fausse route. Le numéro attribué n'est pas un port. Postez un exemple de lien anonymisé (nom de domaine remplacé par toto.synology.me) pour qu'on y voit plus clair. Tout à fait d'accord, et pourtant .... Vous êtes têtu ou vous ne comprenez toujours pas comment fonctionne le parefeu. Encore une fois, si aucune règle n'est applicable, c'est la dernière qui bloque. Si vous avez sélectionné la France pour les IP de votre règle, toutes les applications autorisées par cette règle seront joignable à partir de la France (à condition bien entendu que les ports correspondants aient été dirigés vers le NAS il va s'en dire). Si vous avez cliqué sur refuser dans l'interface LAN1, alors tous les pays en dehors de la France seront bloqués sur cette interface. Pas besoin d'une règle supplémentaire. Plutôt que de longs discours, il serait préférable de joindre une copie d'écran de votre parefeu pour qu'on comprenne ce que vous avez fait.

Le fonctionnement du parefeu est comme je l'ai décrit dans mes messages à savoir : tout ce qui arrive sur le NAS est autorisé. Ensuite, le parefeu analyse l'interface de réception de la requête, le protocole, le port invoqué, la provenance de l'ip et balaye les règles une à une en commençant par la première. Si une règle n'est pas remplie, on passe à la suivante. Le balayage s'arrête si une règle est remplie, et si elle est autorisée, la requête est transmise au service concerné. Si elle est bloquante, la requête est rejetée. Sinon, on continue jusqu'à la dernière règle. A ce stade, rien n'est bloqué et tout est autorisé puisqu'il n'y a aucune règle bloquante. C'est donc la dernière règle dont je parle qui assure le blocage de toute requête qui n'a pas été couverte par une des règles. D'où l'importance de l'ordre des règles, la dernière étant toujours une règle de blocage. Si vos liens sont en https, ce que je suppose car ce sont en principe les liens générés par DSM (il faut voir l'en-tête du lien pour confirmer), alors il faut autoriser https pour les ip de France si c'est de que vous souhaitez. Ca peut être le 443 (port https par défaut) ou le 5001 (port de DSM qui peut aussi atteindre des services) mais ce n 'est pas forcément valable pour vous car il se peut que le lien utilise file station (port 7001) selon comment et dans quelle application il a été généré, auquel cas c'est ce port qu'il faudra autoriser. Vous seul pouvez le déterminer en analysant un de vos liens. Le blocage géographique c'est là : Vous sélectionnez France pour la règle pour laquelle vous voulez qu'elle s'applique. L'établissement des règles de parefeu sont intimement liées aux différentes applications et à la manière de vous y connecter : quickconnect, IP publique, nom de domaine dédié, reverse proxy, portail de connexion, changement des ports par défaut, etc.. tout ceci a une influence sur le parefeu. Aussi, ne connaissant pas vos paramètres je ne peux que vous donner des généralités. A mon avis, vous n'avez pas besoin de mariaDB s'il s'agit de seulement télécharger des liens, d'autant que vous n'hébergez pas de site web sur le NAS.

Il ne sert à rien de masquer des ip privées. Ni moi ni personne ne peut en faire quelque chose, exceptés ceux qui sont connectés à votre réseau. Pour MariaDB, c'est vous que ça regarde en fonction de ce que je vous ai dit plus haut. Je ne sais pas si votre application le nécessite ou pas. Mais si vous voulez bloquer les ip hors de France, il faut aussi le choisir dans les IP sources. Là, toutes les IP y ont accès. Si vous envoyez des liens de téléchargement, il faut que ces liens puissent s'ouvrir à distance. Il faut donc autoriser le protocole de connexion qui est utilisé. Pour le moment votre parefeu est une passoire et donc qu'il soit activé ou pas ne change rien : tout fonctionne sans blocage. Je ne vais pas le répéter à chaque post et ce sera la dernière fois : il faut impérativement une règle de blocage telle que décrite plus haut. Ne pas le faire inhibe toutes les règles de votre parefeu. Encore une fois, c'est expliqué dans le tuto et il serait judicieux de l'appliquer.

Personnellement, je ne recommande pas le renouvellement journalier de docker. Ca n'avait déjà que peu de justifications avec les premières versions docker (je ne l'ai jamais mis en pratique et ne m'en porte pas plus mal), ça n'en a plus aucune avec container manager qui facilite grandement la mise à mise à jour des containers. Il suffit d'aller de temps en temps vérifier l'état des versions et faire les mises à jour si besoin. Ce n'est pas parce qu'une version est remplacée par une nouvelle qu'elle ne fonctionne plus. J'ai certains NAS qui tournent avec de très anciennes versions et les renouvellements se font très bien. Donc, oubliez cette partie du tuto qui n'a aucun intérêt.

Pour commencer, il ne faut pas permettre à DSM d'écrire dans le parefeu. S'il vous le propose lors de l'installation d'une application, vous en prenez note et vous refusez. C'est vous et vous seul qui devez gérer le parefeu. En effet, il arrive que certaines règles automatiques viennent en contradiction d'autres et ça devient rapidement le bazar (ce que vous avez). Ne mettre que votre ip est bien entendu possible mais bien trop restrictif car les autres usagers de votre réseau privé risquent de se faire bloquer alors que le risque d'attaque venant de ce réseau est faible à nul, à moins que vous n'ayez aucune confiance en votre famille ou vos amis. Et si votre IP change, la règle devient caduque. Vous devez autoriser au moins la plage d'adresse de votre réseau privé (par exemple 192.168.x.0/24) à utiliser tous les ports. Vous pouvez aussi la réduire, selon votre besoin. C'est votre choix. S'il y a d'autres applications utilisant d'autres plages privées (VPN, Docker entre autres), il faut aussi mettre en place des règles pour ces plages. Ceci est clairement expliqué dans le tuto. Je ne vois pas de ligne tous dans vos captures. Ce qu'il faut c'est une règle en toute dernière ligne du profil pour tous les protocoles, tous les ports et toutes les IP qui refuse le trafic. C'est obligatoire pour ne pas avoir un parefeu qui ne sert...à rien. Le parefeu n'a rien à voir avec le système, DSM en l’occurrence. Il ne gère que le trafic rentrant. Donc, si vos requêtes externes ont besoin de maria db, alors oui, il faut l'autoriser. C'est vous qui devez définir quelle application ou quel service doit être joignable de l'extérieur étant bien entendu que le trafic local n'est lui pas limité grâce aux règles du réseau privé énoncées ci-dessus.

Pourquoi tous ces profils ? Je ne comprends pas. Le principe : on autorise ce que l'on veut et si on veut la France uniquement, on l'autorise explicitement. Et en dernier il faut impérativement une règle qui bloque ce qui n'a pas été autorisé. Sans cela, le parefeu est une passoire. Donc un seul profil, vous créez les règles d'autorisation, les règles peuvent bien évidemment couvrir plusieurs applications. Et vous rajoutez une dernière règle bloquante. Les règles sont balayées de la première à la dernière. Si une règle n'est pas applicable, on passe à la suivante. Ainsi de suite. Si une règle autorise, on arrête la lecture du parefeu.

Vous trouverez les réponses à vos questions dans le tuto sur la sécurisation de nos NAS.

Je vous invite à aller faire un tour du côté des tutoriels et surtout de mettre en pratique celui concernant la sécurisation de nos NAS. on y parle entre autre de nom de domaine et de certificat.