อินเทอร์เน็ตใหม่ในมุมมองของ Tailscale

 (tailscale.com)
2 คะแนน โดย GN⁺ 2024-07-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Tailscale ต้องการสร้าง เลเยอร์ 3 ของ OSI แบบใหม่ ที่อุปกรณ์ทุกเครื่องเชื่อมต่อกันโดยตรงได้อย่างปลอดภัย เพื่อไม่ให้นักพัฒนาต้องติดอยู่กับสถาปัตยกรรมที่เน้นการขยายสเกลโดยไม่จำเป็น
  • โปรแกรมจำนวนมากจริง ๆ แล้วไม่จำเป็นต้อง ขยายสเกลขนาดใหญ่ แต่ Tailscale มองว่าการที่ Kubernetes, การ deploy ด้วยคอนเทนเนอร์ และการรวบรวม log บนคลาวด์กลายเป็นค่าเริ่มต้น ทำให้การพัฒนาและการปฏิบัติการช้าลง
  • ปัญหาการขาดแคลน IPv4, NAT, firewall, IP แบบไดนามิก และโครงสร้างใบรับรอง TLS ได้แยก client กับ server ออกจากกัน และทำให้ ผู้ให้บริการคลาวด์ส่วนกลาง อย่าง AWS กลายเป็นศูนย์กลางของการเชื่อมต่อ
  • Tailscale ต้องการมอบใบรับรอง, IP address, ชื่อ DNS, การเข้ารหัสแบบ end-to-end และ identity ให้กับอุปกรณ์แต่ละเครื่อง เพื่อให้เชื่อมต่อได้อย่างปลอดภัยแม้อยู่หลัง firewall และทำให้อุปกรณ์ทุกเครื่องเป็น peer
  • การส่งไฟล์ของ Taildrop ที่ใช้ HTTP PUT แสดงให้เห็นว่าสามารถลดเลเยอร์คลาวด์ตัวกลางได้ แต่การจะเกิด ecosystem ของแอปแบบนี้ได้ จำเป็นต้องมีการใช้งานแพร่หลายเพียงพอก่อน

จุดเริ่มต้นของวิสัยทัศน์ Tailscale

  • Tailscale ไม่ได้พูดต่อสาธารณะมากนักเกี่ยวกับวิสัยทัศน์ที่ใหญ่กว่าฟีเจอร์ระยะสั้น แต่บางองค์กรซื้อ Tailscale ไม่ใช่เพียงเพราะฟีเจอร์ปัจจุบัน แต่เพราะ connectivity ที่จะเป็นไปได้ในอนาคต
  • ประเด็นตั้งต้นไม่ได้อยู่ที่การเป็นบริษัทด้าน networking แต่อยู่ที่ประสบการณ์การพัฒนาที่แย่ลง เมื่อ developer พยายาม ขยายสเกลสิ่งที่ไม่จำเป็นต้องขยายสเกล
  • บริบทการก่อตั้ง Tailscale มีคนรุ่นที่จำประสบการณ์ LAN ในทศวรรษ 1990 ได้ และประสบการณ์นั้นกลายเป็นมาตรฐานที่ใช้เปรียบเทียบกับความซับซ้อนของเทคโนโลยีปัจจุบัน
  • แม้ประสิทธิภาพคอมพิวเตอร์, การเข้าถึงการเขียนโปรแกรม, app store, ระบบชำระเงิน และกราฟิกจะดีขึ้น แต่ Tailscale มองว่างานประจำวันของ developer หลายอย่างที่เคยง่ายในอดีตกลับยากขึ้น

ภาระงานพัฒนาที่เกิดจาก scalability ที่ไม่จำเป็น

  • developer ยุคใหม่ถูกฝึกให้คิดถึง สเกลผู้ใช้ 1 พันล้านคน ตั้งแต่ก่อนเขียนโค้ดบรรทัดแรก และมักให้ความสำคัญกับความสามารถในการขยายสเกลเมื่อเลือกอัลกอริทึมและสถาปัตยกรรม
  • หากนำสัญกรณ์ big-O ไปใช้ผิด ๆ อาจทำให้ดูเหมือนว่า hash table เร็วกว่า array เสมอ แต่ในระดับข้อมูล 10 รายการ array อาจเร็วกว่าและเรียบง่ายกว่า
  • การเลือกโครงสร้างที่ขยายสเกลได้ หากไม่ได้มีการขยายสเกลจริง อาจได้ระบบที่ช้ากว่าและสร้างยากกว่า
  • กรณีที่บอกว่าใช้ Kubernetes รองรับ pageview 500,000 ครั้งต่อเดือนนั้น เทียบได้ประมาณ 0.2 request ต่อวินาที และเปรียบเทียบว่าแม้แต่คอมพิวเตอร์ช้า ๆ ในยุค 1990 โปรแกรม Perl หรือ Python ก็เริ่มทำงานได้ในระดับมิลลิวินาทีและรองรับ request ได้มากกว่านั้น
  • build ที่ใช้เวลานาน, Docker build, การอัปโหลดไปยัง container registry, การ deploy ที่กินเวลาหลายสิบวินาทีถึงหลายนาที และ log ที่มาช้า ล้วนถูกมองว่าเป็น overhead ที่เกิดจากสมมติฐานว่า “ทุกอย่างต้องขยายสเกลได้”
  • Tailscale วางตัวเป็นเครื่องมือเพื่อให้การสร้าง งานหางยาวที่ไม่จำเป็นต้องขยายสเกล เช่น dashboard หรือ meme generator ซึ่ง developer ทุกคนใช้เวลาส่วนไม่น้อยไปกับมัน ทำได้ง่ายขึ้น

