Ayusin ang Tailscale install errors sa Ubuntu

Bakit apt errors ang Tailscale install errors sa Ubuntu

Halos palaging nangyayari ang Tailscale install errors sa Ubuntu bago pa tumakbo ang anumang Tailscale code. apt errors ang mga ito. Walang sariling tailscale package ang Ubuntu: batay sa pag-check sa Ubuntu package archive noong August 2026, Go helper libraries at python3-tailscale lamang ang mga tumutugma, kaya kailangang manggaling ang daemon sa sariling apt repository ng Tailscale sa pkgs.tailscale.com.

Dalawang file ang sinusulat kapag idinagdag ang repository na iyon. Sinasabi ng isang file kung saan matatagpuan ang mga package. Hawak naman ng isa pa ang public key na ginagamit ng apt para suriin ang signature sa repository index. Halos lahat ng failure sa ibaba ay dulot ng maling laman ng isa sa dalawang file na iyon, o ng device sa pagitan ng apt at repository na tumatangging ipasa ang request.

Ito ang mga command na inilalathala ng Tailscale para sa 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

Ang noble ang codename para sa Ubuntu 24.04, at lumilitaw ito sa parehong URL. Isinusulat ng pangalawang command ang isang comment line at isang deb line sa /etc/apt/sources.list.d/tailscale.list, at ipinapakita ng cat kung ano mismo ang naisulat doon.

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

Basahin ang deb line na iyon bilang address na may apat na field: ang bracketed option na [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], pagkatapos ang repository base na pkgs.tailscale.com/stable/ubuntu na ina-access gamit ang https, pagkatapos ang suite na noble, at pagkatapos ang component na main. Pinagsasama ng apt ang base at suite upang mabuo ang isang URL at dina-download ito: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease. Kung kaya mong i-fetch nang mano-mano ang URL na iyon, kaya rin itong i-fetch ng apt. Iyon ang buong diagnostic.

Basahin ang apt error bago ka magbago ng anuman

Isagawa nang hiwalay ang update para walang ibang output na mag-scroll sa error.

sudo apt update

Ganito ang hitsura ng failed third-party repository. Magkakaiba ang codename at IP address sa machine mo.

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.

Dalawang bagay sa output na iyon ang magtatakda kung ano ang susunod mong gagawin: ang status code at ang buong URL sa linyang E: Failed to fetch. Huwag manghula batay sa summary line sa ibaba. Kopyahin ang URL at direktang magtanong sa server.

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

Ipi-print nito ang 200 para sa codename na may inilalabas na Tailscale. Sinuri noong August 2026, nagbabalik ang noble ng signed index na naglalaman ng Origin: Tailscale at Codename: noble. Palitan ang noble ng codename mula sa sarili mong error at patakbuhin itong muli. Kung 200 ang makuha ng curl samantalang error ang nakuha ng apt, maayos ang repository at nasa sariling configuration ng apt ang problema.

Ang ipinapahiwatig ng status code

• Ibig sabihin ng 404 Not Found ay walang file ang repository sa path na iyon. Sa pkgs.tailscale.com, halos palaging codename ito sa URL.
• Ibig sabihin ng 403 Forbidden ay may sumagot ngunit tumanggi. Noong August 2026, 404 ang ibinabalik ng repository na ito para sa path na wala rito, kaya ang 403 ay tumutukoy sa proxy, filtering appliance, o firewall sa pagitan ng iyong server at Tailscale.
• Ibig sabihin ng 401 Unauthorized o 407 Proxy Authentication Required ay nangangailangan ng credentials ang proxy na hindi ipinapadala ng apt.
• Ang connect error o name resolution error ay nangangahulugang walang naganap na HTTP conversation. Dumiretso sa seksiyon tungkol sa IPv6.

Ang codename sa URL ay hindi inilalabas ng Tailscale

Gumagawa ang Tailscale ng hiwalay na directory para sa bawat Ubuntu codename. Kapag humiling ka ng codename na wala roon, makakakuha ka ng 404 dahil walang dists/<codename> sa server na maaaring ihatid. Ipinapakita ng sariling listing ng vendor sa pkgs.tailscale.com/stable kung alin ang available. Noong August 2026, mula 16.04 hanggang resolute ang listahang iyon, at ang resolute ay Ubuntu 26.04.

