Accesso remoto a Ollama tramite Tailscale o WireGuard, senza porte pubbliche.

Ollama è al suo meglio quando viene trattato come un demone locale: la CLI e le tue applicazioni comunicano con un’API HTTP su loopback, e il resto della rete non viene a sapere della sua esistenza.

Di default, è esattamente quello che succede: l’indirizzo di base locale comune è sulla porta 11434 di localhost.

Questo articolo riguarda il momento in cui desideri un accesso remoto (laptop, un’altra macchina d’ufficio, forse un telefono), ma non vuoi pubblicare un runner di modelli non autenticato su tutto Internet. Questa intenzione è importante, perché la mossa di scaling più semplice (aprire una porta, inoltrarla, finita) è anche quella che crea il disastro.

Una stella polare pratica è semplice: mantieni l’API Ollama privata, poi rendi il percorso di rete privato noioso. Tailscale e WireGuard sono due modi comuni per fare ciò, e il resto è assicurarsi che l’host ascolti solo dove dovrebbe e che il firewall sia d’accordo.

Dispositivo remoto
  |
  | (percorso VPN privato: tailscale o wireguard)
  v
Interfaccia VPN sull'host (tailscale0 o wg0)
  |
  | (hop locale)
  v
Server Ollama (API HTTP su localhost o IP VPN)

Per capire come Ollama si integra con vLLM, Docker Model Runner, LocalAI e i compromessi dell’hosting cloud, vedi LLM Hosting in 2026: Local, Self-Hosted & Cloud Infrastructure Compared.

Guide correlate:

• Ollama commands cheatsheet
• Ollama behind a reverse proxy with Caddy or Nginx for HTTPS streaming
• Ollama in Docker Compose with GPU and Persistent Model Storage

Modello di minaccia e chi dovrebbe raggiungere l’API

Come può Ollama essere acceso remotamente senza esporlo al pubblico Internet? La risposta riguarda meno uno strumento specifico e più l’essere espliciti su “chi è autorizzato a connettersi” e “da dove”.

Un modello mentale utile è composto da tre anelli concentrici:

• Solo locale: solo i processi sulla macchina possono chiamare l’API.
• Solo LAN: i dispositivi sulla stessa rete locale possono chiamare l’API.
• Solo VPN: dispositivi e utenti selezionati su una rete di overlay privata possono chiamare l’API.

Il primo anello è quello di default. Molte guide (e strumenti come Postman) presuppongono che l’URL di base sia localhost 11434, il che è sia conveniente che una sorprendentemente forte barriera di sicurezza.

Il motivo per cui gli anelli contano è che Ollama è comunemente descritto come privo di autenticazione integrata per la sua API HTTP locale, il che significa che l’esposizione di rete e il controllo degli accessi diventano il tuo compito se ti allontani da localhost.

L’altro motivo è il costo e l’abuso: anche un endpoint LLM “privato” è comunque un endpoint API. Le OWASP API Security Top 10 evidenziano categorie come configurazione insicura e consumo di risorse illimitato; un runner di modelli è praticamente l’emblema del “consumo di risorse” se esposto casualmente.

Quindi il modello di minaccia di base non è solo “un attaccante legge i miei dati”. È anche “qualcuno può guidare la mia CPU e GPU come se fossero un’auto a noleggio” e “utenti non previsti lo scoprono e iniziano a costruirvi sopra”.

OLLAMA_HOST e semantica del binding in 90 secondi

Cosa fa OLLAMA_HOST e qual è il valore di default più sicuro? OLLAMA_HOST è l’interruttore che controlla dove il server Ollama ascolta. In ollama serve, la variabile d’ambiente è descritta come l’indirizzo IP e la porta del server, con un default di 127.0.0.1 e porta 11434.

In parole povere, l’indirizzo di binding decide quali reti possono anche tentare una connessione TCP:

• 127.0.0.1 significa solo localhost.
• Un IP LAN (come 192.168.x.y) significa che la LAN può raggiungerlo.
• 0.0.0.0 significa tutte le interfacce (LAN, VPN, tutto) possono raggiungerlo a meno che un firewall non lo blocchi.

