Fernzugriff auf lokale LLMs – Sicherheitsvergleich

Ihr Modell läuft auf Ihrer eigenen Hardware. Dennoch müssen Sie von anderen Geräten aus darauf zugreifen können – etwa von einem anderen Computer, dem Laptop eines Kollegen oder einem gehosteten Programmieragenten. Auf dieser Seite werden 4 Methoden zur sicheren Realisierung dieses Zugriffs vorgestellt, wobei die jeweiligen Vor- und Nachteile transparent dargestellt werden.

Kurzfassung der Ergebnisse

Methode	Öffnen von eingehenden Ports	Funktioniert auch hinter CGNAT	Integrierte Authentifizierung	Zeitaufwand für die Einrichtung	Am besten geeignet für
SSH-Tunnel	Nein	Nein	Nur Betriebssystem-Anmeldeinformationen	5 Minuten	Einzelner Entwickler, schneller Test
Tailscale	Nein	Ja	Tailnet-Identität	10 Minuten	Mesh-Netzwerk für persönliche Geräte
Cloudflare Tunnel	Nein	Ja	Ihre eigene Schicht	15 Minuten	Öffentliche Webanwendung hinter einem Edge-Service
Tokios-Connector	Nein	Ja	`sk-tok-…` API-Schlüssel	2 Minuten	Bereitstellung einer lokalen Modell-API

Alle 4 Methoden verzichten darauf, einen eingehenden Port zu öffnen. Sie unterscheiden sich lediglich darin, wer den Endpunkt aufrufen darf, wie die Authentifizierung abläuft sowie ob sie speziell für API-Anwendungsfälle konzipiert wurden.

Bedrohungsmodell für lokale LLM-APIs

Bevor wir verschiedene Methoden vergleichen, sollten Sie sich bewusst machen, welche Risiken bei der Freigabe eines lokalen Inferenzservers entstehen können:

Bedrohung	Auswirkung	Wahrscheinlichkeit bei fehlender Authentifizierung
Unbefugte Inferenzaufrufe	Kosten für GPU-Ressourcen sowie Datenabfluss	Sehr hoch – Scanner identifizieren offene Endpunkte bereits innerhalb weniger Stunden
Abfluss der Modellgewichte	Diebstahl von IP-Adressen	Mittel – erfordert Zugriff auf den API-Schlüssel von `/v1/models` bzw. auf die Pull-Endpunkte
Prompt-Injection über einen gemeinsam genutzten Endpunkt	Falsche Nutzung der verfügbaren Rechenressourcen	Mittel – mehrfache Nutzung durch verschiedene Benutzer ohne individuelle API-Schlüssel
Man-in-the-Middle-Angriffe auf unverschlüsselte Tunnelverbindungen	Diebstahl von Zugangsdaten	Gering – alle nachfolgenden 4-Methoden nutzen TLS
Verweigerung des Dienstes	Überlastung der GPU	Mittel – auf den zugrunde liegenden Backends gibt es keine Begrenzung der Anfragen

Das Hauptprinzip: eine lokale Modell-API verfügt über kein integriertes Benutzermanagement. Ollama, vLLM, llama.cpp sowie LM Studio stellen standardmäßig nicht authentifizierte Endpunkte bereit. Die Authentifizierung muss durch eine zusätzliche Komponente erfolgen.

Methode 1: SSH-Tunnel

SSH-Tunnel leiten einen lokalen Port über eine verschlüsselte SSH-Sitzung weiter. Sie stellen die älteste und manuellste Methode dar.

Funktionsweise

ssh -L 8000:127.0.0.1:8000 user@your-server-ip

Sie stellen per SSH eine Verbindung zum Rechner her und leiten den Port 8000 auf Ihren lokalen Rechner weiter. Solange der Tunnel aktiv ist, rufen Sie http://localhost:8000 auf, als befände sich das Modell direkt vor Ort.

Sicherheitsmerkmale

Verschlüsselung: SSH gewährleistet eine starke Verschlüsselung.
Authentifizierung: Es werden Anmeldedaten auf Betriebssystemebene verwendet – also ein Passwort oder ein Schlüsselpaar.
Zugriffsbereich: Jeder, der den SSH-Schlüssel besitzt, erhält vollen Shell-Zugriff auf den Rechner – nicht bloß Zugriff auf den API-Port.

Nachteile bei der Nutzung für LLMs

