こんにちは
>>>私たちはVPNを必要とする最も少なくとも10人未満しか必要としない小さな組織ですが、それはまだ実用的ではありません>>>内部CAサーバーを実行する必要がありますか?
1. まあ、それは依存します。VPN サーバーと 10 VPN クライアントの個別の証明書を購入するためのコスト/予算/費用に問題がない場合は、先に進んで商用 CA から証明書を調達し、RV340 および 10 クライアントにこれらの証明書をインストールできます。
2. しかし、どちらかの方法 (商用 CA から調達するか、内部マシンに独自の内部 CA をインストールして独自の証明書を作成) 1 つのことを覚えておく必要があります。
- VPN サーバー (RV34X) 上の証明書については、次の手順に従います。
a) 「共通名/CN」fieild 値は、vpnservergw.example.com 登録された DNS ドメイン名 (rv34x.example.com などの"example.com"を前提とします) などの vpn-server の FQDN/DNS 名に設定され、dyns-dns サーバーを使用している場合は、rv34x.dyndns.org または vpnservergw.dyndns.org
b) CN/CommonName の同じ FQDN も証明書の "サブジェクト Alt-名前" として設定する必要があります。
DNS:rv34x.例.com
又は
DNS:vpnservergw.の例.com
又は
DNS:rv34x.dyndns.org
- 10 のクライアント証明書の場合、各クライアント証明書の各サブジェクト代替名フィールドの値が、以下のように電子メール ID の形式でクライアント証明書のサブジェクト代替名フィールドに個別に設定されていることを確認します (登録済みのドメイン名「example.com」を使用していると仮定します。
client1 証明書の場合、サブジェクトの alt-name は次のように設定client1@example.com
client2 証明書の場合、サブジェクトの alt-name は次のように設定する必要があります client2@example.com
client3 証明書の場合、サブジェクトの alt-name は次のように設定client3@example.com
....などなど
>>>>答えると、私たちは正しく決定していないかもしれないことに気づきます。 私たちの場合、PSKは証明書と同じくらい安全でしょうか? 私の>>>心証明書の大きな利点は、CAを通じて認証を期限切れ/無効にすることができるということですが、私たちの10と1つのサイトがあれば >>>、私は簡単にPSKをキャンセルまたは変更することができます。 どう思いますか。
IKEv2-VPN-クライアント用の IKEv2-VPN サーバを参照して、次の情報を知っておく必要があります。
打ち明ける/設定できる方法はさまざまですが、標準的な基本構成では、VPN クライアントに対して IKEv2-vpn-server を混同/使用する方法が 3 つあります。
1. 認証に PSK を使用する IKEv2 vpn サーバ
-ここでの psk 認証は、vpn-server と vpn クライアントを ipsec ピアとして相互に認証するため、このトンネルの確立に関与するユーザ名とパスワードはありません。
- このメソッドをサポートするのはグリーンボウクライアントと MacOS/iOS IKEv2 クライアントのみです
- ネイティブウィンドウ IKev2 クライアントは PSK ベースの ikev2 認証をサポートしていません(証明書のみ、およびユーザー名/パスド、および EAP-TLS を使用した EAP-Mschapv2 のみ)
2. IKE 認証用の証明書を使用した IKEv2 VPN サーバ
a) ここでも、IpSec ピア (サーバーとクライアント) の相互認証に VPN サーバーとクライアントの両方で証明書のみが使用されます。
- 拡張認証にユーザー名/パスワードを使用しない
- ネイティブの Windows-IKEv2 クライアントはこれをサポートしています (クライアント構成セクションで「マシン証明書」ラジオボタンを選択する必要があります)
- グリーンボウおよび MacOS/iOS クライアントもこの機能をサポートしています。
この場合、サーバとクライアントの両方が、ピアの相互 IKEv2 認証を行うために使用される独自の証明書を持っている必要があります。
b) では、各クライアントタイプはどのようにして証明書を使用して ikev2 認証を行うのでしょうか?
ネイティブ IKEv2 クライアントの場合
----------------------------
- ネイティブの windows-ikev2-client に関しては、クライアント証明書のサブジェクト alt 名の値を設定/選択する構成はありません。
- したがって、Windows の最初のサーバーは、以前にクライアントにインポートされたサーバー証明書の Root-CA 証明書を使用して、Windows クライアントで検証/認証されるサーバー証明書を送信します。次に、Windows クライアント自体は、クライアント証明書のサブジェクト名フィールド (DN フィールドまたは単に ASN1DN と呼ばれます) を vpn-server に送信し、クライアント証明書に署名した rootCA-cert を使用して VPN サーバー上で検証および検証を行います。
グリーンボウクライアントで
-------------------
- このクライアントでは、クライアント証明書の U-FQDN 値をローカル ID として使用することが望ましいでしょう。
- そして、最初にサーバー証明書に署名したルート CA 証明書を使用して証明書を認証します。
- 次に、GB クライアントはサーバーに証明書を送信し、構成に応じて vpn-server はクライアント証明書のサブジェクト・フィールドを使用するか、クライアント証明書の U-FQDN 値 (clientX@example.com) のサブジェクト・アルトネームをチェックし、VPN サーバーで構成されたリモート識別子の値に一致します。
MacOS クライアントで
---------------
- ここでは、この macOS にインストールされているクライアント証明書のサブジェクト alt-name フィールドに UFQDN 値を設定します。
- この値は macOS クライアントでローカル ID として設定されます。
- Vpn-server 証明書が RootCA 証明書を使用して Mac クライアントで認証を受け、クライアントがサーバーに設定されたリモート ID フィールドの値に基づいて認証を受けるプロセス。必須/関連 ID は、クライアント証明書の subject-alt-name フィールドでチェックされます。
3. EAP 方式を使用する IKEv2 VPN サーバー (ユーザー名/パスドを使用した EAP-Mschapv2 など)
- この場合、vpn-server はクライアントに送信されるサーバー証明書を使用して認証されます (クライアントで最初にクライアントにインポートした RootCA 証明書を使用して検証されます)。
- クライアントには証明書がインストールされていません。
- クライアントは EAP を使用して認証を行います (この場合、クライアントで設定されたユーザ名 passwd を使用して EAP-Mschapv2 になります)
