วิธีตั้งค่า Tailscale subnet router บน VPS อย่างละเอียด

หน้าที่ของ Tailscale subnet router

Tailscale subnet router คือเครื่องคอมพิวเตอร์หนึ่งเครื่องที่ทำหน้าที่ประกาศช่วงหมายเลข IP ภายในทั้งหมดให้แก่ tailnet ของคุณ เพื่อให้อุปกรณ์ทุกเครื่องใน tailnet สามารถเข้าถึงหมายเลข IP ในช่วงดังกล่าวได้แม้ว่าอุปกรณ์เหล่านั้นจะไม่ได้ติดตั้ง Tailscale ไว้ก็ตาม tailnet คือเครือข่าย Tailscale ส่วนตัวของคุณ ซึ่งประกอบด้วยชุดอุปกรณ์ที่ลงชื่อเข้าใช้ด้วยบัญชีหรือองค์กรเดียวกัน ส่วน exit node คือฟีเจอร์ที่มักถูกสับสนกับ subnet router แต่มีหน้าที่ตรงกันข้าม โดย exit node จะส่งทราฟฟิกทั้งหมดของอุปกรณ์ออกผ่าน VPS ทำให้ VPS กลายเป็นเส้นทางออกสู่เครือข่ายอินเทอร์เน็ตสาธารณะสำหรับอุปกรณ์นั้น

อธิบายได้ประโยคละหนึ่งใจความสำคัญ Subnet router ช่วยให้เครือข่ายภายในหนึ่งเครือข่ายสามารถเข้าถึงได้จาก tailnet ส่วน exit node เปลี่ยนจุดที่ทราฟฟิกสาธารณะของคุณใช้เชื่อมต่อออกสู่อินเทอร์เน็ต หากคุณต้องการใช้งาน exit node ให้ศึกษา วิธีการรัน Tailscale exit node บน VPS แทน ทั้งสองอย่างนี้ใช้ flag ที่แยกจากกัน และ VPS หนึ่งเครื่องสามารถทำหน้าที่ทั้งสองอย่างพร้อมกันได้ แต่ทั้งสองฟีเจอร์แก้ปัญหาคนละประเภทและมีสาเหตุความล้มเหลวที่แตกต่างกัน

เมื่อ VPS จำเป็นต้องใช้ subnet router

กรณีที่พบบ่อยคือเครือข่ายส่วนตัวที่ผู้ให้บริการจัดเตรียมไว้ให้ VPS ของคุณจะมีที่อยู่สาธารณะและอินเทอร์เฟซที่สองบนเซกเมนต์ส่วนตัว ในขณะที่เซิร์ฟเวอร์อื่นบนเซกเมนต์นั้นไม่มีที่อยู่สาธารณะเลย เช่น ฐานข้อมูลที่ 10.0.0.20 หรือเป้าหมายสำหรับสำรองข้อมูลที่ 10.0.0.30 ให้ติดตั้ง Tailscale บน VPS หนึ่งเครื่อง ประกาศเส้นทาง 10.0.0.0/24 แล้วแล็ปท็อปของคุณจะสามารถเข้าถึงที่อยู่ส่วนตัวเหล่านั้นได้โดยตรง โดยไม่ต้องเปลี่ยนแปลงการตั้งค่าอื่นใดบนเซกเมนต์นั้น และฐานข้อมูลก็ยังคงไม่มีที่อยู่สาธารณะเช่นเดิม

อีกกรณีหนึ่งคือเครือข่ายที่อยู่ฝั่งตรงข้ามของ VPS เช่น LAN (local area network) ในบ้านหรือสำนักงานที่อยู่หลังเราเตอร์ของตนเอง หรือกลุ่มอุปกรณ์ที่ไม่สามารถรัน Tailscale ได้เลย เช่น managed switch หรือ NAS รุ่นเก่าที่มี firmware แบบล็อกไว้ ในกรณีนี้ เครื่อง Linux เครื่องหนึ่งบนเครือข่ายนั้นจะทำหน้าที่เป็น subnet router ให้กับอุปกรณ์อื่นทั้งหมดที่อยู่บนเครือข่ายเดียวกัน