SSH erfordert eine stabile öffentliche IP-Adresse bzw. einen Zwischenrechner; CGNAT verhindert die Nutzung komplett.
Bei Netzwerkänderungen brechen die Tunnel ab und stellen keine automatische Neuanbindung her.
Jeder Nutzer benötigt seinen eigenen Tunnel sowie eigene SSH-Anmeldedaten – ein Konzept wie ein begrenzter API-Schlüssel existiert nicht.
Es gibt keine native Unterstützung für Streaming; der Client muss das erneute Verbinden selbst handhaben.

Wann ist diese Methode sinnvoll?

SSH-Tunnel eignen sich für einzelne Entwickler, die etwas schnell testen möchten. Für Teams, Agenten oder Anwendungen, die unbeaufsichtigt laufen müssen, sind sie jedoch nicht geeignet.

Methode 2: Tailscale

Tailscale erstellt ein Zero-Trust-Netzwerk (ein sogenanntes „Tailnet“) zwischen Ihren Geräten. Jedes Gerät erhält eine stabile IP-Adresse, und der Datenverkehr läuft über verschlüsseltes WireGuard.

Funktionsweise

# Install Tailscale on the model server
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Access the model at the Tailscale IP from any tailnet device
curl http://100.x.y.z:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama3", "messages": [{"role": "user", "content": "Hello!"}]}'

Sicherheitsmerkmale

Verschlüsselung: WireGuard mit gerätespezifischen Schlüsseln.
Authentifizierung: Die Identität der Geräte wird vom Tailscale-Koordinierungsserver überprüft.
Zugriffsbereich: Nur Geräte, die Sie zu Ihrem Tailnet hinzugefügt haben, können auf das Modell zugreifen.

Einschränkungen bei der Nutzung mit LLMs

Jeder Anrufer muss zunächst Ihrem Tailnet beitreten. Das funktioniert für eigene Geräte, doch für Teammitglieder, SaaS-Kunden oder Programmier-Agenten, die einen API-Schlüssel benötigen, ist das keine praktikable Lösung – schließlich erfordert es ein VPN.
Mit Tailscale Funnel lässt sich ein Dienst öffentlich verfügbar machen; allerdings sind nur die Ports 443, 8443 sowie 10000 zulässig. Die Bandbreite ist begrenzt und nicht konfigurierbar.
Es gibt keine Verwaltung von API-Schlüsseln – Sie steuern lediglich den Gerätezugriff, nicht die Authentifizierung pro Anfrage.
Der Modellserver verfügt zudem über keinerlei Authentifizierungsebene; jeder Nutzer im Tailnet kann ihn ohne jegliche Anmeldedaten aufrufen.

Wann man es verwenden sollte

Tailscale eignet sich hervorragend für die persönliche Nutzung auf mehreren Geräten – etwa wenn man vom Laptop aus auf den Heimserver zugreifen möchte. Es ist das ideale Werkzeug, wenn man alle Geräte selbst kontrolliert und keine API-Schlüssel weitergeben muss.

Methode 3: Cloudflare Tunnel

Der Cloudflare Tunnel (cloudflared) leitet den Datenverkehr über das Edge-Netzwerk von Cloudflare weiter, wobei kein eingehender Port erforderlich ist. Er fungiert dabei als Reverse-Proxy.

Funktionsweise

# cloudflared config.yml
tunnel: ct-tok-XXXX
credentials-file: /etc/cloudflared/creds.json

ingress:
  - hostname: llm.example.com
    service: http://127.0.0.1:8000
  - service: http_status:404

cloudflared tunnel run llm-tunnel

Sicherheitsmerkmale

Verschlüsselung: Zwischen Client und Cloudflare-Edge erfolgt die Kommunikation per TLS; anschließend wird die Verbindung von Cloudflare zum Ursprungsserver verschlüsselt.
Authentifizierung: Diese lässt sich individuell einrichten – etwa mittels Cloudflare Access, API-Token oder eigenem Middleware-Code.
Zugriffsbereich: Standardmäßig ist der Zugriff öffentlich möglich; zusätzliche Authentifizierung lässt sich problemlos hinzufügen.

Einschränkungen bei der Nutzung mit LLMs

