Fjärråtkomst till Ollama via Tailscale eller WireGuard utan publika portar.

Remote Ollama-åtkomst utan publika portar

Sidinnehåll

Ollama är som mest lyckligt när det behandlas som en lokal daemon: CLI:n och dina appar pratar med en loopback HTTP-API, och resten av nätverket får aldrig veta att det finns.

Som standard är det exakt vad som händer: den vanliga lokala basadressen är på localhost port 11434.

ollama remote access

Den här artikeln handlar om ögonblicket när du vill ha fjärråtkomst (laptop, en annan kontorsmaskin, kanske en telefon), men inte vill publicera en oautentiserad modellkörare till hela internet. Den avsikten är viktig, eftersom den enklaste skalningsåtgärden (öppna en port, forwarda den, klart) också är den åtgärden som skapar messet.

En praktisk nordstjärna är enkel: håll Ollama-API:t privat, och gör sedan den privata nätvägen tråkig. Tailscale och WireGuard är två vanliga sätt att göra det på, och resten handlar om att se till att värden lyssnar bara där det ska och att brandväggen håller med.

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)

För hur Ollama passar bredvid vLLM, Docker Model Runner, LocalAI och molnhostningens avvägningar, se LLM-hosting 2026: Lokal, självhostad och molninfrastruktur jämfört.

Relaterade guider:

Hotmodell och vem som ska nå API:t

Hur kan Ollama nås på distans utan att exponeras mot det offentliga internet? Svaret handlar mindre om ett specifikt verktyg och mer om att vara tydlig med “vem får ansluta sig” och “varifrån”.

En användbar mental modell är tre koncentriska ringar:

  • Endast lokalt: bara processer på maskinen kan anropa API:t.
  • Endast LAN: enheter på samma lokala nätverk kan anropa API:t.
  • Endast VPN: valda enheter och användare på ett privat överlappnätverk kan anropa API:t.

Den första ringen är standard. Många guider (och verktyg som Postman) antar att bas-URL:en är localhost 11434, vilket är både praktiskt och en överraskande stark säkerhetsgräns.

Anledningen till att ringarna är viktiga är att Ollama ofta beskrivs som att sakna inbyggd autentisering för sitt lokala HTTP-API, vilket innebär att nätverksexponering och åtkomstkontroll blir ditt ansvar om du går utöver localhost.

Den andra anledningen är kostnad och missbruk: även en “privat” LLM-ändpunkt är fortfarande en API-ändpunkt. OWASP API Security Top 10 pekar ut kategorier som säkerhetsfelkonfiguration och obegränsad resursanvändning; en modellkörare är praktiskt taget en skylt för “resursanvändning” om den exponeras slarvigt.

Så den grundläggande hotmodellen är inte bara “en attackerare läser mina data”. Det är också “någon kan köra min CPU och GPU som en hyrbil” och “oavsiktliga användare upptäcker den och börjar bygga mot den”.

OLLAMA_HOST och bindningssemantik på 90 sekunder

Vad gör OLLAMA_HOST och vad är det säkraste standardvärdet? OLLAMA_HOST är växeln som kontrollerar var Ollama-servern lyssnar. I ollama serve beskrivs miljövariabeln som IP-adress och port för servern, med ett standardvärde på 127.0.0.1 och port 11434.

I enkla termer bestämmer bindningsadressen vilka nätverk som ens kan försöka en TCP-anslutning:

  • 127.0.0.1 betyder endast localhost.
  • En LAN-IP (som 192.168.x.y) betyder att LAN kan nå det.
  • 0.0.0.0 betyder alla gränssnitt (LAN, VPN, allt) kan nå det om inte en brandvägg blockerar dem.

Det är därför de flesta “göra det tillgängligt”-guiderna föreslår att byta från 127.0.0.1 till 0.0.0.0, men den rådet är ofullständigt utan en gränssnittsmedveten brandvägg.

Här är min snabbkurs som jag håller i huvudet:

# Endast lokalt (baslinje)
export OLLAMA_HOST=127.0.0.1:11434

