Mic13710

@Dimebag Darrell, merci de ne pas citer inutilement les posts auxquels vous répondez, ça alourdi la discussion sans rien y apporter. L'intérêt d'un serveur DNS interne c'est de pouvoir utiliser la même url quel que soit l'endroit où on se trouve, chez soi ou à l'extérieur. Par exemple, pour rejoindre Audio station du NAS, vous pouvez paramétrer le reverse proxy pour que l'adresse https://audio.ndd soit dirigée vers localhost:leport http d'audio station. A l'extérieur, les serveurs DNS redirigeront votre requête vers votre routeur qui la transmettra au NAS. Chez vous, c'est le serveur DNS local qui résoudra la même url et la dirigera vers le NAS. Mais pour que ça fonctionne, il faut impérativement que vous puissiez modifier les adresses des serveurs DNS propagées en DHCP par le routeur. Malheureusement certains routeurs n'acceptent pas ces modifications (orange entre autres). Je vous invite à voir le tuto de mise en place du serveur DNS dans la partie tutoriels.

@Dimebag Darrell le reverse proxy ne fait que le relais entre un ndd et une application. Il n'est pas lié uniquement aux accès externes. Si vous avez un serveur DNS privé (celui du NAS par exemple), il pourra faire le même exercice avec les mêmes ndd une fois résolus par le serveur DNS.

Est-ce que tu as plusieurs certificats, et si oui, est-ce que le nom du certificat a été pris en compte par le script comme ceci : SYNO_Certificate='ici le nom du certificat'

@oracle7 je n'ai aucun problème avec mes fichiers account.conf et ndd.conf, et jusqu'à la dernière version de acme.sh, tout fonctionnait parfaitement depuis des mois avec plusieurs renouvellements et déploiements. Je pense que nous avons tous les deux la toute dernière version d'acme.sh (3.0.6 deuxième jus). Malheureusement (pour moi) le renouvellement a été fait avec la première version 3.0.6 et peut-être un mécanisme a été cassé qui ne se voit pas dans les .conf. @Kramlech c'est en faite le même problème de renouvellement apparu avec la dernière version d'acme.sh. Sauf que toi, tu es reparti en cours de route sur une nouvelle install et que ça ne se passe pas correctement. Pour répondre à ton souci de clés : oui, tu peux très bien en créer de nouvelles mais si tu es sûr des anciennes et qu'elles sont toujours valides, ce n'est pas nécessaire. Tu peux vérifier ça dans la console de ton compte ovh. https://api.ovh.com/console/

@oracle7 toutes les données ont été créées avec des export exactement comme dans le github et dans le tuto. Les SAVED dans les fichiers ndd.conf et account.conf sont créés par le script. Je n'ai rien touché dans ces fichiers. Et si tu regardes le tuto, il y a bien des SAVED pour toutes les données exportées par les .conf. De même que le codage en base 64 du nom du certificat qui a été introduit par le script il y a quelques mois de ça. Là aussi je n'ai rien fait d'autre lors du premier déploiement que d'exporter en clair le nom donné dans DSM. Le script a fait le reste. Regardes la ligne SAVED_SYNO_Certificate dans mon ndd.conf, le nom en base 64 est borné __ACME_BASE64. Ce n'est pas de ma propre initiative. D'ailleurs, si tu regardes le fil de discussion du tuto, à un moment j'ai signalé ce changement du nom en dur en base 64. Et pour compléter, la conversion du texte base64 me donne bien le nom du certificat que je souhaite déployer. Lors du déploiement manuel que j'ai tenté aujourd'hui (voir ci-dessus), j'ai bien indiqué le nom du certificat en clair, mais acme.sh ne l'a pas pris en compte. Je viens d'ouvrir un sujet sur github pour ce problème.

