Jeff777

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 😫

Les adresses sont identiques. Je peux utiliser http, https ou rien en préfixe et ça redirige vers du https. Bon je vais peut être me fendre d'un petit tuto. Mais avant cela j'aimerais bien vérifier tout cela depuis l'extérieur de façon plus exhaustive. Cet AM je pourrais. Je vais tester les adresses avec les deux synos puis je vais couper le syno1 et les re-tester. Ce matin panique, je n'y arrivais plus en local....en fait mon certificat wildcard avait expiré (3 mois ça fait court).

Non les seuls enregistrements A que j'ai dans la zone publique sont ceux du ndd et ns.ndd tous les autres sont en AAAA. Par contre le .htaccess et le reverse proxy (qui redirige en IPV4) font leur boulot dans le cas où le syno1 est fonctionnel.Le syno2 n'intervient pas. Dans le cas ou le syno1 n'est pas fonctionnel l'adresse est résolue avec les enregistrements propagés donc pour le syno2 l'adresse IPV6. Pourquoi la box permet la redirection vers le syno2 alors que la redirection est vers syno1 (qui n'est plus là)? Je ne sais pas mais ça fonctionne. Peut-être parce que l'adresse IPV6 pointe directement sur le syno2. oui il faut effectivement une connexion IPV6 pour que ça marche 😉

C"était une erreur. Ils ont corrigé 😒 https://www.cdiscount.com/informatique/disques-durs-internes/pack-x2-disque-dur-interne-nas-wd-red-4to-5/f-10768-bunwd40efrx22.html#mpos=32|cd

