[Résolu]Script Iptables

Après votre aide très efficace, relative a ce post, je rencontre encore quelques petits problemes avec mon script des iptables.

J’utilise un script, pour un serveur de jeu distant(que j’administre en ssh).

le script s’exécute et fonctionne, néanmoins même si ce dernier semble remplir efficacement son office, j obtiens le message d’erreur suivant :

[1] 3595 sd-xxx:/usr/local/games/quake3# iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument

Je lance le dudit script dans un screen [code]screen -dmS nom_de_mon_screen

//puis

screen -r nom_de_mon_screen

//et enfin

sd-3707:/usr/local/games/quake3# ./ports2 xx.xx.xx.xx 27964 40030 40050 3600 &
[/code]

ports2 étant le nom de mon script (mais vous l aviez compris) le script fonctionne donc mais j’obtiens quand même le fameux prompt (iptables: Invalid argument), et tout en étant débutant, j’aime assez les choses “propres”, alors la encore si vous aviez une piste :wink:

Pour ce faire je vous joins le script, assez court en l’occurrence :

[code]#!/bin/tcsh

Copyright © 2008 glizda

set ip=$1
set realport=$2
set startport=$3
set stopport=$4
set timeout=$5

set port=$startport
set lastport=0
set iptables=/sbin/iptables

set masters=“q3master.allseeingeye.com master0.excessiveplus.net

foreach a ( $masters )
$iptables -t nat -A POSTROUTING -p udp --sport $realport -d $a -j ACCEPT
end

$iptables -t nat -A PREROUTING -p udp --dport “$startport”:"$stopport" -m u32 --u32 “0x20&0xFFFFFFFF=0x67657469” -j DROP
$iptables -t nat -A PREROUTING -p udp --dport “$startport”:"$stopport" -m u32 --u32 “0x20&0xFFFFFFFF=0x67657473” -j DROP
$iptables -t nat -A PREROUTING -p udp --dport “$startport”:"$stopport" -m u32 --u32 “0x1c&0xFFFFFFFF=0x70696e67” -j DROP
$iptables -t nat -A PREROUTING -p udp --dport “$startport”:"$stopport" -j DNAT --to-destination “$ip”:"$realport"

while (1)
$iptables -t nat -A POSTROUTING -p udp --sport $realport --dport 27950 -j SNAT --to-source “$ip”:"$port"
$iptables -t nat -I PREROUTING -p udp --dport $port -m u32 --u32 “0x20&0xFFFFFFFF=0x67657469” -j DNAT --to-destination “$ip”:"$realport"
$iptables -t nat -I PREROUTING -p udp --dport $port -m u32 --u32 “0x20&0xFFFFFFFF=0x67657473” -j DNAT --to-destination “$ip”:"$realport"
$iptables -t nat -I PREROUTING -p udp --dport $port -m u32 --u32 “0x1c&0xFFFFFFFF=0x70696e67” -j DNAT --to-destination “$ip”:"$realport"
if ($lastport != 0) then
$iptables -t nat -D PREROUTING -p udp --dport $lastport -m u32 --u32 “0x20&0xFFFFFFFF=0x67657469” -j DNAT --to-destination “$ip”:"$realport"
$iptables -t nat -D PREROUTING -p udp --dport $lastport -m u32 --u32 “0x20&0xFFFFFFFF=0x67657473” -j DNAT --to-destination “$ip”:"$realport"
$iptables -t nat -D PREROUTING -p udp --dport $lastport -m u32 --u32 “0x1c&0xFFFFFFFF=0x70696e67” -j DNAT --to-destination “$ip”:"$realport"
$iptables -t nat -D POSTROUTING -p udp --sport $realport --dport 27950 -j SNAT --to-source “$ip”:"$lastport"
endif

sleep $timeout

@ lastport = $port

if ($port == $stopport) then
    @ port = $startport
else
    @ port++
endif

end
[/code]

Merci d’avance.

