dd5992

Il fonctionne avec ou sans. Pour ma part je n'utilise pas Quickconnect.

Pour l'accès aux dossiers partagés et aux fichiers depuis un smartphone, il y a DS File.

Désolé, je n'ai pas d'idée. Peut être faudrait-il appeler de nouveau la hotline Free, car l'idée de jouer sur le paramètre DHCPv6 n'était sûrement pas la bonne. Il faudrait d'ailleurs remettre la valeur par défaut (non coché) de ce paramètre.

Si tu regardes sur ton compte Free dans "Caractéristiques techniques de la ligne" tu vois quelque chose comme ça : Tu as donc à la fois une adresse IPV4 et une IPV6. Demander une adresse IPV4 Full Stack va simplement échanger ton adresse IPV4 partagée contre une autre qui te sera propre.

Bonjour @Herror404, Le fait de demander une IPV4 Full Stack ne fait que compléter la liste des ports IPV4 accessibles de l'extérieur. C'est donc sans inconvénients, même si c'est irréversible. Je ne sais pas si ça peut régler ton problème qui semble lié à l'utilisation d'IPV6, mais ça ne peut pas faire de mal. Attention, cette opération change la valeur de l'IVP4 qui t'est assignée.

@MilesTEG1 et @EVOTk C'est utile aussi par exemple pour accéder de l'extérieur à une machine virtuelle gérée par VMM.