ทั้งสองกรณีมีข้อกำหนดร่วมกันประการหนึ่งคือ subnet router จะต้องสามารถเข้าถึงช่วงเครือข่ายที่ประกาศไว้ได้อยู่แล้ว โดยใช้ตารางเส้นทาง (routing table) และไฟร์วอลล์ของตนเอง Tailscale ไม่ได้เป็นผู้สร้างการเชื่อมต่อนั้น แต่ทำหน้าที่ส่งผ่านทราฟฟิกไปยังเราเตอร์และส่งต่อให้ kernel เป็นผู้จัดการการส่งต่อข้อมูลต่อไป

ติดตั้ง Tailscale และตรวจสอบเส้นทางเครือข่ายภายในก่อน

curl -fsSL https://tailscale.com/install.sh | sh

สคริปต์จะตรวจหา distribution เพิ่ม package repository ของ Tailscale ติดตั้งคำสั่ง tailscale และ daemon tailscaled จากนั้นจึงเปิดใช้งาน service ให้ยืนยันผลด้วย systemctl is-active tailscaled ซึ่งควรแสดงผลลัพธ์เป็น active

ก่อนดำเนินการขั้นตอนอื่น ให้ตรวจสอบว่า VPS สามารถเข้าถึงเครือข่ายที่คุณต้องการประกาศใช้งานได้จริง

ip route show
ping -c3 10.0.0.20

ip route show ต้องแสดงช่วง IP ภายในบนอินเทอร์เฟซจริง เช่น 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5 หากการ ping ล้มเหลวในขั้นตอนนี้บนตัวเราเตอร์เอง จะไม่มี flag ใดของ Tailscale ที่แก้ไขปัญหานี้ได้ สาเหตุเกิดจากการตั้งค่าเครือข่ายของ VPS หรือ firewall บนโฮสต์ปลายทาง ให้แก้ไขจุดนี้ก่อนเนื่องจากการทดสอบในขั้นตอนถัดไปทั้งหมดขึ้นอยู่กับความสำเร็จของขั้นตอนนี้

เปิดใช้งาน IP forwarding และทำให้การตั้งค่าคงอยู่หลังรีบูต

เครื่อง Linux จะทิ้งแพ็กเก็ตทั้งหมดที่ไม่ได้ส่งมาถึงตัวมันเองหากไม่ได้เปิดใช้งานการส่งต่อ (forwarding) การส่งต่อแพ็กเก็ตของเครื่องอื่นเป็นหน้าที่หลักของ subnet router ดังนั้นขั้นตอนนี้จึงเป็นสิ่งที่ขาดไม่ได้

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

ตรวจสอบสถานะด้วย sysctl net.ipv4.ip_forward ซึ่งควรแสดงผลลัพธ์เป็น net.ipv4.ip_forward = 1

ผู้ใช้งานมักทำขั้นตอนนี้สำเร็จเพียงครึ่งเดียว การใช้ sudo sysctl -w net.ipv4.ip_forward=1 จะเห็นผลทันทีแต่จะหายไปเมื่อรีบูตเครื่อง ทำให้ subnet router ทำงานได้ปกติหลายสัปดาห์แล้วหยุดทำงานในเช้าวันถัดมาหลังจากรีบูตเพื่ออัปเกรด kernel ส่วนที่น่าสับสนคือไม่มีสัญญาณบ่งบอกว่าระบบขัดข้อง tailscale status ยังคงแสดงสถานะว่าโหนดออนไลน์อยู่, admin console ยังคงแสดงว่าเส้นทาง (route) ได้รับการอนุมัติ และฝั่งไคลเอนต์ยังคงติดตั้งเส้นทางนั้นไว้ แพ็กเก็ตจะถูกส่งมาถึง VPS แต่ kernel จะทิ้งแพ็กเก็ตเหล่านั้นโดยไม่บันทึก log ใดๆ การเขียนค่าลงใน /etc/sysctl.d/99-tailscale.conf คือสิ่งที่ทำให้การตั้งค่ากลับมาใช้งานได้อีกครั้งหลังรีบูต

หากคุณประกาศเส้นทาง (advertise routes) ในขณะที่ยังปิด forwarding อยู่ tailscale up จะแจ้งเตือนคุณในขณะนั้น โดยมีข้อความใกล้เคียงกับ Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. โปรดอ่านผลลัพธ์ของคำสั่งนั้นแทนการเลื่อนผ่านไป

การประกาศเส้นทาง (Advertise the routes)

sudo tailscale up --advertise-routes=10.0.0.0/24

