Table des matières
VPN Bridge TAP
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~~
Introduc
Principe
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.
Reseau ⇐⇒ [ eth1 + tap ] ⇔ OpenVPN ⇐⇒ LAN a la con ⇐⇒ OpenVPN ⇔ [ tap + eth1 ] ⇐⇒ Reseau |
couche 2
“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.
scripte
Beaucoup (tous?) utilisent un script pour demarrer OpenVPN avec tap
… WTF ?
On n'a pas besoin de cela.
solution
- 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)
Pré-requis
packages
# aptitude install openvpn bridge-utils
sysctl
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é !
Interfaces
à la main
interface tap
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 ?
bridge
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.
dans /etc/network/interfaces
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 |
Monter le bridge:
# ifup br0
Que ce passe-t-il ?
- le bridge se monte
- l'interface
tap0
est créé allow-hotplug
implique le montage de l'interface correspondante.- 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…
Notes
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?
OpenVPN
Il faut 2 machines…
simple
Sans authentification et sans chiffrement. (si on est sur un reseau local de confiance…pourquoi pas.)
serveur
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
client
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
resultat
- Le client se connecte au serveur.
- les reseaux se voient
nice 10 , c'est parce que j'aime pas trop voir OpenVPN bouffer 90% du CPU lorsqu'il y a une montée en charge |
Clef symétrique
# cd /etc/openvpn # mkdir keys # chmod go-rwx keys # cd keys # openvpn --genkey --secret secret-tap.key
authentification
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 |
chiffrement
#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).
Bilan
udp
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…
sans OpenVPN | auth none + cipher none | auth sha1 + cipher none | auth sha1 + cipher blowfish |
900 Mb/s | 350 Mb/s | 300 Mb/s | 260 Mb/s |
Hum…
Avec “fast-io” (experimental) , on peut atteindre 400 Mb/s …
tcp
Mystérieusement (pour moi), ça fonctionne plus vite en “tcp” … pas loin des 450 Mb/s avec l'authentification.
shaper n
Seems don't work like expected.
final
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.