@ademain : je suis heureux d'avoir pu t'aider. Pour ce qui est des adresses IPV6 du routeur par exemple, il faut savoir qu'en IPV6, chaque équipement, ou plutôt chaque interface réseau (ethernet, wifi, ...) peut avoir plusieurs IPV6. Par exemple, le routeur aura sur son interface WAN (côté freebox) une adresse en fe80, qui est locale et non routable et une adresse routable (en 2a01:... chez free). De même, côté LAN, il y aura les deux également. Sur la capture ci-après (configuration IPV6 du routeur syno - en mode manuel) apparait : Adresse IPV6 : Adresse IPV6 routable côté WAN Passerelle par défaut : l'adresse non routable côté LAN Serveur DNS préféré : adresse IPV6 routable côté LAN (J'ai installé le paquet DNS serveur sur le routeur Syno et il est comme ça utilisé par tout le réseau local). Préfixe : le préfixe (64 premiers bits) des adresses affectées aux différents équipements du réseau local. Pour ce qui est du firewall, il faut : Décider quelles connexions tu souhaites autoriser (et donc lesquelles tu souhaites interdire) en terme de adresse IPV6 et de port. Desactiver le firewall de la box, car sinon il ne laisse passer aucune connexion entrante, L'activer sur le routeur (par qui transitent toutes les connexions entrantes, en intégrant les règles qui autorisent ce que tu veux (en plus des régles IPV4 que tu peux avoir mises). Par exemple pour permettre le traffic sortant et l'accès à un seul NAS synology, voir la capture suivante. Ne pas oublier de mettre une règle interdisant tout le reste comme dernière règle (car pour chaque tentative d'accès, chaque règle du firewall est testée de haut en bas par rapport aux caractéristiques de la requète, et la première rencontrée qui correspond, détermine si la requète est acceptée ou non. Dans ces trois règles, la première accepte les connexions IPV6 entrantes vers mon NAS pour les ports d'entrée 80 et 443 seulement. La seconde accepte toutes les requètes provenant de mon réseau local (aussi bien sortantes vers internet que du réseau local au réseau local). La dernière refuse tout le reste. De cette manière, seuls les ports 80 et 443 de ton serveur nas sont exposés sur internet.

OK très bien, c'est bien là que j'ai regardé et rien n'est configuré. Pourtant ça fonctionne très bien autant en mode routeur qu'en mode bridge et autant de l'intérieur de mon réseau local que de l'extérieur. Du coup, je crois bien que je vais rester en mode bridge, après avoir testé que tout ce que j'utilise fonctionne bien.

C'est bien possible 😉 ! Pour ma part, je n'ai aucun nom de domaine configuré dans Freebox OS.

Désolé, j'avais en effet oublié ce "détail". Pour continuer les investigations, je me suis mis en mode bridge. L'adresse 192.168.0.254 ne fonctionne pas en effet, mais la règle reverse proxy : https://freebox.ndd.tld -> https://mafreebox.freebox.fr fonctionne très bien. Avant de passer en mode bridge, j'avais essayé en mode routeur la même règle de reverse proxy, qui fonctionne également. Conclusion (provisoire) : cette règle peut être généralisée. Pourtant je ne comprends toujours pas pourquoi il faut absolument que la cible de la règle reverse proxy soit en httpS (en HTTP, ça ne marche pas). Excuses moi, mais je ne comprends pas ce que tu as fait.

Merci @dd5992 J'en déduis qu'en mode bridge, aucune solution ? 😞 @Vinky : Je ne dirais pas ça. Pour moi il n'y a pas de différence entre les modes routeur et bridge de ce point de vue, mais je n'ai testé la solution que je donne qu'en mode routeur. Pourrais tu juste tester en changeant simplement dans la règle du reverse proxy pour l'accès à la freebox en https://freebox.ndd.tld -> https://192.168.0.254 Ça fonctionne chez moi en mode routeur et je pense que ça doit marcher chez toi en mode bridge.

La réponse est : Rien à voir avec l'IPV6, ça fonctionne complètement avec https://freebox.ndd.tld -> https://192.168.0.254

Bon alors là, je suis très étonné. Sans conviction, j'ai essayé la manip suivante : Dans mon DNS local, j'ai défini (en IPV4 et IPV6) le domaine ma-freebox.ndd.tld pointant vers 192.168.0.254 et avec un enregistrement AAAA, vers l'adresse IPV6 externe de ma freebox : 2a01:xxxx:yyyy:zzzz::1 et j'ai modifié la règle du reverse proxy en https://freebox.ndd.tld -> https://ma-freebox.ndd.tld et là, tout fonctionne parfaitement, aussi bien localement qu'à l'extérieur. Note1 : j'ai activé l'IPV6 dans mon réseau local. Note2 : si la règle du reverse proxy est https://freebox.ndd.tld -> http://ma-freebox.ndd.tld alors ça ne marche pas. Je continue les investigations pour voir si c'est l'IPV6 ou le HTTPS qui fait que ça marche. C'est tout de même bluffant !

Bonjour, Je reviens sur l'accès à la freebox à travers un reverse proxy et en effet, @Vinky et @PiwiLAbruti, les choses ont changé depuis cet été. J'ai essayé de creuser, mais visiblement pas assez 🤥. Ce qui marchait avant : J'ai un routeur Syno RT2600AC derrière la freebox révolution. Mon reverse proxy est porté par le DS918+ en aval du routeur. La freebox est en mode routeur (avec le RT2600AC dans la DMZ de la freebox), mais le fonctionnement est strictement identique avec la freebox en mode bridge (même chose pour le disfonctionnement constaté depuis cet été). La règle de reverse proxy pour la freebox est : https://freebox.ndd.tld -> http://mafreebox.freebox.fr J'utilisais cette façon de faire 1) pour avoir un accès complet à la freebox depuis l'extérieur, 2) pour disposer du contrôle d'accès par les profils proposé par DSM. Tout marchait très bien de l'intérieur du réseau local ou de l'extérieur. Et maintenant : J'ai dans les deux cas (réseau local ou extérieur) le message d'erreur suivant : "unknown host, use ip address or mafreebox.freebox.fr". Du réseau local, l'utilisation de mafreebox.free.fr, ainsi que 192.168.0.254 fonctionnent parfaitement. J'ai essayé de remplacer la règle reverse proxy par https://freebox.ndd.tld -> http://192.168.0.254 : mêmes messages aussi bien en local qu'à distance. Il semble que la freebox refuse de répondre à une requête qui ne vient ni directement de mafreebox.freebox.fr ni directement de 192.168.0.254. Qu'en pensez vous ? Merci de partager vos réflexions.

Je viens de tester en appliquant la méthode de @Brunchto et ça fonctionne en effet. Je n'avais pas remarqué cette option précédemment.

A ta santé ! Je suis allé voir sur mon NAS principal et les connections à DSM montrent l'IPV4 de l'appelant externe (quand par exemple je me connecte avec mon ordi du bureau connecté en VPN au réseau de mon employeur) en interne je vois l'IPV6 locale pour les connections à DSM ou les connections SMB. Sur mon NAS de backup (accessible de l'extérieur par reverse-proxy) je vois lors d'un appel extérieur, l'IPV4 de mon NAS principal (qui gère le reverse proxy). L'étonnant est que je ne constate pas le même (IP de mon NAS principal) dans le 1er cas alors que je passe là aussi par le reverse-proxy. La différence est qu'il renvoie directement vers localhost:5000. C'est le même chez toi?

