Как объединить два VPS у разных провайдеров

Могут ли два VPS у разных провайдеров работать как единая система

Да. Чтобы объединить два VPS у разных провайдеров, вам нужно самостоятельно построить частную сеть: зашифрованный оверлей, работающий поверх публичного интернета, обычно с использованием WireGuard. Ни один провайдер не сделает это за вас, так как частная сеть каждого провайдера ограничена его собственным периметром. Платой за такое соединение станет задержка (latency), которую невозможно устранить настройками, и оплата исходящего трафика с обеих сторон. Кроме того, размер пакетов внутри туннеля уменьшается, что приводит к сбоям, которые внешне не похожи на сетевые проблемы.

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

Типичная конфигурация для пользователя в Японии — один VPS в Токио или Осаке для обслуживания локальных клиентов и один более дешевый VPS за рубежом для пакетной обработки данных, резервного копирования или задач сборки. Такая схема работает хорошо. Разделение пути одного запроса между этими же двумя машинами обычно работает плохо, и далее на этой странице объясняется почему.

Почему частная сеть провайдера ограничена его собственным периметром

Частная сеть провайдера — это виртуальная локальная сеть (VLAN) внутри дата-центра этого провайдера. Адрес 10.x.x.x на вашем втором интерфейсе маршрутизируется только коммутаторами провайдера. Это частный адрес согласно RFC 1918, а частные адреса не маршрутизируются в публичном интернете: пакет, адресованный 10.0.0.5 и отправленный в интернет, будет отброшен первым же маршрутизатором за пределами сети провайдера. Поэтому в панелях управления нет настроек, объединяющих две учетные записи. Внутри одного провайдера ситуация иная, и бесплатная частная сеть между двумя серверами у одного провайдера является подходящим инструментом, если обе машины находятся в одной учетной записи.

Взаимодействие между разными провайдерами означает, что трафик проходит через транзитные сети и точки обмена трафиком, которые вы не контролируете. Всё, что вы отправляете в открытом виде, может быть прочитано на этом пути. Overlay-сеть — это не дополнительная мера безопасности, а обязательное условие для создания канала связи.

Выберите адреса, которые не будут конфликтовать

Сделайте это до генерации ключа. На обоих серверах выполните:

ip -4 addr show
ip route show
ip -4 addr show docker0 2>/dev/null

Запишите все диапазоны, которые уже используются. Часто бывает, что два провайдера выдают пересекающиеся диапазоны RFC 1918, а Docker по умолчанию резервирует 172.17.0.0/16 для docker0. Затем выберите диапазон для оверлейной сети, который не встречается ни в одном из списков, например 10.83.7.0/24. Избегайте 192.168.0.0/24 и 192.168.1.0/24, так как они конфликтуют с домашними роутерами в тот момент, когда вы подключаете ноутбук к той же оверлейной сети.

Пересечение сетей не вызывает ошибку. Оно приводит к неверной маршрутизации, так как ядро выбирает наиболее специфичный маршрут. Если ваша оверлейная сеть — 10.0.0.0/24, а провайдер уже маршрутизирует 10.0.0.0/16 через второй интерфейс, пакеты для вашего узла уйдут в сеть провайдера и исчезнут без записи в логах.

Назначьте каждой машине фиксированный адрес из этого диапазона и запишите его. В этом руководстве используются 10.83.7.1 для сервера в Токио и 10.83.7.2 для зарубежного сервера.

Настройка туннеля: WireGuard на обоих узлах

В WireGuard нет разделения на клиент и сервер. На обеих машинах работает одно и то же ПО, каждая имеет свою пару ключей и указывает другую сторону в качестве узла (peer). Выполните следующие действия на каждом сервере:

sudo apt update && sudo apt install -y wireguard
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/host.key'
sudo sh -c 'wg pubkey < /etc/wireguard/host.key > /etc/wireguard/host.pub'
sudo chmod 600 /etc/wireguard/host.key
sudo cat /etc/wireguard/host.pub

Создайте файл /etc/wireguard/wg0.conf на сервере в Токио, публичный адрес которого в данном примере — 203.0.113.10:

[Interface]
Address = 10.83.7.1/24
ListenPort = 51820
PrivateKey = <contents of host.key on the Tokyo box>

[Peer]
PublicKey = <contents of host.pub on the overseas box>
AllowedIPs = 10.83.7.2/32
Endpoint = 198.51.100.20:51820
PersistentKeepalive = 25

Аналогичный файл на удаленном сервере, публичный адрес которого — 198.51.100.20:

