Tuna Mesh в бете — частная сеть для устройств
Tuna Mesh пока в бете, и в стабильности его работы мы ещё не уверены. Доступ включаем по запросу: напишите в поддержку. Пробуйте, а если что-то пойдёт не так, расскажите нам: так вы поможете с отладкой.
Туннель хорош, когда нужно показать один сервис наружу: сайт заказчику, вебхук платёжной системе, API коллеге. Но часто нужно другое: зайти по SSH на сервер в офисе, подключиться к базе на стенде или открыть NAS из дома, и чтобы при этом ничего не торчало в интернет.
Для этого мы сделали Tuna Mesh, частную сеть между устройствами команды. Он в бете, и с этого релиза им можно управлять в личном кабинете. Идею мы подсмотрели у Tailscale и NetBird, но архитектуру в итоге выбрали свою. Ниже расскажем, почему.
Сразу оговоримся: Tuna Mesh — не VPN в бытовом смысле слова и не сервис для обхода блокировок, рассматривать его так не стоит. Своей инфраструктуры для выхода трафика в интернет мы не даём. Мы только соединяем устройства пользователя в зашифрованную частную сеть, как это делает корпоративный VPN. Сами мы относим такие сети к классу NGVPN (New Generation Virtual Private Network): это частная сеть корпоративного уровня или доступ к своим устройствам в локальных сетях. Чтобы Tuna Mesh не путали с VPN-сервисами, дальше и в документации мы называем его просто mesh-сетью.
- Устройства команды получают постоянные адреса и 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. По этим адресам устройства обращаются друг к другу по любым протоколам и портам:
ssh ubuntu@office-gw.tuna
psql -h prod-db-1.tuna -U app
Снаружи к устройствам не попасть: в сети видны только устройства вашей команды.
Изоляция и межсетевой экран на нашей стороне
На каждой ноде у команды своё сетевое пространство имён Linux (network namespace). Это отдельный сетевой стек со своими интерфейсами, маршрутами и правилами. Сети разных команд разделены на уровне ядра, поэтому пакет из чужой команды до вашей сети не дойдёт, даже если адреса совпадают: диапазон 100.100.0.0/16 у всех команд один.
Правила доступа работают как межсетевой экран внутри этого пространства имён. Пакет, который правила не пропускают, отбрасывается на ноде и до получателя не доходит. Важно, где именно стоит проверка. В Tailscale и NetBird правила применяет само устройство, поэтому их может отключить тот, у кого на нём есть права root. У нас межсетевой экран работает на ноде, к которой у устройства доступа нет, и с устройства его не обойти.
У этой схемы есть ещё одно следствие: отозванное устройство теряет доступ сразу. Нода обрывает его сессию, и пакеты от него никуда не идут.
Надёжность и безопасность важнее скорости
Tailscale и NetBird в первую очередь стараются соединить устройства напрямую, по WireGuard из точки в точку, а через свои релеи пускают трафик, только если прямой путь не нашёлся. Когда прямой путь есть, задержка минимальная. Мы сознательно выбрали другую схему: трафик всегда проходит через ноду. Это лишний участок пути и чуть большая задержка. Взамен мы получаем межсетевой экран, который нельзя обойти с устройства, изоляцию команд, мгновенный отзыв устройств и сеть, которая не зависит от того, пропускает ли провайдер WireGuard.
В России последнее особенно важно. Разработчики WireGuard прямо пишут, что не прячут протокол от анализа трафика, а его служебные пакеты легко узнать по фиксированному формату. ТСПУ этим пользуются: WireGuard входит в число протоколов, которые блокируют с осени 2025 года, а в 2026 году соединения по нему по-прежнему обрывают по сигнатуре первого пакета. Сильнее всего страдают соединения с зарубежными серверами, но и внутри России WireGuard работает с перебоями: жалуются пользователи мобильных операторов и региональных провайдеров. Мы видели это и на своих серверах: в некоторых региональных дата-центрах в России WireGuard устанавливает соединение, а потом провайдер режет UDP-трафик по объёму.
Пользователи Tailscale и NetBird просят добавить маскировку трафика, потому что в России WireGuard периодически блокируют и его легко обнаружить, но встроенного решения пока нет. А в октябре 2024 года Tailscale на время сама закрыла доступ пользователям из России. Ограничение откатили, но предупредили, что по требованиям закона его придётся вернуть.
WireGuard по умолчанию, SSH в запасе
Чтобы сеть оставалась доступной и при таких блокировках, у клиента два транспорта.
- 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, описано в документации. Потом на рабочем компьютере выполните:
tuna mesh login
tuna mesh up
Первая команда откроет браузер, где нужно подтвердить устройство. Вторая подключит его к сети.
На серверах и в CI браузера нет, поэтому для них есть токены подключения. Токен создаётся в кабинете на срок от часа до суток и подключает до 10 устройств:
tuna mesh enroll <токен>
tuna mesh up
Синтаксис команд на время беты может поменяться, актуальный вариант всегда в документации.
Точки выхода
Устройство на Linux или macOS может стать точкой выхода: пропускать через себя интернет-трафик других устройств команды. Сайты и сервисы видят вас с её IP-адреса. Точка выхода — всегда устройство вашей команды: своих серверов для выхода в интернет мы не даём. Точки выхода и раздача подсетей есть и у Tailscale, и у NetBird, так что если вы ими пользовались, здесь всё будет знакомо.
Когда это пригодится:
- Сервисы с доступом по белому списку IP. CRM, админка, облачная консоль или база заказчика пускают только с IP офиса. Поставьте точку выхода на компьютер в офисе, и с ноутбука из дома доступ будет таким же, как с рабочего места.
- Интернет из другой страны. Точка выхода на сервере в нужной стране покажет сайт, рекламу или платёжную форму так, как их видят местные пользователи.
- Публичный Wi-Fi. В кафе, отеле или аэропорту весь трафик до точки выхода зашифрован.
Чтобы раздать точку выхода, выполните на устройстве, через которое пойдёт трафик:
tuna mesh up --advertise-exit-node
А на своём устройстве выберите её:
tuna mesh up --exit-node=office-gw
Через точку выхода не обязательно пускать весь трафик. Можно выпускать через неё только трафик в одну страну, или наоборот, отправлять трафик в одну страну напрямую, а остальной через точку выхода. С флагом --fallback-to-direct трафик идёт напрямую, пока точка выхода недоступна. Трафик в локальную сеть, в которой вы находитесь, в любом случае идёт мимо точки выхода.
Кто может пользоваться точкой выхода, решает её владелец: вся команда, отдельные устройства или только его собственные. Подробнее — в разделе Точки выхода и подсети.
Доступ к сети в офисе или облаке
Второй режим — раздача подсетей. Устройство открывает доступ к локальной сети, в которой стоит, и ставить клиент на каждый хост в ней не нужно.
Например, у вас в облаке приватная сеть с базой, Kubernetes API и мониторингом, и наружу у них ничего не торчит. Обычно для доступа туда поднимают VPN-сервер или bastion-хост и раздают разработчикам конфиги. С Tuna Mesh достаточно поставить tuna на одну виртуальную машину в этой сети:
# на виртуальной машине в облаке
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 в бете и включается для команды по запросу. Напишите в поддержку, и в боковой панели кабинета появится раздел Mesh.
Это бета, поэтому есть ограничения: точку выхода выбирают вручную, раздавать её можно только с Linux и macOS, а имя устройства берётся из hostname. Полный список — в документации. Если что-то работает не так или не хватает функции, напишите нам: от ваших отзывов зависит, что мы сделаем дальше.
Оставьте отзыв
Если вам нравится пользоваться Tuna, или наоборот вы недовольны чем-либо, то пожалуйста оставьте отзыв.
Новости
Анонсы новых функций и статей публикуем в Telegram-канале. Подписывайтесь, чтобы ничего не пропустить.
Помощь
Мы ценим наших пользователей и детально изучаем все обращения, если у вас возникли проблемы с tuna – обязательно свяжитесь с нами одним из способов: