Problemas conocidos de las pasarelas VPN

Los problemas conocidos son fallos identificados o comportamientos inesperados que no se solucionaron antes del lanzamiento, pero que no eran lo suficientemente críticos como para retrasarlo. Estos problemas se le comunican, a menudo con soluciones alternativas, y se priorizan para que el equipo de desarrollo los resuelva a corto plazo.

Los problemas conocidos de las pasarelas VPN de sitio a sitio son los siguientes:

• Una pasarela VPN para VPC sólo acepta paquetes VPN con encapsulación UDP de paquetes IPsec ESP. No se aceptan paquetes ESP(Encapsulating Security Payload ). Asegúrese de que la característica NAT-T esté habilitada en su dispositivo VPN local. Además, asegúrese de que los puertos UDP 500 y 4500 están permitidos tanto para IBM VPC NACL como para las redes pares.

  NAT-T permite que el tráfico VPN atraviese los dispositivos NAT encapsulando los paquetes IPsec en UDP. Sin NAT-T, los paquetes IPsec podrían ser descartados por los dispositivos NAT porque no pueden gestionar correctamente el tráfico ESP. Para conseguir una conectividad VPN fiable a través de dispositivos NAT, NAT-T debe estar activado en su dispositivo local.

• Cuando haya varias redes, subredes o ambas asociadas con una pasarela de VPN de IBM Cloud con un dispositivo local, evite mezclar VPN basadas en política y basadas en ruta. Las VPN basadas en política crean un túnel para cada rango de red de destino. Sin embargo, las VPN basadas en ruta direccionan todo a un dispositivo de igual a través de un solo túnel. Por lo tanto, cuando se configuran varios rangos de red, sólo se puede establecer un único túnel asociado a un único rango de red. Combinar subredes contiguas en un único superconjunto CIDR es una solución válida.

• Las subredes homólogas de una conexión de pasarela VPN no se pueden solapar.

• Transit Gateway el filtrado de prefijos no es compatible actualmente con las pasarelas VPN.

• Cuando conecte una VPN basada en políticas con un peer basado en rutas (o una VPN estática basada en rutas con un peer basado en políticas), utilice un único rango de red para ambos lados. Una VPN basada en políticas utiliza un túnel para cada red asociada, mientras que una VPN basada en rutas sólo requiere un único túnel. Es posible que las conexiones entre distintos tipos de VPN asociadas a varios rangos de red a ambos lados sólo funcionen para un rango de red.

  {: caption="

  Si es posible, combine subredes contiguas en un solo rango de red en una configuración de VPN. Por ejemplo, las subredes 192.168.0.0/24 y 192.168.1.0/24 se pueden definir como 192.168.0.0/23 en una configuración de VPN o de direccionamiento.

• Una pasarela VPN basada en política de IBM Cloud reside en la zona asociada con la subred que seleccione durante el suministro. La pasarela VPN sólo sirve a instancias de servidor virtual en la misma zona de la VPC. Por lo tanto, las instancias de otras zonas no pueden utilizar la pasarela VPN para comunicarse con una red privada local. Para una tolerancia a errores en las zonas, despliegue una pasarela VPN por zona.

• Una pasarela VPN basada en ruta de IBM Cloud reside en la zona asociada con la subred que seleccione durante el suministro. Se recomienda que una pasarela VPN solo sirva a instancias de servidor virtual en la misma zona de la VPC. Añadiendo rutas de salida personalizadas a la tabla de enrutamiento para dirigir el tráfico, las instancias de otras zonas pueden utilizar la pasarela VPN basada en rutas para comunicarse con una red privada local; sin embargo, no se recomienda esta configuración. Para una tolerancia a errores en las zonas, despliegue una pasarela VPN por zona.

• Al configurar y optimizar las conexiones VPN de IPsec de sitio a sitio, es posible que se encuentre con problemas de rendimiento de red, uno de los cuales está relacionado con la fijación de Unidad de transmisión máxima (MTU) y Tamaño máximo de segmento (MSS). Para obtener más información, consulte IBM VPN site-to-site Maximum Transmission Unit(MTU)clamping.

• Cuando una ruta utiliza una conexión de puerta de enlace VPN como siguiente salto, debe estar presente en una tabla de enrutamiento de salida asociada a subredes VPC. Además, cuando la pasarela VPN reenvía tráfico al túnel VPN, comprueba si la IP de origen de este tráfico se encuentra dentro de la subred que está adjunta a esa tabla de enrutamiento. Si la IP de origen está fuera de esa subred, el tráfico no se encripta ni se envía a través del túnel VPN a la puerta de enlace par. Por ejemplo, si la pasarela VPN recibe tráfico que se enruta a través de la tabla de enrutamiento de entrada, el tráfico no se reenvía al túnel VPN porque la IP de origen está fuera de la subred que se adjunta a la tabla de enrutamiento.

  No se admite la creación de una ruta en una tabla de enrutamiento de entrada con una conexión de puerta de enlace VPN como siguiente salto.

• La configuración de las identidades IKE local y peer (dirección, FQDN o nombre de host) es opcional cuando se crea una pasarela VPN. Sin embargo, la actualización posterior de la dirección peer o FQDN podría afectar a la conectividad VPN:

  • Si no especifica las identidades IKE local y peer, la pasarela utiliza automáticamente los valores por defecto: la IP pública de la pasarela VPN se utiliza como identidad IKE local, y la IP pública de la pasarela peer se utiliza como identidad IKE peer. Esta configuración por defecto ayuda a mantener una conexión VPN estable incluso si cambia la dirección del par.
  • Si estableces explícitamente las identidades IKE local y peer, estás bloqueando valores específicos. En este caso, la actualización de la dirección peer o FQDN requiere que elimine y vuelva a crear la conexión VPN para evitar romper la conectividad.