Acceso remoto a Ollama mediante Tailscale o WireGuard, sin puertos públicos.

Ollama funciona mejor cuando se trata como un demonio local: la CLI y sus aplicaciones se comunican con una API HTTP de bucle local, y el resto de la red nunca descubre su existencia.

Por defecto, eso es exactamente lo que ocurre: la dirección base local común es localhost en el puerto 11434.

Este artículo trata sobre el momento en que desea acceso remoto (portátil, otra máquina de oficina, quizás un teléfono), pero no desea publicar un ejecutor de modelos sin autenticación en todo Internet. Esa intención importa, porque el movimiento de escalado más sencillo (abrir un puerto, reenviarlo y listo) también es el movimiento que crea el desastre.

Una estrella norte práctica es simple: mantenga la API de Ollama privada, luego haga que la ruta de red privada sea aburrida. Tailscale y WireGuard son dos formas comunes de hacerlo, y el resto consiste en asegurarse de que el host escuche solo donde debería y que el firewall esté de acuerdo.

Dispositivo remoto
  |
  | (ruta VPN privada: tailscale o wireguard)
  v
Interfaz VPN en el host (tailscale0 o wg0)
  |
  | (salto local)
  v
Servidor Ollama (API HTTP en localhost o IP de VPN)

Para ver cómo encaja Ollama junto a vLLM, Docker Model Runner, LocalAI y los compromisos de alojamiento en la nube, consulte Alojamiento de LLM en 2026: Infraestructura Local, Autoadministrada y en la Nube Comparadas.

Guías relacionadas:

• Hoja de referencia de comandos de Ollama
• Ollama detrás de un proxy inverso con Caddy o Nginx para transmisión HTTPS
• Ollama en Docker Compose con GPU y almacenamiento de modelos persistente

Modelo de amenazas y quién debe acceder a la API

¿Cómo se puede acceder a Ollama de forma remota sin exponerlo al internet público? La respuesta tiene menos que ver con una herramienta específica y más con ser explícito sobre “quién puede conectarse” y “desde dónde”.

Un modelo mental útil son tres anillos concéntricos:

• Solo local: solo los procesos en la máquina pueden llamar a la API.
• Solo LAN: los dispositivos en la misma red local pueden llamar a la API.
• Solo VPN: dispositivos y usuarios seleccionados en una red de superposición privada pueden llamar a la API.

El primer anillo es el predeterminado. Muchas guías (y herramientas como Postman) asumen que la URL base es localhost 11434, lo cual es tanto conveniente como una barrera de seguridad sorprendentemente fuerte.

La razón por la que los anillos importan es que Ollama comúnmente se describe como que no tiene autenticación integrada para su API HTTP local, lo que significa que la exposición de red y el control de acceso se convierten en su responsabilidad si avanza más allá de localhost.

La otra razón es el costo y el abuso: incluso un punto de final LLM “privado” sigue siendo un punto de final de API. La lista OWASP API Security Top 10 señala categorías como la mala configuración de seguridad y el consumo de recursos ilimitado; un ejecutor de modelos es prácticamente un ejemplo perfecto de “consumo de recursos” si se expone de forma casual.

Por lo tanto, el modelo de amenazas básico no es solo “un atacante lee mis datos”. También es “alguien puede usar mi CPU y GPU como un coche de alquiler” y “usuarios no deseados lo descubren y comienzan a construir sobre él”.

OLLAMA_HOST y semánticas de enlace en 90 segundos

¿Qué hace OLLAMA_HOST y cuál es el valor predeterminado más seguro? OLLAMA_HOST es el interruptor que controla dónde escucha el servidor de Ollama. En ollama serve, la variable de entorno se describe como la dirección IP y el puerto para el servidor, con un valor predeterminado de 127.0.0.1 y puerto 11434.

En términos simples, la dirección de enlace decide qué redes pueden incluso intentar una conexión TCP:

• 127.0.0.1 significa solo localhost.
• Una IP de LAN (como 192.168.x.y) significa que la LAN puede alcanzarla.
• 0.0.0.0 significa todas las interfaces (LAN, VPN, todo) pueden alcanzarla a menos que un firewall las bloquee.

Por eso la mayoría de los tutoriales de “hacerlo accesible” sugieren cambiar de 127.0.0.1 a 0.0.0.0, pero ese consejo es incompleto sin un firewall consciente de la interfaz.

Aquí está la hoja de trucos que tengo en mi cabeza:

# Solo local (línea base)
export OLLAMA_HOST=127.0.0.1:11434

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

# Solo interfaz VPN (preferido cuando la VPN tiene una IP estable en el host)
export OLLAMA_HOST=100.64.0.10:11434   # ejemplo de IP tailscale
export OLLAMA_HOST=10.10.10.1:11434    # ejemplo de IP wireguard

# Puerto diferente (útil cuando 11434 ya está ocupado)
export OLLAMA_HOST=127.0.0.1:11435

El caso de “puerto diferente” se discute explícitamente en el rastreador de problemas de Ollama como un ejemplo de usar OLLAMA_HOST para alterar el puerto de escucha.

Una nota operativa que muerde a la gente: si Ollama se ejecuta como un servicio gestionado, establecer variables de entorno en un shell interactivo no necesariamente cambia la configuración del servicio. Esta es la razón por la que muchas historias de “funcionó en mi terminal pero no después de reiniciar” terminan en sobrescrituras de unidades systemd o configuración del gestor de servicios.

Patrón A: VPN primero con Tailscale

¿Puede Tailscale restringir el acceso a solo un puerto de servicio en una máquina? Sí, y esa es una gran parte de por qué Tailscale es un buen ajuste para “acceso remoto sin publicar”.

Tailscale le proporciona una red privada (un tailnet) con controles de acceso gestionados centralmente (ACLs). Las ACLs existen específicamente para gestionar los permisos de los dispositivos y asegurar la red.

Sin puerto público significa sin coreografía de router

El patrón más limpio es evitar abrir cualquier puerto orientado a Internet para Ollama en absoluto y tratar la VPN como el único acceso. Con Tailscale, los dispositivos intentan conectarse directamente entre pares cuando es posible y pueden recurrir a mecanismos de retransmisión cuando la conectividad directa no es posible.

Esto no es seguridad mágica por sí mismo, pero reduce radicalmente el radio de explosión en comparación con “reenvié 11434 en mi router”.

Horizonte dividido y nombres con MagicDNS

Una segunda pregunta que surge en la vida real es “¿me conecto vía IP LAN cuando estoy en casa y vía IP VPN cuando estoy fuera?”. Eso es básicamente un problema de horizonte dividido.

Tailscale MagicDNS ayuda al dar a cada dispositivo un nombre de host tailnet estable. Bajo el capó, MagicDNS genera un FQDN para cada dispositivo que combina el nombre de la máquina y su nombre de DNS tailnet, y los nombres tailnet modernos terminan en .ts.net.

La opinión es que usar un nombre suele ser mejor que codificar una IP, porque el nombre sigue al dispositivo incluso si su IP tailnet cambia. Pero también está bien ser intencionalmente aburrido y mantener un archivo hosts pequeño o un único registro DNS interno si lo prefiere. MagicDNS existe para que no tenga que hacerlo.

Puerto directo frente a enrutamiento exclusivo de tailnet

Hay dos formas comunes de Tailscale para alcanzar un servicio:

• Acceso directo al puerto, donde el servicio escucha en la interfaz tailnet y los clientes se conectan a esa IP y puerto.
• Tailscale Serve, donde Tailscale enruta el tráfico de otros dispositivos tailnet a un servicio local en el host.

Serve se describe explícitamente como enrutamiento de tráfico de otros dispositivos tailnet a un servicio local que se ejecuta en su dispositivo.

Para Ollama, Serve puede ser atractivo porque le permite mantener Ollama en localhost y exponer solo una ruta de acceso controlada a través de Tailscale. También se empareja naturalmente con HTTPS dentro del tailnet si desea puntos finales amigables para el navegador.

