Mic13710

Ce qui veut dire que le NAS n'est pas accessible quel que soit le protocole. Et les autres voyants LAN et disk ? Plus d'infos sur la led status qui clignote : https://kb.synology.com/fr-fr/DSM/tutorial/What_can_I_do_if_the_STATUS_LED_keeps_flashing_in_orange

Ok, mais est-ce que le NAS va jusqu'au mode ready (voyant status allumé) ?

Merci à tous pour vos retours. En regardant mieux mes logs, j'ai vu que le renouvellement du certificat sur mon NDD Gandi n'a pas été non plus de tout repos. Il a fallu plusieurs jours avant que ça passe. Etrange tout de même que ce soit uniquement sur le NDD OVH que le souci ait perduré jusqu'à extinction du certificat. A la réflexion, je me demande si ça ne serait pas lié à l'évolution de mon réseau vers Unifi et de la "tambouille" que j'ai du mettre en place pour pouvoir utiliser le player freebox sur le LAN. A moins que ce soit un blocage de dns par pihole. Je n'ai pas la réponse. Je pourrais forcer le renouvellement mais je n'ai pas le temps. Je verrai au prochain renouvellement et si ça coince, je ferai des tests plus approfondis.

Vous brulez les étapes. Sortez le disque qui semble HS et essayez de démarrer le NAS avec le disque sain. Si ça fonctionne c'est que le disque est effectivement HS et il faut le remplacer. A réception des nouveaux disques, il suffira d'en monter un dans le NAS et de lancer la reconstruction à partir du gestionnaire de stockage. L'autre disque neuf ... à vous de voir ce que vous en faite.

C'est expliqué dans les notes de versions : Version: 24.0.2-1535 (2025-02-11) Important Notes Starting from this version, if you perform a clean install of the package, the "docker" shared folder will not have the "Hide this shared folder in My Network Places" setting selected by default. As of this version, settings for containers—including ports, volumes, environments, and links—cannot be modified post-creation. To modify the settings, duplicate a desired container and make the change to the newly created one.

Edit: J'ai lancé le renouvellement avec l'instruction dnssleep et ça a marché. docker exec Acme sh -c "acme.sh --issue --force --keylength 4096 -d '<Mon NDD>' -d '*.<Mon NDD>' --dns dns_ovh --dnssleep 300" Suivi d'un lancement de déploiement et c'est reparti. docker exec Acme sh -c "acme.sh --deploy -d '<Mon NDD>' --deploy-hook synology_dsm" Ca ne résout pas le problème mais au moins j'ai un certificat valide. A voir dans 2 mois lors du prochain renouvellement.

