Install openvpn en mode bridge

Trucs et Astuces
#1

Openvpn est un service vpn trés sûr, super stable, et d’enveloppe légère (la qualité enfonce largement PPTP), relativement simple à mettre en place, même si j’ai galéré à comprendre sa simplicité, et bourré de fonctionnalités utiles (cf la doc sur openvpn.org )…

Indépendamment des cas évidents ou l’on a besoin de connecter de manière sûre des sites distant, c’est un bon outil pour faire transiter des données jusqu’à une passerelle et travailler en wifi, le tout avec un bon niveau de sécurité.
Par ailleurs la version windows fonctionne aussi bien et se configure à peu prés de la même manière (et oui, on a parfois des clients windows à gèrer aussi, il faut s’en souvenir).

Phase 1 : prérequis, pré-installation des paquets nécessaires

Attention
En fin d’install, il y a des modifications à vérifier :

  • Créer un user/group openvpn avant de lancer le script.
  • Penser à changer l’interface d’écoute eth0 en br0 dans par exemple les fichiers de routage, de configuration diverses de serveurs (Squid, Samba, etc) ET surtout dans /etc/default/dhcp

openvpn plante parfois avec un noyau 2.4, il vaut mieux utiliser un 2.6.
Par ailleurs, quoi que je ne l’ai pas testé pour des raisons diverses, il est conseillé d’utiliser un noyau sur lequel est appliqué le patch grsecurity, trouvable sur grsecurity.net/ .

Votre noyau doit comporter les options actives suivantes :

Installations
Sur le serveur debian :

apt-get install bridge-utils openvpn openssl libssl-dev liblzo1 liblzo-dev

Sur le client debian :

apt-get install openvpn liblzo1

Tous ces paquets peuvent être pris en source et recompilés plus finement bien sûr dans le cas d’un serveur d’accès dédié.

Phase 2 : mise en œuvre de la PKI
Pour l’authentification, nous allons mettre en œuvre une PKI ( “Public Key Infrastructure”=Infrastructure de clé publique ), et identifier un à un les clients du serveur d’accès, en utilisant le jeu de scripts easy-rsa fourni par le paquet openvpn

Préparation
Commencez par recopier, dans un coin sûr, le répertoire
/usr/share/doc/openvpn/examples/easy-rsa

$ cp -R /usr/share/doc/openvpn/examples/easy-rsa/ .

Passez en root, et sécurisez le répertoire:

# chown -R root.root easy-rsa
# chmod -R 0700 easy-rsa

Descendez dans le répertoire.
La première étape consiste à modifier les variables communes à la génération des différentes clés.
Ces variables sont à ajuster dans le fichier vars

Voici un exemple:

À partir de maintenant, chaque fois que vous reviendrez générer des clés ou faire une opération de clé,
pensez à “sourcer” ce fichier avant pour mettre à jour votre environnement :
# . ./vars

Ensuite :

# mkdir keys
# touch keys/index.txt
# echo 01 > keys/serial
# chmod -R 0700 keys

Préparation des clés du serveur :

# ./build-dh
# ./build-ca
# ./build-key-server serveur

(ndr : à étoffer)

Et d’un client :

./build-key client

(ndr: à etoffer)

A l’issue de ces manœuvres on se retrouve avec les fichiers suivants dans keys :

-rwx------ 1 root root    0 2008-09-18 18:58 index.txt.old
-rwx------ 1 root root    3 2008-09-18 18:59 serial.old
-rw-r--r-- 1 root root  245 2008-09-18 19:00 dh1024.pem
-rw------- 1 root root  887 2008-09-18 19:01 ca.key
-rw-r--r-- 1 root root 1224 2008-09-18 19:01 ca.crt
-rw------- 1 root root  887 2008-09-18 19:01 serveur.key
-rw-r--r-- 1 root root  680 2008-09-18 19:01 serveur.csr
-rw-r--r-- 1 root root 3647 2008-09-18 19:01 serveur.crt
-rw-r--r-- 1 root root    3 2008-09-18 19:01 serial
-rw-r--r-- 1 root root   21 2008-09-18 19:01 index.txt.attr
-rw-r--r-- 1 root root  105 2008-09-18 19:01 index.txt
-rw-r--r-- 1 root root 3647 2008-09-18 19:01 01.pem
-rw-r--r-- 1 root root  887 2008-09-18 19:03 client.key
-rw-r--r-- 1 root root  688 2008-09-18 19:03 client.csr
-rw-r--r-- 1 root root    0 2008-09-18 19:03 client.crt

