Jean Baptiste Favre a écrit :
N'étant pas un spécialiste réseau (notamment sur le multicast), je n'ai pas la réponse. Je ne peux que me perdre en conjectures :-)
Pas mieux. Je ne suis pas spécialiste réseau et ne connais quasiment rien au multicast.
En passant une question: comment se fait-il que la réponse à ce paquet ne passe pas comme ESTABLISHED dans Netfilter ?Si le paquet reçu est le paquet UDP multicast émis, il a l'état NEW. Si c'était un message d'erreur ICMP, il aurait l'état RELATED et passerait par l'interface de loopback puisqu'envoyé de la machine à elle-même.Je pense surtout après réflexion que le problème, c'est l'IP de destination qui n'est pas l'IP locale. Donc le paquet n'est pas considéré comme ESTABLISHED ou RELATED. Je pense même, je ferai l'essai, qu'il devrait être considéré comme INVALID puisque semblant provenir de la machine locale mais sur l'interface externe.
Je ne pense pas. Pour autant que je sache, iptables et le suivi de connexion de Netfilter se servent des adresses source et destination uniquement pour rattacher un paquet à une connexion pour l'un et à faire des comparaisons dans les règles pour l'autre. D'ailleurs ils ne gèrent pas spécifiquement les broadcasts et multicasts, ce qui peut poser des problèmes avec certaines applications. Et puis, je ne crois pas que l'état INVALID puisse exister en UDP.
C'est plutôt la pile IP qui peut rejeter des paquets reçus avec une adresse source jugée invalide (les "martiens"). En ce qui concerne les paquets rebouclés et donc qui entrent avec une adresse source locale, la pile se débrouille bien pour accepter les broadcasts qui entrent dans cette catégorie alors on peut penser que c'est pareil pour les multicasts "locaux".
J'ai bien essayé sur une machine, mais le paquet émis n'est pas rebouclé. Je suppose qu'il faut préalablement "enregistrer" l'adresse multicast pour recevoir le trafic qui lui est destiné, ce que je ne sais faire.