แก้ปัญหาติดตั้ง Tailscale บน Ubuntu จากข้อผิดพลาด apt

เหตุใดข้อผิดพลาดในการติดตั้ง Tailscale บน Ubuntu จึงเป็นข้อผิดพลาดของ apt

ข้อผิดพลาดในการติดตั้ง Tailscale บน Ubuntu เกือบทั้งหมดเกิดขึ้นก่อนที่โค้ดของ Tailscale จะเริ่มทำงาน แต่เป็นข้อผิดพลาดของ apt Ubuntu ไม่มีแพ็กเกจ tailscale ของตนเอง: เมื่อตรวจสอบกับ Ubuntu package archive ในเดือน October 2026 พบรายการที่ตรงกันเพียงไลบรารีตัวช่วยของ Go และ python3-tailscale ดังนั้น daemon จึงต้องมาจาก apt repository ของ Tailscale เองที่ pkgs.tailscale.com

การเพิ่ม repository ดังกล่าวจะเขียนไฟล์ 2 ไฟล์ ไฟล์หนึ่งระบุตำแหน่งของแพ็กเกจให้อยู่ใน apt อีกไฟล์เก็บ public key ที่ apt ใช้ตรวจสอบลายเซ็นของ repository index ความล้มเหลวเกือบทั้งหมดด้านล่างเกิดจากไฟล์ 2 ไฟล์นี้ไฟล์ใดไฟล์หนึ่งไม่ถูกต้อง หรือเกิดจากอุปกรณ์ระหว่าง apt กับ repository ปฏิเสธคำขอ

คำสั่งเหล่านี้เป็นคำสั่งที่ 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 คือ codename ของ Ubuntu 24.04 และปรากฏอยู่ใน URL ทั้ง 2 รายการ คำสั่งที่สองจะเขียนบรรทัดคอมเมนต์และบรรทัด deb 1 บรรทัดลงใน /etc/apt/sources.list.d/tailscale.list ส่วน cat จะแสดงเนื้อหาที่ถูกเขียนลงในไฟล์นั้นอย่างตรงตามจริง

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

ให้อ่านบรรทัด deb นี้เป็น address ที่มี 4 ฟิลด์ ได้แก่ 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 เดียว แล้วดาวน์โหลด URL นั้น: https://pkgs.tailscale.com/stable/ubuntu/dists/noble/InRelease หากคุณดาวน์โหลด URL นี้ด้วยตนเองได้ apt ก็จะดาวน์โหลดได้เช่นกัน นี่คือการวินิจฉัยทั้งหมด

อ่านข้อผิดพลาดของ apt ก่อนแก้ไขสิ่งใด

เรียกใช้การอัปเดตแยกต่างหาก เพื่อไม่ให้คำสั่งอื่นเลื่อนข้อผิดพลาดจนหายไปจากหน้าจอ

sudo apt update

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.

มี 2 สิ่งในผลลัพธ์นี้ที่ใช้กำหนดขั้นตอนถัดไป ได้แก่ status code และ URL เต็มในบรรทัด E: Failed to fetch อย่าคาดเดาจากบรรทัดสรุปด้านล่าง ให้คัดลอก URL แล้วสอบถามเซิร์ฟเวอร์โดยตรง

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

คำสั่งนี้จะแสดง 200 สำหรับ codename ที่ Tailscale เผยแพร่ Checked ใน October 2026 แล้ว noble จะแสดง signed index ที่มี Origin: Tailscale และ Codename: noble อยู่ภายใน ให้แทนที่ noble ด้วย codename จากข้อผิดพลาดของคุณเอง แล้วเรียกใช้อีกครั้ง หาก curl ได้ 200 ขณะที่ apt ได้ข้อผิดพลาด แสดงว่า repository ทำงานปกติ และปัญหาอยู่ในการตั้งค่าของ apt เอง

รหัสสถานะบอกอะไรคุณ