@oracle7 merci pour cette info. J'ai ajouter le syno-create mais ce n'est pas ça. Le problème vient de la non prise en compte du nom du certificat. @Einsteinium j'ai trouvé d'où vient le problème. Le déploiement ne se fait pas car le script n'a pas pris en compte le nom du certificat. Pour le déploiement en décembre de l'un des certificats le nom est pris en compte (ligne 3) et le déploiement se fait bien : [Sun Dec 4 00:08:53 UTC 2022] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Sun Dec 4 00:08:53 UTC 2022] _cdomain='ndd.net' [Sun Dec 4 00:08:53 UTC 2022] SYNO_Certificate='Wildcard ndd.net' [Sun Dec 4 00:08:53 UTC 2022] _base_url='http://172.17.0.1:5000' [Sun Dec 4 00:08:53 UTC 2022] Getting API version [Sun Dec 4 00:08:53 UTC 2022] GET [Sun Dec 4 00:08:53 UTC 2022] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Sun Dec 4 00:08:53 UTC 2022] timeout= [Sun Dec 4 00:08:53 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:54 UTC 2022] ret='0' [Sun Dec 4 00:08:54 UTC 2022] Logging into 172.17.0.1:5000 [Sun Dec 4 00:08:54 UTC 2022] POST [Sun Dec 4 00:08:54 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Sun Dec 4 00:08:54 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:55 UTC 2022] _ret='0' [Sun Dec 4 00:08:55 UTC 2022] token='NFYYbsmbPYtng' [Sun Dec 4 00:08:56 UTC 2022] Getting certificates in Synology DSM [Sun Dec 4 00:08:56 UTC 2022] POST [Sun Dec 4 00:08:56 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Sun Dec 4 00:08:56 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:56 UTC 2022] _ret='0' [Sun Dec 4 00:08:56 UTC 2022] escaped_certificate='Wildcard ndd\.net' [Sun Dec 4 00:08:56 UTC 2022] Generate form POST request [Sun Dec 4 00:08:56 UTC 2022] Upload certificate to the Synology DSM [Sun Dec 4 00:08:56 UTC 2022] POST [Sun Dec 4 00:08:56 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=NFYYbsmbPYtng&_sid=JZY_iOUr1T19dcU5UOBsSeQFvHy94qua4IN_UVasNCwpnF9g-d1JPES5RNU9JhZgnZUtEULoix5WhifQ0pc2BU' [Sun Dec 4 00:08:56 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:09:44 UTC 2022] _ret='0' [Sun Dec 4 00:09:44 UTC 2022] http services were NOT restarted [Sun Dec 4 00:09:44 UTC 2022] Success Pour celui du 2 janvier, le nom n'est pas pris en compte (ligne 3) ce qui empêche le déploiement : [Thu Feb 2 00:04:42 UTC 2023] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Thu Feb 2 00:04:42 UTC 2023] _cdomain='ndd.net' [Thu Feb 2 00:04:42 UTC 2023] SYNO_Certificate [Thu Feb 2 00:04:42 UTC 2023] _base_url='http://172.17.0.1:5000' [Thu Feb 2 00:04:42 UTC 2023] Getting API version [Thu Feb 2 00:04:42 UTC 2023] GET [Thu Feb 2 00:04:42 UTC 2023] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Thu Feb 2 00:04:42 UTC 2023] timeout= [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:42 UTC 2023] ret='0' [Thu Feb 2 00:04:42 UTC 2023] Logging into 172.17.0.1:5000 [Thu Feb 2 00:04:42 UTC 2023] POST [Thu Feb 2 00:04:42 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] token='RabpfZzxqvW0Q' [Thu Feb 2 00:04:44 UTC 2023] Getting certificates in Synology DSM [Thu Feb 2 00:04:44 UTC 2023] POST [Thu Feb 2 00:04:44 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Thu Feb 2 00:04:44 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] escaped_certificate [Thu Feb 2 00:04:44 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:04:44 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:04:44 UTC 2023] Deploy error. [Thu Feb 2 00:04:44 UTC 2023] Return code: 1 [Thu Feb 2 00:04:44 UTC 2023] Error renew ndd.net. Il n'y a pas de problème dans le fichier ndd.net.conf dans le dossier ndd.net où le nom du certificat est bien indiqué en base64 : Le_Domain='ndd.net' Le_Alt='serv1.ndd.net,*.serv1.ndd.net' Le_Webroot='dns_ovh' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='4096' Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxxxxxx' Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/xxxxxxxxxxxxxxxx' Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/xxxxxxxxxxxxxxxxxxxxxxxxxx' Le_CertCreateTime='1675296385' Le_CertCreateTimeStr='2023-02-02T00:06:25Z' Le_NextRenewTimeStr='2023-04-02T00:06:25Z' Le_NextRenewTime='1680393985' Le_DeployHook='synology_dsm,' SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='user' SAVED_SYNO_Password='password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='__ACME_BASE64__START_nom du certificat en base 64__ACME_BASE64__END_' SAVED_SYNO_TOTP_SECRET='' J'ai tenté un déploiement manuel avec une tâche planifiée : $ export SYNO_Username='user' $ export SYNO_Password='password' $ export SYNO_Certificate="le nom de mon certificat" docker exec Acme sh -c "acme.sh --deploy -d 'ndd.net' --deploy-hook synology_dsm" Et là aussi le nom du certificat n'est pas pris en compte (ligne 3) : [Thu Feb 2 00:04:42 UTC 2023] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Thu Feb 2 00:04:42 UTC 2023] _cdomain='ndd.net' [Thu Feb 2 00:04:42 UTC 2023] SYNO_Certificate [Thu Feb 2 00:04:42 UTC 2023] _base_url='http://172.17.0.1:5000' [Thu Feb 2 00:04:42 UTC 2023] Getting API version [Thu Feb 2 00:04:42 UTC 2023] GET [Thu Feb 2 00:04:42 UTC 2023] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Thu Feb 2 00:04:42 UTC 2023] timeout= [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:42 UTC 2023] ret='0' [Thu Feb 2 00:04:42 UTC 2023] Logging into 172.17.0.1:5000 [Thu Feb 2 00:04:42 UTC 2023] POST [Thu Feb 2 00:04:42 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] token='RabpfZzxqvW0Q' [Thu Feb 2 00:04:44 UTC 2023] Getting certificates in Synology DSM [Thu Feb 2 00:04:44 UTC 2023] POST [Thu Feb 2 00:04:44 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Thu Feb 2 00:04:44 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] escaped_certificate [Thu Feb 2 00:04:44 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:04:44 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:04:44 UTC 2023] Deploy error. [Thu Feb 2 00:04:44 UTC 2023] Return code: 1 [Thu Feb 2 00:04:44 UTC 2023] Error renew ndd.net. Bref, il semblerait qu'il y ait aussi un problème au niveau du script de déploiement. Edit : Je réalise que le renouvellement du 2 février a été fait avec la première version 3.0.6 de acme.sh (celle qui a posé des problèmes à certains lors des récents renouvellements). Sa mise à jour automatique a été faite le 5 février sur ce NAS mais malgré cela, le déploiement ne se fait pas.

