Cómo corregir errores al instalar Tailscale en Ubuntu

Por qué los errores de instalación de Tailscale en Ubuntu son errores de apt

Los errores de instalación de Tailscale en Ubuntu casi siempre se producen antes de que se ejecute cualquier código de Tailscale. Son errores de apt. El archivo de paquetes de Ubuntu no contiene ningún paquete tailscale: al comprobar el archivo de paquetes de Ubuntu en octubre de 2026, las únicas coincidencias son bibliotecas auxiliares de Go y python3-tailscale. Por tanto, el daemon normalmente procede del repositorio apt propio de Tailscale en pkgs.tailscale.com. Canonical también mantiene un snap de Tailscale, que se trata junto con las demás alternativas al final.

Al añadir ese repositorio se escriben dos archivos. Un archivo indica a apt dónde están los paquetes. El otro contiene la clave pública que apt utiliza para comprobar la firma del índice del repositorio. Casi todos los errores siguientes se deben a que uno de esos dos archivos es incorrecto o a que un dispositivo entre apt y el repositorio rechaza la solicitud.

Estos son los comandos que Tailscale publica para 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 es el nombre en clave de Ubuntu 24.04 y aparece en ambas URL. El segundo comando escribe una línea de comentario y una línea deb en /etc/apt/sources.list.d/tailscale.list, y cat muestra exactamente lo que se ha escrito allí.

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

Interprete esa línea deb como una dirección dividida en cuatro campos: la opción entre corchetes [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg]; después, la base del repositorio, que es pkgs.tailscale.com/stable/ubuntu y se alcanza mediante https; luego, la suite noble; y, por último, el componente main. apt combina la base y la suite en una única URL y la solicita: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Si puede obtener esa URL manualmente, apt también puede obtenerla. Ese es todo el diagnóstico.

Lee el error de apt antes de cambiar nada

Ejecuta la actualización por separado para que nada desplace el error fuera de la pantalla.

sudo apt update

Un repositorio de terceros que ha fallado tiene este aspecto. El nombre en clave y la dirección IP serán diferentes en tu equipo.

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.

Hay dos elementos de esa salida que determinan qué debes hacer después: el código de estado y la URL completa de la línea E: Failed to fetch. No hagas suposiciones a partir de la línea de resumen final. Copia la URL y consulta el servidor directamente.

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

Esto muestra 200 para un nombre en clave que Tailscale publica. Al comprobarlo en octubre de 2026, noble devuelve un índice firmado que contiene Origin: Tailscale y Codename: noble. Sustituye noble por el nombre en clave del error de tu equipo y vuelve a ejecutarlo. Si curl obtiene 200 donde apt obtuvo un error de descarga, el repositorio es accesible y el problema está en la configuración de apt. Sin embargo, un 200 sólo demuestra que la descarga se realizó correctamente: después de descargar el índice, apt todavía comprueba su firma. Si hay un problema con la clave, el proceso falla en ese punto; la sección sobre el keyring que aparece más abajo explica ese caso.

Qué indica el código de estado

• 404 Not Found significa que el repositorio no tiene ningún archivo en esa ruta. En pkgs.tailscale.com casi siempre se trata del nombre en la URL.
• 403 Forbidden significa que algo respondió y rechazó la solicitud. En octubre de 2026 este repositorio devuelve 404 para una ruta que no existe, por lo que un 403 suele indicar un proxy, un dispositivo de filtrado o un firewall entre su servidor y Tailscale. No siempre es así: pkgs.tailscale.com se sirve mediante Amazon CloudFront, y AWS documenta que una distribución de CloudFront también puede devolver 403 desde su propio lado, por ejemplo debido a una regla de firewall o al servidor de origen.
• 407 Proxy Authentication Required significa que un proxy solicita credenciales que apt no está enviando. 401 Unauthorized es diferente: es un desafío de credenciales para el recurso solicitado, enviado con una cabecera WWW-Authenticate, y por sí solo no identifica un proxy. Este repositorio sirve sus archivos sin credenciales, por lo que un 401 normalmente significa que otra entidad respondió para esa URL, como una pasarela que intercepta las conexiones. El comando de depuración de la sección sobre el proxy muestra a qué host llegó realmente apt.
• Un error de conexión o de resolución de nombres significa que no se produjo ninguna conversación HTTP. Vaya directamente a la sección sobre IPv6.

