Op afstand toegang tot Ollama via Tailscale of WireGuard, zonder openbare poorten.

Toegang op afstand tot Ollama zonder openbare poorten

Inhoud

Ollama is het meest tevreden wanneer het wordt behandeld als een lokale daemon: de CLI en uw apps communiceren met een loopback HTTP API, en de rest van het netwerk komt er nooit achter dat het bestaat.

Standaard gebeurt precies dat: het gebruikelijke lokale basisadres bevindt zich op localhost poort 11434.

ollama remote access

Dit artikel gaat over het moment waarop u externe toegang wilt (laptop, een andere kantoorcomputer, misschien een telefoon), maar u geen ongeautoriseerde modelrunner aan het hele internet wilt blootstellen. Die intentie is belangrijk, omdat de eenvoudigste schaalbaarheidsstap (een poort openen, forwarden, klaar) ook de stap is die het grootste gedoe creëert.

Een praktische north star is simpel: houd de Ollama API privé, en maak het privé-netwerkpad saai. Tailscale en WireGuard zijn twee veelvoorkomende manieren om dat te doen; de rest is ervoor zorgen dat de host alleen luistert waar hij moet luisteren en dat de firewall het daarmee eens is.

Remote device
  |
  | (private VPN path: tailscale or wireguard)
  v
VPN interface on host (tailscale0 or wg0)
  |
  | (local hop)
  v
Ollama server (HTTP API on localhost or VPN IP)

Voor hoe Ollama zich verhoudt tot vLLM, Docker Model Runner, LocalAI en cloud-hosting afwegingen, zie LLM Hosting in 2026: Local, Self-Hosted & Cloud Infrastructure Compared.

Gerelateerde gidsen:

Bedreigingsmodel en wie de API mag bereiken

Hoe kan Ollama op afstand worden benaderd zonder het bloot te stellen aan het publieke internet? Het antwoord gaat minder over een specifiek hulpmiddel en meer over expliciet zijn over “wie mag verbinden” en “vanwaar”.

Een nuttig mentaal model bestaat uit drie concentrische ringen:

  • Alleen lokaal: alleen processen op de machine kunnen de API aanroepen.
  • Alleen LAN: apparaten op hetzelfde lokale netwerk kunnen de API aanroepen.
  • Alleen VPN: geselecteerde apparaten en gebruikers op een privé-overlaynetwerk kunnen de API aanroepen.

De eerste ring is de standaardinstelling. Veel gidsen (en hulpmiddelen zoals Postman) gaan ervan uit dat de basis-URL localhost 11434 is, wat zowel handig is als een verrassend sterke veiligheidsbarrière.

De reden waarom de ringen belangrijk zijn, is dat Ollama vaak wordt beschreven als een service zonder ingebouwde authenticatie voor zijn lokale HTTP API. Dit betekent dat netwerkblootstelling en toegangscontrole uw verantwoordelijkheid worden zodra u verder gaat dan localhost.

De andere reden is kosten en misbruik: zelfs een “privé” LLM-endpoint is nog steeds een API-endpoint. De OWASP API Security Top 10 noemt categorieën zoals beveiligingsmisconfiguratie en onbeperkt bronnenverbruik; een modelrunner is praktisch een posterkind voor “bronnenuitputting” als deze onvoorzichtig wordt blootgesteld.

Het basisbedreigingsmodel is dus niet alleen “een aanvalser leest mijn data”. Het is ook “iemand kan mijn CPU en GPU gebruiken alsof het een huurauto is” en “onbedoelde gebruikers ontdekken het en beginnen er tegen te bouwen”.

OLLAMA_HOST en bind-semantiek in 90 seconden

Wat doet OLLAMA_HOST en wat is de veiligste standaardwaarde? OLLAMA_HOST is de schakelaar die controleert waar de Ollama-server luistert. In ollama serve wordt de omgevingsvariabele beschreven als het IP-adres en de poort voor de server, met een standaard van 127.0.0.1 en poort 11434.

In simpele termen bepaalt het bindadres welke netwerken zelfs maar een TCP-verbinding kunnen proberen:

  • 127.0.0.1 betekent alleen localhost.
  • Een LAN-IP (zoals 192.168.x.y) betekent dat het LAN er toegang toe heeft.
  • 0.0.0.0 betekent dat alle interfaces (LAN, VPN, alles) er toegang toe hebben, tenzij een firewall dit blokkeert.

