Acesso remoto ao Ollama via Tailscale ou WireGuard, sem portas públicas.

Ollama está em seu melhor quando é tratado como um daemon local: a CLI e seus aplicativos se comunicam com uma API HTTP em loopback, e o resto da rede nunca fica sabendo que ele existe.

Por padrão, é exatamente o que acontece: o endereço base local comum é na porta 11434 do localhost.

Este artigo trata do momento em que você deseja acesso remoto (notebook, outra máquina de escritório, talvez um telefone), mas não quer publicar um executor de modelos não autenticado na internet inteira. Essa intenção importa, porque o movimento de escalonamento mais fácil (abrir uma porta, fazer o encaminhamento e pronto) é também o que cria a bagunça.

Uma bússola prática é simples: mantenha a API do Ollama privada e torne o caminho da rede privada tedioso. Tailscale e WireGuard são duas maneiras comuns de fazer isso, e o resto é garantir que o host ouça apenas onde deve e que o firewall concorde.

Dispositivo remoto
  |
  | (caminho de VPN privada: tailscale ou wireguard)
  v
Interface de VPN no host (tailscale0 ou wg0)
  |
  | (salto local)
  v
Servidor Ollama (API HTTP em localhost ou IP da VPN)

Para saber como o Ollama se enquadra junto com vLLM, Docker Model Runner, LocalAI e as compensações de hospedagem em nuvem, veja LLM Hosting in 2026: Local, Self-Hosted & Cloud Infrastructure Compared.

Guias relacionados:

• 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

Modelo de ameaça e quem deve acessar a API

Como o Ollama pode ser acessado remotamente sem expô-lo à internet pública? A resposta tem menos a ver com uma ferramenta específica e mais com ser explícito sobre “quem é permitido conectar” e “de onde”.

Um modelo mental útil são três anéis concêntricos:

• Apenas local: apenas processos na máquina podem chamar a API.
• Apenas LAN: dispositivos na mesma rede local podem chamar a API.
• Apenas VPN: dispositivos e usuários selecionados em uma rede de sobreposição privada podem chamar a API.

O primeiro anel é o padrão. Muitos guias (e ferramentas como o Postman) assumem que a URL base é localhost 11434, o que é conveniente e uma fronteira de segurança surpreendentemente forte.

O motivo pelo qual os anéis importam é que o Ollama é comumente descrito como não tendo autenticação nativa para sua API HTTP local, o que significa que a exposição à rede e o controle de acesso tornam-se sua responsabilidade se você for além do localhost.

O outro motivo é custo e abuso: mesmo um endpoint de LLM “privado” ainda é um endpoint de API. Os Top 10 de Segurança de API do OWASP destacam categorias como configuração de segurança incorreta e consumo de recursos ilimitado; um executor de modelos é praticamente o exemplo perfeito de “consumo de recursos” se exposto casualmente.

Portanto, o modelo de ameaça básico não é apenas “um invasor lê meus dados”. Também é “alguém pode usar minha CPU e GPU como se fosse um carro alugado” e “usuários não intencionais o descobrem e começam a construir sobre ele”.

OLLAMA_HOST e semântica de vínculo em 90 segundos

O que o OLLAMA_HOST faz e qual é o valor padrão mais seguro? OLLAMA_HOST é o controle que define onde o servidor Ollama escuta. Em ollama serve, a variável de ambiente é descrita como o endereço IP e a porta para o servidor, com um padrão de 127.0.0.1 e porta 11434.

Em termos simples, o endereço de vínculo decide quais redes podem até tentar uma conexão TCP:

• 127.0.0.1 significa apenas localhost.
• Um IP de LAN (como 192.168.x.y) significa que a LAN pode alcançá-lo.
• 0.0.0.0 significa todas as interfaces (LAN, VPN, tudo) podem alcançá-lo, a menos que um firewall bloqueie.

