wiki-se.plil.fr - Contributions [fr]

SE4 IdO sécurité système/réseau 2025/2026

2026-03-03T12:12:05Z

Pcasimir : /* Répartition des binômes pour les travaux pratiques "administration système et réseau" */

= Répartition des binômes pour les travaux pratiques "administration système et réseau" =

Préfixe des noms de machine : <code>SE4</code>.

Domaines Internet à louer sur [[gandi.net]]. Identifiant <code>pifou</code>. Regardez le montant prévu sur le compte avant de louer un domaine.

{| class="wikitable"
! Cahier !! Elève !! Nom de domaine
! Nom de machine de services !! Nom de machine mandataire
|-
| [[Atelier SysRes SE4 2025/2026 E1 | Cahier n°1]] || Pierre CASIMIRI || merteuil.tech || SE4.Merteuil||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E2 | Cahier n°2]] || Agathe HOUDUSSE || valmont.tech || SE4.Valmont||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E3 | Cahier n°3]] || Lilia GHAZALI || kirchhoff.live|| SE4.Tension||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E4 | Cahier n°4]] || Marin GOURVEST || courant.online|| SE4.Courant||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E5 | Cahier n°5]] || Cédric PAYET || archlinuxbtw.lol|| SE4.CachyOS||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E6 | Cahier n°6]] || Thomas DELOBELLE || archlinux.lol|| SE4.Manjaro||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E7 | Cahier n°7]] || Ibrahim TEPELI || c2vts.fr|| SE4.C2||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E8 | Cahier n°8]] || Yassine YAHIANI || rs7.online|| SE4.RS7||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E9 | Cahier n°9]] || Aurèle VANGHELUWE || tompere.online|| SE4-Tompere1||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E10 | Cahier n°10]] || Tom MERIEN || tompere2.xyz|| SE4-Tompere2||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E11 | Cahier n°11]] || Varesse Evora Souop Metse || elvis21.tech|| SE4.Elf||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E12 | Cahier n°12]] || Mario Sylainx S. GAUTHIER || kasav.online|| SE4.Kasav||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E13 | Cahier n°13]] || Billel Cheklat || dardevil.tech|| SE4.catwoman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E14 | Cahier n°14]] || Antonin Biernacki || deadpool.tech|| SE4.batman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E15 | Cahier n°15]] || Mohamed Salhi || msalhi.online|| SE4.Moon||SE4.Solstice
|}

{| class="wikitable"
! Nom machine mandataire !! IPv4 publique machine mandataire !! Elèves
!numéro de binôme
!Adresse IPV4 OpenWRT
|-
| SE4.Rosemonde|| 193.48.57.165|| Pierre CASIMIRI & Agathe HOUDUSSE
|1
|193.48.57.177
|-
| SE4.Kirchhoff|| 193.48.57.171|| Lilia GHAZALI & Marin GOURVEST
|
|
|-
| SE4.LinusTorvalds|| 193.48.57.166|| Cédric PAYET & Thomas DELOBELLE
|3
|193.48.57.180
|-
| SE4.Garage|| 193.48.57.170|| Ibrahim TEPELI & Yassine YAHIANI
|4
|
|-
| SE4-Tompere0|| 193.48.57.168|| Aurèle VANGHELUWE & Tom MERIEN
|5
|
|-
| SE4.superman|| 193.48.57.169|| Billel Cheklat & Antonin Biernacki
|7
|
|-
| SE4.RockStar|| 193.48.57.172|| Varesse Evora Souop Metse & GAUTHIER Mario Sylainx S.
|6
|193.48.57.100
|-
| SE4.Solstice|| 193.48.57.167|| Mohamed Salhi
|2
|
|-
|}

= Tableau des commutateurs virtuels =

{| class="wikitable"
! Noms des élèves !! Nom du fichier de configuration !! Réseau IPv4 utilisé
|-
| CASIMIRI / HOUDUSSE || pont_gercourt || 192.168.3.0/24
|-
|PAYET / DELOBELLE
|pont_pacman
|192.168.10.0/24
|-
|MERIEN / VANGHELUWE
|pont_pere
|192.168.0.0/24
|-
|CHEKLAT / BIERNACKI
|pont_ironman
|192.168.69.0/24
|-
|SALHI
|pont_msalhi
|192.168.20.0/24
|-
|GOURVEST/GHAZALI
|pont_diviseur
|192.168.67.0/24
|-
|YAHIANI / TEPELI
|pontclio
|192.168.7.0/24
|-
|GAUTHIER / SOUOP METSE
|Styx
|192.168.50.0/24
|}

= Tableau des réseaux virtuels =

VLAN privés :

{| class="wikitable"
! Nom !! Numéro
|-
| VLAN1 || 1
|-
| MV-PROMO || 2
|-
|E1-Pierre
|11
|-
|E2-Agathe
|12
|-
|E5-Cedric
|15
|-
|E6-Thomas
|16
|-
|E9-Aurele
|19
|-
|E10-Tom
|20
|-
|E13-Billel
|23
|-
|E14-Antonin
|24
|-
|E15-MSalhi
|25
|-
|E11-Evora
|28
|-
|E12-Gauthier
|21
|-
|E8-Yassine
|18
|-
|E7-Ibrahim
|17
|}

VLAN communs avec l'école :

{| class="wikitable"
! Nom !! Numéro
|-
| INTERCO1 || 530
|-
|}

= Schéma de câblage =

Vous avez des éléments réseaux et des panneaux de brassage fibres dans les locaux techniques SR31 et SR52 ainsi que dans les salles E304 et E306.

Le plan doit donc comporter, pour chaque connexion, les locaux d'origine et de destination ainsi que l'identifiant des ports d'origine et de destination.

= Plan d'adressage =

{| class="wikitable"
! Nom VLAN !! Réseau IPv4 !! Réseau IPv6
|-
| MV-PROMO || <code>193.48.57.160/27</code> || </code>2001:660:4401:60a0::/64</code>
|-
| PoolPierre || <code>10.60.1.0/24</code> || </code>2001:660:4401:60a1::/64</code>
|-
| PoolAgathe || <code>10.60.2.0/24</code> || </code>2001:660:4401:60a2::/64</code>
|-
|PoolCedric
|<code>10.60.5.0/24</code>
|2001:660:4401:60a5::/64
|-
|PoolThomas
|<code>10.60.6.0/24</code>
|2001:660:4401:60a6::/64
|-
|PoolBillel
|<code>10.60.13.0/24</code>
|2001:660:4401:60ad::/64
|-
|PoolAurele
|<code>10.60.9.0/24</code>
|2001:660:4401:60a9::/64
|-
|PoolTom
|<code>10.60.10.0/24</code>
|2001:660:4401:60aa::/64
|-
|PoolSalhi
|<code>10.60.15.0/24</code>
|2001:660:4401:60b1::/64
|-
|PoolAntonin
|<code>10.60.14.0/24</code>
|2001:660:4401:60ae::/64
|-
|PoolYassine
|10.60.8.0/24
|2001:660:4401:60a8::/64
|-
|PoolEvora
|10.60.11.0/24
|2001:660:4401:60ab::/64
|}

Adresses IPv4 des éléments réseau dans VLAN1

{| class="wikitable"
! Elément !! Adresse
|-
| Routeur C9200-E304 || 172.27.0.1/16
|-
| Routeur C9200-E306 || 172.27.0.2/16
|-
| Borne Wi-Fi E306 || 172.27.0.3/16
|-
| Borne Wi-Fi E304 || 172.27.0.4/16
|}

= Informations VRRP =

Pour chaque VLAN et pour chaque instance VRRP dans le VLAN listez les adresses IPv4 propres ainsi que l'unique IPv4 virtuelle.

== VLAN des machines virtuelles ==

Une seule instance VRRP dans le VLAN des machines virtuelles.

Adresse IPv4 virtuelle : <code>193.48.57.162</code>

{| class="wikitable"
! Routeur !! IPv4 propre
|-
| C9200 E304 || <code>193.48.57.163</code>
|-
| C9200 E306 || <code>193.48.57.164</code>
|-
|}

== VLAN ... ==

Atelier SysRes SE4 2025/2026 E1

2026-03-01T16:46:02Z

Pcasimir : /* Comment lire ça ? */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', on a '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : on peut dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, on es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* on peut ajouter autant de VIF que on veux '''en théorie'''
* en pratique : on restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie nos '''3 machines''' (nos VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que nos VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), on peut utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge/commutateur virtuel Xen/Linux sur lequel on connectes cette VIF

c’est littéralement “sur quel switch virtuel on branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que on retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc on '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter nos volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, on a une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher nos volumes logiques LVM, on ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand on en a beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, on a :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si on oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, on va vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si on déplace <code>/var</code> sur le host, on peut casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, on évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : on déclares des VIF ====
Dans le fichier de config Xen de ta VM, on a un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* On crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP on es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>On verras <code>eth0</code>, <code>eth1</code> et leurs MAC. On peut matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre nos VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> on mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que on mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* nos machines ne changent pas leur config, ça continue de router

Si on mets directement <code>.163</code> ou <code>.164</code> en gateway :

* on forces l’utilisation d’un routeur précis
* on perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

