Évalue un plan d'adressage et une passerelle Linux

01Contrat de l’évaluation

assessmentId : BTS-SISR-Y1-NET-001
blocs        : Bloc 1 + Bloc 2 SISR + introduction Bloc 3
format       : TP évalué intégré + remédiation mono-cause
contexte     : SORIA Distribution — laboratoire entièrement synthétique
objectif     : concevoir, mettre en œuvre, vérifier, diagnostiquer et prouver

Compétences officielles principalement observées :

Bloc 1
- répondre aux incidents et aux demandes d'assistance et d'évolution
- mettre à disposition des utilisateurs un service informatique

Bloc 2 SISR
- administrer les systèmes et les réseaux
- concevoir une solution d'infrastructure réseau
- installer, tester et déployer une solution d'infrastructure réseau
- exploiter, dépanner et superviser une solution d'infrastructure réseau

Bloc 3 — première introduction
- assurer la cybersécurité d'une infrastructure réseau, d'un système et d'un service

À ce stade de première année, la partie cybersécurité reste limitée aux premiers contrôles de flux et à la réduction de l’exposition. Les politiques avancées seront réinvesties dans les étapes suivantes.

Cette évaluation n’enseigne pas à nouveau IPv4, VLSM, les routes Linux ou la méthode de diagnostic. Elle réutilise les matières SORIA existantes :

architecture-des-reseaux
- leçons 6 à 9 : IPv4, sous-réseaux et VLSM
- leçons 4 et 10 : passerelle et choix de route
- leçon 15 : diagnostic réseau de bout en bout
- leçon 18 : principes de filtrage et tests de flux

linux-utilisation-avancee
- droits et permissions
- processus et signaux
- systemd
- journalctl et diagnostic de service

integration-professionnelle-bts-sio-sisr
- conduire un diagnostic et une remédiation
- construire le dossier de preuves

02Besoin de SORIA Distribution

La PME reçoit le bloc privé suivant pour son laboratoire :

10.44.0.0/24

Quatre zones doivent être prévues :

Utilisateurs     : 50 hôtes
Exploitation     : 25 hôtes
Administration   : 12 hôtes
Serveurs         : 6 hôtes

Contraintes :

- utiliser VLSM ;
- choisir le plus petit préfixe raisonnable pour chaque besoin ;
- allouer du plus grand besoin au plus petit ;
- réserver une adresse de passerelle dans chaque zone ;
- éviter tout chevauchement ;
- conserver et documenter la réserve non utilisée ;
- ne pas utiliser d'adresse ni de topologie de production SORIA réelle.

Tu dois produire ton plan avant de configurer les machines.

03Livrable 1 — plan d’adressage

Ton tableau doit contenir au minimum :

zone
besoin d'hôtes
réseau / préfixe
première adresse utilisable
passerelle retenue
dernière adresse utilisable
broadcast
usage DHCP ou statique
réserve restante

Ajoute une justification courte pour chaque préfixe.

Un plan qui fonctionne par hasard mais contient un chevauchement, une capacité insuffisante ou une adresse de réseau/broadcast attribuée à un hôte n’est pas recevable.

Tu peux utiliser un calcul manuel, Python ou un autre outil de vérification déjà pratiqué, mais tu dois être capable d’expliquer le résultat.

04Implémente une tranche représentative

Tu ne déploies pas quatre réseaux complets. Pour garder l’évaluation centrée sur les compétences, tu mets en œuvre seulement :

zone Utilisateurs
↕
passerelle Linux
↕
zone Serveurs

Les adresses utilisées doivent provenir de ton propre plan validé.

L’environnement peut être réalisé avec des machines virtuelles ou des espaces de noms réseau Linux selon le laboratoire disponible.

État fonctionnel attendu :

CLIENT-LAB
- appartient à la zone Utilisateurs
- possède une route lui permettant de joindre la zone Serveurs

GW-LINUX
- possède une interface dans chaque zone déployée
- route entre les deux zones
- forwarding IPv4 actif
- configuration observable et documentée

SRV-LAB
- appartient à la zone Serveurs
- possède le chemin de retour correct
- fournit un service pédagogique sur TCP 8080

Tu dois pouvoir expliquer la route aller et la route retour.

05Établis l’état de référence avant toute panne

Avant que l’évaluateur ne dégrade l’environnement, conserve une référence minimale :

CLIENT-LAB
ip -brief address
ip route

GW-LINUX
ip -brief address
ip route
sysctl net.ipv4.ip_forward

SRV-LAB
ip -brief address
ip route
ss -lntp

Vérifications de service :

- le client joint sa passerelle ;
- le client joint l'adresse du serveur ;
- TCP 8080 répond depuis le client ;
- le service applicatif attendu répond réellement ;
- le chemin retour est fonctionnel.

Une simple capture de ping ne suffit pas à démontrer le service.

06Introduis les premiers contrôles de flux

La politique métier est volontairement simple :

Utilisateurs -> Serveurs / TCP 8080 : AUTORISÉ
Utilisateurs -> Serveurs / TCP 2222 : NON AUTORISÉ
trafic de retour d'une connexion autorisée : AUTORISÉ

Selon l’avancement du groupe, l’évaluateur peut fournir un squelette de filtrage ou demander sa mise en œuvre complète. Ce qui est obligatoire pour tous est de :

- traduire la politique en flux ;
- vérifier le flux autorisé ;
- réaliser un test négatif sur le flux interdit ;
- conserver les résultats ;
- ne pas désactiver globalement le pare-feu pour obtenir un succès.

L’écriture de politiques de segmentation plus complexes sera réinvestie à l’étape VLAN/commutation.