Una característica relacionada que vale la pena nombrar y luego aparcar mentalmente es Funnel. Funnel está diseñado para enrutamiento de tráfico desde el internet más amplio a un servicio en un dispositivo tailnet y es explícitamente para “cualquiera puede acceder incluso si no usa Tailscale”. Eso es lo opuesto a este artículo.

Patrón B: WireGuard para aquellos que quieren los primitivos crudos

WireGuard es el primitivo subyacente que impulsa muchos productos de VPN, y es deliberadamente minimalista: configura una interfaz, define pares y decide qué tráfico se permite fluir.

La guía de inicio rápido de WireGuard muestra la forma básica: crear una interfaz como wg0, asignar IPs y configurar pares con wg.

El concepto clave para delimitar el acceso es AllowedIPs. En la documentación de Red Hat, WireGuard lee la IP de destino de un paquete y la compara con la lista de direcciones IP permitidas; si el par no se encuentra, WireGuard descarta el paquete.

Para un host de Ollama, la traducción práctica es:

• Coloque el host en una subred privada de WireGuard.
• Enlace Ollama ya sea a localhost y reenvíe a él, o enlace directamente a la IP de WireGuard.
• Solo los pares que tengan las claves correctas y AllowedIPs pueden enrutrar tráfico a esa IP privada.

Esto tiene menos partes móviles que una superposición comercial, pero también significa que usted es responsable de la distribución de claves, el ciclo de vida de los pares y cómo los pares remotos alcanzan su red.

Firewall: permitir solo interfaz VPN o tailnet

¿Cómo puede un firewall limitar Ollama solo al tráfico de la interfaz VPN? El objetivo es prevenir la exposición accidental incluso si la dirección de enlace se vuelve más amplia de lo previsto.

El patrón general es:

• Permitir el puerto TCP de Ollama solo en la interfaz VPN (tailscale0 o wg0).
• Denegar el mismo puerto en todo lo demás.
• Prefiera “denegar entrada por defecto” si opera así para el host.

Tailscale tiene orientación explícita sobre el uso de UFW para restringir el tráfico no-Tailscale a un servidor, que es esencialmente el enfoque de “candear todo excepto el tailnet”.

Un matiz que importa para Tailscale específicamente es que las expectativas del firewall del host pueden no coincidir con la realidad si asume que UFW bloqueará el tráfico del tailnet. El proyecto Tailscale ha discutido que instala intencionalmente una regla para permitir tráfico en tailscale0 y confía en un filtro controlado por ACL dentro de tailscaled.

Eso no es un argumento en contra de un firewall del host. Es un argumento para ser deliberado sobre qué plano de control está realmente ejecutando la política. Si usted quiere “solo estos dispositivos pueden alcanzar el puerto 11434”, las ACLs de Tailscale están diseñadas para ese trabajo.

Si usted quiere controles de host a nivel de interfaz de todos modos, los ejemplos tienden a verse así:

# 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

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

Incluso si confía principalmente en la política de VPN, el firewall del host sigue proporcionando un útil “cinturón de seguridad” contra enlaces incorrectos a 0.0.0.0 o envoltorios de servicio inesperados.

Proxy inverso opcional solo en acceso VPN

¿Cuándo es útil un proxy inverso para el acceso remoto a Ollama? Un proxy es útil cuando desea una o más de estas propiedades:

• Una puerta de autenticación estándar (autenticación básica, OIDC, certificados de cliente).
• Terminación TLS con un certificado que los clientes confían.
• Límites de solicitudes y tiempos de espera.
• URLs más limpias para herramientas que no gustan de los puertos crudos.

Aquí es donde la intención de “no publicar en Internet” debería seguir siendo cierta: el proxy inverso es accesible solo a través de la VPN, no en la interfaz WAN pública.

