Дистанционный доступ к Ollama через Tailscale или WireGuard без открытых публичных портов.

Ollama чувствует себя наиболее комфортно, когда с ним обращаются как с локальным демонами: CLI и ваши приложения общаются через локальный HTTP-интерфейс, а остальная часть сети даже не знает о его существовании.

По умолчанию именно это и происходит: стандартный локальный базовый адрес находится на localhost порту 11434.

Эта статья посвящена ситуации, когда вам нужен удаленный доступ (к ноутбуку, другому офисному компьютеру или, возможно, телефону), но вы не хотите делать модель, работающую без аутентификации, доступной всему интернету. Эта цель имеет значение, потому что самый простой шаг для масштабирования (открыть порт, переслать трафик и готово) является именно тем шагом, который создает проблемы.

Практичный ориентир прост: держите API Ollama приватным, а затем сделайте путь по частной сети максимально скучным и предсказуемым. Tailscale и WireGuard — два распространенных способа сделать это, а остальное сводится к тому, чтобы убедиться, что хост слушает только те адреса, которые должны, и что фаервол с этим согласен.

Удаленное устройство
  |
  | (приватный путь VPN: tailscale или wireguard)
  v
Интерфейс VPN на хосте (tailscale0 или wg0)
  |
  | (локальный переход)
  v
Сервер Ollama (HTTP API на localhost или IP-адресе VPN)

Модель угроз и кто должен иметь доступ к API

Как можно получить удаленный доступ к Ollama, не подвергая его воздействию публичного интернета? Ответ заключается не столько в конкретном инструменте, сколько в четком определении «кто имеет право подключаться» и «откуда».

Полезная ментальная модель состоит из трех концентрических колец:

• Только локально: только процессы на этой машине могут вызывать API.
• Только LAN: устройства в той же локальной сети могут вызывать API.
• Только VPN: выбранные устройства и пользователи в частной оверлейной сети могут вызывать API.

Первое кольцо является значением по умолчанию. Многие руководства (и инструменты, такие как Postman) предполагают, что базовый URL — это localhost 11434, что удобно и создает surprisingly прочную границу безопасности.

Причина, по которой кольца имеют значение, заключается в том, что Ollama обычно описывается как не имеющая встроенной аутентификации для своего локального HTTP API, что означает, что при переходе за пределы localhost вопросы сетевого воздействия и контроля доступа становятся вашей ответственностью.

Другая причина — стоимость и злоупотребления: даже «частный» конечный пункт LLM все еще является API-конечной точкой. В списке OWASP API Security Top 10 выделяются такие категории, как ошибки конфигурации безопасности и неконтролируемое потребление ресурсов; модельный раннер практически является идеальным примером «потребления ресурсов», если он открыт небрежно.

Таким образом, базовая модель угроз включает не только «злоумышленник читает мои данные». Это также «кто-то может использовать мой CPU и GPU как арендованный автомобиль» и «непреднамеренные пользователи обнаруживают его и начинают строить на его основе».

OLLAMA_HOST и семантика привязки за 90 секунд

Что делает OLLAMA_HOST и какое самое безопасное значение по умолчанию? OLLAMA_HOST — это переключатель, который контролирует, где сервер Ollama слушает запросы. В команде ollama serve эта переменная окружения описывается как IP-адрес и порт для сервера, со значением по умолчанию 127.0.0.1 и портом 11434.

Простыми словами, адрес привязки определяет, какие сети вообще могут попытаться установить TCP-соединение:

• 127.0.0.1 означает только localhost.
• IP LAN (например, 192.168.x.y) означает, что LAN может достичь его.
• 0.0.0.0 означает все интерфейсы (LAN, VPN, всё), если фаервол их не блокирует.

Поэтому большинство руководств по «сделанию доступным» предлагают переключиться с 127.0.0.1 на 0.0.0.0, но этот совет неполон без фаервола, учитывающего интерфейсы.

