iptables pour le(s) nul(s)

OK, pour le -t (table), c'est le -j (target) que je ne comprenais pas
(what to do if the packet matches the rule). Et je ne comprends toujours
pas pourquoi il faut une target.

Ben, pour dire ce qu'il faut faire avec les paquets qui correspondent.

Si on veut ajouter quelque chose à la
table nat, c'est bien parce qu'on veut l'accepter, non ?

Non, pas forcément. En général oui, mais dans iptables c'est
indépendant. Un paquet entrant traverse plusieurs chaînes de plusieurs
tables ayant des fonctions différentes (modifier, NATer, filtrer) et
doit toutes les traverser pour ressortir.

En plus tu dis plus bas que de toutes façons le packet sera examiné par
la table filter...

La table nat NATe. La table filter filtre.
Tu es sûr que tu ne veux pas prendre le temps de lire un tutorial ?

J'ai ajouté ma règle avec -I et 'iptables -nvL -t nat' me l'affiche en
premier.

Encore heureux, c'est le but. :-)

Par contre elle est toujours affiché *exactement* de la même manière
après avoir remplacé le -I par -D dans la ligne de commande. C'est à
dire que je n'arrive pas à détruire cette règle.

Bizarre. Pas de message d'erreur ? Et si tu répètes la suppression ?

Le 17 Oct 2007 16:08:07 GMT, Nicolas KOWALSKI a écrit:

In article <slrnfhcb70.60d.hugolino@deborah.rock-n-roll.org> you wrote:

En fait je ne comprenais pas car quand je ne suis pas chez moi, je
suis sous Windows© avec un putty.

Comme l'écrit Nina, ça marche tout aussi bien avec putty.

Oui, mais elle explique pas... :)

Category->Connection->SSH->Tunnels:

"Add new Forwarded port":

source port: 8080
destination: 192.168.1.1:80

-> Cliquer sur "Add".

Revenir à Category->Session, et sauvegarder la session histoire de ne
pas tout refaire à chaque fois.

Saint clou: ça rocks !!!



--
Windows: Taxe pour les analphabètes de l'informatique.
Hugo (né il y a 1 372 092 057 secondes)

Le Wed, 17 Oct 2007 17:56:49 +0200, Nina Popravka a écrit:

On Wed, 17 Oct 2007 17:40:16 +0200, Hugolino <hugolino@free.fr> wrote:

Il faudrait que je trouve un outil windowsesque pour faire ça, si putty
peut pas.

