La Redirection de Ports
From Scratch, Docker & Podman
Comment acheminer le trafic de la carte réseau physique hôte (`eth0`) vers un socket enfermé dans un Network Namespace isolé ?
Le conteneur possède sa propre adresse IP privée (`172.17.0.2`) invisible depuis l'extérieur. La redirection de port est le pont qui traduit les requêtes de l'hôte (`192.168.1.50:8080`) vers le port interne du conteneur (`172.17.0.2:80`).
L'Anatomie du Réseau Isolant
Pourquoi la redirection de port est-elle obligatoire ?
192.168.1.50:8080 (IP Publique/LAN Hôte)⬇️ [Redirection de Port / NAT]
Pont Virtuel
docker0 / br0 ➔ 172.17.0.1⬇️ [Paire Veth : veth-host ➔ veth-guest]
Conteneur Isolé ➔
172.17.0.2:80 (Port interne du conteneur)
🖼️ Port Forwarding From Scratch (Kernel NAT)
Comment faire avec Netfilter / IPTables sans aucun moteur ?
- Activer le transfert de paquets IPv4 au niveau du noyau :
- Appliquer une règle **DNAT (Destination NAT)** dans la table `nat` :
- (Alternative en espace utilisateur sans iptables) Utiliser `socat` :
Le Modèle Hybride de Docker
IPTables (DNAT) + le binaire auxiliaire `docker-proxy`.
Docker intercepte le trafic venant des cartes externes via une chaîne personnalisée `DOCKER` dans `iptables`.
Pour les requêtes `localhost:8080`, Linux contourne parfois `PREROUTING`. Docker lance donc un processus Go léger par port publié pour relayer les sockets localement.
La Révolution Podman (Rootless & Daemonless)
Comment faire sans privilèges root et sans modifier `iptables` ?
Simule une pile TCP/IP complète en **espace utilisateur**. Écoute le port non privilégié de l'utilisateur (>1024) et réinjecte le trafic dans le namespace sans aucun droit root.
Nouveau moteur par défaut ultra-rapide (Pass-Through Adapter). Redirige directement les descripteurs de fichiers sockets sans recopie mémoire, atteignant des performances proches du Kernel NAT.
Performances & Surcoût Réseau
Comparatif de latence et consommation processeur/mémoire.
Zéro surcoût en espace utilisateur. Le processeur traite la paquets directement dans les cartes réseau.
Consommation RAM légère (~4 Mo par `docker-proxy`). Traitement Kernel très rapide pour le trafic externe.
Surcoût quasi nul avec `pasta`. Légère consommation CPU en mode `slirp4netns` lors des pics à très haut débit.
Bypass du Port Forwarding
Quand et comment se passer complètement de la redirection de ports ?
Le conteneur partage **directement** le Network Namespace de l'hôte. Il écoute directement sur l'IP physique (`192.168.1.50:80`).
Avantage : Performance maximale | Inconvénient : Zéro isolation réseauAttribue une véritable adresse MAC et IP physique du réseau local au conteneur. Le conteneur apparaît comme un serveur physique distinct sur le switch/routeur.
Avantage : Pas de NAT | Inconvénient : Exige le mode promiscuousTableau Comparatif 3-Voies
| Critère | From Scratch (Noyau Pure) | Docker (Démon Root) | Podman (Rootless) |
|---|---|---|---|
| Privilèges Requis | Root (`CAP_NET_ADMIN`) | Démon Root (`dockerd`) | Utilisateur normal (Unprivileged) |
| Moteur de Redirection | Kernel Netfilter (DNAT) / `socat` | IPTables + `docker-proxy` | `slirp4netns` ou `pasta` |
| Modification IPTables | Manuelle (`iptables -t nat`) | Automatique (Chaîne `DOCKER`) | Aucune (Espace Utilisateur) |
| Démon Résident | Aucun | Oui (`dockerd`) | Aucun (Daemonless) |
| Consommation Mémoire | 0 Mo extra (Noyau) | ~4-10 Mo par port (`docker-proxy`) | ~5-15 Mo (`pasta` / `slirp4netns`) |
Commandes Utiles de Diagnostic
Comment inspecter et déboguer les redirections de ports ?
Synthèse & Prochaines Étapes
Vous maîtrisez désormais les rouages du réseau conteneurisé.