\documentclass[pdftex,a4paper,fleqn,twoside,final,10pt]{article}
\usepackage[latin1]{inputenc}
\usepackage[OT1]{fontenc} 
\usepackage{vmargin}
\usepackage{relsize}
\usepackage{xr}
\usepackage{graphicx}
\usepackage[pdftex]{hyperref}
\usepackage[french]{babel}

\setpapersize      {A4}

%Pour une sortie avec serrodo
\setmarginsrb      {2cm}%marge gauche
                   {2cm}%marge en haut
                   {2cm}%marge droite
                   {2cm}%marge en bas
                   {0.5cm}%hauteur du header
                   {1cm}%separation header
                   {0.5cm}%hauteur du bas
                   {1cm}%separation du bas


\begin{document}

\section{Introduction}

À l'heure où les missions de l'université évoluent considérablement et où la
demande de performance et de réactivité se fait de plus en plus forte, il nous
apparaît clairement que la mise en {\oe}vre actuelle des ressources
informatiques par le CRI ne permet pas au LACL d'atteindre les objectifs
d'excellence qu'elle s'est fixée. En effet, de par ses activités de recherche en
informatique (section 27 du CNU), le LACL a des besoins spécifiques que nous
allons essayer de rendre explicites dans la section~\ref{sec:besoins} ; nous
proposerons une solution aux problèmes dans la
section~\ref{sec:solution}. Enfin, nous montrerons en
section~\ref{sec:conclusion} combien l'approche proposée peut s'instancier avec
les ressources dont dispose le laboratoire.

\section{Les besoins du LACL} \label{sec:besoins}

Nous donnons dans cette section la liste des services qui ne sont pas
accessibles actuellement\footnote{Certains services sont parfois disponibles,
l'accès ssh par exemple, mais avec de telles restrictions que leur usage est
rendu difficile, sinon inutilisable.}. Nous insistons sur le fait que ces
services sont des services standard qui représentent le minimum qu'un
laboratoire est en droit d'attendre d'une université. 

La liste qui suit n'est pas une liste figée dans le temps car le laboratoire est
un lieu qui évolue constamment au grès des besoins de ses membres :
\begin{enumerate}
 \item accès, depuis l'extérieur via le protocole crypté et sécurisé ssh, aux
       ressources internes du laboratoire,

 \item ajout et retrait d'une ressource de calcul sur le réseau avec une adresse
       IP valide,

 \item serveur VPN pour accéder, de l extérieur du laboratoire, aux ressources
       internes de celui-ci,

 \item serveur CVS/SVN pour permettre le développement collaboratif, accessible
       via un serveur Web et ssh,

 \item serveurs de CMS/Wiki pour les projets scientifiques (ANR et autres),

 \item serveurs applicatifs dédiés reposant sur des technologies en
       développement,

 \item serveur CIFS et NFS permettant la mise en commun d'espace disque,

 \item adresses mails pérennes (et temporaires) en
       \texttt{@lacl.univ-paris12.fr},

 \item liste de diffusions (internes et externes),

 \item utilisation, en interne au labo, de protocoles exotiques (JXTA, p2p...).
\end{enumerate}
Il est important de remarquer qu'une propriété transversale attendue de tous ces
services est la réactivité et l'évolutivité de ceux-ci. Bien entendu, nous
souhaitons que tous ces services soient disponibles avec un niveau de sureté et
de sécurité maximal.

\section{Une proposition de schéma technique} \label{sec:solution}

Nous proposons dans cette section une solution technique simple, robuste et
éprouvée qui permettrait de répondre aux besoins de la section~\ref{sec:besoins}
par une gestion délocalisée de certaines ressources. 

En effet, une solution (classique) de type «~\emph{sous-réseau autonome sur une
classe IP privée avec une machine firewall en front-end}~» permet d'adresser les
problèmes précédemments décrits. Nous détaillons dans les sections suivantes les
éléments permettant de comprendre le schéma proposé.

\subsection{Placement des prises réseaux sur un même VLAN, isolé}

Le premier élément à mettre en place est de placer \emph{toutes les prises
réseau} (sauf une - voir point ci-dessous) du LACL sur un VLAN dédié, non routé
et distinct des réseaux existants (\emph{recherche}, \emph{enseignement} et
\emph{administration}) de l'université. En effet, de par la configuration
actuelle\footnote{Toutes les machines se trouvent actuellement sur le réseau
recherche. Cela a comme conséquence d'êtres accessibles par toutes les machines
de ce réseau : vers, virus, attaques diverses et autres sources de problèmes
mettent en danger les ressources informatiques du laboratoire.} il ne nous est
pas possible d'avoir une mise en commun des ressources du laboratoire,
\emph{distincte} des autres machines de l'université. 

Appelon ce VLAN le VLAN LACL. Il est essentiel que les prises de ce VLAN ne
soient pas routées afin de forcer les machines du réseau LACL à passer par le
routeur du laboratoire ; c'est lui qui aura la responsabilité de gérer les
adresses IP aux machines du VLAN. Ce routeur est présenté dans la section
suivante.

