Tailscale или WireGuard: mesh-VPN против классической схемы

MAATRIX

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

Что вообще значит «mesh» и чем он отличается от классики

Классическая схема WireGuard — это звезда: один VPS с публичным IP выступает сервером, к нему подключаются клиенты. Каждый клиент видит сервер и трафик до других клиентов (если он вообще нужен) идёт через него же. Конфиг простой: один [Interface] и один-два [Peer] на клиенте.

Mesh-топология — это когда каждый узел может установить прямое соединение с любым другим, без обязательного прохождения через центральный сервер. В чистом WireGuard mesh тоже возможен — просто конфиг каждого узла содержит [Peer]-секцию на каждого другого участника. При N узлах это N×(N-1)/2 связей, которые нужно поддерживать вручную: смена IP у одного узла — правка конфигов у всех остальных.

Tailscale строит mesh поверх WireGuard, но добавляет control plane — координационный сервер, который знает актуальные адреса, ключи и статус всех узлов сети (tailnet) и раздаёт их автоматически. Клиент не редактирует конфиг руками — он один раз логинится, дальше топология поддерживается сама.

NAT traversal: ручками или автоматически

Это ключевое различие на практике.

В классическом WireGuard NAT traversal — забота администратора. Если оба узла за NAT (домашний роутер, мобильный интернет), без внешнего посредника прямое соединение не установится. Стандартные обходы:

• один из узлов должен иметь статический публичный IP (обычно это и есть ваш VPS-сервер);
• проброс порта (iptables/роутер) на стороне, что находится в частной сети;
• PersistentKeepalive = 25 в конфиге, чтобы NAT-таблица не сбрасывала маппинг у клиента за симметричным NAT.

# клиент за NAT, сервер — VPS со статическим IP
[Peer]
PublicKey = <ключ_сервера>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25

Tailscale делает это сам: сначала пытается установить прямое P2P-соединение (используя технику вроде STUN — обмен через координационный сервер, чтобы узлы узнали свои внешние IP:порт и попробовали достучаться друг до друга), и если это не удаётся (двойной NAT, симметричный NAT, жёсткий корпоративный файрвол) — трафик временно идёт через relay-серверы DERP (Designated Encrypted Relay for Packets). Важно: relay видит только зашифрованный WireGuard-трафик, расшифровать его не может — но задержка выше, чем при прямом соединении, потому что пакет делает крюк через ближайший DERP-узел.

Проверить тип соединения между двумя машинами в tailnet:

tailscale ping <имя-узла>
# direct — прямое соединение
# relay "fra" — через DERP-релей во Франкфурте

Быстрый старт с Tailscale

Установка на Linux-сервере:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Команда выведет ссылку для авторизации через браузер (SSO — Google, GitHub, Microsoft или ваш собственный OIDC). После подтверждения узел появляется в консоли администратора с адресом из диапазона 100.64.0.0/10 (CGNAT-диапазон, зарезервированный под tailnet).

Полезные флаги для серверного применения:

# сделать сервер точкой выхода в интернет для всей tailnet (аналог road warrior VPN)
sudo tailscale up --advertise-exit-node

# анонсировать локальную подсеть за этим узлом (site-to-site)
sudo tailscale up --advertise-routes=192.168.1.0/24

# разрешить SSH через tailnet без отдельного демона и ключей
sudo tailscale up --ssh

Новые маршруты и exit-node нужно ещё одобрить в консоли администратора (или через tailscale set --accept-routes на клиенте) — по умолчанию произвольный узел не может просто объявить себя шлюзом в чужую сеть.

Классическая схема: сервер-хаб на VPS

Если узлов немного (2–6) и один из них в любом случае должен быть постоянно доступен — держать классическую клиент-серверную схему на VPS часто проще и надёжнее, чем тянуть стороннюю зависимость. Подробная установка разобрана в статье про WireGuard на VPS, здесь — суть конфигурации сервера:

# /etc/wireguard/wg0.conf на сервере
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <приватный_ключ_сервера>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <публичный_ключ_клиента_1>
AllowedIPs = 10.10.0.2/32

[Peer]
PublicKey = <публичный_ключ_клиента_2>
AllowedIPs = 10.10.0.3/32

Плюсы такой схемы: полный контроль над маршрутизацией через AllowedIPs, никакой зависимости от внешнего control plane, предсказуемая топология, минимальная поверхность атаки (нет стороннего сервиса, который знает о вашей сети). Минус — она не масштабируется линейно на mesh: если клиентам нужно ходить друг к другу напрямую, а не только к серверу, каждому нужен [Peer] на каждого, и это быстро превращается в ручной ад при росте числа узлов.

Headscale — если mesh нужен, а сторонний control plane нет

Если преимущества автоматического mesh нужны, но отдавать метаданные о топологии сети (кто с кем соединён, когда был онлайн) стороннему провайдеру не хочется — есть Headscale, open-source реализация протокола координационного сервера Tailscale, которую можно развернуть на своём VPS. Клиенты остаются стандартными (тот же tailscale CLI на устройствах), просто указывают адрес вашего сервера вместо login.tailscale.com:

tailscale up --login-server=https://headscale.example.com

Разворачивание Headscale с нуля и настройка собственного DERP-релея разобраны в статьях Headscale на Debian и Headscale на Ubuntu. Это компромисс: автоматический mesh и NAT traversal остаются, но контроль над данными и инфраструктурой — у вас. Минус — Headscale не покрывает 100% функциональности официального Tailscale (например, некоторые SSO-сценарии и Funnel реализованы с ограничениями), и поддержку придётся брать на себя.

Ещё один mesh-вариант поверх WireGuard — Netmaker, он ближе к self-hosted решению «из коробки» с собственной панелью; сравнение подходов — в статье про Netmaker.

ACL и модель безопасности

В классическом WireGuard весь контроль доступа — это AllowedIPs на сервере и файрвол-правила поверх. Гибко, но плоско: либо пир видит подсеть, либо нет, без ролей и групп.

Tailscale (и Headscale) добавляют политику ACL в формате HuJSON, применяемую централизованно ко всей tailnet:

{
  "acls": [
    {"action": "accept", "src": ["group:devops"], "dst": ["tag:prod-db:5432"]},
    {"action": "accept", "src": ["tag:web"], "dst": ["tag:prod-db:5432"]}
  ],
  "groups": {
    "group:devops": ["you@example.com"]
  }
}

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

Что выбрать: практические критерии

Практическое правило: если у вас один VPS-шлюз и несколько клиентов, которым нужен только выход в интернет или доступ к серверу — классическая схема проще и её быстрее поднять с нуля, она разобрана в статье про выбор между WireGuard и OpenVPN. Если серверов и рабочих машин становится десяток и больше, они за разными NAT (офис, дом, облако, мобильные устройства), и нужен full-mesh доступ между всеми — ручное сопровождение конфигов станет узким местом раньше, чем вы ожидаете, и здесь выигрывает автоматизация Tailscale или self-hosted Headscale.

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