Tailscale-Installationsfehler unter Ubuntu 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. Ubuntu stellt kein eigenes tailscale-Paket bereit: Eine Prüfung des Ubuntu-Paketarchivs im August 2026 ergab als einzige Treffer Go-Hilfsbibliotheken und python3-tailscale. Der Daemon muss daher aus dem eigenen apt-Repository von Tailscale unter pkgs.tailscale.com installiert werden.

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 der folgenden 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. Mit cat sehen Sie genau, welcher Inhalt dort geschrieben wurde.

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

Lesen Sie die deb-Zeile 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, anschließend die Suite noble und zuletzt 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 gesamte Diagnose.

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

Führen Sie das Update separat aus, damit keine andere Ausgabe den Fehler aus dem Terminal scrollt.

sudo apt update

Ein fehlgeschlagenes Repository eines Drittanbieters 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 das weitere Vorgehen: der Statuscode und die vollständige URL in der Zeile E: Failed to fetch. Leiten Sie nichts aus der Zusammenfassungszeile am Ende ab. Kopieren Sie die URL und fragen Sie den Server direkt 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 August 2026 liefert noble einen signierten Index mit Origin: Tailscale und Codename: noble. 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 Fehler meldet, ist das Repository funktionsfähig und das Problem liegt in der Konfiguration von apt.

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 ein System geantwortet und den Zugriff verweigert hat. Im August 2026 gibt dieses Repository für einen nicht vorhandenen Pfad 401 Unauthorized zurück. Ein 407 Proxy Authentication Required weist daher auf einen Proxy, eine Filter-Appliance oder eine Firewall zwischen Ihrem Server und Tailscale hin.
• 401 Unauthorized oder 407 Proxy Authentication Required bedeutet, dass ein Proxy Zugangsdaten verlangt, die apt nicht sendet.
• Ein Verbindungsfehler oder ein Fehler bei der Namensauflösung bedeutet, dass überhaupt keine HTTP-Kommunikation stattgefunden hat. Fahren Sie mit dem Abschnitt zu IPv6 fort.

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

Tailscale erstellt für jeden Ubuntu-Codenamen ein eigenes Verzeichnis. Wenn Sie einen nicht vorhandenen Codename anfordern, erhalten Sie 404, weil auf dem Server kein dists/<codename> vorhanden ist, das ausgeliefert werden könnte. Die eigene Übersicht des Anbieters unter pkgs.tailscale.com/stable zeigt, welche Versionen vorhanden sind. Im August 2026 reicht diese Liste von 16.04 bis resolute, also Ubuntu 26.04.

Ein falscher Codename wird normalerweise 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 Codenamen von Mint. Tailscale veröffentlicht dafür jedoch keine Pakete. Ermitteln Sie stattdessen die Ubuntu-Basis.

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

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

Die zweite Ursache 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 oder auf einem inzwischen mit resolute betriebenen System weiterhin mit noble. Beheben Sie das Problem, indem Sie die beiden curl-Befehle mit dem neuen Codename erneut ausführen. Dadurch werden beide Dateien überschrieben.

Die dritte Ursache ist der Zeitpunkt. In den Wochen nach einem neuen Ubuntu-Release ist der Codename bei Canonical bereits vorhanden, bei Tailscale jedoch noch nicht. Wenn Sie die Datei auf den Codename des vorherigen LTS-Releases verweisen lassen, wird die Installation normalerweise durchgeführt, weil diese Pakete nur wenige Abhängigkeiten haben. Sie verwenden dann jedoch einen Build für ein älteres Release. 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, meldete keinen Fehler

Dieser Fall bleibt unauffällig. Hier enden die meisten dieser Fehler. 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 ausgeführt wird. Deshalb ö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 wird mit einem Fehlerstatus beendet. Die Datei bleibt leer. Der Exit-Status einer Pipeline ist der 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 nehmen an, 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 pub-Zeile und eine uid-Zeile mit dem Namen Tailscale aus. 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 darauf zeigt jedoch 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. Sie erhalten eine W: GPG error-Zeile mit dem Namen des Tailscale-Repositorys und seiner Suite, den Text 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 und darunter eine Fehlermeldung, dass das Repository nicht signiert ist. Beachten Sie, was apt mitteilt: Der Index wurde erfolgreich heruntergeladen, aber die Signatur konnte nicht geprüft werden. Das ist ein Schlüsselproblem und 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 entscheidende Prüfung. 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.