@Einsteinium, je viens de m’apercevoir que sur un des NAS dont je m'occupe, les deux certificats sur 2 ndd chez OVH ont bien été renouvelés automatiquement le 2 février avec pour chacun : [Thu Feb 2 00:06:25 UTC 2023] Cert success. [Thu Feb 2 00:06:25 UTC 2023] Your cert is in: /acme.sh/ndd.net/ndd.net.cer [Thu Feb 2 00:06:25 UTC 2023] Your cert key is in: /acme.sh/ndd.net/ndd.net.key [Thu Feb 2 00:06:25 UTC 2023] The intermediate CA cert is in: /acme.sh/ndd.net/ca.cer [Thu Feb 2 00:06:25 UTC 2023] And the full chain certs is there: /acme.sh/ndd.net/fullchain.cer [Thu Feb 2 00:06:25 UTC 2023] _on_issue_success mais n'ont pas été déployés avec pour tous les deux : [Thu Feb 2 00:06:26 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:06:26 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:06:26 UTC 2023] Deploy error. Voila qu'il n'arrive plus à trouver un certificat qu'il vient d'enregistrer !

@bliz, c'est pour cette raison que je disais "sans garantie", ce qui ne veut pas dire que la solution ne fonctionne pas ! @firlin d'après ce document https://global.download.synology.com/download/Document/Software/AdminGuide/Package/ActiveBackup/All/fre/Synology_ABB_admin_guide_Linux_fre.pdf à la page 21, il semblerait que le transfert vers un autre NAS soit possible via Hyperbackup Cet article peut aussi être utile : https://kb.synology.com/fr-fr/DSM/tutorial/How_to_backup_and_relink_Active_Backup_for_Business_with_DSM_backup_packages

