Zum Hauptinhalt springen
Connic
Platform

Bridge

Connic Bridges ermöglichen sicheren Zugriff auf private Dienste aus Verbindungen, LLM Providern, MCP Servern, eigenen Tools und Middleware. Eingehende Firewall-Regeln sind dafür nicht erforderlich.

Zuletzt aktualisiert

Was ist die Connic Bridge?

Die Connic Bridge ist ein schlanker Agent, der in einem privaten Netzwerk läuft und einen sicheren ausgehenden Tunnel zur Connic Cloud aufbaut. Verbindungen, eigene LLM Provider, MCP Server, Tools und Middleware können darüber auf Dienste zugreifen, die nur im privaten Netzwerk erreichbar sind.

Da die Bridge ausschließlich ausgehende Verbindungen aufbaut, sind keine eingehenden Firewall-Freigaben nötig. Private Dienste müssen nicht öffentlich im Internet erreichbar sein.

Wann ist eine Bridge erforderlich?

Eine Bridge ist erforderlich, wenn der Ziel-Service:

  • sich in einer privaten AWS VPC, GCP VPC oder einem Azure VNet befindet,
  • On-Premises hinter einer Unternehmens-Firewall läuft,
  • nur über privates DNS oder private IPs erreichbar ist oder
  • hinter einer IP-Allowlist liegt, in die Connics IPs nicht aufgenommen werden können.

Öffentlich erreichbare Services (z. B. Managed Kafka in Confluent Cloud oder AWS SQS über einen öffentlichen Endpoint) benötigen die Bridge nicht.

Verbindungsablauf

Privates Netzwerk

Private Services

Kafka, PostgreSQL, SQS, ...

↑ lokales TCP

Connic Bridge

Läuft in einer VPC

TLS-verschlüsselt

Connic Cloud

Connic Tunnel Endpoint

relay.connic.co

↑ routet Traffic

Verbindungen, LLM Provider,
Tools & Middlewares, MCP Server

Alle erreichen private Services über die Bridge

1. Führe die Connic Bridge als Docker-Container im privaten Netzwerk aus.

2. Die Bridge baut eine ausgehende WSS-Verbindung zu relay.connic.co auf (keine eingehenden Ports erforderlich).

3. Connic leitet Verbindungen für die ausgewählte Bridge an die im privaten Netzwerk laufende Bridge weiter.

4. Ist ALLOWED_HOSTS konfiguriert, prüft die Bridge das Ziel gegen diese Liste. Ohne sie ist jedes aus dem Netzwerk der Bridge erreichbare Ziel erlaubt. Anschließend öffnet die Bridge eine lokale TCP-Verbindung und leitet den Traffic weiter.

5. Die WSS-Verbindung verschlüsselt den Traffic zwischen Bridge und Connic Tunnel Endpoint.

Einrichtung

1

Bridge erstellen

Öffne Projekt-Settings > Bridge und klicke auf Add Bridge. Gib ihr einen Namen (z. B. „Produktiv-VPC“) und kopiere den angezeigten Token. Er wird nur einmal eingeblendet. Beliebig viele Bridges mit jeweils eigenem Token können verschiedene Netzwerke oder Environments erreichen.

2

Connic Bridge ausführen

Führe die Bridge im privaten Netzwerk aus. Sie muss sowohl die privaten Services als auch das Internet erreichen können.

Docker:

terminal
docker run -d --name connic-bridge \
  -e BRIDGE_TOKEN=cbr_your_token_here \
  -e ALLOWED_HOSTS=kafka:9092,postgres:5432 \
  connicorg/bridge:latest

pip:

terminal
pip install connic-bridge

connic-bridge \
  --token cbr_your_token_here \
  --allow kafka:9092 \
  --allow postgres:5432

Docker Compose:

docker-compose.yaml
services:
  connic-bridge:
    image: connicorg/bridge:latest
    restart: always
    environment:
      BRIDGE_TOKEN: cbr_your_token_here
      ALLOWED_HOSTS: kafka:9092,postgres:5432,my-db:5432
      LOG_LEVEL: INFO

Sobald die Bridge online ist, können Verbindungen, LLM Provider, benutzerdefinierter Code und MCP Server die Bridge für ihren Traffic nutzen. Konfiguriere jede Anbindung unabhängig.

Wo Bridges eingesetzt werden

1

Verbindungen

Wähle beim Erstellen oder Bearbeiten einer Verbindung im Dropdown Bridge im Abschnitt Network Access aus, über welche Bridge ihr Traffic geroutet werden soll. Lass die Einstellung auf None, um ohne Bridge direkt zu verbinden.

Die folgenden Verbindungstypen unterstützen den Zugriff über eine Bridge:

2

LLM Providers

