Связь между площадками: VPN, Tailscale, NetBird или Cloudflare Mesh?

Я много занимаюсь объединением сетей предприятий. Вопросы повторяются: как лучше связать наши площадки? Нужны ли публичные IP-адреса? Насколько это безопасно? Подойдёт ли решение после открытия филиала, смены подключения к Интернету или увеличения штата?

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

Поэтому сначала я разбираюсь в архитектуре, затем выбираю продукт. Классический site-to-site VPN вполне может подойти. Tailscale и NetBird упрощают управление и установление соединений. Cloudflare Mesh переносит путь передачи данных в сеть провайдера. Именно эти различия определяют область применения каждого подхода.

Здесь речь об объединении целых сетей площадок. Индивидуальный доступ сотрудников из дома рассматривается отдельно как дополнительный сценарий удалённого доступа.

Пример: Три связанные сети площадок

Головной офис использует 10.1.0.0/24, филиал использует 10.2.0.0/24, домашняя лаборатория использует 10.3.0.0/24. На каждой площадке шлюз обеспечивает доступ к удалённым сетям. Принтерам и NAS за ним не нужны собственные VPN-клиенты. Цель всех вариантов одинакова: управляемая связь между этими сетями.

Получается маршрутизируемая сеть третьего уровня. Площадки не становятся единым широковещательным доменом; не все протоколы локального обнаружения начинают работать между ними. DNS должен корректно разрешать внутренние имена, а локальным маршрутизаторам нужны маршруты к удалённым сетям.

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

Site-to-site определяет соединение, а не топологию

Site-to-site означает связь сети с сетью. Это не требует пропускать весь трафик через центральный межсетевой экран. Звезда с головным офисом в центре распространена, но прямые туннели между парами площадок тоже относятся к site-to-site. Шлюзы Tailscale, NetBird и Cloudflare Mesh могут выполнять ту же задачу.

Tailscale и NetBird стремятся передавать данные напрямую, даже если регистрация и координация централизованы. Сеть Cloudflare географически распределена, но трафик между площадками всё равно проходит через неё. Это не прямое соединение между узлами. Сеть провайдера заменяет центральный межсетевой экран в роли транзитной точки.

Публичные IP и меняющиеся требования

Вопрос о публичном IP возникает рано. Я различаю внешнюю доступность подключения и постоянство адреса. Фиксированный публичный адрес упрощает создание доступной конечной точки VPN, но нужен не на каждой площадке. Филиал может сам установить исходящий туннель к доступному центральному шлюзу; в зависимости от схемы динамический DNS помогает при смене адреса.

Сложнее, если оба конца находятся за строгим операторским NAT без доступной извне точки. Особенно для мобильного Интернета стоит проверить, какие адреса и входящие соединения действительно предоставляет оператор. Tailscale и NetBird пытаются установить прямую связь через NAT, при необходимости используя ретрансляторы. Cloudflare Mesh устанавливает исходящие подключения к сети провайдера.

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

Классический site-to-site VPN: Соединение обеспечивают шлюзы

Два межсетевых экрана или маршрутизатора создают зашифрованный туннель, часто через IPsec или настроенный вручную WireGuard. Локальная маршрутизация отправляет в него пакеты удалённой сети. Другой шлюз расшифровывает их и передаёт в сеть назначения.

При трёх площадках головной офис может стать центром. Филиал и лаборатория подключаются к нему. Схема проще, но их обмен проходит через офис. Полная сетка соединяет каждую пару напрямую. Для n площадок нужно n × (n − 1) / 2 соединений: три для трёх, уже 45 для десяти. Контроллеры и динамические механизмы сокращают работу; классические VPN не ограничены вручную настроенной звездой.

Преимущества: подход сочетается с существующими экранами и чёткими границами площадок. Концы туннеля под собственным контролем. Дополнительного mesh-провайдера в пути данных нет; правила, маршруты и журналы входят в привычное управление.

Недостатки: с числом площадок растёт работа с маршрутами, ключами и эксплуатацией. NAT, смена адресов и разные производители усложняют диагностику. Мобильным пользователям часто нужен отдельный удалённый доступ.

