Tailscale на VDS: ACL, exit node и стабильный внешний IP

Инструкции
19 ноя, 2025
Время на чтение: ~15 мин
Автор: AI (GPT 5)

Искусственный интеллект Fastfox

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Если вам нужен управляемый VPN с предсказуемым внешним IP, удобными правилами доступа и минимумом телодвижений в firewall, Tailscale и облачный VDS — отличная пара. В этой статье я покажу, как превратить ваш VDS в exit node для всего трафика устройств, настроить ACL (политику доступа), аккуратно включить IPv4/IPv6 форвардинг и убедиться, что внешний IP стабилен для белых списков и интеграций. По пути разберём нюансы маршрутизации, теги, auto-approve и диагностику производительности.

Зачем VDS как exit node Tailscale

Tailscale строит оверлейную сеть поверх WireGuard: шифрование, P2P, автоматическая маршрутизация, минимум ручной возни. При этом «exit node» позволяет определённым клиентам отправлять весь интернет-трафик через один узел сети — в нашем случае через VDS. Это даёт сразу несколько выгод:

Стабильный внешний IP: удобно для белых списков в сторонних сервисах, доступов к API, корпоративных фаерволов.
Единая точка политик: можно ограничить, кто имеет право пользоваться exit node, и логически отделить окружения тегами.
Работа из любой сети: сотрудники и сервисы получают защищённый VPN-канал поверх публичного интернета без проброса портов и сложного NAT.
IPv6 по желанию: при наличии IPv6 на VDS обеспечиваем двустековый выход.

Идея проста: VDS с публичным адресом становится «шлюзом» вашей tailnet. Клиенты выбирают этот узел как exit node, а вы управляете, кому это разрешено, через ACL и теги.

Требования и подготовка VDS

Подойдёт любой современный Linux (Ubuntu 22.04/24.04, Debian, Rocky/Alma). Важно, чтобы у VDS был публичный статический IPv4 (по возможности также IPv6). В типовой конфигурации Tailscale не требует входящих соединений из интернета — достаточно исходящих UDP. Тем не менее, для стабильности проверьте, что провайдер не ограничивает исходящий UDP и что пакетная фильтрация на самом сервере не блокирует интерфейс tailscale0.

Базовые шаги подготовки:

Обновите пакеты и ядро до актуальной минорной версии.
Синхронизируйте время (chrony/systemd-timesyncd) — для криптографии это критично.
Если используете UFW/nftables/iptables, сразу продумайте политики для интерфейса tailscale0.

Установка Tailscale

В продакшене удобнее использовать официальный репозиторий пакетов, чтобы получать обновления без задержек. Для Ubuntu 22.04 (Jammy) и 24.04 (Noble) это выглядит так:

# Добавляем репозиторий (пример для Ubuntu 22.04 Jammy)
sudo apt-get update
sudo apt-get install -y curl gnupg2
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg] https://pkgs.tailscale.com/stable/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/tailscale.list >/dev/null
sudo apt-get update
sudo apt-get install -y tailscale

# Запускаем сервис
sudo systemctl enable --now tailscaled

Для быстрого стенда возможен инсталлятор одной командой:

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

Но для серверов я всё же рекомендую именно репозиторий.

Авторизация VDS в tailnet, теги и права

Чтобы автоматически зарегистрировать VDS в tailnet и выдать ему нужные теги (например, tag:exit), используем «auth key» из админки Tailscale. Хорошая практика — ключ с ограниченным сроком действия, привязанный к тегам и при необходимости «preapproved».

# Пример: заодно рекламируем теги (tag:exit) и заявляемся как exit node
sudo tailscale up --authkey=tskey-REDACTED --advertise-tags=tag:exit --advertise-exit-node

Тегирование важно для ACL: мы сможем явно описать, кто имеет право управлять узлами с тегом tag:exit и кто может до них дотягиваться по tailnet. Если ключ не имеет права назначить тег, объявление тега провалится — ниже покажу, как это разрешить в политике.

Включаем IPv4/IPv6 форвардинг

Для exit node нужно включить форвардинг на уровне ядра. Разово:

sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

А чтобы сделать это постоянным, создадим отдельный файл с настройками:

sudo tee /etc/sysctl.d/99-tailscale-forwarding.conf << 'EOF'
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
EOF
sudo sysctl --system

Когда включён --advertise-exit-node, Tailscale сам поднимает SNAT для клиентов tailnet, так что дополнительный ручной NAT обычно не требуется. Исключения — кастомные firewall-политики, которые блокируют tailscale0 или трафик FORWARD.

Firewall: UFW/nftables и интерфейс tailscale0

