Błędy instalacji Tailscale w Ubuntu: naprawa apt

Dlaczego błędy instalacji Tailscale w Ubuntu są błędami apt

Błędy instalacji Tailscale w Ubuntu prawie zawsze występują, zanim zostanie wykonany jakikolwiek kod Tailscale. Są to błędy apt. Ubuntu nie udostępnia własnego pakietu tailscale: po sprawdzeniu archiwum pakietów Ubuntu w sierpniu 2026 jedynymi wynikami są biblioteki pomocnicze Go i python3-tailscale, dlatego demon musi pochodzić z własnego repozytorium apt Tailscale pod adresem pkgs.tailscale.com.

Dodanie tego repozytorium zapisuje dwa pliki. Jeden plik wskazuje apt, gdzie znajdują się pakiety. Drugi zawiera klucz publiczny używany przez apt do sprawdzania podpisu indeksu repozytorium. Prawie każdy opisany poniżej błąd wynika z nieprawidłowej zawartości jednego z tych dwóch plików albo z odmowy obsługi żądania przez urządzenie znajdujące się między apt a repozytorium.

Poniżej przedstawiono polecenia publikowane przez Tailscale dla 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 to nazwa kodowa Ubuntu 24.04. Występuje ona w obu adresach URL. Drugie polecenie zapisuje w /etc/apt/sources.list.d/tailscale.list wiersz komentarza oraz jeden wiersz deb, a cat wyświetla dokładnie zawartość zapisaną w tym pliku.

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

Wiersz deb należy odczytać jako adres złożony z czterech pól: opcji w nawiasach kwadratowych [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], następnie podstawy repozytorium pkgs.tailscale.com/stable/ubuntu dostępnej przez https, zestawu noble i komponentu main. apt łączy podstawę z zestawem w jeden adres URL i pobiera dane pod tym adresem: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Jeśli można ręcznie pobrać dane z tego adresu URL, apt również może je pobrać. Na tym polega cała diagnostyka.

Odczytaj błąd apt przed wprowadzeniem jakichkolwiek zmian

Uruchom aktualizację osobno, aby żaden inny komunikat nie przewinął błędu.

sudo apt update

Błąd repozytorium zewnętrznego wygląda następująco. Nazwa kodowa i adres IP będą inne na danym komputerze.

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.

O dalszym działaniu decydują dwa elementy tego wyniku: kod statusu oraz pełny adres URL w wierszu E: Failed to fetch. Nie wyciągaj wniosków na podstawie wiersza podsumowania na dole. Skopiuj adres URL i samodzielnie odpy taj serwer.

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

Polecenie wyświetla 200 dla nazwy kodowej publikowanej przez Tailscale. Weryfikacja przeprowadzona w August 2026 wykazała, że noble zwraca podpisany indeks zawierający Origin: Tailscale i Codename: noble. Zastąp noble nazwą kodową z własnego komunikatu błędu i uruchom polecenie ponownie. Jeżeli curl otrzyma 200, podczas gdy apt otrzymał błąd, repozytorium działa poprawnie, a problem dotyczy konfiguracji apt.

Co oznacza kod statusu

• 404 Not Found oznacza, że repozytorium nie zawiera pliku pod tą ścieżką. W pkgs.tailscale.com jest to niemal zawsze nazwa wydania użyta w adresie URL.
• 403 Forbidden oznacza, że serwer odpowiedział i odmówił dostępu. Według stanu na August 2026 to repozytorium zwraca 404 dla ścieżki, której nie zawiera, dlatego kod 403 wskazuje na proxy, urządzenie filtrujące albo zaporę sieciową między serwerem a Tailscale.
• 401 Unauthorized lub 407 Proxy Authentication Required oznacza, że proxy wymaga poświadczeń, których apt nie przekazuje.
• Błąd połączenia lub błąd rozpoznawania nazwy oznacza, że nie doszło do żadnej wymiany HTTP. Przejdź do sekcji dotyczącej IPv6.

