Приватный канал между дата-центрами: туннель, VLAN или отдельный линк — что выбрать

MAATRIX

Два ваших сервера стоят в разных дата-центрах — не в соседних стойках одного зала, а физически в разных зданиях, часто у разных провайдеров или в разных городах. Между ними ходит трафик, которому не место в открытом интернете: репликация базы, внутренний API, синхронизация очереди. Вариантов организовать приватный канал несколько, и они принципиально разные по деньгам, задержке и доступности у конкретного провайдера. Разберём четыре подхода — VPN-туннель, L2 VLAN между дата-центрами, выделенный линк и приватный backbone провайдера — и дадим критерии выбора между ними, а не совет пробовать наугад.

Чем эта задача отличается от приватной сети внутри одного дата-центра

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

Как только серверы оказываются в разных дата-центрах, ситуация меняется качественно. Внутренний коммутатор одного здания физически не дотягивается до другого — между ними лежит либо публичный интернет, либо магистральная инфраструктура, которую нужно арендовать отдельно или надеяться, что провайдер уже её построил. Здесь недостаточно спросить «а есть ли у вас приватная сеть» — нужно уточнять про связность между конкретными локациями: ответ у одного провайдера может быть разным для разных пар дата-центров — между двумя площадками в одном городе да, между Европой и США нет.

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

Вариант 1: VPN-туннель поверх публичного интернета

Самый доступный и универсальный вариант — поднять зашифрованный туннель между серверами прямо поверх обычного интернет-соединения, не завязываясь на инфраструктуру конкретного провайдера. Для связки сервер-сервер де-факто стандартом стал WireGuard: работает в ядре Linux, минимум параметров в конфиге, современная криптография без выбора шифронаборов.

Общая идея конфига для двух серверов в разных дата-центрах ничем не отличается от туннеля внутри одной страны — на каждой стороне свой приватный ключ, публичный ключ и внешний адрес другой стороны, интерфейс wg0 с адресом из выделенного диапазона:

# сервер A: /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <приватный_ключ_A>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <публичный_ключ_B>
Endpoint = <публичный_IP_сервера_B>:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

После wg-quick up wg0 сервисы на обеих сторонах настраиваются слушать адреса из 10.10.0.0/24, а не публичные интерфейсы. Пошаговое разворачивание с firewall-правилами — отдельная тема; здесь важно место этого варианта в общей картине выбора, а не сама механика настройки.

Плюсы: работает между любыми двумя серверами с публичным IP независимо от провайдера и страны; не требует ничего от хостера, кроме открытого UDP-порта; трафик шифруется по умолчанию, чего не гарантирует ни один из следующих вариантов. Разворачивается за минуты и почти ничего не стоит сверх обычной аренды серверов.

Минусы вытекают из того, что туннель — оверлей поверх чужой сети, а не отдельная физическая связность:

• Трафик идёт тем же маршрутом, что и обычный публичный интернет между этими точками — туннель не даёт задержку или стабильность лучше базового маршрута, он только шифрует то, что и так летит через те же сети.
• Оверхед шифрования и инкапсуляции. Каждый пакет получает заголовок WireGuard и криптографическую обвязку, из-за чего полезная нагрузка в кадре уменьшается — это нужно учитывать в MTU, иначе появляется фрагментация, заметно бьющая по производительности на дальних маршрутах.
• Зависимость от качества публичного маршрута. Если между провайдерами перегружен транзитный стык, туннель унаследует эту проблему целиком — он не умеет объезжать плохой участок сети.

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

Вариант 2: L2 VLAN между дата-центрами одного провайдера

Если оба дата-центра принадлежат одному провайдеру или подключены к его общей магистральной инфраструктуре, иногда доступен растянутый L2-сегмент (VLAN), проходящий через сеть провайдера, а не через публичный интернет. С точки зрения серверов это выглядит почти как приватная сеть внутри одного дата-центра: второй интерфейс, адрес из приватного диапазона, без туннелирования на уровне ОС — изоляция и коммутация происходят на оборудовании провайдера.

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

У варианта два существенных ограничения. Во-первых, доступность — вопрос к конкретному провайдеру для конкретной пары локаций, а не данность: многие хостеры держат дата-центры в разных городах как изолированные площадки без ничего, кроме обычного интернет-транзита между ними, и тогда растянутого L2-сегмента попросту не существует. Уточнять это нужно явно у поддержки, а не предполагать по аналогии с тем, что работает внутри одной локации.

Во-вторых, там где L2-связность есть, это обычно ручная настройка сетевого оборудования на стороне провайдера, а не опция в панели — заявку оформляют через поддержку, и провайдер вручную назначает VLAN-тег на портах обеих площадок. Ошибка здесь — реальный класс инцидентов: неверно назначенный тег может оставить продовую машину в чужом или тестовом сегменте. Это стоит держать в уме, заказывая растянутый VLAN у провайдера, и проверять изоляцию сразу после того, как заявка выполнена, а не полагаться на слова поддержки.

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

Вариант 3: выделенный физический линк (dedicated line / dark fiber)

