Jeff777

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

En loopback avec le syno1 déconnecté je ne vois pas de différence de fonctionnement entre les deux solutions. C'est juste le Zone master qui est différente. Au niveau du zone master le test interroge les serveurs de nom NS sur les ports 53 . Pour les IPV4 c'est la même chose dans les deux cas tous répondent. Pour l'IPV6 il n'y a pas d'interrogation du serveur de nom primaire car je le l'ai pas déclaré en AAAA (d'où le warning que les deux serveurs de nom en IPV6 sont sur le même AS car ils sont tous les deux Hurricane). Dans ta solution le serveur de nom primaire est déclaré en IPV6 comme étant sur le syno2 mais celui-ci n'est pas accessible par le serveur secondaire sur le port 53 (d'où une remarque critique. qui n'est pas grave dans ce cas puisqu'il n'y a pas de zone dans le syno2 à répliquer dans le serveur de nom secondaire. En résumé, je pense que le fonctionnement est quasi identique dans les deux cas, car lorsque le syno2 est déconnecté seules le dNS secondaire peut répondre aux requêtes et là on ne trouve qu'un renvoi sur les adresses IPV6 : https://www.nas-forum.com/forum/topic/63247-intérêt-dun-routeur-avec-une-box/?do=findComment&comment=1319376759 Bon la mauvaise nouvelle : Si tout fonctionne en loopback, mon collègue n'a pas réussi à joindre les adresses de mon réseau sauf pour le syno 2. Nous allons essayer avec une appli sur le syno2 pour voir si cela vient du reverse proxy. En effet la redirection du syno2 est vers localhost tandis que que les autres équipements sont vers leur IP locale. Si ça marche avec localhost:7000 par exemple c'est l'IP qui coince si ça ne marche pas c'est le port....enfin je crois 🙄

Oui en IPV4 et IPV6 c'est bien ce que j'ai dans ma zone publique. oui je vais essayer! J'ai toujours un peu la trouille de mettre mon domaine par terre mais je suis téméraire 🤣 Résultat : ça fonctionne MAIS je crois que je vais garder la config précédente. Dans la config précédente je n'ai pas enregistré de serveur de nom IPV6. Zonemaster me fait juste un warning sans incidence que les serveurs de nom IPV6 se trouvent dans le même AS (normal je n'ai que les deux d'Hurrican). Lorsque je rajoute le syno2 en serveur de nom ça pourrait résoudre ce warning mais j'ai un commentaire critique qui dit que le syno2 n'est pas accessible sur les ports 53. C'est idiot car le DNS secondaire n'y trouverait rien mais ça fait tâche! Et impossible de rediriger le port 53 sur les deux syno. Quant à changer chez HE le port pour les recopie de zone je ne sais pas faire et suis pas sûr que cela soit possible (en plus seulement sur le ns en IPV6). Je préfère avoir un test zonemaster correct. Je m'en sers souvent lorsque j'ai un problème de connectivité.En plus je ne vois pas ce qu'apporte ta solution mis à part l'esthétisme 😉. Oui ça évite de saisir toutes les entrées AAAA mais il n'y en a pas tant que cela et de plus on peut faire un copier coller sur l'adresse IPV6 du syno2. A moins que tu ais une idée pourquoi pas Oui mais suite à un autre sujet que j'avais ouvert sur ce forum j'ai décidé de m'en passer. Je vais attendre que le pare-feu IPV6 de la freebox se muscle un peu 🙄 (de toute manière mon syno 2 il me sert de sauvegarde au syno 1 donc normalement il est remisé dans un placard au sous-sol.....je sais il faudrait mieux l'avoir dans un autre lieu)

donc j'avais bon 😊 elle y est ça c'est vrai mais regarde la fin de mon post précédent que j'ai édité 😉 Je viens d'essayer tout fonctionne en débranchant le syno1. Et avec la tablette aussi. Donc le problème que j'avais chez mon collègue venait sans doute du paramétrage de sa box. Bien vu @dd5992 même les équipements qui n'ont pas d'adresse privée IPV6 sur freeboxOS peuvent être joints. Lorsque je coupe le syno1 il ne faut pas que j'oublie de vider les caches sinon la connexion sur le reverse proxy du syno2 ne se fait systématiquement pas !

Petit complément sur les tests d'hier: Pas de connectivité IPV6 avec ma tablette (android 6.0.1). Je précise également que le DHCPV6 sur la box est désactivé et je n'ai pas activé le filtre IPV6 présent dans le dernier firmware de la freebox Il y a 6 heures, dd5992 a dit : Tu dois pouvoir y accéder par le reverse-proxy de syno2 exactement de la même manière que dans le reverse-proxy de syno1 Là mon test c'était syno2 connecté syno1 déconnecté et mon reverse proxy sur syno 2 donnait : https://syno2.ndd==>>localhost:5000. L'adresse syno2.ndd était interprétée par le DNS secondaire (HE) comme son adresse IP publique IPV6 (réplique de la zone publique de mon DNS du syno) et j'arrivais sur le syno 2 où le reverse proxy renvoyait sur le bon port. Sauf que pour les autres équipements je n'avais pas fait de reverse proxy, quel âne ! Alors je viens de le faire et comme je me rends compte que si je débranche le syno1 et fait une requête vers le syno2, d'après le journal du syno2, mon PC s'y connecte avec une adresse IPCV6 publique (qui est d'ailleurs l'adresse temporaire du PC...à méditer!) je me dis que je suis bien en loopback. Je fais donc le même essai sur la caméra après avoir renseigné le reverse proxy et là cela ne fonctionne pas. 1:Est-ce qu'il faut enregistrer dans le DNS les adresses temporaires publiques et non les adresses basées sur l'adresse mac (mais mis à part celle de mon PC je ne sais pas comment les trouver. A noter que les syno semblent ne pas avoir d'adresse temporaire ?) 2:Est-ce que la caméra refuse une connexion en IPV6? 3: Est-ce que le reverse proxy du syno2 ne peut pas router vers un autre équipement 4: Est ce que, le DNS secondaire dirigeant vers l'équipement directement, le reverse proxy est shunté et le port 80 est utilisé ? Ce qui n'est pas celui de la cam ! autre raison.......? Edition 30mn plus tard :: ça aide beaucoup de résumer ses idées! C'est l'adresse IPV6 du syno2 qu'il faut enregistrer dans le DNS primaire pour tous les enregistrements AAAA , et là on arriverait bien sur le syno2 puis sur la cam par le reverse proxy. Je teste !

Merci pour ton retour @breaker85 et c'est bien de l'avoir posté aussi sur ce sujet, ça évitera à ceux qui le lise de se casser les dents 😊 Et je me permet d'afficher le lien pour faciliter la recherche:

Oui c'est possible en IPV6 et tu n'as pas besoin de deux domaines différents. Maintenant démontrer qu'en IPV4 ce n'est pas possible je n'en suis pas capable 😐 En tout cas je n'y suis pas arrivé. En IPV4, en cas de panne du syno1, le monde ne connait que l'adresse du domaine via le DNS secondaire, . Donc une requête avec ton nom de domaine amène sur la box. Ce qui doit manquer c'est que la box redirige vers le syno2. Pour cela il faudrait un reverse proxy sur la box. Cet article semble dire que c'est possible...mais pas (encore?) à ma portée : http://cvoisin-domo.blogspot.com/2015/11/box-et-reverse-proxy.html J'ai aussi trouvé ce site pour rasberry : https://www.abyssproject.net/2017/02/enfin-un-reverse-proxy-nginx-pour-la-maison/ Mais là on s'éloigne du sujet de ce forum 😁. Et que ce passe-t-il en cas de panne du rasberry ?

Bien joué !

Pas trop le temps de faire un retour détaillé. Du bon et du moins bon mais en tout cas le but est bien atteint: Syno 1 et 2 connectés : tout est accessible Syno 1 seul connecté tout est accessible Syno 2 connecté, lui seul est accessible (j"espérais atteindre des équipements déclarés avec leur IPV6). Mais j'ai une piste.. Ceci sur PC Win 10 par contre problèmes sur Android Bonne soirée

Oui mais ça c'est encore plus galère. Il faut saisir toutes les entrées CNAME dans les zones et tous ces domaines dans le certificat. A moins que tu connaisses une astuce 😊 Pour les 3 questions j'essaie de vérifier cet am

Ils ont essayé....ce qui me conforte dans le sens d'une erreur de prix. Maintenant ils sont coincés...ils vont peut-être tenter la rupture de stock 😫