Agrupación de direcciones IPv4 de cliente

Cuando cree un servidor VPN, se le solicitará una agrupación de direcciones IPv4 de cliente (rango de CIDR). Al cliente, se le asigna una dirección IP para su sesión desde esta agrupación de direcciones. Tenga en cuenta que la propiedad de la agrupación de IP de cliente no se debe solapar con los prefijos de las direcciones de VPC. El servicio VPN valida la dirección IP del cliente si la agrupación de IP de cliente se solapa con un prefijo de dirección existente.

Revise los requisitos siguientes:

• A cada cliente VPN activo se le asigna una dirección IP desde una agrupación de IP configurable. Debe seleccionar el rango de CIDR de IP cuidadosamente, para asegurarse de que no se solape con el prefijo de VPC y el CIDR local del dispositivo personal.
• En función del caso de uso, la agrupación de IP de cliente no se puede solapar con la dirección IP del dispositivo local del cliente. La agrupación de IP de cliente tampoco se puede solapar con la red de destino; por ejemplo, si se utiliza el servidor VPN para acceder a la red clásica de IBM Cloud, la IP de cliente no se puede solapar con la red clásica de IBM Cloud.
• Debe asegurarse de que el tamaño de bloque sea, como mínimo, /22 (1024 direcciones IP libres). Se recomienda utilizar un bloque CIDR que contenga el doble del número de direcciones IP necesarias para habilitar el número máximo de conexiones simultáneas.

Subredes: comparación entre alta disponibilidad y modalidad autónoma

Al crear un servidor VPN, puede especificar la opción de alta disponibilidad o de modalidad autónoma.

• Si selecciona la modalidad de alta disponibilidad, debe desplegar el servidor VPN en dos subredes en zonas distintas. Utilice esta modalidad para los despliegues de producción. Se recomienda para despliegues de varias zonas y para soluciones en las que el acceso a la VPN del cliente resulta fundamental.
• Si selecciona la modalidad autónoma, despliegue el servidor VPN en una subred y una zona únicas. Utilice esta modalidad para un despliegue piloto de no producción en el que no se no se requiera resiliencia de varias zonas.

Autenticación del servidor VPN

Debe especificar un certificado de servidor VPN durante el suministro. Puede crear un certificado utilizando IBM Cloud Secrets Manager, o utilizar uno propio.

Si utiliza la CLI o la API, debe especificar el CRN del certificado. Para obtener el certificado CRN, consulte Ubicación del CRN de certificado.

Si el servidor VPN utiliza únicamente la autenticación con ID de usuario y clave de acceso, solo es necesario especificar el certificado de servidor VPN, que incluye la clave pública/privada y el certificado de CA. El servicio VPN obtiene la clave pública y la privada de la instancia de certificado y las almacena en el servidor VPN. Este certificado de CA también se copia en el perfil de cliente para que el cliente pueda utilizar el certificado de CA para verificar el servidor VPN.

Si la autenticación de certificado está habilitada, debe especificar el certificado de CA de cliente. La clave pública y la clave privada no son necesarias. El servicio VPN obtiene el certificado CA del cliente de Secrets Manager. A su vez, el cliente presenta su clave pública cuando se conecta con el servidor VPN, y el servidor VPN utiliza el certificado de CA para verificar la clave pública.

Si los certificados de cliente y de servidor VPN están firmados por la misma CA, el administrador puede utilizar la misma instancia de certificado al suministrar el servidor VPN.

Para obtener más información, consulte Configuración de la autenticación de cliente a servidor.

Autenticación de cliente de VPN

Como administrador del servidor VPN, debe elegir al menos un método de autenticación y configurarlo durante el suministro de servidor VPN. Puedes elegir un certificado de cliente, seguridad añadida con un ID de usuario y un código de acceso, o ambos tipos de autenticación de cliente.

Varios clientes de VPN pueden compartir un certificado de cliente.

Si tiene previsto utilizar el certificado de cliente, el usuario debe editar el perfil de cliente proporcionado por el administrador del servidor e incluir el certificado de cliente (también denominado clave pública) y la clave privada. Tenga en cuenta que no es necesario modificar el perfil de cliente si sólo se utiliza la autenticación de cliente "ID de usuario y código de acceso".

