Порты и сетевые пути

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

Целевая схема по умолчанию проста: пользователи обращаются к Opfield и публичному Ingress по HTTPS; управляемые ноды инициируют исходящие аутентифицированные соединения с Relay; внутренние базы данных и управляющие интерфейсы остаются приватными. Открывайте дополнительные пути только для документированной функции продукта.

Краткая схема связности

Путь	Назначение
Клиент -> Opfield HTTPS	Console, REST, OAuth, MCP, WebSockets, прокси Opfield Inference
Управляемый демон -> Relay 9443/tcp	Аутентифицированное исходящее управление и поддерживаемый туннельный трафик
Интернет -> nginx 80/tcp	HTTP и ACME HTTP-01, где они используются
Интернет -> nginx 443/tcp	Публичные HTTPS Routes и Pages
Opfield/демон -> внешние поставщики	DNS, OIDC, электронная почта, Git, реестры, обновления, ACME и поставщики AI
Внутренние службы Opfield	PostgreSQL, Redis, внутренний gRPC и обратные вызовы ядра Opfield Inference

Публичным владельцем 9443/tcp является Relay, а не приложение Opfield. Opfield не открывает межсетевые экраны хостов и не обеспечивает обход NAT. Удалённые обработчики Relay должны объявлять адреса контура данных, доступные назначенным управляемым хостам.

Сохраняйте приватными PostgreSQL, Redis, внутренний gRPC, ядро Opfield Inference, порты владельца базы данных, управляющие интерфейсы демона и отдельные Docker-сети привязок.

Направление соединений

Управляемые службы демона инициируют исходящие аутентифицированные соединения с Relay. Обычно операторам не требуется открывать управляющие порты демона для Opfield. Исключение — удалённые обработчики Relay: объявленный ими адрес 9443/tcp должен быть доступен назначенным управляемым хостам.

Ноды Ingress принимают публичный трафик приложений на портах 80 и 443 в соответствии с требованиями Route и ACME. Для Secure Links на нодах Docker и нодах хранилища не требуется открывать публичные порты рабочих нагрузок или владельца базы данных. Публикация адреса управляемой базы данных включается явно и должна ограничиваться отдельно.

Планирование межсетевого экрана

Источник	Назначение	Когда требуется
Пользователь/браузер	Opfield HTTPS	Console, REST, OAuth, MCP, WebSockets, Inference
Управляемая нода	Назначенный Relay 9443/tcp	Всегда для управляемого контроля и поддерживаемых туннелей
Нода Docker политики Availability в режиме аренды и нода Ingress её Routes	Каждый Relay пула, по умолчанию 9443/tcp	Переключение на уровне данных: трафик аренды и Secure Links участников идут через все Relay
Интернет/клиент	Ingress 80/tcp	HTTP Route или ACME HTTP-01
Интернет/клиент	Ingress 443/tcp	HTTPS Routes и Pages
Opfield/нода	Адреса DNS и обновлений	Разрешение имён и загрузка подписанных обновлений
Opfield/Build Worker	Поставщики Git и реестра	Обнаружение источника, входные данные сборки, отправка и получение образов
Opfield	Поставщики OIDC, SMTP, DNS, вебхуков, SIEM и AI	Только для включённой интеграции
Клиент приложения	Опубликованный TLS-порт базы данных	Только когда прямой доступ включён намеренно
Opfield	Служба лицензирования license.thesqlabs.com по HTTPS	Регистрация и контрольные сигналы; активация платного ключа; обновления Opfield на установке, у которой есть или был платный тариф (установки Community без ключа обновляются и при недоступной службе)
Клиент хранилища	S3-порт управляемого хранилища (по умолчанию 9000)	Только когда публикация включена намеренно
Нода хранилища	ghcr.io, при неудаче — Docker Hub	Загрузка образов управляемых баз данных и хранилищ; исполнитель резервного копирования загружается только с ghcr.io
Нода Docker	ghcr.io, при неудаче — Docker Hub	Загрузка закреплённой среды выполнения Compose
Нода хранилища, выполняющая резервное копирование	Внешние базы данных, адреса хранилищ и ghcr.io	Резервное копирование и восстановление баз данных
Внешний Redis — цель восстановления	Служебный IP-адрес исполнителя, TCP 20000–39999	Только во время восстановления во внешний Redis
Внешний сервер ClickHouse	Промежуточный адрес S3	Резервное копирование и восстановление внешнего ClickHouse

По возможности используйте списки разрешений поставщика и политику исходящего трафика, учитывая проверку сертификатов, перенаправления, DNS и адреса пакетов или реестра, необходимые выбранной функции. Не применяйте широкое правило «разрешить всё», чтобы скрыть невыясненную зависимость.

Выбор адресов

Opfield записывает сообщённые локальные и публичные адреса, а также служебные адреса отдельных ролей. Выбирайте их по фактическому пути участников: публичные клиенты обращаются к Ingress, управляемые хосты — к Relay, межузловые операции Docker — к доступным служебным адресам, а сертификаты баз данных должны соответствовать опубликованным служебным IP-адресам.

Изменение адреса может потребовать обновить DNS, заменить сертификат, перенести Route или перераспределить Relay. До удаления старого пути проверьте каждого участника соединения.

Проверка

Проверяйте соединение из фактической исходной сети, а не только с целевого хоста. Подтвердите DNS, доступность TCP, идентичность TLS, работу HTTP или gRPC и состояние, которое сообщает Opfield. Одно успешное TCP-соединение не доказывает аутентификацию или готовность приложения.

Изменение и откат

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

Для отката восстановите прежние адрес, значение DNS, сертификат или назначение как одно согласованное изменение. Не переключайте конфигурации туда и обратно, пока действуют кэши и долговременные соединения. После отката проверьте сеансы Relay, свежесть нод, Routes, Pages, привязки баз данных, вебхуки и исходящий доступ к источникам и поставщикам, используемым установкой.

Диагностика оператора

Проверяйте каждый слой из фактической исходной сети:

1. DNS возвращает ожидаемый адрес.
2. Сетевой путь и межсетевой экран разрешают документированный порт назначения.
3. TLS предъявляет ожидаемую идентичность и доверенную цепочку.
4. Протокол приложения успешно проходит аутентификацию или проверку состояния.
5. Opfield получает свежее состояние от владельца ресурса.

Сигналом служит первый слой, на котором проверка не проходит. Для DNS и межсетевого экрана владельцем является сетевая сторона; для TLS — владелец Domain или сертификата; для протокола — владелец приложения; для устаревшего состояния — владелец соответствующего Relay, ноды или Route. Проверьте страницу этого ресурса в Opfield, связанную Task и её журналы, если изменение выполнялось как операция. Исправляйте только подтверждённый слой и повторяйте проверку из исходной сети; открытие дополнительных портов не устраняет ошибку сертификата, авторизации, политики или готовности приложения.