Pufferung: Cloudflare führt standardmäßig eine Pufferung der Antworten durch, sofern kein text/event-stream Content-Type-Header in der Antwort enthalten ist. Dadurch kann das SSE-Streaming gestört oder verzögert werden.
Proxy-Timeout: Im kostenlosen Tarif beträgt das Proxy-Timeout bei Cloudflare etwa 100 Sekunden. Lange Generierungsprozesse – insbesondere bei großem Kontextumfang oder hohem max_tokens – können dadurch vorzeitig abgebrochen werden.
Keine API-Schlüssel-Schicht: Sie müssen die Authentifizierung selbst implementieren – etwa mittels Cloudflare Access, eines Middlewares oder eines API-Gateways.
Komplexität: Die Verwaltung von DNS-Einträgen, Cloudflare Access-Richtlinien sowie des Tunnel-Lebenszyklus erhöht den Aufwand erheblich.

Wann ist diese Lösung sinnvoll?

Cloudflare Tunnel eignet sich, wenn Sie eine Webanwendung hinter dem Cloudflare-Edge veröffentlichen und bereits deren Ökosystem nutzen. Für reine Inferenz-APIs ist das Verhalten bezüglich Pufferung und Zeitüberschreitungen jedoch problematisch, sofern keine umfangreichen Anpassungen vorgenommen werden.

Methode 4: Der Tokios-Connector

Der Tokios-Connector wurde speziell dafür entwickelt, einen lokalen Modell-Endpunkt in eine authentifizierte API zu verwandeln, die von überall aus erreichbar ist.

So funktioniert es

Installieren Sie den Connector auf dem Modell-Server.

Windows

irm https://tokios.com/downloads/install/windows | iex; tokios-install -Code 'TKS-XXXX-XXXX'

macOS

curl -fsSL https://tokios.com/downloads/install/macos | sh -s -- --code TKS-XXXX-XXXX

Linux

curl -fsSL https://tokios.com/downloads/install/linux | sh -s -- --code TKS-XXXX-XXXX

Registrieren Sie eine Deployment und erstellen Sie anschließend einen API-Schlüssel.

Im Tokios dashboard registrieren Sie Ihr Modell unter einem öffentlichen Namen (zum Beispiel llama3-tunnel) und legen danach einen sk-tok-…-Schlüssel an, der ausschließlich für dieses Modell gilt.

Aufruf aus beliebigen Orten

curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "llama3-tunnel", "messages": [{"role": "user", "content": "Hello!"}]}'

Sicherheitsmerkmale

Verschlüsselung: TLS-Verschlüsselung vom Client zu api.tokios.com, anschließend TLS-Verschlüsselung durch den ausgehenden Tunnel bis zu Ihrem Rechner.
Authentifizierung: Bei jedem Anfragevorgang wird ein Bearer-Token (sk-tok-…) verwendet; zudem lässt sich ein spezifisches Modell festlegen.
Zugriffsbereich: Jeder API-Schlüssel kann auf bestimmte Deployments beschränkt werden. Durch das Entziehen eines Schlüssels wird der Zugriff sofort gesperrt – ohne dass der Connector oder das Backend beeinflusst werden.

Architektur

Der Connector stellt ausschließlich ausgehende Verbindungen zu https://api.tokios.com her. Auf Ihrem Rechner wird kein eingehender Port geöffnet. Es werden weder DNS-Einträge noch eine öffentliche IP-Adresse benötigt, ebenso wenig eine Portweiterleitung.

Your machine                    api.tokios.com              Caller
─────────────                   ──────────────              ──────
vLLM/Ollama ─┐                                            sk-tok-… key
  (localhost) ├─ connector ──── outbound tunnel ────►  gateway ──► HTTPS request
             └─ no inbound     (initiates connection)    (auth +
                port open                                routing)

Wann ist dieser Connector sinnvoll?

Tokios eignet sich besonders, wenn Sie:

Modellzugriffe mit Teammitgliedern teilen möchten, wobei für jede Person ein eigener API-Schlüssel vergeben wird.
Programmier-Agenten wie Claude Code, Codex oder Cline nutzen wollen, die eine standardmäßige OpenAI- oder Anthropic-Basis-URL erwarten.
Hinter CGNAT, Firmen-NAT oder anderen Netzwerken arbeiten müssen, in denen eingehende Verbindungen blockiert sind.
Auf den Aufbau und die Pflege einer eigenen Authentifizierungsebene verzichten wollen.

Vergleichstabelle

