Remote-Zugriff auf Ollama über Tailscale oder WireGuard, ohne öffentliche Ports

Remote-Zugriff auf Ollama ohne öffentliche Ports

Inhaltsverzeichnis

Ollama ist am glücklichsten, wenn es wie ein lokaler Daemon behandelt wird: Die CLI und Ihre Apps kommunizieren mit einer Loopback-HTTP-API, und der Rest des Netzwerks erfährt nie von ihrer Existenz.

Standardmäßig ist genau das, was passiert: Die gemeinsame lokale Basisadresse befindet sich auf localhost Port 11434.

ollama remote access

Dieser Artikel behandelt den Moment, in dem Sie Zugriff von außen wünschen (Laptop, ein anderer Bürocomputer, vielleicht ein Telefon), aber keinen authentizierungslosen Modellrunner in das gesamte Internet veröffentlichen möchten. Diese Absicht ist wichtig, weil der einfachste Skalierungsschritt (einen Port öffnen, weiterleiten, fertig) auch der Schritt ist, der das Chaos erzeugt.

Ein praktischer Nordstern ist einfach: Halten Sie die Ollama-API privat und machen Sie den privaten Netzwerkpfad langweilig. Tailscale und WireGuard sind zwei gängige Wege, dies zu tun, und der Rest besteht darin sicherzustellen, dass der Host nur dort lauscht, wo er es sollte, und die Firewall dem zustimmt.

Remote-Gerät
  |
  | (privater VPN-Pfad: tailscale oder wireguard)
  v
VPN-Schnittstelle auf dem Host (tailscale0 oder wg0)
  |
  | (lokaler Hop)
  v
Ollama-Server (HTTP-API auf localhost oder VPN-IP)

Wie Ollama neben vLLM, Docker Model Runner, LocalAI und Cloud-Hosting-Abwägungen passt, erfahren Sie in LLM-Hosting 2026: Lokal, Self-Hosted und Cloud-Infrastruktur im Vergleich.

Verwandte Leitfäden:

Bedrohungsmodell und wer die API erreichen sollte

Wie kann Ollama aus der Ferne zugegriffen werden, ohne es im öffentlichen Internet freizugeben? Die Antwort liegt weniger in einem bestimmten Werkzeug, sondern mehr in der Präzision bezüglich „wer darf sich verbinden" und „von wo aus".

Ein nützliches mentales Modell sind drei konzentrische Ringe:

  • Nur lokal: Nur Prozesse auf dem Gerät können die API aufrufen.
  • Nur LAN: Geräte im gleichen lokalen Netzwerk können die API aufrufen.
  • Nur VPN: Ausgewählte Geräte und Benutzer in einem privaten Overlays-Netzwerk können die API aufrufen.

Der erste Ring ist der Standard. Viele Leitfäden (und Tools wie Postman) gehen davon aus, dass die Basis-URL localhost 11434 ist, was sowohl bequem als auch eine überraschend starke Sicherheitsgrenze darstellt.

Der Grund, warum die Ringe wichtig sind, ist, dass Ollama häufig als System beschrieben wird, das keine eingebaute Authentifizierung für seine lokale HTTP-API bietet. Das bedeutet, dass Netzwerkaussetzung und Zugriffskontrolle Ihre Aufgabe werden, wenn Sie über localhost hinausgehen.

Der andere Grund sind Kosten und Missbrauch: Selbst ein „privater" LLM-Endpunkt ist immer noch ein API-Endpunkt. Die OWASP API Security Top 10 nennt Kategorien wie Sicherheitsfehlkonfiguration und unbeschränkter Ressourcenverbrauch; ein Modellrunner ist praktisch ein Vorbild für „Ressourcenverbrauch", wenn er leichtsinnig freigegeben wird.

Das grundlegende Bedrohungsmodell ist also nicht nur „ein Angreifer liest meine Daten". Es ist auch „jemand kann meine CPU und GPU wie ein Mietwagen nutzen" und „unbeabsichtigte Benutzer entdecken es und beginnen, darauf aufzubauen".

OLLAMA_HOST und Bind-Semantik in 90 Sekunden