บน VPS ที่เชื่อมต่อกับ tailnet ของคุณอยู่แล้ว ให้เปลี่ยนการตั้งค่าโดยตรงแทน:

sudo tailscale set --advertise-routes=10.0.0.0/24

ใช้ tailscale set สำหรับการเปลี่ยนแปลงในภายหลังทั้งหมด การรัน tailscale up ซ้ำด้วย flag เพียงตัวเดียวจะรีเซ็ต flag อื่นๆ ที่คุณไม่ได้ระบุไว้ และ CLI จะแสดงข้อผิดพลาดว่าการเปลี่ยนการตั้งค่าด้วยวิธีนี้จำเป็นต้องระบุ flag ที่ไม่ใช่ค่าเริ่มต้นทั้งหมด tailscale set จะเปลี่ยนการตั้งค่าเพียงรายการเดียวและคงค่าอื่นไว้ตามเดิม

คุณสามารถระบุช่วงเครือข่ายหลายรายการในรายการเดียวโดยคั่นด้วยเครื่องหมายจุลภาคและไม่มีช่องว่าง: --advertise-routes=10.0.0.0/24,192.168.50.0/24 แต่ละรายการต้องเป็นที่อยู่เครือข่ายในรูปแบบ CIDR (classless inter-domain routing หรือรูปแบบ 10.0.0.0/24) หากคุณระบุที่อยู่โฮสต์ของตนเองโดยผิดพลาด เช่น 10.0.0.5/24 ระบบจะปฏิเสธเนื่องจากบิตหลัง prefix ไม่เป็นศูนย์ และข้อความแสดงข้อผิดพลาดจะระบุ prefix ที่คุณน่าจะต้องการใช้ หากต้องการหยุดการประกาศเส้นทาง ให้ตั้งค่าเป็นรายการว่างด้วย sudo tailscale set --advertise-routes=

อนุมัติเส้นทางในคอนโซลผู้ดูแลระบบ

การประกาศเส้นทาง (advertise a route) เป็นเพียงการส่งคำขอ ไม่ใช่การเปลี่ยนแปลงค่าในทันที จนกว่าผู้ดูแลระบบจะอนุมัติ ไคลเอนต์จะยังไม่ได้รับเส้นทางนั้นและไม่สามารถเข้าถึงช่วงเครือข่ายดังกล่าวได้ การออกแบบนี้มีเจตนาเพื่อความปลอดภัย เนื่องจากเครื่องที่สามารถเพิ่มตัวเองเข้าไปในตารางเส้นทางของทุกคนได้นั้น อาจดักจับทราฟฟิกของช่วงเครือข่ายใดก็ได้ตามต้องการ

คุณสามารถอนุมัติได้ที่หน้า Machines ในคอนโซลผู้ดูแลระบบ โดย VPS จะแสดงรายการพร้อมป้ายกำกับ subnet ให้เปิดแถวของเครื่องนั้น ค้นหาส่วน subnets แก้ไขการตั้งค่าเส้นทาง ทำเครื่องหมายถูกที่เส้นทางดังกล่าว แล้วบันทึก

การอนุมัติจะทำแยกตามแต่ละ prefix หากคุณประกาศ 10.0.0.0/24 ในวันนี้ และประกาศ 192.168.50.0/24 ในเดือนหน้า prefix ใหม่จะเข้ามาในสถานะที่ยังไม่อนุมัติ ในขณะที่ prefix เดิมจะยังคงทำงานได้ตามปกติ สถานะของเส้นทางที่ได้รับการอนุมัติและเส้นทางที่ถูกละเว้นจะดูเหมือนกันจากฝั่ง VPS ดังนั้นควรตรวจสอบในคอนโซลก่อนที่จะเริ่มแก้ไขปัญหาในส่วนอื่น

คุณสามารถข้ามขั้นตอนการทำด้วยตนเองได้โดยใช้บล็อก autoApprovers ในไฟล์นโยบายของ tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

จากนั้นให้เริ่มการทำงานของโหนดด้วยแท็กดังกล่าวผ่านคำสั่ง sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router แล้วเส้นทางจะได้รับการอนุมัติทันทีที่มีการประกาศ ทั้งนี้แท็กดังกล่าวจะต้องมีอยู่ในส่วน tagOwners ของไฟล์นโยบายเดียวกันก่อน วิธีนี้คุ้มค่าที่จะตั้งค่าไว้หากคุณสร้าง VPS ใหม่จากสคริปต์ เนื่องจากโหนดที่ถูกสร้างใหม่จะถือเป็นโหนดใหม่ และเส้นทางของมันจะเริ่มต้นในสถานะที่ยังไม่อนุมัติเสมอ

