Jeff777

Bon. Faut digérer tout cela. Et puis, il y a bien dans ce forum quelqu'un qui pratique OVH avec IP dynamique qui a la réponse. Bonne soirée

Oui les affectations sont les mêmes pour les IPV6 locales pour tous les périphériques (Dans mon cas elles sont toutes liées à l'adresse Mac puisque j'ai retiré la "randomisation" de win 10). Par compte comme j'ai dit plus haut, plus d'IPV6 temporaires (du moins pour le PC et je pense que c'est vrai pour le reste). Ceci est sans doute une conséquence du fait que maintenant les adresses globales publiques ont changé et ne sont plus liées aux adresses mac. Ce sont elles qui sont utilisées de l'extérieur du réseau et non plus les temporaires. Pour l'instant je n'ai pas pu voir une perte de connectivité IPV6 sur ma tablette android. Oui je peux voir quelques connexions IPV6 dans le journal, d'ailleurs cela a toujours été le cas. Mais j'ai toujours eu l'IPV6 activé même sans le DHCPV6. Les enregistrements AAAA de la zone publique ns.ndd et ndd correspondent à l'adresse IPV6 publique du NAS et non celle de la freebox car c'est là que loge le DNS serveur. (Et oui en IPV4 c'est la même pour le NAS et la box. Mais en IPV6 faut pas se tromper) C'est là que je m'étais planté car, comme tu me l'avais fait remarqué, l'adresse a changé avec le DHCPV6 activé. Lorsque je mets dans mon navigateur https://mon IPpublique:5001 j'arrive sur la page d'accueil du NAS que ce soit avec l'adresse IPV4 ou IPV6 (entre crochets). Bien sûr https est en rouge barré non sécurisé puisque le certificat est attaché au nom de domaine et non à l'adresse IP. Donc le reverse proxy fonctionne aussi pour l'IPV6. Si j'ai un moment demain je referai un test et vérifierai les connexions dans le journal sur cette période de test. Bonne soirée

Ah bonne question. Je ne sais pas je n'ai jamais pratiqué Dynhost. Essaie les deux. Par contre méfie-toi que le nombre d'émission de certificats est limité avec Let's Encrypt A priori je dirai que ton domaine c'est dynhost.ndd.fr mais pas sûr

Merci @Zeus La limitation à quelques services peut-être un argument. En tout cas @felix62a sa réponse 🙂 Et merci @Thierry94 je continue donc avec le reverse proxy

Ah oui c'est vrai. Alors effectivement pourquoi préfère-t-on le reverse proxy aux alias? il me semble que j'ai lu un argument quelque part sur ce forum mais je ne sais plus où.

