Rechercher dans la communauté

Bonjour à tous, Sur mon réseau local, j'ai 2 PC windows qui utilise Drive client sans difficulté. Par contre, impossible d'utiliser l'application Android (en local), j'ai les erreurs suivantes : - Saisie adresse IP du NAS avec le port 192.168.1.x:6690, j'ai un message d'erreur concernant le certificat SSL - Saisie adresse IP du NAS SANS le port 192.168.1.x : j'ai un message d'erreur indiquant de contrôler que le nas est bien connecté ou que ports 443 et 5001 ouverts Et ça fait quelques heures que je tourne sans trouver la solution ... Pouvez vous m'aider ?

6690 c'est le port de transfert des données sur les client desktop. Tu accèdes comment à l'interface Drive ? via DSM ? proxy inversé ?

bonjour Mic Merci pour ces précisions ! j’ai ouvert dans ma Bbox les ports 5000, 5001,443, 80 et 6690 avec redirection vers mon ip statique du NAS 192.168.1.159 qui est correct car retrouvée dans la liste des ip utilisées dans mon routeur je crains qu’il y ait un paramètre erroné quelque part … mais ou ? si vous avez d’autres idées n’hésitez pas Oui le test de connexion affiche en vert « normal’

Il faut que vous fassiez dans la bbox les redirections de ports dont vous avez besoin. Tout dépend des services que vous utilisez, mais de ce que j'ai compris, vous vous connectez via le 5001. Ce port doit donc être dirigé vers l'IP du NAS. Si vous utilisez Synology Drive, il faut aussi rediriger le port 6690. Etc... Si votre adresse est en synology.me, le ddns est géré par synology. Dans le service ddns du NAS, est-ce que le test de connexion est OK ? A partir d'où ? de votre réseau privé ? de l'extérieur ?

Donc déjà ça montre qu'il n'y a pas de résolution DNS locale dans ton réseau, à ce titre tu y gagnerais beaucoup en suivant ce tutoriel : Dans ton cas, pour accéder d'un périphérique A à un périphérique B sur ton réseau local, l'IP publique de ta box est sollicitée. Car ne sachant pas vers quoi pointe localement drive.ndd.fr, ton périphérique A s'en remet aux serveurs publiques, qui lui disent que ça pointe chez toi 😄 Le NAT Hair-pinning (appelé aussi parfois loopback), permet à une box de se rendre compte qu'une requête a priori publique provient en fait d'un réseau interne, pour atteindre un périphérique d'un réseau interne, la requête fait donc un "demi-tour" (d'où le terme d'épingle - hairpin) pour revenir au sein de ton réseau. J'ai tendance à penser que la succession de routeurs au sein de ton réseau pourrait perturber ce procédé (pour autant que ta box en soit capable). Lorsque tu es sur les data, ça se passe ainsi : drive.ndd.fr -> résolution publique -> pointe vers l'IP publique : * requête port 443 ? ==> reverse proxy -> interface web * requête port 6690 ? ==> NAS -> transfert de données Drive En local : drive.ndd.fr -> résolution publique (car pas de réso. locale) -> pointe vers l'IP publique -> ? La méthode la plus simple pour moi : Créer un certificat dédié via DSM (par exemple pour le ndd gratuit fourni par Synology) associé aux services Synology non proxiables (Hyperbackup, Drive (données), etc...) ==> nas.toto.synology.me Modifier le fichier hosts de ton Windows (C:\Windows\System32\drivers\etc) et y inclure la ligne : 192.168.10.5 nas.toto.synology.me et c'est le ndd que tu devras mettre dans ton client Synology Drive Windows Quant à la meilleure méthode, elle consiste à mettre en place une zone DNS locale qui permette de faire du split DNS, en gros lorsque tu es en local tu résous localement (avec les IP privées) tes noms de domaine, et en dehors de ton réseau, les mêmes noms de domaine se résolvent publiquement. Ça permet au final : d'avoir les mêmes noms de domaine où qu'on soit de ne pas devoir effectuer la modification sur chaque poste client d'être indépendant des serveurs de nom publiques

