Sự cố gián đoạn của tailscale.com xảy ra ngày 7 tháng 3 năm 2024

 (tailscale.com)
2 điểm bởi GN⁺ 2024-04-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Do chứng chỉ TLS của tailscale.com hết hạn vào ngày 7 tháng 3 năm 2024, trang web đã bị gián đoạn khoảng 90 phút, nhưng ảnh hưởng chủ yếu giới hạn ở tài liệu và trang marketing
  • Vấn đề lộ ra sau khoảng 90 ngày kể từ đợt cải tổ website vào tháng 12 năm 2023 và chuyển sang nhà cung cấp hosting mới; cấu hình proxy tự vận hành dùng để bù cho môi trường không hỗ trợ IPv6 đã cản trở việc tự động gia hạn
  • Trình thăm dò giám sát hết hạn chứng chỉ chỉ kiểm tra đường IPv6, đi qua proxy có chứng chỉ hợp lệ riêng nên đã bỏ lỡ việc tailscale.com và www.tailscale.com sắp hết hạn thực tế
  • Việc sử dụng Tailscale thông thường phần lớn không bị gián đoạn, nhưng tài liệu, blog, install.sh và luồng truy cập vào bảng điều khiển quản trị đối với người dùng không biết URL trực tiếp đã bị ảnh hưởng
  • Tailscale đã khôi phục bằng cách gỡ thêm bản ghi AAAA và gia hạn thủ công; sau quy trình gia hạn thủ công ngắn hạn và kiểm tra tách biệt IPv4/IPv6, công ty hướng tới hỗ trợ IPv6 trực tiếp hơn

Vì sao đã bỏ lỡ việc chứng chỉ hết hạn

  • Vào ngày 7 tháng 3 năm 2024, chứng chỉ TLS của tailscale.com và www.tailscale.com đã hết hạn, khiến việc truy cập website bị gián đoạn khoảng 90 phút
  • Tháng 12 năm 2023, Tailscale đã chuyển sang nhà cung cấp hosting mới cùng với một đợt cải tổ website quy mô lớn
  • Vì nhà cung cấp hosting mới không hỗ trợ IPv6 mặc định, Tailscale đã vận hành proxy riêng để xử lý các yêu cầu IPv6 và thiết lập thêm bản ghi AAAA
  • Nhà cung cấp hosting đã gửi cảnh báo và coi cấu hình này là “misconfiguration”, nhưng cảnh báo không nêu rõ rằng cấu hình đó ngăn việc tự động gia hạn chứng chỉ hoàn tất
  • Trình thăm dò dùng để giám sát việc hết hạn chứng chỉ chỉ kiểm tra đường IPv6
    • Trình thăm dò đi qua proxy tự vận hành
    • Proxy có chứng chỉ hợp lệ được quản lý riêng
    • Vì vậy, việc chứng chỉ thực tế của tailscale.com và www.tailscale.com sắp hết hạn đã không bị phát hiện trước

Ảnh hưởng mà người dùng nhìn thấy

  • Ảnh hưởng tập trung vào các tài nguyên và luồng cài đặt phụ thuộc vào website
    • Tài liệu Tailscale, blog và các tài liệu tham khảo khác dựa trên website không thể truy cập trong thời gian sự cố
    • Bản thân bảng điều khiển quản trị và trang cấu hình không bị ảnh hưởng, nhưng người dùng không biết cách truy cập trực tiếp https://login.tailscale.com/ có thể nghĩ rằng trang đó đang ngoại tuyến
    • Không thể dùng script cài đặt nhanh, khiến một số cài đặt và cài đặt tự động bị ảnh hưởng
  • Miền thực sự cung cấp việc cài đặt gói Tailscale vẫn truy cập được, và việc gián đoạn phân giải thông qua cơ chế go get của Go được cho là ở mức tối thiểu nhờ bộ nhớ đệm
  • Theo thiết kế của Tailscale, phần lớn người dùng không gặp gián đoạn trong đa số trường hợp sử dụng do sự cố lần này, và nhờ nguyên tắc kết nối trực tiếp, mạng ít phụ thuộc hơn vào khả năng sẵn sàng tức thời của một endpoint cụ thể như tailscale.com