Les fichiers .key sont les clefs privés du serveur, du client et du serveur d’authentification (ca.key).
Les fichiers .crt sont les certificats correspondants.
dh1024.pem est un paramètre Diffie Hellman [à expliquer, m’a l’air curieux ce truc]
permettant apparemment de sécuriser les transferts contre une attaque man-in-the-middle

Pour notre utilisation, il faut en fait mettre ces fichiers dans le répertoire /etc/openvpn

# cp ./keys/ca.crt /etc/openvpn/
# cp ./keys/ca.key /etc/openvpn/
# cp ./keys/serveur.crt /etc/openvpn/
# cp ./keys/serveur.key /etc/openvpn/
# cp ./keys/dh1024.pem /etc/openvpn/

Notes:

  • N’oubliez pas d’utiliser des CN (Common Name) unique pour chaque participant duVPN (serveur, et chaque client), sinon votre serveur ne fonctionnera pas !
    Mettez aussi un ON (Organization Name) commun au serveur et aux clients.
  • N’utilisez pas de fqdn pour désigner votre serveur et vos clients,
    openvpn n’aime pas les clés avec un nom de fichier long avec une arobase dedans.
    Je n’ai pas réussi à savoir pourquoi, mais certains noms fqdn passent, d’autres non.
  • Ne transférez pas vos clés par un canal non sécurisé.
    L’idéal est de stocker le répertoire keys sur une clé usb et rien sur la machine,
    mais on peut aussi utiliser le user openvpn pour les transférer en scp (puisque le user root doit si vous êtes raisonnable être désactivé pour ssh).
  • Une précaution supplémentaire est d’utiliser une solution TLS et de générer une clé supplémentaire pour éviter les interceptions de clé (attaque “Man in the Middle”).
    Vous pourrez trouver un exemple de config ici : nbs-system.com/article/openvpn2_howto.
    Pour les paranos, ce tuto effectue un chroot du serveur en plus de la démarche que je décris ici, et il est en français.

Ça y est, vous pouvez annoncer à tout le monde que vous avez votre propre PKI (la frime) :wink:

Configuration du serveur
Comme je l’ai indiqué dans le titre, ce tuto propose une configuration en mode pont ("Bridged"), en opposition au mode routé ("Routed").
Ponté ou non, openvpn utilise un mécanisme appelé Tun/Tap, qui est une sorte de “câble virtuel” entre le client et le serveur, et qui se traduit des deux cotés par l’ajout d’une interface (tunX en routé, tapX en ponté).
Le mode routé est facilement compréhensible, à savoir qu’il faut configurer, une fois le “câble” branché, les tables éventuelles de routage sur le client et le serveur qu’on considère alors comme des routeurs.
Cette configuration est plutôt simple, mais nécessite d’utiliser un réseau “à part” pour l’interface d’entrée du serveur et les clients, augmente d’un hop la distance entre les deux lan connectés, et ne permet pas de transférer d’autres protocoles que ceux qu’iptables sait router (pas d’ipx, ni de - beurk - netbios, par exemple).
Pour info, il suffit d’installer la config serveur openvpn d’exemple, de modifier un peu les valeurs, et de configurer un peu de routage.

Config sur le serveur (dans /etc/openvpn/server.conf, par exemple)

port 5555
proto udp
dev tap0

ca ca.crt
cert serveur.crt
key serveur.key
dh dh1024.pem

ifconfig-pool-persist ipp.txt

server-bridge 192.168.0.1 255.255.255.0 192.168.0.151 192.168.0.250