@bliz Normalement ce ne sont pas des fichiers hbk. @firlin Sans aucune garantie, je pense que si tu copies le contenu du dossier Active Backup for Business dans le même dossier du nouveau NAS, tu pourrais ensuite reconnecter sur le nouvel emplacement en cliquant droit sur l'icône de l'Agent sur le PC et en sélectionnant "Modifier la connexion"

@maxou56 c'est vrai et c'est aussi pour cela que le choix importe peu. Et comme il faudra tôt ou tard changer le mode de sauvegarde, autant partir tout de suite sur du Rsync pour ne pas avoir à tout refaire.

Pour ma part je dirais peu importe. Il s'agit simplement de stocker un fichier sur un support. Même si Hyperbackup Vault du NAS (213 ou 214) n'est plus compatible un jour ou l'autre avec la version Hyperbackup du 1821 (ce qui est inévitable), il sera toujours possible de consulter et restaurer les sauvegardes en passant par Synology Hyperbackup Explorer.

@Nono1333 C'est très compliqué de vous dire ce que vous devez faire car comme je l'ai dit, tout dépend des paramétrages du NAS et de ses applications. Vous seul pouvez retrouver vos besoins en consultant les réglages de DSM. Selon que vous avez ou pas un ndd chez Synology ou ailleurs, que vous avez ou pas activé le parefeu, Quickconnect, le proxy inversé, le serveur DNS, le serveur VPN, que vous avez besoin ou pas d'activer ou de rafraichir le DDNS, que vous utilisez ou pas Synology Drive ou d'autres applications nécessitant des ports spécifiques, que vous avez ou pas modifié les ports par défaut des accès au NAS, les réglages du routeur seront différents. N.B. : merci de ne pas citer inutilement les messages précédents. Ca encombre les discussions sans apporter une meilleure compréhension. Pour interpeler un intervenant, il suffit de taper la lettre '@' suivie des premières lettres du pseudo pour affiner la liste et valider le nom recherché. La personne sera notifiée de votre réponse comme vous venez de l'être pour ce message.

@oracle7 ce sont bien les réglages que j'ai fait et c'est bien comme ça que devrait fonctionner le home mode. Ce n'est pas le cas. Home mode du NAS secondaire activé par le NAS principal via le webhook, notifications de mouvement activées sur les notifications générales, désactivées dans celles du Home mode, j'ai des notifications de mouvement chaque fois que je passe devant la caméra. La seule différence, de taille, entre ta config et la mienne c'est les notifications que tu n'actives que la nuit alors que les miennes sont programmées h24/7. Ce serait intéressant que tu fasses un essai avec les notifications activées en continue pour voir si chez toi aussi tu as des notifications de mouvements en étant en home mode. Pour info, détection par caméra ou par SS ne change rien. Edit : Je pense avoir enfin compris le pourquoi des détections. Le Home mode n'agit que sur le NAS où il est activé. Il n'intervient pas sur ce qui est transmis au NAS principal via le CMS. La détection de mouvement semble être toujours active malgré le Home mode activé. Tout mouvement détecté est transmis sur le réseau et si la notification de mouvement est activée sur le NAS principal, elle déclenche un message quel que soit l'état du Home Mode de ce NAS. C'est un peu ballot comme mode de fonctionnement mais bon, il faut que je fasse avec ça. Comme mes caméras sont sur le NAS secondaire, j'ai activé les notifications sur ce NAS et je les inhibe lorsque HM est actif. Le HM de ce NAS est activé/désactivé par le HM du NAS principal via les webhook. Sur le NAS principal qui ne reçoit que les LiveCam du smartphone de mon épouse et du miens, j'ai désactivé les notifications de détection de mouvements car elles ne sont pas utiles pour ce caméras. Ca semble enfin fonctionner avec ces réglages : HM activé : pas de notifications de mouvement, désactivé : je reçois les notifications de mouvement du NAS secondaire.

