.Shad.

Tu utilises un nom de domaine en .org et tu n'as aucun certificat correspondant dans ton NAS. Donc normal que tu aies un avertissement. Plusieurs solutions : - La plus simple : Utiliser le NDD Synology, demander un wildcard plutôt qu'un certificat avec domaines nominatifs, tu seras moins embêté par la suite si tu ajoutes une nouvelle application dans ton proxy inversé. Voir mon message plus haut pour la procédure à suivre. - Garder ton nom de domaine, il te faut dans ce cas-là t'assurer que le port 80 est ouvert sur ton NAS et redirigé depuis ta box, et tu suis la même procédure que pour le certificat LE pour ton domaine Synology, sauf que c'est pour ton ndd.org. Dans ce cas-ci, pas de wildcard, tu dois spécifier les sous-domaines pour lesquels tu souhaites que ton certificat soit valide. Si tu as besoin d'un autre sous-domaine, tu devras renouveler ton certificat en ajoutant à la liste des alias existants le sous-domaine désiré. - La plus complète : Mettre en place ACME via le tutoriel proposé plus haut pour obtenir un certificat wildcard pour ton ndd.org Dernière chose, quand tu auras un certificat qui couvre le nom d'hôte que tu vas utiliser pour ton instance de Vaultwarden via proxy inversé, il faudra associer cette entrée de proxy inversé au certificat, via le bouton Paramètres dans l'écran de gestion des certificats :

Pas eu le temps de te répondre, mais effectivement : - Supprimer le réseau macvlan, donc avant ça stopper les conteneurs - Supprimer l'interface virtuelle - Recréer le réseau macvlan - Recréer l'interface virtuelle - Relancer les conteneurs A priori rien d'autre. Il y a l'air d'y avoir ce qu'il faut pour ici : Guide ASUSTOR NAS MIB - ASUSTOR NAS

Bienvenue parmi nous !

Le nom QuickConnect n'est valable qu'avec les applications Synology. Le client WebDAV n'en est pas une. Il faut effectivement juste utiliser l'IP si celle-ci est fixe ou le DDNS si l'IP est dynamique (ou fixe, ça marche aussi). Un petit tour sur ce tutoriel pourrait t'aider : https://www.nas-forum.com/forum/topic/75952-tout-ce-que-vous-avez-toujours-voulu-savoir-sur-les-réseaux-sans-jamais-oser-le-demander/

@j0ffr37 Désolé j'avais mal compris, je croyais que tu parlais de route statique. C'est bizarre en effet. Tu dis que tu as bien tes 30Mo/s en upload (ce qui est un peu faible pour du 700 Mbps je trouve si tu es en filaire) vers C2, mais est-ce bien le cas depuis les deux NAS ? Il doit sûrement y avoir un goulot d'étranglement quelque part sur un des deux réseaux. Certains protocoles sont moins optimisés pour du transfert distant, mais pas de là à diviser le débit par trois.

Si les périphériques se joignent par IP publique, quel besoin d'avoir des règles de routage ?