==== Le problème ====
VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → on rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → on rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc on exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si on a une politique restrictive). Dans ton cas, on n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code> (ces adresses seront à rajoutées pour la suite du TP pour l'instant ne les ajoutés pas)

==== Autre amélioration très recommandée : préciser l’interface de sortie ====

Sans <code>-o eth1</code>, on peut NATer des flux que on ne voulais pas NATer si on a plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

==== Explication de PREROUTING et POSTROUTING ====

===== PREROUTING : “avant la décision de routage” =====
'''Quand ?'''

Dès qu’un paquet '''entre''' sur la machine (depuis une interface réseau), ''avant'' que Linux décide s’il doit :

* le garder pour lui (INPUT),
* ou le renvoyer vers un autre réseau (FORWARD).

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''DNAT''' (redirection de destination), parce que on veux changer la destination '''avant''' que le kernel choisisse où l’envoyer.

'''Exemple concret (port forwarding)'''

Quelqu’un sur Internet contacte :

* <code>193.48.57.165:2201</code>

Ta règle en PREROUTING fait :

* destination devient <code>192.168.3.2:22</code>

Ensuite seulement, Linux dit :

“ok, ça doit partir vers le réseau interne” → il route vers <code>192.168.3.2</code>.

PREROUTING = “je reçois le colis, je regarde l’étiquette et j’ai encore le droit de la changer avant de choisir le camion.”

===== POSTROUTING : “juste avant de sortir” =====
'''Quand ?'''

Après que Linux a déjà décidé '''par où''' le paquet sort (quelle interface, quelle route), et juste avant qu’il quitte la machine.

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''SNAT / MASQUERADE''' (changer l’adresse source), parce que :

* on sais maintenant exactement sur quelle interface ça sort,
* et donc quelle IP source externe utiliser.

'''Exemple concret (NAT sortant / masquerade)'''

Une VM interne envoie vers Internet :

* source <code>192.168.3.2</code> → destination <code>1.2.3.4</code>

En POSTROUTING, on remplaces la source :

* source devient <code>193.48.57.165</code> (IP publique du mandataire)

Comme ça, Internet répond à <code>193.48.57.165</code>, et le mandataire retransmet à la VM grâce à conntrack.

POSTROUTING = “le colis est déjà assigné à un camion (interface de sortie), je peut encore modifier l’étiquette avant qu’il parte.”

===== Résumé =====

* '''PREROUTING''' : avant le routage → on change surtout la '''destination''' (DNAT / redirections de ports)
* '''POSTROUTING''' : après le routage → on change surtout la '''source''' (SNAT / MASQUERADE)

= Serveur SSH et Fail2ban =

=== Objectif : se connecter en SSH depuis l’extérieur ===
Dans notre archi :

* Les '''VM services''' sont en IPv4 privé (<code>192.168.3.x</code>) → pas accessibles directement depuis Internet en IPv4.
* Le '''mandataire''' (Rosemonde) a une IPv4 publique (<code>193.48.57.165</code>) → c’est lui qui reçoit les connexions externes.
* Donc pour SSH vers une VM service en IPv4, on fait une '''redirection de port (DNAT)''' sur Rosemonde.

Exemple (déjà dans nos règles NAT) :

* <code>193.48.57.165:2201</code> → <code>192.168.3.2:22</code>
* <code>193.48.57.165:2021</code> → <code>192.168.3.3:22</code>

=== Fail2ban pour SSH ===

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T21:09:42Z

Pcasimir : /* Cassage de clé WIFI */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', on a '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : on peut dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, on es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* on peut ajouter autant de VIF que on veux '''en théorie'''
* en pratique : on restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie nos '''3 machines''' (nos VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que nos VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), on peut utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel on connectes cette VIF

c’est littéralement “sur quel switch virtuel on branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que on retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc on '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter nos volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, on a une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher nos volumes logiques LVM, on ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand on en a beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, on a :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si on oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, on va vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si on déplace <code>/var</code> sur le host, on peut casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, on évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : on déclares des VIF ====
Dans le fichier de config Xen de ta VM, on a un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* On crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP on es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>On verras <code>eth0</code>, <code>eth1</code> et leurs MAC. On peut matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre nos VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> on mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que on mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* nos machines ne changent pas leur config, ça continue de router

Si on mets directement <code>.163</code> ou <code>.164</code> en gateway :

* on forces l’utilisation d’un routeur précis
* on perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

==== Le problème ====
VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → on rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → on rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc on exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si on a une politique restrictive). Dans ton cas, on n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code> (ces adresses seront à rajoutées pour la suite du TP pour l'instant ne les ajoutés pas)

==== Autre amélioration très recommandée : préciser l’interface de sortie ====

Sans <code>-o eth1</code>, on peut NATer des flux que on ne voulais pas NATer si on a plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

==== Explication de PREROUTING et POSTROUTING ====

===== PREROUTING : “avant la décision de routage” =====
'''Quand ?'''

Dès qu’un paquet '''entre''' sur la machine (depuis une interface réseau), ''avant'' que Linux décide s’il doit :

* le garder pour lui (INPUT),
* ou le renvoyer vers un autre réseau (FORWARD).

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''DNAT''' (redirection de destination), parce que on veux changer la destination '''avant''' que le kernel choisisse où l’envoyer.

'''Exemple concret (port forwarding)'''

Quelqu’un sur Internet contacte :

* <code>193.48.57.165:2201</code>

Ta règle en PREROUTING fait :

* destination devient <code>192.168.3.2:22</code>

Ensuite seulement, Linux dit :

“ok, ça doit partir vers le réseau interne” → il route vers <code>192.168.3.2</code>.

PREROUTING = “je reçois le colis, je regarde l’étiquette et j’ai encore le droit de la changer avant de choisir le camion.”

===== POSTROUTING : “juste avant de sortir” =====
'''Quand ?'''

Après que Linux a déjà décidé '''par où''' le paquet sort (quelle interface, quelle route), et juste avant qu’il quitte la machine.

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''SNAT / MASQUERADE''' (changer l’adresse source), parce que :

* on sais maintenant exactement sur quelle interface ça sort,
* et donc quelle IP source externe utiliser.

'''Exemple concret (NAT sortant / masquerade)'''

Une VM interne envoie vers Internet :

* source <code>192.168.3.2</code> → destination <code>1.2.3.4</code>

En POSTROUTING, on remplaces la source :

* source devient <code>193.48.57.165</code> (IP publique du mandataire)

Comme ça, Internet répond à <code>193.48.57.165</code>, et le mandataire retransmet à la VM grâce à conntrack.

POSTROUTING = “le colis est déjà assigné à un camion (interface de sortie), je peut encore modifier l’étiquette avant qu’il parte.”

===== Résumé =====

* '''PREROUTING''' : avant le routage → on change surtout la '''destination''' (DNAT / redirections de ports)
* '''POSTROUTING''' : après le routage → on change surtout la '''source''' (SNAT / MASQUERADE)

= Serveur SSH et Fail2ban =

=== Objectif : se connecter en SSH depuis l’extérieur ===
Dans notre archi :

* Les '''VM services''' sont en IPv4 privé (<code>192.168.3.x</code>) → pas accessibles directement depuis Internet en IPv4.
* Le '''mandataire''' (Rosemonde) a une IPv4 publique (<code>193.48.57.165</code>) → c’est lui qui reçoit les connexions externes.
* Donc pour SSH vers une VM service en IPv4, on fait une '''redirection de port (DNAT)''' sur Rosemonde.

Exemple (déjà dans nos règles NAT) :

* <code>193.48.57.165:2201</code> → <code>192.168.3.2:22</code>
* <code>193.48.57.165:2021</code> → <code>192.168.3.3:22</code>

=== Fail2ban pour SSH ===

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T17:25:33Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', on a '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : on peut dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, on es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* on peut ajouter autant de VIF que on veux '''en théorie'''
* en pratique : on restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie nos '''3 machines''' (nos VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que nos VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), on peut utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel on connectes cette VIF

c’est littéralement “sur quel switch virtuel on branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que on retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc on '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter nos volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, on a une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher nos volumes logiques LVM, on ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand on en a beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, on a :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si on oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, on va vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si on déplace <code>/var</code> sur le host, on peut casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, on évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : on déclares des VIF ====
Dans le fichier de config Xen de ta VM, on a un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* On crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP on es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>On verras <code>eth0</code>, <code>eth1</code> et leurs MAC. On peut matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre nos VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> on mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que on mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* nos machines ne changent pas leur config, ça continue de router

Si on mets directement <code>.163</code> ou <code>.164</code> en gateway :

* on forces l’utilisation d’un routeur précis
* on perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

==== Le problème ====
VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → on rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → on rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc on exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si on a une politique restrictive). Dans ton cas, on n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code> (ces adresses seront à rajoutées pour la suite du TP pour l'instant ne les ajoutés pas)

==== Autre amélioration très recommandée : préciser l’interface de sortie ====

Sans <code>-o eth1</code>, on peut NATer des flux que on ne voulais pas NATer si on a plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

==== Explication de PREROUTING et POSTROUTING ====

===== PREROUTING : “avant la décision de routage” =====
'''Quand ?'''

Dès qu’un paquet '''entre''' sur la machine (depuis une interface réseau), ''avant'' que Linux décide s’il doit :

* le garder pour lui (INPUT),
* ou le renvoyer vers un autre réseau (FORWARD).

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''DNAT''' (redirection de destination), parce que on veux changer la destination '''avant''' que le kernel choisisse où l’envoyer.

'''Exemple concret (port forwarding)'''

Quelqu’un sur Internet contacte :

* <code>193.48.57.165:2201</code>

Ta règle en PREROUTING fait :

* destination devient <code>192.168.3.2:22</code>

Ensuite seulement, Linux dit :

“ok, ça doit partir vers le réseau interne” → il route vers <code>192.168.3.2</code>.

PREROUTING = “je reçois le colis, je regarde l’étiquette et j’ai encore le droit de la changer avant de choisir le camion.”

===== POSTROUTING : “juste avant de sortir” =====
'''Quand ?'''

Après que Linux a déjà décidé '''par où''' le paquet sort (quelle interface, quelle route), et juste avant qu’il quitte la machine.

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''SNAT / MASQUERADE''' (changer l’adresse source), parce que :

* on sais maintenant exactement sur quelle interface ça sort,
* et donc quelle IP source externe utiliser.

'''Exemple concret (NAT sortant / masquerade)'''

Une VM interne envoie vers Internet :

* source <code>192.168.3.2</code> → destination <code>1.2.3.4</code>

En POSTROUTING, on remplaces la source :

* source devient <code>193.48.57.165</code> (IP publique du mandataire)

Comme ça, Internet répond à <code>193.48.57.165</code>, et le mandataire retransmet à la VM grâce à conntrack.

POSTROUTING = “le colis est déjà assigné à un camion (interface de sortie), je peut encore modifier l’étiquette avant qu’il parte.”

===== Résumé =====

* '''PREROUTING''' : avant le routage → on change surtout la '''destination''' (DNAT / redirections de ports)
* '''POSTROUTING''' : après le routage → on change surtout la '''source''' (SNAT / MASQUERADE)

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T15:11:15Z

Pcasimir : /* Mini résumé ultra clair */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie nos '''3 machines''' (nos VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que nos VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter nos volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher nos volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre nos VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* nos machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

==== Le problème ====
VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → tu rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → tu rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc tu exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si tu as une politique restrictive). Dans ton cas, tu n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code> (ces adresses seront à rajoutées pour la suite du TP pour l'instant ne les ajoutés pas)

==== Autre amélioration très recommandée : préciser l’interface de sortie ====

Sans <code>-o eth1</code>, tu peux NATer des flux que tu ne voulais pas NATer si tu as plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

==== Explication de PREROUTING et POSTROUTING ====

===== PREROUTING : “avant la décision de routage” =====
'''Quand ?'''

Dès qu’un paquet '''entre''' sur la machine (depuis une interface réseau), ''avant'' que Linux décide s’il doit :

* le garder pour lui (INPUT),
* ou le renvoyer vers un autre réseau (FORWARD).

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''DNAT''' (redirection de destination), parce que tu veux changer la destination '''avant''' que le kernel choisisse où l’envoyer.

'''Exemple concret (port forwarding)'''

Quelqu’un sur Internet contacte :

* <code>193.48.57.165:2201</code>

Ta règle en PREROUTING fait :

* destination devient <code>192.168.3.2:22</code>

Ensuite seulement, Linux dit :

“ok, ça doit partir vers le réseau interne” → il route vers <code>192.168.3.2</code>.

PREROUTING = “je reçois le colis, je regarde l’étiquette et j’ai encore le droit de la changer avant de choisir le camion.”

===== POSTROUTING : “juste avant de sortir” =====
'''Quand ?'''

Après que Linux a déjà décidé '''par où''' le paquet sort (quelle interface, quelle route), et juste avant qu’il quitte la machine.

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''SNAT / MASQUERADE''' (changer l’adresse source), parce que :

* tu sais maintenant exactement sur quelle interface ça sort,
* et donc quelle IP source externe utiliser.

'''Exemple concret (NAT sortant / masquerade)'''

Une VM interne envoie vers Internet :

* source <code>192.168.3.2</code> → destination <code>1.2.3.4</code>

En POSTROUTING, tu remplaces la source :

* source devient <code>193.48.57.165</code> (IP publique du mandataire)

Comme ça, Internet répond à <code>193.48.57.165</code>, et le mandataire retransmet à la VM grâce à conntrack.

POSTROUTING = “le colis est déjà assigné à un camion (interface de sortie), je peux encore modifier l’étiquette avant qu’il parte.”

===== Résumé =====

* '''PREROUTING''' : avant le routage → on change surtout la '''destination''' (DNAT / redirections de ports)
* '''POSTROUTING''' : après le routage → on change surtout la '''source''' (SNAT / MASQUERADE)

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T15:10:58Z

Pcasimir : /* Autre amélioration très recommandée : préciser l’interface de sortie */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie nos '''3 machines''' (nos VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que nos VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter nos volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher nos volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre nos VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* nos machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

==== Le problème ====
VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → tu rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → tu rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc tu exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si tu as une politique restrictive). Dans ton cas, tu n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code> (ces adresses seront à rajoutées pour la suite du TP pour l'instant ne les ajoutés pas)

==== Autre amélioration très recommandée : préciser l’interface de sortie ====

Sans <code>-o eth1</code>, tu peux NATer des flux que tu ne voulais pas NATer si tu as plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

==== Explication de PREROUTING et POSTROUTING ====

===== PREROUTING : “avant la décision de routage” =====
'''Quand ?'''

Dès qu’un paquet '''entre''' sur la machine (depuis une interface réseau), ''avant'' que Linux décide s’il doit :

* le garder pour lui (INPUT),
* ou le renvoyer vers un autre réseau (FORWARD).

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''DNAT''' (redirection de destination), parce que tu veux changer la destination '''avant''' que le kernel choisisse où l’envoyer.

'''Exemple concret (port forwarding)'''

Quelqu’un sur Internet contacte :

* <code>193.48.57.165:2201</code>

Ta règle en PREROUTING fait :

* destination devient <code>192.168.3.2:22</code>

Ensuite seulement, Linux dit :

“ok, ça doit partir vers le réseau interne” → il route vers <code>192.168.3.2</code>.

PREROUTING = “je reçois le colis, je regarde l’étiquette et j’ai encore le droit de la changer avant de choisir le camion.”

===== POSTROUTING : “juste avant de sortir” =====
'''Quand ?'''

Après que Linux a déjà décidé '''par où''' le paquet sort (quelle interface, quelle route), et juste avant qu’il quitte la machine.

'''À quoi ça sert ?'''

C’est l’endroit parfait pour faire du '''SNAT / MASQUERADE''' (changer l’adresse source), parce que :

* tu sais maintenant exactement sur quelle interface ça sort,
* et donc quelle IP source externe utiliser.

'''Exemple concret (NAT sortant / masquerade)'''

Une VM interne envoie vers Internet :

* source <code>192.168.3.2</code> → destination <code>1.2.3.4</code>

En POSTROUTING, tu remplaces la source :

* source devient <code>193.48.57.165</code> (IP publique du mandataire)

Comme ça, Internet répond à <code>193.48.57.165</code>, et le mandataire retransmet à la VM grâce à conntrack.

POSTROUTING = “le colis est déjà assigné à un camion (interface de sortie), je peux encore modifier l’étiquette avant qu’il parte.”

===== Mini résumé ultra clair =====

* '''PREROUTING''' : avant le routage → on change surtout la '''destination''' (DNAT / redirections de ports)
* '''POSTROUTING''' : après le routage → on change surtout la '''source''' (SNAT / MASQUERADE)

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T15:08:29Z

Pcasimir : /* Le problème */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie nos '''3 machines''' (nos VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que nos VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter nos volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher nos volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre nos VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* nos machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

==== Le problème ====
VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → tu rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → tu rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc tu exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si tu as une politique restrictive). Dans ton cas, tu n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code> (ces adresses seront à rajoutées pour la suite du TP pour l'instant ne les ajoutés pas)

=== Autre amélioration très recommandée : préciser l’interface de sortie ===
Sans <code>-o eth1</code>, tu peux NATer des flux que tu ne voulais pas NATer si tu as plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T15:00:07Z

Pcasimir : /* Le problème */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie tes '''3 machines''' (tes VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que tes VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter tes volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher tes volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre tes VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* tes machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

=== Le problème ===
Tes VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → tu rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → tu rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc tu exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si tu as une politique restrictive). Dans ton cas, tu n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code> (ces adresses seront à rajoutées pour la suite du TP pour l'instant ne les ajoutés pas)

=== Autre amélioration très recommandée : préciser l’interface de sortie ===
Sans <code>-o eth1</code>, tu peux NATer des flux que tu ne voulais pas NATer si tu as plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T14:58:19Z

Pcasimir : /* MASCARED D'IP */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie tes '''3 machines''' (tes VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que tes VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter tes volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher tes volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre tes VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* tes machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

=== Le problème ===
Tes VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>
Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)
Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>
Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

==== Lire un fichier iptables <code>/etc/iptables/rules.v4</code> ====
<syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → tu rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → tu rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc tu exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si tu as une politique restrictive). Dans ton cas, tu n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code>

=== Autre amélioration très recommandée : préciser l’interface de sortie ===
Sans <code>-o eth1</code>, tu peux NATer des flux que tu ne voulais pas NATer si tu as plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-25T14:51:49Z

Pcasimir : /* Cassage de clé WIFI */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie tes '''3 machines''' (tes VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que tes VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter tes volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher tes volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre tes VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* tes machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

=== MASCARED D'IP ===

=== Le problème ===
Tes VM de service sont en '''IPv4 privé''' (ex: <code>192.168.3.x</code>).

Ces adresses '''ne sont pas routables sur Internet''' (elles n’existent pas “officiellement” sur le réseau public).

Donc si une VM <code>192.168.3.2</code> envoie un paquet vers Internet (ex: <code>8.8.8.8</code>), le monde extérieur ne peut pas répondre directement à <code>192.168.3.2</code> → c’est une adresse privée.

'''La solution : NAT sortant (Masquerade)'''

La machine '''mandataire''' (Rosemonde dans mon cas) joue le rôle de '''gateway NAT''' :

* '''En interne''' : les services parlent en <code>192.168.3.x</code>
* '''En externe''' : le mandataire remplace l’IP source par '''son IP publique''' (ex: <code>193.48.57.165</code>)

Donc vu depuis Internet, tout semble venir de <code>193.48.57.165</code>.

C’est exactement ce que fait <code>MASQUERADE</code> :<blockquote>“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”</blockquote>
Le NAT n’est pas “juste une règle”. Ça marche avec un système d’état appelé '''conntrack''' (suivi de connexions).

Exemple : la VM <code>192.168.3.2</code> fait un <code>apt update</code> vers un serveur public <code>X.X.X.X:443</code>.

# La VM envoie :

* source = <code>192.168.3.2:54321</code>
* destination = <code>X.X.X.X:443</code>

# Le mandataire applique <code>MASQUERADE</code> en sortie (POSTROUTING) :

* source devient <code>193.48.57.165:40000</code> (port éventuellement modifié)

# Le mandataire enregistre une “table de correspondance” (conntrack) :

* <code>192.168.3.2:54321</code> ↔ <code>193.48.57.165:40000</code>

# Quand la réponse revient de <code>X.X.X.X:443</code> vers <code>193.48.57.165:40000</code>, le mandataire “dé-NAT” automatiquement et renvoie vers :

* <code>192.168.3.2:54321</code>

Donc le NAT permet à '''plusieurs machines privées''' de partager '''une seule IPv4 publique''' grâce à :

* réécriture d’IP
* réécriture de ports (PAT)
* suivi d’état (conntrack)

Lire un fichier iptables <code>/etc/iptables/rules.v4</code><syntaxhighlight lang="bash">
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Jan 22 18:31:33 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp -m tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE

-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 18:31:33 2026
</syntaxhighlight><syntaxhighlight lang="bash">
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT
</syntaxhighlight>'''Les chaînes (ultra important)'''

* '''PREROUTING''' : NAT fait ''avant'' que Linux décide où router le paquet → typiquement '''DNAT''' (port forwarding)
* '''POSTROUTING''' : NAT fait ''juste avant'' que le paquet sorte sur une interface → typiquement '''SNAT/MASQUERADE''' (NAT sortant)
<syntaxhighlight lang="bash">
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2201 -j DNAT --to-destination 192.168.3.2:22
-A PREROUTING -d 193.48.57.165/32 -p tcp --dport 2021 -j DNAT --to-destination 192.168.3.3:22
</syntaxhighlight>Ça veut dire :

* Si quelqu’un sur Internet fait :
** <code>193.48.57.165:2201</code> → tu rediriges vers <code>192.168.3.2:22</code> (SSH)
** <code>193.48.57.165:2021</code> → tu rediriges vers <code>192.168.3.3:22</code> (SSH)

Donc tu exposes plusieurs SSH internes via '''un seul serveur public''', en jouant sur les ports.

Note importante : DNAT ne suffit pas toujours tout seul : il faut aussi que le '''forwarding''' soit autorisé (et éventuellement règles <code>filter</code> si tu as une politique restrictive). Dans ton cas, tu n’as montré que la table <code>nat</code>.<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE
</syntaxhighlight>Traduction :

* Tout paquet qui '''sort''' et dont la source est dans <code>192.168.3.0/29</code> verra son IP source remplacée par l’IP publique du mandataire.
* Pareil pour <code>10.60.0.0/16</code>.

=== Autre amélioration très recommandée : préciser l’interface de sortie ===
Sans <code>-o eth1</code>, tu peux NATer des flux que tu ne voulais pas NATer si tu as plusieurs sorties. La version “propre” :<syntaxhighlight lang="bash">
-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE
</syntaxhighlight>Mais dans notre TP, il n'y pas besoin de ça

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-24T16:42:36Z

Pcasimir : /* 1) Les VIF : cartes réseau virtuelles de la VM */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

Dans Xen, chaque entrée <code>vif</code> du fichier <code>.cfg</code> correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces <code>eth0</code>, <code>eth1</code>, etc. Le paramètre <code>bridge=...</code> indique sur quel commutateur virtuel (bridge Xen/Linux) la carte est connectée.

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie tes '''3 machines''' (tes VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que tes VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter tes volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher tes volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre tes VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* tes machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-24T14:26:14Z

Pcasimir : /* VRRP : c’est quoi cette gateway 193.48.57.162 ? */

== CRÉATION MACHINES VIRTUELLES ==
Il faut d'abord crée un "bridge" sur capbreton pour relier nos 3 machines virtuelles ensemble. Un "bridge" n'a rien de complexe, c'est un commutateur mais virtuel. C'est comme un commutateur physique avec des ports ethernet pour relier des machines ensemble mais il n'existe pas dans le monde physique seulement sur nos ordinateurs et VM. Pour cela, nous créons notre pont sur capbreton le commutateur/routeur dans la E304. Nous le faisons dans ce chemin : <code>/etc/network/interfaces.d/SE42026_pcasimir_ahoudus</code>

Veuillez faire en sorte de ne <code>PAS</code> modifier le fichier le fichier <code>/etc/network/interfaces</code> car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.
<syntaxhighlight lang="bash">
auto pont_Gercourt
iface pont_Gercourt inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down

</syntaxhighlight>

Ensuite, nous devons initialiser nos MV de services grâce à l'outil hyperviseur <code>Xen</code>.

Un '''hyperviseur''', c’est le logiciel qui permet de faire tourner '''plusieurs “ordinateurs virtuels” (VM)''' sur '''un seul ordinateur physique'''.

Au lieu d’avoir '''1 machine = 1 OS''', tu as '''1 machine physique = plusieurs OS''' (Linux, OpenWRT, Windows…) qui tournent en parallèle, chacun dans sa VM.

Un hyperviseur est “entre” le matériel et les VM, et il s’occupe de partager proprement :

* '''CPU''' : qui a le droit d’exécuter quand (ordonnancement)
* '''RAM''' : qui a droit à quelle mémoire (isolation, allocation)
* '''Disques''' : chaque VM a “son disque” (souvent un fichier <code>.img</code>, LVM, etc.)
* '''Réseau''' : chaque VM a une carte réseau virtuelle, connectée à un '''switch/bridge virtuel'''
* '''Isolation/Sécurité''' : une VM ne doit pas pouvoir casser les autres.

'''Xen''', c’est un hyperviseur “bare-metal” très utilisé historiquement en serveur/cloud.

Dans Xen, toutes les VM sont des ''domains''.

* '''Dom0 (Domain 0)''' : la VM “chef” (privilégiée)
** c’est elle qui a les '''drivers matériels'''
** c’est elle qui '''crée / détruit / configure''' les autres VM
** elle gère souvent le '''réseau (bridges/VLAN)''' et le '''stockage'''
* '''DomU''' : les VM “normales” (invitées)
** elles ont des '''périphériques virtuels'''
** elles passent souvent par Dom0 pour accéder au hardware

Petit schéma mental :<syntaxhighlight lang="bash">
Matériel (CPU/RAM/NIC/Disques)
│
Xen
│
┌───────────┴───────────┐
│ │
Dom0 Dom1, Dom2, Dom3...
(admin + drivers) (VM Linux / OpenWRT / etc.)
</syntaxhighlight>Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Merteuil</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire. Vous devriez quand même configuré votre <code>/etc/network/interface</code> dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

=== Volumes Logiques ===
Dans notre infra, on ne met pas tout le système d’une VM sur un seul “disque” géant. On '''sépare certains répertoires''' dans des '''volumes logiques (LVM)''' dédiés, notamment :

* '''<code>/home</code>''' : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
* '''<code>/var</code>''' : données qui bougent beaucoup (logs, cache, bases de données, spool, etc.)

Cette séparation a plusieurs avantages très concrets :

* '''Meilleure gestion de l’espace disque''' : tu peux dimensionner <code>/var</code> et <code>/home</code> indépendamment (et agrandir si besoin).
* '''Moins de risques''' : si <code>/var</code> explose (logs qui partent en vrille, cache énorme…), ça évite de remplir tout le disque système et de “tuer” la VM.
* '''Maintenance plus simple''' : sauvegarde/restauration ciblée (ex : sauvegarder <code>/home</code> sans prendre tout le système).
* '''Organisation propre''' : chaque VM a ses volumes clairement identifiés.

Pour chaque VM, on crée deux volumes logiques de 10 Go :<syntaxhighlight lang="bash">
lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual
</syntaxhighlight>

* <code>lvcreate</code> : commande qui '''crée un volume logique'''
* <code>-L 10G</code> : taille du volume (ici '''10 Go''')
* <code>-n <nom></code> : nom du volume logique (d’où le <code>SE4.<NomDeVM>.home</code>)
* <code>virtual</code> : le '''Volume Group''' dans lequel on crée le volume

Ces volumes seront ensuite '''attachés à la VM''' comme des disques (ou partitions virtuelles), puis '''formatés''' et '''montés''' dans la VM :

* le volume <code>.home</code> sera monté sur <code>/home</code>
* le volume <code>.var</code> sera monté sur <code>/var</code>

=== Fichier de configuration Xen ===

==== 0) Éditer le fichier de configuration Xen de la VM (réseau + disques) ====
Après avoir généré une VM avec <code>xen-create-image</code>, un '''fichier de configuration''' est créé pour cette VM (souvent un <code>.cfg</code>).

C’est ce fichier qui dit à Xen :

* quels '''disques''' (images, volumes LVM…) la VM utilise
* combien de RAM/vCPU
* et surtout quelles '''interfaces réseau virtuelles''' (VIF) elle a, et sur quels '''bridges''' elles sont branchées
<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]

#
# Hostname
#
name = 'SE4.Merteuil'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt' ,
'mac=00:16:3E:47:BB:E7,bridge=SE4' ]
</syntaxhighlight>

==== 1) Les VIF : cartes réseau virtuelles de la VM ====
Une '''VIF (Virtual Interface)''', c’est tout simplement une '''carte réseau virtuelle''' vue par la VM.

Dans la VM, elle apparaîtra comme une interface réseau (genre <code>eth0</code>, <code>eth1</code>, etc., selon l’OS).

===== Différence avec une machine physique =====
Sur un PC “réel”, tu es limité :

* par le nombre de ports Ethernet / cartes réseau dispo physiquement

Dans une VM, pas ce souci :

* tu peux ajouter autant de VIF que tu veux '''en théorie'''
* en pratique : tu restes limité par la perf + la complexité de ton archi réseau (mais c’est déjà énorme)

==== 2) Ce qu’on veut dans le TP : 2 cartes réseau ====
Dans le cadre du TP, on te demande '''2 VIF''' :

'''VIF 1 : réseau interne de ton groupe (bridge du “switch” virtuel)'''

* branchée sur le '''bridge''' qui relie tes '''3 machines''' (tes VM du groupe)
* ici : <code>pont_Gercourt</code>

Objectif : que tes VMs communiquent entre elles comme si elles étaient branchées sur le même switch.

'''VIF 2 : réseau “école / Internet / infra”'''

* branchée sur le bridge qui donne l’accès au '''reste de l’infra''' + Internet
* ici : <code>SE4</code> (bridge officiel du TP)

Objectif : accès Internet + accès au reste de l’infra (routeurs, services, etc.)

===== Mode “secours” : <code>bridgeStudents</code> =====
Tant que le bridge <code>SE4</code> n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

* <code>bridgeStudents</code>

Ça te donne déjà :

* Internet
* de quoi avancer sur une grosse partie du TP

⚠️ Mais à la fin, pour la note max :

Vous devez faire le '''brassage / branchement réel''' des commutateurs en '''E304 / E306 / E200''', et configurer la partie Cisco reliée au bridge <code>SE4</code>.

==== 3) Exemple de section réseau dans le <code>.cfg</code> ====
<syntaxhighlight lang="bash">
# Networking
dhcp = 'dhcp'
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>

===== Comment lire ça ? =====
* <code>vif = [...]</code> : liste des cartes réseau virtuelles
* chaque ligne décrit '''une VIF'''
* <code>mac=...</code> : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
* <code>bridge=...</code> : le bridge Xen/Linux sur lequel tu connectes cette VIF

c’est littéralement “sur quel switch virtuel tu branches le câble”

==== 4) Lien avec <code>xen-create-image</code> (ce que tu retrouves dans le cfg) ====
<syntaxhighlight lang="antlr-cpp">
xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
--dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

</syntaxhighlight>Elle fait plusieurs trucs automatiquement :

* crée le disque système (<code>disk.img</code>) + swap (<code>swap.img</code>)
* configure le hostname
* met une config réseau DHCP
* et '''ajoute 1 bridge''' par défaut (<code>pont_Gercourt</code>)

Mais elle ne connaît pas forcément ta future archi avec <code>/home</code> et <code>/var</code> séparés, ni le second bridge (SE4).

Donc tu '''complètes à la main''' dans le <code>.cfg</code>.

==== 5) Ajouter tes volumes logiques <code>/home</code> et <code>/var</code> dans <code>disk = [...]</code> ====
Dans ton fichier config, tu as une section :<syntaxhighlight lang="bash">
disk = [

'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',

'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',

]
</syntaxhighlight>

'''Comprendre <code>file:</code> vs <code>phy:</code>'''

* <code>file:</code> → disque = '''fichier image''' (un <code>.img</code>)
* <code>phy:</code> → disque = '''vrai block device''' côté hôte (ex : volume LVM dans <code>/dev/virtual/...</code>)

Donc pour brancher tes volumes logiques LVM, tu ajoutes :<syntaxhighlight lang="ansys">
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
</syntaxhighlight>Ce qui donne :<syntaxhighlight lang="antlr-c#">
disk = [
'file:/usr/local/xen/domains/SE4.Merteuil/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Merteuil/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',
]
</syntaxhighlight>

==== 6) C’est quoi <code>xvda3</code> / <code>xvdb1</code> exactement ? ====
C’est juste '''le nom du disque vu par la VM'''.

* <code>xvda</code> = “disque A virtuel”
* <code>xvdb</code> = “disque B virtuel”
* <code>xvda3</code> = “partition 3 du disque A” (façon de parler : c’est l’identifiant donné à Xen)

'''Ce qui compte vraiment'''

✅ Que chaque “source” (file/phy) ait un '''identifiant unique''' côté VM.

Le choix <code>xvda3</code> vs <code>xvdb1</code> n’a rien de magique : c’est juste une convention.

'''Petit conseil pratique (propre et simple)'''

* garde tout sur <code>xvda1</code>, <code>xvda2</code>, <code>xvda3</code>, <code>xvda4</code>… (ça évite de te perdre)
* ou alors fais :
** <code>xvda...</code> pour OS + swap
** <code>xvdb</code> pour home
** <code>xvdc</code> pour var (plus lisible quand tu en as beaucoup)

Les deux se font. L’important, c’est d’être '''cohérent'''.

==== 7) Le <code>w</code> à la fin : super important ====
À la fin de chaque ligne de disque, tu as :

* <code>w</code> = '''write''' (lecture + écriture)
* <code>r</code> = read-only (lecture seule)

Donc si tu oublies le <code>w</code> sur un volume <code>/home</code> ou <code>/var</code>, tu vas vite te retrouver avec :

* des erreurs d’écriture
* ou un système qui refuse de monter le FS correctement Pour des volumes de données, c’est '''toujours <code>w</code>'''.

=== Montage des partitions et fichier "fstab" ===

==== Très important : ça se fait dans la VM, pas sur capbreton ====
Les commandes <code>mkfs</code>, <code>mount</code>, <code>mv</code> sont à exécuter '''dans la VM''' (le DomU).

* Sur '''capbreton (Dom0 / hôte Xen)''', '''ne touche jamais à <code>/var</code>''' : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces <code>/var</code> sur le host, tu peux casser l’infra du TP (et potentiellement les autres VMs / services).
* Sur capbreton, ton job c’est '''créer les volumes LVM''' et les '''attacher''' à la VM dans le <code>.cfg</code>. Point.

==== Rappel : c’est quoi <code>/var</code> exactement ? ====
<code>/var</code> = “variable data”, donc tout ce qui '''change souvent''' et peut '''grossir vite'''.

Typiquement :

* <code>/var/log</code> : logs (ça peut exploser si un service spam)
* <code>/var/lib</code> : données applicatives (ex: bases de données, états de services)
* <code>/var/cache</code> : caches (apt, etc.)
* <code>/var/tmp</code> : fichiers temporaires “longue durée”
* <code>/var/spool</code> : files d’attente (mail, cron, impressions…)

Pourquoi on le met sur un volume dédié : si <code>/var</code> se remplit, tu évites de remplir <code>/</code> et de rendre la VM inutilisable.<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

=== Explication rapide des commandes ===

* '''<code>mkfs -t ext4 /dev/xvdb1</code>''' : ''formatage'' → crée un système de fichiers ext4 sur le disque. ⚠️ Ça '''efface''' ce qu’il y avait dessus.
* '''<code>mount <device> <dossier></code>''' : “branche” le système de fichiers sur un dossier.
* '''<code>umount <dossier></code>''' : “débranche”.
* '''<code>mount -a</code>''' : monte tout ce qui est dans <code>/etc/fstab</code>
* '''<code>mv</code>''' : déplace. Sur <code>/var</code>, c’est risqué parce que des fichiers peuvent être utilisés en live.

'''DÉMARRAGE AUTOMATIQUE DU MONTAGE'''
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|alt=Fichier fstab|centré|cadre|Fichier fstab]]
|}

== CONFIGURATION RÉSEAU DE NOS VM ==

=== Rappel du schéma et du rôle des machines ===
Dans l’infra, on a deux “mondes” réseau en parallèle :

* '''Un réseau IPv4 privé''' (non routable sur Internet) : utilisé pour l’interconnexion interne et la sortie Internet via NAT.
* '''Un réseau IPv6 public''' : utilisé pour rendre les VM accessibles directement depuis l’extérieur (et accéder à Internet en IPv6 sans NAT).

==== VM de service (serveurs) ====
* IPv4 '''privé''' : pour sortir sur Internet via le mandataire (NAT/Masquerade).
* IPv6 '''public''' : pour être joignable directement (pas de NAT).

==== VM mandataire (gateway) ====
* Reliée au '''réseau privé IPv4''' : côté interne
* Reliée au '''réseau public''' : côté infra école + Internet.
* Fait l’interconnexion (routage + NAT + redirections de ports si besoin).

=== Configuration réseau de la VM de service ===

==== Ton <code>/etc/network/interfaces</code> (service) ====
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.2/27 #192.168.3.3 pour notre deuxième service nommée Valmont
gateway 192.168.3.1 #adresse IPv4 de notre mandataire

auto eth1
iface eth1 inet6 auto #attention de ne pas mettre en dhcp
</syntaxhighlight>

==== Explication simple ====

* '''<code>eth0</code> (IPv4 privé)'''
** IP privée <code>192.168.3.2/27</code>
** passerelle <code>192.168.3.1</code> = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
* '''<code>eth1</code> (IPv6)'''
** <code>inet6 auto</code> = la VM récupère automatiquement une IPv6 (SLAAC/RA) + souvent une route par défaut IPv6 → La VM est accessible directement en IPv6, sans passer par du NAT.

=== Configuration réseau de la VM mandataire ===
Ton <code>/etc/network/interfaces</code> (mandataire)
<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.3.1/24

auto eth1
iface eth1 inet6 auto

iface eth1 inet static
address 193.48.57.165/27
gateway 193.48.57.162
</syntaxhighlight>

* eth0 (IPv4 privé) : 192.168.3.1 = gateway des services (réseau interne)

* eth1 (public) :
** IPv4 public 193.48.57.165/27
** gateway public 193.48.57.162 (VRRP)
* IPv6 en auto (pour avoir IPv6 public côté mandataire aussi)

=== Du <code>.cfg</code> Xen → aux interfaces <code>ethX</code> dans la VM ===

==== Côté Xen (Dom0) : tu déclares des VIF ====
Dans le fichier de config Xen de ta VM, tu as un truc du style :<syntaxhighlight lang="bash">
vif = [
'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
'mac=00:16:3E:47:BB:E7,bridge=SE4'
]
</syntaxhighlight>'''Interprétation :'''

* Tu crées '''2 cartes réseau virtuelles''' (2 VIF) pour la VM.
* Chaque VIF :
** a une '''MAC''' (pour l’identifier)
** est branchée sur un '''bridge''' Xen/Linux (un switch virtuel)

Donc en mode “câblage” :

* VIF #1 = un câble branché sur le switch virtuel <code>pont_Gercourt</code>
* VIF #2 = un câble branché sur le switch virtuel <code>SE4</code> (ou <code>bridgeStudents</code>)

==== Dans la VM (DomU) : ces VIF apparaissent comme <code>eth0</code>, <code>eth1</code>, … ====
Quand la VM boot :

* Xen “présente” ces VIF à l’OS invité
* l’OS les voit comme des interfaces réseau classiques

Typiquement :

* '''la 1ère VIF''' devient <code>eth0</code>
* '''la 2ème VIF''' devient <code>eth1</code>

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser <code>eth0</code>/<code>eth1</code> ou des noms type <code>ens3</code>), mais '''dans ton TP tu es bien sur <code>eth0</code>/<code>eth1</code>''', donc on garde ça.<syntaxhighlight lang="bash">
ip link
ip addr
</syntaxhighlight>Tu verras <code>eth0</code>, <code>eth1</code> et leurs MAC. Tu peux matcher avec celles du <code>.cfg</code>.

==== Le bridge Xen = “le switch” auquel la carte est connectée ====

* <code>bridge=pont_Gercourt</code> : réseau '''privé IPv4''' entre tes VMs (commutateur virtuel interne)
* <code>bridge=SE4</code> (ou <code>bridgeStudents</code>) : réseau '''public / infra école / Internet'''

Donc, si ta VM a :

* <code>eth0</code> reliée à <code>pont_Gercourt</code> → elle est sur le réseau privé
* <code>eth1</code> reliée à <code>SE4</code> → elle est sur le réseau public

C’est exactement pour ça que dans <code>/etc/network/interfaces</code> tu mets :

* IPv4 privé sur <code>eth0</code>
* IPv6 (direct) sur <code>eth1</code>

=== Pourquoi les services sortent en IPv4 via “Masquerade” (NAT) ===

==== Le problème IPv4 ====
IPv4 = adresses sur 32 bits → ~4,3 milliards d’adresses max, et une grosse partie est réservée.

Résultat : on ne peut pas donner une IPv4 publique à chaque machine du monde.

==== La solution historique : NAT / Masquerade ====
On met les machines en '''IP privées''' (ex : <code>192.168.x.x</code>), et une machine (le mandataire) “traduit” :

* en interne : <code>192.168.3.2</code> (service)
* en externe : <code>193.48.57.165</code> (mandataire)

Donc vu d’Internet, '''tout sort avec l’IP publique du mandataire'''.

C’est exactement ce que fait <code>MASQUERADE</code> dans iptables : une forme de NAT automatique adaptée quand l’IP externe peut changer.

=== Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) ===
IPv6 = 128 bits → un nombre d’adresses gigantesque (bien au-delà du “trillions” d'adresses).

Du coup, on peut attribuer à chaque VM une IPv6 unique, routable.

Conséquence :

* pas besoin de NAT
* la VM est joignable directement (avec firewall bien sûr)

Dans ton schéma, c’est l’arc “Accès direct IPv6” : les services sont accessibles depuis l’infra publique en IPv6 sans passer par la traduction du mandataire.

=== VRRP : c’est quoi cette gateway <code>193.48.57.162</code> ? ===
<code>193.48.57.162</code> = '''IP virtuelle VRRP''' portée par '''deux routeurs''' (redondance).

* routeur A : <code>...163</code>
* routeur B : <code>...164</code>
* IP VRRP : <code>...162</code> (celle que tu mets en gateway)

Avantage :

* si un routeur tombe, l’autre reprend l’IP VRRP
* tes machines ne changent pas leur config, ça continue de router

Si tu mets directement <code>.163</code> ou <code>.164</code> en gateway :

* tu forces l’utilisation d’un routeur précis
* tu perds la redondance (si celui-là tombe, plus de sortie)

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-24T14:19:41Z

Pcasimir : /* Pourquoi en IPv6 on fait de l’accès direct (pas de NAT) */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T14:18:28Z

Pcasimir : /* Configuration réseau de la VM mandataire */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T14:15:22Z

Pcasimir : /* Ton /etc/network/interfaces (service) */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T14:10:10Z

Pcasimir : /* Ton /etc/network/interfaces (service) */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T14:08:44Z

Pcasimir : /* Cassage de clé WIFI */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T13:05:05Z

Pcasimir : /* Cassage de clé WIFI */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T11:37:42Z

Pcasimir : /* Différence avec une machine physique */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T11:37:16Z

Pcasimir : /* Comment lire ça ? */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T11:36:23Z

Pcasimir : /* Comment lire ça ? */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T11:34:37Z

Pcasimir : /* Fichier de configuration Xen */

Atelier SysRes SE4 2025/2026 E1

2026-02-24T11:08:50Z

Pcasimir : /* Fichier de configuration Xen */

Atelier SysRes SE4 2025/2026 E1

2026-02-22T22:15:56Z

Pcasimir : /* Volumes Logiques */

Atelier SysRes SE4 2025/2026 E1

2026-02-22T22:07:35Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

Atelier SysRes SE4 2025/2026 E1

2026-02-22T21:25:48Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

Atelier SysRes SE4 2025/2026 E1

2026-02-22T21:24:34Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

Atelier SysRes SE4 2025/2026 E1

2026-02-22T21:22:04Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

Atelier SysRes SE4 2025/2026 E1

2026-02-22T21:12:18Z

Pcasimir : /* Cassage de clé WIFI */

Atelier SysRes SE4 2025/2026 E1

2026-02-22T20:59:01Z

Pcasimir : /* WPA2-PSK */

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>

<syntaxhighlight lang="bash">
pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD
</syntaxhighlight>

Atelier SysRes SE4 2025/2026 E1

2026-02-22T20:58:27Z

Pcasimir : /* WEP */

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<syntaxhighlight lang="bash">
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</syntaxhighlight>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<syntaxhighlight lang="bash">
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</syntaxhighlight>

=== WPA2-PSK ===
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD

Atelier SysRes SE4 2025/2026 E1

2026-02-10T17:50:41Z

Pcasimir : /* WEP */

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

<code>sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4</code>

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

<code>
CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0 10771 48468 31 4 54e. WEP WEP cracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73 0 -36e 621 58224
</code>

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

<code>sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s</code>

Résultat :

<code>
KB depth byte(vote)

 0 1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

 1 0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

 2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

 3 4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

 4 1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

 Decrypted correctly: 100%
</code>

=== WPA2-PSK ===
pcasimir@zabeth13:~$ sudo airodump-ng wlan1 --write crackage_pcasimir/airodumpWPA --bssid 44:AD:D9:5F:87:00 -c13

CH 13 ][ Elapsed: 1 hour 44 mins ][ 2026-02-10 18:41 ][ fixed channel wlan1: 4

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -58 0 28293 508 0 13 54e. WPA2 CCMP PSK kracotte01

BSSID STATION PWR Rate Lost Frames Notes Probes

pcasimir@zabeth13:~$ sudo aircrack-ng -a2 -b 44:AD:D9:5F:87:00 -w crackage_pcasimir/dico.txt crackage_pcasimir/airodumpWPA-01.cap

Aircrack-ng 1.7

 [00:55:43] 66515032/100000000 keys tested (19870.44 k/s)

 Time left: 28 minutes, 5 seconds 66.52%

KEY FOUND! [ 66689666 ]

 Master Key : 3C A8 6A 6B 80 C3 36 12 EC D6 36 89 9F E3 F6 BC

D6 B2 24 8A 49 B4 9C 2A A3 6F 3E A0 96 15 8B F5

 Transient Key : A0 53 57 7D 4B 67 FB 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 EAPOL HMAC : 52 DE 19 6D B0 E3 3B 2C 1A DA D3 F2 66 39 F2 DD

Atelier SysRes SE4 2025/2026 E1

2026-02-10T15:18:27Z

Pcasimir : /* Cassage de clé WIFI */

Atelier SysRes SE4 2025/2026 E1

2026-02-10T15:18:07Z

Pcasimir : /* Cassage de clé WIFI */

Atelier SysRes SE4 2025/2026 E1

2026-02-10T15:17:08Z

Pcasimir : /* WEP */

== Cassage de clé WIFI ==

=== WEP ===
Sur un 1 terminal :

sudo airodump-ng wlan1 --write crackage_pcasimir/pcasimir --bssid 04:DA:D2:9C:50:50 -c4

Il faut laisser tourner le programme pendant un moment pour capturer un maximum d'IVs (environ 50*10³)

Ce que l'on voit :

CH 4 ][ Elapsed: 40 mins ][ 2026-02-10 16:07 ][ paused output

BSSID    PWR RXQ Beacons    #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:50 -64 0    10771    48468 31 4 54e. WEP WEP cracotte01

BSSID    STATION    PWR    Rate    Lost Frames Notes Probes

04:DA:D2:9C:50:50 40:A5:EF:01:21:80 -73    0 -36e 621    58224

sur 2ème terminal :

Une fois qu'on a 50*10³ IV on fait :

sudo aircrack-ng -a1 -b 04:DA:D2:9C:50:50 crackage_pcasimir/pcasimir-01.cap -s

Résultat :

KB    depth byte(vote)

   0    1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

   1    0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

   2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

   3    4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

   4    1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

   Decrypted correctly: 100%

Atelier SysRes SE4 2025/2026 E1

2026-02-10T15:13:56Z

Pcasimir : Clé WEP trouvé

== Cassage de clé WIFI ==

=== WEP ===
[00:00:00] Tested 785 keys (got 45236 IVs)

KB    depth byte(vote)

   0    1/ 2 B5(55552) 84(53504) 2B(52992) 2F(52480) A0(52480) BA(52224)

   1    0/ 5 49(66304) E8(55552) 20(55296) 65(55296) 73(55296) 5F(53760)

   2 41/ 2 E1(48640) 0E(48384) 3D(48384) 63(48384) 6C(48384) 9C(48384)

   3    4/ 3 B3(53248) 7B(52992) 95(52992) 31(52736) 12(52224) FF(52224)

   4    1/ 2 21(55552) 17(52480) 26(52224) B5(52224) 16(51968) C0(51712)

KEY FOUND! [ FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE ]

   Decrypted correctly: 100%

Accueil

2026-02-02T08:28:39Z

Pcasimir : /* Objet du Wiki */

== Objet du Wiki ==

=== Chiffrement et cassage Wi-Fi ===
Clé WEP de cracotte01 : FF:FF:FF:FF:FA:BC:02:CB:AE:EE:EE:EE:EE

Atelier SysRes SE4 2024/2025 E14

2026-01-20T15:59:30Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

'''Projet AARV LECOMTE et CASIMIRI'''

== INTRODUCTION ==
Dans le cadre de ce projet de virtualisation, j’ai déployé une infrastructure composée de '''deux machines dédiées aux services''' et d’une '''machine mandataire''', le tout orchestré à l’aide de '''Xen'''.

La machine '''Atreus''' joue un rôle central en assurant '''l’hébergement des services web''' et autres composants applicatifs. La machine '''GOW''' fait office de '''mandataire réseau''' : elle gère la '''connectivité vers l’extérieur''', que ce soit en '''IPv4 ou en IPv6''', et sert aussi de '''reverse proxy''' pour rediriger les requêtes vers les machines de service internes.

La '''deuxième machine de service''' appartient à Monsieur '''Antoine LECOMPTE''' et porte le nom de '''Kratos'''. Elle complète l’architecture et participe à l’ensemble des services distribués au sein de l’infrastructure.

<big>'''✉️ Petit mot pour les prochaines promotions'''</big>

Salut à vous les prochaines promos 👋

Dans ce document, j’ai essayé de vous expliquer au mieux les différentes étapes que j’ai traversées pour monter ce projet. Je me suis appuyé sur ce que j’ai compris moi-même au fil des TP, les cours des profs (qu’il faut vraiment relire, ils sont précieux), des ressources trouvées sur Internet, et je ne vais pas vous mentir… parfois un petit coup de main de certains LLM comme ChatGPT 👀 m’a bien aidé quand je bloquais.

Ce n’est pas un tutoriel parfait, mais plutôt un guide pour vous accompagner avec des explications techniques assez simples à comprendre (que je pense avoir compris surtout), même si vous n’avez encore jamais touché au réseau, à l’infra ou à un serveur web. L’objectif, c’est que vous puissiez prendre confiance, comprendre les bases, et réussir à faire tourner votre projet sans paniquer.

Je vous souhaite vraiment bon courage pour ce projet. C’est l’un des meilleurs moyens d’apprendre concrètement et de progresser à fond. N’hésitez pas à poser des questions à vos profs, ils sont là pour vous aider. Prenez le temps de relire vos cours tranquillement, et surtout, n’ayez pas peur de tester, de faire des erreurs, de casser et de recommencer (certains profs demande à ce qu'on casse les machines pour montrer qu'on cherche) : c’est comme ça qu’on apprend.

Si vous avez l'occasion de les consulter, je vous conseille vivement d'aller regarder les wikis de Madame EL BACHIRI, Monsieur TOURON et Monsieur DETREZ. Ils ont certaines informations en plus que moi sur tout ce qui va être configurations CISCO, OSPF et tout ce qui touche au physique (câbles, commutateurs).

En espérant que vous allez plus loin que nous sur ce projet ![[Fichier:Df -h.png|vignette]]

== CRÉATION MACHINES VIRTUELLES ==

Tout d'abord, nous devons configurer nos MV de services. Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Atreus --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
root@capbreton:~# xen-create-image --hostname=SE4.Kratos --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Atreus</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

Il faudra aussi créer des volumes logiques dédiés à des /var et /home pour chacune de nos VM.

Sur capbreton, les commandes sont :

<code>lvcreate -L10G -nSE4.[NomdeVM].home virtual

lvcreate -L10G -nSE4.[NomdeVM].var virtual</code>

celà va créer des volumes logiques dédiés aux paths /var et /home pour vos VM dans un dossier /dev/virtual sur capbreton.

A AUCUN moment vous devez écrire une ligne commençant par mkfs sur capbreton, vous risquez de tuer capbreton si vous le faites.

Pour initialiser les machines, nous devons exécuter ces commandes:

<syntaxhighlight lang="bash">
xen create /etc/xen/SE4.Atreus.cfg
xen create /etc/xen/SE4.Kratos.cfg
</syntaxhighlight>

Une fois les MV créées et en ligne, nous devons exécuter ces commandes pour les contrôler:
<syntaxhighlight lang="bash">
xen console SE4.Atreus
xen console SE4.Kratos
</syntaxhighlight>

Une fois le login "root" et le mdp (top secret) rentrés dans la console, nous sommes sur la VM et pouvons la contrôler comme un ordinateur avec un OS classique.
<syntaxhighlight lang="bash">
root@Atreus:~#
</syntaxhighlight>

== PARTIONING DES MV ==
Nous avons modifié les fichiers <code>/etc/xen/[Kratos][Atreus].cfg</code> pour attacher les partitions LVM aux machines :<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w',
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w',
]

</syntaxhighlight>Le paramètre <code>disk</code> définit les disques virtuels attachés à la machine virtuelle (domaine Xen).

Chaque élément du tableau suit la syntaxe :<syntaxhighlight lang="bash">
<type>:<source>,<cible>,<mode>
</syntaxhighlight>

* '''type :''' indique si le disque provient :
** d'un fichier (<code>file:</code>)
** d'un périphérique physique réel (<code>phy:</code>).
* '''source :''' chemin complet vers l'image disque ou vers le périphérique physique sur la machine hôte.
* '''cible :''' nom du périphérique vu par la machine virtuelle (exemple : <code>xvda</code>, <code>xvdb</code>, etc.).

* '''mode :''' type d'accès au disque (<code>r</code> en lecture seule, <code>w</code> en lecture-écriture).

==== DISQUE VIRTUEL PRINCIPAL : ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w'
</syntaxhighlight>

* '''Type''' : <code>file</code> (stockage basé sur un fichier-image disque).
* '''Source''' : <code>/usr/local/xen/domains/SE4.Atreus/disk.img</code> (fichier contenant le disque virtuel).
* '''Cible''' : <code>xvda2</code> (deuxième partition du disque virtuel <code>xvda</code> visible depuis la MV).
* '''Mode''' : <code>w</code> (lecture-écriture).

Ce disque correspond à la racine (<code>/</code>) du système de fichiers Linux de la MV.

==== DISQUE VIRTUEL SWAP ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w'

</syntaxhighlight>

* '''Type :''' <code>file</code> → Image disque stockée dans un fichier.
* '''Source :''' <code>/usr/local/xen/domains/SE4.Atreus/swap.img</code> → Chemin de l'image disque swap.
* '''Cible :''' <code>xvda1</code> → Première partition du disque virtuel <code>xvda</code>.

==== DISQUE PHYSIQUE POUR /home ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Un périphérique physique (généralement une partition réelle ou un volume logique LVM).
* '''Source :''' <code>/dev/virtual/SE4.Atreus.home</code> → Partition ou volume logique physique sur l'hôte. L'hôte étant le disque dur de capbreton.
* '''Cible :''' <code>xvda3</code> → Troisième partition du disque virtuel <code>xvda</code>.

Cette partition dédiée permet d’isoler le répertoire <code>/home</code>, facilitant ainsi la gestion des données utilisateur séparément du système.

==== DISQUE PHYSIQUE POUR /var ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Périphérique physique.
* '''Source :''' <code>/dev/virtual/SE4.Atreus.var</code> → Partition physique ou volume logique dédié sur l'hôte.
* '''Cible :''' <code>xvdb1</code> → Première partition du second disque virtuel (<code>xvdb</code>).

Cette partition est dédiée au répertoire <code>/var</code>, où sont stockés les journaux (logs), les bases de données, les fichiers temporaires, etc. Cette séparation permet une meilleure gestion des données systèmes dynamiques.

Pour le fichier /var<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
</syntaxhighlight>Pour le fichier /home<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

==== DÉMARRAGE AUTOMATIQUE DU MONTAGE ====
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|Fichier_fstab|centré]]
|}

== CONFIGURATION RÉSEAU ==

Chaque machine dispose d'une adresse IPv4 fixe sur un réseau privé, ainsi que d'une adresse IPv6 configurée automatiquement.

Nous modifions la configuration réseau dans <code>/etc/network/interfaces</code> de la machine mandataire. Ensuite, nous ajustons le fichier de configuration de la machine virtuelle afin qu'elle possède deux interfaces : la première permet de communiquer avec le routeur mis en place par nos collègues, tandis que la seconde est connectée au pont réseau que nous avons créé pour l’intercommunication entre nos trois machines.

=== MACHINE MANDATAIRE ===
<syntaxhighlight lang="bash">
name = 'SE4.GOW'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:E7:C5:1A,bridge=bifrost',
'mac=00:16:3E:E7:C5:1B,bridge=SE4' ]

</syntaxhighlight>Le pont nommé '''"bifrost"''', défini dans le fichier de configuration de notre machine virtuelle mandataire, sert à '''relier virtuellement les trois machines''' entre elles.

Pour que des machines puissent communiquer, elles doivent être sur le '''même réseau'''. Ici, c’est un '''VIF (Virtual Interface)''' qui joue ce rôle : c’est une sorte de '''commutateur virtuel''' (ou switch virtuel).

Un '''commutateur''', c’est ce que vous imaginez peut-être comme une grosse boîte avec plein de câbles et de lumières clignotantes, qu’on trouve dans les salles serveurs.

Dans notre cas, tout ça est '''simulé dans la machine virtuelle''', donc pas de câbles physiques : la communication se fait via la '''carte réseau virtuelle''' attribuée à chaque machine.

Après avoir redémarré la machine, l’interface réseau est visible dans le fichier <code>/etc/network/interfaces</code>. On peut modifier ce fichier pour attribuer une adresse IP fixe à la machine GOW.<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.3.1/24
# post-up ethtool -K eth0 tx off

iface eth0 inet6 auto

auto eth1
iface eth1 inet static
address 193.48.57.172/27
gateway 193.48.57.161
</syntaxhighlight>

=== MACHINE DE SERVICES ===
/etc/network/interfaces de la machine SE4.Atreus qui permet de lié les Interfaces de la MV avec ses VIF pour communiquer en IPv6 avec Internet et IPv4 avec la machine mandataire <syntaxhighlight lang="bash">
# The loopback network interface
auto lo
iface lo inet loopback

auto eth0

iface eth0 inet6 auto

iface eth0 inet static
address 192.168.3.2/24
gateway 192.168.3.1

auto eth1
iface eth1 inet6 auto

</syntaxhighlight>On configure la machine mandataire comme une passerelle (gateway) en IPv4. En IPv6, l’adresse est attribuée automatiquement grâce au bridge SE4.

Une fois que chaque machine peut être pingée par les autres et qu’elles arrivent à envoyer des requêtes vers Internet, on peut passer à l’étape suivante.
{| class="wikitable"
|+
![[Fichier:Interfacekratos.png|alt=Interfacekratos|Interfacekratos|centré|vignette|470x470px]]
! rowspan="2" |[[Fichier:IpaAtreusIp6Ip4.png|vignette|546x546px|ip a de la machine SE4.Atreus|centré]]
|-
|[[Fichier:PingEntre2VM.png|alt=PingEntre2VM|PingEntre2VM|centré|vignette|986x986px]]
|}

==== SSH ====
On active le SSH avec la ligne <code>PermitRootLogin yes</code> dans le fichier <code>/etc/ssh/sshd_config</code>sur les 3 machines, on peut accéder à la mandataire avec son adresse IPv4 routée, pour les machines de service on utilise l'adresse en IPv6

===== 🛡️ Sécurisation SSH avec Fail2Ban =====
📄 '''Fichier :''' <code>/etc/fail2ban/jail.local</code>

Ce fichier contient les règles locales de '''Fail2Ban''', un outil qui surveille les logs système et '''bannit temporairement les adresses IP''' en cas de comportement suspect (comme des tentatives de connexion SSH répétées avec un mauvais mot de passe).<syntaxhighlight lang="vim">
[sshd]
enable = true
port = ssh
filter = sshd
maxretry = 3
findtime = 300
bantime = 600
</syntaxhighlight>
{| class="wikitable"
!Paramètre
!Explication
|-
|<code>enable = true</code>
|Active la surveillance de SSH.
|-
|<code>port = ssh</code>
|Surveille le port SSH.
|-
|<code>filter = sshd</code>
|Utilise le '''filtre prédéfini''' <code>sshd.conf</code>, qui détecte les échecs de connexion dans les logs.
|-
|<code>maxretry = 3</code>
|'''3 tentatives''' ratées autorisées avant bannissement.
|-
|<code>findtime = 300</code>
|La fenêtre de détection : '''5 minutes''' pour accumuler ces 3 tentatives.
|-
|<code>bantime = 600</code>
|Durée de bannissement : '''10 minutes''' (600 secondes).
|}

=== CONFIGURATION DNS ===
Rappel : Qu’est-ce qu’un serveur DNS ?

Vu en cours avec Monsieur redon et Monsieur Vantroys, DNS veut dire '''Domain Name System'''. C’est un '''service''' qui fait la conversion entre un '''nom de domaine''' (comme <code>muspellheim2.online</code>) et une '''adresse IP''' (comme <code>193.48.57.172</code>), que les machines utilisent pour communiquer. Ce sont les pages jaunes des serveurs et IP d'Internet. On ne connait pas l'adresse IP de tous les sites. On ne connait que les noms. Quand on écrit netflix.com sur Internet, on interroge les serveurs DNS pour qu"il puisse nous rediriger vers l'adresse IP associé au nom "netflix.com".

==== 🌍 Fichier de zone DNS : <code>muspellheim2.online</code> ====
📄 '''Fichier :''' <code>/etc/bind/zones/muspellheim2.online/muspellheim2.zone</code>

Ce fichier définit tous les enregistrements DNS pour le domaine <code>muspellheim2.online</code>.

Il est utilisé par le serveur BIND '''maître''' (primary) pour répondre aux requêtes DNS.

===== 🧾 En-tête : SOA (Start Of Authority) =====
<syntaxhighlight lang="vim">
@ IN SOA ns.muspellheim2.online. admin.muspellheim2.online. (
3609 ; Numéro de version
21600 ; Rafraîchissement (6h)
3600 ; Re-tentative (1h)
2592000 ; Expiration (30j)
86400 ) ; Cache négatif (24h)
</syntaxhighlight>🔹 <code>@</code> : représente le domaine racine (<code>muspellheim2.online.</code> ici)

🔹 <code>SOA</code> : Spécifie '''l’autorité principale''' de la zone. Ici :

* Serveur DNS maître : <code>ns.muspellheim2.online.</code>
* Contact admin : <code>admin@muspellheim2.online</code> (le point remplace le <code>@</code>)
A chaque modification de ce fichier, il faut incrémenter le numéro de version de +1.

===== 📡 Serveurs DNS (NS) =====
<syntaxhighlight lang="vim">
@ IN NS ns.muspellheim2.online.
@ IN NS ns.jotunheim2.tech.
</syntaxhighlight>🔹 Ces lignes déclarent les serveurs DNS autoritaires pour cette zone :

- ns.muspellheim2.online. (le maître)

- ns.jotunheim2.tech. (un secondaire)

===== 🧭 Enregistrements de type A / AAAA =====
<syntaxhighlight lang="vim">
ns IN A 193.48.57.172
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
@ IN A 193.48.57.172
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
</syntaxhighlight>🔹 '''A''' : Adresse IPv4

🔹 '''AAAA''' : Adresse IPv6

Ces enregistrements associent :

* <code>ns.muspellheim2.online</code> à ses adresses IP (serveur DNS)
* <code>muspellheim2.online</code> lui-même à la même machine (le site est hébergé dessus)

===== 🔗 Alias (CNAME) =====
<syntaxhighlight lang="vim">
www IN CNAME muspellheim2.online.
</syntaxhighlight>🔹 Les requêtes pour <code>www.muspellheim2.online</code> seront redirigées vers <code>muspellheim2.online</code>.

Cela évite de dupliquer les enregistrements A/AAAA pour <code>www</code>.

===== 🔐 DNS Validation via Digicert =====
<syntaxhighlight lang="vim">
_gay4mlana6awxk71vd9gjuzdkzfism2.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
_gay4mlana6awxk71vd9gjuzdkzfism2.www.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
</syntaxhighlight>🔹 Ces lignes servent à '''valider le domaine''' auprès de l’autorité de certification (Digicert) pour obtenir un certificat SSL.

🔹 <code>dcv.digicert.com.</code> est le serveur que Digicert utilise pour vérifier la possession du domaine (via un CNAME dynamique généré).

On peut ensuite vérifier la syntaxe de notre '''fichier de zone DNS''' avec l’outil <code>named-checkzone</code>.

Cet outil nous aide à repérer les erreurs dans l’écriture du fichier, un peu comme '''Microsoft Word souligne les fautes de grammaire ou de syntaxe''' dans un texte.

Par exemple :<syntaxhighlight lang="ruby">
root@Atreus:~# named-checkzone muspellheim2.online /etc/bind/zones/muspellheim2.online/muspellheim2.zone
zone muspellheim2.online/IN: loaded serial 3609
OK
</syntaxhighlight>Ici, le message '''"OK"''' signifie que le fichier est bien écrit et ne contient pas d’erreurs de syntaxe.

Juste à noter : <code>named-checkzone</code> vérifie uniquement la syntaxe et la structure logique du fichier (comme la présence d’un SOA, la validité des enregistrements, etc.), '''mais pas si les adresses IP ou noms existent réellement'''.

Une fois que tout est correctement configuré, '''n’oubliez pas de redémarrer les services <code>named</code> et <code>bind</code>'''.

Cela permet à ces services de '''prendre en compte les nouvelles modifications''' que vous avez apportées dans les fichiers de configuration.

Il faut aussi '''attribuer les bons droits d'accès aux fichiers''', pour que <code>bind</code> puisse les lire correctement. Sinon, il risque de ne pas fonctionner comme prévu.<syntaxhighlight lang="ruby">
chown bind:bind /etc/bind/zones/muspellheim2.online/muspellheim2.zone
chmod 644 /etc/bind/zones/muspellheim2.online/muspellheim2.zone

chown bind:bind /etc/bind/named.conf.local
chmod 644 /etc/bind/named.conf.local
</syntaxhighlight>

* <code>chown</code> permet de '''donner la propriété des fichiers à l’utilisateur et au groupe <code>bind</code>'''.

* <code>chmod 644</code> donne les '''droits de lecture au service <code>bind</code>''', tout en empêchant d'autres utilisateurs non privilégiés de les modifier.

===== Vérification avec l'outil "dig" =====
On peut '''vérifier que notre serveur DNS fonctionne correctement''' en utilisant la commande <code>dig</code>.

C’est un outil qui envoie une requête DNS pour demander l’adresse IP d’un nom de domaine, et affiche la réponse complète reçue du serveur.

Par exemple, ici on interroge notre propre serveur DNS local (<code>@localhost</code>) pour vérifier s’il connaît le domaine <code>muspellheim2.online</code> :<syntaxhighlight lang="vim">
root@Atreus:~# dig @localhost muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="vim">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight>Cela signifie que la requête s’est bien déroulée, et qu’il n’y a '''pas d’erreur''' dans le fichier de zone.<syntaxhighlight lang="vim">
;; ANSWER SECTION:
muspellheim2.online. 200 IN A 193.48.57.172
</syntaxhighlight>
Le serveur DNS a bien répondu avec l’adresse IP '''193.48.57.172''', donc '''la zone est bien configurée et active'''.Ce test permet de s'assurer que '''le nom de domaine est bien reconnu et renvoie vers la bonne adresse IP'''.

On peut aussi tester depuis '''une autre machine virtuelle''', pour voir si '''le domaine est connu à l'extérieur''', par exemple par '''le DNS public de Google (<code>8.8.8.8</code>)'''.

Pour cela, on utilise <code>dig</code> en spécifiant l’IP du serveur DNS qu’on veut interroger :<syntaxhighlight lang="ruby">
root@GOW:~# dig @8.8.8.8 muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ANSWER SECTION:
muspellheim2.online. 189 IN A 193.48.57.172
</syntaxhighlight>Google a répondu avec l’adresse IP '''193.48.57.172''', ce qui prouve que '''notre domaine est maintenant reconnu depuis l’extérieur'''.
🧠 '''Petit point d’attention''' : Si tu n’as pas volontairement '''enregistré le domaine <code>muspellheim2.online</code> sur Internet''' (via un registrar, ici c'est Gandi), alors :

* soit '''ton environnement de test est spécial''' (ex : en école avec une infra réseau propre et un DNS intermédiaire qui communique avec Google),
* soit '''le domaine a réellement été enregistré publiquement''', auquel cas tu partages un vrai domaine avec d'autres (et ça peut poser des conflits si tu voulais juste faire des tests en local).

==== REGISTRAR ET PROPAGATION DNS ====
Pour rendre notre '''serveur DNS opérationnel et accessible depuis Internet''', on se rend sur le site du '''registrar''' (dans notre cas : '''Gandi'''), qui est l’organisme auprès duquel on a acheté notre '''nom de domaine'''.

Dans l’onglet '''"Nameserver"''', on ajoute un '''Glue Record'''.

Un Glue Record sert à '''lier notre nom de domaine à nos propres serveurs DNS''', en indiquant leurs adresses IP :

* l’adresse '''IPv4''' de la '''machine mandataire''' (notre DNS principal),
* les adresses '''IPv6''' des '''machines de service''', si on veut un fonctionnement complet en IPv6.

Ensuite, on '''remplace les serveurs de noms (Nameservers) par les nôtres''', c’est-à-dire notre propre serveur DNS.

Cela fait de notre serveur '''le référent officiel pour la gestion des noms de domaine''' associés à <code>muspellheim2.online</code>.

🧠 Pourquoi on fait tout ça ?

Eh bien, comme on l’a vu avec la commande :<syntaxhighlight lang="vim">
dig @8.8.8.8 muspellheim2.online
</syntaxhighlight>Google a pu répondre car '''notre domaine est désormais public''' !

Si on n’avait pas fait cette configuration chez Gandi, personne sur Internet (hors de notre réseau) n’aurait pu le voir.

🌐 Pour faire simple :

En ajoutant un Glue Record et en configurant nos Nameservers, on annonce notre domaine au monde entier.

Cela permet à n’importe quel ordinateur sur Internet de retrouver l’adresse IP de notre serveur — et donc d’afficher notre site ou d’accéder à nos services.
{| class="wikitable"
|+
![[Fichier:NameserverGandi.png|gauche|NameserverGandi Pierre CASIMIRI muspellheim2.online]]
|-
|[[Fichier:GlueRecordGandi.png|gauche|2305x2305px|GlueRecordGandi Pierre CASIMIRI muspellheim2.online]]
|}

==== DIFFUSION DE NOTRE SUPERBE SERVEUR AU MONDE ====

🌍 Une fois le Glue Record ajouté… on attend un peu que le monde entier soit au courant !

Une fois qu’on a :

* ajouté les '''Glue Records''',
* remplacé les '''Nameservers''' dans le registrar (comme Gandi),

eh bien il faut patienter un peu. Pourquoi ? Parce que '''les informations DNS doivent se propager''' à travers le monde. Cette phase peut prendre '''quelques heures à quelques jours''', selon les serveurs.

🛰️ Comment savoir si c’est bien propagé ?

Il existe des sites comme '''DNSChecker.org''' qui permettent de voir si votre nom de domaine est '''bien visible depuis plusieurs endroits de la planète'''.

📌 Exemple : <code>muspellheim2.online</code>

Sur DNSChecker, vous entrez votre domaine et choisissez le type d'enregistrement que vous voulez vérifier, par exemple :
{| class="wikitable"
!Type
!Ce que ça affiche
|-
|<code>A</code>
|Adresse IPv4 liée au domaine
|-
|<code>AAAA</code>
|Adresse IPv6
|-
|<code>NS</code>
|Liste des Nameservers en charge du domaine
|-
|<code>CNAME</code>
|Alias d’un domaine vers un autre
|-
|<code>DNSKEY</code>
|Clés publiques DNSSEC (on y reviendra plus tard)
|}
{| class="wikitable"
|+
![[Fichier:DNSChecker1.png|gauche|768x768px|DNSChecker1]]
![[Fichier:DNSChecker3.png|alt=DNSChecker3|bordure|687x687px]]
! rowspan="2" |[[Fichier:DNSChecker5.png|alt=DNSChecker5|655x655px]]
|-
|[[Fichier:DNSChecker2.png|alt=DNSChecker2|bordure|768x768px]]
|[[Fichier:DNSChecker4.png|alt=DNSChecker4|701x701px]]
|}

* ✅ '''Check vert''' : ça veut dire que ce serveur DNS a bien reçu et reconnu ton info.
* 🟡 '''Check en attente''' : propagation en cours ou serveur lent.
* ❌ '''Check rouge''' : info non encore propagée à ce serveur ou pas propagée car les certificats ne sont pas acceptés par ses serveurs DNS.

==== DNSSEC sur Atreus ====

===== 🧭 Configuration DNS sur le serveur BIND – <code>named.conf.local</code> =====
📄 Fichier : <code>/etc/bind/named.conf.local</code>

Ce fichier contient la déclaration des zones DNS locales pour le serveur BIND.

On y définit ici :

-Une zone primaires (gérées en local)

-Une zone secondaire (copiée depuis un autre serveur)

Et une politique DNSSEC.<syntaxhighlight lang="bash">
cat /etc/bind/named.conf.local
</syntaxhighlight><syntaxhighlight lang="vim">
zone "muspellheim2.online" {

type primary;
file "/etc/bind/zones/muspellheim2.online/muspellheim2.zone";

allow-transfer{2001:660:4401:60a0:216:3eff:fee7:c51b;

2001:660:4401:60a0:216:3eff:fed0:9ab0;}; // filtrage des secondaires

also-notify{2001:660:4401:60a0:216:3eff:fee7:c51b;}; // pour les secondaires vicieux notify yes; // notification des secondaires
key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes; };

zone "jotunheim2.tech"{

type slave;
file "/etc/bind/jotunheim2.tech";
primaries{2001:660:4401:60a0:216:3eff:fed0:9ab0;};

};

dnssec-policy "dnspol" {

keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;

};
</syntaxhighlight>

🔹 '''type primary''' : Ce serveur est '''l'autorité principale''' pour la zone.

🔹 '''file''' : Chemin du fichier de zone contenant tous les enregistrements DNS (<code>A</code>, <code>AAAA</code>, <code>NS</code>, etc.).

🔹 '''allow-transfer''' : Liste des serveurs secondaires '''autorisés à faire un transfert de zone''' (AXFR). Cela sécurise l’accès aux données DNS.

🔹 '''also-notify''' : Force l’envoi de notifications DNS vers certains secondaires, même s’ils ne sont pas configurés comme secondaires officiels.

🔹 '''notify yes''' : Active les notifications automatiques des serveurs secondaires lorsqu’une mise à jour de la zone est faite.

🔹 '''dnssec-policy "dnspol"''' : Active '''DNSSEC''' avec une politique personnalisée.

🔹 '''inline-signing yes''' : Active la '''signature automatique''' de la zone par BIND.

====== Zone secondaire : <code>jotunheim2.tech</code> ======
<syntaxhighlight lang="vim">
zone "jotunheim2.tech" {
type slave;
file "/etc/bind/jotunheim2.tech";
primaries { 2001:660:4401:60a0:216:3eff:fed0:9ab0; };
};
</syntaxhighlight>🔹 '''type slave''' : Ce serveur récupère les données de zone depuis un '''serveur primaire distant'''.

🔹 '''primaries { ... }''' : Adresse du serveur maître à interroger pour obtenir la zone.

🔹 '''file''' : Emplacement local où la zone est stockée après transfert.

====== 🔐 Politique DNSSEC : <code>"dnspol"</code> ======
<syntaxhighlight lang="vim">
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>🔹 '''ksk''' : Key Signing Key (clé qui signe les autres clés DNS).

🔹 '''zsk''' : Zone Signing Key (clé qui signe les enregistrements DNS).

🔹 '''algorithm 13''' : Il s’agit d’'''ECDSA P-256 with SHA-256''' (<nowiki>RFC 6605</nowiki>), algorithme sécurisé et moderne.

🔹 '''nsec3param''' : Indique que '''NSEC3''' est utilisé (permet de sécuriser les réponses "ce nom n'existe pas" sans divulguer d'autres noms).

✅ Les deux clés sont générées dans le répertoire <code>key-directory</code>, ont une durée de vie '''illimitée''', et utilisent '''l’algorithme 13''' (ED25519, rapide et sécurisé).

✅ <code>nsec3param</code> : active la protection contre l’énumération de noms (empêche de “scanner” une zone DNS facilement).

Pour que '''DNSSEC fonctionne correctement''', il faut '''déclarer la clé KSK''' (Key Signing Key) chez votre '''registrar''', ici '''Gandi'''.

Sur votre machine, les clés sont générées automatiquement dans le répertoire (key-directory dans le fichier <code>/etc/bind/named.conf.local)</code><syntaxhighlight lang="bash">
/etc/bind/keys/
</syntaxhighlight>
Par exemple, vous pouvez voir des fichiers comme ceux-ci :<syntaxhighlight lang="ruby">
Kmuspellheim2.online.+013+03837.key
Kmuspellheim2.online.+013+03837.private
Kmuspellheim2.online.+013+03837.state

Kmuspellheim2.online.+013+14053.key
Kmuspellheim2.online.+013+14053.private
Kmuspellheim2.online.+013+14053.state

</syntaxhighlight>🗝️ Les fichiers importants :

* Les fichiers '''<code>.key</code>''' contiennent la '''clé publique''' (celle que vous devez copier/coller sur Gandi).
* Les fichiers '''<code>.private</code>''' contiennent la '''clé privée''' (à '''ne jamais partager''' !).
* Les fichiers '''<code>.state</code>''' servent à BIND pour gérer l’état et la durée de validité des clés.

Pour éviter tout problème avec la validation DNSSEC, pensez à mettre les deux fichiers .key dans l’interface de Gandi, dans la partie DNSSEC de votre domaine.

💡 En faisant cela, vous reliez votre zone DNS signée à la chaîne de confiance globale d’Internet : tout le monde pourra alors vérifier que vos données DNS sont authentiques et non modifiées.

Une fois la configuration DNSSEC en place, on peut tester si '''tout fonctionne correctement''' avec le site '''DNSViz'''.

Ce site permet d’'''analyser les signatures DNSSEC''' et de vérifier si la '''chaîne de confiance''' est bien construite du début à la fin (depuis la racine DNS jusqu’à votre zone).
{| class="wikitable"
|+
![[Fichier:DNSviz Muspellheim2.online.png|gauche|1129x1129px|DNSviz Muspellheim2.online]]
|}
Le graphe montre '''la chaîne de confiance DNSSEC''' :

* On part de la '''racine DNS''' (<code>.</code>), qui délègue au TLD <code>.online</code>.
* <code>.online</code> contient une clé DS qui fait le lien avec '''ton domaine''' <code>muspellheim2.online</code>.
* Ensuite, ton domaine possède ses propres clés (DNSKEY), qui signent toutes les infos de ta zone (A, NS, AAAA, etc.)

✅ Tout est "Secure" sur le graphe → l'''a configuration DNSSEC est correcte et vérifiée''' !
== APACHE ==
===== '''Configuration d’Apache sur GOW''' : =====
Apache va '''écouter les requêtes envoyées à muspellheim2.online''', puis les '''rediriger vers un autre serveur''' (ici Atreus), via son '''adresse IPv6'''.

Cela permet d’accéder à un site web qui tourne sur Atreus '''même si celui-ci n’a pas d’IPv4 publique'''.

<code>root@GOW:~# cat /etc/apache2/sites-available/muspellheim2.online.conf</code>
<syntaxhighlight lang="bash">
#Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online

ProxyPass / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
</VirtualHost>

# Partie HTTPS (port 443)
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName muspellheim2.online

SSLProxyEngine on
ProxyPreserveHost on

SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/KGandiPierre/GandiCert.pem

ProxyPass / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/

</VirtualHost>
</IfModule>
</syntaxhighlight>
📄 '''Fichier concerné : /etc/apache2/sites-available/muspellheim2.online.conf'''

Ce fichier configure un virtual host Apache2 pour le domaine muspellheim2.online, en mode proxy inverse (reverse proxy). Cela signifie que le serveur Apache2 reçoit les requêtes des utilisateurs et les redirige vers un autre serveur (Atreus), ici identifié par son adresse IPv6.

Le fichier gère deux protocoles :

- HTTP (port 80) — non sécurisé

- HTTPS (port 443) — sécurisé avec SSL/TLS

🔹 *VirtualHost :80 : Cela signifie que ce bloc s'applique à toutes les interfaces réseau, sur le port 80 (HTTP).

🔹 ServerName : Nom de domaine géré par ce virtual host. Apache redirigera les requêtes envoyées à muspellheim2.online.

🔹 ProxyPass / ... : Toutes les requêtes reçues sur / sont transmises à l'adresse IPv6 mentionnée. C’est là que tourne le vrai service web.

🔹 ProxyPassReverse : Permet de réécrire les en-têtes de redirection (comme les Location: envoyés par le serveur cible), pour que le client voit toujours muspellheim2.online au lieu de l’IP.

Atreus n’a pas d’IPv4 publique, donc il n’est pas directement joignable depuis Internet.

➜ GOW, qui a une IP publique, agit comme une porte d’entrée vers Atreus.

➜ C’est lui qui reçoit les requêtes extérieures et les redirige en interne vers le bon serveur.

On appelle ça un proxy inverse : le client ne sait pas que le site tourne ailleurs, tout passe par GOW.

===== '''Configuration d’Apache2 sur Atreus : le vrai serveur web – Site muspellheim2.online''' : =====
📄 Fichier : /etc/apache2/sites-available/000-muspellheim.conf

Ce fichier configure le serveur Apache2 sur la machine Atreus, qui héberge le véritable contenu du site muspellheim2.online. Il gère aussi bien les connexions HTTP que HTTPS.
<syntaxhighlight lang="bash">
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>
</syntaxhighlight>

🔹 *VirtualHost :80 : Écoute sur le port HTTP.

🔹 ServerName / ServerAlias :

ServerName : Nom principal du site.

ServerAlias : Permet aussi de répondre à www.muspellheim2.online.

🔹 RedirectPermanent / : Redirige tout le trafic HTTP vers HTTPS.

💡 '''Pourquoi ?'''

C’est une '''bonne pratique de sécurité''' : on force tous les visiteurs à utiliser une connexion chiffrée.

Partie HTTPS – Serveur principal

<syntaxhighlight lang="bash">
<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
...
</VirtualHost>
</syntaxhighlight>

Port 443 : Pour les connexions HTTPS (chiffrées).

🔹 ServerName / ServerAlias : Idem que pour le port 80

<syntaxhighlight lang="bash">
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
</syntaxhighlight>
🔹 Ces trois fichiers permettent au serveur d’offrir une connexion HTTPS sécurisée :

- .crt : certificat public du site.

- .key : clé privée (confidentielle).

- ChainFile : certificat intermédiaire (chaîne de certification, fourni par Gandi ici).

'''📝 Logs Apache'''
<syntaxhighlight lang="bash">
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</syntaxhighlight>

🔹 Gère la journalisation :

- error.log : erreurs serveur.

- access.log : toutes les requêtes reçues, avec IP, timestamp, etc.
<syntaxhighlight lang="bash">
# Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>

# Partie HTTPS (port 443)

<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
# SSLProxyEngine on
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</syntaxhighlight>Et comme '''Atreus est le vrai serveur''', et que '''GOW redirige tout vers lui''', ça permet à l’utilisateur de '''n’avoir aucune idée que deux serveurs travaillent ensemble derrière <code>muspellheim2.online</code>'''.
{| class="wikitable"
|+
![[Fichier:Schéma fonctionnel redirection vers Atreus.png|alt=Schéma fonctionnel redirection vers Atreus|345x345px]]
|}

== ✅ Vérification finale : est-ce que le site est en ligne et accessible ? ==
Une fois que '''tout est configuré''' (serveur web, DNS, DNSSEC, reverse proxy, certificats...), il ne reste plus qu'à '''tester si le site fonctionne bien'''.

=== 🧪 Méthode 1 : test en ligne de commande avec <code>curl</code> ===
<syntaxhighlight lang="ruby">
curl -4 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -4 muspellheim.png|alt=sortie curl -4 muspellheim|550x550px]]
|}
<syntaxhighlight lang="ruby">
curl -6 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -6 muspellheim.png|alt=sortie curl -6 muspellheim|502x502px]]
|}

=== 🌍 Méthode 2 : test dans un navigateur ===
Vous pouvez aussi tout simplement ouvrir votre navigateur préféré et taper l’adresse :<syntaxhighlight lang="ruby">
https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Projet fini Muspellheim.png|alt=Projet fini Muspellheim|1076x1076px]]
|}

* <code>curl -4</code> et <code>curl -6</code> permettent de '''vérifier si votre site répond en IPv4 et IPv6'''.

* Si vous n’avez pas de retour ou que la connexion échoue, vérifiez :
** votre '''config Apache'''
** vos '''règles de pare-feu'''
** vos '''enregistrements DNS'''
** et que vos '''certificats sont bien en place'''

Atelier SysRes SE4 2024/2025 E14

2026-01-20T15:58:43Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

'''Projet AARV LECOMTE et CASIMIRI'''

== INTRODUCTION ==
Dans le cadre de ce projet de virtualisation, j’ai déployé une infrastructure composée de '''deux machines dédiées aux services''' et d’une '''machine mandataire''', le tout orchestré à l’aide de '''Xen'''.

La machine '''Atreus''' joue un rôle central en assurant '''l’hébergement des services web''' et autres composants applicatifs. La machine '''GOW''' fait office de '''mandataire réseau''' : elle gère la '''connectivité vers l’extérieur''', que ce soit en '''IPv4 ou en IPv6''', et sert aussi de '''reverse proxy''' pour rediriger les requêtes vers les machines de service internes.

La '''deuxième machine de service''' appartient à Monsieur '''Antoine LECOMPTE''' et porte le nom de '''Kratos'''. Elle complète l’architecture et participe à l’ensemble des services distribués au sein de l’infrastructure.

<big>'''✉️ Petit mot pour les prochaines promotions'''</big>

Salut à vous les prochaines promos 👋

Dans ce document, j’ai essayé de vous expliquer au mieux les différentes étapes que j’ai traversées pour monter ce projet. Je me suis appuyé sur ce que j’ai compris moi-même au fil des TP, les cours des profs (qu’il faut vraiment relire, ils sont précieux), des ressources trouvées sur Internet, et je ne vais pas vous mentir… parfois un petit coup de main de certains LLM comme ChatGPT 👀 m’a bien aidé quand je bloquais.

Ce n’est pas un tutoriel parfait, mais plutôt un guide pour vous accompagner avec des explications techniques assez simples à comprendre (que je pense avoir compris surtout), même si vous n’avez encore jamais touché au réseau, à l’infra ou à un serveur web. L’objectif, c’est que vous puissiez prendre confiance, comprendre les bases, et réussir à faire tourner votre projet sans paniquer.

Je vous souhaite vraiment bon courage pour ce projet. C’est l’un des meilleurs moyens d’apprendre concrètement et de progresser à fond. N’hésitez pas à poser des questions à vos profs, ils sont là pour vous aider. Prenez le temps de relire vos cours tranquillement, et surtout, n’ayez pas peur de tester, de faire des erreurs, de casser et de recommencer (certains profs demande à ce qu'on casse les machines pour montrer qu'on cherche) : c’est comme ça qu’on apprend.

Si vous avez l'occasion de les consulter, je vous conseille vivement d'aller regarder les wikis de Madame EL BACHIRI, Monsieur TOURON et Monsieur DETREZ. Ils ont certaines informations en plus que moi sur tout ce qui va être configurations CISCO, OSPF et tout ce qui touche au physique (câbles, commutateurs).

En espérant que vous allez plus loin que nous sur ce projet ![[Fichier:Df -h.png|vignette]]

== CRÉATION MACHINES VIRTUELLES ==

Tout d'abord, nous devons configurer nos MV de services. Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Atreus --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
root@capbreton:~# xen-create-image --hostname=SE4.Kratos --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Atreus</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

Il faudra aussi créer des volumes logiques dédiés à des /var et /home pour chacune de nos VM.

Sur capbreton, les commandes sont :

<code>lvcreate -L10G -nSE4.[NomdeVM].home virtual

lvcreate -L10G -nSE4.[NomdeVM].var virtual</code>

celà va créer des volumes logiques dédiés aux paths /var et /home pour vos VM dans un dossier /dev/virtual.

A AUCUN moment vous devez écrire une ligne commençant par mkfs sur capbreton, vous risquez de tuer capbreton si vous le faites.

Pour initialiser les machines, nous devons exécuter ces commandes:

<syntaxhighlight lang="bash">
xen create /etc/xen/SE4.Atreus.cfg
xen create /etc/xen/SE4.Kratos.cfg
</syntaxhighlight>

Une fois les MV créées et en ligne, nous devons exécuter ces commandes pour les contrôler:
<syntaxhighlight lang="bash">
xen console SE4.Atreus
xen console SE4.Kratos
</syntaxhighlight>

Une fois le login "root" et le mdp (top secret) rentrés dans la console, nous sommes sur la VM et pouvons la contrôler comme un ordinateur avec un OS classique.
<syntaxhighlight lang="bash">
root@Atreus:~#
</syntaxhighlight>

== PARTIONING DES MV ==
Nous avons modifié les fichiers <code>/etc/xen/[Kratos][Atreus].cfg</code> pour attacher les partitions LVM aux machines :<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w',
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w',
]

</syntaxhighlight>Le paramètre <code>disk</code> définit les disques virtuels attachés à la machine virtuelle (domaine Xen).

Chaque élément du tableau suit la syntaxe :<syntaxhighlight lang="bash">
<type>:<source>,<cible>,<mode>
</syntaxhighlight>

* '''type :''' indique si le disque provient :
** d'un fichier (<code>file:</code>)
** d'un périphérique physique réel (<code>phy:</code>).
* '''source :''' chemin complet vers l'image disque ou vers le périphérique physique sur la machine hôte.
* '''cible :''' nom du périphérique vu par la machine virtuelle (exemple : <code>xvda</code>, <code>xvdb</code>, etc.).

* '''mode :''' type d'accès au disque (<code>r</code> en lecture seule, <code>w</code> en lecture-écriture).

==== DISQUE VIRTUEL PRINCIPAL : ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w'
</syntaxhighlight>

* '''Type''' : <code>file</code> (stockage basé sur un fichier-image disque).
* '''Source''' : <code>/usr/local/xen/domains/SE4.Atreus/disk.img</code> (fichier contenant le disque virtuel).
* '''Cible''' : <code>xvda2</code> (deuxième partition du disque virtuel <code>xvda</code> visible depuis la MV).
* '''Mode''' : <code>w</code> (lecture-écriture).

Ce disque correspond à la racine (<code>/</code>) du système de fichiers Linux de la MV.

==== DISQUE VIRTUEL SWAP ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w'

</syntaxhighlight>

* '''Type :''' <code>file</code> → Image disque stockée dans un fichier.
* '''Source :''' <code>/usr/local/xen/domains/SE4.Atreus/swap.img</code> → Chemin de l'image disque swap.
* '''Cible :''' <code>xvda1</code> → Première partition du disque virtuel <code>xvda</code>.

==== DISQUE PHYSIQUE POUR /home ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Un périphérique physique (généralement une partition réelle ou un volume logique LVM).
* '''Source :''' <code>/dev/virtual/SE4.Atreus.home</code> → Partition ou volume logique physique sur l'hôte. L'hôte étant le disque dur de capbreton.
* '''Cible :''' <code>xvda3</code> → Troisième partition du disque virtuel <code>xvda</code>.

Cette partition dédiée permet d’isoler le répertoire <code>/home</code>, facilitant ainsi la gestion des données utilisateur séparément du système.

==== DISQUE PHYSIQUE POUR /var ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Périphérique physique.
* '''Source :''' <code>/dev/virtual/SE4.Atreus.var</code> → Partition physique ou volume logique dédié sur l'hôte.
* '''Cible :''' <code>xvdb1</code> → Première partition du second disque virtuel (<code>xvdb</code>).

Cette partition est dédiée au répertoire <code>/var</code>, où sont stockés les journaux (logs), les bases de données, les fichiers temporaires, etc. Cette séparation permet une meilleure gestion des données systèmes dynamiques.

Pour le fichier /var<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
</syntaxhighlight>Pour le fichier /home<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

==== DÉMARRAGE AUTOMATIQUE DU MONTAGE ====
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|Fichier_fstab|centré]]
|}

== CONFIGURATION RÉSEAU ==

Chaque machine dispose d'une adresse IPv4 fixe sur un réseau privé, ainsi que d'une adresse IPv6 configurée automatiquement.

Nous modifions la configuration réseau dans <code>/etc/network/interfaces</code> de la machine mandataire. Ensuite, nous ajustons le fichier de configuration de la machine virtuelle afin qu'elle possède deux interfaces : la première permet de communiquer avec le routeur mis en place par nos collègues, tandis que la seconde est connectée au pont réseau que nous avons créé pour l’intercommunication entre nos trois machines.

=== MACHINE MANDATAIRE ===
<syntaxhighlight lang="bash">
name = 'SE4.GOW'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:E7:C5:1A,bridge=bifrost',
'mac=00:16:3E:E7:C5:1B,bridge=SE4' ]

</syntaxhighlight>Le pont nommé '''"bifrost"''', défini dans le fichier de configuration de notre machine virtuelle mandataire, sert à '''relier virtuellement les trois machines''' entre elles.

Pour que des machines puissent communiquer, elles doivent être sur le '''même réseau'''. Ici, c’est un '''VIF (Virtual Interface)''' qui joue ce rôle : c’est une sorte de '''commutateur virtuel''' (ou switch virtuel).

Un '''commutateur''', c’est ce que vous imaginez peut-être comme une grosse boîte avec plein de câbles et de lumières clignotantes, qu’on trouve dans les salles serveurs.

Dans notre cas, tout ça est '''simulé dans la machine virtuelle''', donc pas de câbles physiques : la communication se fait via la '''carte réseau virtuelle''' attribuée à chaque machine.

Après avoir redémarré la machine, l’interface réseau est visible dans le fichier <code>/etc/network/interfaces</code>. On peut modifier ce fichier pour attribuer une adresse IP fixe à la machine GOW.<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.3.1/24
# post-up ethtool -K eth0 tx off

iface eth0 inet6 auto

auto eth1
iface eth1 inet static
address 193.48.57.172/27
gateway 193.48.57.161
</syntaxhighlight>

=== MACHINE DE SERVICES ===
/etc/network/interfaces de la machine SE4.Atreus qui permet de lié les Interfaces de la MV avec ses VIF pour communiquer en IPv6 avec Internet et IPv4 avec la machine mandataire <syntaxhighlight lang="bash">
# The loopback network interface
auto lo
iface lo inet loopback

auto eth0

iface eth0 inet6 auto

iface eth0 inet static
address 192.168.3.2/24
gateway 192.168.3.1

auto eth1
iface eth1 inet6 auto

</syntaxhighlight>On configure la machine mandataire comme une passerelle (gateway) en IPv4. En IPv6, l’adresse est attribuée automatiquement grâce au bridge SE4.

Une fois que chaque machine peut être pingée par les autres et qu’elles arrivent à envoyer des requêtes vers Internet, on peut passer à l’étape suivante.
{| class="wikitable"
|+
![[Fichier:Interfacekratos.png|alt=Interfacekratos|Interfacekratos|centré|vignette|470x470px]]
! rowspan="2" |[[Fichier:IpaAtreusIp6Ip4.png|vignette|546x546px|ip a de la machine SE4.Atreus|centré]]
|-
|[[Fichier:PingEntre2VM.png|alt=PingEntre2VM|PingEntre2VM|centré|vignette|986x986px]]
|}

==== SSH ====
On active le SSH avec la ligne <code>PermitRootLogin yes</code> dans le fichier <code>/etc/ssh/sshd_config</code>sur les 3 machines, on peut accéder à la mandataire avec son adresse IPv4 routée, pour les machines de service on utilise l'adresse en IPv6

===== 🛡️ Sécurisation SSH avec Fail2Ban =====
📄 '''Fichier :''' <code>/etc/fail2ban/jail.local</code>

Ce fichier contient les règles locales de '''Fail2Ban''', un outil qui surveille les logs système et '''bannit temporairement les adresses IP''' en cas de comportement suspect (comme des tentatives de connexion SSH répétées avec un mauvais mot de passe).<syntaxhighlight lang="vim">
[sshd]
enable = true
port = ssh
filter = sshd
maxretry = 3
findtime = 300
bantime = 600
</syntaxhighlight>
{| class="wikitable"
!Paramètre
!Explication
|-
|<code>enable = true</code>
|Active la surveillance de SSH.
|-
|<code>port = ssh</code>
|Surveille le port SSH.
|-
|<code>filter = sshd</code>
|Utilise le '''filtre prédéfini''' <code>sshd.conf</code>, qui détecte les échecs de connexion dans les logs.
|-
|<code>maxretry = 3</code>
|'''3 tentatives''' ratées autorisées avant bannissement.
|-
|<code>findtime = 300</code>
|La fenêtre de détection : '''5 minutes''' pour accumuler ces 3 tentatives.
|-
|<code>bantime = 600</code>
|Durée de bannissement : '''10 minutes''' (600 secondes).
|}

=== CONFIGURATION DNS ===
Rappel : Qu’est-ce qu’un serveur DNS ?

Vu en cours avec Monsieur redon et Monsieur Vantroys, DNS veut dire '''Domain Name System'''. C’est un '''service''' qui fait la conversion entre un '''nom de domaine''' (comme <code>muspellheim2.online</code>) et une '''adresse IP''' (comme <code>193.48.57.172</code>), que les machines utilisent pour communiquer. Ce sont les pages jaunes des serveurs et IP d'Internet. On ne connait pas l'adresse IP de tous les sites. On ne connait que les noms. Quand on écrit netflix.com sur Internet, on interroge les serveurs DNS pour qu"il puisse nous rediriger vers l'adresse IP associé au nom "netflix.com".

==== 🌍 Fichier de zone DNS : <code>muspellheim2.online</code> ====
📄 '''Fichier :''' <code>/etc/bind/zones/muspellheim2.online/muspellheim2.zone</code>

Ce fichier définit tous les enregistrements DNS pour le domaine <code>muspellheim2.online</code>.

Il est utilisé par le serveur BIND '''maître''' (primary) pour répondre aux requêtes DNS.

===== 🧾 En-tête : SOA (Start Of Authority) =====
<syntaxhighlight lang="vim">
@ IN SOA ns.muspellheim2.online. admin.muspellheim2.online. (
3609 ; Numéro de version
21600 ; Rafraîchissement (6h)
3600 ; Re-tentative (1h)
2592000 ; Expiration (30j)
86400 ) ; Cache négatif (24h)
</syntaxhighlight>🔹 <code>@</code> : représente le domaine racine (<code>muspellheim2.online.</code> ici)

🔹 <code>SOA</code> : Spécifie '''l’autorité principale''' de la zone. Ici :

* Serveur DNS maître : <code>ns.muspellheim2.online.</code>
* Contact admin : <code>admin@muspellheim2.online</code> (le point remplace le <code>@</code>)
A chaque modification de ce fichier, il faut incrémenter le numéro de version de +1.

===== 📡 Serveurs DNS (NS) =====
<syntaxhighlight lang="vim">
@ IN NS ns.muspellheim2.online.
@ IN NS ns.jotunheim2.tech.
</syntaxhighlight>🔹 Ces lignes déclarent les serveurs DNS autoritaires pour cette zone :

- ns.muspellheim2.online. (le maître)

- ns.jotunheim2.tech. (un secondaire)

===== 🧭 Enregistrements de type A / AAAA =====
<syntaxhighlight lang="vim">
ns IN A 193.48.57.172
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
@ IN A 193.48.57.172
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
</syntaxhighlight>🔹 '''A''' : Adresse IPv4

🔹 '''AAAA''' : Adresse IPv6

Ces enregistrements associent :

* <code>ns.muspellheim2.online</code> à ses adresses IP (serveur DNS)
* <code>muspellheim2.online</code> lui-même à la même machine (le site est hébergé dessus)

===== 🔗 Alias (CNAME) =====
<syntaxhighlight lang="vim">
www IN CNAME muspellheim2.online.
</syntaxhighlight>🔹 Les requêtes pour <code>www.muspellheim2.online</code> seront redirigées vers <code>muspellheim2.online</code>.

Cela évite de dupliquer les enregistrements A/AAAA pour <code>www</code>.

===== 🔐 DNS Validation via Digicert =====
<syntaxhighlight lang="vim">
_gay4mlana6awxk71vd9gjuzdkzfism2.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
_gay4mlana6awxk71vd9gjuzdkzfism2.www.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
</syntaxhighlight>🔹 Ces lignes servent à '''valider le domaine''' auprès de l’autorité de certification (Digicert) pour obtenir un certificat SSL.

🔹 <code>dcv.digicert.com.</code> est le serveur que Digicert utilise pour vérifier la possession du domaine (via un CNAME dynamique généré).

On peut ensuite vérifier la syntaxe de notre '''fichier de zone DNS''' avec l’outil <code>named-checkzone</code>.

Cet outil nous aide à repérer les erreurs dans l’écriture du fichier, un peu comme '''Microsoft Word souligne les fautes de grammaire ou de syntaxe''' dans un texte.

Par exemple :<syntaxhighlight lang="ruby">
root@Atreus:~# named-checkzone muspellheim2.online /etc/bind/zones/muspellheim2.online/muspellheim2.zone
zone muspellheim2.online/IN: loaded serial 3609
OK
</syntaxhighlight>Ici, le message '''"OK"''' signifie que le fichier est bien écrit et ne contient pas d’erreurs de syntaxe.

Juste à noter : <code>named-checkzone</code> vérifie uniquement la syntaxe et la structure logique du fichier (comme la présence d’un SOA, la validité des enregistrements, etc.), '''mais pas si les adresses IP ou noms existent réellement'''.

Une fois que tout est correctement configuré, '''n’oubliez pas de redémarrer les services <code>named</code> et <code>bind</code>'''.

Cela permet à ces services de '''prendre en compte les nouvelles modifications''' que vous avez apportées dans les fichiers de configuration.

Il faut aussi '''attribuer les bons droits d'accès aux fichiers''', pour que <code>bind</code> puisse les lire correctement. Sinon, il risque de ne pas fonctionner comme prévu.<syntaxhighlight lang="ruby">
chown bind:bind /etc/bind/zones/muspellheim2.online/muspellheim2.zone
chmod 644 /etc/bind/zones/muspellheim2.online/muspellheim2.zone

chown bind:bind /etc/bind/named.conf.local
chmod 644 /etc/bind/named.conf.local
</syntaxhighlight>

* <code>chown</code> permet de '''donner la propriété des fichiers à l’utilisateur et au groupe <code>bind</code>'''.

* <code>chmod 644</code> donne les '''droits de lecture au service <code>bind</code>''', tout en empêchant d'autres utilisateurs non privilégiés de les modifier.

===== Vérification avec l'outil "dig" =====
On peut '''vérifier que notre serveur DNS fonctionne correctement''' en utilisant la commande <code>dig</code>.

C’est un outil qui envoie une requête DNS pour demander l’adresse IP d’un nom de domaine, et affiche la réponse complète reçue du serveur.

Par exemple, ici on interroge notre propre serveur DNS local (<code>@localhost</code>) pour vérifier s’il connaît le domaine <code>muspellheim2.online</code> :<syntaxhighlight lang="vim">
root@Atreus:~# dig @localhost muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="vim">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight>Cela signifie que la requête s’est bien déroulée, et qu’il n’y a '''pas d’erreur''' dans le fichier de zone.<syntaxhighlight lang="vim">
;; ANSWER SECTION:
muspellheim2.online. 200 IN A 193.48.57.172
</syntaxhighlight>
Le serveur DNS a bien répondu avec l’adresse IP '''193.48.57.172''', donc '''la zone est bien configurée et active'''.Ce test permet de s'assurer que '''le nom de domaine est bien reconnu et renvoie vers la bonne adresse IP'''.

On peut aussi tester depuis '''une autre machine virtuelle''', pour voir si '''le domaine est connu à l'extérieur''', par exemple par '''le DNS public de Google (<code>8.8.8.8</code>)'''.

Pour cela, on utilise <code>dig</code> en spécifiant l’IP du serveur DNS qu’on veut interroger :<syntaxhighlight lang="ruby">
root@GOW:~# dig @8.8.8.8 muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ANSWER SECTION:
muspellheim2.online. 189 IN A 193.48.57.172
</syntaxhighlight>Google a répondu avec l’adresse IP '''193.48.57.172''', ce qui prouve que '''notre domaine est maintenant reconnu depuis l’extérieur'''.
🧠 '''Petit point d’attention''' : Si tu n’as pas volontairement '''enregistré le domaine <code>muspellheim2.online</code> sur Internet''' (via un registrar, ici c'est Gandi), alors :

* soit '''ton environnement de test est spécial''' (ex : en école avec une infra réseau propre et un DNS intermédiaire qui communique avec Google),
* soit '''le domaine a réellement été enregistré publiquement''', auquel cas tu partages un vrai domaine avec d'autres (et ça peut poser des conflits si tu voulais juste faire des tests en local).

==== REGISTRAR ET PROPAGATION DNS ====
Pour rendre notre '''serveur DNS opérationnel et accessible depuis Internet''', on se rend sur le site du '''registrar''' (dans notre cas : '''Gandi'''), qui est l’organisme auprès duquel on a acheté notre '''nom de domaine'''.

Dans l’onglet '''"Nameserver"''', on ajoute un '''Glue Record'''.

Un Glue Record sert à '''lier notre nom de domaine à nos propres serveurs DNS''', en indiquant leurs adresses IP :

* l’adresse '''IPv4''' de la '''machine mandataire''' (notre DNS principal),
* les adresses '''IPv6''' des '''machines de service''', si on veut un fonctionnement complet en IPv6.

Ensuite, on '''remplace les serveurs de noms (Nameservers) par les nôtres''', c’est-à-dire notre propre serveur DNS.

Cela fait de notre serveur '''le référent officiel pour la gestion des noms de domaine''' associés à <code>muspellheim2.online</code>.

🧠 Pourquoi on fait tout ça ?

Eh bien, comme on l’a vu avec la commande :<syntaxhighlight lang="vim">
dig @8.8.8.8 muspellheim2.online
</syntaxhighlight>Google a pu répondre car '''notre domaine est désormais public''' !

Si on n’avait pas fait cette configuration chez Gandi, personne sur Internet (hors de notre réseau) n’aurait pu le voir.

🌐 Pour faire simple :

En ajoutant un Glue Record et en configurant nos Nameservers, on annonce notre domaine au monde entier.

Cela permet à n’importe quel ordinateur sur Internet de retrouver l’adresse IP de notre serveur — et donc d’afficher notre site ou d’accéder à nos services.
{| class="wikitable"
|+
![[Fichier:NameserverGandi.png|gauche|NameserverGandi Pierre CASIMIRI muspellheim2.online]]
|-
|[[Fichier:GlueRecordGandi.png|gauche|2305x2305px|GlueRecordGandi Pierre CASIMIRI muspellheim2.online]]
|}

==== DIFFUSION DE NOTRE SUPERBE SERVEUR AU MONDE ====

🌍 Une fois le Glue Record ajouté… on attend un peu que le monde entier soit au courant !

Une fois qu’on a :

* ajouté les '''Glue Records''',
* remplacé les '''Nameservers''' dans le registrar (comme Gandi),

eh bien il faut patienter un peu. Pourquoi ? Parce que '''les informations DNS doivent se propager''' à travers le monde. Cette phase peut prendre '''quelques heures à quelques jours''', selon les serveurs.

🛰️ Comment savoir si c’est bien propagé ?

Il existe des sites comme '''DNSChecker.org''' qui permettent de voir si votre nom de domaine est '''bien visible depuis plusieurs endroits de la planète'''.

📌 Exemple : <code>muspellheim2.online</code>

Sur DNSChecker, vous entrez votre domaine et choisissez le type d'enregistrement que vous voulez vérifier, par exemple :
{| class="wikitable"
!Type
!Ce que ça affiche
|-
|<code>A</code>
|Adresse IPv4 liée au domaine
|-
|<code>AAAA</code>
|Adresse IPv6
|-
|<code>NS</code>
|Liste des Nameservers en charge du domaine
|-
|<code>CNAME</code>
|Alias d’un domaine vers un autre
|-
|<code>DNSKEY</code>
|Clés publiques DNSSEC (on y reviendra plus tard)
|}
{| class="wikitable"
|+
![[Fichier:DNSChecker1.png|gauche|768x768px|DNSChecker1]]
![[Fichier:DNSChecker3.png|alt=DNSChecker3|bordure|687x687px]]
! rowspan="2" |[[Fichier:DNSChecker5.png|alt=DNSChecker5|655x655px]]
|-
|[[Fichier:DNSChecker2.png|alt=DNSChecker2|bordure|768x768px]]
|[[Fichier:DNSChecker4.png|alt=DNSChecker4|701x701px]]
|}

* ✅ '''Check vert''' : ça veut dire que ce serveur DNS a bien reçu et reconnu ton info.
* 🟡 '''Check en attente''' : propagation en cours ou serveur lent.
* ❌ '''Check rouge''' : info non encore propagée à ce serveur ou pas propagée car les certificats ne sont pas acceptés par ses serveurs DNS.

==== DNSSEC sur Atreus ====

===== 🧭 Configuration DNS sur le serveur BIND – <code>named.conf.local</code> =====
📄 Fichier : <code>/etc/bind/named.conf.local</code>

Ce fichier contient la déclaration des zones DNS locales pour le serveur BIND.

On y définit ici :

-Une zone primaires (gérées en local)

-Une zone secondaire (copiée depuis un autre serveur)

Et une politique DNSSEC.<syntaxhighlight lang="bash">
cat /etc/bind/named.conf.local
</syntaxhighlight><syntaxhighlight lang="vim">
zone "muspellheim2.online" {

type primary;
file "/etc/bind/zones/muspellheim2.online/muspellheim2.zone";

allow-transfer{2001:660:4401:60a0:216:3eff:fee7:c51b;

2001:660:4401:60a0:216:3eff:fed0:9ab0;}; // filtrage des secondaires

also-notify{2001:660:4401:60a0:216:3eff:fee7:c51b;}; // pour les secondaires vicieux notify yes; // notification des secondaires
key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes; };

zone "jotunheim2.tech"{

type slave;
file "/etc/bind/jotunheim2.tech";
primaries{2001:660:4401:60a0:216:3eff:fed0:9ab0;};

};

dnssec-policy "dnspol" {

keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;

};
</syntaxhighlight>

🔹 '''type primary''' : Ce serveur est '''l'autorité principale''' pour la zone.

🔹 '''file''' : Chemin du fichier de zone contenant tous les enregistrements DNS (<code>A</code>, <code>AAAA</code>, <code>NS</code>, etc.).

🔹 '''allow-transfer''' : Liste des serveurs secondaires '''autorisés à faire un transfert de zone''' (AXFR). Cela sécurise l’accès aux données DNS.

🔹 '''also-notify''' : Force l’envoi de notifications DNS vers certains secondaires, même s’ils ne sont pas configurés comme secondaires officiels.

🔹 '''notify yes''' : Active les notifications automatiques des serveurs secondaires lorsqu’une mise à jour de la zone est faite.

🔹 '''dnssec-policy "dnspol"''' : Active '''DNSSEC''' avec une politique personnalisée.

🔹 '''inline-signing yes''' : Active la '''signature automatique''' de la zone par BIND.

====== Zone secondaire : <code>jotunheim2.tech</code> ======
<syntaxhighlight lang="vim">
zone "jotunheim2.tech" {
type slave;
file "/etc/bind/jotunheim2.tech";
primaries { 2001:660:4401:60a0:216:3eff:fed0:9ab0; };
};
</syntaxhighlight>🔹 '''type slave''' : Ce serveur récupère les données de zone depuis un '''serveur primaire distant'''.

🔹 '''primaries { ... }''' : Adresse du serveur maître à interroger pour obtenir la zone.

🔹 '''file''' : Emplacement local où la zone est stockée après transfert.

====== 🔐 Politique DNSSEC : <code>"dnspol"</code> ======
<syntaxhighlight lang="vim">
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>🔹 '''ksk''' : Key Signing Key (clé qui signe les autres clés DNS).

🔹 '''zsk''' : Zone Signing Key (clé qui signe les enregistrements DNS).

🔹 '''algorithm 13''' : Il s’agit d’'''ECDSA P-256 with SHA-256''' (<nowiki>RFC 6605</nowiki>), algorithme sécurisé et moderne.

🔹 '''nsec3param''' : Indique que '''NSEC3''' est utilisé (permet de sécuriser les réponses "ce nom n'existe pas" sans divulguer d'autres noms).

✅ Les deux clés sont générées dans le répertoire <code>key-directory</code>, ont une durée de vie '''illimitée''', et utilisent '''l’algorithme 13''' (ED25519, rapide et sécurisé).

✅ <code>nsec3param</code> : active la protection contre l’énumération de noms (empêche de “scanner” une zone DNS facilement).

Pour que '''DNSSEC fonctionne correctement''', il faut '''déclarer la clé KSK''' (Key Signing Key) chez votre '''registrar''', ici '''Gandi'''.

Sur votre machine, les clés sont générées automatiquement dans le répertoire (key-directory dans le fichier <code>/etc/bind/named.conf.local)</code><syntaxhighlight lang="bash">
/etc/bind/keys/
</syntaxhighlight>
Par exemple, vous pouvez voir des fichiers comme ceux-ci :<syntaxhighlight lang="ruby">
Kmuspellheim2.online.+013+03837.key
Kmuspellheim2.online.+013+03837.private
Kmuspellheim2.online.+013+03837.state

Kmuspellheim2.online.+013+14053.key
Kmuspellheim2.online.+013+14053.private
Kmuspellheim2.online.+013+14053.state

</syntaxhighlight>🗝️ Les fichiers importants :

* Les fichiers '''<code>.key</code>''' contiennent la '''clé publique''' (celle que vous devez copier/coller sur Gandi).
* Les fichiers '''<code>.private</code>''' contiennent la '''clé privée''' (à '''ne jamais partager''' !).
* Les fichiers '''<code>.state</code>''' servent à BIND pour gérer l’état et la durée de validité des clés.

Pour éviter tout problème avec la validation DNSSEC, pensez à mettre les deux fichiers .key dans l’interface de Gandi, dans la partie DNSSEC de votre domaine.

💡 En faisant cela, vous reliez votre zone DNS signée à la chaîne de confiance globale d’Internet : tout le monde pourra alors vérifier que vos données DNS sont authentiques et non modifiées.

Une fois la configuration DNSSEC en place, on peut tester si '''tout fonctionne correctement''' avec le site '''DNSViz'''.

Ce site permet d’'''analyser les signatures DNSSEC''' et de vérifier si la '''chaîne de confiance''' est bien construite du début à la fin (depuis la racine DNS jusqu’à votre zone).
{| class="wikitable"
|+
![[Fichier:DNSviz Muspellheim2.online.png|gauche|1129x1129px|DNSviz Muspellheim2.online]]
|}
Le graphe montre '''la chaîne de confiance DNSSEC''' :

* On part de la '''racine DNS''' (<code>.</code>), qui délègue au TLD <code>.online</code>.
* <code>.online</code> contient une clé DS qui fait le lien avec '''ton domaine''' <code>muspellheim2.online</code>.
* Ensuite, ton domaine possède ses propres clés (DNSKEY), qui signent toutes les infos de ta zone (A, NS, AAAA, etc.)

✅ Tout est "Secure" sur le graphe → l'''a configuration DNSSEC est correcte et vérifiée''' !
== APACHE ==
===== '''Configuration d’Apache sur GOW''' : =====
Apache va '''écouter les requêtes envoyées à muspellheim2.online''', puis les '''rediriger vers un autre serveur''' (ici Atreus), via son '''adresse IPv6'''.

Cela permet d’accéder à un site web qui tourne sur Atreus '''même si celui-ci n’a pas d’IPv4 publique'''.

<code>root@GOW:~# cat /etc/apache2/sites-available/muspellheim2.online.conf</code>
<syntaxhighlight lang="bash">
#Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online

ProxyPass / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
</VirtualHost>

# Partie HTTPS (port 443)
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName muspellheim2.online

SSLProxyEngine on
ProxyPreserveHost on

SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/KGandiPierre/GandiCert.pem

ProxyPass / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/

</VirtualHost>
</IfModule>
</syntaxhighlight>
📄 '''Fichier concerné : /etc/apache2/sites-available/muspellheim2.online.conf'''

Ce fichier configure un virtual host Apache2 pour le domaine muspellheim2.online, en mode proxy inverse (reverse proxy). Cela signifie que le serveur Apache2 reçoit les requêtes des utilisateurs et les redirige vers un autre serveur (Atreus), ici identifié par son adresse IPv6.

Le fichier gère deux protocoles :

- HTTP (port 80) — non sécurisé

- HTTPS (port 443) — sécurisé avec SSL/TLS

🔹 *VirtualHost :80 : Cela signifie que ce bloc s'applique à toutes les interfaces réseau, sur le port 80 (HTTP).

🔹 ServerName : Nom de domaine géré par ce virtual host. Apache redirigera les requêtes envoyées à muspellheim2.online.

🔹 ProxyPass / ... : Toutes les requêtes reçues sur / sont transmises à l'adresse IPv6 mentionnée. C’est là que tourne le vrai service web.

🔹 ProxyPassReverse : Permet de réécrire les en-têtes de redirection (comme les Location: envoyés par le serveur cible), pour que le client voit toujours muspellheim2.online au lieu de l’IP.

Atreus n’a pas d’IPv4 publique, donc il n’est pas directement joignable depuis Internet.

➜ GOW, qui a une IP publique, agit comme une porte d’entrée vers Atreus.

➜ C’est lui qui reçoit les requêtes extérieures et les redirige en interne vers le bon serveur.

On appelle ça un proxy inverse : le client ne sait pas que le site tourne ailleurs, tout passe par GOW.

===== '''Configuration d’Apache2 sur Atreus : le vrai serveur web – Site muspellheim2.online''' : =====
📄 Fichier : /etc/apache2/sites-available/000-muspellheim.conf

Ce fichier configure le serveur Apache2 sur la machine Atreus, qui héberge le véritable contenu du site muspellheim2.online. Il gère aussi bien les connexions HTTP que HTTPS.
<syntaxhighlight lang="bash">
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>
</syntaxhighlight>

🔹 *VirtualHost :80 : Écoute sur le port HTTP.

🔹 ServerName / ServerAlias :

ServerName : Nom principal du site.

ServerAlias : Permet aussi de répondre à www.muspellheim2.online.

🔹 RedirectPermanent / : Redirige tout le trafic HTTP vers HTTPS.

💡 '''Pourquoi ?'''

C’est une '''bonne pratique de sécurité''' : on force tous les visiteurs à utiliser une connexion chiffrée.

Partie HTTPS – Serveur principal

<syntaxhighlight lang="bash">
<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
...
</VirtualHost>
</syntaxhighlight>

Port 443 : Pour les connexions HTTPS (chiffrées).

🔹 ServerName / ServerAlias : Idem que pour le port 80

<syntaxhighlight lang="bash">
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
</syntaxhighlight>
🔹 Ces trois fichiers permettent au serveur d’offrir une connexion HTTPS sécurisée :

- .crt : certificat public du site.

- .key : clé privée (confidentielle).

- ChainFile : certificat intermédiaire (chaîne de certification, fourni par Gandi ici).

'''📝 Logs Apache'''
<syntaxhighlight lang="bash">
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</syntaxhighlight>

🔹 Gère la journalisation :

- error.log : erreurs serveur.

- access.log : toutes les requêtes reçues, avec IP, timestamp, etc.
<syntaxhighlight lang="bash">
# Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>

# Partie HTTPS (port 443)

<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
# SSLProxyEngine on
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</syntaxhighlight>Et comme '''Atreus est le vrai serveur''', et que '''GOW redirige tout vers lui''', ça permet à l’utilisateur de '''n’avoir aucune idée que deux serveurs travaillent ensemble derrière <code>muspellheim2.online</code>'''.
{| class="wikitable"
|+
![[Fichier:Schéma fonctionnel redirection vers Atreus.png|alt=Schéma fonctionnel redirection vers Atreus|345x345px]]
|}

== ✅ Vérification finale : est-ce que le site est en ligne et accessible ? ==
Une fois que '''tout est configuré''' (serveur web, DNS, DNSSEC, reverse proxy, certificats...), il ne reste plus qu'à '''tester si le site fonctionne bien'''.

=== 🧪 Méthode 1 : test en ligne de commande avec <code>curl</code> ===
<syntaxhighlight lang="ruby">
curl -4 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -4 muspellheim.png|alt=sortie curl -4 muspellheim|550x550px]]
|}
<syntaxhighlight lang="ruby">
curl -6 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -6 muspellheim.png|alt=sortie curl -6 muspellheim|502x502px]]
|}

=== 🌍 Méthode 2 : test dans un navigateur ===
Vous pouvez aussi tout simplement ouvrir votre navigateur préféré et taper l’adresse :<syntaxhighlight lang="ruby">
https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Projet fini Muspellheim.png|alt=Projet fini Muspellheim|1076x1076px]]
|}

* <code>curl -4</code> et <code>curl -6</code> permettent de '''vérifier si votre site répond en IPv4 et IPv6'''.

* Si vous n’avez pas de retour ou que la connexion échoue, vérifiez :
** votre '''config Apache'''
** vos '''règles de pare-feu'''
** vos '''enregistrements DNS'''
** et que vos '''certificats sont bien en place'''

Atelier SysRes SE4 2024/2025 E14

2026-01-20T15:57:58Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

'''Projet AARV LECOMTE et CASIMIRI'''

== INTRODUCTION ==
Dans le cadre de ce projet de virtualisation, j’ai déployé une infrastructure composée de '''deux machines dédiées aux services''' et d’une '''machine mandataire''', le tout orchestré à l’aide de '''Xen'''.

La machine '''Atreus''' joue un rôle central en assurant '''l’hébergement des services web''' et autres composants applicatifs. La machine '''GOW''' fait office de '''mandataire réseau''' : elle gère la '''connectivité vers l’extérieur''', que ce soit en '''IPv4 ou en IPv6''', et sert aussi de '''reverse proxy''' pour rediriger les requêtes vers les machines de service internes.

La '''deuxième machine de service''' appartient à Monsieur '''Antoine LECOMPTE''' et porte le nom de '''Kratos'''. Elle complète l’architecture et participe à l’ensemble des services distribués au sein de l’infrastructure.

<big>'''✉️ Petit mot pour les prochaines promotions'''</big>

Salut à vous les prochaines promos 👋

Dans ce document, j’ai essayé de vous expliquer au mieux les différentes étapes que j’ai traversées pour monter ce projet. Je me suis appuyé sur ce que j’ai compris moi-même au fil des TP, les cours des profs (qu’il faut vraiment relire, ils sont précieux), des ressources trouvées sur Internet, et je ne vais pas vous mentir… parfois un petit coup de main de certains LLM comme ChatGPT 👀 m’a bien aidé quand je bloquais.

Ce n’est pas un tutoriel parfait, mais plutôt un guide pour vous accompagner avec des explications techniques assez simples à comprendre (que je pense avoir compris surtout), même si vous n’avez encore jamais touché au réseau, à l’infra ou à un serveur web. L’objectif, c’est que vous puissiez prendre confiance, comprendre les bases, et réussir à faire tourner votre projet sans paniquer.

Je vous souhaite vraiment bon courage pour ce projet. C’est l’un des meilleurs moyens d’apprendre concrètement et de progresser à fond. N’hésitez pas à poser des questions à vos profs, ils sont là pour vous aider. Prenez le temps de relire vos cours tranquillement, et surtout, n’ayez pas peur de tester, de faire des erreurs, de casser et de recommencer (certains profs demande à ce qu'on casse les machines pour montrer qu'on cherche) : c’est comme ça qu’on apprend.

Si vous avez l'occasion de les consulter, je vous conseille vivement d'aller regarder les wikis de Madame EL BACHIRI, Monsieur TOURON et Monsieur DETREZ. Ils ont certaines informations en plus que moi sur tout ce qui va être configurations CISCO, OSPF et tout ce qui touche au physique (câbles, commutateurs).

En espérant que vous allez plus loin que nous sur ce projet ![[Fichier:Df -h.png|vignette]]

== CRÉATION MACHINES VIRTUELLES ==

Tout d'abord, nous devons configurer nos MV de services. Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Atreus --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
root@capbreton:~# xen-create-image --hostname=SE4.Kratos --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Atreus</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

Il faudra aussi créer des volumes logiques dédiés à des /var et /home pour chacune de nos VM.

Sur capbreton, les commandes sont :

lvcreate -L10G -nSE4.[NomdeVM].home virtual

lvcreate -L10G -nSE4.[NomdeVM].var virtual

celà va créer des volumes logiques dédiés aux paths /var et /home pour vos VM dans un dossier /dev/virtual.

à AUCUN moment vous devez écrire une ligne commençant par mkfs sur capbreton, vous risquez de tuer capbreton si vous le faites.

Pour initialiser les machines, nous devons exécuter ces commandes:

<syntaxhighlight lang="bash">
xen create /etc/xen/SE4.Atreus.cfg
xen create /etc/xen/SE4.Kratos.cfg
</syntaxhighlight>

Une fois les MV créées et en ligne, nous devons exécuter ces commandes pour les contrôler:
<syntaxhighlight lang="bash">
xen console SE4.Atreus
xen console SE4.Kratos
</syntaxhighlight>

Une fois le login "root" et le mdp (top secret) rentrés dans la console, nous sommes sur la VM et pouvons la contrôler comme un ordinateur avec un OS classique.
<syntaxhighlight lang="bash">
root@Atreus:~#
</syntaxhighlight>

== PARTIONING DES MV ==
Nous avons modifié les fichiers <code>/etc/xen/[Kratos][Atreus].cfg</code> pour attacher les partitions LVM aux machines :<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w',
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w',
]

</syntaxhighlight>Le paramètre <code>disk</code> définit les disques virtuels attachés à la machine virtuelle (domaine Xen).

Chaque élément du tableau suit la syntaxe :<syntaxhighlight lang="bash">
<type>:<source>,<cible>,<mode>
</syntaxhighlight>

* '''type :''' indique si le disque provient :
** d'un fichier (<code>file:</code>)
** d'un périphérique physique réel (<code>phy:</code>).
* '''source :''' chemin complet vers l'image disque ou vers le périphérique physique sur la machine hôte.
* '''cible :''' nom du périphérique vu par la machine virtuelle (exemple : <code>xvda</code>, <code>xvdb</code>, etc.).

* '''mode :''' type d'accès au disque (<code>r</code> en lecture seule, <code>w</code> en lecture-écriture).

==== DISQUE VIRTUEL PRINCIPAL : ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w'
</syntaxhighlight>

* '''Type''' : <code>file</code> (stockage basé sur un fichier-image disque).
* '''Source''' : <code>/usr/local/xen/domains/SE4.Atreus/disk.img</code> (fichier contenant le disque virtuel).
* '''Cible''' : <code>xvda2</code> (deuxième partition du disque virtuel <code>xvda</code> visible depuis la MV).
* '''Mode''' : <code>w</code> (lecture-écriture).

Ce disque correspond à la racine (<code>/</code>) du système de fichiers Linux de la MV.

==== DISQUE VIRTUEL SWAP ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w'

</syntaxhighlight>

* '''Type :''' <code>file</code> → Image disque stockée dans un fichier.
* '''Source :''' <code>/usr/local/xen/domains/SE4.Atreus/swap.img</code> → Chemin de l'image disque swap.
* '''Cible :''' <code>xvda1</code> → Première partition du disque virtuel <code>xvda</code>.

==== DISQUE PHYSIQUE POUR /home ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Un périphérique physique (généralement une partition réelle ou un volume logique LVM).
* '''Source :''' <code>/dev/virtual/SE4.Atreus.home</code> → Partition ou volume logique physique sur l'hôte. L'hôte étant le disque dur de capbreton.
* '''Cible :''' <code>xvda3</code> → Troisième partition du disque virtuel <code>xvda</code>.

Cette partition dédiée permet d’isoler le répertoire <code>/home</code>, facilitant ainsi la gestion des données utilisateur séparément du système.

==== DISQUE PHYSIQUE POUR /var ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Périphérique physique.
* '''Source :''' <code>/dev/virtual/SE4.Atreus.var</code> → Partition physique ou volume logique dédié sur l'hôte.
* '''Cible :''' <code>xvdb1</code> → Première partition du second disque virtuel (<code>xvdb</code>).

Cette partition est dédiée au répertoire <code>/var</code>, où sont stockés les journaux (logs), les bases de données, les fichiers temporaires, etc. Cette séparation permet une meilleure gestion des données systèmes dynamiques.

Pour le fichier /var<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
</syntaxhighlight>Pour le fichier /home<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

==== DÉMARRAGE AUTOMATIQUE DU MONTAGE ====
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|Fichier_fstab|centré]]
|}

== CONFIGURATION RÉSEAU ==

Chaque machine dispose d'une adresse IPv4 fixe sur un réseau privé, ainsi que d'une adresse IPv6 configurée automatiquement.

Nous modifions la configuration réseau dans <code>/etc/network/interfaces</code> de la machine mandataire. Ensuite, nous ajustons le fichier de configuration de la machine virtuelle afin qu'elle possède deux interfaces : la première permet de communiquer avec le routeur mis en place par nos collègues, tandis que la seconde est connectée au pont réseau que nous avons créé pour l’intercommunication entre nos trois machines.

=== MACHINE MANDATAIRE ===
<syntaxhighlight lang="bash">
name = 'SE4.GOW'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:E7:C5:1A,bridge=bifrost',
'mac=00:16:3E:E7:C5:1B,bridge=SE4' ]

</syntaxhighlight>Le pont nommé '''"bifrost"''', défini dans le fichier de configuration de notre machine virtuelle mandataire, sert à '''relier virtuellement les trois machines''' entre elles.

Pour que des machines puissent communiquer, elles doivent être sur le '''même réseau'''. Ici, c’est un '''VIF (Virtual Interface)''' qui joue ce rôle : c’est une sorte de '''commutateur virtuel''' (ou switch virtuel).

Un '''commutateur''', c’est ce que vous imaginez peut-être comme une grosse boîte avec plein de câbles et de lumières clignotantes, qu’on trouve dans les salles serveurs.

Dans notre cas, tout ça est '''simulé dans la machine virtuelle''', donc pas de câbles physiques : la communication se fait via la '''carte réseau virtuelle''' attribuée à chaque machine.

Après avoir redémarré la machine, l’interface réseau est visible dans le fichier <code>/etc/network/interfaces</code>. On peut modifier ce fichier pour attribuer une adresse IP fixe à la machine GOW.<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.3.1/24
# post-up ethtool -K eth0 tx off

iface eth0 inet6 auto

auto eth1
iface eth1 inet static
address 193.48.57.172/27
gateway 193.48.57.161
</syntaxhighlight>

=== MACHINE DE SERVICES ===
/etc/network/interfaces de la machine SE4.Atreus qui permet de lié les Interfaces de la MV avec ses VIF pour communiquer en IPv6 avec Internet et IPv4 avec la machine mandataire <syntaxhighlight lang="bash">
# The loopback network interface
auto lo
iface lo inet loopback

auto eth0

iface eth0 inet6 auto

iface eth0 inet static
address 192.168.3.2/24
gateway 192.168.3.1

auto eth1
iface eth1 inet6 auto

</syntaxhighlight>On configure la machine mandataire comme une passerelle (gateway) en IPv4. En IPv6, l’adresse est attribuée automatiquement grâce au bridge SE4.

Une fois que chaque machine peut être pingée par les autres et qu’elles arrivent à envoyer des requêtes vers Internet, on peut passer à l’étape suivante.
{| class="wikitable"
|+
![[Fichier:Interfacekratos.png|alt=Interfacekratos|Interfacekratos|centré|vignette|470x470px]]
! rowspan="2" |[[Fichier:IpaAtreusIp6Ip4.png|vignette|546x546px|ip a de la machine SE4.Atreus|centré]]
|-
|[[Fichier:PingEntre2VM.png|alt=PingEntre2VM|PingEntre2VM|centré|vignette|986x986px]]
|}

==== SSH ====
On active le SSH avec la ligne <code>PermitRootLogin yes</code> dans le fichier <code>/etc/ssh/sshd_config</code>sur les 3 machines, on peut accéder à la mandataire avec son adresse IPv4 routée, pour les machines de service on utilise l'adresse en IPv6

===== 🛡️ Sécurisation SSH avec Fail2Ban =====
📄 '''Fichier :''' <code>/etc/fail2ban/jail.local</code>

Ce fichier contient les règles locales de '''Fail2Ban''', un outil qui surveille les logs système et '''bannit temporairement les adresses IP''' en cas de comportement suspect (comme des tentatives de connexion SSH répétées avec un mauvais mot de passe).<syntaxhighlight lang="vim">
[sshd]
enable = true
port = ssh
filter = sshd
maxretry = 3
findtime = 300
bantime = 600
</syntaxhighlight>
{| class="wikitable"
!Paramètre
!Explication
|-
|<code>enable = true</code>
|Active la surveillance de SSH.
|-
|<code>port = ssh</code>
|Surveille le port SSH.
|-
|<code>filter = sshd</code>
|Utilise le '''filtre prédéfini''' <code>sshd.conf</code>, qui détecte les échecs de connexion dans les logs.
|-
|<code>maxretry = 3</code>
|'''3 tentatives''' ratées autorisées avant bannissement.
|-
|<code>findtime = 300</code>
|La fenêtre de détection : '''5 minutes''' pour accumuler ces 3 tentatives.
|-
|<code>bantime = 600</code>
|Durée de bannissement : '''10 minutes''' (600 secondes).
|}

=== CONFIGURATION DNS ===
Rappel : Qu’est-ce qu’un serveur DNS ?

Vu en cours avec Monsieur redon et Monsieur Vantroys, DNS veut dire '''Domain Name System'''. C’est un '''service''' qui fait la conversion entre un '''nom de domaine''' (comme <code>muspellheim2.online</code>) et une '''adresse IP''' (comme <code>193.48.57.172</code>), que les machines utilisent pour communiquer. Ce sont les pages jaunes des serveurs et IP d'Internet. On ne connait pas l'adresse IP de tous les sites. On ne connait que les noms. Quand on écrit netflix.com sur Internet, on interroge les serveurs DNS pour qu"il puisse nous rediriger vers l'adresse IP associé au nom "netflix.com".

==== 🌍 Fichier de zone DNS : <code>muspellheim2.online</code> ====
📄 '''Fichier :''' <code>/etc/bind/zones/muspellheim2.online/muspellheim2.zone</code>

Ce fichier définit tous les enregistrements DNS pour le domaine <code>muspellheim2.online</code>.

Il est utilisé par le serveur BIND '''maître''' (primary) pour répondre aux requêtes DNS.

===== 🧾 En-tête : SOA (Start Of Authority) =====
<syntaxhighlight lang="vim">
@ IN SOA ns.muspellheim2.online. admin.muspellheim2.online. (
3609 ; Numéro de version
21600 ; Rafraîchissement (6h)
3600 ; Re-tentative (1h)
2592000 ; Expiration (30j)
86400 ) ; Cache négatif (24h)
</syntaxhighlight>🔹 <code>@</code> : représente le domaine racine (<code>muspellheim2.online.</code> ici)

🔹 <code>SOA</code> : Spécifie '''l’autorité principale''' de la zone. Ici :

* Serveur DNS maître : <code>ns.muspellheim2.online.</code>
* Contact admin : <code>admin@muspellheim2.online</code> (le point remplace le <code>@</code>)
A chaque modification de ce fichier, il faut incrémenter le numéro de version de +1.

===== 📡 Serveurs DNS (NS) =====
<syntaxhighlight lang="vim">
@ IN NS ns.muspellheim2.online.
@ IN NS ns.jotunheim2.tech.
</syntaxhighlight>🔹 Ces lignes déclarent les serveurs DNS autoritaires pour cette zone :

- ns.muspellheim2.online. (le maître)

- ns.jotunheim2.tech. (un secondaire)

===== 🧭 Enregistrements de type A / AAAA =====
<syntaxhighlight lang="vim">
ns IN A 193.48.57.172
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
@ IN A 193.48.57.172
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
</syntaxhighlight>🔹 '''A''' : Adresse IPv4

🔹 '''AAAA''' : Adresse IPv6

Ces enregistrements associent :

* <code>ns.muspellheim2.online</code> à ses adresses IP (serveur DNS)
* <code>muspellheim2.online</code> lui-même à la même machine (le site est hébergé dessus)

===== 🔗 Alias (CNAME) =====
<syntaxhighlight lang="vim">
www IN CNAME muspellheim2.online.
</syntaxhighlight>🔹 Les requêtes pour <code>www.muspellheim2.online</code> seront redirigées vers <code>muspellheim2.online</code>.

Cela évite de dupliquer les enregistrements A/AAAA pour <code>www</code>.

===== 🔐 DNS Validation via Digicert =====
<syntaxhighlight lang="vim">
_gay4mlana6awxk71vd9gjuzdkzfism2.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
_gay4mlana6awxk71vd9gjuzdkzfism2.www.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
</syntaxhighlight>🔹 Ces lignes servent à '''valider le domaine''' auprès de l’autorité de certification (Digicert) pour obtenir un certificat SSL.

🔹 <code>dcv.digicert.com.</code> est le serveur que Digicert utilise pour vérifier la possession du domaine (via un CNAME dynamique généré).

On peut ensuite vérifier la syntaxe de notre '''fichier de zone DNS''' avec l’outil <code>named-checkzone</code>.

Cet outil nous aide à repérer les erreurs dans l’écriture du fichier, un peu comme '''Microsoft Word souligne les fautes de grammaire ou de syntaxe''' dans un texte.

Par exemple :<syntaxhighlight lang="ruby">
root@Atreus:~# named-checkzone muspellheim2.online /etc/bind/zones/muspellheim2.online/muspellheim2.zone
zone muspellheim2.online/IN: loaded serial 3609
OK
</syntaxhighlight>Ici, le message '''"OK"''' signifie que le fichier est bien écrit et ne contient pas d’erreurs de syntaxe.

Juste à noter : <code>named-checkzone</code> vérifie uniquement la syntaxe et la structure logique du fichier (comme la présence d’un SOA, la validité des enregistrements, etc.), '''mais pas si les adresses IP ou noms existent réellement'''.

Une fois que tout est correctement configuré, '''n’oubliez pas de redémarrer les services <code>named</code> et <code>bind</code>'''.

Cela permet à ces services de '''prendre en compte les nouvelles modifications''' que vous avez apportées dans les fichiers de configuration.

Il faut aussi '''attribuer les bons droits d'accès aux fichiers''', pour que <code>bind</code> puisse les lire correctement. Sinon, il risque de ne pas fonctionner comme prévu.<syntaxhighlight lang="ruby">
chown bind:bind /etc/bind/zones/muspellheim2.online/muspellheim2.zone
chmod 644 /etc/bind/zones/muspellheim2.online/muspellheim2.zone

chown bind:bind /etc/bind/named.conf.local
chmod 644 /etc/bind/named.conf.local
</syntaxhighlight>

* <code>chown</code> permet de '''donner la propriété des fichiers à l’utilisateur et au groupe <code>bind</code>'''.

* <code>chmod 644</code> donne les '''droits de lecture au service <code>bind</code>''', tout en empêchant d'autres utilisateurs non privilégiés de les modifier.

===== Vérification avec l'outil "dig" =====
On peut '''vérifier que notre serveur DNS fonctionne correctement''' en utilisant la commande <code>dig</code>.

C’est un outil qui envoie une requête DNS pour demander l’adresse IP d’un nom de domaine, et affiche la réponse complète reçue du serveur.

Par exemple, ici on interroge notre propre serveur DNS local (<code>@localhost</code>) pour vérifier s’il connaît le domaine <code>muspellheim2.online</code> :<syntaxhighlight lang="vim">
root@Atreus:~# dig @localhost muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="vim">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight>Cela signifie que la requête s’est bien déroulée, et qu’il n’y a '''pas d’erreur''' dans le fichier de zone.<syntaxhighlight lang="vim">
;; ANSWER SECTION:
muspellheim2.online. 200 IN A 193.48.57.172
</syntaxhighlight>
Le serveur DNS a bien répondu avec l’adresse IP '''193.48.57.172''', donc '''la zone est bien configurée et active'''.Ce test permet de s'assurer que '''le nom de domaine est bien reconnu et renvoie vers la bonne adresse IP'''.

On peut aussi tester depuis '''une autre machine virtuelle''', pour voir si '''le domaine est connu à l'extérieur''', par exemple par '''le DNS public de Google (<code>8.8.8.8</code>)'''.

Pour cela, on utilise <code>dig</code> en spécifiant l’IP du serveur DNS qu’on veut interroger :<syntaxhighlight lang="ruby">
root@GOW:~# dig @8.8.8.8 muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ANSWER SECTION:
muspellheim2.online. 189 IN A 193.48.57.172
</syntaxhighlight>Google a répondu avec l’adresse IP '''193.48.57.172''', ce qui prouve que '''notre domaine est maintenant reconnu depuis l’extérieur'''.
🧠 '''Petit point d’attention''' : Si tu n’as pas volontairement '''enregistré le domaine <code>muspellheim2.online</code> sur Internet''' (via un registrar, ici c'est Gandi), alors :

* soit '''ton environnement de test est spécial''' (ex : en école avec une infra réseau propre et un DNS intermédiaire qui communique avec Google),
* soit '''le domaine a réellement été enregistré publiquement''', auquel cas tu partages un vrai domaine avec d'autres (et ça peut poser des conflits si tu voulais juste faire des tests en local).

==== REGISTRAR ET PROPAGATION DNS ====
Pour rendre notre '''serveur DNS opérationnel et accessible depuis Internet''', on se rend sur le site du '''registrar''' (dans notre cas : '''Gandi'''), qui est l’organisme auprès duquel on a acheté notre '''nom de domaine'''.

Dans l’onglet '''"Nameserver"''', on ajoute un '''Glue Record'''.

Un Glue Record sert à '''lier notre nom de domaine à nos propres serveurs DNS''', en indiquant leurs adresses IP :

* l’adresse '''IPv4''' de la '''machine mandataire''' (notre DNS principal),
* les adresses '''IPv6''' des '''machines de service''', si on veut un fonctionnement complet en IPv6.

Ensuite, on '''remplace les serveurs de noms (Nameservers) par les nôtres''', c’est-à-dire notre propre serveur DNS.

Cela fait de notre serveur '''le référent officiel pour la gestion des noms de domaine''' associés à <code>muspellheim2.online</code>.

🧠 Pourquoi on fait tout ça ?

Eh bien, comme on l’a vu avec la commande :<syntaxhighlight lang="vim">
dig @8.8.8.8 muspellheim2.online
</syntaxhighlight>Google a pu répondre car '''notre domaine est désormais public''' !

Si on n’avait pas fait cette configuration chez Gandi, personne sur Internet (hors de notre réseau) n’aurait pu le voir.

🌐 Pour faire simple :

En ajoutant un Glue Record et en configurant nos Nameservers, on annonce notre domaine au monde entier.

Cela permet à n’importe quel ordinateur sur Internet de retrouver l’adresse IP de notre serveur — et donc d’afficher notre site ou d’accéder à nos services.
{| class="wikitable"
|+
![[Fichier:NameserverGandi.png|gauche|NameserverGandi Pierre CASIMIRI muspellheim2.online]]
|-
|[[Fichier:GlueRecordGandi.png|gauche|2305x2305px|GlueRecordGandi Pierre CASIMIRI muspellheim2.online]]
|}

==== DIFFUSION DE NOTRE SUPERBE SERVEUR AU MONDE ====

🌍 Une fois le Glue Record ajouté… on attend un peu que le monde entier soit au courant !

Une fois qu’on a :

* ajouté les '''Glue Records''',
* remplacé les '''Nameservers''' dans le registrar (comme Gandi),

eh bien il faut patienter un peu. Pourquoi ? Parce que '''les informations DNS doivent se propager''' à travers le monde. Cette phase peut prendre '''quelques heures à quelques jours''', selon les serveurs.

🛰️ Comment savoir si c’est bien propagé ?

Il existe des sites comme '''DNSChecker.org''' qui permettent de voir si votre nom de domaine est '''bien visible depuis plusieurs endroits de la planète'''.

📌 Exemple : <code>muspellheim2.online</code>

Sur DNSChecker, vous entrez votre domaine et choisissez le type d'enregistrement que vous voulez vérifier, par exemple :
{| class="wikitable"
!Type
!Ce que ça affiche
|-
|<code>A</code>
|Adresse IPv4 liée au domaine
|-
|<code>AAAA</code>
|Adresse IPv6
|-
|<code>NS</code>
|Liste des Nameservers en charge du domaine
|-
|<code>CNAME</code>
|Alias d’un domaine vers un autre
|-
|<code>DNSKEY</code>
|Clés publiques DNSSEC (on y reviendra plus tard)
|}
{| class="wikitable"
|+
![[Fichier:DNSChecker1.png|gauche|768x768px|DNSChecker1]]
![[Fichier:DNSChecker3.png|alt=DNSChecker3|bordure|687x687px]]
! rowspan="2" |[[Fichier:DNSChecker5.png|alt=DNSChecker5|655x655px]]
|-
|[[Fichier:DNSChecker2.png|alt=DNSChecker2|bordure|768x768px]]
|[[Fichier:DNSChecker4.png|alt=DNSChecker4|701x701px]]
|}

* ✅ '''Check vert''' : ça veut dire que ce serveur DNS a bien reçu et reconnu ton info.
* 🟡 '''Check en attente''' : propagation en cours ou serveur lent.
* ❌ '''Check rouge''' : info non encore propagée à ce serveur ou pas propagée car les certificats ne sont pas acceptés par ses serveurs DNS.

==== DNSSEC sur Atreus ====

===== 🧭 Configuration DNS sur le serveur BIND – <code>named.conf.local</code> =====
📄 Fichier : <code>/etc/bind/named.conf.local</code>

Ce fichier contient la déclaration des zones DNS locales pour le serveur BIND.

On y définit ici :

-Une zone primaires (gérées en local)

-Une zone secondaire (copiée depuis un autre serveur)

Et une politique DNSSEC.<syntaxhighlight lang="bash">
cat /etc/bind/named.conf.local
</syntaxhighlight><syntaxhighlight lang="vim">
zone "muspellheim2.online" {

type primary;
file "/etc/bind/zones/muspellheim2.online/muspellheim2.zone";

allow-transfer{2001:660:4401:60a0:216:3eff:fee7:c51b;

2001:660:4401:60a0:216:3eff:fed0:9ab0;}; // filtrage des secondaires

also-notify{2001:660:4401:60a0:216:3eff:fee7:c51b;}; // pour les secondaires vicieux notify yes; // notification des secondaires
key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes; };

zone "jotunheim2.tech"{

type slave;
file "/etc/bind/jotunheim2.tech";
primaries{2001:660:4401:60a0:216:3eff:fed0:9ab0;};

};

dnssec-policy "dnspol" {

keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;

};
</syntaxhighlight>

🔹 '''type primary''' : Ce serveur est '''l'autorité principale''' pour la zone.

🔹 '''file''' : Chemin du fichier de zone contenant tous les enregistrements DNS (<code>A</code>, <code>AAAA</code>, <code>NS</code>, etc.).

🔹 '''allow-transfer''' : Liste des serveurs secondaires '''autorisés à faire un transfert de zone''' (AXFR). Cela sécurise l’accès aux données DNS.

🔹 '''also-notify''' : Force l’envoi de notifications DNS vers certains secondaires, même s’ils ne sont pas configurés comme secondaires officiels.

🔹 '''notify yes''' : Active les notifications automatiques des serveurs secondaires lorsqu’une mise à jour de la zone est faite.

🔹 '''dnssec-policy "dnspol"''' : Active '''DNSSEC''' avec une politique personnalisée.

🔹 '''inline-signing yes''' : Active la '''signature automatique''' de la zone par BIND.

====== Zone secondaire : <code>jotunheim2.tech</code> ======
<syntaxhighlight lang="vim">
zone "jotunheim2.tech" {
type slave;
file "/etc/bind/jotunheim2.tech";
primaries { 2001:660:4401:60a0:216:3eff:fed0:9ab0; };
};
</syntaxhighlight>🔹 '''type slave''' : Ce serveur récupère les données de zone depuis un '''serveur primaire distant'''.

🔹 '''primaries { ... }''' : Adresse du serveur maître à interroger pour obtenir la zone.

🔹 '''file''' : Emplacement local où la zone est stockée après transfert.

====== 🔐 Politique DNSSEC : <code>"dnspol"</code> ======
<syntaxhighlight lang="vim">
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>🔹 '''ksk''' : Key Signing Key (clé qui signe les autres clés DNS).

🔹 '''zsk''' : Zone Signing Key (clé qui signe les enregistrements DNS).

🔹 '''algorithm 13''' : Il s’agit d’'''ECDSA P-256 with SHA-256''' (<nowiki>RFC 6605</nowiki>), algorithme sécurisé et moderne.

🔹 '''nsec3param''' : Indique que '''NSEC3''' est utilisé (permet de sécuriser les réponses "ce nom n'existe pas" sans divulguer d'autres noms).

✅ Les deux clés sont générées dans le répertoire <code>key-directory</code>, ont une durée de vie '''illimitée''', et utilisent '''l’algorithme 13''' (ED25519, rapide et sécurisé).

✅ <code>nsec3param</code> : active la protection contre l’énumération de noms (empêche de “scanner” une zone DNS facilement).

Pour que '''DNSSEC fonctionne correctement''', il faut '''déclarer la clé KSK''' (Key Signing Key) chez votre '''registrar''', ici '''Gandi'''.

Sur votre machine, les clés sont générées automatiquement dans le répertoire (key-directory dans le fichier <code>/etc/bind/named.conf.local)</code><syntaxhighlight lang="bash">
/etc/bind/keys/
</syntaxhighlight>
Par exemple, vous pouvez voir des fichiers comme ceux-ci :<syntaxhighlight lang="ruby">
Kmuspellheim2.online.+013+03837.key
Kmuspellheim2.online.+013+03837.private
Kmuspellheim2.online.+013+03837.state

Kmuspellheim2.online.+013+14053.key
Kmuspellheim2.online.+013+14053.private
Kmuspellheim2.online.+013+14053.state

</syntaxhighlight>🗝️ Les fichiers importants :

* Les fichiers '''<code>.key</code>''' contiennent la '''clé publique''' (celle que vous devez copier/coller sur Gandi).
* Les fichiers '''<code>.private</code>''' contiennent la '''clé privée''' (à '''ne jamais partager''' !).
* Les fichiers '''<code>.state</code>''' servent à BIND pour gérer l’état et la durée de validité des clés.

Pour éviter tout problème avec la validation DNSSEC, pensez à mettre les deux fichiers .key dans l’interface de Gandi, dans la partie DNSSEC de votre domaine.

💡 En faisant cela, vous reliez votre zone DNS signée à la chaîne de confiance globale d’Internet : tout le monde pourra alors vérifier que vos données DNS sont authentiques et non modifiées.

Une fois la configuration DNSSEC en place, on peut tester si '''tout fonctionne correctement''' avec le site '''DNSViz'''.

Ce site permet d’'''analyser les signatures DNSSEC''' et de vérifier si la '''chaîne de confiance''' est bien construite du début à la fin (depuis la racine DNS jusqu’à votre zone).
{| class="wikitable"
|+
![[Fichier:DNSviz Muspellheim2.online.png|gauche|1129x1129px|DNSviz Muspellheim2.online]]
|}
Le graphe montre '''la chaîne de confiance DNSSEC''' :

* On part de la '''racine DNS''' (<code>.</code>), qui délègue au TLD <code>.online</code>.
* <code>.online</code> contient une clé DS qui fait le lien avec '''ton domaine''' <code>muspellheim2.online</code>.
* Ensuite, ton domaine possède ses propres clés (DNSKEY), qui signent toutes les infos de ta zone (A, NS, AAAA, etc.)

✅ Tout est "Secure" sur le graphe → l'''a configuration DNSSEC est correcte et vérifiée''' !
== APACHE ==
===== '''Configuration d’Apache sur GOW''' : =====
Apache va '''écouter les requêtes envoyées à muspellheim2.online''', puis les '''rediriger vers un autre serveur''' (ici Atreus), via son '''adresse IPv6'''.

Cela permet d’accéder à un site web qui tourne sur Atreus '''même si celui-ci n’a pas d’IPv4 publique'''.

<code>root@GOW:~# cat /etc/apache2/sites-available/muspellheim2.online.conf</code>
<syntaxhighlight lang="bash">
#Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online

ProxyPass / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
</VirtualHost>

# Partie HTTPS (port 443)
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName muspellheim2.online

SSLProxyEngine on
ProxyPreserveHost on

SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/KGandiPierre/GandiCert.pem

ProxyPass / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/

</VirtualHost>
</IfModule>
</syntaxhighlight>
📄 '''Fichier concerné : /etc/apache2/sites-available/muspellheim2.online.conf'''

Ce fichier configure un virtual host Apache2 pour le domaine muspellheim2.online, en mode proxy inverse (reverse proxy). Cela signifie que le serveur Apache2 reçoit les requêtes des utilisateurs et les redirige vers un autre serveur (Atreus), ici identifié par son adresse IPv6.

Le fichier gère deux protocoles :

- HTTP (port 80) — non sécurisé

- HTTPS (port 443) — sécurisé avec SSL/TLS

🔹 *VirtualHost :80 : Cela signifie que ce bloc s'applique à toutes les interfaces réseau, sur le port 80 (HTTP).

🔹 ServerName : Nom de domaine géré par ce virtual host. Apache redirigera les requêtes envoyées à muspellheim2.online.

🔹 ProxyPass / ... : Toutes les requêtes reçues sur / sont transmises à l'adresse IPv6 mentionnée. C’est là que tourne le vrai service web.

🔹 ProxyPassReverse : Permet de réécrire les en-têtes de redirection (comme les Location: envoyés par le serveur cible), pour que le client voit toujours muspellheim2.online au lieu de l’IP.

Atreus n’a pas d’IPv4 publique, donc il n’est pas directement joignable depuis Internet.

➜ GOW, qui a une IP publique, agit comme une porte d’entrée vers Atreus.

➜ C’est lui qui reçoit les requêtes extérieures et les redirige en interne vers le bon serveur.

On appelle ça un proxy inverse : le client ne sait pas que le site tourne ailleurs, tout passe par GOW.

===== '''Configuration d’Apache2 sur Atreus : le vrai serveur web – Site muspellheim2.online''' : =====
📄 Fichier : /etc/apache2/sites-available/000-muspellheim.conf

Ce fichier configure le serveur Apache2 sur la machine Atreus, qui héberge le véritable contenu du site muspellheim2.online. Il gère aussi bien les connexions HTTP que HTTPS.
<syntaxhighlight lang="bash">
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>
</syntaxhighlight>

🔹 *VirtualHost :80 : Écoute sur le port HTTP.

🔹 ServerName / ServerAlias :

ServerName : Nom principal du site.

ServerAlias : Permet aussi de répondre à www.muspellheim2.online.

🔹 RedirectPermanent / : Redirige tout le trafic HTTP vers HTTPS.

💡 '''Pourquoi ?'''

C’est une '''bonne pratique de sécurité''' : on force tous les visiteurs à utiliser une connexion chiffrée.

Partie HTTPS – Serveur principal

<syntaxhighlight lang="bash">
<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
...
</VirtualHost>
</syntaxhighlight>

Port 443 : Pour les connexions HTTPS (chiffrées).

🔹 ServerName / ServerAlias : Idem que pour le port 80

<syntaxhighlight lang="bash">
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
</syntaxhighlight>
🔹 Ces trois fichiers permettent au serveur d’offrir une connexion HTTPS sécurisée :

- .crt : certificat public du site.

- .key : clé privée (confidentielle).

- ChainFile : certificat intermédiaire (chaîne de certification, fourni par Gandi ici).

'''📝 Logs Apache'''
<syntaxhighlight lang="bash">
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</syntaxhighlight>

🔹 Gère la journalisation :

- error.log : erreurs serveur.

- access.log : toutes les requêtes reçues, avec IP, timestamp, etc.
<syntaxhighlight lang="bash">
# Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>

# Partie HTTPS (port 443)

<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
# SSLProxyEngine on
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</syntaxhighlight>Et comme '''Atreus est le vrai serveur''', et que '''GOW redirige tout vers lui''', ça permet à l’utilisateur de '''n’avoir aucune idée que deux serveurs travaillent ensemble derrière <code>muspellheim2.online</code>'''.
{| class="wikitable"
|+
![[Fichier:Schéma fonctionnel redirection vers Atreus.png|alt=Schéma fonctionnel redirection vers Atreus|345x345px]]
|}

== ✅ Vérification finale : est-ce que le site est en ligne et accessible ? ==
Une fois que '''tout est configuré''' (serveur web, DNS, DNSSEC, reverse proxy, certificats...), il ne reste plus qu'à '''tester si le site fonctionne bien'''.

=== 🧪 Méthode 1 : test en ligne de commande avec <code>curl</code> ===
<syntaxhighlight lang="ruby">
curl -4 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -4 muspellheim.png|alt=sortie curl -4 muspellheim|550x550px]]
|}
<syntaxhighlight lang="ruby">
curl -6 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -6 muspellheim.png|alt=sortie curl -6 muspellheim|502x502px]]
|}

=== 🌍 Méthode 2 : test dans un navigateur ===
Vous pouvez aussi tout simplement ouvrir votre navigateur préféré et taper l’adresse :<syntaxhighlight lang="ruby">
https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Projet fini Muspellheim.png|alt=Projet fini Muspellheim|1076x1076px]]
|}

* <code>curl -4</code> et <code>curl -6</code> permettent de '''vérifier si votre site répond en IPv4 et IPv6'''.

* Si vous n’avez pas de retour ou que la connexion échoue, vérifiez :
** votre '''config Apache'''
** vos '''règles de pare-feu'''
** vos '''enregistrements DNS'''
** et que vos '''certificats sont bien en place'''

SE4 IdO sécurité système/réseau 2025/2026

2026-01-20T15:08:40Z

Pcasimir : /* Répartition des binômes pour les travaux pratiques "administration système et réseau" */

Atelier SysRes SE4 2024/2025 E14

2026-01-20T13:46:22Z

Pcasimir : /* CRÉATION MACHINES VIRTUELLES */

'''Projet AARV LECOMTE et CASIMIRI'''

== INTRODUCTION ==
Dans le cadre de ce projet de virtualisation, j’ai déployé une infrastructure composée de '''deux machines dédiées aux services''' et d’une '''machine mandataire''', le tout orchestré à l’aide de '''Xen'''.

La machine '''Atreus''' joue un rôle central en assurant '''l’hébergement des services web''' et autres composants applicatifs. La machine '''GOW''' fait office de '''mandataire réseau''' : elle gère la '''connectivité vers l’extérieur''', que ce soit en '''IPv4 ou en IPv6''', et sert aussi de '''reverse proxy''' pour rediriger les requêtes vers les machines de service internes.

La '''deuxième machine de service''' appartient à Monsieur '''Antoine LECOMPTE''' et porte le nom de '''Kratos'''. Elle complète l’architecture et participe à l’ensemble des services distribués au sein de l’infrastructure.

<big>'''✉️ Petit mot pour les prochaines promotions'''</big>

Salut à vous les prochaines promos 👋

Dans ce document, j’ai essayé de vous expliquer au mieux les différentes étapes que j’ai traversées pour monter ce projet. Je me suis appuyé sur ce que j’ai compris moi-même au fil des TP, les cours des profs (qu’il faut vraiment relire, ils sont précieux), des ressources trouvées sur Internet, et je ne vais pas vous mentir… parfois un petit coup de main de certains LLM comme ChatGPT 👀 m’a bien aidé quand je bloquais.

Ce n’est pas un tutoriel parfait, mais plutôt un guide pour vous accompagner avec des explications techniques assez simples à comprendre (que je pense avoir compris surtout), même si vous n’avez encore jamais touché au réseau, à l’infra ou à un serveur web. L’objectif, c’est que vous puissiez prendre confiance, comprendre les bases, et réussir à faire tourner votre projet sans paniquer.

Je vous souhaite vraiment bon courage pour ce projet. C’est l’un des meilleurs moyens d’apprendre concrètement et de progresser à fond. N’hésitez pas à poser des questions à vos profs, ils sont là pour vous aider. Prenez le temps de relire vos cours tranquillement, et surtout, n’ayez pas peur de tester, de faire des erreurs, de casser et de recommencer (certains profs demande à ce qu'on casse les machines pour montrer qu'on cherche) : c’est comme ça qu’on apprend.

Si vous avez l'occasion de les consulter, je vous conseille vivement d'aller regarder les wikis de Madame EL BACHIRI, Monsieur TOURON et Monsieur DETREZ. Ils ont certaines informations en plus que moi sur tout ce qui va être configurations CISCO, OSPF et tout ce qui touche au physique (câbles, commutateurs).

En espérant que vous allez plus loin que nous sur ce projet ![[Fichier:Df -h.png|vignette]]

== CRÉATION MACHINES VIRTUELLES ==

Tout d'abord, nous devons configurer nos MV de services. Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

<syntaxhighlight lang="bash">
root@capbreton:~# xen-create-image --hostname=SE4.Atreus --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
root@capbreton:~# xen-create-image --hostname=SE4.Kratos --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>

* '''<code>xen-create-image</code>''' : Commande permettant de créer une nouvelle machine virtuelle Xen
* '''<code>--hostname=SE4.Atreus</code>''' : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera <code>SE4.Atreus</code>.
* '''<code>--dhcp</code>''' : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire.
* '''<code>--bridge=bifrost</code>''' : Précise l'utilisation du pont réseau nommé <code>bifrost</code> pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
* '''<code>--dir=/usr/local/xen</code>''' : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier <code>/usr/local/xen</code>.
* '''<code>--size=10GB</code>''' : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera <code>10 Go</code>.
* '''<code>--dist=daedalus</code>''' : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle <code>daedalus</code> pour Debian.

* '''<code>--memory=2048M</code>''' : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura <code>2048 Mo</code> (soit 2 Go) de RAM.

Il faudra aussi créer des volumes logiques dédiés à des /var et /home pour chacune de nos VM.

Pour initialiser les machines, nous devons exécuter ces commandes:

<syntaxhighlight lang="bash">
xen create /etc/xen/SE4.Atreus.cfg
xen create /etc/xen/SE4.Kratos.cfg
</syntaxhighlight>

Une fois les MV créées et en ligne, nous devons exécuter ces commandes pour les contrôler:
<syntaxhighlight lang="bash">
xen console SE4.Atreus
xen console SE4.Kratos
</syntaxhighlight>

Une fois le login "root" et le mdp (top secret) rentrés dans la console, nous sommes sur la VM et pouvons la contrôler comme un ordinateur avec un OS classique.
<syntaxhighlight lang="bash">
root@Atreus:~#
</syntaxhighlight>

== PARTIONING DES MV ==
Nous avons modifié les fichiers <code>/etc/xen/[Kratos][Atreus].cfg</code> pour attacher les partitions LVM aux machines :<syntaxhighlight lang="bash">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w',
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w',
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w',
]

</syntaxhighlight>Le paramètre <code>disk</code> définit les disques virtuels attachés à la machine virtuelle (domaine Xen).

Chaque élément du tableau suit la syntaxe :<syntaxhighlight lang="bash">
<type>:<source>,<cible>,<mode>
</syntaxhighlight>

* '''type :''' indique si le disque provient :
** d'un fichier (<code>file:</code>)
** d'un périphérique physique réel (<code>phy:</code>).
* '''source :''' chemin complet vers l'image disque ou vers le périphérique physique sur la machine hôte.
* '''cible :''' nom du périphérique vu par la machine virtuelle (exemple : <code>xvda</code>, <code>xvdb</code>, etc.).

* '''mode :''' type d'accès au disque (<code>r</code> en lecture seule, <code>w</code> en lecture-écriture).

==== DISQUE VIRTUEL PRINCIPAL : ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w'
</syntaxhighlight>

* '''Type''' : <code>file</code> (stockage basé sur un fichier-image disque).
* '''Source''' : <code>/usr/local/xen/domains/SE4.Atreus/disk.img</code> (fichier contenant le disque virtuel).
* '''Cible''' : <code>xvda2</code> (deuxième partition du disque virtuel <code>xvda</code> visible depuis la MV).
* '''Mode''' : <code>w</code> (lecture-écriture).

Ce disque correspond à la racine (<code>/</code>) du système de fichiers Linux de la MV.

==== DISQUE VIRTUEL SWAP ====
<syntaxhighlight lang="bash">
'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w'

</syntaxhighlight>

* '''Type :''' <code>file</code> → Image disque stockée dans un fichier.
* '''Source :''' <code>/usr/local/xen/domains/SE4.Atreus/swap.img</code> → Chemin de l'image disque swap.
* '''Cible :''' <code>xvda1</code> → Première partition du disque virtuel <code>xvda</code>.

==== DISQUE PHYSIQUE POUR /home ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.home,xvda3,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Un périphérique physique (généralement une partition réelle ou un volume logique LVM).
* '''Source :''' <code>/dev/virtual/SE4.Atreus.home</code> → Partition ou volume logique physique sur l'hôte. L'hôte étant le disque dur de capbreton.
* '''Cible :''' <code>xvda3</code> → Troisième partition du disque virtuel <code>xvda</code>.

Cette partition dédiée permet d’isoler le répertoire <code>/home</code>, facilitant ainsi la gestion des données utilisateur séparément du système.

==== DISQUE PHYSIQUE POUR /var ====
<syntaxhighlight lang="bash">
'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w'
</syntaxhighlight>

* '''Type :''' <code>phy</code> → Périphérique physique.
* '''Source :''' <code>/dev/virtual/SE4.Atreus.var</code> → Partition physique ou volume logique dédié sur l'hôte.
* '''Cible :''' <code>xvdb1</code> → Première partition du second disque virtuel (<code>xvdb</code>).

Cette partition est dédiée au répertoire <code>/var</code>, où sont stockés les journaux (logs), les bases de données, les fichiers temporaires, etc. Cette séparation permet une meilleure gestion des données systèmes dynamiques.

Pour le fichier /var<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
</syntaxhighlight>Pour le fichier /home<syntaxhighlight lang="bash">
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>

==== DÉMARRAGE AUTOMATIQUE DU MONTAGE ====
{| class="wikitable"
|+
![[Fichier:Fichier fstab.png|Fichier_fstab|centré]]
|}

== CONFIGURATION RÉSEAU ==

Chaque machine dispose d'une adresse IPv4 fixe sur un réseau privé, ainsi que d'une adresse IPv6 configurée automatiquement.

Nous modifions la configuration réseau dans <code>/etc/network/interfaces</code> de la machine mandataire. Ensuite, nous ajustons le fichier de configuration de la machine virtuelle afin qu'elle possède deux interfaces : la première permet de communiquer avec le routeur mis en place par nos collègues, tandis que la seconde est connectée au pont réseau que nous avons créé pour l’intercommunication entre nos trois machines.

=== MACHINE MANDATAIRE ===
<syntaxhighlight lang="bash">
name = 'SE4.GOW'

#
# Networking
#
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:E7:C5:1A,bridge=bifrost',
'mac=00:16:3E:E7:C5:1B,bridge=SE4' ]

</syntaxhighlight>Le pont nommé '''"bifrost"''', défini dans le fichier de configuration de notre machine virtuelle mandataire, sert à '''relier virtuellement les trois machines''' entre elles.

Pour que des machines puissent communiquer, elles doivent être sur le '''même réseau'''. Ici, c’est un '''VIF (Virtual Interface)''' qui joue ce rôle : c’est une sorte de '''commutateur virtuel''' (ou switch virtuel).

Un '''commutateur''', c’est ce que vous imaginez peut-être comme une grosse boîte avec plein de câbles et de lumières clignotantes, qu’on trouve dans les salles serveurs.

Dans notre cas, tout ça est '''simulé dans la machine virtuelle''', donc pas de câbles physiques : la communication se fait via la '''carte réseau virtuelle''' attribuée à chaque machine.

Après avoir redémarré la machine, l’interface réseau est visible dans le fichier <code>/etc/network/interfaces</code>. On peut modifier ce fichier pour attribuer une adresse IP fixe à la machine GOW.<syntaxhighlight lang="bash">
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.3.1/24
# post-up ethtool -K eth0 tx off

iface eth0 inet6 auto

auto eth1
iface eth1 inet static
address 193.48.57.172/27
gateway 193.48.57.161
</syntaxhighlight>

=== MACHINE DE SERVICES ===
/etc/network/interfaces de la machine SE4.Atreus qui permet de lié les Interfaces de la MV avec ses VIF pour communiquer en IPv6 avec Internet et IPv4 avec la machine mandataire <syntaxhighlight lang="bash">
# The loopback network interface
auto lo
iface lo inet loopback

auto eth0

iface eth0 inet6 auto

iface eth0 inet static
address 192.168.3.2/24
gateway 192.168.3.1

auto eth1
iface eth1 inet6 auto

</syntaxhighlight>On configure la machine mandataire comme une passerelle (gateway) en IPv4. En IPv6, l’adresse est attribuée automatiquement grâce au bridge SE4.

Une fois que chaque machine peut être pingée par les autres et qu’elles arrivent à envoyer des requêtes vers Internet, on peut passer à l’étape suivante.
{| class="wikitable"
|+
![[Fichier:Interfacekratos.png|alt=Interfacekratos|Interfacekratos|centré|vignette|470x470px]]
! rowspan="2" |[[Fichier:IpaAtreusIp6Ip4.png|vignette|546x546px|ip a de la machine SE4.Atreus|centré]]
|-
|[[Fichier:PingEntre2VM.png|alt=PingEntre2VM|PingEntre2VM|centré|vignette|986x986px]]
|}

==== SSH ====
On active le SSH avec la ligne <code>PermitRootLogin yes</code> dans le fichier <code>/etc/ssh/sshd_config</code>sur les 3 machines, on peut accéder à la mandataire avec son adresse IPv4 routée, pour les machines de service on utilise l'adresse en IPv6

===== 🛡️ Sécurisation SSH avec Fail2Ban =====
📄 '''Fichier :''' <code>/etc/fail2ban/jail.local</code>

Ce fichier contient les règles locales de '''Fail2Ban''', un outil qui surveille les logs système et '''bannit temporairement les adresses IP''' en cas de comportement suspect (comme des tentatives de connexion SSH répétées avec un mauvais mot de passe).<syntaxhighlight lang="vim">
[sshd]
enable = true
port = ssh
filter = sshd
maxretry = 3
findtime = 300
bantime = 600
</syntaxhighlight>
{| class="wikitable"
!Paramètre
!Explication
|-
|<code>enable = true</code>
|Active la surveillance de SSH.
|-
|<code>port = ssh</code>
|Surveille le port SSH.
|-
|<code>filter = sshd</code>
|Utilise le '''filtre prédéfini''' <code>sshd.conf</code>, qui détecte les échecs de connexion dans les logs.
|-
|<code>maxretry = 3</code>
|'''3 tentatives''' ratées autorisées avant bannissement.
|-
|<code>findtime = 300</code>
|La fenêtre de détection : '''5 minutes''' pour accumuler ces 3 tentatives.
|-
|<code>bantime = 600</code>
|Durée de bannissement : '''10 minutes''' (600 secondes).
|}

=== CONFIGURATION DNS ===
Rappel : Qu’est-ce qu’un serveur DNS ?

Vu en cours avec Monsieur redon et Monsieur Vantroys, DNS veut dire '''Domain Name System'''. C’est un '''service''' qui fait la conversion entre un '''nom de domaine''' (comme <code>muspellheim2.online</code>) et une '''adresse IP''' (comme <code>193.48.57.172</code>), que les machines utilisent pour communiquer. Ce sont les pages jaunes des serveurs et IP d'Internet. On ne connait pas l'adresse IP de tous les sites. On ne connait que les noms. Quand on écrit netflix.com sur Internet, on interroge les serveurs DNS pour qu"il puisse nous rediriger vers l'adresse IP associé au nom "netflix.com".

==== 🌍 Fichier de zone DNS : <code>muspellheim2.online</code> ====
📄 '''Fichier :''' <code>/etc/bind/zones/muspellheim2.online/muspellheim2.zone</code>

Ce fichier définit tous les enregistrements DNS pour le domaine <code>muspellheim2.online</code>.

Il est utilisé par le serveur BIND '''maître''' (primary) pour répondre aux requêtes DNS.

===== 🧾 En-tête : SOA (Start Of Authority) =====
<syntaxhighlight lang="vim">
@ IN SOA ns.muspellheim2.online. admin.muspellheim2.online. (
3609 ; Numéro de version
21600 ; Rafraîchissement (6h)
3600 ; Re-tentative (1h)
2592000 ; Expiration (30j)
86400 ) ; Cache négatif (24h)
</syntaxhighlight>🔹 <code>@</code> : représente le domaine racine (<code>muspellheim2.online.</code> ici)

🔹 <code>SOA</code> : Spécifie '''l’autorité principale''' de la zone. Ici :

* Serveur DNS maître : <code>ns.muspellheim2.online.</code>
* Contact admin : <code>admin@muspellheim2.online</code> (le point remplace le <code>@</code>)
A chaque modification de ce fichier, il faut incrémenter le numéro de version de +1.

===== 📡 Serveurs DNS (NS) =====
<syntaxhighlight lang="vim">
@ IN NS ns.muspellheim2.online.
@ IN NS ns.jotunheim2.tech.
</syntaxhighlight>🔹 Ces lignes déclarent les serveurs DNS autoritaires pour cette zone :

- ns.muspellheim2.online. (le maître)

- ns.jotunheim2.tech. (un secondaire)

===== 🧭 Enregistrements de type A / AAAA =====
<syntaxhighlight lang="vim">
ns IN A 193.48.57.172
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
@ IN A 193.48.57.172
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
</syntaxhighlight>🔹 '''A''' : Adresse IPv4

🔹 '''AAAA''' : Adresse IPv6

Ces enregistrements associent :

* <code>ns.muspellheim2.online</code> à ses adresses IP (serveur DNS)
* <code>muspellheim2.online</code> lui-même à la même machine (le site est hébergé dessus)

===== 🔗 Alias (CNAME) =====
<syntaxhighlight lang="vim">
www IN CNAME muspellheim2.online.
</syntaxhighlight>🔹 Les requêtes pour <code>www.muspellheim2.online</code> seront redirigées vers <code>muspellheim2.online</code>.

Cela évite de dupliquer les enregistrements A/AAAA pour <code>www</code>.

===== 🔐 DNS Validation via Digicert =====
<syntaxhighlight lang="vim">
_gay4mlana6awxk71vd9gjuzdkzfism2.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
_gay4mlana6awxk71vd9gjuzdkzfism2.www.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
</syntaxhighlight>🔹 Ces lignes servent à '''valider le domaine''' auprès de l’autorité de certification (Digicert) pour obtenir un certificat SSL.

🔹 <code>dcv.digicert.com.</code> est le serveur que Digicert utilise pour vérifier la possession du domaine (via un CNAME dynamique généré).

On peut ensuite vérifier la syntaxe de notre '''fichier de zone DNS''' avec l’outil <code>named-checkzone</code>.

Cet outil nous aide à repérer les erreurs dans l’écriture du fichier, un peu comme '''Microsoft Word souligne les fautes de grammaire ou de syntaxe''' dans un texte.

Par exemple :<syntaxhighlight lang="ruby">
root@Atreus:~# named-checkzone muspellheim2.online /etc/bind/zones/muspellheim2.online/muspellheim2.zone
zone muspellheim2.online/IN: loaded serial 3609
OK
</syntaxhighlight>Ici, le message '''"OK"''' signifie que le fichier est bien écrit et ne contient pas d’erreurs de syntaxe.

Juste à noter : <code>named-checkzone</code> vérifie uniquement la syntaxe et la structure logique du fichier (comme la présence d’un SOA, la validité des enregistrements, etc.), '''mais pas si les adresses IP ou noms existent réellement'''.

Une fois que tout est correctement configuré, '''n’oubliez pas de redémarrer les services <code>named</code> et <code>bind</code>'''.

Cela permet à ces services de '''prendre en compte les nouvelles modifications''' que vous avez apportées dans les fichiers de configuration.

Il faut aussi '''attribuer les bons droits d'accès aux fichiers''', pour que <code>bind</code> puisse les lire correctement. Sinon, il risque de ne pas fonctionner comme prévu.<syntaxhighlight lang="ruby">
chown bind:bind /etc/bind/zones/muspellheim2.online/muspellheim2.zone
chmod 644 /etc/bind/zones/muspellheim2.online/muspellheim2.zone

chown bind:bind /etc/bind/named.conf.local
chmod 644 /etc/bind/named.conf.local
</syntaxhighlight>

* <code>chown</code> permet de '''donner la propriété des fichiers à l’utilisateur et au groupe <code>bind</code>'''.

* <code>chmod 644</code> donne les '''droits de lecture au service <code>bind</code>''', tout en empêchant d'autres utilisateurs non privilégiés de les modifier.

===== Vérification avec l'outil "dig" =====
On peut '''vérifier que notre serveur DNS fonctionne correctement''' en utilisant la commande <code>dig</code>.

C’est un outil qui envoie une requête DNS pour demander l’adresse IP d’un nom de domaine, et affiche la réponse complète reçue du serveur.

Par exemple, ici on interroge notre propre serveur DNS local (<code>@localhost</code>) pour vérifier s’il connaît le domaine <code>muspellheim2.online</code> :<syntaxhighlight lang="vim">
root@Atreus:~# dig @localhost muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="vim">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight>Cela signifie que la requête s’est bien déroulée, et qu’il n’y a '''pas d’erreur''' dans le fichier de zone.<syntaxhighlight lang="vim">
;; ANSWER SECTION:
muspellheim2.online. 200 IN A 193.48.57.172
</syntaxhighlight>
Le serveur DNS a bien répondu avec l’adresse IP '''193.48.57.172''', donc '''la zone est bien configurée et active'''.Ce test permet de s'assurer que '''le nom de domaine est bien reconnu et renvoie vers la bonne adresse IP'''.

On peut aussi tester depuis '''une autre machine virtuelle''', pour voir si '''le domaine est connu à l'extérieur''', par exemple par '''le DNS public de Google (<code>8.8.8.8</code>)'''.

Pour cela, on utilise <code>dig</code> en spécifiant l’IP du serveur DNS qu’on veut interroger :<syntaxhighlight lang="ruby">
root@GOW:~# dig @8.8.8.8 muspellheim2.online
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
</syntaxhighlight><syntaxhighlight lang="ruby">
;; ANSWER SECTION:
muspellheim2.online. 189 IN A 193.48.57.172
</syntaxhighlight>Google a répondu avec l’adresse IP '''193.48.57.172''', ce qui prouve que '''notre domaine est maintenant reconnu depuis l’extérieur'''.
🧠 '''Petit point d’attention''' : Si tu n’as pas volontairement '''enregistré le domaine <code>muspellheim2.online</code> sur Internet''' (via un registrar, ici c'est Gandi), alors :

* soit '''ton environnement de test est spécial''' (ex : en école avec une infra réseau propre et un DNS intermédiaire qui communique avec Google),
* soit '''le domaine a réellement été enregistré publiquement''', auquel cas tu partages un vrai domaine avec d'autres (et ça peut poser des conflits si tu voulais juste faire des tests en local).

==== REGISTRAR ET PROPAGATION DNS ====
Pour rendre notre '''serveur DNS opérationnel et accessible depuis Internet''', on se rend sur le site du '''registrar''' (dans notre cas : '''Gandi'''), qui est l’organisme auprès duquel on a acheté notre '''nom de domaine'''.

Dans l’onglet '''"Nameserver"''', on ajoute un '''Glue Record'''.

Un Glue Record sert à '''lier notre nom de domaine à nos propres serveurs DNS''', en indiquant leurs adresses IP :

* l’adresse '''IPv4''' de la '''machine mandataire''' (notre DNS principal),
* les adresses '''IPv6''' des '''machines de service''', si on veut un fonctionnement complet en IPv6.

Ensuite, on '''remplace les serveurs de noms (Nameservers) par les nôtres''', c’est-à-dire notre propre serveur DNS.

Cela fait de notre serveur '''le référent officiel pour la gestion des noms de domaine''' associés à <code>muspellheim2.online</code>.

🧠 Pourquoi on fait tout ça ?

Eh bien, comme on l’a vu avec la commande :<syntaxhighlight lang="vim">
dig @8.8.8.8 muspellheim2.online
</syntaxhighlight>Google a pu répondre car '''notre domaine est désormais public''' !

Si on n’avait pas fait cette configuration chez Gandi, personne sur Internet (hors de notre réseau) n’aurait pu le voir.

🌐 Pour faire simple :

En ajoutant un Glue Record et en configurant nos Nameservers, on annonce notre domaine au monde entier.

Cela permet à n’importe quel ordinateur sur Internet de retrouver l’adresse IP de notre serveur — et donc d’afficher notre site ou d’accéder à nos services.
{| class="wikitable"
|+
![[Fichier:NameserverGandi.png|gauche|NameserverGandi Pierre CASIMIRI muspellheim2.online]]
|-
|[[Fichier:GlueRecordGandi.png|gauche|2305x2305px|GlueRecordGandi Pierre CASIMIRI muspellheim2.online]]
|}

==== DIFFUSION DE NOTRE SUPERBE SERVEUR AU MONDE ====

🌍 Une fois le Glue Record ajouté… on attend un peu que le monde entier soit au courant !

Une fois qu’on a :

* ajouté les '''Glue Records''',
* remplacé les '''Nameservers''' dans le registrar (comme Gandi),

eh bien il faut patienter un peu. Pourquoi ? Parce que '''les informations DNS doivent se propager''' à travers le monde. Cette phase peut prendre '''quelques heures à quelques jours''', selon les serveurs.

🛰️ Comment savoir si c’est bien propagé ?

Il existe des sites comme '''DNSChecker.org''' qui permettent de voir si votre nom de domaine est '''bien visible depuis plusieurs endroits de la planète'''.

📌 Exemple : <code>muspellheim2.online</code>

Sur DNSChecker, vous entrez votre domaine et choisissez le type d'enregistrement que vous voulez vérifier, par exemple :
{| class="wikitable"
!Type
!Ce que ça affiche
|-
|<code>A</code>
|Adresse IPv4 liée au domaine
|-
|<code>AAAA</code>
|Adresse IPv6
|-
|<code>NS</code>
|Liste des Nameservers en charge du domaine
|-
|<code>CNAME</code>
|Alias d’un domaine vers un autre
|-
|<code>DNSKEY</code>
|Clés publiques DNSSEC (on y reviendra plus tard)
|}
{| class="wikitable"
|+
![[Fichier:DNSChecker1.png|gauche|768x768px|DNSChecker1]]
![[Fichier:DNSChecker3.png|alt=DNSChecker3|bordure|687x687px]]
! rowspan="2" |[[Fichier:DNSChecker5.png|alt=DNSChecker5|655x655px]]
|-
|[[Fichier:DNSChecker2.png|alt=DNSChecker2|bordure|768x768px]]
|[[Fichier:DNSChecker4.png|alt=DNSChecker4|701x701px]]
|}

* ✅ '''Check vert''' : ça veut dire que ce serveur DNS a bien reçu et reconnu ton info.
* 🟡 '''Check en attente''' : propagation en cours ou serveur lent.
* ❌ '''Check rouge''' : info non encore propagée à ce serveur ou pas propagée car les certificats ne sont pas acceptés par ses serveurs DNS.

==== DNSSEC sur Atreus ====

===== 🧭 Configuration DNS sur le serveur BIND – <code>named.conf.local</code> =====
📄 Fichier : <code>/etc/bind/named.conf.local</code>

Ce fichier contient la déclaration des zones DNS locales pour le serveur BIND.

On y définit ici :

-Une zone primaires (gérées en local)

-Une zone secondaire (copiée depuis un autre serveur)

Et une politique DNSSEC.<syntaxhighlight lang="bash">
cat /etc/bind/named.conf.local
</syntaxhighlight><syntaxhighlight lang="vim">
zone "muspellheim2.online" {

type primary;
file "/etc/bind/zones/muspellheim2.online/muspellheim2.zone";

allow-transfer{2001:660:4401:60a0:216:3eff:fee7:c51b;

2001:660:4401:60a0:216:3eff:fed0:9ab0;}; // filtrage des secondaires

also-notify{2001:660:4401:60a0:216:3eff:fee7:c51b;}; // pour les secondaires vicieux notify yes; // notification des secondaires
key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes; };

zone "jotunheim2.tech"{

type slave;
file "/etc/bind/jotunheim2.tech";
primaries{2001:660:4401:60a0:216:3eff:fed0:9ab0;};

};

dnssec-policy "dnspol" {

keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;

};
</syntaxhighlight>

🔹 '''type primary''' : Ce serveur est '''l'autorité principale''' pour la zone.

🔹 '''file''' : Chemin du fichier de zone contenant tous les enregistrements DNS (<code>A</code>, <code>AAAA</code>, <code>NS</code>, etc.).

🔹 '''allow-transfer''' : Liste des serveurs secondaires '''autorisés à faire un transfert de zone''' (AXFR). Cela sécurise l’accès aux données DNS.

🔹 '''also-notify''' : Force l’envoi de notifications DNS vers certains secondaires, même s’ils ne sont pas configurés comme secondaires officiels.

🔹 '''notify yes''' : Active les notifications automatiques des serveurs secondaires lorsqu’une mise à jour de la zone est faite.

🔹 '''dnssec-policy "dnspol"''' : Active '''DNSSEC''' avec une politique personnalisée.

🔹 '''inline-signing yes''' : Active la '''signature automatique''' de la zone par BIND.

====== Zone secondaire : <code>jotunheim2.tech</code> ======
<syntaxhighlight lang="vim">
zone "jotunheim2.tech" {
type slave;
file "/etc/bind/jotunheim2.tech";
primaries { 2001:660:4401:60a0:216:3eff:fed0:9ab0; };
};
</syntaxhighlight>🔹 '''type slave''' : Ce serveur récupère les données de zone depuis un '''serveur primaire distant'''.

🔹 '''primaries { ... }''' : Adresse du serveur maître à interroger pour obtenir la zone.

🔹 '''file''' : Emplacement local où la zone est stockée après transfert.

====== 🔐 Politique DNSSEC : <code>"dnspol"</code> ======
<syntaxhighlight lang="vim">
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>🔹 '''ksk''' : Key Signing Key (clé qui signe les autres clés DNS).

🔹 '''zsk''' : Zone Signing Key (clé qui signe les enregistrements DNS).

🔹 '''algorithm 13''' : Il s’agit d’'''ECDSA P-256 with SHA-256''' (<nowiki>RFC 6605</nowiki>), algorithme sécurisé et moderne.

🔹 '''nsec3param''' : Indique que '''NSEC3''' est utilisé (permet de sécuriser les réponses "ce nom n'existe pas" sans divulguer d'autres noms).

✅ Les deux clés sont générées dans le répertoire <code>key-directory</code>, ont une durée de vie '''illimitée''', et utilisent '''l’algorithme 13''' (ED25519, rapide et sécurisé).

✅ <code>nsec3param</code> : active la protection contre l’énumération de noms (empêche de “scanner” une zone DNS facilement).

Pour que '''DNSSEC fonctionne correctement''', il faut '''déclarer la clé KSK''' (Key Signing Key) chez votre '''registrar''', ici '''Gandi'''.

Sur votre machine, les clés sont générées automatiquement dans le répertoire (key-directory dans le fichier <code>/etc/bind/named.conf.local)</code><syntaxhighlight lang="bash">
/etc/bind/keys/
</syntaxhighlight>
Par exemple, vous pouvez voir des fichiers comme ceux-ci :<syntaxhighlight lang="ruby">
Kmuspellheim2.online.+013+03837.key
Kmuspellheim2.online.+013+03837.private
Kmuspellheim2.online.+013+03837.state

Kmuspellheim2.online.+013+14053.key
Kmuspellheim2.online.+013+14053.private
Kmuspellheim2.online.+013+14053.state

</syntaxhighlight>🗝️ Les fichiers importants :

* Les fichiers '''<code>.key</code>''' contiennent la '''clé publique''' (celle que vous devez copier/coller sur Gandi).
* Les fichiers '''<code>.private</code>''' contiennent la '''clé privée''' (à '''ne jamais partager''' !).
* Les fichiers '''<code>.state</code>''' servent à BIND pour gérer l’état et la durée de validité des clés.

Pour éviter tout problème avec la validation DNSSEC, pensez à mettre les deux fichiers .key dans l’interface de Gandi, dans la partie DNSSEC de votre domaine.

💡 En faisant cela, vous reliez votre zone DNS signée à la chaîne de confiance globale d’Internet : tout le monde pourra alors vérifier que vos données DNS sont authentiques et non modifiées.

Une fois la configuration DNSSEC en place, on peut tester si '''tout fonctionne correctement''' avec le site '''DNSViz'''.

Ce site permet d’'''analyser les signatures DNSSEC''' et de vérifier si la '''chaîne de confiance''' est bien construite du début à la fin (depuis la racine DNS jusqu’à votre zone).
{| class="wikitable"
|+
![[Fichier:DNSviz Muspellheim2.online.png|gauche|1129x1129px|DNSviz Muspellheim2.online]]
|}
Le graphe montre '''la chaîne de confiance DNSSEC''' :

* On part de la '''racine DNS''' (<code>.</code>), qui délègue au TLD <code>.online</code>.
* <code>.online</code> contient une clé DS qui fait le lien avec '''ton domaine''' <code>muspellheim2.online</code>.
* Ensuite, ton domaine possède ses propres clés (DNSKEY), qui signent toutes les infos de ta zone (A, NS, AAAA, etc.)

✅ Tout est "Secure" sur le graphe → l'''a configuration DNSSEC est correcte et vérifiée''' !
== APACHE ==
===== '''Configuration d’Apache sur GOW''' : =====
Apache va '''écouter les requêtes envoyées à muspellheim2.online''', puis les '''rediriger vers un autre serveur''' (ici Atreus), via son '''adresse IPv6'''.

Cela permet d’accéder à un site web qui tourne sur Atreus '''même si celui-ci n’a pas d’IPv4 publique'''.

<code>root@GOW:~# cat /etc/apache2/sites-available/muspellheim2.online.conf</code>
<syntaxhighlight lang="bash">
#Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online

ProxyPass / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
</VirtualHost>

# Partie HTTPS (port 443)
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName muspellheim2.online

SSLProxyEngine on
ProxyPreserveHost on

SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/KGandiPierre/GandiCert.pem

ProxyPass / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
ProxyPassReverse / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/

</VirtualHost>
</IfModule>
</syntaxhighlight>
📄 '''Fichier concerné : /etc/apache2/sites-available/muspellheim2.online.conf'''

Ce fichier configure un virtual host Apache2 pour le domaine muspellheim2.online, en mode proxy inverse (reverse proxy). Cela signifie que le serveur Apache2 reçoit les requêtes des utilisateurs et les redirige vers un autre serveur (Atreus), ici identifié par son adresse IPv6.

Le fichier gère deux protocoles :

- HTTP (port 80) — non sécurisé

- HTTPS (port 443) — sécurisé avec SSL/TLS

🔹 *VirtualHost :80 : Cela signifie que ce bloc s'applique à toutes les interfaces réseau, sur le port 80 (HTTP).

🔹 ServerName : Nom de domaine géré par ce virtual host. Apache redirigera les requêtes envoyées à muspellheim2.online.

🔹 ProxyPass / ... : Toutes les requêtes reçues sur / sont transmises à l'adresse IPv6 mentionnée. C’est là que tourne le vrai service web.

🔹 ProxyPassReverse : Permet de réécrire les en-têtes de redirection (comme les Location: envoyés par le serveur cible), pour que le client voit toujours muspellheim2.online au lieu de l’IP.

Atreus n’a pas d’IPv4 publique, donc il n’est pas directement joignable depuis Internet.

➜ GOW, qui a une IP publique, agit comme une porte d’entrée vers Atreus.

➜ C’est lui qui reçoit les requêtes extérieures et les redirige en interne vers le bon serveur.

On appelle ça un proxy inverse : le client ne sait pas que le site tourne ailleurs, tout passe par GOW.

===== '''Configuration d’Apache2 sur Atreus : le vrai serveur web – Site muspellheim2.online''' : =====
📄 Fichier : /etc/apache2/sites-available/000-muspellheim.conf

Ce fichier configure le serveur Apache2 sur la machine Atreus, qui héberge le véritable contenu du site muspellheim2.online. Il gère aussi bien les connexions HTTP que HTTPS.
<syntaxhighlight lang="bash">
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>
</syntaxhighlight>

🔹 *VirtualHost :80 : Écoute sur le port HTTP.

🔹 ServerName / ServerAlias :

ServerName : Nom principal du site.

ServerAlias : Permet aussi de répondre à www.muspellheim2.online.

🔹 RedirectPermanent / : Redirige tout le trafic HTTP vers HTTPS.

💡 '''Pourquoi ?'''

C’est une '''bonne pratique de sécurité''' : on force tous les visiteurs à utiliser une connexion chiffrée.

Partie HTTPS – Serveur principal

<syntaxhighlight lang="bash">
<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
...
</VirtualHost>
</syntaxhighlight>

Port 443 : Pour les connexions HTTPS (chiffrées).

🔹 ServerName / ServerAlias : Idem que pour le port 80

<syntaxhighlight lang="bash">
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
</syntaxhighlight>
🔹 Ces trois fichiers permettent au serveur d’offrir une connexion HTTPS sécurisée :

- .crt : certificat public du site.

- .key : clé privée (confidentielle).

- ChainFile : certificat intermédiaire (chaîne de certification, fourni par Gandi ici).

'''📝 Logs Apache'''
<syntaxhighlight lang="bash">
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</syntaxhighlight>

🔹 Gère la journalisation :

- error.log : erreurs serveur.

- access.log : toutes les requêtes reçues, avec IP, timestamp, etc.
<syntaxhighlight lang="bash">
# Partie HTTP (port 80)
<VirtualHost *:80>
ServerName muspellheim2.online
ServerAlias www.muspellheim2.online
RedirectPermanent / https://muspellheim2.online/
</VirtualHost>

# Partie HTTPS (port 443)

<VirtualHost *:443>
ServerName muspellheim2.online
ServerAlias www.muspellheim.online
# SSLProxyEngine on
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</syntaxhighlight>Et comme '''Atreus est le vrai serveur''', et que '''GOW redirige tout vers lui''', ça permet à l’utilisateur de '''n’avoir aucune idée que deux serveurs travaillent ensemble derrière <code>muspellheim2.online</code>'''.
{| class="wikitable"
|+
![[Fichier:Schéma fonctionnel redirection vers Atreus.png|alt=Schéma fonctionnel redirection vers Atreus|345x345px]]
|}

== ✅ Vérification finale : est-ce que le site est en ligne et accessible ? ==
Une fois que '''tout est configuré''' (serveur web, DNS, DNSSEC, reverse proxy, certificats...), il ne reste plus qu'à '''tester si le site fonctionne bien'''.

=== 🧪 Méthode 1 : test en ligne de commande avec <code>curl</code> ===
<syntaxhighlight lang="ruby">
curl -4 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -4 muspellheim.png|alt=sortie curl -4 muspellheim|550x550px]]
|}
<syntaxhighlight lang="ruby">
curl -6 https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Sortie curl -6 muspellheim.png|alt=sortie curl -6 muspellheim|502x502px]]
|}

=== 🌍 Méthode 2 : test dans un navigateur ===
Vous pouvez aussi tout simplement ouvrir votre navigateur préféré et taper l’adresse :<syntaxhighlight lang="ruby">
https://muspellheim2.online
</syntaxhighlight>
{| class="wikitable"
|+
![[Fichier:Projet fini Muspellheim.png|alt=Projet fini Muspellheim|1076x1076px]]
|}

* <code>curl -4</code> et <code>curl -6</code> permettent de '''vérifier si votre site répond en IPv4 et IPv6'''.

* Si vous n’avez pas de retour ou que la connexion échoue, vérifiez :
** votre '''config Apache'''
** vos '''règles de pare-feu'''
** vos '''enregistrements DNS'''
** et que vos '''certificats sont bien en place'''

SE4 2024/2025 EC2

2025-09-03T18:32:47Z

Pcasimir : /* Programme de test avancé */

= Objectifs =

Vous allez concevoir, réaliser et programmer un système embarqué de test de terminaux série assez souvent utilisés pour l'administration système et réseau.

Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C.

Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port.

Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de <code>gcc</code> et l'utilitaire <code>dfu-programmer</code>. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser <code>minicom</code> dans un premier temps.

Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour <code>minicom</code>. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte.

L'épreuve sera considérée comme un succès s'il est possible de jouer à tétris sur un des deux anciens terminaux.

Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec.

= Matériel nécessaire =

Le matériel nécessaire est constitué :
* d'un PC pour la conception de la carte et la mise au point du programme embarqué (à votre charge) ;
* d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ;
* de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août).

= Foire aux questions =

* L'épreuve complémentaire est-elle réalisable au domicile de l'élève ?

La conception de la carte est réalisable à domicile, la fabrication de la carte est prévue à l'extérieur (50 euros maximum, composants et port compris), il faut donc une adresse postale valide pour recevoir le PCB, la réalisation de la carte peut être externalisée (dans la limite des 50 euros) ou à domicile en utilisant un fer à souder personnel, le développement initial est réalisable sur l'Arduino fourni (et un PC personnel), les tests basiques et avancés sont réalisables à domicile (Arduino et PC personnel), le test sur les anciens terminaux est à prévoir fin août à l'école. Il n'est pas prévu d'accès aux ressources de l'école avant fin août.

* Où est disponible l'Arduino UNO ?

Comme indiqué dans le courriel du 15 juillet, le matériel est disponible à l'accueil de l'école. A rendre au premier septembre 2025.

* Comment programmer la carte ?

Comme indiqué dans le sujet, la carte doit pouvoir se programmer par DFU/USB. Il est conseillé d'utiliser un système d'exploitation Linux pour le développement du programme embarqué mais vous pouvez utiliser tout autre système du moment que vous assumez ce choix.

* Comment sera testée la carte réalisée ?

La carte sera testée par l'encadrant d'abord en utilisant l'utilitaire <code>minicom</code> avec son émulation VT100 sous un Linux mais l'élève peut tester son code avec tout autre outil. Un second test sera conduit sur les anciens terminaux série de l'école.

* Précisions sur les jeux "pendu" et "tétris"

Les jeux évoqués doivent pouvoir être joué à partir de l'écran et des touches des terminaux. Les éventuelles touches sur la cartes ne servent qu'à sélectionner le test et le protocole de commandes du terminal (VT100 ou autre).

= Travail réalisé =

=== COMPTE-RENDU DU 28/07/2025 ===

==== Préliminaires – Connexion d’un Arduino via USB à Minicom dans WSL2 ====
Dans ce projet, il est nécessaire de communiquer avec un microcontrôleur (ici, un '''Arduino Uno''') connecté en '''USB''' à un PC sous '''Windows 11''', en utilisant un outil typiquement '''Linux''' : '''Minicom''', un terminal série.

Or, Minicom ne fonctionne pas directement sur Windows, et nécessite un environnement Linux. Pour cette raison, nous avons mis en place un environnement '''WSL2''' (Windows Subsystem for Linux) avec '''Ubuntu''', capable d'accéder au port USB de l'Arduino.

Cette section détaille toutes les étapes techniques pour configurer correctement cette chaîne de communication entre :

* l’'''IDE Arduino''' sous Windows pour téléverser les programmes,
* l’environnement '''Ubuntu WSL2''' pour dialoguer via le terminal Minicom.

===== Environnement logiciel utilisé =====

* '''Système d’exploitation''' : Windows 11
* '''Distribution Linux via WSL2''' : Ubuntu 20.04
* '''Périphérique série utilisé''' : Arduino Uno
* '''Outils utilisés''' :
** WSL2
** usbipd-win (redirection USB vers WSL)
** <code>Minicom</code> (communication série Linux)

==== Redirection USB du port Arduino vers WSL ====
Par défaut, un port USB comme '''COM9''' sur Windows '''n'est pas visible directement''' sous WSL. Pour le rendre accessible à Ubuntu, il faut utiliser '''usbipd-win'''.

==== Installer usbipd ====
Dans PowerShell :

<syntaxhighlight lang="bash">winget install usbipd</syntaxhighlight>

Redémarrer le système W11 une fois l'installation terminée.

=== Identifier le port USB de l’Arduino ===
Branche l’Arduino via USB.

Dans PowerShell :

<syntaxhighlight lang="bash">usbipd list</syntaxhighlight>

Cela affiche tous les périphériques USB connectés.

<syntaxhighlight lang="bash">BUSID VID:PID DEVICE
1-1 2341:0043 Périphérique série USB (COM9)</syntaxhighlight>

Ici, le '''BUSID''' est <code>1-1</code> et l’Arduino est détecté sur le '''port COM9'''.

=== Partager puis attacher le port à WSL ===
Toujours dans PowerShell :

<syntaxhighlight lang="bash">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>

Vérifier dans Ubuntu que le port est bien présent
Dans Ubuntu (WSL) :
<syntaxhighlight lang="bash">ls /dev/tty*
/dev/tty /dev/tty21 /dev/tty35 /dev/tty49 /dev/tty62
/dev/tty0 /dev/tty22 /dev/tty36 /dev/tty5 /dev/tty63
/dev/tty1 /dev/tty23 /dev/tty37 /dev/tty50 /dev/tty7
/dev/tty10 /dev/tty24 /dev/tty38 /dev/tty51 /dev/tty8
/dev/tty11 /dev/tty25 /dev/tty39 /dev/tty52 /dev/tty9
/dev/tty12 /dev/tty26 /dev/tty4 /dev/tty53 /dev/ttyACM0
/dev/tty13 /dev/tty27 /dev/tty40 /dev/tty54 /dev/ttyS0
/dev/tty14 /dev/tty28 /dev/tty41 /dev/tty55 /dev/ttyS1
/dev/tty15 /dev/tty29 /dev/tty42 /dev/tty56 /dev/ttyS2
/dev/tty16 /dev/tty3 /dev/tty43 /dev/tty57 /dev/ttyS3
/dev/tty17 /dev/tty30 /dev/tty44 /dev/tty58 /dev/ttyS4
/dev/tty18 /dev/tty31 /dev/tty45 /dev/tty59 /dev/ttyS5
/dev/tty19 /dev/tty32 /dev/tty46 /dev/tty6 /dev/ttyS6
/dev/tty2 /dev/tty33 /dev/tty47 /dev/tty60 /dev/ttyS7
/dev/tty20 /dev/tty34 /dev/tty48 /dev/tty61
</syntaxhighlight>
Ce périphérique correspond à l’Arduino connecté en USB.
C’est ce port que Minicom utilisera pour la communication série.

Exemple de sketch Arduino pour test de communication
Ce sketch permet de tester si la communication fonctionne bien.
Téléverser via l’IDE Arduino sous Windows avant d’attacher le périphérique à WSL :
<syntaxhighlight lang="cpp">
void setup() {
Serial.begin(9600);
}

void loop() {
if (Serial.available()) {
char c = Serial.read();
Serial.print("Vous avez tapé : ");
Serial.println(c);
}
}</syntaxhighlight>

Alternance Windows ↔ WSL

Pour téléverser un sketch depuis Windows :
<syntaxhighlight lang="powershell">usbipd detach --busid 1-1</syntaxhighlight>
(Le périphérique redevient accessible dans l’IDE Arduino sous Windows)

Pour basculer la communication vers Ubuntu (Minicom) :
<syntaxhighlight lang="powershell">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>
Cette alternance peut être répétée autant que nécessaire.

= Documents Rendus =

== Projet KiCAD de la carte ==
Lien Gitea avec Code Arduino, Code C, Makefile, fichiers KiCAD : https://gitea.plil.fr/pcasimir/Test-Terminaux_Rattrapages-SE4-2025.git
{| class="wikitable"
|+
![[Fichier:Terminal-Testing SCH KiCAD.pdf|alt=Terminal-Testing SCH KiCAD|vignette|Terminal-Testing SCH KiCAD]]
|}

== Programme de test ASCII ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter si besoin) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Deuxième Makefile<syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = at90usb1287
F_CPU = 16000000UL

# ========= LUFA =========
LUFA_PATH = ./LUFA

# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms)
LUFA_CORE_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c)

# Classe CDC côté Device (et commun) — uniquement CDC
LUFA_CLASS_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c)

# ========= Sources de ton projet =========
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC)
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I.
LDFLAGS = -Wl,--gc-sections

# ========= Règles =========
.PHONY: all clean erase flash reset info
all: $(TARGET).hex

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

$(TARGET).hex: $(TARGET).elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

# -------- DFU workflow --------
info:
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB."
@echo "Ensuite: make erase && make flash && make reset"

erase:
dfu-programmer at90usb1287 erase

flash: $(TARGET).hex
dfu-programmer at90usb1287 flash $(TARGET).hex

reset:
dfu-programmer at90usb1287 reset
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetriss.mp4|vignette|Arduino UNO Minicom Pendu + Tetriss]]
|}

== Programme de test avancé ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C (modifie si besoin)
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Deuxième Makefile <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = at90usb1287
F_CPU = 16000000UL

# ========= LUFA =========
LUFA_PATH = ./LUFA

# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms)
LUFA_CORE_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c)

# Classe CDC côté Device (et commun) — uniquement CDC
LUFA_CLASS_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c)

# ========= Sources de ton projet =========
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC)
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I.
LDFLAGS = -Wl,--gc-sections

# ========= Règles =========
.PHONY: all clean erase flash reset info
all: $(TARGET).hex

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

$(TARGET).hex: $(TARGET).elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

# -------- DFU workflow --------
info:
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB."
@echo "Ensuite: make erase && make flash && make reset"

erase:
dfu-programmer at90usb1287 erase

flash: $(TARGET).hex
dfu-programmer at90usb1287 flash $(TARGET).hex

reset:
dfu-programmer at90usb1287 reset
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|vignette]]
|-
![[Fichier:Vidéo démonstrative surMinicom avec Carte de M-Zongo.mp4|vignette|Vidéo démonstrative surMinicom avec Carte de M-Zongo]]
|}

