Как устроена mesh-сеть, которая пробивает NAT без центрального сервера

Ноутбук в кафе, домашний сервер за NAT серого провайдера и виртуалка в облаке — три разных мира за глухими фаерволами. Mesh-сеть позволяет пинговать узел по адресу вроде 10.42.0.5 так, будто он рядом. Алексей Меркулов (Fobscraft) разбирает механику класса решений: виртуальный интерфейс, упаковку пакетов, пробитие NAT и отделение координации от потока данных. Это база, чтобы потом честно сравнить WireGuard, Tailscale, Headscale или собственный контур под заказ. Похожий разбор систем — через услуги Fobscraft.

Сцена, с которой всё начинается

Обратите внимание на картину. Вы в кафе. Дома — сервер без белого IP. В облаке — ещё одна машина. Обычный интернет между ними не пускает то, что не попросили заранее.

Дальше появляется вопрос, с которого начинается вся архитектура: как программа пробивает стены провайдерских NAT, находит короткий путь между узлами и обходится без центрального сервера на пути данных? И зачем вообще строить свой контур, когда уже есть WireGuard, ZeroTier и Tailscale?

Честный ответ на последнее начинается с механики. Идём по ступеням.

Картонная коробка вместо кабеля

Заметьте странность. В диспетчере устройств появляется сетевая карта, к которой физически ничего не подключено. Операционная система всё равно шлёт туда трафик.

Почему ОС соглашается писать в «несуществующее» устройство? Потому что для ядра это обычный канал — виртуальный сетевой интерфейс (TUN/TAP). Он зарегистрирован в таблице маршрутизации наравне с физической картой.

Приложение пишет пакет на 10.42.0.5. ОС смотрит маршрут, видит виртуальный интерфейс и кладёт пакет туда. Пользовательский процесс mesh-клиента забирает его из этого ящика.

Типичное заблуждение — будто VPN «перехватывает трафик из кабеля». На деле никто ничего не перехватывает: ОС сама кладёт пакеты в виртуальный канал, потому что так настроен маршрут.

Запомним деталь на потом: каждое чтение из TUN — переключение между ядром и пользовательским пространством. Это не бесплатно. К цене переключений вернёмся на ступени про скорость.

Матрёшка: чужой пакет внутри своего

Клиент прочитал из виртуальной карты IP-пакет на приватный адрес туннеля. Провайдер в интернете такой адрес не знает и маршрутизировать не будет.

Суть трюка простая. Программа берёт внутренний пакет целиком и кладёт его полезной нагрузкой внутрь нового внешнего UDP-пакета. Внешний пакет уже адресован на реальный публичный IP другого узла. Так рождается инкапсуляция — пакет в пакете.

Туннелирование — это не то же самое, что шифрование. Шифрование можно добавить сверху. Сама суть туннеля — упаковка одного протокола внутрь другого.

Почему здесь всплывает MTU

У физического кадра есть предел вместимости. Обычно для Ethernet это 1500 байт. Когда мы кладём пакет внутрь пакета, добавляются заголовки и съедают часть лимита.

Полезный размер данных считается примерно так:

Полезные данные ≈ MTU среды (1500)
               − внешний IP (20 байт)
               − внешний UDP (8 байт)
               − заголовки туннеля и крипто (зависят от реализации)

Если приложение шлёт кадр «под завязку» 1500 байт, после упаковки он перестаёт помещаться. ОС режет пакет на фрагменты, принимающая сторона ждёт все куски. Потеря одного куска обнуляет весь пакет. Скорость падает, растут задержки, рвутся TCP-сессии.

Принцип: правильный MTU и MSS — условие работоспособности туннеля, а не косметика после запуска.

Глухая стена: пробитие NAT без белого IP

Усложним картину. Ноутбук в кафе и сервер дома сидят за разными NAT. Ни у кого нет публичного адреса, на который можно просто «постучаться».

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

Это классический приём UDP hole punching. Нужен координатор на этапе знакомства: он знает публичные адреса и помогает синхронизировать «одновременный стук».

Дыра, которая закрывается сама

Теперь изменим только одну деталь. Соединение есть, трафик шёл, потом тишина на пару минут.

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

Принцип: любому P2P mesh-решению нужны фоновые keep-alive пакеты. Их задача — держать дыру открытой, даже когда пользователь ничего не передаёт.

От трубы к паутине: mesh вместо звезды

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

В mesh каждый узел может строить прямой туннель к другим узлам, без транзита данных через сервер. Полносвязная сеть из N узлов теоретически требует N×(N−1)/2 связей. На практике полный граф не обязателен: если прямой NAT-туннель не встал, трафик может пойти через соседний узел.

Координатор в такой схеме нужен для знакомства узлов и выдачи адресов — control plane. Поток данных идёт отдельно — data plane. Выключили координатор: уже знакомые узлы часто продолжают обмен. Новый узел без справочника уже не войти.

Принцип: координатор знакомит, но не обязан возить чужой трафик.

Почему архитектура кода определяет скорость

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

Ключевая метрика здесь — не только мегабиты в секунду, а PPS, пакеты в секунду. На мелких пакетах (голос, игры, DNS) именно PPS показывает качество стека: накладные расходы на заголовок фиксированы независимо от размера полезной нагрузки.

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

Броня без лишних тормозов

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

Современные симметричные потоковые шифры обрабатывают поток быстро, особенно с ускорением на CPU. Длинный ключ и «сложный» алгоритм сами по себе не делают VPN лучше, если процессор тратит лишние микросекунды на каждый пакет.

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

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

Теперь, понимая упаковку, NAT, mesh и скорость, можно сравнивать инструменты по компромиссам.

WireGuard даёт простую и сильную криптографию, но динамический mesh между множеством узлов за NAT обычно достраивают поверх. Tailscale эту задачу закрывает, опираясь на свой control-сервис; self-hosted вариант координации существует отдельно — например, Headscale. ZeroTier и близкие решения делают свою ставку на удобство сети и модель доверия.

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

Принцип: сначала назовите, какую независимость вы покупаете, потом выбирайте стек.

Что вы теперь можете объяснить

Вы можете нарисовать маршрут пакета через mesh-туннель с учётом инкапсуляции и MTU и объяснить, почему превышение лимита рождает фрагментацию. Вы умеете рассказать, почему два устройства за серыми IP устанавливают прямое P2P-соединение и почему без keep-alive оно развалится после тишины. Вы отличаете координатор знакомства от сервера, который возит весь трафик. Вы понимаете, почему скорость часто упирается в копирование памяти и шифрование, и можете спорить, где хватает WireGuard или Headscale, а где нужен заказной контур под вашу инфраструктуру.