.Shad.

@oracle7 C'est pas un peu contradictoire de conseiller quelque chose que tu ne comprends pas ? 😅 Si j'ajoute une entrée du type https://toto.xxx.synology.me:443 vers http://localhost:8080 (bidon, pour l'exemple) dans le proxy inversé du Syno, voilà ce qu'on obtient sur le NAS : root@DS918:/etc/nginx/sites-enabled# cat server.ReverseProxy.conf server { listen 443 ssl; listen [::]:443 ssl; server_name toto.xxx.synology.me ; if ( $host !~ "(^toto.xxx.synology.me$)" ) { return 404; } include /usr/syno/etc/www/certificate/ReverseProxy_12c2e981-4fb5-4ebb-8fb9-c41eccb18f27/cert.conf*; include /usr/syno/etc/security-profile/tls-profile/config/ReverseProxy_12c2e981-4fb5-4ebb-8fb9-c41eccb18f27.conf*; 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 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:8080; } 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; } } Et toi tu ajoutes les entêtes liés au Websocket, qui est principalement utilisé pour garder une connexion à jour de façon permanente, c'est plus intense en ressource pour l'hôte mais parfois obligatoire comme avec Surveillance Station. Ici c'est facultatif, mais ça ne coûte quasi rien de l'ajouter. Plus d'info sur les websockets : https://www.tutorialspoint.com/how-to-configure-nginx-as-reverse-proxy-for-websocket Comme l'a fait remarquer @MilesTEG1, tu utilises la configuration pour un sous-dossier du site web et pas pour un sous-domaine. Quand tu n'es pas sûr, tu consultes la liste des fichiers préconfigurés ici : https://github.com/linuxserver/reverse-proxy-confs Ce n'est pas à utiliser comme tel car c'est adapté pour une utilisation avec SWAG, qui préfère utiliser plusieurs petits fichiers qu'un seul gros fichier reprenant toute la configuration, mais ça te permet de voir généralement s'il y a des entêtes ou des blocs server particuliers à renseigner. @pbai Quelques impressions d'écran de la configuration de ton conteneur Calibre et de la configuration de ton entrée de proxy inversé pourrait nous aiguiller sur ce qui ne va pas. Est-ce que tu as bien translaté le port 8083 du conteneur sur le même port de ton NAS ? En SSH c'est facile à vériier : netstat -tunlp | grep 8083 Si aucun output c'est que Calibre n'est pas translaté sur ton NAS, et tu ne risques pas de pouvoir y accéder.

Le token c'est l'accès à l'API que tu as dû créer au début du tutoriel. Mais si ça fonctionne d'une façon ou l'autre, ce n'est pas la cause, sinon ça ne marcherait pas quelque soit la méthode utilisée. A quoi ressemble ta tâche DSM ?

Voir point 7-B-2-c-2 de mon tutoriel Docker, il n'y a pas de redirection de port à faire en mode host, vu que le conteneur et l'hôte sont confondus, donc pas besoin de NAT entre le NAS et le conteneur. Autre remarque, pourquoi ne pas nommer le fichier env ?

Moi je le comprends dans l'autre sens, le port 22 de la box est NATé sur le port 4826 du NAS. Du coup @PPORCH3 est-ce que tu as bien modifié le port SFTP dans DSM : Et est-ce que tu as modifié le port SSH ? Il y a des redondances dans ton pare-feu, ce qui pourrait être OK s'il t'arrive de désactiver la règle Tous Tous France Autoriser, sinon un petit nettoyage serait utile. Quel est l'intérêt par contre de caler SFTP sur un autre port que 22 ? Car de toute façon, c'est le port 22 de la box que tu utilises.

@MilesTEG1 L'option de nommage du bridge, c'est le nom de l'interface adhoc créée sur le NAS (172.x.0.1), pas le nom du réseau. Ca évite de se taper un nom d'interface généré aléatoirement. @oracle7 Tu es sûr de ta limite de 15 caractères ? Ca me semble peu, et @MilesTEG1 a visiblement des noms de réseau beaucoup plus longs que 15 caractères.

