เหตุการณ์ขัดข้องของ Tailscale.com เมื่อวันที่ 7 มีนาคม 2024
(tailscale.com)- เมื่อวันที่ 7 มีนาคม 2024 tailscale.com หยุดให้บริการประมาณ 90 นาทีเนื่องจาก ใบรับรอง TLS หมดอายุ แต่ผลกระทบส่วนใหญ่อยู่ที่เอกสารและเว็บไซต์การตลาด
- ปัญหาปรากฏขึ้นราว 90 วันหลังจากการปรับปรุงเว็บไซต์และย้ายไปยังโฮสติ้งใหม่ในเดือนธันวาคม 2023 โดยการตั้งค่า พร็อกซีที่ทำเอง เพื่อชดเชยสภาพแวดล้อมที่ไม่รองรับ IPv6 ได้ขัดขวางการต่ออายุอัตโนมัติ
- โพรบเบอร์สำหรับเฝ้าระวังการหมดอายุของใบรับรองตรวจสอบเฉพาะ เส้นทาง IPv6 และวิ่งผ่านพร็อกซีที่มีใบรับรองที่ถูกต้องแยกต่างหาก จึงพลาดการแจ้งเตือนว่าใบรับรองจริงของ tailscale.com และ www.tailscale.com ใกล้หมดอายุ
- การใช้งาน Tailscale ทั่วไปส่วนใหญ่ไม่หยุดชะงัก แต่มีผลกระทบต่อ เอกสาร, บล็อก, install.sh และโฟลว์การเข้าถึงคอนโซลจัดการของผู้ใช้ที่ไม่รู้ URL โดยตรง
- Tailscale กู้คืนด้วยการลบเรคคอร์ด AAAA เพิ่มเติมและต่ออายุด้วยตนเอง และตั้งเป้ารองรับ IPv6 อย่างตรงไปตรงมามากขึ้น หลังผ่านระบบต่ออายุด้วยตนเองระยะสั้นและการตรวจสอบ IPv4/IPv6 แยกกัน
เหตุผลที่พลาดการหมดอายุของใบรับรอง
- เมื่อวันที่ 7 มีนาคม 2024 ใบรับรอง TLS ของ tailscale.com และ www.tailscale.com หมดอายุ ทำให้การเข้าถึงไซต์หยุดชะงักประมาณ 90 นาที
- ในเดือนธันวาคม 2023 Tailscale ย้ายไปยังผู้ให้บริการโฮสติ้งรายใหม่พร้อมกับการปรับปรุงเว็บไซต์ครั้งใหญ่
- เนื่องจากผู้ให้บริการโฮสติ้งรายใหม่ไม่รองรับ IPv6 เป็นค่าเริ่มต้น Tailscale จึงดำเนินพร็อกซีของตนเองเพื่อจัดการคำขอ IPv6 และตั้งค่า เรคคอร์ด AAAA เพิ่มเติม
- ผู้ให้บริการโฮสติ้งมองการตั้งค่านี้ว่าเป็น “misconfiguration” และส่งการแจ้งเตือนมา แต่ในแจ้งเตือนไม่ได้ระบุว่าการตั้งค่านี้จะขัดขวางการต่ออายุใบรับรองอัตโนมัติให้เสร็จสมบูรณ์
- โพรบเบอร์ สำหรับเฝ้าระวังการหมดอายุของใบรับรองตรวจสอบเฉพาะเส้นทาง IPv6
- โพรบเบอร์วิ่งผ่านพร็อกซีที่ทำเอง
- พร็อกซีมีใบรับรองที่ถูกต้องซึ่งจัดการแยกต่างหาก
- ด้วยเหตุนี้ การหมดอายุของใบรับรองจริงของ tailscale.com และ www.tailscale.com จึงไม่ถูกพบล่วงหน้า
ผลกระทบที่ผู้ใช้เห็น
- ผลกระทบกระจุกอยู่ที่แหล่งข้อมูลและโฟลว์การติดตั้งที่พึ่งพาเว็บไซต์
- เอกสาร Tailscale, บล็อก และเอกสารอ้างอิงอื่น ๆ ที่อิงเว็บไซต์ไม่สามารถเข้าถึงได้ระหว่างเหตุขัดข้อง
- คอนโซลจัดการและหน้าตั้งค่าเองไม่ได้รับผลกระทบ แต่ผู้ใช้ที่ไม่รู้วิธีไปที่
https://login.tailscale.com/โดยตรงอาจคิดว่าหน้านั้นออฟไลน์อยู่ - ไม่สามารถใช้ สคริปต์ติดตั้งแบบรวดเร็ว ได้ ส่งผลต่อการติดตั้งบางส่วนและการติดตั้งอัตโนมัติ
- โดเมนที่ให้บริการติดตั้งแพ็กเกจ Tailscale จริง ๆ ยังเข้าถึงได้ และมองว่าการหยุดชะงักของการ resolve ผ่านกลไก
go getของ Go มีน้อยมากด้วย การแคช - ด้วยการออกแบบของ Tailscale ผู้ใช้ส่วนใหญ่ไม่ได้ประสบการหยุดชะงักจากเหตุขัดข้องครั้งนี้ในกรณีใช้งานส่วนใหญ่ และด้วยหลักการเชื่อมต่อโดยตรง เครือข่ายจึงพึ่งพาความพร้อมใช้งานทันทีของเอนด์พอยต์เฉพาะอย่าง tailscale.com น้อยลง
การกู้คืนและการป้องกันไม่ให้เกิดซ้ำ
- หลังยืนยันปัญหาแล้ว Tailscale ได้ลบ เรคคอร์ด AAAA “เพิ่มเติม” ออกชั่วคราว และต่ออายุใบรับรองที่เกี่ยวข้องด้วยตนเอง
- การดำเนินการนี้แก้เหตุขัดข้องที่ผู้ใช้มองเห็นได้ทันที และมีการกู้คืนเรคคอร์ดกลับมาในไม่นานเพื่อให้บริการไซต์และบริการผ่าน IPv6
- ปัญหาการต่ออายุอัตโนมัติยังคงอยู่ ดังนั้นในระยะสั้นจึงมีแผนต่ออายุใบรับรองโดยตรง โดยใช้การแจ้งเตือนปฏิทินซ้ำซ้อนและช่วงเวลาต่ออายุด้วยตนเองที่กำหนดไว้
- โครงสร้างพื้นฐานของโพรบเบอร์จะได้รับการอัปเดตให้ตรวจสอบ เอนด์พอยต์ IPv4 และ IPv6 แยกกัน
- ในระยะยาว ตั้งเป้าให้โครงสร้างพื้นฐานเว็บไซต์รองรับ IPv6 อย่างตรงไปตรงมามากขึ้น เพื่อให้ไม่ต้องใช้พร็อกซีที่ทำเอง
1 ความคิดเห็น
ความเห็นจาก Hacker News
ตอนนี้มองได้ว่าใบรับรองที่หมดอายุคือ DNS ตัวใหม่ที่ทำให้เกิดเหตุขัดข้อง
ถึงอย่างนั้นก็ยังน่าทึ่งอยู่ดีว่า Tailscale ถูกสร้างมาได้ดีแค่ไหน ผมค่อนข้างเป็นผู้ใช้เบา ๆ แต่ก็ใช้ Tailscale เพื่อเข้าถึงทั้งเซิร์ฟเวอร์ on-premises ไม่กี่เครื่องและสภาพแวดล้อม production บน AWS
ทำให้ทำงานจากที่ไหนก็ได้ ช่วงสุดสัปดาห์ผมจะ deploy คอนเทนเนอร์ ECS แต่ Wi‑Fi ที่บ้านช้าเกินไปจน deployment timeout ตลอด
สุดท้ายเลย SSH เข้าเครื่องพัฒนา on-premises,
git pullโค้ดล่าสุด แล้ว deploy จากที่นั่น ทั้ง on-premises และ AWS ก็ยังปลอดภัยโดยไม่ต้องเปิดพอร์ต และถ้ารันแค่ Tailscale agent บน EC2 เครื่องเล็ก ๆ ใน AWS ก็สามารถทดสอบฐานข้อมูล Aurora ใน production ได้โดยไม่ต้องเปิดพอร์ตเช่นกันเวลาต้องให้สิทธิ์เข้าถึงเครือข่ายกับนักพัฒนาคนอื่น Tailscale ก็ทำได้ง่ายมาก และการเพิกถอนสิทธิ์ก็ง่ายเหมือนกัน deployment นี้จะทำผ่านอะไรอย่าง GitHub Actions เพื่อหลบปัญหาอินเทอร์เน็ตแย่ ๆ ก็ได้ แต่ผมอยากทำเองแบบแมนนวล และ Tailscale ก็ทำให้ทำแบบนั้นได้
ต่อไปผมตั้งใจจะใช้แอ็กชันนี้ เพื่อให้ GHA worker ตัวไหนก็ได้เข้าถึงเครื่อง deploy โดยไม่ต้องเปิดเผยพอร์ต: https://github.com/tailscale/github-action
ใบรับรองหมดอายุทำเรื่องอีกแล้ว
ส่วนหนึ่งของ postmortem ผมแนะนำให้แยกสคริปต์ติดตั้งออกจากเว็บไซต์การตลาด หรือมีเส้นทางสำรองอื่นไว้ด้วย แบบนั้น กิจกรรมบนเว็บไซต์การตลาด จะได้ไม่ไปผูกกับเส้นทางสำคัญของการปฏิบัติการลูกค้า เรื่องแบบนี้เกิดบ่อยอยู่แล้ว เลยยิ่งน่าเสียดายเพราะจริง ๆ ก็เกือบจะทำ isolation ตามปกติได้ครบอยู่แล้ว
ถ้าติดตาม uptime ของผู้ให้บริการหลายเจ้า จะเห็นว่าบางส่วนของเว็บไซต์ GitHub หรือ Zendesk ล่มบ่อยกว่าที่คิด อย่างน้อยสองเจ้านี้ก็ยังถือว่าเป็นตัวอย่างที่ดี
ดูเหมือนว่า Cloudflare จะช่วยจัดการเรื่องนี้ได้พอสมควรถ้าโฮสต์โดเมนไว้กับเขา แต่ก็มีเงื่อนไขว่าต้องใช้ Cloudflare
เหมือนกับความผิดพลาดที่ผมเคยทำไว้ที่บริษัทเก่า เราใส่ลิงก์ไปยังหน้า login ของเว็บแอป
app.foo.comไว้บนหน้าแรกของเว็บไซต์การตลาดwww.foo.comกว่าจะเกิดเหตุเว็บไซต์การตลาดล่มครั้งแรก เราถึงได้รู้ว่า แพ็กเกจโฮสติ้งเดือนละ 40 ดอลลาร์ ไม่ได้เป็นแค่เว็บไซต์การตลาดธรรมดา แต่เป็นโครงสร้างพื้นฐานสำคัญจริง ๆ มันคือโฮสติ้งราคา 40 ดอลลาร์ที่รับโหลดจริงตามตัวอักษร แอปไม่ได้ล่ม แต่ผู้ใช้คิดว่ามันล่ม
ผมได้เรียนรู้ว่าผู้ใช้มักแค่เดินตามเส้นทางที่เราสร้างไว้ให้ และไม่รู้ด้วยซ้ำว่ามีทางอื่นอยู่ ถ้าเอาเส้นทางนั้นออกไปเพียงทางเดียว ผู้ใช้บางส่วนก็จะหลงทางไปเลย
tailscaleในเบราว์เซอร์ ผลลัพธ์แรกคือtailscale.comผมไม่ได้ใช้ Tailscale admin console บ่อยพอที่จะต้องจำ URL อื่นเมื่อก่อนถ้าพิมพ์
cloudflareเบราว์เซอร์จะ autocomplete เป็นdash.cloudflare.comแต่หลังจากผมเข้าเว็บไซต์cloudflare.comแค่ครั้งเดียว มันก็กลายเป็นผลลัพธ์แรก และผมก็ทำแบบเดียวกันกับ Cloudflareทีมนี้ดีมากจริง ๆ แต่ผมว่าราคาสูงเกินไป การควบคุมการเข้าถึง ที่เหมาะสมสำหรับ VPN ราคา 18 ดอลลาร์ต่อเดือนนี่แทบจะขายให้ผู้บริหารไม่ได้เลย และ tier ที่ต่ำกว่านั้นก็ขายยากถ้าไม่มีฟีเจอร์นี้
ตัวเลือกที่ถูกกว่าคืออะไร และของพวกนั้นมีทั้งความสามารถด้าน SSH, การยืนยันตัวตนเครือข่ายแบบ OAuth สำหรับบริการอัตโนมัติ, การตั้งค่า VPN node load balancer ภายใน Kubernetes cluster, และการทำคำขอ ACME certificate ผ่าน Let’s Encrypt แบบอัตโนมัติหรือไม่
แค่ไล่ฟีเจอร์ที่ใช้อยู่ใน free tier ก็มีหลายอย่างแล้วที่ปกติไม่ได้นึกว่าเป็นหน้าที่ของบริการ VPN ฟีเจอร์ก็ยังเพิ่มขึ้นเรื่อย ๆ เลยคิดว่าเป็นตัวเลือกที่น่าสนใจและแข่งขันได้มาก จริง ๆ ผมกลับแปลกใจด้วยซ้ำว่า tier ราคาถูกให้มาเยอะขนาดนี้ เลยยิ่งอยากรู้ว่าทำไมถึงประเมินแบบนั้น
มีผลิตภัณฑ์คู่แข่งบางตัวที่ทับซ้อนกับ Tailscale อยู่บ้าง และอาจไม่ตรงกับสิ่งที่ต้องการทั้งหมด
แต่ภายในไม่กี่นาที มันก็ทำให้บางส่วนของโปรเจ็กต์ทำงานเข้ากันได้ดีกว่าเดิมมาก
เมื่อเทียบกับสิ่งที่มันทำ นี่เป็นหนึ่งในเครื่องมือที่เรียบง่ายอย่างหาได้ยากจริง ๆ และ free tier ก็ให้มาค่อนข้างเยอะที่อุปกรณ์ 100 เครื่องกับผู้ใช้ 3 คน
แน่นอนว่าด้วยบทบาทของผม ผมมีอิทธิพลพอสมควรในการโน้มน้าวผู้บริหารเรื่องแบบนี้ แต่ราคาก็ไม่ใช่ปัญหา
เราเป็นลูกค้าที่ใช้อย่างพอใจมาตั้งแต่เดือนเมษายนปีที่แล้ว และทุกคนใช้ระดับพรีเมียม หรือก็คือ tier แพง การพัฒนาฟีเจอร์ก็รวดเร็วมาก บางฟีเจอร์ที่บอกว่าอาจใช้เวลาหลายปี สุดท้ายก็ออกมาตั้งแต่ปีที่แล้วแล้ว
Cloudflare One ก็อาจเป็นทางเลือกได้เหมือนกัน แต่คงจะแพงกว่าอีก
สงสัยว่าใช้ผู้ให้บริการเว็บไซต์เจ้าไหนอยู่ เพราะผู้ให้บริการอื่นแทบทั้งหมดรองรับ IPv6 กันแล้ว เลยฟังดูแปลกที่ต้องมีวิธีอ้อมเยอะแบบนี้เพราะ IPv6
$ host www.tailscale.comจะเห็นว่า IPv4 address76.76.21.21ของwww.tailscale.comคือ Vercel ส่วน IPv6 address เป็นของ Amazonฝั่ง IPv4 ใช้ใบรับรอง Let’s Encrypt และฝั่ง IPv6 ใช้ใบรับรองของ Amazon
น่าอิจฉาจริง ๆ ที่ระบบ CI/CD และการมอนิเตอร์ แข็งแรงพอจะกล้าโรลเอาต์ครั้งใหญ่ในเดือนธันวาคมได้ วัฒนธรรมวิศวกรรมก็ดูแข็งแกร่งมาก
แต่ก็ยังมีคำถามที่ยังไม่ได้คำตอบอยู่บ้าง ถ้าการตั้งค่า IPv6 เป็นตัวที่ทำให้การต่ออายุใบรับรองอัตโนมัติของ IPv4 พัง ก็สงสัยว่าทำไมถึงไม่เจอปัญหานี้ตั้งนานแล้ว และก็สงสัยเหมือนกันว่าทำไมถึงใช้เวลาตั้ง 90 นาทีในการกู้เหตุขัดข้อง แม้นี่จะเป็นโพสต์บล็อกไม่ใช่ postmortem แบบจริงจัง แต่อย่างน้อยถ้ามีไทม์ไลน์สั้น ๆ ก็น่าจะดี
อีกอย่างก็สงสัยว่าทำไมถึงไม่ย้ายไปใช้ผู้ให้บริการ DNS ที่รองรับ IPv6 แบบเนทีฟ และภาระในการดูแลโดเมนแยกสำหรับสคริปต์หรือแพ็กเกจนั้นคุ้มค่าจริงหรือไม่ ไม่รวมบุคคลที่สามอย่าง package repository ก็ยังสงสัยว่าที่อื่นก็ทำแบบนี้กันหรือเปล่า
ไม่เข้าใจว่าทำไมพร็อกซีต้องเป็นตัว terminate TLS ถ้าเป็นแค่ TCP proxy อย่างน้อยระบบมอนิเตอร์ก็คงไม่เข้าใจผิดว่าการหมดอายุของใบรับรองยังไม่ใกล้เข้ามา
แถมถ้าการยืนยันโดเมนทำผ่าน TLS-ALPN challenge ด้วยแล้ว TCP proxy ก็น่าจะทำให้ต่ออายุอัตโนมัติได้ด้วย
ถ้าไม่ต้องการ IP ของผู้ใช้เลยก็ไม่ใช่ปัญหา แต่สำหรับ log และการตรวจจับการใช้งานในทางที่ผิด มันมักมีประโยชน์
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
ตอนที่เราพบอย่างเร่งด่วนว่า IPv6 พัง เราก็รีบตั้งพร็อกซีขึ้นมา และคนที่ตั้งพร็อกซีตอนนั้นไม่รู้ว่า ACME ทำงานอย่างไร
เราวางแผนจะเปลี่ยนเป็น TCP proxy ธรรมดา
ดูแล้ว Tailscale น่าจะใช้ NetActuate กับ
pkgs.tailscale.comและถ้าเป็น NetActuate ก็ดูเหมือนว่าจะช่วยให้มี non-terminating proxy หลายจุดให้บริการได้ในราคาสมเหตุสมผล บนเว็บไซต์ไม่มีราคา แต่ก็ดูไม่เหมือนบริษัทที่บวกมาร์จินทราฟฟิกขาออก 50 เท่าถ้าองค์กรอย่าง Tailscale พลาดแม้แต่ครั้งเดียวในพื้นที่ที่เกี่ยวข้องกับความปลอดภัยไม่ว่าจะเล็กน้อยแค่ไหน สำหรับคนที่ค่อนข้างระแวงนิด ๆ แบบผม มันก็รู้สึกเสี่ยงเกินไป
ส่วนนี้น่าจะต้องมีคำอธิบายที่ดีกว่านี้
น่าจะมีการมอนิเตอร์อินฟราฯ อยู่แล้ว ดังนั้นก็แค่เพิ่มโค้ด 50 บรรทัด ที่เชื่อมต่อทุกโดเมนสาธารณะผ่านทั้ง IPv4 และ IPv6 แล้วแจ้งเตือนถ้าใบรับรองจะหมดอายุภายใน 19 วัน ส่วนการต่ออายุอัตโนมัติก็ให้รันล่วงหน้า 20 วันก็จบ
หลังจากพลาดการต่ออายุ SSL ไปสองสามครั้งในช่วงแรกของบริษัทเล็ก ๆ ผมก็เขียนโค้ดนี้ไว้เมื่อหลายปีก่อน และตั้งแต่นั้นมาก็ไม่มีเหตุขัดข้องเกี่ยวกับ SSL อีกเลย
ไม่ต้องมีคำเชิญในปฏิทิน และการแก้ที่ต้องทำก็มีแค่นี้เอง ใจความสำคัญคือส่วนที่บอกว่า “เราจะอัปเดตโครงสร้างพื้นฐานของ prober เพื่อตรวจสอบ endpoint ของ IPv4 และ IPv6 แยกจากกัน”
มีข้อความว่า “คอนฟิกนั้นถูกมองว่าเป็น การตั้งค่าผิดพลาด โดยผู้ให้บริการรายนั้น และเราได้รับคำเตือนมาอย่างต่อเนื่องนับตั้งแต่ดีพลอย”
งั้นแปลว่าได้รับคำเตือนเกี่ยวกับใบรับรองอยู่ 90 วันแล้วสุดท้ายใบรับรองก็ล้มเหลวอย่างนั้นหรือ?
ผมไม่ได้เห็นคำเตือนจริง ๆ เลยไม่รู้ว่าคำเตือนนั้นอธิบายข้อเท็จจริงนี้ไว้อย่างชัดเจนหรือไม่