Was macht OLLAMA_HOST und was ist der sicherste Standardwert? OLLAMA_HOST ist der Schalter, der steuert, wo der Ollama-Server lauscht. In ollama serve wird die Umgebungsvariable als die IP-Adresse und der Port für den Server beschrieben, mit einem Standardwert von 127.0.0.1 und Port 11434.

Kurz gesagt, die Bind-Adresse entscheidet, welche Netzwerke überhaupt einen TCP-Connection-VERSUCH unternehmen können:

  • 127.0.0.1 bedeutet nur localhost.
  • Eine LAN-IP (wie 192.168.x.y) bedeutet, dass das LAN darauf zugreifen kann.
  • 0.0.0.0 bedeutet alle Schnittstellen (LAN, VPN, alles), können darauf zugreifen, es sei denn, eine Firewall blockiert sie.

Deshalb schlagen die meisten „mach es zugänglich"-Anleitungen vor, von 127.0.0.1 auf 0.0.0.0 zu wechseln, aber dieser Rat ist ohne eine Schnittstellen-aware Firewall unvollständig.

Hier ist die Referenzkarte, die ich im Kopf habe:

# Nur lokal (Basislinie)
export OLLAMA_HOST=127.0.0.1:11434

# Alle Schnittstellen (mächtig, leicht zu bereuen)
export OLLAMA_HOST=0.0.0.0:11434

# Nur VPN-Schnittstelle (empfohlen, wenn das VPN eine stabile IP auf dem Host hat)
export OLLAMA_HOST=100.64.0.10:11434   # Beispiel-Tailscale-IP
export OLLAMA_HOST=10.10.10.1:11434    # Beispiel-WireGuard-IP

# Anderer Port (nützlich, wenn 11434 bereits belegt ist)
export OLLAMA_HOST=127.0.0.1:11435

Der Fall „anderer Port" wird im Ollama-Issue-Tracker explizit als Beispiel für die Verwendung von OLLAMA_HOST zur Änderung des Listen-Ports diskutiert.

Ein operativer Hinweis, der Menschen beißt: Wenn Ollama als verwalteter Dienst läuft, ändert das Setzen von Umgebungsvariablen in einer interaktiven Shell nicht unbedingt die Dienstkonfiguration. Deshalb enden viele „es funktionierte in meinem Terminal, aber nicht nach dem Neustart"-Geschichten in systemd-Einheit-Überschreibungen oder Dienstmanager-Konfigurationen.

Muster A: Zuerst VPN mit Tailscale

Kann Tailscale den Zugriff auf nur einen Dienst-Port auf einer Maschine einschränken? Ja, und das ist ein großer Teil davon, warum Tailscale gut für „Zugriff aus der Ferne ohne Veröffentlichung" geeignet ist.

Tailscale bietet Ihnen ein privates Netzwerk (ein Tailnet) mit zentral verwalteten Zugriffskontrollen (ACLs). ACLs existieren speziell, um Geräteberechtigungen zu verwalten und das Netzwerk zu sichern.

Kein öffentlicher Port bedeutet keine Router-Choreografie

Das sauberste Muster besteht darin, überhaupt keinen internetorientierten Port für Ollama zu öffnen und das VPN als einzige Eingangsstelle zu behandeln. Mit Tailscale versuchen Geräte, wann immer möglich, direkt peer-to-peer zu verbinden, und können auf Relay-Mechanismen ausweichen, wenn eine direkte Konnektivität nicht möglich ist.

Dies ist keine Sicherheitsmagie an sich, aber es schrumpft den Explosionsradius im Vergleich zu „Ich habe 11434 auf meinem Router weitergeleitet" radikal.

Split-Horizon und Benennung mit MagicDNS

Eine zweite Frage, die im echten Leben auftaucht, ist: „Verbinde ich mich über die LAN-IP, wenn ich zu Hause bin, und über die VPN-IP, wenn ich unterwegs bin". Das ist im Grunde ein Split-Horizon-Problem.

