docs(vpn): mise à jour du suivi – flux web OK et étude wildcard Infomaniak

SUIVI_VPN_ONDEMAND.md

@@ -130,17 +130,105 @@ docker exec studioe5-caddy curl -sS -I -H "Host: test-wp-001.studioe5.edudeploy.
 curl -sS -I -L https://test-wp-001.studioe5.edudeploy.com/
 ```
 
+## 🌐 Flux complet testé via l’API web
+
+Test réalisé le 2026-06-23 en utilisant le compte superadmin :
+
+1. **Authentification NextAuth** sur `/api/auth/callback/credentials`.
+2. **Création d’instance** via `POST /api/instances` :
+   ```json
+   {
+     "nodeId": "vps-8fc665eb",
+     "templateId": "wordpress-wordpress-latest",
+     "port": 8002
+   }
+   ```
+   → Instance créée : `cmqqgrur20001lw67t2bdgzkg`.
+3. Le serveur a automatiquement envoyé l’action `start` au node via WebSocket.
+4. L’agent a démarré le VPN (si besoin), écrit le compose et a lancé les conteneurs WordPress.
+5. Caddy a obtenu un certificat Let’s Encrypt pour `cmqqgrur20001lw67t2bdgzkg.studioe5.edudeploy.com`.
+6. **Validation HTTPS** :
+   ```bash
+   curl -sS -I -L https://cmqqgrur20001lw67t2bdgzkg.studioe5.edudeploy.com/
+   # => HTTP/2 302 -> HTTP/2 200 (WordPress install.php)
+   ```
+
+Le flux `UI → API → WebSocket → agent → Docker → VPN → Caddy → HTTPS public` est fonctionnel.
+
 ## 📋 Prochaines étapes à faire
 
 - [x] ~~Attendre la fin du rate limit Let’s Encrypt~~ (levé le 2026-06-23).
 - [x] ~~Relancer un test HTTPS sur `https://test-wp-001.studioe5.edudeploy.com/`~~ → **OK** (HTTP/2 200).
-- [ ] **Nettoyer l’instance test et l’agent test**, puis **committer les modifications** (il reste beaucoup de fichiers modifiés/non suivis ; voir `git status`).
+- [x] ~~Créer une branche dédiée et commiter les modifications VPN on-demand~~ → branche `feat/studioe5-vpn-ondemand`, commit `124543d`. Push vers Gitea à faire dès que le remote sera accessible (actuellement `localhost:3001` et `gitea.alfrednobel.edudeploy.com` injoignables).
-- [ ] **Si le wildcard DNS est stable**, envisager d’obtenir un certificat wildcard unique pour `*.studioe5.edudeploy.com` (évite d’émettre un certificat par instance et donc de retomber dans les rate limits). À étudier côté Caddy (`tls { on_demand }` vs certificat wildcard géré manuellement).
+- [x] ~~Tester le flux complet depuis l’interface web~~ → **OK** via l’API authentifiée (`POST /api/instances`), instance `cmqqgrur20001lw67t2bdgzkg` accessible en HTTPS public.
-- [ ] **Tester le flux complet depuis l’interface web** (activation d’un élève, création d’instance via l’UI).
+- [ ] **Obtenir un certificat wildcard** pour `*.studioe5.edudeploy.com` (voir étude ci-dessous).
+- [ ] **Nettoyer les instances/agent de test** une fois le wildcard en place et le push effectué.
 - [ ] **Packager les binaires Tailscale pour Windows** dans `agent/tailscale-bin/windows/`.
 - [ ] **Nettoyer les anciens nodes/volumes Headscale** créés pendant les tests.
 - [ ] **Documenter la procédure de mise en production** pour le client A (config agent, clés Headscale, ports, etc.).
 
+## 🔒 Étude certificat wildcard `*.studioe5.edudeploy.com`
+
+### Pourquoi passer en wildcard ?
+
+Avec `tls { on_demand }`, Caddy émet **un certificat Let’s Encrypt par sous-domaine d’instance**. Cela expose au rate limit de 50 certificats par domaine principal (`edudeploy.com`) sur 7 jours. Un certificat wildcard unique (`*.studioe5.edudeploy.com`) couvre tous les sous-domaines d’instances et évite ce problème.
+
+### Contrainte technique
+
+Un certificat wildcard nécessite le **challenge DNS-01** (le challenge HTTP-01 ne permet pas de valider `*.domain.tld`). Caddy doit donc pouvoir créer un enregistrement TXT automatiquement chez le registrar DNS.
+
+### Infomaniak (registrar actuel)
+
+Le DNS de `edudeploy.com` est chez **Infomaniak** :
+```bash
+dig NS edudeploy.com +short
+# nsany1.infomaniak.com.
+# nsany2.infomaniak.com.
+```
+
+Il existe un module Caddy DNS pour Infomaniak :
+- Repository : `github.com/caddy-dns/infomaniak`
+- Nécessite un **token API Infomaniak** avec droits DNS.
+
+### Implémentation à envisager
+
+1. **Générer un token API Infomaniak** (compte client A ou compte dédié avec accès au domaine).
+2. **Builder une image Caddy custom** avec le module :
+   ```dockerfile
+   FROM caddy:2-builder AS builder
+   RUN xcaddy build --with github.com/caddy-dns/infomaniak
+
+   FROM caddy:2-alpine
+   COPY --from=builder /usr/bin/caddy /usr/bin/caddy
+   ```
+3. **Modifier le `Caddyfile`** pour gérer le wildcard :
+   ```caddy
+   *.studioe5.edudeploy.com {
+       tls {
+           dns infomaniak {env.INFOMANIAK_API_TOKEN}
+       }
+       reverse_proxy resolver:2020 {
+           header_up Host {host}
+       }
+   }
+   ```
+4. **Ajouter le token dans `.env`** et le passer au conteneur Caddy.
+5. Supprimer ou ajuster le bloc `:443` actuel qui utilise `on_demand` pour les instances.
+
+### Alternative sans module DNS
+
+Obtenir le certificat wildcard manuellement (Certbot DNS-01, acheté, etc.) et le charger dans Caddy :
+```caddy
+*.studioe5.edudeploy.com {
+    tls /data/certs/wildcard.crt /data/certs/wildcard.key
+    reverse_proxy resolver:2020 {
+        header_up Host {host}
+    }
+}
+```
+
+Inconvénient : renouvellement manuel.
+
 ## 🔧 Notes techniques
 
 - Le conteneur `resolver-vpn` utilise `network_mode: service:resolver` pour partager le netns avec le resolver.