En quête d'un moyen de connecter plusieurs reseaux au niveau de la “couche 2” : Ethernet.

OpenVPN TAP en Bridge… mais trés simple et sans scripte particulier…

~~READMORE~~

On a une interface ( eth1 dans ce blabla ) qui voit un reseau Ethernet. Peu importe ce qu'il y a dedans.

On a besoin de propager ce reseau sur un autre domaine, et vice et versa.

Pour cela , on va devoir utiliser OpenVPN avec une interface tap.

L'interface tap doit être bridgé avec eth1 : Bridge ⇒ toutes les interfaces dedans sont dans le même réseau.

D'un autre côté (via eth0 surement), OpenVPN encapsulera les données à l'intention de l'autre OpenVPN , et vice versa.

“couche 2” : pas besoin de s'attarder sur la couche 3, l'IP par exemple.

Beaucoup (tous?) de documentations parlent de monter une interface tap avec une IP … WTF ?

On n'a pas besoin de cela.

Beaucoup (tous?) utilisent un script pour demarrer OpenVPN avec tap … WTF ?

On n'a pas besoin de cela.

• Debian permet de créer les interfaces tap et de les monter, a la volée.
• OpenVPN sait déjà demarré tout seul
• La notion client/serveur est trop lourde pour la mise en place: on utilisera le “p2p” ! (euh, point-to-point)

# aptitude install openvpn bridge-utils

Preparer le fichier /etc/modules avec au moins:

bridge

Sans attendre le prochain reboot, monter le module “bridge” :

# modprobe bridge

On peut eventuellement ajouter des trucs comme ça dans /etc/sysctl.d/local.conf :

# Les requetes ARP ne traversent pas
net.ipv4.conf.all.arp_ignore=1
# desactiver le "tracking" sur le bridge
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Appliquer:

# sysctl -p /etc/sysctl.d/local.conf

Si y a une erreur, c'est peut être que le module “bridge” n'est pas chargé !

OpenVPN a d'abord besoin d'une interface tap .

En pratique, OpenVPN créé lui-même l'interface tap si elle n'existe pas déjà. Mais on fait un test “à la main” pour illustrer.

En créer une:

# ip tuntap add dev tap0 mode tap

Voila.

La supprimer:

# ip tuntap del dev tap0 mode tap

Simple non ?

Soit un bridge , on ajoute l'interface tap (précédement créé!) dans le bridge comme cela:

# brctl addif br0 tap0

Où br0 est le bridge, et tap0 est l'interface tap .

Supprimer l'interface du bridge:

# brctl delif br0 tap0

Easy.

On suppose qu'on veut bridger l'interface eth1 :

Finalement, voila comment il convient de faire “propre” dans Debian:

# bridge
auto br0
iface br0 inet manual
      bridge_ports eth1
      bridge_stp off
      bridge_maxwait 0
      # ---- Normalement , OpenVPN créé lui-même le tunnel tap ----
      #up ip tuntap add dev tap0 mode tap
      #down ip tuntap del dev tap0 mode tap
      # ------------------------------------------------------------

# tap
allow-hotplug tap0
iface tap0 inet manual
      up ip link set $IFACE up
      up /usr/sbin/brctl addif br0 $IFACE
      down /usr/sbin/brctl delif br0 $IFACE

Il faut monter l'interface tap avec ip link set tap0 up

des (petits) paquets “dropped” m'obligent à ajouter aussi txqueuelen 1000 : voir “txqueuelen 1000” dans les configurations des VPNs

Monter le bridge:

# ifup br0

Que ce passe-t-il ?

1. le bridge se monte
2. l'interface tap0 est créé
3. allow-hotplug implique le montage de l'interface correspondante.
4. l'interface tap est alors ajouté au bridge.

Voila.

Et pour l'arrêt:

# ifdown br0

On peut faire la même chose avec un scripte…

Si l'interface tap voulu n'existe pas , OpenVPN la créera automatiquement.