@oracle7 Ah oui en effet j'ajouterai la précision, mon nom de réseau était bien plus court, je n'aurais pas imaginé. Et les messages d'erreur sont flous au possible.

@PPORCH3 Quand tu essaies d'accéder à ton NAS depuis l'extérieur, quel port sollicites-tu ? Je ne suis pas d'avoir bien identifié si c'est le port 22 qui est exposé sur ta box ou sur ton NAS.

Ce sont deux sous-réseaux privés liés à ta machine. Ils n'ont aucune raison de se causer entre eux, hormis par l'intermédiaire du NAT sur les hôtes respectifs, aucune raison qu'il y ait donc des problèmes de routage.

@kroumi Première chose à faire, c'est vérifier que ton NAS est accessible depuis l'extérieur, pour ça tu peux utiliser : https://www.yougetsignal.com/tools/open-ports/ Tu dois ouvrir les ports 443 et 80 au monde entier durant le test. Moi, quand je fais le test sur ton nom de domaine, ça me dit que les ports 443 et 80 sont fermés. Or, vu les règles que tu as testées, ça doit être OK pour le NAS, donc recrée les règles de NAT sur ta box, il y a probablement un bug de ce côté-là. Où est hébergée ta zone DNS publique ? PS : Tu peux vérifier l'état de renouvellement et l'historique d'un ou de plusieurs certificats pour un nom de domaine via ce site : https://crt.sh/?q=nasunivers.fr&deduplicate=y

Là en l'état je ne pourrai pas t'aider plus. Je n'ai pas assez de temps libre pour me lancer dans une révision de mon monitoring malheureusement. Si tu arrives à résoudre ton problème n'hésite pas à partager la solution.

C'est énorme 60s de timeout déjà, passer à 10s au lieu de 5s aurait dû suffire si ton réseau n'est pas défectueux. Pour les collections, ce sont tes uniques messages d'erreur ? Ça me semble léger. Tu es bien en log level debug ?

Tu as mis cb de secondes en timeout dans l'input SNMP pour le NAS ?

@oracle7 Je n'ai jamais touché au SNMPv3, vu que je reste sur du polling local je n'en ai jamais vraiment vu l'utilité. Cela dit à première vue ça me semble, sûrement faussement, facile d'accès. et dans le fichier telegraf.conf : # ## SNMPv3 authentication and encryption options. # ## # ## Security Name. # # sec_name = "myuser" # ## Authentication protocol; one of "MD5", "SHA", or "". # # auth_protocol = "MD5" # ## Authentication password. # # auth_password = "pass" # ## Security Level; one of "noAuthNoPriv", "authNoPriv", or "authPriv". # # sec_level = "authNoPriv" # ## Context Name. # # context_name = "" # ## Privacy protocol used for encrypted messages; one of "DES", "AES" or "". # # priv_protocol = "" # ## Privacy password used for encrypted messages. # # priv_password = "" Pour les champs qui n'apparaissent pas dans DSM : https://www.webnms.com/simulator/help/sim_network/netsim_conf_snmpv3.html Si j'en crois cette page, les options dans sec_level définissent l'utilisation ou non des deux autres champs : authentification et niveau de confidentialité. Pour le context_name, l'article ci-avant en parle aussi mais c'est moins clair. Ah, et SNMPv3 utilise a priori le port 10161 au lieu de 161, en tenir compte pour le réglage de ton pare-feu, si tu as verrouillé l'accès depuis Docker (mais je pense que tu aurais eu une connexion refusée plutôt qu'un timeout en ce cas). Désolé, tu as sûrement déjà dû tester tout ça, vu que je viens de trouver ça en faisant une recherche rapide. Mais j'ai pas mieux à offrir 😄 Ah si peut-être, cet issue sur le Github de Telegraf : https://github.com/influxdata/telegraf/issues/3655

