TP 12. Assembler l'architecture cible

Énoncé de travail pratique

Les commandes ne figurent pas dans les énoncés : elles se construisent à partir du chapitre déclencheur indiqué ci-dessous. Le laboratoire et le livret de corrections ne sont pas encore publiés. Voir les limites du livrable

Chapitre déclencheur : 29. Durée : 3 h.

Objectifs

Terminer l'architecture du fil rouge : mettre en service le répartiteur en passage aveugle, faire servir les nœuds par la PKI interne avec rechargement à chaud, appliquer la matrice de flux et prouver les refus, puis basculer l'entrée et vérifier que la bascule d'un nœud reste invisible des clients.

Prérequis

TP 11 terminé, cluster de trois nœuds sous Transit Seal. Chapitres 28 et 29 lus.

Étapes

1. Le répartiteur. Configurez lb-01 en mode passage, avec la sonde de routage qui attend le code de l'actif et vérifie le certificat des nœuds. Démarrez-le sans encore lui donner l'adresse de service.

2. Vérifier la sonde. Interrogez la santé des trois nœuds depuis lb-01 et vérifiez que seul l'actif est déclaré éligible. Modifiez temporairement la sonde pour accepter le code des standbys, observez la conséquence sur le routage, puis rétablissez.

3. Les certificats de la maison. Émettez pour chaque nœud un certificat portant en SAN le nom de service, le nom du nœud et son adresse. Déposez-les et rechargez chaque service sans le redémarrer, standbys d'abord. Vérifiez qu'aucun descellement n'a eu lieu.

4. Le renouvellement. Installez le minuteur de renouvellement fourni et forcez son exécution avec une échéance simulée. Vérifiez qu'il émet, dépose, recharge et alerte correctement. Débranchez ensuite volontairement l'alerte et constatez ce que l'on ne voit plus.

5. La matrice. Appliquez les règles de filtrage correspondant aux flux du chapitre 29. Puis testez les refus : depuis app-01, tentez d'atteindre le port d'un nœud en direct, puis transit-01 ; depuis monitor-01, tentez d'ouvrir une session vers un nœud. Les trois doivent échouer, et chaque échec se consigne comme preuve.

6. La bascule d'entrée. Faites pointer vault.astrea.lab vers le répartiteur. Depuis app-01, exécutez une connexion, une lecture, une émission dynamique et un chiffrement Transit : quatre succès à travers l'entrée.

7. La preuve finale. Pendant qu'un client boucle sur des lectures, tuez le processus du nœud actif. Mesurez le nombre d'erreurs vues par le client, le temps d'élection et le temps de convergence de la sonde. Comparez au TP 11, où le client parlait directement à un nœud.

8. La trace. Rédigez la ligne de registre de l'étape 5 du fil rouge, avec les mesures obtenues et les trois refus constatés.

Résultats attendus

Une entrée unique fonctionnelle en passage aveugle, trois nœuds servis par la PKI interne sans interruption ni descellement, une matrice appliquée dont trois refus sont prouvés, et une bascule d'actif dont l'impact client se mesure en quelques erreurs retentées.

Erreurs possibles et diagnostic

Le répartiteur ne route vers personne : la sonde attend un code que le cluster ne renvoie jamais, ou elle échoue sur la vérification du certificat, les journaux du répartiteur distinguent les deux. Les clients rejettent le certificat à travers l'entrée : le SAN du nom de service manque. Le rechargement provoque un descellement : vous avez redémarré au lieu de recharger. Le refus attendu ne se produit pas : une règle antérieure plus permissive s'applique avant la vôtre, ce qui est le défaut de pare-feu le plus fréquent.

Questions

1. Le répartiteur ne déchiffre rien. Qu'obtiendrait un attaquant qui le compromettrait, et qu'est-ce qui l'en empêche côté client ?
2. Pourquoi les trois refus testés valent-ils autant que les quatre succès ?
3. Comparez l'expérience client de la bascule au TP 11 et au TP 12. Qu'est-ce qui a changé, et qu'est-ce qui n'a pas changé ?