Tu parles d'un point de vu parefeu du routeur openwrt? Si c'est le cas oui la règle niveau pare feu c'est: Transfère le trafic IPV4 TCP entrant du WAN via le port 6690 vers le port 6690 du NAS en LAN dont l'ip est 192.168.10.5 Si je me met en partage de co depuis ma 5G pas de soucis par contre depuis mon wifi ça ne fonctionne pas 😕

Hello, content que ça réponde à ton besoin. drive.ndd.fr pointe vers ton proxy ou ton NAS ? car le ndd doit pointer vers le NAS pour le trafic qui passe par le port 6690. Ce que tu peux faire passer par le proxy c'est l'interface d'accès à Drive.

Bonjour, Ça fait un moment maintenant que mon NAS et les services associés tournent grâce à la configuration conseillée dans ce tutoriel. Et pour cela, merci. Aujourd'hui, je poste parce que je rencontre des problèmes qui dépassent mes compétences réseau et ma compréhension du sujet. Pour contextualiser, j'ai dû me mettre dans une configuration réseau un peu particulière pour le télétravail. Dans ce contexte, le routeur de mon FAI est resté en mode routeur, il fournit le réseau local (192.168.0.X) pour mes appareils tels que téléphone, ordinateur, etc. Pour segmenter le réseau (et ajouter de la difficulté...), j'ai activé une DMZ vers un routeur OpenWRT derrière lequel se trouve mon serveur NAS (192.168.10.X). Côté redirection de port, mon routeur OpenWRT redirige le port 80 et 443 vers le reverse proxy (192.168.10.145) et le port 6690 directement vers l'IP locale de mon NAS (192.168.10.5). Dans ce contexte, je rencontre deux problèmes liés au client Synology Drive : Quand je tente de me connecter via le nom de domaine, je me retrouve avec une erreur de certificat SSL. Avez-vous une idée d'où cela pourrait venir ? Je ne parviens pas à accéder au client Synology Drive via le nom de domaine depuis mon réseau LAN, mais c'est OK si je me connecte depuis un accès Internet. Auriez-vous des pistes ? Pour rajouter des éléments quelque sorties telnet: Depuis le LAN: telnet drive.ndd.fr 80 Trying IP_PUBLIC... Connected to drive.ndd.fr. telnet drive.ndd.fr 6690 Trying IP_PUBLIC... telnet: connect to address IP_PUBLIC: Operation timed out telnet: Unable to connect to remote host telnet drive.ndd.fr 6691 Trying IP_PUBLIC... telnet: connect to address IP_PUBLIC: Connection refused telnet: Unable to connect to remote host Depuis l'extérieur: telnet drive.ndd.fr 80 Trying IP_PUBLIC... Connected to drive.ndd.fr. telnet drive.ndd.fr 6690 Trying IP_PUBLIC... Connected to drive.ndd.fr.

Comme je l'ai écrit plus haut, le port par défaut et celui de l'application. En l’occurrence, c'est le 5001. Même si vous invoquez le nom de domaine pour rejoindre votre NAS, le port par défaut reste toujours le 5001. En clair, si vous n'entrez que nas.toto.synology.me, l'application DS le transformera en nas.toto.synology.me:5001. Cette requête n'aboutira pas car votre reverse proxy ne sait pas l'interpréter. Raison pour laquelle il faut préciser le port 443. En revanche, si vous utilisez l'application Drive ou Photo, vous pouvez dans ce cas ne pas préciser le port car ces deux applications ne fonctionnent qu'avec leur port par défaut (6690 pour Drive, 80 et 443 pour Photo)

Perso, j'utilise Keepas en SFTP (SSH) sur mon Smartphone et Drive sur mes PC (quoique je pourrais très bien utiliser SMB via OpenVPN) sur ces derniers . En fait, je m'aperçois qu'à l'usage je n'utilise que le Smartphone. Mais bon, vu que le port 6690 est ouvert pour les synchro entre NAS , surtout ne pas bouder son plaisir Bon je reconnais que l'usage de ssh n'est pas trivial, mais ayant utilisé ce protocole durant toute ma carrière .....