Khôi phục và ngăn tái diễn

  • Sau khi xác nhận vấn đề, Tailscale đã tạm thời gỡ bản ghi AAAA “bổ sung” và gia hạn thủ công các chứng chỉ liên quan
  • Biện pháp này đã giải quyết ngay lập tức sự cố mà người dùng nhìn thấy, và các bản ghi sớm được khôi phục để tiếp tục phục vụ website và dịch vụ qua IPv6
  • Vấn đề với tự động gia hạn vẫn còn, nên trong ngắn hạn công ty dự định trực tiếp gia hạn chứng chỉ với hệ thống nhắc lịch trùng lặp và thời điểm gia hạn thủ công được chỉ định
  • Hạ tầng trình thăm dò sẽ được cập nhật để kiểm tra riêng endpoint IPv4 và IPv6
  • Về dài hạn, mục tiêu là hỗ trợ IPv6 trực tiếp hơn trong hạ tầng website để không còn cần proxy tự vận hành

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-01
Ý kiến trên Hacker News

  • Chứng chỉ hết hạn giờ có thể xem là DNS mới của các sự cố
    Dù vậy, tôi vẫn ngạc nhiên về việc Tailscale được làm tốt đến mức nào. Tôi gần như chỉ là người dùng nhẹ, nhưng đang dùng Tailscale để truy cập hai nơi: vài máy chủ on-premises và môi trường production trên AWS
    Tôi có thể làm việc ở bất cứ đâu. Cuối tuần tôi định triển khai một container ECS, nhưng Wi-Fi cục bộ quá chậm nên việc triển khai cứ bị timeout
    Vì vậy tôi SSH vào máy dev on-premises, git pull mã mới nhất rồi triển khai từ đó. Cả on-premises lẫn AWS đều an toàn mà không cần mở port, và chỉ cần chạy agent Tailscale trên một EC2 nhỏ trong AWS là cũng có thể kiểm thử cơ sở dữ liệu Aurora production mà không cần mở port
    Khi cần cấp quyền truy cập mạng cho lập trình viên khác, Tailscale cũng rất dễ dùng, và thu hồi quyền cũng vậy. Việc triển khai này cũng có thể xử lý bằng thứ như GitHub Actions để tránh vấn đề Internet kém, nhưng tôi muốn làm thủ công và Tailscale đã cho phép điều đó

    • Ngay cả khi triển khai bằng GitHub Actions, Tailscale vẫn hữu ích. Hiện tại tôi đang mở port SSH không chuẩn trên một VM đám mây để worker GHA có thể SSH vào và bắt đầu triển khai
      Sắp tới tôi định dùng action này để bất kỳ worker GHA nào cũng có thể truy cập máy triển khai mà không cần expose port: https://github.com/tailscale/github-action
    • Với kết nối không ổn định, tôi dùng mosh và GNU screen. Dù bị ngắt mỗi 10 giây, nó vẫn hoạt động tốt đến ngạc nhiên

  • Chứng chỉ hết hạn lại gây ra sự cố
    Trong phần postmortem, tôi khuyên nên tách script cài đặt khỏi site marketing, hoặc đặt một đường thay thế khác. Như vậy hoạt động của site marketing sẽ không liên quan đến critical path trong vận hành của khách hàng. Vì chuyện này khá phổ biến, và họ đã gần đạt được mức cô lập thông thường, nên lại càng đáng tiếc
    Nếu theo dõi uptime của nhiều nhà cung cấp, bạn sẽ thấy việc một phần site của GitHub hay Zendesk bị down xảy ra thường xuyên hơn tưởng tượng. Dù vậy, họ vẫn thuộc nhóm ví dụ tốt

    • Mức ưu tiên bảo mật của site marketing thường thấp hơn bản thân sản phẩm, còn script cài đặt thường nên được bảo vệ ở mức tương tự sản phẩm
    • Tôi tự hỏi có dịch vụ nào giám sát tất cả chứng chỉ và ngày hết hạn không
      Cloudflare có vẻ xử lý khá nhiều phần này nếu bạn host domain ở đó, nhưng điều kiện là phải dùng Cloudflare

  • Giống sai lầm ở công ty cũ của tôi. Trên trang chủ site marketing www.foo.com, chúng tôi đặt link đến trang đăng nhập web app app.foo.com
    Chỉ sau sự cố đầu tiên của site marketing, chúng tôi mới nhận ra gói hosting 40 đô la mỗi tháng không chỉ là một site marketing đơn giản mà là hạ tầng cốt lõi. Theo đúng nghĩa đen, đó là hosting 40 đô đang chịu tải. Ứng dụng không bị down, nhưng người dùng nghĩ là nó đã down
    Tôi học được rằng người dùng chỉ đi theo con đường chúng ta tạo sẵn, thường không biết còn đường khác; nếu loại bỏ một con đường đó, một phần người dùng sẽ hoàn toàn lạc lối

    • Nếu gõ tailscale vào trình duyệt, kết quả đầu tiên là tailscale.com. Vì không thường xuyên dùng console quản trị Tailscale, tôi không cố nhớ URL khác
      Trước đây khi nhập cloudflare, trình duyệt tự động hoàn thành thành dash.cloudflare.com, nhưng sau khi tôi truy cập website cloudflare.com đúng một lần, nó trở thành kết quả đầu tiên, và tôi cũng bắt đầu hành xử tương tự với Cloudflare

  • Đội ngũ này thật sự rất tốt, nhưng tôi nghĩ giá quá cao. Gần như không thể bán cho ban lãnh đạo việc kiểm soát truy cập đúng nghĩa lại tốn 18 đô la/tháng cho VPN, còn tier thấp hơn thì khó bán nếu thiếu chức năng đó

    • Tôi thật sự tò mò nội bộ họ đang so sánh Tailscale với cái gì. Tailscale làm được nhiều thứ hơn VPN đơn giản rất nhiều
      Lựa chọn rẻ hơn là gì, và chúng có cung cấp chức năng SSH, xác thực mạng OAuth cho dịch vụ tự động hóa, cấu hình load balancer cho node VPN trong cụm Kubernetes, tự động hóa yêu cầu chứng chỉ ACME qua Let’s Encrypt không?
      Chỉ liệt kê vài chức năng tôi đang dùng ở tier miễn phí thôi cũng đã có nhiều thứ thường không được xem là vai trò của một dịch vụ VPN. Tính năng vẫn liên tục được bổ sung, nên tôi thấy đây là một lựa chọn khá thú vị và cạnh tranh. Tôi còn ngạc nhiên vì tier giá thấp cung cấp quá nhiều, nên càng tò mò về đánh giá này
    • Vậy thì có thể cài headscale và tự host để dùng miễn phí
      Cũng có vài sản phẩm cạnh tranh trùng lặp một phần với Tailscale, và có thể không hoàn toàn khớp với thứ bạn muốn
      Tuy nhiên chỉ trong vài phút, một phần dự án đã vận hành ăn khớp hơn trước rất nhiều
      Đây là một trong những công cụ hiếm hoi thật sự đơn giản so với việc nó làm được, và tier miễn phí cũng khá rộng rãi với 100 thiết bị và 3 người dùng
    • Việc này rất dễ thuyết phục. Chúng tôi đã thoát khỏi cấu hình OpenVPN, và nhờ Tailscale, onboarding nhân viên mới cùng nhiều việc khác trở nên dễ thực hiện đúng cách hơn nhiều. Vì công ty hoàn toàn remote nên điều này càng quan trọng
      Tất nhiên, với vai trò của mình, tôi cũng có ảnh hưởng khá lớn trong việc thuyết phục ban lãnh đạo về chủ đề này, nhưng giá không phải vấn đề
      Chúng tôi là khách hàng hài lòng từ tháng 4 năm ngoái và tất cả đều dùng gói premium, tức tier đắt. Tốc độ phát triển cũng rất ấn tượng. Một số tính năng từng được nói có thể mất vài năm đã được phát hành ngay trong năm ngoái
      Cloudflare One cũng có thể là phương án thay thế, nhưng có lẽ sẽ đắt hơn
    • Tôi không biết kiểu lãnh đạo nào lại vấp ở mức 18 đô la mỗi tháng. Tính theo chi phí mỗi người thì đây gần như bằng 0 so với hàng chục thứ mua cho nhân viên
    • Đó là lý do chính đẩy chúng tôi sang Twingate. Sau khi dùng thử, tôi hơi thích chức năng routing của Twingate hơn. Không có nghĩa là tôi ghét Tailscale; chúng tôi dùng cả hai tùy mục đích

  • Tôi tò mò họ dùng nhà cung cấp website nào. Gần như mọi nhà cung cấp khác đều hỗ trợ IPv6, nên nghe khá lạ khi họ phải workaround nhiều như vậy vì IPv6

    • Nhìn vào kết quả $ host www.tailscale.com, địa chỉ IPv4 76.76.21.21 của www.tailscale.com là Vercel, còn các địa chỉ IPv6 là Amazon
      IPv4 dùng chứng chỉ Let’s Encrypt, còn IPv6 dùng chứng chỉ Amazon

  • Thật sự ghen tị vì họ có CI/CD và giám sát vững đến mức dám tin tưởng rollout quy mô lớn vào tháng 12. Văn hóa kỹ thuật trông khá mạnh
    Tuy nhiên vẫn còn một số câu hỏi chưa được trả lời. Nếu cấu hình IPv6 làm hỏng việc tự động gia hạn chứng chỉ của IPv4, tôi tò mò vì sao họ không gặp chuyện này từ sớm hơn nhiều. Tôi cũng tò mò vì sao mất đến 90 phút để khắc phục sự cố. Đây là bài blog chứ không phải phân tích hậu kiểm thật sự, nhưng giá mà có một timeline ngắn thì tốt
    Ngoài ra, tôi cũng thắc mắc vì sao họ không chuyển sang nhà cung cấp DNS hỗ trợ IPv6 native. Tôi cũng tự hỏi liệu gánh nặng vận hành khi tách riêng domain cho script hoặc package có đáng hay không. Trừ các bên thứ ba như kho package, tôi tò mò liệu những nơi khác cũng làm như vậy không

    • Theo tôi hiểu thì có vẻ họ đã chuyển sang cấu hình hiện tại 90 ngày trước sự cố. Chứng chỉ ban đầu được cài khi migration có thời hạn 90 ngày, nên sự cố xảy ra 90 ngày sau migration
    • Họ đang dùng Vercel, và Vercel không hỗ trợ IPv6

  • Tôi không hiểu vì sao proxy phải terminate TLS. Nếu chỉ là TCP proxy thì ít nhất hệ thống giám sát đã không nhầm tưởng rằng chứng chỉ chưa sắp hết hạn
    Hơn nữa, nếu họ xác thực domain bằng TLS-ALPN challenge thì TCP proxy có thể cũng đã cho phép tự động gia hạn

    • TCP proxy sẽ bỏ mất địa chỉ IP của người dùng, trừ khi dùng thứ như giao thức PROXY. Muốn vậy thì server HTTPS đích cũng phải hỗ trợ, và cũng cần cách ngăn người dùng không được ủy quyền tự chèn PROXY header của họ
      Nếu hoàn toàn không cần IP người dùng thì không thành vấn đề, nhưng nó thường hữu ích cho log và phát hiện lạm dụng
      https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
    • Không phải lý do quá lớn, nhưng HTTP/3 không chạy trên TCP, và vận hành UDP proxy có lẽ không vui vẻ gì
    • Không cần terminate TLS. Đó là một trong những sai lầm của chúng tôi và là hạng mục cần sửa
      Khi lần đầu phát hiện IPv6 bị hỏng, chúng tôi vội dựng proxy, và những người dựng proxy lúc đó không biết ACME hoạt động thế nào
      Chúng tôi sẽ chuyển sang TCP proxy đơn thuần
    • Proxy không terminate TLS rất phù hợp để đặt trên các dịch vụ như Hetzner. Nếu cấu hình CAA đúng cách, bạn chỉ giao cho nhà cung cấp phần độ trễ và tính sẵn sàng, đồng thời có thể tránh các dịch vụ đắt vô lý như CloudFront hoặc proxy dựa trên EC2
      Nhìn thì có vẻ Tailscale dùng NetActuate cho pkgs.tailscale.com. Với NetActuate, tôi nghĩ họ có thể giúp cung cấp proxy không kết cuối ở nhiều điểm hiện diện với giá hợp lý. Trên website không có giá, nhưng có vẻ không phải kiểu công ty cộng biên lợi nhuận 50 lần vào lưu lượng outbound
    • Có thể họ đã đặt AWS CloudFront CDN ở lớp trước cho IPv6. Làm vậy thì TLS sẽ bị terminate tại CloudFront, và theo tôi biết đó không phải là tùy chọn có thể tắt

  • Nếu một tổ chức như Tailscale chỉ cần vấp một lần ở bất kỳ mảng nào có dính dáng chút ít đến bảo mật, thì với một người hơi hoang tưởng như tôi, nó đã cảm thấy quá rủi ro
    Phần này cần một lời giải thích tốt hơn

  • Họ hẳn có giám sát hạ tầng, nên chỉ cần thêm 50 dòng code để truy cập tất cả domain công khai qua IPv4 và IPv6, rồi cảnh báo nếu chứng chỉ sẽ hết hạn trong vòng 19 ngày. Cho tự động gia hạn chạy trước 20 ngày là xong
    Hồi công ty còn nhỏ, sau vài lần bỏ lỡ gia hạn SSL, tôi đã viết đoạn code này từ nhiều năm trước, và từ đó không còn sự cố nào liên quan đến SSL
    Không cần lịch mời gì cả, bản sửa cần thiết chỉ có một thứ này. Phần cốt lõi là “cập nhật hạ tầng prober để kiểm tra riêng các endpoint IPv4 và IPv6”

  • Có đoạn nói “cấu hình đó bị nhà cung cấp xem là cấu hình sai, nên chúng tôi liên tục nhận cảnh báo kể từ sau khi triển khai”
    Vậy tức là họ nhận cảnh báo liên quan đến chứng chỉ suốt 90 ngày rồi chứng chỉ mới lỗi à?

    • Có vẻ gần với việc nhận cảnh báo liên quan đến DNS suốt 90 ngày hơn là cảnh báo chứng chỉ. Trước sự cố, có vẻ đội Tailscale không biết rằng nếu có bản ghi DNS IPv6/AAAA thì Vercel sẽ từ chối tự động gia hạn chứng chỉ
      Tôi chưa thấy cảnh báo thực tế nên không biết cảnh báo đó có nói rõ điều này hay không