Rechercher dans la communauté

Bonjour à tous, J'ai un NAS Synology avec Synology Drive installé, que j'utilise depuis quelques années. Souhaitant éviter d'utiliser les ports traditionnels du synology depuis l'extérieur, j'ai configuré mon routeur pour que les ports 5000 / 5001 / 6690 /443 qu'utilise les services synology et tout particulièrement Synology Drive soit accessibles depuis l'extérieur via un "port forward" de ports exotiques. Bref, j'accède à mon synology drive depuis des ports exotiques genre 15000, 15001, 15443 et ces ports sont transférés sur mon réseau interne vers les ports standards du syno (les 5000, 5001, 443, 6690, .... Je peux accéder depuis l'extérieur sans souci depuis mon iPhone / ipad, etc... en mettant dans synology drive client l'adresse du serveur et le port comme dans tout navigateur pour y accéder (genre 82.12.66.45:15000). Par contre, pas moyen de faire la même manipulation depuis le Synology Drive Client sur PC, ça ne se connecte simplement pas. Est-ce qu'il y a moyen de vérifier si le port de Synology drive est bien mon port custom ? La syntaxe marche-t-elle ? Les ports exotiques fonctionnent sur l'appli Synology drive sur téléphone, alors pourquoi pas sur PC ? Peut on changer le port sur l'appli PC ? Merci !

Il faut effectivement voir dans les fichiers de config si effectivement ce port 6690 serait appelé par une variable, en ce cas ce serait facile. Si c'est hardcodé, ça semble compromis. En tout cas rien dans DSM ne permet de modifier ce port. De la redirection de port en sortant je m'en sers pour mes équipements IoT, pour que je sois sûr que ceux auxquels j'autorise un accès vers le net utilisent les DNS de mon choix. Mais ça necessite a minima un routeur semi-pro voir pro, ou un périphérique intermédiaire (Un Rpi pourrait servir d'intermédiaire entre le PC et le routeur de l'entreprise, au cas où on ne pourrait pas rediriger le port d'origine sur le client).

bonjour, je réagit à ce fil. Sur mon lieu de travail, la moitié des ports sont bloqué, comment puis je faire fonctionner le drive client si pas de 6690? J'ai bien essayer en proxy inversé, et passer par le port 443 pour relier le 6690, mais comme il est dit plus haut, le drive client ne le permet pas. Il y a un moyens hors vpn?

Bonjour. Oui c'est fait. La problématique était que même avec le port 6690 redirigé, les applications iOS ne connectent pas si le port de DSM (5001) a été changé, ce qui est mon cas. Si ça peut aider quelqu'un dans le même cas, j'ai pu contourner le problème avec le "portail de connexion" en utilisant mon nom de domaine.

Bonjour, il faut ouvrir le port "6690" pour la synchronisation des fichiers dans votre box/routeur et le diriger vers le NAS.