== Démonstration de fonctionnement sur terminaux anciens ==

Vidéos de démonstration.

Fichier:Vidéo démonstrative surMinicom avec Carte de M-Zongo.mp4

2025-09-03T18:32:38Z

Pcasimir :

Vidéo démonstrative surMinicom avec Carte de M-Zongo

SE4 2024/2025 EC2

2025-09-03T15:35:45Z

Pcasimir : /* Programme de test ASCII */

= Objectifs =

Vous allez concevoir, réaliser et programmer un système embarqué de test de terminaux série assez souvent utilisés pour l'administration système et réseau.

Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C.

Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port.

Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de <code>gcc</code> et l'utilitaire <code>dfu-programmer</code>. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser <code>minicom</code> dans un premier temps.

Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour <code>minicom</code>. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte.

L'épreuve sera considérée comme un succès s'il est possible de jouer à tétris sur un des deux anciens terminaux.

Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec.

= Matériel nécessaire =

Le matériel nécessaire est constitué :
* d'un PC pour la conception de la carte et la mise au point du programme embarqué (à votre charge) ;
* d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ;
* de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août).

= Foire aux questions =

* L'épreuve complémentaire est-elle réalisable au domicile de l'élève ?

La conception de la carte est réalisable à domicile, la fabrication de la carte est prévue à l'extérieur (50 euros maximum, composants et port compris), il faut donc une adresse postale valide pour recevoir le PCB, la réalisation de la carte peut être externalisée (dans la limite des 50 euros) ou à domicile en utilisant un fer à souder personnel, le développement initial est réalisable sur l'Arduino fourni (et un PC personnel), les tests basiques et avancés sont réalisables à domicile (Arduino et PC personnel), le test sur les anciens terminaux est à prévoir fin août à l'école. Il n'est pas prévu d'accès aux ressources de l'école avant fin août.

