Ubuntu میں Tailscale کی تنصیب کی خرابی ٹھیک کریں

Ubuntu میں Tailscale کی تنصیب کی خرابی دراصل apt کی خرابی کیوں ہوتی ہے

Ubuntu میں Tailscale کی تنصیب کی خرابیاں تقریباً ہمیشہ Tailscale کے کسی code کے چلنے سے پہلے پیدا ہوتی ہیں۔ یہ apt کی خرابیاں ہوتی ہیں۔ Ubuntu اپنی طرف سے tailscale package فراہم نہیں کرتا: August 2026 میں Ubuntu package archive کے خلاف کی گئی جانچ کے مطابق، صرف Go helper libraries اور python3-tailscale دستیاب ہیں۔ اس لیے daemon کو Tailscale کے اپنے apt repository، یعنی pkgs.tailscale.com، سے حاصل کرنا پڑتا ہے۔

یہ repository شامل کرنے سے دو files لکھی جاتی ہیں۔ ایک file apt کو بتاتی ہے کہ packages کہاں موجود ہیں۔ دوسری file میں وہ public key ہوتی ہے جسے apt repository index کے signature کی جانچ کے لیے استعمال کرتا ہے۔ ذیل میں بیان کردہ تقریباً ہر خرابی ان دو files میں سے کسی ایک کے غلط ہونے، یا apt اور repository کے درمیان موجود کسی device کی request مسترد کرنے کی وجہ سے ہوتی ہے۔

Ubuntu 24.04 کے لیے Tailscale یہ commands شائع کرتا ہے:

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 /etc/apt/sources.list.d/tailscale.list میں ایک comment line اور ایک deb line لکھتی ہے، جبکہ cat آپ کو بالکل دکھاتا ہے کہ وہاں کیا لکھا گیا ہے۔

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

اس deb line کو چار fields پر مشتمل address سمجھیں: پہلے brackets میں دیا گیا option [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg]، پھر repository base، جو pkgs.tailscale.com/stable/ubuntu ہے اور https کے ذریعے دستیاب ہے، پھر suite noble، اور آخر میں component main۔ apt base اور suite کو ملا کر ایک URL بناتا ہے اور اسے fetch کرتا ہے: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease۔ اگر آپ اس URL کو دستی طور پر fetch کر سکتے ہیں تو apt بھی اسے fetch کر سکتا ہے۔ یہی مکمل diagnostic ہے۔

apt کی خرابی میں موجود معلومات پڑھیں، پھر تبدیلی کریں

Update کو الگ سے چلائیں تاکہ کوئی اور output خرابی کو scroll کر کے اوپر نہ لے جائے۔

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.

اس output میں دو چیزیں طے کرتی ہیں کہ آپ کو آگے کیا کرنا ہے: status code، اور E: Failed to fetch لائن پر موجود مکمل URL۔ نیچے موجود summary line کی بنیاد پر اندازہ نہ لگائیں۔ URL copy کریں اور خود server سے اس کی تصدیق کریں۔

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

یہ 200 output دکھاتا ہے، جو اس codename کے لیے ہے جسے Tailscale publish کرتا ہے۔ August 2026 میں کی گئی جانچ کے مطابق، noble signed index واپس کرتا ہے جس میں Origin: Tailscale اور Codename: noble شامل ہیں۔ noble کی جگہ اپنی error میں موجود codename لکھیں اور command دوبارہ چلائیں۔ اگر curl کو 200 ملتا ہے جبکہ apt کو error ملتی ہے، تو repository درست ہے اور مسئلہ apt کی اپنی configuration میں ہے۔

اسٹیٹس code آپ کو کیا بتاتا ہے

• 404 Not Found کا مطلب ہے کہ repository میں اس path پر کوئی file موجود نہیں۔ pkgs.tailscale.com میں یہ تقریباً ہمیشہ URL میں موجود codename ہوتا ہے۔
• 403 Forbidden کا مطلب ہے کہ کسی endpoint نے جواب دے کر request مسترد کر دی۔ August 2026 تک یہ repository ایسے path کے لیے 404 واپس کرتی ہے جو اس میں موجود نہ ہو، اس لیے 403 آپ کے server اور Tailscale کے درمیان موجود proxy، filtering appliance یا firewall کی طرف اشارہ کرتا ہے۔
• 401 Unauthorized یا 407 Proxy Authentication Required کا مطلب ہے کہ proxy ایسے credentials مانگ رہا ہے جو apt نہیں بھیج رہا۔
• connect error یا name resolution error کا مطلب ہے کہ HTTP conversation بالکل شروع نہیں ہوئی۔ IPv6 section پر جائیں۔

