Błędy instalacji Tailscale na Ubuntu: jak naprawić

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

Błędy instalacji Tailscale na Ubuntu niemal zawsze występują, zanim uruchomi się jakikolwiek kod Tailscale. Są to błędy narzędzia apt. Ubuntu nie dostarcza własnego pakietu tailscale: po sprawdzeniu w archiwum pakietów Ubuntu w sierpniu 2026 roku, jedynymi dopasowaniami są biblioteki pomocnicze Go oraz python3-tailscale, dlatego demon musi pochodzić z własnego repozytorium apt firmy Tailscale pod adresem pkgs.tailscale.com.

Dodanie tego repozytorium powoduje zapisanie dwóch plików. Jeden plik informuje apt, gdzie znajdują się pakiety. Drugi zawiera klucz publiczny, którego apt używa do weryfikacji podpisu indeksu repozytorium. Prawie każda awaria opisana poniżej wynika z błędnej zawartości jednego z tych dwóch plików lub z faktu, że urządzenie znajdujące się między apt a repozytorium odrzuca żądanie.

Oto 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 dla Ubuntu 24.04 i pojawia się ona w obu adresach URL. Drugie polecenie zapisuje linię komentarza oraz jedną linię deb do pliku /etc/apt/sources.list.d/tailscale.list, a cat pokazuje dokładnie, co zostało tam zapisane.

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

Należy odczytać tę linię deb jako adres składający się z czterech pól: opcji w nawiasach [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], następnie bazy repozytorium, którą jest pkgs.tailscale.com/stable/ubuntu dostępna przez https, dalej pakietu noble oraz komponentu main. Narzędzie apt łączy bazę i pakiet w jeden adres URL i pobiera go: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Jeśli można pobrać ten adres URL ręcznie, apt również może go pobrać. To cała diagnostyka.

Przed wprowadzeniem zmian należy przeczytać błąd apt

Uruchom aktualizację samodzielnie, aby komunikat o błędzie nie został przesunięty w terminalu przez inne informacje.

sudo apt update

Nieudane połączenie z repozytorium zewnętrznym wygląda następująco. Nazwa kodowa oraz adres IP będą się różnić w zależności od maszyny.

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.

Dwa elementy w tym wyjściu decydują o dalszych krokach: kod statusu oraz pełny adres URL w linii E: Failed to fetch. Nie należy wyciągać wniosków na podstawie podsumowania na dole. Skopiuj adres URL i odpytaj serwer samodzielnie.

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

To polecenie wyświetla 200 dla nazwy kodowej publikowanej przez Tailscale. Sprawdzono w sierpniu 2026 r., noble zwraca podpisany indeks zawierający Origin: Tailscale oraz Codename: noble. Zastąp noble nazwą kodową z własnego błędu i uruchom ponownie. Jeśli curl otrzyma 200 w miejscu, w którym apt zgłosił błąd, repozytorium jest sprawne, a problem leży w konfiguracji samego apt.

Co oznacza kod statusu

• 404 Not Found oznacza, że w repozytorium pod tą ścieżką nie ma pliku. W przypadku pkgs.tailscale.com prawie zawsze wynika to z błędnej nazwy kodowej w adresie URL.
• 403 Forbidden oznacza, że serwer odpowiedział, ale odmówił dostępu. Według stanu na sierpień 2026 repozytorium zwraca 404 dla nieistniejących ścieżek, więc kod 403 wskazuje na proxy, urządzenie filtrujące lub firewall znajdujący się między serwerem a Tailscale.
• 401 Unauthorized lub 407 Proxy Authentication Required oznacza, że proxy wymaga danych uwierzytelniających, których apt nie wysyła.
• Błąd połączenia lub błąd rozpoznawania nazw oznacza, że komunikacja HTTP w ogóle nie została nawiązana. Należy przejść do sekcji dotyczącej IPv6.

Nazwa kodowa w adresie URL nie jest publikowana przez Tailscale

Tailscale tworzy oddzielny katalog dla każdej nazwy kodowej Ubuntu. Żądanie nazwy kodowej, której nie ma w repozytorium, skutkuje błędem 404, ponieważ na serwerze brakuje dists/<codename>, które mogłoby obsłużyć zapytanie. Oficjalna lista dostawcy pod adresem pkgs.tailscale.com/stable wskazuje dostępne wersje. W sierpniu 2026 roku lista ta obejmuje wydania od 16.04 do resolute, czyli Ubuntu 26.04.

