.Shad.

@Dark-Spirit Pour le test iperf3, tu te connectes en SSH en root, puis : docker run -it --rm --name=iperf3-server -p 5201:5201 networkstatic/iperf3 -s Côté client, sur Windows par exemple, tu télécharges les binaires iperf3 sur Internet, puis tu ouvres PowerShell dans le dossier de l'exécutable iperf3.exe (MAJ + clic droit dans le dossier) : .\iperf3 -c 10.0.0.1 iperf3 va transférer 1 Go en 10 étapes et te donner une valeur moyenne, ça va permettre de confirmer ou pas que le problème vient de la liaison et pas d'ailleurs (navigateur par exemple). Quand tu as terminé, tu fais CTRL+C dans la fenêtre SSH du NAS pour supprimer le conteneur.

Quelle est la vitesse d'upload de la connexion de ton domicile ?

Salut, c'est un peu confus. Ce qu'il te faut c'est suivre le tutoriel sur le proxy inversé : Tu en parles mais je ne suis pas sûr que tu aies bien compris comment ça fonctionne. En tout cas c'est exactement ce qu'il te faut si tu veux ne plus avoir accès à ton Video Station par le ndd Synology.

L'indexation ne s'enclenche que via certains biais : File Station, SMB, AFP, etc... Deluge utilise certainement du bash ou du python pour déplacer le fichier, ce qui ne déclenche pas l'indexation. J'avais eu ce problème avec un autre logiciel à l'époque, c'est gênant.

Un peu étrange votre discussion concernant les débits 😄 Grosso modo, à connexion égale (encore faut-il qu'elle ne fluctue pas comme la tienne @MilesTEG1), ce qui influe : - La connexion montante du serveur (au mieux égale, très souvent inférieure à la vitesse descendante). - Le protocole UDP plus rapide contre TCP plus stable - L'algorithme de chiffrement Généralement, si tous les feux sont au vert, on constate une perte de débit allant de 5 à 15%, suivant le type de VPN. Pour la performance pure, c'est plutôt vers Wireguard qui faut s'orienter. OpenVPN n'est pas loin derrière.

On est on ne peut plus d'accord. 🙂

Je trouve ça un peu overkill les 8 ports quand même 😄

Tape en SSH sur le NAS : docker ps Et vérifie que tu voies la même chose que sur Portainer.

Salut, c'est principalement un forum Synology ici, malgré le nom du site qui peut être trompeur, la bannière ne laisse pas trop de doute. 😉 Tu auras plus de chance de trouver solution à ton problème sur https://www.forum.nas.fr

Bienvenue parmi nous, tu trouveras certainement ton bonheur. 😉

Rien à voir mais on voit sur la capture d'écran que ton NAS est connecté en 100 Mbps, c'est plutôt rare en 2020 quand même, vérifier si c'est lié à un (très vieux) switch ou câble mais ton NAS pourrait dialoguer entre 8 et 9 fois plus vite avec les autres périphériques locaux.

Bienvenue parmi nous !

Ah ben ne cherche pas loin, c'est comme si quelqu'un te demande ton chemin et que tu lui dis d'aller à gauche et à droite en même temps. L'adresse IP commençant par 109 correspond à l'IP de l'hébergement gratuit qui t'est, j'imagine, proposé à l'achat du domaine, quelques Mo pas plus sûrement, de quoi héberger quelques pages web, celles justement sur lesquelles tu arrives. Il faut donc supprimer l'enregistrement A qui fait pointer ndd.tld vers cette IP en 109, garder l'autre, tu peux augmenter un peu le TTL quand même, 60s c'est faible, 14400 c'est déjà mieux (4h). Tu laisses l'enregistrement CNAME de nas.ndd.tld tel quel. L'utilisation d'un wildcard se justifie vraiment si tu utilises un proxy inversé en entrée de ton réseau, le NAS en propose un dans DSM via Nginx. Ca permet que dans le cas où tu crées souvent des sous-domaines, ça t'évite de refaire une demande de certificat Let's Encrypt, car avec le wildcard tous les sous-domaines possibles sont validés a priori. Si ce n'est pas ton cas, tu peux supprimer le wildcard, tu laisses nas.ndd.tld, et tu ajouteras ce dont tu as besoin si tu exposes de nouveaux services vers l'extérieur.

Comme tu peux le voir tu as un enregistrement wildcard *.ndd.tld qui j'imagine pointe via CNAME vers ndd.tld, ton domaine racine. Donc c'est normal que toutetnimportequoi.ndd.tld t'amène sur ton IP publique (et ton NAS car tu as redirigé les ports 443 et 80 vers ton NAS j'imagine). Donc ajouter l'enregistrement nas.ndd.tld ne changera rien, sauf si tu le faisais pointer autre part que ce que le wildcard ne fait déjà. Par contre c'est moi ou ton domaine racine ndd.tld a deux enregistrements A différents ? 2 premières lignes de la deuxième capture d'écran.

