Architektur und Komponenten
Kanonische Bezeichnungen für die Bestandteile eines MCP-Tunnel-Deployments, die beiden Modi zur Bereitstellung von Anmeldedaten und das Verbindungsmodell.
Diese Seite definiert die Begriffe, die in der gesamten Dokumentation zu MCP-Tunneln verwendet werden. Mehrere Komponenten erscheinen in Konfigurationsdateien, Container-Images und Fließtext unter unterschiedlichen Namen; die folgenden Tabellen geben für jede Komponente eine kanonische Bezeichnung an und listen die Aliasse auf, denen du begegnen könntest.
Komponenten
| Begriff | Definition | Erscheint auch als |
|---|---|---|
| Tunnel-Stack | Die zwei Container, die du innerhalb deines Netzwerks betreibst, um dich mit einem Tunnel zu verbinden: der Proxy und cloudflared. Ein Stack bedient einen Tunnel und kann zur Erhöhung der Verfügbarkeit über mehrere Hosts repliziert werden. Bei programmatischem Zugriff läuft die Setup-Komponente neben dem Stack, um Anmeldedaten bereitzustellen. | der Stack, der MCP-Tunnel-Stack, das Tunnel-Deployment, dein Deployment |
| Proxy | Anthropics Routing-Komponente. Terminiert das innere TLS, validiert, dass Upstream-IPs innerhalb eines erlaubten Bereichs liegen, und leitet jede Anfrage anhand des Hostnamens an einen Upstream-MCP-Server weiter. | mcp-proxy (Image-Name, Compose-Service-Name und Helm-Container-Name), mcp-gateway (containerinterner Konfigurationspfad /etc/mcp-gateway/config.yaml und Helm-Werte-Präfix gateway.config.*) |
| cloudflared | Cloudflares Open-Source-Tunnel-Connector. Initiiert die ausschließlich ausgehenden Verbindungen von deinem Netzwerk zum Tunnel-Edge und transportiert verschlüsselten Datenverkehr zwischen dem Edge und dem Proxy. Steht in keinem Zusammenhang mit einem Managed Agent. | der ausgehende Connector, der Tunnel-Connector |
| Setup-Komponente | Das setup-Binary, das im mcp-proxy-Image ausgeliefert wird. Bei programmatischem Zugriff authentifiziert es sich über Workload Identity Federation, ruft das Tunnel-Token ab, erzeugt eine CA und ein Serverzertifikat und registriert die CA bei Anthropic. Stellt außerdem renew-cert bereit. | Setup-Job (der Helm-Pre-Install-Hook), setup-Service (das Compose-Profil), Setup-Hook, Setup-Binary, Setup-CLI |
| Tunnel-Edge | Die Cloudflare-Edge-Server, zu denen cloudflared eine ausgehende Verbindung aufbaut (IP-Bereiche 198.41.192.0/19 und 2606:4700:a0::/44, Port 7844 TCP und UDP). Der darüber laufende Tunnel wird von Anthropic bereitgestellt und kontrolliert; Cloudflare betreibt das zugrunde liegende Netzwerk. | der Edge, der von Anthropic betriebene Tunnel-Edge |
| Inneres TLS | Ein zweiter TLS-Handshake („inner TLS“), der innerhalb des Klartext-WebSocket-Streams des Tunnels zwischen Anthropics Backend und deinem Proxy durchgeführt wird. Der Proxy präsentiert ein Serverzertifikat, das von einer CA signiert ist, die du auf dem Tunnel registriert hast. Da nur du den privaten Schlüssel besitzt, kann der Transportanbieter weder Anfrage- noch Antwort-Payloads lesen. | der innere TLS-Handshake |
| Upstream-MCP-Server | Ein MCP-Server in deinem privaten Netzwerk, an den der Proxy weiterleitet. Jeder Upstream wird als eine Subdomain unter deiner Tunnel-Domain bereitgestellt. | Upstream, gerouteter MCP-Server, getunnelter MCP-Server |
Bereitstellung von Anmeldedaten
Der Tunnel-Stack benötigt zur Laufzeit zwei Anmeldedaten: das Tunnel-Token, das die ausgehende Verbindung von cloudflared authentifiziert, und ein Serverzertifikat, das von einer auf dem Tunnel registrierten CA signiert ist und das der Proxy während des inneren TLS-Handshakes präsentiert. Es gibt zwei Möglichkeiten, diese bereitzustellen, die in diesem Leitfaden durchgehend als Tab-Paar dargestellt werden.
| Modus | Wie die Anmeldedaten den Stack erreichen | Helm-Chart-Bezeichnung | Tab-Beschriftung |
|---|---|---|---|
| Programmatischer Zugriff | Die Setup-Komponente authentifiziert sich über Workload Identity Federation bei der Tunnels API, ruft das Tunnel-Token ab, erzeugt lokal eine CA und ein Serverzertifikat und registriert die CA. Kein langlebiges Secret wird von Hand kopiert. Erfordert eine Federation-Regel mit dem Scope workspace:manage_tunnels. | Managed-Modus (setup.enabled: true, der Standard) | Mit programmatischem Zugriff |
| Manuell | Du kopierst das Tunnel-Token aus der Claude Console, erzeugst selbst eine CA und ein Serverzertifikat (zum Beispiel mit openssl), registrierst die CA in der Console und übergibst das Token und das Zertifikat als Secrets an den Stack. Es läuft keine Setup-Komponente. | External-Modus (setup.enabled: false) | Ohne programmatischen Zugriff |
Diese Modi werden in den Deployment-Leitfäden auch als der programmatische Ablauf und der manuelle Ablauf bezeichnet.
Verbindungsmodell
In einem Tunnel wirken zwei Richtungen, und sie zeigen in entgegengesetzte Richtungen:
- Verbindungsrichtung: cloudflared baut eine ausgehende Verbindung von deinem Netzwerk zum Tunnel-Edge auf. Deine Firewall sieht nur Egress auf Port 7844; es wird kein eingehender Port geöffnet.
- Anfragerichtung: Sobald diese Verbindung hergestellt ist, laufen MCP-Anfragen darüber von Anthropic in Richtung deines Netzwerks, durch cloudflared zum Proxy und weiter zum Upstream-MCP-Server.
Die Formulierung „outbound-only“ (ausschließlich ausgehend) beschreibt die Verbindung, nicht die darüber transportierten Anfragen.
Das innere TLS erstreckt sich zwischen Anthropics Backend und deinem Proxy. cloudflared und der Tunnel-Edge liegen auf der Leitung dazwischen, sehen aber nur Chiffretext; der Proxy ist die erste Stelle innerhalb deines Netzwerks, an der MCP-Anfrage-Payloads lesbar sind.
Siehe auch
- MCP-Tunnel für das Sicherheitsmodell und die Tabelle zur geteilten Verantwortung.
- MCP-Tunnel-Referenz für Proxy-Konfigurationsfelder, Zertifikatsanforderungen und die Setup-Komponente.
Was this page helpful?