Najczęstszą przyczyną użycia błędnej nazwy kodowej jest wykonanie lsb_release -cs w dystrybucji bazującej na Ubuntu, która nie jest samym Ubuntu. W systemie Linux Mint 22 polecenie to zwraca wilma, co jest własną nazwą kodową Mint, dla której Tailscale nie publikuje pakietów. Należy odczytać nazwę bazowego wydania Ubuntu.

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

W systemie Ubuntu obie wartości są identyczne. W systemach pochodnych VERSION_CODENAME to nazwa dystrybucji, a UBUNTU_CODENAME to wydanie Ubuntu, na którym jest ona zbudowana. W obu adresach URL należy użyć UBUNTU_CODENAME.

Drugą przyczyną jest aktualizacja wydania systemu. Narzędzie do aktualizacji Ubuntu wyłącza źródła zewnętrznych dostawców podczas pracy, więc po aktualizacji Ubuntu 24.04 do 26.04 plik /etc/apt/sources.list.d/tailscale.list będzie zakomentowany lub nadal będzie wskazywał na noble na maszynie, która pracuje już pod kontrolą resolute. Problem rozwiązuje ponowne wykonanie dwóch poleceń curl z nową nazwą kodową, co nadpisze oba pliki.

Trzecią przyczyną jest czas. W tygodniach następujących po premierze nowego wydania Ubuntu, nazwa kodowa istnieje już w repozytoriach Canonical, zanim pojawi się w Tailscale. Wskazanie w pliku poprzedniej nazwy kodowej LTS zazwyczaj pozwala na instalację, ponieważ pakiety te mają niewiele zależności, jednak w takim przypadku uruchamiana jest kompilacja przygotowana dla starszego wydania. Należy sprawdzić zainstalowaną wersję za pomocą apt policy tailscale i przywrócić właściwą nazwę kodową w pliku, gdy tylko pojawi się ona w repozytorium.

Brelok kluczy jest pusty, a polecenie, które go zapisało, nie zwróciło żadnego komunikatu

Ten błąd jest cichy i stanowi przyczynę większości problemów tego typu. Należy ponownie przyjrzeć się poleceniu obsługującemu brelok 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 przed uruchomieniem któregokolwiek z programów, więc sudo tee otwiera ścieżkę breloka i natychmiast skraca ją do zera bajtów. Jeśli curl następnie zawiedzie, a -f wymusi błąd przy każdym niepowodzeniu HTTP, curl nie zapisze niczego i zakończy działanie z kodem innym niż zero. Plik pozostaje pusty. Kod wyjścia potoku jest kodem ostatniego polecenia, czyli tee, które zakończyło się powodzeniem. Nic nie zostaje wyświetlone, a użytkownik przechodzi do następnego polecenia, zakładając, że klucz 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

Poprawny brelok kluczy wyświetla linię pub oraz linię uid wskazującą na Tailscale. Pusty plik wyświetla gpg: no valid OpenPGP data found. i nic więcej. Plik, który przechwycił stronę błędu HTML, wyświetla to samo, a head -c 80 na nim pokazuje początek strony internetowej zamiast binarnych danych klucza.

W przypadku breloka, który nie zawiera użytecznego klucza, sudo apt update pobiera indeks, a następnie go odrzuca. Wyświetlona zostaje linia W: GPG error wskazująca na repozytorium Tailscale i jego pakiet, tekst The following signatures couldn't be verified because the public key is not available: NO_PUBKEY wraz z 16-znakowym identyfikatorem klucza, a poniżej błąd informujący, że repozytorium nie jest podpisane. Należy zwrócić uwagę na komunikat apt: indeks został pobrany poprawnie, ale weryfikacja podpisu nie powiodła się. Jest to problem z kluczem, a nie z siecią. Jeśli plik breloka w ogóle nie istnieje, komunikat jest inny i wskazuje bezpośrednio na ścieżkę za pomocą Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Zapisz klucz w dwóch krokach, aby nieudane pobieranie nie zniszczyło działającego breloka 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

Środkowa linia stanowi zabezpieczenie: jeśli nie wyświetla uid dla Tailscale, należy przerwać proces i nie kopiować pliku. Tryb 0644 ma znaczenie, ponieważ apt obniża uprawnienia do użytkownika _apt w celu pobrania i weryfikacji, więc brelok kluczy dostępny tylko dla root jest brelokiem, którego apt nie może użyć.

Zarówno plik .list, jak i .sources opisują to samo repozytorium

