SSD Nodes Learn Hosting plans →
Руководства Matt ConnorАвтор: Matt Connor

Работает ли Tailscale в России и как это проверить

У Tailscale три независимые части: сервер координации, релеи DERP и прямой WireGuard по UDP. Как понять, какая из них отказала у вас, командами netcheck, status и ping.

Работает ли Tailscale в России: короткий ответ

Работает ли Tailscale в России, зависит от трёх независимых частей: сервера координации (login.tailscale.com и провайдер входа, через который вы авторизуетесь), парка релейных серверов DERP и прямого WireGuard-соединения по UDP между вашими устройствами. Каждая из трёх частей отказывает отдельно от других, и симптомы у них разные. Поэтому честный ответ на вопрос «работает или нет» выглядит как три проверки у вашего конкретного провайдера, а не как вердикт на дату. Вердикт устаревает за неделю, проверки нет.

Ниже: как поставить Tailscale на Ubuntu 24.04 из официального репозитория, что именно проверяют tailscale netcheck, tailscale status и tailscale ping, как читать в их выводе слова relay и direct, и что делать, когда недоступен сам сервер координации. Всё рассчитано на типичную для российского читателя схему: VPS за пределами России плюс ноутбук и телефон внутри страны.

Из чего состоит Tailscale: три зависимости

Если вы ещё не разбирали устройство этой сети, начните с обзора что такое Tailscale и как устроена его сеть. Здесь только то, что нужно для диагностики.

Сервер координации. Клиент tailscaled держит постоянное HTTPS-соединение с controlplane.tailscale.com. Оттуда он получает список ваших устройств, их публичные ключи WireGuard, правила доступа (ACL) и карту релеев DERP. Вход в аккаунт идёт через login.tailscale.com, а дальше через провайдера идентификации: Google, Microsoft, GitHub, Apple или ваш собственный OIDC. Это две разные точки отказа: страница Tailscale может открываться, а страница провайдера нет.

Релеи DERP. Релеи DERP (Designated Encrypted Relay for Packets) пересылают уже зашифрованные WireGuard-пакеты между узлами, когда прямое соединение не установилось. Работают они по TCP 443 внутри TLS, то есть внешне это обычный HTTPS. Тот же DERP служит каналом для служебных пакетов, через которые узлы договариваются о прямом пути. Ближайшие к России регионы: hel (Хельсинки), waw (Варшава) и fra (Франкфурт).

Прямой WireGuard по UDP. Когда узлы нашли друг друга, трафик идёт напрямую по UDP, по умолчанию с порта 41641, обычными WireGuard-пакетами. Это самый быстрый путь и одновременно самый уязвимый: именно WireGuard-пакеты умеет распознавать DPI (deep packet inspection, глубокая инспекция пакетов).

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

Что известно о блокировках: даты вместо вердикта

В начале августа 2024 года пользователи на Хабре и в профильных Telegram-каналах, а затем и деловые СМИ, массово сообщали, что WireGuard и OpenVPN перестали работать у крупных мобильных операторов, при этом HTTPS-трафик шёл нормально. Сообщения связывали это с ТСПУ (техническими средствами противодействия угрозам), которые стоят на сетях операторов и умеют распознавать протоколы. Официального объяснения тогда не прозвучало. Для Tailscale это означало ровно одно: страдал прямой путь по UDP, а DERP по TCP 443 продолжал работать, поэтому у многих Tailscale «стал медленным», а не «перестал работать».

Я сознательно не пишу, что заблокировано, а что нет, на сентябрь 2026 года. Такое предложение будет ложным раньше, чем эту страницу проиндексируют. Вместо этого ниже три команды, вывод которых говорит о состоянии именно вашего провайдера именно сейчас. Запускайте их с обеих сторон: на VPS и на устройстве в России. Условия у них разные, и отказ на одной стороне ломает связь для обеих.

Установка Tailscale на Ubuntu 24.04 из репозитория Tailscale

Установка добавляет четвёртую, разовую зависимость: pkgs.tailscale.com, откуда берутся ключ репозитория и сам пакет. Команды ниже взяты из официальной инструкции Tailscale для Ubuntu 24.04 (noble).

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install -y tailscale

Проверьте, что служба поднялась:

systemctl is-active tailscaled
tailscale version