Oui, je pense que ce serait préférable, tu peux choisir la rotation de type Smart Recycle ou en faire une personnalisée. Si ta base de données tourne dans les 50 Go, même un forfait Google One fera très bien l'affaire, l'avantage de C2 par contre c'est son intégration dans DSM. Tu peux utiliser un VPN oui, ou simplement en direct ? Il suffit de rediriger le port 6690 TCP de ta box vers ton NAS, et autoriser ce port dans le pare-feu pour l'IP de ton cabinet, ou ton pays si pas d'IP fixe. Je n'ai rien contre le VPN mais ça me semble overkill si c'est juste pour de la synchronisation Drive. Si ton NAS est protégé derrière un onduleur ça peut vivre très longtemps, les pannes les plus fréquentes à terme sont la pile à changer ou le bloc d'alimentation qui lâche, les deux sont réparables. Avec des sauvegardes tu es tranquille de toute façon. Si c'est le NAS qui lâche il suffira de le changer et d'y remettre les disques dans le même ordre pour repartir Si un disque lâche tu as un disque en spare il faudra reconstruire le RAID, si tes deux disques lâchent la sauvegarde est dans le cloud prête à restaurer les données.

Bonjour j'ai localisé plusieurs nas chez moi qui doivent synchronisés différents sites distants avec Syno Drive. je m'explique : j'ai différents clients, donc différents sites distincts, chez qui j'ai installé Syno drive sur leur serveur Windows, qui doivent synchronisés les données sur différents nas installés chez moi. Le pb étant qu'ils utilisent tous le port 6690, est il possible de modifier ce port sur l'appli Windows afin de dispatcher convenablement les données de chaque client sur le nas dédié ? merci par avance de votre aide.

Bonjour merci à tous les deux pour vos réponses. oui, effectivement, avant de voir vos réponses j'ai configuré sur chaque Nas un ID Quickconnect différent (comme les clients sont différents ça tombe bien !!) et cela fonctionne. Syno drive se connecte directement au bon nas sans modification de redirection du port 6690. j'avais été induit en erreur par un message d'erreur sur un des Drive d'un serveur m'annonçant un pb de droit sur un dossier de destination 😉 merci encore bonne année et meilleurs voeux !!

Non. C'est le port dédié à Drive et il est fixe. Je ne suis pas sûr que ce que vous envisagez soit faisable. Votre configuration est loin d'être standard. Il y aurait éventuellement le reverse proxy mais pas évident qu'il puisse fonctionner avec le 6690 à cause du protocole (http ?, https ?) Ou alors via quickconnect à condition bien entendu qu'il soit possible d'avoir plusieurs comptes sur la même IP publique. Et là encore, pas du tout sûr que cela fonctionne. Attendre d'autres avis. Sinon, il faudrait vous adresser directement au support.

