Un réseau de lab a besoin des mêmes services de base qu'un vrai réseau : quelqu'un doit distribuer les adresses, résoudre les noms et faire sortir le trafic vers Internet. Dans ce lab, ce rôle est tenu par une machine virtuelle dédiée : la passerelle. Elle est la première brique construite, et tout le reste en dépend.
Pourquoi une machine dédiée
Libvirt sait déjà faire du NAT et distribuer des adresses. Pourquoi s'en priver ? Pour trois raisons.
- On veut un vrai serveur DNS, autoritaire sur une zone, capable de servir un enregistrement wildcard — ce que le DHCP intégré de libvirt ne fait pas.
- On veut maîtriser le plan d'adressage : adresses fixes pour les nœuds, plage DHCP séparée pour les postes de passage.
- Et surtout : ces services doivent rester en dehors du cluster Kubernetes. Un cluster qui dépendrait de son propre DNS pour être diagnostiqué serait un piège.
Deux pattes, deux mondes
Une interface vers le réseau de la maison (DHCP), une interface fixe sur le réseau du lab : c'est la définition même d'une passerelle.
La machine reçoit deux interfaces réseau :
- enp1s0, côté WAN, sur le réseau NAT de libvirt, en DHCP — elle donne l'accès au réseau de la maison et à Internet ;
- enp2s0, côté LAN, en adresse fixe 192.168.50.254/24 sur le réseau interne du lab.
La configuration passe par netplan, l'outil de configuration réseau d'Ubuntu :
network:
version: 2
ethernets:
enp1s0:
dhcp4: true
enp2s0:
dhcp4: false
addresses:
- 192.168.50.254/24
netplan generate # valide la syntaxe netplan apply # applique
Prendre l'habitude de lancer netplan generate avant apply évite de perdre la main sur une machine distante à cause d'une faute d'indentation.
Router et masquer : le rôle de passerelle
Deux choses à activer : le routage IP dans le noyau, et le NAT pour que les machines du lab, adressées en privé, puissent sortir.
net.ipv4.ip_forward=1
Le filtrage et la traduction d'adresses sont confiés à nftables, le successeur d'iptables. La logique tient en quatre règles :
table ip edupf
chain postrouting { type nat hook postrouting priority 100; }
oifname "enp1s0" ip saddr 192.168.50.0/24 masquerade
chain forward { type filter hook forward priority 0; policy drop; }
ct state established,related accept
iifname "enp2s0" oifname "enp1s0" ip saddr 192.168.50.0/24 accept
Deux détails valent qu'on s'y arrête. D'abord la politique par défaut à « drop » sur la chaîne de transit : rien ne traverse la passerelle sauf ce qui est explicitement autorisé — le lab vers Internet, et les réponses au trafic déjà établi. Ensuite, l'ensemble est enfermé dans une table dédiée, détruite et recréée à chaque exécution : le script est ainsi rejouable sans effet cumulatif, et ne perturbe pas d'éventuelles autres règles.
Le tout est encapsulé dans un script, lui-même déclenché par une unité systemd de type oneshot — c'est ce qui garantit que les règles sont réappliquées à chaque démarrage :
[Unit] Description=K3S Lab Gateway (routing + NAT) After=network-online.target Wants=network-online.target [Service] Type=oneshot ExecStart=/opt/passerelle/gw.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target
Le DNS : la pièce vraiment structurante
C'est ici que se joue la souplesse du lab. Le serveur BIND9 est installé avec ses outils de vérification :
apt install -y bind9 bind9-utils dnsutils
Les options importantes de la configuration globale :
options {
listen-on { 127.0.0.1; 192.168.50.254; };
listen-on-v6 { none; };
allow-query { localhost; 192.168.50.0/24; };
recursion yes;
allow-recursion { localhost; 192.168.50.0/24; };
forwarders { 192.168.2.20; };
forward only;
version "not disclosed";
};
La ligne à ne pas rater est allow-recursion limitée au réseau local. Un serveur DNS récursif ouvert à tous — un open resolver — est une arme d'amplification pour attaques par déni de service ; c'est le genre d'erreur qu'on ne fait qu'une fois.
La zone interne labk3s.ev1 déclare ensuite les machines du lab :
$TTL 1h
@ IN SOA ns1.labk3s.ev1. admin.labk3s.ev1. (
2026011501 ; Serial — à incrémenter à chaque modification
1h 15m 7d 1h )
@ IN NS ns1.labk3s.ev1.
ns1 IN A 192.168.50.254
gw IN A 192.168.50.254
kube-01 IN A 192.168.50.11
kube-02 IN A 192.168.50.12
kube-03 IN A 192.168.50.13
Le numéro de série doit être incrémenté à chaque modification : c'est lui qui indique aux serveurs secondaires — et au serveur lui-même après rechargement — que la zone a changé. Un fichier modifié sans incrément est un fichier qui semble ne rien changer, et c'est la source d'erreur numéro un.
Avant tout rechargement, deux commandes de contrôle :
named-checkconf named-checkzone labk3s.ev1 /etc/bind/zones/db.labk3s.ev1 dig @127.0.0.1 ns1.labk3s.ev1 +short
Plus tard, quand le cluster sera exposé, il suffira d'ajouter une seule ligne à cette zone — un enregistrement wildcard — pour que toutes les applications du cluster deviennent joignables par leur nom. C'est le sujet du sixième article.
Le DHCP : pour tout ce qui n'est pas serveur
Les nœuds Kubernetes ont des adresses fixes ; en revanche, un poste client de passage doit obtenir une adresse automatiquement. C'est le rôle d'isc-dhcp-server, restreint à l'interface du LAN :
option domain-name "labk3s.ev1";
option domain-name-servers 192.168.50.254;
subnet 192.168.50.0 netmask 255.255.255.0 {
range 192.168.50.100 192.168.50.200;
option routers 192.168.50.254;
}
Le plan d'adressage se lit alors d'un coup d'œil : .1 à .99 pour les serveurs à adresse fixe, .100 à .200 pour le DHCP, et le haut de la plage réservé aux adresses de service du cluster. Découper l'espace d'adressage avant d'en avoir besoin évite les collisions ridicules six mois plus tard.
Ce qu'on a gagné
À ce stade, le lab a un réseau qui se comporte comme un vrai : les machines obtiennent une adresse, se résolvent par leur nom, sortent vers Internet, et rien ne traverse la passerelle sans autorisation explicite. Les nœuds Kubernetes peuvent être installés.
Le pas à pas détaillé est sur le wiki
Cet article ne remplace pas la documentation : il en explique les choix. L'intégralité de la démarche — commandes, sorties d'écran, vérifications et captures — est publiée sur mon wiki, dans la section Datacenter / Cluster K3S. Pages correspondant à cet article :
La série « Lab Kubernetes maison »
Cet article fait partie d'une série qui monte, pas à pas, un cluster Kubernetes complet sur une seule machine physique :