• 404 Not Found หมายความว่า repository ไม่มีไฟล์ที่ path ดังกล่าว สำหรับ pkgs.tailscale.com ค่านั้นเกือบทุกครั้งคือ codename ที่อยู่ใน URL
• 403 Forbidden หมายความว่ามีบางสิ่งตอบกลับและปฏิเสธคำขอ ณ October 2026 repository นี้ส่งคืน 404 สำหรับ path ที่ไม่มีอยู่ ดังนั้น 403 จึงชี้ไปที่ proxy, filtering appliance หรือ firewall ที่อยู่ระหว่างเซิร์ฟเวอร์ของคุณกับ Tailscale
• 401 Unauthorized หรือ 407 Proxy Authentication Required หมายความว่า proxy ต้องการ credentials ที่ apt ไม่ได้ส่งไป
• connect error หรือ name resolution error หมายความว่ายังไม่มีการสื่อสารผ่าน HTTP เกิดขึ้นเลย ให้ข้ามไปยังส่วน IPv6

codename ใน URL ไม่มีการเผยแพร่โดย Tailscale

Tailscale สร้าง directory แยกตาม codename ของ Ubuntu แต่ละรุ่น หากระบุ codename ที่ไม่มีอยู่ ระบบจะตอบกลับ 404 เพราะบนเซิร์ฟเวอร์ไม่มี dists/<codename> สำหรับให้บริการ รายการของผู้พัฒนาเองที่ pkgs.tailscale.com/stable แสดงว่ามีรุ่นใดบ้าง ในเดือน October 2026 รายการดังกล่าวเริ่มตั้งแต่ 16.04 จนถึง resolute ซึ่งคือ Ubuntu 26.04

สาเหตุที่มักทำให้ได้ codename ผิดคือ lsb_release -cs บน distribution ที่พัฒนาต่อยอดจาก Ubuntu แต่ไม่ใช่ Ubuntu บน Linux Mint 22 คำสั่งดังกล่าวจะแสดง wilma ซึ่งเป็น codename ของ Mint เอง และ Tailscale ไม่ได้เผยแพร่แพ็กเกจสำหรับค่านี้ ให้ตรวจสอบ Ubuntu base แทน

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

บน Ubuntu ค่าทั้งสองจะเหมือนกัน แต่บน derivative ค่า VERSION_CODENAME คือชื่อของ derivative และ UBUNTU_CODENAME คือ release ของ Ubuntu ที่ใช้เป็นฐาน ให้ใช้ UBUNTU_CODENAME ใน URL ทั้งสองรายการ

อีกสาเหตุคือการอัปเกรด release เครื่องมืออัปเกรด Ubuntu จะปิดใช้งาน source ของ third-party ขณะทำงาน ดังนั้นหลังจาก อัปเกรด Ubuntu 24.04 เป็น 26.04 คุณอาจพบว่า /etc/apt/sources.list.d/tailscale.list ถูก comment ไว้ หรือยังระบุ noble อยู่ ทั้งที่เครื่องอัปเกรดเป็น resolute แล้ว ให้แก้ไขโดยเรียกใช้คำสั่ง curl 2 คำสั่งอีกครั้งด้วย codename ใหม่ ซึ่งจะเขียนทับไฟล์ทั้งสองรายการ หากการอัปเกรดหยุดกลางคัน และ dpkg แจ้งว่ามีแพ็กเกจที่ตั้งค่าไม่เสร็จหลายรายการ ไม่ใช่เฉพาะ repository นี้ ให้ กู้คืนการอัปเกรด release ที่ล้มเหลว ก่อน เพราะการแก้ไข tailscale.list จะไม่คงอยู่บนระบบที่ apt ไม่สามารถตั้งค่าให้เสร็จได้

สาเหตุที่สามคือช่วงเวลา ในช่วงหลายสัปดาห์หลัง Ubuntu release ใหม่ออก codename อาจมีอยู่ที่ Canonical แล้ว แต่ยังไม่มีที่ Tailscale การเปลี่ยนไฟล์ให้ใช้ codename ของ LTS รุ่นก่อนมักทำให้ติดตั้งได้ เพราะแพ็กเกจเหล่านี้มี dependency ไม่มาก แต่หมายความว่าคุณกำลังใช้ build ที่สร้างมาสำหรับ release รุ่นเก่า ตรวจสอบสิ่งที่ติดตั้งจริงด้วย 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 จะสร้าง pipeline ทั้งหมดก่อนที่โปรแกรมใดจะเริ่มทำงาน ดังนั้น sudo tee จะเปิด path ของ keyring และตัดไฟล์ให้เหลือ 0 ไบต์ทันที หาก curl ทำงานล้มเหลว และ -f ทำให้ curl ล้มเหลวเมื่อเกิด HTTP error curl จะไม่เขียนข้อมูลใด ๆ และจบการทำงานด้วยสถานะที่ไม่ใช่ 0 ไฟล์จึงยังมีขนาด 0 ไบต์ สถานะการจบการทำงานของ pipeline จะเป็นสถานะของคำสั่งสุดท้าย ซึ่งคือ tee และคำสั่งนี้ทำงานสำเร็จ จึงไม่มีข้อความใดแสดงออกมา และคุณก็ไปยังคำสั่งถัดไปโดยเข้าใจว่าติดตั้ง key แล้ว

