Частная сеть между серверами

Место в цепочке

Что предыдущие звенья обязаны обеспечить:

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

Что этот документ оставляет следующему звену:

• адрес каждой машины в туннеле — именно он подставляется в upstream шлюза и в переменные окружения вида CORE_SERVICE_ADDRESS;
• контейнер vpn_client в Compose-файле микросервиса — тот самый, к которому сетевой контур подключает nginx через network_mode: "service:vpn_client";
• непересекающийся план подсетей, на который опираются ipam-блоки Compose.

Порядок принципиален в трёх местах:

1. Ключи создаются до конфигурации: в wg0.conf подставляется значение закрытого ключа, а не ссылка на файл.
2. Блок [Peer] появляется на концентраторе до первого запуска клиента. Рукопожатие с неизвестным ключом отбрасывается молча — на клиенте это выглядит так же, как закрытый порт, и разбирать придётся две причины сразу.
3. UDP-порт открывается до запуска клиента — по той же причине.

Зачем частная сеть

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

Это не отменяет проверок на входе: nginx микросервиса и шлюз остаются на своих местах. Частная сеть убирает обходной путь, а не заменяет то, что стоит на пути основном.

Схема адресации

WireGuard адреса не раздаёт: DHCP в нём нет. Адрес пира записан в двух местах — в его собственном [Interface] Address и на концентраторе в AllowedIPs его блока [Peer]. Расхождение между ними означает, что пакеты пира отбрасываются как пришедшие с чужого адреса. Поэтому адрес назначается один раз и фиксируется в журнале.

Журнал соответствия «адрес — машина» ведётся в одном месте: комментарием над каждым блоком [Peer] в wg0.conf концентратора. Отдельный файл со списком расходится с реальностью на первой же правке.

Весь контур живёт внутри 10.0.0.0/8, разделённого на непересекающиеся планы:

Пример на две машины:

Внутри моста последний октет закрепляется за ролью: .10 — контейнер клиента туннеля, .100 — backend. Это соглашение, а не требование протокола; его смысл в том, что адрес в Compose-файле читается без сверки с чужой конфигурацией.

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

Адреса локальных мостов, которые встречаются в сетевом контуре (10.0.0.100 для vpn_net и 10.0.1.100 для host_net), — это адреса backend на двух мостах одного сервера; конкретные значения задаёт блок ipam его Compose-файла. Жёсткое требование одно: подсети мостов не пересекаются ни между собой, ни с планом туннеля.

Почему на концентраторе у пира всегда /32. AllowedIPs в WireGuard работает в обе стороны: для исходящих пакетов это таблица маршрутов, для входящих — фильтр допустимых адресов отправителя. Пир с AllowedIPs = 10.0.0.0/24 получил бы право отправлять пакеты от имени любой машины контура. Маска /32 оставляет за пиром ровно один адрес.

Шаг 1. Пакеты и ключи на концентраторе

sudo apt-get update
sudo apt-get install -y wireguard wireguard-tools

sudo install -d -m 700 /etc/wireguard
wg genkey | sudo tee /etc/wireguard/server_private.key >/dev/null
sudo chmod 600 /etc/wireguard/server_private.key
sudo sh -c 'wg pubkey < /etc/wireguard/server_private.key > /etc/wireguard/server_public.key'
sudo chmod 644 /etc/wireguard/server_public.key

sudo ls -l /etc/wireguard

Ожидается: server_private.key с правами -rw-------, server_public.key с правами -rw-r--r--. Права на закрытый ключ шире 600 — исправьте до продолжения: файл читают все пользователи машины.

Закрытый ключ не покидает машину, на которой создан. Наружу отдаётся только содержимое server_public.key.

Шаг 2. Конфигурация wg0.conf на концентраторе

sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <содержимое /etc/wireguard/server_private.key>

PostUp   = iptables -I FORWARD 1 -i wg0 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -o wg0 -j ACCEPT
EOF

sudo chmod 600 /etc/wireguard/wg0.conf

Что означает каждая строка:

Правило пересылки ставится первым в цепочке (-I FORWARD 1). В FORWARD ufw держит собственные переходы; правило, добавленное в конец (-A), срабатывает или нет в зависимости от их содержимого, а поставленное первым — не зависит.

Пересылка разрешается только между пирами (-i wg0 -o wg0). Выхода из туннеля в интернет здесь нет и NAT не настраивается: это частная сеть между серверами, а не выходной узел.