Cuando se utiliza un certificado privado para la autenticación de cliente, el administrador no necesita modificar el perfil de cliente. En su lugar, el administrador puede descargar el perfil de cliente con el certificado privado fusionado y la clave para todos los certificados, o seleccionar certificados privados y descargar el perfil de cliente con el certificado privado fusionado y la clave para los certificados seleccionados. Para obtener más información, consulte Configuración de un entorno VPN de cliente y conexión a un servidor VPN.

Los usuarios de VPN no utilizan directamente su contraseña para conectarse al servidor VPN. Obtienen la clave de acceso de IBM Access Manager (IAM) a través de un navegador y, si se ha habilitado la MFA, esta siempre se aplica a través del navegador. El usuario debe configurar la MFA correctamente para asegurarse de que se pueda aplicar en el navegador. Cuando el usuario obtiene la clave de acceso, la introduce en el cliente de OpenVPN e inicia la conexión.

El servidor VPN recibe el nombre de usuario y la clave de acceso del cliente de VPN y realiza una llamada de IAM para verificar la clave de acceso y el permiso con la directiva de IAM.

• El código de acceso es una contraseña de un solo uso. El usuario DEBE volver a generar la clave de acceso para volver a conectarse, incluso si la reconexión la inicia el servidor VPN.
• No se admite la MFA de SoftLayer, ya que esta no se ejecuta a través del navegador.

Si utiliza la autenticación de ID de usuario/clave de acceso, las actividades de mantenimiento obligan a los usuarios a volver a autenticarse captando la clave y volviendo a especificarla. La conexión se restaura solo después de especificar el nuevo código. Esto se aplica utilizando la modalidad autónoma o de alta disponibilidad.

Listas de revocación de certificados de cliente

Si lo desea, puede importar una lista de revocación de certificados (CRL), que es una lista con marca de tiempo de los certificados revocados por una entidad emisora de certificados (CA). Es posible que un certificado de una lista de revocación de certificados (CRL) no haya caducado, pero haya perdido la confianza de la entidad emisora de certificados que ha emitido el certificado. El cliente de VPN utiliza esta lista para validar los certificados digitales.

Después de importar una CRL, el cliente de VPN utiliza esta lista para validar los certificados digitales. La CRL se guarda como una cadena (no un archivo) en el sistema. Si necesita descargar la CRL en el futuro, se ha renombrado como <vpn_server_name>.pem.

Para obtener más información, consulte Configuración de la autenticación de cliente a servidor.

Protocolo de transporte

La capa de transporte supervisa la entrega de datos desde un proceso en un dispositivo a un proceso en otro dispositivo. Los protocolos de la capa de transporte actúan como enlaces entre los protocolos de la capa de aplicación y los servicios que proporciona la red. Client VPN for VPC admite los protocolos siguientes:

Se recomienda UDP para conseguir un rendimiento óptimo y TCP para obtener la mayor fiabilidad.

• User Datagram Protocol (UDP)

  El protocolo User Datagram Protocol (UDP) es un protocolo simple y ligero con una sobrecarga mínima. Si un proceso quiere enviar un mensaje pequeño y no le importa la fiabilidad, puede utilizar UDP. Se tarda mucho menos tiempo en enviar un mensaje utilizando UDP que utilizando TCP. La comprobación de errores no es muy detallada y no ofrece ninguna ventaja con respecto a los servicios de IP, salvo por el hecho de que proporciona una comunicación de proceso a proceso, en lugar de una comunicación de host a host.

• Transmission Control Protocol (TCP)

  El protocolo Transmission Control Protocol (TCP) es un protocolo de capa de transporte fiable, pero complejo. TCP aporta características orientadas a la conexión y fiabilidad a los servicios de IP.

  TCP es un servicio de entrega en secuencia que garantiza la entrega de secuencias de datos enviadas de un host a otro sin duplicación ni pérdida de datos. Puesto que la transferencia de paquetes no es fiable, se utiliza una técnica conocida como acuse de recibo positivo con retransmisión para garantizar la fiabilidad de las transferencias de paquetes. Esta técnica fundamental requiere que el receptor responda con un mensaje de acuse de recibo cuando recibe los datos.

  El remitente guarda un registro de cada paquete que envía y espera el acuse de recibo antes de enviar el siguiente paquete. El emisor también conserva un temporizador del momento en el que se ha enviado el paquete y lo vuelve a transmitir si el temporizador caduca. Este temporizador es necesario en caso de que un paquete se pierda o se dañe.

Modalidad de túnel completo frente a modalidad de túnel dividido

