Ошибка установки Tailscale в Ubuntu: решение проблем apt

Почему ошибки установки Tailscale в Ubuntu являются ошибками apt

Ошибки при установке Tailscale в Ubuntu почти всегда возникают до того, как запускается какой-либо код Tailscale. Это ошибки работы пакетного менеджера apt. В Ubuntu нет собственного пакета tailscale: согласно проверке архива пакетов Ubuntu в августе 2026 года, единственными совпадениями являются вспомогательные библиотеки Go и python3-tailscale, поэтому демон должен устанавливаться из собственного репозитория apt компании Tailscale по адресу pkgs.tailscale.com.

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

Ниже приведены команды, которые Tailscale публикует для Ubuntu 24.04:

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 tailscale

noble — это кодовое имя для Ubuntu 24.04, оно присутствует в обоих URL. Вторая команда записывает строку комментария и одну строку deb в файл /etc/apt/sources.list.d/tailscale.list, а команда cat показывает, что именно было туда записано.

cat /etc/apt/sources.list.d/tailscale.list

Читайте эту строку deb как адрес, состоящий из четырех полей: опция в скобках [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], затем базовый адрес репозитория pkgs.tailscale.com/stable/ubuntu, доступный по протоколу https, затем набор noble и компонент main. apt объединяет базовый адрес и набор в один URL и выполняет запрос: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Если вы можете открыть этот URL вручную, значит, apt тоже может его получить. В этом заключается вся диагностика.

Прочитайте ошибку apt, прежде чем что-либо менять

Запустите обновление отдельно, чтобы вывод ошибки не был перекрыт другими сообщениями.

sudo apt update

Ошибка стороннего репозитория выглядит следующим образом. Кодовое имя и IP-адрес на вашей машине будут отличаться.

E: Failed to fetch https://pkgs.tailscale.com/stable/ubuntu/dists/wilma/InRelease  404  Not Found [IP: 203.0.113.9 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.

Две детали в этом выводе определяют ваши дальнейшие действия: код состояния и полный URL в строке E: Failed to fetch. Не пытайтесь угадать причину по итоговой строке внизу. Скопируйте URL и обратитесь к серверу напрямую.

curl -sS -o /dev/null -w '%{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

Эта команда выводит 200 для кодового имени, которое публикует Tailscale. По состоянию на август 2026 года noble возвращает подписанный индекс, содержащий Origin: Tailscale и Codename: noble. Замените noble на кодовое имя из вашей ошибки и выполните команду снова. Если curl получает 200 там, где apt выдал ошибку, значит, репозиторий исправен, а проблема заключается в конфигурации самого apt.

О чем говорят коды состояния

• 404 Not Found означает, что в репозитории отсутствует файл по указанному пути. В случае с pkgs.tailscale.com это почти всегда указывает на неверное кодовое имя в URL.
• 403 Forbidden означает, что сервер ответил, но отклонил запрос. По состоянию на август 2026 года данный репозиторий возвращает 404 для несуществующих путей, поэтому 403 указывает на прокси, фильтрующее устройство или межсетевой экран между вашим сервером и Tailscale.
• 401 Unauthorized или 407 Proxy Authentication Required означают, что прокси запрашивает учетные данные, которые apt не передает.
• Ошибка подключения или ошибка разрешения имени означают, что HTTP-соединение не было установлено. Переходите к разделу об IPv6.

Кодовое имя в URL не публикуется Tailscale

Tailscale создает отдельный каталог для каждого кодового имени Ubuntu. Если запросить кодовое имя, которого нет в списке, вы получите ошибку 404, так как на сервере отсутствует dists/<codename> для обработки запроса. Собственный список поставщика по адресу pkgs.tailscale.com/stable показывает существующие варианты. В августе 2026 года этот список охватывает версии от 16.04 до resolute, что соответствует Ubuntu 26.04.

Обычно неверное кодовое имя попадает в систему при выполнении lsb_release -cs в дистрибутиве, основанном на Ubuntu, но не являющемся ею. В Linux Mint 22 эта команда выводит wilma — это собственное кодовое имя Mint, для которого Tailscale не выпускает пакеты. Используйте базовую версию Ubuntu.