[Interface]
Address = 10.83.7.2/24
ListenPort = 51820
PrivateKey = <contents of host.key on the overseas box>

[Peer]
PublicKey = <contents of host.pub on the Tokyo box>
AllowedIPs = 10.83.7.1/32
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

Выполните sudo chmod 600 /etc/wireguard/wg0.conf на обоих узлах. AllowedIPs — это вся модель доступа: она определяет, какому узлу отправлять пакеты при исходящем трафике и какие исходные адреса принимать от узла при входящем. Рекомендуется один раз ознакомиться с криптографической маршрутизацией (Cryptokey routing), которая связывает публичный ключ с набором адресов, прежде чем добавлять третий узел. Если один сервер обслуживает множество клиентов, а не работает в режиме равноправных узлов, обратитесь к полному руководству по настройке сервера WireGuard.

PersistentKeepalive = 25 не является строго обязательным, если оба узла имеют публичные адреса. Тем не менее, его стоит настроить. Многие провайдеры используют stateful-файрволы перед инстансами, в которых запись о UDP-соединении удаляется после минуты или двух бездействия. Из-за этого первый пакет после простоя отбрасывается, и кажется, что соединение «просыпается» медленно.

Поднимите интерфейс и проверьте статус:

sudo systemctl enable --now wg-quick@wg0
sudo wg show
ping -c 3 10.83.7.2

wg show должен вывести latest handshake с отметкой времени несколько секунд назад и ненулевые счетчики переданных данных в обоих направлениях. Если в выводе отсутствует строка с рукопожатием (handshake), значит, пакеты не доходят. Проверьте, открыт ли порт UDP 51820 в сетевом файрволе вашего провайдера (это отдельная настройка, отличная от ufw в большинстве панелей управления), а затем запустите sudo tcpdump -ni any udp port 51820 на принимающем узле, чтобы увидеть, приходят ли пакеты вообще.

Настройка межсетевого экрана для туннеля, а не для публичного интерфейса

Смысл этого соединения в том, чтобы ваши сервисы перестали прослушивать публичные адреса. Привяжите каждый сервис к его адресу в оверлейной сети. Для PostgreSQL это listen_addresses = '10.83.7.1' в файле postgresql.conf. Для большинства других демонов это параметр bind или строка address.

Затем откройте порты только на интерфейсе туннеля:

sudo ufw allow from 198.51.100.20 to any port 51820 proto udp
sudo ufw allow in on wg0 to any port 5432 proto tcp
sudo ufw enable

Первое правило — это единственный публичный доступ, который требуется для соединения, и оно ограничено одним адресом. Второе правило никогда не совпадет с пакетом из интернета, так как пакет появляется на интерфейсе wg0 только после того, как WireGuard расшифрует его и проверит источник на соответствие параметру AllowedIPs этого узла. Если эти правила для вас в новинку, в статье основы работы с межсетевым экраном ufw для VPS описаны политики по умолчанию и порядок применения правил.

Одна проблема напрямую связана с привязкой к адресу оверлейной сети. Если сервис запускается до того, как появится интерфейс wg0, адреса еще нет на машине, и привязка завершается ошибкой. PostgreSQL сообщает именно об этом:

could not bind IPv4 address "10.83.7.1": Cannot assign requested address

Самое простое решение — разрешить привязку к адресу, который еще не существует:

echo 'net.ipv4.ip_nonlocal_bind = 1' | sudo tee /etc/sysctl.d/99-overlay.conf
sudo sysctl --system

Другой способ — настроить запуск юнита после поднятия туннеля с помощью параметров sudo systemctl edit postgresql и строки After=wg-quick@wg0.service. Настройка через sysctl проще, к тому же она работает при перезапуске интерфейса, когда сервис продолжает выполняться, чего не обеспечивает исправление порядка запуска.

Как задержка между регионами влияет на ваше приложение

Время кругового обращения (RTT) — это минимально возможный порог. Шифрование занимает значительно меньше миллисекунды на пакет на любом современном процессоре, поэтому сам туннель не является источником ощутимых задержек. Источник — расстояние. Свет в оптоволокне распространяется со скоростью около 200 000 км/с, а реальные маршруты не являются прямыми линиями, поэтому ваш RTT определяется географией и тем, какой путь между собой выбрали ваши провайдеры.

