Ce guide n’emprunte pas l’axe Tailscale / MagicDNS. Si vous voulez des noms *.ts.net, des ACL tailnet et des sondes « mesh natives », commencez par l’article compagnon : OpenClaw multirégion vpshalo avec Tailscale MagicDNS. Ici, l’hypothèse est volontaire : vous évitez un VPN overlay. Vous laissez OpenClaw lié au loopback sur chaque hôte régional, vous ouvrez un tunnel SSH inverse vers une petite flotte bastion, vous faites tourner les secrets au calendrier, et un worker de fusion transforme plusieurs sondes en une seule page d’astreinte lisible — sans dépendre d’une identité tailnet ni d’enregistrements MagicDNS.

L’automatisation multirégion casse souvent quand quelqu’un lie « temporairement » la passerelle sur 0.0.0.0 pour montrer un tableau de bord. Le schéma ci-dessous est volontairement ennuyeux : le seul composant qui parle HTTP vers l’extérieur est ce que vous placez devant la sortie du tunnel ; OpenClaw lui-même ne possède jamais une socket routable sur le réseau d’entreprise. Pour choisir les PoP et la latence SSH, croisez ce plan avec la matrice d’entrée globale 2026 (GeoDNS et SSH). Lorsque les réponses DNS ne doivent pas osciller sous la CI, lisez aussi split-horizon, GeoDNS et p95 des artefacts. Enfin, alignez capacité builders et bastions dans la même enveloppe RTT via la page tarifs — la cohérence géographique stabilise à la fois tunnels et tirages d’artefacts.

Périmètre de sécurité (avant le premier ssh -R)

Le loopback est l’ancre de confiance. Configurez OpenClaw pour que l’administration et la passerelle d’inférence n’écoutent que sur 127.0.0.1 (ou sur un socket UNIX abstrait si votre build le permet). Le client SSH sur l’hôte charge ouvre alors un remote forward : le loopback du bastion reçoit un port qui proxifie vers OpenClaw. Aucun autre segment LAN n’a besoin d’une route IP vers la machine modèle — ce qui réduit la surface latérale lors d’un incident sur le VLAN builders.

Règle rédactionnelle : toute écoute non loopback impose une authentification en amont. Dès qu’un écouteur quitte 127.0.0.1 — balanceur legacy, agent qui fige 0.0.0.0, ou IP privée du Mac distant « pour le debug » — vous sortez du modèle « clé SSH puis tunnel » : le trafic est joignable sans l’échange de clés qui encadrait la session. La posture par défaut reste loopback + tunnel ; toute exception « non loopback » ne passe en production qu’avec une passerelle d’authentification (jeton porteur, mTLS, ou proxy OAuth) avant OpenClaw — de quoi présenter un graphe de flux à un auditeur. Sinon vous revenez au tunnel ou vous documentez une dérogation temporaire avec date de fin, pare-feu hôte et journaux alignés sur le même ticket.

  • Le bastion est le seul pivot exposé. Groupes de sécurité ou règles pf/nft : le port forwardé n’accepte que votre terminateur TLS / load balancer ou des IP break-glass, pas Internet entier sauf démo assumée.
  • Une région, un propriétaire de tunnel. Chaque PoP vpshalo termine sur son propre compte bastion afin qu’une clé volée à Tokyo ne pivote pas vers le OPENCLAW_HOME de Singapour.
  • Pas de OPENCLAW_HOME partagé sur NFS. Journaux et caches API restent locaux au Mac ou Linux qui exécute le modèle, comme dans les autres guides OpenClaw du blog.

Étapes minimales reproductibles

Répétez la séquence une fois par région. Les noms ci-dessous sont des exemples ; substituez vos tags d’inventaire.

  • Étape 1 — Ancrer OpenClaw sur le loopback. Définissez OPENCLAW_HOME=/var/lib/openclaw/<region> (ou l’équivalent macOS sous /usr/local/var) et démarrez OpenClaw avec des flags de bind explicites pour que HTTP et métriques n’écoutent que sur 127.0.0.1:18080. Vérifiez avec curl http://127.0.0.1:18080/healthz depuis localhost.
  • Étape 2 — Utilisateur tunnel dédié sur le bastion. Sur le bastion vpshalo, provisionnez un utilisateur POSIX verrouillé dont le seul rôle est d’accepter le reverse forward. AllowTcpForwarding yes si nécessaire, mais pas de shell interactif pour les clés automatisées lorsque sshd permet des commandes restreintes.
  • Étape 3 — Ouvrir le tunnel depuis l’hôte charge. Depuis la machine OpenClaw, session longue durée du type ssh -N -o ServerAliveInterval=30 -R 127.0.0.1:7443:127.0.0.1:18080 tunnel@bastion-sin.example. Lier le côté distant à 127.0.0.1 évite d’exposer le port sur les interfaces publiques du bastion ; ne passez à 0.0.0.0 qu’avec terminaison TLS et couche d’auth en bordure.
  • Étape 4 — Terminaison TLS devant le port bastion. nginx, Caddy ou Envoy terminent TLS puis proxifient vers 127.0.0.1:7443. Préférez des certificats par région pour limiter la réutilisation d’un wildcard en cas de compromission DNS partielle.
  • Étape 5 — Superviser la résurrection du tunnel. Enveloppez la commande SSH dans systemd, launchd ou un petit superviseur avec backoff exponentiel et alerte après trois crashs consécutifs — les flaps de tunnel sont souvent le moment où l’on « élargit temporairement » le pare-feu pour débugger.