Ca ira mieux... d'ici quelques mois, quand tu auras bien compris ce que tu fais. 😄 Bienvenue parmi nous 😉

Si tu n'as pas d'enregistrement nas.ndd.tld et que c'est l'adresse que tu tapes dans le navigateur il y aura forcément un problème. Vérifie que tu n'as pas d'enregistrement "wildcard", c'est-à-dire écrit *.ndd.tld, pour moi tu aurais dû avoir une erreur 404 et pas une redirection. Tu n'as pas moyen de prendre des impressions d'écran de ta zone DNS (en cachant les IP publiques) ?

Oui depuis l'invite de commande c'est bon aussi, c'est juste que la commande n'est pas toujours disponible par défaut. 🙂 Bon donc tu pointes bien sur ton IP publique, autant depuis ton réseau local que depuis Google sur ton domaine racine, est-ce que tu as un enregistrement CNAME pour nas.ndd.tld ? nas.ndd.tld CNAME ndd.tld ou un autre enregistrement A ? nas.ndd.tld A IP_publique_fixe

Si tu tapes en SSH dans le NAS : nslookup ndd.tld 8.8.8.8 et : nslookup ndd.tld Est-ce que dans les deux cas ça te renvoie ton IP publique ?

Chez quel prestataire as-tu pris ton nom de domaine ? Est-ce que dans la zone DNS correspondante tu as bien un enregistrement A de type ? ndd.tld A IP_publique_fixe A première vue cet enregistrement est soit manquant soit erroné et pointe vers l'IP de l'hébergeur par défaut.

Personnellement j'utilise mon VPS dans l'autre sens, à savoir qu'il est client d'un serveur OpenVPN situé chez moi. Aucune connexion intempestive à déplorer depuis sa mise en place (il y a 1 mois) en tout cas.

Ca a un autre avantage, plus intéressant selon moi, c'est ce que j'utilise : pour un domaine "coucou", si tu fais un : ping nas il va dans un premier temps tenter d'append automatiquement le domaine, et voir si ça correspond à quelque chose que ton serveur DNS sait résoudre.

Pour info, @Jeff777 a eu un souci de déploiement avec de le deploy_hook d'acme sur son NAS en DSM 7 alors que pour l'autre (en 6.2) il n'y a eu aucun souci. J'ai pas eu le temps de lui demander beaucoup de détail (il est en vacances le veinard) mais si vous remarquez un problème similaire n'hésitez pas à balancer du log. 😄

@Mic13710 Ok je comprends mieux, j'étais persuadé que tu étais en TCP, quand on passe sur ce port c'est souvent parce qu'on veut une liaison VPN en TCP et pour les raisons de blocage dont j'ai parlé plus haut. Mais en UDP ce n'est plus le même port que le 443 TCP, on économise une ligne mais ce sont bien deux ports distincts dans chaque cas. @Dark-Spirit pour l'UDP et le TCP : https://openvpn.net/faq/why-does-openvpn-use-udp-and-tcp/

@MilesTEG1 Il te suffit d'ajouter l'argument : depends_on: - influxdb au service telegraf et : depends_on: - influxdb - telegraf au service grafana, ce qui donne pour l'ordre de démarrage : influxdb -> telegraf -> grafana

Un peu plus clair ici, enfin clair c'est vite dit : https://community.synology.com/enu/forum/2/post/126103