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

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

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

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

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

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

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

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

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

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

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

Источник	Назначение	Когда требуется
Пользователь/браузер	Gateway HTTPS	Console, REST, OAuth, MCP, WebSockets, Inference
Управляемая нода	Назначенный Relay `9443/tcp`	Всегда для управляемого контроля и поддерживаемых туннелей
Интернет/клиент	Ingress `80/tcp`	HTTP Route или ACME HTTP-01
Интернет/клиент	Ingress `443/tcp`	HTTPS Routes и Pages
Gateway/нода	Адреса DNS и обновлений	Разрешение имён и загрузка подписанных обновлений
Gateway/Build Worker	Поставщики Git и реестра	Обнаружение источника, входные данные сборки, отправка и получение образов
Gateway	Поставщики OIDC, SMTP, DNS, вебхуков, SIEM и AI	Только для включённой интеграции
Клиент приложения	Опубликованный TLS-порт базы данных	Только когда прямой доступ включён намеренно

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

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

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

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

Проверка

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

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

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

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

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

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

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

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