SSD Nodes Learn 🎉 VPS $5.50/माह से
गाइड Matt Connorलेखक: Matt Connor

Ubuntu पर Tailscale install errors कैसे ठीक करें

Ubuntu पर Tailscale install errors को ठीक करने के लिए apt errors और status codes की जांच करें। यह गाइड आपको सही release codename और signing keyring सेट करने में मदद करेगी।

Ubuntu पर Tailscale install errors, apt errors क्यों होती हैं

Ubuntu पर Tailscale install errors लगभग हमेशा Tailscale code के चलने से पहले ही हो जाती हैं। ये apt errors होती हैं। Ubuntu अपना खुद का tailscale package प्रदान नहीं करता है: अगस्त 2026 में Ubuntu package archive की जाँच करने पर, केवल Go helper libraries और python3-tailscale ही मिलते हैं, इसलिए daemon को pkgs.tailscale.com पर स्थित Tailscale के अपने apt repository से ही आना पड़ता है।

उस repository को जोड़ने पर दो files लिखी जाती हैं। एक file apt को बताती है कि packages कहाँ स्थित हैं। दूसरी में वह public key होती है जिसका उपयोग apt repository index के signature की जाँच करने के लिए करता है। नीचे दी गई लगभग हर विफलता उन दो files में से किसी एक के गलत होने, या apt और repository के बीच किसी device द्वारा अनुरोध को अस्वीकार करने के कारण होती है।

ये वे commands हैं जिन्हें Tailscale ने 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, Ubuntu 24.04 का codename है, और यह दोनों URLs में दिखाई देता है। दूसरी command एक comment line और एक deb line को /etc/apt/sources.list.d/tailscale.list में लिखती है, और cat आपको ठीक वही दिखाता है जो वहाँ दर्ज हुआ है।

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

उस deb line को चार fields वाले पते के रूप में पढ़ें: कोष्ठक में दिया गया option [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg], फिर repository base, जो कि https के माध्यम से पहुँचा जाने वाला pkgs.tailscale.com/stable/ubuntu है, फिर suite noble, और अंत में component main। apt base और suite को जोड़कर एक URL बनाता है और उसे fetch करता है: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease। यदि आप उस URL को मैन्युअल रूप से fetch कर सकते हैं, तो apt भी उसे fetch कर सकता है। यही पूरा diagnostic है।

किसी भी बदलाव से पहले apt error को पढ़ें

Update को अकेले चलाएं ताकि कोई अन्य आउटपुट error को स्क्रीन से न हटा दे।

sudo apt update

एक विफल third-party repository का आउटपुट ऐसा दिखता है। आपकी मशीन पर codename और IP address अलग होंगे।

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.

उस आउटपुट में दो चीजें तय करती हैं कि आपको आगे क्या करना है: status code, और E: Failed to fetch लाइन पर मौजूद पूरा URL। नीचे दी गई summary लाइन से अनुमान न लगाएं। URL को कॉपी करें और सर्वर से स्वयं पूछें।

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

यह उस codename के लिए 200 प्रिंट करता है जिसे Tailscale पब्लिश करता है। अगस्त 2026 में जांचे जाने पर, noble एक signed index लौटाता है जिसमें Origin: Tailscale और Codename: noble शामिल हैं। अपनी error से मिले codename के लिए noble को बदलें और इसे फिर से चलाएं। यदि curl को 200 मिलता है जहाँ apt को error मिली थी, तो repository ठीक है और समस्या apt के अपने configuration में है।

स्टेटस कोड आपको क्या बताता है

  • 404 Not Found का अर्थ है कि उस पाथ पर रिपॉजिटरी में कोई फाइल मौजूद नहीं है। pkgs.tailscale.com पर इसका मतलब लगभग हमेशा URL में मौजूद कोडनेम से होता है।
  • 403 Forbidden का अर्थ है कि किसी ने जवाब दिया और अनुरोध को अस्वीकार कर दिया। अगस्त 2026 तक, यह रिपॉजिटरी उन पाथ के लिए 404 लौटाती है जो मौजूद नहीं हैं, इसलिए 403 का मतलब आपके सर्वर और Tailscale के बीच मौजूद किसी प्रॉक्सी, फिल्टरिंग उपकरण या फायरवॉल से है।
  • 401 Unauthorized या 407 Proxy Authentication Required का अर्थ है कि प्रॉक्सी को ऐसे क्रेडेंशियल्स चाहिए जो apt नहीं भेज रहा है।
  • कनेक्ट एरर या नेम रेजोल्यूशन एरर का मतलब है कि कोई HTTP संवाद हुआ ही नहीं। IPv6 सेक्शन पर जाएं।

