☰

異なるクライアント用に複数の OpenVPN インスタンスを設定するためのベスト プラクティス

tag-icon • tag-icon linux vpn openvpn pki
異なるクライアント用に複数の OpenVPN インスタンスを設定するためのベスト プラクティス

私は、さまざまな顧客の IoT デバイスを中央サーバーに接続するために OpenVPN インスタンスを設定する必要があるプロジェクトに取り組んでいます。各クライアントには、独自の分離された VPN 接続が必要です。現在、インフラストラクチャと証明書の処理を計画しており、最適なアプローチについてアドバイスをいただきたいと思います。

証明書の処理については、次の構造を検討しています。

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

/etc/openvpn/server/Client1/そこで、やのように、各クライアントごとに個別の OpenVPN インスタンスを設定し/etc/openvpn/server/Client2/、次のようなコマンドを使用して起動します。

sudo systemctl start [email protected] これは受け入れられるアプローチでしょうか? 複数の VPN クライアントとサーバーのインフラストラクチャを整理するための洞察や代替案があれば、ぜひ教えてください。

その他の質問は次のとおりです:

  • 多数の分散デバイスを管理するには、Ansible などはどうでしょうか?
  • OpenVPN インスタンスごとに追加のポートが必要です。
    • 443 TCP、UDP と 1194 TCP、UDP を使用した後、次は何が起こるでしょうか?

ありがとう！

答え1

OpenVPN のマニュアルには、OpenVPN で設定した CA 証明書の子孫であるすべての証明書を信頼すると記載されています。したがって、VPN を本当に分離するには、すべての構成からルート証明書を省略します。ルート証明書はどこにも使用されず、価値や利点も追加されないので、わざわざ維持する必要はありません。EasyRSA を使用して、VPN ごとに個別の独立した「ルート、単一レベル」CA を作成してください。

ここでポート 443 をリストした理由がわかりません。このポートはよく知られている HTTPS ポートであり、占有されていることが多いため、OpenVPN ではほとんど使用されません。そのため、このポートが使用されると、 が関係する設定が複雑になることがよくありますport-share。その場合は、sslhの方が優れています。少なくとも、デーモンがリモートの実際の IP を確認するために「透過モード」を使用でき、OpenVPN がその情報を利用できるようにする方法を気にする必要がないためです。ただし、この特殊性がプロジェクトに必要なとは思えません。それ以外は、任意のポート番号を使用できます。1194 は「公式」としてリストされていますが、11941 や 1195、5000 (15 年前に提案されました) などを設定することを禁止するものはありません。ポートのセット (たとえば、1194 から始まる) を選択し、後続の VPN インスタンスごとに 1 つずつ追加します。

残りは正しいです。独立したデーモンには別々の (パブリック) ポートを使用し、それらを別々の SystemD ユニットとして実行します。異なる VPN には別々のコンテナーを検討してください。単一の名前空間で別々の VPN インスタンスを実行することは可能ですが、それらを分割する方が簡単でエラーも少なくなります (リソースの消費もそれほど多くありません)。私が理解したように、顧客は無関係なエンティティであるため、これを分離する方がより直接的な方法になります。その場合、コンテナー内の VPN 構成ではデフォルトのポートを使用できますが、それらに対して異なるポートを転送 (公開) します。

VPN の管理専用のシステムを指定します。このシステムは CA を保存し、証明書を発行できます。このシステムは CRL を発行するためにも必要です。デフォルトでは CRL の有効期限は 30 日間ですが、設定すればcrl-verify(設定します)、CRL の有効期限が切れると、VPN は CRL が再び有効になるまで新しい接続を受け付けなくなります。したがって、実際に自動化する必要があるのは CRL の再発行と配布です。CRL ファイルを更新するときにデーモンをリロードする必要はないので、scpターゲット システムに古いファイルを上書きするだけで十分です。

OpenVPN クライアント構成ファイル テンプレートを作成し、そのテンプレートから証明書が埋め込まれたクライアント構成を生成すると便利です。これにより、Ansible がなくても多くの時間を節約できました。バンドルされたファイルをカスタマイズしopenssl.cnfてvars、いくつかのフィールドを追加し、未使用のものを削除し、整理し直して、より少ない質問で (またはバッチ処理の場合は質問なしで) 実行するようにすることがよくあります。あなたのケースでは、新しい VPN とサーバー構成を作成するためのこのようなテンプレートと生成スクリプトがあると便利な場合があります。このようなテンプレート、スクリプト、カスタマイズは、新しい顧客または既存の顧客の新しい IoT デバイスをインスタンス化する Ansible プレイブックに役立ちます。後者の場合、証明書の CN を IoT デバイスのシリアル番号に結び付けると、アカウンティングが簡素化されるので便利です。

関連情報