Profil de provisionnement et image(s) pour un routeur/pare-feu de site #1

New issue

Open

opened 2026-10-13 07:31:39 +00:00 by julien.blond · 0 comments

julien.blond commented

2026-10-13 07:31:39 +00:00

Owner

Contexte

hamac provisionne aujourd'hui des postes (profil dev-workstation) et suppose que le réseau du site existe déjà : routage, DHCP et DNS sont assurés par un équipement externe que hamac ne touche pas (voir docker/hamac-pxe/README.md). Ce rôle est souvent tenu par un appareil de type Turris/OpenWrt, installé et maintenu à la main.

L'objectif est que hamac sache provisionner ce routeur/pare-feu de site lui-même, sur un serveur physique ou une VM, pour que sa configuration découle du modèle de hamac au lieu de vivre à côté.

Rôle à couvrir

WAN : client DHCP derrière la box du fournisseur d'accès, IPv4 et IPv6, avec demande de délégation de préfixe (DHCPv6-PD).
Segmentation : VLAN 802.1Q sur un lien trunk vers un switch manageable, une zone de pare-feu par VLAN.
Pare-feu nftables : politique inter-zones fermée par défaut, NAT, redirections de ports déclarées avec restriction des sources autorisées.
DHCP par zone, avec annonce systématique d'un serveur DNS (option 6). Une zone sans DNS annoncé échoue sans aucune erreur visible côté routeur.
IPv6 interne : annonces de routeur et DHCPv6 par zone à partir du préfixe délégué, plus un vrai préfixe ULA (fd00::/8) indépendant du fournisseur.
Résolveur DNS récursif validant (DNSSEC), avec ancre de confiance gérée automatiquement (RFC 5011), état persistant et alerte si la mise à jour de l'ancre échoue. Noms locaux alimentés par les baux DHCP.
Concentrateur VPN WireGuard : pairs déclarés, MTU et clamping MSS adaptés au tunnel.
NTP pour le site.
Coexistence avec hamac-pxe : les machines du site doivent pouvoir continuer à démarrer en PXE (options DHCP ou DHCP proxy).
Observabilité : métriques (node-exporter) et journaux exportés.

Système d'exploitation et image(s)

Le routeur est l'équipement le plus exposé du site : il faut un OS à TCB réduite, robuste et reconnue.

Principe : écrire le bundle contre des composants empaquetés par Debian (nftables, systemd-networkd, Kea ou dnsmasq, Knot Resolver ou Unbound, WireGuard, chrony). Debian apporte une équipe sécurité, un support long et des constructions reproductibles, et la configuration générée par hamac ne dépend alors pas de l'image qui l'embarque.

Images, de la plus disponible à la plus réduite :

Debian minimale (debootstrap minbase et les seuls paquets du rôle), dans la chaîne actuelle : qcow2 canonique, dérivés raw/bmap pour le bare-metal (cf. doc/PROVISIONING_SPEC.md).
Image minimale composée paquet par paquet à partir des mêmes paquets Debian : elle ne contient que la fermeture des dépendances déclarées, avec un inventaire exact et une construction reproductible. C'est la cible pour réduire la TCB. Mêmes binaires et mêmes formats de configuration que (1), donc le bundle ne change pas d'une image à l'autre.

Pistes non retenues comme cible principale :

Alpine : base plus petite (musl, busybox), mais support de deux ans par version et reproductibilité moins avancée ; l'option 2 apporte déjà l'essentiel de la minimalité. Elle reste une piste pour réduire encore la base, au prix d'un univers binaire et de configurations de services distincts.
OpenWrt : système de routeur natif, mais sans cloud-init (configuration par uci-defaults), et une configuration uci qui se prête mal à une génération depuis le modèle.

Dans tous les cas, l'image intègre tous ses paquets : un routeur ne peut pas les télécharger au premier démarrage, encore moins lors d'une reprise après panne, quand il n'y a justement plus de routeur. Variantes à prévoir : amd64 avec ses dérivés bare-metal, et une variante VM pour les tests.

Points à trancher

Machines à plusieurs cartes réseau : associer les rôles (WAN, trunk LAN) aux interfaces par adresse MAC au moment du provisionnement.
État à conserver : clés privées WireGuard, état de l'ancre DNSSEC, baux DHCP. Reprovisionner le routeur ne doit pas les perdre ; ils sont fournis par les paramètres ou secrets de la machine.
Bascule : provisionner le nouveau routeur pendant que l'ancien assure encore DHCP et PXE, basculer, et garder un retour arrière possible.
Vérification du filtrage : les règles inter-zones du routeur doivent être testées comme celles des nœuds, pas seulement générées.

Critères d'acceptation

Un profil de provisionnement (nom à fixer, par exemple site-router) et son bundle, sur le modèle de provisioning-profiles/dev-workstation.yaml.
Construction de l'image et de ses dérivés bare-metal documentée et reproductible.
Démonstration en VM : un WAN et au moins deux zones, DHCP, DNS validant et NAT fonctionnels, flux inter-zones non déclaré effectivement refusé.
Installation sur un serveur physique via hamac-pxe.
Reprovisionner le routeur redonne une configuration identique, sans perte de l'état à conserver.