URL में दिया गया codename वह है जिसे Tailscale प्रकाशित नहीं करता है

Tailscale प्रत्येक Ubuntu codename के लिए एक अलग directory बनाता है। यदि आप ऐसे codename के लिए अनुरोध करते हैं जो वहां मौजूद नहीं है, तो आपको 404 error मिलेगा, क्योंकि सर्वर पर सेवा देने के लिए कोई dists/<codename> मौजूद नहीं है। pkgs.tailscale.com/stable पर वेंडर की अपनी सूची दिखाती है कि कौन से codename मौजूद हैं। अगस्त 2026 में, वह सूची 16.04 से लेकर resolute तक है, जो कि Ubuntu 26.04 है।

गलत codename के आने का सामान्य कारण Ubuntu पर आधारित किसी distribution पर lsb_release -cs चलाना है, जो स्वयं Ubuntu नहीं है। Linux Mint 22 पर वह command wilma प्रिंट करती है, जो Mint का अपना codename है, और Tailscale इसके लिए कुछ भी प्रकाशित नहीं करता है। इसके बजाय Ubuntu base को पढ़ें।

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

Ubuntu पर दोनों मान समान होते हैं। किसी derivative पर, VERSION_CODENAME derivative का नाम होता है और UBUNTU_CODENAME वह Ubuntu release है जिस पर इसे बनाया गया है। दोनों URLs में UBUNTU_CODENAME का उपयोग करें।

दूसरा कारण release upgrade है। Ubuntu upgrade tool चलते समय third-party sources को disable कर देता है, इसलिए Ubuntu 24.04 से 26.04 पर अपग्रेड करने के बाद आप पाएंगे कि /etc/apt/sources.list.d/tailscale.list या तो commented out है या अभी भी उस मशीन पर noble का नाम ले रहा है जो अब resolute है। इसे ठीक करने के लिए नए codename के साथ दो curl commands को फिर से चलाएं, जो दोनों फाइलों को overwrite कर देंगी।

तीसरा कारण समय है। नए Ubuntu release के बाद के हफ्तों में, codename Canonical के पास Tailscale से पहले मौजूद होता है। फाइल को पिछले LTS codename पर point करने से आमतौर पर installation हो जाता है, क्योंकि इन packages में dependencies कम होती हैं, लेकिन आप उस स्थिति में पुराने release के लिए बना build चला रहे होते हैं। apt policy tailscale के साथ जांचें कि आपको वास्तव में क्या मिला है, और वास्तविक codename आने पर फाइल को वापस बदल दें।

Keyring खाली है और इसे लिखने वाली कमांड ने कोई आउटपुट नहीं दिया

यह समस्या शांत है और अधिकांश मामले यहीं समाप्त होते हैं। Keyring कमांड को फिर से देखें:

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

Shell किसी भी प्रोग्राम के चलने से पहले पूरी पाइपलाइन तैयार करता है, इसलिए sudo tee keyring पाथ को खोलता है और उसे तुरंत शून्य बाइट्स पर ट्रंकेट (truncate) कर देता है। यदि इसके बाद curl विफल हो जाता है, और -f इसे किसी भी HTTP त्रुटि पर विफल होने के लिए बाध्य करता है, तो curl कुछ भी नहीं लिखता और नॉन-जीरो (nonzero) स्टेटस के साथ बाहर निकल जाता है। फ़ाइल शून्य बाइट्स पर ही रहती है। पाइपलाइन का एक्जिट स्टेटस उसके अंतिम कमांड का स्टेटस होता है, जो कि tee है, जो सफल रहा। कुछ भी प्रिंट नहीं होता है, और आप यह मानकर अगले कमांड पर चले जाते हैं कि की (key) इंस्टॉल हो गई है।