Первая команда должна напечатать active, вторая печатает версию клиента. Если curl завершился ошибкой curl: (6) Could not resolve host: pkgs.tailscale.com или curl: (28) Failed to connect to pkgs.tailscale.com port 443, до репозитория не достучаться с этой машины. На VPS за рубежом это почти всегда опечатка или закрытый исходящий трафик, на устройстве в России стоит повторить команду через другого провайдера. Ошибки apt про ключи и подписи разобраны в статье про типичные ошибки установки Tailscale на Ubuntu.

Зависимость первая: сервер координации и вход

sudo tailscale up

Здоровый результат: клиент печатает ссылку вида https://login.tailscale.com/a/..., вы открываете её в браузере, входите через своего провайдера, и команда завершается. После этого sudo tailscale status показывает адрес вида 100.x.y.z и список устройств.

Если ссылки нет, а команда висит, проверьте сам сервер координации, не отвлекаясь на Tailscale:

curl -sS -m 10 -o /dev/null -w '%{http_code}\n' https://controlplane.tailscale.com/
curl -sS -m 10 -o /dev/null -w '%{http_code}\n' https://login.tailscale.com/

Любой трёхзначный код в ответе означает, что до сервера удалось дойти: имя разрешилось и TLS-рукопожатие прошло. При сбое curl печатает 000 и строку с кодом ошибки, и здесь три разных строки означают три разные причины. curl: (6) Could not resolve host означает, что имя не резолвится: проблема в DNS. curl: (28) Failed to connect ... Timeout was reached означает, что пакеты уходят и не возвращаются: соединение отбрасывается по пути. curl: (35) ... Connection reset by peer (или тот же текст с кодом 56) означает, что кто-то по пути закрыл соединение сразу после TLS-приветствия с именем сервера: так выглядит фильтрация по SNI (server name indication, имя сервера в открытой части TLS-рукопожатия).

Если оба curl вернули код, а ссылка для входа открывается, но страница провайдера нет, отказал провайдер идентификации, а не Tailscale. Аккаунт с входом по ключу доступа (passkey) убирает эту зависимость: Tailscale поддерживает такие аккаунты без внешнего провайдера. Для сервера без браузера вход делается ключом авторизации, который создаётся в админ-панели заранее: sudo tailscale up --auth-key tskey-auth-.... Сервер координации при этом всё равно должен быть доступен с этой машины.

Что происходит, если сервер координации пропал уже после входа. Узлы продолжают работать: у них есть кешированный список пиров и ключи. Но новые устройства не добавятся, изменения ACL не применятся, а через 180 дней (срок жизни ключа узла по умолчанию) устройство выпадет из сети. В sudo tailscale status это состояние подписано так:

# Health check:
#     - Unable to connect to the Tailscale coordination server to synchronize the state of your tailnet. Peer reachability might degrade over time.

Слово degrade здесь точное: сеть не падает сразу, а разваливается по мере того, как устаревают ключи и адреса.

Зависимость вторая: релеи DERP

sudo tailscale netcheck

Здоровый отчёт выглядит примерно так:

Report:
	* Time: 2026-09-15T10:12:03Z
	* UDP: true
	* IPv4: yes, 203.0.113.10:41641
	* IPv6: no, but OS has support
	* MappingVariesByDestIP: false
	* PortMapping:
	* Nearest DERP: Helsinki
	* DERP latency:
		- hel: 28.4ms  (Helsinki)
		- waw: 41.9ms  (Warsaw)
		- fra: 47.2ms  (Frankfurt)

Читать нужно три строки. UDP: true означает, что STUN-запросы по UDP до релеев ушли и вернулись, то есть UDP как таковой у провайдера не перекрыт. MappingVariesByDestIP: false означает, что ваш NAT (network address translation, трансляция сетевых адресов) выдаёт один и тот же внешний порт для разных адресатов; при true прямое соединение возможно, только если у второй стороны открыт порт, и на VPS его как раз можно открыть. Список DERP latency показывает, какие релеи ответили и за сколько.

UDP: false при заполненном списке DERP latency означает, что UDP перекрыт, а релеи по HTTPS отвечают: в этом случае netcheck измеряет задержку HTTPS-запросами, и Tailscale будет работать через релей. Отказ самих релеев выглядит иначе: Nearest DERP: unknown (no response to latency probes) и пустой список задержек. Это означает, что до релеев не доходит ни UDP 3478, ни HTTPS 443, и в sudo tailscale status появляется строка здоровья Tailscale could not connect to any relay server. Check your Internet connection.