Bon @Dimebag Darrell et @dd5992 j'ai une idée toute bête qui mérite d'être exploitée sur l'affaire des deux synos : Lorsque le syno1 est hors circuit il reste le DNS secondaire et la propagation des enregistrements et une requête internet est résolue à ce niveau. Conclusion dans la zone publique il faut : mettre l'adresse IPV6 du syno2 par un enregistrement AAAA celle ci est répliquée dans le DNS secondaire (Hurricane electrique for me) puis communiquée au monde (on vérifie la propagation avec un test AAAA sur syno2.ndd à l'aide de www.whatsmydns.net) On débranche le syno1 la propagation reste en place tant que le DNS secondaire est vivant ( j'ai vérifié en forçant la mise à jour de la zone esclave que les enregistrements restaient en place mais je ne sais pas ce qui se passe à l'expiration des TTL) Les ports ?...........j'ai laissé les ports par défaut 80,443,5000,5501 sur les deux syno et pas de redirection vers le syno2. J'ai gardé le .htaccess et le reverse proxy identiques sur les deux syno. En local je me connecte au syno2 en https avec l'adresse syno2.ndd que le syno1 soit présent ou non. Maintenant pour le test en externe j'ai quelques difficultés. Je n'ai pas la 4G et je n'ai pas trouvé de proxy qui fasse IPV6. Alors j'ai fait du loopback sans être certain que la démonstration soit béton pour cela j'ai interdit dans le pare-feu du syno2 les adresses locales en IPV4 et en IPV6. Je me connecte au syno2 ! L'adresse syno2.ndd est bien résolue en https et dans le journal je vois l'adresse IPV6 temporaire de mon PC. Bon ça parait beaucoup trop simple pour que ce soit la solution ??. Mais c'est peut-être une piste à exploiter...... J'ai eu un doute et j'ai demandé à un copain de se connecter depuis son PC et .....ça marche !

Ah OK c'est un troisième cas que je n'avais pas envisagé. C'est donc une application sur le NAS qui permet via un serveur VPN externe de se connecter à un site depuis ton NAS. VPN serveur ne sert qu'à se connecter à son NAS depuis l'extérieur par un tunnel sécurisé. Il n'est donc d'aucun secours pour ce que tu veux faire. Et moi je ne suis d'aucun secours également 😞

Mais le VPN payant c'est un serveur externe ou bien une application serveur installée sur le NAS ??? Dans le premier cas il n'y a pas de raison que cela ne fonctionne pas (atteindre son NAS depuis l'extérieur via un serveur VPN) Cela voudrait plutôt dire que c'est le deuxième cas : une application qui est installée sur le NAS. Dans ce cas pourquoi ne pas utiliser VPN serveur qui marche très bien ? Sauf à essayer le VPN payant pour le fun 😁. En tout cas je n'ai pas essayé.

Bonjour, Pas essayé. Mais pourquoi utiliser un VPN payant alors que VPN serveur est gratuit et fonctionne?

L'IPV6, comme l'avait vu @dd5992 permet de trouver des solutions à certains sujets :

Ce que je te conseille c'est de noter les IP des attaques et de voir d'où elles proviennent (sur internet il y a des sites qui te permettent de localiser une IP. Par exemple :http://www.localiser-ip.com/) Tu peux alors interdire les IP provenant de cette région en règle N°4.

Oui "aléatoire" (ou pseudo aléatoire comme écrit wikipédia) n'est pas le contraire de "fixe" 😊 et tu as raison elle doivent être inscrites quelque part dans le système. D'ailleurs les modif que j'avais vues sur mon PC et qui dataient de plus de 4 mois devaient correspondre à une réinstallation de Win10.

ça prouve que le forum est très réactif 😉

Bonjour, Il me semble qu'au contraire c'est très précis mais il faut arriver jusque là : Après les autres règles entre la troisième et la quatrième ligne ça dépend de ta config. De mon côté je n'ai autorisé que les IP venant de France ou de GB mais cela ça dépend de chacun. En tout cas, avant jamais de nombreuses attaques (surtout en présence du SSH mais pas que) venant majoritairement d'Asie et maintenant quasiment plus une seule.

Depuis que j'ai désactivé l'attribution aléatoire des adresses par Windows 10 et que j'ai décoché le DHCPv6 de la freebox mes adresses externes et locales sont fixes et basées sur l'adresse MAC. Par contre mon adresse IPV6 sur internet que voit https://test-ipv6.com/ par exemple est l'adresse temporaire qui elle change assez souvent. Extrait de Wikipédia Adresse IPV6 Assignation des adresses IPv6 dans un réseau local La taille du sous-réseau étant fixée à 64 bits, les hôtes disposent des 64 bits restants pour la numérotation à l'intérieur du sous-réseau. Plusieurs techniques existent pour assigner les adresses dans le sous-réseau : Configuration manuelle l'administrateur fixe l'adresse. Les adresses constituées entièrement de 0 ou de 1 ne jouent pas de rôle particulier en IPv6. Configuration automatique RFC 486220 : autoconfiguration sans état basée sur l'adresse MAC qui utilise le Neighbor Discovery Protocol (NDP). RFC 494121 : tirage pseudo aléatoire (actif par défaut sur les versions client des systèmes Microsoft Windows) RFC 331522 : DHCPv6 Il existe au moins une adresse locale de lien (fe80::/64) pour chaque interface IPv6. Le RFC 486123 permet de construire le ou les adresses globales unicast avec chacun des préfixes /64 annoncés par le routeur. En général, les 64 bits d'interfaces sont construits à partir de l'adresse MAC dans un format nommé EUI-64 modifié. Ce système a soulevé des inquiétudes vis-à-vis de la protection de la vie privée, dans la mesure où les adresses MAC sont alors visibles dans l'adresse IPv6 et peuvent permettre d'identifier l'équipement. Que le test IPV6 détecte mon adresse temporaire est plutôt rassurant !

Comment c'est possible ???

!!!! En re-vérifiant ce que j'avais dit je m'aperçois que je me suis planté dans la retranscription de ma solution.!!!!!.Mais tu as corrigé toi même 😊 On reprend : Ce qui marche chez moi c'est : Sur syno1 Zone privée : deux enregistrements A : syno1.ndd1==>192.168.0.X1 et syno2.ndd2==>192.168.0.X2 les deux noms renvoient vers les IP locales des syno Zone publique deux CNAME vers le dns serveur : ns.ndd Reverse proxy : syno1.ndd1==>192.168.0.X1:5000 et syno2.ndd2==>192.168.0.X2:5100 (maintenant je viens d'essayer avec le même port 5000 sur les deux syno, bien sûr ça marche aussi en interne et externe) J'imaginais faire la même chose avec le syno2 en symétrique (utiliser le deuxième domaine faire un dns reprendre les zones et le reverse proxy) et mettre les deux DNS (du syno1 et du syno2) dans le DHCP de la box. Ce qui est idiot puisqu'ils ont la même IP , d'ailleurs c'est certainement pas possible d'avoir deux DNS avec la même IP . Alors oui les IPV6 peuvent être la solution....j'ai bien envie d'essayer 😁