El nombre en la URL no está publicado por Tailscale

Tailscale crea un directorio independiente para cada nombre en clave de Ubuntu. Si se solicita un nombre en clave que no existe, se obtiene un error 404 porque el servidor no tiene ningún directorio dists/<codename> que pueda servir. La lista del propio proveedor en pkgs.tailscale.com/stable muestra cuáles están disponibles. En octubre de 2026, la lista va desde 16.04 hasta resolute, que corresponde a Ubuntu 26.04.

La forma habitual de introducir un nombre en clave incorrecto es ejecutar lsb_release -cs en una distribución basada en Ubuntu, pero que no es Ubuntu. En Linux Mint 22, ese comando muestra wilma, el nombre en clave propio de Mint, y Tailscale no publica nada para él. Consulte la base de Ubuntu.

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

En Ubuntu, ambos valores son iguales. En una distribución derivada, VERSION_CODENAME es el nombre de la distribución derivada y UBUNTU_CODENAME es la versión de Ubuntu sobre la que se basa. Use UBUNTU_CODENAME en ambas URL.

La segunda posibilidad es una actualización de versión. La herramienta de actualización de Ubuntu deshabilita las fuentes de terceros mientras se ejecuta. Por eso, después de actualizar Ubuntu 24.04 a 26.04, encontrará /etc/apt/sources.list.d/tailscale.list comentado o todavía con el nombre noble en un equipo que ahora ejecuta resolute. Corríjalo volviendo a ejecutar los dos comandos curl con el nuevo nombre en clave. Estos comandos sobrescriben ambos archivos. Si la actualización se detuvo a mitad del proceso y dpkg informa de paquetes parcialmente configurados, en lugar de tratarse sólo de este repositorio, recupere la actualización de versión fallida primero. Ninguna corrección de tailscale.list se mantendrá en un sistema en el que apt no puede terminar la configuración.

La tercera posibilidad es el momento de la instalación. Si instala el paquete en una versión nueva de Ubuntu antes de que Tailscale haya añadido su nombre en clave, obtendrá el mismo error 404. Ese intervalo suele ser corto o no existir. El problema de seguimiento de Tailscale para la compatibilidad de instalación con Ubuntu 24.04 se cerró como completado en enero de 2024, varios meses antes del lanzamiento de esa versión. Si se encuentra en ese intervalo, normalmente puede apuntar el archivo al nombre en clave de la LTS anterior, porque estos paquetes tienen pocas dependencias. Sin embargo, ejecutará una compilación preparada para una versión anterior. Compruebe qué instaló realmente con apt policy tailscale y vuelva a cambiar el archivo cuando aparezca el nombre en clave correcto.

El keyring está vacío y el comando que lo escribió no mostró ningún mensaje

Este caso no muestra errores y es donde terminan la mayoría de estos problemas. Vuelva a revisar el comando del keyring:

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

El shell construye toda la canalización antes de ejecutar cualquiera de los programas, por lo que sudo tee abre la ruta del keyring y la trunca inmediatamente a cero bytes. Si curl falla, y -f hace que falle ante cualquier error HTTP, curl no escribe nada y termina con un código distinto de cero. El archivo queda con cero bytes. El estado de salida de una canalización es el estado de su último comando, que es tee, y este terminó correctamente. No se muestra nada y se continúa con el comando siguiente creyendo que la clave está instalada.

Compruebe el archivo, no el comando que lo creó.

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

Un keyring correcto muestra una línea pub y una línea uid con Tailscale. Un archivo de cero bytes muestra gpg: no valid OpenPGP data found. y nada más. Un archivo que recibió una página de error HTML muestra lo mismo, y head -c 80 sobre ese archivo muestra el inicio de una página web en lugar de datos binarios de una clave.

Con un keyring que no contiene ninguna clave utilizable, sudo apt update descarga el índice y después lo rechaza. Se muestra una línea W: GPG error con el repositorio de Tailscale y su suite, el texto The following signatures couldn't be verified because the public key is not available: NO_PUBKEY seguido de un identificador de clave de 16 caracteres y, debajo, un error que indica que el repositorio no está firmado. Observe lo que indica apt: descargó correctamente el índice, pero no pudo comprobar la firma. Es un problema de la clave, no de la red. Si falta por completo el archivo del keyring, el mensaje vuelve a ser diferente y muestra directamente la ruta con Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Escriba la clave en dos pasos para que una descarga fallida no pueda destruir un keyring operativo.

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