@sebdepringy Tu peux vérifier que ça correspond à ce que tu veux dans un fichier de configuration Nginx, ça se trouve dans : /etc/nginx/sites-enabled/server.ReverseProxy.conf Par exemple j'ai créé une entrée bidon dans mon proxy inversé en ajoutant dans l'interface où tu as mis tes entêtes : X-Content-Type-Options nosnif Ca donne : server { listen 80; listen [::]:80; server_name toto.xxx.ovh ; if ( $host !~ "(^toto.xxx.ovh$)" ) { return 404; } proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; location / { proxy_connect_timeout 60; proxy_read_timeout 60; proxy_send_timeout 60; proxy_intercept_errors off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header X-Content-Type-Options nosnif; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://localhost:5124; } location ^~ /.well-known/acme-challenge { root /var/lib/letsencrypt; default_type text/plain; } error_page 403 404 500 502 503 504 /dsm_error_page; location /dsm_error_page { internal; root /usr/syno/share/nginx; rewrite (.*) /error.html break; allow all; } } Il apparaît bien dans la liste des entêtes.

Comment sont reliés les NAS ? VPN site-à-site ? Ou ils se contactent via leur IP publique ?

Bienvenue !

Bienvenue parmi nous ! Tu es au bon endroit 🙂

Welcome !

Heu non c'est bien le but d'utiliser le ndd Synology pour accéder à ton réseau. Tu peux faire des impressions d'écran de ton onglet Certificats, des associations de certificats avec les applications et de tes entrées de proxy inversé ?

Bienvenue parmi nous ! Sain raisonnement que voilà ! 👌

Bien tenté mais nop 🙂 j'ai vraiment rien à apporter sur ce sujet, leur doc est parfaite, et Google Trad fait le travail pour les allergiques à la langue de Shakespeare. Au vu du temps qu'un tutoriel nécessite pour le rédiger correctement, je le réserve pour ce qui je trouve n'est pas suffisamment développé par ailleurs, sinon à quoi bon redire ce que d'autres ont déjà dit ? 😉 Et si c'est pour faire des tutoriels à la Mariushosting, je passe mon tour. 😄 😄 J'ai deux tutos sur le feu que je développerai quand quelques petits bugs gênants auront été corrigés. 🙂

Donc ton problème c'est l'obtention du certificat, je n'étais pas sûr d'avoir bien compris. Si c'est un domaine acheté, alors le seul moyen de renouveler son certificat est de renseigner le domaine, le mail et les sous-domaines lors de la demande de création : domaine : ndd.tld mail : toto@ndd.tld alias : vaultwarden.ndd.tld, nextcloud.ndd.tld, etc... L'obtention du certificat nécessite que les ports 80 et 443 de ton NAS soient ouverts au monde entier lors du renouvellement, et que ces deux ports soient correctement redirigés depuis ta box vers ton NAS. Avec un domaine Synology c'est différent, tu peux demander un certificat wildcard, comprendre joker, qui est valable pour tous les sous-domaines possibles : *.xxx.synology.me, ça ressemblera à ça : domaine : xxx.synology.me mail : toto@gmail.com alias : *.xxx.synology.me Pour ce type de certificat, la vérification par LE se fait au niveau de la zone DNS, donc celle de Synology sur un site distant, tu n'as donc par conséquent pas besoin d'ouvrir le port 80, et tu peux réduire la surface d'exposition du port 443. A savoir que nativement sur DSM, tu ne peux pas obtenir de certificat wildcard pour un ndd autre que Synology, mais tu peux utiliser le tutoriel suivant pour y parvenir : A ta place, dans un premier temps, j'essaierais déjà d'obtenir un certificat wildcard pour ton domaine Synology, et l'associer à ton entrée de proxy inversé pour Vaultwarden. Tu auras déjà quelque chose de fonctionnel. Après tu pourras prendre le temps qu'il faut pour déployer la méthode qui te convient le plus.

@MilesTEG1 Le meilleur tutoriel est là : https://borgbackup.readthedocs.io/en/stable/installation.html, en suivant dans l'ordre des catégories. C'est hyper simple à suivre. Je ne pourrais pas mieux l'expliquer. @oracle7 Cool, il faudra que tu vérifies quand même lors des mises à jour si tes modifications sont persistantes. Parce que là tu écris directement dans le fichier conf, pas dans un conf.d qui est inclus depuis un fichier maître.

J'utilise Borgbackup pour tous mes périphériques Linux. Ça marche nickel, ça gère le versioning, le chiffrement et la préservation des permissions et la propriété des fichiers.

Non je ne vois pas pour l'instant. Est-ce que tu utilisais toujours une ancienne version de Telegraf ou la latest ? Je t'avoue ne pas y avoir consacré assez de temps, le fait étant que je n'ai quasi plus aucun conteneur sur mon NAS, mais sur mes autres périphériques. J'essaierai d'y consacrer un peu de temps dans les semaines qui viennent. 🤘

@snoof bare-metal veut dire que l'OS est installé nativement sur la machine, sans passer par de la virtualisation ou de la conteneurisation. Ce que tu veux donc faire est migrer du bare-metal vers du virtualisé.

Hello, C'est un problème que j'ai récemment aussi, même en chmodant le sock Docker je n'ai pas réussi à résoudre le problème. Si tu veux éviter le message d'erreur tu peux temporairement désactiver le monitoring de Docker. Est-ce que le reste fonctionne bien ?

Welcome !

Ca va juste influer sur la possibilité de lire les données relatives à Docker, dans ton dashboard. Quand tu n'auras plus que ça à régler, tout ira bien.

Les gars, prenez le temps de lire deux minutes les messages d'erreur. Telegraf dit qu'il essaie de créer la base de données lui-même et qu'il échoue, c'est donc que tu as laissé le paramètre skip_database_creation à false, donc il essaie de créer une base de donnée peut-être déjà existante. Or dans le tutoriel je parle de ce paramètre, dans le point 8-B-3-b. Est-ce que tu es sûr de tous tes champs ? nom de la base de donnée, utilisateur/mot de passe, authentification http, etc... Reprend le tutoriel du début, et vérifie que tous les points sont OK.

@Dimebag Darrell Pourquoi tu as mis httpS://monitoring_influxdb:8086, InfluxDB écoute par défaut sur un port non sécurisé.

Ce que tu dois supprimer c'est la première instance de InfluxDB dans le fichier telegraf.conf : # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] et garder uniquement la deuxième instance. Ensuite tu recrées un fichier de configuration vierge, qui va te permettre de copier les champs à ajouter dans la configuration du plugin outputs.influxdb, tu le nommes différemment pour ne pas écraser ton fichier de configuration actuel : docker run --rm telegraf telegraf config > telegraf.conf.new Tu as visiblement changé quelque chose dans ton fichier de configuration Telegraf, volontairement ou pas.