Karaniwang nagkakaroon ng maling codename kapag ginagamit ang lsb_release -cs sa isang distribution na nakabatay sa Ubuntu pero hindi Ubuntu. Sa Linux Mint 22, inilalabas ng command na iyon ang wilma, na sariling codename ng Mint, at walang inilalabas ang Tailscale para rito. Basahin sa halip ang Ubuntu base.

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

Sa Ubuntu, pareho ang dalawang value. Sa isang derivative, ang VERSION_CODENAME ay pangalan ng derivative at ang UBUNTU_CODENAME ay ang Ubuntu release na pinagbabatayan nito. Gamitin ang UBUNTU_CODENAME sa dalawang URL.

Ang ikalawang paraan ay ang release upgrade. Idi-disable ng Ubuntu upgrade tool ang mga third-party source habang tumatakbo ito. Kaya pagkatapos i-upgrade ang Ubuntu 24.04 sa 26.04, makikita mong naka-comment out ang /etc/apt/sources.list.d/tailscale.list o ginagamit pa rin nito ang noble sa isang machine na resolute na ngayon. Ayusin ito sa pamamagitan ng muling pagpapatakbo ng dalawang curl command gamit ang bagong codename. Mao-overwrite ng mga ito ang dalawang file.

Ang ikatlong paraan ay timing. Sa mga linggo matapos ang bagong Ubuntu release, nauuna itong magkaroon ng codename sa Canonical bago ito magkaroon sa Tailscale. Karaniwang nag-i-install kapag itinuro ang file sa codename ng dating LTS, dahil kakaunti ang dependency ng mga package na ito. Ngunit nagpapatakbo ka ng build na ginawa para sa mas lumang release. Suriin kung ano talaga ang na-install gamit ang apt policy tailscale, at ibalik ang file kapag lumitaw na ang tamang codename.

Walang laman ang keyring, at walang inilabas na mensahe ang command na sumulat dito

Tahimik ang problemang ito, at dito nagtatapos ang karamihan sa mga ganitong kaso. Tingnan muli ang keyring command:

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

Binubuo ng shell ang buong pipeline bago tumakbo ang alinmang program, kaya agad binubuksan ng sudo tee ang keyring path at tina-truncate ito sa zero bytes. Kung mag-fail ang curl, at pinapabagsak ito ng -f sa anumang HTTP error, walang isinusulat ang curl at nag-e-exit ito nang may nonzero status. Nananatiling zero bytes ang file. Ang exit status ng pipeline ay status ng huling command, na tee, at nagtagumpay ito. Walang inilalabas na mensahe, at nagpapatuloy ka sa susunod na command dahil iniisip mong naka-install na ang key.

Suriin ang file, hindi ang command na lumikha nito.

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

Ang wastong keyring ay nagpi-print ng isang pub line at isang uid line na naglalaman ng pangalan ng Tailscale. Ang zero-byte file ay nagpi-print ng gpg: no valid OpenPGP data found. at wala nang iba. Ganito rin ang output ng file na nakakuha ng HTML error page, at ipinapakita ng head -c 80 rito ang simula ng isang web page sa halip na binary key data.

Kapag walang usable key ang keyring, dina-download ng sudo apt update ang index at pagkatapos ay tinatanggihan ito. Makakakita ka ng W: GPG error line na naglalaman ng pangalan ng Tailscale repository at suite nito, ng tekstong The following signatures couldn't be verified because the public key is not available: NO_PUBKEY na sinusundan ng 16-character key id, at ng error sa ilalim nito na nagsasabing hindi signed ang repository. Pansinin ang sinasabi ng apt: matagumpay nitong na-download ang index, pero hindi nito ma-check ang signature. Problema ito sa key, hindi sa network. Kung talagang wala ang keyring file, iba ang mensahe at direktang binabanggit nito ang path gamit ang Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg.

Isulat ang key sa dalawang hakbang para hindi masira ng failed download ang gumaganang keyring.

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

Ang gitnang line ang gate: kung hindi ito mag-print ng Tailscale uid, huminto at huwag i-copy ang file. Mahalaga ang Mode 0644 dahil gumagamit ang apt ng unprivileged na _apt user para mag-fetch at mag-verify, kaya hindi magagamit ng apt ang keyring na root lamang ang makakabasa.

Parehong repository ang inilalarawan ng .list at .sources file

