Tailscale unter Ubuntu installieren: apt-Fehler beheben

Warum Tailscale-Installationsfehler unter Ubuntu apt-Fehler sind

Tailscale-Installationsfehler unter Ubuntu treten fast immer auf, bevor Tailscale-Code ausgeführt wird. Es handelt sich um apt-Fehler. Das Ubuntu-Archiv enthält kein Paket tailscale: Eine Prüfung gegen das Ubuntu-Paketarchiv im Oktober 2026 ergibt als einzige Treffer Go-Hilfsbibliotheken und python3-tailscale. Der Daemon stammt daher normalerweise aus dem eigenen apt-Repository von Tailscale unter pkgs.tailscale.com. Canonical stellt außerdem einen Tailscale-Snap bereit. Dieser wird zusammen mit den anderen Ausweichmöglichkeiten am Ende behandelt.

Beim Hinzufügen dieses Repositorys werden zwei Dateien geschrieben. Eine Datei teilt apt mit, wo sich die Pakete befinden. Die andere enthält den öffentlichen Schlüssel, mit dem apt die Signatur des Repository-Index prüft. Fast jeder unten beschriebene Fehler entsteht dadurch, dass eine dieser beiden Dateien falsch ist oder dass ein Gerät zwischen apt und dem Repository die Anfrage ablehnt.

Dies sind die von Tailscale veröffentlichten Befehle für 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 ist der Codename für Ubuntu 24.04 und erscheint in beiden URLs. Der zweite Befehl schreibt eine Kommentarzeile und eine deb-Zeile in /etc/apt/sources.list.d/tailscale.list. cat zeigt genau an, was dort geschrieben wurde.

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

Lesen Sie die Zeile deb als Adresse mit vier Feldern: zuerst die Option [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg] in eckigen Klammern, dann die Repository-Basis pkgs.tailscale.com/stable/ubuntu, die über https erreicht wird, danach die Suite noble und schließlich die Komponente main. apt setzt die Basis und die Suite zu einer URL zusammen und ruft sie ab: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Wenn Sie diese URL manuell abrufen können, kann apt sie ebenfalls abrufen. Das ist die vollständige Diagnose.

Lesen Sie den apt-Fehler, bevor Sie etwas ändern

Führen Sie das Update separat aus, damit keine andere Ausgabe den Fehler vom Bildschirm verdrängt.

sudo apt update

Ein fehlgeschlagenes Drittanbieter-Repository sieht so aus. Der Codename und die IP-Adresse unterscheiden sich auf Ihrem System.

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.

Zwei Angaben in dieser Ausgabe bestimmen den nächsten Schritt: der Statuscode und die vollständige URL in der Zeile E: Failed to fetch. Raten Sie nicht anhand der Zusammenfassungszeile am Ende. Kopieren Sie die URL und fragen Sie den Server selbst ab.

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

Damit wird 200 für einen Codename ausgegeben, den Tailscale veröffentlicht. Bei einer Prüfung im Oktober 2026 liefert noble einen signierten Index mit Origin: Tailscale und Codename: noble zurück. Ersetzen Sie noble durch den Codename aus Ihrem eigenen Fehler und führen Sie den Befehl erneut aus. Wenn curl 200 erhält, während apt einen Abruffehler meldet, ist das Repository erreichbar und das Problem liegt in der Konfiguration von apt selbst. Ein 200 bestätigt jedoch nur, dass der Download funktioniert hat: apt prüft die Signatur dieses Index weiterhin nach dem Download. Ein Problem mit dem Schlüssel führt an dieser Stelle zu einem Fehler. Das wird im folgenden Abschnitt zu Schlüsselringen behandelt.

Was der Statuscode aussagt

