[Résolu] OpenVPN et bridge

Support Debian
#1

Bonjour,

Je viens vous demander un peu d’aide après quelques jours de recherches infructueuses…

Mon problème est l’installation du bridge pour OpenVPN, voici ma config:

# uname -r 2.6.20.6dedibox-r7-beta1

# lspci 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01)

[code]# ifconfig
eth0 Lien encap:Ethernet HWaddr 00:40:63:E4:6C:63
inet adr:88...* Bcast:88...* Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:330490 erreurs:0 :0 overruns:0 frame:0
TX packets:119036 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:136161087 (129.8 MB) Octets transmis:19421866 (18.5 MB)
Interruption:18 Adresse de base:0xfc00

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
Packets reçus:191865 erreurs:0 :0 overruns:0 frame:0
TX packets:191865 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:17201083 (16.4 MB) Octets transmis:17201083 (16.4 MB)

[/code]

Alors voilà, après avoir testé avec succès OpenVPN en mode tun routed et Samba, je décide de passer OpenVPN en mode bridge car le mode routed ne correspondait pas à mes besoins. C’est là que les ennuis commencent… Je récupère donc la version précédente du kernel dedibox pour pouvoir le recompiler avec le bridge activé, ok j’y suis finallement parvenu, j’installe donc bridge-utils et compagnie.
Mon but est de pouvoir interconnecter des PC de différentes IP internet dans le même LAN local.
Mon problème est donc que n’étant pas un expert en réseaux ni en linux, j’ai du mal à saisir le concept du bridge avec une seul carte eth0, je me demande si je dois effectuer le bridge sur l’interface locale lo. De plus j’ai suivi différents tuto très bien faits dont celui-ci viewtopic.php?t=4376 mais étant connecté a distance à ma dedibox, je suis systématiquement déconnecté quand je monte le bridge (br0) et je n’ai donc plus accès au serveur (ne répond plus au ping), j’utilise alors la connexion de secours pour tout rétablir…
Je précise que j’ai essayé différente méthodes, bridge-start ou autres scripts, mais je ne suis pas sur de mes réglages.

Voilà, si on peut éclairer ma lantèrne ce sera bien sympa, merci ! :wink:

#2

Le bridge n’a aucun sens avec une seule interface: il sert à connecter deux segments de réseau. Pour connecter un client sur un serveur, le mode routé suffit.
Bridger sur lo me parait incongru, dangereux pour la sécurité, et sans aucune utilité.
Pourquoi as tu besoin de bridger ?

#3

J’avais d’abord testé le mode tun et cela marchait très bien sauf que les PC n’apparaissaient pas dans le voisinage réseau windows ni dans le LAN des jeux, ce que je voulais à la base. J’ai lu par la suite qu’il fallait utiliser le mode bridge pour faire cela. Désolé si mon problème parait incongru, j’essaie de comprendre comment le mode bridge fonctionne et je me fourvoie peut être totalement… :blush:
Merci mattotop pour ta réponse rapide en tout cas.

#4

Ah oui. Je n’avais pas pensé aux besoins de fonctionnalités arp.
Alors ce que tu peux faire, plutot que de bridger sur lo (c’est dangereux, il y a des services critiques qui n’écoutent que par là pour des questions de sécurité), c’est de te créer un switch virtuel avec vde2 sur lesquelles tu vas plugger tes clients.

Tu installes vde2, et tu lis zless /usr/share/doc/vde2/README.Debian.gz
Dans ton /etc/network/interfaces, tu mets:

auto vde0 iface vde0 inet manual vde2-switch -ensuite, tu lui fais jouer le rôle d’eth0 dans mon tuto que tu as cité plus haut, et ça devrait marcher.

#5

Il n’y a pas que l’ARP mais aussi tout ce qui utilise des broadcasts, ainsi que les protocoles non IP.

On ne peut pas associer l’interface de loopback lo à un pont ethernet, elle n’est pas de type ethernet.

De toute façon, contrairement à ce qu’indiquent la plupart des tutoriels sur le pontage, pour créer un LAN virtuel entre des tunnels OpenVPN en mode TAP il n’est pas nécessaire d’associer au pont une interface autre que les interfaces tapX d’OpenVPN. Et pour rappel, surtout pas l’interface ethernet physique de la dedibox, cf. la discussion récente dans proxad.dedibox.discussions.