Daarom suggereren de meeste “maak het toegankelijk”-handleidingen om te schakelen van 127.0.0.1 naar 0.0.0.0, maar dat advies is onvolledig zonder een interface-bewuste firewall.

Dit is de cheat sheet die ik in mijn hoofd bewaar:

# Alleen lokaal (baseline)
export OLLAMA_HOST=127.0.0.1:11434

# Alle interfaces (krachtig, maar makkelijk om spijt van te krijgen)
export OLLAMA_HOST=0.0.0.0:11434

# Alleen VPN-interface (bij voorkeur als de VPN een stabiel IP heeft op de host)
export OLLAMA_HOST=100.64.0.10:11434   # voorbeeld tailscale IP
export OLLAMA_HOST=10.10.10.1:11434    # voorbeeld wireguard IP

# Andere poort (handig als 11434 al in gebruik is)
export OLLAMA_HOST=127.0.0.1:11435

Het geval “andere poort” wordt expliciet besproken in de Ollama-issue-tracker als een voorbeeld van het gebruik van OLLAMA_HOST om de luisterpoort te wijzigen.

Een operationale voetnoot die mensen bijt: als Ollama loopt als een beheerde service, wijzigt het instellen van omgevingsvariabelen in een interactieve shell niet noodzakelijk de service-configuratie. Dit is waarom veel verhalen over “het werkte in mijn terminal, maar niet na herstart” uiteindelijk uitmonden in systemd-eenheden-overrides of service-manager-configuratie.

Patroon A: eerst VPN met Tailscale

Kan Tailscale toegang beperken tot slechts één servicepoort op een machine? Ja, en dat is een groot deel van de reden waarom Tailscale goed past bij “externe toegang zonder publiceren”.

Tailscale biedt u een privénetwerk (een tailnet) met centraal beheerde toegangscontroles (ACL’s). ACL’s bestaan specifiek om apparaattoegang te beheren en het netwerk veilig te stellen.

Geen openbare poort betekent geen router-choreografie

Het schoonste patroon is om überhaupt geen naar het internet gerichte poort voor Ollama te openen en de VPN te behandelen als de enige ingang. Met Tailscale proberen apparaten direct peer-to-peer te verbinden waar mogelijk, en kunnen ze terugvallen op relay-mechanismen als directe connectiviteit niet mogelijk is.

Dit is op zichzelf geen magische beveiliging, maar het verkleint de explosieradius radicaal vergeleken met “ik heb 11434 op mijn router doorgestuurd”.

Split horizon en naamgeving met MagicDNS

Een tweede vraag die in het echte leven opduikt is “verbinding ik via LAN-IP als ik thuis ben en via VPN-IP als ik weg ben”. Dat is in wezen een split-horizon-probleem.

Tailscale MagicDNS helpt door elk apparaat een stabiele tailnet-hostnaam te geven. Onder de motorkap genereert MagicDNS een FQDN voor elk apparaat dat de machinaam en uw tailnet-DNS-naam combineert, en moderne tailnet-namen eindigen in .ts.net.

De mening is dat het gebruik van een naam over het algemeen beter is dan het hard-coden van een IP, omdat de naam het apparaat volgt, zelfs als uw tailnet-IP verandert. Maar het is ook prima om opzettelijk saai te blijven en een kleine hosts-bestand of een enkel intern DNS-record te houden als u dat liever heeft. MagicDNS bestaat zodat u dat niet hoeft te doen.

Directe poort versus tailnet-only proxying

Er zijn twee veelvoorkomende Tailscale-wijzen om bij een service te komen:

  • Directe poorttoegang, waarbij de service luistert op de tailnet-interface en clients verbinding maken met dat IP en die poort.
  • Tailscale Serve, waarbij Tailscale verkeer van andere tailnet-apparaten doorstuurt naar een lokale service op de host.

Serve is expliciet beschreven als het doorsturen van verkeer van andere tailnet-apparaten naar een lokale service die op uw apparaat draait.

Voor Ollama kan Serve aantrekkelijk zijn omdat het u toelaat om Ollama op localhost te houden en alleen een gecontroleerde ingangsroute via Tailscale te blootstellen. Het past ook natuurlijk aan bij HTTPS binnen het tailnet als u browser-vriendelijke endpoints wilt.