* Où est disponible l'Arduino UNO ?

Comme indiqué dans le courriel du 15 juillet, le matériel est disponible à l'accueil de l'école. A rendre au premier septembre 2025.

* Comment programmer la carte ?

Comme indiqué dans le sujet, la carte doit pouvoir se programmer par DFU/USB. Il est conseillé d'utiliser un système d'exploitation Linux pour le développement du programme embarqué mais vous pouvez utiliser tout autre système du moment que vous assumez ce choix.

* Comment sera testée la carte réalisée ?

La carte sera testée par l'encadrant d'abord en utilisant l'utilitaire <code>minicom</code> avec son émulation VT100 sous un Linux mais l'élève peut tester son code avec tout autre outil. Un second test sera conduit sur les anciens terminaux série de l'école.

* Précisions sur les jeux "pendu" et "tétris"

Les jeux évoqués doivent pouvoir être joué à partir de l'écran et des touches des terminaux. Les éventuelles touches sur la cartes ne servent qu'à sélectionner le test et le protocole de commandes du terminal (VT100 ou autre).

= Travail réalisé =

=== COMPTE-RENDU DU 28/07/2025 ===

==== Préliminaires – Connexion d’un Arduino via USB à Minicom dans WSL2 ====
Dans ce projet, il est nécessaire de communiquer avec un microcontrôleur (ici, un '''Arduino Uno''') connecté en '''USB''' à un PC sous '''Windows 11''', en utilisant un outil typiquement '''Linux''' : '''Minicom''', un terminal série.