ให้ตรวจสอบไฟล์ ไม่ใช่ตรวจสอบคำสั่งที่สร้างไฟล์นั้น

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

keyring ที่ใช้งานได้จะแสดงบรรทัด pub และบรรทัด uid ที่ระบุชื่อ Tailscale ไฟล์ขนาด 0 ไบต์จะแสดง gpg: no valid OpenPGP data found. และไม่มีข้อความอื่น ไฟล์ที่ได้รับ HTML error page ก็จะแสดงผลแบบเดียวกัน และเมื่อใช้ head -c 80 กับไฟล์นั้น จะแสดงจุดเริ่มต้นของ web page แทนข้อมูล key แบบไบนารี

เมื่อ keyring ไม่มี key ที่ใช้งานได้ sudo apt update จะดาวน์โหลด index แล้วปฏิเสธ index นั้น คุณจะเห็นบรรทัด W: GPG error ที่ระบุชื่อ Tailscale repository และ suite ของ repository ตามด้วยข้อความ The following signatures couldn't be verified because the public key is not available: NO_PUBKEY และ key id ความยาว 16 ตัวอักษร จากนั้นจะมี error ระบุว่า repository ไม่ได้ลงนาม ให้สังเกตสิ่งที่ apt กำลังแจ้ง: apt ดาวน์โหลด index ได้สำเร็จ แต่ไม่สามารถตรวจสอบลายเซ็นได้ ปัญหานี้เกี่ยวกับ key ไม่ใช่ปัญหา network หากไม่มีไฟล์ keyring อยู่เลย ข้อความจะแตกต่างออกไป และจะระบุ path โดยตรงด้วย Could not open file /usr/share/keyrings/tailscale-archive-keyring.gpg

ให้เขียน key เป็น 2 ขั้นตอน เพื่อไม่ให้การดาวน์โหลดที่ล้มเหลวทำลาย 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

บรรทัดตรงกลางคือจุดตรวจสอบ หากไม่มีการแสดง Tailscale uid ให้หยุดและอย่าคัดลอกไฟล์ Mode 0644 มีความสำคัญ เพราะ apt จะลดสิทธิ์ไปใช้ผู้ใช้ที่ไม่มีสิทธิ์ระดับสูงคือ _apt เพื่อดาวน์โหลดและตรวจสอบ ดังนั้น keyring ที่อ่านได้เฉพาะ root จึงเป็น keyring ที่ apt ไม่สามารถใช้งานได้

ทั้งไฟล์ .list และไฟล์ .sources อธิบาย repository เดียวกัน

Ubuntu เปลี่ยน source ของตนเองเป็นรูปแบบ deb822 ใน Ubuntu 24.04 LTS โดย /etc/apt/sources.list กลายเป็น /etc/apt/sources.list.d/ubuntu.sources ส่วน Tailscale ยังคงเผยแพร่รูปแบบบรรทัดเดียว เมื่อตรวจสอบในเดือน October 2026 ไม่พบไฟล์ .sources ให้ดาวน์โหลดจาก pkgs.tailscale.com เนื่องจาก URL ดังกล่าวตอบกลับเป็น 404 ดังนั้น หากเครื่องของคุณมี tailscale.sources แสดงว่าคุณหรือคู่มือบางฉบับสร้างไฟล์นี้ขึ้นเอง และหากยังมี tailscale.list อยู่ด้วย ขณะนี้ apt จะมีคำอธิบาย repository เดียวกันซ้ำ 2 แห่ง

