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

Ollama è più felice quando viene trattato come un demone locale: la CLI e le tue applicazioni si connettono a un’API HTTP su loopback, e il resto della rete non sa nemmeno che esiste.

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

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

Una stella polare pratica è semplice: mantieni l’API di Ollama privata, poi rendi il percorso di rete privato noioso. Tailscale e WireGuard sono due modi comuni per farlo, e il resto consiste nell’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)
  |
  | (salto locale)
  v
Server Ollama (API HTTP su localhost o IP VPN)

Modello di minaccia e chi dovrebbe raggiungere l’API

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

Un modello mentale utile è quello di tre cerchi 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 overlay privata possono chiamare l’API.

Il primo cerchio è il valore predefinito. Molti guide (e strumenti come Postman) presuppongono che l’URL di base sia localhost 11434, il che è sia conveniente che una sorprendentemente solida barriera di sicurezza.

Il motivo per cui i cerchi 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 la tua responsabilità se ti allontani dal localhost.

L’altro motivo riguarda costi e abusi: anche un endpoint LLM “privato” è comunque un endpoint API. Le Top 10 di OWASP API Security citano categorie come “errata configurazione di sicurezza” e “consumo risorse illimitato”; un runner di modelli è praticamente un esempio perfetto di “consumo risorse” se esposto con leggerezza.

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 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 predefinito 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 per il server, con un default di 127.0.0.1 e porta 11434.

In termini semplici, 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 la cheat sheet che tengo a mente:

# Solo locale (linea di base)
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 morde la gente: se Ollama viene eseguito come servizio gestito, impostare variabili d’ambiente in un shell interattivo non necessariamente cambia la configurazione del servizio. Ecco perché molte storie “funzionava nel mio terminale ma non dopo il riavvio” finiscono in sovrascritture di unità systemd o nella configurazione del gestore di 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 gran parte del perché Tailscale è un’ottima soluzione per “accesso remoto senza pubblicazione”.

Tailscale ti dà una rete privata (un tailnet) con controlli di accesso gestiti centralmente (ACL). Le ACL esistono specificamente per gestire i permessi 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 cercano di connettersi direttamente peer-to-peer quando possibile, e possono ricadere su meccanismi di relay quando la connettività diretta non è possibile.

Questo non è di per sé una sicurezza magica, ma riduce radicalmente il raggio di esplosione rispetto a “ho inoltrato 11434 sul mio router”.

Orizzonte diviso e naming con MagicDNS

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

Tailscale MagicDNS 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 tuo nome DNS tailnet, e i nomi tailnet moderni finiscono in .ts.net.

La posizione opinata è che usare un nome è solitamente meglio rispetto a codificare un IP, perché il nome segue il dispositivo anche se il tuo IP tailnet cambia. Ma è anche giusto essere intenzionalmente noiosi e mantenere un piccolo file hosts o un singolo record DNS interno se preferisci. MagicDNS esiste così non devi farlo.

Porta diretta rispetto al 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 client 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 in esecuzione sul tuo dispositivo.

Per Ollama, Serve può essere attraente perché ti permette di mantenere Ollama su localhost e 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 funzionalità correlata da nominare e poi parcheggiare mentalmente è Funnel. Funnel è progettato per instradare il traffico da 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 peer e decidi quale traffico è autorizzato a fluire.

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

Il concetto chiave per delimitare 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 subnet WireGuard privata.
• Binding di Ollama o su localhost e inoltra ad esso, o binding 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: permetti solo l’interfaccia VPN o tailnet

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

Il pattern generale è:

• Permetti la porta TCP di Ollama solo sull’interfaccia VPN (tailscale0 o wg0).
• Neghi la stessa porta ovunque else.
• Preferisci “denia in entrata di default” se operi in quel modo per l’host.

Tailscale ha una guida esplicita 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 per Tailscale in particolare è che le aspettative del firewall dell’host potrebbero non corrispondere alla realtà se si presume che UFW bloccherà il traffico tailnet. Il progetto Tailscale ha discusso il fatto che installa intenzionalmente una regola per permettere 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 stia effettivamente applicando la politica. Se vuoi “solo questi dispositivi possono raggiungere la porta 11434”, le ACL di Tailscale sono progettate per questo compito.

Se vuoi comunque controlli dell’host a livello di interfaccia, gli esempi tendono a essere 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

# O 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 comunque una utile “cintura di sicurezza” contro il binding errato a 0.0.0.0 o involucri di servizio inaspettati.

Proxy inverso opzionale solo sull’ingresso VPN

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

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

Qui è dove l’intento “non pubblicare su internet” dovrebbe rimanere vero: il proxy inverso è raggiungibile solo tramite 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 punta fuori che le connessioni tra nodi sono già crittografate end-to-end, ma i browser non ne sono a conoscenza perché si affidano a 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 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 intenzionalmente non include la configurazione completa del proxy inverso (vedi il tuo articolo A1 per quello). L’unica idea che conta qui è il posizionamento:

• Ollama ascolta su localhost o IP VPN.
• Il proxy inverso ascolta solo sull’interfaccia VPN.
• Il 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 questo.
• 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 permettano solo utenti specifici o dispositivi etichettati alla porta di Ollama. Le ACL esistono per gestire i permessi dei dispositivi.
• Se usi WireGuard, mantieni AllowedIPs stretti e tratta le chiavi come il confine reale dell’identità. WireGuard scarta i pacchetti che non corrispondono a una mappatura AllowedIPs peer valida.

Firewall

• Aggiungi una regola a livello di host che permetta la porta di 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 di permettere il traffico tailscale0 e di 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 già cifra il trasporto. Tailscale documenta questo divario tra la crittografia VPN e la fiducia HTTPS del browser.
• Se abiliti i certificati HTTPS di Tailscale, ricorda l’implicazione della trasparenza dei certificati per gli hostnames.
• Se aggiungi un proxy inverso, mantienilo solo VPN e usalo per autenticazione e limiti, non per l’esposizione a internet.

Evita l’esposizione pubblica accidentale

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

Osservabilità e controllo dei danni

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

Il tema coerente è noioso di proposito: mantieni l’API di 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.