Salut @TuringFan Tu peux utiliser le même certificat oui. De souvenir acme permet de déployer le certificat sur plusieurs NAS, d'autant plus s'ils sont reliés par VPN. Mais si tu décidais d'avoir un deuxième certificat pour le même nom de domaine, ça marcherait tout aussi bien. SI ton registrar c'est OVH alors tu peux créer plusieurs dynhost. Du coup tu règles le DDNS du NAS distant de la même manière que le NAS local. Tu peux chiffrer côté client, c'est une option de la sauvegarde. Cela dit si tu utiliser un FQDN sous certificat pour ton NAS distant, pour moi le trafic est naturellement chiffré. Je pense que cette option est utile si tu n'as pas un certificat valide sur ton NAS de destination. A voir avec les experts @maxou56 @PiwiLAbruti Pour ta dernière question je ne sais pas je n'utilise pas Surveillance Station. 🙂

Si tu désactives (disable) le service (pas de lancement au démarrage) et que tu le lances manuellement une fois l'OS booté, ça marche bien ? Pour désactiver : sudo systemctl disable media-greg-DonneesPartagees.mount Pour lancer manuellement : sudo systemctl start media-greg-DonneesPartagees.mount

Non il faut désactiver SMBv1 Tu laisses de 2 à 3, ou 3 seulement. Il faut regarder dans /lib/systemd/system si tu as bien des services qui ont ce nom-là.

Bizarre, tu as bien activé SMB3 sur ton NAS ?

Google ça marche aussi. Ou www.perdu.com Concernant les règles d'accès, ce que je veux dire c'est qu'autant tout laisser dans Authelia plutôt que de mettre des règles dans Nginx ET dans Authelia. Si tu enlèves dashy.ndd.ovh de ton fichier de conf, ça revient à faire ce que tu veux, seuls les accès locaux et vpn seront autorisés (ton premier bloc de règles).

@MilesTEG1 Merci pour la remarque, j'avais màj mon fichier mais oublié de màj le tuto, c'est réparé. 🙂 Oui en yaml : tiré de yaml.org directement. Une site vers lequel tu renvoies l'utilisateur au cas où le proxy inversé n'aurait nulle part vers où renvoyer derrière, ou si tu demandes authelia.ndd.tld par exemple. Je ne pense pas que ça ait d'importance, Authelia doit savoir quel domaine il est sensé protéger, il ne peut pas protéger plusieurs domaines simultanément (tu pourrais avoir plusieurs ndd qui servent ton réseau). Pour ta question concernant les accès locaux, oui tu peux désactiver authelia via le fichier conf de SWAG et ajouter des règles dans nginx, mais est-ce que traiter indifféremment les entrées de proxy pour LAN uniquement ou LAN/WAN et se contenter d'ajouter simplement un bloc de rules dans Authelia n'est pas plus simple ? Moi je trouve que si.

Peut-être, mais Synology Drive n'est pas conçu pour fonctionner comme tu l'entends. Ce que tu cherches à faire correspond aux possibilités d'un logiciel de sauvegarde dédié. Si c'est le trafic réseau le problème, DSM permet de limiter le trafic par utilisateur et application. Ainsi tu ne satures pas ta liaison au réseau tout en continuant de sauvegarder.

Soit tu fais en sorte de laisser ton PC allumé, soit tu utilises le Wake-on-LAN pour allumer ton PC à une heure déterminée. Sinon, tu peux utiliser un logiciel comme Cobian Backup qui peut faire des sauvegardes configurables sur un disque réseau.

Bienvenue parmi nous !

Ce qui aurait été utile c'est d'utiliser la commande date dans le conteneur avant introduction de la variable, et après. 🙂

Bienvenue parmi nous !

Welcome !