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

Ollama är som mest nöjd när den 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 den existerar.

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

Den här artikeln handlar om den stund då du vill ha fjärråtkomst (laptop, en annan kontorsmaskin, kanske en telefon), men du inte vill publicera en oautentiserad modellkörare för hela internet. Den intentionen är viktig, eftersom det enklaste skalningssteget (öppna en port, vidarebefordra den, klart) också är det steg som skapar kaoset.

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ärdlyssnar endast där den bör 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)

Hotmodell och vem som ska nå API:t

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

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

• Endast lokalt: Endast processer på maskinen kan kalla API:t.
• Endast LAN: Enheter på samma lokala nätverk kan kalla API:t.
• Endast VPN: Utvalda enheter och användare på ett privat overlay-nätverk kan kalla API:t.

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

Anledningen till att ringarna är viktiga är att Ollama vanligtvis beskrivs som att ha ingen 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-slutpunkt är fortfarande en API-slutpunkt. OWASP API Security Top 10 pekar ut kategorier som säkerhetsmisskonfiguration och obegränsad resursförbrukning; en modellkörare är praktiskt taget en modell för “resursförbrukning” 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 “oönskade användare upptäcker den och börjar bygga mot den”.

OLLAMA_HOST och bind-semantik på 90 sekunder

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

Med enkla ord bestämmer bind-adressen 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 LANet kan nå den.
• 0.0.0.0 betyder alla gränssnitt (LAN, VPN, allt) kan nå den om inte en brandvägg blockerar dem.

Det är varför de flesta “gör det tillgängligt”-guiderna föreslår att byta från 127.0.0.1 till 0.0.0.0, men det rådet är ofullständigt utan en brandvägg som är medveten om gränssnitt.

Här är fuskbladet jag håller i huvudet:

# Local only (baseline)
export OLLAMA_HOST=127.0.0.1:11434

# All interfaces (powerful, easy to regret)
export OLLAMA_HOST=0.0.0.0:11434

# VPN interface only (preferred when the VPN has a stable IP on the host)
export OLLAMA_HOST=100.64.0.10:11434   # example tailscale IP
export OLLAMA_HOST=10.10.10.1:11434    # example wireguard IP

# Different port (useful when 11434 is already taken)
export OLLAMA_HOST=127.0.0.1:11435

Fallet “annan port” diskuteras uttryckligen i Ollama-problemlisthantering som ett exempel på att använda OLLAMA_HOST för att ändra lyssnande port.

En operativ fotnot som biter folk: om Ollama kör som en hanterad tjänst, att sätta miljövariabler i ett interaktivt skal innebär inte nödvändigtvis att tjänstens konfiguration ändras. Det är varför många “det fungerade i min terminal men inte efter omstart”-berättelser slutar med systemd-enhetsoverskrifter eller konfiguration i tjänstehanteraren.

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 är ett bra pass 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 enhetsbehörigheter och säkra nätverket.

Ingen offentlig port betyder ingen router-koreografi

Det renaste mönstret är att undvika att öppna någon internetvänd port för Ollama överhuvudtaget 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 direkt anslutning inte är möjligt.

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

Split-horisont och namngivning med MagicDNS

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

Tailscale MagicDNS hjälper till genom att ge varje enhet en stabil 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.

Det åsiktsmässiga ståndpunkten är att använda ett namn oftast är bättre än att hårdkoda 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 hosts-fil eller en enda intern DNS-post om du hellre vill det. MagicDNS finns så att du inte behöver göra det.

Direkt port kontra tailnet-ende 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 och porten.
• Tailscale Serve, där Tailscale ruttar trafik från andra tailnet-enheter till en lokal tjänst på värd.

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

För Ollama kan Serve vara attraktivt eftersom det låter dig hålla Ollama på localhost och bara exponera en kontrollerad ingångsväg genom Tailscale. Det parar sig också naturligt med HTTPS inuti tailnetet om du vill ha webbläsarvänliga slutpunkter.

En relaterad funktion värd att namnge och sedan mentalt parkera är Funnel. Funnel är utformat för att ruttar trafik från det bredare internetet till en tjänst på en tailnet-enhet och är uttryckligen för “alla ska kunna nå till och med 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 den underliggande primitiven som driver många VPN-produkter, och den är medvetet minimal: du konfigurerar ett gränssnitt, definierar peers och bestämmer vilken trafik som får flöda.

WireGuard-snabbstarten visar grundformen: skapa ett gränssnitt som wg0, tilldela IPs och konfigurera peers med wg.

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

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

• Sätt värdet på ett privat WireGuard-subnät.
• Bind Ollama antingen till localhost och vidarebefordra till den, eller bind direkt till WireGuard-IP.
• Endast peers som har rätt nycklar och AllowedIPs kan ruttar trafik till det privata IP:et.

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ärr-peers når ditt nätverk.

Brandvägg tillåt 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 bind-adressen 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 “standard förbud inkommande” om du opererar så för värdet.

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åsa ner allt utom tailnet”-metoden.

En nyans som är viktig för Tailscale specifikt är att värd-brandväggsförväntningar 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 litar på en ACL-kontrollerad filter inuti tailscaled.

Det är inte ett argument mot en värd-brandvägg. Det är ett argument för att vara medveten om vilken styrplans som faktiskt genomför policy. Om du vill att “endast dessa enheter kan nå port 11434”, är Tailscale ACL designade för det jobbet.

Om du ändå vill ha värd-nivå kontroller, ser exemplen oftast ut så här:

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

# Or for wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Även om du främst litar på VPN-policy, ger värd-brandväggen fortfarande en användbar “säkerhetsbälte” mot missbindning till 0.0.0.0 eller oväntade tjänstsvärp.

Valfri omvänt proxy endast på VPN-ingång

När är en omvänt 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 timeouts.
• Renare URL:er för verktyg som inte gillar råa portar.

Detta är där intentionen “publicera inte till internet” fortfarande bör hålla sann: den omvända proxy är nåbar endast via VPN, inte på det offentliga WAN-gränssnittet.

Är TLS nödvändigt när trafik redan går genom en VPN? Inte alltid för kryptografi, men ofta för ergonomi. Tailscale påpekar att anslutningar mellan noder redan är krypterade från änd till änd, men webbläsare är inte medvetna om det eftersom de litar 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 publiceras på en offentlig ledare (certifikatgenomskinlighetsloggar).

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

Den här artikeln inkluderar medvetet inte fullständig omvänd proxy-konfiguration (se din A1-artikel för det). Den enda idé som betyder något här är placering:

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

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

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. Den dokumenterade standarden ä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ämlighetsbrytare.
• 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 som tillåter endast specifika användare eller taggade enheter till Ollama-porten. ACL finns för att hantera enhetsbehörigheter.
• Om du använder WireGuard, håll AllowedIPs tajt och behandla nycklar som den verkliga identitetsgränsen. WireGuard slår paket som inte matchar en giltig peer AllowedIPs-mappning.

Brandvägg

• Lägg till en regel på värd-nivå 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 lita 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äsars HTTPS-tillit.
• Om du aktiverar Tailscale HTTPS-certifikat, kom ihåg certifikatgenomskinlighetsimplikationen 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 internet-exponering.

Undvik oavsiktlig offentlig exponering

• Var varsam med funktioner som uttryckligen är designade för att publicera tjänster till internet. Tailscale Funnel ruttar trafik från det bredare internetet till en tailnet-enhet, vilket inte är den standardsäkra vägen för ett Ollama-API.
• Om något slutar upp internet-nåbart, lämna inte en anonym /api-yta. Vid det tillfället slutar OWASP API:s riskkategorier för “säkerhetsmisskonfiguration” och “resursförbrukning” att vara teoretiska.

Observabilitet och skadekontroll

• Logga förfrågningar på ingress-lagret (VPN-policyloggar, proxyloggar eller båda).
• Lägg till förfrågnings- och konkurrensgränser om din proxy stöder dem, eftersom modellinferens är en resurshändelse, inte ett vanligt API-anrop.

Det konsekventa temat är tråkigt medvetet: håll Ollama-API:t privat som standard, lägg till en privat väg för fjärråtkomst, och genomför sedan den policyn två gånger (VPN-identitet plus värd-brandvägg) så att ett enda misstag inte blir en offentlig slutpunkt.