SaveConfig не включается. С ним wg-quick down перезаписывает файл своим представлением состояния и удаляет комментарии — вместе с журналом соответствия адресов машинам.

sudo grep -c '^PrivateKey = <' /etc/wireguard/wg0.conf   # ожидается: 0

Ожидается: 0 — заполнитель заменён на значение ключа. Единица означает, что в файле остался текст <содержимое ...>, и интерфейс не поднимется.

Шаг 3. Пересылка пакетов

Без пересылки концентратор отвечает на обращения к своему адресу, но не передаёт пакеты между двумя пирами: сервер шлюза увидит 10.0.0.1 и не увидит 10.0.0.10.

sudo tee /etc/sysctl.d/99-wireguard.conf >/dev/null <<'EOF'
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

sysctl net.ipv4.ip_forward     # ожидается: net.ipv4.ip_forward = 1

Отдельный файл в /etc/sysctl.d/ вместо правки /etc/sysctl.conf — чтобы настройку было видно как принадлежащую этому документу и чтобы снятие сводилось к удалению одного файла.

Шаг 4. Открыть один порт UDP

sudo ufw allow 51820/udp
sudo ufw status verbose

Ожидается строка 51820/udp ALLOW IN Anywhere и отсутствие других новых разрешений. TCP на этом порту не открывается: WireGuard работает только по UDP, разрешение TCP не даёт ничего, кроме дополнительной открытой точки.

Шаг 5. Запуск и автозапуск

sudo systemctl enable --now wg-quick@wg0

Команда wg-quick up wg0 делает то же самое разово, но не переживает перезагрузку, и после неё systemctl start завершается ошибкой wg0 already exists. Используйте один способ — через systemd.

sudo wg show

interface: wg0
  public key: <открытый ключ концентратора>
  private key: (hidden)
  listening port: 51820

Пиров пока нет — это состояние соответствует конфигурации.

sudo ss -ulpn | grep 51820

Ожидается строка вида UNCONN 0 0 0.0.0.0:51820 0.0.0.0:* без имени процесса: сокет держит модуль ядра, а не пользовательская программа. Пустая колонка процесса здесь — норма, а не признак неисправности.

ip addr show wg0        # ожидается: inet 10.0.0.1/24, состояние UP

Шаг 6. Ключи и адрес для второго сервера

Выполняется на сервере микросервиса — закрытый ключ создаётся там, где будет использоваться, и по сети не передаётся:

sudo apt-get update
sudo apt-get install -y wireguard wireguard-tools

sudo install -d -m 700 /etc/wireguard
wg genkey | sudo tee /etc/wireguard/private.key >/dev/null
sudo chmod 600 /etc/wireguard/private.key
sudo sh -c 'wg pubkey < /etc/wireguard/private.key > /etc/wireguard/public.key'
sudo cat /etc/wireguard/public.key

Содержимое public.key переносится на концентратор. Обратно с концентратора берётся содержимое server_public.key.

Дальше — на концентраторе. Блок пира дописывается в конец wg0.conf:

# сервер микросервиса
[Peer]
PublicKey = <открытый ключ сервера микросервиса>
AllowedIPs = 10.0.0.10/32

Применение без разрыва уже установленных соединений:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

wg-quick strip убирает из файла директивы, которые понимает только wg-quick (Address, PostUp, DNS), и отдаёт остальное wg syncconf. Тот приводит состояние интерфейса к файлу, не пересоздавая его. Пара wg-quick down / wg-quick up дала бы тот же результат, но оборвала бы все остальные пиры.

sudo wg show wg0 allowed-ips

Ожидается строка с открытым ключом сервера микросервиса и 10.0.0.10/32. Обращений от пира ещё нет — рукопожатие появится после шага 7.

Шаг 7. Клиент на сервере микросервиса

sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'
[Interface]
Address = 10.0.0.10/24
PrivateKey = <содержимое /etc/wireguard/private.key>

[Peer]
PublicKey = <содержимое server_public.key концентратора>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25
EOF

sudo chmod 600 /etc/wireguard/wg0.conf
sudo systemctl enable --now wg-quick@wg0

Значение AllowedIPs определяет и маршруты: wg-quick добавляет маршрут на каждую подсеть из этого списка. Указание 0.0.0.0/0 увело бы в туннель в том числе SSH-сессию, по которой идёт настройка.