กรณีที่ไม่รุนแรงจะแสดงคำเตือนทุกครั้งที่อัปเดต:

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

กรณีรุนแรงเกิดขึ้นเมื่อไฟล์ทั้งสองระบุ path ของ keyring ต่างกัน เนื่องจาก apt ไม่สามารถตัดสินใจได้ว่าจะใช้ key ใดกับ repository นี้ apt จะแสดง E: Conflicting values set for option Signed-By regarding source ตามด้วย repository และ suite ของ repository นั้น จากนั้นแสดง path ของ keyring ทั้งสองโดยมี != คั่นกลาง แล้วปฏิเสธที่จะดำเนินการต่อ:

E: The list of sources could not be read.

ปัญหานี้จะบล็อกทุกคำสั่งของ apt ไม่ใช่เฉพาะคำสั่ง update จนกว่าไฟล์ใดไฟล์หนึ่งจะถูกนำออก ปัญหาเดียวกันนี้เกิดกับ repository ของ Ubuntu เอง และ ข้อผิดพลาด duplicate apt source หลังการย้ายไปใช้ deb822 อธิบายกรณีทั่วไปโดยละเอียด

ค้นหาไฟล์ทุกไฟล์ที่กล่าวถึง Tailscale ก่อนลบไฟล์ใด ๆ

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

เก็บไฟล์ไว้เพียงไฟล์เดียว หากต้องการปิดใช้งานอีกไฟล์โดยไม่ลบ ให้เปลี่ยนชื่อไฟล์นั้น apt จะอ่านเฉพาะไฟล์ที่ลงท้ายด้วย .list หรือ .sources ดังนั้น tailscale.list.bak จะถูกข้ามและยังคงอยู่บนดิสก์เพื่อใช้อ้างอิง

การเขียนไฟล์ source แบบ deb822 ให้ถูกต้อง

หากต้องการใช้รูปแบบใหม่ ให้แปลงไฟล์ที่มีอยู่แล้วแทนการพิมพ์ที่อยู่ repository ใหม่ เพราะการพิมพ์ผิดตรงนั้นเป็นสาเหตุโดยตรงของข้อผิดพลาดข้างต้น apt รุ่นล่าสุดมีตัวแปลงที่เขียนไฟล์ .list ใหม่เป็น stanza แบบ deb822 และย้ายตัวเลือก signed-by ไปเป็น Signed-By

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

Ubuntu 24.04 มาพร้อม apt ที่เก่ากว่า subcommand ดังกล่าว ดังนั้นบรรทัด help จะบอกได้ทันทีว่า apt ที่ใช้อยู่รองรับหรือไม่ หากไม่รองรับ ให้สร้าง stanza จากบรรทัดที่มีอยู่ในไฟล์บนดิสก์ เพื่อให้ค่า base มาจากไฟล์ของ vendor ไม่ใช่จากการพิมพ์ด้วยแป้นพิมพ์

. /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 ที่เขียนขึ้นมา คุณจึงตรวจสอบ fields ได้ก่อน apt update ถัดไป มี 4 fields ที่ควรทำความเข้าใจโดยละเอียด เพราะแต่ละ field ทำให้เกิดข้อผิดพลาดคนละแบบ:

• URIs ต้องลงท้ายที่ base ของ repository การนำส่วน dists/noble ไปต่อท้ายจะทำให้เกิด 404 เพราะ apt จะเติม dists/<suite> เอง แล้วร้องขอ dists/noble/dists/noble
• Suites คือ codename ซึ่งต้องเป็นค่าเดียวกับที่อยู่ตรงกลางของรูปแบบบรรทัดเดียว
• Signed-By รับ absolute path ไปยังไฟล์ keyring และยังรองรับ armored key ที่ใส่ไว้ใต้ field นี้โดยตรง โดยต้องเยื้องทุกบรรทัดของ key ด้วยช่องว่าง 1 ตัว และเขียนบรรทัดว่างทุกบรรทัดภายใน key เป็นจุดเดี่ยว
• Enabled: no ปิด source โดยไม่ลบออก จึงย้อนกลับได้ง่ายกว่าการเปลี่ยนชื่อไฟล์ และอธิบายให้ผู้ดูแลคนถัดไปเข้าใจได้ง่ายกว่า