Nazwa kodowa w adresie URL nie jest publikowana przez Tailscale

Tailscale tworzy osobny katalog dla każdej nazwy kodowej Ubuntu. Jeśli zostanie użyta nazwa, której nie ma w tym katalogu, serwer zwróci błąd 404, ponieważ nie ma na nim katalogu dists/<codename>, który można udostępnić. Własny indeks dostawcy pod adresem pkgs.tailscale.com/stable pokazuje dostępne nazwy. W sierpniu 2026 lista obejmuje wersje od 16.04 do resolute, czyli Ubuntu 26.04.

Najczęściej błędna nazwa kodowa pochodzi z polecenia lsb_release -cs uruchomionego w dystrybucji opartej na Ubuntu, ale niebędącej Ubuntu. W Linux Mint 22 to polecenie wyświetla wilma, czyli nazwę kodową używaną przez Mint, dla której Tailscale nie publikuje pakietów. Należy odczytać bazową wersję Ubuntu.

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

W Ubuntu obie wartości są takie same. W dystrybucji pochodnej VERSION_CODENAME oznacza nazwę dystrybucji pochodnej, a UBUNTU_CODENAME oznacza wydanie Ubuntu, na którym ją oparto. W obu adresach URL należy użyć UBUNTU_CODENAME.

Drugą przyczyną jest aktualizacja wydania. Narzędzie aktualizacji Ubuntu wyłącza podczas działania źródła zewnętrzne. Dlatego po aktualizacji Ubuntu 24.04 do 26.04 plik /etc/apt/sources.list.d/tailscale.list będzie zakomentowany albo nadal będzie zawierać noble, mimo że system korzysta już z resolute. Należy ponownie uruchomić oba polecenia curl z nową nazwą kodową. Nadpiszą one oba pliki. Jeśli sama aktualizacja została przerwana, a dpkg zgłasza błędy dotyczące pakietów skonfigurowanych tylko częściowo, a nie wyłącznie tego repozytorium, należy najpierw odzyskać przerwaną aktualizację wydania. Żadna poprawka dotycząca tailscale.list nie będzie trwała, jeśli apt nie może dokończyć konfiguracji systemu.

Trzecią przyczyną jest moment wykonania operacji. W tygodniach następujących po wydaniu nowej wersji Ubuntu nazwa kodowa może być już dostępna w Canonical, ale jeszcze nie w Tailscale. Wskazanie w pliku nazwy kodowej poprzedniego wydania LTS zwykle umożliwia instalację, ponieważ te pakiety mają niewiele zależności. W takim przypadku używana jest jednak kompilacja przygotowana dla starszego wydania. Należy sprawdzić faktycznie zainstalowaną wersję za pomocą apt policy tailscale, a po pojawieniu się właściwej nazwy kodowej zmienić zawartość pliku.

Baza kluczy jest pusta, a polecenie, które ją zapisało, niczego nie wyświetliło

Ten przypadek jest cichy i właśnie tak kończy się większość takich problemów. Sprawdź ponownie polecenie tworzące bazę kluczy:

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

Powłoka buduje cały potok, zanim zostanie uruchomiony którykolwiek program, dlatego sudo tee od razu otwiera ścieżkę bazy kluczy i obcina plik do rozmiaru 0 bajtów. Jeśli curl zakończy się błędem, a -f powoduje jego zakończenie dla każdego błędu HTTP, curl niczego nie zapisuje i kończy działanie z niezerowym kodem wyjścia. Plik pozostaje pusty. Status wyjścia potoku jest statusem ostatniego polecenia, czyli tee, które zakończyło się powodzeniem. Nic nie zostaje wyświetlone i wykonywane jest następne polecenie, mimo że klucz nie został zainstalowany.

Należy sprawdzić plik, a nie polecenie, które go utworzyło.

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

