> Markdown-версия страницы https://tuna.am/blog/tuna-mesh-beta/. Оглавление документации — [llms.txt](https://tuna.am/llms.txt), весь текст одним файлом — [llms-full.txt](https://tuna.am/llms-full.txt). Markdown-версия есть у любой страницы: добавьте `.md` к адресу без слеша на конце.

[Блог](https://tuna.am/blog.md)|[Новые возможности](https://tuna.am/blog/tags/features)

# Tuna Mesh в бете — частная сеть для устройств

4 ноября · 11 мин

> **Бета.** Tuna Mesh пока в бете, и в стабильности его работы мы ещё не уверены. Доступ включаем по запросу: напишите в [поддержку](https://tuna.am/docs/support.md). Пробуйте, а если что-то пойдёт не так, расскажите нам: так вы поможете с отладкой.

Туннель хорош, когда нужно показать один сервис наружу: сайт заказчику, вебхук платёжной системе, API коллеге. Но часто нужно другое: зайти по SSH на сервер в офисе, подключиться к базе на стенде или открыть NAS из дома, и чтобы при этом ничего не торчало в интернет.

Для этого мы сделали Tuna Mesh, частную сеть между устройствами команды. Он в бете, и с этого релиза им можно управлять в личном кабинете. Идею мы подсмотрели у Tailscale и NetBird, но архитектуру в итоге выбрали свою. Ниже расскажем, почему.

Сразу оговоримся: Tuna Mesh — не VPN в бытовом смысле слова и не сервис для обхода блокировок, рассматривать его так не стоит. Своей инфраструктуры для выхода трафика в интернет мы не даём. Мы только соединяем устройства пользователя в зашифрованную частную сеть, как это делает корпоративный VPN. Сами мы относим такие сети к классу NGVPN (New Generation Virtual Private Network): это частная сеть корпоративного уровня или доступ к своим устройствам в локальных сетях. Чтобы Tuna Mesh не путали с VPN-сервисами, дальше и в документации мы называем его просто mesh-сетью.

![Анимация: ноутбук, офисный сервер и база подключены к ноде Tuna Mesh; SSH на офисный сервер проходит через межсетевой экран команды, подключение к базе правила отбрасывают, а устройство другой команды упирается в границу своей изолированной сети](/blog/img/2026-11-04-tuna-mesh-beta/how.svg)

Каждый пакет проходит через сеть вашей команды на ноде, и там его проверяет межсетевой экран.

> **Коротко**
>
> * Устройства команды получают постоянные адреса и DNS-имена вида `office-gw.tuna`. Публичный IP, открытые порты и настройка роутера не нужны.
> * Трафик идёт через ноды Tuna. Там у каждой команды своя изолированная сеть и свой межсетевой экран, и обойти его с устройства нельзя.
> * По умолчанию данные идут по WireGuard. Если провайдер его режет, клиент сам переходит на SSH.
> * Точка выхода выпускает трафик в интернет через устройство команды, а раздача подсетей открывает доступ к сети в офисе или облаке без отдельного VPN-сервера.

## Как это работает

Устройства в Tuna Mesh не соединяются друг с другом напрямую. Каждое держит один зашифрованный канал до ближайшей ноды tuna-mesh, а дальше трафик идёт через наши ноды. Если нода выходит из строя, клиент за несколько секунд переключается на соседнюю, а адрес устройства остаётся прежним.

Каждое устройство получает постоянный адрес из `100.100.0.0/16` и DNS-имя по hostname: `office-gw.tuna`, `prod-db-1.tuna`. По этим адресам устройства обращаются друг к другу по любым протоколам и портам:

```shell
ssh ubuntu@office-gw.tuna
psql -h prod-db-1.tuna -U app

```

Снаружи к устройствам не попасть: в сети видны только устройства вашей команды.

## Изоляция и межсетевой экран на нашей стороне

На каждой ноде у команды своё сетевое пространство имён Linux (network namespace). Это отдельный сетевой стек со своими интерфейсами, маршрутами и правилами. Сети разных команд разделены на уровне ядра, поэтому пакет из чужой команды до вашей сети не дойдёт, даже если адреса совпадают: диапазон `100.100.0.0/16` у всех команд один.

Правила доступа работают как межсетевой экран внутри этого пространства имён. Пакет, который правила не пропускают, отбрасывается на ноде и до получателя не доходит. Важно, где именно стоит проверка. В Tailscale и NetBird правила применяет [само](https://tailscale.com/docs/features/access-control/acls) [устройство](https://docs.netbird.io/about-netbird/how-netbird-works), поэтому их может отключить тот, у кого на нём есть права root. У нас межсетевой экран работает на ноде, к которой у устройства доступа нет, и с устройства его не обойти.

У этой схемы есть ещё одно следствие: отозванное устройство теряет доступ сразу. Нода обрывает его сессию, и пакеты от него никуда не идут.

## Надёжность и безопасность важнее скорости

Tailscale и NetBird в первую очередь стараются соединить устройства напрямую, по WireGuard из точки в точку, а через свои релеи пускают трафик, только если прямой путь не нашёлся. Когда прямой путь есть, задержка минимальная. Мы сознательно выбрали другую схему: трафик всегда проходит через ноду. Это лишний участок пути и чуть большая задержка. Взамен мы получаем межсетевой экран, который нельзя обойти с устройства, изоляцию команд, мгновенный отзыв устройств и сеть, которая не зависит от того, пропускает ли провайдер WireGuard.

В России последнее особенно важно. Разработчики WireGuard прямо [пишут](https://www.wireguard.com/known-limitations/), что не прячут протокол от анализа трафика, а его служебные пакеты легко узнать по фиксированному формату. ТСПУ этим пользуются: WireGuard [входит](https://ru.themoscowtimes.com/2026/01/07/v-kremle-reshili-poka-ne-zapreschat-rossiyanam-polzovatsya-vpn-servisami-a184142) в число протоколов, которые блокируют с осени 2025 года, а в 2026 году соединения по нему по-прежнему [обрывают](https://habr.com/ru/articles/1047442/) по сигнатуре первого пакета. Сильнее всего страдают соединения с зарубежными серверами, но и внутри России WireGuard работает с перебоями: [жалуются](https://habr.com/ru/companies/femida_search/articles/987190/comments/) пользователи мобильных операторов и региональных провайдеров. Мы видели это и на своих серверах: в некоторых региональных дата-центрах в России WireGuard устанавливает соединение, а потом провайдер режет UDP-трафик по объёму.

Пользователи Tailscale и NetBird просят добавить маскировку трафика, потому что [в России WireGuard периодически блокируют](https://github.com/tailscale/tailscale/issues/13119) и [его легко обнаружить](https://github.com/netbirdio/netbird/issues/1096), но встроенного решения пока нет. А в октябре 2024 года Tailscale на время [сама закрыла доступ](https://github.com/tailscale/tailscale/issues/13648) пользователям из России. Ограничение откатили, но предупредили, что по требованиям закона его придётся вернуть.

## WireGuard по умолчанию, SSH в запасе

Чтобы сеть оставалась доступной и при таких блокировках, у клиента два транспорта.

![Анимация: трафик идёт от устройства к ноде Tuna по WireGuard; провайдер начинает резать WireGuard, пакеты теряются; клиент переходит на SSH, и трафик идёт дальше, а адрес устройства не меняется](/blog/img/2026-11-04-tuna-mesh-beta/transport.svg)

Если WireGuard перестаёт проходить, клиент переходит на SSH. Адрес устройства и DNS-имена при этом не меняются.

* **WireGuard** работает по умолчанию, это самый быстрый из двух транспортов.
* **SSH** включается, когда WireGuard деградирует. Клиент регулярно проверяет, проходят ли данные, и если нет, переподключается по SSH. Это обычный TCP-трафик, такой же, как при администрировании серверов. Позже клиент снова пробует WireGuard.

SSH медленнее WireGuard, но сеть при переходе не пропадает. Вот наши замеры `iperf3` между двумя устройствами на тестовом стенде в апреле 2026 года: ноды с 2 vCPU и каналом 1 Гбит/с, задержка между нодами около 5 мс.

| Путь трафика                 | WireGuard         | SSH          |
| ---------------------------- | ----------------- | ------------ |
| Оба устройства на одной ноде | на скорости линка | \~290 Мбит/с |
| Устройства на разных нодах   | \~480–490 Мбит/с  | \~63 Мбит/с  |

Сильнее всего SSH проседает на каналах с большой задержкой и потерями. Внутри SSH идёт TCP поверх TCP, и каждая потеря пакета тормозит весь поток. Поэтому SSH у нас запасной транспорт, а не основной.

## Подключение в 2 клика

На устройство нужно поставить tuna и службу `tunad`, она настраивает сетевой интерфейс. Как это сделать на Linux, macOS и Windows, описано в [документации](https://tuna.am/docs/mesh.md#install). Потом на рабочем компьютере выполните:

```shell
tuna mesh login
tuna mesh up

```

Первая команда откроет браузер, где нужно подтвердить устройство. Вторая подключит его к сети.

На серверах и в CI браузера нет, поэтому для них есть токены подключения. Токен создаётся в кабинете на срок от часа до суток и подключает до 10 устройств:

```shell
tuna mesh enroll <токен>
tuna mesh up

```

Синтаксис команд на время беты может поменяться, актуальный вариант всегда в [документации](https://tuna.am/docs/mesh.md).

## Точки выхода

Устройство на Linux или macOS может стать точкой выхода: пропускать через себя интернет-трафик других устройств команды. Сайты и сервисы видят вас с её IP-адреса. Точка выхода — всегда устройство вашей команды: своих серверов для выхода в интернет мы не даём. Точки выхода и раздача подсетей есть и у Tailscale, и у NetBird, так что если вы ими пользовались, здесь всё будет знакомо.

![Анимация: напрямую ноутбук не может открыть CRM, которая пускает только IP офиса; после tuna mesh up --exit-node=office-gw трафик идёт через ноду Tuna и офисный компьютер и выходит в интернет с IP офиса](/blog/img/2026-11-04-tuna-mesh-beta/exit-node.svg)

Точка выхода в офисе: из дома или из кафе сервисы видят вас с IP офиса.

Когда это пригодится:

* **Сервисы с доступом по белому списку IP.** CRM, админка, облачная консоль или база заказчика пускают только с IP офиса. Поставьте точку выхода на компьютер в офисе, и с ноутбука из дома доступ будет таким же, как с рабочего места.
* **Интернет из другой страны.** Точка выхода на сервере в нужной стране покажет сайт, рекламу или платёжную форму так, как их видят местные пользователи.
* **Публичный Wi-Fi.** В кафе, отеле или аэропорту весь трафик до точки выхода зашифрован.

Чтобы раздать точку выхода, выполните на устройстве, через которое пойдёт трафик:

```shell
tuna mesh up --advertise-exit-node

```

А на своём устройстве выберите её:

```shell
tuna mesh up --exit-node=office-gw

```

Через точку выхода не обязательно пускать весь трафик. Можно выпускать через неё только трафик в одну страну, или наоборот, отправлять трафик в одну страну напрямую, а остальной через точку выхода. С флагом `--fallback-to-direct` трафик идёт напрямую, пока точка выхода недоступна. Трафик в локальную сеть, в которой вы находитесь, в любом случае идёт мимо точки выхода.

Кто может пользоваться точкой выхода, решает её владелец: вся команда, отдельные устройства или только его собственные. Подробнее — в разделе [Точки выхода и подсети](https://tuna.am/docs/mesh/exit-nodes.md).

## Доступ к сети в офисе или облаке

Второй режим — раздача подсетей. Устройство открывает доступ к локальной сети, в которой стоит, и ставить клиент на каждый хост в ней не нужно.

![Анимация: сервер cloud-gw в облаке раздаёт приватную подсеть 10.0.0.0/24; разработчики и CI через ноду Tuna ходят к Postgres, Kubernetes API и Grafana по их внутренним адресам](/blog/img/2026-11-04-tuna-mesh-beta/subnets.svg)

Один сервер с tuna в облаке открывает команде всю приватную сеть.

Например, у вас в облаке приватная сеть с базой, Kubernetes API и мониторингом, и наружу у них ничего не торчит. Обычно для доступа туда поднимают VPN-сервер или bastion-хост и раздают разработчикам конфиги. С Tuna Mesh достаточно поставить tuna на одну виртуальную машину в этой сети:

```shell
# на виртуальной машине в облаке
tuna mesh up --advertise-routes=10.0.0.0/24

# у разработчика — подсеть подключится сама
psql -h 10.0.0.5 -U app
curl http://10.0.0.20:3000/api/health

```

Так же работает офисная сеть: один компьютер в офисе открывает коллегам принтеры, NAS и серверы. Хосты в сети видят подключения с адреса раздающего устройства, поэтому прописывать на них обратные маршруты не нужно. Правила доступа действуют и здесь: на тарифе «Легенда» подсеть можно открыть разработчикам, а CI пустить только к Kubernetes API.

## Правила доступа

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

Перед тем как сохранять правило, его можно проверить на вкладке **Проверить доступ**: кабинет покажет, пропустят ли правила соединение и какое из них сработает.

## Для администраторов команды

В разделе **Команда → Mesh** собраны все устройства команды: кто владелец, когда устройство было в сети, через что оно подключено. Любое устройство можно отозвать, и сессия оборвётся сразу. Там же видны все токены подключения и точки выхода команды.

## Тарифы

| Тариф   | Устройств на участника | Раздавать точки выхода и подсети | Свои правила доступа |
| ------- | ---------------------- | -------------------------------- | -------------------- |
| Новичок | 5                      | нет                              | нет                  |
| Профи   | 10                     | да                               | нет                  |
| Легенда | 100                    | да                               | до 100 правил        |

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

Лимиты пока не окончательные. Скорее всего, к выходу из беты мы их заметно расширим: хотим, чтобы по условиям Tuna Mesh был выгоднее Tailscale и NetBird.

## Как попробовать

Tuna Mesh в бете и включается для команды по запросу. Напишите в [поддержку](https://tuna.am/docs/support.md), и в боковой панели кабинета появится раздел **Mesh**.

Это бета, поэтому есть ограничения: точку выхода выбирают вручную, раздавать её можно только с Linux и macOS, а имя устройства берётся из hostname. Полный список — в [документации](https://tuna.am/docs/mesh.md#limitations). Если что-то работает не так или не хватает функции, напишите нам: от ваших отзывов зависит, что мы сделаем дальше.

## Оставьте отзыв

Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем-либо, то пожалуйста [оставьте отзыв](https://my.tuna.am/?show_feedback=1&lang=ru).

![](/blog/img/2024-08-22/feedback.gif)

## Новости

Анонсы новых функций и статей публикуем в [Telegram-канале](https://t.me/tuna_am). Подписывайтесь, чтобы ничего не пропустить.

## Помощь

Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов:

* [Электронная почта](mailto:info@tuna.am)
* [Telegram сообщество](https://telegram.me/+Kgbtt0_gJwI5ZmEy)

Категории: [Новые возможности](https://tuna.am/blog/tags/features)

[старее →🔐 Запросы на изменение секретов — правка в prod через ревью](https://tuna.am/blog/secrets-change-requests.md)