"Déployer des services dans une architecture réseau”
<aside> 💡 Démarches, prises de décisions, implication et autonomie
</aside>
Le projet réseau/sécu a été le terrain d'application principal de cette compétence. En partant d'un sujet imposant une topologie précise, notre groupe a dû faire des choix techniques structurants dès le début : nous avons opté pour OpenWRT comme routeur principal, en justifiant ce choix par sa flexibilité sur la gestion des VLANs et des règles de filtrage nftables, sa légèreté, et sa capacité à gérer le relais DHCP entre les différents segments réseau. Toute l'architecture a été déployée et configurée sur GNS3 avec des machines virtuelles Debian.
J'ai participé activement à toutes les phases du projet : la définition du plan d'adressage IP (découpage en trois sous-réseaux /24), la configuration des services en DMZ (DNS Bind9, Apache HTTPS, vsftpd/FTPS), et la mise en place des politiques de sécurité pare-feu. La phase d'audit m'a particulièrement impliquée : nous avons utilisé Nmap et Metasploit pour tester notre propre infrastructure et identifier les vulnérabilités réelles, ce qui demandait une bonne compréhension de l'ensemble de l'architecture déployée.
En stage chez Selltim, l'administration s'est manifestée différemment : j'ai géré des environnements de développement web en production réelle, avec des interventions directes sur des sites clients en ligne. La correction du bug critique sur le back-office WordPress d'un client, ou la résolution des bugs au lancement de Kenteleg V2 en production, sont des exemples concrets d'administration de services en conditions réelles.
<aside> 💡 Ressources choisies et combinées
</aside>
Pour le projet réseau, nous avons utilisé de nombreuses ressources techniques : la documentation officielle OpenWRT pour la configuration du routeur et des zones pare-feu, les pages man de Bind9 pour le serveur DNS faisant autorité sur le domaine reseau4ever.iut, la documentation Apache pour la configuration des VirtualHosts HTTP et HTTPS, et la documentation vsftpd pour le passage de FTP à FTPS. Pour Suricata, nous avons combiné la documentation officielle avec les cours de R4.B.12 sur la sécurisation des systèmes.
Les cours de R4.B.11 (réseau avancé) ont été essentiels pour comprendre les mécanismes de routage inter-VLAN, le fonctionnement du relais DHCP, et la configuration du dual-stack IPv4/IPv6 avec SLAAC. Pour la phase d'audit, nous avons utilisé la documentation Nmap et les modules Metasploit pour mener nos tests de manière structurée.
En stage, je me suis appuyée sur la documentation WordPress pour diagnostiquer et corriger les pannes back-office, sur la documentation Next.js et TypeScript pour le développement du CRM, et sur les explications de Lucien et Pierre-Luc pour comprendre l'architecture des projets en cours.
<aside> 💡
Justification de la maîtrise des apprentissages visés
</aside>
L'AC23.01 (concevoir et développer des applications communicantes) est directement illustrée par l'ensemble de l'infrastructure déployée : toutes les machines communiquent via des protocoles réseau configurés manuellement (DHCP, DNS, HTTP/HTTPS, FTP/FTPS, SSH), avec une topologie segmentée en VLANs et une DMZ exposant les services vers l'extérieur. Le serveur DNS Bind9 que nous avons configuré traduit correctement les noms de domaine en IPv4 et IPv6, ce qui valide la maîtrise du routage inter-VLAN et des communications applicatives.
L'AC23.02 (utiliser des serveurs et services réseaux virtualisés) est illustrée par l'utilisation de GNS3 comme plateforme de virtualisation réseau, sur laquelle nous avons déployé plusieurs machines Debian virtualisées jouant chacune un rôle précis dans l'architecture (routeur, DHCP, DNS, Web/FTP, IDS). La gestion des sauvegardes du projet GNS3 et son transfert pour l'audit croisé démontrent aussi une maîtrise de l'environnement virtualisé.