bonjour,
ben tu fais un pti peu de débugage, des echos à chaque ligne pour savoir laquelle passe pas bien( ou alors un pti set -x en début de script et set +x en fin pour tracer … mais en tcsh je sais pas).

Qu’affiche “iptables-save -t nat” ?

@ Uzinagaz

-> J’aimerai faire du debugage… mais l’étendue de mes connaissances ne me permettent pas de comprendre le script… je suis plus que raz des pâquerettes (j’apprends de façon empirique)

Cela étant j’ignore si c’est une hérésie mais j ai bash et tcsh installés sur ce même serveur… les 2 savent coexister en paix ?

@ PascalHambourg

voici le retour de “iptables-save -t nat”

[code]# Generated by iptables-save v1.3.6 on Sat May 10 04:32:43 2008
*nat
:PREROUTING ACCEPT [148487:8312491]
:POSTROUTING ACCEPT [3035:272313]
:OUTPUT ACCEPT [5309:397383]
-A PREROUTING -p udp -m udp --dport 40000:40020 -j DNAT --to-destination xx.xx.xx.xx:27960
-A PREROUTING -p udp -m udp --dport 40030:40050 -j DNAT --to-destination yy.yy.yy.yy:27964
-A PREROUTING -p udp -m udp --dport 50000:50020 -j DNAT --to-destination zz.zz.zz.zz:27968
-A POSTROUTING -d 216.109.112.135 -p udp -m udp --sport 27960 -j ACCEPT
-A POSTROUTING -d 89.149.194.215 -p udp -m udp --sport 27960 -j ACCEPT
-A POSTROUTING -d 216.109.112.135 -p udp -m udp --sport 27964 -j ACCEPT
-A POSTROUTING -d 89.149.194.215 -p udp -m udp --sport 27964 -j ACCEPT
-A POSTROUTING -d 216.109.112.135 -p udp -m udp --sport 27968 -j ACCEPT
-A POSTROUTING -d 89.149.194.215 -p udp -m udp --sport 27968 -j ACCEPT
-A POSTROUTING -p udp -m udp --sport 27960 --dport 27950 -j SNAT --to-source xx.xx.xx.xx:40006
-A POSTROUTING -p udp -m udp --sport 27968 --dport 27950 -j SNAT --to-source yy.yy.yy.yy:50014
-A POSTROUTING -p udp -m udp --sport 27964 --dport 27950 -j SNAT --to-source zz.zz.zz.zz:40047
COMMIT

Completed on Sat May 10 04:32:43 2008

[/code]

xx…yy…zz… correspondent a l’ip (identique a chaque fois) de ma machine, quant aux IPs suivant (-A POSTROUTING -d) j’ignore a quoi elles correspondent, aux games-trackers “q3master.allseeingeye.com” et “master0.excessiveplus.net” probablement ?..

Nota : J’ai 3 scripts fonctionnant sur le même serveur, puisque je fait “tourner” 3 game-servers sur la même machine.

J’obtiens le message d’erreur même lorsqu’un seul des scripts est lancé.

Merci.