Inilipat ng Ubuntu ang sarili nitong sources sa deb822 format sa Ubuntu 24.10, kung saan naging /etc/apt/sources.list.d/ubuntu.sources ang /etc/apt/sources.list. Patuloy namang inilalathala ng Tailscale ang one-line format. Noong sinuri noong August 2026, walang .sources file na mada-download mula sa pkgs.tailscale.com: nagbabalik ang URL na iyon ng 404. Kaya kung may tailscale.sources ang machine mo, ikaw o isang guide ang manu-manong gumawa nito. Kung naroon pa rin ang tailscale.list, dalawang beses nang inilalarawan ng apt ang parehong repository.

Ang mas banayad na bersyon ay isang warning sa bawat 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

Nangyayari ang mas seryosong bersyon kapag magkaibang keyring path ang nakalagay sa dalawang file, dahil hindi matukoy ng apt kung aling key ang dapat mamahala sa repository. Ipi-print nito ang E: Conflicting values set for option Signed-By regarding source, kasunod ang repository at suite nito, pagkatapos ang dalawang keyring path na pinaghihiwalay ng !=, at saka ito tatangging magpatuloy:

E: The list of sources could not be read.

Hinaharangan ng error na ito ang lahat ng apt command, hindi lamang ang update, hanggang sa maalis ang isa sa mga file. Lumilitaw din ang parehong failure sa mga sariling repository ng Ubuntu. Ipinaliliwanag ng duplicate apt source error pagkatapos ng deb822 migration ang pangkalahatang sitwasyon.

Hanapin muna ang lahat ng file na may binabanggit na Tailscale bago ka mag-delete.

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

Magtira ng isang file. Para i-disable ang isa nang hindi ito mawawala, i-rename ito: binabasa lamang ng apt ang mga file na nagtatapos sa .list o .sources. Kaya nilalaktawan ang tailscale.list.bak at nananatili ito sa disk bilang reference.

Wastong pagsulat ng deb822 source file

Kung mas gusto mo ang mas bagong format, i-convert ang kasalukuyan mo nang file sa halip na i-type muli ang repository address. Ang typo roon ang eksaktong pinagmumulan ng mga error sa itaas. May converter ang mga bagong apt release na nagre-rewrite ng .list files bilang mga deb822 stanza at inililipat ang signed-by option bilang Signed-By.

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

May apt ang Ubuntu 24.04 na mas luma kaysa sa subcommand na iyon. Kaya ipinapakita ng help line sa loob ng isang segundo kung mayroon nito ang iyong system. Kung wala, buuin ang stanza mula sa linyang nasa disk na, para manggaling sa file ng vendor ang base sa halip na sa keyboard mo.

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

Ini-print nito ang stanza na isinulat nito, kaya mababasa mong muli ang mga field bago ang susunod na apt update. Mahalaga ang apat sa mga ito, dahil magkakaiba ang paraan ng pag-fail ng bawat isa:

• URIs ang nagtatakda ng base ng repository. Kapag ipinaste rito ang bahaging dists/noble, magreresulta ito sa 404 dahil awtomatikong idinadagdag ng apt ang dists/<suite> at hinihingi nito ang dists/noble/dists/noble.
• Suites ang codename, at ito mismo ang value na nasa gitna ng one-line format.
• Signed-By ay tumatanggap ng absolute path patungo sa keyring file. Tumatanggap din ito ng armored key na direktang inilalagay sa ilalim nito. Sa ganitong format, dapat may isang space sa simula ng bawat linya ng key, at ang bawat blank line sa loob ng key ay dapat isulat bilang isang tuldok.
• Enabled: no ang nag-o-off ng source nang hindi ito dine-delete. Mas madali itong i-undo kaysa sa pag-rename, at mas madali rin itong ipaliwanag sa susunod na mag-a-admin.

Magpanatili ng isang stanza bawat file para sa mga third-party repository. Kung maglalagay ka ng ilang stanza sa iisang file, mag-iwan ng blank line sa pagitan ng mga ito. Nakalista sa repository index ang amd64 at arm64 bilang mga architecture nito, kaya walang kailangang idagdag na Architectures field para sa ARM VPS.

Isang proxy sa pagitan ang nagbabalik ng 403

Dahil 404 ang ibinabalik kapag walang sagot ang path na ito sa repository, nangangahulugan ang 403 na may ibang component na sumagot para rito. Magsimula sa sariling configuration ng apt, dahil ang proxy na itinakda roon ay nalalapat sa apt at hindi sa interactive mong curl.

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

Pagkatapos, tingnan kung ano talaga ang ipinapadala ng apt.

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

