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

Ollama está en su mejor momento cuando se trata como un demonio local: la CLI y tus 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 sucede: la dirección base local común está en localhost en el puerto 11434.

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

Una estrella norte práctica es simple: mantén la API de Ollama privada y luego haz que la ruta de red privada sea aburrida. Tailscale y WireGuard son dos formas comunes de hacer eso, y el resto se trata de asegurarse de que el host escuche solo donde debería y que el firewall esté de acuerdo.

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

Modelo de amenazas y quién debería 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 está autorizado para 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 superpuesta privada pueden llamar a la API.

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

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

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

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 si fuera un coche de alquiler” y “usuarios no previstos lo descubren y comienzan a construir sobre ello”.

OLLAMA_HOST y semántica de vinculación 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 sencillos, la dirección de vinculación 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 alcanzarlo.
• 0.0.0.0 significa todas las interfaces (LAN, VPN, todo) pueden alcanzarlo a menos que un firewall lo bloquee.

Es por eso que 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 las interfaces.

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

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

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

# Solo interfaz de VPN (preferido cuando la VPN tiene una IP estable en el host)
export OLLAMA_HOST=100.64.0.10:11434   # ejemplo de IP de tailscale
export OLLAMA_HOST=10.10.10.1:11434    # ejemplo de IP de 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 uso de OLLAMA_HOST para alterar el puerto de escucha.

Una nota operativa que muerde a la gente: si Ollama se ejecuta como un servicio administrado, establecer variables de entorno en un shell interactivo no necesariamente cambia la configuración del servicio. Por eso es que muchas historias de “funcionó en mi terminal pero no después del reinicio” terminan en sobrescrituras de unidades de systemd o en la configuración del administrador 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 una buena opción para “acceso remoto sin publicar”.

Tailscale te da 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 la única entrada. 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 magia de seguridad por sí mismo, pero reduce radicalmente el radio de explosión en comparación con “reenvié el 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 de LAN cuando estoy en casa y vía IP de VPN cuando estoy fuera”. Eso es básicamente un problema de horizonte dividido.

MagicDNS de Tailscale ayuda dando a cada dispositivo un nombre de host de tailnet estable. Bajo el capó, MagicDNS genera un FQDN para cada dispositivo que combina el nombre de la máquina y tu nombre de DNS de tailnet, y los nombres de 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 tu IP de tailnet cambia. Pero también está bien ser intencionalmente aburrido y mantener un archivo de hosts pequeño o un solo registro DNS interno si prefieres. MagicDNS existe para que no tengas 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 del tailnet y los clientes se conectan a esa IP y puerto.
• Tailscale Serve, donde Tailscale enruta el tráfico desde otros dispositivos del tailnet a un servicio local en el host.

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

Para Ollama, Serve puede ser atractivo porque te permite mantener Ollama en localhost y exponer solo una ruta de entrada controlada a través de Tailscale. También se empareja naturalmente con HTTPS dentro del tailnet si quieres endpoints amigables para navegadores.

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

Patrón B: WireGuard para quienes quieren los primitivos crudos

WireGuard es el primitivo subyacente que impulsa muchos productos de VPN, y es deliberadamente minimalista: configuras una interfaz, defines pares y decides qué tráfico está permitido fluir.

La guía de inicio rápido de WireGuard muestra la forma básica: crea una interfaz como wg0, asigna IPs y configura 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:

• Coloca el host en una subred privada de WireGuard.
• Vincula Ollama ya sea a localhost y reenvía tráfico a él, o vincúlalo 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 piezas móviles que una superposición comercial, pero también significa que eres responsable de la distribución de claves, el ciclo de vida de los pares y cómo los pares remotos alcanzan tu red.

Firewall: permitir solo interfaz de VPN o tailnet

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

El patrón general es:

• Permitir el puerto TCP de Ollama solo en la interfaz de VPN (tailscale0 o wg0).
• Denegar el mismo puerto en todo lo demás.
• Preferir “denegar entrada por defecto” si operas de esa manera 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 “bloquear todo excepto el tailnet”.

Un matiz que importa específicamente para Tailscale es que las expectativas del firewall del host pueden no coincidir con la realidad si asumes 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 de host. Es un argumento para ser deliberado sobre qué plano de control está aplicando realmente la política. Si quieres “solo estos dispositivos pueden alcanzar el puerto 11434”, las ACLs de Tailscale están diseñadas para ese trabajo.

Si de todos modos quieres controles de host a nivel de interfaz, los ejemplos suelen parecerse a esto:

# 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ías principalmente en la política de VPN, el firewall del host sigue proporcionando un útil “cinturón de seguridad” contra la vinculación incorrecta a 0.0.0.0 o envoltorios de servicio inesperados.

Proxy inverso opcional solo en entrada de VPN

¿Cuándo es útil un proxy inverso para el acceso remoto a Ollama? Un proxy es útil cuando quieres 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 solicitud y temporizadores 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 dependen de certificados TLS para establecer confianza HTTPS.

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

Ese detalle del registro público no es una razón para evitar TLS, pero es una razón para nombrar las máquinas como un adulto (evita 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 (consulta tu artículo A1 para eso). La única idea que importa aquí es la colocación:

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

Lista de verificación de seguridad para el 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”.

Vinculación y alcance

• Confirma que el servidor escucha donde crees que escucha. El valor predeterminado documentado es 127.0.0.1 y puerto 11434, y OLLAMA_HOST cambia eso.
• Trata 0.0.0.0 como una elección deliberada, no como un interruptor de conveniencia.
• Prefiere vincular a una IP de interfaz de VPN cuando sea estable y encaje en la topología.

Control de acceso

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

Firewall

• Añade una regla a nivel de host que permita el puerto de Ollama solo en tailscale0 o wg0 y lo bloquee en todas partes.
• Si esperas que UFW bloquee el tráfico del tailnet, verifica cómo interactúa Tailscale con tu firewall. Tailscale ha discutido permitir tráfico de tailscale0 y confiar en la filtración de ACL dentro de tailscaled.

TLS y enrutamiento

• Usa 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 habilitas certificados HTTPS de Tailscale, recuerda la implicación de transparencia de certificados para los nombres de host.
• Si añades un proxy inverso, manténlo solo de VPN y úsalo para autenticación y límites, no para exposición a internet.

Evitar exposición pública accidental

• Ten cuidado con las funciones diseñadas explícitamente para publicar servicios en internet. Tailscale Funnel enruta tráfico desde el internet más amplio a un dispositivo del tailnet, lo cual no es la ruta segura por defecto para una API de Ollama.
• Si algo termina siendo accesible desde internet, no dejes una superficie /api anónima. En ese punto, las categorías de riesgo de OWASP API “configuración de seguridad incorrecta” y “consumo de recursos” dejan de ser teóricas.

Observabilidad y control de daños

• Registra las solicitudes en la capa de entrada (registros de política de VPN, registros de proxy, o ambos).
• Añade límites de solicitud y concurrencia si tu 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: mantén la API de Ollama privada por defecto, añade una ruta privada para el acceso remoto y luego aplica esa política dos veces (identidad de VPN más firewall de host) para que un solo error no se convierta en un endpoint público.