System Ubuntu przeniósł własne źródła do formatu deb822 w wersji Ubuntu 24.10, gdzie /etc/apt/sources.list stało się /etc/apt/sources.list.d/ubuntu.sources. Tailscale nadal publikuje pliki w formacie jednowierszowym. W sierpniu 2026 r. sprawdzono, że nie istnieje plik .sources do pobrania z pkgs.tailscale.com: ten adres URL zwraca błąd 404. Jeśli zatem w systemie znajduje się plik tailscale.sources, został on utworzony ręcznie przez użytkownika lub na podstawie poradnika. Jeśli plik tailscale.list również nadal istnieje, apt posiada teraz dwa opisy tego samego repozytorium.

Łagodna wersja tego problemu objawia się ostrzeżeniem 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

Wersja krytyczna występuje, gdy oba pliki wskazują na różne ścieżki do bazy kluczy, ponieważ apt nie jest w stanie określić, który klucz zarządza repozytorium. Wyświetlany jest komunikat E: Conflicting values set for option Signed-By regarding source, następnie nazwa repozytorium i jego pakietu, potem dwie ścieżki do bazy kluczy z separatorem !=, po czym proces zostaje przerwany:

E: The list of sources could not be read.

Taki błąd blokuje każde polecenie apt, nie tylko aktualizację, dopóki jeden z plików nie zostanie usunięty. Ta sama awaria występuje w przypadku własnych repozytoriów Ubuntu, a błąd zduplikowanego źródła apt po migracji do deb822 zawiera opis ogólnego przypadku.

Przed usunięciem jakichkolwiek plików należy odnaleźć wszystkie, które zawierają odniesienia do Tailscale.

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

Należy zachować jeden plik. Aby wyłączyć drugi bez jego usuwania, należy zmienić jego nazwę: apt odczytuje tylko pliki kończące się na .list lub .sources, więc plik z rozszerzeniem tailscale.list.bak jest pomijany i pozostaje na dysku w celach referencyjnych.

Poprawne tworzenie pliku źródłowego deb822

Jeśli preferowany jest nowszy format, należy przekonwertować istniejący plik zamiast przepisywać adres repozytorium, ponieważ literówki są najczęstszą przyczyną powyższych błędów. Nowsze wydania apt zawierają konwerter, który przepisuje pliki .list na format deb822 i przenosi opcję signed-by jako Signed-By.

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

Ubuntu 24.04 zawiera wersję apt, która nie posiada tego podpolecenia, więc linia pomocy natychmiast informuje, czy dana wersja je obsługuje. Jeśli go brakuje, należy utworzyć sekcję na podstawie linii znajdującej się już na dysku, aby dane bazowe pochodziły z pliku dostawcy, a nie z klawiatury użytkownika.

. /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 to wyświetla zapisaną sekcję, co pozwala na weryfikację pól przed kolejnym apt update. Cztery z nich wymagają szczegółowego omówienia, ponieważ każde z nich może prowadzić do innych błędów:

• URIs kończy się na adresie bazowym repozytorium. Wklejenie tam części dists/noble spowoduje błąd 404, ponieważ apt samodzielnie dodaje dists/<suite> i żąda pliku dists/noble/dists/noble.
• Suites to nazwa kodowa, dokładnie ta wartość, która znajdowała się w środku formatu jednoliniowego.
• Signed-By przyjmuje ścieżkę bezwzględną do pliku bazy kluczy. Akceptuje również klucz w formacie tekstowym (armored) umieszczony bezpośrednio poniżej, gdzie każda linia klucza musi być poprzedzona spacją, a każda pusta linia wewnątrz klucza musi być zapisana jako pojedyncza kropka.
• Enabled: no wyłącza źródło bez jego usuwania, co jest łatwiejsze do cofnięcia niż zmiana nazwy i bardziej przejrzyste dla kolejnych administratorów.

W przypadku repozytoriów zewnętrznych należy przechowywać jedną sekcję w jednym pliku, a w przypadku umieszczenia kilku sekcji w jednym pliku, należy oddzielić je pustą linią. Indeks repozytorium wymienia amd64 oraz arm64 wśród obsługiwanych architektur, więc serwer VPS z architekturą ARM nie wymaga dodatkowego pola Architectures.

Proxy pośredniczący zwraca błąd 403

Ponieważ ścieżka w tym repozytorium nie zwraca błędu 404, kod 403 oznacza, że odpowiedź została wygenerowana przez inny komponent. Należy rozpocząć od konfiguracji apt, ponieważ proxy ustawione w tym miejscu dotyczy apt, a nie interaktywnego polecenia curl.

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

Następnie należy monitorować, co faktycznie wysyła apt.

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