เหตุใดไคลเอนต์ Linux จึงเพิกเฉยต่อเส้นทางหากไม่มีแฟล็ก --accept-routes

เส้นทางดังกล่าวได้รับการประกาศและอนุมัติแล้ว โทรศัพท์และ Mac ของคุณสามารถเข้าถึง 10.0.0.20 ได้ แต่แล็ปท็อป Linux ของคุณกลับทำไม่ได้ และไม่มีสิ่งใดในคอนโซลผู้ดูแลระบบที่บ่งชี้ถึงปัญหา

การยอมรับ subnet route หมายถึงการเขียนรายการลงในตารางเส้นทาง (routing table) ของไคลเอนต์ บน Android, iOS, macOS, tvOS และ Windows ไคลเอนต์ Tailscale จะดำเนินการส่วนนี้ให้คุณโดยอัตโนมัติ แต่บน Linux จะไม่ทำเช่นนั้น เนื่องจากเครื่อง Linux มักทำหน้าที่เป็นเซิร์ฟเวอร์หรือเราเตอร์ ซึ่งตารางเส้นทางถูกกำหนดค่าไว้โดยเจตนา การแทรก /24 ที่เรียนรู้จากเครือข่ายเข้ามาโดยเงียบๆ อาจทำให้ทราฟฟิกที่เครื่องนั้นจัดการอยู่เดิมเกิดปัญหาได้ ดังนั้นบน Linux คุณจึงต้องเลือกเปิดใช้งานด้วยตนเองในไคลเอนต์แต่ละเครื่อง:

sudo tailscale set --accept-routes

จากนั้นตรวจสอบว่าเส้นทางถูกติดตั้งไว้ที่ใด:

ip route show table 52
ip route get 10.0.0.20

Tailscale บน Linux จะไม่ใส่เส้นทางที่ยอมรับไว้ในตารางเส้นทางหลัก (main routing table) แต่จะใส่ไว้ในตารางเส้นทางหมายเลข 52 และติดตั้งกฎนโยบาย (policy rules) ซึ่งสามารถดูได้ด้วย ip rule show ในช่วงลำดับความสำคัญ 5210 ถึง 5270 ซึ่งจะส่งแพ็กเก็ตที่ไม่ตรงกับกฎใดๆ ไปยังตารางนั้น ดังนั้น ip route show เพียงอย่างเดียวจะไม่แสดง 10.0.0.0/24 และผู้อ่านที่ตรวจสอบเพียงคำสั่งนั้นอาจสรุปว่า --accept-routes ไม่ได้ดำเนินการใดๆ ip route show table 52 คือคำสั่งที่แสดงความจริง และควรแสดงช่วงที่ประกาศไว้บน tailscale0

มีข้อยกเว้นประการหนึ่งที่ควรทราบ หากโหนด Linux นี้ทำหน้าที่เป็น subnet router ตัวที่สองสำหรับเครือข่ายท้องถิ่นของตนเอง --accept-routes จะทำให้เครื่องส่งทราฟฟิกสำหรับ subnet ที่เชื่อมต่อโดยตรงของตนเองผ่านเราเตอร์อีกตัว แทนที่จะส่งออกผ่านอินเทอร์เฟซของตนเอง สำหรับเราเตอร์สำรองในชุดที่มีความพร้อมใช้งานสูง (high availability pair) ให้ปิด --accept-routes ไว้และทำการประกาศ (advertise) เพียงอย่างเดียว

รูปแบบความล้มเหลว: เราเตอร์สองตัวประกาศช่วง IP ซ้อนทับกัน

เราเตอร์ subnet สองตัวต้องไม่ประกาศช่วง IP ที่เหมือนกัน การประกาศช่วงที่ซ้อนทับกันโดยมีความยาว prefix ต่างกันนั้นสามารถทำได้ และ Tailscale จะเลือกเส้นทางที่เฉพาะเจาะจงที่สุด หากเราเตอร์ A ประกาศ 10.0.0.0/24 และเราเตอร์ B ประกาศ 10.0.0.0/16 ทราฟฟิกที่มุ่งหน้าไปยัง 10.0.0.20 จะถูกส่งไปยัง A

