TAP サーバーは1台か複数か？ブリッジ上の OpenVPN クライアント

複数の TAP クライアントに、それぞれ一つのサーバープロセス、一つの UDP ポート、ホスト上の一つの TAP デバイスが必要なわけではなく、イーサネットモードの OpenVPN サーバー一台で多数の認証済みクライアントを受け入れて単一のブリッジに接続できます。これがレイヤー2セグメントを拡張する文書化された方法です。単一プロセスの設計はマニュアルが記載しているものであり、通常は正しい既定値です。

本当の問いは、それらのクライアントがそのセグメントを共有すべきかどうかであり、プロセス数では答えになりません。分離の性質はトポロジーから来るもので、デーモンがいくつ動いているかとは関係ありません。この比較の残りは、二つのトポロジーとそれぞれが何を容易にするかについてです。

二つのアーキテクチャであり、二つの設定ではない

ルーティング型 TUN の導入では、各クライアントにサーバーのルーティングドメインへのポイントツーポイントリンクが与えられます。ブロードキャストはサーバーで止まり、クライアントは互いのフレームを見ることができず、クライアント間の通信がある場合は明示的にルーティングしてフィルタリングする必要があります。

ブリッジ型 TAP の導入では、クライアントは一つのイーサネットセグメントのメンバーになります。ブロードキャストが見え、ARP で互いを解決でき、分離を保つためにルーティングではなくブリッジとファイアウォールのポリシーに依存します。クライアントが同じスイッチに接続されているように見える必要がある場合に有用です。

したがって比較は、クライアントが何に到達する必要があるかについてであり、性能についてではありません。まずレイヤーを選び、次にそれを何プロセスで提供するかを決めます。

server-bridge ヘルパーが行うこと

server-bridge ヘルパーはマルチクライアントのイーサネットモードを設定します。アドレスプール形式では、ゲートウェイ、ネットマスク、ブリッジされたサブネット内の専用範囲を指定し、たとえばゲートウェイを 192.168.50.1 に、プールを 192.168.50.160 から 192.168.50.199 にします。

その範囲は他の DHCP や静的割り当ての外に予約してください。ヘルパーはそこからアドレスを割り当てますが、同じセグメント上の別の割り当て者とは調整せず、二つのプールが重なると重複アドレスが生まれ、ランダムな接続障害のように見えます。予約した範囲はサイトのアドレス計画に書き、次の人が再利用しないようにしてください。サーバー設定のコメントはその記録の代わりにはなりません。

外部サーバーがアドレスを配布する環境向けに、DHCP プロキシ形式もあります。これには独自の前提条件があり、二つの形式を混在させると、ドキュメントが警告している衝突がそのまま起こります。ブリッジされたサブネットには一つの割り当て者を選んでください。

分離はプロセス数から来ない

同じ制限のないブリッジに接続された八つの OpenVPN プロセスは、それでも一つのブロードキャストドメインを共有します。クライアントはブリッジ越しに互いへ ARP を送れ、リスナーの数はその点を何も変えません。

要件がクライアント群がレイヤー2で互いを見ないことであるなら、設計には別々のブリッジまたは VLAN 接続と、それに伴うアクセスルールが必要です。これはネットワーク設計の判断であり、サーバープロセスが一つでも八つでも同じ判断です。ブリッジのフィルタリングは一部のトラフィックを制限できますが、別々のブロードキャストドメインを作るわけではありません。セグメンテーションの補助として扱い、代替とはしないでください。

要件がクライアントが特定の IP サービスに到達することだけなら、ルーティング型 TUN の設計は通常、ブリッジとフィルタリングより単純です。各クライアントが独自のリンクを得て、ポリシーはブリッジの内部ではなくルーティングとファイアウォールのルールに置かれます。

複数プロセスがなお正しい場合

別々のプロセスは、認証バックエンドが異なる、認証局が異なる、更新サイクルが別、あるいは互換性のないオプション群といった運用上の必要で正当化できます。これらは実際の理由であり、クライアント数とは無関係です。

複数を使う場合は、それぞれに独自のリスナーとデバイスの所有権を与え、アドレス範囲を調整してください。同じブリッジ上で同じプールを所有していると考える二つのサーバーは、いずれ同じアドレスを配布します。

次に、複数のクライアントを同時に使って設計を検証します。アドレスが一意であること、想定したクライアント間通信が機能すること、通信してはならないペアが実際に通信できないことを確認してください。一つのクライアントの ping 成功は、マルチクライアント設計の何も試しません。

図を信じる前に、稼働中のホストからブリッジとサーバーモードを読み取ってください。重要なのはカーネルとデーモンが実際に読み込んだ設定であり、レビュー担当者が確認できるのもそれです。