Jeff777 Posté(e) le 17 mai 2019 Partager Posté(e) le 17 mai 2019 Zone master me dit que je n'ai pas d'enregistrement PTR en IPV6 pourtant : "Pour vérifier que l'enregistrement PTR a été bien pris en compte, exécutez la commande suivante dans votre terminal : nslookup A.B.C.D La sortie de la commande devra contenir les lignes suivantes : Nom : mx.nomdomaine.tld Address : A.B.C.D" Et moi j'ai bien mon nom de domaine avec l'adresse IPV6 !!!!! Sauf que j'ai pas mx mais ns. C'est peut-être cela le soucis 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
dd5992 Posté(e) le 17 mai 2019 Partager Posté(e) le 17 mai 2019 Bon, petit test en IPV6. Pour l'instant, j'ai utilisé un ndd spécifique IPV6 (syno6.ndd.fr - backup6.ndd.fr - www6.ndd.fr - freebox6.ndd.fr). Les enregistrements AAAA pour ces 4 domaines pointent tous sur mon nas (backup). Le reverse proxy a le port d'entrée 443 sur mon nas (backup). les redirections reverse-proxy pointent sur le SRM de mon nas principal, le SRM de mon nas backup, le webserver https de mon nas (backup), ma freebox (mafreebox.freebox.fr) respectivement. Le firewall de mon routeur ne laisse passer en IPV6 que des requêtes vers le nas (backup) et que sur les ports 80 et 443. Toutes les tentatives de connexion https indiquent que le certificat est incorrect (c'est un certif auto-signé qui ne correspond pas aux adresses). Résultats : La requête http://www6.ndd.fr fonctionne. Les requêtes https://syno6.ndd.fr - https://backup6.ndd.fr - https://freebox6.ndd.fr fonctionnent. La requete http://www6.ndd.fr fonctionne et donne accès au site web hébergé par le nas (backup) La requête https://www6.ndd.fr donne : 400 Bad Request Request Header or Cookie Too Large (nginx) Un problème avec le port 443 reste donc tout au moins possible, même si je ne sais pas comment interpréter le message d'erreur de nginx. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeff777 Posté(e) le 17 mai 2019 Partager Posté(e) le 17 mai 2019 (modifié) Ah j'avais raté ce message ! Pour https://www6.ndd.fr as tu bien vidé l'historique du navigateur ? Sinon de mon côté je vais renoncer à mon enregistrement PTR en IPV6 car j'ai trouvé ce sujet qui semble le condamner. Free propose bien un reverse dns mais seulement en IPV4. Je l'avais pris c'est pour cela que je n'ai pas le pb en IPV4. Modifié le 17 mai 2019 par Jeff777 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeff777 Posté(e) le 18 mai 2019 Partager Posté(e) le 18 mai 2019 Bonjour @dd5992 Ce matin j'ai décoché le DHCPV6 de Free et j'ai remplacé les adresses IPV6 publiques par les adresses globales publiques. Après mise à jour des zones du DNS secondaire, Zonemaster donne les même résultats sauf que dans le commentaire concernant le PTR IPV6 c'est la nouvelle adresse. Après modification du pare-feu pour forcer les connexions au DSM en IPV6 publiques, je peux sans problème me connecter depuis la tablette.en http (redirection vers le https) et en https. En même temps, sur le PC une notification me signifie que j'ai perdu la connexion avec le serveur et que le pare-feu est réinitialisé (C'est un peu normale puisque j'interdis les connexions en locale. Mais je ne sais pas pourquoi il n'a pas fait de loopback, la dernière fois que j'avais fait la manip il ne m'avait rien signalé). Après avoir remis le pare-feu dans sa config d'origine le journal affiche une connexion avec une adresse publique IPV6. Je reçois aussi par mail une notification me signalant un nouveau comportement de connexion qui me renvoie aux conseils de sécurité/analyse de la connexion et je retrouve la même adresse IPV6. Cette adresse n'est pas l'adresse IPV6 publique globale basée sur l'adresse mac. Je suppose donc qu'il s'agit de l'adresse temporaire. Bon week-end 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
dd5992 Posté(e) le 18 mai 2019 Partager Posté(e) le 18 mai 2019 @Jeff777: Pour https://www6.ndd.fr je pense donc que le problème de la boucle infinie est toujours présent dans l'implémentation native de reverse-proxy dans DSM. Il va falloir trouver une autre solution que la redirection de port dans la freebox (qui n'est plus effective en IPV6). Pour l'instant, je n'en vois que deux, : 1) que la machine hébergeant le reverse-proxy soit différente de la (ou les) machine(s) hébergeant un site sur le port 443. Ça peut être un autre syno ou un Raspberry Pi par exemple. Pas génial pour moi d'exposer sur Internet mon nas de backup, même avec un bon firewall. 2) Changer l'adresse d'écoute de WebStation https. Je n'ai pas trouvé comment faire dans l'interface de DSM et je préfère éviter de changer directement dans les fichiers de config. Pour le DHCPV6, je crois que le plus simple est en effet de le décocher. le firewall microsoft du PC peut aussi faire des siennes. On dirait que tu as trouvé la bonne config. Bon week-end à tous. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
dd5992 Posté(e) le 3 juin 2019 Partager Posté(e) le 3 juin 2019 Au sujet de la fréquence de changement de l'adresse IPV6 temporaire sous Windows 10, j'ai remarqué qu'elle change environ tous les 9 jours. Je suis en W10 version 1809. J'ai pu le constater de la manière suivante : A chaque changement, lorsque je me connecte sur mon NAS sur mon réseau local avec une nouvelle IPV6, le Conseiller de Sécurité de DSM m'envoie un message "DSM a détecté un nouveau comportement de connexion sur votre NAS..." en précisant les adresses de connexion. Ces messages sont enregistrés dans le Conseiller de Sécurité sous la rubrique "Analyse de la connexion". La répétition de ces messages est agaçante d'ailleurs. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeff777 Posté(e) le 3 juin 2019 Partager Posté(e) le 3 juin 2019 (modifié) 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 ! Modifié le 3 juin 2019 par Jeff777 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
dd5992 Posté(e) le 3 juin 2019 Partager Posté(e) le 3 juin 2019 (modifié) il y a 26 minutes, Jeff777 a dit : 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. Sans désactiver l'attribution aléatoire des adresses par W1, j'ai le même comportement, sauf que l'adresse fixe n'est pas basée sur l'adresse MAC. Elle est fixe et a dû être tirée au sort la première fois et être enregistrée dans la base de registres de W10 (dixit la base de connaissances de Microsoft). l'adresse employée pour les connexions démarrées du PC (en local comme vers internet) est l'adresse temporaire (et c'est en effet ce qui est souhaité). C'est elle qui change environ tous les 9 jours. Modifié le 3 juin 2019 par dd5992 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeff777 Posté(e) le 3 juin 2019 Partager Posté(e) le 3 juin 2019 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. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
dd5992 Posté(e) le 3 juin 2019 Partager Posté(e) le 3 juin 2019 Alors, gare au passage à la version 1903 de W10 (je suis encore en 1809). On verra si c'est maintenu en cas d'upgrade. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeff777 Posté(e) le 4 juin 2019 Partager Posté(e) le 4 juin 2019 (modifié) L'IPV6, comme l'avait vu @dd5992 permet de trouver des solutions à certains sujets : Modifié le 4 juin 2019 par Jeff777 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.