Hola
>>>Somos una organización pequeña que solo necesitamos como máximo menos de 10 personas que necesitan la VPN, ¿todavía no es práctico?, ¿todavía >>>ne la necesidad de hacer un servidor de CA interno?
1. Pues depende. Si no tiene ningún problema con los costos / presupuesto / gastos para comprar certificados separados para el servidor VPN y 10 clientes VPN, entonces puede seguir adelante y obtener los certificados de una CA comercial, e instalar estos certificados en RV340 y en los 10 clientes
2. PERO de cualquier manera (ya sea obtener de una CA comercial o crear sus propios certificados instalando su propia CA interna en una máquina interna) DEBE recordar 1 cosa:
- Para el certificado en VPN-Server (RV34X), asegúrese de que
a) el valor fieild "Common Name/CN" se establece en un nombre FQDN/DNS del servidor vpn, como su nombre de dominio DNS registrado (por ejemplo, para suposir su "example.com") como vpnservergw.example.com o rv34x.example.com O si está utilizando el servidor dyns-dns, entonces podría ser rv34x.dyndns.org o vpnservergw.dyndns.org
b) el mismo FQDN en el CN/CommonName también debe establecerse como "subject-Alt-Name" en el certificado:
DNS:rv34x.ejemplo.com
o
DNS:vpnservergw.example.com
o
DNS:rv34x.dyndns.org
- Para los 10 certificados de cliente, asegúrese de que cada uno de los certificados de cliente tenga un valor individual/separado para el campo subject-alt-name en el certificado de cliente en forma de id de correo electrónico, como se indica a continuación (suponiendo que esté utilizando su nombre de dominio registrado "example.com"
Para el certificado Client1, el nombre subject-alt-name debe establecerse como, por ejemplo: client1@example.com
Para el certificado Client2, el nombre subject-alt-name debe establecerse como, por ejemplo: client2@example.com
Para el certificado Client3, el nombre subject-alt-name debe establecerse como, por ejemplo: client3@example.com
.... y así sucesivamente
>>>>Usted responde me hace darme cuenta de que es posible que no estemos decidiendo correctamente. En nuestro caso, ¿un PSK sería tan seguro como un certificado? En mi >>>, la gran ventaja de cert es que podemos caducar / invalidar certificados a través de la CA, pero si solo somos 10 y solo 1 sitio, >>> podría cancelar o cambiar fácilmente el PSK. Qué te parece.
Ok, la información que debe tener en cuenta con referencia a los servidores IKEv2-VPN para IKEv2-VPN-Clients es:
Podría haber diferentes métodos que podrían ser confgured/set, pero por configuraciones básicas estándar, hay 3 métodos para confgure/usar el IKEv2-vpn-server para vpn-clients
1. El servidor VPN IKEv2 que utiliza PSK para la autenticación
- Aquí la autenticación psk es para autenticar mutuamente el servidor vpn y los clientes vpn como pares ipsec, y por lo tanto NO hay nombre de usuario / contraseña involucrado en este establecimiento de túnel
- Solo los clientes Greenbow y MacOS / iOS IKEv2 admiten este método
- El cliente nativo de windows-IKev2 no admite ikev2-auth basado en PSK (solo admite certificados y EAP-Mschapv2 con nombre de usuario/passwd, y también EAP-TLS)
2. Servidor VPN IKEv2 que utiliza certificados para la autenticación ike
a) Aquí también, solo se utilizan certificados tanto en el servidor vpn como en los clientes para la autenticación mutua de los pares IPsec (servidor y cliente)
- y no hay uso de nombre de usuario / contraseña para la autenticación extendida
- El cliente nativo de Windows-IKEv2 admite esto (debe seleccionar el botón de opción "certificados de máquina" en las secciones de configuración del cliente)
- Los clientes Greenbow y MacOS / iOS también admiten esto
- En este caso, tanto el servidor como los clientes deben tener sus propios certificados separados que se utilizarán para realizar la autenticación mutua IKEv2 de los pares.
b) Entonces, ¿cómo obtiene cada uno de los tipos de cliente la autenticación ikev2 utilizando certificados?
En el cliente IKEv2 nativo de Windows
----------------------------
- En cuanto al cliente nativo de windows-ikev2, no hay configuración para establecer/seleccionar el valor subject-alt-name en el client-cert.
- Por lo tanto, windows first server enviará su server-cert que se verificará / autenticará en el windows-client utilizando el certificado Root-CA del certificado de servidor que se importó al cliente anteriormente. A continuación, el propio cliente de Windows simplemente enviará el campo subject-name (conocido como campo DN o simplemente ASN1DN) de su client-cert al vpn-server que se verificará y validará en el vpn-server utilizando el rootCA-cert que había firmado el client-cert
En Greenbow-client
-------------------
- En este cliente, sería preferible utilizar el valor U-FQDN en su certificado de cliente como Local-ID
- y así primero autenticará el certificado del servidor utilizando el certificado root-CA que firmó el certificado server-cert
- y a continuación, el cliente GB enviará su certificado al servidor, donde, dependiendo de las configuraciones, el servidor VPN utilizará el campo asunto del certificado cliente O comprobará el nombre subject-altname para el valor U-FQDN (clientX@example.com) en el certificado cliente y coincide con el valor del identificador remoto que se ha configurado en el servidor VPN
En el cliente macOS
---------------
- Aquí vamos a configurar el valor UFQDN en el campo subject-alt-name del client-cert instalado en este macOS
- Este valor se configurará como Local-ID en el cliente macOS
- El proceso de autenticación del certificado del servidor VPN en mac-client utilizando el certificado RootCA, y el cliente que se autentica en función del valor del campo Remote-ID establecido en el servidor. El ID requerido/relevante se comprueba en el campo subject-alt-name del client-cert
3. Servidor VPN IKEv2 utilizando métodos EAP (como EAP-Mschapv2 con nombre de usuario/passwd)
- Aquí en este caso, el servidor vpn se autenticará utilizando el certificado de servidor enviado al cliente (verificado en el cliente utilizando el certificado RootCA que había importado en el cliente al principio)
- Y en el cliente, NO hay ningún certificado instalado.
- Y el cliente se autenticará usando EAP (en este caso será EAP-Mschapv2 usando el username-passwd configurado en los clientes)
