# MacLustr Tunnel — passerelles publiques OVH pour le cluster (remplace ngrok)

⚠️ 2026-10-02 : la passerelle secondaire R9128 (Gravelines) a été retirée (serveur vidé, à résilier) ; BHS64 est la seule passerelle. L'interface wg0 (10.66.0.x) et le LaunchDaemon io.maclustr.wireguard ont été supprimés de M1M32, M3U96a et M4M64b ; mlt -g R9128 et la passerelle R9128 de mld/config.py n'existent plus ; les routes des sites hébergés sur les serveurs OVH retirés (websensor, market-atlas, hfmarketdata, cancerindex, company-atlas, satelliteindex, internetpressure, datacenterindex) ont été retirées (30 routes restantes). Les mentions de R9128, wg0, 10.66.0.x et 51.255.75.61 ci-dessous sont historiques.

Mis en place le 2026-09-09 (R9128, France) puis 2026-09-10 (BHS64, Québec — passerelle principale). Premier site migré : www.qc26.ca (M3U96a:8200).

Internet → DNS (A → 51.161.112.61) → BHS64 (OVH Beauharnois) : Caddy 2 (TLS Let's Encrypt auto, :80/:443)
                                           └─ WireGuard hub 10.67.0.1 (udp 51820) ─→ Macs, interface wg1 (10.67.0.x)
Internet → DNS (A → 51.255.75.61)  → R9128 (OVH Gravelines) : idem, hub 10.66.0.1 ─→ Macs, interface wg0 (10.66.0.x)  [secours / Europe]

Deux passerelles indépendantes : chaque Mac a deux interfaces WireGuard (wg0 → France, wg1 → Québec, LaunchDaemons io.maclustr.wireguard et io.maclustr.wireguard-wg1). Le DNS d'un site décide de la passerelle utilisée ; une route peut exister sur les deux (les certificats Let's Encrypt peuvent être copiés d'une passerelle à l'autre : tar de /var/lib/caddy/.local). mlt vise BHS64 par défaut, mlt -g R9128 … pour la France. Clés publiques des hubs : maclustr-tunnel/hub-BHS64.pub, hub-R9128.pub. Nouvelle passerelle = gateway-setup.sh <alias> <ip> <sous-réseau>.

# Composants

Plage 10.66.0.0/24 (pas 10.100.x : LAN des Macs loués Macly). Attribution fixe dans ipmap : M1M32 .2, M3U96a .10, M3U96b .11, M2U64 .12, M4M64a .13, M4M64b .14, … loués .40–.46.

# Commandes

mlt status                          # pairs (handshake, trafic) + routes
mlt peer M4M64a M2U64               # raccorder des Macs (idempotent)
mlt add www.exemple.com M4M64a:8250 # exposer un port → https://www.exemple.com (TLS auto)
mlt add api.exemple.com M4M64a:8251 M4M64b:8251   # ≥2 upstreams = load balancing (first + health /)
mlt redirect exemple.com www.exemple.com
mlt rm www.exemple.com
mlt ls

Sur la passerelle directement : sudo tunnelctl … (mêmes sous-commandes ; tunnelctl peer add <alias> <pubkey>).

# État au 2026-09-10 : migration complète

Les 34 sites publics du cluster (33 + qc26) passent par BHS64 ; ngrok n'est plus utilisé pour eux (processus PM2 *-ngrok supprimés, LaunchAgents io.adminka.ngrok / com.ka{2,4,6}.ngrok déchargés et renommés .disabled-ngrok-<date>, manifestes mld ngrok: null + champ tunnel, sauvegardes .bak-ngrok-<date> dans M1M32:~/dispatch/apps/). Liste de référence : maclustr-tunnel/sites-ngrok.txt (domaine → nœud:port) et ngrok-map.txt.

Outils de migration en lot (dans maclustr-tunnel/) :

