Jeff777

Pas de quoi 😉

Peut-être mais tu risques d'attendre longtemps l'update 1 qui corrige la non détection de la mise à jour d'après ce que je comprends 😉

A voir également :

Bonjour, Il faudrait être un peu plus précis. C'est en remplaçant le wifi par un câble éthernet que vous n'arrivez plus à vous connecter ou bien c'est un autre problème ? Et une petite présentation permettra de connaître un peu mieux la configuration de votre installation et votre niveau de compétence : https://www.nas-forum.com/forum/forum/16-présentation/ ça peut servir pour vous dépanner 😊 A bientôt

Bienvenue Julien, A bientôt sur ce forum.

Dans les paramètres Hyperbackup, dans l'onglet application il y a trois colonnes : La première nomme l'application, la seconde nomme les dossiers partagés à sauvegarder dans l'onglet précédent si l'on désire sauvegarder l'application (c'est à dire si l'on a coché la case devant la première colonne), la troisième stipule si l'application est arrêtée le temps de la sauvegarde. Le dossier homes est nécessaire de même que les dossiers d'équipe. Home n'est pas indispensable car, si je ne me trompe pas, c'est une recopie du dossier personnel home de l'utilisateur actuellement connecté . L'original est présent dans le dossier homes qui n'est visible que par l'administrateur.

