edubox/SUIVI_VPN_ONDEMAND.md

Suivi – VPN on-demand studioE5 (client A)

✅ Ce qui fonctionne

1. Agent standalone (mode console / systray)

   • Exécutable : agent/studioE5-agent
   • Config lu depuis <data-dir>/studioE5-config.json
   • Mode console : -no-tray

2. VPN on-demand dans l'agent

   • L’agent ne démarre plus Tailscale au boot.
   • Le VPN se lance automatiquement à la création/démarrage d’une instance, ou sur commande serveur.
   • Implémentation basée sur les binaires tailscaled + tailscale up (pas tsnet, car tsnet ne loguait pas automatiquement avec une authkey sur un state vierge).

3. Commandes serveur → agent

   • Endpoint de test : POST /api/internal/send-to-node
   • Actions supportées : start_vpn, stop_vpn, start, stop, reset, delete.

4. Resolver/serveur dans le tailnet studioe5

   • Service resolver-vpn (conteneur Tailscale) partage le netns du resolver.
   • Le resolver peut joindre les IPs Tailscale des nodes (ping 100.64.0.x OK).

5. Instance WordPress démarrée avec succès

   • Le resolver a renvoyé une 302 WordPress via http://resolver:2020/.

✅ Blocage levé

Rate limit Let’s Encrypt pour edudeploy.com est levé.
Le 2026-06-23 vers 09:35 UTC, Caddy a pu obtenir un certificat Let’s Encrypt pour test-wp-001.studioe5.edudeploy.com :

tls.obtain: certificate obtained successfully identifier=test-wp-001.studioe5.edudeploy.com issuer=acme-v02.api.letsencrypt.org-directory

Le flux complet HTTPS public est désormais validé :

curl -sS -I -L https://test-wp-001.studioe5.edudeploy.com/
# => HTTP/2 302 -> HTTP/2 200 (WordPress install.php)

Le DNS wildcard *.studioe5.edudeploy.com est en place. Caddy utilise toujours tls { on_demand } et émet un certificat par sous-domaine d’instance.

🎯 Validation du flux HTTPS public

Le 2026-06-23 09:39 UTC, le flux complet a été validé :

Client (HTTPS) → Caddy (:443) → resolver (:2020) → Tailnet (100.64.0.8) → agent → WordPress (:8001)

Résultat :

$ curl -sS -I -L https://test-wp-001.studioe5.edudeploy.com/
HTTP/2 302
location: https://test-wp-001.studioe5.edudeploy.com/wp-admin/install.php
...
HTTP/2 200

• Certificat Let’s Encrypt obtenu automatiquement par Caddy (tls { on_demand }).
• Le resolver réécrit les en-têtes Location et le contenu HTML pour passer de http:// à https://.

📁 Fichiers modifiés (non exhaustif)

• agent/tailscale.go – lancement tailscaled + tailscale up, gestion start/stop/status.
• agent/websocket.go – handlers start_vpn / stop_vpn, ensureTailscale().
• agent/docker.go – remplacement des placeholders {PORT} et {INSTANCE_ID} dans les compose.
• docker-compose.yml – ajout du sidecar resolver-vpn, suppression des cap_add/ip route obsolètes sur server/resolver.
• Caddyfile – configuration on-demand TLS pour les instances.
• .env – clé pré-auth Headscale mise à jour (clé réutilisable).

🧪 Tests / environnement de test actuel

Agent de test lancé en arrière-plan :

• data-dir : /tmp/studioe5-test-clienta
• node-id : vps-8fc665eb
• tailnet IP actuelle : 100.64.0.8
• PID : 3151830 (lancé le 2026-06-23 09:36 UTC)

Instance de test créée :

• ID : test-wp-001
• Node : vps-8fc665eb
• Port : 8001
• Template : wordpress-wordpress-latest
• État : WordPress répond sur http://127.0.0.1:8001 et en HTTPS public sur https://test-wp-001.studioe5.edudeploy.com/.

🛠️ Commandes utiles pour reprendre

Voir l’agent de test

pgrep -a studioe5-agent

Relancer l’agent de test (si besoin)

mkdir -p /tmp/studioe5-test-clienta
cat > /tmp/studioe5-test-clienta/studioE5-config.json <<EOF
{
  "server": "wss://studioe5.edudeploy.com/api/websocket",
  "headscale_url": "https://headscale.studioe5.edudeploy.com",
  "headscale_auth_key": "$(grep HEADSCALE_AUTH_KEY /opt/studioe5-client-a/.env | cut -d= -f2)",
  "node_id": "vps-8fc665eb",
  "data_dir": "/tmp/studioe5-test-clienta"
}
EOF
cd /opt/studioe5-client-a/agent
./studioE5-agent -no-tray -data-dir /tmp/studioe5-test-clienta

Démarrer le VPN manuellement

curl -sS -X POST https://studioe5.edudeploy.com/api/internal/send-to-node \
  -H "Content-Type: application/json" \
  -d '{"nodeId":"vps-8fc665eb","message":{"action":"start_vpn"}}'

Voir les nodes Headscale

cd /opt/studioe5-client-a
docker compose exec -T headscale headscale nodes list studioe5

Tester le resolver (depuis Caddy)

cd /opt/studioe5-client-a
docker exec studioe5-caddy curl -sS -I -H "Host: test-wp-001.studioe5.edudeploy.com" http://resolver:2020/

Tester en HTTPS public (dès que la limite sera levée)

curl -sS -I -L https://test-wp-001.studioe5.edudeploy.com/

📋 Prochaines étapes à faire

• Attendre la fin du rate limit Let’s Encrypt (levé le 2026-06-23).
• 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).
• 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).
• Tester le flux complet depuis l’interface web (activation d’un élève, création d’instance via l’UI).
• 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.).

🔧 Notes techniques

• Le conteneur resolver-vpn utilise network_mode: service:resolver pour partager le netns avec le resolver.
• L’agent utilise tailscaled --tun=userspace-networking ; le resolver-vpn utilise un vrai TUN (tailscale0).
• Le Caddyfile actuel utilise tls { on_demand } pour les instances. En cas de nouvelle rate limit, on peut temporairement remettre tls internal dans le bloc :443 pour valider le flux sans certificat public.