Jeff777

Bon je ne connais pas dynhost. Sur le site OVH j'ai vu qu'il y avaient des tutos assez précis. Est-ce que tu les as re-vérifiés ? Dans tes enregistrements ci-dessus je trouve curieux le

Bonjour, Pour que cela fonctionne il faut que tu rediriges les http en https à l'aide d'un fichier .htaccess dans le dossier web. Tu trouveras comment faire dans ce forum. Remplace aussi 192.168.0.10 par localhost ce n'est peut-être pas indispensable mais c'est la méthode habituelle.

Merci pour tes réponses. Espérons une amélioration dans le future

Ah oui. C'est râlant. En tout cas pour mon cas ce n'est pas tellement "Universal Search" qui me perturbe mais plutôt "Active Backup for Business" qui me fait perdre les réponses de certaines appli pendant les sauvegardes. Je vais d'ailleurs poser le problème dans la bonne section ☺️

Naïvement je pensais pouvoir me passer de "Universal Search". Après avoir suivi le tuto j'ai bien l'option stop mais si je veux l'exercer il faut déjà que j'arrête Drive et si je veux arrêter Drive il faut que j'arrête Moments et Office. Conclusion je reste comme cela. Il faudrait préciser que ce tuto ne s'adresse pas aux utilisateurs de Dive et/Moments. Quand on réfléchit ça parait évident mais pas de prime abord.

Il faut aussi vider le cache du navigateur. La seule chose que je vois qui est différente de ma config c'est le dynhost. Il y a certainement des mélanges entre dynhost.xxx.fr et xxx.fr au niveau du paramétrage qui fait que quelque chose bloque. Regarde cela :

Bonjour , Attention pour ètre certain que tu obtiennes systématiquement la bonne réponse il faut, avant chaque test, vider les caches DNS et navigateur ! J'ai aussi remarqué que si le NAS était occupé à des tâches qui mobilisaient de la ressource lles réponses pouvaient été affectées

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

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.

Bonjour, La livebox je sais pas mais quand je regarde la télé sur la freebox au bout d'un moment (je n'ai pas mesuré mais plus d'une heure) une validation m'est demandée à l'écran. Si je ne valide pas le flux est interrompu. Je n'ai jamais regardé dans les paramètres si l'on pouvait modifier cette valeur mais je suppose que oui. Sinon ça pourrait aussi venir de la télé non ?

Oui et nous allons négocier une bonne réduc 😂

Alors même avec la loupe j'y arrive pas. C'est grave !😰

Oui j'avais bien vu. C'est bien pour cela qu'il a besoin de lunettes. De ce point de vue là je ne suis pas mal placé aussi (mais j'ai utilisé la loupe) ☺️

Bonjour firlin, Ben moi je vois 8870. Comment ça se fait? Il te faut des 😎 🤣 Mais la remarque est vraie pour l'IPV6

Bonjour, La connexion se fait sur le port 8870. Quelle est l'application qui correspond à ce port sur le NAS ? C'est sans doute la coupable. Si c'est pas possible de savoir mettre ce port en interdiction dans le pare-feu DSM dans une première ligne et voir ce qui ne marche plus.

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

Non rien à faire !

Je réponds dans l'ordre pour limiter les images : 1/Intérêt du DHCPV6 Free. Bon effectivement cette perte de connectivité sur les appareils android est gênante. Je vais essayer de m'e passer du DHCPV6 de free. Mais il faut que je re-paramètre les entrées DNS. Je vais faire un essai limité. 2/Redirection de ports pas possible en IPV6 : d'où l'intérêt de ne pas faire de redirection sur un port différent. 3/Je retiens ta proposition, merci. Ce sera sans doute milieu semaine prochaine car je voudrais d'abord résoudre cet histoire de zone inversée et je vais m'absenter demain matin jusqu'à mardi. 4/Ben non la zone de mon domaine locale n'est pas non plus déléguée. Je ne vois pas à quoi ça pourrait servir et je ne sais pas si c'est possible. Je fais comme toi sauf que le dns secondaire n'est pas le même. "Serveur par défaut inconnu" signifie que tu n'a pas d'enregistrement PTR ce que confirme zonemaster. Effectivement ce n'est absolument pas gênant. Les enregistrements PTR sont loin d'être indispensables http://blog.christopher.compagnon.name/article.sh?id=d20170509072404731 C'est juste pour le fun que j'essaie de le réaliser. DNSSEC je crois que ce n'est pas possible avec DNS Serveur. En fait mis à part l'enregistrement PTR du serveur secondaire qui existe pour Hurricane et pour mon IPV4. J'ai la même chose que toi.

Bon j'ai réussi la création de 4 zones inversées ( LAN et WAN pour IPV4 et IPV6) les zones WAN ont été transférées vers le DNS secondaire (Hurricane) avec succès. Tout ceci n'était pas évident en l'absence de tuto précis et j'ai pas mal galéré. Par contre pour le moment toujours pas d'enregistrement PTR pour l'adresse IPV6 de ns.ndd détectée par zonemaster. Et si je supprime l'option reverse dns de free je perd l'enregistrement PTR en IPV4 ! A suivre

Ah OK. Je pensais que c'était peut-être une histoire de sécurité.... Pour tromper l'ennemi 😉

Bonjour @dd5992 . Je ne comprends pas l'intérêt de libérer le port 443 du NAS ! Peux tu m'expliquer. Merci