Oops...
Je m'aperçois que j'ai oublié de répondre à Nina. (on a qu'une seule
<a href="http://tinyurl.com/2lfvln">nana</a>, faut qu'on la soigne :)

Toute implémentation de ssh le fait, quelque soit la plate forme. Ca
s'appelle un tunnel.

Tunnel: encore un nouveau mot. (ça fait 42 pile-poil...)

Putty le fait évidemment.

Ça n'a rien d'évident pour un n00b en rézal.

Suffit de lire la doc.

Merde, une 'tégisse.

Et si ça te gêne à ce point d'avoir une interface graphique pour ssh,

Non.

y a plein d'implémentations en cli sous win, celle de cygwin en tête.

Que je n'ai pas réussi à installer sur mon win98se pourtant fraichement
(pas plus de 3 ans à ce qu'il me semble) réinstallé.


Merci à toi.


--

Ne pas installer Windows, c'est déjà s'y connaître...
Hugo (né il y a 1 372 102 795 secondes)

Le Wed, 17 Oct 2007 20:32:36 +0200, Pascal Hambourg a écrit:

OK, pour le -t (table), c'est le -j (target) que je ne comprenais pas
(what to do if the packet matches the rule). Et je ne comprends toujours
pas pourquoi il faut une target.

Ben, pour dire ce qu'il faut faire avec les paquets qui correspondent.

OK, alors je le dis dans l'autre sens, à partir du moment ou la target
est DNAT, pourquoi dire à iptables d'écrire la règle dans la table nat.
Y-a-t'il un cas où on pourrait écrire du DNAT dans la table filter par
exemple ?

Si on veut ajouter quelque chose à la table nat, c'est bien parce
qu'on veut l'accepter, non ?

Non, pas forcément. [...]

Exemple ?

[...] En général oui, mais dans iptables c'est indépendant. Un paquet
entrant traverse plusieurs chaînes de plusieurs tables ayant des
fonctions différentes (modifier, NATer, filtrer) et doit toutes les
traverser pour ressortir.

C'est la philosopie «je ferme tout, avant d'ouvrir ce que je veux», non ?

En plus tu dis plus bas que de toutes façons le packet sera examiné
par la table filter...

La table nat NATe. La table filter filtre.
Tu es sûr que tu ne veux pas prendre le temps de lire un tutorial ?

J'ai déjà *lu* le tutorial, il y a plein de choses intéressantes dedans
et iptables a l'air très puissant, mais du coup j'ai peur de faire des
bétises et il faudrait que je monte une machine de test, c'est surtout
ça qui va prendre du temps.
Et puis si je trouve le temps de le faire, je reviendrais avec une tonne
de questions supplémentaires, alors ne crois pas que tu (c'est toujours
toi qui répond sur les problème de routage) va t'en tirer à si bon
compte :)

J'ai ajouté ma règle avec -I et 'iptables -nvL -t nat' me l'affiche
en premier.

Encore heureux, c'est le but. :-)

Tu confirmes qu'une fois qu'un paquet à matché une règle, il n'est pas
examiné par les autres règles de la table ?
(Désolé, je suis en plein déménagement et ma doc d'olivieraj est dans
un carton).

Par contre elle est toujours affiché *exactement* de la même manière
après avoir remplacé le -I par -D dans la ligne de commande. C'est à
dire que je n'arrive pas à détruire cette règle.

Bizarre. Pas de message d'erreur ?

Nope. Le tux qui tourne dans la box à l'air assez frustre.

Et si tu répètes la suppression ?

Je l'ai fait plusieurs fois sans succès, obligé de rebooter la box.
(Nicolas avait raison en disant que les règles saisies par telnet
n'était pas sauvegardées, fort heureusement d'ailleurs)


Merci pour ta patience.

--
«Comme annoncé dans fr.usenet.forums.annonces récemment, le vote pour
la destruction/remplacement du groupe fr.comp.os.linux a reussi
et est donc detruit.»
-+- Control in Guide du linuxien pervers - "BSD a encore frappé" -+-

Le Wed, 17 Oct 2007 17:56:49 +0200, Nina Popravka a écrit:

On Wed, 17 Oct 2007 17:40:16 +0200, Hugolino <hugolino@free.fr> wrote:

Il faudrait que je trouve un outil windowsesque pour faire ça, si putty
peut pas.

Oops...
Je m'aperçois que j'ai oublié de répondre à Nina. (on a qu'une seule
<a href="http://tinyurl.com/2lfvln">nana</a>, faut qu'on la soigne :)

Toute implémentation de ssh le fait, quelque soit la plate forme. Ca
s'appelle un tunnel.

Tunnel: encore un nouveau mot. (ça fait 42 pile-poil...)

Putty le fait évidemment.

Ça n'a rien d'évident pour un n00b en rézal.

Suffit de lire la doc.

Merde, une 'tégrisse.

Et si ça te gêne à ce point d'avoir une interface graphique pour ssh,

Non.

y a plein d'implémentations en cli sous win, celle de cygwin en tête.

Que je n'ai pas réussi à installer sur mon win98se pourtant fraichement
(pas plus de 3 ans à ce qu'il me semble) réinstallé.


Merci à toi.


--

Ne pas installer Windows, c'est déjà s'y connaître...
Hugo (né il y a 1 372 102 795 secondes)

OK, alors je le dis dans l'autre sens, à partir du moment ou la target
est DNAT, pourquoi dire à iptables d'écrire la règle dans la table nat.

Parce que c'est comme ça. On spécifie la table, la chaîne et la cible,
et iptables vérifie que la table existe, que la chaîne existe dans cette
table et que l'usage de la cible est valide dans cette chaîne de cette
table.

Y-a-t'il un cas où on pourrait écrire du DNAT dans la table filter par
exemple ?

Non, ce n'est pas permis.

Si on veut ajouter quelque chose à la table nat, c'est bien parce
qu'on veut l'accepter, non ?

Non, pas forcément. [...]

Exemple ?

Je n'en ai pas en tête. Mais il faut bien comprendre qu'iptables c'est
du bas niveau donc il faut tout lui dire, et que chaque chaîne et chaque
table est indépendante. Il y a des firewalls de plus haut niveau
(front-ends d'iptables en fait) qui vont créer toutes les règles
iptables nécessaires pour une règle de haut niveau.

[...] En général oui, mais dans iptables c'est indépendant. Un paquet
entrant traverse plusieurs chaînes de plusieurs tables ayant des
fonctions différentes (modifier, NATer, filtrer) et doit toutes les
traverser pour ressortir.

C'est la philosopie «je ferme tout, avant d'ouvrir ce que je veux», non ?

Non, rien à voir. L'approche «je ferme tout, avant d'ouvrir ce que je
veux» ou l'inverse dépend de la politique par défaut des chaînes,
c'est-à-dire l'action lorsque le paquet ne correspond à aucune règle de
la chaîne, or celle-ci est initialement ACCEPT.

On va prendre un exemple concret. Un paquet qui traverse un routeur
passe dans l'ordre par les chaînes suivantes :
(le paquet arrive sur l'interface d'entrée)
- chaîne PREROUTING de la table raw
- chaîne PREROUTING de la table mangle
- chaîne PREROUTING de la table nat s'il crée une connexion
(là il y a la décision de routage)
- chaîne FORWARD de la table mangle
- chaîne FORWARD de la table filter
- chaîne FORWARD de la table mangle
- chaîne POSTROUTING de la table mangle
- chaîne POSTROUTING de la table nat s'il crée une connexion
(le paquet part par l'interface de sortie)

Chacune de ces chaînes a une politique par défaut ACCEPT ou DROP,
indépendamment des autres chaînes. Initialement, toutes les chaînes ont
leur politique par défaut à ACCEPT donc c'est plutôt "on accepte tout
par défaut". Il n'y a pas vraiment de raison de changer la politique par
défaut des chaînes des tables mangle et nat en DROP ; on le fait sur les
trois chaînes de la table filter pour mettre en place la politique "on
bloque tout par défaut", sachant que tout paquet doit traverser
forcément une et une seule chaîne de la table filter quelles que soient
son origine et sa destination.

Tu confirmes qu'une fois qu'un paquet à matché une règle, il n'est pas
examiné par les autres règles de la table ?

De la chaîne, pas de la table.
Ça dépend de la cible. Il y a principalement deux catégories de cibles,
les "terminales" et les "non terminales". Si la cible est terminale
(ACCEPT, DROP, la majorité des cibles spécifiques aux tables filter et
nat comme REJECT, DNAT...) la traversée de la chaîne est terminée. Mais
cela n'empêche pas le paquet d'être examiné par les règles des chaînes
suivantes, sauf bien sûr si la cible a détruit le paquet (DROP, REJECT).
Si la cible est non terminale (LOG, les cibles spécifiques à la table
mangle comme MARK, TCPMSS...), le paquet continue à être examiné par les
règles suivantes de la chaîne.

Par contre elle est toujours affiché *exactement* de la même manière
après avoir remplacé le -I par -D dans la ligne de commande. C'est à
dire que je n'arrive pas à détruire cette règle.

Bizarre. Pas de message d'erreur ?

Nope. Le tux qui tourne dans la box à l'air assez frustre.

Pas une raison pour ne pas afficher les erreurs...

Et si tu répètes la suppression ?

Je l'ai fait plusieurs fois sans succès, obligé de rebooter la box.

Surprenant. Et en essayant de la supprimer par son numéro (syntaxe :
iptables -t <table> -D <CHAINE> <numero>) ?

(Nicolas avait raison en disant que les règles saisies par telnet
n'était pas sauvegardées, fort heureusement d'ailleurs)

Par défaut les règles iptables sont volatiles. Il faut explicitement les
sauvegarder avant l'arrêt (avec iptables-save) puis les restaurer après
le redémarrage (avec iptables-restore) pour qu'elles soient conservées.
Certaines distributions ont des scripts de démarrage/arrêt qui font ça
sous le contrôle d'une option.

Le Thu, 18 Oct 2007 12:21:45 +0200, Pascal Hambourg a écrit:

OK, alors je le dis dans l'autre sens, à partir du moment ou la target
est DNAT, pourquoi dire à iptables d'écrire la règle dans la table nat.

Parce que c'est comme ça.

OK, (et j'ai lu ton commentaire sur le "bas niveau de iptables")

[...]

C'est la philosopie «je ferme tout, avant d'ouvrir ce que je veux», non ?

Non, rien à voir.

[snip le petit résumé du focntionnement interne]

Tu confirmes qu'une fois qu'un paquet à matché une règle, il n'est pas
examiné par les autres règles de la table ?

De la chaîne, pas de la table.

OK, mais qu'appelles-tu une chaîne ?

paquet (packet): OK, ce qui arrive,
règle (rule): OK, ce qu'on a écrit à l'aide commande iptables,
cible (target): OK (grâce à ton résumé),

man iptables: «Each chain is a list of rules which can match a set of
packets. Each rule specifies what to do with a packet that matches. This
is called a `target', which may be a jump to a user-defined chain in the
same table.»

Donc: «Une chaîne est une liste de règles applicables à un (set ?) de
paquets Une règle dit quoi faire d'un paquet qui marche...»

Et là je coince, je ne comprends pas ce que désigne "This"...
Avant que tu ne définisse ce qu'est une cible, j'aurais cru comprendre
qu'il définissait une "cible" comme un synomyme de "chaîne"

[cut la definition de cible]

C'est à dire que je n'arrive pas à détruire cette règle.
[...]

Et si tu répètes la suppression ?

Je l'ai fait plusieurs fois sans succès, obligé de rebooter la box.

Surprenant. Et en essayant de la supprimer par son numéro (syntaxe :
iptables -t <table> -D <CHAINE> <numero>) ?

Dès que je saurais ce qu'est une chaîne et que je saurais demander
l'affichage des numéros de règle par iptables, j'essayerais.


Merci encore de partager ton savoir.


--

Bon mon LFS ça sera pas encore pour aujourd'hui... demain je réinstalle
LFS a une grande qualité, c'est que l'envie de réinstaller toutes les 5

minutes passe vite.

OK, mais qu'appelles-tu une chaîne ?

paquet (packet): OK, ce qui arrive,
règle (rule): OK, ce qu'on a écrit à l'aide commande iptables,
cible (target): OK (grâce à ton résumé),

man iptables: «Each chain is a list of rules

Voilà. Une liste de règles parcourues séquentiellement qui examinent les
paquets qui la traversent.

which can match a set of packets.

Ceci s'applique aux règles.

Each rule specifies what to do with a packet that matches. This
is called a `target', which may be a jump to a user-defined chain in the
same table.»

Donc: «Une chaîne est une liste de règles applicables à un (set ?) de

set = ensemble

paquets Une règle dit quoi faire d'un paquet qui marche...»

"Qui correspond" (matches), pas "qui marche".

Et là je coince, je ne comprends pas ce que désigne "This"...

"This" désigne "what to do with a packet that matches", ce qu'il faut
faire d'un paquet qui correspond.

Avant que tu ne définisse ce qu'est une cible, j'aurais cru comprendre
qu'il définissait une "cible" comme un synomyme de "chaîne"

Ah non, ce sont deux choses très différentes. La cible, c'est juste
l'action. La règle, c'est la combinaison de conditions de correspondance
et d'une cible.

Surprenant. Et en essayant de la supprimer par son numéro (syntaxe :
iptables -t <table> -D <CHAINE> <numero>) ?

Dès que je saurais ce qu'est une chaîne

PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING ainsi que les chaînes
utilisateur créés par iptables -N. Les règles de redirection de port qui
t'intéressent sont dans la chaîne PREROUTING de la table nat.

et que je saurais demander
l'affichage des numéros de règle par iptables, j'essayerais.

Avec l'option --line-numbers.