ハクソク

世界を動かす技術を、日本語で。

Tailscaleの状態ファイル暗号化がデフォルトで無効になりました

99日前原文(tailscale.com)

概要

  • Tailscaleの各プラットフォームおよびコンテナ・Kubernetes Operator等の主要アップデートまとめ
  • ハードウェア認証キーやStateファイル暗号化のデフォルト設定変更
  • Kubernetes連携やワークロードIDフェデレーション対応の強化
  • バグ修正・安定性向上・セキュリティ改善
  • 管理コンソールやCLIの新機能追加・UI改善

Tailscale全般の主な変更点

  • Linux/WindowsのStateファイル暗号化およびハードウェア認証キー、デフォルト無効化
  • TPMデバイスのリセットや交換時、ハードウェア認証キーの読み込み失敗でもクライアント起動可能
  • Tailscale container imageの新リリース、Docker HubやGitHub Packagesからダウンロード可能
  • Kubernetes State Secretsにハードウェア認証キーを追加しない仕様に変更、ノード移動が容易に
  • Tailscale Kubernetes Operatorの新リリース、インストール/アップデート手順参照推奨
  • 証明書更新はARI order非デフォルト化、ACMEアカウントキー再作成時の失敗回避
  • Kubernetes OperatorのワークロードIDフェデレーション対応、プロバイダーネイティブIDトークン認証サポート
  • IngressリソースへのHTTP→HTTPSリダイレクト注釈サポート
  • DNSConfigリソースのnameserver、安定イメージ使用をデフォルト化
  • Recorderリソースでレプリカ数指定可能、高可用性展開にはS3ストレージ必須
  • ArgoCD互換性向上、apiServerProxyConfigのmode/allowImpersonationでbool/文字列両対応
  • Ingress管理の正確なリコンシリエーション、ProxyGroup Ingress削除時のスタック解消

tsrecorder・GitHub Action・iptables等の改善

  • Tailscale tsrecorder新バージョン、主にライブラリアップデート
  • TS_AUTHKEY_FILE環境変数で認証キーをファイルから利用可能
  • GitHub Action、macOSランナーのキャッシュアーキテクチャ正確化
  • iptables、nftables非対応ホストでも利用可能に

Funnel・Peer Relays・Serve等の新機能

  • Tailscale Funnel/ServeでPROXYプロトコルサポート
  • Peer Relays、静的エンドポイント指定や複数バインドパケット対応
  • サービスのリモートターゲット指定、ノードのワークロードIDフェデレーション認証
  • ネットワークフローログで自ノード・通信相手情報自動記録
  • Tailnet Lockコマンドのjsonレスポンス安定化
  • Peer Relayエンドポイント広告のIP:port候補増加

macOS/iOS/Android/全プラットフォームの修正

  • macOS、VoiceOver冗長ラベル削除・スリープ復帰時の接続問題解消
  • iOS、Taildrop対応ノード表示・ショートカット経由のExit Node選択正常化
  • Android、セルラー→Wi-Fi時のDNS継続動作
  • tailscaled、イベントバースト時のデッドロック解消・ポートマッピング時の復帰不具合修正
  • Peer Relays関連のパニック・デッドロック・メモリリーク解消
  • Linux、Tailnet Lock有効時の署名チェック強制不具合修正（TS-2025-008）
  • macOS、スリープ復帰時の接続問題解消

ドメイン・ファイアウォール・App connectors

  • log.tailscale.com、Tailscale管理の静的IPレンジへ解決
    • IPv4: 199.165.136.0/24、IPv6: 2606:B740:1::/48
    • 通常はファイアウォール設定不要
  • App connectors、ルート更新の適用失敗問題修正

Kubernetes Operator・DNS・ログ・UI強化

  • DNSConfig nameserver、IPv6アドレスPod・AAAAレコード対応
  • nameserverレプリカ数指定・Pod toleration設定可能
  • ProxyClassでdnsConfig/dnsPolicy指定対応
  • ReconcilerログはTailscaleコントロールプレーンにも送信（TS_NO_LOGS_NO_SUPPORTで無効化可）
  • tsrecorderのWeb UIで検索・フィルタ・UI強化
  • kubectl execセッション記録の安定化・大規模データセットのキャッシュ安定化

ワークロードIDフェデレーション・API連携

  • OIDCワークロードIDフェデレーション（β）、サードパーティ認証プロバイダー対応
  • tailscale-client-go-v2・Terraform provider・GitHub Action・tailscale upコマンドでフェデレーション認証サポート