Вот шпаргалка, которую я держу в уме:

# Только локально (базовый уровень)
export OLLAMA_HOST=127.0.0.1:11434

# Все интерфейсы (мощно, но легко пожалеть об этом)
export OLLAMA_HOST=0.0.0.0:11434

# Только интерфейс VPN (предпочтительно, когда у VPN есть стабильный IP на хосте)
export OLLAMA_HOST=100.64.0.10:11434   # пример IP tailscale
export OLLAMA_HOST=10.10.10.1:11434    # пример IP wireguard

# Другой порт (полезно, если 11434 уже занят)
export OLLAMA_HOST=127.0.0.1:11435

Случай с «другим портом» явно обсуждается в трекере проблем Ollama как пример использования OLLAMA_HOST для изменения порта прослушивания.

Одна операционная заметка, которая часто кусает людей: если Ollama работает как управляемая служба, установка переменных окружения в интерактивной оболочке не обязательно изменяет конфигурацию службы. Именно поэтому многие истории «это работало в моем терминале, но не после перезагрузки» заканчиваются настройками переопределения unit systemd или конфигурацией менеджера служб.

Паттерн A: Сначала VPN с Tailscale

Может ли Tailscale ограничивать доступ только одним портом службы на машине? Да, и это большая часть того, почему Tailscale хорошо подходит для «удаленного доступа без публикации».

Tailscale предоставляет частную сеть (tailnet) с централизованно управляемым контролем доступа (ACL). ACL существуют специально для управления разрешениями устройств и защиты сети.

Нет публичного порта — нет необходимости в настройке роутера

Самый чистый паттерн — вообще не открывать никаких портов, ориентированных на интернет, для Ollama и рассматривать VPN как единственный вход. С Tailscale устройства пытаются подключаться напрямую, точка-к-точке, когда это возможно, и могут использовать механизмы ретрансляции, когда прямое соединение невозможно.

Это не магия безопасности сама по себе, но это радикально сокращает радиус поражения по сравнению с «я переслал 11434 на моем роутере».

Разделение горизонтов и именование с MagicDNS

Второй вопрос, который возникает в реальной жизни: «подключаюсь ли я через IP LAN, когда я дома, и через IP VPN, когда я вдали». Это по сути проблема разделения горизонтов.

Tailscale MagicDNS помогает, предоставляя каждому устройству стабильное имя хоста tailnet. Под капотом MagicDNS генерирует FQDN для каждого устройства, сочетая имя машины и имя DNS вашего tailnet, а современные имена tailnet заканчиваются на .ts.net.

Субъективное мнение состоит в том, что использование имени обычно лучше, чем жесткая кодировка IP, потому что имя следует за устройством, даже если ваш IP tailnet изменится. Но также нормально быть намеренно скучным и поддерживать небольшой файл hosts или одну внутреннюю DNS-запись, если вы предпочитаете это. MagicDNS существует именно для того, чтобы вам не пришлось этого делать.

Прямой порт против проксирования только в tailnet

Существует два распространенных способа Tailscale для доступа к службе:

• Прямой доступ к порту, где служба слушает на интерфейсе tailnet, а клиенты подключаются к этому IP и порту.
• Tailscale Serve, где Tailscale маршрутизирует трафик от других устройств tailnet к локальной службе на хосте.

Serve явно описывается как маршрутизация трафика от других устройств tailnet к локальной службе, работающей на вашем устройстве.

Для Ollama Serve может быть привлекательным, потому что это позволяет держать Ollama на localhost и открывать только контролируемый путь входа через Tailscale. Он также естественным образом сочетается с HTTPS внутри tailnet, если вам нужны удобные для браузера конечные точки.

Связанная функция, которую стоит назвать, а затем мысленно отложить, — это Funnel. Funnel предназначен для маршрутизации трафика из более широкого интернета к службе на устройстве tailnet и явно предназначен для «доступа для всех, даже если они не используют Tailscale». Это противоположно цели этой статьи.

