【Hacker News搬运】关于Tailscale.com于2024年3月7日中断

[hackernews]

Title: About the Tailscale.com outage on March 7, 2024

关于Tailscale.com于2024年3月7日中断

Text:

hn link

Url: https://tailscale.com/blog/tls-outage-20240307

2024年3月7日，tailscale.com因TLS证书过期而无法访问约90分钟。我们能够快速识别并解决问题，停机时间主要限于我们的营销材料和文档，以下是一些例外。尽管任何意外的停机都是一个问题，但我们想借此机会详细说明发生了什么，影响是什么，以及我们采取了哪些措施确保不再发生。

发生的事情：我们在2023年12月推出了一个重大的网站刷新，包括迁移到新的托管服务提供商，就在停机前大约90天。细心的读者可能已经注意到这个细节是预示性的。我们的配置也有点不寻常：因为我们的托管服务提供商不支持IPv6，而IPv6对我们和我们的用户来说很重要，所以我们运行自己的代理来解决此类请求并在相应的地方列出“额外的”AAAA记录。该安排被认为是一个“配置错误”，自从推出以来我们就一直在收到关于它的警报。我们没有意识到（而且警报也没有说明）这个配置会阻止自动证书续签完成。还有一点不幸：尽管我们有过期证书检查的探测器，但它们只通过IPv6进行检查。因此，我们的探测器没有 surfacing 即将到期的证书，因为它们击中了代理——它有一个有效的证书，我们正在独立管理。

在自动续签缺席的情况下，tailscale.com和www.tailscale.com的证书在3月7日到期，导致无法访问网站。

影响：幸运的是，大多数Tailscale操作不需要访问主网站，因此许多用户正常的Tailscale使用没有受到干扰。主要的中断是：

Tailscale文档，位于https://tailscale.com/kb，在停机期间无法访问，我们的博客和其他通过我们的网站提供的参考材料也无法访问尽管我们的管理控制台和其他设置页面没有受到影响，但不知道直接导航到https://login.tailscale.com/的用户无法访问这些页面，并且可能认为它们 offline 我们的快速安装脚本，位于https://tailscale.com/install.sh，也无法访问，这干扰了一些安装（包括一些自动安装）实际上提供Tailscale包以供安装的域名仍然可以访问，并且我们相信，由于缓存，通过Go的go get机制的解析中断是很小的。

解决步骤：一旦我们确定了问题所在，我们就通过暂时移除“额外”的AAAA记录并手动续签有关证书来响应，这立即解决了用户面临的问题。

当然，我们仍然希望我们的网站和服务能够通过IPv6访问，所以我们在那之后立即恢复了这些记录。这意味着证书续签的根本问题仍然存在，我们计划在短期内像我们的祖先一样解决这个问题：多个冗余的日历提醒和一个指定的窗口，让我们自己手动续签证书。我们还计划更新我们的探测器基础设施，分别检查IPv4和IPv6端点。

我们还希望通过在我们的网站基础设施中以更直接的方式支持IPv6来使我们的代理变得不必要。

最后，虽然我们将努力避免任何停机，但Tailscale设计的一个很好的好处是，这个小小的波动没有中断大多数用户的绝大多数使用。我们的一条指导原则是启用您机器和服务之间的直接连接，这意味着您的网络对任何特定端点的可用性——甚至是tailscale.com——在任何给定时间都依赖性较小。

Post by: tatersolid

Comments:

smackeyacky: I've said it before and I'll say it again: expiring certs are the new DNS for outages.<p>I still marvel at just how good Tailscale is. I'm a minor user really but I have two sites that I use tailscale to access: a couple of on-prem servers and my AWS production setup.<p>I can literally work from anywhere - had an issue over the weekend where I was trying to deploy an ECS container but the local wifi was so slow that the deploy kept timing out.<p>I simply SSH'd over to my on-prem development machine, did a git pull of the latest code and did the deploy from there. All while remaining secure with no open ports at all on my on-prem system and none in AWS. Can even do testing against the production Aurora database without any open ports on it, simply run a tailscale agent in AWS on a nano sized EC2.<p>Got another developer you need to give access to your network to? Tailscale makes that trivial (as it does revoking them).<p>Yeah, for that deployment I could just make a GitHub action or something and avoid the perils of terrible internet, but for this I like to do it manually and Tailscale lets me do just that.

