Развёртывание шлюза в режиме forward proxy

Forward-шлюз поставляется отдельным Docker-образом: в нём нет пользовательского портала, vLLM и Nginx — только процесс прозрачного прокси. Всю конфигурацию (политики, Пути, режим аутентификации, CA-сертификат перехвата, параметры цепочного прокси) шлюз получает из Core.

Создайте объект Шлюз в режиме forward

В интерфейсе StarGuard Base создайте шлюз, выберите режим Forward proxy, задайте CA-сертификат и приватный ключ перехвата, привяжите Пути (Управление шлюзами). Скопируйте UUID шлюза.

Задайте переменные окружения

Переменная Описание

Переменная	Описание
`CORE_URL`	URL платформы управления StarGuard Base
`CORE_TOKEN`	UUID шлюза, созданного в интерфейсе Base в режиме forward
`CORE_API_KEY`	API-токен для аутентификации в Base API
`LISTEN_HOST`, `LISTEN_PORT`	Адрес и порт, на которых прокси принимает подключения (по умолчанию `0.0.0.0:8080`)
`FORWARD_CONFDIR`	Рабочий каталог прокси, в который при каждом старте записывается CA-сертификат перехвата, полученный из Core
`FILE_RECOGNIZER_URL`	Адрес уже развёрнутого сервиса File Recognizer (опционально, для обработки вложений)
`FILE_RECOGNIZER_SERVICE_TOKEN`	Общий секрет для обращения к File Recognizer
`JWKS_VERIFY_X509_STRICT`	Строгая проверка сертификата JWKS-эндпоинта OIDC-провайдера. Установите `false` для провайдеров, чьи сертификаты не содержат Authority Key Identifier
`SSL_CERT_FILE`	Путь к корневому сертификату корпоративного TLS-инспектора (опционально)
`LOG_LEVEL`	Уровень логирования

CORE_URL

URL платформы управления StarGuard Base

CORE_TOKEN

UUID шлюза, созданного в интерфейсе Base в режиме forward

CORE_API_KEY

API-токен для аутентификации в Base API

LISTEN_HOST, LISTEN_PORT

Адрес и порт, на которых прокси принимает подключения (по умолчанию 0.0.0.0:8080)

FORWARD_CONFDIR

Рабочий каталог прокси, в который при каждом старте записывается CA-сертификат перехвата, полученный из Core

FILE_RECOGNIZER_URL

Адрес уже развёрнутого сервиса File Recognizer (опционально, для обработки вложений)

FILE_RECOGNIZER_SERVICE_TOKEN

Общий секрет для обращения к File Recognizer

JWKS_VERIFY_X509_STRICT

Строгая проверка сертификата JWKS-эндпоинта OIDC-провайдера. Установите false для провайдеров, чьи сертификаты не содержат Authority Key Identifier

SSL_CERT_FILE

Путь к корневому сертификату корпоративного TLS-инспектора (опционально)

LOG_LEVEL

Уровень логирования

Запустите контейнер

Прокси открывает слушающий сокет только после того, как успешно получит конфигурацию из Core.
Настройте клиентов

На стороне клиента указывается адрес прокси и, при включённой на шлюзе авторизации, учётные данные:
```
export HTTPS_PROXY=http://<имя пользователя>:<токен>@<адрес шлюза>:8080
export HTTP_PROXY=$HTTPS_PROXY
```
Клиент продолжает обращаться к реальному адресу провайдера и передавать свой ключ доступа к LLM — шлюз их не изменяет.

Установите CA-сертификат перехвата

Для перехвата TLS клиенты должны доверять CA-сертификату, заданному в настройках шлюза. Сертификат добавляется в системное хранилище доверенных корневых сертификатов на рабочих местах и серверах, которые ходят через прокси.

Внимание. Если CA-сертификат и приватный ключ в Core не заданы, контейнер стартует, но перехват TLS не работает: прокси использует самоподписанный сертификат, которому клиенты не доверяют.

Только HTTPS. При включённой на шлюзе настройке «Только HTTPS» запросы, пришедшие открытым текстом, отклоняются с кодом 403. Учётные данные прокси, отправленные клиентом по HTTP до включения настройки, следует считать скомпрометированными и заменить.