# Alla gränssnitt (kraftfullt, lätt att ångra sig på)
export OLLAMA_HOST=0.0.0.0:11434

# Endast VPN-gränssnitt (föredraget när VPN har en stabil IP på värden)
export OLLAMA_HOST=100.64.0.10:11434   # exempel tailscale IP
export OLLAMA_HOST=10.10.10.1:11434    # exempel wireguard IP

# Annet portnummer (nyttigt när 11434 redan är upptaget)
export OLLAMA_HOST=127.0.0.1:11435

Fallet med “annet portnummer” diskuteras uttryckligen i Ollama-frågespåret som ett exempel på att använda OLLAMA_HOST för att ändra lyssningsport.

En operationell fotnot som bitar folk: om Ollama körs som en hanterad tjänst, att sätta miljövariabler i ett interaktivt skal inte nödvändigtvis ändra tjänstkonfigurationen. Det är därför många “det fungerade i min terminal men inte efter omstart”-berättelser slutar med systemd-enhetsoverskrifter eller konfiguration av tjänsthanteraren.

Mönster A VPN först med Tailscale

Kan Tailscale begränsa åtkomst till endast en tjänstport på en maskin? Ja, och det är en stor del av varför Tailscale passar bra för “fjärråtkomst utan publicering”.

Tailscale ger dig ett privat nätverk (en tailnet) med centralt hanterade åtkomstkontroller (ACL). ACL finns specifikt för att hantera enhetsrättigheter och säkra nätverket.

Ingen offentlig port betyder ingen routerdans

Det renaste mönstret är att undvika att öppna någon internetvänd port för Ollama alls och behandla VPN som den enda ingången. Med Tailscale försöker enheter att ansluta direkt peer-to-peer när det är möjligt, och kan falla tillbaka till relämekanismer när direktkoppling inte är möjlig.

Detta är inte magisk säkerhet i sig, men det minskar explosionsradien radikalt jämfört med “jag forwardade 11434 på min router”.

Split-horisont och namn med MagicDNS

En andra fråga som dyker upp i verkligheten är “kopplar jag via LAN-IP när jag är hemma och via VPN-IP när jag är borta”. Det är i grunden ett split-horisontproblem.

Tailscale MagicDNS hjälper till genom att ge varje enhet ett stabilt tailnet-värdnamn. Under huven genererar MagicDNS ett FQDN för varje enhet som kombinerar maskinens namn och ditt tailnet-DNS-namn, och moderna tailnet-namn slutar med .ts.net.

Den åsiktsfulla tolkningen är att använda ett namn oftast är bättre än att hardkoda en IP, eftersom namnet följer enheten även om ditt tailnet-IP ändras. Men det är också helt okej att vara medvetet tråkig och behålla en liten värdfil eller en enda intern DNS-post om du föredrar det. MagicDNS finns så du inte behöver göra det.

Direkt port kontra tailnet-endast proxying

Det finns två vanliga Tailscale-sätt att nå en tjänst:

  • Direkt portåtkomst, där tjänsten lyssnar på tailnet-gränssnittet och klienter ansluter till den IP:n och porten.
  • Tailscale Serve, där Tailscale dirigerar trafik från andra tailnet-enheter till en lokal tjänst på värden.

Serve beskrivs uttryckligen som att dirigera trafik från andra tailnet-enheter till en lokal tjänst som körs på din enhet.

För Ollama kan Serve vara lockande eftersom det låter dig behålla Ollama på localhost och exponera endast en kontrollerad ingångsväg genom Tailscale. Det passar också naturligt med HTTPS inuti tailnet om du vill ha webbläsarvänliga ändpunkter.

En relaterad funktion värd att nämna och sedan mentalt parkera är Funnel. Funnel är utformat för att dirigera trafik från det bredare internet till en tjänst på en tailnet-enhet och är uttryckligen för “alla ska kunna komma åt även om de inte använder Tailscale”. Det är motsatsen till den här artikeln.

Mönster B WireGuard för de som vill ha de råa primitiven