วิธีที่อินเทอร์เน็ตปัจจุบันเพิ่มความซับซ้อน

  • ความซับซ้อนจำนวนมากถูกมองว่าไม่ใช่ความซับซ้อนโดยเนื้อแท้ แต่เป็นผลจากการนำวิธีแก้ที่ซับซ้อนไปวางทับปัญหาที่สามารถแก้ได้อย่างเรียบง่าย
    • ระบบ log เป็นเพียงการ stream ข้อความจากที่หนึ่งไปอีกที่หนึ่ง แต่ผลลัพธ์อาจปรากฏหลังจากนั้น 5 นาที
    • ระบบ orchestration คือโปรแกรมที่รันโปรแกรมอื่น แต่ kernel ของ Unix ทำสิ่งนี้ในระดับมิลลิวินาทีมาเป็นเวลาหลายสิบปีแล้ว
  • networking เป็นสิ่งจำเป็นต่อซอฟต์แวร์สมัยใหม่ แต่อินเทอร์เน็ตปัจจุบันทำให้หลายปัญหายากขึ้น
  • Tailscale ไม่ต้องการเพิ่มเลเยอร์ไว้บนสุดของ OSI stack เดิมเพื่อซ่อนปัญหา แต่ต้องการสร้าง เลเยอร์ 3 ของ OSI แบบใหม่ บนสมมติฐานที่ต่างออกไป

การรวมศูนย์ของคลาวด์และค่าเช่าของ connectivity

  • หากดูว่าในอุตสาหกรรมเทคโนโลยี ใครสามารถเก็บค่าเช่าได้ ก็จะเห็นจุดคอขวด และ Tailscale มองว่าในการ deploy ซอฟต์แวร์ปัจจุบัน AWS อยู่ในตำแหน่งนั้น
  • คลาวด์ให้ทรัพยากรประมวลผลที่ขยายสเกลได้ แต่มีการเปรียบเทียบว่าแม้แต่ MacBook ระดับกลาง ก็สามารถประมวลผล transaction ต่อวินาทีจาก SSD ได้มากกว่าดิสก์ local บนคลาวด์ถึง 10 เท่าหรือ 100 เท่า
  • เหตุผลที่คอมพิวเตอร์ของเราเองเป็น server ได้ยากคือเรื่องตำแหน่งและ connectivity
    • มี firewall, NAT, IP แบบไดนามิก และลิงก์เครือข่ายแบบไม่สมมาตร
    • แม้จะตั้งค่า port forwarding, static IP และลิงก์อินเทอร์เน็ตสำรองเองได้ แต่ต้องใช้แรงงานและความเชี่ยวชาญมาก
  • สุดท้ายจึงต้องจ่ายเงินให้ผู้ให้บริการ hosting ที่มี IP address และ bandwidth และถ้าเป็นบริษัทจริงจังก็มักเลือกผู้ให้บริการรายใหญ่ที่เชื่อถือได้ในเรื่องสิทธิ์เข้าถึงอุปกรณ์
  • โครงสร้างแบบ “ไม่มีใครถูกไล่ออกเพราะซื้อ AWS” ถูกเชื่อมโยงกับสำนวนในอดีตที่พูดถึง IBM

Gatekeeper ที่ย้ายจากระบบปฏิบัติการไปสู่ HTTPS

  • IBM เคยเก็บค่าเช่าได้จาก computing แบบรวมศูนย์ และ Microsoft เขย่าโครงสร้างนั้นด้วย computing แบบกระจายศูนย์บน PC
  • Tailscale มองว่าโลกปัจจุบันที่มีคลาวด์และโทรศัพท์มือถือเป็นศูนย์กลางได้กลับไปสู่ความเป็น รวมศูนย์ อีกครั้ง
    • อุปกรณ์บนโต๊ะและในกระเป๋าของเราเป็นระดับ supercomputer ตามมาตรฐานเมื่อ 20 ปีก่อน แต่หาก AWS ล่ม ก็จะกลายเป็นก้อนอิฐที่ใช้งานไม่ได้
    • แม้จะมี server หลาย instance และระบบ distributed consensus แต่ส่วนใหญ่ก็ยังรันอยู่บนผู้ให้บริการคลาวด์ส่วนกลาง
  • ในทศวรรษ 1990 ระบบปฏิบัติการเป็นตัวกำหนด compatibility และการเชื่อมต่อระหว่างโปรแกรม แต่หลังยุคเว็บ JavaScript และ ความสามารถในการเชื่อมต่อผ่าน HTTPS สำคัญกว่า
  • HTTPS โดยพื้นฐานมีโครงสร้างรวมศูนย์แบบ client กับ server
    • server มี static IP, ชื่อ DNS, ใบรับรอง TLS และ port ที่เปิดอยู่
    • client โดยทั่วไปไม่มีองค์ประกอบเหล่านั้น
    • หาก server หายไป client ก็ทำอะไรไม่ได้
  • เนื่องจากปัญหาความปลอดภัยและการขาดแคลน IPv4 address จึงมีการเพิ่ม firewall และ NAT เข้ามา และการเชื่อมต่อกลายเป็นโครงสร้างทางเดียวจาก client ไปยัง server

New Internet ของ Tailscale

  • ตลอด 5 ปีที่ผ่านมา Tailscale ได้สร้างผลิตภัณฑ์ขึ้นมาเพื่อเป็นทางแก้ของปัญหานี้
  • อุปกรณ์แต่ละเครื่องมี ใบรับรอง, IP address, ชื่อ DNS, การเข้ารหัสแบบ end-to-end และ identity พร้อมทั้งข้าม firewall ได้อย่างปลอดภัย
  • อุปกรณ์ทุกเครื่องไม่จำเป็นต้องมีบทบาทตายตัวเป็น server หรือ client แต่สามารถเป็น peer ที่เชื่อมต่อถึงกันได้
  • Tailscale มองว่าสิ่งนี้ทำได้โดยไม่เพิ่ม latency หรือ overhead
  • ผู้ใช้ Tailscale ได้สัมผัสสภาพแวดล้อมที่ตัดเลเยอร์ซับซ้อนหลายชั้นออกไปแล้ว และอินเทอร์เน็ตทำงานใกล้เคียงกับสิ่งที่เคยคาดหวังไว้แต่เดิมมากขึ้น

