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.
iptables -A FORWARD -d 10.0.0.3 -j ACCEPT
pq? je sais pas, mais ca marchait chez moi. SI qq1 a une explication.
Arnaud
Remi Moyen wrote:
Salut,
Bonjour,
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.
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.
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.
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.
En vrac et non exhaustivement. L'interface côté internet est bien eth0 ? Les règles FORWARD correspondantes sont-elles en place dans les deux sens ? La machine en question a-t-elle bien la route par défaut vers la passerelle pour les paquets en réponse ?
Remi Moyen wrote:
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.
En vrac et non exhaustivement.
L'interface côté internet est bien eth0 ?
Les règles FORWARD correspondantes sont-elles en place dans les deux
sens ?
La machine en question a-t-elle bien la route par défaut vers la
passerelle pour les paquets en réponse ?
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.
En vrac et non exhaustivement. L'interface côté internet est bien eth0 ? Les règles FORWARD correspondantes sont-elles en place dans les deux sens ? La machine en question a-t-elle bien la route par défaut vers la passerelle pour les paquets en réponse ?
news
Annie D. wrote:
En vrac et non exhaustivement. L'interface côté internet est bien eth0 ? Les règles FORWARD correspondantes sont-elles en place dans les deux sens ? La machine en question a-t-elle bien la route par défaut vers la passerelle pour les paquets en réponse ?
Est-ce qu'il serait possible d'avoir une explication? qu'est-ce qui passe par le FORWARD? Est-ce que c'est juste ce qui a ete preroute? En clair : est-ce que si je fais ca pour que mes amis voient ma webcam sur le port zzzz, est-ce que je risque pas de laisser entrer tout le monde? (en pratique j'ai pris soin de n'autoriser que les ips connues, mais bon dans le cas general?)
Annie D. wrote:
En vrac et non exhaustivement.
L'interface côté internet est bien eth0 ?
Les règles FORWARD correspondantes sont-elles en place dans les deux
sens ?
La machine en question a-t-elle bien la route par défaut vers la
passerelle pour les paquets en réponse ?
Est-ce qu'il serait possible d'avoir une explication?
qu'est-ce qui passe par le FORWARD? Est-ce que c'est juste ce qui a ete
preroute? En clair : est-ce que si je fais ca pour que mes amis voient
ma webcam sur le port zzzz, est-ce que je risque pas de laisser entrer
tout le monde? (en pratique j'ai pris soin de n'autoriser que les ips
connues, mais bon dans le cas general?)
En vrac et non exhaustivement. L'interface côté internet est bien eth0 ? Les règles FORWARD correspondantes sont-elles en place dans les deux sens ? La machine en question a-t-elle bien la route par défaut vers la passerelle pour les paquets en réponse ?
Est-ce qu'il serait possible d'avoir une explication? qu'est-ce qui passe par le FORWARD? Est-ce que c'est juste ce qui a ete preroute? En clair : est-ce que si je fais ca pour que mes amis voient ma webcam sur le port zzzz, est-ce que je risque pas de laisser entrer tout le monde? (en pratique j'ai pris soin de n'autoriser que les ips connues, mais bon dans le cas general?)
Franck
news wrote:
Est-ce qu'il serait possible d'avoir une explication?
En fait, il faut faire la distinction entre la translation de ports/d'adresses et le filtrage :
La translation de port et/ou adresse se fait dans la table "nat" : La chaine PREROUTING est parcourue avant que la décision de routage du paquet soit prise : C'est donc dans cette chaine qu'on change la destination d'un paquet (DNAT), afin que la route correcte soit ensuite déterminée. A l'opposé, lorsque l'on change la source d'un paquet (SNAT ou MASQUERADE), on le fait une fois la route (et donc l'interface de sortie) déterminée, c'est à dire dans la chaine POSTROUTING.
Ensuite le filtrage : Il est indépendant de l'étape précédente et a lieu dans la table "filter" (qui est la table par défaut, si non précisée, pour la commande iptables). Dans le filtrage, on voit les adresses/port source et destination réelles, après avoir été "natées". Dans ce qui suit je vais appeler "ROUTEUR" la machine qui effectue le filtrage :
- Si un paquet a pour destination finale le ROUTEUR (par exemple un serveur web qui serait sur le routeur), alors elle passe par la chaine INPUT de la table filter - Si un paquet a pour source initiale le ROUTEUR (par exemple une personne logguée sur le routeur lance un wget), alors elle passe par la chaine OUTPUT de la table filter - Dans tous les autres cas, le paquet passe par la table FORWARD.
Dans le cas d'une translation d'adresse (DNAT), la source n'est pas le routeur. La destination réelle après translation n'est pas le routeur non plus (c'est la machine du lan typiquement) : Donc les paquets passeront pas la chaine FORWARD.
news wrote:
Est-ce qu'il serait possible d'avoir une explication?
En fait, il faut faire la distinction entre la translation de
ports/d'adresses et le filtrage :
La translation de port et/ou adresse se fait dans la table "nat" : La chaine
PREROUTING est parcourue avant que la décision de routage du paquet soit
prise : C'est donc dans cette chaine qu'on change la destination d'un paquet
(DNAT), afin que la route correcte soit ensuite déterminée. A l'opposé,
lorsque l'on change la source d'un paquet (SNAT ou MASQUERADE), on le fait
une fois la route (et donc l'interface de sortie) déterminée, c'est à dire
dans la chaine POSTROUTING.
Ensuite le filtrage : Il est indépendant de l'étape précédente et a lieu
dans la table "filter" (qui est la table par défaut, si non précisée, pour
la commande iptables). Dans le filtrage, on voit les adresses/port source et
destination réelles, après avoir été "natées". Dans ce qui suit je vais
appeler "ROUTEUR" la machine qui effectue le filtrage :
- Si un paquet a pour destination finale le ROUTEUR (par exemple un serveur
web qui serait sur le routeur), alors elle passe par la chaine INPUT de la
table filter
- Si un paquet a pour source initiale le ROUTEUR (par exemple une personne
logguée sur le routeur lance un wget), alors elle passe par la chaine OUTPUT
de la table filter
- Dans tous les autres cas, le paquet passe par la table FORWARD.
Dans le cas d'une translation d'adresse (DNAT), la source n'est pas le
routeur. La destination réelle après translation n'est pas le routeur non
plus (c'est la machine du lan typiquement) : Donc les paquets passeront pas
la chaine FORWARD.
Est-ce qu'il serait possible d'avoir une explication?
En fait, il faut faire la distinction entre la translation de ports/d'adresses et le filtrage :
La translation de port et/ou adresse se fait dans la table "nat" : La chaine PREROUTING est parcourue avant que la décision de routage du paquet soit prise : C'est donc dans cette chaine qu'on change la destination d'un paquet (DNAT), afin que la route correcte soit ensuite déterminée. A l'opposé, lorsque l'on change la source d'un paquet (SNAT ou MASQUERADE), on le fait une fois la route (et donc l'interface de sortie) déterminée, c'est à dire dans la chaine POSTROUTING.
Ensuite le filtrage : Il est indépendant de l'étape précédente et a lieu dans la table "filter" (qui est la table par défaut, si non précisée, pour la commande iptables). Dans le filtrage, on voit les adresses/port source et destination réelles, après avoir été "natées". Dans ce qui suit je vais appeler "ROUTEUR" la machine qui effectue le filtrage :
- Si un paquet a pour destination finale le ROUTEUR (par exemple un serveur web qui serait sur le routeur), alors elle passe par la chaine INPUT de la table filter - Si un paquet a pour source initiale le ROUTEUR (par exemple une personne logguée sur le routeur lance un wget), alors elle passe par la chaine OUTPUT de la table filter - Dans tous les autres cas, le paquet passe par la table FORWARD.
Dans le cas d'une translation d'adresse (DNAT), la source n'est pas le routeur. La destination réelle après translation n'est pas le routeur non plus (c'est la machine du lan typiquement) : Donc les paquets passeront pas la chaine FORWARD.
Au passage, je suis tombé sur ça : http://okki666.free.fr/docmaster/articles/linux128.html qui cause d'iptables d'une manière que, miracle !, pour une fois j'arrive à comprendre et correspond au genre de choses que je veux faire. Est-ce que quelqu'un qui s'y connait pourrait jeter un oeil pour me dire si il ne raconte pas de trop grosses conneries (autant je suis capable de vérifier si une syntaxe est bonne ou pas, et de voir ce qu'elle fait, autant je suis loin de maîtriser suffisamment les aspects réseau mis en jeu pour savoir si il oublie pas des trucs évidents, par exemple) ?
En tout cas, merci quand même d'avoir regardé mon problème... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Au passage, je suis tombé sur ça :
http://okki666.free.fr/docmaster/articles/linux128.html
qui cause d'iptables d'une manière que, miracle !, pour une fois j'arrive
à comprendre et correspond au genre de choses que je veux faire. Est-ce
que quelqu'un qui s'y connait pourrait jeter un oeil pour me dire si il ne
raconte pas de trop grosses conneries (autant je suis capable de vérifier
si une syntaxe est bonne ou pas, et de voir ce qu'elle fait, autant je
suis loin de maîtriser suffisamment les aspects réseau mis en jeu pour
savoir si il oublie pas des trucs évidents, par exemple) ?
En tout cas, merci quand même d'avoir regardé mon problème...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Au passage, je suis tombé sur ça : http://okki666.free.fr/docmaster/articles/linux128.html qui cause d'iptables d'une manière que, miracle !, pour une fois j'arrive à comprendre et correspond au genre de choses que je veux faire. Est-ce que quelqu'un qui s'y connait pourrait jeter un oeil pour me dire si il ne raconte pas de trop grosses conneries (autant je suis capable de vérifier si une syntaxe est bonne ou pas, et de voir ce qu'elle fait, autant je suis loin de maîtriser suffisamment les aspects réseau mis en jeu pour savoir si il oublie pas des trucs évidents, par exemple) ?
En tout cas, merci quand même d'avoir regardé mon problème... -- 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.
iptables -A FORWARD -d 10.0.0.3 -j ACCEPT
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.
Enfin, je crois... (p'tain, depuis le temps que je capte que dalle aux règles de firewall, voilà-t-y pas que j'ai l'air de piger ce que je fais !) -- 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.
iptables -A FORWARD -d 10.0.0.3 -j ACCEPT
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.
Enfin, je crois...
(p'tain, depuis le temps que je capte que dalle aux règles de firewall,
voilà-t-y pas que j'ai l'air de piger ce que je fais !)
--
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.
iptables -A FORWARD -d 10.0.0.3 -j ACCEPT
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.
Enfin, je crois... (p'tain, depuis le temps que je capte que dalle aux règles de firewall, voilà-t-y pas que j'ai l'air de piger ce que je fais !) -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
news
Franck wrote:
news wrote:
Est-ce qu'il serait possible d'avoir une explication?
En fait, il faut faire la distinction entre la translation de ports/d'adresses et le filtrage : <snip>
Merci!
Franck wrote:
news wrote:
Est-ce qu'il serait possible d'avoir une explication?
En fait, il faut faire la distinction entre la translation de
ports/d'adresses et le filtrage :
<snip>
Est-ce qu'il serait possible d'avoir une explication?
En fait, il faut faire la distinction entre la translation de ports/d'adresses et le filtrage : <snip>
Merci!
TiChou
Dans le message <news:, *Remi Moyen* tapota sur f.c.o.l.configuration :
Au passage, je suis tombé sur ça : http://okki666.free.fr/docmaster/articles/linux128.html qui cause d'iptables d'une manière que, miracle !, pour une fois j'arrive à comprendre et correspond au genre de choses que je veux faire. Est-ce que quelqu'un qui s'y connait pourrait jeter un oeil pour me dire si il ne raconte pas de trop grosses conneries (autant je suis capable de vérifier si une syntaxe est bonne ou pas, et de voir ce qu'elle fait, autant je suis loin de maîtriser suffisamment les aspects réseau mis en jeu pour savoir si il oublie pas des trucs évidents, par exemple) ?
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.
-- TiChou
Dans le message
<news:Pine.LNX.4.58.0407081411370.1457@pbeanf.raft.vacy-anapl.se>,
*Remi Moyen* tapota sur f.c.o.l.configuration :
Au passage, je suis tombé sur ça :
http://okki666.free.fr/docmaster/articles/linux128.html
qui cause d'iptables d'une manière que, miracle !, pour une fois j'arrive
à comprendre et correspond au genre de choses que je veux faire. Est-ce
que quelqu'un qui s'y connait pourrait jeter un oeil pour me dire si il ne
raconte pas de trop grosses conneries (autant je suis capable de vérifier
si une syntaxe est bonne ou pas, et de voir ce qu'elle fait, autant je
suis loin de maîtriser suffisamment les aspects réseau mis en jeu pour
savoir si il oublie pas des trucs évidents, par exemple) ?
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.
Dans le message <news:, *Remi Moyen* tapota sur f.c.o.l.configuration :
Au passage, je suis tombé sur ça : http://okki666.free.fr/docmaster/articles/linux128.html qui cause d'iptables d'une manière que, miracle !, pour une fois j'arrive à comprendre et correspond au genre de choses que je veux faire. Est-ce que quelqu'un qui s'y connait pourrait jeter un oeil pour me dire si il ne raconte pas de trop grosses conneries (autant je suis capable de vérifier si une syntaxe est bonne ou pas, et de voir ce qu'elle fait, autant je suis loin de maîtriser suffisamment les aspects réseau mis en jeu pour savoir si il oublie pas des trucs évidents, par exemple) ?
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.
vu sur des newsgroups : il faut aussi autoriser le forward.
iptables -A FORWARD -d 10.0.0.3 -j ACCEPT
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...
Le premier paquet dans le sens client serveur, va traverseri entre autre les chaines (en capital) et les tables (minuscule) suivantes : - PREROUTING/conntrack qui va faire l'entrée dans la table d'état avec l'état NEW - PREROUTING/nat (en fait nat_dst), qui modifie la table d'état en fonction de l'entrée faite grace à iptables et le paquet parce qu'il est dans l'état NEW. - FORWARD/filter, qui filtre....
Le deuxième paquet, dans le sens serveur client, va traverser entre autre : - PREROUTING/conntrack qui va mettre la table d'état dans l'état ESTABLISHED, - FORWARD/filter, qui filtre.... - POSTROUTING/nat (en fait nat_src), qui modifie le paquet en fonction de l'entrée dans la table d'état car la connexion est ESTABLISHED.
Ensuite les autre paquets dans le sens client-serveur font : - PREROUTING/conntrack qui ne fait que modifier la dernière date d'utilisation de l'entrée car la session est ESTABLISHED. - PREROUTING/nat (en fait nat_dst), qui modifie le paquet en fonction de l'entrée dans la table d'état car la connexion est ESTABLISHED. - FORWARD/filter, qui filtre....
Les autres paquets dans le sens serveur client vont traverser entre autre : - PREROUTING/conntrack qui ne fait que modifier la dernière date d'utilisation de l'entrée car la session est ESTABLISHED. - FORWARD/filter, qui filtre.... - POSTROUTING/nat (en fait nat_src), qui modifie le paquet en fonction de l'entrée dans la table d'état car la connexion est ESTABLISHED.
Maintenant, on ne modifier que les tables filter (par défaut) et nat. Dans le cas qui nous interesse on fait une modification de la table nat_dst qui est utilisée qu'une seule fois (pour le premier paquet). Ensuite les les opérations de NAT sont faites automatiquement. La modification de la table filter permet au paquet de passer la chaine FORWARD.
En résumé pratique : - les règles des tables de nat ne sont utilisée qu'une fois - les règles des tables filter sont utilisées à chaque fois, - un même paquet ne traverse au plus qu'une des chaines INPUT, OUTPUT et FORWARD.
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).
Enfin, je crois... (p'tain, depuis le temps que je capte que dalle aux règles de firewall, voilà-t-y pas que j'ai l'air de piger ce que je fais !)
vu sur des newsgroups : il faut aussi autoriser le forward.
iptables -A FORWARD -d 10.0.0.3 -j ACCEPT
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...
Le premier paquet dans le sens client serveur, va traverseri entre autre
les chaines (en capital) et les tables (minuscule) suivantes :
- PREROUTING/conntrack qui va faire l'entrée dans la table d'état avec
l'état NEW
- PREROUTING/nat (en fait nat_dst), qui modifie la table d'état en
fonction de l'entrée faite grace à iptables et le paquet parce qu'il
est dans l'état NEW.
- FORWARD/filter, qui filtre....
Le deuxième paquet, dans le sens serveur client, va traverser entre
autre :
- PREROUTING/conntrack qui va mettre la table d'état dans l'état
ESTABLISHED,
- FORWARD/filter, qui filtre....
- POSTROUTING/nat (en fait nat_src), qui modifie le paquet en fonction
de l'entrée dans la table d'état car la connexion est ESTABLISHED.
Ensuite les autre paquets dans le sens client-serveur font :
- PREROUTING/conntrack qui ne fait que modifier la dernière date
d'utilisation de l'entrée car la session est ESTABLISHED.
- PREROUTING/nat (en fait nat_dst), qui modifie le paquet en fonction de
l'entrée dans la table d'état car la connexion est ESTABLISHED.
- FORWARD/filter, qui filtre....
Les autres paquets dans le sens serveur client vont traverser entre
autre :
- PREROUTING/conntrack qui ne fait que modifier la dernière date
d'utilisation de l'entrée car la session est ESTABLISHED.
- FORWARD/filter, qui filtre....
- POSTROUTING/nat (en fait nat_src), qui modifie le paquet en fonction
de l'entrée dans la table d'état car la connexion est ESTABLISHED.
Maintenant, on ne modifier que les tables filter (par défaut) et nat.
Dans le cas qui nous interesse on fait une modification de la table
nat_dst qui est utilisée qu'une seule fois (pour le premier paquet).
Ensuite les les opérations de NAT sont faites automatiquement. La
modification de la table filter permet au paquet de passer la chaine
FORWARD.
En résumé pratique :
- les règles des tables de nat ne sont utilisée qu'une fois
- les règles des tables filter sont utilisées à chaque fois,
- un même paquet ne traverse au plus qu'une des chaines INPUT, OUTPUT et
FORWARD.
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).
Enfin, je crois...
(p'tain, depuis le temps que je capte que dalle aux règles de firewall,
voilà-t-y pas que j'ai l'air de piger ce que je fais !)
vu sur des newsgroups : il faut aussi autoriser le forward.
iptables -A FORWARD -d 10.0.0.3 -j ACCEPT
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...
Le premier paquet dans le sens client serveur, va traverseri entre autre les chaines (en capital) et les tables (minuscule) suivantes : - PREROUTING/conntrack qui va faire l'entrée dans la table d'état avec l'état NEW - PREROUTING/nat (en fait nat_dst), qui modifie la table d'état en fonction de l'entrée faite grace à iptables et le paquet parce qu'il est dans l'état NEW. - FORWARD/filter, qui filtre....
Le deuxième paquet, dans le sens serveur client, va traverser entre autre : - PREROUTING/conntrack qui va mettre la table d'état dans l'état ESTABLISHED, - FORWARD/filter, qui filtre.... - POSTROUTING/nat (en fait nat_src), qui modifie le paquet en fonction de l'entrée dans la table d'état car la connexion est ESTABLISHED.
Ensuite les autre paquets dans le sens client-serveur font : - PREROUTING/conntrack qui ne fait que modifier la dernière date d'utilisation de l'entrée car la session est ESTABLISHED. - PREROUTING/nat (en fait nat_dst), qui modifie le paquet en fonction de l'entrée dans la table d'état car la connexion est ESTABLISHED. - FORWARD/filter, qui filtre....
Les autres paquets dans le sens serveur client vont traverser entre autre : - PREROUTING/conntrack qui ne fait que modifier la dernière date d'utilisation de l'entrée car la session est ESTABLISHED. - FORWARD/filter, qui filtre.... - POSTROUTING/nat (en fait nat_src), qui modifie le paquet en fonction de l'entrée dans la table d'état car la connexion est ESTABLISHED.
Maintenant, on ne modifier que les tables filter (par défaut) et nat. Dans le cas qui nous interesse on fait une modification de la table nat_dst qui est utilisée qu'une seule fois (pour le premier paquet). Ensuite les les opérations de NAT sont faites automatiquement. La modification de la table filter permet au paquet de passer la chaine FORWARD.
En résumé pratique : - les règles des tables de nat ne sont utilisée qu'une fois - les règles des tables filter sont utilisées à chaque fois, - un même paquet ne traverse au plus qu'une des chaines INPUT, OUTPUT et FORWARD.
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).
Enfin, je crois... (p'tain, depuis le temps que je capte que dalle aux règles de firewall, voilà-t-y pas que j'ai l'air de piger ce que je fais !)
