Acerca de las pasarelas VPN de sitio a sitio
Puede utilizar el servicio IBM Cloud VPN for VPC para conectar de forma segura el Virtual Private Cloud (VPC) a otra red privada. Utilice una VPN estática basada en ruta o una VPN basada en políticas para configurar un túnel de sitio a sitio de IPsec entre el VPC y la red privada local u otro VPC.
La VPN basada en ruta ya está disponible además de la VPN basada en política. Para empezar, seleccione Basado en ruta como modalidad al crear una pasarela VPN y crear rutas utilizando el tipo de conexión VPN.
Características de VPN for VPC
El servicio IBM Cloud VPN for VPC incluye las siguientes características:
MD-5 y SHA-1, 2 y 5 grupos DH, y el algoritmo de cifrado 3-DES quedaron obsoletos el 20 de septiembre de 2022 y ya no son compatibles con la consola.
-
Autenticación: IBM Cloud VPN for VPC da soporte a una clave precompartida para la autenticación de iguales de fase 1. Los algoritmos de autenticación admitidos para ambas fases son SHA-256, SHA-384 y SHA-512.
-
Alta disponibilidad: IBM Cloud VPN for VPC se basa en dos dispositivos VPN para proporcionar redundancia a nivel de dispositivo. Una VPN basada en política opera en modalidad de Espera Activa con una sola IP de pasarela VPN compartida entre los miembros, mientras que una VPN basada en ruta ofrece redundancia de tipo Activo-Activo con dos IP de pasarela VPN.
Una VPN estática basada en ruta se despliega en modalidad de redundancia activa-activa. Dos túneles VPN están conectados con la pasarela VPN de igual; sin embargo, la pasarela de IBM siempre utiliza el túnel con la IP pública pequeña como la vía de acceso de salida primaria. El túnel con la IP pública grande es la vía de acceso de salida secundaria. El tráfico desde IBM VPC a la red local pasa por la vía de acceso de salida primaria si ambos túneles están activos. El tráfico pasa por la vía de acceso de salida secundaria si la vía de acceso de salida primaria está inhabilitada. La pasarela VPN local debe utilizar la prioridad de ruta para elegir la misma vía de acceso preferida. Más información
-
Detección de igual inactivo: mecanismo configurable para detectar la disponibilidad de un igual de IPsec.
-
Diffie-Hellman (DH): protocolo de intercambio de claves utilizado en la fase 1 para generar una clave secreta compartida entre iguales de VPN. Si lo desean, los usuarios pueden habilitar Perfect Forward Secrecy (PFS) y un grupo de DH para la negociación de la fase 2 de IPsec. IBM Cloud VPN para VPC admite los grupos DH 14-24 y 31.
-
Cifrado- IBM Cloud VPN para VPC soporta AES-128, AES-192, y AES-256 para el cifrado de datos tanto durante la Fase 1 como la Fase 2 de IKE.
-
Internet Key Exchange (IKE): IKE forma parte del protocolo de IPsec que se utiliza para establecer conexiones VPN. En la fase 1 de IKE, los iguales de VPN utilizan el intercambio de claves Diffie-Hellman (DH) para crear un canal de comunicación seguro y autenticado. En la fase 2 de IKE, los iguales utilizan el canal seguro de la fase 1 para negociar los parámetros para los túneles de IPsec. IBM Cloud VPN for VPC da soporte a IKEv1 (modalidad principal) e IKEv2. Consulte Acerca de la negociación de políticas para ver las combinaciones admitidas.
-
IPsec: suite de protocolos que proporciona comunicación segura entre dispositivos. IBM Cloud VPN para VPC utiliza la encapsulación UDP de paquetes IPsec Encapsulating Security Protocol (ESP) en modo túnel, que ofrece autenticación y encriptación completa de paquetes.
-
Modalidades: IBM Cloud VPN for VPC ofrece modalidades de VPN basadas en rutas estáticas y basadas en políticas. Con una VPN basada en políticas, el tráfico que coincide con los rangos de CIDR negociados pasa a través de la VPN. Para una VPN basada en rutas estáticas, se crean interfaces de túneles virtuales y todo el tráfico que se direcciona hacia estas interfaces lógicas con rutas personalizadas pasa a través de la VPN. Ambas opciones de VPN proporcionan las mismas características.
-
Perfect forward secret (PFS): PFS garantiza que las claves generadas por DH no se utilicen de nuevo durante la renegociación de IPsec. Si la seguridad de una clave se ve comprometida, solo se puede acceder a los datos en tránsito durante el tiempo de vida de la asociación de seguridad protegida.
Iniciación a pasarelas de VPN
Antes de crear una VPN, debe crear una VPC y una o varias subredes para su VPN y otros recursos.
Aunque no es obligatorio, se recomienda dedicar una subred de al menos 16 IP (prefijo 28 o inferior) para la pasarela VPN. Si decide suministrar recursos adicionales dentro de la subred de VPN, asegúrese de que siempre haya al menos 4 IP disponibles para las tareas de recuperación y mantenimiento para que las utilice la pasarela VPN. Además de las 4 IP que necesita la pasarela VPN, se reservan hasta 5 IP en una subred para uso interno de la red. Por lo tanto, asegúrese de que la subred sea lo suficientemente grande.
Para crear una pasarela VPN, siga estos pasos generales:
-
Asegúrese de que las ACL de red para que el tráfico VPN fluya están en su lugar.
-
Asegúrese de que el dispositivo de igual dé soporte a NAT transversal y esté habilitado en el dispositivo de igual. Para obtener más información, consulte Limitaciones de pasarela de VPN.
-
Revise las consideraciones de planificación y cree la pasarela VPN.
-
IBM Cloud VPN for VPC solo da soporte a una VPN basada en ruta por zona y por VPC.
-
Para las VPN estáticas basadas en rutas, seleccione o cree una tabla de direccionamiento para el direccionamiento estático y, a continuación, cree rutas utilizando el tipo de conexión VPN.
-
Verifique que la conexión VPN esté disponible enviando la acción ping o data traffic a través del túnel a los dispositivos que están en la red de iguales.
Arquitectura
En este diagrama se ilustra una configuración de VPN de ejemplo con varias redes locales. La VPN está configurada en una subred dentro de una VPC de un usuario, pero puede ser compartida por instancias en todas las subredes dentro de la zona. Las políticas de IKE e IPsec también pueden ser utilizadas por una o varias conexiones de VPN.
Sobre la negociación de políticas
Para ambas fases de negociación IKE, los iguales de IPsec deben intercambiar propuestas de parámetros de seguridad, admitidas por cada uno en su configuración, y acordar un conjunto de configuraciones. Las políticas IKE e IPsec personalizadas permiten a los usuarios de IBM Cloud VPN for VPC configurar estos parámetros de seguridad utilizados durante la negociación.
El uso de las políticas IKE e IPsec para configurar una conexión VPN es opcional. Cuando no se selecciona una política, las propuestas predeterminadas se eligen automáticamente a través de un proceso conocido como negociación automática.
Los principales parámetros de seguridad que intervienen en este proceso de negociación son los siguientes:
- Fase de IKE
- Algoritmo de cifrado
- Algoritmo de autenticación
- Grupo de Diffie-Hellman (protocolo de intercambio de claves de cifrado)
Debido a que la negociación automática de IBM Cloud utiliza IKEv2, el dispositivo local también debe utilizar IKEv2. Utilice una política IKE personalizada si el dispositivo local no admite IKEv2.
Negociación automática de IKE (fase 1)
Puede utilizar las siguientes opciones de cifrado, autenticación y grupo de Diffie-Hellman en cualquier combinación:
| Cifrado | Autenticación | Grupo DH | |
|---|---|---|---|
| 1 | aes128 | sha256 | 14-24, 31 |
| 2 | aes192 | sha384 | 14-24, 31 |
| 3 | aes256 | sha512 | 14-24, 31 |
Negociación automática de IPsec (fase 2)
Puede utilizar las siguientes opciones de cifrado y autenticación en cualquier combinación, o utilizar las siguientes opciones de cifrado de modalidad combinada que requieren que se inhabilite la autenticación.
De forma predeterminada, PFS está inhabilitado para IBM Cloud VPN for VPC. Algunos proveedores exigen habilitar PFS en la fase 2. Compruebe las instrucciones del proveedor y utilice políticas personalizadas si se exige PFS.
| Cifrado | Autenticación | Grupo DH | |
|---|---|---|---|
| 1 | aes128 | sha256 | Inhabilitado |
| 2 | aes192 | sha384 | Inhabilitado |
| 3 | aes256 | sha512 | Inhabilitado |
| Cifrado | Autenticación | Grupo DH | |
|---|---|---|---|
| 1 | aes128gcm16 | Inhabilitado | Inhabilitado |
| 2 | aes192gcm16 | Inhabilitado | Inhabilitado |
| 3 | aes256gcm16 | Inhabilitado | Inhabilitado |
casos de uso de VPN for VPC
Caso de uso 1: conexión VPN con un único dispositivo de igual remoto del mismo tipo que está asociado a una o más redes de igual
Tanto las VPN basadas en ruta como las basadas en política permiten a los usuarios conectarse a un solo dispositivo de igual remoto asociado con una o varias redes.
Este caso de uso no se aplica a las conexiones entre una VPN basada en política y una VPN basada en ruta. Para obtener más información, consulte Limitaciones conocidas.
Caso de uso 2: Conexiones de VPN con varios dispositivos de igual remotos
Las VPN basadas en políticas y basadas en rutas permiten que los usuarios se conecten a varios dispositivos remotos de igual asociados con diferentes VPC/entornos utilizando varias conexiones VPN.
Caso de uso 3: configuración avanzada de VPN mediante un FQDN
El caso de uso siguiente ilustra un cliente que tiene una VPC en IBM Cloud y desea conectar su sitio local con una única pasarela VPN. La pasarela VPN del sitio local está detrás de un dispositivo NAT y no tiene ninguna dirección IP pública. La identidad IKE local de la pasarela VPN local es la dirección IP privada que posee. Un FQDN está asociado con la dirección IP pública del dispositivo NAT.
Caso práctico 4: Distribución del tráfico para una VPN basada en rutas
Una VPN basada en rutas tiene 2 túneles activos en el backend. Cuando ambos túneles VPN están activados, sólo se utiliza 1 túnel para enrutar el tráfico VPN a través del túnel.
La VPN utiliza el túnel con la IP pública pequeña como ruta de salida primaria. Cuando la ruta de salida primaria está desactivada, el tráfico fluye a través de la ruta secundaria. La razón de utilizar sólo un túnel para encaminar el tráfico
es evitar el problema del encaminamiento asimétrico. El siguiente diagrama muestra la configuración por defecto. Cuando se crea una ruta con destino 10.1.0.0/24 y el siguiente salto es la conexión VPN, si tanto tunnel 1 como tunnel 2 están activas, se devuelve la IP privada 10.254.0.2 del dispositivo VPN para la creación de la ruta.
El filtrado del estado del protocolo en una interfaz de red virtual ofrece opciones para abordar el problema del enrutamiento asimétrico. Para obtener más información, consulte Modo de filtrado del estado del protocolo.
Al crear conexiones para una VPN basada en rutas, ahora puede habilitar la distribución de tráfico entre los Up túneles de la conexión de la pasarela VPN cuando el siguiente salto de una ruta VPC es la conexión VPN. Para lograr
este modo de redundancia activo/activo, debe activar la función "distribuir tráfico" al crear o añadir conexiones a una pasarela VPN.
Como se muestra en el siguiente diagrama, la salida del tráfico se enruta a los 2 túneles de forma dinámica. Cuando los túneles son Up, se devuelven las direcciones IP privadas 10.254.0.2 y 10.254.0.3 y el servicio de red VPC crea 2 rutas. Como estas rutas tienen la misma prioridad, el tráfico fluye hacia tunnel 1 y tunnel 2 dinámicamente.
Para utilizar esta función, el dispositivo local debe admitir el enrutamiento asimétrico para obtener un mayor rendimiento de la red. Además, tenga en cuenta que no todas las pasarelas VPN locales admiten este caso de uso. Por ejemplo, si la entrada y la salida del tráfico VPN proceden de túneles diferentes, el tráfico podría ser bloqueado por dispositivos VPN o cortafuegos locales.