OpenVPN / mode bridgé / client-to-client

Bonjour à tous,
Merci par avance à ceux qui liront.

[HS]
Je sacrifie à la tradition des forums, et je commence par me présenter : Je suis un homme de la Feria, j’aime bien les tartes aux figues et je trempe plus souvent dans le développement que dans l’admin sys, ce qui explique en partie mon ignorance du sujet qui me pose problème aujourd’hui.
[/HS]

Voilà, j’utilise un programme client/serveur qui ne fonctionne qu’en réseau local. Ce n’est pas un problème de temps d’accès, c’est juste qu’il a été programmé ainsi. Or je veux m’en servir entre n machines qui sont loin géographiquement. J’ai donc pensé à utiliser un VPN et notamment le programme http://openvpn.net.

J’ai donc installé un serveur VPN quelque part sur le net (sur une debian dédiée que je loue), je l’ai configuré en mode “routé” après avoir patiemment lu (et compris, j’espère) toute la doc.

Tout marche pour le mieux.

192.168.10.1    192.168.10.3       192.168.10.5   192.168.10.7
Client 1 <----------------          ----------------> Client 2
212.45.7.8                 \       /                  124.187.6.45
                       Serveur 42.57.185.1
111.48.75.4                /       \                  14.124.45.2
Client 3 <----------------          ----------------> Client 4
192.168.10.9    192.168.10.11      192.168.10.13   192.168.10.15

C’est là que j’ai découvert (merci Wireshark) que le client du programme que je souhaite utiliser, se sert de broadcasts pour repérer le serveur. Or, selon la doc, le mode routé ne permet pas d’acheminer les broadcast (et c’est là qu’on touche mon ignorance, je ne comprends vraiment pas pourquoi, mais si c’est feature, c’est feature).

J’essaie donc de configurer le vpn en mode bridgé, de manière à ce qu’il émule un unique réseau local. Et c’est là que ça se complique. En effet, d’après ce que j’ai compris, je ne peux que bridger mes n interfaces réseaux client avec une interface réelle de mon serveur.

192.168.10.2                                        192.168.10.3
Client 1 <----------------          ----------------> Client 2
                          \       /
                       Serveur 192.168.10.1
                          /       \
Client 3 <-----------------         ----------------> Client 4
192.168.10.4                                        192.168.10.5

Autrement dit, j’ai un peu peur que :

  1. Mon serveur n’aie plus accès à internet, une fois que j’ai “réassigné” son interface
  2. Même si j’arrive à faire en sorte qu’il puisse toujours avoir accès, et bien tous les paquets de mes clients soient reroutés vers le réseau local de mon serveur (que je ne maîtrise pas du tout et que je ne veux pas polluer puisqu’il s’agit d’un serveur dédié)

En fait, je n’ai pas du tout besoin que le router soit sur mon réseau local virtuel, je veux juste que mes clients soient sur ce réseau.
Je ne sais pas si je suis clair.

