(Mini 4K) Défaut de redirection de ports

[paroy (Auteur du topic)]

Bonjour,

J’essaie d'installer une passerelle domotique sur raspberrypi (debian11) derrière une FBXmini r1 version 4.7.3 en Full Stack. En local, pas de pb de communication. En wan, les redirections que j'ai paramêtrées ne semblent pas s'ouvrir (ports appli domotique et vnc). Ils n'apparaissent pas en connexion entrante. J'accède sans problème à Freebox.os en externe. J'ai autorisé ces ports dans le parefeux du raspberry.

celui-ci a bien une IP fixe définie dans le DHCP de la FBX. J'ai installé ce même raspberry sur un autre réseau derrière une Livebox avec les mêmes redirections en NAT, et là, j'accède sans problème à VNC et ma domotique en WAN. Ca semble confirmer que c'est la FBX qui ne veut pas de me redirections. Mes recherches sur ce sujet sur les différents forums ne m'ont pas permis de trouver où je pouvais me planter: IP destination, l'adresse IP fixe de mon raspberry; Redirection active cochée; IP source: toutes.

Le redémarrage de la box et sa réinitialisation n'y ont rien fait. Je pense tenter l'utilisation du DMZ et/ou la réinitialisation d'usine.

Quelqu'un a-t-il une quelconque piste à me proposer ?

Merci d'avance de votre aide

*** Modération *** Titre et mise en page édités *** Modération ***

Curtis Newton

[Eric12]

Bonjour,

[winged]

Bonjour,

si vous êtes en Fibre, avez-vous l'ensemble de votre plage de port ?

sinon il faut demander à Free une IP Full Stack.

Cordialement

[Eric12]

[FreeWave]

L' éternelle rengaine... ma Freebox n'exécute pas la redirection de port

On la connait, c'est un sujet récurrent depuis 10 ans... ou disons depuis que Freebox OS existe

Avec le recul....

On peut vous affirmer avec certitude que la redirection de port IPv4 fonctionne sur la Freebox le problème vient d'ailleurs (dès lors que vous confirmez être en IPv4 Full Stack), ça fait suffisamment de temps que certains d'entre nous utilisons ce bidule et répondons à des questions sur ce forum ou ailleurs, forum que je connais personnellement depuis ses origines (même si je n'ai pas forcément eu de compte actif dessus pendant longtemps),

Si ça marche avec Orange et pas avec Free...
La différence fondamentale entre Free et Orange... c'est que Free est passé il y a quelques temps en IPv6 natif, avec IPv4 tunnelé, alors qu'avant c'était l'inverse comme partout ailleurs. Il semblerait que dans certains scénarios ce changement ait eu un effet en changeant le comportement de certains hôtes distants qui vont alors prioriser la couche IPv6

Alors, je me demande si votre connexion entrante ne se ferait en pas en IPv6... rendant le port forwarding IPv4 inutile sur le réseau Free puisqu'il n'y a aucun flux, et on aurait une explication rationnelle sur la différence de comportement entre les deux box agissant sur deux réseaux différents.

La Freebox n'ayant pas de port forwarding en IPv6 il faut impérativement DESACTIVER le pare feu IPv6 de la box (case à laisser décochée sur Freebox OS) pour laisser tous les flux parvenir au niveau des hôtes réseaux, c'est au niveau des pare feu des hôtes réseau qu'on autorise la connexion entrante en IPv6 sur le port de son choix, de ce fait en IPv6 un simple port forwarding suffit, il n'est en général pas nécessaire de faire une redirection de port (triggering) sauf si on cherchait à masquer volontairement un port connu. Typiquement serveur HTTP/HTTPS en local, mais de l'extérieur accessible uniquement depuis un numéro de port bidon redirigé par ue règle IPTABLE sur le port HTTP/HTTPS, ce qui évite d'exposer directement son serveur local aux attaques massives qui peuvent venir sur les ports standard HTTP/HTTPS

Je vous rappelle que si votre Raspbery est bien paramétré, il dispose DE SA PROPRE adresse IPv6 publique distincte de l'adresse IPv6 de la box [2a01:aaaa:aaaa:aaa::1] pour la Freebox elle même. Je rappelle que le concept de NAT n'existe pas en IPv6

Votre Raspberry Pi correctement paramétré sur ses valeurs par défaut, devrait même disposer de deux adresses IPv6, une IPv6 publique dynamique qui change tous les "x" temps que l'on peut très bien utiliser sur un serveur avec un système de DNS Dynamique (voir dynv6.com le seul opérateur que j'ai trouvé faisant du dynamic DNS en IPv4 et IPv6, et pour le moment totalement gratuit), l'avantage de cette solution est qu'elle réduit de façon considérable l'exposition de votre serveur à des attaques DOS.