कमांड के बजाय फ़ाइल की जाँच करें जिसने इसे बनाया है।

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

एक सही keyring एक pub लाइन और Tailscale का नाम बताने वाली एक uid लाइन प्रिंट करता है। शून्य बाइट वाली फ़ाइल gpg: no valid OpenPGP data found. प्रिंट करती है और कुछ नहीं। जिस फ़ाइल में HTML त्रुटि पृष्ठ आ गया है, वह भी यही प्रिंट करती है, और उस पर head -c 80 चलाने से बाइनरी की डेटा के बजाय वेब पेज की शुरुआत दिखाई देती है।

ऐसे keyring के साथ जिसमें कोई उपयोगी की नहीं है, sudo apt update इंडेक्स को डाउनलोड करता है और फिर उसे अस्वीकार कर देता है। आपको Tailscale रिपॉजिटरी और उसके सुइट का नाम बताने वाली एक W: GPG error लाइन मिलती है, उसके बाद The following signatures couldn't be verified because the public key is not available: NO_PUBKEY टेक्स्ट और 16 वर्णों की की आईडी होती है, और उसके नीचे एक त्रुटि होती है कि रिपॉजिटरी हस्ताक्षरित (signed) नहीं है। ध्यान दें कि apt आपको क्या बता रहा है: इसने इंडेक्स को ठीक से डाउनलोड किया, लेकिन यह हस्ताक्षर की जाँच नहीं कर सका। यह एक की (key) से संबंधित समस्या है, नेटवर्क की समस्या नहीं। यदि keyring फ़ाइल पूरी तरह से गायब है, तो संदेश फिर से अलग होता है, और Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg के साथ सीधे पाथ का नाम बताता है।

की (key) को दो चरणों में लिखें ताकि एक विफल डाउनलोड काम कर रहे 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

बीच की लाइन गेट (gate) है: यदि यह Tailscale uid प्रिंट नहीं करती है, तो रुक जाएं और फ़ाइल को कॉपी न करें। मोड 0644 मायने रखता है क्योंकि apt फ़ेच और सत्यापित करने के लिए अनप्रिविलेज्ड _apt यूजर पर स्विच हो जाता है, इसलिए जिस keyring को केवल root ही पढ़ सकता है, वह ऐसा keyring है जिसे apt इस्तेमाल नहीं कर सकता।

एक ही रिपॉजिटरी के लिए .list और .sources दोनों फाइलें मौजूद हैं

Ubuntu ने 24.10 संस्करण में अपने sources को deb822 फॉर्मेट में स्थानांतरित कर दिया है, जहाँ /etc/apt/sources.list बदलकर /etc/apt/sources.list.d/ubuntu.sources हो गया है। Tailscale अभी भी one-line फॉर्मेट का ही उपयोग करता है। अगस्त 2026 में जाँच करने पर, pkgs.tailscale.com से डाउनलोड करने के लिए कोई .sources फाइल उपलब्ध नहीं है: वह URL 404 error देता है। इसलिए, यदि आपके सिस्टम में tailscale.sources मौजूद है, तो या तो आपने इसे स्वयं बनाया है या किसी गाइड का पालन करते हुए लिखा है, और यदि tailscale.list भी वहां मौजूद है, तो apt के पास अब एक ही रिपॉजिटरी दो बार वर्णित है।

इसका हल्का रूप हर अपडेट पर एक चेतावनी के रूप में दिखता है:

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

गंभीर समस्या तब होती है जब दोनों फाइलें अलग-अलग keyring paths बताती हैं, क्योंकि apt यह तय नहीं कर पाता कि रिपॉजिटरी के लिए कौन सी key मान्य है। यह E: Conflicting values set for option Signed-By regarding source प्रिंट करता है, फिर रिपॉजिटरी और उसकी suite का नाम, फिर उनके बीच != के साथ दोनों keyring paths दिखाता है, और आगे बढ़ने से मना कर देता है:

E: The list of sources could not be read.