È per questo che la maggior parte dei tutorial “rendilo accessibile” suggerisce di passare da 127.0.0.1 a 0.0.0.0, ma quel consiglio è incompleto senza un firewall consapevole delle interfacce.

Ecco il cheat sheet che tengo a mente:

# Solo locale (baseline)
export OLLAMA_HOST=127.0.0.1:11434

# Tutte le interfacce (potente, facile da rimpiangere)
export OLLAMA_HOST=0.0.0.0:11434

# Solo interfaccia VPN (preferibile quando la VPN ha un IP stabile sull'host)
export OLLAMA_HOST=100.64.0.10:11434   # esempio IP tailscale
export OLLAMA_HOST=10.10.10.1:11434    # esempio IP wireguard

# Porta diversa (utile quando 11434 è già occupata)
export OLLAMA_HOST=127.0.0.1:11435

Il caso “porta diversa” è esplicitamente discusso nel tracker di problemi di Ollama come esempio di utilizzo di OLLAMA_HOST per alterare la porta di ascolto.

Una nota operativa che fa male alle persone: se Ollama viene eseguito come servizio gestito, impostare le variabili d’ambiente in un shell interattivo non cambia necessariamente la configurazione del servizio. È per questo che molte storie “funzionava nel mio terminale ma non dopo il riavvio” finiscono in override delle unità systemd o nella configurazione del gestore dei servizi.

Pattern A: Prima la VPN con Tailscale

Tailscale può limitare l’accesso a una sola porta di servizio su una macchina? Sì, ed è una grande parte del motivo per cui Tailscale è un’ottima soluzione per “accesso remoto senza pubblicazione”.

Tailscale ti offre una rete privata (un tailnet) con controlli di accesso gestiti centralmente (ACL). Le ACL esistono specificamente per gestire le autorizzazioni dei dispositivi e proteggere la rete.

Nessuna porta pubblica significa nessuna coreografia del router

Il pattern più pulito è evitare di aprire qualsiasi porta esposta a Internet per Ollama e trattare la VPN come l’unico ingresso. Con Tailscale, i dispositivi tentano di connettersi direttamente peer-to-peer quando possibile, e possono ricorrere a meccanismi di relay quando la connettività diretta non è possibile.

Non è sicurezza magica di per sé, ma riduce radicalmente il raggio d’azione rispetto a “ho inoltrato la 11434 sul mio router”.

Orizzonte diviso e naming con MagicDNS

Una seconda domanda che sorge nella vita reale è “mi connetto via IP LAN quando sono a casa e via IP VPN quando sono fuori”. Questo è fondamentalmente un problema di orizzonte diviso.

MagicDNS di Tailscale aiuta fornendo a ogni dispositivo un hostname tailnet stabile. Sotto il cofano, MagicDNS genera un FQDN per ogni dispositivo che combina il nome della macchina e il nome DNS del tuo tailnet, e i nomi tailnet moderni terminano con .ts.net.

La presa d’opinione è che usare un nome è solitamente meglio che codificare un IP in modo rigido, perché il nome segue il dispositivo anche se il tuo IP tailnet cambia. Ma è anche corretto essere intenzionalmente noiosi e mantenere un piccolo file hosts o un singolo record DNS interno se preferisci. MagicDNS esiste proprio per non doverlo fare.

Porta diretta contro proxying solo tailnet

Ci sono due modi comuni di Tailscale per raggiungere un servizio:

• Accesso diretto alla porta, dove il servizio ascolta sull’interfaccia tailnet e i clienti si connettono a quell’IP e porta.
• Tailscale Serve, dove Tailscale instrada il traffico da altri dispositivi tailnet a un servizio locale sull’host.

Serve è esplicitamente descritto come instradamento del traffico da altri dispositivi tailnet a un servizio locale in esecuzione sul tuo dispositivo.

Per Ollama, Serve può essere attraente perché ti permette di mantenere Ollama su localhost ed esporre solo un percorso di ingresso controllato attraverso Tailscale. Si abbina anche naturalmente con HTTPS all’interno del tailnet se vuoi endpoint amichevoli per il browser.