Tailscale MagicDNS hilft, indem es jedem Gerät einen stabilen Tailnet-Hostnamen gibt. Hinter den Kulissen generiert MagicDNS einen FQDN für jedes Gerät, der den Maschinennamen und Ihren Tailnet-DNS-Namen kombiniert, und moderne Tailnet-Namen enden in .ts.net.

Die Meinungsposition ist, dass die Verwendung eines Namens in der Regel besser ist als das Hard-Coding einer IP, weil der Name dem Gerät folgt, selbst wenn sich Ihre Tailnet-IP ändert. Es ist jedoch auch in Ordnung, absichtlich langweilig zu sein und eine kleine Hosts-Datei oder einen einzelnen internen DNS-Eintrag zu behalten, wenn Sie das bevorzugen. MagicDNS existiert, damit Sie das nicht tun müssen.

Direkter Port versus Tailnet-only-Proxying

Es gibt zwei gängige Tailscale-Weise, um auf einen Dienst zuzugreifen:

  • Direkter Portzugriff, bei dem der Dienst auf der Tailnet-Schnittstelle lauscht und Clients sich an diese IP und diesen Port verbinden.
  • Tailscale Serve, bei dem Tailscale den Verkehr von anderen Tailnet-Geräten zu einem lokalen Dienst auf dem Host weiterleitet.

Serve wird explizit als Weiterleitung des Verkehrs von anderen Tailnet-Geräten zu einem auf Ihrem Gerät laufenden lokalen Dienst beschrieben.

Für Ollama kann Serve attraktiv sein, weil es Ihnen erlaubt, Ollama auf localhost zu behalten und nur einen kontrollierten Eingangs-Pfad über Tailscale freizugeben. Es passt sich auch natürlich an HTTPS innerhalb des Tailnetts an, wenn Sie browserfreundliche Endpunkte wünschen.

Eine verwandte Funktion, die es wert ist, genannt und dann mental geparkt zu werden, ist Funnel. Funnel ist darauf ausgelegt, Verkehr aus dem breiteren Internet auf einen Dienst auf einem Tailnet-Gerät zu leiten und ist explizit für „jeden zugänglich, auch wenn sie Tailscale nicht verwenden". Das ist das Gegenteil dieses Artikels.

Muster B: WireGuard für diejenigen, die die rohen Primitive wollen

WireGuard ist das zugrundeliegende Primitive, das viele VPN-Produkte antreibt, und ist bewusst minimalistisch: Sie konfigurieren eine Schnittstelle, definieren Peers und entscheiden, welcher Verkehr fließen darf.

Der WireGuard-Quickstart zeigt die grundlegende Form: Erstellen Sie eine Schnittstelle wie wg0, weisen Sie IPs zu und konfigurieren Sie Peers mit wg.

Das Schlüsselkonzept für die Zugriffsbegrenzung ist AllowedIPs. In der Red Hat-Dokumentation liest WireGuard die Ziel-IP aus einem Paket und vergleicht sie mit der Liste der erlaubten IP-Adressen; wenn der Peer nicht gefunden wird, verwirft WireGuard das Paket.

Für einen Ollama-Host ist die praktische Übersetzung:

  • Bringen Sie den Host auf ein privates WireGuard-Subnetz.
  • Binden Sie Ollama entweder an localhost und leiten Sie es weiter, oder binden Sie es direkt an die WireGuard-IP.
  • Nur Peers, die die richtigen Schlüssel und AllowedIPs haben, können Verkehr auf diese private IP weiterleiten.

Das sind weniger bewegliche Teile als bei einem kommerziellen Overlay, aber es bedeutet auch, dass Sie für die Schlüsselverteilung, den Peer-Lebenszyklus und dafür verantwortlich sind, wie entfernte Peers Ihr Netzwerk erreichen.

Firewall erlaubt nur VPN-Schnittstelle oder Tailnet

Wie kann eine Firewall Ollama auf nur VPN-Schnittstellenverkehr beschränken? Das Ziel ist es, eine versehentliche Freigabe zu verhindern, auch wenn die Bind-Adresse breiter wird als beabsichtigt.

