openvpn
[ --help ]
openvpn
[ --config fichier ]
openvpn
[ --genkey ]
[ --secret fichier ]
openvpn
[ --mktun ]
[ --rmtun ]
[ --dev tunX | tapX ]
[ --dev-type type-périph ]
[ --dev-node noeud ]
openvpn
[ --test-crypto ]
[ --secret fichier ]
[ --auth algo ]
[ --cipher algo ]
[ --keysize n ]
[ --no-replay ]
[ --no-iv ]
openvpn
[ --askpass ]
[ --auth algo ]
[ --ca fichier ]
[ --cd répertoire ]
[ --cert fichier ]
[ --chroot répertoire ]
[ --cipher algo ]
[ --comp-lzo ]
[ --comp-noadapt ]
[ --config fichier ]
[ --crl-verify crl ]
[ --daemon ]
[ --dev-name nom ]
[ --dev-node noeud ]
[ --dev-type type-périph ]
[ --dev tunX | tapX | null ]
[ --dh fichier ]
[ --disable-occ ]
[ --down cmd ]
[ --float ]
[ --fragment max ]
[ --gremlin ]
[ --group groupe ]
[ --hand-window n ]
[ --http-proxy serveur port [authfichier] ]
[ --http-proxy-retry ]
[ --ifconfig l r ]
[ --ifconfig-noexec ]
[ --ifconfig-nowarn ]
[ --inactive n ]
[ --inetd ]
[ --ipchange cmd ]
[ --key fichier ]
[ --key-method m ]
[ --keysize n ]
[ --link-mtu n ]
[ --local hôte ]
[ --log-append fichier ]
[ --log fichier ]
[ --lport port ]
[ --mlock ]
[ --mssfix max ]
[ --mtu-disc type ]
[ --mtu-test ]
[ --mute n ]
[ --nice-work n ]
[ --nice n ]
[ --no-iv ]
[ --no-replay ]
[ --nobind ]
[ --passtos ]
[ --persist-key ]
[ --persist-local-ip ]
[ --persist-remote-ip ]
[ --persist-tun ]
[ --ping-exit n ]
[ --ping-restart n ]
[ --ping-timer-rem ]
[ --ping n ]
[ --port port ]
[ --proto p ]
[ --redirect-passerelle ]
[ --remote hôte ]
[ --reneg-bytes n ]
[ --reneg-pkts n ]
[ --reneg-sec n ]
[ --replay-persist fichier ]
[ --replay-window n [t] ]
[ --resolv-retry n ]
[ --route réseau [masque
réseau] [passerelle] [métrique] ]
[ --route-delay n ]
[ --roue-gateway gw ]
[ --route-noexec ]
[ --route-up cmd ]
[ --rport port ]
[ --secret fichier ]
[ --setenv nom valeur ]
[ --shaper n ]
[ --single-session ]
[ --tls-auth f ]
[ --tls-cipher l ]
[ --tls-client ]
[ --tls-remote nomx509 ]
[ --tls-server ]
[ --tls-timeout n ]
[ --tls-verify cmd ]
[ --tran-window n ]
[ --tun-ipv6 ]
[ --tun-mtu-extra n ]
[ --tun-mtu n ]
[ --up cmd ]
[ --up-restart ]
[ --up-delay ]
[ --user utilisateur ]
[ --verb n ]
[ --writepid fichier ]
OpenVPN est un démon VPN robuste et flexible qui peut être utilisé pour crééer sur Internet un lien sécurisé entre deux (ou plus) réseaux privés par un tunnel chiffré. Les points forts d'OpenVPN sont notamment sa grande portabilité, son excellente stabilité, le support pour les addresses dynamiques et le NAT, la compression dynamique de données, l'utilisation d'un unique port UDP/TCP, une conception qui transfère la plupart des tâches de cryptographie à la bibliothèque OpenSSL, et une installation plutôt facile qui, dans la plupart des cas, ne requiert pas de module noyau spécifique.
OpenVPN s'appuie sur la bibliothèque OpenSSL, et obtient de celle-ci la plupart de ses capacités cryptographiques.
Open VPN supporte le chiffrement conventionnel utilisant un secret partagé (mode Clé Statique) ou le chiffrement par clés publiques (mode SSL/TLS) utilisant des certificats clients et serveur.
OpenVPN peut également fonctionner en mode tunnel UDP/TCP sans chiffrement.
OpenVPN est conçu pour fonctionner avec les périphériques réseau virtuels TUN/TAP qui sont disponibles sur la plupart des plates-formes.
En résumé, OpenVPN vise à fournir, sous une forme compacte, les fonctionnalités essentielles d'IPSec.
Les guillemets ("") peuvent être utilisés pour délimiter les paramètres contenant un espace, et les caractères "#" ou ";" désignent les commentaires.
Les fichiers de configuration peuvent être imbriqués jusqu'à une profondeur raisonnable.
Pour des exemples de fichiers de configuration, reportez-vous à http://openvpn.sourceforge.net/examples.html
Voici un court exemple de fichier de configuration :
#
# Exemple de fichier de configuration OpenVPN
# utilisant le secret partagé.
#
# '#' ou ';' dénotent les commentaires.
# Nous utilisons un peripherique dynamique tun.
dev tun
# Notre vis-à-vis distant
remote mypeer.mydomain
# 10.1.0.1 est l'extrémité locale de notre VPN
# 10.1.0.2 est l'extrémité distante de notre VPN
ifconfig 10.1.0.1 10.1.0.2
# Notre secret partagé
secret static.key
Lorsque utilisé en mode TCP, --remote agit comme un filtre qui rejette les connexions provenant de machines qui ne correspondent pas à hôte.
Le protocole par défaut est udp si --proto n'est pas défini.
Pour un fonctionnement en UDP, --proto udp doit être défini pour les deux hôtes.
Pour un fonctionnement en TCP, un hôte doit être démarré avec l'option --proto tcp-server et l'autre doit utiliser --proto tcp-client. L'hôte démarré avec tcp-server se place en attente d'une connexion entrante. L'hôte démarré avec tcp-client va essayer de se connecter. En cas d'échec, il attendra 5 secondes avant de recommencer. Le serveur et le client TCP émulent tous deux un signal SIGUSR1 (restart) si l'un ou l'autre réinitialisent la connexion.
OpenVPN est optimisé pour fonctionner sous UDP, la fonctionnalité TCP est fournie dans le cas où UDP n'est pas disponible. En comparaison d'UDP, TCP sera généralement un peu moins efficace et robuste lorsque utilisé sur un réseau chargé ou peu fiable. TCP est également une fonctionnalité récente d'OpenVPN version 1.5 qu'il faut considérer comme expérimentale jusqu'à la sortie des versions 1.6 ou 1.7.
L'article suivant pointe certaines des difficultés présentées par les tunnels IP sous TCP :
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
Dans certaines conditions toutefois, TCP peut présenter des avantages du point de vue de la sécurité et de la robustesse : tunnel de protocoles non-IP, de communications inter-applications en UDP, ou encore tunnel de protocoles qui ne comportent pas leur propre fonctionnalité de correction d'erreurs.
En essence, --float commande à OpenVPN d'accepter des paquets authentifiés provenant de n'importe quelle adresse, et pas uniquement de celle définie par l'option --remote.
Cette option est interprétée ainsi :
cmd addresse_ip numero_port
Reportez-vous à la section "Variables d'Environnement" ci-dessous pour connaître les paramètres supplémentaires qui sont passés aux scripts.
Notez que cmd peut être une ligne de commande comportant de multiples arguments. Dans ce cas, tous les arguments générés par OpenVPN sont ajoutés à cmd pour construire une ligne de commande complète qui est passée au script.
Si vous fonctionnez dans un environnement d'adresses IP dynamiques et que l'un ou l'autre des hôtes est susceptible de changer d'IP hors de votre contrôle, vous pouvez utiliser un tel script pour, par exemple, mettre à jour le fichier /etc/hosts. Ce script est exécuté à chaque fois que l'hôte distant change d'adresse IP.
En miroir, si notre adresse IP change via DHCP, il convient de configurer un script de changement d'IP (voir la page de man de dhcpcd(8) ) afin d'envoyer à OpenVPN un signal SIGHUP ou SIGUSR1. OpenVPN rétablira alors la connexion entre sa nouvelle adresse et la dernière adresse authentifiée pour l'hôte distant.
Reportez-vous aux sections suivantes pour un exemple de configuration d'un périphérique TUN.
Il faut utiliser le même type de périphérique sur les deux hôtes qui participent au tunnel. Il n'est pas possible de d'utiliser un périphérique tun d'un côté et un périphérique tap de l'autre, car ils utilisent des protocoles différents : les interfaces tun encapsulent IPv4 tandis que les interfaces tap encapsulent ethernet 802.3.
Sous Windows, sélectionner le périphérique TAP-Win32 nommée noeud dans le Panneau de Contrôle Réseau. L'option --show-adapters disponible sous Windows permet de lister le nom des périphériques TAP-Win32 disponibles.
Pour les périphériques TUN qui permettent de réaliser des connexions virtuelles de type point à point, --ifconfig s'utilise en définissant deux adresses IP privées qui n'appartiennent à aucun sous-réseau en cours d'utilisation. Les adresses IP peuvent être consécutives, et doivent être spécifiées dans l'ordre inverse dans la configuration de l'hôte en vis-à-vis. Lorsque le tunnel VPN est établi, un ping de rn traverse le tunnel jusqu'à l'autre hôte.
Pour les périphériques TAP qui permettent de créer des segments ethernet virtuels, --ifconfig est utilisé pour définir une adresse IP et un masque de sous réseau, exactement comme une interface ethernet classique. Si vous voulez vous connecter à un pont ethernet distant, l'adresse IP et le masque doivent avoir des valeurs valides pour ce pont ethernet (notez que vous pourriez utiliser DHCP pour définir automatiquement les bonnes valeurs sans recourir à cette option).
Cette option est un proxy pour la commande ifconfig(8) , et permet de simplifier la configuration de tunnels TUN/TAP en fournissant une interface standard, indépendante des variations d'implémentation d'ifconfig sur les différentes plates-formes.
Les paramètres de --ifconfig qui correspondent à des adresses IP peuvent également être spécifiés par des noms de domaines qui seront résolus par DNS ou dans /etc/hosts.
Si par exemple vous avez une configuration telle que l'hôte local utilise --ifconfig tandis que l'hôte distant ne l'utilise pas, vous pouvez spécifier --ifconfig-nowarn sur l'hôte local.
Cette option est un proxy pour la commande route(8), qui fournit une interface standard sur les différentes plates-formes.
masque réseau défaut -- 255.255.255.255
passerelle défaut -- défini par --route-gateway ou par le second paramètre de --ifconfig lorsque --dev tun est utilisé.
La valeur par défaut peut être spécifiée en ne précisant pas de paramètre pour une option ou en utilisant la valeur "default".
Les paramètres réseau et passerelle peuvent être aussi spécifiés comme des noms résolus par DNS ou /etc/hosts, ou en utilisant l'un des 3 mots-clés spéciaux suivants :
vpn_gateway -- L'adresse de l'extrémité distante du VPN (dérivant soit de --route-gateway, soit du second paramètre de --ifconfig lorsque --dev tun est utilisé).
net_gateway -- La passerelle IP par défaut préexistante, obtenue dans la table de routage (Linux et Windows seulement).
remote_host -- L'adresse définie par --remote, ou bien l'adresse d'un client se connectant si OpenVPN est exécuté en mode serveur.
Cette option est utile dans le cas où l'adresse du périphérique TAP est fournie par DHCP. Le délai spécifié permettra au dialogue DHCP d'avoir lieu avant que les routes soient ajoutées.
La solution optimale dans ce scénario consisterait à scruter l'adresse IP de l'interface virtuelle, et d'attendre qu'elle soit définie. Malheureusement il n'y a pas de moyen portable sur toutes plates-formes de réaliser cela.
Reportez-vous à la section "Variables d'Environnement" ci-dessous pour les paramètres additionnels passés en environnement.
Notez que cmd peut être une ligne de commande avec des arguments multiples.
Cette option s'exécute en trois étapes :
(1) Créer une route statique pour l'adresse --remote qui renvoie les paquets vers la passerelle par défaut préexistante. Ceci évite que l'étape (3) ne créée une boucle de routage.
(2) Effacer la route vers la passerelle par défaut.
(3) Définir comme nouvelle passerelle par défaut l'adresse de l'extrémité du VPN (dérivée de --route-gateway ou du second paramètre de --ifconfig lorsque --dev tun est défini).
Lorsque le tunnel est supprimé, les étapes ci-dessus sont réalisées à l'inverse de manière à restaurer la route par défaut initiale.
Fondamentalement, --link-mtu définit la borne haute de la taille des paquets UDP envoyés entre les hôtes OpenVPN.
Pour les versions antérieures à OpenVPN 1.5, cette option se nomme --udp-mtu. L'usage de ce nom est désormais découragé, mais reste supporté pour assurer la compatibilité entre versions.
Le MTU (Maximum Transmission Units) représente la taille maximale en octets du datagramme qui peut être envoyé sans fragmentation sur le lien réseau. Les paquets envoyés par OpenVPN sur les canaux de contrôle ou de données ne doivent pas être fragmentés.
Classiquement, la valeur du MTU devrait être définie entre 1300 et 1500. La taille optimale pour le MTU est le plus petit dénominateur commun à l'ensemble des routeurs présents sur le chemin réseau. La valeur de MTU doit être la même pour les deux hôtes en vis-à-vis.
Un problème de MTU se concrétise fréquemment par une connexion qui se bloque lorsque le trafic est intense. Les options --fragment et --mssfix permettent de régler ce type de problème. Lorsque vous utilisez l'une ou l'autre de ces options, il est préférable de définir --tun-mtu à 1500.
OpenVPN surcharge légèrement chaque paquet destiné au tunnel sécurisé avant de l'envoyer via l'interface TUN. Cette surcharge est constituée de champs de données comme la signature HMAC, l'ID du paquet, le remplissage des blocs de chiffrement, etc. En raison de cette surcharge, le MTU de l'interface TUN devrait être légèrement inférieur au MTU du lien réseau pour qu'OpenVPN puisse rajouter ces octets supplémentaires aux paquets du canal de données. OpenVPN vous permet de spécifier soit le TUN MTU soit le MTU du lien, mais pas les deux. OpenVPN détermine à partir de la valeur spécifiée celle qui n'a pas été définie, en calculant le montant exact de la surcharge qui est nécessaire. Si vous utilisez un script --up , OpenVPN passera les valeurs de TUN MTU et MTU du lien en paramètres de la ligne de commande.
Reportez-vous à l'option --link-mtu ci-dessus pour plus d'information concernant le MTU.
'no' -- Ne jamais envoyer de trames DF (Don't
Fragment)
'maybe' -- Deviner pour chaque route
'yes' -- Toujours envoyer en DF (Don't Fragment)
Le paramètre max est interprété de la même façon que le paramètre --link-mtu : il définit la taille du paquet UDP mesurée après la surcharge liée à son encapsulation, mais avant l'ajout de l'en-tête UDP lui-même.
L'option --fragment n'a de sens que si vous utilisez le protocole UDP pour la communication entre les hôtes OpenVPN, c'est-à-dire si l'option --proto udp est utilisée.
--fragment rajoute 4 octets de surcharge par datagramme.
Voyez l'option --mssfix ci-dessous en complément de l'option --fragment.
Notez aussi que cette option n'est pas destinée à remplacer la fragmentation qui intervient au niveau de la pile IP. Elle ne constitue qu'un dernier recours lorsque la recherche du MTU du chemin réseau ne fonctionne pas. Utiliser cette option est moins efficace que de découvrir correctement le MTU du chemin réseau et d'utiliser la fragmentation IP native.
Cela dit, il y a aussi des circonstances dans lesquelles utiliser la fragmentation interne d'OpenVPN est la seule solution, comme dans le cas d'un flux de multidiffusion UDP qui requiert de la fragmentation.
Le paramètre max est interprété de la même façon que le paramètre --link-mtu : il définit la taille du paquet UDP mesurée après la surcharge liée à son encapsulation, mais avant l'ajout de l'en-tête UDP lui-même.
L'option --mssfix n'a de sens que si vous utilisez le protocole UDP pour la communication entre les hôtes OpenVPN, c'est-à-dire si l'option --proto udp est utilisée.
--mssfix et --fragment sont conçus pour s'utiliser conjointement : --mssfix va tenter d'éviter que TCP ne fragmente les paquets, et si de grands paquets sont transmis malgré tout (provenant de protocoles autres que TCP), --fragment procèdera à leur fragmentation en interne.
Les options --fragment et --mssfix sont un recours lorsque la découverte du MTU du chemin réseau entre deux hôtes OpenVPN en vis-à-vis ne fonctionne pas.
Un problème de MTU se concrétise fréquemment par une connexion qui se bloque lorsque le trafic est intense.
Si --fragment et --mssfix sont utilisés ensemble, --mssfix prendra par défaut la valeur max provenant de l'option --fragment max.
Par exemple, pour limiter la taille maximum des paquets UDP à 1300 (une bonne valeur de base pour régler les problèmes de connexion liés au MTU), on peut simplement définir :
--tun-mtu 1500 --fragment 1300 --mssfix
OpenVPN implémente le bridage du trafic par l'algorithme suivant : étant donné un seuil de n octets par seconde, attendre un minimum de (b / n) secondes entre deux opérations d'écriture de datagrammes de b octets sur le port TCP/UDP.
Il convient de noter qu'OpenVPN accepte des tunnels multiples entre deux hôtes, ce qui vous permet de créer deux tunnels, l'un dont la bande passante est bridée, et l'autre non, de manière à transmettre les données de basse priorité comme une sauvegarde distante par le tunnel bridé, tandis que les autres données passeront par le tunnel normal.
Notez aussi que pour les tunnels à faible bande passante (moins de 1000 octets par seconde), vous devriez probablement abaisser aussi les valeurs de MTU (voir ci-dessus), sans quoi le temps de latence entre deux paquets deviendrait si grand que vous attendriez les délais d'expiration au niveau de la couche TLS et des connexions TCP du tunnel.
OpenVPN accepte n entre 100 octets/seconde et 100 Mo/seconde.
Cette option est conçue pour répondre à deux besoins :
(1) Compatibilité avec les pare-feux dynamiques. Le ping périodique permet de s'assurer que la règle du pare-feu permettant aux paquets UDP d'OpenVPN de passer ne va pas expirer.
(2) Pour fournir un moyen à l'hôte distant de vérifier la présence de son vis-à-vis, en utilisant l'option --ping-exit .
Par exemple, en utilisant
openvpn [options...] --inactive 3600 --ping 10 --ping-exit 60
sur les deux hôtes en vis-à-vis, OpenVPN quittera dans les 60 secondes suivant la déconnexion de l'un des hôtes, mais attendra une heure avant de quitter dans le cas où aucune donnée n'est échangée entre les deux.
Cette option est utile dans les configurations où l'hôte distant possède une adresse IP dynamique et où un nom DNS volatile est utilisé pour pointer vers cette adresse, comme avec un service tel que http://dyndns.org/ et un client DNS dynamique comme ddclient.
L'impossibilité de joindre l'hôte déclanchera un redémarrage, ce qui a pour conséquence de résoudre à nouveau le nom d'hôte défini par --remote (à condition que --resolv-retry soit également spécifié).
Reportez-vous à la section sur les signaux ci-dessous pour plus d'information sur SIGUSR1.
Notez que le comportement de SIGUSR1 peut être modifié grâce aux options --persist-tun, --persist-key, --persist-local-ip, et --persist-remote-ip.
Notez aussi que les options --ping-exit et --ping-restart sont exclusives l'une de l'autre. Vous ne devez pas les utiliser en même temps.
SIGUSR1 est un signal de redémarrage similaire à SIGHUP, mais il offre un contrôle plus fin sur la remise à zéro des options.
Cette option peut se combiner avec --user nobody pour autoriser le redémarrage sur signal SIGUSR1. Normalement, si vous réduisez les privilèges d'exécution d'OpenVPN, le démon ne peut pas redémarrer car il n'a pas le droit de relire les fichiers de clés qui sont protégés.
Cette option résout ce problème en rendant les clés persistantes au redémarrage sur signal SIGUSR1, ce qui fait qu'il n'y a plus besoin d'accéder de nouveau aux fichiers.
L'utilisation de cette option vous permet d'être sûr que des données comme les clés ou celles qui transitent par le tunnel ne seront jamais écrites sur le disque dur de l'hôte à la suite d'une opération de gestion de la mémoire comme en font la plupart des systèmes d'exploitation récents. Elle vous garantit que dans le cas où un attaquant serait capable d'accéder à la machine qui fait tourner OpenVPN, il ne pourrait pas retrouver des clés en scrutant le fichier d'échange. La durée de validité des clés est contrôlée par les options --reneg (voir ci-dessous).
Le défaut de l'option --mlock est de réduire le montant de mémoire physique disponible pour les autres applications.
Pour --dev tun, s'exécute ainsi :
cmd tun_dev tun_mtu link_mtu ifconfig_ip_locale ifconfig_ip_distante [ init | restart ]
Pour --dev tap, s'exécute ainsi :
cmd tap_dev tap_mtu link_mtu ifconfig_ip_locale ifconfig_masque_réseau [ init | restart ]
Reportez-vous à la section "Variables d'Environnement" ci-dessous pour d'autres paramètres qui sont passés sous forme de variable d'environnement.
Notez que cmd peut être une commande avec plusieurs arguments, auquel cas les arguments générés par OpenVPN seront ajoutés à la fin de cmd pour former une ligne de commande complète.
Traditionnellement, cmd lancera un script qui ajoute des routes vers le tunnel.
Normalement, le script up est appelé après que l'interface TUN/TAP soit ouverte. Dans ce contexte, le dernier paramètre de la ligne de commande passée au script sera init. Si l'option --up-restart est également présente, le script up sera aussi appelé lors des redémarrages. Un redémarrage est une réinitialisation partielle d'OpenVPN lors de laquelle l'interface TUN/TAP existante est conservée (via l'option --persist-tun option). Un redémarrage peut être déclanché par un signal SIGUSR1, l'expiration du délai --ping-restart, ou une réinitialisation de la connexion lorsque le protocole TCP est utilisé (via l'option --proto ). Si un redémarrage intervient et que --up-restart est défini, le script up sera appelé avec restart en dernier paramètre.
L'exemple suivant vous montre comment utiliser le script --up dans les contextes d'initialisation et de redémarrage. (NOTES : Pour des raisons de sécurité, n'exécutez cet exemple que si votre pare-feu bloque le port UDP 9999. Cet exemple doit être interrompu par contrôle-c sinon il tournera indéfiniment).
openvpn --dev tun --port 9999 --verb 4 --ping-restart 10 --up 'echo up' --down 'echo down' --persist-tun --up-restart
Notez qu'OpenVPN dispose de l'option --ifconfig pour configurer automatiquement les périphériques TUN. Vous n'avez donc pas besoin de script --up , sauf si vous voulez également configurer des routes dans un tel script.
Si --ifconfig est également défini, OpenVPN passera les extrémités locales et distantes de ifconfig au script --up de manière à ce qu'on puisse configurer une route ainsi :
route add -net 10.0.0.0 netmask 255.255.255.0 gw $5
En mode --proto udp , cette option demande à utiliser --ping pour que la connexion soit reconnue malgré l'absence de trafic de données, puisque UDP est un protocole "non connecté".
Sous Windows, cette option temporise le changement d'état du media à "connecté" jusqu'à ce que la connexion soit établie, c'est-à-dire jusqu'à la réception du premier paquet authentifié provenant de l'hôte distant.
Cette option ne devrait pas être utilisée normalement. Elle constitue une solution temporaire aux situations où une version récente d'OpenVPN doit se connecter à une version plus ancienne.
En spécifiant user à la valeur nobody (ou un autre utilisateur sans privilèges), l'attaquant ne pourrait provoquer que des dommages limités au système. Bien entendu, lorsque OpenVPN a perdu ses privilèges, il ne peut pas les retrouver au cours de la même session. Ceci signifie par exemple que si vous voulez redémarrer un démon OpenVPN avec un signal SIGUSR1 (par exemple suite à un rafraîchissement DHCP), vous devriez utiliser une ou plusieurs options --persist pour que le redémarrage ne demande pas à exécuter des opérations privilégiées, comme par exemple relire les fichiers de clés ou exécuter ifconfig sur l'interface TUN.
Cette option est utile lorsque vous exécutez OpenVPN en mode --daemon et que vous voulez disposer tous les fichiers qui contrôlent l'exécution d'OpenVPN dans un unique répertoire.
Etant donné que le chroot a lieu postérieurement à l'initialisation, la plupart des options d'OpenVPN qui font référence à des fichiers seront exécutées dans le contexte normal.
Dans la plupart des cas, le paramètre répertoire peut pointer vers un répertoire vide. Des difficultés peuvent cependant survenir lorsque des scripts sont exécutés postérieurement au chroot, ou lors du redémarrage.
Le paramètre optionnel prognom fait apparaître OpenVPN sous le nom prognom dans les traces. Ceci peut être utile pour identifier les messages spécifiques à un tunnel particulier. Lorsqu'il n'est pas spécifié, l'argument prognom vaut par défaut "openvpn".
Lorsque OpenVPN est lancé avec l'option --daemon, le passage en mode démon n'interviendra pas avant que la plupart des fonctions d'initialisation qui sont susceptibles de déclancher des erreurs fatales ne soient exécutées. Ceci veut dire que des scripts d'initialisation peuvent obtenir une information relativement fiable concernant le démarrage effectif d'OpenVPN en testant la valeur de retour de la commande openvpn.
Dans OpenVPN, la grande majorité des erreurs pouvant intervenir postérieurement à l'initialisation n'est pas fatale.
Notez également que chaque tunnel OpenVPN requiert sa propre entrée dans inetd ou xinetd, ainsi que son propre port UDP/TCP. Reportez-vous au HOWTO OpenVPN pour un exemple d'utilisation d'OpenVPN sous xinetd : http://openvpn.sourceforge.net/howto.html
Lorsque vous démarrez OpenVPN via inetd ou xinetd, vous devez utiliser "wait" ou "wait = yes" dans l'entrée correspondante.
L'utilisation d'une tâche séparée pour TLS permet d'exécuter en tâche de fond le processus d'échange de clés basé sur SSL/TLS qui demande beaucoup de ressources de calcul, en sorte qu'il ne devienne jamais une cause de latence dans l'envoi des données vers le tunnel.
Le paramètre n est interprété de la même manière que pour l'option --nice ci-dessus, mais concerne seulement la tâche TLS et non la tâche principale.
0 -- Pas de trace, sauf erreur fatale.
1 -- Informations de démarrage + d'initialisation
de la connexion + erreurs non-fatales de chiffrement et de
réseau.
2 -- Affiche les dialogues SSL/TLS
3 -- Eléments SSL/TLS complémentaires +
alertes réseau --gremlin + changement d'état de
la compression dynamique (arrêtée/démarrée).
4 -- Affiche la valeur de tous les paramètres de
réglage.
5 -- Imprime les lettres R et W sur la
console pour chaque paquet lu (R) ou écrit (W).
Les majuscules
sont utilisées pour les paquets TCP/UPD, les minuscules pour les
paquets TUN/TAP.
6 à 11 -- Affiche des traces de déboguage
de plus en plus nombreuses (voyez errlevel.h pour plus d'information
sur les niveaux de trace de déboguage).
La compression dynamique permet d'optimiser la communication dans le cas où vous utilisez la compression, mais que vous transmettez par le tunnel des paquets incompressibles ou déjà compressés, comme par exemple lors du transfert d'un gros fichier compressé par FTP ou rsync. Avec la compression dynamique, OpenVPN va régulièrement faire un test de compression pour mesurer son efficacité. Pour les données déjà compressées, l'efficacité sera très basse, et OpenVPN suspendra la compression jusqu'à la prochaine mesure d'efficacité.
Le paramètre optionnel direction permet d'utiliser 4 clés distinctes (envoi-HMAC, chiffrement-données, réception-HMAC, déchiffrement-données) en sorte que chaque direction du flux de communication possède son propre ensemble de clés d'authentification HMAC et de chiffrement. Cette fonction présente de nombreuses qualités du point de vue de la sécurité, notamment elle élimine le risque de certains types d'attaques par déni de service ("Denial of Service" - DoS) et par rejeu ("replay attack").
Lorsque le paramètre direction n'est pas défini, 2 clés sont utilisées de manière bidirectionnelle, l'une pour le HMAC et l'autre pour le chiffrement/déchiffrement des données.
Le paramètre direction doit toujours être utilisé de manière cohérente entre les 2 extrémités du tunnel. Ainsi, soit le premier hôte spécifie "0" et l'autre spécifie obligatoirement "1", soit le paramètre ne doit pas être défini sur aucun des deux.
Le paramètre direction requiert que le fichier fichier contienne une clé à 2048 octets. Les versions antérieures à OpenVPN 1.5 ne génèrent que des clés à 1024 octets, tandis que toutes les versions d'OpenVPN qui supportent le paramètre direction sont capables de générer une clé à 2048 octets par l'option --genkey .
Le mode de chiffrement statique présente certains avantages, le premier étant probablement sa facilité de mise en oeuvre.
Il ne nécessite ni certificats ni autorité de certification, ni protocole élaboré de négociation de la connexion. L'unique contrainte qu'il suppose est de disposer au préalable d'un moyen sécurisé pour copier la clé vers l'hôte en vis-à-vis, par exemple ssh. Cette contrainte, ajoutée au fait que les clés ne sont jamais remplacées sauf si vous en générez manuellement de nouvelles, rend ce mode probablement moins sécurisé que le mode TLS (voir ci-dessous). Si un attaquant parvient à voler la clé, la sécurité de toutes les données qui ont été ou qui seront échangées avec cette clé est compromise. En revanche, le mode TLS (avec échange de clés Diffie Hellman) offre la caractéristique de "Perfect Forward Secrecy" (PFS), puisque si l'attaquant vole votre clé privée, il sera incapable de déchiffrer des données échangées lors de sessions précédentes.
Un autre interêt du mode de chiffrement statique est que le protocole ne demande pas de négociation. Comme il ne porte aucune marque distinctive (comme un en-tête ou un dialogue d'initialisation), il est impossible de deviner la présence d'OpenVPN depuis l'extérieur. Quiconque espionnerait sur la ligne ne verrait passer qu'un flot de données indistinctes.
OpenVPN chiffre les paquets puis leur applique le traitement HMAC.
En mode de chiffrement statique, la clé HMAC est inclue dans le fichier de clé généré par --genkey. En mode TLS, la clé HMAC est générée et échangée dynamiquement entre les hôtes à travers le canal de contrôle TLS. Si OpenVPN reçoit un paquet dont l'empreinte HMAC est incorrecte, il ignore le paquet. HMAC surcharge traditionnellement les paquets de 16 à 20 octets. Pour supprimer l'authentification, choisissez algo=none.
Pour plus de détails sur HMAC, reportez-vous à http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
Pour plus de détails sur Blowfish, reportez-vous à http://www.counterpane.com/blowfish.html
Pour la liste des autres algorithmes disponibles avec OpenVPN, utilisez l'option --show-ciphers.
OpenVPN supporte les modes de chiffrement CBC, CFB, et OFB.
Pour supprimer le chiffrement, choisissez algo=none.
OpenVPN offre par défaut une protection contre la répétition de datagrammes.
Cette protection est obtenue en étiquetant chaque datagramme sortant avec un identifiant unique généré avec la clé courante. Le vis-à-vis qui reçoit le datagramme vérifie l'unicité de l'identifiant du paquet. Si un identifiant a marqué un datagramme déjà reçu, OpenVPN ignore le paquet. La protection contre le rejeu est efficace contre les attaques du type "SYN flood" où l'attaquant espionne sur la ligne, intercepte un paquet TCP SYN (identifiable par le contexte dans lequel il apparaît), et ensuite submerge l'hôte cible avec des copies de ce paquet.
La protection contre le rejeu est implémentée dans OpenVPN de manière un peu différente selon le mode de chiffrement que vous avez choisi.
En mode à clé statique ou lorsque vous utilisez les modes de chiffrement CFB ou OFB, OpenVPN utilise un identifiant unique a 64 bits composé d'un horodatage et d'un compteur qui s'incrémente.
En mode TLS et avec le chiffrement par CBC, OpenVPN utilise uniquement un numéro de séquence sur 32 bits sans horodatage, car OpenVPN peut garantir l'unicité de cette valeur pour chaque clé. Comme avec IPSec, OpenVPN procède au renouvellement des clés avant que le numéro de séquence n'atteigne le maximum et ne revienne à zéro.
Pour identifier les rejeux de messages, OpenVPN utilise l'algorithme à fenêtre glissante ("sliding window") utilisé par IPSec.
Par défaut, n vaut 64 (valeur par défaut d'IPSec) et t vaut 15 secondes.
Cette option n'a de sens qu'en mode UDP, c'est-à-dire lorsque --proto udp est défini, ou si l'option --proto n'est pas définie.
Quand OpenVPN envoie ses paquets IP sur UDP, il existe une possibilité que les paquets soient perdus en chemin ou qu'ils arrivent dans le désordre. Etant donné qu'OpenVPN émule la couche physique du réseau comme IPSec, il va accepter les paquets en désordre, et les transmettra tel quel à la pile TCP/IP, à condition que :
(a) Le paquet ne soit pas rejoué (sauf si --no-replay est défini, ce qui supprime la protection contre le rejeu de paquets).
(b) Si un paquet arrive dans le désordre, il ne sera accepté que si la différence entre son numéro de séquence et le plus haut numéro reçu jusqu'à cet instant est inférieure à n.
(c) Si un paquet arrive dans le désordre, il ne sera accepté que s'il arrive au maximum t secondes après un paquet qui contenait un numéro de séquence plus élevé.
Si vous utilisez un réseau qui a un grand pipeline (c'est-à-dire que le produit de la bande passante par le temps de latence est élevé), vous pourrez avoir intérêt à augmenter la valeur de n. Les liaisons par satellite, par exemple, requièrent souvent cela.
Si vous exécutez OpenVPN sous --verb 4, vous verrez le message "Replay-window backtrack occurred [x]" à chaque fois que le retard maximum rencontré dans la séquence de numéros s'accroît. Ce message permet donc de calibrer la valeur de n.
La méthode adéquate de gestion de l'ordonnancement des paquets au niveau de la couche de sécurité est sujette à débat : jusqu'à quel point la couche de sécurité qui encapsule le protocole doit-elle détecter des attaques dissimulées sous la forme de pertes et de réordonnancements de paquets, qui sont des phénomènes normaux sur les réseaux IP ?
L'approche proposée par IPSec et OpenVPN est d'autoriser le réordonnancement, dans la limite d'une certaine fenêtre.
OpenVPN rajoute au modèle IPSec la limite par fenêtre temporelle en plus de la limite liée au numéro de séquence.
OpenVPN offre aussi, à la différence d'IPSec, l'option d'utiliser TCP comme couche de transport. Dans ce cas, OpenVPN interdit tout réordonnancement. Puisque TCP garantit la fiabilité de la communication, tout paquet perdu ou arrivant dans le désordre est interprété comme une attaque.
On peut donc proposer que le tunnel TCP devrait être utilisé pour transporter les protocoles applicatifs non-IP ou UDP qui pourraient être sensibles à des pertes ou réordonnancements de messages tels que ceux rencontrés dans des conditions normales d'utilisation d'un réseau IP.
Je propose ainsi la règle suivante : ne jamais transporter par tunnel UDP un protocole non-IP ou un protocole applicatif UDP si ce protocole peut être vulnérable à des attaques par perte ou réordonnancement de messages qui resteraient dans la limite normale de ces phénomènes pour un réseau IP. En utilisant le transport par TCP pour le tunnel VPN, le dilemme disparaît et le problème est résolu.
Cette option renforce la protection contre les attaques par rejeu, notamment lorsque vous utilisez OpenVPN de manière dynamique (comme avec --inetd), et que les sessions sont fréquemment démarrées et interrompues.
Cette option conserve une copie sur le disque dur de l'état de la protection contre le rejeu (le cachet horodateur et le numéro de séquence du dernier paquet reçu) en sorte qu'OpenVPN sera capable d'identifier un paquet rejoué, même s'il a été reçu lors de la session précédente.
Cette option n'a de sens que lorsque la protection contre les attaques par rejeu de messages est activée (par défaut) et que vous utilisez soit le chiffrement par secret partagé --secret , soit le mode TLS avec --tls-auth.
OpenVPN utilise un IV par défaut. Son utilisation est requise pour les modes de chiffrement CFB et OFB (qui seraient totalement vulnérables sans). L'utilisation d'un IV est un facteur de sécurité important lorsque de nombreux messages sont chiffrés/déchiffrés en utilisant la même clé.
L'implémentation de l'IV varie en fonction du mode de chiffrement utilisé.
En mode CBC, OpenVPN utilise un IV pseudo-aléatoire pour chaque paquet.
En modes CFB ou OFB, OpenVPN utilise un numéro de séquence unique et un horodatage en tant qu'IV. En fait, en mode CFB/OFB, OpenVPN réalise une optimisation qui consiste à utiliser en guise d'IV l'identifiant unique de protection contre la rejeu de messages ajouté au datagramme.
L'utilisation classique de --test-crypto ressemble à ceci :
openvpn --test-crypto --secret key
ou à cela :
openvpn --test-crypto --secret key --verb 9
Cette option est très utile pour tester OpenVPN après son portage vers une nouvelle plate-forme, ou pour identifier des problèmes au niveau de la compilation, de la bibliothèque cryptographique OpenSSL, ou du code cryptographique d'OpenVPN. S'agissant d'un auto-test, vous pouvez déboguer les problèmes de chiffrement et d'authentification en étant libre d'éventuels problèmes liés au réseau et au tunnel.
Pour activer le mode TLS, chaque hôte en vis-à-vis doit posséder en local sa propre paire clé/certificat ( --cert et --key ), signés par le certificat racine défini par l'option --ca.
Lorsque deux hôtes OpenVPN se connectent, chacun présente son certificat à l'autre. Chacun vérifie alors que ce certificat est bien signé par le certificat racine spécifié par --ca.
Si c'est bien le cas des deux côtés, la négociation TLS est réussie et les hôtes OpenVPN vont s'échanger des clés temporaires qui sont utilisées pour le transfert des données dans le tunnel.
La distribution d'OpenVPN contient un ensemble de scripts pour gérer des certificats et clés RSA, localisé dans le répertoire easy-rsa.
Vous trouverez la même information sur le web ici : http://openvpn.sourceforge.net/easyrsa.html
openssl req -nodes -new -x509 -keyout tmp-ca.key -out tmp-ca.crt
Ensuite, éditez votre fichier de configuration openssl.cnf et faites pointer la variable certificate vers votre nouveau certficiat racine tmp-ca.crt.
A des fins exclusives de test, la distribution OpenVPN inclut un exemple de certificat racine d'Autorité de Certification (tmp-ca.crt). Vous ne devez absolument jamais utiliser les clés et les certificats distribués en standard avec OpenVPN dans un environnement de production : étant à la libre disposition de quiconque, ces clés ne procurent aucune sécurité.
openssl dhparam -out dh1024.pem 1024
pour générer vos propres paramètres, ou utilisez le fichier dh1024.pem existant dans la distribution d'OpenVPN. Les paramètres Diffie Hellman peuvent être considérés comme des données publiques.
openssl req -nodes -new -keyout mycert.key -out mycert.csr
Si la clé privée de votre Autorité de Certification réside sur un autre ordinateur, copiez la demande de certificat ("CSR") mycert.csr jusqu'à cette machine. Ceci peut être réalisé sans sûreté particulière, par exemple par courriel. Ensuite, signez le certificat par une commande comme :
openssl ca -out mycert.crt -in mycert.csr
Maintenant, copiez en retour le certificat (mycert.crt) sur l'hôte qui avait servi à générer le fichier .csr. Ceci peut être réalisé sans sûreté particulière, par exemple par courriel. Notez que la commande openssl ca obtient l'emplacement de la clé de l'Autorité de Certification à partir d'un fichier de configuration, comme /usr/share/ssl/openssl.cnf. Notez également que pour que l'Autorité de Certification fonctionne, vous devez créer les fichiers index.txt (peut être initialement vide) et serial (initialisez à 01 ).
Après qu'OpenVPN a négocié une session TLS, un ensemble de clés neuves est généré et échangé au sein de la session TLS, pour chiffrer le tunnel des données.
Selon la méthode 1 (par défaut), les deux hôtes génèrent leurs clés aléatoires de chiffrement et d'authentification HMAC-send, et les envoient à leur vis-à-vis par le canal TLS.
Selon la méthode 2, le client génère une clé aléatoire. Le client et le serveur fournissent également divers germes de générateur aléatoire. Ces éléments sont échangés sur le canal TLS. Les clés réelles sont générées en utilisant la fonction TLS PRF qui prend sa source d'entropie sur le client et sur le serveur. La méthode 2 est conçue pour ressembler de près à la méthode de génération de clés de TLS 1.0.
Si le démon est redémarré par un signal ou par --ping-restart, il autorisera une nouvelle connexion.
--single-session peut être spécifié avec --ping-exit ou --inactive pour créer une session dynamique unique, qui s'interrompt lorsqu'elle est terminée.
En essence, --tls-auth active une sorte de "pare-feu HMAC" sur le port TCP/UDP utilisé par OpenVPN, où les paquets de contrôle TLS porteurs d'une signature HMAC invalide sont ignorés.
fichier (requis) est un fichier de clé qui peut être fourni sous l'un des deux formats :
(1) Une clé statique OpenVPN générée par --genkey (requise si le paramètre direction est spécifié).
(2) Un fichier de mot de passe au format libre. Dans ce cas la clé HMAC sera dérivée du fichier en en calculant un hachage sécurisé, à l'instar des commandes md5sum(1) ou sha1sum(1) .
OpenVPN essaie d'abord le format (1), et s'il ne parvient pas à obtenir une clé, le format (2) sera utilisé.
Reportez-vous à l'option --secret pour plus d'information sur le paramètre optionnel direction.
L'utilisation de --tls-auth est recommandée dans le cas où OpenVPN serait paramétré pour répondre à des paquets provenant de n'importe quelle adresse IP, comme lorsque --remote n'est pas spécifié ou que --remote est spécifié avec --float.
La justification de cette option est la suivante : la négociation TLS nécessite l'échange de plusieurs paquets avant que le vis-à-vis soit authentifié. Durant cette période préalable à l'authentification, OpenVPN alloue des ressources (mémoire, processeur) au bénéfice de son vis-à-vis potentiel. Ce vis-à-vis ouvre également des portions d'OpenVPN et de la bibliothèque OpenSSL aux paquets qu'il expédie. La plupart des attaques réseau efficaces à ce jour consiste à exploiter les bogues d'un programme (attaques par dépassement de tampon) ou à forcer un programme à consommer tant de ressources qu'il devient inutilisable. La première réponse à ce risque consiste bien sur à écrire et à auditer sérieusement un programme. OpenVPN a ainsi été écrit avec la préoccupation permanente de contrer les attaques par dépassement de tampon. Cependant l'histoire a démontré que même les applications réseau les plus utilisées peuvent être sensibles aux attaques par dépassement de tampon.
Par conséquent, OpenVPN offre une seconde ligne de défense par cette couche d'authentification rajoutée au canal de contrôle TLS, qui le protège contre les attaques par rejeu de message via l'empreinte HMAC et l'identification des paquets. L'empreinte offre également une protection contre les attaques par déni de service : la stratégie de base de lutte contre ces attaques consiste à limiter le montant de ressources qui peut être dédié à un vis-à-vis potentiel, mais non identifié.
--tls-auth atteint cet objectif en scellant les paquets du canal de contrôle TLS avec un HMAC, y compris les paquets qui sont envoyés avant que la couche TLS ne soit en mesure d'identifier le vis-à-vis. Le résultat est que les paquets porteurs d'une empreinte incorrecte sont ignorés avant de pouvoir engager des ressources système comme celles nécessitées par la négociation TLS. L'effet de --tls-auth peut être renforcé par l'option --replay-persist qui préserve l'état de la protection contre les attaques par rejeu dans un fichier qui est réutilisé d'un redémarrage à un autre.
Il est important de noter que cette fonctionnalité est optionnelle et que le fichier de mot de passe ou la clé spécifiée par --tls-auth ne permet à un hôte rien d'autre que d'initialiser un dialogue TLS. Ce fichier n'est pas utilisé pour chiffrer ou authentifier les données dans le tunnel.
cmd certificate_depth X509_name_oneline
Voyez la section "Variables d'Environnement" ci-dessous pour plus d'information sur les variables passés en paramètres aux scripts.
Notez que cmd peut être une ligne de commande comportant des arguments multiples, auquel cas les arguments générés par OpenVPN sont rajoutés à la fin de cmd pour constituer une ligne de commande passée au script.
Cette fonction est utile si le vis-à-vis auquel vous souhaitez accorder votre confiance possède un certificat qui a été signé par une Autorité de Certification qui a déjà signé un nombre astronomique de certificats. Dans ce cas, vous voudrez spécifier finement le certificat que vous acceptez. Cette fonction vous autorise à écrire un script qui testera le nom X509 d'un certificat, et de décider si vous devez l'accepter ou non. Pour un script Perl simple que teste le nom commun contenu dans un certificat, voyez le fichier verify-cn fourni dans la distribution d'OpenVPN.
Cette option remplace opportunément --tls-verify pour valider l'hôte distant, car --tls-remote fonctionne même dans un environnement limité par --chroot.
Une CRL (liste des certificats révoqués) est utilisée lorsque qu'une clé est compromise, mais que globalement votre Infrastructure à Clé Publique (PKI) reste sécurisée.
Supposons que votre PKI soit constituée d'une Autorité de Certification, d'un certificat racine, et d'un nombre de certificats clients. Supposons encore qu'un ordinateur portable, contenant un certificat client et sa clé privée associée, soit volé. En ajoutant le certificat volé au fichier de CRL, vous pouvez rejeter toute connexion qui en ferait usage, sans rien changer à votre PKI.
Le seul cas où il faudrait reconstituer une nouvelle PKI de zéro est celui où la clé racine de l'autorité de certification elle-même serait compromise.
L'un des avantages des tunnels persistants est qu'ils éliminent le besoin de scripts --up et --down pour lancer les commandes ifconfig(8) et route(8) appropriées. Ces commandes peuvent être simplement placées dans le script qui lance ou arrête une session OpenVPN.
Un autre avantage est que les connexions ouvertes dans le tunnel TUN/TAP ne seront pas interrompues si OpenVPN redémarre. Ceci permet de fournir une continuité de connexion dans le cas ou l'adresse IP public de l'hôte distant est changée par DHCP (voir l'option --ipchange ci-dessus).
Un défaut des tunnels persistants est qu'il est plus difficile de configurer automatiquement leur valeur de MTU (voir --link-mtu et --tun-mtu ci-dessus).
Sur certaines plates-formes comme Windows, les tunnels TAP-Win32 sont persistants par défaut.
manual -- Ne pas définir l'adresse IP ou le masque réseau automatiquement, mais afficher un message indiquant à l'utilisateur de configurer l'interface lui-même, accompagné de l'IP et du masque réseau qu'OpenVPN attend pour l'interface.
netsh -- Définit automatiquement l'adresse IP et le masque réseau en utilisant la ligne de commande Windows "netsh". Cette méthode semble fonctionner correctement sous Windows XP, mais pas sous Windows 2000.
ipapi -- Définit automatiquement l'adresse IP et le masque réseau en utilisant l'API Windows d'Aide IP (méthode par défaut). Cette approche n'a pas une sémantique parfaite, mais les tests ont démontré qu'elle fonctionne correctement. Si vous utilisez cette option, il est préférable de laisser les propriétés TCP/IP de l'interface TAP-Win32 à leur valeur par défaut, c'est-à-dire "Obtenir une adresse IP automatiquement."
dynamic -- Cette option n'est pas implémentée. Elle est réservée à un usage futur.
Cette option est destinée à régler des problèmes liés aux options --ifconfig et --ip-win32, elle donne le temps au périphérique TAP-Win32 de s'activer avant que l'API Windows d'Aide IP ne procède à sa configuration.
Les adresses de la liaison point-à-point pour le périphérique TUN émulé doivent ainsi être les adresses médianes d'un sous-réseau /30 (masque réseau 255.255.255.252).
parm peut prendre les valeurs : "network" pour le réseau, "netmask" pour le masque réseau, "gateway" pour la passerelle, ou "metric".
n est le numéro de la route OpenVPN, commençant à 1.
Si le réseau ou la passerelle sont définis sur la ligne de commande ou dans le fichier de configuration par des noms résolus par DNS, c'est leur adresse IP qui est conservée, pas le nom.
Ce signal peut aussi être généré en interne sur expiration de délai, selon l'option --ping-restart.
Ce signal, combiné avec l'option --persist-remote-ip, est susceptible d'être envoyé lorsque les paramètres réseau de base de l'hôte distant changent, comme par exemple lorsque l'hôte est un client DHCP et qu'il se voit attribué une nouvelle adresse. Pour plus d'information reportez-vous à l'option --ipchange ci-dessus.
Créer le périphérique : mknod /dev/net/tun c 10 200
Charger le pilote : modprobe tun
Si vous utilisez Linux version 2.2 ou précédentes, vous devez récupérer le pilote TUN/TAP ici http://vtun.sourceforge.net/tun/ et suivre les instructions d'installation.
Si vous installez depuis un RPM, vous pouvez sauter l'étape mknod car l'installation du RPM la réalise pour vous.
Si vous utilisez Linux version 2.2, vous devez récupérer le pilote TUN/TAP en version 1.1 ici http://vtun.sourceforge.net/tun/ et suivre les instructions d'installation.
Pour les autres plates-formes, reportez-vous au fichier INSTALL : http://openvpn.sourceforge.net/install.html .
Si vous utilisez un pare-feu Linux basé sur iptables, les commandes suivantes vous seront peut-être utiles pour autoriser l'entrée de paquets sur le périphérique TUN :
Reportez-vous à la section sur les pare-feux ci-dessous pour plus d'information sur leur configuration pour OpenVPN.
Maintenant, choisissons les extrémités du tunnel. Les extrémités de tunnel sont des adresses IP privées qui n'ont de sens que dans le contexte du VPN. Chaque machine va s'adresser à l'extrémité de tunnel de l'autre machine pour communiquer sur le VPN. Dans notre exemple, l'extrémité du tunnel pour sera 10.4.0.1 pour may.kg et 10.4.0.2 pour june.kg.
Lorsque le VPN est établi vous obtenez, en essence, un nouveau chemin sécurisé qui relie les deux hôtes que vous emprunterez en utilisant les adresses définies pour les extrémités du tunnel. Vous pouvez contrôler le trafic réseau qui passe entre les hôtes (a) par le tunnel ou (b) indépendamment du tunnel, en utilisant soit (a) l'adresse de l'extrémité distante du tunnel, soit (b) l'adresse Internet publique de l'hôte distant. Par exemple, si vous étiez sur may.kg et que vous vouliez accéder à june.kg par ssh sans passer par le VPN (puisque ssh possède sa propre couche de sécurité), vous utiliseriez la commande ssh june.kg. Mais vous pourriez aussi utiliser dans le même but la commande telnet 10.4.0.2 pour obtenir un session telnet avec june.kg à travers le VPN. Dans ce cas précis, c'est le VPN qui apporterait la sécurité à la place de ssh.
Pour les extrémités du tunnel, vous pouvez utiliser n'importe quelles adresses, à condition que ce soient des adresses privées (comme celles qui commencent par 10. ou par 192.168.), et qu'elles n'appartiennent pas à un sous-réseau utilisé par le réseau d'aucun des deux hôtes. Si vous utilisez une adresse qui fait partie de votre sous-reseau pour l'une ou l'autre des extrémités du tunnel, vous créez une boucle réseau qui produit des effets étranges.
Sur may :
Sur june :
Maintenant vérifiez que le tunnel est fonctionnel en faisant un ping à travers le tunnel.
Sur may :
Sur june :
L'option --verb 9 produit des traces abondantes, similaires à celle du programme tcpdump(8). N'ajoutez pas --verb 9 pour qu'OpenVPN s'exécute sans traces.
Cette commande créée une clé aléatoire (au format ASCII) dans un fichier nommé key. Ensuite copiez le fihier key vers june en utilisant un moyen sécurisé tel que le programme scp(1).
Sur may :
Sur june :
Maintenant vérifiez que le tunnel est fonctionnel en faisant un ping à travers le tunnel.
Sur may :
Sur june :
Commencez par créer les certificats et clés pour may et pour june (reportez-vous à --cert ci-dessus pour plus d'information). Ensuite, obtenez les paramètres Diffie Hellman (reportez-vous à --dh ci-dessus pour plus d'information). Vous pouvez également utiliser pour cet exemple les fichiers de test client.crt, client.key, server.crt, server.key et tmp-ca.crt inclus dans la distribution OpenVPN. Les fichiers .crt sont des certificats (ou clés publiques), les fichiers .key son des clés privées, et tmp-ca.crt est le certificat de l'Autorité de Certification qui a signé les certificats client.crt et server.crt. Pour les paramètres Diffie Hellman, vous pouvez utiliser le fichier dh1024.pem. Notez bien que les certificats et clés fournis avec OpenVPN ne procurent aucune sécurisation. Ils sont destinés aux tests et ne doivent pas être utilisés en production.
Sur may :
Sur june :
Maintenant vérifiez que le tunnel est fonctionnel en faisant un ping à travers le tunnel.
Sur may :
Sur june :
Remarquez que nous utilisons ci-dessus l'option --reneg-sec 60. Cette option commande à OpenVPN de négocier de nouvelles clés pour le canal de données chiffré toutes les minutes. En utilisant --verb 5, vous voyez se dérouler la négociation des nouvelles clés.
En environnement de production, une fréquence de renouvellement d'une minute est probablement trop elevée. Si vous ne définissez pas --reneg-sec 60, OpenVPN utilise la fréquence par défaut d'une heure pour le renouvellement des clés.
D'abord vérifiez que le routage IP est activé sur les deux hôtes. Sous linux :
Ensuite autorisez les paquets TUN à passer à travers le pare-feu :
Sur may :
Sur june :
Maintenant, n'importe quelle machine du sous-réseau 10.0.0.0/24 peut se connecter de manière sécurisée à n'importe quelle machine du sous-réseau 10.0.1.0/24, et vice-versa.
En environnement de production, vous pourriez inclure les commandes route à un script qui serait exécuté via l'option --up.
Cette règle autorise les paquets UDP à arriver sur le port 5000 (port UDP d'OpenVPN par défaut) s'ils proviennent de l'hôte distant OpenVPN d'adresse IP 1.2.3.4.
Si vous utilisez l'authentification de paquets HMAC (par défaut pour tous les modes sécurisés d'OpenVPN), le filtrage sur l'adresse IP source peut être considéré comme superflu puisque HMAC est un moyen beaucoup plus sûr d'identifier la source d'un paquet. La règle devient alors :
ce qui permet à l'hôte distant d'utiliser une adresse IP publique dynamique.
OpenVPN fonctionne également avec les pare-feux dynamiques. Vous n'aurez normalement aucune règle à rajouter au pare-feu si celui-ci est capable de garder la trace des connexions UDP. Si vous spécifiez --ping n, vous êtes certains qu'OpenVPN va envoyer au moins un paquet vers l'hôte distant toutes les n secondes. Si n est inférieur au délai d'expiration d'une connexion pour le pare-feu dynamique, OpenVPN maintiendra la connexion indéfiniment sans qu'il y ait besoin de définir une règle de pare-feu explicite.
Vous devriez également ajouter les règles de pare-feu qui autorisent le trafic IP à entrer sur les périphériques TUN ou TAP, comme :
pour autoriser les paquets entrants sur les périphériques tun,
pour autoriser les paquets entrants sur les périphériques tun à être routés vers les autres hôtes du réseau local,
pour autoriser les paquets entrants sur les périphériques tap,
pour autoriser les paquets entrants sur les périphériques tap à être routés vers les autres hôtes du réseau local,
Ces règles sont suffisantes du point de vue de la sécurité si vous utilisez l'authentification des paquets puisque aucun trafic n'arrivera sur un périphérique TUN ou TAP avant que sa source ne soit authentifiée grâce au test HMAC.
Vous pourrez y télécharger la dernière version d'OpenVPN, vous abonner aux listes de discussion, lire les archives des listes de discussion et naviguer le référentiel CVS.
Ce développement inclut du logiciel développé par le Projet OpenSSL ( http://www.openssl.org/ )
Pour plus d'information sur le protocole TLS : http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-01.txt
Pour plus d'information sur le pilote TUN/TAP : http://vtun.sourceforge.net/tun/
Pour plus d'information sur la bibliothèque de compression dynamique LZO : http://www.oberhumer.com/opensource/lzo/