Daniel Allaire c9d31e9a60 preuves : trois gardes pour ce que ma lecture ne tiendra pas

Une revision de documentation vieillit comme le reste. Ce qui tient, c est ce
qu une machine verifie — et trois lacunes etaient nommees sans etre gardees.

P58  HABILITATIONS. autorisation.md posait la regle (un service nomme un
     GROUPE, jamais une personne, D-66) et meta/acces.yml la portait ; rien ne
     la verifiait. P29 gardait les POSITIONS d authentification, personne ne
     gardait les DROITS.

     Le controle qui porte la preuve est un croisement : une entree
     porte_par: role-realm affirme que l habilitation voyage par un role de
     realm projete depuis un groupe LDAP. P58 le confronte a serveur_keycloak.
     Sans ca, un service annonce une habilitation que rien ne transporte, et l
     ecran reste vide sans que personne sache pourquoi.

     CE QU ELLE N EXIGE PAS, et c est le point le plus important : que les
     groupes nommes existent dans l annuaire. Ce serait contredire le regime du
     paragraphe 2 — le depot AMORCE un acces et se retire, les appartenances
     appartiennent a une personne. dev et personnel n existent dans aucun code,
     et ce n est pas un defaut.

P59  ENUMERATIONS ANNONCEES. Les deux ecarts trouves a la main pendant la
     tournee — cinq portes annoncees devant une table de six, huit lignes
     renvoyees vers une fiche qui en compte dix — etaient d une forme que P57
     ne voit pas.

     Ma premiere version a signale CINQ ecarts, et les cinq etaient du bruit :
     dans « reprise dans les deux devis : », le nombre qualifie autre chose que
     la liste. Cent pour cent de faux positifs — la preuve qui crie sur un cas
     sain et qu on apprend a ignorer. Resserree aux deux formes ou le nombre ne
     peut compter rien d autre. Etroite et vraie plutot que large et devineuse.

P60  WIKI PUBLIE. Le wiki est publie DEPUIS le depot ; rien ne mesurait l ecart,
     et il s est creuse de VINGT-SEPT JOURS en silence. Deux unites jamais
     publiees, vingt et une differentes : pour qui lit la forge plutot que le
     depot, toute la revision n existait pas.

     Le harnais est STATIQUE, zero appel reseau — cloner la forge romprait la
     seule propriete qui fasse qu une preuve vaille hors de ce poste. La mesure
     passe donc par un TEMOIN que make wiki-publier depose. Amorce avec la
     valeur MESUREE : le wiki d eregion porte b6167f2, dont le message dit
     source: ac85278.

     Ce qu elle ne prouve pas : un temoin dit ce qui est PARTI, jamais ce qui
     est ARRIVE.

LES TROIS SONT EPROUVEES DANS LES DEUX SENS

Douze essais negatifs, douze refus : groupe non projete, acces.yml disparu,
personne au lieu d un groupe, mecanisme invente, raison manquante, compte
revenu a cinq, septieme porte ajoutee sans toucher au compte, renvoi croise
fausse, temoin absent, temoin d un autre depot. Une garantie qu on n a jamais vu
dire non n est pas une garantie, c est une habitude.

ETAT : NON CONFORME, 58 OK, 1 echec, 1 saute.

P60 est rouge, et c est le comportement voulu : le registre a le droit de
perdre. Le retard qu elle signale est reel et anterieur a elle. Une commande le
ferme, et elle vient ensuite.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

2026-09-08 12:47:18 -04:00

7.2 KiB

Raw Blame History

Le réseau des tenants — du câble au VRF

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

C'est la partie de Set-OPS qui emploie le plus de mots obscurs — underlay, VXLAN, VNet, VRF, strophe FRR. Aucun n'est là par goût du jargon : chacun répond à un problème précis, et on peut les rencontrer dans l'ordre où ils sont apparus.

① Le concept

Le problème de départ : deux clients sur le même fil

Deux organisations hébergées sur le même matériel ne doivent pas se voir. Or leurs machines partagent des câbles, des commutateurs, des hyperviseurs. Il faut donc séparer ce qui est physiquement mélangé.

Première réponse : le VLAN

Un VLAN colle une étiquette (un nombre) sur chaque trame. Deux machines n'échangent que si leurs étiquettes correspondent. C'est simple, ça marche, et c'est vieux de trente ans.

Deux limites :

l'étiquette tient sur 12 bits — 4094 VLAN, pas un de plus ;
chaque commutateur du chemin doit connaître chaque VLAN. Ajouter un client, c'est toucher à la configuration de tout le monde.

Deuxième réponse : l'encapsulation

VXLAN prend la trame d'un tenant, la met dans une enveloppe et l'expédie comme un colis ordinaire d'un hyperviseur à l'autre. Le réseau physique ne voit passer que des colis — il n'a plus besoin de connaître les clients.

Deux vocabulaires en découlent, et c'est la distinction la plus utile de cette page :


underlay	le réseau physique : les câbles, les commutateurs, les adresses des hyperviseurs. Il ne connaît aucun tenant.
overlay	les réseaux virtuels des tenants, transportés dans des enveloppes par-dessus l'underlay.

L'enveloppe coûte 50 octets. C'est toute l'explication du mtu_overlay: 1450 : 1450 + 50 = 1500, la taille standard d'une trame. Se tromper là ne casse rien franchement — les petites requêtes passent, les grosses réponses restent suspendues. C'est la panne la plus déroutante du domaine.