ให้ใช้ 1 stanza ต่อ 1 ไฟล์สำหรับ repository ของ third-party และเว้นบรรทัดว่างระหว่าง stanza หากเก็บหลาย stanza ไว้ในไฟล์เดียว ดัชนีของ repository แสดง amd64 และ arm64 อยู่ในรายการ architectures ดังนั้น ARM VPS จึงไม่ต้องมี field Architectures เพิ่มเติม

พร็อกซีตรงกลางตอบกลับ 403

เนื่องจาก path นี้ไม่มีอยู่ใน repository การตอบกลับ 403 จึงหมายความว่ามีบางอย่างตอบกลับแทน repository ให้เริ่มตรวจสอบ configuration ของ apt เองก่อน เพราะ proxy ที่กำหนดไว้ที่นั่นจะมีผลกับ 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

คำสั่งนี้จะแสดง request line, headers ที่ apt ส่ง และ proxy ที่เชื่อมต่อผ่าน หากมี เปรียบเทียบกับการใช้ curl แบบปกติกับ URL เดียวกัน หาก curl ตอบกลับ 200 แต่ apt ตอบกลับ 403 แสดงว่า request ทั้งสองแตกต่างกันในส่วนที่อุปกรณ์ระหว่างทางให้ความสำคัญ โดยตัวเลือกที่พบบ่อยคือ 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 ตามชื่อ การแก้ไขต้องทำที่อุปกรณ์นั้น ไม่ใช่ที่เซิร์ฟเวอร์ของคุณ corporate proxy ที่ตรวจสอบ TLS จะมีพฤติกรรมแตกต่างออกไปอีก โดย apt จะแจ้งข้อผิดพลาดในการตรวจสอบ certificate แทนการรายงาน status code เพราะ certificate ที่ได้รับออกโดย proxy ไม่ใช่โดย certificate authority ของ Tailscale อีกสาเหตุที่พบบ่อยคือ cloud egress firewall ที่อนุญาตเฉพาะ Ubuntu mirror และในกรณีนี้ต้องแก้ไขโดยอนุญาต pkgs.tailscale.com บน firewall

Egress ที่ใช้ IPv6 เท่านั้น และข้อผิดพลาดที่ไม่ใช่ status code

หาก 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 ค้างหรือรายงาน Network is unreachable แสดงว่า apt ล้มเหลวเพราะ resolver library เลือกใช้ IPv6 ก่อน และเครื่องไม่มีเส้นทาง IPv6 ที่ใช้งานได้ ให้บังคับการทำงาน 1 ครั้งให้ใช้ IPv4 เพื่อยืนยันสาเหตุนี้:

sudo apt -o Acquire::ForceIPv4=true update

หากการอัปเดตสำเร็จ ให้ตั้งค่าเป็นการถาวร

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

ควรพิจารณากรณีตรงข้ามด้วย ใน VPS ที่ไม่มี IPv4 address เลย การบังคับใช้ IPv4 ไม่ช่วยแก้ปัญหา เพราะไม่มี IPv4 route ให้บังคับ network traffic ไปใช้ กรณีนี้ต้องใช้ NAT64 ร่วมกับ DNS64 จาก provider หรือใช้ proxy ที่มี IPv4 address อาการคือ connect error ที่ระบุ IPv6 address ดังนั้นบรรทัด curl -6 คือบรรทัดที่แสดงสาเหตุที่แท้จริง

ทางเลือกสำรองและต้นทุนของแต่ละทางเลือก

สคริปต์ติดตั้งจากผู้จำหน่าย curl -fsSL https://tailscale.com/install.sh | sh คือคำสั่งที่ Tailscale แนะนำ เมื่ออ่านสคริปต์จะพบว่าสคริปต์ตรวจพบ distribution ของคุณจาก /etc/os-release แล้วเขียน path เดิม 2 รายการที่คู่มือนี้กำลังแก้ไขอยู่ ได้แก่ /usr/share/keyrings/tailscale-archive-keyring.gpg และ /etc/apt/sources.list.d/tailscale.list โดยดึงจาก URL เดิม ดังนั้นควรตั้งความคาดหวังให้ถูกต้อง: วิธีนี้ไม่ได้หลีกเลี่ยง repository ที่ proxy กำลังบล็อกอยู่ แต่จะล้มเหลวในลักษณะเดียวกันและแสดงข้อมูลน้อยกว่า การส่งสคริปต์ที่ดาวน์โหลดมาเข้า shell ในฐานะ root เป็นการแลกเปลี่ยน ไม่ใช่วิธีแก้ เพราะคุณกำลังไว้วางใจสิ่งที่เซิร์ฟเวอร์ส่งกลับมาในขณะนั้น และจะไม่มีสำเนาของสิ่งที่ถูกเรียกใช้ หากยอมรับการแลกเปลี่ยนนี้ ควรทำโดยเข้าใจความเสี่ยงอย่างชัดเจน:

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