Öffne für private LLM-Endpoints (vLLM, Ollama, einen LiteLLM-Proxy oder einen beliebigen OpenAI-kompatiblen Server) Projekt-Settings > LLM Provider, erweitere den benutzerdefinierten Provider und wähle im Dropdown Route via Bridge eine Bridge aus. Jeder LLM-Request eines Agenten, der diesen Provider verwendet, wird durch die Bridge getunnelt.

3

Tools & Middlewares

Projekt-Code – benutzerdefinierte Tools, Middleware, Tool Hooks und benutzerdefinierte Guardrails – kann private Services über einen Bridge-Hostnamen erreichen:

<target>.cnc-bridge-<bridge_id>

Dabei ist target der Hostname des Services im privaten Netzwerk (z. B. postgres-primary, kafka oder billing) und bridge_id wird aus Projekt-Settings > Bridge kopiert. Jede Bridge Card enthält das kopierbare Feld „Custom-tool host“.

Connic routet Verbindungen mit diesem Hostname-Muster über die angegebene Bridge. Standard-Python-Clients wie psycopg, aiokafka, httpx, requests und redis-py können das Muster direkt verwenden:

tools/lookup_order.py
import psycopg
from aiokafka import AIOKafkaProducer
import httpx

BRIDGE_ID = "abc123"  # aus Projekt Settings > Bridge kopieren

async def lookup_order(order_id: str) -> dict:
    # Postgres in einer privaten VPC
    with psycopg.connect(
        host=f"postgres-primary.cnc-bridge-{BRIDGE_ID}",
        port=5432, dbname="orders", user="reader", password="...",
    ) as conn:
        row = conn.execute(
            "SELECT data FROM orders WHERE id = %s", (order_id,)
        ).fetchone()

    # Privates Kafka-Topic
    producer = AIOKafkaProducer(
        bootstrap_servers=f"kafka.cnc-bridge-{BRIDGE_ID}:9092"
    )
    await producer.start()
    await producer.send("order-lookups", order_id.encode())
    await producer.stop()

    # Privater HTTP-Service
    r = httpx.get(f"http://billing.cnc-bridge-{BRIDGE_ID}/v1/orders/{order_id}")
    return {"row": row, "billing": r.json()}

Mit dieser Hilfsfunktion lässt sich der Hostname zusammensetzen:

tools/example.py
from connic import bridge_host

host = bridge_host("abc123", "postgres-primary")
# ergibt "postgres-primary.cnc-bridge-abc123"

Automatische Routen für erkannte Endpoints

Manche Protokolle verbinden sich zunächst mit einem Service und erhalten für die nächste Verbindung einen anderen Hostnamen oder eine andere IP. Redis Sentinel, Kafka-Metadaten und Datenbank-Clients mit Failover arbeiten häufig so. Wenn sich das Bridge-Suffix nicht an dieses zurückgegebene Ziel anhängen lässt, konfiguriere automatische Routen unter Projekt-Settings > Bridge oder über die authentifizierte API GET/PUT /v1/projects/{project_id}/bridges/{bridge_id}/routes. API Keys benötigen für beide Aktionen bridges.update.

bridge-routes.json
{
  "routes": [
    {
      "match_type": "exact",
      "target": "redis-sentinel.internal",
      "port": 26379
    },
    {
      "match_type": "regex",
      "target": "^redis-[a-z0-9-]+\\.internal$",
      "port": 6379
    }
  ]
}
  • Jede Bridge kann bis zu 32 Routen haben; insgesamt sind in einem Projekt 256 automatische Routen möglich. Jede Route gleicht einen Hostnamen oder eine IP und einen erforderlichen TCP-Port ab.
  • exact gleicht einen Hostnamen oder eine IP ab. regex akzeptiert eine sichere, verankerte ^...$-Teilmenge mit höchstens einer quantifizierten Zeichenklasse, etwa [a-z0-9-]+. Gruppen, Lookarounds, Backreferences, Alternation, geschweifte Klammern, nicht escapte Punkte und breite .*-Muster werden abgelehnt.
  • Explizite .cnc-bridge-<bridge_id>-Hostnamen haben Vorrang, gefolgt von exakten Routen und anschließend Regex-Routen. Mehrdeutige Treffer über verschiedene Bridges hinweg werden abgelehnt.
  • Listen- und Detail-Responses für Bridges enthalten route_count. Rufe Routendefinitionen über den dafür vorgesehenen Routes Endpoint ab.

Redis-Sentinel-Beispiel

Route den Sentinel-Service auf Port 26379 und die möglichen Master-Hostnamen auf Port 6379. Verwende anschließend die gewöhnlichen Hostnamen in redis-py:

tools/redis_health.py
from redis.sentinel import Sentinel

sentinel = Sentinel(
    [("redis-sentinel.internal", 26379)],
    socket_timeout=1,
)
redis = sentinel.master_for("orders-primary", socket_timeout=1)