Prawidłowa baza kluczy wyświetla wiersz pub oraz wiersz uid z nazwą Tailscale. Pusty plik wyświetla gpg: no valid OpenPGP data found. i nic więcej. Plik zawierający stronę błędu HTML zachowuje się tak samo, a polecenie head -c 80 wyświetla jego początek, czyli stronę internetową zamiast binarnych danych klucza.

Jeśli baza kluczy nie zawiera użytecznego klucza, sudo apt update pobiera indeks, a następnie odrzuca go. Wyświetlany jest wiersz W: GPG error z nazwą repozytorium Tailscale i jego zestawem, tekst The following signatures couldn't be verified because the public key is not available: NO_PUBKEY wraz z 16-znakowym identyfikatorem klucza, a pod nim błąd informujący, że repozytorium nie jest podpisane. Należy zwrócić uwagę na znaczenie tego komunikatu apt: indeks został pobrany prawidłowo, ale nie można było sprawdzić jego podpisu. Jest to problem z kluczem, a nie problem z siecią. Jeśli plik bazy kluczy całkowicie nie istnieje, komunikat jest inny i bezpośrednio wskazuje ścieżkę za pomocą Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Klucz należy zapisać w dwóch krokach, aby nieudane pobieranie nie mogło uszkodzić działającej bazy kluczy.

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

Środkowy wiersz pełni funkcję kontroli: jeśli nie wyświetli identyfikatora uid Tailscale, należy przerwać działanie i nie kopiować pliku. Tryb 0644 ma znaczenie, ponieważ apt przełącza się na nieuprzywilejowanego użytkownika _apt podczas pobierania i weryfikowania, dlatego baza kluczy dostępna wyłącznie dla root jest niedostępna dla apt.

Pliki .list i .sources opisują to samo repozytorium

Ubuntu przeniosło własne źródła do formatu deb822 w Ubuntu 24.10, gdzie /etc/apt/sources.list stało się /etc/apt/sources.list.d/ubuntu.sources. Tailscale nadal publikuje format jednoliniowy. Według stanu z sierpnia 2026 nie ma pliku .sources do pobrania spod adresu pkgs.tailscale.com: ten adres zwraca kod 404. Jeśli więc na komputerze znajduje się tailscale.sources, został utworzony ręcznie przez użytkownika lub przewodnik. Jeśli jednocześnie nadal istnieje tailscale.list, apt ma teraz to samo repozytorium opisane dwukrotnie.

Łagodny wariant powoduje ostrzeżenie przy każdej aktualizacji:

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

Poważny wariant występuje, gdy oba pliki wskazują różne ścieżki do keyringów, ponieważ apt nie może ustalić, który klucz odpowiada za repozytorium. Wyświetla E: Conflicting values set for option Signed-By regarding source, następnie repozytorium i jego suite, potem obie ścieżki do keyringów rozdzielone przez !=, a następnie odmawia kontynuowania:

E: The list of sources could not be read.

Ten błąd blokuje każde polecenie apt, nie tylko aktualizację, dopóki jeden z plików nie zostanie usunięty. Taki sam błąd występuje w przypadku własnych repozytoriów Ubuntu. W artykule duplikat źródła apt po migracji do formatu deb822 omówiono ogólny przypadek.

Przed usunięciem czegokolwiek znajdź każdy plik zawierający wzmiankę o Tailscale.

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

Pozostaw jeden plik. Aby wyłączyć drugi bez jego usuwania, zmień jego nazwę: apt odczytuje tylko pliki zakończone na .list lub .sources, dlatego tailscale.list.bak zostanie pominięty i pozostanie na dysku do wglądu.

Poprawne tworzenie pliku źródłowego deb822

Jeśli preferowany jest nowszy format, należy przekonwertować istniejący plik zamiast ponownie wpisywać adres repozytorium, ponieważ właśnie literówka w tym miejscu powoduje opisane wcześniej błędy. Nowsze wydania apt zawierają konwerter, który przepisuje pliki .list do postaci sekcji deb822 i przenosi opcję signed-by jako Signed-By.

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