Если вы используете UFW, минимум нужен явный доступ на интерфейсе tailscale0. Варианты зависят от вашей базовой политики, пример:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow in on tailscale0
sudo ufw allow out on tailscale0
# Разрешить SSH по tailnet, но не с интернета
sudo ufw deny in proto tcp to any port 22
sudo ufw allow in on tailscale0 to any port 22 proto tcp
sudo ufw reload

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

table inet filter {
  chain input {
    type filter hook input priority 0;
    ct state established,related accept
    iifname "tailscale0" accept
    tcp dport 22 iifname "tailscale0" accept
    reject with icmpx type admin-prohibited
  }
  chain forward {
    type filter hook forward priority 0;
    iifname "tailscale0" accept
    oifname "tailscale0" accept
    ct state established,related accept
  }
}

Дополнительно проверьте базовую гигиену безопасности на сервере: ключи, SSH, файрвол. Для систематизации пригодится наш материал чек-лист по SSH и базовому фаерволу для VDS.

Правила UFW и nftables для интерфейса tailscale0 на сервере

Включаем и используем exit node на клиентах

После того как VDS зарегистрирован с --advertise-exit-node и форвардинг включён, клиенты tailnet могут выбрать его как exit node. На Linux это можно сделать так:

# Список узлов, чтобы узнать имя/ID VDS
tailscale status

# Включить использование exit node и оставить доступ к локальной сети клиента
sudo tailscale up --exit-node=vds-exit --exit-node-allow-lan-access=true

На десктопах (Windows/macOS) это включается в GUI-клиенте. Если в админке включено обязательное одобрение exit node, не забудьте его approve после объявления.

Проверьте внешний IP клиента на любом сервисе «what is my IP». Он должен совпасть с публичным адресом вашего VDS. Для IPv6 — аналогично.

ACL-политика: теги, владельцы и auto-approve

Политика ACL в Tailscale — это JSON, который описывает, кто и к кому может подключаться в tailnet, кто владеет тегами и какие вещи можно автоодобрять. Ниже — типовая заготовка для узла-выхода с тегом tag:exit. Она отключает «разрешать всё по умолчанию» и даёт доступ к узлу только группам, которым это нужно. Также мы настраиваем владельца тега и автоматическое одобрение exit node, когда его объявляет узел с этим тегом.

{
  "version": 1,
  "disableDefaultAllow": true,
  "groups": {
    "group:netops": ["alice@example.com", "bob@example.com"],
    "group:devs": ["dev1@example.com", "dev2@example.com"]
  },
  "tagOwners": {
    "tag:exit": ["group:netops"]
  },
  "autoApprovers": {
    "exitNode": ["group:netops"]
  },
  "acls": [
    { "action": "accept", "src": ["group:netops"], "dst": ["tag:exit:*"] },
    { "action": "accept", "src": ["group:devs"],   "dst": ["tag:exit:*"] }
  ]
}

Здесь важны несколько моментов:

disableDefaultAllow отключает «политику по умолчанию», когда все видят всех. Мы явно разрешаем доступ к tag:exit.
tagOwners определяет, кто может назначать тег tag:exit узлам и, как следствие, кто может их запускать с этим тегом.
autoApprovers.exitNode позволяет автоматически одобрять узлы-выходы, заявленные «владельцами» (удобно для CI/CD и автоматизации).
Логика «кто может использовать exit node» на практике сводится к тому, кому ACL разрешают ходить на IP узла-выхода по tailnet. Если вы не дадите клиенту права на tag:exit, он не сможет направить к нему трафик.

Пример ACL политики Tailscale с тегами и группами

Exit node vs Subnet router: когда что выбирать

Exit node — это объявление маршрута по умолчанию через VDS. Все подключения клиента к интернету пойдут через ваш сервер. Это полезно, если вы хотите:

сделать стабильный egress IP для белых списков;
применить централизованные egress-политики/логирование;
обходить проблемы локальных сетей клиента (фильтры, CGNAT, асимметричные маршруты).

Subnet router — объявление конкретных подсетей, к которым доступен маршрут через узел. Например, если VDS подключён к вашей приватной сети или к другим туннелям, вы можете дать доступ только к этим сетям, не трогая глобальный интернет-трафик клиентов.

# Пример одномоментного объявления и exit node, и роутов к приватным сетям
sudo tailscale up --authkey=tskey-REDACTED --advertise-tags=tag:exit --advertise-exit-node --advertise-routes=10.10.0.0/16,192.168.50.0/24

Если используете subnet routes, проверьте, что у VDS есть связность до этих сетей и корректная обратная маршрутизация. При необходимости включайте SNAT для подсетей, если обратные маршруты настроить нельзя.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Стабильный внешний IP и нюансы провайдера