Ipinapakita nito ang request line, ang mga header na ipinadala ng apt, at ang proxy na pinagkonektahan nito, kung mayroon man. Ikumpara ito sa plain curl gamit ang parehong URL. Kung nagbabalik ang curl ng 200 at nagbabalik ang apt ng 403, may pagkakaiba ang dalawang request sa isang bagay na sinusuri ng middlebox. Karaniwang suspect ang 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

Kung 403 ang ibinabalik nito habang 200 ang ibinabalik ng default curl, tinatanggihan ng filtering device ang apt batay sa pangalan nito. Sa device na iyon dapat ayusin ang problema, hindi sa server mo. Iba naman ang kilos ng isang corporate proxy na nag-iinspeksyon ng TLS: nag-uulat ang apt ng certificate verification failure sa halip na status code, dahil ang natanggap nitong certificate ay inisyu ng proxy at hindi ng certificate authority ng Tailscale. Ang isa pang karaniwang pinagmumulan ay cloud egress firewall na pinapayagan lamang ang Ubuntu mirrors. Doon, ang kailangang ayusin ay ang pagpayag sa pkgs.tailscale.com sa firewall.

IPv6-only na egress, at ang mga error na hindi status code

Kung hindi kailanman nakatanggap ng HTTP response ang apt, subukan nang hiwalay ang bawat protocol.

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

Kapag sumasagot ang IPv4 ngunit nagha-hang ang IPv6 o nag-uulat ng Network is unreachable, nabibigo ang apt dahil mas pinipili ng resolver library ang IPv6 at walang gumaganang IPv6 path ang server. I-force ang isang run na gumamit ng IPv4 upang makumpirma ang teorya:

sudo apt -o Acquire::ForceIPv4=true update

Kung matagumpay ang update na ito, gawin itong permanenteng configuration.

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

Isaalang-alang din ang kabaligtarang sitwasyon. Sa isang VPS na walang IPv4 address, walang maaayos ang pag-force ng IPv4 dahil walang IPv4 route na mapagpapasahan ng traffic. Kailangan mo roon ng NAT64 na may DNS64 mula sa provider, o proxy na may IPv4 address. Ang sintomas ay isang connect error na naglalaman ng IPv6 address, kaya ang linyang curl -6 ang nagsasabi ng aktuwal na problema.

Mga fallback at ang kapalit ng bawat isa

Vendor install script. Ang curl -fsSL https://tailscale.com/install.sh | sh ang command na ina-advertise ng Tailscale. Kapag binasa ang script, dini-detect nito ang distribution mula sa /etc/os-release at pagkatapos ay isinusulat ang parehong dalawang path na inaayos ng gabay na ito, /usr/share/keyrings/tailscale-archive-keyring.gpg at /etc/apt/sources.list.d/tailscale.list, mula sa parehong mga URL. Mahalaga ito sa iyong expectations: hindi nito nilalampasan ang repository na bina-block ng proxy. Pareho itong nagfa-fail, pero mas kaunti ang output. Ang pag-pipe ng na-download na script papunta sa shell bilang root ay isang trade-off, hindi solusyon, dahil nagtitiwala ka sa anumang ibinabalik ng server sa sandaling iyon at wala kang naiwan na kopya ng isinagawa. Kung tatanggapin mo ang trade-off, gawin ito nang alam mo ang panganib:

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

Static binaries. Nagpa-publish din ang parehong server ng mga plain tarball sa ilalim ng seksyong static binaries sa pkgs.tailscale.com/stable. Noong August 2026, ang stable release ay 1.102.2 at ang 64 bit x86 file ay tailscale_1.102.2_amd64.tgz. Ikaw mismo ang maglalagay ng tailscale client at tailscaled daemon, at ikaw rin ang magmo-monitor sa daemon. Dahil dito, walang apt upgrade path at bawat future update ay download na kailangan mong tandaan. May silbi ito sa air-gapped host o kapag kailangan mong i-pin ang isang eksaktong version.

Sariling package ng Ubuntu. Wala nito. Kapag pinatakbo ang sudo apt install tailscale nang hindi naka-configure ang vendor repository, magtatapos ito sa E: Unable to locate package tailscale, at walang anumang pagbabago sa apt update ang makakapag-ayos nito. Kung ang talagang kailangan mo ay isang coordination server na ikaw ang kumokontrol sa halip na hosted server ng Tailscale, hiwalay na desisyon iyon: saklaw ng pagpapatakbo ng Headscale bilang sarili mong control server ang prosesong iyon, at tinatalakay naman sa paghahambing ng Tailscale at plain WireGuard kung kailangan mo ang alinman sa mga mekanismong ito.