Ubuntu 24.04 zawiera apt starszy od tej podkomendy, dlatego wiersz pomocy pozwala od razu sprawdzić, czy jest ona dostępna. Jeśli nie jest, należy utworzyć sekcję na podstawie wiersza znajdującego się już na dysku. Dzięki temu wartość base pochodzi z pliku dostawcy, a nie z ręcznego wpisywania.

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

Polecenie wyświetla utworzoną sekcję, dzięki czemu przed wykonaniem kolejnego apt update można sprawdzić wartości pól. Cztery z nich wymagają szczegółowego omówienia, ponieważ każde powoduje inny rodzaj błędu:

• URIs kończy się na katalogu bazowym repozytorium. Wklejenie do niego części dists/noble powoduje błąd 404, ponieważ apt sam dopisuje dists/<suite> i żąda dists/noble/dists/noble.
• Suites oznacza nazwę kodową, czyli dokładnie wartość znajdującą się w środku formatu jednoliniowego.
• Signed-By przyjmuje ścieżkę bezwzględną do pliku keyring. Akceptuje również klucz zapisany bezpośrednio poniżej tego pola w formacie armored. Każdy wiersz klucza musi być wcięty o jedną spację, a każdy pusty wiersz wewnątrz klucza należy zapisać jako pojedynczą kropkę.
• Enabled: no wyłącza źródło bez jego usuwania. Cofnięcie takiej zmiany jest łatwiejsze niż przywrócenie zmienionej nazwy pliku i łatwiejsze do wyjaśnienia kolejnej osobie.

Dla repozytoriów zewnętrznych należy utrzymywać jedną sekcję w jednym pliku. Jeśli kilka sekcji znajduje się w jednym pliku, należy oddzielić je pustym wierszem. Indeks repozytorium wymienia amd64 i arm64 wśród obsługiwanych architektur, dlatego VPS z architekturą ARM nie wymaga dodatkowego pola Architectures.

Proxy pośredniczący zwraca 403

Ponieważ ścieżka, której nie ma w tym repozytorium, zwraca 404, kod 403 oznacza, że w imieniu repozytorium odpowiedziała inna warstwa. Najpierw sprawdź własną konfigurację apt, ponieważ skonfigurowany w niej proxy dotyczy apt, a nie interaktywnego curl.

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

Następnie obserwuj, co faktycznie wysyła apt.

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

Polecenie wyświetla linię żądania, nagłówki wysłane przez apt oraz proxy, przez które nawiązano połączenie, jeśli takie proxy występuje. Porównaj wynik ze zwykłym curl dla tego samego URL. Jeśli curl zwraca 200, a apt zwraca 403, żądania różnią się elementem istotnym dla urządzenia pośredniczącego. Najczęstszym kandydatem jest 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

Jeśli to żądanie zwraca 403, a domyślny curl zwraca 200, urządzenie filtrujące odrzuca apt na podstawie jego nazwy. Zmiany należy wprowadzić na tym urządzeniu, a nie na serwerze. Proxy firmowe, które analizuje TLS, zachowuje się inaczej. W takim przypadku apt zgłasza błąd weryfikacji certyfikatu zamiast kodu statusu, ponieważ otrzymany certyfikat został wystawiony przez proxy, a nie przez urząd certyfikacji Tailscale. Innym częstym źródłem problemu jest chmurowa zapora ruchu wychodzącego, która zezwala wyłącznie na dostęp do mirrorów Ubuntu. W takim przypadku należy zezwolić na pkgs.tailscale.com w konfiguracji zapory.

Wyjście wyłącznie przez IPv6 i błędy, które nie są kodami statusu

Jeśli apt nie otrzymał żadnej odpowiedzi HTTP, przetestuj każdy protokół osobno.

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