[
  {
    "label": "Tokyo to Osaka",
    "rtt_ms": 8,
    "seconds_for_200_queries": 1.6
  },
  {
    "label": "Tokyo to Singapore",
    "rtt_ms": 70,
    "seconds_for_200_queries": 14
  },
  {
    "label": "Tokyo to US West",
    "rtt_ms": 100,
    "seconds_for_200_queries": 20
  },
  {
    "label": "Tokyo to Frankfurt",
    "rtt_ms": 235,
    "seconds_for_200_queries": 47
  }
]

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

Внутренний переход с задержкой 8 мс незаметен для пользователя. Задержка при связи Токио с западным побережьем США в 100 мс уже ощутима, а связь Токио с Франкфуртом в 235 мс — это проблема совершенно иного порядка. Задержки суммируются, и именно это часто становится неожиданностью. Веб-запрос, который выполняет 200 последовательных SQL-запросов к базе данных (обычное дело для приложения на базе ORM), тратит один RTT на каждый запрос. Это 1.6 секунд на внутреннем канале и 47 секунд на канале до Франкфурта — еще до того, как база данных начнет обрабатывать хоть один байт данных.

Пропускная способность имеет ту же первопричину. TCP-поток может удерживать в процессе передачи только одно окно неподтвержденных данных, поэтому его предел — это размер окна, деленный на RTT. Linux автоматически увеличивает размер окна до максимума, указанного в net.ipv4.tcp_rmem, но на длинном маршруте любая потеря пакетов приводит к сжатию окна, и оно восстанавливается медленно. Копирование большого резервного архива через один поток rsync будет значительно медленнее, чем то же копирование, разделенное на восемь параллельных потоков.

Оплата исходящего трафика с обеих сторон

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

Две вещи часто становятся неожиданностью. Трафик резервного копирования и репликации полностью учитывается на стороне отправителя. Таким образом, ночной дамп базы данных объемом 50 GB, скачиваемый из Токио, каждую ночь расходует 50 GB из лимита Токио, а не зарубежного сервера. Кроме того, накладные расходы WireGuard на каждый пакет также являются тарифицируемым трафиком. Для полных пакетов размером 1500 байт они составляют около 4 процентов, что обычно незаметно. Однако при использовании протоколов с интенсивным обменом мелкими данными, где полезная нагрузка составляет 100 байт, каждый пакет занимает в сети 160 байт, что означает накладные расходы в 60 процентов от объема данных.

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

MTU и фрагментация нарушают передачу больших объемов данных, но не малых

MTU (maximum transmission unit) — это максимальный размер пакета, который может передать сетевой интерфейс. WireGuard упаковывает ваш пакет во внешний IP-заголовок, UDP-заголовок, собственный заголовок сообщения и тег аутентификации.

[
  {
    "label": "1500 byte path, IPv4 outer",
    "overhead_bytes": 60,
    "tunnel_mtu": 1440
  },
  {
    "label": "1500 byte path, IPv6 outer",
    "overhead_bytes": 80,
    "tunnel_mtu": 1420
  },
  {
    "label": "1492 byte path, IPv4 outer",
    "overhead_bytes": 60,
    "tunnel_mtu": 1432
  },
  {
    "label": "1400 byte path, IPv4 outer",
    "overhead_bytes": 60,
    "tunnel_mtu": 1340
  }
]

При использовании IPv4 накладные расходы составляют 60 байт, поэтому при стандартном пути в 1500 байт внутри туннеля остается 1440 байт. Для IPv6 это значение составляет 80 байт. wg-quick по умолчанию устанавливает значение интерфейса 1420, так как всегда вычитает большее число — это безопасный, хотя и не самый оптимальный вариант. Если какой-либо узел между вашими провайдерами поддерживает размер менее 1500 байт, требуемое число будет еще меньше: путь в 1400 байт оставляет только 1340 байт.

Симптомы этой проблемы специфичны и часто вводят в заблуждение. ping работает. SSH подключается, ввод текста кажется нормальным. Затем apt update зависает, большой HTTPS-ответ «замирает» после получения заголовков, или копирование файла останавливается через несколько килобайт. Малые пакеты проходят, а большие — нет. Ядро должно определять ограничение через ICMP-сообщение «fragmentation needed», но многие сети блокируют ICMP. В результате отправитель не получает уведомление и продолжает повторно передавать пакет, который никогда не дойдет до получателя.

Найдите реальный предел вручную. Следующая команда отправляет полезную нагрузку в 1472 байта, что вместе с 8 байтами ICMP-заголовка и 20 байтами IP-заголовка дает ровно 1500 байт, при этом фрагментация запрещена:

ping -M do -s 1472 -c 2 198.51.100.20

