Jean Baptiste Favre a écrit :
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.
Je répète que le suivi de connexion de Netfilter, qui classe les paquets dans l'état NEW, ESTABLISHED,RELATED ou INVALID, ne fait aucune vérification de la validité des adresses source et destination d'un paquet. Et le traitement du suivi de connexion est identique pour les paquets reçus et les paquets émis localement.
Les raisons pour classer un paquet dans l'état INVALID sont notamment :- segment TCP correspondant à une connexion existante mais dont le numéro de séquence ne correspond pas ou ne respectant pas la séquence de synchronisation SYN,SYN/ACK,ACK,
- message d'erreur ICMP ne correspondant pas à une connexion existante- réponse ICMP (echo reply par exemple) ne correspondant pas à une requête existante...
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.
Je suppose (mais ne peux que supposer) que c'est lié au fait que le paquet vu en entrée a été rebouclé en interne et n'est jamais passé par l'interface ethernet.