• 404 Not Found bedeutet, dass das Repository unter diesem Pfad keine Datei enthält. Bei pkgs.tailscale.com ist das in der URL fast immer der Codename.
• 403 Forbidden bedeutet, dass eine Gegenstelle geantwortet und den Zugriff verweigert hat. Seit Oktober 2026 liefert dieses Repository für einen nicht vorhandenen Pfad 404. Ein 403 weist daher normalerweise auf einen Proxy, eine Filterkomponente oder eine Firewall zwischen Ihrem Server und Tailscale hin. Das gilt nicht immer: pkgs.tailscale.com wird über Amazon CloudFront bereitgestellt. AWS dokumentiert, dass eine CloudFront-Distribution auch auf ihrer eigenen Seite 403 zurückgeben kann, beispielsweise aufgrund einer Firewall-Regel oder durch den Origin-Server.
• 407 Proxy Authentication Required bedeutet, dass ein Proxy Anmeldedaten verlangt, die apt nicht sendet. 401 Unauthorized ist etwas anderes: Dieser Status fordert Anmeldedaten für die angeforderte Ressource selbst an. Die Aufforderung wird mit einem WWW-Authenticate-Header gesendet. Allein daraus lässt sich kein Proxy erkennen. Dieses Repository stellt seine Dateien ohne Anmeldedaten bereit. Ein 401 bedeutet daher normalerweise, dass eine andere Komponente auf diese URL geantwortet hat, beispielsweise ein Gateway, das die Verbindung abfängt. Der Debug-Befehl im Proxy-Abschnitt zeigt, welchen Host apt tatsächlich erreicht hat.
• Ein Verbindungsfehler oder ein Fehler bei der Namensauflösung bedeutet, dass überhaupt keine HTTP-Kommunikation stattgefunden hat. Fahren Sie mit dem IPv6-Abschnitt fort.

Der Codename in der URL wird von Tailscale nicht veröffentlicht

Tailscale erstellt für jeden Ubuntu-Codename ein eigenes Verzeichnis. Wenn Sie einen nicht vorhandenen Codename anfordern, erhalten Sie 404, weil auf dem Server kein dists/<codename> zum Ausliefern vorhanden ist. Die eigene Übersicht des Anbieters unter pkgs.tailscale.com/stable zeigt, welche Einträge existieren. Im Oktober 2026 reicht diese Liste von 16.04 bis resolute, also Ubuntu 26.04.

Ein falscher Codename wird meist durch lsb_release -cs auf einer Distribution eingetragen, die auf Ubuntu basiert, aber nicht Ubuntu ist. Unter Linux Mint 22 gibt dieser Befehl wilma aus, den eigenen Codename von Mint. Tailscale veröffentlicht dafür keine Pakete. Ermitteln Sie stattdessen die zugrunde liegende Ubuntu-Version.

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

Unter Ubuntu sind beide Werte identisch. Bei einer abgeleiteten Distribution ist VERSION_CODENAME der Name der Distribution und UBUNTU_CODENAME die Ubuntu-Version, auf der sie basiert. Verwenden Sie UBUNTU_CODENAME in beiden URLs.

Die zweite Möglichkeit ist ein Release-Upgrade. Das Ubuntu-Upgrade-Tool deaktiviert beim Ausführen Quellen von Drittanbietern. Nach dem Upgrade von Ubuntu 24.04 auf 26.04 finden Sie /etc/apt/sources.list.d/tailscale.list daher entweder auskommentiert vor oder es verweist weiterhin auf noble, obwohl auf dem System bereits resolute läuft. Beheben Sie das Problem, indem Sie die beiden curl-Befehle mit dem neuen Codename erneut ausführen. Dadurch werden beide Dateien überschrieben. Wenn das Upgrade selbst abgebrochen wurde und dpkg nicht nur über dieses Repository, sondern über halb konfigurierte Pakete klagt, beheben Sie zuerst das fehlgeschlagene Release-Upgrade. Eine Korrektur von tailscale.list bleibt nicht bestehen, solange apt die Konfiguration des Systems nicht abschließen kann.

