TP3 — Interconnexion : deux archipels, un tunnel

Conception d'architecture · Ingénieurs Avancé

🎯 Objectif de mission

Interconnecter votre base avec celle d'un autre groupe : négocier la fiche d'interconnexion, monter le tunnel IPsec site-à-site entre vos deux OPNsense, consommer un service de l'autre base à travers le tunnel, prouver la dépendance lien coupé — et clore le module par l'épreuve du destroy.

▸ Prérequis

TP2 terminé : AD, Nextcloud et supervision en service, matrice à jour
Un groupe partenaire, désigné en séance — votre pair d'interconnexion
En salle : les deux postes reliés (LAN de la salle, ou câble RJ45 direct entre les deux postes)
La fiche d'interconnexion vierge du dépôt (`public/templates/fiche-interconnexion-ipsec.csv`)

▸ Livrable attendu

La fiche d'interconnexion remplie à deux, le tunnel prouvé (SA établies + capture ESP), un service de l'autre base consommé à travers, la preuve inverse lien coupé, et l'épreuve du destroy validée par le balayage bash avant/après + check-vm.sh sur chaque VM reconstruite.

Conception d'architecture Ingénieurs · ESIROI IPsec site-à-site · fiche d'interconnexion · épreuve du destroy · ~6 h

1. Contexte — l’archipel voisin existe

Depuis le TP0, une note traînait en fin d’axe C : les autres archipels existent. Aujourd’hui ils ont un visage : un autre groupe, avec sa base, son plan d’adressage, son AD, son Nextcloud. Votre mission commune : relier vos deux bases par un tunnel chiffré, à travers un réseau qui n’appartient à aucune des deux.

C’est le format réel d’une interconnexion entre deux organisations : personne ne « configure le VPN » tout seul — deux équipes négocient un document, puis chacune configure son côté, et le tunnel ne monte que si les deux configurations se répondent exactement. Le désaccord de paramètres est le mode d’échec normal de l’exercice — c’est pour ça qu’on négocie par écrit d’abord.

2. Le modèle mental — IKE en deux phases

D’abord les deux pare-feu se mettent d’accord sur comment se parler, ensuite sur quel trafic protéger.

sequenceDiagram
  participant A as OPNsense — base G3
  participant B as OPNsense — base G7
  Note over A,B: Phase 1 (IKE_SA) — ouvrir un canal de négociation sécurisé
  A->>B: Propositions (IKEv2, AES-256, SHA-256, DH 14) + authentification PSK
  B->>A: Accord + échange Diffie-Hellman
  Note over A,B: secret partagé calculé, jamais transmis
  Note over A,B: Phase 2 (CHILD_SA) — quel trafic passe dans le tunnel
  A->>B: sélecteurs : 10.3.0.0/16 ⟷ 10.7.0.0/16 (ESP)
  B->>A: Accord — sélecteurs en miroir
  Note over A,B: Tunnel établi — le trafic circule chiffré (ESP)

Un tunnel qui ne monte pas, c’est presque toujours un désaccord : propositions différentes (« no proposal chosen »), sélecteurs qui ne sont pas en miroir, ou réseaux qui se chevauchent. Les trois se préviennent sur la fiche, pas dans les logs.

3. Palier E9 — Le transit est un réseau hostile

La 4ᵉ carte entre en jeu : em3 (opt4), pontée sur la carte réseau du poste du Membre A, VM éteinte. Selon la salle : les deux postes A des deux groupes sur le LAN de la salle, ou un câble RJ45 direct (adressage statique convenu à deux, ex. 172.16.99.0/29).

Ajoutez la carte (VBoxManage modifyvm — puis comptez les adaptateurs, le dépassement est silencieux) ou recréez la VM câblée d’un bloc avec create-opnsense-vm.sh --trunk <carte> --transit — mais --force détruit le disque : exportez d’abord votre config.xml. Vous avez le réflexe depuis le TP1 ; c’est lui qu’on teste.

Assignez, adressez, et traitez cette patte comme le réseau le plus hostile de votre architecture : vous ne le maîtrisez pas, il n’a droit à rien par défaut — seuls IKE et ESP y entrent.

Preuve E9 : le ping du pare-feu d’en face répond sur le transit. Le lien existe ; il n’est pas encore digne de confiance.

4. Palier E10 — La fiche, puis le tunnel

La fiche d’interconnexion — le livrable central

Remplissez-la à deux, avant toute configuration (gabarit : fiche-interconnexion-ipsec.csv) : identités des pairs, adresses de transit, propositions Phase 1 (IKEv2, AES-256, SHA-256, DH 14 — non négociables ici), sélecteurs Phase 2 en miroir, mode d’échange de la PSK. Trois correspondances obligatoires : propositions identiques, sélecteurs en miroir exact, réseaux disjoints.

