J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100
Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100
Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100
Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100
s/--to ports/--to-ports/Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT
Tu te manges une grosse erreur de syntaxe.
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
En effet.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100
s/--to ports/--to-ports/
Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT
Tu te manges une grosse erreur de syntaxe.
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
En effet.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
J'ai un petit soucis avec iptables, je souhaiterai rediriger ce qui
arrive sur le port 200 sur eth0 vers le port 100 de la même machine.
Ceci n'est pas compliqué :
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 200
-j REDIRECT --to ports 100
s/--to ports/--to-ports/Le problème est que je souhaiterai que le port 100 ne soit plus
accessible directement. Si je fais naïvement :
iptables -i eth0 -p tcp --dport 100 -j REJECT
Tu te manges une grosse erreur de syntaxe.
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
En effet.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
Pascal Hambourg wrote in message <h8nh99$1858$:iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
Est-ce qu'il n'y aurait pas moyen de jouer avec l'ordre des paquets. La doc
n'est pas très explicite sur ce point, mais j'ai l'impression qu'après la
règle REDIRECT, iptables considère que c'est toujours le même paquet qui est
en train de traverser les règles.
Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.
Pascal Hambourg wrote in message <h8nh99$1858$1@saria.nerim.net>:
iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
Est-ce qu'il n'y aurait pas moyen de jouer avec l'ordre des paquets. La doc
n'est pas très explicite sur ce point, mais j'ai l'impression qu'après la
règle REDIRECT, iptables considère que c'est toujours le même paquet qui est
en train de traverser les règles.
Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.
Pascal Hambourg wrote in message <h8nh99$1858$:iptables bloque tout se qui arrive sur le port 100 mais aussi ce qui
a été redirigé.
"-m conntrack --ctstate DNAT" ne détecte que les changements d'adresse,
pas de port. Il reste le marquage des paquets avec "-j MARK" dans la
chaîne mangle/PREROUTING avant redirection et le test de la marque avec
"-m mark" après dans la chaîne INPUT.
Est-ce qu'il n'y aurait pas moyen de jouer avec l'ordre des paquets. La doc
n'est pas très explicite sur ce point, mais j'ai l'impression qu'après la
règle REDIRECT, iptables considère que c'est toujours le même paquet qui est
en train de traverser les règles.
Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.
Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».
Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».
Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».
Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.
Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.
Donc peut-être qu'en mettant dans la même chaîne d'abord la règle qui
rejette les paquets pour le port 100 puis celle qui transforme le port 200
en port 100, ça passerait.
Benoit Izac wrote in message :Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».
C'est vrai qu'iptables a récemment introduit des règles plus strictes de ce
genre.
Dans ce cas, tu peux essayer de rediriger le port 100 vers le port 101 (ou
n'importe quel autre port dont tu sais qu'il est fermé) puis rediriger le
port 200 vers le port 100.
Benoit Izac wrote in message <w53fxaomxhb@message.id>:
Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».
C'est vrai qu'iptables a récemment introduit des règles plus strictes de ce
genre.
Dans ce cas, tu peux essayer de rediriger le port 100 vers le port 101 (ou
n'importe quel autre port dont tu sais qu'il est fermé) puis rediriger le
port 200 vers le port 100.
Benoit Izac wrote in message :Le problème c'est qu'on ne peut pas mettre ça dans une même chaîne car
il y a deux tables différentes « nat » et « filter ».
C'est vrai qu'iptables a récemment introduit des règles plus strictes de ce
genre.
Dans ce cas, tu peux essayer de rediriger le port 100 vers le port 101 (ou
n'importe quel autre port dont tu sais qu'il est fermé) puis rediriger le
port 200 vers le port 100.
Après ça comment veux-tu qu'on ait encore de la crédibilité quand on dit
que le NAT n'est pas du filtrage...
Benoît, quel est le but la manoeuvre ? N'était-il pas possible de
simplement modifier le port d'écoute du service concerné ?
Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.
Après ça comment veux-tu qu'on ait encore de la crédibilité quand on dit
que le NAT n'est pas du filtrage...
Benoît, quel est le but la manoeuvre ? N'était-il pas possible de
simplement modifier le port d'écoute du service concerné ?
Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.
Après ça comment veux-tu qu'on ait encore de la crédibilité quand on dit
que le NAT n'est pas du filtrage...
Benoît, quel est le but la manoeuvre ? N'était-il pas possible de
simplement modifier le port d'écoute du service concerné ?
Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.
Pascal Hambourg wrote in message <h8nmg7$19os$:
Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.
Ça me semble assez stupide, comme décision. Il est clair que le NAPT
automatique pour partage d'adresse IP n'a pas lieu d'être en IPv6,
mais il y a d'autres utilisations tout à fait légitimes de ces règles qui
sont tout à fait pertinentes en IPv6. Personnellement, j'en utilise deux :
- Une redirection uniquement sur le port pour permettre à un serveur
tournant sans privilèges d'apparaître sur un port privilégié. C'est
largement plus simple que toute autre méthode envisagées, en particulier
au niveau de la quantité d'intervention requise de root (qui a peu de
temps à nous consacrer).
- Une redirection uniquement d'adresse IP pour faire apparaître un serveur
quelconque sur une adresse IP privée au choix. Je m'en sers sur mon
portable pour faire apparaître les serveurs DNS, qui varient selon
l'endroit où le portable en question est branché, toujours sur la même
adresse pour mon PDA connecté en bluetooth. Je n'ai pas envie de faire
tourner un cache DNS local sur cette machine.
Pascal Hambourg wrote in message <h8nmg7$19os$1@saria.nerim.net>:
Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.
Ça me semble assez stupide, comme décision. Il est clair que le NAPT
automatique pour partage d'adresse IP n'a pas lieu d'être en IPv6,
mais il y a d'autres utilisations tout à fait légitimes de ces règles qui
sont tout à fait pertinentes en IPv6. Personnellement, j'en utilise deux :
- Une redirection uniquement sur le port pour permettre à un serveur
tournant sans privilèges d'apparaître sur un port privilégié. C'est
largement plus simple que toute autre méthode envisagées, en particulier
au niveau de la quantité d'intervention requise de root (qui a peu de
temps à nous consacrer).
- Une redirection uniquement d'adresse IP pour faire apparaître un serveur
quelconque sur une adresse IP privée au choix. Je m'en sers sur mon
portable pour faire apparaître les serveurs DNS, qui varient selon
l'endroit où le portable en question est branché, toujours sur la même
adresse pour mon PDA connecté en bluetooth. Je n'ai pas envie de faire
tourner un cache DNS local sur cette machine.
Pascal Hambourg wrote in message <h8nmg7$19os$:
Avis perso : avec IPv6 qui approche, il faudrait commencer à se
désintoxiquer du NAT et de ses facilités, car il n'y a pas de NAT pour
IPv6 dans netfilter/iptables et ça n'a pas l'air d'être dans les
intentions des développeurs de l'ajouter.
Ça me semble assez stupide, comme décision. Il est clair que le NAPT
automatique pour partage d'adresse IP n'a pas lieu d'être en IPv6,
mais il y a d'autres utilisations tout à fait légitimes de ces règles qui
sont tout à fait pertinentes en IPv6. Personnellement, j'en utilise deux :
- Une redirection uniquement sur le port pour permettre à un serveur
tournant sans privilèges d'apparaître sur un port privilégié. C'est
largement plus simple que toute autre méthode envisagées, en particulier
au niveau de la quantité d'intervention requise de root (qui a peu de
temps à nous consacrer).
- Une redirection uniquement d'adresse IP pour faire apparaître un serveur
quelconque sur une adresse IP privée au choix. Je m'en sers sur mon
portable pour faire apparaître les serveurs DNS, qui varient selon
l'endroit où le portable en question est branché, toujours sur la même
adresse pour mon PDA connecté en bluetooth. Je n'ai pas envie de faire
tourner un cache DNS local sur cette machine.
Mais toutes ces applications du NAT ne sont fondamentalement que des
béquilles pour des problématiques qui devraient être résolues autrement.
Car un problème de fond demeure : le NAT ne marche pas avec tous les
protocoles et applications.
Comme le NAT n'a jamais été standardisé et
inclus dans la spécification du protocole IP (v4 ou v6), chaque
implémentation fait son NAT à sa sauce.
Et les
protocoles et applications se débrouillent (ou pas) comme ils peuvent
pour passer à travers (helpers, STUN et compagnie).
Mais toutes ces applications du NAT ne sont fondamentalement que des
béquilles pour des problématiques qui devraient être résolues autrement.
Car un problème de fond demeure : le NAT ne marche pas avec tous les
protocoles et applications.
Comme le NAT n'a jamais été standardisé et
inclus dans la spécification du protocole IP (v4 ou v6), chaque
implémentation fait son NAT à sa sauce.
Et les
protocoles et applications se débrouillent (ou pas) comme ils peuvent
pour passer à travers (helpers, STUN et compagnie).
Mais toutes ces applications du NAT ne sont fondamentalement que des
béquilles pour des problématiques qui devraient être résolues autrement.
Car un problème de fond demeure : le NAT ne marche pas avec tous les
protocoles et applications.
Comme le NAT n'a jamais été standardisé et
inclus dans la spécification du protocole IP (v4 ou v6), chaque
implémentation fait son NAT à sa sauce.
Et les
protocoles et applications se débrouillent (ou pas) comme ils peuvent
pour passer à travers (helpers, STUN et compagnie).