URL میں دیا گیا codename وہ ہے جسے Tailscale شائع نہیں کرتا

Tailscale ہر Ubuntu codename کے لیے الگ directory بناتا ہے۔ اگر آپ ایسا codename طلب کریں جو وہاں موجود نہ ہو تو 404 ملتا ہے، کیونکہ server پر پیش کرنے کے لیے کوئی dists/<codename> موجود نہیں ہوتا۔ vendor کی اپنی فہرست pkgs.tailscale.com/stable میں موجود codename دکھائے گئے ہیں۔ August 2026 میں یہ فہرست 16.04 سے شروع ہو کر resolute تک جاتی ہے، جو Ubuntu 26.04 ہے۔

غلط codename عموماً اس وقت شامل ہوتا ہے جب lsb_release -cs ایسی distribution پر چلایا جائے جو Ubuntu پر مبنی ہو، لیکن Ubuntu نہ ہو۔ Linux Mint 22 پر یہ command wilma دکھاتی ہے، جو Mint کا اپنا codename ہے، اور Tailscale اس کے لیے کچھ شائع نہیں کرتا۔ اس کے بجائے Ubuntu base معلوم کریں۔

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

Ubuntu پر دونوں values ایک جیسی ہوتی ہیں۔ 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 پر upgrade کرنے کے بعد آپ کو /etc/apt/sources.list.d/tailscale.list یا تو commented out ملے گا، یا ایسی machine پر بھی noble دکھائے گا جو اب resolute ہے۔ اسے درست کرنے کے لیے نئے codename کے ساتھ دونوں curl commands دوبارہ چلائیں۔ یہ دونوں files کو overwrite کر دیں گی۔

تیسرا طریقہ timing ہے۔ نئی Ubuntu release کے بعد چند ہفتوں تک codename، Tailscale سے پہلے Canonical پر موجود ہوتا ہے۔ file میں پچھلی LTS release کا codename درج کرنے سے عموماً installation ہو جاتی ہے، کیونکہ ان packages کی dependencies کم ہوتی ہیں۔ لیکن اس صورت میں آپ پرانی release کے لیے بنائی گئی build چلا رہے ہوتے ہیں۔ apt policy tailscale سے تصدیق کریں کہ حقیقت میں کیا install ہوا ہے، اور اصل codename ظاہر ہونے کے بعد file کو دوبارہ درست codename پر منتقل کریں۔

keyring خالی ہے، اور اسے لکھنے والی command نے کچھ نہیں بتایا

یہ خاموشی سے ہوتا ہے، اور زیادہ تر مسائل کا اختتام بھی یہی ہوتا ہے۔ keyring command دوبارہ دیکھیں:

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

Shell دونوں programs چلنے سے پہلے پوری pipeline تیار کرتا ہے، اس لیے sudo tee فوراً keyring path کھول کر اسے zero bytes تک truncate کر دیتا ہے۔ اگر curl ناکام ہو جائے، اور -f اسے کسی بھی HTTP error پر ناکام بنائے، تو curl کچھ نہیں لکھتا اور nonzero status کے ساتھ بند ہو جاتا ہے۔ فائل zero bytes پر رہتی ہے۔ Pipeline کا exit status اس کی آخری command کا status ہوتا ہے، یعنی tee، جو کامیاب رہی۔ کچھ بھی print نہیں ہوتا، اور آپ اگلی command پر چلے جاتے ہیں، یہ سمجھ کر کہ key install ہو گئی ہے۔

جس command نے فائل بنائی ہے اسے نہیں، خود فائل کو check کریں۔

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

صحت مند keyring میں pub line اور uid line print ہوتی ہے، جو Tailscale کا نام بتاتی ہے۔ zero byte فائل میں gpg: no valid OpenPGP data found. print ہوتا ہے اور اس کے علاوہ کچھ نہیں ہوتا۔ اگر فائل میں HTML error page محفوظ ہو گئی ہو تو بھی یہی نتیجہ آتا ہے، اور اس پر head -c 80 چلانے سے binary key data کے بجائے web page کا آغاز دکھائی دیتا ہے۔