管理コンソール・CLI・UIの新機能

  • OAuthクライアントスコープ・説明文の編集機能追加
  • Trust credentialsページでOAuthクライアント管理（旧OAuth clientsページ置換）
  • 複数tailnet管理（α）、共通IdP・ドメインによる組織管理
  • tailscaledのシャットダウン安定化、Linux/FreeBSD/OpenBSDでノールーター構成時の起動安定化
  • Linux、非amd64/arm64プラットフォームでiptables回帰修正
  • TPM 1.xデバイス搭載機器でのtailscaled起動失敗問題修正

その他の機能・設定

  • DNSリゾルバ、Exit Node利用時も全ドメインで設定可能
  • ノードキー自動更新、再認証中も既存接続維持
  • Go 1.25.3へのアップデート
  • DERPサーバーへの不要なパスディスカバリパケット抑制
  • ノードキーシーリング、GA化・デフォルト有効（Linux/Windows/macOS）
  • macOS、Dockアイコン非表示オプション追加・GUIでのディレクトリ共有推奨
  • iOS/macOS、ショートカット経由Exit Node選択やアカウント表示の安定化
  • Android、ダイレクト接続の安定化
  • Tailnet名・ID・表示名のカスタマイズ、管理コンソールへの新フィールド追加

注記:

  • 詳細な情報や手順は公式ドキュメントやインストールガイドを参照
  • 一部バージョン（例: 1.92.0, 1.90.0, 1.90.7）はテスト・内部リリース用

Hackerたちの意見