Je ne sais pas si ce sont mes tests qui ont mis le site du forum "down" mais j'ai eu du mal à me connecter 🤣 Pour répondre à tes questions j'ai fait un test (après vidage des caches) avec ceci : Donc j'ai supprimé (mis de côté plutôt) un certain nombre de ports qui pouvaient parasiter le test. Même résultat que précédemment sauf qu'il faut se connecter en https puisque j'ai supprimé le 80. Sauf avec la tablette où j'ai " time-out". Mais si j'autorise les connections locales ça fonctionne et si je les interdis à nouveau (sans vider les caches) ça fonctionne à nouveau même sur un sous domaine non testé. Par exemple je teste https://audio.ndd.fr sans les connections locales : time out, j'autorise les connections locale https://audio.ndd.fr fonctionne...... je les interdis à nouveau, ça fonctionne et photo.ndd.fr aussi ! D'où l'intérêt de vider les caches dns et navigateur avant tout test. Le time out est peut-être lié à la mise en garde de free sur la connectivité IPV6 sur android lorsque le DHCPV6 est activé. Je vais essayé d'éclaircir ce pb. (J'édite ce texte et confirme que j'ai perdu la connectivité IPV6 sur les appareils android . Dans Freebox OS les IP locales IPV6 sont maintenant marquées comme injoignables) Sinon la réponse est oui à toutes tes questions. https://www.ndd.fr ==>http://localhost dans le RP donc j'ai le même résutat qu'avec ndd.fr. Un de ces jours je customiserai la page web éventuellement avec des raccourcis vers les applis. Pour les sites j'utilise les virtual hosts dans webstation : nomdusite.ndd.fr 80/443 http/https web/nomdusite J'en ai deux dont un fait avec Wordpress du Syno et ça marche très bien. Bien sur il faut déclarer les sous domaines nomdusite, leur adjoindre un certificat (si pas de wildcard) et placer tous les fichiers du site sur le serveur dans le dossier web/nomdusite (pour wordpress j'ai garder ce nom pour le site et le dossier mais je suppose qu'il est possible de changer cela avec qq modifs des fichiers). Je crois que j'ai rien oublié. Si mais que des redirections sans changer le numéro du port. Et faudra que je vérifie lesquelles sont utiles (par exemple j'ai une redirection du 443 mais pas du 80 !). C'est vrai. Mais je n'ai pas de smartphone je n'ai qu'un tablette sans carte SIM. Oui je fais partie de ces irréductibles qui ont toujours résisté. Alors lorsque je veux tester une connexion par l'extérieur j'utilise un proxy. C'est lent et pas très prudent et j'évite d'y rester longtemps. Mais pour ces tests il faut que je trouve un proxy avec connexion IPV6, c'est plus rare et je ne m'y suis pas encore mis. Oui. Et là je suis en train de créer des zones inversées pour les enregistrements PTR. Pour le moment j'ai réussi cela en local : Avant la création de la zone j'avais serveur par défaut inconnu mais j'avais la bonne adresse et maintenant j'ai ns.ndd.fr ce qui prouve que l'enregistrement PTR est fait. Par contre pour les zones inverses externes je n'ai pas réussi à les déléguer vers mon serveur DNS secondaire (chez Hurricane) et Zonemaster me dit que le serveur ns.ndd à une adresse IP IPV6 celle ci dessus sans enregistrement PTR. Mais cela progresse. Bonne soirée

Oui donc lorsque je fais un test avec audio.ndd.fr et que mon pare-feu interdit les connexions locales au NAS ainsi que celles avec l'adresse IPV4 publique la seule solution est que je rentre (en loopback) sur le LAN en IPV6 publique (vérifié dans le journal des connexions) avec le port 80 que j'ai autorisé dans le pare-feu pour tous les IP France. J'arrive donc sur webstation et je tombe sur le .htaccess qui me dit de passer en https avec le port 443, je continue sur le reverse proxy et je passe en http en localhost mais avec le port que j'ai attribué à l'appli audio. Ce port n'est pas autorisé dans le pare-feu du NAS (ni d'alleurs le port correspondant au https pour l'appli audio qui de plus n'est même pas déclaré). Mais comme je suis déja sur le NAS j'arrive sur la page d'accueil de l'appli, je renseigne mes identifiants et j'arrive sur Audiostation. Bon d'accord c'est mon vocabulaire. Peut-être pas très pro.et peut-être qu'il y a quelque chose qui m'échappe mais pour moi je ne vois pas de différence de fonctionnement entre une connexion en IPV4 et une en IPV6. Donc le reverse proxy est opérationnel dans les deux cas !

Bon j'ai que quelques minutes pour répondre. Tu as raison le "donc" est totalement idiot. 🙄 Par contre on est bien d'accord que le reverse proxy se sert des adresses et non des IP pour les redirections. Donc je ne vois pas pourquoi cela ne marcherait pas avec les IPV6 s'ils pointent sur les mêmes adresses. D'ailleurs toutes les connexions du journal ont été réalisées avec les adresses de type tartanpion.ndd.fr ( le journal donne toujours l'IP) et ont bien été redirigées vers la bonne application. Les connexion avec l'adresse privée du NAS 192.168.0.10 ont été réalisée également avec tartanpion.ndd.fr mais avant et après les modif du pare-feu pour interdire l'IPV4. A suivre....

Me serai-je emmêlé les pinceaux ? Je regarde ce soir.