Третий вариант — арендовать или проложить отдельный физический канал именно между двумя точками: выделенную линию у оператора связи (dedicated line, часто на базе MPLS или Ethernet-канала уровня оператора) либо тёмное волокно (dark fiber) — физическое оптоволокно без активного оборудования оператора, на котором клиент сам выбирает протокол.

Это самый качественный и одновременно самый дорогой вариант из всех. Отдельная линия даёт предсказуемую полосу, которая не делится ни с кем (в отличие от общего канала, где трафик конкурирует с трафиком соседей провайдера — механика разобрана в статье «Общий канал против выделенного»), минимальную стабильную задержку без зависимости от загрузки чужих транзитных сетей и полный контроль над протоколом поверх канала.

Цена этой точности реальна: выделенный физический канал между двумя точками — не тарифный план с кнопкой в панели, а отдельный проект. Нужно либо найти оператора с уже проложенной линией между интересующими вас точками (или близко, с довключением «последней мили»), либо заказывать прокладку с нуля, что может занимать месяцы и требует вложений, окупаемых на горизонте лет. Точные тарифы приводить бессмысленно — они зависят от расстояния, оператора и готовой инфраструктуры между точками, узнать их можно только напрямую у операторов для конкретной пары локаций.

Поэтому выделенный линк обычно оправдан при выполнении хотя бы одного условия:

• Объём трафика уже достаточно большой, чтобы плата за исходящий трафик по обычному каналу была сопоставима или превышала стоимость аренды выделенного канала — тогда дедикейт может оказаться дешевле в пересчёте на гигабайт.
• Требования к задержке и джиттеру жёсткие и измеримые — синхронная репликация со строгим SLA, финансовые транзакции с ограничением по времени подтверждения, голосовой или видеотрафик, для которого стабильность задержки важнее среднего значения (подробнее в статье «Средний пинг 30 мс, а созвон рассыпается»).
• Регуляторные или контрактные требования к маршруту — ограничение на прохождение трафика через транзитные сети третьих сторон, или SLA со штрафами за простой канала.

Если ни одно из условий не выполняется, выделенный линк почти всегда избыточен по цене относительно того, что реально даёт задача — VPN-туннель или, если повезёт с провайдером, L2 VLAN закрывают потребность на порядок дешевле.

Вариант 4: приватный backbone самого провайдера

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

Идея та же, что у L2 VLAN из варианта 2, но масштаб другой: это не сегмент между двумя площадками по индивидуальному запросу, а готовая глобальная инфраструктура провайдера, к которой в теории можно подключиться между любой парой его регионов — если такая функция вообще реализована и коммерчески доступна.

Важная оговорка: наличие backbone — свойство конкретного провайдера, а не отраслевой стандарт по умолчанию. У части провайдеров такая возможность есть и подаётся как заметное преимущество, у большинства — просто нет, и трафик между их же дата-центрами идёт как обычный публичный. Прежде чем закладывать этот вариант в архитектуру, стоит спросить у провайдера — есть ли backbone между нужными регионами, как он тарифицируется и какие гарантии по задержке даёт. Не предполагайте его существование по аналогии с другими провайдерами — это деталь, которую нужно подтверждать документацией или ответом поддержки.

Если backbone доступен и покрывает нужную пару дата-центров, это часто оптимальное сочетание цены и качества — дешевле выделенного линка, но потенциально стабильнее VPN-туннеля через произвольный публичный маршрут, поскольку трафик физически не покидает инфраструктуру, которую провайдер контролирует сам.

Как выбирать: критерии решения

Первый вопрос — что вообще доступно у провайдера для нужной пары дата-центров. Варианты 2 и 4 попросту не существуют для большинства пар локаций у большинства провайдеров, и выяснять это нужно прямым вопросом в поддержку, а не догадками по маркетинговым материалам. Если ответ «ничего из этого нет» — выбор сужается до туннеля или выделенного линка, и дальше решает бюджет.

Второй вопрос — окупает ли объём трафика разницу в цене. При небольшом трафике (единицы-десятки гигабайт в месяц) экономия на приватном канале провайдера обычно не окупает усилий на его получение — VPN-туннель закрывает задачу так же надёжно. При постоянном большом трафике (значимая часть журнала репликации, потоковая синхронизация хранилищ) разница в тарификации между обычным egress и приватным каналом может окупить настройку многократно — это стоит посчитать, а не предполагать.

Третий вопрос — насколько критичны задержка и джиттер для нагрузки. Для асинхронной репликации или редких синхронизаций джиттер в несколько миллисекунд роли не играет. Для синхронной репликации, где RTT добавляется к каждому COMMIT, или для внутреннего голосового/видеотрафика разница между VPN через случайный публичный маршрут и магистральным каналом провайдера может быть ощутимой — и тогда есть смысл переплатить.

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

Комбинировать варианты — нормальная практика: держать backbone или VLAN провайдера как основной канал и параллельно поднятый WireGuard-туннель как резерв на случай деградации основного — тогда потеря одного механизма не превращается в потерю связности вообще.

Частые вопросы