สิ่งที่มักทำให้ผู้ใช้งานประหลาดใจคือพฤติกรรมเมื่อ A ออฟไลน์ Tailscale จะไม่เปลี่ยนไปใช้เส้นทางที่กว้างกว่าโดยอัตโนมัติ ทราฟฟิกไปยัง 10.0.0.20 จะหยุดลง ในขณะที่ทราฟฟิกไปยัง 10.1.0.20 ยังคงทำงานผ่าน B ได้ตามปกติ อาการนี้จะดูเหมือนเครือข่ายส่วนตัวใช้งานได้เพียงบางส่วน โดยมีสาเหตุมาจากโหนดที่ออฟไลน์ยังคงถือครอง prefix ที่เฉพาะเจาะจงกว่าเอาไว้ หากคุณต้องการระบบ failover ให้กำหนดเราเตอร์ตัวที่ครอบคลุมกว้างกว่าให้ประกาศ prefix ที่แคบกว่าด้วย เพื่อให้ทั้งสองตัวครอบคลุมช่วงที่อยู่เดียวกัน

การซ้อนทับอีกรูปแบบหนึ่งเกิดขึ้นใกล้กับฝั่งไคลเอนต์มากกว่า หากคุณใช้งานเครือข่ายโรงแรมที่ 192.168.1.0/24 ในขณะที่ subnet router ของคุณประกาศ 192.168.1.0/24 จะทำให้ทั้งสองแหล่งแย่งชิงการส่งข้อมูลไปยังปลายทางเดียวกัน ซึ่งผลลัพธ์จะขึ้นอยู่กับแพลตฟอร์ม สำหรับ Linux ให้ติดตั้งกฎ (rule) ไว้ก่อนหน้ากฎของ Tailscale เพื่อให้ที่อยู่ภายในเครื่องใช้ตารางหลัก (main table):

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

กฎดังกล่าวจะไม่คงอยู่ถาวรและจะหายไปเมื่อรีบูตเครื่อง วิธีแก้ไขที่แท้จริงคือการเลือกช่วง IP ส่วนตัวที่คุณจะไม่พบเจอในการใช้งานทั่วไป 192.168.0.0/24 และ 192.168.1.0/24 เป็นค่าเริ่มต้นบนเราเตอร์ตามบ้านส่วนใหญ่ ดังนั้นควรเลือกช่วง IP ภายใน 10.0.0.0/8 ที่คุณกำหนดขึ้นเองอย่างตั้งใจ การชนกันของ IP ในลักษณะเดียวกันนี้ยังส่งผลเสียต่อ VPN แบบ WireGuard ทั่วไปที่คุณตั้งค่าด้วยตนเอง ด้วยเหตุผลเดียวกัน คือเส้นทางภายในเครื่องที่เฉพาะเจาะจงกว่าจะเป็นฝ่ายชนะ ทำให้ทราฟฟิกไม่ถูกส่งเข้าอุโมงค์ VPN

โหมดความล้มเหลว: DNS แปลงชื่อเป็นที่อยู่ซึ่งไม่มีเส้นทางรองรับ

ปัญหานี้ตรวจสอบได้ยากเนื่องจากไม่มีการรายงานข้อผิดพลาดใดๆ ชื่อโดเมนถูกแปลงเป็น IP ได้ปกติ แต่การเชื่อมต่อกลับหมดเวลา (timeout)

สมมติว่า db.internal.example.com แปลงเป็น 10.0.5.20 ผ่านเนมเซิร์ฟเวอร์ส่วนตัวของคุณ และคุณได้ประกาศเส้นทาง 10.0.0.0/24 ไว้ การค้นหาชื่อโดเมนจะสำเร็จเพราะการแปลงชื่อ (Domain Name System) และการกำหนดเส้นทาง IP เป็นขั้นตอนที่แยกจากกันโดยสิ้นเชิงและไม่มีขั้นตอนใดตรวจสอบความถูกต้องของอีกฝ่าย จากนั้นแพ็กเก็ตที่ส่งไปยัง 10.0.5.20 จะไม่พบเส้นทางที่ตรงกันใน tailnet จึงหลุดออกไปทาง default gateway ของไคลเอนต์และหายไปในที่สุด

คำสั่งสองคำสั่งต่อไปนี้ช่วยแยกแยะปัญหาทั้งสองส่วน:

nslookup db.internal.example.com
ip route get 10.0.5.20