Donc finalement sur cet aspect vous gagnez largement avec l'IPv6 puisque votre adresse IPv4 statique est en réalité un non sens en terme de sécurité. C'est un point d'entrée rêvé pour les attaques, le hacker n'a qu'une seule adresse IPv4 comme cible puis tranquilou il scanne les ports, en IPv6 il doit scanner un prefix de 64 bits d'adresse qui est l'espace de variation potentiel de l'adresse dynamique, et pour chaque adresse tester les ports.

Ou, vous pouvez utiliser l'adresse publique statique EUI64 générée à partir de l'adresse MAC, adresse masquée qui ne se manifestera que sur une connexion entrante initiale, ce n'est pas l'adresse qui sera utilisée par défaut pour les connexions sortantes.

Si cette hypothèse se révélait exacte, la question est de savoir : avec quelle adresse IPv6 votre bidule chercherait à se connecter à votre Raspberry Pi, je n'en sais fichtre rien, je ne connais pas le bidule qui cherche à se connecter (je suppute qu'on parle d'un pilotage via une app Android/iOS. Il y a donc des serveurs centraux extérieurs à qui vous avez communiqué des instructions via votre app Android).

Si il cherche à se connecter avec l'adresse IPv6 de la Freebox, ça ne peut pas marcher... encore une fois en IPv6 il faut s'éjecter de l'esprit la notion de NAT d'où l'utilité éventuelle de mettre en oeuvre un service de DNS dynamique au niveau du serveur et paramétrer le bidule pour se connecter via le nom de domaine monbidule@dynv6.com (ou autre noms de domaines racine autorisés par le fournisseur) ou vous lui codez en dur l'adresse statique EUI64 qui sera toujours la même même après reboot du Raspberry sauf si vous avez bidouillé les paramètre IPv6 par défaut.

Sur Windows par défaut, et par pure paranioa, EUI64 n'est pas activé, donc à chaque redémarrage Windows peut potentiellement changer d'adresse de lien local et d'adresse IPv6 statique, les deux partageant des bits commun (il n'y a pas de lien avec l'adresse MAC), c'est clairement casse c.... à gérer pour les parefeu, il y a une manipulation simple à faire pour activer l'EUI64 sous Windows
Sur les distro Linux en général EUI64 est activé par défaut, mais attention, on peut très bien tomber sur des distros qui auraient pris l'option inverse donc à vous de régler les paramètres.

Il faut déjà s'assurer que votre serveur a de bons paramètres IPv6... les Geeks du dimanche détestant l'IPv6 ont tendance à négliger ces aspects, certains ahuris allant même jusqu'à le désactiver décrétant sans aucune connaissance du sujet que ce n'est pas "safe"

Dès lors que Free a basculé en IPv6 natif... il parait impossible désormais de désactiver la couche IPv6 au niveau d'un serveur local vu que nombreuses requêtes entrantes se feront en priorité via cette couche pour éviter le tunneling IPv4 qui se paie en terme d'efficacité.

[paroy (Auteur du topic)]

Merci à tous pour vos réactions et aide. Avec la mine d'infos de Freewave, j'y vois plus claire (un peu) et entrevois quelques pistes de travail en basculant des redirections IPv4 à des liaisons IPv6. Faut juste que j'assure mes arrières côté parefeux serveur domotique.