J'ai un petit problème avec une règle d'iptable, pourtant ça m'a l'air
tout simple... Quoique, à la réflexion, ça vient peut-être de
l'application derrière.
J'ai une machine, derrière ma passerelle/firewall, que je veux utiliser
comme serveur de streaming (je peux pas utiliser ma passerelle pour ça,
parce qu'il faut que je fasse du resampling, et j'ai pas assez de cpu sur
la passerelle).
J'ai mis en place le serveur de streaming (gnump3d -- au fait, il permet
de faire exactement ce que j'arrivais pas à faire avec icecast/ices !) sur
la machine, il est accessible sur machine:8888 (avec une interface web).
Quand je suis sur ma passerelle, je fais, par exemple, links
http://machine:8888, nickel, je tombe bien là où il faut.
Maintenant, je voudrais que ce soit accessible de l'exterieur. Je mets
donc une règle de plus sur mon firewall, qui dit :
Donc, je me dis que à ce stade, un links http://passerelle.dyndns.org:888
devrait me renvoyer sur 10.0.0.3:8888. Ben non, ça marche pas...
J'ai vérifié, la règle est bien appliquée (en tout cas, listée par
iptables -t nat -L), et une connexion directe sur 10.0.0.3:8888 (depuis la
passerelle, forcément) marche aussi.
Alors je sais pas trop...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
vu sur des newsgroups : il faut aussi autoriser le forward.
pq? je sais pas, mais ca marchait chez moi. SI qq1 a une explication.
Ben, d'après ce que j'ai compris, une fois le premier paquet filtré par la première règle, les autres paquets vont arriver en tant que paquets forwardés. Donc si ta config, par défaut, refuse de forwarder des paquets sur 10.0.0.3, les paquets suivants (et p'têt même le premier) ne passeront pas.
Non !
Une petite explication simplifiée...
Mais quand même bien complète, je trouve... enfin, par rapport à ce que je connais pour l'instant ! :-)
Donc, il faut trois règles pour faire de la DNAT : - une de nat en PREROUTING, - une règle de filtre en FORWARD pour le sens client-serveur, - une règle de filtre en FORWARD pour le sens serveur-client (cette dernière est souvent globale).
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est parce que je ne parlais que des paquets entrants, et pas des paquets sortants (dans le sens serveur-client, donc) ? Ou alors c'est parce qu'on parlait que du forward client-serveur, et pas du forward serveur-client ?
C'est pas pour le plaisir d'avoir le dernier mot que je dis ça, mais juste qu'il y a quelque chose que je ne dois pas comprendre comme il faut, et j'aimerais savoir quoi... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Thu, 8 Jul 2004, Julien Salgado wrote:
vu sur des newsgroups : il faut aussi autoriser le forward.
pq? je sais pas, mais ca marchait chez moi.
SI qq1 a une explication.
Ben, d'après ce que j'ai compris, une fois le premier paquet filtré par la
première règle, les autres paquets vont arriver en tant que paquets
forwardés. Donc si ta config, par défaut, refuse de forwarder des paquets
sur 10.0.0.3, les paquets suivants (et p'têt même le premier) ne passeront
pas.
Non !
Une petite explication simplifiée...
Mais quand même bien complète, je trouve... enfin, par rapport à ce que je
connais pour l'instant ! :-)
Donc, il faut trois règles pour faire de la DNAT :
- une de nat en PREROUTING,
- une règle de filtre en FORWARD pour le sens client-serveur,
- une règle de filtre en FORWARD pour le sens serveur-client (cette
dernière est souvent globale).
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais
était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est parce que je ne parlais que des paquets entrants, et pas des paquets
sortants (dans le sens serveur-client, donc) ? Ou alors c'est parce qu'on
parlait que du forward client-serveur, et pas du forward serveur-client ?
C'est pas pour le plaisir d'avoir le dernier mot que je dis ça, mais juste
qu'il y a quelque chose que je ne dois pas comprendre comme il faut, et
j'aimerais savoir quoi...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
vu sur des newsgroups : il faut aussi autoriser le forward.
pq? je sais pas, mais ca marchait chez moi. SI qq1 a une explication.
Ben, d'après ce que j'ai compris, une fois le premier paquet filtré par la première règle, les autres paquets vont arriver en tant que paquets forwardés. Donc si ta config, par défaut, refuse de forwarder des paquets sur 10.0.0.3, les paquets suivants (et p'têt même le premier) ne passeront pas.
Non !
Une petite explication simplifiée...
Mais quand même bien complète, je trouve... enfin, par rapport à ce que je connais pour l'instant ! :-)
Donc, il faut trois règles pour faire de la DNAT : - une de nat en PREROUTING, - une règle de filtre en FORWARD pour le sens client-serveur, - une règle de filtre en FORWARD pour le sens serveur-client (cette dernière est souvent globale).
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est parce que je ne parlais que des paquets entrants, et pas des paquets sortants (dans le sens serveur-client, donc) ? Ou alors c'est parce qu'on parlait que du forward client-serveur, et pas du forward serveur-client ?
C'est pas pour le plaisir d'avoir le dernier mot que je dis ça, mais juste qu'il y a quelque chose que je ne dois pas comprendre comme il faut, et j'aimerais savoir quoi... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Julien Salgado
Remi Moyen a écrit :
Donc, il faut trois règles pour faire de la DNAT : - une de nat en PREROUTING, - une règle de filtre en FORWARD pour le sens client-serveur, - une règle de filtre en FORWARD pour le sens serveur-client (cette dernière est souvent globale).
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est sur le à peu près que je tique... ;) Je sais, je suis ch**nt. Mais c'est vrai que « Non ! » était un peu trop fort.
Ben, d'après ce que j'ai compris, une fois le premier paquet filtré par la première règle, les autres paquets vont arriver en tant que paquets forwardés.
Tous les paquets seront forwardés le premier comme les autres. Le premier paquet n'est pas filtré (en fait si, mais dans le sens dans lequel on l'entend habituellement), par la règle de NAT, il est modifié. Ce sont les règles en FORWARD qui filtrent.
Donc si ta config, par défaut, refuse de forwarder des paquets sur 10.0.0.3, les paquets suivants (et p'têt même le premier) ne passeront pas.
Là, c'est bon, puisque tous les paquets (y compris le premier) ne passeront que si ils sont autorisés en FORWARD.
C'est parce que je ne parlais que des paquets entrants, et pas des paquets sortants (dans le sens serveur-client, donc) ? Ou alors c'est parce qu'on parlait que du forward client-serveur, et pas du forward serveur-client ?
C'est pas pour le plaisir d'avoir le dernier mot que je dis ça, mais juste qu'il y a quelque chose que je ne dois pas comprendre comme il faut, et j'aimerais savoir quoi...
-- Julien
Remi Moyen a écrit :
Donc, il faut trois règles pour faire de la DNAT :
- une de nat en PREROUTING,
- une règle de filtre en FORWARD pour le sens client-serveur,
- une règle de filtre en FORWARD pour le sens serveur-client (cette
dernière est souvent globale).
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais
était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est sur le à peu près que je tique... ;) Je sais, je suis ch**nt.
Mais c'est vrai que « Non ! » était un peu trop fort.
Ben, d'après ce que j'ai compris, une fois le premier paquet filtré
par la première règle, les autres paquets vont arriver en tant que
paquets forwardés.
Tous les paquets seront forwardés le premier comme les autres.
Le premier paquet n'est pas filtré (en fait si, mais dans le sens dans
lequel on l'entend habituellement), par la règle de NAT, il est modifié.
Ce sont les règles en FORWARD qui filtrent.
Donc si ta config, par défaut, refuse de forwarder des paquets sur
10.0.0.3, les paquets suivants (et p'têt même le premier) ne
passeront pas.
Là, c'est bon, puisque tous les paquets (y compris le premier) ne
passeront que si ils sont autorisés en FORWARD.
C'est parce que je ne parlais que des paquets entrants, et pas des
paquets sortants (dans le sens serveur-client, donc) ? Ou alors c'est
parce qu'on parlait que du forward client-serveur, et pas du forward
serveur-client ?
C'est pas pour le plaisir d'avoir le dernier mot que je dis ça, mais
juste qu'il y a quelque chose que je ne dois pas comprendre comme il
faut, et j'aimerais savoir quoi...
Donc, il faut trois règles pour faire de la DNAT : - une de nat en PREROUTING, - une règle de filtre en FORWARD pour le sens client-serveur, - une règle de filtre en FORWARD pour le sens serveur-client (cette dernière est souvent globale).
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est sur le à peu près que je tique... ;) Je sais, je suis ch**nt. Mais c'est vrai que « Non ! » était un peu trop fort.
Ben, d'après ce que j'ai compris, une fois le premier paquet filtré par la première règle, les autres paquets vont arriver en tant que paquets forwardés.
Tous les paquets seront forwardés le premier comme les autres. Le premier paquet n'est pas filtré (en fait si, mais dans le sens dans lequel on l'entend habituellement), par la règle de NAT, il est modifié. Ce sont les règles en FORWARD qui filtrent.
Donc si ta config, par défaut, refuse de forwarder des paquets sur 10.0.0.3, les paquets suivants (et p'têt même le premier) ne passeront pas.
Là, c'est bon, puisque tous les paquets (y compris le premier) ne passeront que si ils sont autorisés en FORWARD.
C'est parce que je ne parlais que des paquets entrants, et pas des paquets sortants (dans le sens serveur-client, donc) ? Ou alors c'est parce qu'on parlait que du forward client-serveur, et pas du forward serveur-client ?
C'est pas pour le plaisir d'avoir le dernier mot que je dis ça, mais juste qu'il y a quelque chose que je ne dois pas comprendre comme il faut, et j'aimerais savoir quoi...
-- Julien
Remi Moyen
On Thu, 8 Jul 2004, Julien Salgado wrote:
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est sur le à peu près que je tique... ;) Je sais, je suis ch**nt. Mais c'est vrai que « Non ! » était un peu trop fort.
Ah, si c'était juste du pinaillage, je dis rien, je suis moi-même spécialiste de la chose (sur des domaines que je maîtrise mieux...) :-)
('fin bon, je trouve qu'il vaut mieux trop précis que pas assez, alors, continue à pinailler ! :-) ) -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Thu, 8 Jul 2004, Julien Salgado wrote:
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais
était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est sur le à peu près que je tique... ;) Je sais, je suis ch**nt.
Mais c'est vrai que « Non ! » était un peu trop fort.
Ah, si c'était juste du pinaillage, je dis rien, je suis moi-même
spécialiste de la chose (sur des domaines que je maîtrise mieux...) :-)
('fin bon, je trouve qu'il vaut mieux trop précis que pas assez, alors,
continue à pinailler ! :-) )
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Mais... Je pige pas pourquoi tu dis "Non !" plus haut. Ce que je disais était à peu près (et en infiniment plus simplifié) la même chose, non ?
C'est sur le à peu près que je tique... ;) Je sais, je suis ch**nt. Mais c'est vrai que « Non ! » était un peu trop fort.
Ah, si c'était juste du pinaillage, je dis rien, je suis moi-même spécialiste de la chose (sur des domaines que je maîtrise mieux...) :-)
('fin bon, je trouve qu'il vaut mieux trop précis que pas assez, alors, continue à pinailler ! :-) ) -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
A part quelques erreurs de syntaxe évidentes, par exemple celle-ci '-m state --state INPUT', et l'utilisation, pour charger les modules, de la commande 'insmod' aulieu de la commande 'modprobe' qui serait préférable, je trouve que le document aborde le sujet assez efficacement.
J'ai quand même relevé quelques erreurs (certes la critique est facile alors que l'art est difficile, air connu).
L'auteur emploie à plusieurs reprises un vocabulaire non conforme à la documentation de Netfilter et pouvant prêter à confusion, par exemple "règle" à la place de "chaîne" ou "instruction" à la place de "cible".
La suppression des chaînes utilisateur dans les tables "nat" et "mangle" a été oubliée.
La mention de la cible REJECT dans le paragraphe sur la politique par défaut est sans objet. Contrairement à ce qui se passe avec ipchains, REJECT ne peut pas être spécifiée comme politique par défaut avec iptables.
Dans le paragraphe sur la configuration du noyau, il n'est pas précisé que mettre rp_filter à 1 dans la branche net/conf/all n'est pas suffisant pour activer la vérification de l'adresse source : il faut aussi mettre rp_filter à 1 dans la branche de chaque interface concernée, d'où la boucle "for" qu'on retrouve dans de nombreux scripts.
Par contre la création de chaînes utilisateur spécifiques à chaque interface ou couple d'interfaces me plaît beaucoup. Normal, j'ai fait pareil ! J'ai dû un peu abuser avec les chaînes utilisateur, j'en compte 40 dans mon script d'initialisation...
A part quelques erreurs de syntaxe évidentes, par exemple celle-ci '-m
state --state INPUT', et l'utilisation, pour charger les modules, de la
commande 'insmod' aulieu de la commande 'modprobe' qui serait préférable, je
trouve que le document aborde le sujet assez efficacement.
J'ai quand même relevé quelques erreurs (certes la critique est facile
alors que l'art est difficile, air connu).
L'auteur emploie à plusieurs reprises un vocabulaire non conforme à la
documentation de Netfilter et pouvant prêter à confusion, par exemple
"règle" à la place de "chaîne" ou "instruction" à la place de "cible".
La suppression des chaînes utilisateur dans les tables "nat" et "mangle"
a été oubliée.
La mention de la cible REJECT dans le paragraphe sur la politique par
défaut est sans objet. Contrairement à ce qui se passe avec ipchains,
REJECT ne peut pas être spécifiée comme politique par défaut avec
iptables.
Dans le paragraphe sur la configuration du noyau, il n'est pas précisé
que mettre rp_filter à 1 dans la branche net/conf/all n'est pas
suffisant pour activer la vérification de l'adresse source : il faut
aussi mettre rp_filter à 1 dans la branche de chaque interface
concernée, d'où la boucle "for" qu'on retrouve dans de nombreux scripts.
Par contre la création de chaînes utilisateur spécifiques à chaque
interface ou couple d'interfaces me plaît beaucoup. Normal, j'ai fait
pareil ! J'ai dû un peu abuser avec les chaînes utilisateur, j'en compte
40 dans mon script d'initialisation...
A part quelques erreurs de syntaxe évidentes, par exemple celle-ci '-m state --state INPUT', et l'utilisation, pour charger les modules, de la commande 'insmod' aulieu de la commande 'modprobe' qui serait préférable, je trouve que le document aborde le sujet assez efficacement.
J'ai quand même relevé quelques erreurs (certes la critique est facile alors que l'art est difficile, air connu).
L'auteur emploie à plusieurs reprises un vocabulaire non conforme à la documentation de Netfilter et pouvant prêter à confusion, par exemple "règle" à la place de "chaîne" ou "instruction" à la place de "cible".
La suppression des chaînes utilisateur dans les tables "nat" et "mangle" a été oubliée.
La mention de la cible REJECT dans le paragraphe sur la politique par défaut est sans objet. Contrairement à ce qui se passe avec ipchains, REJECT ne peut pas être spécifiée comme politique par défaut avec iptables.
Dans le paragraphe sur la configuration du noyau, il n'est pas précisé que mettre rp_filter à 1 dans la branche net/conf/all n'est pas suffisant pour activer la vérification de l'adresse source : il faut aussi mettre rp_filter à 1 dans la branche de chaque interface concernée, d'où la boucle "for" qu'on retrouve dans de nombreux scripts.
Par contre la création de chaînes utilisateur spécifiques à chaque interface ou couple d'interfaces me plaît beaucoup. Normal, j'ai fait pareil ! J'ai dû un peu abuser avec les chaînes utilisateur, j'en compte 40 dans mon script d'initialisation...