Je ne comprends rien à la gestion des notifications en Home Mode. La logique voudrait que le choix fait dans les notifications du Home Mode priment sur les choix dans les notifications générales mais ce n'est pas le cas. Si je désactive les détections de mouvements dans le Home mode alors qu'elles sont activées dans le général, je reçois toujours des notifications. Le seul moyen est de les désactiver dans le général. En clair, le home mode ne présente aucun intérêt puisqu'il est incapable de faire cette chose très basique. Ce mode qui est sensé gérer automatiquement le fonctionnement de SS est sûrement une bonne idée, encore faudrait-il qu'il fonctionne, et qu'il le fasse de manière intuitive. Je me demande toutefois si le problème ne viendrait pas du fait que la détection de mouvement est gérée par les caméras et non par SS....

J'ai oublié de vous dire de d'abord commencer par donner une IP fixe à votre NAS sinon vos redirections ne fonctionneront plus lorsque le NAS changera d'adresse. Ce qui suit n'est possible que si votre NAS est en DHCP ! Si une adresse a été définie dans l'interface réseau de DSM, il faudra modifier et régler le LAN1 sur DHCP. Dans la console, vous ouvrez DHCP, onglet Baux actifs, votre NAS devrait apparaître dans la liste. Soit vous voulez conserver l'adresse déjà attribuée auquel cas il faut activer un bail statique pour cette IP, soit vous voulez attribuer une autre IP et dans ce cas, vous récupérez l'adresse MAC du NAS pour la reporter dans l'onglet Baux statique. Là vous cliquez sur Ajouter un bail DHCP statique, vous collez l'adresse MAC, vous indiquez l'adresse IP que vous voulez attribuer au NAS, ajoutez un commentaire et vous sauvegardez. Pour que le NAS prenne sa nouvelle IP, vous débranchez son câble Ethernet et vous le rebranchez.

Ca c'est toi qui le dit. As tu au moins essayé ? Moi je t'affirme que ça marche. Tu peux créer, modifier un fichier root et même définir ses droits utilisateur directement dans l'interface. Lors de la sauvegarde, il faut simplement indiquer la clé pour confirmer le status root et c'est OK. Par contre, il est bien évident qu'on ne peut pas passer des commandes dans WinSCP et qu'il faut pour cela ouvrir le terminal ou putty, tous deux intégrés dans l'interface.

??? De quel accès à distance il s'agit ?

Pour ma part, je réserve le marteau burin uniquement sur les disques HS, ceux que je ne peux plus effacer. Sinon, si j'envisage de céder un disque encore fonctionnel, je fais au minimum une ou deux écritures de zéros pour limiter les possibilités de récupération des données. A moins que la NSA s'intéresse à ma petite personne, la probabilité est mince qu'un quidam s'amuse à tenter une récupération de données fastidieuse et chronophage pour au final avoir des fichiers sans réel intérêt pour la plupart, et ceux qui pourraient l'être sont protégés par des mdp forts.

Il est possible de lancer WinSCP en root avec une clé comme expliqué dans le tuto du regretté unpixel