यह स्थिति हर apt कमांड को रोक देती है, न कि केवल अपडेट को, जब तक कि उन फाइलों में से एक को हटा न दिया जाए। यही विफलता Ubuntu की अपनी रिपॉजिटरी के साथ भी हो सकती है, और deb822 माइग्रेशन के बाद डुप्लिकेट apt source त्रुटि लेख में इसके सामान्य समाधान के बारे में बताया गया है।

कुछ भी हटाने से पहले उन सभी फाइलों को खोजें जिनमें Tailscale का उल्लेख है।

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

एक फाइल रखें। दूसरी को बिना खोए डिसेबल करने के लिए, उसका नाम बदल दें: apt केवल उन फाइलों को पढ़ता है जो .list या .sources पर समाप्त होती हैं, इसलिए tailscale.list.bak को नजरअंदाज कर दिया जाता है और वह संदर्भ के लिए डिस्क पर सुरक्षित रहती है।

deb822 सोर्स फ़ाइल को सही ढंग से लिखना

यदि आप नए फॉर्मेट को प्राथमिकता देते हैं, तो रिपॉजिटरी एड्रेस को दोबारा टाइप करने के बजाय अपनी मौजूदा फ़ाइल को कन्वर्ट करें, क्योंकि टाइपिंग की गलती ही ऊपर दी गई त्रुटियों का मुख्य कारण होती है। हालिया apt रिलीज़ में एक कन्वर्टर होता है जो .list फ़ाइलों को deb822 स्टैंज़ा (stanzas) में फिर से लिखता है और signed-by विकल्प को Signed-By के रूप में स्थानांतरित कर देता है।

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

Ubuntu 24.04 में जो apt वर्शन आता है, उसमें यह सब-कमांड उपलब्ध नहीं है, इसलिए हेल्प लाइन आपको तुरंत बता देगी कि आपके वर्शन में यह सुविधा है या नहीं। जहाँ यह उपलब्ध नहीं है, वहाँ डिस्क पर मौजूद लाइन से ही स्टैंज़ा बनाएँ, ताकि बेस आपके कीबोर्ड के बजाय वेंडर की फ़ाइल से आए।

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

यह उस स्टैंज़ा को प्रिंट करता है जिसे उसने लिखा है, ताकि आप अगले apt update से पहले फ़ील्ड्स को दोबारा पढ़ सकें। इनमें से चार के बारे में विस्तार से जानना उपयोगी है, क्योंकि प्रत्येक अलग तरह से विफल (fail) होता है:

  • URIs रिपॉजिटरी के बेस पर रुक जाता है। इसमें dists/noble भाग को पेस्ट करने पर 404 त्रुटि मिलती है, क्योंकि apt स्वयं dists/<suite> जोड़ देता है और dists/noble/dists/noble के लिए अनुरोध करता है।
  • Suites कोडनेम है, जो बिल्कुल वही मान है जो वन-लाइन फॉर्मेट के बीच में होता था।
  • Signed-By कीरिंग फ़ाइल का एब्सोल्यूट पाथ लेता है। यह इसके नीचे इनलाइन (inlined) आर्मर्ड की (armored key) को भी स्वीकार करता है, जहाँ की की प्रत्येक लाइन एक स्पेस से इंडेंट होती है और की के अंदर की प्रत्येक खाली लाइन को एक डॉट के रूप में लिखा जाता है।
  • Enabled: no किसी सोर्स को डिलीट किए बिना उसे बंद कर देता है, जिसे रीनेम करने की तुलना में वापस ठीक करना आसान है और किसी अन्य व्यक्ति को समझाना भी सरल है।

थर्ड-पार्टी रिपॉजिटरी के लिए प्रति फ़ाइल एक स्टैंज़ा रखें, और यदि आप कभी कई स्टैंज़ा एक साथ रखते हैं तो उनके बीच एक खाली लाइन छोड़ें। रिपॉजिटरी इंडेक्स अपने आर्किटेक्चर में amd64 और arm64 को लिस्ट करता है, इसलिए ARM VPS को किसी अतिरिक्त Architectures फ़ील्ड की आवश्यकता नहीं होती है।

बीच में मौजूद प्रॉक्सी 403 एरर लौटाता है

