yacine/edubox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b4344e9d6649262acca4d81ac28cadadfa6f98b5
edubox/SUIVI_VPN_ONDEMAND.md
T

9.4 KiB
Raw Blame History

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/

🌐 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 : 
    {
  "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 : 
    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

  • 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).
  • 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).
  • Tester le flux complet depuis l’interface web → OK via l’API authentifiée (POST /api/instances), instance cmqqgrur20001lw67t2bdgzkg accessible en HTTPS public.
  • 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 :

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 : 
    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 : 
    *.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 :

*.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.
  • 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.
Reference in New Issue View Git Blame Copy Permalink