Réponse obtenue sur le forum us Pour activer le home mode sur un autre NAS : Dans SS du NAS secondaire (dans mon cas c'est le 220+) : Règle d'action, Ajouter "Informations" on donne un Nom à la règle (par exemple Home Mode On), on laisse les choix par défaut : "Déclenchée" et "Peut interrompre", suivant "Evènement", choix "Webhook" dans source d'évènement, on copie l'URL du webhook, suivant "Action", choix "Surveillance Station" dans Périphérique d'action, choix "Accéder au Home Mode" dans Action, suivant pour valider la règle Dans SS du NAS principal avec le CMS (dans mon cas le 718+) : Règle d'action, Ajouter "Informations" on donne un Nom à la règle (par exemple Home Mode 220 On), on laisse les choix par défaut : "Déclenchée" et "Peut interrompre", suivant "Evènement", choix "Surveillance Station" dans source d'évènement, choix "Accéder au Home mode" dans évènement, suivant "Action", choix "Webhook" dans Périphérique d'action, dans URL on colle l'URL du webhook copiée précédemment, les identifiants de connexion du NAS secondaire, suivant pour valider la règle On fait la même manip pour quitter le Home Mode. Avec ces deux règles en place de part et d'autre, les changements du home mode sur le 718 sont bien répercutés sur le 220. Si ce point est maintenant réglé, j'ai toujours des notifications qui arrivent sur ma bal et je ne sais pas pourquoi. Sans doute une autre subtilité de SS qui m'échappe.

Moins dangereux que la disqueuse, un grand coup de massette avec un burin pointu sur la zone des disques, un deuxième à 180° pour se rassurer, et avec ça peu de chance de récupérer quelque chose d'exploitable.

Comme je l'ai dit, il y a 2 licences gratuites. Au delà, il faut acheter des licences pour 1 ou 4 caméras supplémentaires, et ce n'est pas donné.

Pour paramétrer vos ports il faut aller dans la console Freebox OS avec cette adresse : http://mafreebox.freebox.fr Dans la page, vous cliquez sur "Paramètres de la freebox". Après avoir indiqué votre mdp Free qui vous a sûrement été communiqué et qui est le même que celui pour vous connecter à votre compte Free, vous sélectionnez le mode avancé et vous cliquez sur "Gestion des ports". Vous cliquez sur "Ajouter une redirection" IP de destination : c'est l'IP de votre NAS (192.168.x.x), Protocole à choisir selon le service (TCP ou UDP ou les deux), port de début et port de fin sont à la même valeur (par exemple 80) si vous ne transférez que ce port vers le port de destination (c'est en général ce qu'on fait), port de destination, le port vers lequel les requêtes arrivant sur le ou les port(s) de début et de fin doivent être redirigées (80 pour l'exemple que j'ai pris). Ca c'est le principe car en pratique on ne peut guère vous aider sur les ports à rediriger puisque cela dépend du paramétrage que vous avez fait sur votre NAS et nous ne le connaissons pas.

C'est tout de même la base de surveillance Station 😉; Ce n'est pas de ça dont je parle mais de la sauvegarde directe des flux de la caméra sur le NAS. (demande initiale)

Si vos caméras sont compatibles avec Surveillance Station, vous pouvez les faire contrôler par cette application qui enregistrera vos flux selon des règles définies. SS dispose de 2 licences gratuites pour contrôler 2 caméras. Si besoin de plus, vous devrez acquérir des licences supplémentaires, mais attention, le nombre de caméras que peut contrôler un NAS est fonction du modèle de NAS, de la quantité d'image pas seconde (FPS) à traiter et de la qualité des images enregistrées. Pour enregistrer les flux de vos caméras directement dans le NAS, je suppose que c'est dans le paramétrage des caméras que ça se passe en indiquant un support (dossier sur le NAS par exemple), un identifiant d'accès, une fréquence d'enregistrement, autres... Mais attention, les enregistrements vont très rapidement prendre du volume sur votre stockage et vous devrez mettre en place des règles dans le planificateur de tâche pour éliminer les fichiers les plus anciens afin de limiter l'espace occupé.