En conséquence: dans la configuration du bridge, il n'est pas besoin d'ajouter:

up ip tuntap add dev tap0 mode tap
down ip tuntap del dev tap0 mode tap

Car la création de “tap0” sera faite par “OpenVPN”

Il faudra au préalable s'assurer que le module “tun” est monté:

echo "tun" >> /etc/modules

modprobe tun

Pour ce qui est du reste, c'est a dire la section “allow-hotplug …” elle reste vrai:
Toutefois, on peut pousser la configuration de l'IP par le serveur… dans la mesure ou cette topologie client/serveur est mis en place.

On y reviendra ultérieurement… ou pas?

Il faut 2 machines…

Sans authentification et sans chiffrement. (si on est sur un reseau local de confiance…pourquoi pas.)

Configuration du “serveur” (dans le sens où il attend le “client”), par exemple dans /etc/openvpn/conf/server_tap.conf :

#local localhost

port 1195
proto udp

dev tap0
dev-type tap

mode p2p

auth none
cipher none

# The keepalive directive causes ping-like
keepalive 10 120

txqueuelen 1000

nice 10 

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup

# Because we downgrade privileges:
persist-tun
persist-key

comp-lzo

status /etc/openvpn/server-tap-openvpn-status.log

#verb 5
verb 3

Activer la conf pour quel demarre a chaque reboot.

# ln -s /etc/openvpn/conf/server_tap.conf /etc/openvpn/

Démarrer le serveur:

# /etc/init.d/openvpn start server_tap

Même chose, mais le fichier s'appele /etc/openvpn/conf/client_tap.conf et dedans (peu de modification):

remote <IP_DU_SERVER> 1195

proto udp

dev tap0
dev-type tap

mode p2p                                                                                                  

auth none
cipher none

# The keepalive directive causes ping-like
keepalive 10 120

txqueuelen 1000

nice 10

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup

# Because we downgrade privileges:
persist-tun
persist-key

comp-lzo

status /etc/openvpn/client-tap-openvpn-status.log

#verb 5
verb 3

Remplace <IP_DU_SERVEUR> par ce qu'il convient.

Activer la conf pour quel demarre a chaque reboot.

# ln -s /etc/openvpn/conf/client_tap.conf /etc/openvpn/

Démarrer le serveur:

# /etc/init.d/openvpn start client_tap

1. Le client se connecte au serveur.
2. les reseaux se voient

# cd /etc/openvpn
# mkdir keys
# chmod go-rwx keys
# cd keys
# openvpn --genkey --secret secret-tap.key

La clé doit être la même sur les 2 machines (bien sur!).

Modifier la conf pour avoir:

#auth none
secret /etc/openvpn/keys/secret-tap.key

cipher none

Relancer: l'authentification est faite. Sans la clé, pas d'authentification, et donc pas de communication.

10% de perte de débit entre les 2 clients ( compression ? )

Il y a authentification, mais pas chiffrement de la communication

#auth none
#cipher none
secret /etc/openvpn/keys/secret-tap.key

Equivalent par defaut a (dixit la doc): auth sha1 et cipher bf-cbc (blowfish).

Lien: http://sourceforge.net/mailarchive/message.php?msg_id=27365978

My point of view about above: this is a CPU overhead problem, not a network bottleneck issue.

Un tunnel créé entre machine Xen montrent une chute du débit de 900Mb/s à 350Mb/s …

Ce n'est pas dramatique mais un peu contrariant, surtout que OpenVPN monte rapidement en charge (autour de 80%) dés que la quantité de données a échanger augmente…

Hum…

Avec “fast-io” (experimental) , on peut atteindre 400 Mb/s …

Mystérieusement (pour moi), ça fonctionne plus vite en “tcp” … pas loin des 450 Mb/s avec l'authentification.

Seems don't work like expected.

J'ai laissé en “udp” mais aujouté un petit “nice 10” dans les conf , afin qu'OpenVPN ne bouffe pas trop de ressource CPU au détriment du Dom0 Xen.