É por isso que a maioria dos tutoriais de “tornar acessível” sugere mudar de 127.0.0.1 para 0.0.0.0, mas esse conselho está incompleto sem um firewall ciente da interface.

Aqui está o guia rápido que mantenho na minha cabeça:

# Apenas local (linha de base)
export OLLAMA_HOST=127.0.0.1:11434

# Todas as interfaces (poderoso, fácil de arrepender)
export OLLAMA_HOST=0.0.0.0:11434

# Apenas interface VPN (preferível quando a VPN tem um IP estável no host)
export OLLAMA_HOST=100.64.0.10:11434   # exemplo de IP tailscale
export OLLAMA_HOST=10.10.10.1:11434    # exemplo de IP wireguard

# Porta diferente (útil quando 11434 já está em uso)
export OLLAMA_HOST=127.0.0.1:11435

O caso de “porta diferente” é explicitamente discutido no rastreador de problemas do Ollama como um exemplo de uso do OLLAMA_HOST para alterar a porta de escuta.

Um rodapé operacional que pega as pessoas desprevenidas: se o Ollama roda como um serviço gerenciado, definir variáveis de ambiente em um shell interativo nem sempre altera a configuração do serviço. É por isso que muitas histórias de “funcionou no meu terminal, mas não após a reinicialização” acabam em sobrescritas de unidade systemd ou configuração do gerenciador de serviços.

Padrão A: VPN primeiro com Tailscale

O Tailscale pode restringir o acesso a apenas uma porta de serviço em uma máquina? Sim, e isso é uma grande parte do motivo pelo qual o Tailscale é um bom ajuste para “acesso remoto sem publicação”.

O Tailscale fornece uma rede privada (um tailnet) com controles de acesso geridos centralmente (ACLs). As ACLs existem especificamente para gerenciar permissões de dispositivos e proteger a rede.

Nenhuma porta pública significa nenhuma coreografia de roteador

O padrão mais limpo é evitar abrir qualquer porta voltada para a internet para o Ollama e tratar a VPN como o único ingresso. Com o Tailscale, os dispositivos tentam se conectar diretamente peer-to-peer quando possível e podem recorrer a mecanismos de retransmissão quando a conectividade direta não é possível.

Isso não é segurança mágica por si só, mas reduz drasticamente o raio de explosão em comparação com “encaminhei a porta 11434 no meu roteador”.

Horizonte dividido e nomenclatura com MagicDNS

Uma segunda questão que aparece na vida real é “devo conectar via IP de LAN quando estou em casa e via IP de VPN quando estou fora”. Isso é basicamente um problema de horizonte dividido.

O MagicDNS do Tailscale ajuda dando a cada dispositivo um nome de host estável no tailnet. Sob o capô, o MagicDNS gera um FQDN para cada dispositivo que combina o nome da máquina e o nome de DNS do seu tailnet, e os nomes de tailnet modernos terminam em .ts.net.

A opinião é que usar um nome é geralmente melhor do que codificar um IP, porque o nome segue o dispositivo mesmo se o seu IP do tailnet mudar. Mas também é perfeitamente aceitável ser intencionalmente tedioso e manter um arquivo hosts pequeno ou um único registro de DNS interno se você preferir. O MagicDNS existe para que você não precise fazer isso.

Porta direta versus proxying apenas no tailnet

Existem duas maneiras comuns do Tailscale para alcançar um serviço:

• Acesso direto à porta, onde o serviço escuta na interface do tailnet e os clientes se conectam a esse IP e porta.
• Tailscale Serve, onde o Tailscale roteia tráfego de outros dispositivos do tailnet para um serviço local no host.

O Serve é explicitamente descrito como rotear tráfego de outros dispositivos do tailnet para um serviço local rodando no seu dispositivo.

Para o Ollama, o Serve pode ser atraente porque permite que você mantenha o Ollama em localhost e exponha apenas um caminho de ingresso controlado através do Tailscale. Também se encaixa naturalmente com HTTPS dentro do tailnet se você quiser endpoints amigáveis para navegadores.