# Der von Sentinel zurückgegebene Master-Hostname wird automatisch geroutet.
value = redis.get("health")

Routing und Autorisierung sind getrennt. Ist ALLOWED_HOSTS konfiguriert, müssen Sentinel und jeder mögliche Master exakt aufgelistet sein, zum Beispiel ALLOWED_HOSTS=redis-sentinel.internal:26379,redis-1.internal:6379,redis-2.internal:6379. Gibt Sentinel IP-Adressen bekannt, verwende anstelle des obigen Hostname-Musters exakte IP-Routen oder einen eng begrenzten IP-Regex.

Hinweise
  • Ist für den Bridge-Agenten ALLOWED_HOSTS konfiguriert, muss Host:Port des Ziels in dieser Liste stehen. Ohne Wert oder mit einer leeren Liste ist jedes aus dem Netzwerk der Bridge erreichbare Ziel erlaubt.
  • Automatische Routen erhalten den ursprünglichen Hostnamen für die TLS-Verifizierung. Bei Verwendung eines expliziten Bridge-Hostnamens wird SNI / server_hostname als tatsächliches Ziel konfiguriert, sofern der Client Zertifikate prüft.
  • Automatisches Routing unterstützt synchrone Standard-Sockets und asyncio-TCP-Verbindungen. Benutzerdefinierte native Resolver, auf aiodns basierende Bibliotheken und später aufgebaute Verbindungen aus Hintergrund-Threads benötigen den expliziten Bridge-Hostnamen.
4

MCP Server

Private MCP Server, die in einer VPC, On-Premises oder hinter einer Unternehmens-Firewall laufen, werden über das Feld bridge im Server-Eintrag der Agent-YAML erreicht. Connic tunnelt die Streamable-HTTP-Verbindung durch die Bridge und handelt mit dem Server MCP 2026-07-28 oder eine unterstützte frühere Revision aus.

agents/agent.yaml
mcp_servers:
  - name: internal-mcp
    url: http://mcp.internal:8080/mcp
    bridge: ${INTERNAL_BRIDGE_ID}

Ist für den Bridge-Agenten ALLOWED_HOSTS konfiguriert, muss die Liste Host:Port des MCP Servers enthalten. Weitere Details stehen unter Private MCP Server über eine Bridge.

Konfigurationsreferenz

VariableErforderlichBeschreibung
BRIDGE_TOKENJaBridge-Authentifizierungstoken aus dem Connic Dashboard
ALLOWED_HOSTSNeinOptionale, durch Kommas getrennte Host:Port-Allowlist. Ohne Wert oder mit einer leeren Liste ist jedes über das Netzwerk erreichbare Ziel erlaubt.
RELAY_URLNeinConnic Tunnel Endpoint (Standard: wss://relay.connic.co)
LOG_LEVELNeinDEBUG, INFO, WARNING oder ERROR (Standard: INFO)

Sicherheit

  • Nur ausgehend – die Bridge akzeptiert nie eingehende Verbindungen. Es müssen keine Ports geöffnet werden.
  • Optionale erlaubte Hosts – konfiguriere exakte Host:Port-Werte, um die erreichbaren Ziele der Bridge einzuschränken. Ohne Wert oder mit einer leeren Liste ist jedes aus ihrem Netzwerk verfügbare Ziel erlaubt.
  • Token-Authentifizierung – jede Bridge hat einen eigenen Token, der an ein einzelnes Connic-Projekt gebunden ist. Tokens können jederzeit rotiert werden; für dasselbe Projekt lassen sich mehrere Bridges in verschiedenen Netzwerken ausführen.
  • TLS-Verschlüsselung – die Kommunikation zwischen Bridge und Connic Tunnel Endpoint verwendet WSS (WebSocket über TLS).

Fehlerbehebung

Prüfe, ob der Bridge-Container läuft (docker ps) und ausgehenden Internetzugriff hat. Stelle sicher, dass der Token korrekt ist und nicht neu generiert wurde.

Die Verbindung verweist auf eine Bridge, die derzeit nicht verbunden ist. Starte den passenden Connic-Bridge-Agenten im privaten Netzwerk oder stelle das Dropdown Bridge der Verbindung auf eine andere Bridge oder auf None.

Die Bridge hat die Verbindung abgelehnt, weil Host:Port des Ziels nicht in der Liste erlaubter Hosts steht. Füge den Wert der Umgebungsvariablen ALLOWED_HOSTS (oder dem Flag --allow) des Bridge-Containers hinzu und starte ihn neu.

Die Bridge ist mit Connic verbunden, kann aber keine Verbindung zum Ziel-Service aufbauen. Prüfe, ob der Bridge-Container Host:Port des Ziels aus seinem Netzwerk erreichen kann (z. B. über docker exec connic-bridge nc -zv kafka 9092).