Re: [FRsAG] Problème redirection port iptables
Pour plus d'informations : iptables -t nat -nvL Chain PREROUTING (policy ACCEPT 129 packets, 23159 bytes) pkts bytes target prot opt in out source destination 3 180 DNAT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901 to:194.57.105.57:2069 Chain INPUT (policy ACCEPT 15 packets, 2506 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 2 packets, 152 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 2 packets, 152 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE tcp -- * br0 0.0.0.0/0 0.0.0.0/0 tcp dpt:2069 Donc au final, les paquets sont bien interceptés par la règle PREROUTING mais pas par le POSTROUTING Florent NOLOT Université de Reims Champagne-Ardenne Le 10/01/2014 17:24, Aurélien Bras a écrit :
Bonjour,
Je spécifie toujours l'interface de sortie pour pour un snat :
-A PREROUTING -i br0 -p tcp -m tcp --dport 5901 -j DNAT --to-destination X.X.X.X:2069 -A POSTROUTING -o br0 -p tcp -m tcp --dport 2069 -j MASQUERADE
Sinon comme je vois que l'interface se nomme br0, je soupçonne que l'ip sur lequel tu effectue ton nat ne soit pas le routeur et ignore donc les paquets en question, sauf avec un tcpdump qui activerait le promiscius mode ...
Cordialement.
Aurélien
Le 10 janvier 2014 17:09, Florent Nolot <florent.nolot@univ-reims.fr <mailto:florent.nolot@univ-reims.fr>> a écrit :
Bonjour
Je suis confronté à un problème dans une configuration de redirection de port avec iptables. Quand je fais un écoute avec tcpdump sur le port concerné, ma redirection fonctionne mais quand j'arrête mon tcpdump, la redirection en marche plus ! Il semble donc que comme lors de l'écoute avec tcpdump, l'interface est en listen la redirection fonctionne alors que sans le tcpdump, il n'y a pas d'écoute et le port ne s'ouvre pas à la demande de connexion !
Ci-dessous ma règle iptable.
# Generated by iptables-save v1.4.14 on Fri Jan 10 17:05:09 2014 *nat :PREROUTING ACCEPT [1008:218755] :INPUT ACCEPT [154:25938] :OUTPUT ACCEPT [7:532] :POSTROUTING ACCEPT [8:572] -A PREROUTING -i br0 -p tcp -m tcp --dport 5901 -j DNAT --to-destination X.X.X.X:2069 -A POSTROUTING -p tcp -m tcp --dport 2069 -j MASQUERADE COMMIT # Completed on Fri Jan 10 17:05:09 2014 # Generated by iptables-save v1.4.14 on Fri Jan 10 17:05:09 2014 *filter :INPUT ACCEPT [2146:198921] :FORWARD ACCEPT [2:80] :OUTPUT ACCEPT [484:91340] COMMIT # Completed on Fri Jan 10 17:05:09 2014
Je suis sur une
Linux serv-vm1 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
Cordialement
-- Florent NOLOT Université de Reims Champagne-Ardenne
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/01/2014 18:25, Florent Nolot a écrit :
Pour plus d'informations :
iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 129 packets, 23159 bytes) pkts bytes target prot opt in out source destination 3 180 DNAT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901 to:194.57.105.57:2069
Donc au final, les paquets sont bien interceptés par la règle PREROUTING
Certes, mais ne serait-ce pas les paquets qui sont passé au moment ou ton tcpdump était lancé ? Sans s'être concerné avec Aurélien, on en arrive à la même conclusion : que le tcpdump active le promiscuous, et accepte des paquets qui ne sont normalement pas destinés à la machine. (As tu vérifié que les interfaces constituant le bridge br0 n'ont pas d'adresse IP ?) Un autre truc me chagrine : c'est la destination de tes paquets , qui semble être une IP publique . Non pas que techniquement, ça ne soit pas possible , mais cela me parait curieux . Habituellement, la cible d'une règle DNAT de la table POSTROUTING est une adresse privée.
mais pas par le POSTROUTING
Pour autant que je sache , seul le PREROUTING est nécessaire dans ce cas. @+ Christophe.
Le POSTROUTING est nécessaire dans son cas si il veut que le flux retour passe par son serveur, sinon la serveur de destination répondra directement à l'ip source non modifié, routage public oblige. Mais comme on voit ne voit rien qui traverse le POSTROUTING, on pourrait penser comme le suggère Pierre que l'ip_forward n'est pas activé. Le 10 janvier 2014 19:03, Christophe <tech@stuxnet.org> a écrit :
Le 10/01/2014 19:00, Christophe a écrit :
Habituellement, la cible d'une règle DNAT de la table POSTROUTING est une adresse privée.
s/POSTROUTING/PREROUTING/
sorry .. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Est-ce que ta as tout simplement essayé d'activer le mode promisc sur ton interface? Perso sur mes hn OpenVz j'utilise le script suivant sur le host pour un vpn propagé entre les machines lors du montage du tunnel : #!/bin/bash /sbin/ifconfig mgmtbr0 promisc /sbin/ifconfig tap0 up promisc /sbin/brctl addif mgmtbr0 tap0 Le 10 janv. 2014 19:18, "Aurélien Bras" <aurelien.bras@gmail.com> a écrit :
Le POSTROUTING est nécessaire dans son cas si il veut que le flux retour passe par son serveur, sinon la serveur de destination répondra directement à l'ip source non modifié, routage public oblige.
Mais comme on voit ne voit rien qui traverse le POSTROUTING, on pourrait penser comme le suggère Pierre que l'ip_forward n'est pas activé.
Le 10 janvier 2014 19:03, Christophe <tech@stuxnet.org> a écrit :
Le 10/01/2014 19:00, Christophe a écrit :
Habituellement, la cible d'une règle DNAT de la table POSTROUTING est une adresse privée.
s/POSTROUTING/PREROUTING/
sorry .. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/01/2014 19:27, Nathan delhaye a écrit :
Est-ce que ta as tout simplement essayé d'activer le mode promisc sur ton interface?
Cela fonctionne effectivement en faisant un simple ifconfig br0 promisc Ce qui est assez logique car on retrouve le comportement de la carte comme avec le tcpdump Dès que j'aurai la réponse sans le promisc, je poste car c'est très étrange. Florent NOLOT Université de Reims Champagne-Ardenne
Bonsoir, Le 10/01/2014 19:17, Aurélien Bras a écrit :
Le POSTROUTING est nécessaire dans son cas si il veut que le flux retour passe par son serveur, sinon la serveur de destination répondra directement à l'ip source non modifié, routage public oblige.
Donc il y'a clairement un truc qui m'échappe. Le 10/01/2014 17:30, Florent Nolot a écrit :
Archi assez simple
Internet --> Serveur avec la redirection --> Destination X.X.X.X
La machine de destination est en IP publique ? Au vu du "Archi assez simple", j'en doute. Si tel est le cas (et ça rejoint la question de Pierre, sur la Gateway utilisée par la machine de destination), il est fort à parier qu'il y a un routage asymétrique. Les paquets arrivant depuis une gateway , mais ressortant par un autre (et ça , à part cas très particuliers, ça ne marche pas / et du coup, c'est pas de l'archi simple). Mais dans les deux cas, je ne saisis quand même pas l'intérêt de la règle POSTROUTING. surtout avec un --dport ?? (c'est pas --sport normalement ?)
Mais comme on voit ne voit rien qui traverse le POSTROUTING, on pourrait penser comme le suggère Pierre que l'ip_forward n'est pas activé.
C'est vrai qu'il est bon de rappeler la base (oubli assez fréquent dans ce genre de situations) ... Mais c'est plutôt le fait que ça fonctionne pendant qu'un tcpdump (et donc le promiscuous mode) est lancé alors que cela n'est plus le cas sans qui me parait curieux. @+ Christophe.
Mais c'est plutôt le fait que ça fonctionne pendant qu'un tcpdump (et donc le promiscuous mode) est lancé alors que cela n'est plus le cas sans qui me parait curieux.
En fait c'est rigolo, le promiscuous mode se substitue à l'ip_forward si on a un DNAT et un SNAT. J'ai fait le test sur mon dédié perso en redirigeant le port 9998 vers le port 80 de www.free.fr, c'est fonctionnel sans ip_forward si et seulement si l'interface est en promiscuous : Voici mes deux règles de NAT : -A PREROUTING -i eth0 -p tcp -m tcp --dport 9998 -j DNAT --to-destination 212.27.48.10:80 -A POSTROUTING -o eth0 -p tcp -m tcp --dport 80 -j MASQUERADE Donc je pense qu'il a bien oublié d'activer l'ip_forward :) Bonne soirée Aurélien
participants (4)
-
Aurélien Bras -
Christophe -
Florent Nolot -
Nathan delhaye