Если команда завершается ошибкой, уменьшите значение вдвое и попробуйте 1372, затем 1272. Ограничение на вашем собственном интерфейсе даст ответ немедленно:

ping: local error: message too long, mtu=1500

Ограничение на пути следования пакета даст такой ответ, где число в сообщении и будет искомым значением:

From 192.0.2.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)

Возьмите наибольшее значение полезной нагрузки, при котором команда выполняется успешно, прибавьте 28, чтобы получить MTU пути, вычтите 60, а затем внесите результат в секцию [Interface] на обоих узлах:

MTU = 1340

Перезапустите соединение с помощью sudo systemctl restart wg-quick@wg0 и повторите тест внутри туннеля, используя ping -M do -s 1312 -c 2 10.83.7.2. Если вы маршрутизируете целую подсеть через канал, а не только два адреса туннеля, добавьте TCP MSS (maximum segment size) clamping для исходящего трафика. Это необходимо, так как машины за вашими узлами не могут самостоятельно узнать MTU вашего туннеля.

Внутренний DNS для взаимодействия двух серверов

Не используйте overlay-адреса в конфигурации приложений. Присвойте машинам имена. Для двух серверов использование /etc/hosts на каждом из них является надежным решением, не имеющим собственных точек отказа:

10.83.7.1 tokyo.internal tokyo
10.83.7.2 batch.internal batch

Используйте суффикс, который вам принадлежит, или явно частный суффикс. Не выдумывайте суффикс, который в будущем может стать реальным доменом верхнего уровня, иначе ваши внутренние имена начнут указывать на чужой сервер. Если у вас более четырех или пяти машин, запустите dnsmasq на одном из серверов, привяжите его к overlay-адресу этой машины и укажите его остальным через drop-in файл /etc/systemd/resolved.conf.d/. Этот резолвер станет критической зависимостью: если сервер с ним выйдет из строя, разрешение имен на других машинах прекратится, поэтому сохраняйте записи /etc/hosts в качестве резервных. Если концепции резолверов и типов записей для вас новы, что такое DNS и как происходит разрешение имен — это краткое изложение данной темы.

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

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

Отклонение времени проявляется как проблемы, которые не выглядят связанными с часами. Проверка TLS (transport layer security) завершается ошибкой "certificate is not yet valid" на сервере, где часы отстают. JWT (JSON web token), созданный на одном сервере, отклоняется другим, так как его поле nbf указывает на будущее. Строки логов с двух машин перемешиваются в неверном порядке, поэтому хронология инцидентов становится недостоверной. Установите chrony на обе машины:

sudo apt install -y chrony
chronyc tracking
chronyc sources -v

chronyc tracking выводит строку System time, содержащую текущее смещение. Значение менее миллисекунды является нормой. Любое отклонение более секунды требует немедленного внимания. На японском сервере близкий источник сокращает путь: добавьте server ntp.nict.jp iburst в /etc/chrony/chrony.conf, где ntp.nict.jp — это публичный сервис, поддерживаемый Национальным институтом информационных и коммуникационных технологий Японии. Для зарубежного сервера укажите источник, расположенный поблизости, по той же причине, затем выполните sudo systemctl restart chrony и снова проверьте chronyc sources -v на наличие источника, помеченного ^*.

Ключи, которыми вы управляете, или сервис координации, от которого вы зависите

Приведенная выше конфигурация не использует сторонние сервисы. Вы храните оба закрытых ключа, и связь работает, пока оба узла активны. Плата за это — необходимость ведения учета. Каждая новая машина означает редактирование блока [Peer] на всех остальных машинах, а ротация ключей — это ручная работа, о которой нужно не забыть. Для двух или трех машин это не проблема. При пятнадцати узлах это приводит к дублированию адресов и устаревшим записям о пирах.

Tailscale и NetBird переносят этот учет на сервер координации. Оба решения используют WireGuard в качестве уровня передачи данных, добавляя поверх него распределение ключей, выделение адресов, обход NAT (network address translation) и правила доступа. Headscale — это координатор с открытым исходным кодом, который вы можете развернуть самостоятельно для клиентов Tailscale. Ваш трафик по-прежнему передается напрямую между двумя узлами, и координатор никогда не хранит ключи, которыми он зашифрован, но пока координатор недоступен, новые пиры не могут подключиться, а ключи не могут быть обновлены. Выбор между самостоятельным запуском WireGuard и использованием координатора в основном сводится к тому, сколько машин вы планируете иметь через год. Если вы хотите, чтобы зарубежный узел имел доступ ко всему диапазону частных адресов за домашним узлом, а не к одному адресу, это называется анонсированием подсети с вашими частными диапазонами, и выполнение этой задачи вручную означает сопоставление записей AllowedIPs и настроек net.ipv4.ip_forward = 1 на узле, который выполняет пересылку трафика.

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

