Jeff777

ç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 ?

Ah mais c'est vrai que j'ai essayé en local. Mais il me semble bien que pour moi c'était bon aussi de l'extérieur, je vérifierai pour la forme.

Bonjour, Ah bon. Moi ça marche sans mettre 443. Par contre il faut bien cocher https 😊 Salut, ça c'est pas bien, mais moi je suis retraité 🤣 Un certain nombre devrait fonctionner sans problème si audio fonctionne. Vérifie les enregistrements de zone les ports et le reverse proxy. J'utilise openVPN sur VPN serveur du syno et comme client sur PC ou tablette Openvpn Connect et ça marche super. Il y a un très bon tuto sur ce forum.

Bonjour Pour que le nom de domaine ndd.fr dirige for le dsm il faut que dans le reverse proxy on ait : https://ndd.fr. ==> http://ndd.fr:5001 En général on crée plutôt un sous domaine syno.ndd.fr par exemple et on laisse ndd.fr pointer vers la page d'accueil de webstation en l'adaptant éventuellemnt à son goût.

Ah regarde mon post précédent j'avais rajouté le reverse ! oui

Pour photostation tu ajoutes cela dans ton htaccess: Ne tiens pas compte de surveillance station ce n'est pas une bonne idée d'ouvrir le port 5001. Il est préférable d'utiliser l'appli client. Et le reverse proxy doit pointer vers localhost port 80 ou 443 pour toi en https Tu peux utiliser le navigateur avec l'adresse audio.xxx.fr ou l' appli spécifique DSaudio avec l'adresse et tes identifiant et n'oublie pas de cocher la case https.

Ah oui j'ai oublié ce petit problème. Ce n'est pas grave sauf que tu cryptes deux fois mais bon ! J'ai comme l'impression que tu fais du ping-pong entre le .htaccess et le reverse proxy ! Comme si le port http de l'appli n'avait pas été pris en compte Il est bien déclaré dans le portail des applis ?

Oui c'est correct pour le htaccess. Bon t'avais trouvé l'histoire du port http dans le reverse proxy. J'avais pas vu. Donc tout roule😊