## Contexte hamac provisionne aujourd'hui des postes (profil `dev-workstation`) et suppose que le réseau du site existe déjà : routage, DHCP et DNS sont assurés par un équipement externe que hamac ne touche pas (voir `docker/hamac-pxe/README.md`). Ce rôle est souvent tenu par un appareil de type Turris/OpenWrt, installé et maintenu à la main. L'objectif est que hamac sache provisionner ce routeur/pare-feu de site lui-même, sur un serveur physique ou une VM, pour que sa configuration découle du modèle de hamac au lieu de vivre à côté. ## Rôle à couvrir - **WAN** : client DHCP derrière la box du fournisseur d'accès, IPv4 et IPv6, avec demande de délégation de préfixe (DHCPv6-PD). - **Segmentation** : VLAN 802.1Q sur un lien trunk vers un switch manageable, une zone de pare-feu par VLAN. - **Pare-feu nftables** : politique inter-zones fermée par défaut, NAT, redirections de ports déclarées avec restriction des sources autorisées. - **DHCP par zone**, avec annonce systématique d'un serveur DNS (option 6). Une zone sans DNS annoncé échoue sans aucune erreur visible côté routeur. - **IPv6 interne** : annonces de routeur et DHCPv6 par zone à partir du préfixe délégué, plus un vrai préfixe ULA (`fd00::/8`) indépendant du fournisseur. - **Résolveur DNS récursif validant** (DNSSEC), avec ancre de confiance gérée automatiquement (RFC 5011), état persistant et alerte si la mise à jour de l'ancre échoue. Noms locaux alimentés par les baux DHCP. - **Concentrateur VPN WireGuard** : pairs déclarés, MTU et clamping MSS adaptés au tunnel. - **NTP** pour le site. - **Coexistence avec hamac-pxe** : les machines du site doivent pouvoir continuer à démarrer en PXE (options DHCP ou DHCP proxy). - **Observabilité** : métriques (node-exporter) et journaux exportés. ## Système d'exploitation et image(s) Le routeur est l'équipement le plus exposé du site : il faut un OS à **TCB réduite, robuste et reconnue**. Principe : écrire le bundle contre des **composants empaquetés par Debian** (nftables, systemd-networkd, Kea ou dnsmasq, Knot Resolver ou Unbound, WireGuard, chrony). Debian apporte une équipe sécurité, un support long et des constructions reproductibles, et la configuration générée par hamac ne dépend alors pas de l'image qui l'embarque. Images, de la plus disponible à la plus réduite : 1. **Debian minimale** (debootstrap `minbase` et les seuls paquets du rôle), dans la chaîne actuelle : qcow2 canonique, dérivés raw/bmap pour le bare-metal (cf. `doc/PROVISIONING_SPEC.md`). 2. **Image minimale composée paquet par paquet** à partir des mêmes paquets Debian : elle ne contient que la fermeture des dépendances déclarées, avec un inventaire exact et une construction reproductible. C'est la cible pour réduire la TCB. Mêmes binaires et mêmes formats de configuration que (1), donc le bundle ne change pas d'une image à l'autre. Pistes non retenues comme cible principale : - **Alpine** : base plus petite (musl, busybox), mais support de deux ans par version et reproductibilité moins avancée ; l'option 2 apporte déjà l'essentiel de la minimalité. Elle reste une piste pour réduire encore la base, au prix d'un univers binaire et de configurations de services distincts. - **OpenWrt** : système de routeur natif, mais sans cloud-init (configuration par `uci-defaults`), et une configuration uci qui se prête mal à une génération depuis le modèle. Dans tous les cas, l'image intègre tous ses paquets : un routeur ne peut pas les télécharger au premier démarrage, encore moins lors d'une reprise après panne, quand il n'y a justement plus de routeur. Variantes à prévoir : amd64 avec ses dérivés bare-metal, et une variante VM pour les tests. ## Points à trancher - **Machines à plusieurs cartes réseau** : associer les rôles (WAN, trunk LAN) aux interfaces par adresse MAC au moment du provisionnement. - **État à conserver** : clés privées WireGuard, état de l'ancre DNSSEC, baux DHCP. Reprovisionner le routeur ne doit pas les perdre ; ils sont fournis par les paramètres ou secrets de la machine. - **Bascule** : provisionner le nouveau routeur pendant que l'ancien assure encore DHCP et PXE, basculer, et garder un retour arrière possible. - **Vérification du filtrage** : les règles inter-zones du routeur doivent être testées comme celles des nœuds, pas seulement générées. ## Critères d'acceptation - [ ] Un profil de provisionnement (nom à fixer, par exemple `site-router`) et son bundle, sur le modèle de `provisioning-profiles/dev-workstation.yaml`. - [ ] Construction de l'image et de ses dérivés bare-metal documentée et reproductible. - [ ] Démonstration en VM : un WAN et au moins deux zones, DHCP, DNS validant et NAT fonctionnels, flux inter-zones non déclaré effectivement refusé. - [ ] Installation sur un serveur physique via hamac-pxe. - [ ] Reprovisionner le routeur redonne une configuration identique, sans perte de l'état à conserver.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

OSS/hamac#1

No description provided.

Rows
Columns