\subsection{Administration d'une machine firewall}

Une machine effectuera le lien entre l'intérieur du sous-réseau LACL et le reste
du monde : le \emph{firewall}. Cette machine sera le point de passage du flux
réseau entre les machines du VLAN LACL et le reste de
l'université/internet. Inversement, il sera le point de passage obligé de tout
flux entrant.


\subsection{Gestion déléguée du sous-domaine \texttt{lacl.univ-paris12.fr}}

Dans cette configuration, la machine firewall gère tous les services réseaux se
situant à l'interface des deux mondes. Afin de disposer d'un controle sur les
services mail, web, ssh... il est essentiel que la sous-réseau
\texttt{lacl.univ-paris12.fr} soit délégué à cette machine qui gèrera le DNS et
tous les autres services de ce sous-réseau. La délégation de sous-réseau est un
acte technique simple qui permet de déléguer la gestion d'un sous-réseau à une
entité.

Afin de permettre la mise en {\oe}uvre des services décrits dans la
section~\ref{sec:besoins}, il est essentiels que les \emph{ports} de cette
machine ne soient pas filtrés par le CRI. Ainsi (liste non exhaustive), les
ports 22 (ssh), 25 (smtp), 80 (http), 1194 (VPN), 2401 (cvs)8080 (http),
... doivent êtres ouverts. C'est le firewall de ce VLAN qui aura la
responsabilité de filtrer le traffic indésirable, en accord avec la politique de
sécurité du CRI et de l'université.


\section{Mise en {\oe}uvre effective} \label{sec:conclusion}


Le schéma technique esquissé dans les sections qui précèdent est une solution
robuste, maîtrisée et évolutive car extrêmement standard dans les laboratoires
de recherche en informatique. La viabilité de ce projet repose sur deux éléments
clefs :
\begin{enumerate}
 \item Le laboratoire dispose en interne, via des enseignants/chercheurs
       spécialiste de la sécurité et de l'administration système, de toutes les
       ressources permettant une mise en place maîtrisée du schéma proposé. En
       particulier, ce schéma a déjà été mis en place, administré et validé pendant
       plusieurs années dans le cadre d'une précédente affectation d'un collègue.

 \item Le LACL dispose de plus d'un ingénieur système qui administre au
       quotidien les ressources du laboratoire. Ses compétences permettrons une mise
       en {\oe}uvre rapide du schéma qui aura été défini avec le CRI et un pilotage au
       jour le jour de celui-ci.
\end{enumerate}

Pour toutes ces raisons, nous aimerions entamer un cycle de réflexion avec les
instances responsables au sein de l'université pour la mise en place et
l'évolution des ressources informatique. Pour que ce projet puisse être mené à
bien dans les meilleures conditions, il nous semble essentiel que tous les
acteurs - politiques et techniques - soient impliqués.   
  

\end{document}


Bonjour a tous,
 
Peut-etre avez-vous remarque que l'acces ssh externe sur Soleil a ete
supprime par le CRI de l'universite ? Afin de mettre un terme a notre
dependance aux bons vouloirs du CRI, je vous propose que nous
etablissions la liste des besoins que nous avons en outils/ressources
reseaux et qui ne peuvent pas actuellement etre mis en place du fait
des contraintes trop fortes imposees par le CRI. Nous en avions parle
lors du dernier conseil de labo, mais j'ai un peu manque de temps pour
m'en occuper...
 
Comme toute equipe systeme, le CRI est d'une certaine facon dans son
'role' en nous bloquant le plus possible (chaque inge systeme a
presque pour ennemi objectif les utilisateurs !), mais, a l'heure de
l'autonomie et de l'excellence des universites, cette attitude n'est
plus tenable. On ne peut pas claironner partout que les universites
ont besoins d'equipes performantes et reactives et en meme temps ne
pas leur donner les moyens.
 
Actuellement, l'architecture mise en place par le CRI ne nous permet
pas d'avoir les services suivants :
 
  * acces ssh,
  * ajout de machines sur le reseau,
  * serveur VPN,
  * serveur CVS/SVN,
  * serveurs applicatifs dedies,
  * listes de diffusions,
  * banalisation des prises reseaux pour *tout usage*,
  * [vos avis ?]
 
et surtout nous place dans une situation de totale dependance
vis-a-vis des lubies du CRI (par exemple, une prise reseau ou du
traffic P2P aura ete detecte est bloquee !?!? Les distribution Linux
sont maintenant disponibles en P2P, des travaux de recherches sont
faits sur le sujet...).
 
Cela serait possible si nous avions une architecture (tres peu)
differente qui reposerait sur :
 
  * une unique prise reseau routee,
 
  * mise en place d'une machine faisant firewall/routeur (+ services
   associes) vers un sous-reseau en IP privees,
 
  * gestion du sous-domaine/sous-reseau sur le meme VLAN pour toutes
  les prises du labo ; aucun filtrage sur cette adresse ; ainsi, on
  pourrait gerer nos adresses mail @lacl, les listes de diffusion,
  serveurs CVS...
 
Cette organisation est standart et classique et requiert un minimum de
changement de la part du CRI. Elle est le garant de notre autonomie
(gestion des adresses IP, filtrage, reactivite accruee...), de notre
securite (seule la machine routeur est visible de l'exterieur) et du
meilleur fonctionnement de nos ressources. Actuellement, toutes les
machines sont visibles du reste de l'universite (en tout cas de tout
le sous-reseau des machines de recherche) et c'est une source
important de problemes potentiels...
 
J'attends vos remarques/ameliorations sur ce texte, en particulier la
partie [services qui ne sont pas possibles].
 


\end{document}
