削除したZeroTierメンバーが戻ってくる：先に認可を取り消す

メンバーを削除してページを閉じ、一日後に同じ端末が戻ってくる。これはコンソールの不具合ではありません。端末がオンラインのまま参加を要求し続けている間に記録を削除すると、こうなります。

二つの操作は隣り合って存在し、それぞれ別の仕事をします。一方はアクセスを決め、もう一方は一覧を整えるだけです。

戻ってきた記録から始める

ネットワークを開き、戻ってきた項目を見ます。そのnode ID、最後のアドレス、再び現れた時刻を記録します。廃止しようとしていた端末と照らし合わせてください。表示名は誰かが入力したものであり、アドレスは次の参加で変わり得ます。

node IDこそが安定した識別子です。ネットワークIDはネットワークに名前を付けるものであり、どの一覧を読んでいるかは分かっても、そこにどの端末がいるかは分かりません。両方を記録し、node IDを廃止対象のマシンと突き合わせてください。

この照合を誤ると、動いているマシンを外してしまい、不要な端末は要求を続けます。すると一覧は一日だけ正しく見えます。誰も気づかないほどの時間であり、まさにそれが問題です。

削除する前に取り消す

まずコントローラが対応する手順で認可状態を変更します。その時点から、参加の試行はアクセスを静かに復活させるのではなく未認可として現れ、要求は見えないものではなく見えるものになります。

削除はその後に来るもので、代わりになるものではありません。認可済みメンバーの記録を消すと、取り消すべきものが残りません。端末は再び要求し、コントローラはそれを新規として扱います。

まだ管理下にあるマシンにとって、ネットワークからの離脱は廃止の有効な一部です。紛失した端末についての管理者の判断の代わりにはなりません。もはや管理していないクライアントは、何を言われても無視できます。

二つの操作はどこにあるか

ホスト型コントローラでは、メンバー一覧が両方の操作を提供し、区別できる程度に明確に表示します。セルフホスト型コントローラでは、同じ区別がAPIとローカル設定に現れ、たいていそこから混乱が始まります。

# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'

# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
  "http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"

この二つの呼び出しで、そのメンバーが本当に未認可だったことがあるかを示せます。authorized: trueのまま何度も戻ってくる記録は、取り消されたことがなく、削除されただけです。

一覧ではなくリソースで確認する

整ったメンバー一覧はアクセス確認ではありません。端末が以前使っていたリソースを、その端末から、または古いアドレスを持つマシンから試し、接続が失敗することを確認します。次に、承認済みの代替機がまだ機能することを確認します。

そのテストにはルートとサービス権限も含めます。ZeroTierはメンバーを認可しても、管理ルートに到達できないままにすることがあります。アプリケーション権限も同じように失敗し得ます。どちらもメンバー一覧からは同じに見えます。

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

セルフホスト型コントローラでは、その識別情報と設定の一貫したバックアップを保ってください。以前の状態に巻き戻す復元は古い認可を一緒に戻すことがあり、メンバー一覧は廃止前とまったく同じに見えます。

古い識別情報が何にも到達できず、記録が消えていれば廃止は完了です。この順序で行えば、メンバーは戻ってこなくなります。