Construire son propre Laboratoire Informatique

Que vous soyez étudiant, professionnel de l’IT, chercheur en informatique ou juste un passionné des nouvelles technologies, construire votre propre laboratoire informatique est une démarche enrichissante et éducative. Un laboratoire informatique personnel ouvre les portes à l’expérimentation et à l’apprentissage continu, offrant un terrain de jeu pour tester des configurations, des logiciels et des systèmes d’exploitation.

Dans un laboratoire informatique personnel, appelé aussi « Home-Lab », vous êtes le « Maître du monde ». C’est à vous de choisir les systèmes à installer et les initiatives à entreprendre, avançant selon votre propre calendrier et vos passions. Vous endossez simultanément les rôles de PDG, de directeur des systèmes d’information, de responsable de la sécurité des systèmes d’information, de chef de projet, de spécialiste DevSecOps, et d’analyste en sécurité opérationnelle. 🙂

Que ce soit pour mettre en pratique des connaissances théoriques, pour préparer des certifications professionnelles, ou pour s’adonner à des projets de développement logiciel personnels, un labo personnel est un investissement précieux dans votre futur technologique.

Choix du matériel

L’aventure commence par le choix de l’équipement de base.

Nous avons le choix entre un serveur auto-hébergé et un serveur loué chez un hébergeur cloud.

Il faut garder à l’esprit qu’auto-hébergement n’est pas une mince affaire, et présente à la fois des avantages comme des inconvénients…

Bien qu’un ordinateur grand public légèrement surdimensionné puisse suffire pour un nano-laboratoire, nous atteindrons rapidement ses limites en termes de capacité de calcul. Il est donc préférable d’envisager une configuration plus étendue pour le laboratoire afin de ne pas être restreint par la puissance de traitement.

Option 1 : Serveur auto-hébergé

Avantage: La maitrise de bout en bout du matériel et software.

Inconvénients: Nécessite un investissement de départ (comptez entre 800€ et 1500€ pour un serveur d’occasion sans disques et avec peu de RAM), de plus il vous faut un emplacement dédié (cellier, garage, sous-sol) pour positionner le serveur, de plus il doit être allumé H24 et 7j/7, certains serveurs sont être assez bruyants et chauffent beaucoup (peut nécessiter un local climatisé)…

Option 2: Location d’un serveur bare-metal chez un hébergeur Cloud (OVH, Scaleway …)

Pour un investissement mensuel modique de quelques dizaines d’euros, il est possible de se procurer un serveur dédié performant doté de 64 à 128 Go de RAM, offrant ainsi un large éventail de possibilités.

L’hébergement d’un serveur dédié chez un fournisseur comme OVH consiste à louer un serveur physique complet dans un de leurs Datacenters, réservé exclusivement à l’usage d’un client, offrant contrôle total et ressources non partagées.

Choix du logiciel de virtualisation

Dans le choix du matériel nous avons choisi l’option 2, donc nous allons louer un serveur bare-metal chez OVH. Après avoir sélectionné notre équipement, il est temps de décider de l’hyperviseur qui gérera notre virtualisation.

Un hyperviseur dans notre laboratoire est un logiciel qui permet de créer et de gérer des machines virtuelles, c’est-à-dire de faire fonctionner plusieurs systèmes d’exploitation distincts sur un seul et même serveur physique.

Notre choix final se porte entre VMware vSphere et la solution open-source Proxmox. Pour plus de simplicité nous allons opter pour le choix par defaut qui est VMware vSphere.

Maintenant que nous avons notre serveur physique dédié et notre hyperviseur VMware vSphere installé, passons à la configuration.

Configuration du Lab

Après avoir finalisé l’installation de l’hyperviseur VMware vSphere depuis le portail OVH, nous disposons d’une adresse IP publique pour l’accès à l’interface d’administration. Puisque notre premier objectif est de configurer un réseau local (LAN) pour des machines virtuelles (VMs) avec accès Internet, il est nécessaire de trouver une solution qui permette à la fois la connexion au web et la protection du LAN contre les risques de sécurité externes.

IP-Failover

Dans le cadre de la location d’un serveur dédié chez OVH, nous avions qu’une adresse IP publique, nous allons acheter une seconde IP publique pour 2,50€, nous allons voir pourquoi.

L’objectif de cette configuration est de conserver l’adresse IPv4 fournit par OVH pour administrer l’hyperviseur VMware ESXi via le vSphere Client. Tout en ayant une seconde adresse IPv4 pour sortir sur Internet pour les machines virtuelles. Pour protéger l’accès à nos machines virtuelles, comme on le ferait finalement sur une infrastructure on-premise, nous allons positionner en frontal un firewall.

Le rôle de firewall sera assuré par la solution OPNsense, où l’interface WAN se verra attribuer l’adresse IP-Failover (que nous venons d’acheter), et où le LAN isolé et NATé permettra aux VMs de sortir sur Internet. On pourrait même imaginer avoir plusieurs LANs isolés, le tout contrôlé par le firewall.