Il ne faut pas faire passer les connexions vers le drive (sur port 6690) par le conteneur SWAG, ça ne fonctionnera pas. Il faut envoyer directement sur le NAS lui-même. Depuis l'extérieur, c'est hyper facile : il faut juste que le port 6690 soit rediriger dans la box vers l'IP du NAS, et non pas l'IP du conteneur SWAG. En revanche pour un accès depuis le LAN, il faut faire une réécriture DNS dédiée à la sychronisation Drive (dans AdGuard Home, Pi-Hole, ou le serveur DNS (paquet DNS Server, zone locale du NAS). Sinon point de salut. J'ai ça comme réécriture DNS dans mon AdGuard Home : la première entrée, réécrit toutes les URL de mes noms de domaines vers l'IP LAN de SWAG (je l'ai mis en macvlan), et la seconde entrée réécrit le domaine spécial pour la synchronisation de Drive (donc pour les clients desktop) qui réécrit vers l'IP du NAS lui-même. En revanche, pour l'accès via navigateur au Drive, là ça passer par le reverse proxy, et mon .conf est : ## Version 2021/05/18 # make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url # Note for DSM Applications (Package) # As SWAG is installed in macvlan mode, you have to set the virtual IP for $upstream_app # set $upstream_app 192.168.2.230 server { listen 443 ssl; listen [::]:443 ssl; server_name drv.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; # GeoIP Blocking with Maxmind Docker-MOD include /config/nginx/maxmind-geoblock_and_LAN.conf; # Custom error pages include /config/nginx/error_pages.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.2.230; set $upstream_port 12345; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } }

Génial merci pour cette découverte ! A chaque fois je galéré pour héberger mes applications, obligé de se rappeler des ports de chaque. Maintenant c'est de l'histoire ancienne. Plus que 2 ports à ouvrir est c'est fini. Me reste une chose que j'ai pas bien compris et que je n'ai pas encore réussi. Comment faire pour transférer un port autre que pour du http ? (surtout pour drive et sont port 6690). J'ai suivi la technique de @MilesTEG1 a savoir créer un sous domaine spécifique pour drive et mapper le port 6690 à la place de 443. Mais sois j'ai pas compris une particularité sois ça ne fonctionne pas. port 6690 ouvert et redirigé sur le container, port ouvert sur le container, fichier de configuration qui redirige sur DSM avec le port 6690. Echec de la connexion sur drive. Merci

Je suis tout à fait d'accord avec ceci. Je n'ai aucune tentatives loguées dans DSM ou dans SRM. Mon NAS n'est exposé sur le net qu'avec le port 443 et 6690. Le routeur en frontal lui ne laisse passer que ces deux ports, mais reçoit les connexions VPN (OpenVPN, L2TP, et SSL VPN). Tous les deux (NAS et RT) n'acceptent que les IP FR. Alors je sais que je ne suis pas à l'abris d'une attaque depuis une IP FR qui est un VPN donc derrière un attaquant d'ailleurs, mais là je n'ai rien constaté. C'est vrai qu'ils devraient faire une communication... Mais les constructeurs se ressemblent tous, et ils attendent je pense d'avoir suffisamment d'éléments pour avertir... ou pas 😅

Faut surtout pas autoriser tout depuis toutes les IP en première ligne !! Perso, j'ai ces règles là : Et dans le pare-feu de mon routeur c'est encore plus restrictif : seuls les ports 443 et 6690 sont ouverts et routé vers le NAS.

Déjà, ce n'est pas le port 5001 mais le 6690 pour Drive. Si vous utilisez l'IP du NAS, alors ce n'est pas là qu'il y a un problème. Très probablement que votre PC, le PC de votre fils et le NAS utilisent le même tronc commun de votre réseau qui se trouve alors surchargé, ce qui expliquerait le ralentissement (il faut bien partager entre les utilisateurs). Essayez de dissociez si c'est possible le réseau de votre PC vers le NAS du réseau de votre fils vers la box.

@Einsteinium Ca fait longtemps que je n'ai pas testé sur le NAS, mais de mémoire ça marchait bien. @MilesTEG1 Mais de quelle application tu aurais encore besoin sur le 443 sur le NAS directement ? Tout passe par SWAG comme l'a dit @Einsteinium, ce qui ne passe pas par SWAG (Drive, HBK, etc...) passe par un port dédié (6690, 6281, etc...) et là il te faut un certificat pour ces applis là sur le NAS, méthode acme par Docker ou ndd Synology, peu importe.

Pourtant je pensais avoir compris 😅 la synchronisation fonctionne sur le port 6690 ça j’en suis sûr vu que ce port est nécessaire à ouvrir sur l’extérieur pour que ça fonctionne. les certificats sur le nas sont liés aux noms de domaines donc si tu utilises les noms de domaines tu utilises les certificats. Mais comme les noms de domaines .ovh pointent sur mon iP internet, depuis l’extérieur, je dois passer par le reverse proxy qui est maintenant swag, le tout passant uniquement par le port 443, port routé et dirigé vers swag. Donc même si j’utilise le nom de domaine synology, dsm.ndd.synology.me, il va arriver sur swag. Et swag n’a pas le certificat synology , donc ça va faire une erreur de sécurité. D’où ma question sur ton utilisation conjointe du ndd synology et ovh le tout passant par swag. A moins qu’il y ait un paramètre à mettre dans Swag pour permettre le transfert au nas du ndd tel quel, je ne comprend. pas. Je n’ai peut être pas des connaissances super développées en réseau mais je pense quand même saisir le minimum pour savoir comment on se sert d’un reverse proxy sur un unique port. Ce que je n’avais pas prévu car oublié, c’est le port de la synchronisation drive qui est 6690. Mais ça ne fonctionne pas en passant par le reverse proxy (ou alors j’ai mal fait mon fichier de configuration 😅). J’ai contourné le soucis pour le moment. Je pourriez essayer de mettre le nom de domaine synology sur drive, ou rentre de mettre drive.ndd.ovh pointant sur le nas directement via adguard (pour le lan). On peut tenter un vocal (discord je suppose 😁) faut que je vois tes dispos 😊 je te réponds là dessus en mp 😉

Bon, un jour à l'occasion, je te demanderais probablement de l'aide à ce sujet ^^ Mais là ce n'est pas la priorité. Si c'est une entrée de mon proxy inversé, et effectivement je n'avais pas prévu le bug. J'ai créé une nouvelle entrée : drive-sync.ndd.ovh avec ce fichier : ## Version 2021/05/18 # make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url # Note for DSM Applications (Package) # As SWAG is installed in macvlan mode, you have to set the virtual IP for $upstream_app # set $upstream_app 192.168.2.230 server { listen 6690 ssl; listen [::]:6690 ssl; server_name drv-sync.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.2.230; set $upstream_port 6690; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Mais ça ne fonctionne pas en local XD La seule solution que j'ai trouvé c'est de faire une réécriture du drive-sync.ndd.ovh vers l'IP réelle du NAS. Et là ça fonctionne mais que en local ! Si je suis à distance (via la 4G), ça ne fonctionne plus 😮 à priori même à distance en 4G 😉. Ça va mériter davantage de tests... J'ai laissé ACME fonctionner, donc j'ai encore les certificats pour mon ndd.ovh dans DSM 🙂 Mais on est d'accord que ceux-çi ne peuvent plus vraiment fonctionner ? puisque le port 443 sur lequel ils sont accessibles est redirigé sur SWAG. Donc si tu voulais utiliser le ndd synology, il faudrait que je précise un port et que ce dernier soit ouvert dans les parefeu, et routé vers le NAS dans le routeur, tu valides ce schéma ? Mais du coup, utilises-tu ton ndd synology comme ceci : service.synology.me:14443 Avec le port 14443 ouvert et transféré sur ton NAS ? (bon je me dis que ton cas est aussi particulier que le mien vu que tu utilises un VPS pour t'y connecter en 4G... tu n'as toujours pas la fibre chez toi ?) Ok donc c'est pas forcément le MOD à installer en priorité, sauf pour utiliser le dashboard nginx 😄 Oué 😅 c'est un peu la même chose pour moi 🙂 Et puis j'ai déjà un chantier ouvert et tout juste commencé avec Adguard Home XD et le tuto Vaultwarden qu'il faudrait que je réécrive pour le rendre un poil plus lisible (voir signature ^^) Bon en tout cas, merci beaucoup pour l'aide apportée 😇

@Einsteinium Merci pour les fichiers. Je vais tenter avec tes éléments de configuration. À la différence près que j'utilise cette action : action = %(action_mwl)s Va probablement falloir que je fasse plusieurs .local pour les sendmail*.conf ou les mail*.conf ... je sais pas trop lesquels sont utilisés avec sendmail... Ok, je comprends ^^ Parce que 😋 Non, plus franchement, c'est surtout que je n'ai pas envie de mettre en place davantage de chose... et que je ne me servirais pas vraiment d'un serveur discord. Et aussi parce que Discord peut accéder à tout ce qui passe par le serveur, non ? Bref, il y a certes des trucs intéressants faisable avec, mais là je n'ai pas trop le temps de regarder. Tout ce qui est proxiable doit passer de préférence par un unique proxy inversé. Donc port 443 -> SWAG et plus DSM. Pour les autres applis : Hyper Backup, Drive, etc... tu utilises simplement un autre certificat pour ces applis non proxiables. Que ce soit le nom de domaine de Synology, ton OVH ou ce que tu veux. Géré indépendamment de SWAG, par DSM, Acme, ou autre. Moi j'utilise le ndd Synology pour ces applis. Et bien justement, tu fais comment ? Je remarque que je n'utilise jamais le nom de domaine synology mis dans DSM. Donc ce n'est pas trop un soucis, mais j'aimerais comprendre comment tu fais, ou tu ferais dans mon cas particulier : swag en macvlan sur le NAS, derrière un routeur. J'ai bien redirigé le port 443 vers swag. Et je constate un effet de bord lorsque je suis sur le LAN que je ne sais pas encore corriger : pour la synchronisation Drive avec les clients desktop. Aucun soucis lorsque je suis connecté en 4G via mon smartphone, la synchro se fait sans soucis, vu que ça passe par le port 6690 et que ce dernier est redirigé vers le NAS dans le routeur. Mais quand je suis connecté au wifi du RT, la synchro est bloquée : Je précise à nouveau que j'ai des réécriture DNS avec AdGuardHome : mon-ndd.ovh -> IP macvlan de SWAG *.mon-ndd.ovh -> IP macvlan de SWAG @.Shad. Comment puis-je faire pour que la synchronisation fonctionne ? (c'est peut-être la question le plus importante à résoudre pour moi actuellement). Haa ! Je pensais que le pare-feu du NAS s'appliquait aux conteneurs... Mon routeur Synology RT2600AC permet de n'autoriser que les IP française à accéder au port 443 qui est transmis à SWAG. Regarde la capture de mon précédent message, elle est prise sur le routeur : Cela dit, je pense quand même regarder le geoIP que tu me dis ici 🙂 Ça fera toujours une protection supplémentaire 🙂 Oui carrément, je suis en train de paramétrer le F2B intégré en utilisant ce que j'avais fait pour l'instance dédiée et ce qui est dispo sur le dépot de Linuxserver/fail2ban-conf. La prochaine étape, quand la synchronisation Drive fonctionnera, sera Authelia, puis CrowdSec (tu ferais pas un tuto pour ça par hasard ? 🤗😇

Bonjour, comme indiqué dans le titre je n’accède plus à mon nas sauf que: j’y accède toujours via Drive et auparavant via PhotosMobile avant de me déconnecter (depuis impossible). J’y accède aussi directement en tapant l’adresse Ip interne. Sur accès externe du panneau de configuration j’accède à ddns et je vois le test ddns normal après nouveau test. Par contre sur l’onglet configuration j’ai plein de lignes qui sont cochées (activées) mais celles intitulées quickconnect avec les ports 80,443,5000 et 5001 ne sont pas cochées et impossible de les cocher. La dernière ligne quickconnect avec port local 6690 et port routeur 63650 est cochée mais impossible de la décocher. Toutes les autres lignes cochées peuvent être décochées. Je pense que cela vient de moi (c’est même sûr) car je galère depuis quelques jours sur 2 points: j’ai tenté quelques manipulations pour éviter l’emploi de quickconnect mais trop compliqué pour moi j’ai laissé tomber. J’ai également galéré pour installer Plex afin de regarder mes photos du nas sur la télé: là aussi, je n’ai pas terminé. Merci par avance pour les retours.

Bonjour, étant de Belgique, je ne connais pas la Freebox Pro, mais elle se ressemble toute 🙂 A votre problème, soit les ports utilisés sont fermés, soit votre FB pro ne translate pas les bon ports vers votre Syno maison. (la ou la box Orange le faisait sans doute) (peut etre que votre syno communiquait mieux avec votre ancienne box Orange ==> ouverture des ports automatiques) Je vois aussi qu'avec Synolgy Drive, un port différent est utilisé pour la synchronisation, le 6690: A bon entendeur 😉

Bonjour, merci pour la réponse. Mon NAS est bien en IP fixe, je n'ai aucun soucis d'accès à part Synology Drive et Time Machine. J'ai essayé de router le port 6690, mais ça ne change rien... Toujours "erreur d'authentification" J'accède à tout mon NAS via mon système d'exploitation, ainsi que via la page web... Je ne vois vraiment pas d'où vient le problème. Mais merci encore!

bonjour, ça ressemble a un redémarrage du nas qui n’était pas en bail ou ip statique.. étape 1 retrouver le nas et regardez l’ip (peut se faire via synology assistant) étape 2 sur box si box présente et si c’est elle qui gère l’attribution des ip, fixer un bail pour le nas étape 3 vérifier routages requis exemple port 6690 pour un accès drive externe

Je crois qu’il ce n’est pas le même port qui est utilisé par Synology Drive Client (pour les PC) et l’application Synology Drive (pour le iDevices). Pour le premier c’est le port 6690, alors que pour le second c’est le 443. Je ne l’ai pas vérifié par moi même (je n’utilise pas Drive sur mon téléphone), mais c’est ce qui ressort des diverses interventions sur le forum…

Merci beaucoup car je me suis juste trompé de port... Il était déjà configuré le 6690. Par contre sur mon téléphone c'est marrant c'est un autre port que j'avais personnalisé qui est enregistré... En tout cas ca refonctionne

Bonjour pour un accès externe il faut ouvrir le port 6690 dans la box/routeur.

Bonjour @Jeff777 et @Kramlech, merci pour vos retours. @Jeff777 : oui, j'avais renseigné mon profil depuis mon espace mais pas depuis la page "Présentation". @Kramlech : Lorsque j'indique "OK, mais sans www.ndd.fr", cela signifie que j'ai réussi, il y a déjà quelques semaines, à avoir un certificat Let's Encrypt mais n'ayant pas dans "autre nom de l'objet" le "www.ndd.fr" (en revanche, il y a bien : moments.ndd.fr;video-station.ndd.fr;download-station.ndd.fr;file-station.ndd.fr;synology-drive.ndd.fr J'ai ajouté toutes les redirections sur la Freebox Server, dont le port 6690 (et l'ai redémarrée) Désormais, - lorsque je tape http://moments.ndd.fr (sans le "s") > j'arrive sur cette page depuis un smartphone non connecté au wifi : - lorsque je tape : https://moments.ndd.fr (avec le "s") > j'arrive sur cette page également depuis un smartphone non connecté au wifi, le certificat n'est pas appliqué car j'ai le message d'erreur : Je viens à l'instant d'essayer de refaire une demande de certificat Let's Encrypt, en ajoutant cette fois le "www.ndd.fr" dans "autre nom de l'objet", j'ai toujours le message d'erreur. J'avoue sécher, d'autant plus que je suis carrément newbie sur ces sujets. Bien à vous

C'est normal que tu ais une alerte de sécurité si tu n'as pas encore demandé le certificat de Let's Encrypt. Je ne comprend pas ce que tu veux dire.. C'est la demande du certificat ? Pour quels sous domaines as-tu demandé ce certificat ? (Autres noms de l'objet dans le dialogue de génération du certificat) Ca, c'est normal, le port 35978 n'est pas redirigé vers ton NAS au niveau de la box ... Et petit détail qui a son importance, si tu veux utiliser Synology Drive pour synchroniser des fichiers depuis ton ordinateur, il faut que tu rediriges le port 6690 vers ton NAS (port utilisé par le client pour faire la synchro, non modifiable, et qui ne peut pas passer par le Reverse Proxy). Grilled par @Jeff777

@oracle7 C'est de plus en plus claire en tout cas... En plus mon exemple n'était pas vraiment bon, car le Drive version PC n'utilise pas l'http(s) seulement le port de synchro sécurisé 6690. Je parlerais plutôt de mon Drive version IOS qui lui devrait être toujours être utiliser en http car inutile de doublé la sécurité au travers de mon VPN qui lui est déjà sécurisé, comme si j'étais sur mon réseau local. Mais ce qui est sur c'est que je vais pas modifié les IPs ou utiliser une app un coup en http un coup en https, donc en attendant d'avoir un reverse proxy et une zone locale, mon VPN sera utilisé en local ou en distant avec toute les app en http au travers. Mais la encore on va me dire que utilisé mon VPN en local, c'est une surcharge inutile, mais si les appli avait la possibilité d'enregistré plusieurs configuration, local / distant, la question ne se poserais un peux moins... Je vais testé de creusé du côté reverse proxy pour mon drive IOS, accès à ma freebox à distance, etc.. et une petite zone locale pour la suite, oui, oui, vous allez pas vous débarrassé de moi comme ça 😅 ...

@Mickaël DRJ Bonjour, C'est on ne peux plus normal car Drive gère les synchronisations au travers de ce port 6690, donc à ne surtout pas fermer. Désolé mais la surcharge n'est pas financière mais pour ton processeur du NAS car dans ce cas tu lui fais faire du HTTPS sur du HTTPS. En clair tu cryptes pour rien une deuxième fois quelque chose qui était déjà crypté, tu me suis ? Cordialement oracle7😉