Les équipes veulent que la passerelle OpenClaw reste joignable quand les portables dorment et que la box résidentielle coupe la session. Placer ce plan de contrôle sur un Mac mini loué (ou équivalent Apple Silicon hébergé) apporte une écoute stable, une frontière d’audit claire et la possibilité d’utiliser Tailscale sans monopoliser une machine personnelle. Ce guide recoupe docs.openclaw.ai/gateway, l’accès distant et l’intégration Tailscale : garder gateway.bind en loopback, préférer Serve dans le tailnet, n’ajouter des routes de sous-réseau que lorsque l’atteinte RFC1918 est un vrai besoin métier, et réserver Funnel aux exceptions encadrées. Pour l’installation de base et le durcissement Docker, enchaînez avec notre tutoriel OpenClaw Docker et dépannage ; pour le premier accès SSH sur l’hôte fournisseur, le guide SSH/VNC première configuration reste la référence la plus courte.
Pourquoi faire tourner la passerelle sur un Mac loué
La passerelle OpenClaw se comporte davantage comme de l’infra qu’une session CLI occasionnelle. La sortir de votre portable élimine les cycles de veille, les bascules VPN imprévisibles et le risque de tuer le processus en pleine démo. Un Mac distant loué se prête bien à ce rôle : alimentation et refroidissement sont pensés pour le 24/7, et vous pouvez isoler les secrets sur une machine que vous ne partagez pas avec la navigation web du quotidien.
- Disponibilité — Les offres type Mac mini M4 visent des charges longues ; la passerelle et les sondes /healthz / /readyz restent utiles même lorsque l’équipe est déconnectée.
- Posture réseau — Vous gardez le plan de contrôle hors exposition LAN « brute » tout en utilisant des chemins Tailscale que la sécurité peut déjà auditer.
- Rayon d’explosion — Combinez les ACL tailnet avec les limites de sortie côté compétences OpenClaw (sandbox et liste blanche sortante) pour qu’un outil compromis ne pivote pas sur tout le tailnet.
Sur le plan commercial, louer transforme une expérimentation sur laptop en service : vous validez le runbook sur une location courte, puis prolongez lorsque les sondes restent vertes — sans immobiliser du CAPEX avant d’avoir prouvé l’usage.
Alignement documentation : liaison passerelle et moindre privilège
Le tableau suivant sert de fiche pour les revues sécurité ou plateforme : chaque ligne relie l’attendu officiel à un choix concret sur un Mac géré par un hébergeur.
| Sujet | Attendu (doc officielle) | Pratique Mac loué |
|---|---|---|
| gateway.bind | Par défaut loopback ; des écoutes plus larges exigent jeton ou mot de passe. | Rester en loopback ; mettre devant Serve, un tunnel SSH -L ou un proxy inverse colocalisé — éviter le port 18789 nu sur un LAN partagé. |
| Tailscale Serve | HTTPS dans le tailnet ; option allowTailscale pour certains chemins UI. | Conserver l’authentification explicite sur les routes API ; désactiver les raccourcis d’identité si des charges non fiables cohabitent sur l’hôte. |
| Funnel | Exige le mode password ; dépend de HTTPS, MagicDNS, nœuds funnel éligibles. | N’ouvrir que pour des fenêtres d’opération courtes ; stocker les mots de passe dans l’environnement du service, pas dans des fichiers lisibles par le monde. |
| CLI distante | Les surcharges --url exigent --token ou --password explicites. | Recharger les secrets après chaque rotation ; un tunnel « vert » ne garantit pas des identifiants à jour des deux côtés. |
Routage de sous-réseau, Serve et Funnel : trois leviers distincts
Routage de sous-réseau (subnet routes) permet aux appareils du tailnet d’atteindre des services internes via le Mac qui annonce le préfixe — registre d’artefacts privé, vieux HTTP interne, etc. Approuvez le préfixe le plus étroit dans la console Tailscale, activez le forwarding sur ce Mac et vérifiez les chemins de retour avant de dépendre de la configuration en production.
Serve répond à l’usage majoritaire : équipe distante, réseau privé. La passerelle reste sur 127.0.0.1 ; Tailscale termine le TLS et peut injecter des en-têtes de confiance là où la politique l’autorise.
Funnel publie la même entrée vers Internet public. Réservez-le aux prestataires qui ne peuvent pas rejoindre votre tailnet ; attendez-vous à une authentification plus stricte et à une supervision renforcée.
Exemples de ligne de commande (à promouvoir vers des fichiers de config pour le déploiement réel) :
# Chemin tailnet uniquement (passerelle toujours en loopback)
openclaw gateway --tailscale serve
# Chemin Internet public (mot de passe + revue politique)
openclaw gateway --tailscale funnel --auth passwordResserrement des ACL et rotation des identifiants
Esquissez le graphe de connexions avant de coller du JSON dans Tailscale : quels portables admin peuvent joindre l’entrée Serve, quels tags représentent la CI, quelles API amont la passerelle doit appeler. Refus par défaut pour tout le reste.
Les annonces de sous-réseau doivent cibler des groupes ou des tags, pas « toute l’entreprise », sauf obligation de conformité. Croisez les ACL tailnet avec les contrôles de sortie OpenClaw : une route RFC1918 fraîchement ouverte ne doit pas devenir un couloir de pivot pour une compétence trop permissive.
La rotation des jetons doit suivre le rythme de maintenance de votre fournisseur de Mac loué. Générez un nouvel OPENCLAW_GATEWAY_TOKEN, mettez à jour l’environnement du service (launchd, Compose, etc.), redémarrez la passerelle, exécutez openclaw gateway status et openclaw channels status --probe, puis propagez le secret aux postes et jobs d’automatisation. Révoquez l’ancienne valeur et documentez le changement, surtout si les disques peuvent être réimaged entre locataires.
HowTo : étapes minimales reproductibles
- Rejoindre Tailscale sur le Mac loué — Vérifier version client, nom d’hôte et attentes MagicDNS avec l’administrateur du tailnet.
- Installer OpenClaw par le chemin officiel — CLI (openclaw onboard) ou Docker (./scripts/docker/setup.sh) ; recopier bind et jeton depuis la doc passerelle.
- Partir de loopback + jeton — Prouver openclaw gateway status en SSH local avant toute exposition.
- Activer Serve — Valider UI et WebSocket depuis un second appareil du tailnet sans ouvrir Funnel.
- Ajouter des routes de sous-réseau seulement si nécessaire — Tester avec des IP littérales, puis resserrer les ACL vers les opérateurs qui ont besoin du préfixe.
- Funnel optionnel — Passer en mode mot de passe, nommer les responsables, planifier la fermeture automatique ou manuelle.
- Rotation périodique ou post-incident — Traiter les jetons passerelle comme des clés API production.
Ancres vérifiables : écoute par défaut 127.0.0.1:18789 ; santé /healthz et /readyz ; modes Tailscale serve vs funnel ; variables OPENCLAW_GATEWAY_TOKEN et OPENCLAW_GATEWAY_PASSWORD.
FAQ : erreurs de connectivité courantes
Tailscale ping réussit mais les WebSockets échouent. Souvent, rien ne relaie le port 18789 vers l’écoute loopback. Ajoutez Serve ou un tunnel ssh -L 18789:127.0.0.1:18789, puis retestez avec openclaw gateway status sur le serveur.
Réponses « non autorisé » en boucle. Cherchez une surcharge --url sans --token / --password assorti, ou une désynchronisation après rotation (CI encore sur l’ancien jeton).
Avec Funnel, la passerelle refuse de démarrer. Confirmer le mode mot de passe, les tags funnel, HTTPS et MagicDNS selon la documentation Tailscale et OpenClaw.
Routes de sous-réseau approuvées mais paquets perdus. Inspecter sysctl de forwarding, pare-feu macOS ou fournisseur, et les règles ACL qui autorisent à la fois la route et le port de destination.
Synthèse
Une passerelle sur Mac loué transforme OpenClaw d’essai portable en composant que l’équipe peut consommer comme un service. Ancrez-vous sur loopback, utilisez Serve et des ACL serrées pour l’accès quotidien, et traitez Funnel et les subnet routes comme des décisions de risque explicites, instrumentées. La rotation régulière de OPENCLAW_GATEWAY_TOKEN limite l’exposition sur une infrastructure partagée.
Pour passer du runbook à la capacité, ouvrez Tarifs et Achat (Mac mini M4, plusieurs régions) — pages lisibles sans compte. Besoin d’aide opérationnelle : Centre d’aide.