Como corrigir erros ao instalar o Tailscale no Ubuntu

Por que os erros de instalação do Tailscale no Ubuntu são erros do apt

Os erros de instalação do Tailscale no Ubuntu quase sempre ocorrem antes de qualquer código do Tailscale ser executado. São erros do apt. O Ubuntu não fornece um pacote tailscale próprio: verificado no arquivo de pacotes do Ubuntu em outubro de 2026, as únicas correspondências são bibliotecas auxiliares do Go e python3-tailscale. Portanto, o daemon precisa vir do próprio repositório apt do Tailscale em pkgs.tailscale.com.

Adicionar esse repositório grava dois ficheiros. Um ficheiro informa ao apt onde estão os pacotes. O outro contém a chave pública que o apt usa para verificar a assinatura do índice do repositório. Quase todas as falhas abaixo resultam de um desses dois ficheiros estar incorreto ou de um dispositivo entre o apt e o repositório recusar o pedido.

Estes são os comandos publicados pelo Tailscale para o 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 é o codinome do Ubuntu 24.04 e aparece nos dois URLs. O segundo comando grava uma linha de comentário e uma linha deb em /etc/apt/sources.list.d/tailscale.list, e cat mostra exatamente o conteúdo gravado nesse ficheiro.

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

Leia essa linha deb como um endereço com quatro campos: a opção entre colchetes [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], depois a base do repositório, que é pkgs.tailscale.com/stable/ubuntu acedida através de https, depois a suite noble e, por fim, o componente main. O apt combina a base e a suite num único URL e faz o download: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Se conseguir aceder a esse URL manualmente, o apt também conseguirá. Esse é todo o diagnóstico.

Leia o erro do apt antes de alterar qualquer coisa

Execute a atualização isoladamente para que nada faça o erro desaparecer do ecrã.

sudo apt update

Um repositório de terceiros com falha aparece assim. O codename e o endereço IP serão diferentes no seu sistema.

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.

Duas informações dessa saída determinam o que fazer a seguir: o código de estado e o URL completo na linha E: Failed to fetch. Não tire conclusões a partir da linha de resumo no fim. Copie o URL e consulte o servidor diretamente.

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

Isto devolve 200 para um codename publicado pelo Tailscale. Verificado em outubro de 2026, noble devolve um índice assinado que contém Origin: Tailscale e Codename: noble. Substitua noble pelo codename do seu próprio erro e execute novamente. Se o curl obtiver 200 onde o apt obteve um erro, o repositório está correto e o problema está na própria configuração do apt.

O que o código de estado informa

• 404 Not Found significa que o repositório não tem nenhum ficheiro nesse caminho. Em pkgs.tailscale.com, esse caminho é quase sempre o codinome no URL.
• 403 Forbidden significa que algo respondeu e recusou o pedido. Em outubro de 2026, este repositório devolve 404 para um caminho que não existe. Portanto, um 403 aponta para um proxy, um dispositivo de filtragem ou uma firewall entre o seu servidor e o Tailscale.
• 401 Unauthorized ou 407 Proxy Authentication Required significa que um proxy está a pedir credenciais que o apt não está a enviar.
• Um erro de ligação ou de resolução de nomes significa que não houve qualquer comunicação HTTP. Avance para a secção sobre IPv6.

O codinome no URL não é publicado pela Tailscale

A Tailscale cria um diretório separado para cada codinome do Ubuntu. Se pedir um codinome que não existe, recebe 404, porque não há dists/<codename> no servidor para servir. A listagem oficial do fornecedor em pkgs.tailscale.com/stable mostra quais existem. Em outubro de 2026, a lista vai de 16.04 até resolute, que corresponde ao Ubuntu 26.04.

A forma habitual de surgir um codinome incorreto é executar lsb_release -cs numa distribuição baseada no Ubuntu, mas que não é o Ubuntu. No Linux Mint 22, esse comando imprime wilma, o codinome próprio do Mint, e a Tailscale não publica nada para ele. Consulte a base Ubuntu em vez disso.

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

No Ubuntu, os dois valores são iguais. Numa derivada, VERSION_CODENAME é o nome da distribuição derivada e UBUNTU_CODENAME é a versão do Ubuntu na qual ela se baseia. Use UBUNTU_CODENAME nos dois URLs.

A segunda forma é uma atualização de versão. A ferramenta de atualização do Ubuntu desativa as fontes de terceiros durante a execução. Por isso, depois de atualizar o Ubuntu 24.04 para 26.04, encontrará /etc/apt/sources.list.d/tailscale.list comentado ou ainda a indicar noble numa máquina que agora usa resolute. Corrija o problema executando novamente os dois comandos curl com o novo codinome. Eles substituem os dois ficheiros. Se a própria atualização tiver parado a meio, de modo que o dpkg esteja a indicar pacotes parcialmente configurados e não apenas este repositório, recupere primeiro a atualização de versão falhada, porque nenhuma correção em tailscale.list será mantida enquanto o apt não conseguir concluir a configuração do sistema.