07Panne contrôlée

Après validation de l’état de référence, l’évaluateur prépare une seule cause principale parmi les familles suivantes :

A — passerelle par défaut incorrecte sur CLIENT-LAB
B — forwarding IPv4 désactivé sur GW-LINUX
C — route de retour incorrecte ou absente côté Serveurs
D — règle de filtrage ciblée bloquant TCP 8080 alors que le routage reste correct

La variante réellement utilisée ne doit pas être annoncée à l’étudiant.

À cette étape du parcours, aucune panne multi-cause n’est injectée.

Symptôme remis à l’étudiant :

« Depuis CLIENT-LAB, le service pédagogique de SRV-LAB n'est plus utilisable. »

08Diagnostique avant de corriger

Commence par distinguer :

fait
hypothèse
test
résultat
conclusion provisoire

Tu dois écrire au minimum trois hypothèses plausibles avant correction.

Outils possibles selon la cause :

ip -brief address
ip route
ip route get ADRESSE_DESTINATION
ping
tracepath
sysctl net.ipv4.ip_forward
ss -lntp
nc -vz HOTE PORT
curl -v URL
nft list ruleset
journalctl

Tu n’es pas évalué sur le nombre de commandes exécutées. Tu es évalué sur la capacité de chaque test à confirmer ou affaiblir une hypothèse.

Interdictions :

modifier plusieurs paramètres simultanément ;
redémarrer tout l'environnement sans diagnostic ;
désactiver globalement le filtrage ;
changer le plan d'adressage pour contourner la panne ;
inventer une preuve qui n'a pas été observée.

09Applique une remédiation bornée

Avant de modifier, écris :

cause retenue
niveau de certitude
fait décisif
objet exact à modifier
correction proposée
risque
condition d'arrêt
retour arrière
preuve attendue après correction

La correction doit viser uniquement la cause démontrée.

Exemple de principe : une mauvaise passerelle sur un poste ne justifie pas de modifier le routeur, le serveur et toutes les règles de filtrage.

10Refais la recette complète

Après correction :

1. vérifier le composant modifié ;
2. rejouer le test qui avait mis la panne en évidence ;
3. vérifier le routage aller et retour ;
4. vérifier TCP 8080 ;
5. vérifier le service du point de vue client ;
6. refaire le test négatif TCP 2222 ;
7. noter ce qui n'a pas été vérifié.

Le test négatif est important : rétablir TCP 8080 en ouvrant tous les ports constitue une mauvaise correction.

11Livrables attendus

Remets :

1. plan d'adressage VLSM ;
2. schéma simple de la tranche déployée ;
3. état de référence avant panne ;
4. configuration réseau utile, limitée au besoin ;
5. résultats des tests positifs et négatifs ;
6. tableau faits / hypothèses / tests ;
7. cause retenue et niveau de certitude ;
8. correction et rollback ;
9. recette après correction ;
10. entrée dans le dossier de preuves ;
11. limite de la conclusion.

Entrée minimale du dossier de preuves :

EXIGENCE
Concevoir et exploiter une connectivité routée entre deux zones sans exposition inutile.

CONTEXTE
SORIA Distribution — plan IPv4 et passerelle Linux de laboratoire synthétique.

ACTION
Décrire le plan retenu, la configuration réellement appliquée, les tests et la remédiation.

RÉSULTAT + VÉRIFICATION
Conserver la preuve du service TCP 8080 fonctionnel et du test négatif TCP 2222.

LIMITE
Préciser les zones non déployées, les composants non inspectés et ce que les tests ne démontrent pas.

12Critères de réussite

L’évaluation est techniquement recevable si :

- le plan VLSM satisfait les besoins sans chevauchement ;
- la tranche Utilisateurs / Serveurs est cohérente avec le plan ;
- les routes aller et retour sont correctes ;
- GW-LINUX assure le forwarding attendu ;
- TCP 8080 fonctionne après recette ;
- TCP 2222 reste non autorisé ;
- la panne est diagnostiquée avant correction ;
- une seule modification bornée traite la cause ;
- les preuves sont compréhensibles et ne contiennent aucun secret réel.

13Grille de correction sur 20

4 pts — plan d'adressage, capacité, absence de chevauchement et justification
4 pts — configuration Linux, routes aller/retour et fonctionnement du service
4 pts — méthode de diagnostic, hypothèses et test discriminant
4 pts — maîtrise des flux, test positif, test négatif et rollback
4 pts — preuves, schéma, compte rendu et limites explicites

Une infrastructure qui fonctionne après plusieurs changements non tracés ne valide pas la méthode attendue.

14Indices gradués

N’utilise un indice qu’après avoir conservé les résultats déjà observés.

Indice 1
Compare l'état actuel du client, de la passerelle et du serveur avec l'état de référence.

Indice 2
Demande-toi à quel endroit précis le paquet cesse d'avancer : client, routeur, retour serveur ou filtrage.

Indice 3
Un service peut être en écoute et rester inaccessible : prouve séparément adressage, route, forwarding, filtrage et port.

15Remise à zéro contrôlée

Avant chaque tentative, l’évaluateur conserve l’état fonctionnel de référence.

Après l’évaluation :

1. restaurer les adresses et préfixes validés ;
2. restaurer les routes client, passerelle et serveur ;
3. remettre net.ipv4.ip_forward à l'état fonctionnel ;
4. restaurer la politique de filtrage de référence ;
5. vérifier TCP 8080 ;
6. vérifier que TCP 2222 reste non autorisé ;
7. réinjecter une seule variante propre pour une nouvelle tentative.

Une remise à zéro ne doit jamais dépendre d’une infrastructure de production SORIA.