Приватная сеть между своими серверами: зачем она нужна и как не выпустить её в интернет

MAATRIX

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

Зачем вообще выносить трафик между серверами в отдельную сеть

Три причины обычно идут в связке, но по значимости они не равны.

Первая — задержка и число промежуточных узлов. Пакет от приложения к базе через публичный интернет проходит тот же путь, что и трафик до случайного постороннего адреса: через аплинк провайдера, возможно через несколько транзитных сетей, — даже если оба сервера стоят в одной стойке одного дата-центра. Приватная сеть внутри одной локации обычно означает прямой путь через внутренний коммутатор, без выхода на публичные маршруты. Дело не столько в борьбе за миллисекунды (для соседних серверов разница может быть небольшой), сколько в отказе от лишней зависимости: публичный маршрут между двумя сетями строится по BGP-политикам и договорам операторов, а не по карте, и может со временем измениться. От этой изменчивости приватная сеть внутри одной инфраструктуры не зависит.

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

Третья причина — главная, ради неё стоит городить приватную сеть, даже если первые две не играют роли. Часть сервисов вообще не должна быть доступна из интернета: сама база данных, внутренний API, кеш вроде Redis, панель очереди задач, service mesh между микросервисами. Если такой сервис слушает только приватный интерфейс, поверхность атаки для него — уже не «весь интернет плюс уязвимость в аутентификации», а «нужно сначала оказаться внутри приватной сети». Это не отменяет нормальные пароли и обновления, но убирает самый массовый вектор — автоматическое сканирование диапазонов IP ботами, которые ищут открытые базы и админки без целенаправленной атаки именно на вас.

Способ 1: приватная сеть провайдера — VLAN или выделенный внутренний интерфейс

Многие хостеры дают серверам, кроме публичного IP, ещё один интерфейс в изолированной сети — называют её private network, internal network или просто «второй интерфейс». Технически за этим обычно стоит VLAN (виртуальная локальная сеть, отделяющая трафик клиентов друг от друга на уровне коммутатора) либо отдельная подсеть, недоступная снаружи дата-центра по определению — маршрутизатор её просто не анонсирует наружу.

Общая идея настройки со стороны сервера простая: провайдер выдаёт второй интерфейс с адресом из приватного диапазона (10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16), и дальше сервисы настраиваются слушать именно этот адрес, а не публичный. Конкретные шаги активации отличаются от провайдера к провайдеру, описывать интерфейс конкретной панели здесь смысла нет — сути это не меняет.

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

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

Если серверы у разных провайдеров или в разных дата-центрах — приватной сети провайдера между ними физически не существует, и нужен один из следующих вариантов.

Способ 2: VPN между серверами — WireGuard как современный выбор

Когда серверы физически не в одной приватной сети провайдера (разные хостеры, страны, облака), между ними поднимают VPN-туннель: он создаёт логическую приватную сеть поверх обычного интернет-соединения, шифруя трафик и выдавая каждому серверу «виртуальный» IP из отдельного диапазона.

Для связки сервер-сервер чаще всего выбирают WireGuard — он работает в ядре Linux (начиная с 5.6, для старых ядер есть модуль или userspace-реализация), использует современную криптографию без выбора шифронаборов и заметно проще OpenVPN: конфиг — пара ключей и адресов, а не десятки параметров. Общая идея настройки для связки двух серверов:

• на каждом сервере генерируется пара ключей (приватный остаётся на сервере, публичный передаётся второй стороне);
• поднимается интерфейс wg0 с приватным IP из выделенного для туннеля диапазона (10.10.0.1/24 на первом сервере, 10.10.0.2/24 на втором);
• в конфиге каждой стороны указывается публичный ключ и внешний адрес (endpoint) другой стороны;
• сервисы на обоих серверах настраиваются слушать IP из диапазона 10.10.0.0/24, а не публичный адрес.

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

Для двух серверов схема «точка-точка» работает без проблем. Когда серверов больше трёх-четырёх и нужна полносвязная топология, поддерживать конфиг WireGuard руками становится утомительно — растёт число peer-записей, которые нужно синхронизировать при каждом изменении; здесь имеет смысл смотреть в сторону mesh-надстроек, автоматизирующих распространение ключей и маршрутов между узлами, а не держать полносвязную топологию вручную.

Способ 3: overlay-сети — сеть поверх сети для контейнеров и кластеров

Третий вариант ближе к прикладному уровню, чем к сетевому: overlay-сеть поднимает не сетевое оборудование и не VPN-демон сам по себе, а платформа оркестрации — Docker Swarm, Kubernetes с CNI-плагином, HashiCorp Nomad с Consul Connect и подобные. Технически overlay почти всегда тоже строится поверх туннелирования (часто VXLAN или WireGuard как транспорт у некоторых CNI-плагинов), но администратору она видна не как интерфейс, который нужно настраивать руками, а как декларативная сущность из манифеста — платформа сама маршрутизирует трафик между узлами.

Общая идея, без привязки к конкретному продукту как единственному варианту: overlay-сеть даёт контейнерам на разных серверах кластера обращаться друг к другу по внутреннему DNS-имени сервиса, как будто они в одной локальной сети, независимо от того, на каком физическом узле контейнер запущен сейчас. Это удобно, когда состав узлов и нагрузка на них меняются динамически — то есть в оркестраторах, а не для пары статичных серверов, где WireGuard или приватная сеть провайдера обычно проще в обслуживании.

