journal : pare-feu Proxmox et nftables des edges poses ; route du poste vers le site

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -30,6 +30,23 @@ l'Internet, tout `externe` reçu, aucune source vide, exclusions en `nomatch`.
 **Le web frontal** ne déclare encore que le 80 depuis l'edge : le rendre public (son propre
 TLS, sa redirection à la frontière) est l'étape suivante, pas celle-ci.
 
+**Posé.** Pare-feu Proxmox (depuis le runner du site) : 2 IPSets `internet`, 8 groupes mis à
+jour, convergé (0 écart). Premier passage : Proxmox a refusé `frag-needed` — nom nftables ;
+l'API attend `fragmentation-needed` (`ICMP_PROXMOX` dans le devis). Les autres règles des
+groupes `srv-debian` étaient restées en place (SSH 13/13 chez chaque locataire, ping de
+supervision). Nftables des trois edges, après simulation : les deux « toute source »
+retirées, 80 réservé à l'administration. Depuis le poste : Dovecot 993 répond (TLS 1.3) chez
+les deux locataires — il était rejeté par la VM — ; `vigie`/`auth` en 443 (302) et 80 (301
+vers HTTPS) par leurs noms.
+
+**Une régression, de ma part : le poste ne joint plus l'edge du SITE.** Il a une route par
+son lien de gestion (10.37.0.17) vers `10.17.0.0/16` et `10.23.0.0/16`, mais aucune vers les
+zones du site (`10.37.x`) : il y va par le wifi (`192.168.13.254`) et arrive à l'edge avec une
+adresse hors administration. Seule la règle « toute source » le laissait passer ; je ne l'ai
+vu qu'après l'avoir retirée (le contrôle d'avant, sur les journaux d'accès, ne montrait que
+des adresses internes — la traduction en route cachait le chemin). Remède sur le poste,
+comme pour les tenants : `10.37.0.0/16 via 10.37.0.1` sur la connexion filaire.
+
 ## 2026-09-29 (32) — L'edge expose aux personnes ; entre machines du site, on va au service
 
 **La règle, énoncée par l'exploitant** : l'edge sert à exposer des interfaces web ; les