Начните со скачивания клиента на машину, которая уже имеет прямой доступ к защищенному сервису. Регистрация, вход по ключу доступа и настройка маршрутов начинаются прямо в клиенте.
Быстрый старт
Самый короткий путь от нуля до рабочего сервисного туннеля.
Зарегистрируйтесь по email, получите ключ доступа и затем используйте этот ключ в клиенте. Ключ связывает пользователя, маршруты, владение узлами и состояние подписки.
Когда публикующая сторона уже готова, скачайте и установите клиент на машину, где реально работает потребляющее приложение.
На публикующей машине создайте маршрут Publish к реальной внутренней конечной точке. На машине-потребителе создайте маршрут Listen, который привязывает локальный порт к тому же ключу маршрута.
Публикующий узел: Publish Ключ маршрута: exchange-main Целевой хост: exchange.internal.local Целевой порт: 443 Потребляющий узел: Listen Ключ удаленного маршрута: exchange-main Локальный хост: 127.0.0.1 Локальный порт: 8443
Базовые сущности
Вот сущности, которые важны при проектировании развертывания.
Публичный ретранслятор и плоскость управления. Здесь живут состояние доступа пользователей, версии, определения маршрутов, видимость сессий и операции дашборда.
Идентичность машины. Маршруты остаются привязанными к идентификатору узла, потому что именно они описывают, что эта машина стабильно может публиковать или потреблять.
Конкретный запущенный экземпляр клиента на машине. Под одним ключом доступа может существовать несколько экземпляров приложения, но это все равно просто экземпляры поверх одного или нескольких узлов.
Именованный сервисный путь. Публикующие маршруты объявляют реальные внутренние цели. Потребляющие маршруты слушают локально и указывают на ключ публикующего маршрута.
Общий паттерн маршрутизации
Почти каждое удачное развертывание следует одной и той же последовательности.
1. Скачайте и установите клиента на машину, которая уже имеет прямой доступ к защищенной цели. 2. Опубликуйте цель под стабильным ключом маршрута. 3. Скачайте и установите клиента на машину, где работает реальное потребляющее приложение. 4. Поднимите локальную точку прослушивания на том хосте и порту, которые приложение уже ожидает. 5. Направьте потребляющее приложение на локальную точку прослушивания вместо исходной недоступной конечной точки.
Называйте по смыслу сервиса, а не по временным деталям инфраструктуры. exchange-main лучше, чем server42-prod-a.
Используйте понятные локальные порты и фиксируйте их в конфигурации приложения, чтобы операторы точно видели, что и куда отображено.
Публикующие узлы должны быть рядом с защищенным ресурсом. Потребляющие узлы — рядом с реальным пользовательским сценарием или нагрузкой.
Если приложению нужен только один точный сервис, публикуйте один точный сервис. Избегайте широких обходных путей удаленного доступа, если задача действительно этого не требует.
Типовые сценарии
Это самые частые паттерны, в которых StreamGate подходит лучше, чем VPN или одноразовый проброс.
Outlook / Exchange / Autodiscover
Используйте публикующий узел рядом с Exchange и потребляющий узел на рабочей станции. Точка прослушивания дает Outlook доступную локальную конечную точку для того Exchange-пути, который он ожидает.
- Опубликуйте Exchange или Autodiscover с узла внутри почтовой среды.
- Поднимите точку прослушивания на машине пользователя с ожидаемым переопределением хоста или локальным proxy-маппингом.
- Направьте почтовый клиент или переопределение хоста на локальную точку прослушивания StreamGate.
Jira / Confluence / внутренние порталы
Когда браузеру или интеграционному инструменту нужна только конкретная HTTPS-конечная точка, публикуйте внутренний портал со стороны публикующего узла и слушайте локально со стороны потребляющего узла.
- Provider target:
jira.internal.local:443 - Consumer listener:
127.0.0.1:9443 - Цель для приложения или браузера: локальный порт или локальный обратный прокси перед ним
SQL Server / PostgreSQL / Redis
Идеально для настольных инструментов, утилит миграции и BI-клиентов, которым нужен один порт базы данных, а не членство во всей сети.
- Опубликуйте порт базы данных на машине, которая уже имеет приватный доступ к базе.
- Поднимите точку прослушивания локально там, где работает инструмент.
- Оставьте учетные данные и конфигурацию приложения без изменений, кроме хоста и порта конечной точки.
RDP / SSH / maintenance
Используйте StreamGate, когда нужен узкий путь обслуживания к одному хосту без одобрения широкой среды удаленного доступа.
- Публикующий узел объявляет сервисный порт обслуживания приватного хоста.
- Потребляющая сторона слушает локально и подключается обычными RDP- или SSH-инструментами.
- Оператор потом может удалить маршрут и аккуратно закрыть этот путь.
Private APIs and webhook consumers
Полезно, когда внутренняя API должна быть доступна только с очень конкретного worker'а или рабочей станции.
- Опубликуйте API изнутри приватной среды.
- Поднимите точку прослушивания на сборочном узле, задаче синхронизации или интеграционном хосте, которому это нужно.
- Оставьте API приватной и сервисно-ограниченной, а не открывайте целый сетевой коридор.
CI/CD, artifact stores and license servers
Сборочным узлам часто нужна всего одна защищенная зависимость. StreamGate позволяет сборочному узлу видеть ее локально, не превращая его в постоянный доверенный сетевой остров.
- Publish: реестр артефактов, сервер лицензий, зеркало пакетов
- Listen: локальная конечная точка на сборочном узле
- Используйте обычные клиентские инструменты против локальной конечной точки
Эксплуатация и обновления
Как ведет себя плоскость управления, когда модель маршрутов уже работает.
Сервер объявляет текущий обслуживаемый пакет клиента. Подключенные клиенты узнают о новых версиях через ретранслятор, а не через агрессивный опрос.
Сервер хранит каталог версий, умеет переключать версии и при установке как служба Windows может обновлять целевой путь службы на новый версионированный исполняемый файл.
Маршруты, узлы, сессии и лимиты приложений привязаны к владельцу ключа доступа. Каждый пользователь видит и использует только свои данные.
Маршруты остаются привязанными к идентичности узла, поэтому машина сохраняет владение своей сервисной картой, даже если на ней со временем запускается несколько экземпляров приложения.
Заметки по безопасности
Логика безопасности должна совпадать с логикой маршрутизации.
Узлы используют одну стабильную защищенную точку входа в сервер. Ретранслятор остается единственным публичным узлом плоскости управления, который нужно выставлять наружу.
После поднятия внешнего TLS-соединения StreamGate все равно выполняет собственное аутентифицированное установление сессии до начала переключения кадров данных.
Ретранслятор может отклонять отсутствующие, истекшие, заблокированные или отозванные ключи доступа и направлять потоки продления через портал подписки.
Архитектура намеренно остается сервисно-ограниченной. В этом и состоит ключевое отличие от традиционных инструментов удаленного доступа на всю сеть.
Диагностика проблем
Вот с чего стоит начать, если маршрут ведет себя не так, как вы ожидаете.
Клиент подключается, но приложение все равно не видит сервис.
Проверьте локальный хост и порт точки прослушивания, убедитесь, что ключ маршрута совпадает у публикующей и потребляющей стороны, и подтвердите, что публикующий узел действительно достает до защищенной цели напрямую со своей машины.
Публикующий узел в сети, но сессия не открывается.
Убедитесь, что publish-маршрут существует на правильном узле, пользователь владеет обеими сторонами маршрута, а потребляющая сторона слушает тот же ключ удаленного маршрута.
Потребляющее приложение работает только пока клиент на переднем плане.
Используйте сборку клиента с режимом работы в системном трее, держите узел подключенным и не закрывайте приложение полностью, если маршрут должен жить в фоне.
Обновление клиента доступно, но появляется не сразу.
Подключенные клиенты узнают о новых пакетах из снимка состояния ретранслятора. Если клиент офлайн, ручной путь Check по-прежнему доступен, но на более редком интервале.