Objectifs

Améliorer le réseau privé virtuel actuel, basé sur une technologie peu souple IPSec à clé statiques.

Liste des services attendus :

• avoir un meilleur maillage pour permettre plus de liaisons directes point-à-point
• connexions automatisées et authentifiées de manière plus sécurisée (SSL/TLS)
• optimisation en fonction de la latences et de la régularité (stabilité)

Objectifs secondaires :

• maillage le plus complet possible tout gardant une dimension régionale aux problèmes
• compression des données à la volée pour tenter d'optimiser un peu la bande passante

  Voir aussi la page du projet sur l'intranet : http://informatique.auf/article10.html yapu?

Technologie

Choix final : OpenVPN et autotun

Principe général

Sur chaque noeud du RPV tournent deux processus en continu (démons):

• un serveur OpenVPN capable de recevoir des demandes de connexions depuis des noeuds clients ;
• un lanceur qui "écoute" les demandes de connexions vers le RPV et est capable de lancer des clients OpenVPN vers des serveurs distants.

En outre, chaque serveur dispose aussi d'un démon OpenVPN dédié à la connexion des clients nomades.

Le serveur OpenVPN inter-noeuds

C'est un OpenVPN configuré de façon relativement classique. Lorsqu'un client demande une connexion, il utilise une authentification par certificat (TLS) pour vérifier que ce client appartient bien au RPV, c'est-à-dire que le certificat du client ait été signé par une autorité de certification de l'AUF.

Ensuite, en fonction du nom donné au certificat (commonname), le serveur est capable de savoir quel est le sous-réseau qui désire se connecter (ceci est effectué via un script client-script). Il créée alors sur la machine locale une route vers ce sous-réseau (options route et iroute).

Enfin, le serveur envoie au client la route que ce dernier doit construire sur la machine distante afin de communiquer avec la partie du RPV correspondante au serveur (option push route).

Note : le serveur est configuré pour couper un tunnel au bout de 5 minutes d'inactivité sur le tunnel, voire au bout d'une minute si le client correspondant n'est plus joignable (problème réseau).

Le lanceur de client autotun

Il s'agit d'un processus qui tourne en tâche de fond et gère une interface virtuelle de type tun (une sorte de carte réseau virtuelle). Lors de son lancement, autotun construit l'interface ainsi qu'une route pour le réseau RPV vers cette interface. Lorsqu'un paquet IP doit être émis par la machine locale vers le RPV il arrivera sur cette interface... sauf bien sûr s'il a été intercepté par une route vers un tunnel RPV déjà établi. autotun devient en quelque sort la route par défaut pour le RPV.

Lorsqu'un paquet IP arrive sur autotun, celui-ci cherche comment créer le tunnel adéquat. Pour cela, il effectue une requête DNS. Le tunnel pourra être créé en lançant un client OpenVPN, mais toute autre technique est envisageable (création d'une route vers un netopia, lancement d'un pipsecd, etc).