Проверьте один релей руками, без Tailscale. У каждого DERP-сервера есть служебный адрес /derp/probe, который отвечает пустым 200:

curl -sS -m 10 -o /dev/null -w '%{http_code}\n' https://derp28b.tailscale.com/derp/probe
curl -sS -m 10 -o /dev/null -w '%{http_code}\n' https://derp4f.tailscale.com/derp/probe

Имена узлов берутся из карты релеев, которую клиент скачивает с сервера координации; посмотреть её можно командой curl -s https://controlplane.tailscale.com/derpmap/default. Ошибка (28) на одном регионе и код 200 на другом означают, что недоступен конкретный узел или регион, и Tailscale сам переключится на следующий. Ошибка на всех регионах при работающем curl https://example.com означает, что фильтруется имя *.tailscale.com целиком.

Зависимость третья: прямой WireGuard по UDP

Эта зависимость единственная из трёх, где «не работает» означает «работает медленно». Проверяется двумя командами: tailscale status показывает текущий путь до каждого пира, tailscale ping пытается его улучшить.

sudo tailscale status
100.101.102.103 vps-ams           user@        linux   -
100.104.105.106 laptop            user@        linux   active; direct 198.51.100.7:41641, tx 48212 rx 391044
100.107.108.109 phone             user@        android active; relay "hel", tx 9120 rx 30877

direct 198.51.100.7:41641 означает прямой UDP-путь до этого адреса и порта. relay "hel" означает, что весь трафик до этого пира идёт через релей в Хельсинки. Слово relay само по себе не ошибка: Tailscale обычно начинает через релей и переходит на прямой путь в первые секунды обмена. Ошибка, когда relay держится минутами при живом трафике.

sudo tailscale ping laptop
pong from laptop (100.104.105.106) via DERP(hel) in 71ms
pong from laptop (100.104.105.106) via DERP(hel) in 69ms
pong from laptop (100.104.105.106) via 198.51.100.7:41641 in 24ms

tailscale ping по умолчанию останавливается, как только получает ответ напрямую. Если все десять ответов пришли via DERP(...), команда заканчивает строкой direct connection not established. Обратите внимание: обычный tailscale ping шлёт служебные пакеты обнаружения, а не трафик внутри туннеля. Ключ --tsmp отправляет запрос уже внутри WireGuard, поэтому sudo tailscale ping --tsmp laptop доказывает, что работает сам зашифрованный канал, а не только обнаружение.

Теперь диагностика. Откройте на VPS порт WireGuard, чтобы сторона в России могла инициировать соединение к известному публичному адресу, и посмотрите две ключевые строки отчёта на устройстве в России:

sudo ufw allow 41641/udp
sudo tailscale netcheck 2>/dev/null | grep -E 'UDP|MappingVaries'

Дальше три сочетания. Первое: на устройстве в России UDP: false. Провайдер не пропускает UDP целиком или в этом направлении, прямой путь невозможен, Tailscale будет работать через DERP, и это штатный режим. Второе: UDP: true, MappingVariesByDestIP: true, VPS с открытым портом, а tailscale ping всё равно заканчивается на direct connection not established. Проверьте, что порт на VPS действительно открыт и в панели хостера, и в ufw; при открытом порте на VPS жёсткий NAT клиента прямому пути не мешает. Третье, самое показательное: UDP: true, MappingVariesByDestIP: false, порт открыт, служебный tailscale ping получает via 198.51.100.7:41641, а tailscale ping --tsmp laptop и обычный ping 100.104.105.106 ответа не получают. Служебные пакеты Tailscale и WireGuard-пакеты идут через один и тот же UDP-порт, отличаются они только форматом. Когда проходят первые и не проходят вторые, между узлами что-то отбрасывает пакеты именно по признакам WireGuard, и настройки Tailscale здесь ничего не изменят.

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

Сводка: какая часть отказала

  • tailscale up висит без ссылки, curl до controlplane.tailscale.com даёт (6), (28) или (35): сервер координации недоступен с этой машины. Вход и добавление устройств невозможны.
  • Ссылка открывается, страница провайдера входа нет: отказ провайдера идентификации. Попробуйте другой способ входа или ключ авторизации.
  • netcheck печатает Nearest DERP: unknown, curl до /derp/probe не отвечает ни в одном регионе: релеи недоступны. Соединения не поднимаются даже при живом UDP.
  • netcheck показывает UDP: false, а список DERP latency заполнен: прямого пути не будет, сеть работает через DERP. Это медленнее, но это работа, а не отказ.
  • UDP: true, tailscale ping получает прямой ответ, а --tsmp нет: пакеты WireGuard отбрасываются по пути. Tailscale останется на релее.