Bonjour felix62 Ce dont je suis certain c'est qu'avec le reverse proxy il n'est nécessaire d'ouvrir que le port 443 vers le NAS (Ce n'est qu'une fois dans le réseau local que le port de l'appli est utilisé). Avec les alias je ne sais pas si c'est le cas. A valider par les forts en thème de ce forum 😀

🤔 Quand tu as modifié le reverse proxy en ajoutant dynhost, as-tu pensé à corriger les certificats Let's Encrypt également

ça c'est pas bon. Il faut soit http://audio.ndd.fr ou audio.ndd.fr et automatiquement tu passes par le port 80. ou bien : https://audio.ndd.fr et alors c'est le port 443 qui est autorisé. Dans les deux cas tu passes par le .htaccess puis une fois que tu es redirigé en https par le reverse proxy. Par contre si tu veux pouvoir te connecter en utilisant http il faut autoriser le port 80 dans le pare-feu du NAS. Je ne l'avais pas autorisé et je ne pouvais pas me connecter en http sauf quand je le faisais en https auparavant, c'est curieux mais le cache garde l'information.

Avec DHCPV6 j'ai tenté de forcer les connexions au NAS en IPV6 de la manière suivante : Dans le pare-feu du NAS j'ai refusé toutes les connexions du LAN en IPV4 (elle restent autorisées en IPV6) j'ai aussi refusé mon adresse publique IPV4. Le fonctionnement reste identique après nettoyage des caches pour toutes les connexions locales utilisant les noms de domaines. Mais je ne sais pas dire si ce test est concluant vis à vis de l'IPV6. Si j'ai le courage j'essaierai bien de supprimer mes enregistrements A de ma zone publique mais j'ai peur des conséquences. 😰

ça je ne sais pas. Peut-être faire l'essai sur un dossier et un type de fichiers qui ne demande pas trop de temps à indexer pour voir. Je n'ai pas regardé l'aide du DSM, peut-être y-a t'il des précisions. Après réflexion je ne pense pas que ce soit une solution de faire cet essai. On va tout réindexer sauf ce qui aura été décoché que l'on va perdre. Désolé

Bonjour Dans le service d'indexation tu cliques sur "dossiers indexés" et là en sélectionnant un des dossiers puis modifier tu peux choisir le type de fichiers à indexer.

Oui parfois on ne voit pas ce qui nous crève les yeux, c'est là qu'un avis extérieur est utile. Bonne journée

Dans les paramètres DSM tu as bien décoché le renvoi automatique de http vers https ? Tu peux aussi essayer de désinstaller et réinstaller nginx Enfin ceci : https://www.tecmint.com/fix-400-bad-request-in-nginx/ Je n'ai pas tout lu mais peut-être un début de réponse. En tout cas redémarrer nginx semble être une solution. Je dois m'absenter. A+

Ah zut je croyais avoir trouvé le pb. C'est ton post précédent qui est bizarre : il fait référence à nginx alors j'ai cru que tu avais mis nginx plutôt qu'Apache. Mais c'est vrai que cela dit bien que la redirection a été faite alors le pb ne viendrait pas du htaccess.!

En tout cas maintenant j'ai des adresses locales fixes déduites des adresses mac et des adresses publiques qui n'ont plus rien à voir avec l'adresse locale (ni avec les adresses mac, à priori) du type : 2a01:xxxx:xxxx:xxxx::yyyy:yyyy avec la partie en x identique pour tous les périphériques. De plus ces adresses sont fixes et sont utilisées à la place des adresses temporaires. Par exemple avant de mettre le DHCP IPV6, l'adresse ipv6 de mon PC (https://test-ipv6.com/) changeait à chaque reboot de ma box et correspondait à l'adresse temporaire donnée par la cmd ipconfig. Maintenant avec le DHCP IPV6 j'ai une adresse fixe publique (que je peux trouver par https://test-ipv6.com/ et ipconfig) et plus d'adresse temporaire ( dans ipconfig)

Ben oui c'est toi qui a raison il faut rediriger les http vers les https avant les lignes concernant photo sinon ça ne marche pas pour http://photo..... Autrement je crois avoir trouvé ton erreur pour le htaccess,..... il faut Apache dans webstation paramètres généraux du http

Le plus facile pour un usage répété: Tu fais un fichier texte sur le bureau et tu mets dedans: @echo off ipconfig /flushdns pause Tu le transformes en .bat en changeant l'extension. En cliquant dessus puis en validant tu vides le cache tu as du te tromper en écrivant 😃

Ah j'oubliais. lorsque l'on fait ces tests, pour être certain de la réponse, il faudrait vider le cache du DNS et celui du navigateur sinon la réponse peut-être la même que la précédente. ça c'est du vécu et à de nombreuses reprises.

Alors j'ai deux questions: 1/ le fichier htaccess est-il bien à la racine du dossier web dans ton syno 2/les sites internet dont tu parles sont-ils des sites perso hébergés sur le Syno. Et dans ce cas dans quel dossier?

Bon pour faire progresser la science j'ai réactivé l'IPV6 de la freebox et tout rebooté PC,NAS et Freebox. Résultat: Je n'ai plus d'adresse IPV6 publique sur mon PC (vérifié avec ipconfig) je n'ai que l'adresse locale en fe80 toujours la même puisque basée sur l'adresse mac. Le zone master est rouge car l'IPV6 globale du NAS à changé et les 4 derniers groupes sont maintenant différents de l'adresse locale. Donc dd5992 n'avait pas tort. Pour pousser un peu plus loin j'ai mis cette nouvelle adresse dans les enregistrements de ma zone publique et maintenant mon zonemaster est correct ! Reste à récupérer mes adresses IPV6 publiques. J'attends de voir Et oui en rebootant la box j'ai une nouvelle adresse publique non liée à mon adresse mac. Et je n'ai plus d'adresse IPV6 temporaire ! Bon appétit !

Effectivement j'ai essayé de l'activer par curiosité et là ça ne marche plus. Zonemaster voit rouge. Alors que sans le dhcp IPV6 de la free ça marche très bien avec les enregistrements AAAA de l'adresse publique IPV6 du NAS et les DNS IPV6 déclarés : IPV6 du NAS et IPV6 de FDN.

Bonjour, Maintenant je me suis mis en fixe basé sur l'adresse mac (netsh interface ipv6 set global randomizeidentifiers=disabled) mais comme je disais, l'historique des enregistrements des adresses IPV6 des PC sous win 10 sur freebox OS m'indique que les adresses publiques aléatoires ne changent pas souvent. Une fois choisies elles doivent rester en cache quelque part. Il doit falloir une modif majeur de win 10, une réinstallation ou une grosse mise à jour pour que l' IPV6 publique aléatoire change. Pour mon PC elle a changé plusieurs fois en janvier mais je ne sais plus ce que j'ai fait. Mon fils est resté en aléatoire et comme son PC est sur le même LAN je vérifierai si ça change avec freebox OS . Son adresse a changé plusieurs fois en octobre dernier et une fois en décembre mais il ne se souvient pas non plus de ce qu'il a fait.

Je ne pense pas. Vérifie les déclarations des ports dans le portail des applis et les enregistrements du reverse proxy tu as bien par exemple https://file.xxx.fr ==> https://localhost:"port https de file station"

oui. j'ai deux sites

non mais j'ai autorisé le port 5001 dans le pare-feu. Tu crois que cela pourrait être la raison ?