Or, Minicom ne fonctionne pas directement sur Windows, et nécessite un environnement Linux. Pour cette raison, nous avons mis en place un environnement '''WSL2''' (Windows Subsystem for Linux) avec '''Ubuntu''', capable d'accéder au port USB de l'Arduino.

Cette section détaille toutes les étapes techniques pour configurer correctement cette chaîne de communication entre :

* l’'''IDE Arduino''' sous Windows pour téléverser les programmes,
* l’environnement '''Ubuntu WSL2''' pour dialoguer via le terminal Minicom.

===== Environnement logiciel utilisé =====

* '''Système d’exploitation''' : Windows 11
* '''Distribution Linux via WSL2''' : Ubuntu 20.04
* '''Périphérique série utilisé''' : Arduino Uno
* '''Outils utilisés''' :
** WSL2
** usbipd-win (redirection USB vers WSL)
** <code>Minicom</code> (communication série Linux)

==== Redirection USB du port Arduino vers WSL ====
Par défaut, un port USB comme '''COM9''' sur Windows '''n'est pas visible directement''' sous WSL. Pour le rendre accessible à Ubuntu, il faut utiliser '''usbipd-win'''.

==== Installer usbipd ====
Dans PowerShell :

<syntaxhighlight lang="bash">winget install usbipd</syntaxhighlight>