Когда сервер координации недоступен: Headscale или чистый WireGuard

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

Headscale, открытая реализация сервера координации на вашем VPS, переносит первую зависимость на машину, которую контролируете вы. Клиент остаётся тем же tailscale, меняется только --login-server. Headscale умеет поднимать и встроенный DERP-релей, тогда все три части сети живут на ваших адресах, и в списке tailscale netcheck появится ваш регион вместо hel или fra.

Если устройств два или три и полносвязная сеть (mesh) не нужна, проще поднять обычный WireGuard на VPS: один файл конфигурации и ни одного внешнего сервиса. Зависимость остаётся одна, третья: WireGuard-пакеты по UDP. Если у вашего провайдера не проходит именно она, WireGuard не поможет, и тогда полезнее статья о том, что запускать на VPS, когда VPN-протоколы блокируются. Разница между двумя подходами в целом разобрана в сравнении WireGuard против Tailscale.

Что Tailscale защищает, а что нет

Tailscale строит приватную сеть между вашими собственными устройствами. Трафик между узлами зашифрован WireGuard, ключи живут только на узлах, релеи DERP видят зашифрованные пакеты и не могут их прочитать. Это хорошо закрывает задачи «зайти по SSH на VPS, не открывая порт 22 наружу» и «достучаться до домашнего NAS из поездки».

Анонимности Tailscale не даёт и не обещает. Сервер координации знает ваш аккаунт, имена устройств, их публичные адреса и время появления в сети. Провайдер видит, что вы держите соединение с *.tailscale.com и шлёте UDP-трафик на адрес вашего VPS. Если вы включите VPS как выходной узел, сайты увидят адрес VPS, а хостер VPS увидит ваш трафик. Как это настроить и чем это отличается от коммерческого VPN, разобрано в статье про выходной узел Tailscale на VPS и в разборе вопроса, является ли Tailscale VPN в привычном смысле. Модель угроз и то, что именно видит сервер координации, подробно описаны в статье насколько безопасен Tailscale.

FAQ

Работает ли Tailscale в России прямо сейчас?

Ответ зависит от трёх независимых частей и от вашего провайдера, поэтому проверяйте, а не читайте вердикты. Запустите sudo tailscale netcheck на устройстве в России: UDP: true и заполненный список DERP latency означают, что и релеи, и UDP доступны. Затем sudo tailscale status: слово direct у пира означает прямой путь, relay дольше минуты означает, что работает только релей. Если sudo tailscale up не выдаёт ссылку, проверьте curl -sS -m 10 -o /dev/null -w '%{http_code}\n' https://controlplane.tailscale.com/ и читайте код ошибки curl.

Tailscale подключается, но всё идёт через relay. Это блокировка?

Не обязательно. relay при UDP: false в netcheck означает, что провайдер не пропускает UDP, и это может быть как фильтрация, так и корпоративная сеть или мобильный оператор с жёстким NAT. Откройте на VPS порт 41641/udp и повторите sudo tailscale ping --tsmp имя-узла. Если служебный tailscale ping получает прямой ответ, а --tsmp нет, по пути отбрасываются именно пакеты WireGuard. Tailscale в этом случае остаётся на релее и продолжает работать, только медленнее.

Что произойдёт, если login.tailscale.com станет недоступен, а устройства уже вошли в сеть?

Существующие узлы продолжат работать на кешированном списке пиров, а в sudo tailscale status появится строка Unable to connect to the Tailscale coordination server. Новые устройства добавить не получится, изменения ACL не применятся, и по мере истечения ключей узлов (по умолчанию 180 дней) устройства начнут выпадать из сети. Долгосрочное решение на вашей стороне: Headscale на собственном VPS с тем же клиентом tailscale.

Можно ли через Tailscale скрыть, что я пользуюсь VPN?

Нет. Tailscale строит приватную сеть между вашими устройствами, а не скрывает факт её использования. Прямой путь состоит из обычных WireGuard-пакетов по UDP, релейный путь из TLS-соединения с *.tailscale.com, и оба видны провайдеру как таковые. Выходной узел на VPS меняет адрес, который видят сайты, но не убирает ни аккаунт на сервере координации, ни метаданные соединения.

#tailscale#russia#wireguard#derp#headscale#vpn