WireGuard är underliggande primitiv som driver många VPN-produkter, och det är medvetet minimalt: du konfigurerar ett gränssnitt, definierar peers och bestämmer vilken trafik som tillåts att flöda.

WireGuard-snabbstarten visar den grundläggande formen: skapa ett gränssnitt som wg0, tilldela IP:er och konfigurera peers med wg.

Nyckelkonceptet för att omfatta åtkomst är AllowedIPs. I Red Hat-dokumentationen läser WireGuard destinationens IP från en packet och jämför den med listan över tillåtna IP-adresser; om peer inte hittas, kasserar WireGuard paketet.

För en Ollama-värd är den praktiska översättningen:

  • Placera värden på ett privat WireGuard-undernätverk.
  • Bind Ollama antingen till localhost och forwarda till den, eller bind direkt till WireGuard-IP:n.
  • Endast peers som har rätt nycklar och AllowedIPs kan dirigera trafik till det privata IP:t.

Detta är färre rörliga delar än en kommersiell overlay, men det innebär också att du är ansvarig för nyckeldistribution, peer-livscykel och hur fjärrpeers når ditt nätverk.

Brandvägg tillåter endast VPN-gränssnitt eller tailnet

Hur kan en brandvägg begränsa Ollama till endast VPN-gränssnittstrafik? Målet är att förhindra oavsiktlig exponering även om bindningsadressen blir bredare än avsett.

Det allmänna mönstret är:

  • Tillåt Ollama TCP-porten endast på VPN-gränssnittet (tailscale0 eller wg0).
  • Förbjud samma port på allt annat.
  • Föredra “förbjud inkommande som standard” om du opererar så för värden.

Tailscale har uttryckliga riktlinjer för att använda UFW för att begränsa icke-Tailscale-trafik till en server, vilket i princip är “lås ner allt utom tailnet”-tillvägagångssättet.

En nyans som är viktig för Tailscale specifikt är att värdbrandväggsexpektationer kanske inte matchar verkligheten om du antar att UFW kommer att blockera tailnet-trafik. Tailscale-projektet har diskuterat att det medvetet installerar en regel för att tillåta trafik på tailscale0 och förlitar sig på en ACL-kontrollerad filtrering inuti tailscaled.

Det är inte ett argument mot en värdbrandvägg. Det är ett argument för att vara medveten om vilken kontrollplan som faktiskt tillämpar policyn. Om du vill att “endast dessa enheter ska nå port 11434”, är Tailscale ACL:er utformade för det jobbet.

Om du ändå vill ha gränssnittsnivåkontroller på värden, ser exemplen ut så här:

# UFW-liknande logik (illustrativt)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Eller för wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Även om du primärt förlitar dig på VPN-policy, ger värdbrandväggen fortfarande en användbar “säkerhetsbälte” mot felaktig bindning till 0.0.0.0 eller oväntade tjänstsvrappar.

Valbar omvänd proxy endast på VPN-ingång

När är en omvänd proxy användbar för fjärråtkomst till Ollama? En proxy är användbar när du vill ha en eller flera av dessa egenskaper:

  • En standardautentiseringsport (basic auth, OIDC, klientcertifikat).
  • TLS-avslutning med ett certifikat som klienter litar på.
  • Begränsningar för förfrågningar och tidsgränser.
  • Renare URL:er för verktyg som inte gillar råa portar.

Det är här avsikten “publicera inte till internet” fortfarande ska vara sann: den omvända proxyn är tillgänglig endast via VPN, inte på det offentliga WAN-gränssnittet.

Är TLS nödvändigt när trafiken redan går genom en VPN? Inte alltid för kryptering, men ofta för ergonomi. Tailscale påpekar att anslutningar mellan noder redan är änd-till-änd-krypterade, men webbläsare vet inte om det eftersom de förlitar sig på TLS-certifikat för att etablera HTTPS-tillit.

Om du är i Tailscale-världen kan du aktivera HTTPS-certifikat för ditt tailnet, vilket kräver MagicDNS och noterar uttryckligen att maskinnamn och tailnet-DNS-namn kommer att publiceras i en offentlig register (certifikattransparensloggar).