keepalive 10 120
comp-lzo

user openvpn
group openvpn

persist-key
persist-tun
status openvpn-status.log
verb 1

Démarrage d’openvpn
À l’installation, openvpn est configuré pour démarrer avec la machine.
Pour le mode ponté, cela n’est pas souhaitable, car cela pose des problèmes si le pont n’est pas bien configuré à ce moment-là.

Pour désactiver le service :

update-rc.d -f openvpn remove

Plutôt que d’utiliser un script pour lever le bridge comme beaucoup de tutos non spécifiques debian font,
nous allons utiliser les scripts de levées d’interface dans /etc/network/interfaces
C’est le bridge qui va désormais hériter des caractéristiquesd de la carte vers le lan.

Considèrons dans notre exemple que la carte (la seule dans notre exemple) vers le lan est eth0 configurée en static 192.168.0.1/24.
On aura alors:

  • /etc/network/interfaces
auto lo br0
iface lo inet loopback
iface br0 inet static
       address 192.168.0.1
       netmask 255.255.255.0
       broadcast 192.168.0.255
       bridge-ports eth0
       post-up /etc/openvpn/scripts/ovup && /etc/init.d/openvpn start
       pre-down /etc/init.d/openvpn stop
       post-down /etc/openvpn/scripts/ovdown
  • /etc/openvpn/scripts/ovup
#!/bin/sh
openvpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig eth0 promisc up
ifconfig tap0 promisc up
ifconfig br0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255
  • /etc/openvpn/scripts/ovdown
#!/bin/sh
openvpn --rmtun --dev tap0

Config sur le client :
Sur le client, un fichier de config suffit :

  • /etc/openvpn/client.conf
client
dev tap0
proto udp
remote adresse.du.serveur 5555
resolv-retry infinite
nobind
user openvpn
group openvpn
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 1

Conclusion
N’hésitez pas à regarder les fichier d’exemple de configuration dans
/usr/share/doc/openvpn/examples
Je ne peux que vous renvoyer à nbs-system.com/article/openvpn2_howto qui s’est encore affiné depuis le début de la redaction de ce post.

1 J'aime
Digression sur la sécurité et l'utilisation de selinux vs apparmor vs grsecurity
#2

cool merci pour l’initiative, ca risque de me servir :slightly_smiling:

#3

Terminé.

#4

Je passe de plus en plus pour un con quand les gens me voient me branché chez moi avec un fil, meme les plus attardé en informatique ont maintenant le wifi chez eux. Bon la plus part du temps ya meme pas une clef WEP, mais il s’en foutent l’ignorance les proteges :unamused:

Enfin voila j’ai une carte wifi sur mon PC fix et je voudrais que moi ou des visiteurs puissions nous brancher dessus, mais tu parle d’un logiciel client pour windows, ca craint ca y a pas moyen de faire sans ? il doit bien avoir des outils vpn intégré a windows XP ?

Ha oui question subsidiaire, je n’habite pas en france et je me contre fous des limitations sur le cryptage. Je ne connais pas la lois ici, mais je suis certain que c’est le dernier de leur soucis a eux aussi de respecter ce genre de norme imposé par des gouvernement big brother style. Alors quel genre de clef me conseils tu ?

#5

Si ipsec, mais c’est ingèrable sous lin, et pptp qui est cassable en 3 minutes.
Mais le client windows se télécharge et s’installe en 10 minutes, et aprés, il faut deux secondes pour copier la PKI et la config depuis une clé usb. Une fois installé, le tunnel est actif définitivement sans toucher à rien si le service est actif et le point d’accés répond.

Je ne sais pas. Je me fous de la legislation française en la matière (en plus, je crois qu’elle a évolué), et par principe, j’ai pris la taille qui etait conseillée qui est un compromis entre une cle trop faible qui n’apporte pas de securité, et une clé trop grosse qui ralentit le cryptage/decryptage.

#6

oui tu as raison installé un logiciel n’est pas si genant puisque il faudra bien faire passé la clef de toute facons, mais ca perd de sa spontanéité c’est ca qui est un peu domage…

