Rechercher dans la communauté

"je veux bien voir un screen de l'endroit où tu modifies le port de transfert de données de Drive" Ben c'est l'une des photos d'écran : celle de la freebox. Pour le gain de sécurité, ça me paraissait opportun : tout le monde sait que le 6690 est le port utilisé par synology pour ses applis... maintenant je viens de lire l'inverse sur le forum, alors...

Je ne vois pas le rapport entre tes impressions d'écran et mes questions, j'ai bien compris que tu faisais du NAT x6690 -> 6690. De plus tu ne réponds pas à ma question :

Je veux bien voir un screen de l'endroit où tu modifies le port de transfert de données de Drive. 🙂 Si c'est dans Portail des Applications tu n'as pas compris ce que je t'ai dit alors. Ton plan marcherait si tu pouvais définir un port personnalisé de manière bilatérale. Vu qu'on parle de synchronisation avec Drive, comment le serveur en retour sait-il qu'il doit contacter ton périphérique sur le port 26690 ? Lui il cherche le port 6690 de ton périphérique, quand il tombe sur le pare-feu du service informatique, il est bloqué actuellement. De plus, un intérêt particulier à changer le port ? Imposé par le service informatique ? Il n'y a aucun gain de sécurité à faire cela. Pour vérifier l'ouverture d'un port, tu peux utiliser nmap ou telnet.

Je m'explique : - le NAS chez moi a son port configuré en standard 6690 - j'ai mis une translation de port : 26690 vers 6690 sur le routeur chez moi, donc pour accéder depuis l'extérieur, faut accéder au port 26690 - j'accède depuis mon "drive client" du téléphone et de ma tablette vers le drive de mon NAS en tapant l'adresse IP + le port dans les informations de connexion de l'appli comme suit : "xx.xx.xx.xx:26690" et ça fonctionne très bien - j'essaye de mettre en place le drive client au boulot sur Windows, mais ça ne semble pas marcher. Je me demande si le Synology Drive Client sous Windows accepte ou non les ports customisés comme le port 26690. Ca marche sur iPhone, mais est-ce le cas sous Windows ? Le problème est que je ne peux pas faire d'essai et tâtonner au boulot. Je dois demander l'ouverture de ports sortant au coup par coup, et ça prend un mois pour que la demande soit prise en compte... En ayant demandé l'ouverture du 26690, je pensais que ça fonctionnerait puisque j'y accède depuis mon smartphone mais apparemment non... à moins que le service n'ait pas ouvert le port demandé. Donc 2 questions : - y a-t-il moyen de vérifier que le port 26690 a été ouvert ou non ? - Est-ce que quelqu'un peut m'indiquer si on peut changer le port par défaut de Synology Drive client sous Windows ou faut-il que je passe impérativement par le port standard 6690 ? Mais dans ce cas, je ne vois pas à quoi peut servir la possibilité de mettre un port customisé sur le nas si le client ne peut pas le prendre en compte... MERCI !

Il y a deux choses différentes : l'interface Drive accessible depuis DSM, via port personnalisé ou proxy inversé. Ça on peut le modifier. Puis tu as le transit des données, qui se fait via le port TCP 6690 comme l'a dit @pluton212+. Pour synchroniser à distance ce port doit être redirigé vers ton NAS depuis ta box. Et ouvert dans le pare-feu du NAS. Pour une utilisation locale, il suffit qu'il soit ouvert dans le pare-feu. L'adresse à entrer dans Synology Drive Client est juste l'IP publique ou le DDNS ou nom de domaine qui pointe vers cette IP, sans préciser de port. EDIT : A noter que pour une utilisation combinée locale et externe, tu peux utiliser un serveur DNS local pour ne pas avoir à changer l'adresse du NAS.

Bonjour, pour que drive fonctionne il faut ouvrir le port 6690 dans le routeur et le diriger vers le nas. Vous devriez vous pencher sur le tuto du reverse proxy pour éviter d'ouvrir trop de ports et finalement utiliser les ports 80-443 (6690).

