Débogage d'Iptables

Iptables peut être parfois difficile à déboguer, car les messages d'erreur provenant d'iptables lui-même ne sont pas toujours conviviaux. Pour cette raison, ce peut être une bonne idée de regarder les messages d'erreur les plus fréquents venant d'iptables, et pourquoi vous les obtenez.

Un des premiers messages d'erreur à regarder est le "Unknown arg". Il peut apparaître pour différentes raisons. Exemple ci-dessous.

work3:~# iptables -A INPUT --dport 67 -j ACCEPT
iptables v1.2.9: Unknown arg `--dport'
Try `iptables -h' or 'iptables --help' for more information.
      

Cette erreur est simple à corriger, car nous n'avons utilisé qu'un seul argument. Normalement, nous pouvons avoir utilisé une très longue commande et obtenir ce message. Le problème dans le scenario ci-dessus est que nous avons oublié d'utiliser la correspondance --protocol, et à cause de ça, le module --dport n'est pas disponible. En ajoutant la correspondance --protocol nous résoudrons le problème. Soyez absolument certains que vous n'oubliez aucune pré-condition spéciale nécessaire pour utiliser une correspondance spécifique.

Une autre erreur très commune est que vous oubliez un tiret (-) quelque part dans la ligne de commande, comme en-dessous. La solution est de rajouter simplement ce tiret, et la commande fonctionnera.

work3:~# iptables -A INPUT --protocol tcp -dport 67 -j ACCEPT
Bad argument `67'
Try `iptables -h' or 'iptables --help' for more information.
      

Et enfin, le simple oubli, ce qui est le plus courant. Voir ci-dessous. Le message d'erreur, est exactement le même que lorsque vous oubliez d'ajouter une correspondance pré-requise à votre règle, aussi il est nécessaire de les regarder de près.

work3:~# iptables -A INPUT --protocol tcp --destination-ports 67 -j ACCEPT
iptables v1.2.9: Unknown arg `--destination-ports'
Try `iptables -h' or 'iptables --help' for more information.
      

Il existe aussi une cause plus probable quand vous obtenez l'erreur "Unknown arg". Si l'argument est écrit correctement, et qu'il n'y a pas d'erreur dans les pré-requis, il est possible que la cible/correspondance/table ne soit pas compilée dans le noyau. Par exemple, nous oublions de compiler la table filter dans le noyau, ce qui ressemblera à ça.

work3:~# iptables -A INPUT -j ACCEPT
iptables v1.2.9: can't initialize iptables table `filter': Table does not exist 
(do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
      

Normalement, iptables est capable de charger automatiquement un module spécifique qui n'est pas déjà dans le noyau, c'est généralement le signe que soit vous n'avez pas fait un depmod correct après avoir redémarré avec le nouveau noyau, soit vous avez simplement oublié le(s) module(s). Si le module problématique est une correspondance, le message d'erreur sera plus crypté et difficile à interpréter. Par exemple, regardons ce message d'erreur.

work3:~# iptables -A INPUT -m state 
--state ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name
      

Dans ce cas, nous avons oublié de compiler le module, et comme vous avez vu, le message d'erreur n'est pas très facile à interpréter. Mais il fait allusion à ce qui est faux. Finalement, nous avons la même erreur de nouveau, mais cette fois, la cible est omise. Comme vous l'avez compris en regardant le message, il est plus compliqué car c'est exactement le même pour les deux erreurs (correspondance et/ou cible oubliée).

work3:~# iptables -A INPUT -m state 
--state ESTABLISHED -j REJECT
iptables: No chain/target/match by that name
      

Le moyen le plus simple de savoir si vous avez oublié de faire un depmod, ou si le module est manquant, est de regarder dans le répertoire où se trouvent les modules. C'est le répertoire /lib/modules/2.6.4/kernel/net/ipv4/netfilter. Tous les fichiers ipt_* écrits en majuscules sont des cibles, et tous les autres en minuscules sont des correspondances. Par exemple, ipt_REJECT.ko est une cible, tandis que ipt_state.ko est une correspondance.

Dans les noyaux 2.4 et plus anciens, l'extension de fichier pour tous les modules du noyau étaient .o, qui a été changée pour les fichiers des noyaux 2.6 en .ko.

Une autre façon d'obtenir de l'aide d'iptables lui-même est de commenter une chaîne entière dans votre script pour savoir si ça résoud le problème. En supprimant la chaîne et mettant à la place une stratégie par défaut (ACCEPT), et ensuite en testant, si ça marche mieux, c'est que c'était cette chaîne qui causait les problèmes. Si rien ne s'améliore, alors c'est une autre chaîne, et vous devez chercher le problème ailleurs.