La línea intermedia es el control: si no muestra un uid de Tailscale, deténgase y no copie el archivo. El modo 0644 es importante porque apt cambia al usuario sin privilegios _apt para descargar y verificar; por tanto, un keyring que sólo root puede leer es un keyring que apt no puede utilizar.

Tanto un archivo .list como un archivo .sources describen el mismo repositorio

Ubuntu trasladó sus propios orígenes al formato deb822 en Ubuntu 24.04 LTS, cuando /etc/apt/sources.list pasó a ser /etc/apt/sources.list.d/ubuntu.sources. Tailscale todavía publica el formato de una sola línea. En octubre de 2026, no hay ningún archivo .sources disponible para descargar desde pkgs.tailscale.com: esa URL devuelve 404. Por tanto, si su equipo tiene un archivo tailscale.sources, usted o alguna guía lo creó manualmente. Si tailscale.list también sigue presente, apt tiene ahora el mismo repositorio descrito dos veces.

La versión leve muestra una advertencia en cada actualización:

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

La versión grave se produce cuando los dos archivos especifican rutas de keyring diferentes, porque apt no puede decidir qué clave controla el repositorio. Muestra E: Conflicting values set for option Signed-By regarding source, después el repositorio y su suite, luego las dos rutas de keyring separadas por != y, finalmente, se niega a continuar:

E: The list of sources could not be read.

Este problema bloquea todos los comandos de apt, no sólo la actualización, hasta que se elimine uno de los archivos. El mismo fallo aparece con los repositorios propios de Ubuntu. El error de origen de apt duplicado después de una migración a deb822 explica el caso general.

Busque todos los archivos que mencionen Tailscale antes de eliminar nada.

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

Conserve un solo archivo. Para deshabilitar el otro sin perderlo, cámbiele el nombre: apt sólo lee los archivos que terminan en .list o .sources, por lo que tailscale.list.bak se omite y permanece en el disco como referencia.

Escritura correcta del archivo de fuentes deb822

Si prefiere el formato más reciente, convierta el archivo que ya tiene en lugar de volver a escribir la dirección del repositorio, porque un error tipográfico ahí es precisamente cómo comienzan los errores anteriores. Las versiones recientes de apt incluyen un conversor que reescribe los archivos .list en estrofas deb822 y traslada la opción signed-by como Signed-By.

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

Ubuntu 24.04 incluye una versión de apt anterior a ese subcomando, por lo que la línea de ayuda le indica en un segundo si la suya lo admite. Si no lo admite, genere la estrofa a partir de la línea que ya está guardada en el disco, para que la base proceda del archivo del proveedor y no del 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

Eso muestra la estrofa que escribió, de modo que puede revisar los campos antes del siguiente apt update. Conviene conocer cuatro de ellos en detalle, porque cada uno falla de una forma diferente:

• URIs se detiene en la base del repositorio. Si pega en él la parte dists/noble, se produce un error 404, porque apt añade dists/<suite> por su cuenta y solicita dists/noble/dists/noble.
• Suites es el nombre en clave, exactamente el valor que aparecía en el centro del formato de una sola línea.
• Signed-By recibe una ruta absoluta a un archivo de conjunto de claves. También acepta una clave con formato ASCII incluida debajo, donde cada línea de la clave lleva una sangría de un espacio y cada línea en blanco dentro de la clave se escribe como un único punto.
• Enabled: no desactiva una fuente sin eliminarla. Esto es más fácil de deshacer que cambiarle el nombre y más fácil de explicar a la siguiente persona.

Mantenga una estrofa por archivo para los repositorios de terceros y deje una línea en blanco entre estrofas si alguna vez mantiene varias juntas. El índice del repositorio incluye amd64 y arm64 entre sus arquitecturas, por lo que una VPS ARM no necesita ningún campo Architectures adicional.

Un proxy intermedio devuelve 403

Como una ruta que este repositorio no tiene devuelve 404, un 403 no indica que falte un archivo. Lo más habitual es que proceda de un dispositivo situado entre su servidor y Tailscale, aunque la CDN situada delante del repositorio también puede devolverlo. Empiece por la configuración del propio apt, porque un proxy definido allí se aplica a apt, pero no al curl interactivo.

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

