2024年3月7日に発生した Tailscale.com 障害
(tailscale.com)- 2024年3月7日に期限切れとなった TLS証明書 が原因で、tailscale.com は約90分間停止したが、影響は主にドキュメントサイトとマーケティングサイトにとどまった
- 2023年12月のWebサイト刷新と新しいホスティング環境への移行から約90日後に問題が表面化し、IPv6非対応環境を補う 独自プロキシ 構成が自動更新を妨げていた
- 証明書有効期限監視用の プローバー が IPv6経路のみを確認 していたため、別個に有効な証明書を持つプロキシを通過し、実際の tailscale.com と www.tailscale.com の期限切れ接近を見逃した
- 通常の Tailscale 利用の大半は停止しなかったが、ドキュメント、ブログ、install.sh、直接URLを知らないユーザーの管理コンソールへのアクセス導線には影響があった
- Tailscale は追加の AAAA レコード削除と手動更新で復旧し、短期的な手動更新体制と IPv4/IPv6 の分離確認を経て、より直接的な IPv6対応 を目指す
証明書失効を見逃した理由
- 2024年3月7日、tailscale.com と www.tailscale.com の TLS 証明書が失効し、約90分間サイトへのアクセスが停止した
- 2023年12月、Tailscale は大規模なWebサイト刷新にあわせて新しいホスティング事業者へ移行した
- 新しいホスティング事業者は IPv6 を標準サポートしていなかったため、Tailscale は IPv6 リクエスト処理のために独自プロキシを運用し、追加の AAAA レコード を設定した
- ホスティング事業者はこの構成を「misconfiguration」として通知したが、その構成が証明書の自動更新完了を妨げることは通知に明記されていなかった
- 証明書有効期限監視用の プローバー は IPv6 経路しか確認していなかった
- プローバーは独自プロキシを通過していた
- プロキシは別管理の有効な証明書を持っていた
- そのため、tailscale.com と www.tailscale.com の実際の証明書失効が事前に表面化しなかった
ユーザーに見えた影響
- 影響はWebサイトに依存する資料とインストール導線に集中した
- Tailscale ドキュメント、ブログ、その他のWebサイトベースの参考資料は障害中アクセスできなかった
- 管理コンソールと設定ページ自体は影響を受けなかったが、
https://login.tailscale.com/に直接移動する方法を知らないユーザーは、そのページ自体がオフラインだと思う可能性があった - クイックインストールスクリプト を利用できず、一部のインストールと自動インストールに支障が出た
- Tailscale パッケージを実際に配布しているドメインはアクセス可能であり、Go の
go getメカニズムによる解決停止も キャッシュ のおかげで最小限だったとみられる - Tailscale の設計上、大半のユーザーはほとんどの利用ケースで今回の障害による停止を経験せず、直接接続の原則によりネットワークは tailscale.com のような特定エンドポイントの即時可用性にあまり依存していない
復旧と再発防止
- 問題確認後、Tailscale は「追加」 AAAA レコード を一時的に削除し、関連証明書を手動で更新した
- この対応によりユーザーに見える障害は直ちに解消され、サイトとサービスを IPv6 で提供するためレコードはまもなく復元された
- 自動更新の問題は残っているため、短期的には重複したカレンダー通知と指定した手動更新時間を設け、証明書を直接更新する予定である
- プローバー基盤は IPv4 と IPv6 エンドポイント を個別に確認するよう更新される予定である
- 長期的には、Webサイト基盤で IPv6 をより直接的にサポートし、独自プロキシが不要な構成を目指す
1件のコメント
Hacker News のコメント
期限切れになる証明書は、今や障害における新たな DNS だと思う
それでも Tailscale がどれほどよくできているかには、いまだに驚かされる。どちらかといえばライトユーザーだが、オンプレミスのサーバー数台と AWS の本番環境という 2 か所に Tailscale でアクセスしている
どこからでも仕事ができる。週末に ECS コンテナをデプロイしようとしたら、ローカルの Wi-Fi が遅すぎてデプロイが何度もタイムアウトした
そこでオンプレミスの開発マシンに SSH で入り、最新コードを
git pullして、そこからデプロイした。オンプレミスも AWS も開放ポートなしで安全な状態で、AWS の小さな EC2 で Tailscale エージェントを動かすだけで、本番の Aurora データベースも開放ポートなしでテストできる他の開発者にネットワークアクセス権を与えるときも Tailscale はとても簡単で、権限の取り消しも同様だ。このデプロイは GitHub Actions のようなもので処理して劣悪なインターネット回線の問題を避けることもできたが、手動でやりたかったし、Tailscale がそれを可能にしてくれた
今後は、どの GHA ワーカーでもポートを公開せずにデプロイ用マシンへアクセスできるよう、このアクションを使うつもりだ: https://github.com/tailscale/github-action
期限切れ証明書がまた事故を起こした
事後分析の一環として、インストールスクリプトをマーケティングサイトから切り離すか、別の代替経路を用意することを勧める。そうすれば、マーケティングサイトの活動が顧客運用のクリティカルパスと無関係になる。こういうことはよくあるので、通常の分離を維持するところまであと少しだっただけに、なおさら惜しい
複数プロバイダーの稼働時間を追跡していると、GitHub や Zendesk のサイトの一部が落ちることは予想以上によくある。少なくとも彼らは良い事例の部類に入る
Cloudflare はドメインをそちらでホスティングすれば、この部分をかなり処理してくれるようだが、Cloudflare を使わなければならないという条件が付く
以前の会社でやったミスと同じだ。マーケティングサイト
www.foo.comのホームに、Web アプリのログインページapp.foo.comへのリンクを置いていた最初にマーケティングサイトの障害が起きて初めて、月 40 ドルのホスティングプランが単なるマーケティングサイトではなく、コアインフラだったのだと気づいた。文字どおり負荷を支える 40 ドルのホスティングだった。アプリは落ちていなかったが、ユーザーは落ちていると思った
ユーザーは私たちが用意した経路をたどるだけで、別の道があることを知らない場合が多く、その経路を 1 つなくすと、一部のユーザーは完全に迷子になるのだと学んだ
tailscaleと入力すると、最初の結果はtailscale.comになる。Tailscale の管理コンソールは頻繁には使わないので、わざわざ別の URL を覚えていない以前は
cloudflareと入力するとブラウザがdash.cloudflare.comを自動補完していたが、cloudflare.comの Web サイトを一度訪問してからはそれが最初の結果になり、Cloudflare でも同じ行動をするようになったこのチームは本当に良いが、価格は高すぎると思う。まともな アクセス制御が VPN に月 18 ドルもかかるとなると、経営陣に売り込むのはほぼ不可能で、低いティアはその機能なしでは売りにくい
もっと安い選択肢は何で、それらも SSH 機能、自動化サービス向けの OAuth ネットワーク認証、Kubernetes クラスター内での VPN ノードのロードバランサー構成、Let’s Encrypt による ACME 証明書リクエストの自動化を提供しているのか気になる
無料ティアで使っている機能をいくつか挙げるだけでも、普通の VPN サービスの役割とは思われないものが多い。機能も継続的に追加されていて、かなり興味深く競争力のある選択肢だと思う。むしろ低価格ティアで提供しているものが多すぎて驚くので、そういう評価がなおさら気になる
Tailscale と一部重なる競合製品もあるし、望むものと完全に一致しないかもしれない
ただ、数分でプロジェクトの一部が以前よりずっとよく噛み合って動くようになった
やっていることの割に本当に珍しいほどシンプルなツールの 1 つで、無料ティアもデバイス 100 台とユーザー 3 人でかなり余裕がある
もちろん私の役割上、こうしたテーマで経営陣を説得する影響力がかなりあったのは確かだが、価格は問題にならなかった
昨年 4 月から満足して使っている顧客で、全員がプレミアム、つまり高いティアを利用している。開発速度も印象的だ。数年かかるかもしれないと言われていた機能の一部が、すでに昨年リリースされた
Cloudflare One も代替になり得たが、そちらの方が高かったはずだ
Web サイトのプロバイダーにどこを使っているのか気になる。他のほぼすべてのプロバイダーが IPv6 対応しているのに、IPv6 のためにこれほど多くの回避策が必要だというのは不思議に聞こえる
$ host www.tailscale.comの結果を見ると、www.tailscale.comの IPv4 アドレス76.76.21.21は Vercel で、IPv6 アドレス群は Amazon だIPv4 は Let’s Encrypt 証明書を使い、IPv6 は Amazon 証明書を使っている
12月に大規模ロールアウトを安心して行えるほど、CI/CDとモニタリングがしっかりしているのは本当にうらやましい。エンジニアリング文化がかなり強そうに見える
ただ、まだ答えられていない疑問がある。IPv6設定がIPv4の証明書自動更新を壊したのだとしたら、なぜもっとずっと前に経験しなかったのか気になる。障害解決になぜ90分もかかったのかも気になる。ブログ記事であって本当の事後分析ではないが、簡単なタイムラインくらいはあればよかったと思う
さらに、なぜIPv6をネイティブにサポートするDNSプロバイダーへ移行しないのかも気になる。スクリプトやパッケージ専用のドメインを別に持つ運用負荷に、それだけの価値があるのかも気になる。パッケージリポジトリのような第三者は除いて、ほかのところもこうしているのか気になる
プロキシがなぜTLSを終端する必要があるのか分からない。単なるTCPプロキシだったなら、少なくともモニタリングが証明書の期限切れは迫っていないと勘違いすることはなかったはずだ
それに、ドメイン検証をTLS-ALPNチャレンジで行っていたなら、TCPプロキシなら自動更新も可能にできたかもしれない
ユーザーIPがまったく不要なら問題ではないが、ログや不正利用検知にはしばしば有用だ
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
最初にIPv6が壊れていることに気づいたとき、急いでプロキシを立てた。当時プロキシを立てた人たちは、ACMEがどう動くのかを知らなかった
単なるTCPプロキシに変更する予定だ
見たところ、Tailscaleは
pkgs.tailscale.comにNetActuateを使っているようだ。NetActuateなら、妥当な価格で複数拠点から非終端プロキシを提供するのを支援できそうだ。ウェブサイトに価格は載っていないが、送信トラフィックに50倍のマージンを乗せる会社には見えないTailscaleという組織が、セキュリティに少しでも関わる領域で一度でもつまずくと、私のように少しだけ偏執的な人間にはあまりにも危険に感じられる
この点について、より良い説明が必要だ
インフラ監視はあるはずなので、すべての公開ドメインについてIPv4とIPv6で接続し、証明書が19日以内に期限切れになるなら警告するコードを50行追加すればいい。自動更新は20日前に回せばそれで終わりだ
小さな会社の初期にSSL更新を何度か逃した後、このコードを数年前に書き、それ以降SSL関連の障害はなかった
カレンダー招待は不要で、必要な修正はこれ一つだけだ。「プローバーインフラを更新し、IPv4とIPv6エンドポイントを別々に確認する」という部分が核心だ
「その構成が当該プロバイダーには誤設定と見なされ、デプロイ後ずっと警告を受けていた」とある
では、証明書関連の警告を90日間受け続けた末に証明書が失敗したということなのか？
実際の警告を見たわけではないので、その警告がこの事実を明確に伝えていたのかは分からない