Gdy IPv4 odpowiada, a IPv6 zawiesza się lub zgłasza Network is unreachable, apt nie działa, ponieważ biblioteka resolvera preferuje IPv6, a serwer nie ma działającej ścieżki IPv6. Wymuś IPv4 podczas jednego uruchomienia, aby potwierdzić tę hipotezę:

sudo apt -o Acquire::ForceIPv4=true update

Jeśli ta aktualizacja zakończy się powodzeniem, ustaw to na stałe.

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

Należy uwzględnić również odwrotny przypadek. Na VPS, który w ogóle nie ma adresu IPv4, wymuszenie IPv4 niczego nie naprawi, ponieważ nie istnieje trasa IPv4, przez którą można skierować ruch. W takim przypadku potrzebne są NAT64 z DNS64 od dostawcy albo proxy mające adres IPv4. Objawem jest błąd połączenia zawierający adres IPv6, dlatego to wiersz curl -6 wskazuje rzeczywistą przyczynę.

Rozwiązania awaryjne i koszt każdego z nich

Skrypt instalacyjny dostawcy. curl -fsSL https://tailscale.com/install.sh | sh to polecenie promowane przez Tailscale. Skrypt wykrywa dystrybucję na podstawie /etc/os-release, a następnie zapisuje te same dwie ścieżki, które są naprawiane w tym poradniku: /usr/share/keyrings/tailscale-archive-keyring.gpg i /etc/apt/sources.list.d/tailscale.list. Korzysta przy tym z tych samych adresów URL. Ma to znaczenie dla oczekiwań: skrypt nie omija repozytorium, którego dostęp blokuje proxy. Kończy się niepowodzeniem w ten sam sposób, ale wyświetla mniej informacji. Przekazanie pobranego skryptu do powłoki uruchomionej jako root jest kompromisem, a nie rozwiązaniem, ponieważ oznacza zaufanie do zawartości zwróconej przez serwer w danym momencie i nie pozostawia lokalnej kopii wykonanego skryptu. Jeśli zostanie wybrany ten kompromis, należy świadomie zaakceptować jego konsekwencje:

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

Statyczne pliki binarne. Ten sam serwer publikuje zwykłe archiwa tar w sekcji statycznych plików binarnych pod adresem pkgs.tailscale.com/stable. W sierpniu 2026 najnowsze stabilne wydanie to 1.102.2, a plik dla 64-bitowego x86 to tailscale_1.102.2_amd64.tgz. Klient tailscale i demon tailscaled są umieszczane samodzielnie. Demon trzeba również samodzielnie nadzorować, dlatego nie ma ścieżki apt upgrade, a każdą przyszłą aktualizację trzeba pamiętać pobrać ręcznie. To rozwiązanie sprawdza się na hoście odłączonym od sieci albo wtedy, gdy trzeba przypiąć dokładnie jedną wersję.

Pakiet Ubuntu. Takiego pakietu nie ma. Uruchomienie sudo apt install tailscale bez skonfigurowanego repozytorium dostawcy kończy się komunikatem E: Unable to locate package tailscale. Żadne apt update tego nie zmieni. Jeśli w rzeczywistości potrzebny jest kontrolowany przez siebie serwer koordynacji zamiast hostowanego serwera Tailscale, jest to odrębna decyzja: uruchomienie Headscale jako własnego serwera sterowania opisuje tę możliwość, a porównanie Tailscale ze zwykłym WireGuard pomaga określić, czy cała ta infrastruktura jest potrzebna.

Pakiet został zainstalowany, ale tailscaled nie uruchamia się

Gdy apt działa poprawnie, błędy dotyczą już demona.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

Na VPS korzystającym z wirtualizacji kontenerowej, która współdzieli jądro hosta, na przykład LXC lub OpenVZ, w dzienniku znajduje się wpis o braku /dev/net/tun. Demon potrzebuje urządzenia TUN do utworzenia interfejsu tailscale0, ale kontenerowi go nie przydzielono. Należy poprosić dostawcę o włączenie TUN dla kontenera albo przejść na plan KVM, w którym dostępne jest własne jądro. W środowisku KVM działa to bez dodatkowej konfiguracji.

