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

138日前原文(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シール形式に移行しましたって。

ハクソク