ไบนารีแบบ static เซิร์ฟเวอร์เดียวกันเผยแพร่ tarball แบบ plain ไว้ในส่วน static binaries ของ pkgs.tailscale.com/stable ณ เดือน October 2026 รุ่น stable คือ 1.102.4 และไฟล์ x86 แบบ 64 bit คือ tailscale_1.102.4_amd64.tgz คุณต้องวาง client tailscale และ daemon tailscaled ด้วยตนเอง รวมถึงควบคุมการทำงานของ daemon ด้วยตนเอง จึงไม่มี path apt upgrade และการอัปเดตในอนาคตทุกครั้งจะเป็นการดาวน์โหลดที่คุณต้องจำไว้ว่าต้องทำ วิธีนี้เหมาะกับ host ที่แยกออกจาก network หรือกรณีที่ต้องตรึงไว้ที่ version ใด version หนึ่งโดยเฉพาะ

แพ็กเกจของ Ubuntu เอง ไม่มีแพ็กเกจดังกล่าว การเรียกใช้ sudo apt install tailscale โดยไม่ได้กำหนดค่า repository ของผู้จำหน่ายจะจบลงที่ E: Unable to locate package tailscale และไม่ว่า apt update มากเพียงใดก็ไม่ทำให้ผลลัพธ์เปลี่ยน หากสิ่งที่คุณต้องการจริง ๆ คือเซิร์ฟเวอร์ coordination ที่คุณควบคุมเองแทนเซิร์ฟเวอร์ที่ Tailscale ให้บริการ นั่นเป็นการตัดสินใจอีกเรื่องหนึ่ง: การเรียกใช้ Headscale เป็น control server ของคุณเอง อธิบายวิธีดังกล่าว และ การเปรียบเทียบระหว่าง Tailscale กับ WireGuard แบบ plain อธิบายว่าคุณจำเป็นต้องใช้โครงสร้างนี้หรือไม่

ติดตั้งแพ็กเกจแล้ว แต่ tailscaled ไม่เริ่มทำงาน

เมื่อ apt ทำงานได้ตามปกติแล้ว ปัญหาจะย้ายไปอยู่ที่ daemon

systemctl status tailscaled
sudo journalctl -u tailscaled -n 50

บน VPS ที่ใช้ container virtualisation ซึ่งแชร์ kernel ของโฮสต์ เช่น LXC หรือ OpenVZ log จะมีข้อความเกี่ยวกับ /dev/net/tun ที่ไม่มีอยู่ daemon ต้องใช้ TUN device เพื่อสร้าง interface tailscale0 แต่ container ไม่ได้รับ device นี้ ขอให้ผู้ให้บริการเปิดใช้ TUN ใน container หรือเปลี่ยนไปใช้แผน KVM ซึ่งมี kernel ของตนเอง บน KVM จะทำงานได้โดยไม่ต้องตั้งค่าเพิ่มเติม

หลังจากนั้น sudo tailscale up จะแสดง URL สำหรับเข้าสู่ระบบ และ tailscale status ควรแสดงรายการเครื่องของคุณพร้อม address ในช่วง 100.64.0.0/10 เครื่องที่ปรากฏในรายการนี้เป็นเครื่องที่นำไปต่อยอดได้ ไม่ว่าจะเป็น การประกาศ private subnet จาก VPS ของคุณ หรือ การใช้ VPS เป็น exit node

FAQ

เหตุใด apt จึงแจ้งว่า repository ของ Tailscale ไม่มีลายเซ็น

