Le réseau : un pare-feu, un WAN, un LAN

L’idée reçue

« Mes VMs ont Internet, donc le réseau est réglé. »

Pour l’instant, tes machines sont branchées « en direct » sur le réseau du serveur, sans aucune protection. En production, jamais : on place un pare-feu à l’entrée, on sépare l’extérieur (WAN) d’un réseau privé (LAN), et on décide qui a le droit de parler à qui. C’est ce que tu vas construire — et le voir fonctionner.

Avant de commencer : prends un snapshot de tes deux VMs. Cette phase déplace les cartes réseau, et pendant la manœuvre tu perdras temporairement l’accès. Le snapshot est ton filet.

À la fin de cette phase, tu sauras…

Distinguer WAN (Internet) et LAN (réseau privé), et pourquoi on les sépare
Créer un switch virtuel (bridge) isolé dans Proxmox
Obtenir une IP publique dédiée via une MAC virtuelle OVH
Installer OPNsense comme pare-feu entre WAN et LAN
Activer un DHCP sur le LAN et réserver une IP fixe pour le serveur Jenkins

01Deux réseaux, pas un seul

Expérience 1

Crée le switch virtuel du LAN

Aujourd’hui, tes VMs sont sur vmbr0 — le pont relié à l’extérieur (ce sera le WAN). On va créer un second pont, vmbr1, sans carte physique : un switch purement interne, le futur LAN. Dans Proxmox : nœud → System → Network → Create → Linux Bridge.

Réglage	Valeur
Name	`vmbr1`
Bridge ports	(vide — aucun port physique)
Commentaire	LAN interne

Applique la configuration (Apply Configuration). Tu viens de créer un réseau local privé, isolé, qui n’existe que dans ton serveur.

Comprends WAN et LAN, pourquoi séparer ?

Le WAN (Wide Area Network) est le côté Internet, exposé et hostile. Le LAN (Local Area Network) est ton réseau privé, où vivent tes serveurs à l’abri. Entre les deux, un pare-feu filtre tout. Un switch virtuel (bridge) est l’équivalent logiciel d’un switch réseau physique : il relie les machines d’un même réseau.

02Une IP publique rien qu’à toi (MAC virtuelle OVH)

Expérience 2

Relier l’IP publique OVH directement au pare-feu

Tu disposes d’une IP publique supplémentaire (une « IP Failover / additionnelle » déjà achetée). Pour que ton pare-feu la porte lui-même — sans passer par l’IP de Proxmox — OVH exige que la carte réseau qui l’utilise ait une adresse MAC virtuelle générée par eux.

Dans l’espace client OVH : Bare Metal Cloud → ton serveur → IP. Repère ton IP publique additionnelle, puis « ajouter une MAC virtuelle » (type OVH) sur cette IP. OVH te donne une adresse du style 02:00:00:xx:xx:xx.

Note cette MAC virtuelle : on va l’attribuer à la carte WAN d’OPNsense. Ainsi, le réseau OVH « reconnaît » le pare-feu comme propriétaire légitime de l’IP publique.

Comprends pourquoi une MAC virtuelle, et pas du NAT ?

Le réseau OVH n’accepte de router une IP publique que vers une adresse MAC qu’il connaît. La MAC virtuelle est ce « laissez-passer » : elle autorise une seconde machine (ton OPNsense) à porter l’IP publique directement. Résultat : le pare-feu a sa propre IP publique, sans NAT compliqué au niveau de Proxmox. C’est la façon propre de faire du réseau en cloud — et ça fait partie de ce que tu apprends ici.

03Installer OPNsense entre les deux mondes

Expérience 3

Un pare-feu avec deux cartes : WAN et LAN

Télécharge l’ISO d’OPNsense dans Proxmox (/var/lib/vz/template/iso), puis crée une VM opnsense avec deux cartes réseau :

Carte	Pont	Rôle	MAC
net0 (WAN)	`vmbr0`	Internet / OVH	la MAC virtuelle OVH
net1 (LAN)	`vmbr1`	réseau privé	auto

Sur la carte net0, remplace la MAC générée par celle d’OVH (champ « MAC address » dans le matériel de la VM). C’est l’étape clé qui lie l’IP publique au pare-feu.

Démarre la VM, ouvre sa console, installe OPNsense, puis assigne les interfaces : WAN = vtnet0, LAN = vtnet1. Configure le WAN avec l’IP publique OVH (IP, passerelle OVH, masque /32 selon la doc OVH), et le LAN avec une IP privée, par exemple 192.168.10.1/24.

Comprends le pare-feu est une « porte » entre deux réseaux

OPNsense a un pied dans chaque monde : une carte sur le WAN (Internet), une sur le LAN (privé). Tout ce qui entre ou sort passe par lui. Il route le trafic, et surtout il filtre : par défaut, il laisse sortir le LAN vers Internet, mais bloque tout ce qui vient de l’extérieur. C’est le rôle d’un pare-feu.

04Donner des adresses au LAN (DHCP)

Expérience 4

Depuis l’interface web d’OPNsense, active le DHCP