#7

Ah oui, ça. Peut être que de windows à windows, la mise en oeuvre d’ipdec est plus simple, mais j’en doutes. :cry:

#8

Si la spontanéité sinifie se priver de protection je dis non :laughing:

#9

J’ai lu quelques trucs a propo de WPA pro ca parait etre un bon compromis, je ne me suis toujours pas décidé en tout cas, je n’ai pas eu trop le temps ces derniers temps.
Mais quand je vois que en me rapprochant bien de mon balcon j’arrive a détecté un reseau de l’ambassade du mexique non protégé je me dis que je suis quand meme bien plus parano que la moyenne! (preuve je n’ai pas essayé de me connecté de peur que ce soit un genre de piege :laughing: )

#10

vu comment le fonctionnement d’openvpn est transparent une fois en place, faut pas se priver de sécuriser tout ce qu’on fait.

#11

How to bridge networks with OpenVPN
( Tuesday November 21, 2006 )
linux.com/article.pl?sid=06/11/07/213217

#12

J’explique mieux. 8)

#13

Ah oui c’est pas comparable
:wink:

#14

Je rajouterais bien les précisions suivantes:

Le fichier configurant le serveur est /etc/openvpn/server.conf

Sinon, pourquoi mettre les interfaces en mode promiscuous???

ifconfig eth0 promisc up
ifconfig tap0 promisc up

je n’arrive pas à voir l’intérêt…
[edit: En fait, elles se mettent d’emblée dans ce mode]

Sinon, je confirme que c’est particulièrement pratique, j’ai essayé avec ipsec+strongswan, c’est incomprehensible.

#15

fait.

Et c’est partout fait comme ça, alors j’ai fait comme ça. Ca doit être lié à l’ “apprentissage” du bridge.

intègré.

A noter que l’empaquetage debian s’est amélioré, et je n’ai pas encore eu le temps d’y mettre mon nez, mais tout doit pouvoir maintenant être configuré sans script, juste avec de la syntaxe avancée dans
/etc/network/interfaces, et des choses en plus dans le server.conf . A voir.

#16

Sur Etch, j’ai finalement configuré openVPN comme suit:

Fichier interfaces :

Fichier /etc/init.d/vpn

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="VPN"
NAME=vpn
SCRIPTNAME=/etc/init.d/$NAME


[ -r /etc/default/$NAME ] && . /etc/default/$NAME

. /lib/init/vars.sh

. /lib/lsb/init-functions

do_start()
{
        /etc/init.d/openvpn start
        ifconfig tap0 0.0.0.0 promisc up
        brctl addif br0 tap0
        ifconfig br0 192.168.0.251 netmask 255.255.255.0 broadcast 192.168.0.255 up
}

do_stop()
{
        /etc/init.d/openvpn stop
}


case "$1" in
  start)
        [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
        do_start
        case "$?" in
                0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  stop)
        [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
        do_stop
        case "$?" in
                0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  restart|force-reload)
        log_daemon_msg "Restarting $DESC" "$NAME"
        do_stop
        case "$?" in
          0|1)
                do_start
                case "$?" in
                        0) log_end_msg 0 ;;
                        1) log_end_msg 1 ;; # Old process is still running
                        *) log_end_msg 1 ;; # Failed to start
                esac
                ;;
          *)
                log_end_msg 1
                ;;
        esac
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
        exit 3
        ;;
esac

Il n’est plus nécessaire de faire un
openvpn --mktun --dev tap0
et
openvpn --rmtun --dev tap0
semble-t-il.
Il est important de noter que le serveur dhcp doit être arrêté avant d’arrêter le VPN…
Par contre le ifconfig tap0 0.0.0.0 promisc up est absolument indispensable.
Dans le cas où on l’oublie, le VPN semble marcher mais il n’y a aucune connexion entre tap0 et br0,
les paquets arrivent mais sont cachés et la connexion ne se fait pas.
C’est assez dur à repérer comme erreur (à noter que matt avait dit de le faire!)

#17