Bonjour j'ai un serveur joplin qui fonctionne parfaitement depuis des mois. J'essaie aujoud'hui de monter un serveur de notifications gotify en docker. Mais il semble qu'il y ait un conflit entre les deux, sans que j'arrive à comprendre où. Voici le docker-compose de joplin : version: '3' services: db: image: postgres:13.1 # Download latest postgres image container_name: postgres-db # Here you can give the container a name of your liking restart: unless-stopped # Restart if not stopped manually volumes: - /volume1/docker/joplin/joplin-data:/var/lib/postgresql/data # Make database files persistent. Otherwise your data is lost when the container is destroyed. environment: - APP_PORT=22300 # Specify port joplin-server is reachable at - POSTGRES_PASSWORD=****** # Specify database password - POSTGRES_USER=****** # Specify database user - POSTGRES_DB=joplin # Specify database name app: image: joplin/server:latest # Download joplin-server image 2.2.5 the latest at the time container_name: joplin-server labels: - com.centurylinklabs.watchtower.enable=true depends_on: - db ports: - "22300:22300" # Expose internal port to LAN restart: unless-stopped environment: - APP_BASE_URL=https://joplin.**********.fr # If you do not want to expose joplin-server to the internet use your LAN-IP and port - DB_CLIENT=pg - POSTGRES_PASSWORD=****** # Must be the same as above - POSTGRES_DATABASE=joplin # Must be the same as above - POSTGRES_USER=******* # Must be the same as above - POSTGRES_PORT=5432 # Postgres internal port - POSTGRES_HOST=db Voici le docker-compose du serveur gotify : version: "3" services: app: image: gotify/server container_name: gotify restart: unless-stopped ports: - 127.0.0.1:8764:80 environment: - TZ='Europe/Paris' - GOTIFY_DEFAULTUSER_NAME=admin - GOTIFY_DEFAULTUSER_PASS=admin - GOTIFY_PASSSTRENGTH=10 - GOTIFY_UPLOADEDIMAGESDIR=data/images - GOTIFY_PLUGINSDIR=data/plugins volumes: - ./data:/app/data Lorsque j'essaie de monter le conteneur gotify, voici le retour en ligne de commandes : root@DS220:/volume1/docker/gotify/script# docker-compose up -d [+] Running 5/5 ⠿ app Pulled 9.3s ⠿ 00d3338ddf14 Pull complete 3.5s ⠿ 557ea8465e9a Pull complete 4.6s ⠿ 3ecb6f16884e Pull complete 5.5s ⠿ 793754435704 Pull complete 6.6s WARN[0009] Found orphan containers ([sabnzbd sonarr radarr jellyfin postgres-db watchtower]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. [+] Running 1/2 ⠿ Container joplin-server Recreated 39.9s ⠼ Container gotify Starting 6.4s Error response from daemon: driver failed programming external connectivity on endpoint gotify (a9b441ca577a1716274272aca0f4d30b8df97e992610938065568ad31b04d1fa): Error starting userland proxy: listen tcp4 127.0.0.1:8000: bind: address already in use root@DS220:/volume1/docker/gotify/script# Et donc je constate qu'il me recrée l'image joplin, et je ne sais pas pourquoi. Plus problématique : en fait, il le recrée, mais ça plante : je ne peux plus synchroniser avec les clients joplin. J'ai pensé à un problème de ports, alors j'ai cherché des conflits : root@DS220:/volume1/docker/gotify/script# netstat -tulpn | grep LISTEN tcp 0 0 0.0.0.0:662 0.0.0.0:* LISTEN 10076/statd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 9150/sshd: /usr/bin tcp 0 0 127.0.0.1:33304 0.0.0.0:* LISTEN 2004/synomibactiono tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 20407/postgres tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:892 0.0.0.0:* LISTEN 10052/mountd tcp 0 0 0.0.0.0:8989 0.0.0.0:* LISTEN 501/docker-proxy tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 13522/smbd tcp 0 0 0.0.0.0:8096 0.0.0.0:* LISTEN 419/jellyfin tcp 0 0 127.0.0.1:512 0.0.0.0:* LISTEN 29315/termd tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 29198/docker-proxy tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:161 0.0.0.0:* LISTEN 10516/snmpd tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN 3325/docker-proxy tcp 0 0 0.0.0.0:6690 0.0.0.0:* LISTEN 5194/syncd tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN 18872/transmission- tcp 0 0 0.0.0.0:10211 0.0.0.0:* LISTEN 26005/docker-proxy tcp 0 0 0.0.0.0:10212 0.0.0.0:* LISTEN 25963/docker-proxy tcp 0 0 0.0.0.0:7878 0.0.0.0:* LISTEN 32194/docker-proxy tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 29171/docker-proxy tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:5001 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 13522/smbd tcp 0 0 0.0.0.0:5357 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:4045 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 7439/rpcbind tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3351/docker-proxy tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 0.0.0.0:10002 0.0.0.0:* LISTEN 15980/nginx: master tcp 0 0 127.0.0.1:915 0.0.0.0:* LISTEN 23389/httpd24 tcp 0 0 0.0.0.0:51413 0.0.0.0:* LISTEN 18872/transmission- tcp6 0 0 :::662 :::* LISTEN 10076/statd tcp6 0 0 :::22 :::* LISTEN 9150/sshd: /usr/bin tcp6 0 0 :::3001 :::* LISTEN 23745/AdGuardHome tcp6 0 0 :::443 :::* LISTEN 15980/nginx: master tcp6 0 0 :::892 :::* LISTEN 10052/mountd tcp6 0 0 :::8989 :::* LISTEN 506/docker-proxy tcp6 0 0 :::3261 :::* LISTEN - tcp6 0 0 :::445 :::* LISTEN 13522/smbd tcp6 0 0 :::3263 :::* LISTEN - tcp6 0 0 :::8000 :::* LISTEN 29203/docker-proxy tcp6 0 0 :::3264 :::* LISTEN - tcp6 0 0 :::3265 :::* LISTEN 5859/scsi_plugin_se tcp6 0 0 :::2049 :::* LISTEN - tcp6 0 0 :::9090 :::* LISTEN 3331/docker-proxy tcp6 0 0 :::6690 :::* LISTEN 5194/syncd tcp6 0 0 :::10211 :::* LISTEN 26020/docker-proxy tcp6 0 0 :::10212 :::* LISTEN 25969/docker-proxy tcp6 0 0 :::7878 :::* LISTEN 32200/docker-proxy tcp6 0 0 :::9000 :::* LISTEN 29177/docker-proxy tcp6 0 0 :::5000 :::* LISTEN 15980/nginx: master tcp6 0 0 :::5001 :::* LISTEN 15980/nginx: master tcp6 0 0 :::139 :::* LISTEN 13522/smbd tcp6 0 0 :::5005 :::* LISTEN 17507/httpd tcp6 0 0 :::5357 :::* LISTEN 15980/nginx: master tcp6 0 0 :::4045 :::* LISTEN - tcp6 0 0 :::5006 :::* LISTEN 17507/httpd tcp6 0 0 :::111 :::* LISTEN 7439/rpcbind tcp6 0 0 :::8080 :::* LISTEN 3360/docker-proxy tcp6 0 0 :::80 :::* LISTEN 15980/nginx: master tcp6 0 0 :::10002 :::* LISTEN 15980/nginx: master tcp6 0 0 :::51413 :::* LISTEN 18872/transmission- tcp6 0 0 :::53 :::* LISTEN 23745/AdGuardHome root@DS220:/volume1/docker/gotify/script# Mais il n'y a rien qui me saute aux yeux. Une petite idée ? Merci

