adam/Paillasse
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ajoute le réseau pour OpenStack : dummy0, paire veth, NAT restreint au réseau externe

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Adam Belkacemi 2026-10-07 11:40:34 +02:00
parent e879a214a9
commit 87c8aac5f5
14 changed files with 247 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

44
docs/journal.md
View file

@ -105,3 +105,47 @@ Chiffrer avant d'envoyer (plutôt que de compter sur un transport chiffré) a un
**Suite**
Étape 4 : réseau pour OpenStack (`dummy0`, paire veth, NAT). Touche le réseau → accord explicite d'Adam obligatoire avant d'appliquer, filet anti-coupure, et redémarrage du serveur seulement avec son accord.
## 2026-10-07 — Étape 4 : réseau pour OpenStack
**Fait**
- Rôle Ansible `reseau-openstack` + playbook `ansible/reseau-openstack.yml` (qui rejoue aussi `durcissement` pour le pare-feu et son filet anti-coupure). Appliqué après accord explicite d'Adam, puis redémarrage avec son accord.
- `dummy0` : 10.10.0.1/24, futur `network_interface` / `kolla_internal_vip_address` (Kolla sans HAProxy).
- Paire veth : `veth-ext-ovs` (sans IP, futur `neutron_external_interface`) ↔ `veth-ext-gw` (172.24.4.1/24, passerelle du réseau externe OpenStack).
- Persistance par `systemd-networkd`, limité à ces trois interfaces : `eno1` reste sous `ifupdown`, inchangé.
- `net.ipv4.ip_forward=1` (`/etc/sysctl.d/99-reseau-openstack.conf`).
- nftables : NAT masquerade de 172.24.4.0/24 vers `eno1` (`/etc/nftables.d/10-nat-openstack.conf`, inclus depuis `/etc/nftables.conf`). Chaîne `forward` resserrée à la demande d'Adam : seulement `veth-ext-gw → eno1` depuis 172.24.4.0/24, et les réponses `eno1 → veth-ext-gw` (`established,related`). Tout le reste est refusé ; rien n'entre depuis Internet vers les réseaux internes.
**Règles nftables finales (relues après redémarrage)**
```
chain forward { policy drop;
iifname "veth-ext-gw" oifname "eno1" ip saddr 172.24.4.0/24 accept
iifname "eno1" oifname "veth-ext-gw" ct state established,related accept
}
table ip nat { chain postrouting {
ip saddr 172.24.4.0/24 oifname "eno1" masquerade
} }
```
**Problèmes rencontrés et solution**
- 1er lancement : `Destination directory /etc/nftables.d does not exist`. Le dossier était créé par `durcissement`, qui tourne après `reseau-openstack`. Échec survenu avant toute modification du pare-feu. Corrigé en créant aussi le dossier dans `reseau-openstack`.
- Un lancement a été bloqué par le garde-fou de Claude Code parce que la règle `forward` avait été modifiée après l'accord d'Adam sans lui être remontrée. On a fait une simulation `--check --diff`, Adam a validé le diff, puis on a appliqué.
- Table `f2b-table` de fail2ban absente après rechargement du pare-feu et après redémarrage : c'est normal, fail2ban 1.0 ne la crée qu'au premier bannissement. Point encore à vérifier : `flush ruleset` à chaque rechargement efface une table de bannissement déjà créée. fail2ban devrait la recréer au bannissement suivant (vérification automatique de ses actions), mais ce n'est pas encore testé.
**Critère vérifié (après redémarrage à 11:37, SSH revenu à 11:39)**
- SSH répond, `dummy0` et la paire veth sont présents avec leurs IP, `ip_forward=1`.
- Internet joignable depuis le serveur (ping 9.9.9.9, résolution de `deb.debian.org`), route par défaut inchangée.
- Services actifs : ssh, nftables, fail2ban, chrony, systemd-networkd, timer de sauvegarde. RAID `[UU]` sur `md0` et `md1`.
- `nmap` depuis le Mac : seul le port 22 est ouvert.
**Comprendre**
OpenStack a besoin de deux réseaux en plus de l'accès public : un réseau interne pour que ses services se parlent, et un réseau « externe » pour que les routeurs virtuels puissent sortir. Sur un serveur qui n'a qu'une seule IP publique, mettre Neutron directement sur `eno1` reviendrait à lui confier notre seule porte d'entrée. On a donc créé des interfaces virtuelles : `dummy0`, une carte réseau factice qui porte une adresse privée stable pour les services, et une paire veth, qui fonctionne comme un câble virtuel dont un bout ira à Neutron et l'autre sert de passerelle. Le NAT fait sortir ce réseau externe vers Internet en se faisant passer pour l'IP publique. Le pare-feu n'autorise que ce sens-là, plus les réponses, si bien que personne ne peut entrer depuis Internet vers les réseaux internes. Le redémarrage prouve que tout cela est persistant, et pas seulement appliqué en mémoire.
**Suite**
Étape 5 : Kolla-Ansible 2025.2 tout-en-un. `bootstrap-servers` peut toucher au pare-feu et à Docker : vérifier avant, rejouer `durcissement` après, et demander l'accord d'Adam pour ce qui touche au pare-feu.