หากการค้นหาชื่อโดเมนได้ที่อยู่ IP กลับมา แต่ ip route get ไม่ตอบสนองด้วย dev tailscale0 แสดงว่าชื่อโดเมนถูกต้องแต่เส้นทางหายไป ให้ประกาศช่วง IP ที่ครอบคลุมที่อยู่นั้น ไม่ว่าจะเป็น 10.0.0.0/16 หรือ prefix อื่นที่ระบุแยกต่างหาก จากนั้นอนุมัติ prefix ใหม่ในคอนโซล

มีกับดักที่คล้ายกันบนตัวเนมเซิร์ฟเวอร์เอง หากคุณตั้งค่า global nameserver ใน admin console เป็นที่อยู่ส่วนตัว เช่น 10.0.0.53 ที่อยู่นั้นจะต้องอยู่ภายในเส้นทางที่ได้รับการอนุมัติแล้ว มิฉะนั้นอุปกรณ์ของคุณจะไม่สามารถเข้าถึงตัว resolver ได้เลย หากคุณเปิดตัวเลือกที่บังคับใช้ DNS เซิร์ฟเวอร์ส่วนกลางในขณะที่ชี้ไปยัง resolver ที่ไม่มีใครเข้าถึงได้ อุปกรณ์ทุกเครื่องใน tailnet จะสูญเสียความสามารถในการแปลงชื่อโดเมนทันที รวมถึงเครื่องที่เพิ่งใช้งานได้เมื่อครู่ ให้ประกาศและอนุมัติเส้นทางไปยัง resolver ก่อน แล้วจึงเปลี่ยนการตั้งค่า DNS หากปัญหา DNS ภายในอุโมงค์เป็นสิ่งที่คุณยังคงประสบอยู่ วิธีที่ DNS ทำงานผิดพลาดผ่านอุโมงค์ WireGuard จะอธิบายกลไกเดียวกันนี้โดยไม่มีเลเยอร์การประสานงานด้านบนเข้ามาเกี่ยวข้อง

Source NAT และการเชื่อมต่อแบบ site to site

โดยค่าเริ่มต้น subnet router จะเขียนทับ source address ของทุกแพ็กเก็ตที่ส่งต่อด้วยที่อยู่ส่วนตัวของตัวมันเอง กระบวนการนี้เรียกว่า SNAT (source network address translation) ซึ่งมีไว้เพื่อให้การตอบกลับทำงานได้โดยไม่ต้องแก้ไขค่าใดๆ ในเครือข่ายส่วนตัว เช่น ฐานข้อมูลที่ 10.0.0.20 จะตอบกลับไปยัง VPS ซึ่งเป็นปลายทางที่ฐานข้อมูลรู้จักเส้นทางอยู่แล้ว ข้อเสียคือฐานข้อมูลจะมองเห็นการเชื่อมต่อผ่าน tailnet ทั้งหมดว่ามาจาก VPS ทำให้กฎไฟร์วอลล์ที่อิงตาม source และ access log ไม่สามารถระบุตัวตนผู้ใช้งานจริงได้

คุณสามารถปิดการทำงานนี้บน Linux ได้หากต้องการคงค่า tailnet address จริงของไคลเอนต์ไว้:

sudo tailscale set --snat-subnet-routes=false

จากนั้นโฮสต์ในเครือข่ายส่วนตัวจำเป็นต้องมีเส้นทางกลับไปยัง 100.64.0.0/10 ซึ่งเป็นช่วงที่ Tailscale กำหนดให้กับอุปกรณ์ต่างๆ โดยต้องชี้กลับมาที่ subnet router หากไม่มีเส้นทางขากลับนี้ แพ็กเก็ตตอบกลับจะถูกส่งไปยัง default gateway และไม่ถึงปลายทาง ส่งผลให้การเชื่อมต่อค้างหลังจากส่งแพ็กเก็ตแรก คุณต้องเพิ่ม static route บน gateway ของเครือข่ายส่วนตัว หรือเลือกเปิด SNAT ไว้ตามเดิม

การเชื่อมต่อแบบ site to site คือการที่ subnet router สองตัวทำงานนี้พร้อมกัน โดยแต่ละตัวจะประกาศเครือข่ายของตนเองและยอมรับเครือข่ายของอีกฝั่ง:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

