eth1 en promisc, tcpdump ne capture rien

Support Debian
#1

Hello,

J’aimerais écouter tout le trafic de mon vlan sur l’interface secondaire de mon serveur : eth1

Eth0 me sert pour l’administration de celui-ci et Eth1 pour la capture de trame. Eth1 est connectée sur un switch non manageable, dont le port est en trunk (au sens nortel, pas cisco).

Eth1 est configuré ainsi :

[quote]eth1 Link encap:Ethernet HWaddr 00:19:b9:eb:cd:2b
adr inet6: fe80::219:b9ff:feeb:cd2b/64 Scope:Lien
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:16050874 errors:0 dropped:0 overruns:0 frame:0
TX packets:695750 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:2379895021 (2.2 GiB) TX bytes:124191888 (118.4 MiB)
Interruption:16 Mémoire:f4000000-f4012100[/quote]

Lorsque je fais un tcpdump -i Eth1, je ne vois quasiment pas de trafic… pourtant, il y a le vlan sur lequel est eth1 (port en access sur le switch) plus bien d’autres vlans.

Donc je ne vois pas trop pourquoi je ne chope rien vu que toutes les conditions sont là : mode promisc sur ma carte + agrégat sur le port de eth1.

Merci

#2

Quel est le sens de “trunk” selon Nortel ? Sur un forum Linux, il serait préférable d’utiliser les définitions au sens Linux plutôt que de tel ou tel constructeur, non ?
S’agit-il d’un port faisant partie d’une agrégation de liens (bonding au sens Linux) ?
D’un port sur lequel transite du trafic VLAN taggé (vlan au sens Linux) ?
D’un port utilisé en “mirroring” (réplique le trafic d’autre ports pour analyse ou surveillance) ?

Note : Inutile de mettre explicitement l’interface en mode promiscuous, tcpdump le fait par défaut (option -p pour ne pas le faire).
Pour une interface qui ne voit rien, je trouve que le compteur RX est bien gros.

#3

[quote=“PascalHambourg”]Quel est le sens de “trunk” selon Nortel ? Sur un forum Linux, il serait préférable d’utiliser les définitions au sens Linux plutôt que de tel ou tel constructeur, non ?
S’agit-il d’un port faisant partie d’une agrégation de liens (bonding au sens Linux) ?
D’un port sur lequel transite du trafic VLAN taggé (vlan au sens Linux) ?
D’un port utilisé en “mirroring” (réplique le trafic d’autre ports pour analyse ou surveillance) ?

Note : Inutile de mettre explicitement l’interface en mode promiscuous, tcpdump le fait par défaut (option -p pour ne pas le faire).
Pour une interface qui ne voit rien, je trouve que le compteur RX est bien gros.[/quote]
J’utilise ce port pour mes machines virtuelles. Ce port fait de l’agrégat de lien (j’y fais passer plusieurs vlans, que je récupère ensuite via des bridges pour ensuite dispatcher vers mes différentes interfaces virtuelles).

Je me dis (bêtement peut-être), que vu que je fais passer mes différents vlans sur ce port (pour les VM), je peux m’en servir aussi pour écouter l’activité de ces fameux réseaux.

Concernant le compteur RX, oui, 2,2 go de trafic c’est assez énorme, mais est-ce que ça ne correspond pas au trafic de mes machines virtuelles ? Sachant que je n’ai passé l’interface en promisc qu’hier.

As-tu une idée ?

#4

Je ne comprends pas. Est-ce

  • de l’agrégation de liens : plusieurs liens physiques regroupés pour réaliser un lien logique pour augmenter la bande passante et/ou apporter de la redondance ?
  • du VLAN : un lien physique sur lequel on fait transiter plusieurs liens logiques (VLAN) grâce au tagging ?
  • une combinaison des deux ?
#5

