Conteneurs LXC : du réseau NAT au mode bridge

Contexte et objectif

Ce TP porte sur la virtualisation par conteneurs. L'objectif était de comprendre comment un conteneur obtient sa connectivité réseau et en quoi ces mécanismes diffèrent de ceux d'une machine virtuelle classique. Le fil conducteur est le réseau : où se situe la frontière entre le conteneur et l'hôte, le trafic est-il traduit, et quelle visibilité le conteneur a-t-il depuis le LAN.

Ce que j'ai réalisé

J'ai installé LXC sur une VM Debian 13 après avoir vérifié le support du noyau.
J'ai observé le réseau NAT par défaut (pont interne et règle de masquage) puis créé et administré un premier conteneur.
J'ai basculé le conteneur en mode bridge pour en faire une machine du LAN à part entière.
J'ai validé le résultat avec un serveur Apache hébergé dans le conteneur et consulté depuis le poste physique.

Difficultés rencontrées et solutions

La bascule en mode bridge échouait alors que la configuration était correcte : absence totale de connectivité.
Première hypothèse (adresse MAC du pont refusée par l'hyperviseur) écartée par l'observation de la table de voisinage.
Cause réelle : deux routes concurrentes pour le même sous-réseau, entretenues par un client DHCP resté actif sur l'ancienne configuration. Un service actif sur une configuration périmée annulait chaque correction.
Support de TP daté : adaptation à Debian 13 (modèle de conteneur récent, nftables, cgroups v2).

Résultats

Conteneur joignable directement depuis le LAN.
Trois indicateurs du basculement relevés : l'adresse passe du réseau interne au réseau du LAN, la passerelle passe de l'hôte au routeur, le TTL passe de 117 à 64.
La partie Docker du sujet n'a pas pu être menée dans le temps imparti, et le compte rendu le dit clairement.

Ce que j'en retiens

En NAT, le conteneur est caché derrière l'hôte : simple, sans impact sur le LAN, mais injoignable sans redirection. En bridge, il devient une machine du réseau, au prix d'une exposition accrue. L'apport le plus solide de la séance reste le diagnostic : comprendre pourquoi un service oublié peut annuler silencieusement chaque correction relève exactement du type de panne rencontré en exploitation.