To polecenie wyświetla linię żądania, nagłówki wysłane przez apt oraz proxy, przez które nawiązano połączenie, jeśli zostało użyte. Należy porównać to ze zwykłym poleceniem curl skierowanym do tego samego adresu URL. Jeśli curl zwraca 200, a apt zwraca 403, żądania różnią się elementem istotnym dla urządzenia pośredniczącego. Najczęstszą przyczyną jest nagłówek 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 polecenie zwraca 403, podczas gdy domyślny curl zwraca 200, urządzenie filtrujące odrzuca apt na podstawie nazwy. Rozwiązanie problemu leży po stronie tego urządzenia, a nie serwera. Proxy korporacyjne, które dokonuje inspekcji TLS, zachowuje się inaczej: apt zgłasza błąd weryfikacji certyfikatu zamiast kodu stanu, ponieważ otrzymany certyfikat został wystawiony przez proxy, a nie przez urządzenie certyfikujące Tailscale. Innym częstym źródłem problemów jest firewall wyjściowy w chmurze, który zezwala tylko na połączenia z serwerami lustrzanymi Ubuntu. W takim przypadku rozwiązaniem jest zezwolenie na pkgs.tailscale.com w konfiguracji firewalla.

Ruch wychodzący tylko przez IPv6 oraz błędy niebędące kodami statusu

Jeśli apt nie otrzymuje odpowiedzi HTTP, należy przetestować każdy protokół z osobna.

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 zawodzi, ponieważ biblioteka resolvera preferuje IPv6, a serwer nie posiada działającej ścieżki IPv6. Należy wymusić uruchomienie z użyciem IPv4, aby potwierdzić tę teorię:

sudo apt -o Acquire::ForceIPv4=true update

Jeśli ta aktualizacja zakończy się powodzeniem, należy wprowadzić zmianę na stałe.

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

W przypadku przeciwnym należy zachować realizm. Na serwerze VPS, który w ogóle nie posiada adresu IPv4, wymuszenie IPv4 nic nie naprawi, ponieważ nie istnieje trasa IPv4, przez którą można by skierować ruch. W takiej sytuacji wymagane jest użycie NAT64 wraz z DNS64 od dostawcy lub proxy posiadającego adres IPv4. Symptomem jest błąd połączenia wskazujący adres IPv6, a wiersz curl -6 zawiera rzeczywistą przyczynę problemu.

Mechanizmy awaryjne i ich koszty

Skrypt instalacyjny dostawcy. curl -fsSL https://tailscale.com/install.sh | sh to polecenie promowane przez Tailscale. Po przeanalizowaniu skryptu widać, że wykrywa on dystrybucję za pomocą /etc/os-release, a następnie zapisuje te same dwa pliki, które naprawiano w tym przewodniku, /usr/share/keyrings/tailscale-archive-keyring.gpg oraz /etc/apt/sources.list.d/tailscale.list, pobierając je z tych samych adresów URL. Jest to istotne dla oczekiwań użytkownika: skrypt nie omija repozytorium blokowanego przez proxy. Kończy się niepowodzeniem w ten sam sposób, dostarczając mniej informacji w wyjściu. Przekazywanie pobranego skryptu potokiem do powłoki z uprawnieniami root to kompromis, a nie rozwiązanie, ponieważ użytkownik ufa zawartości zwracanej przez serwer w danej chwili i nie zachowuje kopii uruchomionego kodu. Jeśli decydujesz się na ten kompromis, rób to świadomie:

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

Statyczne pliki binarne. Ten sam serwer udostępnia zwykłe archiwa tar w sekcji statycznych plików binarnych pod adresem pkgs.tailscale.com/stable. Według stanu na sierpień 2026 r. wersja stabilna to 1.102.2, a plik dla architektury x86 64-bit to tailscale_1.102.2_amd64.tgz. Klient tailscale oraz demon tailscaled są umieszczane ręcznie, a nadzór nad demonem sprawuje się samodzielnie, więc ścieżka apt upgrade nie istnieje, a każda przyszła aktualizacja wymaga ręcznego pobrania. Rozwiązanie to sprawdza się na hostach odizolowanych od sieci (air-gapped) lub w sytuacjach, gdy konieczne jest przypisanie konkretnej wersji oprogramowania.

Pakiet systemowy Ubuntu. Taki pakiet nie istnieje. Uruchomienie sudo apt install tailscale bez skonfigurowanego repozytorium dostawcy kończy się błędem E: Unable to locate package tailscale i żadna liczba wywołań apt update tego nie zmieni. Jeśli celem jest serwer koordynujący pod własną kontrolą, a nie rozwiązanie hostowane przez Tailscale, jest to odrębna decyzja: uruchamianie Headscale jako własnego serwera kontrolnego omawia to zagadnienie, a porównanie Tailscale i standardowego WireGuard wyjaśnia, czy korzystanie z tego mechanizmu jest w ogóle konieczne.

