Mic13710

cloudfare est pris en exemple par l'auteur. Ce n'est pas à suivre aveuglément. Puisque vous avez suivi ce tuto, vous avez déjà toutes les clés OVH pour passer directement à l'installation. Pour lancer la configuration DNS, il faut simplement utiliser les mêmes clés et les exporter : export OVH_AK='Application Key' export OVH_AS='Application Secret' export OVH_CK='Consumer Key' @oracle7 Tu as tout à fait raison. Ce n'est pas DSM mais bien acme.sh qui lance le déploiement en appelant un autre script : /usr/local/share/acme.sh/deploy/synology_dsm.sh. Ce dernier a été mis à jour plusieurs fois en 2020, la dernière date du 10 décembre, ce qui explique probablement que le déploiement s'effectue maintenant normalement et sans l'aide d'un script supplémentaire.

Avec plus de 51000 heures, ça fait presque 6 ans de fonctionnement 24/7.

Généralement, un test smart bloqué à 90% = disque HS.

Bonjour Arno22, soyez le bienvenu dans la communauté

Justement, le tuto sur github dont j'ai parlé plus haut que j'utilise sur tous les NAS non compatibles Docker. Et si vous le comparez au tuto d' @Einsteinium, vous verrez qu'il est très similaire. Il y fait d'ailleurs référence à la fin de son tuto. Que ce soit avec Docker ou pas, la méthode est la même : on passe par le deploy_hook. La seule différence c'est qu'avec Docker, le certificat est créé dans une instance Docker alors que sans, il est créé dans DSM. Les deux utilisent le même script acme.sh. Docker n'est absolument pas une nécessité puisqu'on fait au final la même chose que ce soit avec ou sans. C'est juste une autre manière d'obtenir le certificat qui est fondamentalement la même dans les deux cas avec des commandes quasi identiques. Le déploiement est ensuite strictement le même puisqu'il s'agit de déployer le certificat dans les dossiers appropriés en utilisant le deploy_hook de DSM. Je ne l'avez pas relevé. acme.sh ne fait pas de déploiement. Il se contente d'obtenir le certificat. C'est le deploy_hook de DSM qui fait ensuite le déploiement.

Toujours ce problème de certificat sur le VPN. Pour ne pas y être confronté, il faut utiliser pour le seul serveur VPN un certificat spécifique d'une durée de validité éloignée. Soit on lui affecte le certificat par défaut de DSM synology.com, soit un certificat auto-signé. Ainsi le certificat n'est pas affecté par les renouvellements Let's Encrypt, et surtout on ne perd pas la connexion à distance qui peut devenir un vrai cauchemar à rétablir.

Absolument pas. Je n'ai rien eu à faire pour rétablir les affectations. Et je n'ai pas qu'un seul domaine, ce qui pourrait simplifier les choses. Comme je l'ai écrit, je n'ai fait que le déploiement et basta. tous les ".pem" sont en place, les infos renvoyées par Firefox sur les certificats sont conformes aux dernières mises à jour, les affectations n'ont pas bougé. Alors, je veux bien creuser un peu plus mais en l'état je ne vois rien qui cloche. Je ne dis pas que ton script ne sert à rien, je dis qu'il ne sert plus à grand chose, ou pour être plus précis, qu'il ne m'est d'aucune utilité. As-tu au moins essayé de ne faire que le déploiement ? Parce que faire tourner un script qui est sensé corriger des erreurs qui n'existent plus ne prouve pas qu'il sert à quelque chose. Juste qu'il s'évertue à recopier des fichiers qui n'ont pas besoin de l'être. Je ne vois pas l'intérêt d'un déclenchement avant les 60 jours, mais s'il faut le faire, un simple --force dans le script permet de renouveler le certificat. Aisément contournable en créant un user admin spécifique uniquement pour ça que tu appelles par exemple ACME avec des droits très limités et sans double authentification.

@Diabolomagic, oui, le 216 comporte 2 licences comme pratiquement tous les NAS Synology. Seuls les premiers modèles (serie 01 à 08, et peut-être 09) n'avaient qu'une seule licence. Les NVR en ont 4.

@oracle7 Salut, Je viens vers toi à propos de ce tuto car je me demande quelle en est encore la pertinence. Je viens d'avoir 3 renouvellements automatiques avec deploy_hook sur 3 NAS, 2 avec la méthode Neilpang sur github dont la tienne est dérivée, et l'autre via Docker à partir de la toute première version du tuto d' @Einsteinium qui est en fait une réplique du même tuto de github. J'ai aussi eu fin décembre un renouvellement auto via Docker sur un autre NAS et son prochain renouvellement est prévu pour le 27. Tous se sont déroulés sans utilisation d'un script supplémentaire (celui de ton tuto) pour pallier un supposé dysfonctionnement et tous les certificats ont été correctement reportés dans les différentes applications concernées que ce soit dans /usr/syno/etc/certificate » ou « /usr/local/etc/certificate Aussi, je me pose la question de l'utilité de ton script avec les dernières versions de DSM. Je me trompe peut-être, mais à mon avis le deploy_hook a été corrigé, ce qui de facto ne nécessiterait plus de rajouter ton script. J'ai plusieurs renouvellements planifiés dans les prochains jours. Je te ferai un retour, mais je suis persuadé qu'ils se dérouleront sans encombre.