[quote=“PascalHambourg”]Je ne comprends pas. Est-ce

  • de l’agrégation de liens : plusieurs liens physiques regroupés pour réaliser un lien logique pour augmenter la bande passante et/ou apporter de la redondance ?
  • du VLAN : un lien physique sur lequel on fait transiter plusieurs liens logiques (VLAN) grâce au tagging ?
  • une combinaison des deux ?[/quote]

Dans ce que tu me décris, c’est du VLAN. Par élimination… Il n’est pas question de redondance ni d’augmentation de bande passe, ça élimine le premier choix et implicitement le dernier.

Sur mon switch, j’ai 2 ports : un qui est en [size=150]"[/size]access[size=150]"[/size] (donc taggé avec un vlan) avec un lien physique vers eth0 qui a une adresse ip dans le vlan taggé. Et l’autre, dont on parle, où je fais passer dessus plusieurs vlan, qui est connecté physiquement à ma Eth1 (qui elle n’a évidemment pas d’ip). Cette conf fonctionne pour moi parfaitement avec mon serveur Xen, je me sers de Eth1 pour dispatcher mes packets vers les bons bridge (un bridge par vlan) qui eux envoient vers les interfaces virtuelles liées à chaque VM).

/edit: bon, j’ai quelqu’un à côté qui me dit que je ne verrai que le trafic broadcasté (ce qui est actuellement le cas)… La seule solution serait de faire du port mirroring.
Bon, moi j’ai quand même un doute, il y a des mecs qui font ça depuis des machines virtuelles, donc à travers un bridge et une interface virtuelle… c’est que “logiciellement” c’est quand même possible de le faire non ?

#6

Bon, j’ai un peu avancé :

Voici un brctl show :

[quote]bridge name bridge id STP enabled interfaces
eth0 8000.0019b9ebcd29 no peth0
vif7.0
xenbr1128 8000.0019b9ebcd2b no eth1.1128
vif28.0
vif29.0
vif30.0
vif53.0[/quote]
Je me suis rendu compte que je chopais pas mal de trafic si je me mettais à monitorer eth1.1128 (la première interface du bridge du vlan que je veux écouter).

Là, je chope tout ce qui vient de n’importe quelle machine du réseau vers l’interface eth0 de mon serveur + toutes les machines virtualisées derrière le pont xenbr1128.

Le problème, c’est que lorsque je génère du trafic entre une machine du vlan 1128 (où qu’elle soit physiquement, virtualisée ou non) et une autre machine du même vlan, qui elle n’est pas virtualisée (dont le trafic ne passe donc pas par le pont xenbr1128) je ne vois toujours rien. Vu la configuration ce “problème” parait logique… il est logique que je ne chope que le trafic à destination de mon bridge et non pas le trafic dans l’ensemble du vlan. Comment faire pour y arriver ?

#7

Personne n’a une idée ? La seule solution que j’aurais pour l’instant est de mirrorer un autre port qui fait de l’agrégat de lien sur mon port eth1, pour avoir quelque-chose, mais sur mon switch ça n’a pas l’air possible.

#8

Le mirroring est en place, je vois le compteur de mon eth1 qui est passé de 2.5 gb à 2.7 gb, ce qui est semble-t-il bon signe, mais au niveau de tcpdump, je ne capture toujours rien de plus…

#9

bon, réponse de moi à moi, j’ai trouvé d’où vient le problème : Xen serveur semble “tronquer” les trames 8021q, du coup, si je veux écouter la principale interface utilisée par Xen (en l’occurance Eth1 chez moi), je ne verrai rien d’autre passer que le trafic broadcast/multicast ou ce qui est adressé directement aux machines virtuelles… Même en faisant du port mirroring.

J’ai utilisé une autre machine, branché sur un port mirroré, port en trunk, tous mes vlans dessus, un petit coup de mode promisc + tcpdump et là je chopais tout mon trafic.

Je ferme ce topic, me reste à trouver comment empêcher xen de tronquer ces trames, de façon à pouvoir placer mon snifer dans une machine virtuelle, si c’est possible…