サポートが大変すぎたってことかな？サポートに連絡した人たちに問題が多すぎたのかも。
チェンジログを見る限り、デフォルトでオンになっている設定が原因で問題が発生したみたい。ただ、Tailscaleの社員じゃないから、内部情報なしでの推測だけどね。Tailscaleは、問題を修正してこのデフォルト設定を短期間で再有効化する予定があるか確認してくれるかな？今のところ、Tailscaleを運営している人たちの善意には信頼を置いてるけど、今の地政学的状況を考えると、政府機関が表明している監視の容易さに配慮した変更ではないと信じるための具体的な理由が欲しいな。
└
問題になっていることは、Tailscaleがコントロールできる範囲外みたいだね（基本的に、一般のTPMデバイスがあまりにも信頼性がないから、この機能は使用を選択する制御された環境に向いている）。
これが機能を無効にした理由を説明しているPRはこちらだよ。https://github.com/tailscale/tailscale/pull/18336 TPMの品質のばらつきなどが原因で、たくさんの問題が発生したみたい。
これがデフォルトでオンになるべきじゃなかった。エンドユーザー（つまり管理者）は、TPMを使いたいってことを理解している必要がある。これは多くのデバイスにとって大きな足元をすくう原因になる。チェンジログの注釈がその理由を示唆しているね。> ハードウェア認証キーの読み込みに失敗しても、クライアントの起動を妨げなくなった。TPMデバイスがリセットされたり交換されたりすると、これが起こることがある。これは残念なことだね。多くの展開では、絶対にこれをオンにしておきたい。でも、Tailscaleが制御できない、あるいは予測できない特定のデバイス/OSの組み合わせにとっては時限爆弾みたいなもので、Tailscaleはほぼすべてのデバイスにインストールされるから、問題のあるインストールが増えるのは避けられないよ。
└
暗号関連でTPMを使うことに興味がある者として、こういう実装の詳細を深く考えるたびに、TPMの意味を完全に否定するようなリカバリーパスワードやバックアップキーの設定が必要だと感じるんだ。TPMは本当に面白そうだけど、ちょっとしたミスでユーザーのキーが消えちゃうのを考えると、暗号に使うメリットが見えづらい。しかも、その小さなミスが自分のソフトウェアに起因するわけじゃなくて、OSやTPMスタックのエッジケースかもしれないし。
└
>> TPMデバイスがリセットされたり交換されたりすると、これが起こることがある。物理的な攻撃に対抗するための望ましい動作じゃないの？
└
でも、例えばWindowsは今やデフォルトでTPMを使ってるよね？TPMがそんなに大きな問題なら、何百万ものWindowsユーザーがTPMの問題を抱えているはずじゃない？内部情報はないけど、これは「ナッツを割るためのハンマー」みたいに感じるな。Tailscaleが少数のTPMのエッジケースのために重要な機能をオフにするのは残念だし、全てオンか全てオフのハードバイナリの間に妥協点を見つけられなかったのも残念だね。
私はTailscaleのエンジニアの一人で、最初にノード状態の暗号化を作った人です（GitHubでは@awly）。1.92.5でデフォルトでオフにする決定をしたのも私です。このスレッドの別のコメントが正解でした - この機能はサポートがかなり大変なんです。最初は、TPMがリセットされたり交換されたりするのは常に改ざんの兆候だと思っていて、クライアントが起動したり接続したりしないようにすべきだと考えていました。でも、TPMが悪意のない理由で信頼できない状況がたくさんあることが分かりました。いくつかの例を挙げると: * https://github.com/tailscale/tailscale/issues/17654 * https://github.com/tailscale/tailscale/issues/18288 * https://github.com/tailscale/tailscale/issues/18302 * それに加えていくつかのサポートチケット。TPMは、デバイスをしっかり管理している組織には素晴らしいツールです。でも、Tailscaleのユーザーが持っている非常に多様なデバイス群は、初期設定のままではサポートが難しいです。だから今のところ、セキュリティに敏感なユーザーや管理者に有効化を任せて、広いユーザーベースに予期しない問題が起こらないようにしています。もっとこの背景を変更履歴に書いておくべきでした、ごめんなさい！
└
それについてGoogleのGo TPMライブラリを使ったの？
└
それは非常に合理的で論理的な方針ですね。背景を教えてくれてありがとう。
└
@cronos 質問です: あなたは https://github.com/tailscale/tailscale/issues/17654 にリンクしていますが、そこではユーザーが「以前の回避策（TS_ENCRYPT_STATE=false、FLAGS="--encrypt-state=false"）は、この問題のあるDebian 13ホストでは効果がなかった」と言っています。同じユーザーが「tailscaleバージョン1.92.1ではこの問題はもう見つからないことを確認しました」とも言っています。これらのコメントが結局状態の暗号化ではなかったことを示唆しているように見える点について、もう少し背景を教えてもらえますか？
└
その問題は驚きの内容ですね。古いデバイスやニッチなデバイスでTPMの問題があるのは予想できるけど、Dell XPSのノートパソコンやさまざまなVMで問題が出るとは思わなかったです。でも、自分のVMがTPMの状態をどう扱っているのか、そもそも扱えるのかもよく分からないです。ほとんどの個人用TailscaleインスタンスはコンテナやVMで動かしています。今ダッシュボードを見たら、この機能は私の主要なLinuxとWindowsのPC、iPhone、そしてメインのLinuxサーバーのホストでしか暗号化されていないようです。私が使っているVMやコンテナはこれを活用できなかったし、ノートパソコンも同様でした。もしかしたら、ノートパソコンが古すぎるのかも。
└
今週、PCのBIOSアップデートでTPMがリセットされました。行動する前にBitlockerのキーが消去されるという警告はもらいました。（これはAMDのTPMの脆弱性を修正するためだったと思います - おそらくTPMのコードを更新するとTPMストレージが意図的に消去されるか、避けられない副作用として消去されるのです。）
└
私もTPMは秘密を信頼できるものだと思っていましたが、BIOSのアップグレードでそれが消去されました。もうTPMには頼りません。
└
あなたの疑念は正しいです。AMD AM5マザーボードを使っていて、BIOSを更新するたびにfTPMがリセットされるって警告が出るんですよ。その後、Bitlockerがリカバリーキーを入力するように促してくるから、ドライブが解除できなくなってるのが分かります。
└
ありがとう！あなたの変更で https://github.com/tailscale/tailscale/pull/18336 にこう書いてありますね: > macOSではtailscaledもあるけど、TPMやKeychainのバインディングはないよ。つまり、macOSではtailscaledがSEPから同等のハードウェア認証機能を利用していない、もしくは利用したことがないってことですか？（その機能が利用可能だと仮定して）
神様に感謝、私は本当に古いハードウェアのnixosマシンでTailscaleを動かしていて、なぜクラッシュするのか分からなかったんです。これが原因だったけど、静かに失敗していました。
じゃあ、Linuxでは /etc/default/tailscaled を更新して、FLAGS="--encrypt-state" を追加すればいいってこと？あとはうまくいくことを願う感じ？追記: ログにこれが出てるから、うまくいってるっぽいね。「/var/lib/tailscale/tailscaled.state」をプレーンテキストからTPMシール形式に移行しましたって。