# 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

| Où | Quoi |
|---|---|
| R9128 | `wg-quick@wg0` (10.66.0.1/24, clé `/etc/wireguard/server.key`, pairs dans `/etc/wireguard/peers.d/*.conf`), `caddy` (Caddyfile `/etc/caddy/Caddyfile` + `import sites/*.caddy`), `ufw` (22, 80, 443 tcp/udp, 51820 udp), **`/usr/local/bin/tunnelctl`**, carte alias→IP `/etc/maclustr-tunnel/ipmap` |
| Macs | `wireguard-tools` + `wireguard-go` (Homebrew), conf `/opt/homebrew/etc/wireguard/wg0.conf` (Address 10.66.0.X/24, MTU 1380, AllowedIPs 10.66.0.0/24, PersistentKeepalive 25), LaunchDaemon `io.maclustr.wireguard` (boucle : remonte wg0 si absent, log `/var/log/maclustr-wireguard.log`) |
| Laptop | `~/Desktop/cluster-skill/mlt` (wrapper) + `maclustr-tunnel/` (tunnelctl, ipmap, Caddyfile, wg-node-setup.sh — copies de référence) |

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

```bash
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).