A terceira forma é uma questão de tempo. Nas semanas seguintes ao lançamento de uma nova versão do Ubuntu, o codinome existe na Canonical antes de existir na Tailscale. Apontar o ficheiro para o codinome da LTS anterior normalmente permite instalar, porque estes pacotes têm poucas dependências. No entanto, estará a executar uma compilação feita para uma versão mais antiga. Verifique o que foi realmente instalado com apt policy tailscale e altere o ficheiro novamente quando o codinome correto aparecer.

O keyring está vazio e o comando que o gravou não apresentou qualquer saída

Este caso é silencioso e é onde a maioria destes problemas termina. Volte a consultar o comando do keyring:

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

A shell constrói todo o pipeline antes de qualquer programa ser executado, portanto sudo tee abre o caminho do keyring e trunca-o imediatamente para zero bytes. Se o curl falhar, e -f fizer com que falhe em qualquer erro HTTP, o curl não escreve nada e termina com um código diferente de zero. O ficheiro permanece com zero bytes. O estado de saída de um pipeline é o estado do último comando, que é tee e terminou com sucesso. Nada é apresentado e você avança para o comando seguinte, acreditando que a chave foi instalada.

Verifique o ficheiro, não o comando que o criou.

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

Um keyring válido apresenta uma linha pub e uma linha uid que identifica o Tailscale. Um ficheiro com zero bytes apresenta gpg: no valid OpenPGP data found. e nada mais. Um ficheiro que recebeu uma página de erro HTML apresenta o mesmo resultado, e head -c 80 mostra o início de uma página web em vez de dados binários da chave.

Com um keyring que não contém uma chave utilizável, sudo apt update transfere o índice e depois rejeita-o. É apresentada uma linha W: GPG error que identifica o repositório Tailscale e a respetiva suite, o texto The following signatures couldn't be verified because the public key is not available: NO_PUBKEY seguido de um ID de chave com 16 caracteres e, abaixo, um erro a indicar que o repositório não está assinado. Observe o que o apt está a informar: transferiu o índice corretamente, mas não conseguiu verificar a assinatura. É um problema com a chave, não com a rede. Se o ficheiro do keyring não existir, a mensagem é novamente diferente e identifica diretamente o caminho com Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Grave a chave em duas etapas para que uma transferência falhada não destrua um keyring válido.

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

A linha do meio é a verificação decisiva: se não apresentar uma uid do Tailscale, pare e não copie o ficheiro. O modo 0644 é importante porque o apt muda para o utilizador sem privilégios _apt para transferir e verificar, portanto um keyring que apenas o root consegue ler é um keyring que o apt não consegue utilizar.

Um ficheiro .list e um ficheiro .sources descrevem o mesmo repositório

O Ubuntu mudou as próprias fontes para o formato deb822 no Ubuntu 24.04 LTS, quando /etc/apt/sources.list passou a ser /etc/apt/sources.list.d/ubuntu.sources. A Tailscale continua a publicar o formato de uma linha. Verificado em outubro de 2026, não existe nenhum ficheiro .sources para descarregar de pkgs.tailscale.com: esse URL devolve 404. Portanto, se a sua máquina tiver um tailscale.sources, esse ficheiro foi criado manualmente por si ou por um guia. Se tailscale.list também continuar presente, o apt tem agora o mesmo repositório descrito duas vezes.

A versão menos grave mostra um aviso em cada atualização:

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

A versão grave ocorre quando os dois ficheiros indicam caminhos diferentes para o keyring, porque o apt não consegue decidir qual chave controla o repositório. O apt mostra E: Conflicting values set for option Signed-By regarding source, depois o repositório e a respetiva suite, os dois caminhos para o keyring separados por != e, em seguida, recusa continuar:

E: The list of sources could not be read.

Esse erro bloqueia todos os comandos apt, não apenas a atualização, até que um dos ficheiros seja removido. A mesma falha ocorre com os próprios repositórios do Ubuntu. O artigo erro de fonte apt duplicada após uma migração para deb822 explica o caso geral.

Procure todos os ficheiros que mencionam Tailscale antes de eliminar qualquer coisa.

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

Mantenha um dos ficheiros. Para desativar o outro sem o perder, mude o nome: o apt lê apenas ficheiros que terminam em .list ou .sources. Assim, tailscale.list.bak é ignorado e permanece no disco para referência.

Escrever corretamente o ficheiro de fontes deb822

Se preferir o formato mais recente, converta o ficheiro que já tem em vez de voltar a escrever o endereço do repositório, porque um erro de digitação nesse endereço é exatamente como começam os erros anteriores. As versões recentes do apt incluem um conversor que reescreve ficheiros .list em estrofes deb822 e transfere a opção signed-by como Signed-By.

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