चूंकि जिस पाथ पर यह रिपॉजिटरी मौजूद नहीं है, वहां 404 एरर आता है, इसलिए 403 का मतलब है कि किसी और ने आपकी ओर से जवाब दिया है। सबसे पहले apt के अपने कॉन्फ़िगरेशन की जाँच करें, क्योंकि वहां सेट की गई प्रॉक्सी केवल apt पर लागू होती है, न कि आपके इंटरैक्टिव curl पर।

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

इसके बाद देखें कि apt वास्तव में क्या भेज रहा है।

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

यह कमांड रिक्वेस्ट लाइन, apt द्वारा भेजे गए हेडर और उस प्रॉक्सी को प्रिंट करती है जिससे वह कनेक्ट हुआ है (यदि कोई हो)। इसकी तुलना उसी URL पर चलाए गए सामान्य curl से करें। यदि curl 200 लौटाता है और apt 403 लौटाता है, तो दोनों रिक्वेस्ट में कुछ ऐसा अंतर है जिसे बीच में मौजूद डिवाइस (middlebox) ट्रैक कर रहा है, और आमतौर पर इसका कारण 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

यदि यह कमांड 403 लौटाती है जबकि डिफ़ॉल्ट curl 200 लौटाता है, तो कोई फ़िल्टरिंग डिवाइस apt को उसके नाम के आधार पर ब्लॉक कर रहा है। इसका समाधान उस डिवाइस पर किया जाना चाहिए, न कि आपके सर्वर पर। TLS का निरीक्षण करने वाली कॉर्पोरेट प्रॉक्सी अलग तरह से व्यवहार करती है: apt स्टेटस कोड के बजाय सर्टिफिकेट वेरिफिकेशन फेलियर की रिपोर्ट करता है, क्योंकि उसे प्राप्त सर्टिफिकेट Tailscale की सर्टिफिकेट अथॉरिटी के बजाय प्रॉक्सी द्वारा जारी किया गया होता है। क्लाउड एग्रेस फ़ायरवॉल जो केवल Ubuntu मिरर्स को अनुमति देता है, वह एक अन्य सामान्य कारण है, और वहां समाधान फ़ायरवॉल पर pkgs.tailscale.com को अनुमति देना है।

केवल IPv6 egress, और वे त्रुटियाँ जो status codes नहीं हैं

यदि apt को कभी कोई HTTP response नहीं मिला, तो प्रत्येक 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

जब IPv4 उत्तर देता है और IPv6 hang हो जाता है या Network is unreachable रिपोर्ट करता है, तो apt इसलिए विफल हो रहा है क्योंकि resolver library IPv6 को प्राथमिकता देती है और box पर कोई कार्यशील IPv6 path नहीं है। सिद्धांत की पुष्टि करने के लिए एक run को IPv4 पर force करें:

sudo apt -o Acquire::ForceIPv4=true update

यदि वह update सफल हो जाता है, तो इसे स्थायी बना दें।

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

विपरीत स्थिति के बारे में स्पष्ट रहें। ऐसे VPS पर जिसमें कोई IPv4 address ही नहीं है, IPv4 को force करने से कुछ ठीक नहीं होगा, क्योंकि traffic को भेजने के लिए कोई IPv4 route मौजूद नहीं है। वहाँ आपको अपने provider से NAT64 और DNS64 की आवश्यकता होगी, या एक ऐसे proxy की जो IPv4 address रखता हो। इसका लक्षण एक connect error है जो IPv6 address का नाम लेता है, इसलिए curl -6 line ही वह है जो आपको सच्चाई बताती है।

फॉलबैक और उनकी लागत