. /etc/os-release
echo "$VERSION_CODENAME $UBUNTU_CODENAME"

В Ubuntu оба значения совпадают. В производных дистрибутивах VERSION_CODENAME — это имя самого дистрибутива, а UBUNTU_CODENAME — релиз Ubuntu, на котором он построен. Используйте UBUNTU_CODENAME в обоих URL.

Второй сценарий — обновление релиза. Инструмент обновления Ubuntu отключает сторонние источники при запуске, поэтому после обновления Ubuntu 24.04 до 26.04 вы обнаружите, что /etc/apt/sources.list.d/tailscale.list либо закомментирован, либо по-прежнему ссылается на noble на машине, которая теперь работает под управлением resolute. Исправьте это, повторно выполнив две команды curl с новым кодовым именем, которые перезапишут оба файла.

Третий сценарий связан со временем. В течение нескольких недель после выхода нового релиза Ubuntu кодовое имя уже существует у Canonical, но еще не появилось у Tailscale. Указание в файле предыдущего кодового имени LTS обычно позволяет выполнить установку, так как эти пакеты имеют мало зависимостей, но в этом случае вы будете использовать сборку, предназначенную для более старого релиза. Проверьте, что именно вы установили с помощью apt policy tailscale, и верните файл в исходное состояние, как только появится актуальное кодовое имя.

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

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

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null

Оболочка выстраивает весь конвейер до запуска программ, поэтому sudo tee открывает файл связки ключей и немедленно усекает его до нулевого размера. Если затем -f вызывает сбой при любой ошибке HTTP, curl ничего не записывает и завершается с ненулевым кодом. Файл остается пустым. Код завершения конвейера определяется последней командой, в данном случае это tee, которая выполнилась успешно. Ничего не выводится, и вы переходите к следующей команде, полагая, что ключ установлен.

Проверяйте сам файл, а не команду, которая его создала.

ls -l /usr/share/keyrings/tailscale-archive-keyring.gpg
gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg

Корректная связка ключей выводит строку pub и строку uid с упоминанием Tailscale. Файл нулевого размера выводит gpg: no valid OpenPGP data found. и больше ничего. Файл, в который попала HTML-страница ошибки, выводит то же самое, а head -c 80 покажет начало веб-страницы вместо бинарных данных ключа.

Если в связке ключей нет подходящего ключа, sudo apt update загружает индекс, а затем отклоняет его. Вы получите строку W: GPG error с названием репозитория Tailscale и его набора, текст The following signatures couldn't be verified because the public key is not available: NO_PUBKEY, за которым следует 16-символьный идентификатор ключа, а ниже — сообщение об ошибке, что репозиторий не подписан. Обратите внимание на то, что сообщает apt: индекс был успешно загружен, но проверить подпись не удалось. Это проблема с ключом, а не с сетью. Если файл связки ключей отсутствует вовсе, сообщение будет другим и будет содержать прямой путь к файлу с Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

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

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg -o /tmp/tailscale.gpg
gpg --show-keys /tmp/tailscale.gpg
sudo install -m 0644 -o root -g root /tmp/tailscale.gpg /usr/share/keyrings/tailscale-archive-keyring.gpg

Средняя строка здесь является проверочной: если она не выводит uid для Tailscale, остановитесь и не копируйте файл. Режим доступа 0644 важен, так как apt переключается на непривилегированного пользователя _apt для загрузки и проверки, поэтому связка ключей, доступная только для root, будет недоступна для apt.

Файл .list и файл .sources описывают один и тот же репозиторий

В Ubuntu 24.10 системные источники были переведены на формат deb822, где /etc/apt/sources.list стал /etc/apt/sources.list.d/ubuntu.sources. Tailscale по-прежнему публикует настройки в однострочном формате. По состоянию на август 2026 года, файла .sources для загрузки с pkgs.tailscale.com не существует: этот URL возвращает ошибку 404. Если на вашей машине есть файл tailscale.sources, значит, вы или автор руководства создали его вручную. Если при этом остался и файл tailscale.list, то apt теперь видит один и тот же репозиторий, описанный дважды.