O Ubuntu 24.04 inclui uma versão do apt anterior a esse subcomando. Por isso, a linha de ajuda indica imediatamente se a sua versão o suporta. Quando não suportar, construa a estrofe a partir da linha que já está no disco. Assim, a base é obtida do ficheiro do fornecedor e não do teclado.

. /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

Esse comando imprime a estrofe que escreveu, para poder rever os campos antes do próximo apt update. Vale a pena conhecer quatro deles em detalhe, porque cada um falha de uma forma diferente:

• URIs termina na base do repositório. Colar nele a parte dists/noble produz um erro 404, porque o apt acrescenta dists/<suite> por si próprio e solicita dists/noble/dists/noble.
• Suites é o nome de código, exatamente o valor que aparecia no meio do formato de uma linha.
• Signed-By recebe um caminho absoluto para um ficheiro de keyring. Também aceita uma chave blindada incluída abaixo dele, com cada linha da chave indentada por um espaço e cada linha em branco dentro da chave escrita como um ponto único.
• Enabled: no desativa uma fonte sem a eliminar. Isso é mais fácil de reverter do que mudar o nome do ficheiro e mais fácil de explicar à pessoa seguinte.

Mantenha uma estrofe por ficheiro para repositórios de terceiros e, se algum dia mantiver várias estrofes no mesmo ficheiro, coloque uma linha em branco entre elas. O índice do repositório lista amd64 e arm64 entre as suas arquiteturas. Por isso, uma VPS ARM não precisa de um campo Architectures adicional.

Um proxy intermediário devolve 403

Como este repositório não tem respostas para um caminho inexistente, 404, um 403 significa que outra camada respondeu em seu nome. Comece pela configuração do próprio apt, porque um proxy definido aí aplica-se ao apt, mas não ao seu curl interativo.

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

Depois, monitorize o que o apt envia efetivamente.

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

Isto mostra a linha do pedido, os cabeçalhos enviados pelo apt e o proxy através do qual se ligou, se existir. Compare com um curl simples para o mesmo URL. Se o curl devolver 200 e o apt devolver 403, os dois pedidos diferem em algo que o dispositivo intermediário considera relevante. O candidato habitual é o 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

Se este comando devolver 403 enquanto o curl predefinido devolve 200, um dispositivo de filtragem está a recusar o apt pelo nome. A correção deve ser feita nesse dispositivo, não no seu servidor. Um proxy empresarial que inspeciona TLS tem um comportamento diferente: o apt comunica uma falha na verificação do certificado, em vez de um código de estado, porque o certificado recebido foi emitido pelo proxy e não pela autoridade certificadora do Tailscale. Uma firewall de saída na cloud que só permite os mirrors do Ubuntu é outra fonte comum. Nesse caso, a correção é permitir pkgs.tailscale.com na firewall.

Saída apenas por IPv6 e erros que não são códigos de estado

Se o apt nunca recebeu uma resposta HTTP, teste cada protocolo isoladamente.

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

Quando o IPv4 responde e o IPv6 fica bloqueado ou informa Network is unreachable, o apt falha porque a biblioteca de resolução dá preferência ao IPv6 e o servidor não tem um caminho IPv6 funcional. Force uma execução pelo IPv4 para confirmar a hipótese:

sudo apt -o Acquire::ForceIPv4=true update

Se essa atualização for concluída, torne a alteração permanente.

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

Considere também o caso oposto. Numa VPS que não tem qualquer endereço IPv4, forçar o IPv4 não resolve nada, porque não existe uma rota IPv4 para encaminhar o tráfego. Nesse caso, é necessário usar NAT64 com DNS64 do seu provedor ou um proxy que tenha um endereço IPv4. O sintoma é um erro de ligação que identifica um endereço IPv6; por isso, a linha curl -6 é a que mostra a causa real.

As alternativas e o custo de cada uma

O script de instalação do fornecedor. curl -fsSL https://tailscale.com/install.sh | sh é o comando divulgado pela Tailscale. Ao ler o script, ele identifica a distribuição a partir de /etc/os-release e depois escreve os mesmos dois caminhos que este guia tem corrigido, /usr/share/keyrings/tailscale-archive-keyring.gpg e /etc/apt/sources.list.d/tailscale.list, a partir dos mesmos URLs. Isto é importante para definir as expectativas: o script não contorna um repositório que um proxy esteja a bloquear. Falha da mesma forma, mas com menos saída. Encaminhar um script descarregado para uma shell como root é uma troca, não uma solução, porque implica confiar no que o servidor devolver naquele momento e não manter uma cópia do que foi executado. Se aceitar essa troca, faça-o sabendo exatamente o que está a fazer:

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