Puis chacun configure son OPNsense, fiche en main — chaque champ de votre configuration doit correspondre à la ligne d’en face.

Preuve E10 : VPN ▸ IPsec ▸ Status Overview — Phase 1 ESTABLISHED, Phase 2 INSTALLED des deux côtés ; et la preuve que ça chiffre : un tcpdump sur le transit pendant un ping inter-bases montre de l’ESP, pas vos ICMP en clair.

5. Palier E11 — Le tunnel n’est pas un boulevard

Un tunnel monté autorise… rien, tant que vos matrices ne le disent pas. Décidez à deux ce que vos bases s’offrent mutuellement — un service, pas tout :

l’accès au Nextcloud de l’autre base, par exemple — un agent de l’archipel voisin vient consulter un document partagé ;
ou la remontée croisée : les refus pare-feu de l’autre base poussés vers votre Loki (une base surveille l’autre — préfiguration d’un SOC mutualisé).

Déclarez ce flux dans les deux matrices (source, destination, port, justification — comme toujours), et vérifiez l’inverse : tout le reste de l’autre base doit tomber en filtered à travers le tunnel. Votre AD, en particulier, n’a rien à offrir au voisin.

Preuve E11 : le service choisi répond à travers le tunnel ; un flux non déclaré (leur z-services, votre 3000…) tombe. Puis la preuve inverse : coupez le lien (débranchez, ou désactivez le tunnel) — le service de l’autre base devient injoignable, et vos deux SI continuent de fonctionner localement. Une base australe survit à la coupure : c’était le cahier des charges du TP0, le voilà prouvé.

6. Palier E12 — L’épreuve du destroy : la fin du module

Votre base tient. Reste à prouver qu’elle survivrait à celui qui l’a montée — une panne en hiver austral, six mois sans technicien, un hivernant qui réinstalle depuis votre dépôt :

# 1. La référence — le balayage bash de l'E4 (TP1), rejoué ici
DB=10.G.10.30
for p in 22 389 5432; do
  timeout 2 bash -c "</dev/tcp/$DB/$p" 2>/dev/null \
    && echo "$p  ouvert" || echo "$p  bloqué"
done

# 2. Détruire et rebâtir depuis le dépôt
vagrant destroy -f
vagrant up            # votre Vagrantfile + provisioning
# OPNsense : réimport du config.xml (Restore), réinjection des secrets

# 3. Sur CHAQUE VM reconstruite : l'état est-il bon ?
../check-vm.sh

# 4. La preuve : le même balayage repasse, à l'identique

Si le second balayage rend le même résultat, port par port — et que check-vm.sh passe sur chaque VM — sans une retouche manuelle non documentée, votre infrastructure est reproductible, et c’est une propriété de sécurité : la configuration exacte, celle que vous avez pensée et prouvée, revient à l’identique après sinistre. Si vous devez « juste retoucher un truc à la main », ce truc-là est précisément ce qui manque dans votre dépôt.

(L’AD Windows se réinstalle à la main — comme OPNsense : c’est votre procédure versionnée qui le rend reconstructible, pas un script. La reproductibilité a plusieurs formes : du code quand c’est possible, une procédure testée quand c’est le prix du composant.)

Preuve E12 : les deux balayages bash, avant/après, identiques port par port ; check-vm.sh au vert sur chaque VM reconstruite ; et un dépôt sans aucun secret (git grep -iE "password|psk|secret" ne rend rien de sensible ; un secret commité est un critère éliminatoire).

7. Livrable — le rendu final du module

La fiche d’interconnexion remplie à deux — le document qui a précédé toute configuration.
La preuve du tunnel — Status Overview des deux côtés + le tcpdump ESP.
Le service consommé à travers + la preuve que le reste tombe + la preuve inverse lien coupé.
Les deux matrices amendées — le flux inter-bases déclaré et justifié des deux côtés.
L’épreuve du destroy — le balayage bash avant/après identique, check-vm.sh au vert sur chaque VM reconstruite, le dépôt Git final propre.

8. Critères de réussite

Critère	Ce qu’on vérifie
La négociation a précédé la configuration	La fiche est remplie, cohérente, antérieure aux configs ; les trois correspondances tiennent.
Le transit est traité en hostile	Seuls IKE/ESP y entrent ; « Block private networks » décoché en connaissance de cause.
Le tunnel est monté et chiffré	SA établies des deux côtés, ESP au tcpdump.
Le tunnel n’est pas un boulevard	Le service déclaré passe, tout le reste tombe — dans les deux sens.
La dépendance est prouvée	Lien coupé : le service distant tombe, les deux bases vivent localement.
L’épreuve du destroy passe	Balayage bash identique avant/après reconstruction, `check-vm.sh` au vert sur chaque VM, dépôt sans secrets.