Następnie sudo tailscale up wyświetla URL logowania, a tailscale status powinno wyświetlić maszynę z adresem z zakresu 100.64.0.0/10. Maszyna widoczna na tej liście nadaje się jako baza do dalszej konfiguracji, na przykład do rozgłaszania prywatnej podsieci z VPS lub użycia VPS jako węzła wyjściowego.

FAQ

Dlaczego apt informuje, że repozytorium Tailscale nie jest podpisane?

Ponieważ apt pobrał indeks repozytorium, ale nie mógł zweryfikować jego podpisu względem /usr/share/keyrings/tailscale-archive-keyring.gpg. Zwykle przyczyną jest plik keyring o rozmiarze zero bajtów: sudo tee obciął plik, zanim curl zakończył nieudane pobieranie, a potok zgłosił powodzenie, ponieważ tee zakończyło się powodzeniem. Uruchom gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Prawidłowy keyring wyświetla wiersz pub oraz wiersz uid z nazwą Tailscale, natomiast pusty lub uszkodzony wyświetla gpg: no valid OpenPGP data found.. Pobierz klucz do pliku tymczasowego, sprawdź go w tym miejscu, a następnie skopiuj go na właściwe miejsce z trybem 0644, aby użytkownik _apt mógł go odczytać.

Który kryptonim Ubuntu należy umieścić w adresach URL Tailscale?

Użyj wartości UBUNTU_CODENAME z /etc/os-release. W Ubuntu 24.04 jest to noble, a w Ubuntu 26.04 resolute. Nie używaj lsb_release -cs w dystrybucji pochodnej od Ubuntu: w Linux Mint 22 polecenie wyświetla wilma, Tailscale niczego nie publikuje pod tą nazwą, a apt zgłasza błąd 404 dla dists/wilma/InRelease. Przed rozpoczęciem edycji potwierdź wybór, pobierając ręcznie indeks za pomocą curl -sS -o /dev/null -w '%{http_code}\n' z adresu https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

Czy uruchamianie skryptu instalacyjnego Tailscale przekazanego do powłoki jest bezpieczne?

Jest to kompromis, który należy świadomie zaakceptować. Skrypt pochodzi od Tailscale i wykonuje te same czynności co kroki ręczne: odczytuje /etc/os-release, zapisuje ten sam keyring i ten sam /etc/apt/sources.list.d/tailscale.list, a następnie instaluje pakiet. Ceną jest uruchomienie z uprawnieniami root dowolnej zawartości zwróconej przez serwer w danym momencie oraz brak jej lokalnej kopii. Pobierz skrypt za pomocą -o install.sh, przeczytaj go, a następnie uruchom, jeśli potrzebujesz wygody bez pomijania tej kontroli. Skrypt nie rozwiąże również problemu zablokowanego repozytorium, ponieważ używa tych samych adresów URL, które już zawiodły.

Jak zainstalować Tailscale w Ubuntu bez repozytorium apt?

Użyj statycznych archiwów tarball publikowanych w pkgs.tailscale.com. W sierpniu 2026 są one dostępne w wersji 1.102.2, a plik dla amd64 nosi nazwę tailscale_1.102.2_amd64.tgz. Programy tailscale i tailscaled należy zainstalować samodzielnie, a demon uruchamiać samodzielnie za pomocą systemd. Ceną są aktualizacje: nie ma pakietu apt, który pobierałby nową wersję, dlatego każdą aktualizację wykonuje się ręcznie. Archiwum Ubuntu nie zawiera własnego pakietu tailscale, dlatego sudo apt install tailscale na komputerze bez repozytorium dostawcy kończy działanie na E: Unable to locate package tailscale.