bonjour,
mes connaissances d’iptables ne me permettent pas de voir à vue de nez les lignes qui posent problème, oui bash et d’autre coexistent sans problème.
tu édites ton script, et tu places des `echo’ tout simplement, comme ceci:

echo "envoi ligne 1" $iptables -t nat -A PREROUTING -p udp --dport "$startport":"$stopport" -m u32 --u32 "0x20&0xFFFFFFFF=0x67657469" -j DROP echo "envoi ligne 2" ... etc ...
pour voir les lignes qui passent pas.
enfin, sans doute passes tu des arguments non valides, ou même tu te réfères à des tables qui ne sont pas activées/crées dans noyau/iptables ?

@ usinagaz

J’ai effectué la manip indiquée… le résultat est… comment dire… accablant !

voici les lignes posant problème :

étrangement, les scripts ont fonctionné pratiquement une journée… puis, sans que je ne modifie quoi que ce soit, ils ont cesses de remplir leur fonction - ou plus précisément l’effet visible des scripts ne dura que le temps d’un journée :open_mouth:

Dans le how-to qui m as été fourni avec le script, il est fait mention de la necessité pour le serveur de pouvoir ‘gérer’ le U32 packet matching (ou quelque chose comme ça) - cela pourrait il être a l’origine du problème ?

bonsoir,
c’est quoi déjà -m 32 --u32 ?
à priori il y a 6 adresses qui n’existent plus, je suppose qu’un truc du style 0x20&0xFFFFFFFF=0x67657469 est une adresse ?
en quoi consiste ton script au juste, sa fonction ?
tu peux toujours rediriger vers /dev/null l’erreur, ou alors tu commentes ces 6 lignes, ou alors tu trouves à quoi correspondent ces adresses et pourquoi elles n’existent plus, ou pourquoi elles ont changé.

La fonction de ce script :

Mon serveur héberge un modification d’un jeu (Q3 pour ne pas le nommer) - Ce script effectuer des rotations de ports du jeu ip:port_variable tout en 'leurrant" les gametrackers pour que les joueurs puissent “bookmarker” un serveur dont l’IP et le port semblent constants

le --u32 (et consort) semblent être relatif a la fameuse technologie u32 packet-matching.

  • Je file réparer mon clavier, qui subit mes humeurs a cause de ce script, et reviens au plus vite renseigner le reste de tes questions :wink: -

tu as donc des lignes qui sont correctes, avec arguments valides, commente celles qui posent problème.
je ne pourrais pas plus t’aider pour ces dernières. @+

ps: à part que tu dois chercher pourquoi ces arguments ne sont plus valides …; heum … en tout cas, une partie de ton script est exécuté, normalement (sauf lignes invalides). Vois le avec un iptables -L ?

Merci pour ton aide, je vais continuer a chercher une solution a ce problème…

Pour ceux qui pourraient avoir une idée, je peux apporter les nouvelles infos suivantes, les recommandations pour faire fonctionner ce script sont :

-> vanilla iptables version 1.4.0rc1 ou ulterieure
-> Nouveau Kernel (> à 2.6.23.12)

Pour ma part, mon serveur fonctionne avec -> Debian : Sarge et Etch (4.0r2)

petite précision, vanilla c’est le nom du kernel, rien à voir avec iptables non ?
en tous cas tu dois avoir compilé iptables pour ton noyau j’imagine ?
mais c’est pas le problème, puisque --u32 passe, ça passe tout le temps, pour peu que l’argument soit valide.

Je découvre… pour moi vanilla jusqu’à présent n’évoquais qu’une épice sympathique ou un groupe de mauvaise pop.

En l’occurrence je me suis contenté (il y a un certain temps déjà) de choisir un distro avec la location de mon serveur… Je n ai rien compilé des plus - j’ai utilisé un outils fourni “clé en main”.

J’ai par contre, testé le script en local sur un laptop installé en ubuntu Hardy… Et la ! surprise ! le script s’exécute sans problèmes !

Le qualificatif “vanilla” désigne généralement un noyau construit à partir des sources originelles non modifiées de kernel.org. Les distributions comme Debian appliquent souvent des patches à ces sources, leurs noyaux ne sont donc pas “vanilla”.

Les erreurs semble venir de la correspondance u32. Cette correspondance n’est incluse dans le noyau vanilla qu’à partir de la version 2.6.23. Quel noyau utilises-tu ? Les noyaux 2.6.8 de sarge et 2.6.18 d’etch ne supportent pas u32.

L’argument de l’option --u32 n’est pas une adresse mais une expression logique complexe composée d’éléments du type {si l’offset xx du paquet masqué avec les bits yy égale zz} dont le résultat vrai ou faux conditionne l’application de la règle au paquet.

J’imagine que c’est assez simple de savoir quel noyau l’on utilise… mais en bon noob qui se respecte, je me suis contenté de choisir une distro (Debian) en l’occurrence parmi toutes celle proposée par mon hebergeur (Dedibox pour ne pas le citer).

Pour tester, j ai remplacé Debian par Ubuntu sur le serveur, puisque @ home cela semblait poser moins de problèmes…

La encore, le script semble fonctionner avec un mess. d’erreur au lancement :

[code]root@xxx:/usr/local/games/quake3# ./ports1 xx.xx.xx.xx 27960 40000 40020 3600 &
[1] 23670
root@xxx:/usr/local/games/quake3# iptables v1.3.8: Couldn’t load match `u32’:/lib/iptables/libipt_u32.so: cannot open shared object file: No such file or directory

