bridge et interfaces virtuelles sous linux

Le
lidiriel
Bonjour,

je ne sais pas si je poste au bon endroit mais je charche des
spécialiste réseau.
Alors voila ma problématique.
je développe une application qui doit causé avec 300 petit serveur
(PS).
cela cause avec un protocol maison en rawethernet. Donc via les
adresse MAC.
J aimerais tester la monter en charge de mon appli appelons la FOO.

Ce que je voulais faire c est installer un bridge sur un linux
disposant dun interface eth0
A ce bridge je lui rajoute 300 interface TAP (de TAP0 a TAP299).
Je recupere les adresse MAC des TAP et je les donne a mon appli FOO.
Ensuite je démarre les 300 serveur PS chacun connecté a une interface
TAP.

Mais ca marche pas.
voici la procedure :

# conf de l hote au 300 serveur
ifconfig eth0 0.0.0.0 promisc up
brctl addbr monbridge
brctl setfd monbridge 0
brctl sethello monbridge 0
brctl stp monbridge off
ifconfig monbridge 192.168.0.42 netmask 255.255.255.0 up
# connexion a eth0
brctl addif monbridge eth0

#creation des interface virtuel
tunctl -t tap0


tunctl -t tap299
#conf des interfaces
ifconfig tap0 0.0.0.0 promisc up

# on connect au bridge
brctl addif monbridge tap0

de même avec les autre tap (en fait j essaye d abord avec 2)
ensuite je lance mon serveur avec en parametre le nom de l interface.

Voici l archi reseau :
FOO <-> [[ eth0 <==> monbridge <==>TAP1, TAP2, TAPX <==> PS1,=

PS2, PSX ]]

FOO est sur une machine physique différente
remarque monbridge a pris l adresse mac de eth0 ce qui me parrait
normal
l'ensemble des interface sont en "promisc" sauf monbridge


*** resultat ***
les 2 serveurs PS recoivent bien les requetes
ils repondent, quand je scan le reseau sur les interface TAP avec
wireshark je recupère les requete qu ils envoient a FOO pas ce qui
rentre par contre ! bizarre déjà.
Quand je fait inspecter l interface "monbridge" a wireshark je choppe
les trames qui rentre a destination des mes serveur PS mais rien qui
sort.


Si quelqu un avait une idée a me proposer . car je suis pas fortich en
réseau et cela me dépanerais bien.

a+
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #2154411
Salut,


je ne sais pas si je poste au bon endroit mais je charche des
spécialiste réseau.


Pourquoi des spécialistes ? Perso je préfère un non spécialiste qui sait
répondre à ma question qu'un spécialiste qui ne sait pas.

A ce bridge je lui rajoute 300 interface TAP (de TAP0 a TAP299).
Je recupere les adresse MAC des TAP et je les donne a mon appli FOO.
Ensuite je démarre les 300 serveur PS chacun connecté a une interface
TAP.


Si je puis me permettre, ce ne sont pas les adresses MAC des interfaces
TAP qu'il faut récupérer puisqu'elles vont disparaître dans le pont,
mais plutôt les adresses MAC de ce qui se trouve à l'autre bout, donc
des PS si j'ai bien compris.

FOO est sur une machine physique différente
remarque monbridge a pris l adresse mac de eth0 ce qui me parrait
normal


En effet, le pont prend l'adresse MAC de la première interface liée.

l'ensemble des interface sont en "promisc" sauf monbridge


C'est de toute façon nécessairement le cas dans un pont, inutile de
s'embêter à les mettre manuellement en mode promiscuous.

*** resultat ***
les 2 serveurs PS recoivent bien les requetes
ils repondent, quand je scan le reseau sur les interface TAP avec
wireshark je recupère les requete qu ils envoient a FOO pas ce qui
rentre par contre ! bizarre déjà.


C'est FOO ou les PS qui envoient des requêtes ?
Qu'est-ce qui est censé rentrer, depuis où et vers où ?

Quand je fait inspecter l interface "monbridge" a wireshark je choppe
les trames qui rentre a destination des mes serveur PS mais rien qui
sort.


Normal a priori, l'interface monbridge ne voit pas ce qui transite entre
l'interface ethernet et les interfaces TAP. Les interfaces d'un pont,
c'est un peu comme les ports d'un switch ethernet :

monbridge
|
tap0 - switch - tap1
|
eth0

