hellow,
> Le problème tourne vraiment autour du br0 je pense.
J'ai pas creusé ta question, mais au cas où:
Ne serait ce pas dû à net.bridge.bridge-nf-call-iptables ?
___
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 tcpd
>
>
> 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
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'é
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 supp
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: mtu
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/b
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 Pi
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/
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
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/0tcp dpt:5901 to:194.57.105.57:
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
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 redirecti
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,
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 r
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 a
16 matches
Mail list logo