ایسے keyring کے ساتھ جس میں کوئی قابلِ استعمال key نہ ہو، sudo apt update index download کرتا ہے اور پھر اسے مسترد کر دیتا ہے۔ آپ کو W: GPG error line ملتی ہے، جس میں Tailscale repository اور اس کا suite درج ہوتا ہے، اس کے بعد The following signatures couldn't be verified because the public key is not available: NO_PUBKEY اور 16 character کا key id آتا ہے، اور اس کے نیچے error ہوتا ہے کہ repository signed نہیں ہے۔ apt آپ کو واضح طور پر بتا رہا ہے: اس نے index کامیابی سے download کیا، لیکن اس کے signature کی تصدیق نہیں کر سکا۔ یہ key کا مسئلہ ہے، network کا نہیں۔ اگر keyring فائل مکمل طور پر missing ہو تو پیغام پھر مختلف ہوتا ہے، اور Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg کے ذریعے path براہِ راست دکھاتا ہے۔

Key کو دو steps میں write کریں تاکہ failed download موجودہ درست 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

درمیانی line فیصلہ کن شرط ہے: اگر اس میں Tailscale uid print نہ ہو تو رک جائیں اور فائل copy نہ کریں۔ Mode 0644 اہم ہے، کیونکہ apt fetch اور verify کرنے کے لیے unprivileged _apt user پر آ جاتا ہے۔ اس لیے ایسا keyring جسے صرف root پڑھ سکتا ہو، apt استعمال نہیں کر سکتا۔

ایک ہی repository کو .list اور .sources فائل دونوں بیان کرتی ہیں

Ubuntu نے Ubuntu 24.10 میں اپنی sources کو deb822 format میں منتقل کیا، جہاں /etc/apt/sources.list، /etc/apt/sources.list.d/ubuntu.sources بن گیا۔ Tailscale اب بھی one line format شائع کرتا ہے۔ August 2026 میں جانچ کے وقت pkgs.tailscale.com سے download کرنے کے لیے کوئی .sources file موجود نہیں تھی: یہ URL 404 واپس کرتا ہے۔ لہذا اگر آپ کی machine پر tailscale.sources موجود ہے تو اسے آپ نے یا کسی guide نے دستی طور پر لکھا ہے، اور اگر tailscale.list بھی اب تک موجود ہے تو apt کے پاس اب اسی repository کی دو وضاحتیں موجود ہیں۔

ہلکی صورت میں ہر update پر warning دکھائی دیتی ہے:

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

سنگین صورت اس وقت پیش آتی ہے جب دونوں files مختلف keyring paths بیان کرتی ہیں، کیونکہ apt فیصلہ نہیں کر سکتا کہ repository کے لیے کون سی key معتبر ہے۔ یہ E: Conflicting values set for option Signed-By regarding source، پھر repository اور اس کی suite، پھر != کے درمیان موجود دونوں keyring paths دکھاتا ہے، اور اس کے بعد آگے بڑھنے سے انکار کر دیتا ہے:

E: The list of sources could not be read.

یہ خرابی ہر apt command کو روک دیتی ہے، صرف update کو نہیں، جب تک دونوں files میں سے ایک حذف نہ ہو جائے۔ یہی خرابی Ubuntu کی اپنی repositories کے ساتھ بھی ظاہر ہوتی ہے، اور deb822 migration کے بعد duplicate apt source error عمومی صورت کی وضاحت کرتا ہے۔

کچھ بھی حذف کرنے سے پہلے Tailscale کا ذکر کرنے والی ہر file تلاش کریں۔

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

ایک file رکھیں۔ دوسری کو ضائع کیے بغیر غیر فعال کرنے کے لیے اس کا نام تبدیل کریں: apt صرف ان files کو پڑھتا ہے جن کے اختتام پر .list یا .sources ہو، اس لیے tailscale.list.bak کو نظرانداز کر دیا جاتا ہے اور وہ reference کے لیے disk پر موجود رہتی ہے۔

deb822 source فائل درست طریقے سے لکھنا

اگر آپ نیا format استعمال کرنا چاہتے ہیں تو موجودہ فائل دوبارہ address ٹائپ کرنے کے بجائے اسے convert کریں، کیونکہ معمولی typo ہی اوپر بیان کردہ errors کی اصل وجہ بنتا ہے۔ حالیہ apt releases میں ایک converter شامل ہے جو .list files کو deb822 stanzas میں rewrite کرتا ہے اور signed-by option کو Signed-By کے طور پر منتقل کرتا ہے۔

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