lidiriel
Le #2170211
On Apr 3, 11:43 pm, Pascal Hambourg wrote:


je ne sais pas si je poste au bon endroit mais je charche des
spécialiste réseau.


Pourquoi des spécialistes ? Perso je préfère un non spécialiste qu i sait
répondre à ma question qu'un spécialiste qui ne sait pas.


:) quelqu'un qui peut me répondre est pour moi un spécialiste (a
différent degré :) ) même si il est menuisier.

A ce bridge je lui rajoute 300 interface TAP (de TAP0 a TAP299).
Je recupere les adresse MAC des TAP et je les donne a mon appli FOO.
Ensuite je démarre les 300 serveur PS chacun connecté a une interfa ce
TAP.


Si je puis me permettre, ce ne sont pas les adresses MAC des interfaces
TAP qu'il faut récupérer puisqu'elles vont disparaître dans le pont,
mais plutôt les adresses MAC de ce qui se trouve à l'autre bout, donc
des PS si j'ai bien compris.


Mais ce que j appele PS c est une petit application qui a besoin d une
interface reseau. Donc je lui donne comme interface une TAP.
Et pour mon appli FOO elle (l'appli PS) est identifié avec sa
MACADRESS.
( A terme PS tournera sur une carte dédié avec une vrai interface
physique et une vrai MACADRESS, je voudrais juste simuler tout ca )

*** resultat ***
les 2 serveurs PS recoivent bien les requetes
ils repondent, quand je scan le reseau sur les interface TAP avec
wireshark je recupère les requete qu ils envoient a FOO pas ce qui
rentre par contre ! bizarre déjà.


C'est FOO ou les PS qui envoient des requêtes ?
Qu'est-ce qui est censé rentrer, depuis où et vers où ?


FOO envoie une requete sur le reseau avec les MACADRESS des TAP. Les
softs PS receptionnent les requete et renvoient des réponses a FOO.
Jusque la ca marche mais la reponse n arrive pas a FOO. Pourtant les
PS recoivent bien les requetes de FOO

je refait un petit schema j espère qu il passera correctement.
/
foo* | machine 1
|| /
{ lan }
| /
eth0 |
| |
monbridge | machine 2
| | | |
tap0 tap1 tap2 |
|| || || |
ps0* ps1* ps2* |
/
Quand je fait inspecter l interface "monbridge" a wireshark je choppe
les trames qui rentre a destination des mes serveur PS mais rien qui
sort.


Normal a priori, l'interface monbridge ne voit pas ce qui transite entre
l'interface ethernet et les interfaces TAP. Les interfaces d'un pont,
c'est un peu comme les ports d'un switch ethernet :

pourquoi je vois les trame qui rentre alors ?


merci pour votre aide


lidiriel
Le #2175341
Ok je viens d avancer un peu. Je constate comme tu me la dit que
apriori le bridge est completement ransparent puisque mes deux soft
PS1 et PS2 on recu chacun une requete venant de FOO qui n'était
adresser (en MAC) qu a PS1.
Bon je me replonge dans la doc mais je vois pas comment faire car il
me faut des interface style TUN/TAP avec une adresse MAC. Peut etre
avec un switch virtuel et pas un bridge ? ca existe au moin un switch
virtuel ?
Pascal Hambourg
Le #2182841

A ce bridge je lui rajoute 300 interface TAP (de TAP0 a TAP299).
Je recupere les adresse MAC des TAP et je les donne a mon appli FOO.
Ensuite je démarre les 300 serveur PS chacun connecté a une interface
TAP.


Si je puis me permettre, ce ne sont pas les adresses MAC des interfaces
TAP qu'il faut récupérer puisqu'elles vont disparaître dans le pont,
mais plutôt les adresses MAC de ce qui se trouve à l'autre bout, donc
des PS si j'ai bien compris.


Mais ce que j appele PS c est une petit application qui a besoin d une
interface reseau. Donc je lui donne comme interface une TAP.
Et pour mon appli FOO elle (l'appli PS) est identifié avec sa
MACADRESS.


Je voudrais éclaircir un point important. Les applis PS communiquent
bien avec les TAP via /dev/net/tun et non via des sockets réseau avec
les interfaces tapX, n'est-ce pas ?

J'insiste bien, l'application qui communique via /dev/net/tun simule un
réseau ethernet virtuel connecté à tapX, et donc doit utiliser des
adresses MAC sources distinctes de l'adresse MAC de tapX.

je refait un petit schema j espère qu il passera correctement.


Non, il est tout déformé. Composé avec une police de caractères à
espacement variable comme Arial ou Times ? Il faut composer les schémas
ASCII avec une police à espacement fixe comme Courier. Je le redresse :

/
foo* | machine 1
|| /
{ lan }
| /
eth0 |
| |
monbridge | machine 2
| | | |
tap0 tap1 tap2 |
|| || || |
ps0* ps1* ps2* |
/

Quand je fait inspecter l interface "monbridge" a wireshark je choppe
les trames qui rentre a destination des mes serveur PS mais rien qui
sort.


Normal a priori, l'interface monbridge ne voit pas ce qui transite entre
l'interface ethernet et les interfaces TAP. Les interfaces d'un pont,
c'est un peu comme les ports d'un switch ethernet :


pourquoi je vois les trame qui rentre alors ?


Parce que le pont diffuse sur tous les "ports" (monbridge, tapX, eth0)
autres que le port d'entrée les trames dont il ne connaît pas le port de
destination.

Ok je viens d avancer un peu. Je constate comme tu me la dit que
apriori le bridge est completement ransparent puisque mes deux soft
PS1 et PS2 on recu chacun une requete venant de FOO qui n'était
adresser (en MAC) qu a PS1.


Le pont doit apprendre quelles adresses MAC sont associées à quels
ports. Pour cela il se base sur l'adresse MAC source des trames reçues.
En attendant, il diffuse les trames avec des adresses MAC destination
inconnues sur tous les ports autres que le port d'entrée.

Bon je me replonge dans la doc mais je vois pas comment faire car il
me faut des interface style TUN/TAP avec une adresse MAC. Peut etre
avec un switch virtuel et pas un bridge ? ca existe au moin un switch
virtuel ?


Pont ou switch, c'est la même chose.



lidiriel
Le #2539211
D'abord merci pour les explications

On Apr 4, 2:00 pm, Pascal Hambourg wrote:

Je voudrais éclaircir un point important. Les applis PS communiquent
bien avec les TAP via /dev/net/tun et non via des sockets réseau avec
les interfaces tapX, n'est-ce pas ?


en fait j ouvre des raw sockets que je connect au tapX. Le PS récupère
l adresse mac du tapX.
et renvoie une réponse avec l adresse MAC de la machine ou FOO est
executé.
En fait non je n'utilise pas /dev/net/tun !
C'est grave doc ?
Je vois que je dois mal m y prendre mais je ne sais pas comment
faire ...

Pascal Hambourg
Le #2541241

en fait j ouvre des raw sockets que je connect au tapX. Le PS récupère
l adresse mac du tapX.
et renvoie une réponse avec l adresse MAC de la machine ou FOO est
executé.
En fait non je n'utilise pas /dev/net/tun !
C'est grave doc ?


En effet, ce n'est pas ainsi que les interfaces TUN/TAP doivent être
utilisées. Là, elles n'apportent rien de plus que des interfaces "dummy"
(factices). Tu prends le problème à l'envers : quand un PS envoie un
paquet, ce paquet doit apparaître comme entrant par l'interface TAP
pontée et non émis par l'interface car ce qui est émis par l'interface
ne va pas vers le pont mais vers "l'extérieur", c'est-à-dire le vide
sidéral si rien ne communique avec l'interface via /dev/net/tun.

Une solution serait de créer des paires d'interfaces TAP simulant
chacune un brin ethernet : une trame émise sur une interface d'une paire
est reçue par l'autre interface de la paire. Un PS se connecterait à une
interface et l'autre interface serait intégrée dans le pont. J'avais
gribouillé un petit programme en C qui crée une telle paire (voire
simule un hub, avec plus de deux ports) mais je ne suis pas sûr que ce
soit viable pour plusieurs centaines d'interfaces.

Sinon, il y a une solution pour créer un switch virtuel en userland, VDE
(Virtual Distributed Switch). Un switch virtuel est créé avec la
commande vde_switch. Ensuite des interfaces TAP peuvent être branchées
dessus avec la commande vde_plug2tap. Je pense que ces interfaces TAP
seraient directement utilisables par les PS.

lidiriel
Le #2541221
On Apr 8, 11:34 am, Pascal Hambourg wrote:



en fait j ouvre des raw sockets que je connect au tapX. Le PS récupè re
l adresse mac du tapX.
et renvoie une réponse avec l adresse MAC de la machine ou FOO est
executé.
En fait non je n'utilise pas /dev/net/tun !
C'est grave doc ?


En effet, ce n'est pas ainsi que les interfaces TUN/TAP doivent être
utilisées. Là, elles n'apportent rien de plus que des interfaces "dumm y"
(factices). Tu prends le problème à l'envers : quand un PS envoie un
paquet, ce paquet doit apparaître comme entrant par l'interface TAP
pontée et non émis par l'interface car ce qui est émis par l'interfa ce
ne va pas vers le pont mais vers "l'extérieur", c'est-à-dire le vide
sidéral si rien ne communique avec l'interface via /dev/net/tun.


si je comprend bien les interfaces TAP c est jsute un flux sortant du
bridge donc c est pour ca que je recois mes trame venant de l
exterieur et que les trames que j envoie ne rentre aps dans le bridge.
Et les dummy j ai découvert ca aussi je voit pas trop la différence et
l utilité ?
Es ce que cela peut me servir dans ce cas précis ?

Ok tap n est pas viable cela me semble plus compliquer que je le
pensais.. je voyais ca comme une interface a double sens que je
pouvais utiliser comme mon eth0 classique.

Sinon, il y a une solution pour créer un switch virtuel en userland, VDE
(Virtual Distributed Switch). Un switch virtuel est créé avec la
commande vde_switch. Ensuite des interfaces TAP peuvent être branchées
dessus avec la commande vde_plug2tap. Je pense que ces interfaces TAP
seraient directement utilisables par les PS.
Je vais regarder cela.



Pascal Hambourg
Le #2546441

si je comprend bien les interfaces TAP c est jsute un flux sortant du
bridge


Telles que tu les as (mal) utilisées, oui.

donc c est pour ca que je recois mes trame venant de l
exterieur et que les trames que j envoie ne rentre aps dans le bridge.


C'est ce que je soupçonne.

Et les dummy j ai découvert ca aussi je voit pas trop la différence et
l utilité ?


Voir plus bas.

Es ce que cela peut me servir dans ce cas précis ?


Non, je ne pense pas.

Ok tap n est pas viable cela me semble plus compliquer que je le
pensais.. je voyais ca comme une interface a double sens que je
pouvais utiliser comme mon eth0 classique.


C'est bien le cas. Je pense que ton problème est une mauvaise
compréhension de fonctionnement de ces interfaces TUN/TAP et d'un pont.

Je vais rappeler quelques évidences. Une interface réseau est une
interface de communication standardisée permettant au système et aux
programmes d'échanger des paquets de données avec "l'extérieur". Envoyer
un paquet par une interface, c'est le transmettre depuis le système vers
l'extérieur. Recevoir un paquet par une interface, c'est le transmettre
depuis l'extérieur vers le système.

La nature de cet "extérieur" dépend de la nature des interfaces. Pour
une interface ethernet physique, l'extérieur est un réseau relié à une
carte ethernet, constitué d'autres équipements qui peuvent envoyer et
recevoir des paquets. Pour une interface "dummy" (factice), l'extérieur
est un trou noir qui n'envoie rien et dans lequel toute trame émise
disparaît. C'est en quelque sorte une interface ethernet physique dont
on aurait débranché le câble.

Pour une interface TUN/TAP, l'extérieur est un programme qui émet et
reçoit des paquets et écrivant et en lisant sur le fichier spécial
(périphérique en mode caractère) /dev/net/tun. Un paquet émis par le
système sur l'interface TUN/TAP est lu (reçu) par le programme sur
/dev/net/tun, et un paquet écrit (émis) par le programme sur
/dev/net/tun est reçu par le système sur l'interface TUN/TAP. Le
programme peut simuler un hôte distant, voire tout un réseau. Ce
mécanisme est d'ailleurs souvent utilisé pour communiquer avec des
machines virtuelles. Si une interface TAP persistante a été créée avec
tunctl, il est clair que si aucun programme ne communique avec elle via
/dev/net/tun, alors c'est un trou noir, comme une interface dummy ou une
interface physique dont le câble est débranché.

Un pont modifie le fonctionnement des interfaces qui lui sont liées.
Lorsqu'un paquet est reçu par une interface appartenant à un pont
(c'est-à-dire émis par "l'extérieur" de cette interface), au lieu d'être
transmis aux couches réseau supérieures du système il est transmis au
pont. Puis le pont retransmet le paquet sur certaines de ses autres
interfaces, c'est-à-dire l'émet vers "l'extérieur" de chcune de ces
interfaces. Une interface appartenant à un pont n'est donc plus
autonome. En revanche si le système émet un paquet directement par une
interface appartenant à un pont, il est envoyé vers l'extérieur de cette
interface, pas vers le pont. C'est pourquoi les interface appartenant à
un pont ne doivent pas être utilisées directement par le système et les
applications, à l'exception de l'interface pont elle-même (br0) qui est
là pour ça.

Par conséquent, pour que ce que tu veux faire fonctionne, il faudrait
non pas que les PS utilisent les interfaces TAP du pont (à l'intérieur
du système, donc) mais soient leur "extérieur". Soit directement par
/dev/net/tun, ce qui implique de modifier le programme, soit
indirectement en utilisant d'autres interfaces TAP qui communiquent avec
les interfaces TAP du pont via des liens virtuels point à point ou un
switch virtuel comme VDE.

Sinon, il y a une solution pour créer un switch virtuel en userland, VDE
(Virtual Distributed Switch).



Correction : VDE signifie Virtual Distributed Ethernet.


lidiriel
Le #2552461
Ok il semble que cela marche:

alors le process que j ai appliqué :
* je désactive toute mes interfaces
* création d'une interface tap0
* création d'un bridge
* configuration de br0 (reseau 192.168.Y.Y)
* ajout au bridge de eth0 et tap0
* activation de eth0 (ifup 193.55.X.X)
* activation de tap0 (ifup 0.0.0.0)
* démarrage de vde_switch sur tap0

* création de tap1 et tap2
* activation de tap1 et tap2 (192.168.Y.Y)

* démarrage de vde_plug2tap pour tap1 et tap2

* démarrage du process ps1 connecté sur tap1
* démarrage du process ps2 connecté sur tap2

test avec wireshark sur eth0 (ca a l air de marcher)
test avec FOO sur une autre machine avec envoie de trame en
rawethernet avec les 2 adresse MAC : OK ca marche :))

Il me reste plus qu a scripter et mettre ca sur une bonne machine.
Au passage j ai eu quelque soucis avec libvdeplug.so.2 , j ai fait une
sale copie a la main pour que cela marche. Problème d install depuis
les source apparament.

Encore un grand merci a toi Pascal et juste une dernière question.
j utilise les MACADRESS de mes tap1 a tapX mais elles sont attribuée
aléatoirement peut ton les fixer ?
Pascal Hambourg
Le #2555491
Ok il semble que cela marche:


Tu as de la chance, il y a encore trois jours j'ignorais l'existence
même de VDE. J'en ai entendu parler au détour d'une discussion sur le
pontage dans un forum web. Faut dire, la virtualisation c'est ps trop
mon truc.

alors le process que j ai appliqué :
* je désactive toute mes interfaces
* création d'une interface tap0
* création d'un bridge
* configuration de br0 (reseau 192.168.Y.Y)
* ajout au bridge de eth0 et tap0
* activation de eth0 (ifup 193.55.X.X)
* activation de tap0 (ifup 0.0.0.0)
* démarrage de vde_switch sur tap0

* création de tap1 et tap2
* activation de tap1 et tap2 (192.168.Y.Y)


Si les PS ne communiquent qu'en ethernet brut et pas en IP, AMA il n'est
pas utile ni même souhaitable d'attribuer des adresses IP aux interfaces
TAP.

Aussi, je me demande s'il est nécessaire de créer des interfaces TAP
persistantes, et s'il ne serait pas possible de les créer directement
avec vde_switch et vde_plug2tap.

* démarrage de vde_plug2tap pour tap1 et tap2

* démarrage du process ps1 connecté sur tap1
* démarrage du process ps2 connecté sur tap2
[...]

j utilise les MACADRESS de mes tap1 a tapX mais elles sont attribuée
aléatoirement peut ton les fixer ?


Ça doit être faisable de la façon habituelle avec ifconfig ou ip, de
préférence avant de les activer :

ifconfig tapX hw ether xx:xx:xx:xx:xx:xx
ou
ip link set tapX address xx:xx:xx:xx:xx:xx

Publicité
Poster une réponse
Anonyme