Uma funcionalidade relacionada que vale a pena nomear e depois estacionar mentalmente é o Funnel. O Funnel é projetado para rotear tráfego da internet mais ampla para um serviço em um dispositivo do tailnet e é explicitamente para “qualquer pessoa acessar mesmo que não use o Tailscale”. Isso é o oposto deste artigo.

Padrão B: WireGuard para aqueles que querem os primitivos brutos

O WireGuard é o primitivo subjacente que alimenta muitos produtos de VPN e é deliberadamente minimalista: você configura uma interface, define peers e decide qual tráfego é permitido fluir.

O início rápido do WireGuard mostra a forma básica: crie uma interface como wg0, atribua IPs e configure peers com wg.

O conceito chave para escalar o acesso é AllowedIPs. Na documentação da Red Hat, o WireGuard lê o IP de destino de um pacote e compara-o com a lista de endereços IP permitidos; se o peer não for encontrado, o WireGuard descarta o pacote.

Para um host Ollama, a tradução prática é:

• Coloque o host em uma sub-rede privada WireGuard.
• Vincule o Ollama ao localhost e encaminhe para ele, ou vincule diretamente ao IP do WireGuard.
• Apenas peers que possuem as chaves corretas e AllowedIPs podem rotear tráfego para esse IP privado.

Isso é menos peças móveis do que uma sobreposição comercial, mas também significa que você é responsável pela distribuição de chaves, ciclo de vida de peers e como peers remotos alcançam sua rede.

Firewall permite apenas interface VPN ou tailnet

Como um firewall pode limitar o Ollama a apenas tráfego de interface VPN? O objetivo é prevenir exposição acidental mesmo se o endereço de vínculo se tornar mais amplo do que o pretendido.

O padrão geral é:

• Permitir a porta TCP do Ollama apenas na interface da VPN (tailscale0 ou wg0).
• Negar a mesma porta em tudo o mais.
• Preferir “negar entrada por padrão” se você operar assim para o host.

O Tailscale tem orientações explícitas sobre o uso do UFW para restringir tráfego não-Tailscale para um servidor, que é essencialmente a abordagem de “bloquear tudo exceto o tailnet”.

Uma nuance que importa especificamente para o Tailscale é que as expectativas do firewall do host podem não corresponder à realidade se você assumir que o UFW bloqueará o tráfego do tailnet. O projeto Tailscale discutiu que ele instala intencionalmente uma regra para permitir tráfego em tailscale0 e confia em um filtro controlado por ACL dentro do tailscaled.

Isso não é um argumento contra um firewall de host. É um argumento para ser deliberado sobre qual plano de controle está realmente aplicando a política. Se você quer “apenas estes dispositivos podem alcançar a porta 11434”, as ACLs do Tailscale foram projetadas para esse trabalho.

Se você ainda quiser controles de nível de interface no host, os exemplos tendem a parecer assim:

# Lógica estilo UFW (ilustrativo)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Ou para wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Mesmo que você confie principalmente na política de VPN, o firewall do host ainda fornece um útil “cinto de segurança” contra vinculação inadvertida a 0.0.0.0 ou wrappers de serviço inesperados.

Proxy reverso opcional apenas na entrada da VPN

Quando um proxy reverso é útil para acesso remoto ao Ollama? Um proxy é útil quando você quer uma ou mais dessas propriedades:

• Um portão de autenticação padrão (autenticação básica, OIDC, certificados de cliente).
• Terminação TLS com um certificado que os clientes confiam.
• Limites de solicitação e tempos de espera.
• URLs mais limpas para ferramentas que não gostam de portas brutas.

É aqui que a intenção de “não publicar na internet” ainda deve permanecer verdadeira: o proxy reverso é acessível apenas via VPN, não na interface WAN pública.

O TLS é necessário quando o tráfego já passa por uma VPN? Nem sempre para criptografia, mas frequentemente para ergonomia. O Tailscale aponta que as conexões entre nós já são criptografadas de ponta a ponta, mas os navegadores não têm consciência disso porque dependem de certificados TLS para estabelecer confiança HTTPS.