เนื่องจาก apt ดาวน์โหลดดัชนีของ repository แล้วไม่สามารถตรวจสอบลายเซ็นกับ /usr/share/keyrings/tailscale-archive-keyring.gpg ได้ สาเหตุที่พบบ่อยคือ keyring มีขนาดเป็นศูนย์ไบต์: sudo tee ทำให้ไฟล์ถูกตัดขนาดก่อนที่ curl จะดาวน์โหลดข้อมูลใด ๆ ได้ และ pipeline รายงานว่าสำเร็จเพราะ tee ทำงานสำเร็จ ให้เรียกใช้ gpg --show-keys /usr/share/keyrings/tailscale-archive-keyring.gpg keyring ที่ใช้งานได้จะแสดงบรรทัด pub และบรรทัด uid ที่ระบุชื่อ Tailscale ส่วน keyring ที่ว่างเปล่าหรือเสียหายจะแสดง gpg: no valid OpenPGP data found. ให้ดาวน์โหลด key ไปยังไฟล์ชั่วคราว ตรวจสอบไฟล์นั้น แล้วคัดลอกไปยังตำแหน่งจริงด้วย mode 0644 เพื่อให้ผู้ใช้ _apt อ่านได้

ควรใส่ Ubuntu codename ใดใน URL ของ Tailscale

ใช้ค่าของ UBUNTU_CODENAME จาก /etc/os-release ซึ่งมีค่าเป็น noble บน Ubuntu 24.04 และ resolute บน Ubuntu 26.04 อย่าใช้ lsb_release -cs บน distribution ที่พัฒนาต่อยอดจาก Ubuntu: บน Linux Mint 22 คำสั่งนี้จะแสดง wilma, Tailscale ไม่มีแพ็กเกจภายใต้ชื่อนั้น และ apt จะแจ้ง 404 บน dists/wilma/InRelease ยืนยันค่าที่เลือกก่อนแก้ไขสิ่งใด โดยดาวน์โหลดดัชนีด้วยตนเองด้วย curl -sS -o /dev/null -w '%{http_code}\n' จาก https://pkgs.tailscale.com/stable/ubuntu/dists/<codename>/InRelease

การรันสคริปต์ติดตั้ง Tailscale ที่ pipe เข้า shell ปลอดภัยหรือไม่

ควรพิจารณาความเสี่ยงนี้อย่างตั้งใจ สคริปต์มาจาก Tailscale และทำงานเช่นเดียวกับขั้นตอนแบบ manual คืออ่าน /etc/os-release, เขียน keyring เดียวกันและ /etc/apt/sources.list.d/tailscale.list เดียวกัน แล้วติดตั้งแพ็กเกจ ข้อแลกเปลี่ยนคือคุณจะรันทุกสิ่งที่เซิร์ฟเวอร์ส่งกลับมาในขณะนั้นด้วยสิทธิ์ root และจะไม่มีสำเนาบันทึกสคริปต์นั้น ให้ดาวน์โหลดด้วย -o install.sh อ่านสคริปต์ก่อน แล้วจึงรันหากต้องการความสะดวกโดยไม่มองข้ามความเสี่ยง วิธีนี้ไม่ช่วยหาก repository ถูกบล็อก เนื่องจากสคริปต์ใช้ URL เดียวกับที่ล้มเหลวอยู่แล้ว

จะติดตั้ง Tailscale บน Ubuntu โดยไม่ใช้ apt repository ได้อย่างไร

ใช้ static tarball ที่เผยแพร่บน pkgs.tailscale.com ซึ่ง ณ เดือน October 2026 อยู่ที่ version 1.102.4 และมีไฟล์ amd64 ชื่อ tailscale_1.102.4_amd64.tgz คุณต้องติดตั้งโปรแกรม tailscale และ tailscaled ด้วยตนเอง และเรียกใช้ daemon ภายใต้ systemd ด้วยตนเอง ข้อแลกเปลี่ยนคือการอัปเกรด: ไม่มีแพ็กเกจ apt สำหรับดึง version ใหม่ ดังนั้นการอัปเดตแต่ละครั้งต้องทำด้วยตนเอง archive ของ Ubuntu ไม่มีแพ็กเกจ tailscale ของตนเอง ดังนั้น sudo apt install tailscale บนเครื่องที่ไม่มี vendor repository จะหยุดที่ E: Unable to locate package tailscale