D’une façon ou d’une autre il suffit de faire l’équivalent de :

brctl addbr br0
ifconfig br0 up
brctl addif br0 tapX
brctl addif br0 tapY
[...]

PS: le noyau 2.6.20.6dedibox contient de graves failles de sécurité, il est plus que temps d’en changer !

#6

quote="PascalHambourg"
On ne peut pas associer l’interface de loopback lo à un pont ethernet, elle n’est pas de type ethernet.[/quote]Ah ? Ok .[quote=“PascalHambourg”]De toute façon, contrairement à ce qu’indiquent la plupart des tutoriels sur le pontage, pour créer un LAN virtuel entre des tunnels OpenVPN en mode TAP il n’est pas nécessaire d’associer au pont une interface autre que les interfaces tapX d’OpenVPN. Et pour rappel, surtout pas l’interface ethernet physique de la dedibox, cf. la discussion récente dans proxad.dedibox.discussions.

D’une façon ou d’une autre il suffit de faire l’équivalent de :

brctl addbr br0
ifconfig br0 up
brctl addif br0 tapX
brctl addif br0 tapY
[...]

PS: le noyau 2.6.20.6dedibox contient de graves failles de sécurité, il est plus que temps d’en changer ![/quote] Aprés, le problême vient de ce que ça nécessite un script avancé rc.local . Personellement, je préfère tout centraliser dans le fichier interfaces, et il ne me semble pas qu’on puisse créer un bridge sans qu’il ait un device initial.

#7

Salut,

Merci pour vos réponses… mattotop je vais étudier ta solution de device virtuel et essayer de la mettre en place, merci pour le coup de main !
PascalHambourg j’avais mis le dernier kernel, mais il était compilé sans le bridge et dedibox ne fournit que les sources de leurs avant-derniers noyaux… donc j’ai dû compiler celui là. Sinon tu proposes de monter 2 interfaces tap et de les bridger ensemble ? J’arrive mieux à visualiser la solution du switch virtuel mais c’est surement le même principe.
Bon j’étudie tout ça, je fais des tests et je vous tiens au courant. Encore merci à vous ! :wink:

#8

Pour s’en convaincre il suffit d’essayer, brctl couine.

Si, en spécifiant “bridge_ports none”. Au pire, on peut lui associer une interface “dummy”.

Si les interfaces tapX sont créées dynamiquement par OpenVPN, lors de l’établissement d’un VPN on peut lui faire invoquer un petit script qui associe l’interface créée au pont - s’il n’y a pas déjà une option qui le fait.

Si les interfaces tapX sont créées statiquement une fois pour toutes avec tunctl, on peut tout gérer dans le fichier interfaces. Exemple :

interface inet tap0 manual
  tunctl_user <proprietaire>
[...]
interface inet br0 static
  bridge_ports tap0 [...]

Ce ne sont que des pistes, je ne l’ai jamais fait moi-même.

#9

C’est mal de leur part ! Et surtout, n’est-ce pas contraire à la GPL ? Ce coup-ci ils ne peuvent pas prétendre que le noyau n’est pas distribué à l’utilisateur, comme ils l’ont faut pour le firmware de la Freebox.
Sinon, pas possible d’installer un noyau Debian standard ou de prendre les sources de kernel.org ?

Oui.

Moi c’est plutôt le switch virtuel que je n’arrive pas trop à visualiser, et comment on le raccorde aux interfaces TAP !

#10

Core: si tu as compris ce que dit PascalHambourg, c’est que tu peux te passer de vde2, et utiliser juste bridge_ports none dans mon tuto, là ou je mettais eth0.
Je ne savais pas que c’était possible.
PascalHambourg: c’est l’ajout de vde0 en plus des différents taps dans le bridge, qui fait la connection. Les fonctionnalités de plug de vde ne sont pas utilisées, et les taps ne sont pas pluggées dans le vde.
Mais je me demande s’il n’y aurait pas moyen de plugger les tuns en mode routé pour les faire fonctionner comme s’ils étaient bridgés.

#11

Moi non plus, mais j’ai cherché. :smiley:

La connexion avec quoi ? Si j’ai bien compris, le besoin c’est juste que les TAP soient connectés entre eux.

Dans ce cas à quoi sert le vde, puisque si je t’ai bien compris, il faut aussi un pont et y associer les TAP ?

