Problème redirection port iptables
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
Bonjour, Le 10 janv. 2014 à 17:09, Florent Nolot 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 !
Je crois que ça manque d'infos... Quelle est la topologie réseau ? Laquelle des deux règles foire ? Tu peux également débugguer en utilisant la cible LOG ou la cible TRACE: iptables -t raw -j TRACE Cordialement Emmanuel Thierry
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/
Archi assez simple Internet --> Serveur avec la redirection --> Destination X.X.X.X Le problème tourne vraiment autour du br0 je pense. Florent NOLOT Université de Reims Champagne-Ardenne Le 10/01/2014 17:19, Emmanuel Thierry a écrit :
Bonjour,
Le 10 janv. 2014 à 17:09, Florent Nolot 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 !
Je crois que ça manque d'infos... Quelle est la topologie réseau ? Laquelle des deux règles foire ?
Tu peux également débugguer en utilisant la cible LOG ou la cible TRACE: iptables -t raw -j TRACE
Cordialement Emmanuel Thierry
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/
Bonsoir, Le 10/01/2014 17:09, Florent Nolot 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 !
Quand tcpdump est lancé, cela active le mode promiscuous sur l'interface réseau concernée , et cette interface peut donc prendre en compte des paquets qui ne lui sont normalement pas destinés. (à creuser).
Archi assez simple
Internet --> Serveur avec la redirection --> Destination X.X.X.X
Le problème tourne vraiment autour du br0 je pense.
Fort possible : Comment ce bridge est il configuré ? Question subsidiaire (parce que c'est un cas vécu) : Et ce qu'il n'y aurait pas une adresse IP qui traine sur une des interfaces réseau qui constitue ton bridge ? (typiquement une adresse IP attribuée en DHCP sur une des interfaces réseau avant que le bridge ne soit monté ?). @+ Christophe.
le bridge porte l'IP publique, et redirrige les flux vers une ip privée montée sur le même bridge ? je dirai déjà qu'il y a un soucis de choix de l'archi. sinon, quelle est la gw de la VM (?) truc con, tu as bien pensé a activer le routage au niveau du kernel ? Le 10/01/2014 18:07, Christophe a écrit :
Bonsoir,
Le 10/01/2014 17:09, Florent Nolot 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 ! Quand tcpdump est lancé, cela active le mode promiscuous sur l'interface réseau concernée , et cette interface peut donc prendre en compte des paquets qui ne lui sont normalement pas destinés. (à creuser).
Archi assez simple
Internet --> Serveur avec la redirection --> Destination X.X.X.X
Le problème tourne vraiment autour du br0 je pense. Fort possible : Comment ce bridge est il configuré ?
Question subsidiaire (parce que c'est un cas vécu) : Et ce qu'il n'y aurait pas une adresse IP qui traine sur une des interfaces réseau qui constitue ton bridge ? (typiquement une adresse IP attribuée en DHCP sur une des interfaces réseau avant que le bridge ne soit monté ?).
@+ Christophe. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/01/2014 18:18, Pierre `Sn4kY` DOLIDON a écrit :
le bridge porte l'IP publique, et redirrige les flux vers une ip privée montée sur le même bridge ? je dirai déjà qu'il y a un soucis de choix de l'archi. Non, je redirige vers une publique ou une privée, d'où le nat en postrouting pour supporter les 2 possibilités (que j'ai), aucun problème d'archi. Le paquet est routé vers la gw mais du coup, avec le nat en postrouting, avec la bonne source. Avant un upgrade majeur de kernel, cela marchait parfaitement.
Le 10/01/2014 18:07, Christophe a écrit :
Fort possible : Comment ce bridge est il configuré ? classiquement,
$ brctl br0 show bridge name bridge id STP enabled interfaces br0 8000.0025901b2988 no eth0 $ ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000 link/ether 00:25:90:1b:29:88 brd ff:ff:ff:ff:ff:ff
Question subsidiaire (parce que c'est un cas vécu) : Et ce qu'il n'y aurait pas une adresse IP qui traine sur une des interfaces réseau qui constitue ton bridge ? (typiquement une adresse IP attribuée en DHCP sur une des interfaces réseau avant que le bridge ne soit monté ?).
Florent NOLOT Université de Reims Champagne-Ardenne
participants (5)
-
Christophe -
Emmanuel Thierry -
Florent Nolot -
Pierre `Sn4kY` DOLIDON -
Sébastien Bocahu