Merci à toi pour la réponse ! Le port 6690 est autorisé sur le pare-feu mais je ne me souviens plus si j'ai testé avec le :443 à la fin de l'URL. Je vais faire un tour sur la page de présentation 😉 Bonne soirée Popoff

@popoff 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 et de ses équipements. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... C'est une particularité et un fait, mais avec les applications DSxxx, il te faut ajouter le port 443 à l'URL de connexion, par ex : audio.ndd.tld:443, file.ndd.tld:443, etc ... Dans le cas particulier de drive, il te faut aussi ouvrir/autoriser le port 6690 dans le pare-feu du NAS. Drive en a besoin pour son fonctionnement interne. Cordialement oracle7😉

En quoi c'est normal ? Tu as dit : Si le proxy inversé est sur le NAS1, drive aussi bien que video.alexisg.com doivent pointer sur le proxy inversé. Là tu sollicites le port 443 du NAS2, y a rien dessus donc il te renvoie le port DSM du protocole demandé, ici HTTPS... On s'en balance du certificat sur NAS2 sauf pour les services non proxiables du NAS2 comme le transfert de données Drive sur le port 6690, Active Backup for Business, etc...

Bonjour @oracle7 et @.Shad., Avant tout bonne année ! Merci pour vos réponses très utiles. Très clair. Visiblement notre première interprétation était la bonne selon @.Shad. Ok. Et sauf erreur de ma part ces ports sont listés ici. Par ailleurs dans la gestion des applications sur le NAS il est possible de choisir un unique port en HTTP et/ou un unique port en HTTPS : je comprends donc qu'il s'agit ici uniquement d'un accès via portail Web donc et que cela n'a rien à voir avec les clients (PC et/ou mobiles). Est-ce exact ? Par ailleurs d'un point de vue purement théorique il n'y a aucune contre indication à changer le port du moment que l'on reste cohérent dans l'URL utilisé pour atteindre la cible ou la source du reverse proxy (si on en a un) mais en pratique c'est est déconseillé car cela introduit une complexité de gestion sans apport véritable de sécurité (scan de port très rapide). Est-ce Exact ? Enfin je crois comprendre que l'on peut choisir à sa convenance le HTTP ou le HTTPS pour la source et le destination du reverse proxy mais que l'on opte souvent pour une source en HTTPS et une destination en HTTP (pour ne pas double chiffrer et donc préserver de la performance tout en étant sécurisé). Il existe néanmoins quelques exceptions comme par exemple (la seule que je connais pour le moment) Vidéo Station qui doit utiliser du HTTP car le transcodage fonctionne mal en HTTPS. Réponse apportée par @.Shad. ci-dessous. Merci, je vais faire cette lecture. Petite question subsidiaire alors : mon port 6690 est ouvert sur mon NAS et transféré par mon Routeur (en DMZ de ma LiveBox fibre) j'ai un reverse proxy (sans condition de profil) sur mon NAS dont la source est le port HTTPS 443 et la destination le localhost sur le port 10002 en HTTP dans mon client Drive pour PC la cible indiquée est "drive.ndd.tld:6690" dans mon client Drive pour mobile la cible indiquée est "drive.ndd.tld" Aucun problème d'accès via le portail web et/ou le client mobile via une IP WAN/VPN/LAN en revanche sur le client PC la synchronisation ne se fait qu'en IP VPN/LAN, impossible en IP WAN ! Pourquoi ? Si mon hypothèse précédente sur l'utilisation exclusive d'un reverse proxy pour le HTTP/HTTPS et donc un portail web est juste cela veut il donc dire que je dois utiliser une autre cible dans mon client PC tel que "nas.tld.ndd" (qui pointe vers l'interface du NAS) et/ou ndd.tld qui résout mon IP externe via mon DDNS ? Pour info j'ai essayé cela sans succès aussi. J'ai donc remonté ce point au support Synology et je suis en attente d'un retour concret. Évidement, j'aurais dû y penser ! L'interface de mon NAS : le DSM. Pardon, mal formulé. Je souhaitais savoir d'une façon générale quel format doit avoir l'URL demandée dans la fenêtre de connexion des clients : faut il préciser http/https, le port, etc. ? Tu as donc répondu après et je comprends qu'il faut toujours construire l'URL sans le http/hhtps, avec l'IP externe (ou le domaine) et avec le numéro de port. Merci encore à vous deux, NB : Je vous prie de bien vouloir m'excuser par avance si je dérive trop par rapport au sujet initial et si ce post n'est pas au bon endroit. Dans ce cas indiquez moi ou le mettre et je le déplacerais.

Quand un périphérique A met dans sa DMZ un périphérique B, tous les ports qui ne sont pas par ailleurs redirigés par A vers un autre périphérique sont redirigés automatiquement vers B. Donc il n'y aucun besoin de faire du NAT pour un périphérique dans une DMZ, c'est redondant et donc inutile. Pas que je sache, tout simplement parce que certaines requêtes émises à l'extérieur de ton réseau s'attendent à trouver un port donné à destination : 25, 587, etc... Ca dépend d'où tu regardes, depuis un PC local rien n'empêche de le bypasser pour les applications Synology. En IPv4 depuis l'extérieur le NAT remplit ce rôle de frontend. Je crois qu'il y a un gros malentendu sur la définition de port sécurisé, le port HTTPS l'est par défaut pour de la navigation. Le port 54256 peut parfaitement l'être aussi... tant que j'ai un certificat serveur à opposer au client, muni ou non d'un certificat lui aussi. Un peu de lecture : http://www.steves-internet-guide.com/ssl-certificates-explained/ Le port 6690 utilisé par Synology Drive se fait sur base d'une transaction TLS, donc le transfert des informations est chiffré. C'est que le routeur fait une redirection automatique, case que l'on conseille de décocher dans le NAS quand on met en place un proxy inversé. Pour le NAS, nas.ndd.tld est sensé t'amener vers quoi ? Je n'ai rien compris. 😝 Si le port de l'application que tu souhaites atteindre est différent du port de base (le cas de toutes les applications DS sauf DS Photo), il faut le préciser car si tu ne mets rien, les applications DS chercheront à atteindre le port dédié. Le domaine que tu entres dans l'applications DS ne suit pas la convention de navigation où pas de port en http = 80 et pas de port en https = 443.

Bonjour à tous et joyeuses fêtes de fin d'année, J'ai suivi ce tutoriel avec succès mais je me permets je me rends compte aujourd'hui qu'après avoir pensé le comprendre à l'époque je n'en avais qu'une vision partielle. Je viens donc affiner ici ma compréhension du sujet. Je ne m'attends pas à une réponse exhaustive sur toutes mes questions mais agrégats des morceaux de réponses des uns et des autres me permettra d'avancer. Description de ma configuration : FAI : Orange fibre particulier via Livebox (IP dynamique) Routeur Synology en DMZ de ma LiveBox avec redirection de ports dont 80 et 443 NAS Synology derrière le routeur avec ports ouverts dont 80 et 443 Serveur DNS avec définition d'une zone locale sur le Routeur avec des redirections de type A depuis des URL en "service.ndd.tld" vers le NAS Zone DNS publique définie chez mon Registrar (OVH) avec les redirections équivalentes : de type CNAM depuis des URL en "service.ndd.tld" vers "ndd.tld" DynDNS définie chez mon registrar (OVH) et sur mon Routeur Web station installé sur le NAS Redirection HTTP vers HTTPS désactivée sur le NAS HTTP/2 activé sur le NAS Reverse proxy qui passe en entrée soit par le port HTTP 80 soit par le port HTTPS 443 puis pointe vers des ports HTTP pour chaque service (avec parfois une restriction de profil qui impose une IP VPN/LAN) J'ai également un fichier php à la racine de Webstation (/web/index.php) : <?php $http_host = $_SERVER['HTTP_HOST']; // 307 Temporary Redirect header("Location: https://$http_host",TRUE,307); exit; ?> Mes questions : Est-ce utile d'avoir un DDNS chez OVH et sur mon routeur ? Mon routeur étant en DMZ de la Livebox est-il nécessaire de créer sur ma Livebox des règles de transferts de ports type NAT/PAT ? Je pensais initialement que non mais je commence à douter au regard de mes dernières lectures. Si oui et dans l'hypothèse de vouloir atteindre un service hébergé sur mon NAS faut il (i) créer des règles de transfert vers mon routeur qui possèdera lui même les mêmes règles de transfert vers le NAS ou (ii) créer des règles de transfert directement vers mon NAS ? J'accède souvent à mes services via différents canaux : portail web et/ou clients mobile et/ou clients PC. Je croyais que le reverse proxy permettait une redirection "totale" des flux or je commence à comprendre (i) que les clients mobiles/PC demandent parfois l'ouverture de ports spécifiques en plus du reverse proxy (ex : port 6690 pour Drive sur PC) et que (ii) même avec un accès portail web fonctionnel pour un service, des ports spécifiques doivent parfois être ouverts pour permettre la pleine utilisation du service (ex : activation des ports SMTP / IMAP / POP3 pour l’hébergement d'un serveur de messagerie). Est il possible de tout faire passer par le port de reverse proxy (y compris 6690, SMTP/IMAP/POP3 dans mes exemples) ? Est-il possible de "court-circuiter" l'entrée en HTTPS du reverse proxy pour atteindre les applications via ces ports spécifiques qui sont peut être moins sécurisées ? On dit souvent le port HTTP est moins sécurisé que le port HTTPS grâce aux mécanismes de certificats. Qu'en est il de ces ports spécifiques : sont ils plus ou moins sécurisés que les ports sources HTTP/HTTPS du reverse proxy ? J'accède via mon reverse proxy et le port HTTPS à DSM (interface du NAS) via "nas.ndd.tld" et à RSM (interface du Routeur) via "rt.ndd.tld" et j'ai remarqué qu'en tapant "rt.ndd.tld" dans un navigateur cela fonctionnait sans problème et que la redirection vers "https://rt.ndd.tld:8001" se faisait automatiquement. En revanche en tapant "nas.ndd.tld" j'arrive vers une page d'erreur de Web Station : je dois alors taper "https://nas.ndd.tld" pour que cela fonctionne. Pourquoi une t-elle différence de comportement ? Pourquoi l'URL du Routeur fait elle apparaitre un numéro de port et pas celle du NAS ? In fine, dans l'hypothèse ou je souhaite pouvoir atteindre mes services hébergés sur le NAS indifféremment depuis le WAN/VPN/LAN. Quelles sont les règles que je dois utiliser dans les champs URL des navigateurs et dans les formulaires de connexions des clients PC/mobiles ? J'ai en effet tendance à utiliser "service.ndd.tld" systématiquement mais je constate pour les clients que parfois le port doit être précisé et parfois "nas.ndd.tld" est suffisant : pourquoi ? Merci d'avance à tous,

