Comment puis-je corriger le message d'erreur iptables "Impossible d'initialiser la table 'Filtre'"?

Question

Lorsque j'essaie d'utiliser la commande iptables sur l'un de mes serveurs cloud Rackspace, le message d'erreur suivant s'affiche.

Dans une tentative d'appliquer des règles iptables avec iptables-apply -t 120 /etc/iptables.rules et iptables-restore < /etc/iptables.rules, j'ai l'erreur suivante:

FATAL: Could not load /lib/modules/2.6.32.4-rscloud/modules.dep: No such file or directory iptables-restore v1.4.4: iptables-restore: unable to initialize table 'filter' Error occurred at line: 2 Try `iptables-restore -h' or 'iptables-restore --help' for more information.

Comment puis-je réparer ça?

EDIT 1:

uname -r :

2.6.32.4-rscloud

modprobe/lib/modules/$ (uname -r) /kernel/net/ipv4/netfilter/iptable_filter.ko :

FATAL: Could not load /lib/modules/2.6.32.4-rscloud/modules.dep: No such file or directory

ls/lib/modules/$ (uname -r)/kernel/net/ipv4/netfilter /:

ls: cannot access /lib/modules/2.6.32.4-rscloud/kernel/net/ipv4/netfilter/: No such file or directory

EDIT 2:

apt-cache search linux-image- *:

alsa-base - ALSA driver configuration files linux-image-2.6.31-14-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-14-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-14-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-302-ec2 - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-9-rt - Linux kernel image for version 2.6.31 on Ingo Molnar's full real time preemption patch linux-image-rt - Rt Linux kernel image rt2400-source - source for rt2400 wireless network driver rt2500-source - source for rt2500 wireless network driver rt2570-source - source for rt2570 wireless network driver linux-image - Generic Linux kernel image. linux-image-2.6.31-15-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-15-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-15-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-16-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-16-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-16-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-17-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-17-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-17-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-19-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-19-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-19-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-20-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-20-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-20-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-21-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-21-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-21-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-304-ec2 - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-305-ec2 - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-306-ec2 - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-ec2 - Linux kernel image for ec2 machines linux-image-generic - Generic Linux kernel image linux-image-server - Linux kernel image on Server Equipment. linux-image-virtual - Linux kernel image for virtual machines linux-image-2.6.31-22-generic - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-22-server - Linux kernel image for version 2.6.31 on x86_64 linux-image-2.6.31-22-virtual - Linux kernel image for version 2.6.31 on x86/x86_64 linux-image-2.6.31-307-ec2 - Linux kernel image for version 2.6.31 on x86/x86_64

Lekensteyn · Answer

Vous devez charger un module de noyau pour activer la table de filtres. Exécutez la commande suivante en tant que root:

modprobe /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/iptable_filter.ko

(uname -r donne la version actuelle du noyau)

Pour obtenir une liste des modules disponibles pour iptables, indiquez le répertoire contenant les modules iptables:

ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/

Pour obtenir des informations sur tous les modules:

modinfo /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/*.ko

Anona112 · Answer

il s'avère que c'était juste un manque Sudo!

Sudo iptables-restore < /etc/iptables.rules

au lieu de

iptables-restore < /etc/iptables.rules

codercake · Answer

J'utilise également le cloud Rackspace, avec le noyau 2.6.35.4-rscloud. J'ai plusieurs instances avec ce noyau et iptables fonctionne bien sur certains et j'ai le même problème que vous sur quelques autres.

Par conséquent, je crois que ce noyau a le support nécessaire pour iptables, et que le problème est causé par autre chose (je cherche toujours la solution moi-même)

EDIT: J'ai résolu mon problème en scp -r en copiant le /lib/modules/2.6.35.4-rscloud du serveur iptablessur le serveur qui ne fonctionnait pas.

Pour une raison quelconque, uname -r affiche 2.6.35.4-rscloud et ls /lib/modules/ ne contenait que la version précédente, comme /lib/modules/2.6.31-302-rs.

Je ne sais pas pourquoi cela peut ne pas être synchronisé, ou quoi faire si vous ne disposez pas d'un serveur de travail pour copier ces fichiers, mais j'espère que cela vous oriente dans la bonne direction.

Je n'ai pas eu besoin de recompiler un noyau ou quoi que ce soit du genre.

Francis Turner · Answer

Un autre moyen d'obtenir le bon support iptables est d'installer xtables-addons, vous devez disposer de nombreux outils pour que cela fonctionne (module-assistant, build-essential, etc.), mais l'avantage est qu'au final vous avez Ipset ainsi que iptables et (IMHO) utilisant Ipset est également bien meilleur pour les grands ensembles de règles complexes

apt-get install xtables-addons-common apt-get install xtables-addons-source m-a prepare m-a build xtables-addons m-a install xtables-addons

David Michael Gregg · Answer

J'ai eu la même erreur, mais j'ai trouvé un commentaire errant dans un article sans rapport ( http://articles.slicehost.com/2007/11/6/ubuntu-gutsy-setup-page-1 ) qui a identifié l'erreur moléculaire stupide qui était en cause dans mon cas. Le problème était que j'avais créé le fichier iptables.rules à l'aide d'un éditeur de texte (Notepad ++), mais parce que le type de fichier n'était pas reconnu, Notepad ++ utilisait par défaut Windows . et caractères de fin de fichier . iptables rejette ces caractères, nécessitant leurs équivalents Unix, et lançait donc une erreur lors de la première occurrence: la fin de la ligne *filter - donnant la fausse impression qu'il y avait un problème avec la syntaxe *filter. Ah, les joies omniprésentes des erreurs liées au codage de caractères!

Deux solutions

Le commentateur que j'ai mentionné ci-dessus a installé (Sudo aptitude install tofrodos) et exécuté (fromdos /etc/iptables.rules) un petit utilitaire de conversion sur le fichier.

---OU---

Ce que j'ai fait était, dans Notepad ++, Edit> EOL Conversion> UNIX Format, puis Save et de télécharger à nouveau le fichier. Cela s’occupait des caractères de fin de ligne , mais pas du caractère de fin de fichier (malgré ce que l’on pourrait faire attendre). Donc, une fois que je l'ai téléchargé sur le serveur, je l'ai ouvert dans nano et créé une nouvelle ligne à la fin du fichier et enregistré. Ensuite, tout a fonctionné parfaitement.

Il est également possible que d'ouvrir le fichier dans nano et de le sauvegarder, sans modifier réellement les caractères manuellement, ferait l'affaire, mais je n'ai pas encore testé.

William Turrell · Answer

Vous pouvez également obtenir des erreurs avec iptables si vous avez installé une nouvelle version du noyau mais que vous n’avez pas encore redémarré (assez courant si vous construisez un nouveau serveur en utilisant, par exemple, un playbook Ansible, et si une tâche antérieure est: une apt-get upgrade )

Voir https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829269#41 Objet: Erreur "Symbole inconnu dans le module ou paramètre inconnu".

Pierre · Answer

Il est possible que le noyau Linux que vous utilisez n'ait pas été construit avec un support de module chargeable. Un bon moyen de savoir si votre noyau prend en charge le module consiste à vérifier l'existence du fichier /proc/modules. S'il est là mais que vous n'avez pas de fichier /lib/modules/$(uname -r)/modules.dep, cela signifie que votre noyau prend en charge les modules mais qu'ils n'ont pas été correctement installés. On dirait que votre noyau a été construit par votre fournisseur Rackspace, vous devriez leur poser des questions sur la configuration du noyau.