二台のサーバーにまたがる一つの VPN アカウント：三つの状態台帳

二つの VPN ノードのどちらにもサインインできる一つのアカウントは、ソフトウェアの問いになるはるか前から設計の問いを投げかける。アカウントの見え方、各ノードが持つネットワーク、接続中のクライアントが保持するセッションは、三つの異なる種類の状態であり、あちこちにコピーするとそれぞれ違う形で壊れる。三つすべてを一つのシステムにコピーすることは、そのうちの一つを失うよくある方法だ。

以下の三つの台帳を順にたどる。どれも、何が権威で、何がローカルで、もう一方のノードがないとき何が起きるのかを問い、答えは互いから導かれない。

誰が接続できるか：一つの権威、多くのノード

まず受け入れの台帳から始める：どの ID ソースが権威か、どの証明書発行者が信頼されるか、どのアカウントが対象か、どの第二要素が適用されるか、各アカウントが何に到達できるか。次に、各ノードが変更をどう知るのか、どれくらい速く知るのかを書き出す。

共有データベースはその答えの可能な構成要素の一つにすぎない。関連するすべての方針がそこに住んでいる証拠でも、すべてのノードが同じ瞬間に変更を適用する証拠でもない。ノード A で無効化されたアカウントがノード B でまだ受け入れられているなら、退去の手続きは終わっていない。

権威に到達できないときノードがどうするかを決める。障害中にキャッシュされた資格情報を受け入れるのはセキュリティのコストを伴う方針の選択であり、拒否するのは可用性のコストを伴う方針の選択だ。どちらも擁護できるが、文書化しないままにすることは擁護できない。

発行者の権威もアカウントのデータから分けておく。複数のゲートウェイが、署名鍵を持たずに同じ CA を信頼することはできるし、各ノードには依然として独自のサーバー証明書と独自のクライアント側の信頼関係が必要だ。

ノードが何を持つか：アドレスと経路

二つ目の台帳は各ノードにローカルだ：待ち受けアドレス、サーバーの識別情報、アドレスプール、プライベートリソースへの経路、リゾルバの方針、そしてトラフィックがどうインターネットへ出ていくか。同じアカウントをどちらのノードでも扱えるが、これらのオブジェクトは別のままになる。

忘れられるのは戻り経路だ。両方のノードが同じプールからアドレスを配ると、プライベートネットワークは、あるクライアントがどちらのノードのものかを判別できず、応答が間違った場所へ送られることがある。別のプールにも経路と許可が必要なので、番号範囲を分けるだけでは設計として不十分だ。

クライアントは意図して一つのノードへ向ける。DNS の選択、クライアントのエンドポイント一覧、フロントエンドのサービスは、それぞれ異なる仕組みで、健全性とフェイルオーバーの振る舞いも違う。どれか一つを選ぶのはよいが、「負荷分散」を設計そのものと見なすと、戻り経路と障害時の振る舞いが未定義のまま残る。

文書化された製品の例がここで役に立つ。Pritunl のレプリケーション文書は VPN ネットワークをレプリカごとのオブジェクトとして扱い、異なるレプリカ上のクライアント同士が届き合うには追加の経路と接続が必要だとしている。これは製品固有の取り決めであり、Community OpenVPN の手順書ではないが、レプリカを足すことがアカウントの保管場所だけでなくネットワークを変える理由を示している。

セッションとは何か：行ではなく生きた状態

三つ目の台帳は稼働中のセッションだ。接続済みのクライアントは、受け入れたノード上にプロトコルの状態とネットワークの割り当てを持つ。アカウントがもう一方のノードで知られていても、そのノードにセッションや鍵やパケットを継続する能力が与えられるわけではない。

ノードが故障したとき何が起きるかを明示する。サポートされる結果は、新しい認証と新しいアドレスで別のノードへ再接続し、その後アプリケーションがそれぞれのやり方で回復する、というものかもしれない。無中断の引き継ぎが必要なら、その要件には実装上の明示的な対応が必要であり、データベースの複製からの推測では足りない。答えは、当番のエンジニアが見つけられる場所に書いておく。

容量のルールも同じ扱いが必要だ。アカウントあたり同時二セッションという上限をノード間で強制できるのは、使用中の枠について調整された見方を持つ権威がある場合だけだ。ノードローカルの一覧と履歴のアカウント記録を足しても、その見方にはならない。

三つの台帳を試す

それぞれを別々に試す。ノード A でサインインし、次にノード B でサインインして、どちらも想定のアドレス範囲で成功することを確かめる。ID を一つ取り消し、たまたま試したノードだけでなく両方のノードを確認する。そのうえで片方のノードを止め、クライアントとプライベートアプリケーションが実際に何をするかを観察する。

受け入れテストには戻り経路も含める。B に接続できても A の背後のリソースから応答を受け取れないクライアントは、受け入れの検査には通り、ネットワークの検査には落ちている、そしてその区別は報告書に現れるべきだ。

三つの台帳すべてに明示的な所有者、変更の経路、障害時の振る舞いがあって初めて、マルチノードのアカウント設計は完成する。設定ファイルをノード間にコピーしても、これらの問いには一つも答えられない。