ให้รันคำสั่งที่สอดคล้องกันบนเราเตอร์อีกตัวโดยใช้ช่วงเครือข่ายของตัวมันเอง ช่วงเครือข่ายทั้งสองต้องไม่ซ้ำกัน หากการถ่ายโอนข้อมูลขนาดใหญ่เกิดการหยุดชะงักในขณะที่ ssh และ ping ยังทำงานได้ปกติ สาเหตุมาจาก MSS (maximum segment size) ซึ่งเป็นขนาดข้อมูลที่ใหญ่ที่สุดที่แพ็กเก็ต TCP สามารถบรรจุได้ ค่า overhead ของอุโมงค์ทำให้แพ็กเก็ตที่ส่งต่อมีขนาดใหญ่เกินกว่าที่ลิงก์ระหว่างทางจะรองรับได้ การทำ clamping จะช่วยแก้ไขปัญหานี้:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

บันทึกกฎดังกล่าวด้วย iptables-persistent มิฉะนั้นกฎจะหายไปเมื่อมีการบูตเครื่องใหม่

การดูแลรักษาเพื่อให้ระบบทำงานได้อย่างต่อเนื่อง

โดยค่าเริ่มต้น Node keys จะหมดอายุหลังจาก 180 วัน นับตั้งแต่เดือนสิงหาคม 2026 เมื่อคีย์บน subnet router หมดอายุ โหนดจะออกจากระบบและช่วง IP ที่ประกาศไว้ทั้งหมดจะไม่สามารถเข้าถึงได้ โดยไม่มีการเปลี่ยนแปลงการตั้งค่าใดๆ ที่อธิบายเหตุการณ์นี้ได้ ให้ปิดการใช้งานการหมดอายุของคีย์สำหรับเครื่องนี้ที่หน้า Machines ใน admin console จากนั้นให้จดบันทึกไว้ว่าคุณได้ดำเนินการดังกล่าวแล้ว

Tailscale ให้ความสำคัญกับการเชื่อมต่อโดยตรงระหว่าง peer และจะเปลี่ยนไปใช้ relay servers เมื่อไม่สามารถเชื่อมต่อโดยตรงได้ แม้ relay จะทำงานได้ดี แต่ก็จะเพิ่ม latency ให้กับการเชื่อมต่อ VPS ที่มี public address เป็นกรณีที่จัดการได้ง่าย: ให้เปิดรับ UDP 41641 ขาเข้าเพื่อให้ peer ส่วนใหญ่เชื่อมต่อได้โดยตรง หากคุณใช้ ufw ในการจัดการ firewall กฎ ufw ที่ VPS จำเป็นต้องใช้จริง จะครอบคลุมถึงไวยากรณ์ที่ต้องใช้

Access rules คืออีกส่วนที่สำคัญ ใน tailnet ค่าเริ่มต้น อุปกรณ์ทุกเครื่องของคุณสามารถเข้าถึงกันได้ ดังนั้นเส้นทางที่ได้รับอนุมัติจึงใช้งานได้ทันที แต่เมื่อคุณเขียน ACL policy ฝั่งปลายทางของกฎจะต้องระบุช่วง private range ไว้ด้วย เนื่องจาก 10.0.0.20 ไม่ใช่ที่อยู่ของ tailnet และไม่ครอบคลุมโดยกฎที่เขียนขึ้นสำหรับ tailnet IP หรือ tags

สุดท้าย ให้ตัดสินใจว่าคุณต้องการใช้ coordination server ที่คุณไม่ได้ดูแลเองหรือไม่ Control plane ของ Tailscale เป็นบริการแบบ hosted แม้คีย์จะยังคงอยู่บนเครื่องของคุณ แต่บัญชีและไฟล์นโยบายจะถูกเก็บไว้ที่นั่น การใช้งาน Headscale ซึ่งเป็น Tailscale control server แบบ self-hosted จะช่วยให้คุณเก็บส่วนนี้ไว้บน VPS ของคุณเองได้ แต่ต้องแลกมาด้วยภาระในการดูแลรักษา อีกทางเลือกหนึ่งสำหรับความกังวลเดียวกันคือการเลิกใช้ไคลเอนต์ของ Tailscale และหันไป self-hosting NetBird VPN server ซึ่งจะรวมชั้น coordination และ mesh clients ไว้ในเครื่องเดียวที่คุณควบคุม หากคุณยังตัดสินใจไม่ได้ระหว่างโมเดลนี้กับการตั้งค่าด้วยตนเอง การเปรียบเทียบระหว่าง WireGuard และ Tailscale จะอธิบายว่าชั้น coordination มอบอะไรให้คุณและมีต้นทุนอย่างไรบ้าง