Постоянный публичный IP везде не является универсальным требованием. Во многих схемах достаточно доступного центра и исходящих туннелей филиалов. Помогают динамический DNS и обход NAT. Однако при строгом CGNAT с обеих сторон прямая связь затруднена без доступной конечной точки или посредника.

Для двух стабильных площадок с подходящими экранами это разумный вариант. Работающий VPN не стоит менять лишь потому, что в другом продукте меньше полей настройки.

Tailscale: Прямые соединения с центральной координацией

Tailscale дополняет WireGuard регистрацией устройств, координацией и политиками доступа. Служба управления помогает участникам найти друг друга. По возможности данные передаются напрямую. Если NAT или экран мешают, другой путь предоставляет ретранслятор. Даже через DERP данные зашифрованы между узлами Tailscale.

Маршрутизаторы подсетей подключают целые LAN к tailnet. Описанный Tailscale сценарий site-to-site использует Linux на обоих концах. Устройствам за ними не нужен агент, но нужны правильные маршруты. Отключение NAT источника ради сохранения исходных адресов делает обратный маршрут особенно важным.

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

Недостатки: прямой путь не гарантирован. Через ретрансляторы задержка и пропускная способность могут отличаться. Размещённая у провайдера координация остаётся эксплуатационной зависимостью; тариф и функции должны соответствовать внедрению.

Шифрование WireGuard заканчивается на узле. Если это маршрутизатор подсети, следующий участок LAN находится вне туннеля. Поэтому HTTPS и SSH полезны и в частной сети.

NetBird: Похожая сетка с самостоятельным размещением

NetBird тоже использует WireGuard, стремится к прямой связи и применяет ретрансляторы при необходимости. Маршрутизирующие узлы подключают сети, устройства которых не запускают клиент. Текущее руководство site-to-site описывает Networks, Resources и соответствующие политики доступа.

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

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

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

Cloudflare Mesh: Путь проходит через сеть провайдера

Участники устанавливают исходящие соединения с Cloudflare. Межплощадочный трафик проходит через его сеть. Не нужно напрямую соединять каждую площадку со всеми остальными или поддерживать собственный VPN-центр. При этом границы доверия и путь отличаются от прямой сетки WireGuard.

Преимущества: объединяет связь с центральными политиками Gateway. Особенно уместно там, где уже используется Cloudflare One. Площадки за NAT и мобильные клиенты подключаются исходящими соединениями.

Недостатки: эксплуатация и путь зависят от поставщика. Обработка чувствительных данных должна соответствовать требованиям доверия и приватности. TLS и SSH остаются полезны. Выгодность маршрута для приложения проверяется измерениями; глобальная магистраль не гарантирует лучшую скорость везде.

При новом внедрении я следовал бы текущей документации клиента. Cloudflare обозначает Mesh как бета-версию и требует MASQUE в профиле узла. Для WireGuard документированы ограничения высокой доступности, IPv6-маршрутов и маршрутов по имени хоста. Самой поддержки WireGuard на маршрутизаторе недостаточно, чтобы считать его равноценным Mesh-узлом.

Mesh также следует отличать от туннеля cloudflared для отдельных приложений. Здесь нужна двунаправленная частная IP-связь между участниками и маршрутизируемыми сетями.

Основные различия

Сначала я сопоставляю следующие особенности. Нужный тариф и фактический путь нужно проверять в конкретной среде.

Что для меня означает безопасная связь площадок

На вопрос о безопасности я прежде всего проверяю разрешённые соединения и управление доступом. Зашифрованный туннель может давать чрезмерные права. Мне нужны определённые связи сетей и служб, защита администраторов и возможность отозвать доступ. MFA для управления и персонально зарегистрированных пользователей, ограниченные права и обслуживаемые шлюзы входят в эту оценку.

Границы шифрования тоже различаются. Классический туннель заканчивается на шлюзах. Tailscale и NetBird шифруют между узлами, в том числе маршрутизаторами подсетей. Следующая LAN автоматически не шифруется. Для Cloudflare обработка в сети провайдера должна удовлетворять требованиям предприятия. HTTPS и SSH полезны на уровне приложения.