Merci beaucoup de m'avoir aidé! Après avoir remplacé le certificat Let's Encrypt en ajoutant les sous noms de domaine des applis et après avoir appliqué un double chiffrement dans le proxy inversé pour Video Station (port 443 vers port HTTS local de Video Station), tout fonctionne! Je peux me connecter à toutes les applis. Merci à toi, effectivement il y avait eu une erreur lors de ma première manip, cette fois ci je vois bien *.ndd.synology.me et ça fonctionne aussi bien qu'avant. Je reviens vers toi par rapport à ce que tu m'avais dit @.Shad. J'ai configuré le NAS en serveur VPN également pour accéder à DSM à distance. L'intérêt pour moi c'est de ne pas rediriger le port spécifique DSM dans ma box. Lorsque je me connecte avec OpenVPN ça fonctionne. En entrant l'adresse IP Locale 192.168.X.X ou l'adresse VPN 10.8.X.X, j'arrive à DSM. Par contre, que ce soit en wifi local ou en VPN via 4g, lorsque je rentre le nom de domaine ndd.synology.me, je n'aboutis à rien. Les applications configurées dans le proxy inversé fonctionnent toutes. C'est uniquement pour accéder à DSM par cette voie qu'il y a un soucis. Est ce que cela est dû au fait que je passe par l'extérieur à cause de la résolution DNS interne de mon ndd synology.me justement? Parmi les solutions que tu énonces: Comment savoir si ma box fait du loopback? Le tuto DSN Server a l'air hors de ma portée, surtout concernant la partie publique Comment modifier les fichiers host des clients? Sur la box je ne redirige que les 2 ports du proxy inversé, le port 6690, le port 16881 et le port OpenVPN. Je ne fais pas celui de DSM. Idem dans le pare feu, j'ai décoché celui de DSM et je n'autorise que les ports précédents. Merci encore!

Oui mais tu vois on a pas le détail de ces ports. On sait uniquement que ce sont des ports pour audio station et video station et qu'ils sont différents des ports de l'application (1900, 5000 et 5001) Dans mon autre topic je demande justement à quoi ils servent. Je pensais que 6001-6010 ne correspondait qu'au Airplay. Etant donné que je n'ai pas d'appareils Apple, j'ai décidé de ne plus les traiter. Sauf qu'apparemment ça enlève aussi les périphériques chromecast! Je ne les vois plus apparaitre sur mon téléphone dans audio station, uniquement "le nom de mon téléphone". Je les ai re-natté et ré-autorisé et c'est revenu... Je pense donc que ces ports autorisent plus que Airplay. J'en ai profité pour re-traiter 9025-9040 car je ne voyais plus les périphériques dans video station non plus. D'ailleurs concernant les périphériques distants, je me suis aperçu d'un truc dingue. Lorsque je me connecte à audio station avec un compte admin, je vois les périphériques DLNA mais pas les périphériques chromecast (alors qu'avec DS audio sur smartphone je vois les 2). MAIS SURTOUT, si je me connecte avec un compte utilisateur qui a accès à tous les dossiers du nas et toutes les applications, je ne vois plus aucun périphérique!!!!!! Uniquement "Mon ordinateur". J'ai refait le test en faisant appartenir cet utilisateur au groupe administrateur également et là je peux voir les périphériques DLNA... J'y comprends rien. Idem dans Video Station, il faut un compte administrateur pour voir les différents périphériques de lecture!! Et alors pourquoi les périphériques chromecast ne sont visibles que dans l'appli smartphone... Mystère!! Sinon à propos de DS video j'ai du nouveau. Dans la configuration du proxy inversé j'ai fait en sorte de ne passer qu'en HTTP via le port 80 et le port spécifique HTTP de video station. J'ai essayé avec le smartphone en me connectant en HTTP comme ça et ça fonctionne... les films sont lus. Il y a donc un soucis quand je me connecte en HTTPS. Voici mes règles de pare feu: 1/ Je refuse toutes les communications venant de Chine/ Mali/ Côte d'Ivoire, etc 2/ J'autorise tout le trafic provenant d'une connexion depuis VPN Serveur 3/ J'autorise tout le trafic provenant des sous-réseaux de Docker. 4/ J'autorise tout le trafic provenant des appareils de mon réseau local. 5/ J'autorise les ports de certaines applications en les sélectionnant directement dans la liste (ports 80, 443, 5001, openVPN, NTP, 6690, 16881, 6001-6010, 9025-9040, transferts de fichiers windows) 6/ J'autorise le port spécifique SFTP (je désactive cette règle lorsque je ne m'en sers pas) 7/ Je refuse tout le reste Je pense que c'est OK

Merci pour ces précisions. J'avais trouvé cette fameuse liste synology mais ils ne renseignent pas sur la fonction de ces ports. Si tu me dis que c'est uniquement de la communication interne alors je vais supprimer la redirection et l'autorisation dans le pare feu. Merci beaucoup. Sur cette liste on ne fait pas mention des ports en dur à activer pour certaines applications (16881 pour download station, 6690 pour le drive). Je n'avais pas compris tout de suite que le soucis venait du fait que je n'avais pas traité ces ports. Je pensais que le problème était identique pour Video Station mais visiblement non. Je continue de chercher, merci pour tes éclaircissements!

Merci Shad pour tes réponses à mes 2 posts. Oui c'est ce que j'avais fini par comprendre lorsque j'ai traité (natté et autorisé) les ports 6690 et 16881 en plus des ports 443 et 80. Certaines applications clientes communiquent avec le serveur via des ports spécifiques "en dur". C'est pour cela que drive et download station refonctionnent désormais. Je suis content de voir que j'étais sur la bonne piste 🙂 Dans ce post je me demande justement quels seraient ces autres ports spécifiques qui m'empêcheraient d'utiliser mes applications avec ndd synology.me correctement si je ne les traite pas: C'est très intéressant ce que tu dis car en passant par le DDNS synology.me pour me connecter depuis mon WiFi local, j'avais constaté aussi que c'était comme si je passais à l'extérieur. Si je ne traite pas les ports réseau correspondants, je ne peux plus accéder à rien alors qu'en me connectant via IP locale j'ai accès à tout. Personne ne m'avais confirmé cela et je te remercie de tes explications. Je n'ai pas forcément tout compris aux diverses solutions que tu énonces: je ne sais pas ce que c'est que du loopback mais je vais me renseigner. Ma box est une SFR (redbox) plus. Est ce que je peux mettre en place un serveur DNS local sans acheter un nom de domaine? Modifier le fichier host des clients me semble compliqué. Surement que sur PC c'est pas très complexe mais sur android ou android TV c'est trop difficile je pense. Tu ne saurais pas quelle est l'utilité des ports 9025-9040 et 6001-6010 / 6011-6030 par hasard? J'ai essayé et sur l'ordi portable en tout cas ça fonctionne. Les films se lisent. Par contre rien sur smartphone ou tablette (vlc tourne dans le vide) et android tv ne veut toujours pas accéder à l'application à cause de certificat non fiable. snif

Bonjour et merci pour vos nombreuses réponses. Je pense que je prends la question dans le bon sens mais je l'ai mal posé. Ce post fait référence à un autre post que j'ai posté ici sur le site: J'ai suivi le tuto sécurisation du NAS déjà (il est vraiment très bien fait et très bien adapté pour un débutant en réseau comme moi) et j'ai donc autorisé les communications vers les IP privées. Comme je l'ai dit dans l'autre post, j'ai configuré un reverse proxy et c'est justement pour ça que je me pose la question de l'utilité de ces ports. En proxy inversé, j'ai traité uniquement les ports des applications (ports 80 et 443 redirigés par la box et autorisés dans le pare feu) sauf que, comme Kramlech n'a signalé: ces applications sont devenues inopérantes à l'extérieur à cause d'une communication des clients sur un serveur via un port spécifique. Drive ne se synchronisait pas puisque je n'avais pas traité le port 6690. Idem pour download station car je n'avais pas traité le port 16881. Lorsque je ferme un paquet et que je le relance, DSM me demande d'autoriser certains ports dans mon pare feu. Je me connecte au NAS avec un nom de domaine synology.me donc en DDNS. Ceci fait en sorte que je me connecte comme "à l'extérieur" même si je suis en wifi local. Si je ne traite pas les ports spécifiques de ces applications, elles seront inutilisables (elles se lancent mais aucune donnée ne transite) En redémarrant le paquet Video Station par exemple (que je veux utiliser à l'extérieur), DSM me suggère d'autoriser les ports 9025-9040 dans le pare feu. Quand je redémarre Audio station ce sont les ports 6001-6010 udp et 6011-6030 tcp. Quand j'active le service SMB, ce sont les ports 37,138,139,445. En reverse proxy, Video Station ne lit plus de film. Voilà pourquoi je demande à quoi servent ces ports que DSM me demande d'autoriser dans le pare feu. Si ce sont aussi des ports spécifiques pour autoriser une communication entre les clients et un serveur, ça expliquerait pourquoi ça ne fonctionne plus. Mais je ne voudrai pas traiter ces ports (les natter et les autoriser dans le pare feu) si j'en ai pas besoin pour lire un film depuis l'extérieur ou diffuser une musique Comme l'a dit Kramlech, la liste est finalement longue: VPN, SSH, Mail, Torrent, FTP, Drive,... J'utilise HyperBackup, open VPN, SSH, SFTP... et j'aimerai que tout fonctionne en DDNS avec mon nom de domaine synology.me. c'est pour ça que j'aimerai savoir à quoi ces ports peuvent servir et si c'est utile ou non que je les redirige ou autorise.

Ce n'est pas la solution universelle ... Si le client veut communiquer avec le serveur via un port "codé en dur", le reverse proxy ne te sera d'aucune utilité (exemple : le client Synology Drive qui communique avec le serveur Drive via le port 6690... Ne pas rediriger ce port empêchera toute synchronisation - problème récurent pour beaucoup de personnes qui partent sur la solution de Reverse Proxy)

Ne pas confondre l'interface de gestion de Drive, qui est exposé sur le port 10002 par défaut lorsque tu actives un port personnalisé, et le port par lequel les données sont synchronisées entre les clients et le serveur : 6690. Pour les connexions extérieures il faut évidemment rediriger vers le NAS, vu que le NAS n'est pas directement accessible. Si tu ne rediriges pas, Drive va chercher à se synchroniser sur le port 6690 de la box ou du routeur, il ne trouvera rien. Donc le NAT est nécessaire, et il est donc également nécessaire d'autoriser ce port dans le pare-feu. Même chose pour Download Station, il ne faut pas confondre le port sur lequel l'interface est exposée, et le port par lequel tu vas télécharger ou uploader. L'autre problème que tu rencontres est que lorsque tu tapes ton ndd Synology, tu pointes sur ton IP publique, tu passes par l'extérieur car ta résolution DNS interne ne permet pas de savoir que c'est le NAS que tu cherches à atteindre. Il y a plusieurs solutions à ce problème : - avoir une box qui fait du loopback, visiblement ce n'est pas ton cas. - mettre en place un serveur DNS local. - modifier le fichiers hosts de tes clients. Au passage, le pare-feu du NAS ne bloque pas les connexions sortantes (voir ta première phrase) mais seulement entrantes. Il est très rare de vouloir restreindre les ports utilisés par une machine pour communiquer vers une autre.

Alors justement j'avais redirigé uniquement les ports 80 et 443 à partir de ma box internet car effectivement j'avais vu que le reverse proxy permettait d'accéder à ces applis à partir uniquement du port 443 en https. En me connectant à l'aide de https://appli.ndd j'arrivais bien sur chaque application. Mais certaines étaient inutilisables comme le drive où j'ai dû ouvrir et rediriger le port 6690 (qui est différent du port de l'application synology drive) et le port 16881 pour download station (qui est différent également du port de l'application) J'ai ouvert et redirigé également les ports 6001-6010 et 6011-6030 parce qu'ils servent à audio station apparemment et 9025-9040 qui servent à video station aussi. Je ne sais pas si c'est utile de les rediriger certains peuvent juste être ouverts dans le pare feu je pense. Si je savais à quoi ils servent je saurai lesquels fermer ou ne pas rediriger. Idem pour le 6690 et 16881 je ne suis pas sûr qu'il faille les rediriger. Juste les ouvrir dans le pare feu devrait suffire. J'ai ouvert et redirigé le port openVPN également mais ça c'est normal pour utiliser le vpn comme tu l'as dit D'accord je comprends. Donc si le drive ne fonctionnait pas ça n'était pas lié à une connexion extérieure puisque je suis sur mon wifi local. Pourtant le pare feu bloque les connexions vers l'extérieur c'est cela? si je suis en local, pourquoi ouvrir le port 6690 pour que cela fonctionne alors? Idem si je coupe le port 5001 je ne peux plus accéder au nas à partir de https://ndd.synology.me:5001. En local pourtant ça devrait fonctionner non?

Merci beaucoup pour ta réponse! Le soucis est pour après car dans videostation j'ai accès à ma bibliothèque mais je ne peux lire aucun film. Dans download station je peux ajouter un téléchargement mais rien ne se lance. Sur le drive client de W10, je ne peux plus me connecter à l'aide de drive.ndd.synology.me, on me dit connexion impossible. Je peux accéder à plex par plex.ndd.synology.me mais en me connectant à dsm avec mon nom de domaine, si je clique sur l'îcone plex serveur, on m'envoie sur une addresse ndd.synology.me:32400 qui est le port de plex mais la page se s'affiche jamais puisque je l'ai redirigé vers plex.ndd.synology.me. Voilà pourquoi je demandais s'il n'y avait pas moyen de changer le lien du raccourcis. Et justement, je viens d'ouvrir avant ta réponse les ports de synology drive server tcp 6690 du pare feu du NAS (et non de synology drive qui est utilisé en reverse proxy sur le port 443) et celui pour le téléchargement tcp 16881 (et non le port de download station qui est utilisé sur le port 443) et j'ai redirigé ces ports dans la box et les 2 refonctionnent! Le drive se connecte et se synchronise et je peux lancer un téléchargement. Je pense vraiment qu'au delà de l'accès à l'application (port 443) il fallait aussi ouvrir les ports du flux de données à travers le pare feu et la box. Par contre j'ai encore un soucis avec video station. aucune vidéo ne se lit Sur une box android tv, on me refuse de me connecter parce que le certificat n'est pas fiable... J'ai lu d'autres posts sur le sujet mais je patine. Une idée? Effectivement j'ai lu que la redirection automatique http vers https de DSM cassait le reverse proxy donc je l'ai décoché

¨Pour Drive, c'est le 6690 qu'il faut ouvrir dans le routeur et à autoriser dans le parefeu. Vérifiez aussi que vous n'avez pas activé la redirection http vers https. Cette redirection bloque le fonctionnement du reverse proxy.

Bonjour, dans le routeur/box il faut rediriger le port 6690 vers le nas.

Quelque soit le port, à partir du moment tu as un proxy inversé en frontend qui peut rediriger vers l'application voulue, il n'y a aucune raison de continuer à exposer ce port. Dans certains cas, on est obligé, le proxy inversé ne fonctionne par exemple pas pour le transit des données vers Drive (6690) et là tu es obligé d'ouvrir ce port vers l'extérieur si tu souhaites pouvoir synchroniser des données à distance. Même chose pour Active Backup for Business. Les connexions restent malgré tout sécurisées car chiffrées de bout en bout, simplement le protocole exige de devoir discuter en direct avec l'application, et pas avec le proxy inversé.

Bonjour, Je suis débutant en réseaux et en NAS. J'ai suivi différents tuto (dont celui-ci qui est super) et je me retrouve aujourd'hui avec un pare feu qui impose une IP LAN ou VPN pour tous mes ports (dont le port DSM) sauf pour les ports 80, 443, (renouvellement de certificat LE et reverse proxy) et les ports 16881, 6681 et 6690 (liés à l'installation de BT et Synology Drive Server). Coté reverse proxy, mes redirections vers certaines applications "clefs" utilisent un profil qui impose une IP LAN ou VPN, la redirections vers d'autres applications moins critiques (vidéos, audio, photo, etc.) se fait sans filtrage des IP. J'ai par ailleurs activé le DoS, une redirection forcée du HTTP vers le HTTPS via Web Station (HSTS désactivé donc). Dois je encore effectuer certaines actions pour mieux me protéger, notamment les ports cités ci-dessus ? Dans l'état actuel de ma configuration, quels sont mes risques ? Merci d'avance,