Una caratteristica correlata da nominare e poi parcheggiare mentalmente è Funnel. Funnel è progettato per instradare il traffico dall’Internet più ampio a un servizio su un dispositivo tailnet ed è esplicitamente per “chiunque acceda anche se non usa Tailscale”. Questo è l’opposto di questo articolo.

Pattern B: WireGuard per chi vuole i primitivi grezzi

WireGuard è il primitivo sottostante che alimenta molti prodotti VPN ed è deliberatamente minimale: configuri un’interfaccia, definisci i peer e decidi quale traffico è autorizzato a fluire.

Il rapido avvio di WireGuard mostra la forma di base: crea un’interfaccia come wg0, assegna gli IP e configura i peer con wg.

Il concetto chiave per limitare l’accesso è AllowedIPs. Nella documentazione Red Hat, WireGuard legge l’IP di destinazione da un pacchetto e lo confronta con l’elenco degli indirizzi IP consentiti; se il peer non viene trovato, WireGuard scarta il pacchetto.

Per un host Ollama, la traduzione pratica è:

• Metti l’host su una sottorete WireGuard privata.
• Collega Ollama sia a localhost e inoltra ad esso, oppure lega direttamente all’IP WireGuard.
• Solo i peer che hanno le chiavi corrette e AllowedIPs possono instradare il traffico a quell’IP privato.

Ci sono meno parti in movimento rispetto a un overlay commerciale, ma significa anche che sei responsabile della distribuzione delle chiavi, del ciclo di vita dei peer e di come i peer remoti raggiungono la tua rete.

Firewall: consenti solo traffico interfaccia VPN o tailnet

Come può un firewall limitare Ollama solo al traffico dell’interfaccia VPN? L’obiettivo è prevenire l’esposizione accidentale anche se l’indirizzo di binding diventa più ampio del previsto.

Il pattern generale è:

• Consenti la porta TCP di Ollama solo sull’interfaccia VPN (tailscale0 o wg0).
• Negare la stessa porta su tutto il resto.
• Preferisci “negazione predefinita in ingresso” se operi in quel modo per l’host.

Tailscale ha linee guida esplicite sull’uso di UFW per limitare il traffico non-Tailscale a un server, che è essenzialmente l’approccio “blocca tutto tranne il tailnet”.

Una sfumatura che conta specificamente per Tailscale è che le aspettative del firewall dell’host potrebbero non corrispondere alla realtà se si assume che UFW bloccherà il traffico tailnet. Il progetto Tailscale ha discusso come installa intenzionalmente una regola per consentire il traffico su tailscale0 e si affida a un filtro controllato da ACL all’interno di tailscaled.

Questo non è un argomento contro un firewall dell’host. È un argomento per essere deliberati su quale piano di controllo sta effettivamente applicando la politica. Se vuoi “solo questi dispositivi possono raggiungere la porta 11434”, le ACL di Tailscale sono progettate per quel compito.

Se vuoi comunque controlli a livello di interfaccia dell’host, gli esempi tendono a sembrare così:

# Logica stile UFW (illustrativa)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Oppure per wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Anche se ti affidi principalmente alla politica VPN, il firewall dell’host fornisce ancora una utile “cintura di sicurezza” contro il binding errato a 0.0.0.0 o involucri di servizi inaspettati.

Reverse proxy opzionale solo sull’ingresso VPN

Quando è utile un reverse proxy per l’accesso remoto a Ollama? Un proxy è utile quando desideri una o più di queste proprietà:

• Un gate di autenticazione standard (basic auth, OIDC, certificati client).
• Terminazione TLS con un certificato che i client fidano.
• Limiti e timeout delle richieste.
• URL più puliti per strumenti che non amano le porte grezze.

È qui che l’intento di “non pubblicare su Internet” dovrebbe rimanere vero: il reverse proxy è raggiungibile solo tramite la VPN, non sull’interfaccia WAN pubblica.

TLS è necessario quando il traffico passa già attraverso una VPN? Non sempre per la crittografia, ma spesso per l’ergonomia. Tailscale evidenzia che le connessioni tra nodi sono già crittografate end-to-end, ma i browser non ne sono a conoscenza perché si affidano ai certificati TLS per stabilire la fiducia HTTPS.