Исходящее соединение упрощает установку и позволяет не открывать публичный VPN-сервис в филиале. Политику доступа оно не заменяет. Публичный IP сам по себе также не делает экран небезопасным. Риск определяется открытыми службами, защитой и эксплуатацией. Рейтинг безопасности по названиям продуктов я не составляю.

Что я хочу проверить перед приёмкой

Нужны рабочие маршруты в обе стороны. Маршрут к 10.2.0.0/24 должен быть на ответственном маршрутизаторе или клиенте. Если получатель отвечает через другой шлюз по умолчанию, нужен правильный обратный маршрут. SNAT упрощает ответы, но меняет видимый адрес, влияя на журналы и правила. Это осознанное проектное решение.

Двух оверлейных узлов недостаточно для высокой доступности. После сбоя LAN-устройства должны по-прежнему достигать следующего шлюза. Keepalived и VRRP позволяют использовать виртуальный адрес. Удалённые маршруты тоже должны выбирать здоровый узел. При приёмке я хочу видеть поведение новых и существующих TCP-сеансов при отказе шлюза или туннеля. Работающий процесс и успешный ping дают лишь часть ответа.

Проверять нужно и намеренно запрещённые соединения. Если SSH разрешён, а другое приложение запрещено, необходимо подтвердить именно это. ICMP не доказывает срабатывания TCP-правила. Регистрация, политики и экран целевого узла должны согласовываться.

Остаются малозаметные детали повседневной работы: уникальные префиксы, внутренние имена и подходящая MTU. Ни 192.168.x.x, ни 10.x.x.x не гарантируют отсутствие конфликтов. Если короткие ping проходят, а большие передачи зависают, связь я не считаю готовой.

Для оценки скорости нужны одинаковая передача файла и интерактивное приложение через реальные каналы. Следует записать прямой или ретранслируемый путь, нагрузку CPU и поведение при смене Интернета. Здесь я оцениваю архитектуру и эксплуатацию, а не представляю измеренный рейтинг скорости продуктов.

Удалённый доступ: Подключение отдельных устройств

Подключение рабочего ноутбука из дома к корпоративной сети представляет собой удалённый доступ, или client-to-site. Клиент работает на ноутбуке и не подключает автоматически всю домашнюю сеть к офису. Можно использовать службу центрального экрана или клиенты этих платформ. Персональная регистрация позволяет назначать права пользователям и группам.

Домашний офис может быть и site-to-site-площадкой: шлюз связывает разрешённую сеть или VLAN с головным офисом. Различие в подключаемом устройстве или сети, а не в месте работы. Для отдельных устройств удалённый доступ часто соответствует нужному объёму. Делать доступной всю личную сеть без намерения незачем.

Где каждый подход уместен для меня

Для нескольких постоянных площадок с существующими экранами я начал бы с классического VPN, выбрав звезду или прямые туннели. Для площадок за NAT с центральным управлением и по возможности прямыми путями сравнил бы Tailscale и NetBird. При обязательном собственном размещении координации NetBird стоит оценить рано. При уже используемых политиках Cloudflare One рассмотрел бы Mesh, его бета-статус и обработку внутри провайдера. Дополнительный удалённый доступ остаётся отдельным критерием.

Есть и Headscale: самостоятельно размещаемая реализация сервера координации Tailscale. Это отдельный проект со своим набором функций, не полная замена всех возможностей облачной службы. Ручной WireGuard уже относится к классическому подходу и подходит, если достаточно нескольких туннелей без дополнительного управления.

На вопрос о лучшем решении я хочу рекомендовать подходящее предприятию и будущим изменениям. В небольшой системе с готовыми экранами им может остаться классический VPN. Другие условия подключения или требования управления делают mesh интересным. Выбор зависит от возможности безопасно эксплуатировать, понимать и восстанавливать необходимые соединения после сбоя.

До следующего раза,
Joe