Redémarrer le système W11 une fois l'installation terminée.

=== Identifier le port USB de l’Arduino ===
Branche l’Arduino via USB.

Dans PowerShell :

<syntaxhighlight lang="bash">usbipd list</syntaxhighlight>

Cela affiche tous les périphériques USB connectés.

<syntaxhighlight lang="bash">BUSID VID:PID DEVICE
1-1 2341:0043 Périphérique série USB (COM9)</syntaxhighlight>

Ici, le '''BUSID''' est <code>1-1</code> et l’Arduino est détecté sur le '''port COM9'''.

=== Partager puis attacher le port à WSL ===
Toujours dans PowerShell :

<syntaxhighlight lang="bash">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>

Vérifier dans Ubuntu que le port est bien présent
Dans Ubuntu (WSL) :
<syntaxhighlight lang="bash">ls /dev/tty*
/dev/tty /dev/tty21 /dev/tty35 /dev/tty49 /dev/tty62
/dev/tty0 /dev/tty22 /dev/tty36 /dev/tty5 /dev/tty63
/dev/tty1 /dev/tty23 /dev/tty37 /dev/tty50 /dev/tty7
/dev/tty10 /dev/tty24 /dev/tty38 /dev/tty51 /dev/tty8
/dev/tty11 /dev/tty25 /dev/tty39 /dev/tty52 /dev/tty9
/dev/tty12 /dev/tty26 /dev/tty4 /dev/tty53 /dev/ttyACM0
/dev/tty13 /dev/tty27 /dev/tty40 /dev/tty54 /dev/ttyS0
/dev/tty14 /dev/tty28 /dev/tty41 /dev/tty55 /dev/ttyS1
/dev/tty15 /dev/tty29 /dev/tty42 /dev/tty56 /dev/ttyS2
/dev/tty16 /dev/tty3 /dev/tty43 /dev/tty57 /dev/ttyS3
/dev/tty17 /dev/tty30 /dev/tty44 /dev/tty58 /dev/ttyS4
/dev/tty18 /dev/tty31 /dev/tty45 /dev/tty59 /dev/ttyS5
/dev/tty19 /dev/tty32 /dev/tty46 /dev/tty6 /dev/ttyS6
/dev/tty2 /dev/tty33 /dev/tty47 /dev/tty60 /dev/ttyS7
/dev/tty20 /dev/tty34 /dev/tty48 /dev/tty61
</syntaxhighlight>
Ce périphérique correspond à l’Arduino connecté en USB.
C’est ce port que Minicom utilisera pour la communication série.