वेंडर इंस्टाल स्क्रिप्ट। curl -fsSL https://tailscale.com/install.sh | sh वह कमांड है जिसका Tailscale विज्ञापन करता है। स्क्रिप्ट को पढ़ने पर पता चलता है कि यह /etc/os-release से आपके डिस्ट्रिब्यूशन का पता लगाती है और फिर उन्हीं दो पाथ्स को लिखती है जिन्हें यह गाइड ठीक कर रही है, यानी /usr/share/keyrings/tailscale-archive-keyring.gpg और /etc/apt/sources.list.d/tailscale.list, उन्हीं URLs से। यह आपकी अपेक्षाओं के लिए महत्वपूर्ण है: यदि कोई प्रॉक्सी रिपॉजिटरी को ब्लॉक कर रही है, तो यह उसे बायपास नहीं करती। यह कम आउटपुट के साथ उसी तरह विफल हो जाती है। डाउनलोड की गई स्क्रिप्ट को root के रूप में सीधे शेल में पाइप करना एक समझौता है, समाधान नहीं, क्योंकि आप उस समय सर्वर जो भी लौटाता है उस पर भरोसा कर रहे होते हैं और आपके पास इस बात की कोई कॉपी नहीं रहती कि क्या रन हुआ। यदि आप यह समझौता करते हैं, तो पूरी जानकारी के साथ करें:

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

स्टैटिक बाइनरीज। वही सर्वर pkgs.tailscale.com/stable के स्टैटिक बाइनरीज सेक्शन के तहत प्लेन टारबॉल्स प्रकाशित करता है। अगस्त 2026 तक स्टेबल रिलीज 1.102.2 है और 64 बिट x86 फाइल tailscale_1.102.2_amd64.tgz है। आप tailscale क्लाइंट और tailscaled डेमन को स्वयं रखते हैं, और आप स्वयं डेमन को सुपरवाइज करते हैं, इसलिए इसमें कोई apt upgrade पाथ नहीं होता और भविष्य का हर अपडेट एक ऐसा डाउनलोड होता है जिसे आपको याद रखना पड़ता है। यह एयर-गैप्ड होस्ट के लिए, या जब आपको किसी एक सटीक वर्जन को पिन करना हो, तब उपयोगी है।

Ubuntu का अपना पैकेज। ऐसा कोई पैकेज नहीं है। वेंडर रिपॉजिटरी को कॉन्फ़िगर किए बिना sudo apt install tailscale चलाने का परिणाम E: Unable to locate package tailscale पर समाप्त होता है, और apt update का कितना भी उपयोग इसे नहीं बदलता। यदि आप वास्तव में Tailscale के होस्टेड सर्वर के बजाय एक ऐसा कोऑर्डिनेशन सर्वर चाहते हैं जिसे आप नियंत्रित कर सकें, तो वह एक अलग निर्णय है: अपना कंट्रोल सर्वर चलाने के रूप में Headscale इसे कवर करता है, और Tailscale और प्लेन WireGuard के बीच तुलना यह कवर करती है कि क्या आपको इस मशीनरी की आवश्यकता है या नहीं।

Package install हो गया है, लेकिन tailscaled start नहीं हो रहा है

जब apt की प्रक्रिया पूरी हो जाती है, तो त्रुटियाँ daemon स्तर पर आ जाती हैं।

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

LXC या OpenVZ जैसे container virtualization का उपयोग करने वाले VPS पर, जो host kernel को साझा करते हैं, log में /dev/net/tun के मौजूद न होने के बारे में एक पंक्ति दिखाई देती है। Daemon को tailscale0 interface बनाने के लिए एक TUN device की आवश्यकता होती है, और container को यह सुविधा नहीं दी गई थी। अपने provider से container पर TUN enable करने के लिए कहें, या किसी ऐसे KVM plan पर जाएँ जहाँ आपको अपना kernel मिलता है। KVM पर यह बिना किसी अतिरिक्त setup के काम करता है।

उसके बाद, sudo tailscale up एक login URL print करता है, और tailscale status को आपकी machine को 100.64.0.0/10 range में एक address के साथ list करना चाहिए। जो machine वहाँ दिखाई देती है, उस पर आप काम शुरू कर सकते हैं, चाहे इसका मतलब अपने VPS से private subnet advertise करना हो या VPS को exit node के रूप में उपयोग करना हो।

FAQ

apt यह क्यों कहता है कि Tailscale रिपॉजिटरी हस्ताक्षरित (signed) नहीं है?