sudo wg show

interface: wg0
  public key: <открытый ключ этого сервера>
  private key: (hidden)
  listening port: <выбран ядром>

peer: <открытый ключ концентратора>
  endpoint: <публичный адрес концентратора>:51820
  allowed ips: 10.0.0.0/24
  latest handshake: 12 seconds ago
  transfer: 1.98 KiB received, 3.12 KiB sent

Ключевая строка — latest handshake. Её отсутствие означает, что рукопожатие не состоялось, и дальше идти нельзя.

ip route get 10.0.0.1

Ожидается: 10.0.0.1 dev wg0 src 10.0.0.10. Вывод с другим интерфейсом означает пересечение подсетей — см. отказы.

ping -c 3 10.0.0.1                   # ожидается: 3 packets transmitted, 3 received
ping -M do -s 1392 -c 3 10.0.0.1     # ожидается: 3 received, без "Frag needed"

Второй ping проверяет проходимость пакета полного размера: 1392 байта данных плюс заголовки дают 1420 — это MTU интерфейса wg0 по умолчанию. Первая команда прошла, вторая нет — раздел про MTU в отказах.

sudo wg show wg0 latest-handshakes    # ожидается: у пира не 0
ping -c 3 10.0.0.10                   # ожидается: 3 received

Шаг 8. Клиент внутри контейнера рядом с сервисом

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

vpn/Dockerfile:

FROM linuxserver/wireguard:latest

ENV PUID=1000 \
    PGID=1000 \
    TZ=UTC

# образ обращается к этому каталогу при старте, проверяя наличие модуля ядра
RUN mkdir -p /lib/modules && chmod 755 /lib/modules

Конфигурация в образ не копируется, а монтируется: слой образа с закрытым ключом попадает в кэш сборки и в реестр, если образ туда отправляют. Файл vpn/wg0.conf — тот же, что в шаге 7, с адресом этого сервера; в системе контроля версий он не хранится.

Compose-файл микросервиса:

networks:
  host_net:
    driver: bridge
    ipam: { config: [{ subnet: 10.20.2.0/24 }] }
  vpn_net:
    driver: bridge
    ipam: { config: [{ subnet: 10.21.2.0/24 }] }

services:
  vpn_client:
    build: { context: ., dockerfile: vpn/Dockerfile }
    networks:
      vpn_net: { ipv4_address: 10.21.2.10 }
    cap_add: ["NET_ADMIN"]
    devices: ["/dev/net/tun:/dev/net/tun"]
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    volumes:
      - ./vpn/wg0.conf:/config/wg0.conf:ro
    restart: unless-stopped
    command: >
      sh -c "iptables -t nat -A POSTROUTING -s 10.21.2.0/24 -o wg0 -j MASQUERADE
             && tail -f /dev/null"

  backend:
    build: { context: ., dockerfile: source/Dockerfile }
    networks:
      host_net: { ipv4_address: 10.20.2.100 }
      vpn_net:  { ipv4_address: 10.21.2.100 }
    expose: ["8000"]
    depends_on: [vpn_client]

Вход в микросервис со стороны туннеля — отдельный nginx, подключённый к сетевому пространству клиента (network_mode: "service:vpn_client"). Он описан в сетевом контуре и здесь не повторяется.

Что делает command

Правило MASQUERADE переписывает адрес отправителя у пакетов, уходящих из моста vpn_net в туннель. Без него сервер на другом конце получил бы пакет с адресом 10.21.2.100 — адресом локального моста чужой машины, маршрута к которому у него нет, и ответ никуда бы не ушёл. С правилом обращения приходят с адреса 10.0.0.10, то есть с адреса этого сервера в туннеле.

Правило ссылается на wg0, поэтому может быть добавлено только после подъёма интерфейса. Инициализация образа поднимает wg0 из /config/wg0.conf до запуска команды, отдельный вызов wg-quick не нужен. tail -f /dev/null удерживает команду запущенной: её завершение остановило бы контейнер, а вместе с ним и сетевое пространство, в котором живёт nginx.

Права: почему NET_ADMIN, а не privileged

privileged: true выдаёт все возможности сразу, доступ ко всем устройствам хоста и ослабляет профили seccomp и AppArmor. Из этого набора клиенту нужны две позиции из таблицы выше.