Exemple de sketch Arduino pour test de communication
Ce sketch permet de tester si la communication fonctionne bien.
Téléverser via l’IDE Arduino sous Windows avant d’attacher le périphérique à WSL :
<syntaxhighlight lang="cpp">
void setup() {
Serial.begin(9600);
}

void loop() {
if (Serial.available()) {
char c = Serial.read();
Serial.print("Vous avez tapé : ");
Serial.println(c);
}
}</syntaxhighlight>

Alternance Windows ↔ WSL

Pour téléverser un sketch depuis Windows :
<syntaxhighlight lang="powershell">usbipd detach --busid 1-1</syntaxhighlight>
(Le périphérique redevient accessible dans l’IDE Arduino sous Windows)

Pour basculer la communication vers Ubuntu (Minicom) :
<syntaxhighlight lang="powershell">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>
Cette alternance peut être répétée autant que nécessaire.

= Documents Rendus =

== Projet KiCAD de la carte ==
Lien Gitea avec Code Arduino, Code C, Makefile, fichiers KiCAD : https://gitea.plil.fr/pcasimir/Test-Terminaux_Rattrapages-SE4-2025.git
{| class="wikitable"
|+
![[Fichier:Terminal-Testing SCH KiCAD.pdf|alt=Terminal-Testing SCH KiCAD|vignette|Terminal-Testing SCH KiCAD]]
|}

== Programme de test ASCII ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter si besoin) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Deuxième Makefile<syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = at90usb1287
F_CPU = 16000000UL

# ========= LUFA =========
LUFA_PATH = ./LUFA

# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms)
LUFA_CORE_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c)

# Classe CDC côté Device (et commun) — uniquement CDC
LUFA_CLASS_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c)

# ========= Sources de ton projet =========
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC)
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I.
LDFLAGS = -Wl,--gc-sections

# ========= Règles =========
.PHONY: all clean erase flash reset info
all: $(TARGET).hex

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

$(TARGET).hex: $(TARGET).elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