Некоторые процессы не выдерживают сетевого соединения, и никакая настройка не решает эту проблему. Синхронная реплика базы данных, первичный узел которой ожидает подтверждения записи, добавляет полное время RTT к каждой операции записи. Приложение, запрашивающее базу данных на удаленной стороне, тратит один RTT на каждый запрос, что на графике выше выражается в секундах. Сетевая файловая система, такая как NFS (network file system), при задержке в 100 мс становится непригодной для использования, так как операции с метаданными состоят из множества мелких запросов, и пользователь вынужден ждать завершения каждого из них. Служба координации кластера, например etcd, начинает перевыборы лидера при потере сигналов heartbeat, что само по себе происходит из-за длинного или нестабильного сетевого пути.

То, что хорошо поддается разделению, обладает одним общим свойством: оно асинхронно, поэтому одна сторона никогда не ждет другую. Пакетная обработка, ночное резервное копирование, CI (continuous integration) сборщики, отправка логов, транскодирование медиафайлов и воркеры очередей, которые забирают задачи, — все они терпимы к длинному каналу связи, так как каждая единица работы содержит всё необходимое для воркера. Именно в этом заключается смысл использования сервера в Токио для пользователей и более дешевого сервера за рубежом для тяжелых задач. Дешевый зарубежный сервер часто работает на архитектуре ARM, а не x86, поэтому хорошо ли ваша пакетная нагрузка работает на ARM стоит выяснить до покупки, так как каждый контейнерный образ, от которого вы зависите, должен существовать для этой архитектуры.

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

FAQ

Можно ли использовать частную сеть провайдера для доступа к серверу у другого провайдера?

Нет. Частная сеть провайдера маршрутизируется только внутри его собственного центра обработки данных, а адрес 10.x.x.x в ней является частным адресом согласно RFC 1918, который не пересылает ни один маршрутизатор в публичном интернете. Пакет, отправленный на такой адрес извне, отбрасывается первым же маршрутизатором, который его получит. Чтобы связать двух провайдеров, необходимо самостоятельно создать зашифрованную оверлейную сеть поверх публичного интернета, обычно с помощью WireGuard, запущенного на обоих узлах, где каждый из них указан в качестве пира для другого.

Какую задержку вносит туннель WireGuard между двумя VPS?

Практически никакую. Шифрование и дешифрование занимают значительно меньше миллисекунды на пакет на любом современном процессоре. То, что вы измеряете, — это расстояние между двумя дата-центрами и маршрут, который выбирают провайдеры между ними. Проверьте это с помощью ping -c 100 через туннель и ориентируйтесь на среднее значение и отклонение, а не на единичный замер. Если RTT через туннель значительно хуже, чем RTT между двумя публичными адресами, ищите проблему в загрузке процессора или потере пакетов, а не в настройках WireGuard.

Почему при передаче больших объемов данных через туннель соединение зависает, хотя ping продолжает работать?

Потому что пакеты слишком велики для данного маршрута, а отправитель не получает уведомления об этом. WireGuard добавляет 60 байт поверх IPv4, поэтому при MTU 1500 байт внутри туннеля передается не более 1440 байт. Если какой-либо узел между провайдерами поддерживает меньший размер, пакеты с превышением размера отбрасываются, а сети, блокирующие ICMP, не пропускают сообщение «fragmentation needed» до отправителя, из-за чего он продолжает бесконечные попытки повторной передачи. Найдите рабочий размер с помощью ping -M do -s 1472 <peer public address>, уменьшайте его до тех пор, пока передача не станет успешной, а затем установите MTU в секции [Interface] на обоих узлах.

Нужно ли платить за исходящий трафик у обоих провайдеров при использовании туннеля?

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

Стоит ли запускать приложение у одного провайдера, а его базу данных — у другого?

Не в том случае, если пользователь ожидает ответа. Каждый запрос требует одного цикла обмена данными (round trip), поэтому страница, выполняющая 200 запросов, потребует 200 циклов обмена до того, как начнется какая-либо обработка данных, что на межконтинентальном канале может занять секунды. Держите приложение и его базу данных на одной стороне. На другую сторону отправляйте задачи, которые не блокируют работу пользователя: резервное копирование, пакетные задания, отправку логов и сборку проектов.