Se você estiver no mundo Tailscale, pode habilitar certificados HTTPS para seu tailnet, o que requer MagicDNS e nota explicitamente que os nomes de máquinas e o nome de DNS do tailnet serão publicados em um ledger público (logs de transparência de certificados).

Esse detalhe de ledger público não é um motivo para evitar o TLS, mas é um motivo para nomear máquinas como adultos (evite incorporar nomes de projetos privados ou identificadores de clientes nos nomes de host).

Este artigo intencionalmente não inclui configuração completa de proxy reverso; para Caddy ou Nginx, streaming e autenticação na borda, veja Ollama behind a reverse proxy with Caddy or Nginx for HTTPS streaming. A única ideia que importa aqui é a colocação:

• Ollama escuta em localhost ou IP da VPN.
• Proxy reverso escuta apenas na interface da VPN.
• Proxy encaminha para o Ollama.

Lista de verificação de segurança para acesso remoto à API Ollama

Esta é a lista de verificação que uso para evitar que “remoto” se torne silenciosamente “público”.

Vínculo e alcançabilidade

• Confirme que o servidor escuta onde você acha que ele escuta. O padrão documentado é 127.0.0.1 e porta 11434, e OLLAMA_HOST muda isso.
• Trate 0.0.0.0 como uma escolha deliberada, não como um botão de conveniência.
• Prefira vincular a um IP de interface VPN quando for estável e se encaixar na topologia.

Controle de acesso

• Se estiver usando Tailscale, implemente ACLs que permitam apenas usuários específicos ou dispositivos marcados para a porta do Ollama. As ACLs existem para gerenciar permissões de dispositivos.
• Se estiver usando WireGuard, mantenha AllowedIPs restritos e trate as chaves como a fronteira de identidade real. O WireGuard descarta pacotes que não correspondem a um mapeamento AllowedIPs de peer válido.

Firewall

• Adicione uma regra de nível de host que permita a porta do Ollama apenas em tailscale0 ou wg0 e bloqueie em todo o resto.
• Se você espera que o UFW bloqueie tráfego de tailnet, verifique como o Tailscale interage com seu firewall. O Tailscale discutiu permitir tráfego de tailscale0 e confiar na filtragem ACL dentro do tailscaled.

TLS e proxying

• Use TLS quando os clientes forem navegadores ou quando as ferramentas esperarem HTTPS, mesmo que a VPN já criptografe o transporte. O Tailscale documenta essa lacuna entre a criptografia de VPN e a confiança HTTPS do navegador.
• Se você habilitar certificados HTTPS do Tailscale, lembre-se da implicação de transparência de certificados para nomes de host.
• Se você adicionar um proxy reverso, mantenha-o apenas na VPN e use-o para autenticação e limites, não para exposição à internet.

Evite exposição pública acidental

• Tenha cuidado com recursos projetados explicitamente para publicar serviços na internet. O Tailscale Funnel roteia tráfego da internet mais ampla para um dispositivo do tailnet, o que não é o caminho padrão seguro para uma API Ollama.
• Se algo acabar alcançável pela internet, não deixe uma superfície /api anônima. A esse ponto, as categorias de risco de “configuração de segurança incorreta” e “consumo de recursos” do OWAPI deixam de ser teóricas.

Observabilidade e controle de danos

• Registre solicitações na camada de ingresso (logs de política de VPN, logs de proxy ou ambos).
• Adicione limites de solicitação e concorrência se seu proxy suportar, porque a inferência de modelo é um evento de recurso, não uma chamada de API normal.

O tema consistente é o tédio intencional: mantenha a API Ollama privada por padrão, adicione um caminho privado para acesso remoto e, em seguida, imponha essa política duas vezes (identidade de VPN mais firewall do host) para que um único passo em falso não se torne um endpoint público.