Salut, Le dernier renouvellement de mon certificat sur mon nom de domaine chez OVH ne s'est pas fait, et chaque tentative journalière se solde par un échec. Et cela sur mes deux NAS. Par contre, le renouvellement de mon autre nom de domaine chez Gandi s'est fait sans trop de problème sur mes deux NAS (juste un ou deux échecs mais rien d'anormal). Mes API sont correctes puisque les entrée TXT sont bien écrites dans ma zone DNS, mais ça bloque à chaque fois lors de la vérifications des dns publics : [Sun Jun 8 03:25:30 UTC 2025] Let's check each DNS record now. Sleeping for 20 seconds first. [Sun Jun 8 03:25:50 UTC 2025] You can use '--dnssleep' to disable public dns checks. [Sun Jun 8 03:25:50 UTC 2025] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck [Sun Jun 8 03:25:50 UTC 2025] d='<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] txtdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] aliasDomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] txt='TRms99shC4euqpAUu3pD4YO-Zv8puWhxRgmuuncz1ns' [Sun Jun 8 03:25:50 UTC 2025] d_api='/root/.acme.sh/dnsapi/dns_ovh.sh' [Sun Jun 8 03:25:50 UTC 2025] Checking <Mon NDD> for _acme-challenge.<Mon NDD> [Sun Jun 8 03:25:50 UTC 2025] _c_txtdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] _c_aliasdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] _c_txt='TRms99shC4euqpAUu3pD4YO-Zv8puWhxRgmuuncz1ns' [Sun Jun 8 03:25:50 UTC 2025] Detecting DNS server first. [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://cloudflare-dns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.google' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.alidns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://doh.pub' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] No DOH [Sun Jun 8 03:25:50 UTC 2025] Detecting DNS server first. [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://cloudflare-dns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.google' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://dns.alidns.com' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://doh.pub' [Sun Jun 8 03:25:50 UTC 2025] timeout=10 [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 10' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] No DOH [Sun Jun 8 03:25:50 UTC 2025] GET [Sun Jun 8 03:25:50 UTC 2025] url='https://cloudflare-dns.com/dns-query?name=_acme-challenge.<Mon NDD>&type=TXT' [Sun Jun 8 03:25:50 UTC 2025] timeout= [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] ret='6' [Sun Jun 8 03:25:50 UTC 2025] Not valid yet, let's wait for 10 seconds then check the next one. [Sun Jun 8 03:25:50 UTC 2025] _p_txtdomain='_acme-challenge.<Mon NDD>' [Sun Jun 8 03:25:50 UTC 2025] Purging Cloudflare TXT record for domain _acme-challenge.<Mon NDD> [Sun Jun 8 03:25:50 UTC 2025] POST [Sun Jun 8 03:25:50 UTC 2025] _post_url='https://cloudflare-dns.com/api/v1/purge?domain=_acme-challenge.<Mon NDD>&type=TXT' [Sun Jun 8 03:25:50 UTC 2025] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Jun 8 03:25:50 UTC 2025] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6 [Sun Jun 8 03:25:50 UTC 2025] _ret='6' Toutes les lignes ci-dessus sont répétées pas moins de 160 fois à chaque fois que le script est lancé ! C'est 6000 lignes qui sont enregistrées dans le fichier acme.sh.log qui à ce jour comptabilise 251000 lignes depuis le 01/01/2025 ..... A comparer aux 27000 lignes du fichier de 2024. Bref, il y a comme un souci alors que je n'ai rien modifié, l'image docker ainsi que le script acme.sh sont à jour. J'ai beau chercher, je ne trouve rien dans les logs d'anormal exceptés ces recherches sur les dns publics qui me semblent étranges et que je ne retrouve pas pour les renouvellements précédents. Est-ce que ceux qui sont chez OVH ont pu renouveler leurs certificats ou suis-je le seul dans ce cas ?

Je ne vois pas le rapport. Votre borne AX92 est connectée en ethernet à votre RT. Si vous la passez en point d'accès et non en routeur comme c'est le cas à présent, ça ne change rien au niveau du wifi (vous gardez votre SSID et votre mdp), par contre les clients eux sont connectés au réseau du RT au travers de la borne et reçoivent leurs IP du RT. Dans ce cas, votre PC portable (comme tous les clients de la borne) reçoit une IP en 192.168.2.x et peu directement communiquer avec vos NAS, votre imprimante, etc....

Les adresses IP des smartphones ne sont pas fixes. Elles varient en fait très souvent. Deux possibilités : soit vous ouvrez toutes les plages d'IP couvertes par votre opérateur (je vous laisse chercher), soit vous passez par le VPN du NAS (ou celui du routeur s'il en est pourvu) et vous autorisez la seule plage IP de votre VPN. Le risque 0 n'existe pas. Si vous avez correctement paramétré le parefeu de votre NAS, que les tentatives de connexion en échec sont bloquées comme indiqué dans le tuto et que vous avez limité les accès au reverse proxy aux seules adresses de confiance, les risques sont assez limités.

Oui, à condition que l'IP soit la bonne !

Il faut rajouter une règle Refuser après la dernière règle :

Il faut paramétrer la borne wifi en point d'accès et non en routeur pour que les adresses ip attribuées aux clients de la borne soient attribuées par le DHCP du routeur ou de la box.

Le plus direct c'est de créer des lecteurs réseaux sur chaque PC qui pointent vers les "home" respectifs. En utilisant exclusivement l'IP LAN du NAS (en 192.168.x.y), ces lecteurs sont accessibles localement et à travers le VPN.(\\192.168.x.y\home, identifiants de l'utilisateur, valider pour que le lecteur soit activé au démarrage du PC). Mais pour cela, il faudrait autoriser l'accès au LAN. Sinon, vous pouvez utiliser l'IP du VPN mais à ce moment là les lecteurs ne seront pas accessibles localement. C'est un choix. Pas de NetBIOS car ils sont beaucoup moins stables que les IPs. Je ne suis pas du tout familier avec les ibidules et imachins. Et donc, je ne suis pas à même de commenter ce qu'il se passe du côté de vos clients. Le problème qui peut exister concerne le certificat utilisé dans le fichier .conf qui est peut être expiré. Lorsque vous créez le fichier à partir de DSM, le certificat qui est utilisé est celui que vous avez indiqué dans les paramètres. L'ennui c'est que si vous utilisez le certificat Let's Encrypt, ce dernier est renouvelé tous les deux mois et il faut alors remettre à jour le fichier .conf sur tous les clients pour actualiser le certificat. Pour résoudre cela, je ne saurais trop vous conseiller d'utiliser à minima le certificat par défaut du NAS dont la validité est beaucoup plus longue. Le mieux étant de créer un certificat autosigné dont la durée de validité est la plus longue possible. J'ai pour ma part un certificat autosigné avec une échéance en 2038 et que je n'utilise que pour le VPN (bien que je ne passe plus par le serveur VPN du NAS depuis bien longtemps) Ce qui signifie qu'il faut d'abord indiquer à DSM quel certificat utiliser pour le serveur VPN AVANT de créer le fichier .conf. Si vous le faites après, il n'y aura pas de correspondance entre fichier et certificat.

Sans les disques je suppose ?

Je comprends mieux. Mais dans ce cas, je ne crois pas que le serveur VPN puisse être invoqué, ni même le nom de domaine et son certificat qui sont situés sur le LAN. Je peux me tromper mais sans accès au LAN, vous ne pourrez pas obtenir les résultats escomptés.