接続と認証
ピア間の接続(Raftポート = クライアントポート + 1000)は、クライアントポートとまったく 同じ順序で確立されます。プロトコル内にクライアントとピアを区別する手順はなく、 役割は純粋にポートだけで区別されます。
- TCP接続 — 発信側は常にリクエスト側
- サーバーがTLSを有効にしていればTLSハンドシェイク
- 認証ハンドシェイクを1回 — 仕様(チャレンジ、ダイジェスト、 応答)はクライアントポートとバイト単位で同一
- 以降は長さプレフィックス付きRPCのやり取り
フロー
発信ノード
受信ノード
TCP接続 (Raftポート = クライアントポート + 1000)
サーバーがTLSを有効にしていればTLSハンドシェイク
チャレンジ (SHA-256 ␣ nonce)
ダイジェスト — cluster_tokensの最初のトークンで計算
cluster_tokensリスト全体と照合
ここから先は長さプレフィックス付きRaft RPC
リクエストレスポンス合意形成RPC(Raft)
クライアントポートとの違い
| 項目 | クライアントポート | Raftポート |
|---|---|---|
| 検証に使うトークンセット | client_tokens | cluster_tokens |
| 送信されるトークン | クライアントが設定したトークン | cluster_tokensの先頭のトークン |
| 認証後 | \n終端のフレーム | 長さプレフィックス付きRPC |
- 受信側の検証は
cluster_tokensリストの全体と照合するため、新旧のトークンを一緒に 並べておき、ノードを1台ずつ順にローリングすることで、無停止のままトークンを ローテーションできます(設定 (環境変数))。 - TLSが有効な場合、Raftポートも同じ証明書を使います。発信側はピアの証明書を
tls_ca(未設定ならシステム信頼ストア)と照合します。tls_skip_verifyはテスト専用です。 - 認証に失敗すると、
E auth_failedの後に接続が 閉じられます — クライアントポートと同様です。