Try iptables -h' or 'iptables --help' for more information. iptables v1.3.8: Couldn't load matchu32’:/lib/iptables/libipt_u32.so: cannot open shared object file: No such file or directory

Try iptables -h' or 'iptables --help' for more information. iptables v1.3.8: Couldn't load matchu32’:/lib/iptables/libipt_u32.so: cannot open shared object file: No such file or directory

Try iptables -h' or 'iptables --help' for more information. iptables v1.3.8: Couldn't load matchu32’:/lib/iptables/libipt_u32.so: cannot open shared object file: No such file or directory

Try iptables -h' or 'iptables --help' for more information. iptables v1.3.8: Couldn't load matchu32’:/lib/iptables/libipt_u32.so: cannot open shared object file: No such file or directory

Try iptables -h' or 'iptables --help' for more information. iptables v1.3.8: Couldn't load matchu32’:/lib/iptables/libipt_u32.so: cannot open shared object file: No such file or directory

Try `iptables -h’ or ‘iptables --help’ for more information.
[/code]

Puis, même symptômes qu’avec la distro Debian… au bout de 24 heures, le script ne rempli plus son office :confused:

A la lecture du mess. d’erreur je crois deviner que libipt_u32.so est manquante…
Y’a t’il un moyen de remedier a ça ? de l’installer ?

pour connaître la version du noyau actif. Dedibox fournit ses propres noyaux, de versions plus récentes que ceux de sarge ou etch.
[code]grep "MATCH_U32" /boot/config-$(uname -r)[/code]
devrait permettre de voir si le noyau actif supporte la correspondance u32.

Le message d'erreur signifie cette fois que c'est iptables qui ne supporte pas la correspondance u32. En effet plusieurs extensions du patch-o-matic-ng dont u32, non supportées par le noyau "vanilla" et jugées obsolètes, ont été retirées de la version 1.3.8 d'iptables (un peu hâtivement à mon goût) ; puis certaines dont u32 ont été réintroduites dans la version suivante 1.4.0 à la faveur d'un remaniement du code d'iptables et de l'ajout de ces extensions dans les noyaux "vanilla" plus récents.

pour connaître la version du noyau actif. Dedibox fournit ses propres noyaux, de versions plus récentes que ceux de sarge ou etch.

devrait permettre de voir si le noyau actif supporte la correspondance u32.

Le message d’erreur signifie cette fois que c’est iptables qui ne supporte pas la correspondance u32. En effet plusieurs extensions du patch-o-matic-ng dont u32, non supportées par le noyau “vanilla” et jugées obsolètes, ont été retirées de la version 1.3.8 d’iptables (un peu hâtivement à mon goût) ; puis certaines dont u32 ont été réintroduites dans la version suivante 1.4.0 à la faveur d’un remaniement du code d’iptables et de l’ajout de ces extensions dans les noyaux “vanilla” plus récents.

Bien,

J ai donc formaté, viré Ubuntu Hardy, réinstalle la distro Debian de dedibox et entré les commandes suivantes :

uname -a me retourne :

Linux sd-3707 2.6.24.2dedibox-r8-1-c7 #1 Mon Feb 11 17:41:33 CET 2008 i686 GNU/Linux

grep “MATCH_U32” /boot/config-$(uname -r) me retourne :

Il semble donc que mon noyau (c’est bizarre de dire ça :,] ) ne supporte pas U32. pour le moment ?

Peut on remédier a ça (en updatant/installant les composants manquants)? dans le cas contraire, y’a t’il un distro (autre que le dedibox-Debian susceptible de supporter U32 - une Ubuntu moins récente que Hardy par ex ?)

Merci encore.

Non, le message d’erreur de grep signale que le fichier /boot/config-2.6.24.2dedibox-r8-1-c7, censé contenir la configuration du noyau, n’existe pas. J’ai retrouvé ce noyau là ftp://ftp.dedibox.fr/pub/dedibox/kernel/r8-1/C7-X86-32bits/ et en fait le fichier de config s’appelle config-2.6.24.2. Bizarre. Bref, la correspondance u32 est bien présente en module, tu peux le vérifier avec la commande suivante :

Maintenant, le problème qui peut éventuellement se produire est une incompatibilité entre le module libipt_u32.so de la version 1.3.6 d’iptables (qui était prévu pour fonctionner avec le module ipt_u32.ko du patch-o-matic-ng) incluse dans Debian etch et le module xt_u32.ko intégré au noyau à partir de la version 2.6.23. Dans ce cas il faudrait installer iptables 1.4.0 soit à partir d’un paquetage rétroporté (pas vu dans backports-etch) soit en le compilant à partir des sources de http://www.netfilter.org/.

Effectivement a la commande -> modinfo xt_u32 :

filename:       /lib/modules/2.6.24.2dedibox-r8-1-c7/kernel/net/netfilter/xt_u32               .ko
alias:          ip6t_u32
alias:          ipt_u32
license:        GPL
description:    netfilter u32 match module
author:         Jan Engelhardt <jengelh@computergmbh.de>
depends:        x_tables
vermagic:       2.6.24.2dedibox-r8-1-c7 mod_unload VIAC7

Pour le reste - j essaie de te suivre :,] - la solution a mon probleme reside probablement dans l’installation d’iptables 1.4.0 ?
-> faute de quoi je reverrai mon fameux message d’erreur sd-xxxx:/usr/local/games/quake3# iptables: Invalid argument iptables: Invalid argument ...

Si je te suit bien, l’install d’iptables 1.4.0 ne peut se faire grâce a un bête apt-get install quelque_chose … mais compilant (? su make install quelque_chose?) des sources téléchargées sur netfilter.org ?

(Désolé, j’ai conscience d’être affligeant d’ignorance)

[quote=".Su!."]Pour le reste - j essaie de te suivre :,] - la solution a mon probleme reside probablement dans l’installation d’iptables 1.4.0 ?
-> faute de quoi je reverrai mon fameux message d’erreur[/quote]
J’en ai peur.

En effet, sauf à récupérer un paquetage .deb d’iptables 1.4.0 chez Ubuntu à supposer qu’il existe et qu’il daigne bien s’installer avec ‘dpkg -i nomdupaquet.deb’.
Pour installer iptables à partir des sources, il faut récupérer et décompresser l’archive iptables-1.4.0.tar.bz2 puis suivre les instructions dans le fichier INSTALL. J’ai fait ça il y a longtemps pour une version antérieure, je ne suis pas sur la machine en question et j’ai un peu oublié les détails. En tout cas par défaut les fichiers sont installés à un emplacement (sous /usr/local/ de mémoire) différent de ceux du paquetage iptables Debian, donc ils ne les écrasent pas. De plus cet emplacement est prioritaire dans les chemins d’exécution (PATH).

Bien compris…

Cela me donnera l’occasion de faire ma première compil.

Cela étant… il ne s’agit pas (plus) d’ubuuntu mais de Debian V4.0r2 32 bits
Mais cela ne change rien je suppose (puisqu’il s’agit de la version v1.3.6 d’iptables)


UPDATE de mon post


Apres avoir DL iptables 1.4.0 chez netfilter, voici les indications du fichier d’install…
Je ne suis pas sur du path a spécifier ? est-ce /sbin ?

1) Next, make the package. % make KERNEL_DIR=<<where-you-built-your-kernel>>
Du coup il me faut “écrire” ? (j’ai le sentiment de dire une énorme c…)% make KERNEL_DIR=/sbin