Возможность SYS_MODULE в список не входит намеренно: она нужна только для загрузки модуля ядра изнутри контейнера и равносильна праву загрузить в ядро хоста произвольный код. Модуль wireguard входит в ядро с версии 5.6; если он не загружен, загрузите его на хосте:

sudo modprobe wireguard
echo wireguard | sudo tee /etc/modules-load.d/wireguard.conf

Исходящие обращения от backend

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

  backend:
    cap_add: ["NET_ADMIN"]
    command: >
      sh -c "ip route replace 10.0.0.0/24 via 10.21.2.10
             && exec python -m source.app.main"

Возможность NET_ADMIN здесь выдаётся ради одной команды ip route. Микросервису, который никуда не обращается сам, ни маршрут, ни возможность не нужны — не добавляйте их «на всякий случай».

docker compose up -d
docker compose exec vpn_client wg show

Ожидается тот же вывод, что в шаге 7: интерфейс, пир концентратора и непустой latest handshake.

docker compose exec vpn_client ip route          # ожидается строка: 10.0.0.0/24 dev wg0
docker compose exec vpn_client iptables -t nat -L POSTROUTING -n
docker compose exec vpn_client ping -c 3 10.0.0.1

Ожидается во второй команде правило MASQUERADE ... 10.21.2.0/24 ... на интерфейсе wg0, в третьей — три полученных пакета. Ответ ping: not found означает только, что в образе нет этой программы: тогда признак связности — растущие счётчики transfer в wg show при повторном вызове.

Если настраивали маршрут для backend:

docker compose exec backend ip route get 10.0.0.1   # ожидается: via 10.21.2.10

Клиент из шага 7 и клиент в контейнере — два способа сделать одно и то же на одной машине. Работать должен один: два интерфейса wg0 с одним и тем же адресом пира дадут отбрасывание пакетов на концентраторе. Переходя на контейнер, снимите хостовый клиент: sudo systemctl disable --now wg-quick@wg0.

Проверка всей цепочки

Снизу вверх, с сервера шлюза:

# 1. пир поднят и обменивается данными
sudo wg show                                   # ожидается: latest handshake, ненулевой transfer

# 2. адрес второй машины отвечает
ping -c 3 10.0.0.10                            # ожидается: 3 received

# 3. вход в микросервис отвечает по адресу туннеля
curl -sf http://10.0.0.10:8000/health && echo OK

# 4. адрес микросервиса недоступен снаружи контура — с машины вне туннеля
curl -m 5 -I http://10.0.0.10:8000/health      # ожидается: таймаут

Типичные отказы

Отзыв ключа

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

# на концентраторе: убрать блок [Peer] со старым ключом из /etc/wireguard/wg0.conf
sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 allowed-ips        # ожидается: старого ключа в выводе нет

# на пире: новая пара
wg genkey | sudo tee /etc/wireguard/private.key >/dev/null
sudo chmod 600 /etc/wireguard/private.key
sudo sh -c 'wg pubkey < /etc/wireguard/private.key > /etc/wireguard/public.key'

# на концентраторе: новый блок [Peer] с тем же адресом, снова syncconf

Что нужно сделать дополнительно, если ключ утёк через образ: пересобрать образ без старого файла и удалить прежние слои (docker image prune -a на машинах, где образ есть). Слой с ключом остаётся в кэше сборки и в реестре после того, как из репозитория файл убран.

Откат и снятие

Снять клиента в контейнере:

docker compose stop vpn_client
docker compose rm -f vpn_client

Сервисы, у которых network_mode: "service:vpn_client", останавливаются вместе с ним: их сетевое пространство принадлежит удалённому контейнеру. Уберите эти сервисы из Compose-файла или переключите их на локальный вход — в сетевом контуре для этого рядом с vpn_nginx лежит закомментированный host_nginx.

Снять клиента на хосте:

sudo systemctl disable --now wg-quick@wg0
ip link show wg0        # ожидается: Device "wg0" does not exist

Отозвать ключ на концентраторе — по разделу «Отзыв ключа»: блок [Peer] удаляется, wg syncconf применяет; после этого машина с этим ключом в туннель не входит.

Полностью снять концентратор:

sudo systemctl disable --now wg-quick@wg0
sudo ufw delete allow 51820/udp
sudo rm /etc/sysctl.d/99-wireguard.conf && sudo sysctl --system

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

Что не удаляется перечисленными командами:

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