В мягкой форме это проявляется в виде предупреждения при каждом обновлении:

W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/tailscale.list:1 and /etc/apt/sources.list.d/tailscale.sources:1

Серьезная проблема возникает, когда в двух файлах указаны разные пути к связкам ключей (keyring), так как apt не может определить, какой ключ управляет репозиторием. В этом случае выводится сообщение E: Conflicting values set for option Signed-By regarding source, затем название репозитория и его suite, далее два пути к файлам ключей с != между ними, после чего выполнение прерывается:

E: The list of sources could not be read.

Эта ошибка блокирует любую команду apt, а не только обновление, пока один из файлов не будет удален. Такая же неисправность встречается и с собственными репозиториями Ubuntu, а в статье ошибка дублирования источника apt после миграции на deb822 подробно описан общий случай решения.

Перед удалением найдите все файлы, в которых упоминается Tailscale.

grep -RIn tailscale /etc/apt/sources.list /etc/apt/sources.list.d/

Оставьте один файл. Чтобы отключить другой, не удаляя его, переименуйте его: apt считывает только файлы, заканчивающиеся на .list или .sources, поэтому файл с расширением tailscale.list.bak будет проигнорирован и останется на диске для справки.

Правильное создание файла источников deb822

Если вы предпочитаете новый формат, преобразуйте уже имеющийся файл, а не вводите адрес репозитория заново: опечатки в нем — основная причина ошибок, описанных выше. В современных выпусках apt есть конвертер, который переписывает файлы .list в блоки deb822 и переносит опцию signed-by в поле Signed-By.

apt modernize-sources --help
sudo apt modernize-sources

В Ubuntu 24.04 поставляется версия apt, в которой эта подкоманда отсутствует, поэтому справка сразу подскажет, есть ли она у вас. Если её нет, сформируйте блок на основе строки, которая уже есть на диске: так базовый адрес будет взят из файла поставщика, а не набран вручную.

. /etc/os-release
{
  echo 'Types: deb'
  echo "URIs: $(awk '/^deb /{print $3}' /etc/apt/sources.list.d/tailscale.list)"
  echo "Suites: $UBUNTU_CODENAME"
  echo 'Components: main'
  echo 'Signed-By: /usr/share/keyrings/tailscale-archive-keyring.gpg'
} | sudo tee /etc/apt/sources.list.d/tailscale.sources
sudo rm /etc/apt/sources.list.d/tailscale.list

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

• URIs указывает на базовый URL репозитория. Если вставить туда часть dists/noble, вы получите ошибку 404, так как apt сам добавляет dists/<suite> и запрашивает dists/noble/dists/noble.
• Suites — это кодовое имя дистрибутива, в точности то значение, которое находилось в середине строки старого формата.
• Signed-By принимает абсолютный путь к файлу ключей. Также поддерживается вставка ключа в формате armored непосредственно в файл: каждая строка ключа должна начинаться с пробела, а пустые строки внутри ключа обозначаются точкой.
• Enabled: no отключает источник без его удаления; это проще отменить, чем переименование, и понятнее для других администраторов.

Для сторонних репозиториев храните по одному блоку в файле, а если размещаете несколько блоков в одном файле, разделяйте их пустой строкой. Индекс репозитория уже содержит amd64 и arm64 в списке архитектур, поэтому для ARM VPS дополнительное поле Architectures не требуется.

Промежуточный прокси возвращает 403

Поскольку отсутствие пути в репозитории вызывает ошибку 404, статус 403 означает, что ответ пришел от другого устройства. Начните с проверки конфигурации apt, так как настройки прокси в ней применяются к apt, а не к вашему интерактивному curl.

grep -RIn -i proxy /etc/apt/apt.conf.d/ /etc/apt/apt.conf
sudo apt-config dump | grep -i 'acquire::http'

Затем отследите, что именно отправляет apt.

sudo apt -o Debug::Acquire::http=1 update