• migrate-watch.sh <sites.txt> [BHS64] [durée] : surveille le DNS autoritaire de chaque domaine ; dès qu'il pointe vers la passerelle, mlt add (+ redirect apex si l'apex pointe aussi) puis test HTTPS. Journal migrate.log.
• ngrok-retire.sh <ngrok-map.txt> <sites.txt> [BHS64] [durée] : quand 8.8.8.8 et 1.1.1.1 renvoient la passerelle, supprime le tunnel ngrok (pm2 ou launchd) et met le manifeste mld à jour. Journal ngrok-retire.log.
• wg-forward-setup.sh <ip-wg> <sudo> <port>… : relais socat (LaunchDaemon io.maclustr.wgfwd, conf /opt/homebrew/etc/maclustr-wgfwd.conf) pour les apps qui n'écoutent que sur 127.0.0.1 (spbgit :7420 sur M1M32, api-ka :8000 sur M4M64b).
• Apex : les redirections GoDaddy existantes (15.197.225.128, 3.33.130.190, 76.223.105.230 → www) ont été conservées ; seul qc26.ca a son apex sur la passerelle (redirect Caddy).

# Migrer un site ngrok → tunnel (procédure suivie pour qc26)

1. mlt peer <nœud> si le nœud n'est pas encore raccordé (mlt status : handshake récent, ping 10.66.0.X depuis R9128).
2. Vérifier l'app à travers le tunnel depuis R9128 : curl -H "Host: www.site" http://10.66.0.X:PORT/.
3. (Optionnel) répétition générale sur un hôte jetable : mlt add test-x.51-255-75-61.sslip.io <nœud>:<port> → https OK + cert Let's Encrypt.
4. GoDaddy : supprimer le CNAME www → …ngrok-cname.com, ajouter A www → 51.255.75.61 (et A @ → 51.255.75.61 pour l'apex).
5. Dès que le serveur autoritaire répond (dig @ns5x.domaincontrol.com), mlt add www.site <nœud>:<port> puis mlt redirect site www.site. Let's Encrypt lit le DNS autoritaire : pas besoin d'attendre les caches publics.
6. Vérifier : curl --resolve www.site:443:51.255.75.61 https://www.site/, cert, redirections 80→443 et apex, API.
7. Quand les caches publics ont basculé (ancien TTL, ~1 h) : pm2 delete <app>-ngrok && pm2 save sur le nœud, et dans le manifeste mld (M1M32:~/dispatch/apps/<app>.json) mettre "ngrok": null + "tunnel": {…} (sinon mld deploy relancerait ngrok).

# Points d'attention

• Latence : R9128 est à Gravelines (France) ; depuis le Québec, chaque requête fait Québec → France → Québec (+~200-250 ms vs ngrok US). Un serveur OVH BHS (Beauharnois, Québec) comme passerelle ramènerait ça à ~10 ms — à envisager si les sites sont surtout consultés au Québec.
• Caddy journalise dans journald (journalctl -u caddy -f) ; hôte inconnu → 404 « MacLustr Tunnel ». Certificats dans /var/lib/caddy.
• wg show wg0 ne marche pas sur macOS (wireguard-tools 1.0.2026) : utiliser wg show $(cat /var/run/wireguard/wg0.name) en root.
• sudo -S lit le mot de passe sur stdin : ne jamais l'enchaîner avec un heredoc (bug corrigé dans wg-node-setup.sh).
• Le LaunchDaemon macOS peut refuser bootstrap juste après un bootout (EIO) : le script réessaie 6× puis fait wg-quick up directement.
• Migration ngrok → tunnel : un site à la fois, en gardant ngrok actif jusqu'à expiration des caches DNS.
• Intégré à mld depuis le 2026-09-10 soir (mld/tunnel.py) : mld deploy/move posent/repointent la route https://<tunnel.domain> → <nœud courant>:<port> via tunnelctl (ssh direct ubuntu@51.161.112.61 avec la clé de M1M32), raccordent le nœud en wg1 s'il ne l'est pas (assets/wg-node-setup.sh), mld retire retire la route, mld tunnel status|peer|route|rm depuis le laptop, mld heal vérifie toutes les 5 min que chaque route pointe vers le bon nœud et que wg1 est monté. mlt (laptop) reste utile pour les sites hors mld et les redirections d'apex.
• Pas encore fait : fail2ban/CrowdSec, WebSocket (Caddy le gère nativement, tunnel.websocket: true dans le manifeste ajoute --websocket, à vérifier au premier site qui en a besoin).