Cuando se configura una conexión VPN, se crea un túnel cifrado a través de Internet al servidor VPN. La conexión VPN aparece como una interfaz de red virtual en el sistema, además de la interfaz LAN existente. Ahora, puede utilizar ambas interfaces simultáneamente enviando el tráfico privado destinado a la VPC dentro del túnel VPN y el tráfico público (tráfico de Internet) a través de la otra interfaz (fuera del túnel VPN). Cuando el tráfico se divide entre la interfaz VPN y otras interfaces, se dice que se está usando un tunelado dividido. Cuando no se usa el tunelado dividido, todo el tráfico utiliza la interfaz VPN, lo que resulta en que el tráfico de Internet se envía al túnel VPN, que es un túnel completo.

Otras consideraciones:

• Utilice la modalidad de túnel completo (predeterminada) si le preocupa la seguridad en los accesos del cliente a Internet sin un túnel VPN. La modalidad de túnel completo suele ser necesaria para lograr la conformidad con los estándares normativos; sin embargo, este enfoque puede resultar caro y también aumenta la carga del servidor VPN.
• En modalidad de túnel dividido, el servidor VPN envía por push las rutas al cliente de VPN. De esta forma, el cliente de OpenVPN sabe qué tráfico se debe enviar al túnel VPN. Debe tener cuidado al añadir rutas, para evitar los bucles de direccionamiento. Por ejemplo, si la dirección IP pública del servidor VPN es 3.3.3.3, no se puede añadir una ruta 3.3.3.0/24, porque esta ruta enviaría tráfico a 3.3.3.3 que no debería pasar por el túnel VPN. Lo ideal es configurar la subred privada solo como destino de ruta, como una subred de VPC, una subred de CSE, una subred privada local, etc.
• La ruta de VPN se envía por push al cliente de VPN. Si el cliente de VPN ya tiene una ruta con el mismo destino, el envío por push de la ruta falla y el tráfico no puede acceder al servidor VPN. Debe solucionar el conflicto de las rutas y, a continuación, volver a conectar el cliente de VPN. Un problema habitual se produce cuando se añade una ruta VPN con el destino 0.0.0.0/0 en un servidor VPN en modalidad de túnel dividido y esta ruta debe ser enviada por push al cliente de VPN. Normalmente, el cliente de VPN ya tiene una ruta con el destino 0.0.0.0/0; por lo tanto, esta ruta de VPN entrará en conflicto con la ruta del cliente de VPN. Para evitar este conflicto, utilice un servidor VPN en modalidad de túnel completo o elimine la ruta 0.0.0.0/0 del host.

No importa qué modalidad de túnel elija, debe utilizar la API /vpn_servers/{id}/routes para definir cómo reenvía el servidor VPN el tráfico desde el cliente de VPN. Por ejemplo, si quiere que el tráfico de Internet del cliente pase por el túnel VPN, debe configurar una ruta 0.0.0.0/0 utilizando la API de rutas del servicio VPN.

Software de cliente de VPN soportado

Debe proporcionar software de cliente de VPN a los usuarios. Se verifica el uso de las siguientes versiones de software de cliente:

• Para macOS Catalina y posteriores: OpenVPN Conectar v3, OpenVPN Conectar v2, y Tunnelblick 3.8.4
• Windows 8 y posterior: OpenVPN Connect v3, OpenVPN Connect v2
• RHEL 7.x y posteriores: OpenVPN Connect v3, OpenVPN Connect v2, y OpenVPN cliente de línea de comandos (versión 2.4.4 y posteriores)
• Ubuntu 18.04 y posteriores: OpenVPN Connect v3, OpenVPN Connect v2, y OpenVPN cliente de línea de comandos (versión 2.4.10 y posteriores)

Los usuarios de cliente de VPN pueden elegir otro software de cliente compatible con OpenVPN-2.4. Sin embargo, no se garantiza que el software que no aparece en la lista funcione.

IBM Power Virtual Servers: Automatizar el despliegue del espacio de trabajo

Está disponible un proyecto de automatización de VPN de cliente a sitio que proporciona un módulo de Terraform para crear un servidor VPN de cliente a sitio, lo que permite a los usuarios conectarse de forma segura desde un dispositivo local o remoto a un espacio de trabajo de Power Virtual Server. El repositorio Github para este proyecto de automatización se encuentra en IBM / power-vpn-server Repositorio Github. Este proyecto Archivo léame crea un servidor VPN y lo adjunta a un espacio de trabajo nuevo o existente de Power Virtual Server, proporcionando acceso seguro a la infraestructura de IBM Cloud Power.