Oui, c'est bien ce que je voulais dire. Mais ne sachant pas quelle est la topologie de ton réseau je ne peux pas te proposer de solution (s'il y en a une). Je crois que de toute façon, dans "l'état actuel de nos connaissances", il ne peut y avoir qu'un seul réseau. A voir s'il est possible de le cantonner aux équipements inaccessibles par câble/switch. Après, il peut en effet être intéressant de voir ce qui peut perturber ton CPL, ce qui le rendrait "saturé". Il faudrait faire des tests spécifiques sur cette partie pour voir si les débits observés sont très élevés, alors la cause peut être une vraie saturation ou non, alors il faudrait rechercher les perturbateurs. C'était bien mon intention initiale de privilégier le mode bridge, mais dans ce mode, j'avais des instabilités, en particulier de la TV. Je ne sais pas si ce problème a persisté car je suis depuis près d'un an en mode routeur et ça fonctionne très bien, y compris la TV. Il faudrait que je prenne le courage un jour de retester en mode bridge. Comme je l'ai dit plus haut ce n'est pas très compliqué, à part que les instabilités ne se produisent pas forcément tout de suite...

On est d'accord, il ne faut qu'un jeu de CPL, sur le réseau 192.168.1.0. Après, si c'est un problème de saturation, il n'y a plus qu'à espérer trouver une disposition des équipements et des câbles/CPL qui réduit le flux dans le CPL, au profit de flux dans les liens filaires pour décharger le CPL. Sachant que les switches (et les routeurs - côté LAN) sont assez intelligents pour ne pas diriger sur des ports des flux qui ne lui sont pas destinés. On peut peut-être jouer sur ça ?

C'est sûr, c'est là le problème. Mais as tu besoin de deux réseaux CPL séparés? Un seul ne suffirait-il pas? C'est vrai que s'il est saturé!

Si on reprend ton schéma (post du 29 mars) Il est clair que tu ne veux pas de l'option 1 qui utilise un cable direct entre les FBX Server et FBX Player. Pour l'option 2, Pourrait-on supprimer le branchement CPL sur le FBX server, mettre un CPL sur la sortie du routeur qui transfère Internet ET le VLAN 100, et un ou des CPL pour les équipements tout à droite (FBX Player, PC2 et NAS2). Comme ça il ne devrait pas y avoir de pont parasite entre le sous-réseau géré par la Freebox Server et celui géré par le routeur. Qu'en penses tu?

Est-ce que la TV est plus stable?

Non, je n'ai jamais réussi à faire passer le flux TV à travers le routeur, ni en mode bridge ni en mode routeur. Ca marchait avec un cable direct entre les deux FBX, que ce soit en bridge ou en routeur.

Pour moi, j'avais décidé de passer en mode routeur pour améliorer la stabilité de l'ensemble, surtout de la TV. Cela dit, ce n'est pas long de faire le test, et même de revenir après : Pour passer du mode Bridge au mode routeur, Pas de changement de câblage. Pour la config de la Freebox : passer en mode routeur, mettre en marche le DHCP de la Freebox, mettre le routeur dans la DMZ à une adresse IPV4 fixe grâce au DHCP de la FBX. Je crois que je n'ai rien oublié. la config du routeur ne doit pas changer, ni pour IPV6 ni pour le firewall. Attention à bien arrêter et redémarrer tout après les modifs. Pour comparer la vitesse internet avant et après, tu peux faire quelques coups de Speedtest avant et après. Je pense que ça vaut la peine d'essayer.

Oui. ça marche avec ou sans. J'avais traité IPV6 séparément de la TV. Au début, je n'utilisais pas la TV par la Freebox (j'étais seulement en TNT) et j'ai configuré IPV6 comme ça sur mon réseau. Plus tard, après que ça ait fonctionné en continu, j'ai essayé les différentes confs pour l'IPTV; Comme j'ai un second cable qui va vers mon salon, je n'ai pas été obligé de creuse ce point. J'ai seulement testé la config avec un switch administrable décrite plus haut, mais je l'ai démontée ensuite car j'avais besoin d'un switch pour autre chose. Ceci dit, j'ai trouvé en installant IPV6 qu'il faut bien prendre garde à vider tous les caches et à rallumer chacun des équipements après un changement de config. J'ai eu pas mal de surprises avec ça.

Quand tu dis "ne prenait pas", veux tu dire qu'il ne s'affectait pas d'adresse IPV6 à l'initialisation de son réseau ? ou que l'appelant sur internet n'utilisait pas systématiquement son adresse IPV6, mais parfois l'IPV4 ? Dans le premier cas, je ne connais pas la cause et je n'ai pas d'autre moyen que de forcer l'adresse dans le syno. Dans le second cas (que j'ai eu aussi), j'ai forcé la chose en supprimant l'enregistrement A correspondant dans le DNS et en ne gardant que le AAAA.