Se sei nel mondo Tailscale, puoi abilitare certificati HTTPS per il tuo tailnet, il che richiede MagicDNS e nota esplicitamente che i nomi delle macchine e il nome DNS del tailnet saranno pubblicati su un registro pubblico (log di trasparenza dei certificati).

Questo dettaglio del registro pubblico non è un motivo per evitare TLS, ma è un motivo per nominare le macchine come un adulto (evita di incorporare nomi di progetti privati o identificatori di clienti negli hostnames).

Questo articolo non include intenzionalmente una configurazione completa del reverse-proxy; per Caddy o Nginx, streaming e auth al bordo, vedi Ollama behind a reverse proxy with Caddy or Nginx for HTTPS streaming. L’unica idea che conta qui è il posizionamento:

• Ollama ascolta su localhost o IP VPN.
• Reverse proxy ascolta solo sull’interfaccia VPN.
• Proxy inoltra a Ollama.

Checklist di sicurezza per l’accesso remoto all’API di Ollama

Questa è la checklist che uso per impedire che “remoto” diventi silenziosamente “pubblico”.

Binding e raggiungibilità

• Conferma che il server ascolti dove pensi che ascolti. Il default documentato è 127.0.0.1 e porta 11434, e OLLAMA_HOST cambia quello.
• Tratta 0.0.0.0 come una scelta deliberata, non come un interruttore di comodità.
• Preferisci il binding a un IP di interfaccia VPN quando è stabile e si adatta alla topologia.

Controllo degli accessi

• Se usi Tailscale, implementa ACL che consentano solo agli utenti specifici o ai dispositivi taggati di accedere alla porta Ollama. Le ACL esistono per gestire le autorizzazioni dei dispositivi.
• Se usi WireGuard, mantieni AllowedIPs stretti e tratta le chiavi come il vero confine dell’identità. WireGuard scarta i pacchetti che non corrispondono a un mapping AllowedIPs di un peer valido.

Firewall

• Aggiungi una regola a livello di host che consenta la porta Ollama solo su tailscale0 o wg0 e la blocchi ovunque else.
• Se ti aspetti che UFW blocchi il traffico tailnet, verifica come Tailscale interagisce con il tuo firewall. Tailscale ha discusso la possibilità di permettere il traffico tailscale0 e affidarsi al filtraggio ACL all’interno di tailscaled.

TLS e proxying

• Usa TLS quando i client sono browser o quando gli strumenti si aspettano HTTPS, anche se la VPN critta già il trasporto. Tailscale documenta questo divario tra la crittografia VPN e la fiducia HTTPS del browser.
• Se abiliti i certificati HTTPS di Tailscale, ricorda le implicazioni di trasparenza dei certificati per gli hostnames.
• Se aggiungi un reverse proxy, mantienilo solo VPN e usalo per aut e limiti, non per l’esposizione a Internet.

Evita l’esposizione pubblica accidentale

• Attento alle funzionalità progettate esplicitamente per pubblicare servizi su Internet. Tailscale Funnel instrada il traffico dall’Internet più ampio a un dispositivo tailnet, che non è il percorso predefinito sicuro per un’API Ollama.
• Se qualcosa finisce per essere raggiungibile su Internet, non lasciare una superficie /api anonima. A quel punto, le categorie di rischio OWASP API “configurazione insicura” e “consumo di risorse” smettono di essere teoriche.

Osservabilità e controllo dei danni

• Registra le richieste al livello di ingresso (log di politica VPN, log del proxy, o entrambi).
• Aggiungi limiti di richiesta e concorrenza se il tuo proxy li supporta, perché l’inferenza del modello è un evento di risorse, non una chiamata API normale.

Il tema coerente è noioso di proposito: mantieni l’API Ollama privata di default, aggiungi un percorso privato per l’accesso remoto, poi applica quella politica due volte (identità VPN più firewall dell’host) in modo che un singolo errore non si trasformi in un endpoint pubblico.