Ubuntu 24.04 میں ایسا apt شامل ہے جو اس subcommand سے پہلے کا ہے، اس لیے help line فوراً بتا دیتی ہے کہ آپ کے پاس یہ سہولت موجود ہے یا نہیں۔ جہاں یہ موجود نہ ہو، وہاں پہلے سے disk پر موجود line سے stanza بنائیں، تاکہ base آپ کے keyboard کے بجائے vendor کی file سے حاصل ہو۔

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

یہ اس stanza کو print کرتا ہے جسے اس نے لکھا ہے، لہذا اگلے apt update سے پہلے آپ fields دوبارہ پڑھ کر تصدیق کر سکتے ہیں۔ ان میں سے چار کو تفصیل سے سمجھنا ضروری ہے، کیونکہ ہر ایک مختلف طریقے سے fail ہوتا ہے:

• URIs repository کے base پر رک جاتا ہے۔ اس میں dists/noble حصہ paste کرنے سے 404 آتا ہے، کیونکہ apt خود dists/<suite> شامل کرتا ہے اور dists/noble/dists/noble کے لیے request بھیجتا ہے۔
• Suites codename ہے، یعنی وہی value جو one-line format کے درمیان موجود تھی۔
• Signed-By keyring file کا absolute path لیتا ہے۔ اس کے نیچے armored key بھی inline کی جا سکتی ہے۔ اس صورت میں key کی ہر line کے آغاز میں ایک space ہونا چاہیے، اور key کے اندر ہر blank line کو single dot کے طور پر لکھنا چاہیے۔
• Enabled: no source کو delete کیے بغیر بند کر دیتا ہے۔ اسے واپس فعال کرنا rename کرنے کے مقابلے میں آسان ہے اور اگلے administrator کو سمجھانا بھی آسان رہتا ہے۔

Third-party repositories کے لیے ہر file میں ایک stanza رکھیں، اور اگر کبھی کئی stanzas ایک ہی file میں رکھیں تو ان کے درمیان ایک blank line دیں۔ Repository index اپنی architectures میں amd64 اور arm64 شامل کرتا ہے، اس لیے ARM VPS کے لیے اضافی Architectures field کی ضرورت نہیں۔

درمیانی proxy سے 403 موصول ہوتا ہے

چونکہ اس repository میں موجود نہ ہونے والے path کے لیے 404 آتا ہے، اس لیے 403 کا مطلب ہے کہ کسی اور سروس نے اس کی طرف سے جواب دیا ہے۔ پہلے apt کی اپنی configuration دیکھیں، کیونکہ وہاں set کیا گیا proxy، apt پر لاگو ہوتا ہے، آپ کے interactive 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

اس سے request line، apt کے بھیجے ہوئے headers، اور وہ proxy دکھائی دیتا ہے جس کے ذریعے apt نے connection قائم کیا، اگر کوئی proxy استعمال ہوا ہو۔ اسی URL پر سادہ curl کے نتیجے سے اس کا موازنہ کریں۔ اگر curl 200 واپس کرے اور apt 403 واپس کرے، تو دونوں requests میں ایسا فرق ہے جسے درمیانی network device اہم سمجھتی ہے۔ عام طور پر یہ فرق 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

اگر اس command سے 403 ملے جبکہ default curl سے 200 ملے، تو کوئی filtering device نام کی بنیاد پر apt کو مسترد کر رہی ہے۔ اصلاح اسی device پر کی جائے، آپ کے server پر نہیں۔ ایسا corporate proxy جو TLS کا معائنہ کرتا ہو، مختلف صورت پیدا کرتا ہے: apt status code کے بجائے certificate verification failure رپورٹ کرتا ہے، کیونکہ موصول ہونے والا certificate proxy نے جاری کیا ہوتا ہے، Tailscale کی certificate authority نے نہیں۔ Cloud egress firewall جو صرف Ubuntu mirrors کی اجازت دیتا ہو، دوسری عام وجہ ہے۔ اس صورت میں firewall پر pkgs.tailscale.com کی اجازت دیں۔

صرف IPv6 کے ذریعے outbound رسائی، اور وہ errors جو status codes نہیں ہیں