Qui distribue les enveloppes : EVPN

Pour expédier un colis, il faut savoir où l'envoyer. EVPN est le mécanisme par lequel les hyperviseurs s'annoncent mutuellement les machines qu'ils hébergent. Sans lui, il faudrait tenir cette table à la main.

Le VRF : une table de routage étanche

Un routeur ordinaire a une table de routage. Un VRF lui en donne plusieurs, hermétiques : dans la table du tenant A, les réseaux du tenant B n'existent pas. Ce n'est pas une règle de pare-feu qu'on pourrait oublier — c'est une ignorance structurelle.

C'est la différence entre « je t'interdis d'y aller » et « la route n'existe pas ».

② Dans Set-OPS

Ce que tu écris, et ce qui se calcule

Tu écris un nombre : index. Tout le reste en découle.

index: 29
  ↓
supernet    10.29.0.0/16
VLAN        1000 + 29×10 + zone     →  1291, 1292, 1293…
zone SDN    t29
VNet        t29fron, t29serv, t29donn, t29appl
sous-réseau 10.29.16.0/24, 10.29.17.0/24 …

Un VNet est le réseau virtuel d'une zone d'un tenant : le point où les cartes réseau des VM se branchent. Une VM de la zone Frontière du tenant 29 se branche sur t29fron, et nulle part ailleurs.

Trois commandes, trois questions

Commande	Question à laquelle elle répond
`make underlay`	mon réseau physique est-il cohérent, et n'empiète-t-il pas sur les tenants ?
`make sdn-plan`	ce que le cluster porte diffère-t-il de ce que le plan décrit ? (aucune écriture)
`make sdn-appliquer`	pose la différence — et retire ce qui est périmé

sdn-plan avant sdn-appliquer, toujours. La seconde écrit sur le cluster et sur les hyperviseurs ; la première ne fait que regarder.

La strophe FRR

FRR est le démon de routage des hyperviseurs. Set-OPS lui pose un bloc par tenant — ce que le dépôt appelle une strophe — dans /etc/frr/frr.conf.local, sur chaque nœud de sortie :

vrf vrf_t29
 ip route 0.0.0.0/0 10.0.4.1 nexthop-vrf default
 ip route 10.29.0.0/16 blackhole
exit-vrf

La première ligne, c'est la sortie. Tout ce qui ne concerne pas le tenant part vers la frontière. nexthop-vrf default emprunte une seule adresse à la table principale au lieu de l'importer en entier : importer aurait fait entrer dans le VRF le transport VXLAN, le plan de gestion et les VLAN hérités — et permis de contourner la frontière.

La deuxième ligne, c'est un puits. Elle attrape les adresses non attribuées du tenant. Elle est moins précise que les /24 des VNets, donc le trafic légitime ne la voit jamais.

Sans ce puits (mesuré le 2026-08-09) : une adresse inexistante ne trouvait aucune route locale, sortait par le défaut, revenait de la frontière vers l'hyperviseur, atterrissait dans la table principale — et repartait vers la passerelle du réseau d'administration. Deux conséquences : le trafic d'un tenant pouvait atteindre le plan de gestion par une faute de frappe, et connect() réussissait vers n'importe quelle adresse inexistante. Ce qu'on avait longtemps pris pour une protection de la frontière n'était qu'une route manquante ici.

Le fichier ne se sauvegarde pas : il se régénère. Il porte son avertissement en tête — « NE PAS ÉDITER À LA MAIN ». La source de vérité est le plan.

③ Transférable

Rien de tout ça n'appartient à Set-OPS. Ce sont les briques de n'importe quel réseau multi-locataire :

underlay / overlay : le vocabulaire de tous les centres de données depuis 2015 ;
VXLAN + EVPN : la même paire chez tous les hébergeurs, du garage à AWS ;
VRF : présent sur tout routeur professionnel, et sur Linux depuis 2016 ;
le puits (blackhole) : une pratique standard d'anti-fuite.

Ce que Set-OPS ajoute n'est pas de la technologie, c'est une dérivation : ailleurs, ces objets se saisissent à la main, un par un, dans quatre interfaces différentes. Ici, ils descendent tous d'un seul nombre — donc ils ne peuvent pas se contredire.

④ À toi de jouer

Lis ton réseau physique : make underlay. Repère les VLAN sous 1000 (l'underlay) et les MTU. Pourquoi le transport doit-il être à 1500 quand l'overlay est à 1450 ?
Regarde sans écrire : make sdn-plan. Si le cluster dit déjà ce que le plan dit, la sortie tient en une ligne.
Trouve la sortie d'un tenant : dans make devis-sdn, repère la strophe FRR et l'adresse du prochain saut. À quel équipement appartient-elle ?
Change index dans un modèle (jamais en production) et régénère : combien de valeurs ont bougé ? C'est la mesure exacte de ce que la dérivation t'épargne.

Pour aller plus loin : docs/sdn-evpn.md dans le dépôt (référence technique), Le plan & l'adressage dérivé, Multi-instance & fédération.

Le lien vers docs/ était relatif (../docs/…) : il fonctionne dans le dépôt et casse une fois le wiki publié, la forge ne recevant que le contenu de wiki/. C'est pourquoi le corpus cite docs/ en texte, jamais en lien — une seule page dérogeait.

7.2 KiB Raw Blame History Unescape Escape