Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity

journal : le REJECT est instantane — quatre RST en quatre secondes
Some checks are pending
verifier / verifier (push) Waiting to run
Details

Browse source 
J avais presente 3,05 s comme le signal d un refus. Faux, et l exploitant a eu
raison de le contester : c etait l ARP qui abandonne pour une machine inexistante.

La mesure qui tranche n est pas le delai mais le COMPTEUR : tcp-reset 17 -> 21
pendant une sonde de 4 s, un RST par retransmission du SYN. Le refus part
immediatement, chaque fois.

Ce qui manquait etait le RETOUR : ip route get rendait src 10.17.21.1, une
passerelle ANYCAST. Le RST revient au noeud qui porte cette adresse dans le VRF,
pas a la socket emettrice. Troisieme instrument fautif de la journee, et celui-ci
etait deja documente.

Entre deux VM d un tenant — le cas reel — la source est une adresse propre et le
routage inter-zone ne la reecrit pas : le refus arrive instantanement. L artefact
ne vaut que depuis un hyperviseur.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
This commit is contained in:
Daniel Allaire 2026-08-28 16:51:43 -04:00
parent 4beb7e0724
commit c918a50257
1 changed files with 34 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
CHANGELOG.md
View file

@ -68,6 +68,40 @@ Chezlepro n'en a qu'une.
créée, 0 retirée. Le changement ne ferme rien — `REJECT` et `DROP` refusent tous deux,
l'un répond.
### Le REJECT est instantané — et c'est mon instrument qui disait le contraire
J'avais présenté « 3,05 s » comme le signal d'un refus. **C'était faux, et l'exploitant a
eu raison de le contester** : un REJECT répond en microsecondes. Ces 3 secondes étaient
l'ARP qui abandonne pour une machine inexistante — aucun pare-feu n'était impliqué.
Puis, sondé depuis l'hyperviseur, un port non déclaré a expiré à 8 s. La mesure qui tranche
n'est pas le délai mais le **compteur** :
```
compteur tcp-reset AVANT : 17
sonde vers ops-01:9999 (non déclaré) → TimeoutError en 4,001 s
compteur tcp-reset APRÈS : 21
```
**Quatre RST émis en quatre secondes**, un par retransmission du SYN. Le refus part
immédiatement, chaque fois. Ce qui manquait, c'était le retour :
```
ip route get 10.17.19.41 -> dev vrf_t17 src 10.17.21.1
```
`10.17.21.1` est une **passerelle anycast**. Le RST revient au nœud qui porte cette adresse
dans le VRF, pas à la socket émettrice. *Troisième instrument fautif de la journée, et
celui-ci était déjà documenté — « anycast n'est pas une source de test ».*
**Entre deux VM d'un tenant — le cas réel — la source est une adresse propre, et le
routage inter-zone ne la réécrit pas : le refus arrive instantanément.** L'artefact ne
vaut que depuis un hyperviseur.
*Ce qui manque n'est donc pas dans le pare-feu, c'est une sonde qui rapporte l'errno et le
délai au lieu de les écraser dans un « échec ».*
make verifier : vert. make prouver : CONFORME, 53 OK, 0 echec, 0 saute.
## 2026-08-28 — L'insémination aboutit : un runner de tenant, né d'un runner de site