Ce tuto est l'objet d'une collaboration avec @dd5992 N'oubliez pas de le remercier si cela vous à plu 😉 Prérequis : · avoir 2 synos sur le réseau local · une box compatible IPV6 · Avoir son propre nom de domaine et être ns et soa de sa zone (voir Tuto de Fenrir DNS serveur). · Savoir utiliser le reverse proxy : (voir Tuto de Kawamashi ) · Avoir implémenté le tuto de Fenrir sur la sécurisation des accès. Notation : On notera « ndd » le nom de domaine principal utilisé (par exemple machin.fr) Idée directrice : But à atteindre : accéder en interne et en externe aux applications des synos ainsi qu’aux périphériques du réseau local avec une adresse xxx.ndd, même en cas de panne ou de déconnexion d’internet de l’un des deux synos (fonctionnement dégradé), tout ceci en n’utilisant que le port 443 (https), le port 80 pouvant être utilisé pour rediriger son traffic sur le port 443 ou pour un autre usage (par exemple être disponible pour le renouvellement du certificat Let’s Encrypt – en limitant l’accès dans le pare-feu). Bien entendu, en cas de fonctionnement dégradé il ne sera pas possible d’accéder, depuis l’extérieur, aux applications du syno déconnecté d’internet 😊. Lors d’une connexion à partir d’une adresse de type « xxx.ndd » un reverse-proxy est utilisé pour accéder à une application de l’un des synos ou à l’un des périphériques (imprimante, routeur, caméra, …). L’idée est d’implémenter un reverse-proxy dans chacun des deux synos, chacun étant accessible de l’extérieur avec la même adresse et donnant accès aux mêmes applications et périphériques du réseau local. La difficulté principale est de conserver la connexion depuis l’extérieur avec le réseau local lorsque le syno1 qui héberge la zone locale est déconnecté d’internet. Pour cela nous allons utiliser la recopie de la zone publique sur le DNS secondaire et transmettre par cette zone l’adresse IPV6 du syno2 comme ns publique IPV6. L’autre difficulté est d’utiliser les reverse-proxies sur 2 synos différents avec la contrainte de n’utiliser que le port 443, car en IPV4, il n’est possible de rediriger ce port que sur l’un d’eux. L’IPV6 nous permettra de résoudre cette difficulté tout en conservant le même niveau de sécurité. Réalisation : Fonctions IPV6 utilisées Règle générale : En IPV6, toutes les machines du réseau local qui sont compatibles avec ce protocole (routeurs, synos, PC, caméras, …) peuvent être accessibles depuis Internet grâce à leur adresse IPV6 publique, la seule condition est que IPV6 soit activé sur la box et sur chacune des machines à contacter. Pour notre tuto : Pour pouvoir contacter Syno2 en IPV6, il suffira d’activer l’IPV6 sur Syno2 et la box (si ce n’est déjà fait). On pourra garder la configuration du reste du réseau local tel qu’il était précédemment, c’est-à-dire en IPV4. En IPV6, la box se comporte comme un simple routeur (même en mode bridge) sans PAT (Port Address Translation), donc le flux IPV6 entrant sera directement routé vers l’équipement qui a la bonne adresse IPV6, sans configuration particulière. Les deux comportements IPV6 et IPV4 vont coexister, et en IPV4, le PAT utilisera les redirections de port de la box pour envoyer le flux IPV4 vers Syno1 sur le port d’entrée du reverse-proxy. Il faut donc enregistrer dans les DNS du domaine l’adresse IPV6 de Syno2 (par un enregistrement AAAA) et installer un reverse-proxy sur ce syno. L’ouverture du réseau local à IPV6 donnant accès de l’extérieur à tout équipement local, il conviendra de filtrer les accès. C’est ce qui sera abordé dans la section Sécurité,ci-après. Nom de domaine et DNS Point de départ : les prérequis ci-dessus. Syno1 : Dans la zone publique on ajoute (ou modifie) deux enregistrements AAAA : ndd AAAA IPV6syno2 adresse publique ns.ndd AAAA IPV6syno2 adresse publique Syno2 : Pour que le domaine ne soit pas bancal et qu’il réponde correctement au test https://zonemaster.net on crée une zone publique. Avec les enregistrements suivants : ndd NS ns.ndd ndd NS ns1.dnssecondaire ndd NS ns2.dnssecondaire (éventuellement) ndd AAAA IPV6syno2 adresse publique ns.ndd AAAA IPV6syno2 adresse publique Dans notre cas nous avions un enregistrement *.ndd CNAME ns.ndd et un certificat wildcard qui nous évite de nombreux enregistrements CNAME et la création du certificat correspondant. Il ne reste plus qu’a renseigner pour cette zone la règle de transfert de zone avec l’adresse IPV6 du DNS secondaire (IPV4 peut marcher aussi) et renseigner la notification des zones esclaves puis vérifier le zone master. Par rapport au résultat du test https://zonemaster.net/ avant réalisation de ce tuto, Il ne doit y avoir qu’un seul warning supplémentaire sans importance concernant les numéros de série des SOA qui sont différents (on peut d’ailleurs facilement corriger ceci). Edit : pour simplifier les mises à jour des zones, il est possible que les zones locales et publiques du syno1 soient transférées dans le syno2 par des zones slaves. Utilisation des reverse-proxies On complètera le reverse proxy du syno1 avec les applications du syno2 en employant des noms différents de celles du syno1 et une redirection vers : http://IP-locale-syno2:port de l’appli. Pour éviter de futures ambiguïtés on remplacera, dans les redirections des applications syno1, localhost par l’adresse locale du syno1. On fait, sur le syno2, un reverse proxy, avec les mêmes enregistrements. Cas particuliers : 1/ Les virtual hosts du syno1 ne sont pas affectés. Il n’a pas été fait de test sur d’éventuels virtual hosts du syno2. 2 / PhotoStation La commande suivante dans le .htaccess (en plus de l’éventuelle redirection du http en https si l’on utilise le port 80) : RewriteCond %{HTTP_HOST} ^photo.ndd$ RewriteRule ^$ https://photo.nddr/photo [L,R=301] peut être utilisée, dans les deux synos, en plus du reverse proxy. Il faut dans ce cas remplacer photo.ndd par photo2.ndd (par exemple) pour le syno2 3/ SurveillanceStation Le reverse proxy réalisé de manière identique aux autres applications n’est pas suffisant pour visualiser les flux vidéo des caméras (bug connu), Il faudra utiliser l’application client. Il est possible d’utiliser le même nom pour les applications des deux synos , dans ce cas, si l’on paramètre SurveillanceStation de manière identique, on obtient une redondance sur la vue obtenue. Seuls les enregistrements réalisés seront différents d’un syno à l’autre. Avec les synos1 et 2 (ou uniquement syno1) opérationnels, on se connecte à l’aide de l’application client à SurveillanceStation du syno1. Si le syno1 est down l’image se gèle et en rafraichissant l’application client, elle se connecte sur SurveillanceStation du Syno2. Sécurité : Pare-feu IPV6 Comme on l’a vu précédemment, l’ouverture du réseau local à IPV6 impose de protéger les équipements locaux contre les accès indésirables provenant de l’extérieur. Dans l’exemple de ce tuto, il s’agit de tous les accès sur toutes les machines locales, à l’exception des ports 443 (et éventuellement 80) de Syno2. Donc pour Syno2 il faudra activer le pare-feu en n’autorisant pour le traffic IPV6 entrant que les ports 443 et/ou 80 et en restreignant plus si besoin. On peut ajouter d’autres filtres, par exemple restreindre en plus l’accès en provenance de certaines zones géographiques. Pour interdire l’accès IPV6 vers les autres machines, plusieurs possibilités : · Ne pas activer IPV6 sur une machine permet d’interdire tout accès IPV6 à cette machine. C’est possible sur les synos (Panneau de configuration/Réseau/Interface réseau/LAN/Modifier/IPV6/Configuration d’IPV6:Desactivé), les machines (PC ou serveurs) sous Windows (voir ici) et sur certains autres équipements. · Utiliser un pare feu local à chaque machine (solution idéale sur syno - ici, existe sur Windows). A utiliser pour syno1. · La troisième solution est plus radicale, mais nécessite un équipement spécifique : Installer un pare-feu en entrée du réseau local (par exemple dans un routeur en aval de la box en mode bridge) (voir la configuration ici), en ne laissant passer que les accès vers le port 443 (et 80 si besoin) de Syno2 (on peut là aussi ajouter d’autres filtres, par exemple restreindre l’accès pour certaines zones géographiques). Note : Lors de nos tests, nous avons également essayé d’utiliser le nouveau pare-feu IPV6 de notre box (une freebox révolution). Ce pare-feu (comme la plupart des pare-feux IPV6 des box n’est pas configurable et en l’activant, nous avons perdu l’accès à Syno2 de l’extérieur. Donc pour appliquer ce tuto, il faut désactiver le pare-feu IPV6 de la box. Résultats En cas de panne du syno1 : périphériques, DSM et applications du syno2 resterons accessibles du réseau local et de l’extérieur tant que l’enregistrement IPV6 du syno2 en tant que serveur de nom restera propagé. A priori tant qu’un changement n’aura pas été transmis dans le DNS secondaire par la zone publique du DNS syno1. Si les syno1 et 2 sont opérationnels tous les périphériques, DSM et applications sont accessibles (sauf DSM et applications syno2 si celui-ci est en panne, bien sûr) Restrictions · En cas de panne de la box, plus aucun accès · La redondance n'est disponible que pour les clients externes qui ont une connectivité IPV6 (fonctionnement non redondant en IPV4) Schémas illustrant le fonctionnement