Die dritte Möglichkeit ist der Zeitpunkt der Installation. Wenn Sie eine neue Ubuntu-Version installieren, bevor Tailscale deren Codename hinzugefügt hat, erhalten Sie denselben 404-Fehler. Dieses Zeitfenster ist oft kurz oder gar nicht vorhanden. Tailscales Tracking-Issue zur Installationsunterstützung für Ubuntu 24.04 wurde im Januar 2024 als abgeschlossen geschlossen, also Monate vor der Veröffentlichung dieser Version. Wenn Sie dennoch in dieses Zeitfenster fallen, funktioniert die Angabe des vorherigen LTS-Codenamens normalerweise, weil diese Pakete nur wenige Abhängigkeiten haben. Sie verwenden dann jedoch einen Build für eine ältere Version. Prüfen Sie mit apt policy tailscale, was tatsächlich installiert wurde, und ändern Sie die Datei zurück, sobald der richtige Codename verfügbar ist.

Der Keyring ist leer, und der Befehl, der ihn geschrieben hat, gab nichts aus

Dieser Fehler bleibt unauffällig. In den meisten Fällen endet die Fehlersuche hier. Sehen Sie sich den Befehl für den Keyring noch einmal an:

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

Die Shell erstellt die gesamte Pipeline, bevor eines der beiden Programme startet. Daher öffnet sudo tee den Pfad zum Keyring und setzt die Datei sofort auf eine Größe von null Byte. Wenn curl anschließend fehlschlägt und -f curl bei jedem HTTP-Fehler fehlschlagen lässt, schreibt curl nichts und beendet sich mit einem Fehlerstatus. Die Datei bleibt leer. Der Exit-Status einer Pipeline entspricht dem Status ihres letzten Befehls. Das ist tee, und dieser Befehl war erfolgreich. Es wird nichts ausgegeben. Sie fahren mit dem nächsten Befehl fort und gehen davon aus, dass der Schlüssel installiert wurde.

Prüfen Sie die Datei, nicht den Befehl, der sie erstellt hat.

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

Ein intakter Keyring gibt eine Zeile mit pub und eine Zeile mit uid aus, die Tailscale nennt. Eine Datei mit null Byte gibt gpg: no valid OpenPGP data found. und sonst nichts aus. Eine Datei, in der eine HTML-Fehlerseite gelandet ist, verhält sich genauso. head -c 80 zeigt darin den Anfang einer Webseite statt binärer Schlüsseldaten.

Wenn der Keyring keinen verwendbaren Schlüssel enthält, lädt sudo apt update den Index herunter und weist ihn anschließend zurück. Es wird eine Zeile mit W: GPG error ausgegeben, die das Tailscale-Repository und dessen Suite nennt. Darunter steht The following signatures couldn't be verified because the public key is not available: NO_PUBKEY gefolgt von einer 16 Zeichen langen Schlüssel-ID. Danach erscheint die Fehlermeldung, dass das Repository nicht signiert ist. Beachten Sie, was apt damit mitteilt: Der Index wurde erfolgreich heruntergeladen, aber die Signatur konnte nicht geprüft werden. Das ist ein Schlüsselproblem, kein Netzwerkproblem. Wenn die Keyring-Datei vollständig fehlt, ist die Meldung wieder anders. Sie nennt den Pfad direkt mit Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Schreiben Sie den Schlüssel in zwei Schritten, damit ein fehlgeschlagener Download keinen funktionierenden Keyring zerstören kann.

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

Die mittlere Zeile ist die Prüfbedingung. Wenn sie keinen Tailscale-uid ausgibt, brechen Sie ab und kopieren Sie die Datei nicht. Der Modus 0644 ist wichtig, weil apt zum Abrufen und Prüfen auf den unprivilegierten Benutzer _apt wechselt. Ein Keyring, den nur root lesen kann, ist für apt nicht verwendbar.

Eine .list- und eine .sources-Datei beschreiben dasselbe Repository