Je suppose que vous voulez parler de Synology Drive. Vous ne pouvez pas connecter plusieurs utilisateurs sur la même session windows. C'est une session, un compte. A mon avis, le plus simple est de créer une session pour chaque utilisateur où chacun peut se synchroniser à son dossier perso sur le NAS et gérer ses données personnelles. Pour le dossier commun, il suffit de rajouter à la connexion de chaque utilisateur une connexion du dossier commun du NAS vers le même dossier commun du PC. Il faut bien entendu que ce dossier commun soit en dehors du dossier "User" du PC, à un emplacement où tous les utilisateurs peuvent lire/écrire des données. A la racine du disque "C" par exemple. Ainsi, tout utilisateur qui se connecte à sa session retrouve ses données persos dans sont compte de session et les données communes sur le dossier commun. Si le "à distance" concerne le même PC, tout devrait fonctionner de la même manière. Si c'est sur des PC différents l'approche est la même puisque les dossiers sont synchronisés. Il faudra toutefois attendre la fin de la synchronisation pour retrouver les dernières modifications effectuées sur les autres postes. Les accès externes ne peuvent toutefois se faire qu'à la condition que les accès au NAS soient correctement paramétrés (ouverture du port 6690 entre autres choses). Pour les smartphones et tablettes, vous avez l'application Drive qui vous permet de vous connecter à votre compte.