Avant de paramétrer notre Firewall OPNsense, nous devons déclarer l’adresse MAC de l’interface WAN de notre OPNsense dans l’espace client OVH pour qu’elle soit prise en compte. Cf. Figure de dessous

Comme indique notre schéma sur la Figure de dessus, notre LAN doit être totalement sécurisé et cloisonné, nos machines doivent accéder à internet via la passerelle 192.168.1.1 (interface LAN du pare-feu OPNsense) et la route par défaut paramétrée manuellement sur le pare-feu qui est 149.xx.xx.254 (OVH).

Configuration du firewall OPNsense

Une fois l’adresse MAC virtuelle déclarée dans l’espace client OVH nous devons la paramétrer sur notre VM OPNsense, sur l’interface WAN, comme suit :

Configurons l’adresse IPv4 statique sur l’interface WAN, en indiquant l’IP Failover dans le champ. Pour nous ce sera 54.37.xx.xx avecle masque en /32.

Pour la passerelle, nous devons utiliser la passerelle de l’adresse IP publique du serveur dédiée, ce qui est hors réseau par rapport à l’IP définie sur l’interface, donc, nous devons créer nos propres routes en ligne de commande, laissez impérativement « None » pour la passerelle et validez.

Maintenant nous nous rendons dans le Shell de notre OPNsense, nous supprimons les routes existantes pour éviter tout conflit, avec route del default,

Puis ajoutons la passerelle sur notre interface WAN « vmx1 » et ensuite nous indiquons à OPNSense la passerelle par défaut à utiliser. Ce qui donne :

Pour rappel, « 149.XX.XX.254 » correspond à la passerelle utilisée par le serveur dédié OVH. Autrement dit, c’est la même passerelle que celle utilisée par notre ESXi.

Attention : après le redémarrage, cette configuration sera perdue ! Il faut passer par shellcmd pour réexécuter ces deux commandes à chaque redémarrage du Firewall.

route add -net 149.XX.XX.254/32 -iface vmx1

route add default 149.XX.XX.254

À ce stade de la configuration, votre OPNSense accède à Internet mais pas nos VMs connectées au LAN. Il va falloir créer une règle du NAT.

Règles de NAT

À partir d’une VM de notre LAN, retournez sur l’administration Web de OPNSense. Dans le menu « Firewall », cliquez sur « NAT » et ensuite sur la section « Outbound ».

En ce qui concerne le mode de NAT, choisissez « Manual Outbound NAT » ce qui va nous donner la main sur les règles de NAT que l’on veut créer.

Maintenant, cliquez sur le bouton « Add » pour ajouter une règle de NAT.

Nous allons utiliser les paramètres suivants :

• Interface : WAN
• Protocol : Any
• Source : Network – 192.168.1.0/24 pour NATer les hosts connectés à notre LAN isolé
• Destination : Any (Internet)
• Translation : l’IP de l’interface WAN de OPNsense qui sera utilisée pour sortir sur Internet

Cliquez sur « Save » puis appliquez les modifications.

À partir de cet instant, nos VM doivent accéder à internet. Vérifions.

Vswitch LAN sur vSphere

Pour avoir un LAN isolé du WAN dans ESXi nous avons créé un second vSwitch.

Seul intermédiaire entre ces deux réseaux est notre pare-feu OPNsense.

Nous pouvons voir sur la Figure de dessous, que depuis l’extérieur nous tombons sur le pare-feu OPNsense en frontal.

Sur la figure de dessous nous avons la vue de notre LAN avec nos VM sécurisées et isolées de l’extérieur et qui accèdent à Internet.

Ainsi, nous avons une infrastructure prête à recevoir des machines virtuelles pour notre future laboratoire de test.

Avec le serveur que nous venons d’installer et configurer, un large éventail d’options s’offre à vous. Il est possible de déployer une variété de systèmes d’exploitation, y compris Linux, Windows Server, ou des OS orientés réseaux. La mise en place des serveurs web, la simulation d’attaques sur des systèmes Linux ou Windows, ainsi que l’installation de systèmes de détection et de réponse aux incidents, représentent seulement un échantillon des nombreux projets réalisables dans votre tout nouveau laboratoire informatique personnel.

En conclusion, construire un laboratoire informatique est un processus dynamique qui exige de se tenir constamment informé des dernières avancées technologiques.

Un « Home-Lab » est un environnement adaptable à vos passions et exigences. Cela implique non seulement des dépenses en équipements, mais aussi un investissement personnel en termes de temps et d’effort pour s’instruire et suivre les évolutions technologiques. Les avantages sont multiples : l’enrichissement des compétences, une compréhension approfondie des systèmes et des architectures élaborés, et peut-être le plus important, le plaisir de la découverte et de la création.