# Hôte charge (image CI ou Mac distant) : santé loopback uniquement
curl -fsS --max-time 2 http://127.0.0.1:18080/healthz

# Bastion : prouver que le tunnel arrive avant d’exposer le HTTPS
curl -fsS --max-time 2 http://127.0.0.1:7443/healthz
Si des équipes doivent joindre la passerelle sans VPN d’overlay, arrêtez-vous à l’étape 4 et publiez du HTTPS propre sur le bastion. Ne sautez pas TLS sous prétexte qu’OpenClaw était « interne ».

Rotation des jetons sans déchirer le tunnel

Les clés d’hôte SSH tournent rarement ; en revanche les jetons API des modèles amont et des webhooks doivent tourner souvent. Stockez les secrets dans un coffre ; injectez un fichier d’environnement à courte durée de vie dans l’unité systemd avant rechargement. Playbook type : (1) émettre le nouveau jeton, (2) l’écrire à côté de l’ancien sous OPENCLAW_HOME/secrets.d/next, (3) signaler à OpenClaw un reload si la version le permet, sinon redémarrer le processus — le bind loopback fait que ce redémarrage ne modifie pas la posture pare-feu, (4) révoquer l’ancien jeton après cinq minutes de métriques vertes. Décalez les rotations entre régions pour que Tokyo et Singapour ne redémarrent pas en même temps hors fenêtre de maintenance documentée dans les runbooks du centre d’aide.

Sondes d’intégrité et pagination fusionnée

Chaque région doit émettre le même schéma JSON : region, lane (loopback, tunnel, edge_https), rtt_ms, error_class. Un petit worker de fusion (quelques lignes de Python ou une requête planifiée dans votre store métrique) compresse les événements dans une fenêtre glissante de cinq minutes. Paginez une fois lorsque toutes les voies échouent dans une même région ; n’étiquetez « multirégion » qu’à partir du moment où au moins deux régions perdent la voie tunnel dans le même bucket temporel. Une seule alerte porte alors la preuve dédupliquée au lieu de trois pages pour le même flap SSH.

  • Voie A — loopback sur l’hôte modèle. Peu coûteuse, toutes les minutes depuis localhost.
  • Voie B — bastion vers le port forwardé. Exerce le tunnel inverse sans traverser Internet public.
  • Voie C — HTTPS synthétique via la bordure. Fréquence basse (toutes les cinq minutes) pour ne pas confondre quotas TLS et panne OpenClaw.

Appliquez le même repli exponentiel sur les répétitions de pages que dans le guide MagicDNS — mais l’entrée du worker se limite ici au SSH et au HTTPS, sans identité tailnet. C’est précisément ce qui distingue ce playbook de celui centré sur MagicDNS, où les sondes peuvent s’appuyer sur le maillage et les ACL.

FAQ

Pourquoi ne pas utiliser Tailscale directement ? Certaines organisations interdisent les meshes overlay sur les sous-réseaux builders. Le reverse SSH réemploie des compétences déjà auditées et laisse le DNS public simple. Quand le maillage redevient autorisé, migrez vers le playbook MagicDNS sans renommer OPENCLAW_HOME.

GatewayPorts rend-il le tout dangereux ? Seulement si vous liez 0.0.0.0 sans couche d’auth. Gardez les forwards distants sur 127.0.0.1 et laissez nginx (ou équivalent) porter les certificats clients.

Comment les sondes s’authentifient-elles ? Émettez un jeton de sonde dédié, stocké à côté du worker de fusion, jamais sur les portables développeurs. Faites-le tourner sur le même rythme que les clés API modèle.

Qu’est-ce qui casse en premier pendant une panne ? Souvent le keepalive SSH, pas OpenClaw. Formez l’astreinte à redémarrer le service tunnel avant de toucher aux poids ou à la config modèle.

Avertissement : les versions OpenClaw diffèrent sur les noms de flags et les endpoints de santé. Vérifiez les adresses de bind et les signaux de reload contre la version déployée. La configuration sshd doit suivre la ligne de durcissement de votre organisation — cet article fixe l’intention, pas une politique complète.

Une fois les étapes scriptées, vous obtenez un périmètre reproductible : loopback dans chaque région vpshalo, tunnel étroit, authentification explicite si une écoute quitte le loopback, rotation prévisible des jetons, et un bruit d’alerte qui suit la cardinalité des incidents réels plutôt que le nombre brut de sondes. C’est suffisant pour livrer sereinement pendant que vous décidez si un DNS overlay vaut la charge opérationnelle supplémentaire.

Prochaines étapes publiques

Alignez PoP et latence de tunnel

Parcourez l’accueil, comparez les tarifs, puis commandez sur achat pour placer des builders Mac distant dans les mêmes régions vpshalo que vos bastions SSH — un RTT plus bas stabilise à la fois tunnels et tirages d’artefacts.

Louer un Mac maintenant Voir les tarifs Centre d’aide Autres articles