Ubuntu hat seine eigenen Paketquellen in Ubuntu 24.04 LTS auf das deb822-Format umgestellt. Dabei wurde /etc/apt/sources.list zu /etc/apt/sources.list.d/ubuntu.sources. Tailscale veröffentlicht weiterhin das einzeilige Format. Bei einer Prüfung im Oktober 2026 gab es keine .sources-Datei zum Herunterladen von pkgs.tailscale.com: Die URL liefert den Statuscode 404. Wenn auf Ihrem System also eine tailscale.sources vorhanden ist, wurde sie von Ihnen oder einem Tutorial manuell erstellt. Wenn tailscale.list ebenfalls noch vorhanden ist, ist dasselbe Repository in apt jetzt doppelt beschrieben.

Die harmlose Variante ist eine Warnung bei jedem Update:

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

Die schwerwiegende Variante tritt auf, wenn die beiden Dateien unterschiedliche Keyring-Pfade angeben, weil apt nicht entscheiden kann, welcher Schlüssel für das Repository gilt. apt gibt E: Conflicting values set for option Signed-By regarding source aus, danach das Repository und seine Suite, anschließend die beiden Keyring-Pfade mit != dazwischen, und verweigert dann die weitere Ausführung:

E: The list of sources could not be read.

Dadurch werden alle apt-Befehle blockiert, nicht nur das Update, bis eine der Dateien entfernt wird. Derselbe Fehler tritt bei den Ubuntu-eigenen Repositories auf. Der Artikel Der Fehler durch doppelte apt-Paketquellen nach einer deb822-Migration erklärt den allgemeinen Fall.

Suchen Sie nach jeder Datei, die Tailscale erwähnt, bevor Sie etwas löschen.

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

Behalten Sie eine Datei. Um die andere zu deaktivieren, ohne sie zu verlieren, benennen Sie sie um: apt liest nur Dateien, die mit .list oder .sources enden. tailscale.list.bak wird daher übersprungen und bleibt als Referenz auf der Festplatte erhalten.

Die deb822-Quelldatei korrekt schreiben

Wenn Sie das neuere Format bevorzugen, konvertieren Sie die bereits vorhandene Datei, statt die Repository-Adresse erneut einzugeben. Ein Tippfehler an dieser Stelle verursacht genau die oben genannten Fehler. Aktuelle apt-Versionen enthalten einen Konverter, der .list-Dateien in deb822-Stanzas umschreibt und die Option signed-by als Signed-By übernimmt.

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

Ubuntu 24.04 enthält eine apt-Version, die älter als dieses Subkommando ist. Anhand der Hilfezeile sehen Sie daher sofort, ob Ihre Version es unterstützt. Wenn nicht, erstellen Sie die Stanza aus der bereits auf dem Datenträger vorhandenen Zeile. Dadurch stammt die Basis aus der Datei des Anbieters und nicht aus Ihrer Tastatureingabe.

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

Damit wird die geschriebene Stanza ausgegeben. Sie können die Felder daher vor dem nächsten apt update prüfen. Vier Felder sollten Sie im Detail kennen, weil jedes auf eine andere Weise fehlschlägt:

• URIs endet am Basisverzeichnis des Repositorys. Wenn Sie den dists/noble-Teil darin einfügen, erhalten Sie einen 404-Fehler, weil apt dists/<suite> selbst anhängt und dists/noble/dists/noble anfordert.
• Suites ist der Codename, also genau der Wert, der in der einzeiligen Formatvariante in der Mitte stand.
• Signed-By erwartet einen absoluten Pfad zu einer Keyring-Datei. Darunter können Sie auch einen ASCII-armored Key inline einfügen. Jede Zeile des Keys muss dabei um ein Leerzeichen eingerückt sein, und jede Leerzeile innerhalb des Keys wird als einzelner Punkt geschrieben.
• Enabled: no deaktiviert eine Quelle, ohne sie zu löschen. Das lässt sich leichter rückgängig machen als eine Umbenennung und ist für die nächste zuständige Person einfacher nachzuvollziehen.

Verwenden Sie für Drittanbieter-Repositories jeweils eine Stanza pro Datei. Wenn Sie mehrere Stanzas gemeinsam speichern, setzen Sie eine Leerzeile zwischen sie. Der Repository-Index führt amd64 und arm64 als Architekturen auf. Für eine ARM-VPS ist daher kein zusätzliches Architectures-Feld erforderlich.