Naka-install ang package, pero hindi nagsisimula ang tailscaled

Kapag maayos na ang apt, sa daemon naman lilitaw ang mga failure.

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

Sa VPS na gumagamit ng container virtualisation na nakikigamit sa kernel ng host, gaya ng LXC o OpenVZ, may linya sa log tungkol sa hindi umiiral na /dev/net/tun. Kailangan ng daemon ng TUN device para malikha ang tailscale0 interface, pero hindi ito ibinigay sa container. Hilingin sa provider na i-enable ang TUN sa container, o lumipat sa KVM plan kung saan sarili mong kernel ang ginagamit. Sa KVM, gumagana ito nang walang karagdagang setup.

Pagkatapos nito, magpi-print ang sudo tailscale up ng login URL, at dapat ilista ng tailscale status ang machine mo na may address sa 100.64.0.0/10 range. Ang machine na lumilitaw doon ay maaari mo nang pagbatayan sa susunod na configuration, gaya ng pag-aanunsiyo ng private subnet mula sa iyong VPS o paggamit sa VPS bilang exit node.

FAQ

Bakit sinasabi ng apt na hindi signed ang Tailscale repository?

Dahil na-download ng apt ang repository index pero hindi nito na-verify ang signature nito laban sa /usr/share/keyrings/tailscale-archive-keyring.gpg. Karaniwang dahilan nito ang keyring na zero bytes: pinutol ng sudo tee ang file bago nabigong mag-download ng kahit ano ang curl, at nag-report ng success ang pipeline dahil nagtagumpay ang tee. Patakbuhin ang gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg. Ang gumaganang keyring ay nagpi-print ng pub line at uid line na naglalaman ng pangalan ng Tailscale, habang ang walang laman o corrupt na keyring ay nagpi-print ng gpg: no valid OpenPGP data found. I-download ang key sa temporary file, suriin ito roon, at pagkatapos ay kopyahin ito sa tamang lokasyon gamit ang mode na 0644 upang mabasa ito ng _apt user.

Aling Ubuntu codename ang dapat kong ilagay sa Tailscale URLs?

Gamitin ang value ng UBUNTU_CODENAME mula sa /etc/os-release, na noble sa Ubuntu 24.04 at resolute sa Ubuntu 26.04. Huwag gamitin ang lsb_release -cs sa distribution na derived mula sa Ubuntu: sa Linux Mint 22, nagpi-print ito ng wilma, walang pino-publish ang Tailscale sa ilalim ng pangalang iyon, at nagre-report ang apt ng 404 sa dists/wilma/InRelease. Kumpirmahin ang pinili mo bago mag-edit ng kahit ano sa pamamagitan ng manu-manong pag-fetch ng index gamit ang curl -sS -o /dev/null -w '%{http_code}\n' laban sa https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease.

Ligtas bang patakbuhin ang Tailscale install script na naka-pipe sa isang shell?

Isa itong trade-off na dapat mong sadyang pagpasiyahan. Galing ang script sa Tailscale at ginagawa nito ang ginagawa ng manual steps: binabasa nito ang /etc/os-release, isinusulat ang parehong keyring at parehong /etc/apt/sources.list.d/tailscale.list, at pagkatapos ay ini-install ang package. Ang kapalit nito ay pinapatakbo mo ang anumang ibinabalik ng server sa sandaling iyon, gamit ang root, at wala kang naiwan na kopya nito. I-download ito gamit ang -o install.sh, basahin ito, at pagkatapos ay patakbuhin kung nais mo ang convenience nang hindi nawawala ang visibility sa ginagawa nito. Hindi rin nito maaayos ang blocked repository dahil ginagamit nito ang parehong URLs na dati nang nag-fail.

Paano ko ii-install ang Tailscale sa Ubuntu nang walang apt repository?

Gamitin ang static tarballs na pino-publish sa pkgs.tailscale.com, na noong August 2026 ay nasa version 1.102.2 at may amd64 file na pinangalanang tailscale_1.102.2_amd64.tgz. Ikaw mismo ang mag-i-install ng tailscale at tailscaled programs at ikaw rin ang magpapatakbo ng daemon sa ilalim ng systemd. Ang kapalit nito ay ang upgrades: walang apt package na kukuha ng bagong version, kaya manual ang bawat update. Walang sariling tailscale package ang Ubuntu archive, kaya ang sudo apt install tailscale sa machine na walang vendor repository ay humihinto sa E: Unable to locate package tailscale.