اگر apt کو کبھی HTTP response نہیں ملا تو ہر protocol کو الگ الگ test کریں۔

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 کو ترجیح دیتی ہے اور اس سرور کے پاس کام کرنے والا IPv6 path نہیں ہے۔ نظریے کی تصدیق کے لیے ایک بار IPv4 استعمال کرنے پر مجبور کریں:

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 پر مجبور کرنے سے کچھ درست نہیں ہوگا، کیونکہ traffic کو بھیجنے کے لیے کوئی IPv4 route موجود نہیں ہے۔ ایسی صورت میں provider کی طرف سے NAT64 کو DNS64 کے ساتھ استعمال کریں، یا ایسا proxy استعمال کریں جس کے پاس IPv4 address ہو۔ علامت یہ ہے کہ connect error میں IPv6 address کا نام آتا ہے؛ اس لیے اصل صورت حال curl -6 والی line سے واضح ہوتی ہے۔

متبادل طریقے اور ہر طریقے کی لاگت

وینڈر کی install script۔ curl -fsSL https://tailscale.com/install.sh | sh وہ command ہے جس کی Tailscale تشہیر کرتا ہے۔ Script پڑھنے سے معلوم ہوتا ہے کہ یہ /etc/os-release سے آپ کی distribution کا تعین کرتی ہے، پھر انہی دو paths، /usr/share/keyrings/tailscale-archive-keyring.gpg اور /etc/apt/sources.list.d/tailscale.list، کو انہی URLs سے لکھتی ہے جنہیں یہ guide درست کرتی رہی ہے۔ آپ کی توقعات کے لیے یہ بات اہم ہے: اگر کوئی proxy repository کو block کر رہا ہو تو یہ script اس رکاوٹ سے بچ کر کام نہیں کرتی۔ یہ کم output کے ساتھ اسی طرح fail ہوتی ہے۔ Download کی گئی script کو root کے طور پر shell میں pipe کرنا ایک سمجھوتا ہے، حل نہیں، کیونکہ آپ اس وقت server کی جانب سے واپس کیے جانے والے ہر مواد پر اعتماد کر رہے ہوتے ہیں اور جو کچھ چلایا گیا اس کی کوئی copy محفوظ نہیں رکھتے۔ اگر آپ یہ سمجھوتا کرتے ہیں تو اس کے نتائج کو پوری طرح سمجھ کر کریں:

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

Static binaries۔ یہی server pkgs.tailscale.com/stable کے static binaries section میں سادہ tarballs بھی publish کرتا ہے۔ August 2026 تک stable release 1.102.2 ہے اور 64 bit x86 file tailscale_1.102.2_amd64.tgz ہے۔ آپ tailscale client اور tailscaled daemon خود install کرتے ہیں اور daemon کی نگرانی بھی خود کرتے ہیں، اس لیے apt upgrade path موجود نہیں ہوتا اور ہر آئندہ update کے لیے download خود کرنا یاد رکھنا پڑتا ہے۔ یہ طریقہ air-gapped host پر، یا اس وقت مناسب ہے جب آپ کو ایک مخصوص version پر پابندی لگانی ہو۔

Ubuntu کا اپنا package۔ ایسا کوئی package موجود نہیں۔ Vendor repository configure کیے بغیر sudo apt install tailscale چلانے کا اختتام E: Unable to locate package tailscale پر ہوتا ہے، اور apt update کی کوئی بھی مقدار اس صورتحال کو تبدیل نہیں کرتی۔ اگر آپ دراصل Tailscale کے hosted server کے بجائے اپنے زیرِ انتظام coordination server چاہتے ہیں تو یہ الگ فیصلہ ہے: Headscale کو اپنے control server کے طور پر چلانا اس کا احاطہ کرتا ہے، جبکہ Tailscale اور plain WireGuard کا تقابل یہ واضح کرتا ہے کہ آیا آپ کو اس پورے نظام کی ضرورت ہے۔

پیکیج انسٹال ہو گیا، لیکن tailscaled شروع نہیں ہوگا

جب apt بغیر کسی مسئلے کے مکمل ہو جائے تو خرابی daemon کی طرف منتقل ہو جاتی ہے۔

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

ایسے VPS پر جو host kernel شیئر کرنے والی container virtualisation، مثلاً LXC یا OpenVZ، استعمال کرتا ہو، log میں /dev/net/tun کے موجود نہ ہونے سے متعلق ایک سطر ہوتی ہے۔ daemon کو tailscale0 interface بنانے کے لیے TUN device درکار ہوتی ہے، لیکن container کو یہ device فراہم نہیں کی گئی۔ اپنے provider سے container میں TUN فعال کرنے کو کہیں، یا KVM plan پر منتقل ہو جائیں جہاں آپ کو اپنا kernel ملتا ہے۔ KVM پر یہ اضافی setup کے بغیر کام کرتا ہے۔