Si aucun tunnel ne correspont au paquet IP reçu:: autotun ignorera tout paquet IP reçu pour le même sous-réseau pendant 5 minutes (délai configurable). De même, si un tunnel ne parvient pas à se créer (échec de lancement d'un client OpenVPN par exemple) on pourra mettre un délai pour éviter de refaire une tentative immédiatement.

Si le tunnel est correctement créé et fonctionnel:: une route existera alors sur la machine vers le sous-réseau correspondant. Par la suite, tous les paquets IP à destination de ce sous-réseau passeront directement dans ce tunnel sans jamais atteindre autotun. Cependant, dès que le tunnel sera coupé, tout nouveau paquet à destination du sous-réseau parviendra au lanceur... qui initiera alors un nouveau tunnel.

Les clients OpenVPN lancés par autotun

Il s'agit de clients OpenVPN classiques, lancés par autotun. Ils sont lancés avec des paramètres adaptés au sous-réseau auquel ils doivent se connecter, c'est-à-dire principalement l'adresse IP du serveur distant (option remote). Ces options auront été déterminées par autotun via des requêtes DNS.

Comme pour le serveur, le client est configuré pour s'arrêter en cas d'inactivité du tunnel pendant 5 minutes, ou au bout d'une minute si le serveur n'est plus joignable.

Adressage

Chaque noeud possèdera un réseau avec un masque de /20 (ou 16 classes C).

• Réseau		Usage	Exemple
  10.pays.impl+0.0/21	10.pays.impl+0.0/24	serveurs locaux RPV (ex : fichiers du personnel et éventuellement VoIP)	10.120.64.0/24
  	10.pays.impl+1.0/24	clients locaux	10.120.65.0/24
  	10.pays.impl+2.0/24	usages futurs	10.120.66.0/24
  	...
  	10.pays.impl+6.0/24	usages futurs	10.120.70.0/24
  	10.pays.impl+7.0/24	OpenVPN inter-noeud	10.120.71.0/24
  10.pays.impl+8.0/21		OpenVPN accès nomades	10.120.72.0/21

OpenVPN ne permet pas de directement faire se connecter deux sous-réseaux. Il ne permet que l'établissement de connection point à point. Pour connecter deux sous-réseaux, il faudra après la création du tunnel configurer correctement des routes.

Nous avons donc décidé que la 8ème classe C de chaque noeud sera utilisée pour la connection des systèmes OpenVPN. Un client obtiendra donc une adresse IP dans la dernière classe du serveur cible. Ce n'est qu'ensuite que les routes des réseaux complets seront créées sur les interfaces.

Autrement dit, le serveur OpenVPN inter-noeud ne gérera que la 8ème classe C. Les 7 premières sont celles où on retrouvera les machines locales (clients et éventuels serveurs). Les 8 classes C restantes seront destinées aux machines nomades qui se connectent à ce noeud.

Voici le principe que nous avons choisi pour l'interconnection de deux sous-réseaux A et B. A est le serveur, B le client.

1. Le client B se connecte au serveur A
2. A lui donne une adresse IP dans la 8ème classe C de son réseau complet (/20)
3. Le client B construit une route du réseau complet de A vers son interface
4. Le serveur A construit une route du réseau complet de B vers son interface

5. Le serveur A construit une route interne (iroute) du réseau complet de B vers le client de B (voir le script client-script.sh). Ceci est spécifique à OpenVPN : le serveur gère plusieurs clients, il doit donc savoir qu'un paquet reçu pour tel réseau est destiné à tel client. Le paquet est reçu via la couche IP du noyau, OpenVPN l'envoie ensuite vers le bon client via ces routes internes, définies par iroute.

L'infrastructure de gestion de clé (PKI)

Puisque chaque serveur et client qui établit une connexion vérifie que le certificat de son correspondant appartient au RPV, cela signifie que nous devons disposer d'un système de gestion des clés et certificat.

Sa description complète est sur PKI.

Etat des lieux

• openvpn : étudier le paquet de Etch (2.0) vs Lenny (2.1), voir adaptation du patch export-cert (todo : tentative de relance au niveau de l'upstream... ne réponds à rien, rien de rien...)

• autotun : à revoir/relire, mais surtout à porter en Python ou Perl (help needed)

Les codes sources sont visibles sur http://git.auf.org/?p=rpv2.git

Notes de bas de page :

• FranckKouyami : Au sujet des clients nomades, Pourquoi ne pas prévoir en plus un serveur OpenVPN général pour eux. Toutes les clés créées à l'ouverture des comptes seraient également valables sur ce serveur. L'avantage serait que dans le cas où leur implantation serait injoignable, ils pourraient toujours accéder au RPV..

  • On va faire plus fort : toutes les implantations disposeront d'un serveur OpenVPN sur lequel tous les personnels de l'AUF pourront se connecter. En effet, les certificats "personnel AUF" seront émis depuis la même PKI, et donc acceptés par tous les serveurs. -- ThomasNoël 2008-10-21 08:36:13