ऐसा इसलिए होता है क्योंकि apt ने रिपॉजिटरी इंडेक्स डाउनलोड तो कर लिया, लेकिन वह /usr/share/keyrings/tailscale-archive-keyring.gpg के विरुद्ध इसके हस्ताक्षर की पुष्टि नहीं कर सका। इसका सामान्य कारण यह है कि कीरिंग (keyring) शून्य बाइट्स की है: sudo tee ने कुछ भी डाउनलोड होने से पहले ही फाइल को काट (truncate) दिया, और पाइपलाइन ने सफलता की सूचना दी क्योंकि tee सफल रहा था। gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg चलाएं। एक सही कीरिंग pub लाइन और Tailscale का नाम बताने वाली uid लाइन प्रिंट करती है, जबकि खाली या दूषित कीरिंग gpg: no valid OpenPGP data found. प्रिंट करती है। कुंजी को एक अस्थायी फाइल में डाउनलोड करें, वहां उसकी जांच करें, और फिर उसे 0644 मोड के साथ सही स्थान पर कॉपी करें ताकि _apt उपयोगकर्ता इसे पढ़ सके।

मुझे Tailscale URLs में कौन सा Ubuntu कोडनेम डालना चाहिए?

/etc/os-release से UBUNTU_CODENAME का मान उपयोग करें, जो Ubuntu 24.04 पर noble और Ubuntu 26.04 पर resolute है। Ubuntu से व्युत्पन्न (derived) किसी वितरण पर lsb_release -cs का उपयोग न करें: Linux Mint 22 पर यह wilma प्रिंट करता है, Tailscale उस नाम के तहत कुछ भी प्रकाशित नहीं करता है, और apt dists/wilma/InRelease पर 404 रिपोर्ट करता है। कुछ भी संपादित करने से पहले https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease के विरुद्ध curl -sS -o /dev/null -w '%{http_code}\n' के साथ इंडेक्स को मैन्युअल रूप से फेच करके अपने विकल्प की पुष्टि करें।

क्या Tailscale इंस्टॉल स्क्रिप्ट को पाइप के जरिए सीधे शेल में चलाना सुरक्षित है?

यह एक ऐसा समझौता है जिसे आपको सोच-समझकर करना चाहिए। स्क्रिप्ट Tailscale से आती है और वही काम करती है जो मैन्युअल चरणों में होता है: यह /etc/os-release को पढ़ती है, वही कीरिंग और वही /etc/apt/sources.list.d/tailscale.list लिखती है, और फिर पैकेज इंस्टॉल करती है। इसकी कीमत यह है कि आप उस समय सर्वर जो भी लौटाता है, उसे root के रूप में चलाते हैं और उसका कोई रिकॉर्ड नहीं रखते। इसे -o install.sh के साथ डाउनलोड करें, इसे पढ़ें, और यदि आप बिना किसी जोखिम के सुविधा चाहते हैं तो इसे चलाएं। यह किसी ब्लॉक की गई रिपॉजिटरी के मामले में भी मदद नहीं कर सकती, क्योंकि यह उन्हीं URLs का उपयोग करती है जो पहले ही विफल हो चुके हैं।

मैं apt रिपॉजिटरी के बिना Ubuntu पर Tailscale कैसे इंस्टॉल करूं?

pkgs.tailscale.com पर प्रकाशित स्टेटिक टारबॉल्स (static tarballs) का उपयोग करें, जो अगस्त 2026 तक संस्करण 1.102.2 पर हैं और जिसमें tailscale_1.102.2_amd64.tgz नामक amd64 फाइल है। आप tailscale और tailscaled प्रोग्राम स्वयं इंस्टॉल करते हैं और डेमन (daemon) को स्वयं systemd के तहत चलाते हैं। इसकी कीमत अपग्रेड है: नया संस्करण प्राप्त करने के लिए कोई apt पैकेज नहीं है, इसलिए प्रत्येक अपडेट मैन्युअल है। Ubuntu के आर्काइव में अपना कोई tailscale पैकेज नहीं है, इसलिए वेंडर रिपॉजिटरी के बिना मशीन पर sudo apt install tailscale चलाने पर E: Unable to locate package tailscale पर त्रुटि आती है।

#tailscale#apt#troubleshooting#gpg-keys#ubuntu