Сильная сторона VDS — стабильный публичный IPv4. В роли exit node ваш VDS станет источником всего исходящего трафика клиентов, так что именно его адрес увидят внешние сервисы. Это удобно для:

белых списков на корпоративных фаерволах и API поставщиков;
аналитики и аудита исходящего трафика;
снижения риска блокировок при «скачущих» клиентских IP.

Рекомендации из практики:

Уточните у провайдера политику по замене/сохранению IP. При миграции VDS на другой хостинг убедитесь, что IP сохраняется или заранее планируйте окно перегенерации белых списков.
Если используете IPv6, проверьте наличие глобального префикса и включён ли форвардинг. На клиентах включайте exit node с учётом IPv6, чтобы получить двустековый выход.
Для сервисов, чувствительных к обратной DNS-записи, настройте PTR на IP VDS (если это релевантно вашему кейсу).

Производительность и надёжность

Tailscale использует WireGuard и работает поверх UDP. На производительность влияют CPU (шифрование), MTU и качество сети до релеев (DERP) при невозможности прямого P2P. Пара практических советов:

Выберите VDS с достаточной CPU (AES-NI/armv8 crypto extensions помогают). Подбор поможет материал как выбрать конфигурацию VDS по CPU и RAM.
Следите за MTU: по умолчанию Tailscale сам подстраивается, но если видите фрагментацию в определённых провайдерах — тестируйте.
Обновляйте tailscaled — релизы регулярно улучшают сетевую устойчивость и диагностику.

Диагностика: status, netcheck, логи

Несколько команд, которые экономят время при разборе полётов:

# Состояние узлов tailnet и маршрутов
tailscale status

# Проверка сетевой связности до релеев и NAT traversal
tailscale netcheck

# IP адреса узла (в т.ч. адрес интерфейса tailscale0)
tailscale ip -4

# Пинги по tailnet (диагностируют доступность по оверлею)
tailscale ping vds-exit

# Системный журнал демона
journalctl -u tailscaled -n 200 --no-pager

Если клиенты не могут включить exit node, проверьте:

одобрение узла как exit node (если включено обязательное approve);
ACL: разрешён ли доступ к tag:exit;
форвардинг в ядре (ip_forward и ipv6.forwarding);
политики firewall на tailscale0 и в цепочке FORWARD;
что сам VDS видит интернет (маршруты, DNS).

Роллбэк и безопасность

Жёстко закрепите операционные практики:

Не выдавайте всем право назначать tag:exit; используйте tagOwners и группы.
Храните auth-ключи безопасно, ограничивайте срок действия и охват тегами; при компрометации немедленно отзывайте.
Регулярно просматривайте tailscale status и журналы, отключайте неиспользуемые клиенты.
Проверяйте, кто реально пользуется exit node: по логам и по статусу сессий.

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

Нужно ли открывать входящие порты на VDS для Tailscale?

Нет, как правило достаточно исходящих соединений. Tailscale строит соединение самостоятельно и умеет работать через NAT и корпоративные фаерволы. Исключения — сильно ограничительные egress-политики, где блокируют UDP — тогда разрешите исходящий UDP.

Чем exit node отличается от прокси?

Клиент направляет весь IP-трафик через шифрованный туннель на ваш VDS, где он выходит в интернет под его публичным IP. Это не приложенческий прокси, а IP-роутинг с NAT. Работает для любых протоколов поверх IP.

Можно ли принудительно включить exit node на некоторых серверах?

Да, на Linux-клиентах используйте tailscale up --exit-node=.... На десктопах — включите в UI. Чтобы ограничить круг пользователей, используйте ACL и при необходимости autoApprovers для exit node.

Как совместить exit node и доступ к корпоративной сети?

Рекламируйте одновременно exit node и конкретные приватные подсети через --advertise-routes. Тогда клиенты и выходят через VDS в интернет, и видят нужные подсети. Следите за обратными маршрутами или включайте SNAT для приватных сетей на VDS.

Итог

Развёрнутый на VDS Tailscale-узел в роли exit node — быстрый способ дать команде безопасный VPN с контролируемым внешним IP, прозрачной политикой доступа (ACL, теги, auto-approve) и поддержкой IPv6. Со стороны эксплуатации всё сводится к нескольким понятным шагам: установка, авторизация с тегами, включение форвардинга, аккуратные правила firewall и проверка статуса. Дальше — дело практики и автоматизации: заведите инфраструктурные теги, разделите группы, добавьте тесты netcheck в CI и периодически пересматривайте политику — получится простой и надёжный фундамент для предсказуемого egress из любой точки.

Поделиться статьей