Bonjour Thierry, Ce n'est pas évident à trouver. J'ai rajouté une vue à mon post. Il faut aller sur le site de téléchargement, avoir la version 24922 et tout en bas de la page sélectionner la version à mettre à jour. J'ai réussi à faire la mise à jour sur DS212+ et DS218+ avec update1.😊 Mais c'est tiré par les cheveux cette histoire !

Bonjour à tous, Pour ceux qui comme moi sont bloqués sur DSM 6.2.2 -24922, je viens par hasard de découvrir cet update (dispo depuis le 11 juin. A télécharger sur le site de Synology). Il corrige entre autre : l'absence d'information concernant la disponibilité d'une révision du DSM .......et oui !!! et d'autre petites choses bien utiles : A télécharger là :

Bonjour, Tout ce que je peux dire c'est que j'héberge un site wordpress sur mon Syno, j'y accède par un virtual host (web/wordpress). Je viens d'essayer et ça marche en interne et en externe via un proxy.

Pas de quoi ! Je ne connaissais pas le triple karmeliet ...moi aussi j'ai appris quelque chose 😃. J'aime bien la bière faudra que je goûte celle là. Je ne sais pas s'il y a une bonne et une mauvaise façon d'apprendre mais sur le Syno, je fais comme toi, j'essaie et si je n'y arrive pas je viens sur ce forum. En général ça fonctionne 😉. A +

Ah mais je suis étourdi bien sûr il faut mettre localhost dans la destination 🤪. Pourquoi tu ne pourrais pas taper localhost ?? Sinon tu mets l'adresse local du proxy en 192.168.x.x. Pour le VPN je ne sais pas à quoi tu le destinais. Son utilisation n'a rien à voir avec le fait que tu sois en filaire ou non. Le VPN du NAS est utile lorsque tu te connectes de l'extérieur. On peut l'illustrer par un tunnel qui relie ton PC externe à ton réseau local. Donc personne ne peut voir ce qui se trame dans ce tunnel. De plus de ton PC externe c'est comme si tu étais dans ton réseau local, tu peux donc atteindre tes équipements avec leurs adresses locales. Par exemple 192.168.0.10:5000 te conduit au DSM direct (192.168.0.10 étant l'adresse du NAS par exemple).

Pour openVPN il faut ouvrir et rediriger le port 1194. Et éditer le fichier de configuration. Le mieux c'est de suivre ce tuto partie openVPN 😊

Ben si quand même tu ouvres tous les ports. 1/Tu retires le DMZ, 2/Il te faut le port 443 ouvert dans le pare-feu du NAS (sécurité/pare-feu) pour entrer sur ton réseau en https. 3/Ce port doivent être redirigés vers le NAS dans ta box. 4/ça c'est bien de le faire. ça permet de ne pas ouvrir les ports 5000 et 5001 de plus la requête se fait en https://monchoix.synology.me . La redirection vers le port 5000 se fait dans le réseau local donc derrière le pare-feu et ce n'est pas la peine d'utiliser https puisque tu es dans ton réseau local. Il y a un tuto ici : De plus ça permet de faire des adresses pour les appli du nas sans ouvrir de nouveaux ports. Comment rediriger automatiquement http://monchoix.synology.me vers https://monchoix.synlogy.me? Quand ça marche en https et si tu veux simplifier et ne plus avoir à taper https , tu fais un .htaccess dans le NAS à la racine du dossier web. (Il n'est pas recommander d'utiliser l'option du DSM de redirection du http vers https.) Dans ce cas il faut autoriser le port 80 (pare-feu et redirection). Un htaccess se fait avec un fichier texte tu mets les instructions suivantes dans ton fichier texte avant de le convertir en changeant le nom+extension en .htaccess : RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Bien sûr autoriser le port 5001 et le rediriger dans la box ! Ou mieux faire un reverse proxy dans le portail des applications : https://monchoix.synology.me:443 ==>http://monchoix.synology.me:5000