Een verwante functie die de moeite waard is om te noemen en dan mentaal op te zetten, is Funnel. Funnel is ontworpen om verkeer van het bredere internet naar een service op een tailnet-apparaat te routen en is expliciet bedoeld voor “iedereen die toegang wil, zelfs als ze geen Tailscale gebruiken”. Dat is het tegenovergestelde van dit artikel.

Patroon B: WireGuard voor diegenen die de ruwe primitieven willen

WireGuard is de onderliggende primitieve die veel VPN-producten aandrijft, en het is opzettelijk minimaal: u configureert een interface, definieert peers en beslist welk verkeer mag stromen.

De WireGuard-quickstart toont de basisvorm: maak een interface zoals wg0, wijs IP’s toe en configureer peers met wg.

Het kernconcept voor het inperken van toegang is AllowedIPs. In de Red Hat-documentatie leest WireGuard het bestemmings-IP uit een pakket en vergelijkt het met de lijst van toegestane IP-adressen; als de peer niet wordt gevonden, verwijdert WireGuard het pakket.

Voor een Ollama-host is de praktische vertaling:

  • Plaats de host op een privé WireGuard-subnet.
  • Bind Ollama ofwel aan localhost en stuur het door, of bind het direct aan het WireGuard-IP.
  • Alleen peers met de juiste sleutels en AllowedIP’s kunnen verkeer naar dat privé-IP routen.

Dit heeft minder bewegende onderdelen dan een commercieel overlay, maar het betekent ook dat u verantwoordelijk bent voor sleutelverdeling, peer-lifecycle en hoe externe peers uw netwerk bereiken.

Firewall: alleen VPN-interface of tailnet toestaan

Hoe kan een firewall Ollama beperken tot alleen VPN-interface-verkeer? Het doel is om onbedoelde blootstelling te voorkomen, zelfs als het bindadres breder wordt dan bedoeld.

Het algemene patroon is:

  • Sta de Ollama TCP-poort alleen toe op de VPN-interface (tailscale0 of wg0).
  • Weiger dezelfde poort overal anders.
  • Kies voor “standaard weigeren binnenkomend” als u dat zo doet voor de host.

Tailscale heeft expliciete richtlijnen voor het gebruik van UFW om niet-Tailscale-verkeer naar een server te beperken, wat in wezen de “alles afsluiten behalve het tailnet”-benadering is.

Een nuance die specifiek voor Tailscale belangrijk is, is dat host-firewall-verwachtingen niet met de realiteit kunnen overeenkomen als u ervan uitgaat dat UFW tailnet-verkeer blokkeert. Het Tailscale-project heeft besproken dat het opzettelijk een regel installeert om verkeer op tailscale0 toe te staan en vertrouwt op een ACL-beheerde filter binnen tailscaled.

Dat is geen argument tegen een host-firewall. Het is wel een argument voor het doordacht zijn over welk controleplan de beleid daadwerkelijk afdwingt. Als u wilt dat “alleen deze apparaten poort 11434 mogen bereiken”, zijn Tailscale ACL’s ontworpen voor dat werk.

Als u toch interface-niveau hostcontroles wilt, zien de voorbeelden er zo uit:

# UFW style logic (illustratief)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Of voor wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Zelfs als u voornamelijk vertrouwt op VPN-beleid, biedt de host-firewall nog steeds een nuttige “veiligheidsgordel” tegen misbinding aan 0.0.0.0 of onverwachte service-wrappers.

Optionele reverse proxy alleen op VPN-ingang

Wanneer is een reverse proxy nuttig voor externe Ollama-toegang? Een proxy is nuttig als u een of meer van deze eigenschappen wilt:

  • Een standaard authenticatiepoort (basic auth, OIDC, clientcertificaten).
  • TLS-terminatie met een certificaat dat clients vertrouwen.
  • Aanvraaglimieten en time-outs.
  • Schoonere URLs voor hulpmiddelen die geen rauwe poorten leuk vinden.

Dit is waar de intentie “niet publiceren aan het internet” nog steeds waar moet blijven: de reverse proxy is alleen toegankelijk via de VPN, niet op de publieke WAN-interface.

