Когда нужен свой relay-сервер, а когда нет

Вопрос про свой сервер задают чаще, чем он действительно нужен, и почти всегда в одной формулировке: «а развернуть у себя можно?». Можно. Но прежде чем разворачивать, стоит отделить желание держать инфраструктуру под рукой от требования, которое это желание оправдывает.

Какой запрет оправдывает свой сервер

Поводов звучит много, но проверку выдерживает один — письменный запрет выпускать трафик за периметр организации. Остальные обычно сводятся к ощущению контроля, за которое потом платит дежурный администратор.

• Регламент или политика безопасности прямо запрещает передавать служебные данные через внешние сервисы. Это требование, с ним не спорят.
• Сегмент сети изолирован и в интернет не выходит вовсе — тогда внешний ретранслятор недоступен физически, а не по регламенту.
• Заказчик требует, чтобы весь служебный трафик оставался в его дата-центре, и это записано в договоре.
• «Хочется, чтобы всё было своё» — не повод: у своего сервера появляются дежурство, обновления и ответственность за простой.

Если ни один из первых трёх пунктов не ваш, облачный ретранслятор обойдётся дешевле и предсказуемее. Что он делает с трафиком и где оседают данные сессий, описано на странице модели безопасности.

Что именно переносится на свой сервер

Главное недопонимание в этой теме — объём переносимого. Свой relay не становится точкой, через которую идёт весь удалённый доступ: прямые соединения между машинами его не касаются вовсе.

• Прямые P2P-сессии идут между устройствами и через ретранслятор не проходят — ни через облачный, ни через ваш.
• Relay включается, когда NAT не пускает машины друг к другу: например, при симметричном NAT мобильного оператора.
• Регистрация устройств и поиск по идентификатору — сигнальная часть, и она переезжает вместе с ретранслятором.
• При ретрансляции канал терминируется на сервере — именно поэтому организациям с запретом на внешний трафик и нужен свой.

Какой маршрут выбирается в каждом случае и как понять, по какому пошёл конкретный сеанс, разобрано в статье про маршрут удалённого сеанса. Сами термины собраны в глоссарии, в разделе о своём ретрансляторе.

Что нужно для запуска

Требования скромные, и это обманчиво: сервер поднимается за вечер, а живёт потом годами.

• Сервер с Docker и адресом, доступным вашим устройствам.
• Открытые порты 21115–21117, причём 21116 — и по TCP, и по UDP.
• Два сервиса: сигнальный hbbs и собственно ретранслятор hbbr. Оба поднимаются одним docker-compose.
• Место под служебные данные: оба сервиса держат состояние в примонтированном каталоге.

Готовый docker-compose и порядок запуска лежат на странице своего relay-сервера. Серверная часть — форк rustdesk-server под AGPL-3.0, поэтому можно не верить описанию, а прочитать код и проверить, что ретранслятор делает с трафиком.

Что меняется у пользователей

На стороне клиента изменение одно: в настройках указывается адрес вашего сервера в поле ID/Relay. Ни роутер, ни входящие порты на машинах сотрудников при этом настраивать не нужно — устройства сами регистрируются на вашем сервере и через него же ретранслируются.

Зато появляется зависимость, которой раньше не было. Пока сервер жив, всё работает как прежде; когда он недоступен, устройства не находят друг друга — и это уже ваш инцидент, а не чужой. Поэтому в небольшой команде свой ретранслятор обычно выходит дороже, чем кажется на старте: платят не деньгами, а дежурством.

Если выбор между своим и облачным ретранслятором делается при внедрении, его полезно задать вместе с остальными пунктами из списка вопросов поставщику — там же про лимиты и условия, которые обнаруживаются уже после подписания.

Когда свой relay не нужен

Три ситуации, в которых затея добавит работы и не решит ни одной задачи:

• Сеансов мало и они короткие. Доля ретранслированных подключений в небольшой команде обычно невелика, а администрировать сервер придётся постоянно.
• Нет дежурного. Сервер без владельца тихо ломается, и обнаруживается это в худший момент — когда до машины нужно добраться срочно.
• Цель — скорость. Свой ретранслятор не ускоряет сеанс: быстрее всего работает прямое соединение, и его добиваются настройкой сети, а не переносом relay.

Условия и объёмы облачного ретранслятора по тарифам перечислены на странице тарифов. Если прямые соединения не складываются и сеансы постоянно уходят на ретранслятор, начинать нужно не с сервера, а с сети — об этом статья про доступ без VPN и белого IP.