Эта команда выведет строку запроса, заголовки, отправленные apt, и прокси, через который было установлено соединение (если он используется). Сравните это с обычным запросом curl к тому же URL. Если curl возвращает 200, а apt возвращает 403, значит, запросы различаются параметром, который важен для промежуточного устройства. Чаще всего это User-Agent:

curl -sS -o /dev/null -w '%{http_code}\n' -A 'Debian APT-HTTP/1.3' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

Если эта команда возвращает 403, а стандартный curl — 200, значит, фильтрующее устройство блокирует apt по имени. Исправление должно быть внесено на этом устройстве, а не на вашем сервере. Корпоративный прокси, выполняющий инспекцию TLS, ведет себя иначе: apt сообщает об ошибке проверки сертификата, а не о коде состояния, так как полученный сертификат был выпущен прокси, а не центром сертификации Tailscale. Еще одна распространенная причина — облачный межсетевой экран, разрешающий доступ только к зеркалам Ubuntu. В этом случае решение заключается в разрешении pkgs.tailscale.com на межсетевом экране.

Исходящий трафик только по IPv6 и ошибки, не являющиеся кодами состояния

Если apt не получает HTTP-ответ, протестируйте каждый протокол отдельно.

curl -4 -sS -o /dev/null -w 'v4 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease
curl -6 -sS -o /dev/null -w 'v6 %{http_code}\n' https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease

Если IPv4 отвечает, а IPv6 зависает или сообщает об ошибке Network is unreachable, apt не работает, так как библиотека разрешения имен отдает предпочтение IPv6, а у сервера нет работающего маршрута IPv6. Принудительно выполните запуск через IPv4, чтобы подтвердить эту теорию:

sudo apt -o Acquire::ForceIPv4=true update

Если обновление прошло успешно, сделайте это изменение постоянным.

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

Рассмотрим обратную ситуацию. На VPS, у которого вообще нет IPv4-адреса, принудительное использование IPv4 ничего не даст, так как нет маршрута IPv4 для передачи трафика. В этом случае вам потребуется NAT64 с DNS64 от вашего провайдера или прокси-сервер, имеющий IPv4-адрес. Симптомом является ошибка соединения с указанием IPv6-адреса, поэтому строка curl -6 — это то, что укажет вам на истинную причину.

Варианты резервного развертывания и их издержки

Скрипт установки от поставщика. curl -fsSL https://tailscale.com/install.sh | sh — это команда, которую рекомендует Tailscale. Если изучить скрипт, видно, что он определяет ваш дистрибутив через /etc/os-release, а затем записывает те же два пути, которые мы исправляли в этом руководстве: /usr/share/keyrings/tailscale-archive-keyring.gpg и /etc/apt/sources.list.d/tailscale.list, используя те же URL. Это важно понимать: скрипт не обходит репозиторий, если его блокирует прокси. Он завершается с той же ошибкой, но предоставляет меньше диагностической информации. Передача скачанного скрипта напрямую в оболочку от имени root — это компромисс, а не решение, так как вы доверяете тому, что сервер вернет в данный момент, и не сохраняете копию выполненного кода. Если вы идете на этот компромисс, делайте это осознанно:

curl -fsSL https://tailscale.com/install.sh -o install.sh
less install.sh
sh install.sh

Статические бинарные файлы. Тот же сервер публикует обычные архивы tarball в разделе статических бинарных файлов на pkgs.tailscale.com/stable. По состоянию на август 2026 года стабильным релизом является 1.102.2, а файл для 64-битной архитектуры x86 называется tailscale_1.102.2_amd64.tgz. Вы самостоятельно размещаете клиент tailscale и демон tailscaled, а также сами берете на себя управление демоном, поэтому путь apt upgrade отсутствует, а каждое последующее обновление требует ручной загрузки. Этот метод оправдан на изолированных хостах (air-gapped) или в случаях, когда необходимо зафиксировать конкретную версию.