https://openvpn.net/vpn-server-resources/connecting-to-access-server-with-macos/

Ah oui il faut rediriger. Pour le profil VPN dans l'interface réseau je ne sais pas à quoi ça sert. Moi je n'en ai pas et je peux joindre mon NAS de l'extérieur avec ou sans VPN. Par contre j'utilise openVPN

Bonjour, D'abord si tu as pris les ports standards c'est le port 5001 qu'il faut mettre dans l'adresse ci-dessus. Si ça ne marche pas essaie déjà avec l'adresse https://monchoix.synology.me:5001 mais sans le VPN en retirant la redirection de http vers https et en autorisant le port 443

Avec la méthode ci-dessus tu as l'adresse du stockage ?

Bonjour, Il n'y a peut-être pas de dossier de stockage de créé pour les enregistrements. Dans SS Icône "enregistrements" puis onglet stockage. Vérifie si un stockage existe, sinon ajouter un stockage.

Bonjour, J'ai celle-ci qui marche très bien avec mon Syno. Je l'ai payé 35€, par contre elle est fixe et n'est plus en stock sur ce site. Deux conseils : ne te limite pas aux caméras d'intérieur, celle d'extérieur ne sont pas tellement plus chères et il y en a plus. Plutôt que du WiFi tu peux employer le CPL. De toute façon il te faut un câble pour alimenter ta caméra. Tu insères un plug CPL avec prise filtrée intégrée entre l'alimentation de ta caméra et le câble d'alimentation et tu branches un câble éthernet entre les deux connecteurs J45 (cam et plug) l'autre plug entre l'alim de ta box et la prise. J'ai deux caméras montées comme ceci avec des câbles de 15 et 25m de long et ça fonctionne bien. avec l'appli client de Surveillance station je peux visualiser depuis le réseau extérieur. Le CPL augmente le prix si tu n'en a pas. Mais il n'y a pas besoin de beaucoup de débit des anciens d'occasion peuvent faire l'affaire (avec prise intégrée ne pas oublier). Et puis un bridage ça se négocie 😉

Bonjour, Il faut peut-être faire l'inverse : Chercher sur internet un produit qui convient en coût et en performance (y'en a aussi un paquet) puis vérifier qu'elle est compatible. Sachant que la plupart le sont. J'en ai achetée une pas chère (35€, Chinoise) fixe avec détection de mouvement, fonction nuit qui fonctionne très bien avec SurveillanceStation et je ne suis pas sûr qu'elle soit dans la liste des compatibles syno.

Pas très courtois le SAV, mais ça reste une bonne affaire 😊

Retour pour ceux que ça intéresse après nombreux essais avec dd5992 par MP. La solution de dd5992 qui consiste à ajouter deux entrées AAAA pour désigner le syno2 comme serveur de nom, complétée par une zone publique sur le syno2 accessible seulement en IPV6 donne satisfaction. Avec .htaccess et reverse proxy sur chaque syno on peut se connecter sur les périphériques et sur dsm, applis syno1 et dsm, appli syno2 (à condition que le syno en question soit présent bien sûr) ceci dans les trois cas de figures (syn1,syno2,syno1 et 2 connectés). Dans ce cas la zone du syno2 n'est pas répliquée sur le dns secondaire il ne peut y avoir qu'une seule zone publique apparemment, celle du syno1. Par contre le zonemaster avec les deux syno est correct avec quelques "warning" en plus des remarques habituelles sur le DNSSEC et l'enregistrement PTR de ns.nnd en IPV6: Le zone master avec un seul syno a logiquement des points critiques concernant l'impossibilité de joindre le serveur de nom ns.ndd en ipv6 lorsque syn2 est down et en IPV4 lorsque syno1 est down. Reste à voir si la situation avec seulement le syno2 est stable même à l'expiration des TTL du DNS secondaire. Mais cette situation est un mode dégradé qui n'est pas sensé durer une journée.

Bienvenue @racsi, Il y a plusieurs dinosaures sur ce forum mais l'âge à peu d'importance. A bientôt