Pascal Hambourg a écrit : > 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. Justement, dans le cas qui nous intéresse, le paquet DROPpé a comme adresse IP source l'IP locale et comme adresse destination l'IP multicast. C'est pour cela que je pense qu'il pourrait être classé INVALID. Exemple de log: Mar 24 12:24:26 localhost kernel: [17591169.788000] IN=eth0 OUT= MAC= SRC=10.0.0.10 DST=228.67.43.91 LEN=39 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=UDP SPT=15947 DPT=15947 LEN=19
Faut que je contrôle avec tcpdump d'ailleur parce que je vois pas d'adresse MAC. Peut-être normal pour du multicast mais je ne peux pas en juger. Un spécialiste de la chose pourrait-il nous éclairer ? > 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". Donc ce multicast là se comporterait "comme" sur une interface de loopback ? ou alors j'ai pas compris ce qui est loin d'être exclu :-) > 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. Moi itou :-s Cordialement, JB