Собственный пакет Ubuntu. Его не существует. Запуск sudo apt install tailscale без настроенного репозитория поставщика приводит к E: Unable to locate package tailscale, и никакие команды apt update не изменят ситуацию. Если на самом деле вам нужен сервер координации под вашим контролем, а не облачный сервис Tailscale, это отдельное решение: запуск Headscale в качестве собственного сервера управления описывает этот процесс, а сравнение Tailscale и обычного WireGuard поможет понять, нужны ли вам вообще эти инструменты.

Пакет установлен, но tailscaled не запускается

После успешного завершения работы apt проблемы могут возникнуть на уровне демона.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

На VPS с контейнерной виртуализацией, использующей общее ядро хоста (например, LXC или OpenVZ), в логах появляется запись о том, что /dev/net/tun не существует. Демону требуется устройство TUN для создания интерфейса tailscale0, а контейнеру оно не было предоставлено. Попросите провайдера включить TUN для вашего контейнера или перейдите на тариф с KVM, где вы используете собственное ядро. В KVM всё работает без дополнительной настройки.

После этого sudo tailscale up выведет URL для входа, а tailscale status должен показать вашу машину с адресом из диапазона 100.64.0.0/10. Если машина появилась в списке, значит, её можно использовать для дальнейших задач, будь то анонсирование частной подсети с вашего VPS или использование VPS в качестве выходного узла.

FAQ

Почему apt сообщает, что репозиторий Tailscale не подписан?

Потому что apt загрузил индекс репозитория, но не смог проверить его подпись с помощью /usr/share/keyrings/tailscale-archive-keyring.gpg. Обычно это происходит из-за того, что размер связки ключей равен нулю: sudo tee обрезал файл до того, как curl завершился с ошибкой, а конвейер отчитался об успехе, так как tee выполнился успешно. Выполните gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Рабочая связка ключей выводит строку pub и строку uid с упоминанием Tailscale, тогда как пустая или поврежденная выводит gpg: no valid OpenPGP data found.. Загрузите ключ во временный файл, проверьте его, а затем скопируйте на нужное место с правами 0644, чтобы пользователь _apt мог его прочитать.

Какое кодовое имя Ubuntu указывать в URL Tailscale?

Используйте значение UBUNTU_CODENAME из файла /etc/os-release, которое равно noble для Ubuntu 24.04 и resolute для Ubuntu 26.04. Не используйте lsb_release -cs на дистрибутивах, основанных на Ubuntu: в Linux Mint 22 эта команда выводит wilma, Tailscale не публикует пакеты под этим именем, и apt сообщает об ошибке 404 при обращении к dists/wilma/InRelease. Перед внесением изменений подтвердите правильность выбора, вручную запросив индекс с помощью curl -sS -o /dev/null -w '%{http_code}\n' по адресу https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

Безопасно ли запускать скрипт установки Tailscale через конвейер в оболочку?

Это компромисс, на который вы должны идти осознанно. Скрипт предоставляется Tailscale и выполняет те же действия, что и ручная установка: считывает /etc/os-release, записывает ту же связку ключей и тот же файл /etc/apt/sources.list.d/tailscale.list, а затем устанавливает пакет. Минус в том, что вы запускаете от имени root всё, что сервер вернет в данный момент, не сохраняя историю изменений. Загрузите скрипт с помощью -o install.sh, изучите его содержимое, а затем запустите, если хотите получить удобство без слепых зон. Этот метод также не поможет, если репозиторий заблокирован, так как используются те же URL, которые уже вызвали ошибку.

Как установить Tailscale на Ubuntu без использования репозитория apt?

Используйте статические tar-архивы, опубликованные на pkgs.tailscale.com; по состоянию на август 2026 года доступна версия 1.102.2, файл для amd64 называется tailscale_1.102.2_amd64.tgz. Вы самостоятельно устанавливаете программы tailscale и tailscaled и запускаете демон под управлением systemd. Минус заключается в обновлении: нет пакета apt, который загрузил бы новую версию, поэтому каждое обновление выполняется вручную. В архивах Ubuntu нет собственного пакета tailscale, поэтому команда sudo apt install tailscale на машине без репозитория поставщика завершается ошибкой E: Unable to locate package tailscale.