ความเรียบง่ายที่ Taildrop แสดงให้เห็น

  • Taildrop เป็นตัวอย่างเล็ก ๆ ของโครงสร้างที่ Tailscale ทำให้เป็นไปได้
  • เมื่อมี Tailscale ติดตั้งอยู่แล้ว แกนหลักของ Taildrop คือ HTTP PUT เพียงครั้งเดียว
    • ฝั่งส่งส่ง HTTP request ไปยังฝั่งรับ
    • แจ้งว่า “กำลังส่งไฟล์ X”
    • ส่งไฟล์
  • บนอินเทอร์เน็ตแบบเดิม เนื่องจากอุปกรณ์ฝั่งรับอยู่หลัง firewall และไม่มี port เปิดกับ identity จึงจำเป็นต้องใช้วิธีอัปโหลดขึ้นคลาวด์แล้วดาวน์โหลดกลับลงมา
  • วิธีผ่านคลาวด์สร้างเลเยอร์เพิ่มเติมหลายอย่าง
    • เกิดค่าใช้จ่ายด้าน network egress, ค่า storage และค่า CPU ของ server
    • ต้องตัดสินใจว่าจะลบไฟล์ที่ยังไม่ถูกดาวน์โหลดเมื่อใด
    • ต้องให้ server ออนไลน์อยู่แม้ตอนที่ไม่ได้ใช้งาน
    • พนักงานคลาวด์ในทางทฤษฎีอาจเข้าถึงไฟล์ได้ จึงจำเป็นต้องเข้ารหัส
    • การเข้ารหัสต้องมีการแลกเปลี่ยน key ระหว่างผู้ส่งกับผู้รับ
    • หากต้องการแจ้งผู้รับว่ามีไฟล์รออยู่ อาจต้องใช้ระบบ push notification เฉพาะแพลตฟอร์ม
  • Taildrop ทำให้ overhead ด้านต้นทุนเหล่านี้หายไป จึงสามารถส่งไฟล์ฟรีได้ และสิ่งนี้เชื่อมโยงกับบริบทของ แผนฟรี ของ Tailscale

เหตุผลที่ต้องมีการใช้งานแพร่หลาย

  • Taildrop เป็นเพียงตัวอย่างเล็ก ๆ แต่ทำหน้าที่เป็น proof of existence ของหมวดโปรแกรมที่อาจทำได้ง่ายขึ้น 10 เท่าหากมี Tailscale
  • การขาด connectivity ทำให้เกิดการรวมศูนย์ และการรวมศูนย์ทำให้แม้แต่โปรแกรมเล็ก ๆ ก็ต้องจ่ายค่าเช่า พร้อมสร้างโครงสร้างที่ช้า ซับซ้อน และ debug ยาก
  • หากต้องการให้เกิดแอปที่ทำงานบน Tailscale เท่านั้น ต้องมีคนใช้ Tailscale มากเพียงพอ
  • หากการใช้งานยังไม่แพร่หลายพอ ก็จะเกิด ปัญหาไก่กับไข่ ที่ไม่มีใครสร้างแอปแบบนั้น
  • ด้วยเหตุนี้ Tailscale จึงทุ่มเทอย่างมากกับการให้ใช้ฟรี พร้อมกับให้ความสำคัญกับฟีเจอร์ enterprise ที่ช่วยให้การนำไปใช้ในที่ทำงานและการ deploy ทั่วทั้งองค์กร Fortune 500 ทำได้ง่ายขึ้น