Salut, petit update. Je suis de retour en France ( chez NAS1 😁 ) du coup j'ai pu refaire quelques tests. Entre temps, j'ai ouverts les ports ( 5000, 5001, 6690 ) sur la box du NAS2, et j'ai verifie via le site donne par @.Shad. qu'ils etaient bien detectes comme ouverts. Aussi, j'ai upgrade l'abonnement de 100 Mbps a 300 Mbps sur la box du NAS2. De retour a la maison donc, j'ai reparametre Drive Sync sur NAS1 pour qu'il joigne le NAS2 via nas2.dsmynas.com au lieu d'ID quickconnect. Connexion etablie avec succes 🤩 J'ai donc relance un test de telechargement et voici les resultats: Méthode DriveSync: 3 min pour télécharger sur NAS1 + 4 min ou il ne se passait rien ( icone de "sync en cours" mais aucun mouvement reseau ) + 19 min pour sync sur NAS2 ( vitesse moyenne sync 12 Mo/s ). Total 26 min Méthode CloudSync: 3 min pour télécharger sur NAS1 + 4 min pour upload sur Google Drive + 14 min pour sync sur NAS2 ( vitesse moyenne sync 25 Mo/s ). Total 17 min On note donc que la vitesse de synchro sur la methode Drive a ete x3 par rapport au precedent test ( 59min de sync ), ce qui est coherent avec le nouvel abonnement passe de 100 a 300 Mbps. Par contre, toujours un temps de retard par rapport a la methode Cloud. Bon, ces temps sont completement acceptables pour moi, merci encore pour m'avoir guide jusqu'ici. Maintenant c'est juste de la curiosite de demeler tout ca. Sur ma Freebox donc les ports ne sont pas ouverts, et detectes comme fermes par le site yougetsignal, pourtant j'arrive bien a acceder a nas1.dsmynas.com ( alors que j'avais une erreur timeout auparavant, et je n'ai rien change depuis... curieux ). J'ai fait la demande d'IPv4 full stack a l'instant, tant pis pour la penibilite 😛 On va voir si ca change quelque chose avec le port 6690 ouvert au prochain test. Merci

Alors, depuis j'ai au moins testé d'ouvrir les ports pour le NAS2, n'ayant pas de limitation sur ce reseau, mais par contre en utilisant ton site pour verifier après coup, ça me dit 'Port is Closed' ( testé avec 5000 et 6690 ). Peut être ai-je mal fait la manip? Voici l'interface sur le routeur: Merci

Si ton NAS n'est pas joignable par les moyens usuels via QuickConnect, alors un relais est établi via les serveurs de Synology pour faire transiter les données, donc la lenteur constatée en est sûrement l'origine. Les ports 5000 et 5001 sont pour DSM, avec son bureau. Toi ce qui t'intéresse ici c'est uniquement la synchronisation des données, et celle-ci se fait par le port TCP 6690. C'est un port hardcodé, le NAS qui va initier une synchro tentera de joindre le domaine:6690 ou l'ip:6690, si tu veux pouvoir synchroniser d'un NAS1 à un NAS2 il faut que ce port soit accessible de part et d'autre sur tes box. Je ne réside pas en France, mais de ce que j'ai pu lire il n'a pas l'air aussi difficile que tu as l'air de le penser de demander une IP full stack. Pour le changement de ports, voir mon message ci-dessus.

Merci @.Shad. ! Tu penses donc que ça peut être cette histoire d'ID quickconnect qui limite la vitesse de transfert pour la méthode DriveSync? ( pourtant pas d'incidence avec methode Cloud ). Autre question, pour l'accès au domainexxx.dsmynas.com, il me semblait que c'etait les ports 5000 et 5001 qui étaient en jeu? ( meme si 6690 aura surement aussi son utilité ). J'ai jeté un coup d'oeil car c'est du chinois pour moi ces histoires de ports, mais ça a l'air d'être un joyeux bordel sur les freebox ( NAS1 ), avec le besoin de faire une demande à Free d'une IP full stack pour pouvoir gérer es ports inférieurs à 36000... Du coup je me demandais si je pouvais changer les ports 5000/5001/6690 sur le nas pour des ports genre 41000, afin de pouvoir les gérer sans trop de bazar? Pour cela sur DSM je vois plusieurs endroits ou il semble qu'on puisse modifier les ports 5000 et 5001 mais je ne comprends pas trop la différence: Paramètres > Système > Portail de connexion > DSM Paramètres > Connectivité > Accès Externe > Configuration du routeur Paramètres > Connectivité > Accès Externe > Avancé 🤔 Par contre je vois rien pour 6690. Merci !

