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

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 dies genau das, was passiert: Die übliche lokale Basisadresse befindet sich auf localhost Port 11434.

Dieser Artikel behandelt den Moment, in dem Sie Remote-Zugriff wünschen (Laptop, ein anderer Bürocomputer, vielleicht ein Telefon), aber keinen nicht authentifizierten Modell-Läufer für 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 schafft.

Ein praktischer Nordstern ist einfach: Halten Sie die Ollama-API privat und machen Sie den Pfad des privaten Netzwerks langweilig. Tailscale und WireGuard sind zwei gängige Methoden dafür, 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)

Bedrohungsmodell und wer auf die API zugreifen sollte

Wie kann Ollama remote zugegriffen werden, ohne es dem öffentlichen Internet auszusetzen? Die Antwort liegt weniger in einem spezifischen Werkzeug, sondern mehr darin, explizit zu definieren, „wer verbinden darf" und „von wo aus".

Ein nützliches mentales Modell besteht aus drei konzentrischen Ringen:

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

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

Der Grund, warum die Ringe wichtig sind, ist, dass Ollama häufig als System beschrieben wird, das für seine lokale HTTP-API keine eingebaute Authentifizierung 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 uneingeschränkter Ressourcenverbrauch; ein Modell-Läufer ist praktisch ein Paradebeispiel für „Ressourcenverbrauch", wenn er lässig exponiert 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 fahren" und „unbeabsichtigte Benutzer entdecken es und beginnen, darauf aufzubauen".

OLLAMA_HOST und Bind-Semantik in 90 Sekunden

Was bewirkt 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.

In einfachen Worten entscheidet die Bind-Adresse, welche Netzwerke überhaupt einen TCP-Verbindungsauftrag versuchen 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-bewusste Firewall unvollständig.

Hier ist die Spickzettel, den ich im Kopf behalte:

# 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 (bevorzugt, 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 Leute beißt: Wenn Ollama als verwalteter Dienst läuft, führt das Setzen von Umgebungsvariablen in einer interaktiven Shell nicht unbedingt zu einer Änderung der Dienstkonfiguration. Deshalb enden viele „es funktionierte in meinem Terminal, aber nicht nach dem Neustart"-Geschichten in systemd-Einheit-Überschreibungen oder in der Konfiguration des Dienstmanagers.

Muster A: VPN zuerst mit Tailscale

Kann Tailscale den Zugriff auf nur einen Dienstport auf einer Maschine beschränken? Ja, und das ist ein großer Teil davon, warum Tailscale gut für „Remote-Zugriff 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 internetexponierten Port für Ollama zu öffnen und das VPN als einzigen Zugangspunkt 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 direkte Konnektivität nicht möglich ist.

Das ist für sich genommen keine magische Sicherheit, aber es schrumpft den Explosionsradius im Vergleich zu „Ich habe 11434 an meinem Router weitergeleitet" radikal.

Split-Horizon und Benennung mit MagicDNS

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

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

Die meinungsstarke Auffassung ist, dass die Verwendung eines Namens in der Regel besser ist als das Hard-Coding einer IP, weil der Name dem Gerät folgt, auch wenn sich Ihre Tailnet-IP ändert. Aber es ist 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 im Vergleich zu Tailnet-only-Proxying

Es gibt zwei gängige Tailscale-Methoden, 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 Datenverkehr von anderen Tailnet-Geräten zu einem lokalen Dienst auf dem Host umleitet.

Serve wird explizit als Weiterleitung des Datenverkehrs 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 ermöglicht, Ollama auf localhost zu behalten und nur einen kontrollierten Zugangspfad über Tailscale freizugeben. Es passt auch natürlich mit HTTPS innerhalb des Tailnets zusammen, 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, Datenverkehr aus dem breiteren Internet zu einem Dienst auf einem Tailnet-Gerät zu leiten und ist explizit dafür gedacht, „dass jeder Zugriff hat, 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 die zugrundeliegende Primitive, die viele VPN-Produkte antreibt, und ist bewusst minimal: Sie konfigurieren eine Schnittstelle, definieren Peers und entscheiden, welcher Datenverkehr fließen darf.

Der WireGuard-Schnellstart 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:

• Stellen Sie den Host auf ein privates WireGuard-Subnetz.
• Binden Sie Ollama entweder an localhost und leiten Sie dorthin weiter, oder binden Sie direkt an die WireGuard-IP.
• Nur Peers, die die richtigen Schlüssel und AllowedIPs haben, können Datenverkehr zu dieser privaten IP weiterleiten.

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

Firewall erlaubt nur VPN-Schnittstelle oder Tailnet

Wie kann eine Firewall Ollama auf nur VPN-Schnittstellen-Datenverkehr beschränken? Das Ziel ist es, eine zufällige Exposition zu verhindern, selbst wenn die Bind-Adresse breiter wird als beabsichtigt.

Das allgemeine Muster ist:

• Erlaube den Ollama-TCP-Port nur auf der VPN-Schnittstelle (tailscale0 oder wg0).
• Verweise denselben Port auf alles andere.
• Bevorzuge „Standardmäßig eingehend blockieren", wenn Sie auf diese Weise für den Host operieren.

Tailscale hat explizite Richtlinien zur Verwendung von UFW, um nicht-Tailscale-Datenverkehr zu einem Server zu beschränken, was im Wesentlichen der Ansatz „sperren Sie alles außer dem Tailnet" ist.

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

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

Wenn Sie dennoch Schnittstellen-level-Host-Kontrollen 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 die VPN-Richtlinie verlassen, bietet die Host-Firewall immer noch ein nützliches „Sicherheitsgurt" gegen Fehlbindung an 0.0.0.0 oder unerwartete Dienst-Umhüllungen.

Optionales Reverse-Proxy nur auf VPN-Zugang

Wann ist ein Reverse-Proxy für den Remote-Zugriff auf Ollama 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.
• Anfragegrenzen 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 an der öffentlichen WAN-Schnittstelle.

Wird TLS benötigt, wenn der Datenverkehr bereits über ein VPN läuft? Nicht immer für die Kryptografie, 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, da sie sich auf TLS-Zertifikate verlassen, 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 einem öffentlichen Ledger (Zertifikat-Transparenz-Protokolle) 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 private Projektnamen oder Kundenidentifikatoren in Hostnamen zu kodieren).

Dieser Artikel enthält absichtlich keine vollständige Reverse-Proxy-Konfiguration (siehe dazu Ihren Artikel A1). 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 Remote-Zugriff auf die Ollama-API

Dies 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 eine Bequemlichkeitsschalter.
• Bevorzugen Sie die Bindung an eine VPN-Schnittstellen-IP, wenn diese stabil ist und zur Topologie passt.

Zugriffskontrolle

• Wenn Sie Tailscale verwenden, implementieren Sie ACLs, die nur bestimmten Benutzern oder markierten Geräten Zugriff auf den Ollama-Port gewähren. ACLs existieren, um Geräteberechtigungen zu verwalten.
• Wenn Sie WireGuard verwenden, halten Sie AllowedIPs eng und behandeln Sie Schlüssel als die eigentliche Identitätsgrenze. WireGuard verwirft Pakete, die nicht mit einer gültigen Peer-AllowedIPs-Zuordnung übereinstimmen.

Firewall

• Fügen Sie eine Regel auf Host-Ebene hinzu, die den Ollama-Port nur auf tailscale0 oder wg0 erlaubt und ihn überall else blockiert.
• Wenn Sie erwarten, dass UFW Tailnet-Datenverkehr blockiert, überprüfen Sie, wie Tailscale mit Ihrer Firewall interagiert. Tailscale hat diskutiert, dass es tailscale0-Datenverkehr 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 den Transport bereits 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 Implikation der Zertifikat-Transparenz für Hostnamen.
• Wenn Sie einen Reverse-Proxy hinzufügen, halten Sie ihn nur auf VPN und verwenden Sie ihn für Authentifizierung und Limits, nicht für die Internet-Exposition.

Vermeiden Sie zufällige öffentliche Exposition

• Seien Sie vorsichtig mit Funktionen, die explizit dafür ausgelegt sind, Dienste im Internet zu veröffentlichen. Tailscale Funnel leitet Datenverkehr aus dem breiteren Internet zu einem Tailnet-Gerät weiter, was nicht der standardmäßig sichere Pfad für eine Ollama-API ist.
• Wenn irgendetwas interneterreichbar wird, lassen Sie keine anonyme /api-Oberfläche. An diesem Punkt sind die OWASP-API-Risk-Kategorien „Sicherheitsfehlkonfiguration" und „Ressourcenverbrauch" nicht mehr theoretisch.

Beobachtbarkeit und Schadensbegrenzung

• Protokollieren Sie Anfragen auf der Ingress-Schicht (VPN-Richtlinien-Protokolle, Proxy-Protokolle oder beide).
• Fügen Sie Anfrage- und Parallelitätslimits hinzu, wenn Ihr Proxy diese unterstützt, da Modellinferenz ein Ressourcenereignis und kein normaler 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 Remote-Zugriff hinzu und erzwingen Sie diese Richtlinie doppelt (VPN-Identität plus Host-Firewall), damit ein einziger Fehler nicht zu einem öffentlichen Endpunkt wird.