เป้าหมายและตำแหน่งปัจจุบัน

  • อินเทอร์เน็ตเป็นของทุกคน และแม้ในอดีตจะมี internetwork หลายแบบ แต่ Internet ที่หลากหลายและเปิดกว้างที่สุดเป็นฝ่ายชนะ
  • New Internet ก็ควรใช้งานได้สำหรับ developer ที่บ้าน, developer ในมหาวิทยาลัย, พนักงานองค์กร และท้ายที่สุดคือทุกคน
  • ปัจจุบันในประชากรโลกประมาณ 1 ใน 30,000 คน ใช้ New Internet หรือก็คือ Tailscale
  • Tailscale ตั้งเป้าว่าจะไม่หยุดจนกว่าทุกคนจะใช้งานได้
  • โดยชวนให้นึกถึงช่วงเวลาที่ Microsoft ถูกล้อเลียนจากเป้าหมายว่าจะวางคอมพิวเตอร์ไว้บนโต๊ะทำงานทุกตัว และยุคที่ TCP/IP ยังเป็นฟีเจอร์เสริมที่ต้องซื้อจาก third party พร้อมเน้นว่าโลกเทคโนโลยีสามารถเปลี่ยนแปลงอย่างรวดเร็วได้แม้ภายใน 30 ปี

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-28
ความคิดเห็นจาก Hacker News

  • ปัญหาถาวรของบริษัทอย่าง Tailscale, Cloudflare, Google คือการที่พวกเขาเข้ามาแก้ปัญหาที่อินเทอร์เน็ตควรจะแก้ได้เองตั้งแต่แรก เช่น การเชื่อมต่อแบบ end-to-end ที่ปลอดภัยและเรียบง่าย ทำให้เกิดแรงจูงใจที่จะปล่อยให้ปัญหานั้นยังคงอยู่ต่อไป
    สิ่งที่อินเทอร์เน็ตต้องการคืออะไรสักอย่างอย่าง IPv6 ที่มีโครงสร้างพื้นฐานกุญแจสาธารณะตามที่ DNSSEC ให้มา และการเข้ารหัสอัตโนมัติแบบ IPsec แต่ถ้าสิ่งนั้นถูกนำไปใช้อย่างเข้ากันได้ในวงกว้าง ธุรกิจของ Tailscale ก็จะพัง
    สุดท้ายธุรกิจของพวกเขาพึ่งพาการที่ปัญหายังคงมีอยู่
    โพสต์ซ้ำ: https://news.ycombinator.com/item?id=38570370

    • ฟังดูเหมือนเป็นข้อสังเกตที่เข้าท่า แต่ยิ่งคิดก็ยิ่งรู้สึกเหมือนเป็น การบำเพ็ญทุกข์ทางดิจิทัล
      IPv6 ออกมาในปี 1998 และตลอด 21 ปีจนกระทั่ง Tailscale เปิดตัวในปี 2019 วิธีที่กล่าวถึงก็ยังไม่ถูกนำไปใช้จริง
      ตอนนั้นใครเป็นคนขวาง และตอนนี้ใครกำลังขวางอยู่? Google, Cloudflare, Tailscale ได้รับเงินหรือสิ่งตอบแทนเทียบเท่าเงินอย่างข้อมูลส่วนตัว เพราะพวกเขาแก้ปัญหาจริงได้
      ผมเห็นด้วยได้ยากกับแนวคิดเร่งย้อนกลับที่ว่าเราต้องทำให้อินเทอร์เน็ตแย่ลงสำหรับทุกคน ถึงจะมีโซลูชันที่ดีจริง ๆ โผล่มา
      ไม่ใช่เพราะ Tailscale ทำให้โซลูชันแบบนั้นไม่เกิดขึ้น แต่เป็นเพราะ ปริมาณงานมหาศาลที่ต้องทำเพื่อสร้างมัน และถ้าไม่มี WireGuard ก็มีความเป็นไปได้สูงว่า Tailscale จะไม่มีด้วย
      เมื่อ Tailscale เกิดขึ้น Headscale ก็เกิดขึ้นตามมา และนั่นก็เป็นอีกหนึ่งฐานตั้งต้นสำหรับการสร้าง “อะไรสักอย่าง” ที่ว่ามา
    • ที่แย่กว่านั้นคือ Tailscale มีแรงจูงใจให้ผู้ใช้ต้องใช้ coordination server ที่ช่วยทะลุ NAT และ firewall
      พูดยาว ๆ แต่แก่นคือโครงสร้างที่ Tailscale นั่งอยู่ตรงกลางระหว่างอุปกรณ์ที่กำลังหากัน
      ยังมีวิธีอื่นด้วย Dynamic DNS ที่ผูกชื่อถาวรให้กับอุปกรณ์ที่มีเพียง IP ชั่วคราวก็มีมาหลายสิบปีแล้ว แม้ชื่อเสียงจะไม่ค่อยดีนัก
      วิธีที่ใช้ coordination node หลายตัวที่รู้จักกันเองกับรายชื่อ node สาธารณะก็เป็นไปได้ ต่อให้รายชื่อเก่าแล้ว แค่มี node ที่ยังมีชีวิตอยู่สักตัวก็เชื่อมต่อเพื่ออัปเดตได้ และ Kademlia ซึ่งเป็นรากฐานของเครือข่าย Ethereum กับระบบแชร์ไฟล์บางส่วนก็ทำงานในลักษณะนี้
      การประนีประนอมด้วยการแยกการค้นหาออกจากการส่งข้อมูลก็ทำได้ Peertube ค้นหาไฟล์ที่จะสตรีมผ่าน HTTP จากเซิร์ฟเวอร์ที่หาเจอด้วยการค้นเว็บทั่วไป ส่วนการส่งจริงเป็นแบบกระจายศูนย์ที่ผู้ชมปัจจุบันส่งบล็อกให้กันเอง ทำให้ขยายตัวได้ดีแม้วิดีโอจะไวรัล
      ดังนั้นมันจึงเป็นไปได้อย่างเพียงพอในแบบที่ไม่มีใครอยู่ตรงกลางแล้วตัดสายออกซิเจนได้
    • ไม่ต้องการ “IPsec อัตโนมัติ” โดยเฉพาะ การทำ IPsec ให้เป็นอัตโนมัติ การใส่การเข้ารหัสแบบบังคับใน network layer นั้นเสี่ยง แม้ตามมาตรฐานปัจจุบันจะเป็นอะไรที่ดีอย่าง WireGuard ก็ตาม
      โปรโตคอล VPN เก่า ๆ หรือวิธีพิสูจน์ตัวตนอย่าง RADIUS ต่อให้มีช่องโหว่ความปลอดภัยร้ายแรง ก็แก้ยากเพราะต้องรักษาความเข้ากันได้ และสิ่งเหล่านั้นยังทำงานในสเกลที่เล็กกว่าอินเทอร์เน็ตทั้งใบมาก
      ข้อเท็จจริงที่ว่าอุตสาหกรรมกำลังแก้ปัญหา ossification ของ TCP ด้วยการทิ้ง TCP แล้วนำไปสร้างใหม่บน UDP นั้นบอกอะไรได้มาก
    • Zerotier ทำหน้าที่แบบนั้นได้ในระดับหนึ่ง เป็น tunnel ก็จริง แต่ทราฟฟิกวิ่งตรง และถ้าไม่ใช่ double NAT ก็อาจข้าม zt ได้เมื่อสามารถ route ตรงไปยัง IP ของ endpoint
      Location service ก็ โฮสต์เองได้ถ้าต้องการ ดังนั้นไม่จำเป็นต้องใช้บริการของเขาเสมอไป
      ถ้าไม่นับ DNSSEC ก็ถือว่าคล้ายกับสิ่งที่เรียกร้องอยู่พอสมควร
    • นั่นเป็นการตีความเชิงลบเกินไป value proposition ของ Tailscale ก็คือ “เข้าถึงเครือข่ายได้อย่างปลอดภัยจากทุกที่ และคนอื่นเข้าไม่ได้” ด้วย
      คุณค่านี้ไม่ได้หายไปเพียงเพราะมี IPsec

  • เริ่มด้วยการบ่นยาวมากเรื่องการควบคุมแบบรวมศูนย์ที่รีดค่าเช่า ซึ่งตัวมันเองก็เป็นความไม่พอใจที่สมเหตุสมผล
    แต่แล้วก็หลุดไปประเด็นแยกต่างหากอย่าง client-server computing มีเหตุผลไหม หรือมันเป็นสาเหตุของการแสวงหารายได้แบบค่าเช่าหรือไม่ ก่อนจะลงท้ายด้วยข้อสรุปว่า “พรุ่งนี้จะแบ่งเป็นคนที่มี Tailscale กับคนที่ไม่มี”
    ให้ความรู้สึกเหมือนราชาตายแล้ว ขอพระราชาองค์ใหม่จงเจริญ

    • ผมเห็นด้วยว่าระบบ peer-to-peer แบบ proprietary ก็รีดรายได้แบบค่าเช่าได้ แต่ผมยังใช้ เครื่องมือที่ไม่ใช่ proprietary ซึ่งเก่ากว่า Tailscale และไม่ใช่ OpenVPN อยู่
      มันเล็กและเรียบง่ายพอที่คนไม่ใช่โปรแกรมเมอร์อย่างผมก็แก้ได้
      ไม่ใช่ทุกคนจะมี IP บนอินเทอร์เน็ตที่เข้าถึงได้โดยตรงและไม่มี firewall ดังนั้นเพื่อให้ได้ peer-to-peer ก็อาจต้องใช้ client-server ได้
      อาจต้องตั้ง “supernode” ไว้บนเซิร์ฟเวอร์ของบริษัทโฮสติ้ง แต่ถ้าใช้เป็นแค่ rendezvous server ทราฟฟิกก็ไม่วิ่งผ่าน ค่าใช้จ่ายจึงน้อย
      ผมมักจะสงสัยบริษัทที่พยายามแข่งกับ “ของฟรี” อย่างมากเสมอ แนว ๆ ว่าเลิกใช้ซอฟต์แวร์ฟรีแล้วมาจ่ายเงินให้เราเถอะ แลกกับฟีเจอร์ไม่จำเป็นอีก 100 อย่างที่เราใส่เพิ่มให้
      กลยุทธ์องค์กรแบบนี้อาจสำเร็จระยะสั้นได้เหมือน Slack แต่ subscription แบบนี้ไม่ใช่รสนิยมของผม
      ผมมองว่าแก่นไม่ใช่ client-server ปะทะ peer-to-peer แต่คือ proprietary ปะทะ non-proprietary
    • CEO ของ Tailscale กำลังเทศนาว่า “พรุ่งนี้จะแบ่งกันที่ว่ามี Tailscale หรือไม่ และถ้าไม่มี คุณจะรันแอปที่ทำงานได้เฉพาะในโลกหลัง Tailscale ไม่ได้” อย่างนั้นหรือ?
      ถ้าภายใน 10 ปีไม่ได้กลายเป็นยักษ์ระดับ Microsoft ก็คงยากที่จะถูกมองในแง่ดี
    • ตลอดหลายสิบปีที่ผ่านมา ผมค่อนข้างคิดถึง Hamachi
      ตอนนั้นมันเป็นเครื่องมือที่ยอดเยี่ยมและใช้ง่ายมากสำหรับออกแบบและตั้งค่าเครือข่ายส่วนตัวของตัวเอง การแชร์ไฟล์, LAN เกมในเครื่อง, การทำงานพัฒนาร่วมกัน หรือแม้แต่การสตรีมมีเดียก็ทำได้ง่าย
      อนาคตของ peer-to-peer น่าจะใกล้เคียงกับ Hamachi รุ่นที่โฮสต์เอง ซึ่งโดยทั่วไปผูก node ที่อยู่หลัง NAT และ ASN ต่างกันเข้าด้วยกัน และเข้าใจเทคนิคการทะลุ NAT, STUN/TURN, turtle routing มากกว่าจะเป็น Tailscale
      ถ้าเป็นเครื่องมือที่ผู้ใช้ระยะไกลเข้าร่วมได้ง่ายโดยไม่ต้องมี VPN gateway ส่วนกลาง นั่นจะเป็นฟีเจอร์ที่ทรงพลังในสภาพแวดล้อมสมัยใหม่
    • ฟังดูเหมือนโครงสร้างที่บอกว่านักแสวงหารายได้แบบค่าเช่านั้นแย่ แต่ก็ขอให้ผมจ่ายค่าเช่าให้คุณเพิ่มจากค่าเช่าที่จ่ายอยู่แล้ว
    • เห็นด้วยกับคำว่า “บทนำยาวมหาศาล”
      คงดีถ้าเราทุกคนเรียนรู้และนำ Iceberg Articles ไปใช้: https://john.kozubik.com/pub/IcebergArticle/tip.html

  • ในทางปฏิบัติใช้งาน Tailscale กับระบบโปรดักชันอยู่ เซิร์ฟเวอร์อยู่ในที่ที่ใกล้ทางกายภาพหรือในตำแหน่งอื่นที่ควบคุมได้ และผู้ใช้หลายร้อยคนที่อยู่ห่างออกไปหลายร้อยกิโลเมตรก็ทำงานผ่าน Tailscale กันทั้งหมด
    มีสองอย่างที่ต้องพูด Tailscale นั้นน่าทึ่งและดีมากจริง ๆ ระบบนี้คงไม่มีทางมีอยู่ได้ถ้าไม่มี Tailscale หรือไม่ก็ต้องมีคนเพิ่มในทีมอย่างน้อย 10 คนเพื่อให้รันได้ตลอด 24 ชั่วโมง
    แต่ต้องลดความคาดหวังลงหน่อย มันไม่ได้ดีเท่ากับ “อินเทอร์เน็ต” ค่า latency กระโดดเป็นระยะ ๆ การเชื่อมต่อหลุดเป็นครั้งคราว และ MagicDNS ก็หยุดทำงานแบบราวกับมีเวทมนตร์ตามชื่อ หรือไม่ก็ชนกับระบบ
    เพราะมีผู้ใช้จำนวนมาก เลยเจอปัญหาแทบทุกอย่างที่พอจะเจอได้แล้ว และพรุ่งนี้ก็อาจมีปัญหาใหม่โผล่มาอีก
    ถึงอย่างนั้นก็ยังเชื่อใน Tailscale และวิสัยทัศน์ของมัน นี่เป็นแนวทางใหม่โดยสิ้นเชิงที่ให้สิทธิ์ควบคุมฮาร์ดแวร์ พร้อมลดต้นทุนและเพิ่มความปลอดภัย
    เซิร์ฟเวอร์โปรดักชันขนาดใหญ่ตัวแรกคือ แล็ปท็อป Linux แบบ 4 คอร์

    • อยากฟังรายละเอียดเพิ่มเติมเกี่ยวกับการตั้งค่าที่ใช้แล็ปท็อป Linux แบบ 4 คอร์เป็นเซิร์ฟเวอร์โปรดักชันผ่าน Tailscale
      ผมเองก็ใช้ Tailscale ได้ดีสำหรับ self-hosting ภายใน แต่ไม่เคยคิดจะใช้กับบริการโปรดักชันสาธารณะ เลยสงสัยว่าตั้งค่าอย่างไร
    • ถ้าผู้ใช้หลายร้อยคนที่อยู่ห่างออกไปหลายร้อยกิโลเมตรทำงานผ่าน Tailscale แปลว่าบังคับให้ผู้ใช้ ติดตั้ง Tailscale หรือเปล่า?

  • ผมชอบ Tailscale แต่บทความนี้อ่านแล้วน่าขนลุก
    อินเทอร์เน็ตประสบความสำเร็จเพราะสร้างบนมาตรฐานและเปิดเสรีอย่างสมบูรณ์
    ใน Tailscale นั้น WireGuard เป็นโอเพนซอร์ส และก็มีของอย่าง Headscale แต่โครงสร้างแบบ “ทุกคนมี IP” ไม่ได้พึ่งพาการที่ Tailscale เป็นเจ้าของพื้นที่ที่อยู่ IP ขนาดมหึมาหรือ?
    ถ้าต้องรอให้ IPv6 แพร่หลายอย่างสมบูรณ์ หรือไม่ก็ต้องพึ่งพา IPv4 แบบรวมศูนย์ เซิร์ฟเวอร์ และสิ่งที่เป็นกรรมสิทธิ์ ก็ดูเหมือนหน้าไหว้หลังหลอกอยู่บ้าง

    • สามารถ self-host เซิร์ฟเวอร์ควบคุมของ Tailscale ด้วย Headscale ได้: https://github.com/juanfont/headscale
      แม้ฟีเจอร์จะยังไม่เทียบเท่า Tailscale แบบครบถ้วน แต่ตอนนี้รองรับฟีเจอร์ส่วนใหญ่แล้วและดีขึ้นทุกวัน
      ถ้าจำไม่ผิด หนึ่งในนักพัฒนาหลักได้รับค่าตอบแทนจาก Tailscale ให้ทำงานนี้
      ผมใช้กับโครงสร้างพื้นฐาน self-hosting ส่วนตัวอยู่ และมันทำงานได้ดีมาก การตั้งค่า URL ของเซิร์ฟเวอร์ควบคุมแบบกำหนดเองบน Windows และ Android ก็ค่อนข้างง่าย
      ใช้ taildrop ด้วย และยังเปิดให้ Docker container อยู่ใน tailnet ได้ด้วย Headscale ทำงานได้ดีพอสมควร น่าลองใช้
    • 100.64.0.0/10 เป็นบล็อก IP ที่สงวนไว้สำหรับ NAT ระดับผู้ให้บริการเครือข่าย
    • Tailscale ไม่ใช่ “อินเทอร์เน็ต” แต่เป็นชุดของ คูน้ำป้องกัน หลายแห่งที่แยกจากกัน จึงไม่จำเป็นต้องมีพื้นที่ IP ขนาดมหึมา
      พื้นที่ IP ที่ต้องใช้มีขนาดเท่ากับคูน้ำที่ใหญ่ที่สุดก็พอ และสามารถเชื่อมต่อได้ทีละคูน้ำเท่านั้น
    • ถ้าต้องย้ายออกจาก Tailscale จะย้ายไปที่ไหน?

  • ผมชอบ Tailscale แต่บทความนี้อ่านแล้วรู้สึกอวดตัวเองเกินไป
    มันเป็นผลิตภัณฑ์ mesh VPN ที่มีบริการเสริมพ่วงมา และตัวมันเองก็ดีมาก แต่ไม่ใช่ไอเดียใหม่หรือไอเดียเดียวในโลก
    ทำไมโซลูชันนี้ต้องเป็น อินเทอร์เน็ตใหม่ แทนที่จะเป็นทางเลือกอื่น?
    อย่างไรก็ตาม ผมไม่อยากให้โครงสร้างพื้นฐานอินเทอร์เน็ตทั้งหมดพึ่งพาบริษัทเดียว ดังนั้นแม้จะซับซ้อน ผมก็จะยังใช้อินเทอร์เน็ตแบบดั้งเดิมต่อไป
    ปัญหาใหญ่ ๆ เป็นเรื่องสังคมมากกว่าเทคโนโลยี และเทคโนโลยีใหม่ก็แก้ปัญหาเหล่านั้นไม่ได้

    • ปัญหาใหญ่ของอินเทอร์เน็ตในปัจจุบันเป็นเรื่องสังคมจริงหรือ? ถ้าปัญหาหลักคือคำสัญญาเดิมของเครือข่ายแบบกระจายศูนย์ 100% นั้นซับซ้อนเกินกว่าจะจัดการได้จริง จนบริการกลายเป็นแบบรวมศูนย์โดยธรรมชาติ นั่นก็ดูเป็น ปัญหาเชิงเทคนิค อย่างลึกซึ้ง
      ยกตัวอย่างโซเชียลมีเดีย ลองจินตนาการโลกที่ Facebook/Twitter/TikTok/YouTube/Reddit/HN ฯลฯ ทำงานได้ลื่นไหลเหมือน BitTorrent
      แอปในคอมพิวเตอร์ของผมเข้าร่วมเครือข่าย “Facebook” และเพื่อน ๆ เห็นว่าผมออนไลน์ผ่านอินสแตนซ์แอปของแต่ละคน ส่วนฟีดกับวอลล์ก็ให้บริการโดยตรงจากอุปกรณ์ของผม
      เป็นโครงสร้างที่คน 2 คน, 1000 คน หรือหลายล้านคนสื่อสารกันโดยตรงโดยไม่มีเซิร์ฟเวอร์กลาง
      BitTorrent, Soulseek, Bitcoin และเครือข่าย peer-to-peer อื่น ๆ หลายตัวได้แสดงให้เห็นความเป็นไปได้แล้ว
      แต่ถ้าจะทำให้ลื่นไหลเท่ากับการเข้า facebook.com ปัญหาเชิงเทคนิคจะโผล่มาทั้งหมด อุปสรรคใหญ่ข้อแรกคือ การเชื่อมต่อ peer-to-peer ที่ลื่นไหล โดยไม่ต้องมี port forwarding, dynamic DNS หรือความรู้ขั้นสูงด้านเครือข่าย ความปลอดภัย และการดูแลระบบ
      ถ้าโหนดออฟไลน์จะทำอย่างไร เมื่อต้องเชื่อมต่อกับเครื่องนับพัน นับแสน หรือนับล้านเพื่อดึงฟีด latency และโหลดจะเป็นอย่างไร จะทำแคชอย่างไร จะผลักอัปเดตและการแจ้งเตือนอย่างไร โหนดที่เก่ามาก ๆ จะสื่อสารกันอย่างไร ข้อมูลจะเก็บไว้ที่ไหน การค้นพบกันได้และความปลอดภัยจะทำอย่างไร ทั้งหมดนี้เป็นปัญหาเชิงเทคนิค
      ส่วนใหญ่แก้ได้ แต่การไปให้ถึงประสบการณ์ที่ง่ายเหมือนบริการรวมศูนย์แบบไม่ต้องคิดนั้นต้องใช้ความพยายามมหาศาลในการแก้ปัญหาทีละข้อ
      Fediverse ก็แก้เพียงส่วนเล็ก ๆ ของปัญหานี้มานานกว่า 10 ปีแล้ว แต่จนถึงตอนนี้ หากอยากให้ประสบการณ์ใกล้เคียงหรือแย่กว่า twitter.com เล็กน้อย ก็ยังต้องมีผู้ดูแลระบบที่เก่งพอสมควร
    • คุณค่าที่ Tailscale เสนอคืออะไร? มันไม่ใช่แค่ วิธีแก้ขัด ที่เอาซอฟต์แวร์เสรีโอเพนซอร์สตัวใหญ่ ๆ หลายตัวมาร้อยเข้าด้วยกันหรือ?

  • Yggdrasil ไม่ใช่สิ่งที่พยายามจะเป็นอินเทอร์เน็ตใหม่หรอกหรือ? https://yggdrasil-network.github.io
    ถ้าไม่ใช่ แล้วทำไมต้องเป็น Tailscale โดยเฉพาะ ไม่ใช่ Netbird, Nebula, Netmaker หรือคู่แข่งรายอื่น?
    บทความเขียนได้ดีมาก แต่ให้ความรู้สึกแปลก ๆ เหมือนกำลังจะมีอะไรบางอย่าง เช่น การถูกซื้อกิจการ การเปลี่ยนผ่าน การแยกบริษัท หรือการปิดตัวตามมา คำว่า “นี่เป็นเพียงจุดเริ่มต้น” ก็ฟังเหมือนคำพูดสุดท้ายอันโด่งดัง
    เพื่อความสมดุล ขอเสริมว่าในฐานะผู้ใช้ Tailscale ผมพอใจกับมัน และประทับใจที่มันทำงานได้เองโดยแทบไม่ต้องใส่ใจ

    • จากคำอธิบายแล้ว Yggdrasil ดูจะตรงกว่า
      อย่างไรก็ตาม แม้มันจะทำงานได้ดี แต่ก็ต้องคำนึงว่ายังเป็น โปรเจกต์วิจัย อยู่

  • ผมใช้บริการ Tailscale อย่างสนุกและขอบคุณจริง ๆ แต่บทความนี้ไม่โดนใจ
    ผมชอบสุนทรพจน์ปลุกใจจาก CEO ที่สร้างแรงบันดาลใจ และเห็นด้วยว่าโลกคอมพิวติ้งมีแรงเสียดทานกับความซับซ้อนสำหรับนักพัฒนาเยอะจนน่าขัน แต่ Tailscale เองก็มีแรงเสียดทานของตัวเอง และไม่ได้กำลังมุ่งไปแก้ปัญหาในภาพใหญ่เลย
    เมื่อไม่กี่สัปดาห์ก่อน ผมเชิญพ่อเข้ามาใน tailnet ของผมเพื่อจะแก้ปัญหาคอมพิวเตอร์ผ่าน Remote Desktop พ่อกดยอมรับคำเชิญแล้ว และในเว็บอินเทอร์เฟซของโดเมน TS ก็เห็นอุปกรณ์ แต่ ping ไม่ได้
    ตอนนี้พ่อเกลียด Tailscale ไปแล้ว และเพราะผมเคยบอกไว้ว่ามันเจ๋ง ความน่าเชื่อถือของผมก็ลดลงด้วย ในสายตาพ่อ มันคือของที่ทำให้เสียเวลาและ “ทำงานไม่ถูกต้อง”

    • พ่อใช้ Windows หรือเปล่า? Windows Firewall ขึ้นชื่อว่าบล็อกทราฟฟิก ICMP และนี่เป็นปัญหาที่ Tailscale หรือ VPN แบบ peer-to-peer อื่น ๆ แก้ให้ไม่ได้
    • ไม่รู้ว่าเป็นปัญหาเดียวกันไหม แต่ผมเคยเจอปัญหาในสภาพแวดล้อมครอบครัวที่ใช้แต่ที่อยู่ Gmail เพราะเข้าใจวิธีทำงานผิด
      มันค่อนข้างขัดกับสัญชาตญาณ ฟีเจอร์องค์กรไม่ได้มีไว้ใช้แบบนั้น แต่แต่ละคนควรสร้าง tailnet ของตัวเองแล้วเชื่อม tailnet เหล่านั้นเข้าหากันแทน
      อ้างอิง: https://github.com/tailscale/tailscale/issues/10731
    • มีความเป็นไปได้สูงว่าเกิด network interface ใหม่ขึ้นมา แล้วพ่อหรือ Windows ไม่ได้มองว่ามันเป็น การเชื่อมต่อบ้าน/ส่วนตัวที่เชื่อถือได้ ซึ่งอนุญาตให้ตอบ ping หรือ RDP ได้
      ถ้าเป็นงานแบบนี้ เครื่องมืออย่าง TeamViewer, AnyDesk ถึงจะเหมาะกว่า
    • อาจเป็นปัญหา ACL ได้ไหม?

  • ผมมองว่าผู้เขียนวินิจฉัยปัญหาผิด และทางออกที่เสนอไม่ได้ลบศูนย์กลางออกไป แต่แค่ซ่อนมันไว้
    เหตุผลที่ AWS แพงไม่ใช่เพราะ IPv4 หรือศูนย์ข้อมูล แต่หลัก ๆ เพราะซอฟต์แวร์ บริการแบบ managed และความสามารถในการเพิ่มเซิร์ฟเวอร์ได้อย่างรวดเร็ว
    ถ้า “บริษัทที่จริงจัง” ไม่อยากจ่ายเงินให้ AWS หรือบริษัทคล้ายกัน ก็สามารถเช่าแร็กแล้วนำเซิร์ฟเวอร์ของตัวเองไปวางแบบ colocation ได้ และหลายบริษัทก็ทำแบบนั้นจริง ๆ
    ผมไม่เห็นด้วยว่า certificate ทำให้เกิดการรวมศูนย์ Certificate ไม่ได้แบ่งแยกคนมีและคนไม่มี และเทียบไม่ได้กับการมีหรือไม่มีเมนเฟรม
    การที่ HTTPS กลายเป็นสิ่งจำเป็นโดยพฤตินัย ไม่ได้ทำให้ผู้คนต้องมีโดเมนหรือซับโดเมนของตัวเอง แต่พวกเขามีอยู่แล้วเพราะความสะดวก
    อีกจุดรวมศูนย์หนึ่งคือ DNS แต่ Tailscale ก็ไม่ได้หลีกเลี่ยง DNS เลย MagicDNS ก็พึ่งพา ICANN root และ control plane ของ Tailscale ก็เช่นกัน
    ถ้าแค่ต้องการซับโดเมนฟรี มีหลายที่ที่ให้บริการอยู่แล้ว
    ถ้าอยู่หลัง CGNAT tailnet ก็ไม่ได้กระจายศูนย์มากกว่านัก เพราะทราฟฟิกต้องผ่านเซิร์ฟเวอร์ DERP
    ถ้าปริมาณทราฟฟิกไม่ใช่ระดับ Gbps แต่เป็น Tbps ผมสงสัยว่า Tailscale จะให้บริการแบบนี้ฟรีต่อไปได้หรือไม่
    ผมเห็นด้วยว่าโซลูชันคล้าย Tailscale มีประโยชน์ในกรณีสุดท้ายที่เหลืออยู่ คือการเข้าถึงคอมพิวเตอร์ที่อยู่หลัง NAT และอาจไปถึงผู้ใช้หลายสิบล้านคนได้
    แต่แค่นี้ยังไม่พอจะอ้างชื่อว่าเป็น อินเทอร์เน็ตใหม่

    • นี่ตั้งอยู่บนสมมติฐานที่ผิดว่าแอปพลิเคชันส่วนใหญ่ต้องการสเกลระดับที่ต้องเพิ่มเซิร์ฟเวอร์อย่างรวดเร็ว
      ในบทความเองก็ชี้ว่าสมมติฐานนั้นผิด

  • แนวคิดแบบนี้แน่นอนว่าไม่ใช่ของใหม่
    IPv6 ถูกสร้างมาเพื่อให้ทุกคนมี การเชื่อมต่อแบบ end-to-end และเดิมที IPsec เป็นองค์ประกอบบังคับของ IPv6 เพื่อมอบตัวตนเชิงเข้ารหัสให้กับโฮสต์อินเทอร์เน็ตแต่ละตัว

    • ผมสงสัยว่าทำไมบทความไม่พูดถึง IPv6 เลย ทั้งที่ Tailscale ก็รองรับ IPv6
      ถ้าใช้ IPv6 ร่วมกับ WireGuard ก็จะได้ความเป็นส่วนตัว ความปลอดภัย และประสิทธิภาพ ข้อเสียคือความซับซ้อนในการตั้งค่า
      Tailscale ยืนอยู่บนไหล่ของยักษ์ ทั้ง IPv4, WireGuard, NAT punching ของ Samy Kamkar, OpenSSH และน่าจะมีอีกมาก
      ข้อดีคือมันนำสิ่งเหล่านี้มาประกอบเข้าด้วยกัน และมีอินเทอร์เฟซจัดการที่โดยรวมใช้ง่าย
      อย่างไรก็ตาม สิ่งที่พูดถึง certificate authority ก็ใช้กับ Tailscale ได้เช่นกัน ทั้งคู่ใช้ซอฟต์แวร์เสรีโอเพนซอร์สเพื่อสุดท้ายแล้วให้บริการเป็น บริการ proprietary
      ถึงอย่างนั้น ก็ไม่ใช่ปัญหาใหญ่ เพราะแทบทุกอย่างอยู่บนซอฟต์แวร์เสรีโอเพนซอร์ส และมี Headscale ด้วย อีกทั้ง Tailscale ก็ดูจะมองเรื่องนี้ในทางที่ดี
      มันเป็นข้อเสียก็จริง แต่ไม่ใช่ข้อเสียหลัก และในทางปฏิบัติแทบไม่มี vendor lock-in ด้วยซ้ำ จากมุมมองธุรกิจและการสนับสนุน อาจเป็นข้อดีเสียด้วยซ้ำ

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

    • ประเด็นเรื่อง “ต้องพึ่งพาผู้ให้เช่า” เป็นข้อสังเกตที่ดีมาก
      ข้อโต้แย้งคือการโฮสต์ Headscale เอง ซึ่งมีคนพูดถึงในที่อื่นด้วย: https://github.com/juanfont/headscale
      แค่เปลี่ยนการตั้งค่าไม่กี่อย่างก็ทำงานร่วมกับไคลเอนต์ Tailscale มาตรฐานได้ และผมก็ใช้อยู่เอง