リモートのTailscaleデバイスを安全に再認証する
Tailscaleへの強制ログインは、使用中のセッションを切断することがあります。他の障害を除外し、第2の入口を用意し、鍵を1回だけ更新してから、ノードが実際に何を提供しているかを検証します。
リモートサーバーでTailscaleの新しいログインを強制すると、デバイスが再ログインを完了する前にtailnet接続が切れることがあります。これはコマンドの不具合ではなく、使用している経路で設計どおりに動作しているだけです。原則は単純で、鍵を更新する前にマシンへ到達する第二の経路を用意してください。それ以外はすべて、その瞬間のための準備です。
コマンドが接続を切る理由
デバイス鍵は、ノードがtailnetに参加するための鍵です。更新すると古い鍵は受け入れられなくなり、ノードは再参加する前に新しいログインを完了する必要があります。唯一のセッションがそのtailnet経由で動いているなら、再参加はあなた不在のまま起こります。サブネットルーターは、クライアントがルートを保持したままその先の経路を失うため、これをさらに悪化させます。
だからこそ、コマンドそのものより順序が重要です。まずアクセス、次に更新です。コンソールセッション、シリアルコンソール、現地の同僚はいずれも該当します。
まず別の障害を除外する
何かを更新する前に、鍵が本当に原因かを確かめます。管理コンソールで有効期限を確認し、次にデバイス自身が接続されているか、どのピアが見えているかという状態を見ます。有効な鍵でも経路が壊れていたり、ACL変更やサービス停止があったりすると、遠目には同じに見えます。強制更新はそれらのどれも直しません。
tailscale statusノードがオンラインで鍵が有効なら、調査を続けてください。更新は最後の手段であり、一般的な修理ではありません。半分しか接続していないノードも稼働中と報告するため、ピア一覧とオンライン表示の両方を読みます。
第二の入口で更新する
コンソールアクセスか第二の管理経路を用意したうえで、デバイス上で更新を実行します。Tailscaleはこの目的のためにupコマンドのforce-reauth形式を文書化しており、プラットフォームが求める場所では高い権限が必要です。一度だけ実行し、セッションを閉じるのではなく出力を確認します。コマンドで接続が切れたら、第二の経路で再接続し、ローカルログを読みます。
sudo tailscale up --force-reauth鍵がすでに期限切れの場合、管理コンソールが対象デバイスに一時的な延長を提示することがあります。その延長はアクセスを取り戻してログインを完了するための窓であり、恒久的な代替ではありません。表示される期限を記録してください。
デバイスが実際に提供しているものを検証する
デバイスが再参加したら、それが存在する理由であるサービスを検証します。ルーターはその背後のリソース経由で、出口ノードは想定したインターネット経路で、通常のサーバーは実際に使っているポートで検証します。オンラインと表示されるだけのノードは、それ自体では何も証明しません。ローカルチェックはtailnet経路を完全に迂回するため、ノードではないマシンから検証してください。
tailscale ping 100.101.102.103その後、このマシンの期限ポリシーを書き留めます。無人コネクターと個人のノートPCでは許容度が異なり、サーバーを引き継ぐ人がどちらなのかを再調査する必要はないはずです。そのメモが、文書化されたポリシーと来年の驚きの差になります。Tailscaleの鍵の期限に関するドキュメントには、更新の選択肢とその限界がまとめられています。