@thepopol777 Est-ce que tu as bien fait la redirection de port pour le port 6690 en TCP sur chacune des box vers les NAS respectifs ? Car la connection refused c'est typiquement une redirection non fait et/ou un pare-feu mal réglé. Assure-toi que dans le pare-feu de chaque NAS le port TCP 6690 est ouvert au monde entier le temps d'un test, et que les redirections sont correctement faites, puis tu vas sur https://www.yougetsignal.com/tools/open-ports/ et tu testes depuis chaque NAS si l'ouverture du port est ok :

Le plus simple est d'utiliser Synology Drive Sharesync, il synchronise des dossiers partagés entre plusieurs NAS. Et tu peux choisir le sens de la synchro. Synology Drive ShareSync | Synology Drive Server - Synology Centre de connaissances Si tu utilises une connexion distante directe (= pas de QuickConnect), il faudra faire de la redirection du port 6690 en TCP sur la box "distante" vers le NAS2. Même chose côté "1" si NAS1 peut recevoir des données en plus de les transmettre.

Bonjour à tous, Étant un newb sur les Synology, je me permet de poser ma question à la communauté 🙂 Je possède actuellement un Syno avec le paquet Synology Drive accessible depuis le WAN avec les ports classique : Mon problème se pose lorsque j'essaie de mettre un deuxième Synology Drive Server sur un deuxième appareil du même réseau accessible depuis le WAN. Je peux bien modifier les ports du DSM et donc faire mon NAT en conséquence pour le deuxième appareil : Sauf pour le port 6690 utilisé par le Synology Drive que l'on ne peut modifier dans l'interface de gestion du Synology ni sur la partie client du logiciel, je n'arrive pas à indiquer un port spécifique. Avez-vous déjà rencontré cette problématique ou avez-vous un piste pour contourner ce problème ? En vous remerciant, Maxence P.

Bonjour, Hum petite chose déplaisante : Je vois aujourd'hui dans aiprotect de mon routeur asus : Il faut ignorer celles du 07 juin.. Je n'ai jamais d'alertes de ce genre. j'ai pourtant les pare feu d'actifs avec comme seuls ports ouverts à la france (80/443) (1984/6881) pour bittorent et 6690 pour drive. mon serveur impose l'utilisation de l'HTTPS avec un certificat let's encrypt du nas, je reverse proxy vers un pc NUC qui heberge emby serveur, vers mon routeur et vers un docker adguard. Sur le routeur, le NAT est réglé également assez restrictif ( 80/443/1984/6881/6690) Je n'ai donc rien d'exposé en direct et tout passe par des sous domaines en 443 via synology Depuis ce week end, j'ai installé en docker home assistant et je suis en train de bidouiller pour le tester.. mais il n'est pas accessible hors réseau local Comment traiter ces alertes ? quelles vérifications faire et quels corrections apporter ? merci

Si c'est du reverse proxy dont vous parlez alors vous avez probablement laissé des lignes sur le bas côté. Reprenez le complètement et normalement tout devrait fonctionner. Si ce n'est pas le cas, prière de reprendre la discussion directement à la suite du tuto. Le reverse proxy vous permet de ne pas avoir à utiliser d'autres ports que le 80 ou le 443 et vous évite de surcroit d'ouvrir d'autres ports que ceux-ci dans le routeur (sauf ports spécifiques à certaines applications comme par exemple le 6690 pour Drive). Donc déjà atteindre audio station en utilisant un port autre que le 80 ou 443 démontre que vous avez ouvert des ports qui ne le devraient pas puisque c'est le reverse proxy qui se charge des redirections en interne. Je verrouille ce sujet.