.Shad.

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

@bruno78 Est-ce que ça ne peut pas être dû au downtime de ton installation, le buffer de Telegraf qui s'est gonflé pendant qu'InfluxDB était indisponible, et que le paquet est devenu trop gros ? Je n'ai pas constaté de problèmes équivalents, peut-être simplement supprimer le fichier temporaire ? Je n'ai rien trouvé de plus que j'imagine tu as déjà trouvé en modifiant la taille du cache dans Nginx.

Bienvenue parmi nous ! 🙂

Pour moi ce que l'OP veut faire correspond à ces (34 😄) pages de discussion chez Orange : https://lafibre.info/orange-les-news/livebox-5-2-gbs-sur-un-seul-pc/72/ En gros c'est de l'agrégation de liens modifiée logiciellement au niveau du PC pour rassembler les débits. Je doute fort que tu aies aussi "facile" (entre tes gros guillemets 😛) avec le NAS. C'est quand même très technique et va te demander de nombreuses heures de travail (en supposant que tu sois à l'aise avec tous les concepts développés). Je pense que tu as plus facile d'attendre que la Livebox passe ses ports réseaux en 10 Gb/s et adapter ton réseau, le temps que ça arrive tu auras pu économiser. 😛

C'est possible mais très spécifique, ça s'appelle SSLH. Un article qui en parle clairement : https://ostechnix.com/sslh-share-port-https-ssh/ En gros, c'est SSLH qui écoute sur le port 443, puis redirige vers SSH ou SSL (proxy inversé) suivant la requête. C'est en amont du proxy inversé. La même chose est faisable avec OpenVPN, je crois que c'est ce que @Mic13710 a mis en place, dans les faits je pense que c'est se fatiguer pour pas grand chose. Le données circulant sur le port 1194 sont de toute façon chiffrées. L'intérêt que tu peux avoir à passer sur le port HTTPS pour OpenVPN c'est d'être en TCP et pas UDP. C'est plus stable, mais moins rapide généralement (les paquets arrivés à destination renvoient l'information qu'ils sont bien arrivés, UDP ne le permet pas). On ne parle pas de quelque chose de facilement discernable à l'usage. Concrètement on s'en sert quand on est sur une connexion qui bloque des ports de destination autres que 443 et 80 par exemple, ça arrive dans certains wifi surveillés et bien cadenassés, ou en entreprise. C'est quand même pas fréquent. A moins d'être dans ce cas-là je ne vois pas d'intérêt réel. @GrOoT64 a tout de même raison dans le sens où le proxy inversé ne sert à rien pour OpenVPN. J'apportais juste la nuance concernant la possibilité de "partager" le port 443.

InfluxDB peut être gourmand, suivant le nombre de machines que tu supervises.

A ta place je partirais sur le J, vu qu'effectivement la Shield va s'occuper du reste.

Google est ton ami ! Et la documentation de Grafana est hyper détaillée, donc... 😗 La dashboard que je donne un exemple pour importer dans le tuto utilise ce principe-là pour la variable "host".

Pour éviter de rentrer des IP il suffit d'utiliser les variables de dashboard, dans les paramètres de celui-ci. Perso je mets des variables où je peux, ça évite justement d'avoir à modifier des valeurs, et ça facilite la transition d'un NAS à l'autre dans le même dashboard.

Bienvenue parmi nous !