Aucune idée, mais ponter des interfaces TUN en mode routé ça me paraît assez peu orthodoxe, pour ne pas dire que ça fleure l’hérésie.

#12

Moi non plus, mais j’ai cherché. :smiley: [quote]c’est l’ajout de vde0 en plus des différents taps dans le bridge, qui fait la connection.[/quote]La connexion avec quoi ? Si j’ai bien compris, le besoin c’est juste que les TAP soient connectés entre eux.[/quote]Si tu préfères: c’est l’ajout des différents taps dans le même bridge qui fait la connection entre eux. [quote=“PascalHambourg”][quote]Les fonctionnalités de plug de vde ne sont pas utilisées, et les taps ne sont pas pluggées dans le vde.[/quote] Dans ce cas à quoi sert le vde, puisque si je t’ai bien compris, il faut aussi un pont et y associer les TAP ?[/quote]A rien, je l’utilisais comme dummy autour duquel bridger, parceque je ne savais pas qu’on pouvait s’en passer: c’est toi qui a donné le moyen de s’en passer. [quote=“PascalHambourg”] [quote]Mais je me demande s’il n’y aurait pas moyen de plugger les tuns en mode routé pour les faire fonctionner comme s’ils étaient bridgés.[/quote] Aucune idée, mais ponter des interfaces TUN en mode routé ça me paraît assez peu orthodoxe, pour ne pas dire que ça fleure l’hérésie.[/quote] Non, je n’ai pas dit ça, mais les plugger sur le même switch virtuel vde les met en connexion pour le broadcast >comme si< elles étaient bridgées: les tuns qui sont des interfaces séparées se retrouvent cablées sur un même switch et fonctionnent comme les taps fusionnées dans le bridge.

#13

Ok, grace à vos explications je crois que je commence à comprendre…

[quote=“mattotop”]Core: si tu as compris ce que dit PascalHambourg, c’est que tu peux te passer de vde2, et utiliser juste bridge_ports none dans mon tuto, là ou je mettais eth0.
[/quote]

Ok, je vais essayer de mettre en place tout ça, je vais réinstaller openVPN avant, car j’avais installé à partir de webmin, ce qui etait bien pratique pour la gestion des certificats mais ça devient un peu fouilli là. Ensuite je suis ton tuto mattotop avec les modifs que tu m’as indiqué.
Je vous donne mes résultats dès que c’est fait, merci encore pour votre aide à tous les deux ! :wink:

#14

Je comprends mieux maintenant. Je pensais que c’était une alternative au pont. Ce n’est pas un peu riche d’utiliser vde juste comme interface bidon ? D’autant plus qu’il n’est pas dans etch, ni dans les backports apparemment.
Indépendamment de l’option “bridge_ports none” pour créer un pont sans ports, il y avait d’autres méthodes plus légères pour créer une interface ethernet bidon comme le module dummy.

Qu’est-ce que tu entends par “plugger” ?
J’avoue que j’ai du mal à appréhender comment un switch virtuel pourrait traiter du trafic IP non encapsulé dans ethernet et savoir ce qui est un broadcast IP et ce qui ne l’est pas. Ce ne serait plus un switch mais un routeur.

#15

Je comprends mieux maintenant. Je pensais que c’était une alternative au pont. Ce n’est pas un peu riche d’utiliser vde juste comme interface bidon ? D’autant plus qu’il n’est pas dans etch, ni dans les backports apparemment.
Indépendamment de l’option “bridge_ports none” pour créer un pont sans ports, il y avait d’autres méthodes plus légères pour créer une interface ethernet bidon comme le module dummy.[/quote] Je n’ai tout simplement pas pensé à dummy.[quote=“PascalHambourg”][quote]les plugger sur le même switch virtuel vde les met en connexion pour le broadcast >comme si< elles étaient bridgées: les tuns qui sont des interfaces séparées se retrouvent cablées sur un même switch et fonctionnent comme les taps fusionnées dans le bridge.[/quote]Qu’est-ce que tu entends par “plugger” ?[/quote] Les tuns étant des cables virtuels apparaissant sur le routeur (entre lesquels il peut se mettre en position de router), et vde étant un switch virtuel, au lieux de router, le routeur peut insèrer (=pluguer) ces cables dans ce switch virtuel, exactement comme des cables réels sortant d’interfaces réelles pourraient être pluguées dans un switch réel.
pwet.fr/man/linux/commandes/vde_plug [quote=“PascalHambourg”]J’avoue que j’ai du mal à appréhender comment un switch virtuel pourrait traiter du trafic IP non encapsulé dans ethernet et savoir ce qui est un broadcast IP et ce qui ne l’est pas. Ce ne serait plus un switch mais un routeur.[/quote] Justement: comme un switch réel, il saura reconnaitre ce qui est à envoyer vers une mac donnée et tout ce qui est à relayer sur tous les ports/plugs.