Os binários estáticos. O mesmo servidor publica tarballs simples na secção de binários estáticos de pkgs.tailscale.com/stable. Em outubro de 2026, a versão estável é 1.102.4 e o ficheiro x86 de 64 bits é tailscale_1.102.4_amd64.tgz. Instala manualmente o cliente tailscale e o daemon tailscaled, e também supervisiona o daemon, por isso não existe o caminho apt upgrade e cada atualização futura exige um download que terá de se lembrar de fazer. Esta opção é adequada para um host isolado de redes externas ou quando é necessário fixar uma versão exata.

O pacote da própria Ubuntu. Não existe. Executar sudo apt install tailscale sem o repositório do fornecedor configurado termina em E: Unable to locate package tailscale, e nenhuma quantidade de apt update altera esse resultado. Se o que pretende é, na realidade, um servidor de coordenação sob o seu controlo em vez do servidor alojado pela Tailscale, essa é uma decisão separada: executar o Headscale como o seu próprio servidor de controlo explica essa opção, e a comparação entre Tailscale e WireGuard simples explica se precisa de toda esta infraestrutura.

O pacote foi instalado, mas tailscaled não inicia

Quando o apt termina sem erros, os problemas passam para o daemon.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

Num VPS que usa virtualização baseada em contentores e partilha o kernel do host, como LXC ou OpenVZ, o log contém uma linha indicando que /dev/net/tun não existe. O daemon precisa de um dispositivo TUN para criar a interface tailscale0, mas o contentor não recebeu esse dispositivo. Peça ao fornecedor para ativar o TUN no contentor ou mude para um plano KVM, no qual tem o seu próprio kernel. Em KVM, isto funciona sem configuração adicional.

Depois disso, sudo tailscale up apresenta um URL de início de sessão, e tailscale status deve listar a sua máquina com um endereço no intervalo 100.64.0.0/10. Uma máquina apresentada nessa lista pode servir de base para outras configurações, seja anunciar uma sub-rede privada a partir do seu VPS ou usar o VPS como nó de saída.

FAQ

Por que o apt informa que o repositório do Tailscale não está assinado?

Porque o apt descarregou o índice do repositório, mas não conseguiu verificar a respetiva assinatura com /usr/share/keyrings/tailscale-archive-keyring.gpg. A causa habitual é o keyring ter zero bytes: sudo tee truncou o ficheiro antes de o curl conseguir descarregar alguma coisa, e o pipeline indicou sucesso porque tee terminou com sucesso. Execute gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Um keyring funcional apresenta uma linha pub e uma linha uid com o nome Tailscale. Um keyring vazio ou corrompido apresenta gpg: no valid OpenPGP data found.. Descarregue a key para um ficheiro temporário, verifique-a nesse local e depois copie-a para o destino com o modo 0644, para que o utilizador _apt a possa ler.

Que codename do Ubuntu devo colocar nos URLs do Tailscale?

Use o valor de UBUNTU_CODENAME obtido de /etc/os-release. Esse valor é noble no Ubuntu 24.04 e resolute no Ubuntu 26.04. Não use lsb_release -cs numa distribuição derivada do Ubuntu: no Linux Mint 22, esse comando apresenta wilma, o Tailscale não publica nada com esse nome e o apt informa 404 em dists/wilma/InRelease. Confirme a escolha antes de editar qualquer ficheiro, descarregando manualmente o índice com curl -sS -o /dev/null -w '%{http_code}\n' contra https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

É seguro executar o script de instalação do Tailscale encaminhado para uma shell?

É uma decisão que deve tomar deliberadamente. O script vem do Tailscale e executa os mesmos passos do procedimento manual: lê /etc/os-release, grava o mesmo keyring e o mesmo /etc/apt/sources.list.d/tailscale.list e depois instala o pacote. O risco é executar, com root, tudo o que o servidor devolver naquele momento, sem manter um registo do conteúdo. Descarregue-o com -o install.sh, leia-o e execute-o depois, se quiser a conveniência sem esse ponto cego. O script também não resolve um repositório bloqueado, porque usa os mesmos URLs que já falharam.

Como instalo o Tailscale no Ubuntu sem o repositório apt?

Use os tarballs estáticos publicados em pkgs.tailscale.com. Em outubro de 2026, estão na versão 1.102.4 e incluem um ficheiro amd64 com o nome tailscale_1.102.4_amd64.tgz. Terá de instalar manualmente os programas tailscale e tailscaled e executar o daemon através do systemd. O custo são as atualizações: não existe um pacote apt que descarregue uma versão nova, por isso cada atualização é manual. O arquivo do Ubuntu não contém um pacote tailscale próprio, por isso sudo apt install tailscale numa máquina sem o repositório do fornecedor termina em E: Unable to locate package tailscale.