Ein Proxy dazwischen liefert 403

Da ein Pfad, den dieses Repository nicht besitzt, mit 404 beantwortet wird, weist 403 nicht auf eine fehlende Datei hin. Meistens wird der Status von einem Gerät zwischen Ihrem Server und Tailscale erzeugt. Auch das CDN vor dem Repository kann ihn zurückgeben. Beginnen Sie mit der eigenen Konfiguration von apt. Ein dort gesetzter Proxy gilt für apt, nicht für Ihr interaktives curl.

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

Überwachen Sie anschließend, was apt tatsächlich sendet.

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

Damit werden die Anforderungszeile, die von apt gesendeten Header und gegebenenfalls der verwendete Proxy ausgegeben. Vergleichen Sie diese Ausgabe mit einem einfachen curl-Aufruf für dieselbe URL. Wenn curl 200 zurückgibt und apt 403, unterscheiden sich die beiden Anforderungen in einem für das zwischengeschaltete Gerät relevanten Detail. Der häufigste Kandidat ist der 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

Wenn dieser Aufruf 403 zurückgibt, während das Standard-curl 200 liefert, verweigert ein Filtergerät apt anhand seines Namens. Die Korrektur muss auf diesem Gerät erfolgen, nicht auf Ihrem Server. Wenn jede Anforderung von Ihrem Server 403 zurückgibt, führen Sie dasselbe curl von einem Rechner in einem anderen Netzwerk aus: Ein 200 dort ordnet die Sperre Ihrer Seite zu. Ein 403 überall weist dagegen auf den Dienst hin. Prüfen Sie in diesem Fall die Statusseite von Tailscale. Ein Unternehmensproxy, der TLS inspiziert, verhält sich wiederum anders: apt meldet einen Fehler bei der Zertifikatsprüfung statt eines Statuscodes, weil das empfangene Zertifikat vom Proxy und nicht von der Zertifizierungsstelle von Tailscale ausgestellt wurde. Eine Cloud-Egress-Firewall, die nur die Ubuntu-Spiegelserver zulässt, ist eine weitere häufige Ursache. Dort müssen Sie pkgs.tailscale.com in der Firewall zulassen.

Nur ausgehender IPv6-Verkehr und Fehler, die keine Statuscodes sind

Wenn apt keine HTTP-Antwort erhalten hat, testen Sie jedes Protokoll einzeln.

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

Wenn IPv4 antwortet und IPv6 hängt oder Network is unreachable meldet, schlägt apt fehl, weil die Resolver-Bibliothek IPv6 bevorzugt und auf dem Server kein funktionierender IPv6-Pfad vorhanden ist. Erzwingen Sie einen Lauf über IPv4, um diese Annahme zu bestätigen:

sudo apt -o Acquire::ForceIPv4=true update

Wenn dieses Update erfolgreich ist, machen Sie die Einstellung dauerhaft.

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

Berücksichtigen Sie auch den umgekehrten Fall. Auf einem VPS ohne IPv4-Adresse hilft das Erzwingen von IPv4 nicht, weil keine IPv4-Route vorhanden ist, über die der Datenverkehr geleitet werden kann. In diesem Fall benötigen Sie NAT64 mit DNS64 von Ihrem Provider oder einen Proxy mit einer IPv4-Adresse. Das Symptom ist ein Verbindungsfehler, der eine IPv6-Adresse nennt. Daher ist die Zeile curl -6 diejenige, die die tatsächliche Ursache zeigt.

Die Alternativen und ihre jeweiligen Kosten

