<> = 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).''' ||<-2> '''Réseau''' || '''Usage''' || '''Exemple''' || ||<|6> `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` || ||<-2> `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 1. A lui donne une adresse IP dans la 8ème classe C de son réseau complet (/20) 1. Le client B construit une route du réseau complet de A vers son interface 1. Le serveur A construit une route du réseau complet de B vers son interface 1. 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 <>