Mes questions sont donc multiples, et je remercie ceux qui m’aideront à avancer dans la résolution de l’une ou de l’autre :

  1. Que dois-je lire pour mieux comprendre le problème, sachant que j’ai lu toute la doc de openvpn, mais qu’il me manque des bases (je ne suis pas sur de comprendre la différence entre tun et tap, je ne sais pas ce que sont les différentes “couches” réseau : ethernet vs ip …
  2. Est-ce qu’il est possible de faire marcher les broadcasts entre deux clients d’un vpn en mode routé ? et comment ?
  3. Est-ce qu’il est possible de bridger les interfaces des clients sans altérer le réseau du serveur ? et comment ?
  4. Est-ce qu’il est possible/raisonnable/secure de créer une carte réseau virtuelle ou une interface virtuelle sur le serveur et de la bridger elle ? Comment ? Quelle est la différence entre l’un et l’autre ?

Merci déjà à tous ceux qui ont lu.
Merci aussi à ceux qui m’aideront.

Bonne journée.

Je répare une omission, même si je ne pense pas que ce soit pertinent : voici la version de ma debian :

$ uname -a Linux becane 2.6.32.2-xxxx-grs-ipv4-64 #1 SMP Tue Dec 29 14:41:12 UTC 2009 x86_64 GNU/Linux

J’ajoute une précision qui semble me conforter dans mes craintes.
On peut lire dans le chapitre “Bridge Server on Linux” de la doc openvpn sur “ethernet bridging” (cf http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html#linuxscript) la phrase suivante :

Bonjour à nouveau.

Suite, mais certainement pas fin du problème.
Deux éléments nouveaux déterrés au fond de forums me permettent d’avancer :

  1. Il semble que le script de bridge (bridge-start) d’open-vpn pour le mode bridge accepte une interface physique bidon (eth = “dummy0”), et qu’à ce moment-là il fasse exactement ce que je veux, c’est à dire ne bridger que les interface virtuelles (tap), c’est à dire celles des clients.

Difficile de vérifier, car le script, s’il accepte le paramètre, me retourne maintenant un “add bridge failed: Package not installed”, qui semble indiquer que mon kernel n’a pas été compilé avec l’option bridge. A vérifier, et surtout à réparer. Je ne suis pas très chaud à l’idée de recompiler un kernel, étant donné qu’il s’agit d’une machine dédiée distante.

  1. Il semble qu’openvpn puisse rerouter les broadcast, y compris en mode routed, a condition qu’il soit configuré pour fonctionner au niveau ethernet (tap) et non pas au niveau tcp/ip (tun). Pour moi c’est presque du chinois.

Pour l’instant, j’ai fait la configuration correspondante, et victoire : mes pings broadcastés coté client arrivent au serveur. Par contre :

  • la réponse du serveur n’arrive jamais
  • les pings n’arrivent pas aux autres clients

A suivre donc

C’était logique, et cela explique pourquoi il ne fonctionne qu’en réseau local (réseau local = domaine de diffusion/broadcast).

En effet. Par définition un broadcast s’adresse à un domaine de broadcast, donc à un réseau local. On distingue le broadcast limité (255.255.255.255) qui s’adresse au réseau local de l’émetteur et ne peut être routé, et le broadcast limité (par exemple 192.0.2.255 pour le réseau 192.0.2.0/24) qui peut être routé (ou pas, selon la politique des routeurs) jusqu’au réseau de destination mais s’adresse encore à un unique réseau local. Il n’y a évidemment pas de broadcast global qui serait destiné à tout l’internet (déjà qu’on a tendance à bloquer le broadcast dirigé).

Il me semblait qu’on pouvait configurer le serveur openvpn pour ponter les clients ensemble sans devoir ponter avec une autre interface.

A priori, non, si chaque client est dans un domaine de broadcast (sous-réseau) séparé.

Bien sûr on peut ponter le VPN avec une interface ethernet factice (dummy). Dans ton cas il ne faut évidemment surtout pas ponter le VPN avec l’interface ethernet physique.
Pour créer une interface factice, il suffit de charger le module dummy et de configurer l’interface dummy0 ainsi créée, comme n’importe quelle interface.

Non, ce message indique que c’est plutôt le paquetage bridge-utils qui n’est pas installé.

tun = IP = routed
tap = ethernet = bridged

Bonjour,

Merci pour ces informations qui sont très claires et rassurantes.

Je n’ai pas trouvé de façon officielle de faire cela dans la doc.
Est-ce que tu valide ma “bidouille” qui consiste à utiliser comme paramètre des script de bridge-utils une interface qui n’existe pas (“dummy0”) ?

[quote=“PascalHambourg”]Bien sûr on peut ponter le VPN avec une interface ethernet factice (dummy). Dans ton cas il ne faut évidemment surtout pas ponter le VPN avec l’interface ethernet physique.
Pour créer une interface factice, il suffit de charger le module dummy et de configurer l’interface dummy0 ainsi créée, comme n’importe quelle interface.[/quote]
Merci !
Donc au pire je ferais cela. Je ne te demande pas plus d’info pour l’instant, car je n’ai pas encore essayé. Je reviendrais vers toi en cas d’échec seulement.

OK, dommage, c’était plus simple. Dans ce cas je laisse tomber.

[quote=“PascalHambourg”]
Non, ce message indique que c’est plutôt le paquetage bridge-utils qui n’est pas installé.[/quote]
Ahh très intéressant, donc je dois avoir un problème de droits, ou une corruption de fichier ou quelque chose comme ça. Je vais investiguer là-dessus, j’ai peut-être arrête trop vite de chercher (face à la menace de recompilation de kernel).

Merci encore !
Je vous tiens au courant.

Bon, c’est pas clair.

$ sudo apt-get install bridge-utils ... bridge-utils est déjà la plus récente version disponible.

Mais d’un autre coté :

$ locate bridge-utils /usr/share/bridge-utils /usr/share/bridge-utils/ifupdown.sh /usr/share/doc/bridge-utils ... /usr/share/doc/bridge-utils/examples/pm-utils /usr/share/man/man5/bridge-utils-interfaces.5.gz /var/cache/apt/archives/bridge-utils_1.4-5_amd64.deb /var/lib/dpkg/info/bridge-utils.list /var/lib/dpkg/info/bridge-utils.md5sums /var/lib/dpkg/info/bridge-utils.postinst

Est-il possible que j’aie une version trop récente de bridge-utils ?

Je rappelle mon problème :

$ sudo brctl addbr "br0" add bridge failed: Package not installed $ sudo brctl show bridge name bridge id STP enabled interfaces

Je précise que :

$ sudo locate brctl /usr/sbin/brctl /usr/share/man/man8/brctl.8.gz

Bon, je vous tiens au courant …

Au temps pour moi, j’ai répondu trop vite.
Cette erreur semble se produire quand le noyau ne supporte pas le pontage ethernet. Comme j’avais aussi lu trop vite, je n’avais pas vu que ce n’était pas un noyau Debian standard (qui supporte le pontage). Il faut vérifier si ce noyau a été compilé avec l’option BRIDGE activée en dur (=y) ou en module (=m).

zgrep BRIDGE /proc/config.gz grep BRIDGE /boot/config-$(uname -r)

+1 pour le respect de la langue

[quote=“PascalHambourg”]

zgrep BRIDGE /proc/config.gz grep BRIDGE /boot/config-$(uname -r)[/quote]

J’obtiens un magnifique :

et je n’ai aucun fichier commençant par “conf” dans le répertoire "/boot"
Je pense que c’est râpé pour un bridge.

Cela dit, mon problème est résolu, car en configurant openVPN en mode routé (sans bridge en tout cas), mais au niveau tap, il re-route bien les broadcast et donc mon programme marche malgré le fait que chaque zone géographique ait un sous-réseau propre.

Cela dit, je me doute que ça doit poser des problèmes dans certains cas, j’ai juste la chance de ne pas être dans un de ceux-là.

Merci encore !

A tout hasard, si quelqu’un a le même problème, voici mon fichier de conf coté server :

[quote]port 3328
proto udp
dev tap
ca ca.crt
cert crt.crt
key key.key
dh dh.pem

server 192.168.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS ipdundns"
push "dhcp-option DNS ipdunautredns"

client-to-client
keepalive 10 120
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 6
[/quote]
En rouge ce qui me semble important pour le problème en question
En bleu ce qu’il faut changer, car c’est propre à ma machine