Паттерн B: WireGuard для тех, кто хочет сырые примитивы

WireGuard — это базовый примитив, питающий многие VPN-продукты, и он намеренно минималистичен: вы настраиваете интерфейс, определяете сверстников (peers) и решаете, какой трафик разрешен.

Быстрый старт WireGuard показывает базовую форму: создайте интерфейс, например wg0, назначьте IP-адреса и настройте сверстников с помощью wg.

Ключевое понятие для ограничения доступа — это AllowedIPs. В документации Red Hat WireGuard считывает IP-адрес назначения из пакета и сравнивает его со списком разрешенных IP-адресов; если сверстник не найден, WireGuard отбрасывает пакет.

Для хоста Ollama практическая интерпретация такова:

• Поместите хост в частную подсеть WireGuard.
• Привяжите Ollama либо к localhost и пересылите к нему, либо привяжите напрямую к IP WireGuard.
• Только сверстники, имеющие правильные ключи и AllowedIPs, могут маршрутизировать трафик к этому частному IP.

Это меньше движущихся частей, чем коммерческий оверлей, но это также означает, что вы несете ответственность за распределение ключей, жизненный цикл сверстников и то, как удаленные сверстники достигают вашей сети.

Фаервол разрешает только трафик интерфейса VPN или tailnet

Как фаервол может ограничить Ollama только трафиком интерфейса VPN? Цель — предотвратить случайное раскрытие даже в том случае, если адрес привязки становится шире, чем предполагалось.

Общий паттерн таков:

• Разрешать TCP-порт Ollama только на интерфейсе VPN (tailscale0 или wg0).
• Запрещать тот же порт везде остальном.
• Предпочесть политику «по умолчанию запретить входящие» если вы работаете таким образом для хоста.

Tailscale имеет явные рекомендации по использованию UFW для ограничения трафика, не относящегося к Tailscale, на сервере, что по сути является подходом «заблокировать всё, кроме tailnet».

Один нюанс, имеющий значение для Tailscale в частности, заключается в том, что ожидания хостового фаервола могут не соответствовать реальности, если вы предполагаете, что UFW заблокирует трафик tailnet. Проект Tailscale обсуждал, что он намеренно устанавливает правило для разрешения трафика на tailscale0 и полагается на фильтр, контролируемый ACL внутри tailscaled.

Это не аргумент против хостового фаервола. Это аргумент в пользу того, чтобы быть преднамеренным в отношении того, какая плоскость управления на самом деле обеспечивает политику. Если вы хотите, чтобы «только эти устройства могли достичь порта 11434», ACL Tailscale разработаны именно для этой задачи.

Если вы все же хотите контролировать уровень интерфейса на хосте, примеры обычно выглядят так:

# Логика в стиле UFW (иллюстративная)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Или для wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Даже если вы в основном полагаетесь на политику VPN, хостовый фаервол все еще предоставляет полезный «ремень безопасности» против ошибочной привязки к 0.0.0.0 или неожиданных обертывателей служб.

Необязательный обратный прокси только на входе VPN

Когда обратный прокси полезен для удаленного доступа к Ollama? Прокси полезен, когда вам нужны одно или несколько из следующих свойств:

• Стандартный шлюз аутентификации (базовая аутентификация, OIDC, клиентские сертификаты).
• Завершение TLS с сертификатом, которому доверяют клиенты.
• Ограничения запросов и таймауты.
• Более чистые URL для инструментов, которые не любят сырые порты.

Здесь намерение «не публиковать в интернет» должно оставаться истинным: обратный прокси доступен только через VPN, а не на публичном интерфейсе WAN.

Нужен ли TLS, когда трафик уже проходит через VPN? Не всегда для криптографии, но часто для удобства. Tailscale указывает, что соединения между узлами уже зашифрованы end-to-end, но браузеры об этом не знают, потому что они полагаются на TLS-сертификаты для установления доверия HTTPS.