Das Installationsskript des Anbieters. curl -fsSL https://tailscale.com/install.sh | sh ist der von Tailscale beworbene Befehl. Beim Lesen des Skripts zeigt sich, dass es anhand von /etc/os-release Ihre Distribution erkennt und anschließend dieselben beiden Pfade, die in diesem Leitfaden korrigiert wurden, /usr/share/keyrings/tailscale-archive-keyring.gpg und /etc/apt/sources.list.d/tailscale.list, von denselben URLs schreibt. Das ist für Ihre Erwartungen wichtig: Das Skript umgeht kein Repository, das von einem Proxy blockiert wird. Es schlägt auf dieselbe Weise fehl, nur mit weniger Ausgabe. Ein heruntergeladenes Skript als root in eine Shell zu pipen ist ein Abwägen, keine Lösung, weil Sie dem vertrauen, was der Server in diesem Moment zurückgibt, und keine Kopie des ausgeführten Skripts behalten. Wenn Sie diesen Kompromiss eingehen, sollten Sie die Folgen kennen:

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

Die statischen Binärdateien. Derselbe Server veröffentlicht im Abschnitt für statische Binärdateien von pkgs.tailscale.com/stable einfache Tarballs. Im Oktober 2026 ist die stabile Version 1.104.1, und die 64-Bit-x86-Datei heißt tailscale_1.104.1_amd64.tgz. Sie installieren den tailscale-Client und den tailscaled-Daemon selbst und müssen den Daemon selbst überwachen. Daher gibt es keinen apt upgrade-Pfad, und jedes zukünftige Update müssen Sie selbst herunterladen. Diese Variante ist für einen vom Netzwerk getrennten Host sinnvoll oder wenn Sie eine exakt festgelegte Version verwenden müssen.

Das Ubuntu-eigene Paket. Das Archiv enthält kein deb-Paket. Wenn Sie sudo apt install tailscale ohne konfiguriertes Anbieter-Repository ausführen, endet der Vorgang mit E: Unable to locate package tailscale. Auch apt update ändert daran nichts. Canonical veröffentlicht jedoch ein Snap, das Sie mit sudo snap install tailscale installieren. Da es aus dem Snap Store stammt, umgeht es alle oben genannten apt-Fehler. Bei einer Prüfung im Oktober 2026 enthielt sein 1/stable-Kanal die Version 1.102.3. Diese ist älter als Tailscales aktuelle Version 1.104.1. In der Paketbeschreibung steht außerdem, dass Canonical das Paket pflegt und dass es nicht unbedingt von den Upstream-Entwicklern unterstützt wird. Das Paket wird nach dem Zeitplan von snapd aktualisiert. Der Abschnitt Snap-Updates auf Ubuntu Server steuern erklärt, wie Sie diese Updates verwalten. Wenn Sie tatsächlich einen Koordinationsserver unter Ihrer eigenen Kontrolle statt des von Tailscale gehosteten Servers benötigen, ist das eine separate Entscheidung: Headscale als eigenen Control Server betreiben behandelt dieses Thema. Der Vergleich zwischen Tailscale und einfachem WireGuard hilft Ihnen bei der Entscheidung, ob Sie diese Infrastruktur überhaupt benötigen.

Das Paket wurde installiert, aber tailscaled startet nicht

Sobald apt ordnungsgemäß arbeitet, verlagern sich die Fehler auf den Daemon.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

Auf einem VPS mit containerbasierter Virtualisierung, die den Kernel des Hosts gemeinsam nutzt, beispielsweise LXC oder OpenVZ, enthält das Log eine Zeile darüber, dass /dev/net/tun nicht vorhanden ist. Der Daemon benötigt ein TUN-Gerät, um die tailscale0-Schnittstelle zu erstellen. Der Container wurde jedoch nicht mit einem solchen Gerät ausgestattet. Bitten Sie Ihren Anbieter, TUN für den Container zu aktivieren, oder wechseln Sie zu einem KVM-Tarif mit eigenem Kernel. Unter KVM funktioniert dies ohne zusätzliche Einrichtung.

Danach gibt sudo tailscale up eine Anmelde-URL aus. tailscale status sollte Ihren Rechner anschließend mit einer Adresse aus dem Bereich 100.64.0.0/10 auflisten. Ein dort angezeigter Rechner eignet sich als Grundlage für weitere Konfigurationen. Sie können beispielsweise ein privates Subnetz von Ihrem VPS aus bekanntgeben oder den VPS als Exit-Node verwenden.

