OpenClaw 2026 : passerelle sur VM cloud avec accès privé Tailscale

Les équipes qui hébergent la passerelle OpenClaw sur une petite VM cloud veulent le même socle : MCP et Streamable HTTP uniquement sur le tailnet, sans écoute publique sur l’hôte ni dans le groupe de sécurité du fournisseur. Le motif durable est une pile Docker Compose où l’image officielle Tailscale joue le rôle de sidecar : elle porte tailscale up, l’état persistant sur volume et la montée d’interface, tandis que le conteneur passerelle écoute sur le bridge interne ou 127.0.0.1 et n’expose jamais 0.0.0.0:443 vers Internet. Le pare-feu du cloud reste nécessaire mais insuffisant : les règles ports: de Compose ou une unité systemd socket peuvent rouvrir un chemin que la grille de sécurité ne montre pas. Les balises d’image, healthchecks et ports exacts suivent la release OpenClaw que vous épinglez ; ce guide fixe la couche réseau et d’authentification à recopier dans un runbook. Pour stdio, Streamable HTTP, délais et erreurs de chemins côté outils, prolongez avec OpenClaw & MCP : stdio, Streamable HTTP, délais et tutoriel ENOENT ; pour une montée en charge sur orchestrateur avec sondes et Secrets, reliez au tutoriel OpenClaw sur Kubernetes : Helm, sondes et rotation des Secrets.

1. Sidecars Compose : empêcher ports: de rouvrir le plan de données public

Placez le sidecar et la passerelle sur le même bridge utilisateur, montez des répertoires d’état distincts et ne partagez jamais un seul /var/lib/tailscale entre deux conteneurs. L’écueil classique est ports: "443:443" ou une liaison passerelle sur 0.0.0.0 « juste pour tester » : le groupe de sécurité peut être irréprochable pendant que Docker publie tout de même vers Internet. Préférez l’écoute sur loopback ou IP interne du bridge, puis joignez le service via les noms MagicDNS depuis d’autres membres du tailnet. Si vous terminez le TLS, faites-le sur un reverse proxy joignable seulement dans le tailnet, pas via une publication hôte. Lorsque vous durcissez openclaw.json (permissions minimales, jetons), gardez la même discipline documentaire que pour les clés d’auth Tailscale.

Règle d’or : lancez docker ps et vérifiez qu’aucun mapping n’atteint l’interface publique de l’hôte avant d’optimiser des ACL ou des certificats pendant des heures.

2. Lier la passerelle au tailnet : empiler HTTPS et jetons Bearer

Après un tailscale up réussi, délivrez des certificats avec tailscale cert ou un Caddy interne afin que les clients fassient confiance à la chaîne plutôt qu’à un auto-signé ignoré silencieusement. Injectez les jetons par variables d’environnement ou secrets Docker montés en fichiers — jamais dans les couches d’image. Si le TLS s’arrête devant la passerelle, validez Authorization: Bearer au proxy et conservez un second contrôle côté passerelle pour qu’un chemin mal routé ne saute pas l’authentification. Journalisez séparément les 401 applicatifs et les échecs de poignée TLS afin que l’astreinte ne confonde pas les couches. Faites tourner les secrets avec un redémarrage progressif : les processus longs gardent souvent l’ancien jeton en mémoire tant qu’ils ne sont pas remplacés.

3. Serve versus Funnel : tracer explicitement la frontière d’exposition

tailscale serve convient en général pour un accès strictement tailnet. Funnel expose volontairement certains chemins à Internet public. Si la conformité exige zéro exposition publique, désactivez Funnel par défaut, bloquez-le par politique et auditez les bascules « temporaires » de debug. Sous Serve, des préfixes d’hôte ou de chemin désalignés par rapport au chemin de base OpenClaw donnent des 404 ou des boucles de redirection alors que le processus est sain : alignez noms MagicDNS, chemins Serve et tables de routes OpenClaw dans le même ticket de changement.

4. Échecs de connexion : réduire l’espace de recherche dans un ordre fixe

1) Dans le sidecar, tailscale status : tailnet attendu, pas d’état NeedsLogin. 2) Depuis un autre membre, ping sur l’adresse 100.x puis curl -vk https://nom-machine pour séparer refus d’ACL et bug applicatif. 3) curl la passerelle avec un en-tête Authorization réel afin que les erreurs TLS ne se déguisent pas en 401. 4) Si Streamable HTTP échoue alors que stdio fonctionne, revérifiez timeouts d’inactivité et limites de corps de bout en bout. Pour répéter un incident, resserrez une ACL, capturez les journaux, puis revenez en arrière — le rollback doit être aussi scripté que la panne.

  • Un redémarrage du sidecar a-t-il effacé le volume d’état et forcé une nouvelle authentification ?
  • Cohabitation accidentelle entre tailscaled sur l’hôte et un sidecar conteneurisé sur des routes qui se chevauchent ?
  • Les endpoints de métadonnées du cloud ont-ils été absorbés dans une table « interne seulement » ?

Passerelles Linux, macOS pour la partie lourde

Garder la passerelle sur une petite VM Linux réduit la facture, mais notarisation, signature de code et débogage GUI restent plus simples sur macOS. Coupler des conteneurs de plan de contrôle sur le tailnet à des charges par à-coups sur un Mac mini dédié profite de la bande passante mémoire Apple Silicon et des outils Xcode natifs sans exposer l’une ou l’autre face à Internet. Un Mac mini au repos consomme de l’ordre de quelques watts, reste silencieux en service continu et empile Gatekeeper, SIP et FileVault pour les machines sans clavier. Si vous voulez aligner région, latence et classe de machine avec des builds ou des runners voisins, le Mac mini M4 reste en 2026 un point d’entrée équilibré pour industrialiser ce schéma avant de multiplier les nœuds. Pour comparer les offres Macstripe et monter un Mac cloud prêt SSH/VNC en quelques minutes, ouvrez la page d’accueil Macstripe : c’est le bon moment pour valider latence réelle, tailnet et observabilité sur du matériel dédié plutôt que sur un portable saturé.