Если вы находитесь в мире Tailscale, вы можете включить сертификаты HTTPS для вашего tailnet, что требует MagicDNS и явно указывает, что имена машин и имя DNS tailnet будут опубликованы в публичном реестре (журналы прозрачности сертификатов).

Деталь публичного реестра — это не причина избегать TLS, но это причина называть машины как взрослые (избегайте включения частных названий проектов или идентификаторов клиентов в именах хостов).

Эта статья намеренно не включает полную конфигурацию обратного прокси (см. вашу статью A1 для этого). Единственная идея, которая имеет значение здесь, — это размещение:

• Ollama слушает на localhost или IP VPN.
• Обратный прокси слушает только на интерфейсе VPN.
• Прокси пересылает запросы к Ollama.

Контрольный список безопасности для удаленного доступа к API Ollama

Это контрольный список, который я использую, чтобы «удаленный» не становился незаметно «публичным».

Привязка и доступность

• Убедитесь, что сервер слушает там, где вы думаете, что он слушает. Документированный стандарт — 127.0.0.1 и порт 11434, и OLLAMA_HOST изменяет это.
• Рассматривайте 0.0.0.0 как осознанный выбор, а не как переключатель удобства.
• Предпочитайте привязку к IP интерфейса VPN, когда он стабилен и соответствует топологии.

Контроль доступа

• Если вы используете Tailscale, реализуйте ACL, которые разрешают доступ к порту Ollama только конкретным пользователям или помеченным устройствам. ACL существуют для управления разрешениями устройств.
• Если вы используете WireGuard, держите AllowedIPs строгими и рассматривайте ключи как реальную границу идентификации. WireGuard отбрасывает пакеты, которые не соответствуют валидному сопоставлению AllowedIPs сверстника.

Фаервол

• Добавьте правило на уровне хоста, которое разрешает порт Ollama только на tailscale0 или wg0 и блокирует его везде остальном.
• Если вы ожидаете, что UFW заблокирует трафик tailnet, проверьте, как Tailscale взаимодействует с вашим фаерволом. Tailscale обсуждал разрешение трафика tailscale0 и полагается на фильтрацию ACL внутри tailscaled.

TLS и проксирование

• Используйте TLS, когда клиентами являются браузеры или когда инструменты ожидают HTTPS, даже если VPN уже шифрует транспорт. Tailscale документирует этот разрыв между шифрованием VPN и доверием браузера к HTTPS.
• Если вы включите сертификаты HTTPS Tailscale, помните о последствиях прозрачности сертификатов для имен хостов.
• Если вы добавите обратный прокси, держите его только в VPN и используйте его для аутентификации и ограничений, а не для экспозиции в интернет.

Избегайте случайной публичной экспозиции

• Остерегайтесь функций, явно разработанных для публикации служб в интернет. Tailscale Funnel маршрутизирует трафик из более широкого интернета к устройству tailnet, что не является безопасным по умолчанию путем для API Ollama.
• Если что-то оказывается доступным из интернета, не оставляйте анонимную поверхность /api. На этом этапе категории рисков OWASP API «ошибки конфигурации безопасности» и «потребление ресурсов» перестают быть теоретическими.

Наблюдаемость и контроль повреждений

• Логируйте запросы на уровне входа (журналы политики VPN, журналы прокси или оба).
• Добавьте ограничения запросов и параллелизма, если ваш прокси поддерживает их, потому что инференс модели — это событие потребления ресурсов, а не обычный API-вызов.

Последовательная тема — намеренная скучность: держите API Ollama приватным по умолчанию, добавьте приватный путь для удаленного доступа, а затем обеспечите эту политику дважды (идентичность VPN плюс хостовый фаервол), чтобы одна ошибка не превратилась в публичный конечный пункт.