FAQ

Warum meldet apt, dass das Tailscale-Repository nicht signiert ist?

apt hat den Repository-Index heruntergeladen, konnte seine Signatur jedoch nicht anhand von /usr/share/keyrings/tailscale-archive-keyring.gpg überprüfen. Die übliche Ursache ist ein leerer Keyring mit 0 Bytes: sudo tee hat die Datei abgeschnitten, bevor curl Daten herunterladen konnte, und die Pipeline hat Erfolg gemeldet, weil tee erfolgreich war. Führen Sie gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg aus. Ein funktionierender Keyring gibt eine pub-Zeile und eine uid-Zeile mit dem Namen Tailscale aus. Ein leerer oder beschädigter Keyring gibt gpg: no valid OpenPGP data found. aus. Laden Sie den Schlüssel in eine temporäre Datei herunter und prüfen Sie ihn dort. Kopieren Sie ihn anschließend mit dem Modus 0644 an die vorgesehene Stelle, damit der Benutzer _apt ihn lesen kann.

Welchen Ubuntu-Codenamen soll ich in den Tailscale-URLs verwenden?

Verwenden Sie den Wert von UBUNTU_CODENAME aus /etc/os-release. Unter Ubuntu 24.04 ist dies noble, unter Ubuntu 26.04 resolute. Verwenden Sie lsb_release -cs nicht auf einer von Ubuntu abgeleiteten Distribution. Unter Linux Mint 22 gibt der Befehl wilma aus. Tailscale veröffentlicht unter diesem Namen nichts, und apt meldet für dists/wilma/InRelease einen 404-Fehler. Bestätigen Sie Ihre Auswahl, bevor Sie Dateien bearbeiten. Rufen Sie den Index mit curl -sS -o /dev/null -w '%{http_code}\n' manuell von https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease ab.

Ist es sicher, das Tailscale-Installationsskript an eine Shell weiterzuleiten?

Dies ist eine Abwägung, die Sie bewusst treffen sollten. Das Skript stammt von Tailscale und führt dieselben manuellen Schritte aus: Es liest /etc/os-release, schreibt denselben Keyring und dieselbe /etc/apt/sources.list.d/tailscale.list und installiert anschließend das Paket. Der Nachteil ist, dass Sie mit root genau das ausführen, was der Server in diesem Moment zurückgibt, ohne eine lokale Kopie davon zu behalten. Laden Sie das Skript mit -o install.sh herunter und lesen Sie es. Führen Sie es danach aus, wenn Sie den Komfort nutzen möchten, ohne den Inhalt ungeprüft auszuführen. Bei einem blockierten Repository hilft das Skript nicht, da es dieselben URLs verwendet, die bereits fehlgeschlagen sind.

Wie installiere ich Tailscale unter Ubuntu ohne das apt-Repository?

Dafür gibt es zwei Möglichkeiten. Die erste ist der von Canonical gepflegte Snap sudo snap install tailscale. Im Oktober 2026 enthielt dessen 1/stable-Kanal die Version 1.102.3. Diese Variante wird nicht unbedingt von Tailscale unterstützt. Die zweite Möglichkeit sind die auf pkgs.tailscale.com veröffentlichten statischen Tarballs. Im Oktober 2026 lagen sie in der Version 1.104.1 vor. Für amd64 gab es die Datei tailscale_1.104.1_amd64.tgz. Bei den Tarballs installieren Sie die Programme tailscale und tailscaled selbst und führen den Daemon selbst unter systemd aus. Der Nachteil sind die Aktualisierungen: Es gibt kein apt-Paket, das eine neue Version einspielt. Jedes Update muss daher manuell erfolgen. Das Ubuntu-Archiv enthält kein eigenes tailscale-deb-Paket. Deshalb bleibt sudo apt install tailscale auf einem Rechner ohne Hersteller-Repository bei E: Unable to locate package tailscale stehen.