اس کے بعد sudo tailscale up ایک login URL دکھاتا ہے، اور tailscale status کو 100.64.0.0/10 range میں آپ کی machine کا address دکھانا چاہیے۔ وہاں نظر آنے والی machine پر آپ مزید کام کر سکتے ہیں، خواہ اس کا مطلب اپنے VPS سے private subnet کا اشتہار دینا ہو یا VPS کو exit node کے طور پر استعمال کرنا۔

FAQ

apt یہ کیوں کہتا ہے کہ Tailscale repository signed نہیں ہے؟

کیونکہ apt نے repository index download کیا، لیکن /usr/share/keyrings/tailscale-archive-keyring.gpg کے خلاف اس کے signature کی تصدیق نہیں کر سکا۔ عام وجہ یہ ہوتی ہے کہ keyring صفر bytes کی ہے: sudo tee نے فائل کو truncate کر دیا، پھر curl کچھ download کیے بغیر ناکام ہو گیا، اور pipeline نے success report کی کیونکہ tee کامیاب ہوا تھا۔ gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg چلائیں۔ درست keyring میں pub line اور Tailscale کا نام دینے والی uid line ظاہر ہوتی ہے، جبکہ خالی یا خراب keyring gpg: no valid OpenPGP data found. ظاہر کرتی ہے۔ Key کو temporary file میں download کریں، وہیں اس کی جانچ کریں، پھر اسے mode 0644 کے ساتھ مطلوبہ جگہ پر copy کریں تاکہ _apt user اسے پڑھ سکے۔

Tailscale URLs میں Ubuntu کا کون سا codename لکھنا چاہیے؟

/etc/os-release سے UBUNTU_CODENAME کی value استعمال کریں۔ Ubuntu 24.04 پر یہ noble اور Ubuntu 26.04 پر resolute ہے۔ Ubuntu سے اخذ شدہ distribution پر lsb_release -cs استعمال نہ کریں۔ Linux Mint 22 پر یہ wilma ظاہر کرتا ہے، Tailscale اس نام کے تحت کچھ publish نہیں کرتا، اور apt کو dists/wilma/InRelease پر 404 ملتا ہے۔ کسی بھی editing سے پہلے curl -sS -o /dev/null -w '%{http_code}\n' کے ذریعے https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease سے index manually fetch کر کے اپنے انتخاب کی تصدیق کریں۔

کیا Tailscale install script کو shell میں pipe کر کے چلانا محفوظ ہے؟

یہ ایسا فیصلہ ہے جو سوچ سمجھ کر کرنا چاہیے۔ یہ script Tailscale کی طرف سے آتی ہے اور manual steps ہی انجام دیتی ہے: یہ /etc/os-release پڑھتی ہے، وہی keyring اور وہی /etc/apt/sources.list.d/tailscale.list لکھتی ہے، پھر package install کرتی ہے۔ اس کا نقصان یہ ہے کہ آپ root کے ساتھ اس وقت server جو کچھ return کرے، وہ چلاتے ہیں، اور اس کا کوئی record محفوظ نہیں رکھتے۔ اسے -o install.sh کے ذریعے download کریں، پڑھیں، پھر سہولت درکار ہو تو اسے چلائیں تاکہ یہ blind spot نہ رہے۔ Blocked repository کی صورت میں بھی یہ مدد نہیں کر سکتی، کیونکہ یہ وہی URLs استعمال کرتی ہے جو پہلے ہی ناکام ہو چکے ہیں۔

apt repository کے بغیر Ubuntu پر Tailscale کیسے install کروں؟

pkgs.tailscale.com پر شائع کردہ static tarballs استعمال کریں۔ August 2026 تک ان کا version 1.102.2 ہے اور amd64 file کا نام tailscale_1.102.2_amd64.tgz ہے۔ tailscale اور tailscaled programs خود install کریں اور daemon کو خود systemd کے تحت چلائیں۔ اس کا نقصان upgrades ہیں: نیا version حاصل کرنے کے لیے کوئی apt package نہیں ہوگا، اس لیے ہر update manually کرنا پڑے گا۔ Ubuntu کے archive میں اپنا کوئی tailscale package موجود نہیں، اس لیے vendor repository کے بغیر machine پر sudo apt install tailscale، E: Unable to locate package tailscale پر رک جاتا ہے۔