Pakiet zainstalowany, a tailscaled nie uruchamia się

Gdy apt zakończy pracę, błędy przenoszą się na poziom demona.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

Na serwerze VPS korzystającym z wirtualizacji kontenerowej współdzielącej jądro hosta, takiej jak LXC lub OpenVZ, w dzienniku pojawia się wpis o braku /dev/net/tun. Demon wymaga urządzenia TUN do utworzenia interfejsu tailscale0, a kontener go nie otrzymał. Należy poprosić dostawcę o włączenie TUN dla kontenera lub przenieść się na plan KVM, gdzie dostępny jest własny kernel. W przypadku KVM rozwiązanie to działa bez dodatkowej konfiguracji.

Następnie sudo tailscale up wyświetli adres URL logowania, a tailscale status powinno pokazać maszynę z adresem z zakresu 100.64.0.0/10. Maszyna, która się tam pojawi, jest gotowa do dalszej pracy, niezależnie od tego, czy oznacza to ogłaszanie prywatnej podsieci z VPS czy użycie VPS jako węzła wyjściowego.

FAQ

Dlaczego apt zgłasza, że repozytorium Tailscale nie jest podpisane?

Ponieważ apt pobrało indeks repozytorium i nie mogło zweryfikować jego podpisu za pomocą /usr/share/keyrings/tailscale-archive-keyring.gpg. Zazwyczaj przyczyną jest zerowy rozmiar pliku bazy kluczy: sudo tee obcięło plik, zanim curl zdołał cokolwiek pobrać, a potok zgłosił sukces, ponieważ tee zakończyło się powodzeniem. Uruchom gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Poprawna baza kluczy wyświetla linię pub oraz linię uid wskazującą na Tailscale, podczas gdy pusta lub uszkodzona baza wyświetla gpg: no valid OpenPGP data found.. Pobierz klucz do pliku tymczasowego, sprawdź go, a następnie skopiuj w docelowe miejsce z uprawnieniami 0644, aby użytkownik _apt mógł go odczytać.

Którą nazwę kodową Ubuntu należy umieścić w adresach URL Tailscale?

Użyj wartości UBUNTU_CODENAME z pliku /etc/os-release, która wynosi noble dla Ubuntu 24.04 oraz resolute dla Ubuntu 26.04. Nie używaj lsb_release -cs w dystrybucjach pochodnych Ubuntu: w Linux Mint 22 polecenie to zwraca wilma, Tailscale nie publikuje nic pod tą nazwą, a apt zgłasza błąd 404 dla dists/wilma/InRelease. Przed edycją jakichkolwiek plików potwierdź swój wybór, pobierając indeks ręcznie za pomocą curl -sS -o /dev/null -w '%{http_code}\n' dla adresu https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

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

Jest to kompromis, na który należy zdecydować się świadomie. Skrypt pochodzi od Tailscale i wykonuje te same czynności, co kroki ręczne: odczytuje /etc/os-release, zapisuje tę samą bazę kluczy i ten sam plik /etc/apt/sources.list.d/tailscale.list, a następnie instaluje pakiet. Kosztem jest uruchomienie wszystkiego, co serwer zwróci w danym momencie, z uprawnieniami root, bez zachowania historii zmian. Pobierz skrypt za pomocą -o install.sh, przejrzyj go, a następnie uruchom, jeśli chcesz wygody bez ryzyka wynikającego z braku wglądu. Skrypt nie pomoże również w przypadku zablokowanego repozytorium, ponieważ korzysta z tych samych adresów URL, które wcześniej zawiodły.

Jak zainstalować Tailscale na Ubuntu bez użycia repozytorium apt?

Użyj statycznych archiwów tarball publikowanych pod adresem pkgs.tailscale.com, które w sierpniu 2026 roku są dostępne w wersji 1.102.2, z plikiem dla architektury amd64 o nazwie tailscale_1.102.2_amd64.tgz. Programy tailscale oraz tailscaled należy zainstalować samodzielnie, a demona uruchomić ręcznie w systemd. Kosztem jest proces aktualizacji: brak pakietu apt oznacza, że każda nowa wersja musi być instalowana ręcznie. Archiwum Ubuntu nie zawiera własnego pakietu tailscale, więc polecenie sudo apt install tailscale na maszynie bez repozytorium dostawcy kończy się błędem E: Unable to locate package tailscale.