Projet / RPVv2

Sommaire

  1. Objectifs
  2. Technologie
  3. Principe général
  4. Le serveur OpenVPN inter-noeuds
  5. Le lanceur de client autotun
  6. Les clients OpenVPN lancés par autotun
  7. Adressage
  8. L'infrastructure de gestion de clé (PKI)
  9. Etat des lieux

Objectifs

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

Liste des services attendus :

Objectifs secondaires :

Technologie

Choix final : OpenVPN et autotun

Principe général

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

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).

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

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

Notes de bas de page :

Projet/RPVv2 (dernière édition le 2008-11-11 11:56:10 par JeanChristopheAndré)