Eigenschaft	SSH-Tunnel	Tailscale	Cloudflare Tunnel	Tokios-Connector
Eingehender Port ist geöffnet	Nein	Nein	Nein	Nein
Funktioniert auch hinter CGNAT	Nein	Ja	Ja	Ja
Authentifizierung	SSH-Schlüssel (vollständiger Shell-Zugriff)	Geräteidentität (Tailnet)	Sie erstellen es selbst	`sk-tok-…` API-Schlüssel
Einschränkung der API-Schlüssel auf einzelne Nutzer	Nein	Nein	Zugriff ist erforderlich	Ja – pro Deployment
SSE-Streaming	Manuelle Wiederverbindung	Ja	Standardmäßig gepuffert	Nativer SSE-Support
Unterstützung für lange Generierungsvorgänge	Ja	Ja	Etwa 100 Sekunden Timeout	Keine Begrenzung
Kompatibel mit OpenAI/Anthropic	Nein – reiner Port	Nein – reiner Port	Nein – reiner Port	Ja – beide APIs
Komplexität der Einrichtung	Gering (1 Befehl)	Mittel (Installation sowie Verbindung)	Hoch (DNS-Einstellungen, Konfiguration sowie Zugriffsberechtigungen)	Niedrig (1 Befehl sowie Dashboard)
Erneute Verbindung bei Netzwerkänderung	Nein	Ja (WireGuard)	Ja	Ja
Mehrbenutzerfähigkeit ab Tag 1	Nein	Nein – jeder Nutzer tritt dem Tailnet separat bei	Mittels Access ist dies möglich	Ja – es können API-Schlüssel erstellt werden
Dies ist speziell für Modell-APIs konzipiert	Nein	Nein	Nein	Ja

Empfehlungen je nach Anwendungsfall

Anwendungsfälle	Empfohlene Vorgehensweise	Begründung
Schneller Test direkt von Ihrem Laptop aus	SSH-Tunnel	1 Befehl, nichts zu installieren
Persönlicher Zugriff auf mehrere Geräte	Tailscale	WireGuard-Netzwerk mit stabilen IP-Adressen; nach der Einrichtung keine weitere Konfiguration nötig
Öffentliche Webanwendung hinter einem CDN	Cloudflare Tunnel	Edge-Caching sowie Schutz vor DDoS-Angriffen – ideal für Web-Verkehr
Teilen Sie ein Modell mit Ihren Teamkollegen	Tokios Connector	Individuelle API-Schlüssel pro Person, kein VPN erforderlich, zielgerichteter Zugriff
Verbinden Sie einen Coding-Agenten	Tokios Connector	Standardmäßige OpenAI/Anthropic-Basis-URL mit Streaming-Unterstützung
Nutzung hinter CGNAT oder firmeninternem NAT	Tokios Connector oder Tailscale	Beide Lösungen funktionieren auch ohne öffentliche IP-Adresse
Produktionsfähige API für mehrere Nutzer	Tokios Connector	Authentifizierung, API-Schlüssel-Rotation sowie Streaming sind bereits integriert.

Diese Methoden schließen einander nicht aus; Sie können Tailscale für den Zugriff auf persönliche Geräte sowie Tokios für den Zugriff von Teammitgliedern oder Agenten auf demselben Rechner nutzen – sie stehen in keiner Weise im Widerspruch zueinander.

Was wäre, wenn man lediglich einen Port öffnet?

Durch das Einstellen von OLLAMA_HOST=0.0.0.0, das Weiterleiten eines Router-Ports oder das Binden von vLLM an 0.0.0.0 wird das Modell erreichbar – allerdings ohne jegliche Authentifizierung. Sicherheitsforscher berichteten von etwa 175,000 öffentlich zugänglichen Ollama-Hosts im Internet (SentinelLABS/Censys, 2026). Scanner durchsuchen das gesamte Internet und indexieren solche Dienste innerhalb weniger Stunden. Keine der oben genannten 4 Methoden erfordert das Öffnen eines eingehenden Ports; daher sollte man sie nicht zugunsten einer breiteren Portfreigabe außer Acht lassen.

Ihr Modell bleibt lokal – Ihr Endpunkt ist überall nutzbar.

Unabhängig von der gewählten Methode gilt stets: Das Modell verlässt Ihren Rechner niemals, und Sie entscheiden selbst, welchen Endpunkt Sie freigeben. Tokios stellt dabei den einfachsten Weg dar, um den Endpunkt sicher für mehrere Nutzer zugänglich zu machen.

Detaillierte Betrachtungen

Jeder der folgenden Vergleiche geht über die obige Tabelle hinaus – sie behandeln Architektur, Fehlerverhalten sowie spezifische Arbeitslastbedingungen, die dazu führen, dass eine Methode der anderen überlegen ist.