Das allgemeine Muster ist:

  • Erlauben Sie den Ollama-TCP-Port nur auf der VPN-Schnittstelle (tailscale0 oder wg0).
  • Verbieten Sie denselben Port überall sonst.
  • Bevorzugen Sie „Standard-Verbot für eingehende Verbindungen", wenn Sie so für den Host arbeiten.

Tailscale hat explizite Anleitungen zur Verwendung von UFW, um nicht-Tailscale-Verkehr auf einem Server zu beschränken, was im Wesentlichen der Ansatz „alles abschließen außer dem Tailnet" ist.

Eine Nuance, die speziell für Tailscale wichtig ist, ist, dass Host-Firewall-Erwartungen der Realität nicht entsprechen, wenn Sie annehmen, dass UFW Tailnet-Verkehr blockiert. Das Tailscale-Projekt hat diskutiert, dass es absichtlich eine Regel installiert, um Verkehr auf tailscale0 zu erlauben, und auf einen durch ACL gesteuerten Filter innerhalb von tailscaled verlässt.

Das ist kein Argument gegen eine Host-Firewall. Es ist ein Argument dafür, bewusst zu sein, welche Kontrollebene die Richtlinie tatsächlich durchsetzt. Wenn Sie wollen, dass „nur diese Geräte Port 11434 erreichen können", sind Tailscale-ACLs dafür konzipiert.

Wenn Sie dennoch Schnittstellen-Level-Host-Steuerungen wünschen, sehen die Beispiele in der Regel so aus:

# UFW-ähnliche Logik (illustrierend)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Oder für WireGuard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Selbst wenn Sie sich primär auf VPN-Richtlinien verlassen, bietet die Host-Firewall immer noch eine nützliche „Sicherheitsgürtel" gegen Fehlbindungen an 0.0.0.0 oder unerwartete Dienst-Wraps.

Optionaler Reverse-Proxy nur am VPN-Eingang

Wann ist ein Reverse-Proxy für den ferngesteuerten Ollama-Zugriff nützlich? Ein Proxy ist nützlich, wenn Sie eine oder mehrere dieser Eigenschaften wünschen:

  • Ein Standard-Authentifizierungstor (Basic Auth, OIDC, Client-Zertifikate).
  • TLS-Terminierung mit einem Zertifikat, dem Clients vertrauen.
  • Anfrage-Limits und Timeouts.
  • Sauberere URLs für Tools, die rohe Ports nicht mögen.

Hier sollte die Absicht „nicht ins Internet veröffentlichen" immer noch wahr bleiben: Der Reverse-Proxy ist nur über das VPN erreichbar, nicht auf der öffentlichen WAN-Schnittstelle.

Ist TLS nötig, wenn der Verkehr ohnehin über ein VPN läuft? Nicht immer für die Kryptographie, aber oft für die Ergonomie. Tailscale weist darauf hin, dass Verbindungen zwischen Knoten bereits Ende-zu-Ende verschlüsselt sind, aber Browser sind sich dessen nicht bewusst, weil sie auf TLS-Zertifikate angewiesen sind, um HTTPS-Vertrauen herzustellen.

Wenn Sie in der Tailscale-Welt sind, können Sie HTTPS-Zertifikate für Ihr Tailnet aktivieren, was MagicDNS erfordert und explizit feststellt, dass Maschinennamen und der Tailnet-DNS-Name in einer öffentlichen Ledger (Certificate Transparency Logs) veröffentlicht werden.

Dieses Detail des öffentlichen Ledgers ist kein Grund, TLS zu vermeiden, aber es ist ein Grund, Maschinen wie ein Erwachsener zu benennen (vermeiden Sie die Einbettung privater Projektname oder Kundenkennungen in Hostnamen).

Dieser Artikel schließt absichtlich keine vollständige Reverse-Proxy-Konfiguration ein; für Caddy oder Nginx, Streaming und Auth am Rand, siehe Ollama hinter einem Reverse-Proxy mit Caddy oder Nginx für HTTPS-Streaming. Die einzige Idee, die hier zählt, ist die Platzierung:

  • Ollama lauscht auf localhost oder VPN-IP.
  • Reverse-Proxy lauscht nur auf der VPN-Schnittstelle.
  • Proxy leitet an Ollama weiter.