La configuration d’un client sous Windows est identique, il faut installer openVPN téléchargé ici, et mettre dans
c:\program files\openVPN\config
un fichier config.vpn comme suit par exemple

client
dev tap
proto udp
remote IP_du_serveur 5555
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 1

ainsi que les fichiers client.crt,client.keyetca.crt`

Si on veut faire en sorte que TOUT passe par le VPN (et que tout se passe comme si on était sur le réseau distant en local), il faut modifier plusieurs choses. cela se fait comme suit:

  1. Accès du serveur assuré (il faut connaitre l’IP de la passerelle du réseau réel et l’IP de la passerelle du réseau distant (celui où on accède par VPN)):
Linux :
route add -host IP_du_SERVEUR_VPN gw IP_de_la_passerelle

Windows :
c:\>route add IP_du_SERVEUR_VPN IP_de_la_passerelle
  1. Changer le DNS de la machine utilisé de telle manière à utiliser celui du réseau distant.
  2. Changement de la route par défaut:

Linux :

route del default gw IP_de_la_passerelle
route add default gw IP_de_la_passerelle_du_reseau_distant

Windows :

route delete 0.0.0.0
route add 0.0.0.0 mask 0.0.0.0 IP__de_la_passerelle_du_reseau_distant metric 20

Attention à également changer les proxy éventuels dans les réglages de firefox/IE.
À partir de ce moment, la machine réagit comme si elle était physiquement sur le réseau distant.

#18

Une dernière remarque, si il s’agit de faire un vpn fait à la demande sous linux (et non de manière automatique), le script sommaire suivant convient en faisant automatiquement ce qui est dit dans le message précédent:

#!/bin/sh
RESEAU=IP_SERVEUR_VPN
if [ -z $1 ] ; then
PASSERELLE=`route -n | grep "^0.0.0.0 " | awk '{print $2}'`
PASSEVPN=IP_PASSERELLE_DU_VPN
        /etc/init.d/openvpn start
        sleep 1
echo    /etc/init.d/openvpn start
        route add -host $RESEAU gw $PASSERELLE
echo    route add -host $RESEAU gw $PASSERELLE
        route del default gw $PASSERELLE
echo    route del default gw $PASSERELLE
        sleep 4
        route add default gw $PASSEVPN
echo    route add default gw $PASSEVPN
        echo $PASSERELLE > /tmp/__vpnpasse
        cp /etc/resolv.conf /tmp/__vpnresolv.conf
        cp /etc/resolv.conf.vpn /etc/resolv.conf
else
if [ -f /tmp/__vpnresolv.conf ] ; then
PASSERELLE=`cat /tmp/__vpnpasse`
PASSEVPN=`route -n | grep "^0.0.0.0 " | awk '{print $2}'`
        route del default gw $PASSEVPN
        route add default gw $PASSERELLE
        mv /tmp/__vpnresolv.conf /etc/resolv.conf
        /etc/init.d/openvpn stop
        route del -host $RESEAU gw $PASSERELLE
fi
fi

le sleep 4 est indispensable, il faut que le vpn soit opérationnel avant de modifer la table de routage.
# vpn
lance le VPN
# vpn stop
(vpn avec un argument quelconque en fait) stoppe le VPN.

Il ne reste plus qu’à savoir comment attribuer une IP fixe à un client. Cela semble se faire sans problème, reste à rédiger le bazar.

#19

Je suis en train de suivre ce tuto. A ce stade:

  • Une info complémentaire, la création du répertoire keys put se faire automatiquement avec le script clean-all après avoir sourcé vars. ça remplace:
# mkdir keys
# touch keys/index.txt
# echo 01 > keys/serial
# chmod -R 0700 keys
  • Quel client utilisez-vous pour tester si le serveur marche bien?[/li][/ul]

J’ai d’autres questions que je pose sur le fil suivant pour ne pas trop polluer celui-ci.
viewtopic.php?f=3&t=17611

#20

openvpn :mrgreen:

j’va aller voir, mais si c’est une suite de ce tuto, autant que les questions le concernant soient dessus.