Is TLS nodig als verkeer al door een VPN gaat? Niet altijd voor cryptografie, maar vaak voor gebruiksgemak. Tailscale wijst erop dat verbindingen tussen nodes al end-to-end versleuteld zijn, maar browsers weten dat niet omdat ze vertrouwen op TLS-certificaten om HTTPS-vertrouwen te vestigen.

Als u in de Tailscale-wereld bent, kunt u HTTPS-certificaten voor uw tailnet inschakelen, wat MagicDNS vereist en expliciet vermeldt dat machinaam en de tailnet-DNS-naam op een openbaar register (certificate transparency logs) worden gepubliceerd.

Dat detail over het openbare register is geen reden om TLS te vermijden, maar het is wel een reden om machines als een volwassene te noemen (vermijd het inbedden van private projectnamen of klantidentificatoren in hostnames).

Dit artikel bevat opzettelijk geen volledige reverse-proxy-configuratie; voor Caddy of Nginx, streaming en auth aan de rand, zie Ollama behind a reverse proxy with Caddy or Nginx for HTTPS streaming. Het enige idee dat hier van belang is, is de plaatsing:

  • Ollama luistert op localhost of VPN-IP.
  • Reverse proxy luistert alleen op de VPN-interface.
  • Proxy stuurt door naar Ollama.

Veiligheidscontrolelijst voor externe toegang tot de Ollama API

Dit is de controlelijst die ik gebruik om te voorkomen dat “extern” ongemerkt “publiek” wordt.

Binding en bereikbaarheid

  • Bevestig dat de server luistert waar u denkt dat hij luistert. De gedocumenteerde standaard is 127.0.0.1 en poort 11434, en OLLAMA_HOST verandert dat.
  • Behandel 0.0.0.0 als een bewuste keuze, niet als een handig schakelaartje.
  • Geef de voorkeur aan binding aan een VPN-interface-IP als deze stabiel is en past bij de topologie.

Toegangscontrole

  • Als u Tailscale gebruikt, implementeer ACL’s die alleen specifieke gebruikers of gelabelde apparaten toegang geven tot de Ollama-poort. ACL’s bestaan om apparaattoegang te beheren.
  • Als u WireGuard gebruikt, houd AllowedIP’s strak en behandel sleutels als de echte identiteitsgrens. WireGuard verwijdert pakketten die niet overeenkomen met een geldige peer AllowedIPs-mapping.

Firewall

  • Voeg een host-niveau regel toe die de Ollama-poort alleen toestaat op tailscale0 of wg0 en het overal anders blokkeert.
  • Als u verwacht dat UFW tailnet-verkeer blokkeert, verifieer hoe Tailscale interacteert met uw firewall. Tailscale heeft besproken om tailscale0-verkeer toe te staan en te vertrouwen op ACL-filtering binnen tailscaled.

TLS en proxying

  • Gebruik TLS als clients browsers zijn of als hulpmiddelen HTTPS verwachten, zelfs als de VPN het transport al versleutelt. Tailscale documenteert deze kloof tussen VPN-versleuteling en browser-HTTPS-vertrouwen.
  • Als u Tailscale HTTPS-certs inschakelt, onthoud dan de certificaattransparantie-implicatie voor hostnamen.
  • Als u een reverse proxy toevoegt, houd deze VPN-only en gebruik deze voor auth en limieten, niet voor internet-blootstelling.

Vermijd onbedoelde publieke blootstelling

  • Wees voorzichtig met functies die expliciet zijn ontworpen om services aan het internet te publiceren. Tailscale Funnel routet verkeer van het bredere internet naar een tailnet-apparaat, wat niet de standaardveilige weg is voor een Ollama API.
  • Als iets uiteindelijk voor het internet bereikbaar wordt, laat dan geen anonieme /api-oppervlakte achter. Op dat punt stoppen de OWASP API “security misconfiguration” en “resource consumption” risicocategorieën met theoretisch te zijn.

Observabiliteit en schadebestrijding

  • Log aanvragen op de ingangslaag (VPN-beleid logs, proxy logs, of beide).
  • Voeg aanvraag- en concurrentielimieten toe als uw proxy dit ondersteunt, omdat modelinferentie een bronevenement is, geen normale API-aanroep.

Het consistente thema is opzettelijk saai: houd de Ollama API standaard privé, voeg een privé-pad toe voor externe toegang, en dwing dat beleid tweemaal af (VPN-identiteit plus host-firewall) zodat een enkele misstap geen publiek endpoint wordt.