Sowohl eine .list-Datei als auch eine .sources-Datei beschreiben dasselbe Repository

Ubuntu hat seine eigenen Paketquellen in Ubuntu 24.10 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. Stand August 2026 gibt es keine .sources-Datei zum Herunterladen von pkgs.tailscale.com: Diese URL liefert 404. Wenn auf Ihrem System also eine tailscale.sources vorhanden ist, wurde sie von Ihnen oder einer Anleitung manuell angelegt. Wenn tailscale.list ebenfalls noch vorhanden ist, ist dasselbe Repository für 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 Pfade zu Keyrings angeben. apt kann dann nicht entscheiden, welcher Schlüssel für das Repository maßgeblich ist. 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 bricht dann ab:

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 auch bei den eigenen Ubuntu-Repositories auf. Der Fehler durch eine doppelte apt-Paketquelle nach einer deb822-Migration beschreibt den allgemeinen Fall.

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

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

Behalten Sie eine Datei. Wenn Sie die andere deaktivieren möchten, ohne sie zu verlieren, benennen Sie sie um: apt liest nur Dateien, die auf .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 signed-by-Option als Signed-By übernimmt.

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

Ubuntu 24.04 enthält eine apt-Version, die älter als dieses Unterkommando ist. Anhand der Hilfezeile erkennen Sie daher sofort, ob Ihre Version das Unterkommando unterstützt. Falls nicht, erstellen Sie das Stanza aus der bereits auf dem Datenträger vorhandenen Zeile. So 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 das geschriebene Stanza ausgegeben. Sie können die Felder daher prüfen, bevor der nächste apt update ausgeführt wird. Vier Felder sollten Sie im Detail kennen, weil jedes auf eine andere Weise fehlschlägt:

• URIs endet an der Basis des Repositorys. Wenn Sie den dists/noble-Teil dort einfügen, erhalten Sie einen 404-Fehler, weil apt dists/<suite> selbst anhängt und dists/noble/dists/noble anfordert.
• Suites ist der Codename. Das ist genau der Wert, der im einzeiligen Format in der Mitte stand.
• Signed-By erwartet einen absoluten Pfad zu einer Keyring-Datei. Darunter kann auch ein inline eingefügter ASCII-armored Key stehen. Jede Zeile des Keys muss dabei um ein Leerzeichen eingerückt werden. 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 der nächsten Person leichter erklären.

Verwenden Sie für Drittanbieter-Repositorys jeweils ein Stanza pro Datei. Wenn Sie mehrere Stanzas zusammen in einer Datei speichern, setzen Sie eine Leerzeile zwischen sie. Der Repository-Index führt amd64 und arm64 als Architekturen auf. Ein ARM-VPS benötigt daher kein zusätzliches Architectures-Feld.

Ein Proxy in der Mitte liefert 403

Da ein Pfad, den dieses Repository nicht besitzt, 404 liefert, hat bei 403 etwas anderes stellvertretend geantwortet. Beginnen Sie mit der Konfiguration von apt, da ein dort gesetzter Proxy für apt gilt, 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'

Prüfen Sie anschließend, was apt tatsächlich sendet.

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

Damit werden die Request-Zeile, die von apt gesendeten Header und gegebenenfalls der verwendete Proxy ausgegeben. Vergleichen Sie die Ausgabe mit einem einfachen curl-Aufruf für dieselbe URL. Wenn curl 200 zurückgibt und apt 403, unterscheiden sich die beiden Anfragen in einem Detail, das die Netzwerkkomponente berücksichtigt. 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 standardmäßige curl 200 liefert, weist ein Filtersystem apt anhand seines Namens zurück. Die Anpassung muss auf diesem Filtersystem erfolgen, nicht auf Ihrem Server. 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 besteht die Lösung darin, pkgs.tailscale.com in der Firewall zuzulassen.

IPv6-only-Egress und Fehler, die keine Statuscodes sind

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

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 System 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 bringt das Erzwingen von IPv4 nichts, 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. Die Zeile curl -6 zeigt daher, was tatsächlich passiert.

Die Alternativen und ihre jeweiligen Kosten