Pour joindre l’interface graphique d’OPNsense, on branche temporairement debian-gui sur le LAN (vmbr1) et on lui met une IP fixe dans le même réseau (ex. 192.168.10.50). Depuis son navigateur, ouvre https://192.168.10.1 (l’IP LAN d’OPNsense).

Dans OPNsense : Services → DHCPv4 → LAN. Active-le et définis une plage, par exemple de 192.168.10.100 à 192.168.10.200.

Désormais, toute VM branchée sur le LAN recevra automatiquement une adresse dans cette plage. Plus besoin de configurer chaque IP à la main.

Comprends DHCP, en une phrase

Le DHCP distribue automatiquement les adresses IP aux machines qui se connectent au réseau, avec la passerelle et le DNS. Sans lui, il faudrait configurer chaque machine à la main. C’est OPNsense qui joue ce rôle sur ton LAN.

05Faire entrer les serveurs dans le LAN

Expérience 5

Déplacer debian-cli et debian-gui derrière le pare-feu

Maintenant que le LAN distribue des adresses, on y rapatrie les serveurs. Pour chaque VM (debian-cli, debian-gui), dans Proxmox → Hardware → carte réseau → change le pont de vmbr0 vers vmbr1.

Manipule

sudo systemctl restart networking
ip -brief address

Observe

ens18  UP   192.168.10.101/24    # une IP fournie par le DHCP d'OPNsense

La VM a reçu une adresse du LAN, automatiquement. Elle est maintenant derrière le pare-feu : elle sort vers Internet via OPNsense, mais n’est plus exposée en direct.

Comprends ce qui vient de changer, en sécurité

Avant, tes serveurs étaient exposés directement à Internet. Maintenant, ils sont dans un réseau privé, derrière OPNsense. Pour les atteindre depuis l’extérieur, il faudra une règle explicite sur le pare-feu. C’est le principe de base d’une infrastructure sûre : fermé par défaut, ouvert au cas par cas.

06Une adresse fixe pour Jenkins (réservation DHCP)

Expérience 6

Un serveur doit garder la même adresse

Un serveur comme Jenkins ne doit pas changer d’IP à chaque redémarrage. On lui réserve une adresse fixe, liée à sa carte réseau. Récupère d’abord la MAC de debian-cli :

Manipule

ip link show ens18

Observe

link/ether bc:24:11:aa:bb:cc ...   # la MAC de la carte

Dans OPNsense : Services → DHCPv4 → LAN → Réservations, ajoute une entrée qui associe cette MAC à une IP fixe, par exemple 192.168.10.10. Redémarre debian-cli et vérifie.

Comprends réservation vs IP statique

Plutôt que de figer l’IP dans la VM elle-même, on laisse le DHCP décider — mais on lui dit : « cette carte (cette MAC) aura toujours cette IP ». C’est propre : la gestion des adresses reste centralisée dans OPNsense. Jenkins sera toujours joignable sur 192.168.10.10:8080.

✓Ce que tu retiens

Tes machines ont désormais une vraie architecture réseau : un WAN qui porte une IP publique dédiée (via MAC virtuelle OVH), un pare-feu OPNsense à l’entrée, et un LAN privé où vivent tes serveurs, avec un DHCP et une IP réservée pour Jenkins. C’est exactement l’ossature réseau d’une infrastructure de production.

Mini-projet

Vérifie ton architecture réseau

Prouve que tout est en place, et documente le schéma.

À faire

Depuis debian-cli, prouve l’accès à Internet à travers OPNsense : ping -c 2 debian.org.
Confirme que Jenkins garde son IP réservée après un redémarrage (ip -brief address).
Depuis debian-gui (sur le LAN), ouvre à nouveau http://192.168.10.10:8080 : Jenkins répond.
Prends un snapshot de chaque VM nommé phase2-ok.
Dans BookStack, dessine (ou décris) le schéma : Internet → WAN OPNsense → LAN → serveurs. Explique WAN, LAN, DHCP.

Critères de réussite

Les VMs accèdent à Internet uniquement via OPNsense.
Jenkins est joignable sur son IP réservée, stable après reboot.
Snapshots phase2-ok présents.
Schéma réseau clair dans BookStack.

Fil rouge — Tu as un réseau propre et un serveur stable. À la Phase 3, on arrête de déployer « à la main » : on découvre Docker et les conteneurs, pour empaqueter une application proprement — la première brique de ta future mise en production.

?Auto-évaluation

1. Quelle est la différence entre WAN et LAN ?

Le WAN est le côté Internet (exposé) ; le LAN est le réseau privé où vivent tes serveurs, à l’abri derrière le pare-feu.

2. À quoi sert la MAC virtuelle OVH ?

Elle autorise OPNsense à porter directement l’IP publique, car le réseau OVH ne route une IP que vers une MAC qu’il connaît — sans NAT complexe côté Proxmox.

3. Pourquoi réserver une IP pour Jenkins plutôt qu’une simple attribution DHCP ?

Un serveur doit rester joignable à la même adresse. La réservation lie sa MAC à une IP fixe, tout en gardant la gestion centralisée dans OPNsense.