A continuación, observe qué envía realmente apt.

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

Esto muestra la línea de solicitud, las cabeceras que envió apt y el proxy a través del que se conectó, si hay alguno. Compárelo con un curl simple a la misma URL. Si curl devuelve 200 y apt devuelve 403, las dos solicitudes difieren en algún aspecto que el dispositivo intermedio tiene en cuenta. El candidato habitual es el agente de usuario:

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

Si ese comando devuelve 403 mientras que el curl predeterminado devuelve 200, un dispositivo de filtrado está rechazando apt por su nombre. La corrección debe hacerse en ese dispositivo, no en su servidor. Si todas las solicitudes de su servidor devuelven 403, ejecute el mismo curl desde un equipo conectado a otra red: un 200 allí sitúa el bloqueo en su lado, mientras que un 403 en todas partes apunta al servicio; en ese caso, consulte la página de estado de Tailscale. Un proxy corporativo que inspecciona TLS se comporta de otra forma: apt informa de un fallo de verificación del certificado en lugar de un código de estado, porque el certificado recibido fue emitido por el proxy y no por la autoridad certificadora de Tailscale. Un firewall de salida en la nube que sólo permite los mirrors de Ubuntu es otra fuente habitual. En ese caso, la corrección consiste en permitir pkgs.tailscale.com en el firewall.

Egreso sólo por IPv6 y errores que no son códigos de estado

Si apt nunca recibió una respuesta HTTP, pruebe cada protocolo por separado.

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

Cuando IPv4 responde y IPv6 se queda bloqueado o informa Network is unreachable, apt falla porque la biblioteca del resolvedor prefiere IPv6 y el servidor no tiene una ruta IPv6 funcional. Fuerce una ejecución sobre IPv4 para confirmar esta hipótesis:

sudo apt -o Acquire::ForceIPv4=true update

Si esa actualización funciona, haga el cambio permanente.

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

Considere también el caso contrario. En un VPS que no tiene ninguna dirección IPv4, forzar IPv4 no soluciona nada porque no existe una ruta IPv4 por la que se pueda encaminar el tráfico. En ese caso necesita NAT64 con DNS64 de su proveedor o un proxy que tenga una dirección IPv4. El síntoma es un error de conexión que muestra una dirección IPv6, por lo que la línea curl -6 es la que indica la causa real.

Las alternativas y el coste de cada una

El script de instalación del proveedor. curl -fsSL https://tailscale.com/install.sh | sh es el comando que anuncia Tailscale. Al leer el script, se comprueba la distribución a partir de /etc/os-release y después se escriben las mismas dos rutas que se han corregido en esta guía: /usr/share/keyrings/tailscale-archive-keyring.gpg y /etc/apt/sources.list.d/tailscale.list, desde las mismas URL. Esto afecta a sus expectativas: no evita un repositorio que un proxy esté bloqueando. Falla de la misma forma, pero con menos salida. Pasar un script descargado a un shell como root es una concesión, no una solución, porque confía en lo que el servidor devuelva en ese momento y no conserva una copia de lo que se ejecutó. Si acepta esta concesión, hágalo con conocimiento de causa:

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

Los binarios estáticos. El mismo servidor publica archivos tar sin formato en la sección de binarios estáticos de pkgs.tailscale.com/stable. En octubre de 2026, la versión estable es 1.104.1 y el archivo x86 de 64 bits es tailscale_1.104.1_amd64.tgz. Debe colocar usted mismo el cliente tailscale y el daemon tailscaled, y también supervisar el daemon, por lo que no existe la ruta apt upgrade y cada actualización futura requiere que recuerde descargarla. Esta opción resulta útil en un host aislado de la red o cuando debe fijar una versión exacta.

El paquete propio de Ubuntu. El archivo no contiene ningún deb. Ejecutar sudo apt install tailscale sin configurar el repositorio del proveedor termina en E: Unable to locate package tailscale, y ningún apt update puede cambiarlo. Canonical sí publica un snap, que se instala con sudo snap install tailscale, y como procede de Snap Store evita todos los errores de apt anteriores. En la comprobación realizada en octubre de 2026, su canal 1/stable contenía la versión 1.102.3, más antigua que la versión actual 1.104.1 de Tailscale, y la ficha indica que Canonical lo mantiene y que no cuenta necesariamente con el respaldo de los desarrolladores originales. Se actualiza según el calendario de snapd; cómo controlar las actualizaciones de snap en Ubuntu Server explica cómo administrarlas. Si en realidad quiere un servidor de coordinación bajo su control en lugar del servidor alojado de Tailscale, se trata de una decisión independiente: cómo ejecutar Headscale como su propio servidor de control lo explica, y la comparación entre Tailscale y WireGuard sin más indica si necesita toda esta infraestructura.