Das Installationsskript des Anbieters. curl -fsSL https://tailscale.com/install.sh | sh ist der Befehl, den Tailscale bewirbt. Das Skript erkennt anhand von /etc/os-release Ihre Distribution und schreibt anschließend dieselben beiden Pfade, die in dieser Anleitung korrigiert wurden: /usr/share/keyrings/tailscale-archive-keyring.gpg und /etc/apt/sources.list.d/tailscale.list. Es verwendet dafür dieselben URLs. 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 und keine Lösung. Sie vertrauen dabei dem Inhalt, den der Server in diesem Moment zurückgibt, und behalten keine Kopie des ausgeführten Skripts. Wenn Sie dieses Abwägen akzeptieren, sollten Sie die Auswirkungen 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 August 2026 ist 1.102.2 die stabile Version, und die Datei für 64-Bit-x86 ist tailscale_1.102.2_amd64.tgz. Sie installieren den tailscale-Client und den tailscaled-Daemon selbst und überwachen den Daemon ebenfalls selbst. Daher gibt es keinen apt upgrade-Pfad, und jedes zukünftige Update müssen Sie als Download selbst durchführen. Diese Variante ist für einen Air-Gap-Host sinnvoll oder wenn Sie exakt eine bestimmte Version festlegen müssen.

Das eigene Ubuntu-Paket. Ein solches Paket gibt es nicht. Wenn Sie sudo apt install tailscale ohne konfiguriertes Repository des Anbieters ausführen, endet der Vorgang mit E: Unable to locate package tailscale. Auch apt update ändert daran nichts. Wenn Sie tatsächlich einen von Ihnen kontrollierten Coordination Server statt des gehosteten Servers von Tailscale benötigen, ist das eine separate Entscheidung: Headscale als eigenen Control Server betreiben behandelt dieses Thema. Der Vergleich zwischen Tailscale und einfachem WireGuard erläutert, ob Sie diese gesamte Infrastruktur benötigen.

Das Paket ist installiert, aber tailscaled startet nicht

Sobald apt keine Fehler mehr meldet, verlagern sich die Probleme 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 Meldung, 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 Provider, TUN für den Container zu aktivieren, oder wechseln Sie zu einem KVM-Tarif mit eigenem Kernel. Unter KVM funktioniert dies ohne zusätzliche Konfiguration.

Danach gibt sudo tailscale up eine Login-URL aus. tailscale status sollte Ihre Maschine anschließend mit einer Adresse aus dem Bereich 100.64.0.0/10 auflisten. Eine dort angezeigte Maschine eignet sich als Grundlage für weitere Konfigurationen, beispielsweise zum Ankündigen eines privaten Subnetzes von Ihrem VPS oder zur Verwendung des VPS als Exit-Node.

FAQ

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

apt hat den Repository-Index heruntergeladen, konnte seine Signatur aber nicht gegen /usr/share/keyrings/tailscale-archive-keyring.gpg überprüfen. Die häufigste Ursache ist ein Keyring mit null Bytes: sudo tee hat die Datei abgeschnitten, bevor curl etwas herunterladen konnte, und die Pipeline meldete Erfolg, 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, prüfen Sie ihn dort und kopieren Sie ihn anschließend mit dem Modus 0644 an die vorgesehene Stelle, damit der Benutzer _apt ihn lesen kann.

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

Verwenden Sie den Wert von UBUNTU_CODENAME aus /etc/os-release. Unter Ubuntu 24.04 lautet er 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 nichts unter diesem Namen, und apt meldet bei dists/wilma/InRelease den Fehler 404. Überprüfen Sie Ihre Auswahl vor Änderungen, indem Sie den Index mit curl -sS -o /dev/null -w '%{http_code}\n' manuell von https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease abrufen.

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

Das 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-Rechten alles ausführen, was der Server in diesem Moment zurückgibt, und keine Kopie davon 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 blind auszuführen. Bei einem blockierten Repository hilft das Skript ebenfalls nicht, da es dieselben URLs verwendet, die bereits fehlgeschlagen sind.

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

Verwenden Sie die auf pkgs.tailscale.com veröffentlichten statischen Tarballs. Im August 2026 liegen sie in Version 1.102.2 vor. Die amd64-Datei heißt tailscale_1.102.2_amd64.tgz. Installieren Sie die Programme tailscale und tailscaled selbst und führen Sie den Daemon ebenfalls selbst unter systemd aus. Der Nachteil sind die Updates: Es gibt kein apt-Paket, das eine neue Version einspielt. Jedes Update muss daher manuell erfolgen. Das Ubuntu-Archiv enthält kein eigenes tailscale-Paket. Deshalb endet sudo apt install tailscale auf einem Rechner ohne Hersteller-Repository bei E: Unable to locate package tailscale.