Hashtagueule

Gérer plusieurs parcs informatiques (Partie 0 : Présentation)

Salut à tous,

Voici le premier tutoriel en temps réel présenté sur Hashtagueule. Il s'agit tout simplement de résoudre un problème "costaud" en plusieurs parties, qui sont publiées à chaques fois que l'auteur achève de formaliser son idée. Cette idée de temps réel reflète le fait que l'auteur travaille sur la solution en même temps qu'il écrit le guide.

Que les soucieux se rassurent, cela ne veut pas dire que les solutions présentées sont bancales ou non testées. À chaque partie publiée correspond beaucoup d'heures d'essais et de prototypage. Ne vous inquiétez pas, on sait rester pro chez Hashtagueule :)

Il va sans dire que vous êtes encouragés à partager vos propres solutions, demander des précisions, suggérer un détail ou réagir pour n'importe quel motif, en commentaires, sur les forums ou bien par IRC. Nous vous écouterons avec le plus grand plaisir et le plus grand intérêt.

Venons-en au fameux problème auquel j'ai été confronté il y a quelques semaines. Sa formulation en elle même est assez délicate, et les contraintes sont assez, comment dire, "contraignantes". Enfin bon, essayons tout de même.

Mettre en place une administration collective de plusieurs réseaux virtuels dont les adressages IP sont indépendants et possiblement conflictuels

Là. Je vous avais dit que la formulation était indigeste. Si vous avez tout compris du premier coup je vous en félicite. Pour les autres comme moi, voici une petite explication grosso modo.

  • Il s'agit de donner un accès facilement révocable indépendamment à plusieurs personnes à plusieurs parcs informatiques. Une personne ayant été exclue de ce groupe ne doit plus pouvoir s'y connecter après coup.
  • Les parcs informatiques sont gérés par des personnes indépendantes qui ont mis en place la plupart du temps un VPN pour que nous puissions nous y connecter. Ces VPN étant eux-mêmes indépendants, les conflits IP sont monnaies courantes (beaucoup d'adresses en 192.168.0.0/16 ou 172.16.0.0/16 par exemple).
  • Les technologies de méthodes d'accès sont différentes d'un parc à l'autre. Par exemple on peut avoir du OpenVPN, VPNC, IPsec, etc. sur les VPN, et pour la connexion SSH on peut avoir de l'identification par clef ou par mot de passe.

Voilà, ça fait pas mal de contraintes, hein ? Ben devinez quoi, c'est l'objet de notre tutoriel.

La question qu'il est légitime de se poser à ce niveau, c'est : Mais Raspbeguy, à quoi ça peut bien servir, et pourquoi tu gaspille notre temps avec des inepsies pareilles ? À cela je vous répondrai que ce genre de problèmes ne sort pas spontanément de mon esprit dérangé, mais bel et bien d'une situation réelle, et en l'occurence bloquante. Les gens capables de concevoir des horreurs pareilles sont les entreprises offrant un support technique informatique à d'autres entreprises ayant une infrastructure relativement imposante. Si vous n'êtes pas dans ce cas, ne fermez pas tout de suite votre onglet ; si vous êtes un peu curieux, ce tutoriel pourrait vous donner des idées, car au delà d'une application précise, il permet de comprendre un peu plus certains mécanismes réseau et/ou Linux. Donc tout le monde y gagne :)

Et ce tutoriel, ma foi, nous ne le commencerons pas aujourd'hui. Non non. Mais bientôt je vous le promet. J'ai réfléchi longuement à ce problème pour le décomposer en sous-parties. Voici mon plan d'attaque :

  1. La gestion de conflits LAN to LAN : résoudre les problèmes de routage induits par les conflits exposés ci dessus.
  2. L'uniformisation des accès VPN, ou comment éviter à l'utilisateur de se prendre la tête avec 50 commandes faisant toutes la longueur de mon bras.
  3. La gestion des droits : autoriser un groupe de personnes à effectuer des actions précises et uniquement ces actions.

Donc je vous donne rendez-vous pour la première partie de ce tutoriel consacrée à la mise en place du terrain fertile pour y planter nos tunnels. En attendant, dites-nous ce que vous en pensez :)