@CyberFr Attention tout n'est pas sauvegardé par Hyperbackup et il faudra malgré tout mettre les mains dans le cambouis pour rétablir toutes les fonctions. Par exemple, les certificats ne sont pas sauvegardés, le reverse proxy non plus, et si je ne fais pas erreur, les tâches planifiées non plus, tout comme un certain nombre de paquets comme par exemple Docker et ses containers sur certains modèles de NAS. Disons que l'essentiel est préservé et permet de repartir sur de bonnes bases sans avoir à tout reconstruire.

Pour pouvoir restaurer un NAS, il faut d'abord installer DSM puis les paquets, y compris Hyperbackup et Hyperbackup Vault bien sûr, et on les lance. Dans Hyperbackup, on se reconnecte à des tâches existantes pointant vers les sauvegardes. Il suffit de lancer les restaurations et c'est reparti.

Et encore moins en présentation. J'ai rarement vu plus court. Sans en faire un roman, on aurait aimé en savoir un peu plus sur vous, votre environnement informatique, votre modèle de NAS, etc... Sinon, ça n'a pas de sens. Bienvenue dans la communauté.

Vous avez donné la réponse. Si vos identifiants ont changé, il faut bien évidemment les mettre à jour dans toutes les connexions au NAS, Drive y compris.

Bof, à quoi bon créer plusieurs fois des ouvertures de ports, c'est le routeur derrière qui filtre. Une DMZ sur une IP dédiée à un routeur ne pose pas de problème en terme de sécurité. Ca revient à faire du bridge, tout simplement.

Ah l'interface chaise/clavier, c'est bien souvent là que se situe la source du problème, et plus l'interface prend de l'âge, plus les problèmes s'accentuent 😉

D'autant qu'il est impossible de faire fonctionner les deux sur un même NAS car ils utilisent les mêmes ressources. C'est soit l'un, soit l'autre.

Pas compris. Pour que les dossiers partagés puissent être intégrés dans CS, il faut d'abord les inclure dans le périmètre CS. Avec un compte admin, vous allez dans la console d'administration de Cloud Station serveur, Dossiers de l'équipe et vous activez les dossiers partagés à inclure. Ensuite, sur chaque client pour lequel le compte utilisateur est déjà dans Cloud Station, vous créez une nouvelle connexion qui pointe vers le dossier partagé. Vous le faite pour chaque dossier auquel l'utilisateur a accès.

Peut-être. Je n'utilise pas le VPN à partir d'un smartphone. Seulement à partir de mon PC sous Win10. OpenVPN est très bien et je l'utilise beaucoup pour la maintenance à distance du parc de NAS dont je m'occupe, mais on doit systématiquement renseigner les identifiants de connexion alors qu'on peut les enregistrer dans les paramètres pour une connexion en L2TP ce qui au final ne demande qu'un clic se souris pour se connecter. Perso, je n'ai que mon PC portable que j'utilise avec L2TP lorsque j'ai besoin d'intervenir sur DSM à distance. J'utilise aussi L2TP pour les connexions et sauvegardes inter NAS car là aussi, il n'est point besoin de passer par un fichier de configuration, la liaison se faisant en direct. Mis à part l'accès à DSM ou la synchro entre 2 NAS, je n'utilise pas le VPN, les accès classiques aux comptes utilisateurs étant suffisamment sécurisés pour pouvoir prendre un risque raisonnable.

Non. sur chacune des règles, il ne faut autoriser que la France. Mais attention, si vous avez un certificat LE à renouveler, il faut aussi autoriser les US sur le 80 et/ou le 443 au moins le temps du renouvellement.

Il faut prendre le problème à l'envers. Au lieu de refuser tous les pays sauf la France il faut accepter uniquement la France

@Jeff777 @Drickce Kangel , j'ai une FB Révolution et je n'ai aucun problème que ce soit avec L2TP ou open VPN. La FB est en mode routeur et en DMZ vers mon routeur, ceci pourrait expliquer cela. Perso, à l'usage je préfère L2TP car il est activable directement à partir du bouton réseau alors qu'O.VPN demande des manipulations plus contraignantes.

La seule solution c'est d'avoir un NAS compatible BTRFS, ce qui n'est pas le cas de tous les NAS. https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/Which_Synology_NAS_models_support_the_Btrfs_file_system

Le deuxième LAN n'a aucun intérêt. Vous pouvez le supprimer et vérifiez que les redirections de ports se font bien vers le LAN actif (vos captures d'écran indiquent HomeBase mais ne précisent pas lequel). Vérifiez aussi que le VPN est bien dirigé vers le même LAN dans les paramètres généraux.

N'y aurait-il pas tout simplement un blocage d'IP (voir dans le menu sécurité, onglet Compte, bouton "Autoriser/Bloquer la liste") ?

Je ne vois pas alors ce qui peut clocher. Vous pouvez faire une sauvegarde de votre configuration, et faire un reset de second niveau (Mode 2) pour réinitialiser DSM et refaire son installation avec synology assistant. https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS_7 Si le défaut persiste, il faudra vous tourner vers l'assistance.