El paquete se instaló, pero tailscaled no se inicia

Cuando apt termina correctamente, los fallos pasan al daemon.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

En un VPS que usa virtualización basada en contenedores y comparte el kernel del host, como LXC u OpenVZ, el registro contiene una línea que indica que /dev/net/tun no existe. El daemon necesita un dispositivo TUN para crear la interfaz tailscale0, pero el contenedor no recibió uno. Pida a su proveedor que habilite TUN en el contenedor o cambie a un plan KVM, donde dispondrá de su propio kernel. En KVM funciona sin configuración adicional.

Después, sudo tailscale up muestra una URL de inicio de sesión y tailscale status debe mostrar su máquina con una dirección del rango 100.64.0.0/10. Una máquina que aparece ahí es una máquina sobre la que puede seguir trabajando, ya sea anunciando una subred privada desde su VPS o usando el VPS como nodo de salida.

FAQ

¿Por qué apt indica que el repositorio de Tailscale no está firmado?

Porque apt descargó el índice del repositorio y no pudo verificar su firma con /usr/share/keyrings/tailscale-archive-keyring.gpg. La causa habitual es que el keyring tiene cero bytes: sudo tee truncó el archivo antes de que curl pudiera descargar algo, y la canalización indicó éxito porque tee terminó correctamente. Ejecute gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Un keyring válido muestra una línea pub y una línea uid con el nombre Tailscale, mientras que uno vacío o dañado muestra gpg: no valid OpenPGP data found. Descargue la clave en un archivo temporal, compruébela allí y cópiela después a su ubicación con el modo 0644 para que el usuario _apt pueda leerla.

¿Qué nombre en clave de Ubuntu debo incluir en las URL de Tailscale?

Use el valor de UBUNTU_CODENAME obtenido de /etc/os-release. En Ubuntu 24.04 es noble y en Ubuntu 26.04 es resolute. No use lsb_release -cs en una distribución derivada de Ubuntu: en Linux Mint 22 muestra wilma, Tailscale no publica nada con ese nombre y apt informa de un error 404 en dists/wilma/InRelease. Confirme la elección antes de modificar nada. Para ello, descargue manualmente el índice con curl -sS -o /dev/null -w '%{http_code}\n' usando https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

¿Es seguro ejecutar el script de instalación de Tailscale canalizado a un shell?

Debe decidirlo de forma consciente. El script procede de Tailscale y realiza los mismos pasos manuales: lee /etc/os-release, escribe el mismo keyring y el mismo /etc/apt/sources.list.d/tailscale.list y después instala el paquete. El coste es que ejecuta con root lo que el servidor devuelva en ese momento y no conserva ningún registro. Descárguelo con -o install.sh, léalo y ejecútelo después si quiere la comodidad sin perder visibilidad. Tampoco puede resolver un repositorio bloqueado, porque usa las mismas URL que ya han fallado.

¿Cómo instalo Tailscale en Ubuntu sin el repositorio apt?

Tiene dos opciones. La primera es el snap que mantiene Canonical, sudo snap install tailscale, que en octubre de 2026 incluía la versión 1.102.3 en su canal 1/stable y no cuenta necesariamente con el respaldo de Tailscale. La segunda son los tarballs estáticos publicados en pkgs.tailscale.com, que en octubre de 2026 estaban en la versión 1.104.1, con un archivo amd64 llamado tailscale_1.104.1_amd64.tgz. Con los tarballs, debe instalar manualmente los programas tailscale y tailscaled y ejecutar manualmente el daemon mediante systemd. El coste son las actualizaciones: no hay ningún paquete apt que descargue una versión nueva, por lo que cada actualización es manual. El archivo de Ubuntu no contiene ningún deb tailscale propio, de modo que sudo apt install tailscale en una máquina sin el repositorio del proveedor se detiene en E: Unable to locate package tailscale.