Если вы используете Docker без оркестратора, стоит понимать разницу между обычной сетью bridge для контейнеров на одном хосте и overlay-сетью для контейнеров на разных хостах — три типа docker-сетей разобраны в статье про типы docker-сетей: bridge, host, overlay. Важный нюанс: overlay-сеть сама по себе не заменяет VPN между серверами дата-центра — под ней всё равно должен быть какой-то транспорт (тот же VPN или приватная сеть провайдера), просто он обычно не виден разработчику.

Частая ошибка: приватная сеть настроена, а сервис всё равно виден снаружи

Это самая распространённая причина, почему «мы настроили приватную сеть» на практике не защищает вообще ничего.

Типичная последовательность: администратор поднимает WireGuard или получает приватный интерфейс от провайдера, радуется адресу 10.10.0.2 и запускает сервис (например, PostgreSQL или Redis) с настройками по умолчанию, которые слушают 0.0.0.0 — все интерфейсы сразу, публичный в том числе. Наличие приватного адреса ничего не меняет для сервиса, который явно не сконфигурирован слушать конкретный IP: он как слушал все интерфейсы, так и продолжает, просто теперь их два вместо одного.

Вторая часть ошибки — файрвол. Если UFW, firewalld или облачная security group не закрывают явно порт сервиса на публичном интерфейсе, а полагаются на то, что «он же теперь и так в приватной сети», сервис остаётся доступен снаружи ровно как и до появления приватной сети — просто у администратора теперь ложное чувство защищённости. Похожая по механике ситуация, когда firewall формально настроен правильно, а сервис через Docker всё равно виден снаружи из-за того, как трафик проходит через цепочки iptables, разобрана в статье «Docker пробил ваш firewall, почему порт всё-таки открыт». Смежная ошибка — выключить firewall целиком «на время отладки» и забыть включить обратно — разобрана в статье про антипаттерн firewall «разрешить всё».

Итог один: приватная сеть существует, адрес выделен, но реальная защита сервиса нулевая — она никогда не опиралась на саму приватную сеть, а полагалась на предположение о ней.

Как проверить, что приватный сервис действительно не виден снаружи

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

1. Explicit-биндинг сервиса на приватный IP, а не на все интерфейсы. Это не файрвол, а конфигурация самого сервиса — самый надёжный слой: если сервис физически не слушает публичный интерфейс, вопрос «а что если файрвол упадёт» не встаёт вообще. Примеры:

# PostgreSQL, postgresql.conf
listen_addresses = '10.10.0.1'

# Redis, redis.conf
bind 10.10.0.1 127.0.0.1

# docker-compose.yml — публикация порта только на приватный IP хоста
services:
  db:
    image: postgres:16
    ports:
      - "10.10.0.1:5432:5432"

Проверить, что сервис реально слушает нужный адрес, можно прямо на сервере:

ss -tlnp | grep 5432

Строка LISTEN 0 244 10.10.0.1:5432 говорит, что сервис привязан к конкретному адресу. Строка LISTEN 0 244 0.0.0.0:5432 — тревожный сигнал: сервис слушает всё, и дальше вся защита держится исключительно на файрволе.

2. Файрвол как второй, независимый слой (defense in depth). Даже если сервис корректно забиндлен на приватный адрес, лишним не будет явное правило, запрещающее доступ к его порту с публичного интерфейса — на случай ошибки конфигурации, обновления, которое сбросит bind к дефолту, или временного открытия порта кем-то другим для отладки:

ufw deny in on eth0 to any port 5432
ufw allow in on wg0 to any port 5432

где eth0 — публичный интерфейс, а wg0 — интерфейс приватной сети/VPN. Явное разрешение для приватного интерфейса и явный запрет для публичного — это и есть defense in depth: два независимых слоя, каждый может подстраховать другой.

3. Внешняя проверка — сканирование собственного сервера снаружи. Ни бинд на приватный адрес, ни правило файрвола нельзя считать подтверждёнными, пока результат не проверен с точки зрения внешнего наблюдателя. Проверка curl localhost:5432 ничего не говорит о видимости порта из интернета: локальные проверки почти всегда успешны независимо от состояния файрвола для внешнего трафика. Правильная проверка — с другой машины, из другой сети:

nmap -p 5432,6379,27017,9200 <публичный-ip-вашего-сервера>

Если порт помечен filtered или closed — снаружи он недоступен. Если open — вы нашли ровно ту ситуацию, от которой должна была защищать приватная сеть, и стоит вернуться к пунктам 1 и 2. Такую проверку полезно делать не разово, а регулярно — как минимум после разворачивания нового сервиса или изменения сетевой конфигурации.

Проверять стоит и после обновлений: пакетный менеджер иногда возвращает конфиг к значениям по умолчанию, если свои настройки не вынесены в отдельный override-файл — тогда bind на приватный адрес может незаметно откатиться на 0.0.0.0 при следующем apt upgrade, а внешний скан — единственный способ поймать это раньше, чем кто-то другой.

Итог

Приватная сеть между своими серверами — не единственная настройка «включил и забыл», а сочетание трёх независимых вещей: правильно выбранный транспорт (VLAN провайдера, WireGuard или overlay — под задачу), сервис, явно забиндленный на приватный адрес, и файрвол, который не полагается на то, что «сеть и так приватная». Каждый слой способен подстраховать, если откажет другой, но ни один не заменяет остальные два. Дешевле всего проверить это не постфактум после инцидента, а сразу после разворачивания — командой ss -tlnp на сервере и nmap с внешней точки.

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