#16

Merci, je regarde ça (edit à prévoir si j’ai des commentaires). En attendant,

Mais le trafic des interfaces TUN n’est pas encapsulé dans des trames ethernet, il n’y a donc pas d’adresse MAC sur laquelle se baser pour aiguiller les paquets.

PS: Core, pardon de squatter ton fil. :blush:

#17

quote=“PascalHambourg”

Mais le trafic des interfaces TUN n’est pas encapsulé dans des trames ethernet, il n’y a donc pas d’adresse MAC sur laquelle se baser pour aiguiller les paquets.
(…)[/quote] Tu as raison, je comprends ce que tu dis: tun fonctionne au niveau de la couche réseau, sans MAC, donc ce que je dis est inepte. C’est ça d’échaffauder sans tester ni bien tout avoir compris de ce que l’on manipule.
Effectivement, donc, j’ai bien regardé, et vde_plug ne prend que du tap comme argument.

#18

[quote=“PascalHambourg”]
PS: Core, pardon de squatter ton fil. :blush:[/quote]

Lol, non non au contraire, je lis avec intérêt toutes vos propositions et ça m’aide à comprendre pas mal de choses que je ne voyais pas à la base.
Bon, je retourne à mes tests avec le tap et bridge none pour l’instant, encore merci ! :slightly_smiling:

#19

Ce n’est pas moi qui te jetterai la pierre, vu le mal que j’ai à appréhender VDE.

En fait vde_plug ne prend même pas de tap. Si (important, le “si”) j’ai bien compris, la seule interface TAP dans VDE c’est celle qu’on peut créer en même temps que le switch virtuel avec vde_switch pour que la couche réseau de la machine hôte puisse communiquer avec lui. En-dehors de cette interface qui est gérée par vde_switch, on ne peut pas plugger d’autres interfaces TAP locales gérées par d’autres programmes comme openvpn.

Mais je crois que j’entrevois où tu voulais en venir. L’idée, ce serait qu’openvpn (en mode TAP, hein) se plugge et communique directement avec le switch virtuel, au lieu qu’il utilise des interfaces TAP dont on n’a pas l’usage en tant que telles puisque tout ce qu’on veut c’est ponter les VPN ensemble. Par contre je n’ai aucune idée de la faisabilité.

#20

quote="PascalHambourg"
En fait vde_plug ne prend même pas de tap. Si (important, le “si”) j’ai bien compris, la seule interface TAP dans VDE c’est celle qu’on peut créer en même temps que le switch virtuel avec vde_switch pour que la couche réseau de la machine hôte puisse communiquer avec lui. En-dehors de cette interface qui est gérée par vde_switch, on ne peut pas plugger d’autres interfaces TAP locales gérées par d’autres programmes comme openvpn.[/quote]En fait tu as une fois de plus raison, et j’avais un peu vite confondu l’option -tap de vde_switch avec une option de vde_plug ce qu’elle n’est pas (vde_plug ne cause que par socket). MAIS…

[quote=“PascalHambourg”] Mais je crois que j’entrevois où tu voulais en venir. L’idée, ce serait qu’openvpn (en mode TAP, hein) se plugge et communique directement avec le switch virtuel, au lieu qu’il utilise des interfaces TAP dont on n’a pas l’usage en tant que telles puisque tout ce qu’on veut c’est ponter les VPN ensemble. Par contre je n’ai aucune idée de la faisabilité.[/quote] En regardant les commandes du paquet vde2, je suis tombé sur linuxcertif.com/man/1/vde_plug2tap/ qui fait exactement ça: plugger “à chaud” un tap sur un switch existant.
Mais lis aussi zless /usr/share/doc/vde2/README.Debian.gz il y a vraiment des utilisations rigolottes de vde en pipe, entre autre pour créer un vpn crypté ssh en deux temps trois mouvements.