Architecture et composants
Noms canoniques des éléments d'un déploiement de tunnel MCP, les deux modes de provisionnement des identifiants et le modèle de connexion.
Cette page définit les termes utilisés dans l'ensemble de la documentation des tunnels MCP. Plusieurs composants apparaissent sous des noms différents dans les fichiers de configuration, les images de conteneurs et le texte ; les tableaux suivants donnent un nom canonique unique pour chacun et répertorient les alias que vous pourriez rencontrer.
Composants
| Terme | Définition | Apparaît également sous |
|---|---|---|
| Pile de tunnel (tunnel stack) | Les deux conteneurs que vous exécutez à l'intérieur de votre réseau pour vous rattacher à un tunnel : le proxy et cloudflared. Une pile dessert un tunnel et peut être répliquée sur plusieurs hôtes pour la disponibilité. Avec l'accès programmatique, le composant de configuration s'exécute aux côtés de la pile pour provisionner les identifiants. | la pile, la pile de tunnel MCP, le déploiement du tunnel, votre déploiement |
| Proxy | Le composant de routage d'Anthropic. Termine le TLS interne, valide que les adresses IP en amont se situent dans une plage autorisée, et achemine chaque requête vers un serveur MCP en amont en fonction du nom d'hôte. | mcp-proxy (nom de l'image, nom du service Compose et nom du conteneur Helm), mcp-gateway (chemin de configuration interne au conteneur /etc/mcp-gateway/config.yaml et préfixe des valeurs Helm gateway.config.*) |
| cloudflared | Le connecteur de tunnel open source de Cloudflare. Initie les connexions exclusivement sortantes depuis votre réseau vers la périphérie du tunnel et transporte le trafic chiffré entre la périphérie et le proxy. Sans rapport avec un Managed Agent. | le connecteur sortant, le connecteur de tunnel |
| Composant de configuration (setup component) | Le binaire setup, livré dans l'image mcp-proxy. Avec l'accès programmatique, il s'authentifie via Workload Identity Federation, récupère le jeton de tunnel, génère une autorité de certification (CA) et un certificat serveur, et enregistre la CA auprès d'Anthropic. Fournit également renew-cert. | Job de configuration (le hook de pré-installation Helm), service setup (le profil Compose), hook de configuration, binaire setup, CLI setup |
| Périphérie du tunnel (tunnel edge) | Les serveurs de périphérie Cloudflare vers lesquels cloudflared établit des connexions sortantes (plages IP 198.41.192.0/19 et 2606:4700:a0::/44, port 7844 TCP et UDP). Le tunnel qui s'exécute par-dessus est provisionné et contrôlé par Anthropic ; Cloudflare exploite le réseau sous-jacent. | la périphérie, la périphérie du tunnel exploitée par Anthropic |
| TLS interne (inner TLS) | Une seconde négociation TLS transportée à l'intérieur du flux WebSocket en clair du tunnel, entre le backend d'Anthropic et votre proxy. Le proxy présente un certificat serveur signé par une CA que vous avez enregistrée sur le tunnel. Comme vous seul détenez la clé privée, le fournisseur de transport ne peut pas lire les charges utiles des requêtes ou des réponses. | la négociation TLS interne |
| Serveur MCP en amont (upstream MCP server) | Un serveur MCP s'exécutant dans votre réseau privé vers lequel le proxy achemine le trafic. Chaque serveur en amont est exposé sous la forme d'un sous-domaine sous votre domaine de tunnel. | amont, serveur MCP routé, serveur MCP tunnelisé |
Provisionnement des identifiants
La pile de tunnel a besoin de deux identifiants à l'exécution : le jeton de tunnel (tunnel token), qui authentifie la connexion sortante de cloudflared, et un certificat serveur (server certificate) signé par une CA enregistrée sur le tunnel, que le proxy présente lors de la négociation TLS interne. Il existe deux façons de les fournir, présentées tout au long de ce guide sous la forme d'une paire d'onglets.
| Mode | Comment les identifiants parviennent à la pile | Nom dans le chart Helm | Libellé de l'onglet |
|---|---|---|---|
| Accès programmatique | Le composant de configuration s'authentifie auprès de l'API Tunnels via Workload Identity Federation, récupère le jeton de tunnel, génère localement une CA et un certificat serveur, et enregistre la CA. Aucun secret de longue durée n'est copié à la main. Nécessite une règle de fédération avec la portée workspace:manage_tunnels. | Mode géré (setup.enabled: true, la valeur par défaut) | Avec accès programmatique |
| Manuel | Vous copiez le jeton de tunnel depuis la Claude Console, générez vous-même une CA et un certificat serveur (par exemple avec openssl), enregistrez la CA dans la Console, et fournissez le jeton et le certificat à la pile sous forme de secrets. Aucun composant de configuration ne s'exécute. | Mode externe (setup.enabled: false) | Sans accès programmatique |
Ces modes sont également désignés comme le flux programmatique et le flux manuel dans les guides de déploiement.
Modèle de connexion
Deux directions sont à l'œuvre dans un tunnel, et elles pointent dans des sens opposés :
- Direction de la connexion : cloudflared établit une connexion sortante depuis votre réseau vers la périphérie du tunnel. Votre pare-feu ne voit que du trafic sortant sur le port 7844 ; aucun port entrant n'est ouvert.
- Direction des requêtes : une fois cette connexion établie, les requêtes MCP circulent depuis Anthropic vers votre réseau par son intermédiaire, via cloudflared jusqu'au proxy, puis jusqu'au serveur MCP en amont.
L'expression « exclusivement sortant » (outbound-only) décrit la connexion, et non les requêtes qu'elle transporte.
Le TLS interne s'étend du backend d'Anthropic à votre proxy. cloudflared et la périphérie du tunnel se trouvent entre eux sur le réseau mais ne voient que du texte chiffré ; le proxy est le premier endroit à l'intérieur de votre réseau où les charges utiles des requêtes MCP sont lisibles.
Voir aussi
- Tunnels MCP pour le modèle de sécurité et le tableau de responsabilité partagée.
- Référence des tunnels MCP pour les champs de configuration du proxy, les exigences relatives aux certificats et le composant de configuration.
Was this page helpful?