OpenVPN
Un article de Toulouse Sans Fil, un réseau wifi libre sur Toulouse.
Présentation
Cette page est l'annexe aux spécifications du réseau TSF concernant la mise en place d'un VPN de type OpenVPN.
Le 20/03/2006, tard le soir, un serveur de test OpenVPN 2.0.4 vient d'être mis en place chez Julien qui dispose d'une ligne aDSL avec IP fixe. Les informations ci-dessous sont au maximum découplées de la configuration de l'opérating system (OS) mais restent orientées UNIX. Pour les utilisateurs de WinXP, NetBSD, FreeBSD il faudra attendre que quelqu'un fasse l'adaptation et les tests associés.
Quoi qu'il en soit, le howto v2.0 est une petite merveille et moyennant quelques essais et quelques notes additionnelles, il est facile d'arriver à une solution qui fonctionne même pour un débutant.
Avertissement : cette page est un peu longue mais présente tout le nécessaire pour les serveurs et les clients de façon à ne pas éparpiller les données et de n'avoir qu'une page à gérer. Aidez-vous de la table des matières.
Les certificats crées pour le test initial
Le serveur comporte le gestionnaire de certificats complet y compris le certificat maître et a permis de produire des clefs et certificats pour les configuration suivantes :
- Certificat maître
- Serveur (Debian /ADSL)
- Ouinouin (Debian ou Ubuntu / ADSL)
- Vice13 (Debian ou Ubuntu / ADSL)
- Grompf (OpenBSD / RNIS)
- Mq (ubuntu/ADSL)
- tolomicro (ubuntu/ADSL)
Chacun reçoit trois fichiers produits par l'opérateur sur ce serveur : le ca.crt ou certificat public du serveur, <nom>.crt son certificat signé avec la clef maître, et le fichier <nom>.key la clef privée de l'utilisateur. Ces certificats peuvent être très facilement révoqués en cas de problème en les plaçant dans la liste de révocation.
Administration des certificats
Commandes de configuration des certificats
Toutes les commandes sont localisées dans un répertoire créé par recopie du répertoire openvpn souvent situé dans /usr/share/doc. Créer un répertoire keys quelque-part dans /etc/openvpn pour y stocker les clefs et certificats :
# cd /etc/openvpn/easy-rsa
Attention : le contenu des répertoires chez la Debian sont moisis de fichiers inattendus. Du nettoyage sera à faire un jour ou l'autre.'
On initialise les sous-répertoires et les fichiers :
# init-config
Editer et configurer les variables dans le fichiers vars puis l'exécuter. Il faut bien définir les entrées liées au certificat et aux répertoires associés (accès au répertoire keys par exemple) en renseignant les variables KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL. Aucune variable ne doit être vide. Il faut donc aussi se munir d'une adresse de contact à renseigner dans les clefs : elle servira par exemple à trouver facilement un contact en cas de révocation impromptue... ;
/!\ bien mettre un point suivi d'un espace devant la commande ./vars cela permet au sous shell lancé lors du script de pouvoir exporter les variables crées dans le script dans l'environnement local : ces variables seront ensuites lues par un autre script : si vous oubliez le ". " la suite ne fonctionnera pas.
# . ./vars
On procède au nettoyage des vieilles clefs inutiles maintenant.
# ./clean-all
On construit le certificat maître :
# ./build-ca
Ici, la plupart des paramètres par défauts sont corrects dans la série de question qui va être posée, il suffit de donner un nom spécifique à la clef (exemple "nom du serveur" ou quelque chose de plus spécifique genre tsf-CA).
easy-rsa # ./build-ca Generating a 1024 bit RSA private key ............++++++ ...........++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [KG]: FR State or Province Name (full name) [NA]: 31 Locality Name (eg, city) [BISHKEK]: TOULOUSE Organization Name (eg, company) [OpenVPN-TEST]: Toulouse-sans-fil Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []: plop-CA Email Address [me@myhost.mydomain]: vpn@toulouse-sans-fil.net
On construit le certificat du serveur :
# ./build-key-server server
Ici dans le nom indiquer server.
On construit les certificats des clients :
# ./build-key ouinouin # ./build-key grompf ...
Ici pour les noms, répéter les noms donnés en paramètres.
Les fichiers ca.crt, grompf.crt, et grompf.key seront par exemple, transmis à l'utilisateur grompf par un canal sécurisé.
On construit les paramètres Diffie-Helmann pour le chiffrage :
# ./build-dh
L'opérateur de l'autorité locale de certification retrouvera les clefs et certificats à distribuer dans le répertoire keys
Ajouter un nouveau certificat
Il suffit de relancer la commande build-key pour chaque nouvel utilisateur à relier via openVPN après avoir lancé la commande vars :
# . ./vars # ./build-key vice13
Révocation d'un certificat
De la même façon que l'on crée un certificat, il est possible d'en révoquer un :
# . ./vars # ./revoke-full vice13
Il faudra ensuite que le serveur openvpn puisse accéder au fichier contenant la liste de révocation crl.pem ainsi créé. L'inclusion de la ligne crl-verify crl.pem (attention au chemin d'accès) dans la configuration du serveur sera obligatoire.
Serveurs OpenVPN
Configuration du serveur pour les tests initiaux
Une configuration simple basée sur les fichiers d'exemple a été utilisée pour le serveur. Et bien sûr, il ne faut pas oublier que le mode routé (tun) ne supporte pas les broadcasts. Après tests divers en mode tun, la solution fonctionne plutôt bien à l'exception du broadcast comme prévu. Il a donc fallu reconfigurer le serveur en bridge (mode tap) : ce qui induit des variation de réglage des devices selon les OS. (Aurélien : la config WinXP, c'est pour toi hein ! ) ;o)
Il faut cependant s'assurer que, coté serveur, le firewall a bien le port 1194 ouvert et si besoin bien redirigé vers la bonne machine.
L'adressage choisis pour le réseau virtuel est 10.254.0.0/16. Il n'existe pas de département 254 en France, il y a peu de risque de voir quelqu'un l'utiliser et cela nous permettra de proposer à wireless-fr d'utiliser ces adresses pour les réseaux virtuels openVPN inter-régionaux quand la solution marchera à pleine charge.
La visibilité (routage) entre liaisons virtuelles à été activée sur le serveur. La version 3 devrait cependant permetre la formation d'un Mesh virtuel via un ou plusieurs serveurs. Mais vu la faible densité des liens actuels et le besoin de pouvoir logguer et mesurer ce qui se passe : ce n'est pas un mal de commencer avec des liaisons en étoile.
Une clef ta.key pour chiffrage HMAC et les clefs d'identification de serveur seront créées plus tard, quand le besoin s'en fera sentir (active un firewall-vpn contre les cas de DoS par exemple).
Une éventualité à considérer consiste an l'achat d'un coprocesseur de chiffrage de façon à pouvoir utiliser de petites machines ou des machines chauffant peu lorsqu'il faudra désengorger le cpu du VPN ou du routeur le supportant.
Réglages basiques pour tout OS
Installation et création de la configuration dans /etc/openvpn
Après installation ou compilation d'OpenVPN, on crée d'abord le répertoire ou vont être stockés les clefs et les certificats :
mkdir /etc/openvpn/keys
On utilise le fichier client.conf fourni dans la documentation comme base de travail (ici exemple ubuntu mais la localisation du répertoire de documentation peut varier en fonction de la source de ce qui est installé) :
ubuntu# cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn
Et on l'adapte en suivant les recommandation qui suivent plus loin.
On crée ensuite les certificats et clefs maître et du serveur que l'on copie dans le repertoire /etc/openvpn/keys si besoin est. Il faudra par la suite toujours penser à recopier tout fichier d'autentification à cet endroit s'ils sont crées ailleurs.
Note : on peut aussi utiliser le répertoire dans easy-rsa comme localisation des clefs et autres certificats. Auquel cas, la phase de recopie est aussi inutile. Bref faites ça à votre façon, mais n'oubliez pas de contrôler que les clefs et certificats requis sont bien à la place choisie.
/etc/openvpn/server.conf
Les paramètres indiqués en gras ont été modifiés par rapport au fichier d'exemple initial.
Publication du fichier de configuration dès que tout est stable.
lancement du serveur pour test sur la console locale
openvpn /etc/openvpn/server.conf
lancement du serveur en daemon en plaçant les logs bavards à part
Un élément problématique pour l'aisance d'administration du serveur réside dans sa production plétorique de logs. L'option log <path/fichier> ou l'option de lancement --log <path/fichier> permet de détourner ce flux vers un fichier spécifique. Et l'option log-append <path/fichier> ou l'option de lancement --log-append <path/fichier> permet d'avoir une rotation du contenu du fichier à chaque relance.
La ligne de commande de lancement devient ici :
/usr/sbin/openvpn --config /etc/openvpn/server.conf --daemon --log-append /var/log/openvpn.log
Une autre méthode consiste à exporter les logs vers syslogd et à faire traiter ces derniers par syslogd, voire même d'exporter les logs vers un serveur de log.
Arrêt du serveur
Selon les habitudes de votre O.S. : pkill openvpn , /etc/init.d/openvpn stop , etc
Specificités Linux
Testé sur Debian/Sarge.
Voir les notes de Ouinouin en attendant leur rapatriement final ici. Notament en ce qui concerne la configuration des bridges et les fichiers d'automatisation de lancement et d'arrêt.
Spécificités des autres OS
Encore non testés.
Clients OpenVPN
Configuration des clients pour test
Une configuration simple basée sur les fichiers d'exemple à été utilisée pour les clients. Elle sera améliorée au fur et à mesure des besoins.
Réglages basiques pour tout OS
Installation et création de la configuration dans /etc/openvpn
Après installation ou compilation d'OpenVPN, on crée d'abord le répertoire où vont être stockées les clefs et les certificats :
mkdir /etc/openvpn/keys
On utilise le fichier client.conf fourni dans la documentation comme base de travail (ici exemple ubuntu mais la localisation du répertoire de documentation peu varier en fonction de la source de ce qui est installé.) :
ubuntu# cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn
et on y copie les clefs et certificats qui ont été donnés par l'administrateur du VPN par une méthode sécurisée (copie de fichier par échange sur clef USB, dispatch SSH, etc).
Des liens symboliques vont ensuite être créés de façon à n'utiliser qu'un fichier de configuration générique et identique pour tous les participants au VPN :
cd /etc/openvpn/keys/ # mettre votre nom d'utilisateur qui forme la première partie des noms de fichiers qui vous ont été transmis : user=<user> ln -s $user.crt my_cert.crt ln -s $user.key my_key.key
/etc/openvpn/client.conf
Les paramètres indiqués en gras ont été modifiés par rapport au fichier d'exemple initial.
Actuellement 88.160.104.3 est l'adresse actuelle du serveur OpenVPN de TSF ; adresse qui se retrouve dans le fichier de configuration et qui pourra être éventuellement amenée à changer de temps à autre en fonction des aléas et des problèmes connus par l'association dans l'exploitation des serveurs.
############################################## # Sample client-side OpenVPN 2.0 config file # # for connecting to multi-client server. # # # # This configuration can be used by multiple # # clients, however each client should have # # its own cert and key files. # # # # On Windows, you might want to rename this # # file so it has a .ovpn extension # ############################################## # Specify that we are a client and that we # will be pulling certain config file directives # from the server. client # Use the same setting as you are using on # the server. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. ;dev tap ;dev tun dev tap # Windows needs the TAP-Win32 adapter name # from the Network Connections panel # if you have more than one. On XP SP2, # you may need to disable the firewall # for the TAP adapter. ;dev-node MyTap # Are we connecting to a TCP or # UDP server? Use the same setting as # on the server. ;proto tcp proto udp # The hostname/IP and port of the server. # You can have multiple remote entries # to load balance between the servers. ;remote my-server-1 1194 ;remote my-server-2 1194 remote 88.160.104.3 1194 # Choose a random host from the remote # list for load-balancing. Otherwise # try hosts in the order specified. ;remote-random # Keep trying indefinitely to resolve the # host name of the OpenVPN server. Very useful # on machines which are not permanently connected # to the internet such as laptops. resolv-retry infinite # Most clients don't need to bind to # a specific local port number. nobind # Downgrade privileges after initialization (non-Windows only) user nobody group nobody # Try to preserve some state across restarts. persist-key persist-tun # If you are connecting through an # HTTP proxy to reach the actual OpenVPN # server, put the proxy server/IP and # port number here. See the man page # if your proxy server requires # authentication. ;http-proxy-retry # retry on connection failures ;http-proxy [proxy server] [proxy port #] # Wireless networks often produce a lot # of duplicate packets. Set this flag # to silence duplicate packet warnings. ;mute-replay-warnings # SSL/TLS parms. # See the server config file for more # description. It's best to use # a separate .crt/.key file pair # for each client. A single ca # file can be used for all clients. ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/my_cert.crt key /etc/openvpn/keys/my_key.key # Verify server certificate by checking # that the certicate has the nsCertType # field set to "server". This is an # important precaution to protect against # a potential attack discussed here: # http://openvpn.net/howto.html#mitm # # To use this feature, you will need to generate # your server certificates with the nsCertType # field set to "server". The build-key-server # script in the easy-rsa folder will do this. ns-cert-type server # If a tls-auth key is used on the server # then every client must also have the key. ;tls-auth ta.key 1 # Select a cryptographic cipher. # If the cipher option is used on the server # then you must also specify it here. ;cipher x # Enable compression on the VPN link. # Don't enable this unless it is also # enabled in the server config file. comp-lzo # Set log file verbosity. verb 3 # Silence repeating messages ;mute 20
Lancement d'OpenVPN dans une console pour test
openvpn /etc/openvpn/client.conf
Lancement du serveur en daemon en plaçant les logs bavards à part
Un élément problématique pour l'aisance d'administration du serveur reside dans sa production plétorique de logs. L'option log <path/fichier> ou l'option de lancement --log <path/fichier> permet de détourner ce flux vers un fichier spécifique. Et l'option log-append <path/fichier> ou l'option de lancement --log-append <path/fichier> permet d'avoir une rotation du contenu du fichier à chaque relance.
La ligne de commande de lancement devient ici :
openvpn --daemon --config /etc/openvpn/client.conf --log-append /var/log/openvpn.log
Une autre méthode consiste à exporter les logs vers syslogd et à faire traiter ces derniers par syslogd, voire même d'exporter les logs vers un serveur de log.
Arrêt du client
Selon les habitudes de votre O.S. : pkill openvpn , /etc/init.d/openvpn stop , etc
Note sur les Firewalls
Les clients OpenVPN sont à même de traverser naturellement les firewalls sauf cas de configuration paranoïaque de leur part. Il n'y a pas besoin, dans les architectures réseaux domestiques courantes, de modifier quoi que ce soit pour faire fonctionner un client OpenVPN.
Spécificités Linux
Voir les notes de vice13
Pour une installation avec Ubuntu/Debian d'un client openVPN, on installe les paquets nécessaires avec la commande :
apt-get install openvpn
Attention : sous ubuntu il faut avoir les ports "universe".
Spécificités OpenBSD
Les ports & packages nécessaires sont disponibles au moins depuis la version 3.8 d'OpenBSD. Une installation directe est tout à fait possible sans aucun problème. Le plus dur sera de retrouver le répertoire de documentation où se trouve le répertoire openvpn à copier dans /etc/openvpn. Si ma mémoire est bonne il devrait se trouver vers /usr/share/doc/openvpn ou /usr/local/share/doc/openvpn.
Le périphérique tun sous OpenBSD fait aussi office de périphérique tap, il suffit simplement de le configurer avec le drapeau link0 activé pour cela. OpenVPN gère très bien celà de façon automatique il suffit de remplacer, dans le fichier /etc/openvpn/client.conf, la déclaration spécifique à linux:
dev tap
par la déclaration suivante :
dev tun0 dev-type tap
Il est à noter qu'il faut indiquer explicitement le numéro du canal tun qui va être utilisé.
Après tests en mode tun ou en mode tap il apparait qu'OpenVPN sur OpenBSD fonctionne parfaitement et sans lutte. Le problème actuel restant à regler est qu'OLSR semble utiliser le péripherique tun (en mode tap) d'une façon incompatible avec la gestion interne d'OpenBSD. A régler...
Spécificités FreeBSD
A faire.
Spécificités NetBSD
A Faire.
Spécificités MOS X
A Faire.
Spécificités Windows XP
A faire.
ceci (http://forums.gentoo.org/viewtopic-t-233080.html) peut certainement aider.
Evolution
A terme, une solution avec deux serveurs régionaux en region configurés pour l'équilibrage de charge (deux lignes à modifier et activer dans le configuration des clients et serveurs ), couplés avec un OLSR devrait être suffisant question robustesse. Et une solution avec deux serveurs inter régionaux par région avec connexions croisées entre régions devrait aussi être suffisant pour avoir un export fiable et redondant. Et bien sûr avec routage par OLSR la dedans pour rester simple. Ces serveurs régionaux et inter régionaux pourront avoir exactement la même structure et la même définition.
Le but aussi étant bien sûr d'être fiable, quasiment sans administration, donc sans administrateur appointé et attitré, et ne demandant pas de manipulation donc de présence humaine, ni de configuration en tous genres quoi qu'il se passe.
Par ailleurs, il faut par ailleurs mettre au point une infrastructure de distribution de clefs et certificats et accessoirement créer un utilisateur adminvpn avec les droits suffisants, ou affecter un utilisateur spécifique au groupe qui va bien, pour lui donner les droits de créer et de révoquer des clefs. Il faut penser à sécuriser le générateur de certificats : mettre le ca.key hors de portée de qui que ce soit. (attention : le ca.key est nécessaire pour produire les certificats).