Sicherheits-Checkliste für den ferngesteuerten Ollama-API-Zugriff

Das ist die Checkliste, die ich verwende, um sicherzustellen, dass „remote" nicht stillschweigend zu „öffentlich" wird.

Bindung und Erreichbarkeit

  • Bestätigen Sie, dass der Server dort lauscht, wo Sie denken, dass er lauscht. Der dokumentierte Standard ist 127.0.0.1 und Port 11434, und OLLAMA_HOST ändert das.
  • Behandeln Sie 0.0.0.0 als eine bewusste Entscheidung, nicht als Bequemlichkeitsschalter.
  • Bevorzugen Sie die Bindung an eine VPN-Schnittstellen-IP, wenn sie stabil ist und zur Topologie passt.

Zugriffskontrolle

  • Wenn Sie Tailscale verwenden, implementieren Sie ACLs, die nur bestimmten Benutzern oder markierten Geräten den Zugriff auf den Ollama-Port erlauben. ACLs existieren, um Geräteberechtigungen zu verwalten.
  • Wenn Sie WireGuard verwenden, halten Sie AllowedIPs eng und behandeln Sie Schlüssel als die echte Identitätsgrenze. WireGuard wirft Pakete weg, die keine gültige Peer-AllowedIPs-Zuordnung haben.

Firewall

  • Fügen Sie eine Regel auf Host-Ebene hinzu, die den Ollama-Port nur auf tailscale0 oder wg0 erlaubt und ihn überall sonst blockiert.
  • Wenn Sie erwarten, dass UFW Tailnet-Verkehr blockiert, überprüfen Sie, wie Tailscale mit Ihrer Firewall interagiert. Tailscale hat diskutiert, dass es tailscale0-Verkehr erlaubt und sich auf die ACL-Filterung innerhalb von tailscaled verlässt.

TLS und Proxying

  • Verwenden Sie TLS, wenn Clients Browser sind oder wenn Tools HTTPS erwarten, auch wenn das VPN bereits den Transport verschlüsselt. Tailscale dokumentiert diese Lücke zwischen VPN-Verschlüsselung und Browser-HTTPS-Vertrauen.
  • Wenn Sie Tailscale-HTTPS-Zertifikate aktivieren, denken Sie an die Implikationen der Zertifikat-Transparenz für Hostnamen.
  • Wenn Sie einen Reverse-Proxy hinzufügen, halten Sie ihn VPN-only und verwenden Sie ihn für Auth und Limits, nicht für die Internet-Exposition.

Vermeiden Sie versehentliche öffentliche Freigabe

  • Seien Sie vorsichtig mit Funktionen, die explizit dafür entwickelt wurden, Dienste ins Internet zu veröffentlichen. Tailscale Funnel leitet Verkehr aus dem breiteren Internet auf ein Tailnet-Gerät um, was nicht der standard-sichere Pfad für eine Ollama-API ist.
  • Wenn irgendetwas interneterreichbar wird, lassen Sie keine anonyme /api-Oberfläche. An diesem Punkt werden die OWASP-API-Risikokategorien „Sicherheitsfehlkonfiguration" und „Ressourcenverbrauch" nicht mehr theoretisch.

Beobachtbarkeit und Schadensbegrenzung

  • Protokollieren Sie Anfragen auf der Eingangs-Ebene (VPN-Richtlinien-Logs, Proxy-Logs oder beides).
  • Fügen Sie Anfrage- und Parallelitätslimits hinzu, wenn Ihr Proxy sie unterstützt, weil Modellinferenz ein Ressourcenereignis und keine normale API-Aufruf ist.

Das konsistente Thema ist absichtlich langweilig: Halten Sie die Ollama-API standardmäßig privat, fügen Sie einen privaten Pfad für den ferngesteuerten Zugriff hinzu und erzwingen Sie diese Richtlinie doppelt (VPN-Identität plus Host-Firewall), damit ein einziger Fehler nicht zu einem öffentlichen Endpunkt wird.