¿Se necesita TLS cuando el tráfico ya pasa a través de una VPN? No siempre para la criptografía, pero a menudo para la ergonomía. Tailscale señala que las conexiones entre nodos ya están cifradas de extremo a extremo, pero los navegadores no son conscientes de eso porque confían en certificados TLS para establecer confianza HTTPS.

Si usted está en el mundo de Tailscale, puede habilitar certificados HTTPS para su tailnet, lo que requiere MagicDNS y nota explícitamente que los nombres de máquinas y el nombre de DNS tailnet se publicarán en un registro público (registros de transparencia de certificados).

Ese detalle de registro público no es una razón para evitar TLS, pero es una razón para nombrar máquinas como un adulto (evite incrustar nombres de proyectos privados o identificadores de clientes en los nombres de host).

Este artículo intencionalmente no incluye la configuración completa del proxy inverso; para Caddy o Nginx, transmisión y autenticación en el borde, consulte Ollama detrás de un proxy inverso con Caddy o Nginx para transmisión HTTPS. La única idea que importa aquí es la colocación:

• Ollama escucha en localhost o IP de VPN.
• Proxy inverso escucha solo en la interfaz de VPN.
• Proxy reenvía a Ollama.

Lista de verificación de seguridad para acceso remoto a la API de Ollama

Esta es la lista de verificación que uso para evitar que “remoto” se convierta silenciosamente en “público”.

Enlace y accesibilidad

• Confirme que el servidor escuche donde usted cree que escucha. El valor predeterminado documentado es 127.0.0.1 y puerto 11434, y OLLAMA_HOST cambia eso.
• Trate 0.0.0.0 como una elección deliberada, no como un interruptor de conveniencia.
• Prefiera enlazar a una IP de interfaz VPN cuando sea estable y se ajuste a la topología.

Control de acceso

• Si usa Tailscale, implemente ACLs que permitan solo a usuarios específicos o dispositivos etiquetados al puerto de Ollama. Las ACLs existen para gestionar los permisos de los dispositivos.
• Si usa WireGuard, mantenga AllowedIPs ajustados y trate las claves como el límite de identidad real. WireGuard descarta paquetes que no coinciden con un mapeo AllowedIPs de par válido.

Firewall

• Agregue una regla a nivel de host que permita el puerto de Ollama solo en tailscale0 o wg0 y lo bloquee en todas partes.
• Si espera que UFW bloquee el tráfico del tailnet, verifique cómo Tailscale interactúa con su firewall. Tailscale ha discutido permitir tráfico tailscale0 y confiar en el filtrado de ACL dentro de tailscaled.

TLS y enrutamiento

• Use TLS cuando los clientes sean navegadores o cuando las herramientas esperen HTTPS, incluso si la VPN ya cifra el transporte. Tailscale documenta esta brecha entre el cifrado de VPN y la confianza HTTPS del navegador.
• Si habilita certificados HTTPS de Tailscale, recuerde la implicación de transparencia de certificados para los nombres de host.
• Si agrega un proxy inverso, manténgalo solo de VPN y úselo para autenticación y límites, no para exposición a Internet.

Evite la exposición pública accidental

• Tenga cuidado con las características diseñadas explícitamente para publicar servicios en Internet. Tailscale Funnel enruta tráfico desde el internet más amplio a un dispositivo tailnet, lo cual no es el camino seguro predeterminado para una API de Ollama.
• Si algo termina siendo accesible desde Internet, no deje una superficie /api anónima. En ese punto, las categorías de riesgo de OWASP API “mala configuración de seguridad” y “consumo de recursos” dejan de ser teóricas.

Observabilidad y control de daños

• Registre las solicitudes en la capa de acceso (registros de política de VPN, registros de proxy, o ambos).
• Agregue límites de solicitudes y concurrencia si su proxy los soporta, porque la inferencia del modelo es un evento de recursos, no una llamada de API normal.

El tema consistente es aburrido a propósito: mantenga la API de Ollama privada por defecto, agregue una ruta privada para acceso remoto, luego ejecute esa política dos veces (identidad de VPN más firewall del host) para que un solo error no se convierta en un punto final público.