# -------- DFU workflow --------
info:
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB."
@echo "Ensuite: make erase && make flash && make reset"

erase:
dfu-programmer at90usb1287 erase

flash: $(TARGET).hex
dfu-programmer at90usb1287 flash $(TARGET).hex

reset:
dfu-programmer at90usb1287 reset
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetriss.mp4|vignette|Arduino UNO Minicom Pendu + Tetriss]]
|}

== Programme de test avancé ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C (modifie si besoin)
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Deuxième Makefile <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = at90usb1287
F_CPU = 16000000UL

# ========= LUFA =========
LUFA_PATH = ./LUFA

# Core USB (prend tous les .c du core + AVR8 pour éviter les soucis de noms)
LUFA_CORE_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Core/AVR8/*.c)

# Classe CDC côté Device (et commun) — uniquement CDC
LUFA_CLASS_SRC = \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Common/*CDC*.c) \
$(wildcard $(LUFA_PATH)/Drivers/USB/Class/Device/*CDC*.c)

# ========= Sources de ton projet =========
SRC = main.c hangman.c tetris.c timer.c serial.c Descriptors.c \
$(LUFA_CORE_SRC) $(LUFA_CLASS_SRC)
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -ffunction-sections -fdata-sections \
-I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I. \
-DUSE_LUFA_CONFIG_HEADER -I$(LUFA_PATH) -I$(LUFA_PATH)/Drivers -I.
LDFLAGS = -Wl,--gc-sections

# ========= Règles =========
.PHONY: all clean erase flash reset info
all: $(TARGET).hex

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

$(TARGET).hex: $(TARGET).elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

# -------- DFU workflow --------
info:
@echo "DFU: maintenir HWB, pulse RESET, relâcher RESET, relâcher HWB."
@echo "Ensuite: make erase && make flash && make reset"

erase:
dfu-programmer at90usb1287 erase

flash: $(TARGET).hex
dfu-programmer at90usb1287 flash $(TARGET).hex

reset:
dfu-programmer at90usb1287 reset
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|vignette]]
|}

== Démonstration de fonctionnement sur terminaux anciens ==

Vidéos de démonstration.

SE4 2024/2025 EC2

2025-08-20T20:57:21Z

Pcasimir : /* Programme de test ASCII */

= Objectifs =

Vous allez concevoir, réaliser et programmer un système embarqué de test de terminaux série assez souvent utilisés pour l'administration système et réseau.

Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C.

Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port.

Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de <code>gcc</code> et l'utilitaire <code>dfu-programmer</code>. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser <code>minicom</code> dans un premier temps.

Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour <code>minicom</code>. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte.

L'épreuve sera considérée comme un succès s'il est possible de jouer à tétris sur un des deux anciens terminaux.

Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec.

= Matériel nécessaire =

Le matériel nécessaire est constitué :
* d'un PC pour la conception de la carte et la mise au point du programme embarqué (à votre charge) ;
* d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ;
* de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août).

= Foire aux questions =

* L'épreuve complémentaire est-elle réalisable au domicile de l'élève ?

La conception de la carte est réalisable à domicile, la fabrication de la carte est prévue à l'extérieur (50 euros maximum, composants et port compris), il faut donc une adresse postale valide pour recevoir le PCB, la réalisation de la carte peut être externalisée (dans la limite des 50 euros) ou à domicile en utilisant un fer à souder personnel, le développement initial est réalisable sur l'Arduino fourni (et un PC personnel), les tests basiques et avancés sont réalisables à domicile (Arduino et PC personnel), le test sur les anciens terminaux est à prévoir fin août à l'école. Il n'est pas prévu d'accès aux ressources de l'école avant fin août.

* Où est disponible l'Arduino UNO ?

Comme indiqué dans le courriel du 15 juillet, le matériel est disponible à l'accueil de l'école. A rendre au premier septembre 2025.

* Comment programmer la carte ?

Comme indiqué dans le sujet, la carte doit pouvoir se programmer par DFU/USB. Il est conseillé d'utiliser un système d'exploitation Linux pour le développement du programme embarqué mais vous pouvez utiliser tout autre système du moment que vous assumez ce choix.

* Comment sera testée la carte réalisée ?

La carte sera testée par l'encadrant d'abord en utilisant l'utilitaire <code>minicom</code> avec son émulation VT100 sous un Linux mais l'élève peut tester son code avec tout autre outil. Un second test sera conduit sur les anciens terminaux série de l'école.

* Précisions sur les jeux "pendu" et "tétris"

Les jeux évoqués doivent pouvoir être joué à partir de l'écran et des touches des terminaux. Les éventuelles touches sur la cartes ne servent qu'à sélectionner le test et le protocole de commandes du terminal (VT100 ou autre).

= Travail réalisé =

=== COMPTE-RENDU DU 28/07/2025 ===

==== Préliminaires – Connexion d’un Arduino via USB à Minicom dans WSL2 ====
Dans ce projet, il est nécessaire de communiquer avec un microcontrôleur (ici, un '''Arduino Uno''') connecté en '''USB''' à un PC sous '''Windows 11''', en utilisant un outil typiquement '''Linux''' : '''Minicom''', un terminal série.

Or, Minicom ne fonctionne pas directement sur Windows, et nécessite un environnement Linux. Pour cette raison, nous avons mis en place un environnement '''WSL2''' (Windows Subsystem for Linux) avec '''Ubuntu''', capable d'accéder au port USB de l'Arduino.

Cette section détaille toutes les étapes techniques pour configurer correctement cette chaîne de communication entre :

* l’'''IDE Arduino''' sous Windows pour téléverser les programmes,
* l’environnement '''Ubuntu WSL2''' pour dialoguer via le terminal Minicom.

===== Environnement logiciel utilisé =====

* '''Système d’exploitation''' : Windows 11
* '''Distribution Linux via WSL2''' : Ubuntu 20.04
* '''Périphérique série utilisé''' : Arduino Uno
* '''Outils utilisés''' :
** WSL2
** usbipd-win (redirection USB vers WSL)
** <code>Minicom</code> (communication série Linux)

==== Redirection USB du port Arduino vers WSL ====
Par défaut, un port USB comme '''COM9''' sur Windows '''n'est pas visible directement''' sous WSL. Pour le rendre accessible à Ubuntu, il faut utiliser '''usbipd-win'''.

==== Installer usbipd ====
Dans PowerShell :

<syntaxhighlight lang="bash">winget install usbipd</syntaxhighlight>

Redémarrer le système W11 une fois l'installation terminée.

=== Identifier le port USB de l’Arduino ===
Branche l’Arduino via USB.

Dans PowerShell :

<syntaxhighlight lang="bash">usbipd list</syntaxhighlight>

Cela affiche tous les périphériques USB connectés.

<syntaxhighlight lang="bash">BUSID VID:PID DEVICE
1-1 2341:0043 Périphérique série USB (COM9)</syntaxhighlight>

Ici, le '''BUSID''' est <code>1-1</code> et l’Arduino est détecté sur le '''port COM9'''.

=== Partager puis attacher le port à WSL ===
Toujours dans PowerShell :

<syntaxhighlight lang="bash">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>

Vérifier dans Ubuntu que le port est bien présent
Dans Ubuntu (WSL) :
<syntaxhighlight lang="bash">ls /dev/tty*
/dev/tty /dev/tty21 /dev/tty35 /dev/tty49 /dev/tty62
/dev/tty0 /dev/tty22 /dev/tty36 /dev/tty5 /dev/tty63
/dev/tty1 /dev/tty23 /dev/tty37 /dev/tty50 /dev/tty7
/dev/tty10 /dev/tty24 /dev/tty38 /dev/tty51 /dev/tty8
/dev/tty11 /dev/tty25 /dev/tty39 /dev/tty52 /dev/tty9
/dev/tty12 /dev/tty26 /dev/tty4 /dev/tty53 /dev/ttyACM0
/dev/tty13 /dev/tty27 /dev/tty40 /dev/tty54 /dev/ttyS0
/dev/tty14 /dev/tty28 /dev/tty41 /dev/tty55 /dev/ttyS1
/dev/tty15 /dev/tty29 /dev/tty42 /dev/tty56 /dev/ttyS2
/dev/tty16 /dev/tty3 /dev/tty43 /dev/tty57 /dev/ttyS3
/dev/tty17 /dev/tty30 /dev/tty44 /dev/tty58 /dev/ttyS4
/dev/tty18 /dev/tty31 /dev/tty45 /dev/tty59 /dev/ttyS5
/dev/tty19 /dev/tty32 /dev/tty46 /dev/tty6 /dev/ttyS6
/dev/tty2 /dev/tty33 /dev/tty47 /dev/tty60 /dev/ttyS7
/dev/tty20 /dev/tty34 /dev/tty48 /dev/tty61
</syntaxhighlight>
Ce périphérique correspond à l’Arduino connecté en USB.
C’est ce port que Minicom utilisera pour la communication série.

Exemple de sketch Arduino pour test de communication
Ce sketch permet de tester si la communication fonctionne bien.
Téléverser via l’IDE Arduino sous Windows avant d’attacher le périphérique à WSL :
<syntaxhighlight lang="cpp">
void setup() {
Serial.begin(9600);
}

void loop() {
if (Serial.available()) {
char c = Serial.read();
Serial.print("Vous avez tapé : ");
Serial.println(c);
}
}</syntaxhighlight>

Alternance Windows ↔ WSL

Pour téléverser un sketch depuis Windows :
<syntaxhighlight lang="powershell">usbipd detach --busid 1-1</syntaxhighlight>
(Le périphérique redevient accessible dans l’IDE Arduino sous Windows)

Pour basculer la communication vers Ubuntu (Minicom) :
<syntaxhighlight lang="powershell">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>
Cette alternance peut être répétée autant que nécessaire.

= Documents Rendus =

== Projet KiCAD de la carte ==
Lien Gitea avec Code Arduino, Code C, Makefile, fichiers KiCAD : https://gitea.plil.fr/pcasimir/Test-Terminaux_Rattrapages-SE4-2025.git
{| class="wikitable"
|+
![[Fichier:Terminal-Testing SCH KiCAD.pdf|alt=Terminal-Testing SCH KiCAD|vignette|Terminal-Testing SCH KiCAD]]
|}

== Programme de test ASCII ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter si besoin) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetriss.mp4|vignette|Arduino UNO Minicom Pendu + Tetriss]]
|}

== Programme de test avancé ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C (modifie si besoin)
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|vignette]]
|}

== Démonstration de fonctionnement sur terminaux anciens ==

Vidéos de démonstration.

Fichier:Arduino UNO Minicom Pendu + Tetriss.mp4

2025-08-20T20:57:13Z

Pcasimir :

Arduino UNO Minicom Pendu + Tetriss

SE4 2024/2025 EC2

2025-08-18T12:50:22Z

Pcasimir : /* Projet KiCAD de la carte */

= Objectifs =

Vous allez concevoir, réaliser et programmer un système embarqué de test de terminaux série assez souvent utilisés pour l'administration système et réseau.

Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C.

Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port.

Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de <code>gcc</code> et l'utilitaire <code>dfu-programmer</code>. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser <code>minicom</code> dans un premier temps.

Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour <code>minicom</code>. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte.

L'épreuve sera considérée comme un succès s'il est possible de jouer à tétris sur un des deux anciens terminaux.

Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec.

= Matériel nécessaire =

Le matériel nécessaire est constitué :
* d'un PC pour la conception de la carte et la mise au point du programme embarqué (à votre charge) ;
* d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ;
* de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août).

= Foire aux questions =

* L'épreuve complémentaire est-elle réalisable au domicile de l'élève ?

La conception de la carte est réalisable à domicile, la fabrication de la carte est prévue à l'extérieur (50 euros maximum, composants et port compris), il faut donc une adresse postale valide pour recevoir le PCB, la réalisation de la carte peut être externalisée (dans la limite des 50 euros) ou à domicile en utilisant un fer à souder personnel, le développement initial est réalisable sur l'Arduino fourni (et un PC personnel), les tests basiques et avancés sont réalisables à domicile (Arduino et PC personnel), le test sur les anciens terminaux est à prévoir fin août à l'école. Il n'est pas prévu d'accès aux ressources de l'école avant fin août.

* Où est disponible l'Arduino UNO ?

Comme indiqué dans le courriel du 15 juillet, le matériel est disponible à l'accueil de l'école. A rendre au premier septembre 2025.

* Comment programmer la carte ?

Comme indiqué dans le sujet, la carte doit pouvoir se programmer par DFU/USB. Il est conseillé d'utiliser un système d'exploitation Linux pour le développement du programme embarqué mais vous pouvez utiliser tout autre système du moment que vous assumez ce choix.

* Comment sera testée la carte réalisée ?

La carte sera testée par l'encadrant d'abord en utilisant l'utilitaire <code>minicom</code> avec son émulation VT100 sous un Linux mais l'élève peut tester son code avec tout autre outil. Un second test sera conduit sur les anciens terminaux série de l'école.

* Précisions sur les jeux "pendu" et "tétris"

Les jeux évoqués doivent pouvoir être joué à partir de l'écran et des touches des terminaux. Les éventuelles touches sur la cartes ne servent qu'à sélectionner le test et le protocole de commandes du terminal (VT100 ou autre).

= Travail réalisé =

=== COMPTE-RENDU DU 28/07/2025 ===

==== Préliminaires – Connexion d’un Arduino via USB à Minicom dans WSL2 ====
Dans ce projet, il est nécessaire de communiquer avec un microcontrôleur (ici, un '''Arduino Uno''') connecté en '''USB''' à un PC sous '''Windows 11''', en utilisant un outil typiquement '''Linux''' : '''Minicom''', un terminal série.

Or, Minicom ne fonctionne pas directement sur Windows, et nécessite un environnement Linux. Pour cette raison, nous avons mis en place un environnement '''WSL2''' (Windows Subsystem for Linux) avec '''Ubuntu''', capable d'accéder au port USB de l'Arduino.

Cette section détaille toutes les étapes techniques pour configurer correctement cette chaîne de communication entre :

* l’'''IDE Arduino''' sous Windows pour téléverser les programmes,
* l’environnement '''Ubuntu WSL2''' pour dialoguer via le terminal Minicom.

===== Environnement logiciel utilisé =====

* '''Système d’exploitation''' : Windows 11
* '''Distribution Linux via WSL2''' : Ubuntu 20.04
* '''Périphérique série utilisé''' : Arduino Uno
* '''Outils utilisés''' :
** WSL2
** usbipd-win (redirection USB vers WSL)
** <code>Minicom</code> (communication série Linux)

==== Redirection USB du port Arduino vers WSL ====
Par défaut, un port USB comme '''COM9''' sur Windows '''n'est pas visible directement''' sous WSL. Pour le rendre accessible à Ubuntu, il faut utiliser '''usbipd-win'''.

==== Installer usbipd ====
Dans PowerShell :

<syntaxhighlight lang="bash">winget install usbipd</syntaxhighlight>

Redémarrer le système W11 une fois l'installation terminée.

=== Identifier le port USB de l’Arduino ===
Branche l’Arduino via USB.

Dans PowerShell :

<syntaxhighlight lang="bash">usbipd list</syntaxhighlight>

Cela affiche tous les périphériques USB connectés.

<syntaxhighlight lang="bash">BUSID VID:PID DEVICE
1-1 2341:0043 Périphérique série USB (COM9)</syntaxhighlight>

Ici, le '''BUSID''' est <code>1-1</code> et l’Arduino est détecté sur le '''port COM9'''.

=== Partager puis attacher le port à WSL ===
Toujours dans PowerShell :

<syntaxhighlight lang="bash">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>

Vérifier dans Ubuntu que le port est bien présent
Dans Ubuntu (WSL) :
<syntaxhighlight lang="bash">ls /dev/tty*
/dev/tty /dev/tty21 /dev/tty35 /dev/tty49 /dev/tty62
/dev/tty0 /dev/tty22 /dev/tty36 /dev/tty5 /dev/tty63
/dev/tty1 /dev/tty23 /dev/tty37 /dev/tty50 /dev/tty7
/dev/tty10 /dev/tty24 /dev/tty38 /dev/tty51 /dev/tty8
/dev/tty11 /dev/tty25 /dev/tty39 /dev/tty52 /dev/tty9
/dev/tty12 /dev/tty26 /dev/tty4 /dev/tty53 /dev/ttyACM0
/dev/tty13 /dev/tty27 /dev/tty40 /dev/tty54 /dev/ttyS0
/dev/tty14 /dev/tty28 /dev/tty41 /dev/tty55 /dev/ttyS1
/dev/tty15 /dev/tty29 /dev/tty42 /dev/tty56 /dev/ttyS2
/dev/tty16 /dev/tty3 /dev/tty43 /dev/tty57 /dev/ttyS3
/dev/tty17 /dev/tty30 /dev/tty44 /dev/tty58 /dev/ttyS4
/dev/tty18 /dev/tty31 /dev/tty45 /dev/tty59 /dev/ttyS5
/dev/tty19 /dev/tty32 /dev/tty46 /dev/tty6 /dev/ttyS6
/dev/tty2 /dev/tty33 /dev/tty47 /dev/tty60 /dev/ttyS7
/dev/tty20 /dev/tty34 /dev/tty48 /dev/tty61
</syntaxhighlight>
Ce périphérique correspond à l’Arduino connecté en USB.
C’est ce port que Minicom utilisera pour la communication série.

Exemple de sketch Arduino pour test de communication
Ce sketch permet de tester si la communication fonctionne bien.
Téléverser via l’IDE Arduino sous Windows avant d’attacher le périphérique à WSL :
<syntaxhighlight lang="cpp">
void setup() {
Serial.begin(9600);
}

void loop() {
if (Serial.available()) {
char c = Serial.read();
Serial.print("Vous avez tapé : ");
Serial.println(c);
}
}</syntaxhighlight>

Alternance Windows ↔ WSL

Pour téléverser un sketch depuis Windows :
<syntaxhighlight lang="powershell">usbipd detach --busid 1-1</syntaxhighlight>
(Le périphérique redevient accessible dans l’IDE Arduino sous Windows)

Pour basculer la communication vers Ubuntu (Minicom) :
<syntaxhighlight lang="powershell">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>
Cette alternance peut être répétée autant que nécessaire.

= Documents Rendus =

== Projet KiCAD de la carte ==
Lien Gitea avec Code Arduino, Code C, Makefile, fichiers KiCAD : https://gitea.plil.fr/pcasimir/Test-Terminaux_Rattrapages-SE4-2025.git
{| class="wikitable"
|+
![[Fichier:Terminal-Testing SCH KiCAD.pdf|alt=Terminal-Testing SCH KiCAD|vignette|Terminal-Testing SCH KiCAD]]
|}

== Programme de test ASCII ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter si besoin) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|gauche|vignette]]
|}

== Programme de test avancé ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C (modifie si besoin)
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|vignette]]
|}

== Démonstration de fonctionnement sur terminaux anciens ==

Vidéos de démonstration.

Fichier:Terminal-Testing SCH KiCAD.pdf

2025-08-18T12:50:09Z

Pcasimir :

Terminal-Testing SCH KiCAD

SE4 2024/2025 EC2

2025-08-18T12:24:55Z

Pcasimir : /* Projet KiCAD de la carte */

= Objectifs =

Vous allez concevoir, réaliser et programmer un système embarqué de test de terminaux série assez souvent utilisés pour l'administration système et réseau.

Les terminaux visés sont des terminaux logiciels comme <code>minicom</code> tournant sur un système d'exploitation moderne mais aussi d'ancien terminaux comme un Ampex 210 ou un Televideo TVI-920C.

Vous commencerez par concevoir votre carte dont le coeur doit être un microcontrôleur AVR et qui doit pouvoir se connecter en USB/série à un PC moderne mais aussi à d'anciens terminaux via des connecteurs DB9 et DB25 (voir les manuels des terminaux pour le brochage). L'utilisateur doit aussi pouvoir sélectionner le mode de test et le type de terminal. Une réflexion doit être menée sur l'alimentation de la carte. Vous avez le droit à un budget de 50 euros pour la carte, les composants et le port.

Une fois la carte conçue et validée par l'encadrant vous pourrez vous pencher sur la programmation de la carte. Cette programmation se fera uniquement en utilisant la version AVR de <code>gcc</code> et l'utilitaire <code>dfu-programmer</code>. Vous pouvez utiliser l'Arduino Uno fourni pour les premières versions de votre programme de test de terminaux. Comme terminal vous pouvez utiliser <code>minicom</code> dans un premier temps.

Le logiciel de test doit proposer plusieurs tests, un test fonctionnant en ASCII pur, par exemple un jeu de pendu et un jeu plus complexe utilisant des séquences de déplacement du curseur sur l'écran, par exemple un jeu tétris. Pour les séquences permettant l'adressage du curseur, vous pouvez utilisez le protocole VT100 pour <code>minicom</code>. Pour les terminaux plus anciens, vérifiez quels protocoles avancés de gestion d'affichage sont disponibles. Le cas échéant, faites en sorte que votre test avancé puisse utiliser des protocoles différents sélectionnés par l'utilisateur via les contrôles sur votre carte.

L'épreuve sera considérée comme un succès s'il est possible de jouer à tétris sur un des deux anciens terminaux.

Il s'agit là d'un cahier des charges initial qui peut être revu en cas d'ambigüité. Vous avez jusqu'au 1 septembre pour réaliser le travail demandé. Il vous est explicitement demandé de produire un travail régulier le plus tôt possible *et* de faire des rapports réguliers (obligatoirement au travers de ce Wiki) à votre encadrant. S'y prendre à la dernière minute avec un seul retour à quelques jours de la date limite est une garantie d'échec.

= Matériel nécessaire =

Le matériel nécessaire est constitué :
* d'un PC pour la conception de la carte et la mise au point du programme embarqué (à votre charge) ;
* d'un Arduino UNO pour le test de la version initiale de votre programme embarqué (fourni par l'encadrant) ;
* de terminaux Ampex 210 et Televideo TVI-920C (à utiliser à l'école fin août).

= Foire aux questions =

* L'épreuve complémentaire est-elle réalisable au domicile de l'élève ?

La conception de la carte est réalisable à domicile, la fabrication de la carte est prévue à l'extérieur (50 euros maximum, composants et port compris), il faut donc une adresse postale valide pour recevoir le PCB, la réalisation de la carte peut être externalisée (dans la limite des 50 euros) ou à domicile en utilisant un fer à souder personnel, le développement initial est réalisable sur l'Arduino fourni (et un PC personnel), les tests basiques et avancés sont réalisables à domicile (Arduino et PC personnel), le test sur les anciens terminaux est à prévoir fin août à l'école. Il n'est pas prévu d'accès aux ressources de l'école avant fin août.

* Où est disponible l'Arduino UNO ?

Comme indiqué dans le courriel du 15 juillet, le matériel est disponible à l'accueil de l'école. A rendre au premier septembre 2025.

* Comment programmer la carte ?

Comme indiqué dans le sujet, la carte doit pouvoir se programmer par DFU/USB. Il est conseillé d'utiliser un système d'exploitation Linux pour le développement du programme embarqué mais vous pouvez utiliser tout autre système du moment que vous assumez ce choix.

* Comment sera testée la carte réalisée ?

La carte sera testée par l'encadrant d'abord en utilisant l'utilitaire <code>minicom</code> avec son émulation VT100 sous un Linux mais l'élève peut tester son code avec tout autre outil. Un second test sera conduit sur les anciens terminaux série de l'école.

* Précisions sur les jeux "pendu" et "tétris"

Les jeux évoqués doivent pouvoir être joué à partir de l'écran et des touches des terminaux. Les éventuelles touches sur la cartes ne servent qu'à sélectionner le test et le protocole de commandes du terminal (VT100 ou autre).

= Travail réalisé =

=== COMPTE-RENDU DU 28/07/2025 ===

==== Préliminaires – Connexion d’un Arduino via USB à Minicom dans WSL2 ====
Dans ce projet, il est nécessaire de communiquer avec un microcontrôleur (ici, un '''Arduino Uno''') connecté en '''USB''' à un PC sous '''Windows 11''', en utilisant un outil typiquement '''Linux''' : '''Minicom''', un terminal série.

Or, Minicom ne fonctionne pas directement sur Windows, et nécessite un environnement Linux. Pour cette raison, nous avons mis en place un environnement '''WSL2''' (Windows Subsystem for Linux) avec '''Ubuntu''', capable d'accéder au port USB de l'Arduino.

Cette section détaille toutes les étapes techniques pour configurer correctement cette chaîne de communication entre :

* l’'''IDE Arduino''' sous Windows pour téléverser les programmes,
* l’environnement '''Ubuntu WSL2''' pour dialoguer via le terminal Minicom.

===== Environnement logiciel utilisé =====

* '''Système d’exploitation''' : Windows 11
* '''Distribution Linux via WSL2''' : Ubuntu 20.04
* '''Périphérique série utilisé''' : Arduino Uno
* '''Outils utilisés''' :
** WSL2
** usbipd-win (redirection USB vers WSL)
** <code>Minicom</code> (communication série Linux)

==== Redirection USB du port Arduino vers WSL ====
Par défaut, un port USB comme '''COM9''' sur Windows '''n'est pas visible directement''' sous WSL. Pour le rendre accessible à Ubuntu, il faut utiliser '''usbipd-win'''.

==== Installer usbipd ====
Dans PowerShell :

<syntaxhighlight lang="bash">winget install usbipd</syntaxhighlight>

Redémarrer le système W11 une fois l'installation terminée.

=== Identifier le port USB de l’Arduino ===
Branche l’Arduino via USB.

Dans PowerShell :

<syntaxhighlight lang="bash">usbipd list</syntaxhighlight>

Cela affiche tous les périphériques USB connectés.

<syntaxhighlight lang="bash">BUSID VID:PID DEVICE
1-1 2341:0043 Périphérique série USB (COM9)</syntaxhighlight>

Ici, le '''BUSID''' est <code>1-1</code> et l’Arduino est détecté sur le '''port COM9'''.

=== Partager puis attacher le port à WSL ===
Toujours dans PowerShell :

<syntaxhighlight lang="bash">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>

Vérifier dans Ubuntu que le port est bien présent
Dans Ubuntu (WSL) :
<syntaxhighlight lang="bash">ls /dev/tty*
/dev/tty /dev/tty21 /dev/tty35 /dev/tty49 /dev/tty62
/dev/tty0 /dev/tty22 /dev/tty36 /dev/tty5 /dev/tty63
/dev/tty1 /dev/tty23 /dev/tty37 /dev/tty50 /dev/tty7
/dev/tty10 /dev/tty24 /dev/tty38 /dev/tty51 /dev/tty8
/dev/tty11 /dev/tty25 /dev/tty39 /dev/tty52 /dev/tty9
/dev/tty12 /dev/tty26 /dev/tty4 /dev/tty53 /dev/ttyACM0
/dev/tty13 /dev/tty27 /dev/tty40 /dev/tty54 /dev/ttyS0
/dev/tty14 /dev/tty28 /dev/tty41 /dev/tty55 /dev/ttyS1
/dev/tty15 /dev/tty29 /dev/tty42 /dev/tty56 /dev/ttyS2
/dev/tty16 /dev/tty3 /dev/tty43 /dev/tty57 /dev/ttyS3
/dev/tty17 /dev/tty30 /dev/tty44 /dev/tty58 /dev/ttyS4
/dev/tty18 /dev/tty31 /dev/tty45 /dev/tty59 /dev/ttyS5
/dev/tty19 /dev/tty32 /dev/tty46 /dev/tty6 /dev/ttyS6
/dev/tty2 /dev/tty33 /dev/tty47 /dev/tty60 /dev/ttyS7
/dev/tty20 /dev/tty34 /dev/tty48 /dev/tty61
</syntaxhighlight>
Ce périphérique correspond à l’Arduino connecté en USB.
C’est ce port que Minicom utilisera pour la communication série.

Exemple de sketch Arduino pour test de communication
Ce sketch permet de tester si la communication fonctionne bien.
Téléverser via l’IDE Arduino sous Windows avant d’attacher le périphérique à WSL :
<syntaxhighlight lang="cpp">
void setup() {
Serial.begin(9600);
}

void loop() {
if (Serial.available()) {
char c = Serial.read();
Serial.print("Vous avez tapé : ");
Serial.println(c);
}
}</syntaxhighlight>

Alternance Windows ↔ WSL

Pour téléverser un sketch depuis Windows :
<syntaxhighlight lang="powershell">usbipd detach --busid 1-1</syntaxhighlight>
(Le périphérique redevient accessible dans l’IDE Arduino sous Windows)

Pour basculer la communication vers Ubuntu (Minicom) :
<syntaxhighlight lang="powershell">usbipd bind --busid 1-1
usbipd attach --busid 1-1 --wsl</syntaxhighlight>
Cette alternance peut être répétée autant que nécessaire.

= Documents Rendus =

== Projet KiCAD de la carte ==
Lien Gitea avec Code Arduino, Code C, Makefile, fichiers KiCAD : https://gitea.plil.fr/pcasimir/Test-Terminaux_Rattrapages-SE4-2025.git
{| class="wikitable"
|+
![[Fichier:Terminal-Testing SCH.pdf|alt=Terminal-Testing SCH|gauche|vignette|1080x1080px|Terminal-Testing SCH]]
|}

== Programme de test ASCII ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter si besoin) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|gauche|vignette]]
|}

== Programme de test avancé ==

Archive attachée avec <code>Makefile</code> intégré. <syntaxhighlight lang="makefile">
# ========= Projet =========
TARGET = program
MCU = atmega328p
F_CPU = 16000000UL

# Tes sources C (modifie si besoin)
SRC = main.c serial.c timer.c hangman.c tetris.c
OBJ = $(SRC:.c=.o)

# ========= Outils =========
CC = avr-gcc
OBJCOPY = avr-objcopy
CFLAGS = -mmcu=$(MCU) -DF_CPU=$(F_CPU) -Os -W -Wall -Wextra -std=c99

# ========= Port série (à adapter) =========
# Linux / WSL
PORT = /dev/ttyACM0
# Windows (exemple)
# PORT = COM4
# macOS (exemple)
# PORT = /dev/tty.usbmodem14101

# ========= avrdude (bootloader Optiboot UNO) =========
AVRDUDE = avrdude
PROGRAMMER = arduino
BAUD = 115200

# ========= dfu-programmer (ATmega16U2 en DFU) =========
DFU_CHIP = atmega16u2
# Met le chemin vers le firmware USB-série officiel Uno R3 (ou ton .hex LUFA)
# Exemples :
# - Arduino-usbserial-atmega16u2-Uno-Rev3.hex
# - Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex
FW16U2 = Arduino-usbserial-atmega16u2-Uno-Rev3.hex

# ========= Règles par défaut =========
.PHONY: all clean upload flash16u2 help

all: $(TARGET).hex

$(TARGET).elf: $(OBJ)
$(CC) $(CFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

%.hex: %.elf
$(OBJCOPY) -O ihex -R .eeprom $< $@

# ========= Téléversement sur l'ATmega328P (comme l'IDE Arduino) =========
upload: $(TARGET).hex
$(AVRDUDE) -p m328p -c $(PROGRAMMER) -P $(PORT) -b $(BAUD) -D -U flash:w:$<:i

# ========= Flash du 16U2 en DFU (optionnel) =========
flash16u2:
@if [ ! -f "$(FW16U2)" ]; then echo ">> ERREUR: FW16U2 introuvable: $(FW16U2)"; exit 1; fi
@echo ">> Assure-toi que l'ATmega16U2 est en mode DFU (RESET↔GND sur header ICSP du 16U2)."
dfu-programmer $(DFU_CHIP) erase
dfu-programmer $(DFU_CHIP) flash $(FW16U2)
dfu-programmer $(DFU_CHIP) reset
@echo ">> 16U2 reflashé. Le port série doit réapparaître."

clean:
rm -f $(OBJ) $(TARGET).elf $(TARGET).hex

help:
@echo "Cibles utiles :"
@echo " make -> compile et génère $(TARGET).hex"
@echo " make upload -> téléverse sur l'ATmega328P via bootloader (avrdude)"
@echo " make flash16u2 -> flashe le firmware du pont USB ATmega16U2 (dfu-programmer)"
@echo " make clean -> nettoyage"
</syntaxhighlight>Vidéos de démonstration avec <code>minicom</code>.
{| class="wikitable"
|+
![[Fichier:Arduino UNO Minicom Pendu + Tetris.mp4|vignette]]
|}

== Démonstration de fonctionnement sur terminaux anciens ==

Vidéos de démonstration.