FAQ

Subnet router กับ exit node ต่างกันอย่างไร

Subnet router จะประกาศช่วงที่อยู่ IP ภายใน เพื่อให้เครื่องใน tailnet สามารถเข้าถึงเครื่องที่ไม่ได้ติดตั้ง Tailscale ได้ ส่วน exit node จะประกาศตัวเองเป็นเส้นทางออกสู่ Internet ทั้งหมด เพื่อให้เครื่องลูกข่ายส่งทราฟฟิกทั้งหมดออกผ่านที่อยู่สาธารณะของโหนดนั้น VPS หนึ่งเครื่องสามารถเป็นได้ทั้งสองอย่าง โดยใช้ flag แยกกันคือ --advertise-routes และ --advertise-exit-node ซึ่งแต่ละรายการต้องได้รับการอนุมัติใน admin console แยกกัน

ทำไม Linux client ของฉันถึงเพิกเฉยต่อ subnet route ที่ประกาศไว้

Linux client จะไม่ยอมรับ subnet route จนกว่าคุณจะสั่งให้ทำ ให้รันคำสั่ง sudo tailscale set --accept-routes บนเครื่องลูกข่าย จากนั้นตรวจสอบด้วย ip route show table 52 แทนการใช้ ip route show เนื่องจาก Tailscale จะติดตั้งเส้นทางที่ยอมรับไว้ใน routing table 52 และเข้าถึงผ่าน policy rules ทำให้ตารางหลัก (main table) ไม่แสดงรายการเหล่านี้ และดูเหมือนว่าเส้นทางที่ใช้งานได้จริงนั้นหายไป

ทำไม subnet ถึงหยุดทำงานหลังจากรีบูตเครื่อง

สาเหตุที่เป็นไปได้มากที่สุดคือ IP forwarding ค่าที่ตั้งไว้ด้วย sysctl -w จะไม่คงอยู่หลังการรีบูต ดังนั้นควรเขียนค่าลงใน /etc/sysctl.d/99-tailscale.conf และยืนยันด้วย sysctl net.ipv4.ip_forward หากเปิด forwarding แล้วแต่ยังเข้าถึงช่วง IP ไม่ได้ ให้ตรวจสอบโหนดใน admin console โดยปกติ node key จะหมดอายุหลังจาก 180 วัน และ subnet router ที่หมดอายุจะแสดงผลเหมือนปัญหาเครือข่ายมากกว่าปัญหาบัญชีผู้ใช้

Subnet router สองตัวสามารถประกาศช่วง IP เดียวกันได้หรือไม่

ไม่สามารถประกาศช่วงที่เหมือนกันทุกประการได้ แต่สามารถประกาศช่วงที่ซ้อนทับกันโดยมีความยาว prefix ต่างกันได้ โดยระบบจะเลือกเส้นทางที่เฉพาะเจาะจงที่สุด การทำ failover ต้องระมัดระวัง: เมื่อ router ที่ถือ prefix เฉพาะเจาะจงกว่าออฟไลน์ Tailscale จะไม่ย้อนกลับไปใช้เส้นทางที่กว้างกว่า ทำให้ทราฟฟิกนั้นหยุดชะงัก สำหรับการทำ standby pair ที่แท้จริง ควรให้ router ทั้งสองตัวประกาศ prefix เฉพาะเจาะจงชุดเดียวกัน

ทำไม hostname ถึง resolve ได้ แต่การเชื่อมต่อกลับหมดเวลา (timeout)

การทำ DNS resolution และการทำ routing เป็นขั้นตอนที่แยกจากกัน ชื่อโฮสต์สามารถ resolve ไปยังที่อยู่ IP ที่ไม่มีเส้นทางที่ได้รับอนุมัติรองรับ ทำให้แพ็กเก็ตหลุดออกไปผ่าน default gateway ของเครื่องลูกข่ายแทน ให้รันคำสั่ง ip route get <address> บนเครื่องลูกข่าย หากคำตอบที่ได้ไม่มี dev tailscale0 ให้ประกาศช่วง IP ที่ครอบคลุมที่อยู่นั้นและอนุมัติ prefix ใหม่ใน admin console