Tokios im Vergleich zu Tailscale

Gerätenetzwerk versus API-Gateway: Wann genügt ein Peer-to-Peer-Netzwerk via WireGuard und wann sind zielgerichtete API-Schlüssel erforderlich?

Tokios im Vergleich zu Cloudflare Tunnel

SSE-Pufferung, Proxy-Timeouts sowie der Grund, weshalb Cloudflares Edge-Infrastruktur das Streaming von Inferenzergebnissen stillschweigend unterbrechen kann.

Tokios im Vergleich zu LiteLLM

Open-Source-Proxy für mehrere Anbieter versus verwalteter Tunnel – sowie die Kombination beider Lösungen.

Tokios im Vergleich zu einer selbst erstellten Infrastruktur

Die vollständig selbst gehostete Infrastruktur auf der 7. Ebene – inklusive Laufzeitumgebung, Proxy, Tunnel, Authentifizierung, TLS, DNS sowie Überwachung – und wann sich der Aufwand lohnt.

In welchen Fällen ist Tokios die richtige Wahl?

Entscheidungshilfe: CGNAT, Teamgröße, Kompatibilität mit Agenten sowie Anforderungen an Netzwerkisolation – welches Tool passt zu welchen Rahmenbedingungen?

Schnellstartanleitung

Verknüpfen Sie einen Connector und registrieren Sie Ihr erstes Modell in nur 2 Minuten.

Warum ausschließlich ausgehende Verbindungen?

Die zugrundeliegende Architekturentscheidung und welche Probleme dadurch vermieden werden.

Fernzugriff auf vLLM

Schritt-für-Schritt-Anleitung zur Freischaltung des lokalen vLLM-Servers.

Checkliste zur Absicherung

10 Schritte zur Sicherung einer selbstgehosteten LLM-Deployment.

​Kurzfassung der Ergebnisse

​Bedrohungsmodell für lokale LLM-APIs

​Methode 1: SSH-Tunnel

​Funktionsweise

​Sicherheitsmerkmale

​Nachteile bei der Nutzung für LLMs

​Wann ist diese Methode sinnvoll?

​Methode 2: Tailscale

​Funktionsweise

​Sicherheitsmerkmale

​Einschränkungen bei der Nutzung mit LLMs

​Wann man es verwenden sollte

​Methode 3: Cloudflare Tunnel

​Funktionsweise

​Sicherheitsmerkmale

​Einschränkungen bei der Nutzung mit LLMs

​Wann ist diese Lösung sinnvoll?

​Methode 4: Der Tokios-Connector

​So funktioniert es

​Sicherheitsmerkmale

​Architektur

​Wann ist dieser Connector sinnvoll?

​Vergleichstabelle

​Empfehlungen je nach Anwendungsfall

​Was wäre, wenn man lediglich einen Port öffnet?

​Ihr Modell bleibt lokal – Ihr Endpunkt ist überall nutzbar.

​Detaillierte Betrachtungen

Tokios im Vergleich zu Tailscale

Tokios im Vergleich zu Cloudflare Tunnel

Tokios im Vergleich zu LiteLLM

Tokios im Vergleich zu einer selbst erstellten Infrastruktur

In welchen Fällen ist Tokios die richtige Wahl?

Schnellstartanleitung

Warum ausschließlich ausgehende Verbindungen?

Fernzugriff auf vLLM

Checkliste zur Absicherung

Kurzfassung der Ergebnisse

Bedrohungsmodell für lokale LLM-APIs

Methode 1: SSH-Tunnel

Funktionsweise

Sicherheitsmerkmale

Nachteile bei der Nutzung für LLMs

Wann ist diese Methode sinnvoll?

Methode 2: Tailscale

Funktionsweise

Sicherheitsmerkmale

Einschränkungen bei der Nutzung mit LLMs

Wann man es verwenden sollte

Methode 3: Cloudflare Tunnel

Funktionsweise

Sicherheitsmerkmale

Einschränkungen bei der Nutzung mit LLMs

Wann ist diese Lösung sinnvoll?

Methode 4: Der Tokios-Connector

So funktioniert es

Sicherheitsmerkmale

Architektur

Wann ist dieser Connector sinnvoll?

Vergleichstabelle

Empfehlungen je nach Anwendungsfall

Was wäre, wenn man lediglich einen Port öffnet?

Ihr Modell bleibt lokal – Ihr Endpunkt ist überall nutzbar.

Detaillierte Betrachtungen