smackeyacky: I-；我以前说过；我再说一遍：过期证书是导致停机的新DNS<p> 我仍然惊叹于Tailscale有多好；我真的是一个小用户，但我有两个网站可以使用tailscale访问：几个预处理服务器和我的AWS生产设置<p> 我真的可以在任何地方工作——周末我遇到了一个问题，当时我正试图部署一个ECS容器，但本地wifi太慢，以至于部署一直超时<p> 我只是简单地SSH；d转到我的预开发机器上，对最新的代码进行git提取，然后从那里进行部署。同时保持安全，在我的on-prem系统上没有任何打开的端口，在AWS中也没有。甚至可以在没有任何开放端口的情况下对生产Aurora数据库进行测试，只需在纳米级EC2上的AWS中运行一个尾标代理。<p>是否有其他开发者需要访问您的网络？Tailscale使其变得微不足道（就像撤销它们一样）<p> 是的，为了这个部署，我可以做一个GitHub操作或其他什么，避免糟糕的互联网带来的危险，但为了这个，我喜欢手动操作，Tailscale让我这样做。

lmeyerov: Expiring certs strikes again!<p>I'd recommend as part of the post mortem to move their install script off their marketing site or putting in some other fallback so marketing site activity is unrelated to customer operations critical path. They're almost there for maintaining that typical isolation, which helps bc this kind of thing is common.<p>We track uptime of our various providers, and seeing bits like the GitHub or Zendesk sites go down is more common than we expected... and they're the good cases.

lmeyerov: 过期证书再次出现<p> I-；d建议作为事后评估的一部分，将安装脚本从营销网站上删除，或采取其他后备措施，使营销网站活动与客户运营关键路径无关。他们；我们几乎可以保持典型的隔离，这有助于bc这种事情很常见<p> 我们跟踪各种提供商的正常运行时间，看到像GitHub或Zendesk网站这样的网站宕机比我们预期的更常见。。。并且它们-7；是好的案例。

physicles: They have monitoring for their infrastructure, right? Add 50 lines of code that connects to all public domains on ipv4 and ipv6 and alerts if the cert expires in under 19 days. Set automatic renewal to happen 20 days out. Done.
I wrote this code years ago, after missing a couple ssl renewals in the early days of our small company. Haven’t had an ssl-related outage since.<p>Edit: this is the only necessary fix, no need for calendar invites:<p>> We also plan to update our prober infrastructure to check IPv4 and IPv6 endpoints separately.

physicles: 他们对自己的基础设施进行了监控，对吧？添加50行代码，连接到ipv4和ipv6上的所有公共域，并在证书在19天内过期时发出警报。将自动续订设置为20天后发生。完成。几年前，在我们小公司的早期，我错过了几次ssl续订，之后我写了这段代码。自那以后，还没有发生过与ssl相关的中断<p> 编辑：这是唯一必要的修复程序，不需要日历邀请：<p>&gt；我们还计划更新我们的prober基础设施，以分别检查IPv4和IPv6端点。

snapplebobapple: I really like these guys, I wish their pricings wasn't so ridiculous. proper access control shouldn't cost 18 bucks a month for a vpn, it's basically unsellable to management at that price and the lower tiers are unsellable without it.

snapplebobapple: 我真的很喜欢这些家伙，我希望他们的价格不是；不要那么可笑。适当的访问控制应该；一个vpn每月花费18美元；它基本上不能以这个价格出售给管理层，没有它，较低级别的产品也卖不出去。

nerdbaggy: I wonder what provider they use for their website. Sounds like a lot of hoops to jump through for IPV6 when just about any other provider has IPv6 support.

nerdbaggy: 我想知道他们的网站使用什么提供商。当几乎任何其他提供商都支持IPV6时，IPV6似乎有很多困难需要克服。