すべての OpenVPN ノードに同じサービス IP：それができないこと

クライアントは複数の OpenVPN サーバーの一つに接続し、そのノードで動く小さなサービスを必要とします：状態ページ、メトリクスのエンドポイント、バックアップエージェントです。どのノードにも同じプライベートなサービスアドレスを与えると、クライアントの設定は接続先のサーバーに関係なく同一になります。その便利さは本物ですが、過大に読むのも簡単です：共有アドレスはどのノードに到達したかを示すのであって、何かが冗長であることを示すのではありません。

同じアドレスがどのノードでも機能する理由

各ノードはアドレスをローカルに所有してそれに応答するため、現在のトンネル経由で到達したクライアントはそのトンネルの向こう側でサービスを得ます。ノード間で調整されるものはなく、あるノードから別のノードへトラフィックが渡ることもありません。

アドレスはローカルなラベルであり、複製ではなく繰り返しです。各ノードは自分自身のためだけに応答し、どれも他のノードの代わりにそのアドレスのトラフィックを転送しません。これが、サーバーが独立したままで一つのクライアント設定が有効であり続ける理由です。また、この設計がノード間の調整を必要としない理由でもあります。

だからこそ同じ設定が、ノード間にルーティングプロトコルなしでどのサーバーでも機能します。また、この設計が健全性について何も語らない理由でもあります：アドレスはホストに結び付いているのであって、サービスの有用性に結び付いているのではないため、不健全なノードでも健全なノードとまったく同じように存在します。

トンネルではなくループバックに割り当てる

アドレスをループバックインターフェースに置くと、どのトンネルデバイスの寿命からも切り離されるため、再接続や設定の再読み込みで消えることはありません。アドレスはホストが存在する限り存在します。

lo 上のアドレスはフィルターではありません。サービスは依然としてそこで待ち受ける必要があり、ホストのファイアウォールは実際の受信経路を依然として評価します、その経路はトンネルインターフェースに到着します。ループバックがローカル限定を意味すると仮定する人は、結局、正当なクライアントを遮断するか、意図しなかったものを露出させることになります。

割り当てはフックから再追加するのではなく、ホストのネットワーク設定を通じて永続化します。セットアップフックはトンネルが上がらなかったノードでは発火せず、サービスアドレスはトンネルの活動に依存すべきではありません。アドレスはディストリビューションが管理するインターフェース設定に置き、その後一度再起動して確認します。再起動は、後からの設定変更に耐える唯一のテストです。

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

プッシュするルートは一つ、意味する宛先も一つ

クライアントにはそのアドレスへのホストルートが必要で、それは接続先のサーバーが提供します。どのサーバーも同じ宛先を提供するため、クライアントが移動してもプロファイルは変わりません。

サービスを責める前に、クライアントが何をインストールしたかを確認してください。

ip route get 10.250.0.1

HTTP サービスの場合、アドレスに名前を与え、その名前の証明書を用意します。共有 IP は身元ではなく、TLS 検証を取り除くものでも、同じ秘密鍵を全ノードに配ることを正当化するものでもありません。共有アドレスに解決する名前は、証明書の話をありきたりなままに保ち、必要ならノードごとの同一性を保てます。

共有アドレスにできないこと

フェイルオーバーは提供しません。選択したノードが落ちれば、アドレスもそれとともに落ち、クライアントは別の場所に再接続する必要があります。

新しい接続は古い接続を知らない別のホストで終端するため、稼働中の TCP セッションを移行することはありません。

健全なノードを選ぶこと、負荷を分散すること、ノード間でデータを同期することもありません。それらはそれぞれ独自の故障モードを持つ別個の仕組みであり、アドレスの工夫がそれらを覆うふりをすることが、単純な設計に不当な回復力の評判を与える道です。二つのトンネルが同時に有効なら宛先の意味は曖昧になるので、トンネルは一つだけ有効という前提を明示しておきましょう。

サービスの同一性は名前とともに保つ

アドレスが何を意味するかを書き留めます：クライアントが現在接続しているノードのサービスに到達する、ということです。その一文が、このパターンが引き寄せる誤解のほとんどを防ぎます。

次に各部分をまとめて文書化します：アドレス、それが載るインターフェース、サーバーがプッシュするルート、そしてサービスが提示する名前と証明書です。将来の読者が検証できる四つの小さな事実を、実際に確認する順序で並べます。

要件がノードローカルなサービスへの安定した宛先であれば、このパターンは適合し、ほとんどコストはかかりません。

要件が可用性であれば、一段上へ移ります：ロードバランサー、ヘルスチェック付きのサービス名、またはノードの交換方法をすでに知っているオーケストレーションシステムです。

それを早く決めておけば、共有アドレスは便利なラベルという本来の姿のまま保たれ、決して設計されなかった仕事を静かに期待される部品にはなりません。