多数の OpenVPN クライアントが OpenVPN サーバーに接続するクライアントのシステムを評価しています。「多数」とは、50000 ～ 1000000 を意味します。
なぜそうするのでしょうか? クライアントは分散組み込みシステムであり、それぞれがシステム所有者の DSL ルーターの背後に配置されています。サーバーはクライアントにコマンドを送信できる必要があります。私の最初の素朴なアプローチは、クライアントを OpenVPN ネットワーク経由でサーバーに接続させることです。この方法では、安全な通信トンネルを双方向で使用できます。
これは、すべてのクライアントが常にサーバーに接続されていることを意味します。長年にわたって蓄積されたクライアントは数多くあります。
質問は：OpenVPN サーバーは、一定数のクライアントに達すると爆発的に増加しますか? TCP 接続数の上限については既に認識しています。そのため (およびその他の理由により)、VPN は UDP トランスポートを使用する必要があります。
OpenVPN の専門家の皆さん、あなたの意見はいかがですか?
答え1
これほど大規模なセットアップがこれまでに試みられたことはないと思うので、試してみると限界に挑戦することになるだろう。400クライアント向けのVPN展開しかし、テキストから判断すると、著者は CPU ごとに実行できるクライアントの数について大まかな見積もりに頼っているだけで、自分のセットアップがどのように機能するかについての理解が欠けていました。
主に次の 2 つの点を考慮する必要があります。
データ転送に使用する帯域幅は、VPNサーバー側で暗号化/復号化が必要となり、CPUリソースを消費します。
OpenVPNクライアント接続は、データが転送されていない場合でも、サーバーのメモリとCPUリソースの両方を消費します。
現在入手可能なまともなPCハードウェアなら、BlowfishやAES-128でギガビットリンクを簡単に飽和させることができる。100ドルの組み込みデバイスでさえもだ。100 Mbps近くの速度が可能したがって、帯域幅の強度による CPU ボトルネックについては心配する必要はありません。
デフォルトの再キー化間隔が 3600 秒であることを考えると、クライアント数が 1,000,000 台の場合、サーバーは平均して 1 秒あたり 278 回のキー交換を完了できる必要があります。キー交換は CPU をかなり集中的に使用するタスクですが、必要に応じて専用ハードウェアにオフロードできます。利用可能な暗号化アクセラレータ カードは、この TLS ハンドシェイクの数を簡単に満たし、超えることができます。また、メモリ制限もそれほど問題にはなりません。64 ビット バイナリは、それ以外の場合に発生する可能性のある仮想メモリ制限に対処します。
しかし、OpenVPN の本当の利点は、非常に簡単に拡張できることです。任意の数の OpenVPN サーバーを設定し、クライアントがそれらを使用していることを確認し (DNS ラウンドロビンなど)、選択した動的ルーティング プロトコル (通常はシンプルなため RIP になります) を構成するだけで、十分なハードウェアがあれば、インフラストラクチャは任意の数のクライアントをサポートできるようになります。
答え2
私は実際にこれを実行しましたが、DSL ルーターの背後にある「わずか」数百のリモート接続だけでした。キー再生成の問題についてはあまりコメントできませんが、その過程で学んだ実用的なことがいくつかあります。
1) クライアントを展開するときは、クライアント設定で複数の VPN サーバー (vpn1.example.com、vpn2.example.com、vpn3...) を指定してください。現時点では、これらのうち 1 つまたは 2 つだけを指定する場合でも、余裕が生まれます。適切に構成されていれば、クライアントは、動作するサーバーが見つかるまでランダムに再試行し続けます。
2) 当社ではカスタム AWS VPN サーバー イメージを使用しており、オンデマンドで追加容量を増設できます。また、Amazon DNS (R53) が DNS 側を処理します。これは、当社のインフラストラクチャの残りの部分から完全に切り離されています。
3) サーバー側では、ネットマスクを慎重に使用して、潜在的なクライアントの数を制限します。これにより、クライアントを別のサーバーに強制的に移動させ、CPU の問題を軽減できます。サーバーを 300 台程度のクライアントに制限していると思います。この選択は、私たちの側でいくぶん恣意的でした。いわば「直感」です。
4) また、サーバー側では、ファイアウォールを慎重に使用する必要があります。簡単に言うと、クライアントが VPN 接続できるようにファイアウォールを設定していますが、サーバーは既知の IP アドレス以外からの SSH 接続をすべて厳しく禁止しています。必要に応じて、クライアントに SSH 接続できますが、クライアントが私たちに SSH 接続することはできません。
5) クライアント側で OpenVPN が再接続を行うことを期待しないでください。10 回中 9 回は再接続されますが、時々停止することがあります。クライアント側で定期的に OpenVPN をリセット/再起動する別のプロセスを用意してください。
6) クライアントに一意のキーを生成して、時々それらを否認できるようにする方法が必要です。私たちは、サーバー ビルド (PXEboot) プロセスを使用して、これらを内部的に生成します。私たちにはそのようなことは一度もありませんでした。しかし、それが可能であることはわかっています。
7) VPN サーバー接続を効果的に監視するには、いくつかの管理ツールやスクリプトが必要になります。
残念ながら、これを行う方法についての資料はあまりありませんが、慎重に構成すれば可能です。
答え3
2018年アップデート
2012 年から何が変わったのかはわかりません。2018 年の私の経験について最新情報をお伝えしたいと思いました。私たちは、OP セットアップに非常によく似た OpenVPN ネットワークを展開しました。エンドポイントは、組み込みデバイスではなく、本格的な Linux PC です。各エンドポイントには、そのサイトの情報とアラームを表示するモニターがあり、サーバーは、すべてのエンドポイントにリモート接続するための単一のポイントを提供します。ネットワークは過度にアクティブではありませんが、5 ～ 10 のリモート セッションが同時に実行されることがあります。
シングル コアと 2 GB の RAM を搭載した Azure イメージで約 100 のクライアントで現在の OpenVPN ビルドを使用すると、平均で約 0.7% のメモリが使用され、CPU 使用率はほぼ常に約 0% になります。この小規模なテストで判明したことに基づくと、十分な RAM があれば、適切な仕様の単一サーバーで 50000 の同時接続を簡単に処理できると考えられます。RAM 使用量が直線的に増加する場合、16 GB で 50000 人のユーザーを処理でき、専用の OpenVPN マシンで十分な余裕があります。
自信を持ってそう言えるほどの規模ではありませんが、最初にネットワークを展開したときにこれを見つけ、この規模でははるかに多くのリソースが使用されると予想していたので、最近のアップデートをお伝えしたいと思いました。現在、これを実行する CPU にはハードウェア暗号化が搭載されていると思いますが、どの時点でトラフィックが過負荷になるかはわかりませんが、あまり通信しないエンドポイントでは問題にならないはずです。
1000000 では、1 台のマシンに 200 GB の RAM が必要になります (追加で線形に拡張する場合)。これは可能ですが、その時点で、単一障害点がないように、それぞれ 64 GB の RAM を搭載したマシンを 5 台用意することをお勧めします。これにより、1 台または 2 台のマシンのメンテナンス、再起動、交換が大きな問題なく実行できるようになります。
私の RAM の推定値は、OpenVPN の使用量全体をクライアント数で割っているため、おそらく過剰です。クライアントによる RAM は、その一部だけです。
最初に導入してから 1 年で 74 個のエンドポイントを追加しました。この数を大幅に増やし続けたいと考えており、十分な規模に達したらさらに更新する予定です。
答え4
私は同様の問題を調査中ですが、クライアントの数は数百、おそらく数千になるでしょう。
すべてのクライアントを常に接続したままにすることはできないと考えました。
私は、クライアントがポーリングされたかどうかを確認できるように、ランダムな時間間隔でクライアント上で OpenVPN デーモンを起動することを考えています。ポーリングされた場合、クライアントはオンラインであることを知らせる電子メールなどを送信し、接続できるように一定期間キープアライブ パケットを送信します。
しばらくトラフィックがない場合、デーモンは停止されます。
私が現在直面している問題は、現在接続されている VPN クライアントのリストを取得することが不可能であるように思われることです...