Detta detalj om offentliga register är inte en anledning att undvika TLS, men det är en anledning att namnge maskiner som en vuxen (undvik att inbädda privata projektnamn eller kundidentifierare i värdnamn).

Den här artikeln inkluderar medvetet ingen fullständig konfiguration av omvänd proxy; för Caddy eller Nginx, strömning och autentisering vid kanterna, se Ollama bakom en omvänd proxy med Caddy eller Nginx för HTTPS-strömning. Den enda idén som är viktig här är placering:

  • Ollama lyssnar på localhost eller VPN-IP.
  • Omvänd proxy lyssnar endast på VPN-gränssnittet.
  • Proxy dirigerar vidare till Ollama.

Säkerhetskontrolllista för fjärråtkomst till Ollama-API:t

Detta är kontrollistan jag använder för att hålla “fjärr” från att tyst bli “offentlig”.

Bindning och nåbarhet

  • Bekräfta att servern lyssnar där du tror att den lyssnar. Dokumenterad standard är 127.0.0.1 och port 11434, och OLLAMA_HOST ändrar det.
  • Behandla 0.0.0.0 som ett medvetet val, inte en bekvämlighetsväxel.
  • Föredra bindning till ett VPN-gränssnitts-IP när det är stabilt och passar topologin.

Åtkomstkontroll

  • Om du använder Tailscale, implementera ACL:er som endast tillåter specifika användare eller taggade enheter till Ollama-porten. ACL:er finns för att hantera enhetsrättigheter.
  • Om du använder WireGuard, håll AllowedIPs stramt och behandla nycklar som den verkliga identitetsgränsen. WireGuard kasserar paket som inte matchar en giltig peer AllowedIPs-mappning.

Brandvägg

  • Lägg till en regel på värdnivå som tillåter Ollama-porten endast på tailscale0 eller wg0 och blockerar den överallt annat.
  • Om du förväntar dig att UFW ska blockera tailnet-trafik, verifiera hur Tailscale interagerar med din brandvägg. Tailscale har diskuterat att tillåta tailscale0-trafik och förlita sig på ACL-filtrering inuti tailscaled.

TLS och proxying

  • Använd TLS när klienter är webbläsare eller när verktyg förväntar sig HTTPS, även om VPN redan krypterar transport. Tailscale dokumenterar detta gap mellan VPN-kryptering och webbläsarens HTTPS-tillit.
  • Om du aktiverar Tailscale HTTPS-certifikat, kom ihåg certifikattransparensimplikationen för värdnamn.
  • Om du lägger till en omvänd proxy, håll den VPN-endast och använd den för autentisering och begränsningar, inte för internetexponering.

Undvik oavsiktlig offentlig exponering

  • Var försiktig med funktioner som uttryckligen är utformade för att publicera tjänster till internet. Tailscale Funnel dirigerar trafik från det bredare internet till en tailnet-enhet, vilket inte är den standard-säkra vägen för ett Ollama-API.
  • Om något slutar upp som internet-nåbart, lämna inte en anonym /api-yta. Vid det tillfället slutar OWASP API:s kategorier för “säkerhetsfelkonfiguration” och “resursanvändning” att vara teoretiska.

Observabilitet och skadekontroll

  • Logga förfrågningar vid ingångs-lagret (VPN-policyloggar, proxyloggar eller båda).
  • Lägg till förfrågnings- och konkurrensbegränsningar om din proxy stöder dem, eftersom modellinferens är en resurshändelse, inte ett normalt API-anrop.

Den konsistenta teman är medvetet tråkigt: håll Ollama-API:t privat som standard, lägg till en privat väg för fjärråtkomst, och tillämpa sedan den policyn två gånger (VPN-identitet plus värdbrandvägg) så att ett enda misstag inte blir en offentlig ändpunkt.

Prenumerera

Få nya inlägg om system, infrastruktur och AI-ingenjörskonst.