Compartir vía

Preguntas más frecuentes sobre VPN Gateway

  • Artículo

En este artículo se da respuesta a las preguntas más frecuentes sobre las conexiones entre locales de Azure VPN Gateway, las conexiones de configuración híbrida y las puertas de enlace de red virtual (VNet). Contiene información completa sobre los valores de configuración de punto a sitio (P2S), de sitio a sitio (S2S) y de configuración de red virtual a red virtual, incluidos los protocolos de seguridad de Internet (IPsec) y de Intercambio de claves por red (IKE).

Conexión a redes virtuales

¿Puedo conectar redes virtuales en diferentes regiones de Azure?

Sí. No hay ninguna restricción de región. Una red virtual puede conectarse a otra red virtual de la misma región de Azure o de otra diferente.

¿Puedo conectar redes virtuales en diferentes suscripciones?

Sí.

¿Puedo especificar servidores DNS privados en mi red virtual al configurar una puerta de enlace de VPN?

Si especifica un servidor o servidores del Sistema de nombres de dominio (DNS) al crear la red virtual, la puerta de enlace de red privada virtual (VPN) usa esos servidores DNS. Compruebe que los servidores DNS especificados puedan resolver los nombres de dominio necesarios para Azure.

¿Puedo conectar a varios sitios desde una única red virtual?

Puede conectarse a varios sitios mediante el uso de Windows PowerShell y las API de REST de Azure. Consulte la sección de P+F Conectividad de red virtual a red virtual y multisitio.

¿Hay un costo adicional para configurar una puerta de enlace VPN como activa-activa?

No. Sin embargo, los costos de direcciones IP públicas adicionales se cobrarán como corresponda. Consulte Precios de direcciones IP.

¿Cuáles son mis opciones de conexión entre locales?

Azure VPN Gateway admite las siguientes conexiones de puerta de enlace entre locales:

Para más información sobre las conexiones de VPN Gateway, consulte ¿Qué es VPN Gateway?.

¿Cuál es la diferencia entre una conexión de sitio a sitio y una de punto a sitio?

  • Las configuraciones de sitio a sitio (túnel de VPN sobre IPsec/IKE) se encuentran entre la ubicación local y Azure. Puede conectarse desde cualquiera de sus equipos ubicados en su entorno local a cualquier máquina virtual (VM) o instancia de rol dentro de su red virtual, en función de cómo elija configurar el enrutamiento y los permisos. Es ideal para una conexión entre locales que esté siempre disponible y una opción que se adapta bien a las configuraciones híbridas.

    Este tipo de conexión se basa en un dispositivo VPN IPsec (dispositivo de hardware o dispositivo temporal). El dispositivo debe implementarse en el perímetro de la red. Para crear este tipo de conexión, debe tener una dirección IPv4 externa.

  • Las configuraciones de punto a sitio (VPN sobre SSTP) le permiten conectarse desde una única máquina y desde cualquier lugar con cualquier dispositivo de la red virtual. Usa el cliente VPN integrado de Windows.

    Como parte de la configuración de punto a sitio, se instala un certificado y un paquete de configuración de cliente VPN. El paquete contiene la configuración que permite que el equipo se conecte a cualquier máquina virtual o instancia de rol dentro de la red virtual.

    Esta configuración es útil cuando desea conectarse a una red virtual, pero no se encuentra en el entorno local. También es una buena opción cuando no tenga acceso a un hardware VPN o una dirección IPv4 con orientación externa, ya que ambos son necesarios para una conexión de sitio a sitio.

Puede configurar la red virtual para utilizar las conexiones de sitio a sitio y de punto a sitio simultáneamente, siempre y cuando la conexión de sitio a sitio se cree mediante un tipo de VPN basada en rutas para la puerta de enlace. Los tipos de VPN basada en rutas se denominan puertas de enlace dinámicas en el modelo de implementación clásico.

¿La configuración incorrecta del DNS personalizado interrumpe el funcionamiento normal de una instancia de VPN Gateway?

Para el funcionamiento normal, la instancia de VPN Gateway debe establecer una conexión segura y obligatoria con el plano de control de Azure, que se facilita a través de direcciones IP públicas. Esta conexión se basa en la resolución de puntos de conexión de comunicación a través de direcciones URL públicas. De forma predeterminada, las redes virtuales de Azure usan el servicio Azure DNS integrado (168.63.129.16) para resolver estas direcciones URL públicas. Este comportamiento predeterminado ayuda a garantizar una comunicación fluida entre la instancia de VPN Gateway y el plano de control de Azure.

Al implementar un DNS personalizado dentro de una red virtual, es fundamental configurar un reenviador DNS que apunte a Azure DNS (168.63.129.16). Esta configuración ayuda a mantener una comunicación ininterrumpida entre la instancia de VPN Gateway y el plano de control. Si no se configura un reenviador DNS en Azure DNS, se puede impedir que Microsoft realice operaciones y mantenimiento en la instancia de VPN Gateway, lo que supone un riesgo de seguridad.

Para ayudar a garantizar una funcionalidad adecuada y un estado correcto de la instancia de VPN Gateway, considere una de las siguientes configuraciones de DNS en la red virtual:

  • Volver al valor predeterminado de Azure DNS quitando el DNS personalizado dentro de la configuración de la red virtual (configuración recomendada).
  • Agregar a la configuración de DNS personalizada un reenviador DNS que apunte a Azure DNS (168.63.129.16). Según las reglas y la naturaleza específicas de su DNS personalizado, es posible que esta configuración no resuelva el problema según lo previsto.

¿Pueden comunicarse dos clientes VPN conectados de punto a sitio a la misma instancia de VPN Gateway?

No. Los clientes VPN conectados de punto a sitio a la misma instancia de VPN Gateway no se pueden comunicar entre sí.

Cuando dos clientes VPN están conectados a la misma instancia de VPN Gateway de punto a sitio (P2S), la puerta de enlace puede enrutar automáticamente el tráfico entre ellos al determinar la dirección IP del grupo de direcciones a la que se asigna cada cliente. Sin embargo, si los clientes VPN están conectados a diferentes instancias de VPN Gateway, el enrutamiento entre los clientes VPN no es posible porque cada instancia de VPN Gateway no conoce la dirección IP asignada al cliente por la otra instancia.

¿Una posible vulnerabilidad conocida como "visión de túnel" podría afectar a las conexiones VPN de punto a sitio?

Microsoft está al tanto de informes sobre una técnica de red que evita la encapsulación de VPN. Se trata de un problema que afecta a todo el sector. Afecta a cualquier sistema operativo que implemente un cliente de Protocolo de configuración dinámica de host (DHCP) según su especificación RFC y que tenga compatibilidad con las rutas 121 de la opción DHCP, incluido Windows.

Como señala la investigación, las mitigaciones incluyen la ejecución de la VPN dentro de una máquina virtual que obtiene una concesión de un servidor DHCP virtualizado para evitar que el servidor DHCP de la red local instale rutas por completo. Puede encontrar más información sobre esta vulnerabilidad en la base de datos nacional de vulnerabilidades de NIST.

Privacidad

¿El servicio VPN almacena o procesa datos de los clientes?

No.

Puertas de enlace de red virtual

¿Es la puerta de enlace de VPN una puerta de enlace de red virtual?

Una puerta de enlace de VPN es un tipo de puerta de enlace de red virtual. Una puerta de enlace de VPN envía tráfico cifrado entre la red virtual y la ubicación local a través de una conexión pública. También puede utilizar una puerta de enlace de VPN para enviar tráfico entre redes virtuales. Al crear una instancia de VPN Gateway, use Vpn con el valor -GatewayType. Para más información, consulte Acerca de la configuración de VPN Gateway.

¿Por qué no puedo especificar tipos de VPN basados en directivas y basados en rutas?

A partir del 1 de octubre de 2023, no puede crear una instancia de VPN Gateway basada en directivas mediante Azure Portal. Todas las nuevas instancias de VPN Gateway se crean automáticamente como basadas en rutas. Si ya tiene una puerta de enlace basada en directivas, no es necesario actualizarla a basada en rutas. Puede usar Azure PowerShell o la CLI de Azure para crear las puertas de enlace basadas en directivas.

Anteriormente, las versiones más antiguas de productos de puerta de enlace (SKUs) no admitían IKEv1 para puertas de enlace basadas en rutas. Ahora, la mayoría de las SKU de puerta de enlace actuales admiten IKEv1 y IKEv2.

Tipo de VPN de la puerta de enlace SKU de puerta de enlace Versiones de IKE admitidas
Puerta de enlace basada en directivas Basic IKEv1
Puerta de enlace basada en rutas Basic IKEv2
Puerta de enlace basada en rutas VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 IKEv1 e IKEv2
Puerta de enlace basada en rutas VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ IKEv1 e IKEv2

¿Puedo actualizar mi puerta de enlace VPN basada en directivas a una basada en el enrutamiento?

No. Un tipo de puerta de enlace no puede cambiarse de basado en directiva a basado en ruta, o de basado en ruta a basado en directiva. Para cambiar un tipo de puerta de enlace, debe eliminar y volver a crear la puerta de enlace siguiendo estos pasos. Este proceso tarda aproximadamente 60¹minutos. Cuando se crea la nueva puerta de enlace, no se puede conservar la dirección IP de la puerta de enlace original.

  1. Elimine las conexiones asociadas a la puerta de enlace.

  2. Elimine la puerta de enlace siguiendo los pasos que se indican en uno de los siguientes artículos:

  3. Cree una nueva puerta de enlace utilizando el tipo de puerta de enlace que desee y, a continuación, complete la configuración de la VPN. Para conocer los pasos, consulte el tutorial sobre las conexiones de sitio a sitio.

¿Puedo especificar mis propios selectores de tráfico basados en directivas?

Sí, puede definir selectores de tráfico usando el atributo trafficSelectorPolicies en una conexión mediante el comando New-AzIpsecTrafficSelectorPolicy de Azure PowerShell. Para que el selector de tráfico especificado surta efecto, asegúrese de habilitar los selectores de tráfico basados en directivas.

Los selectores de tráfico configurados personalizados solo se proponen cuando una instancia de VPN Gateway inicia la conexión. Las puertas de enlace de VPN aceptarán los selectores de tráfico que proponen las puertas de enlace remotas (es decir, los dispositivos VPN locales). Este comportamiento es coherente entre todos los modos de conexión (Default, InitiatorOnly y ResponderOnly).

¿Necesito una subred de puerta de enlace?

Sí. La subred de puerta de enlace contiene las direcciones IP que usan los servicios de puerta de enlace de la red virtual. Necesitará crear una subred de puerta de enlace de red virtual para configurar la puerta de enlace de la red virtual.

Todas las subredes de puerta de enlace deben llamarse GatewaySubnet para que funcionen correctamente. No denomine de ninguna otra forma la subred de puerta de enlace. Y no implemente máquinas virtuales ni nada más en la subred de puerta de enlace.

Al crear la subred de puerta de enlace, especifique el número de direcciones IP que contiene la subred. Las direcciones IP de la subred de puerta de enlace se asignan al servicio de puerta de enlace.

Algunas configuraciones requieren la asignación de más direcciones IP a los servicios de puerta de enlace que otras. Asegúrese de que la subred de puerta de enlace contenga suficientes direcciones IP para soportar el crecimiento futuro y las posibles configuraciones de nuevas conexiones.

Aunque puede crear una subred de puerta de enlace tan pequeña como /29, se recomienda que sea de /27 o mayor (/27, /26, /25, etc.). Compruebe que la subred de puerta de enlace existente cumpla los requisitos de la configuración que desea crear.

¿Puedo implementar máquinas virtuales o instancias de rol en mi subred de puerta de enlace?

No.

¿Puedo obtener mi dirección IP de puerta de enlace VPN antes de crearla?

Los recursos de IP pública de SKU estándar de Azure deben usar un método de asignación estático. Tendrá la dirección IP pública de la instancia de VPN Gateway en cuanto cree el recurso de IP pública de la SKU estándar que tiene pensado usar para ella.

¿Se puede solicitar una dirección IP pública estática para una puerta de enlace de VPN?

Los recursos de IP pública de SKU Estándar deben usar un método de asignación estático. En el futuro, deberá usar una dirección IP pública del SKU estándar al crear una nueva puerta de enlace de VPN. Este requisito se aplica a todas las SKU de puerta de enlace, excepto a la SKU básica. Actualmente, la SKU básica solo admite direcciones IP públicas de SKU básica. Estamos trabajando para agregar compatibilidad con direcciones IP públicas de SKU estándar para la SKU básica.

En el caso de puertas de enlace sin redundancia de zona y no zonales que se hayan creado anteriormente (SKU de puerta de enlace que no tienen AZ en el nombre), se admite la asignación de direcciones IP dinámicas, pero se está eliminando gradualmente. Cuando se usa una dirección IP dinámica, la dirección IP no cambia después de que se haya asignado a la instancia de VPN Gateway. La única vez que cambia la dirección IP de la instancia de VPN Gateway es cuando se elimina y se vuelve a crear la puerta de enlace. La dirección IP pública no cambia aunque se cambie el tamaño, se restablezca o se lleven a cabo otras operaciones de mantenimiento interno y actualizaciones de la instancia de VPN Gateway.

¿Cómo afecta la retirada de direcciones IP públicas de SKU Basic a mis puertas de enlace de VPN?

Estamos tomando medidas para garantizar el funcionamiento continuo de las puertas de enlace de VPN implementadas que usan direcciones IP públicas de SKU básica hasta la retirada de la dirección IP básica en septiembre de 2025. Antes de esta retirada, proporcionaremos a los clientes una ruta de migración de la dirección IP básica a estándar.

Sin embargo, las direcciones IP públicas de SKU básica se están eliminando gradualmente. En el futuro, al crear una instancia de VPN Gateway, debe usar la dirección IP pública de SKU estándar. Puede encontrar detalles sobre la retirada de las direcciones IP públicas de SKU básica en el anuncio de actualizaciones de Azure.

¿Cómo se autentica mi túnel VPN?

Azure VPN Gateway usa la autenticación de clave precompartida (PSK). Generamos una PSK cuando creamos el túnel VPN. Puede cambiar la PSK generada automáticamente por su cuenta mediante la API de REST Set Pre-Shared Key o el cmdlet Set Pre-Shared Key de PowerShell.

¿Puedo usar la API de REST Set Pre-Shared Key para configurar mi VPN de puerta de enlace basada en directivas (enrutamiento estático)?

Sí. Sí, puede usar la API de REST y el cmdlet de PowerShell Set Pre-Shared Key para configurar tanto las VPN de enrutamiento basadas en directivas (estático) de Azure como las basadas en rutas (dinámico).

¿Puedo usar otras opciones de autenticación?

Está limitado a usar claves previamente compartidas (PSK) para la autenticación.

¿Cómo especifico qué tráfico pasa a través de la puerta de enlace VPN?

Para el modelo de implementación de Azure Resource Manager:

  • Azure PowerShell: use AddressPrefix para especificar el tráfico de la puerta de enlace de red local.
  • Azure Portal: vaya a puerta de enlace de red local>Configuración>Espacio de direcciones.

Para el modelo de implementación clásico:

  • Azure Portal: vaya a la red virtual clásica y, a continuación, vaya a Conexiones VPN>Conexiones VPN de sitio a sitio>nombre del sitio local>sitio local>Espacio de direcciones del cliente.

¿Puedo usar NAT-T en las conexiones VPN?

Sí, se admite la traducción de direcciones de red transversal (NAT-T). Azure VPN Gateway no realiza ninguna funcionalidad de tipo NAT en los paquetes internos hacia y desde los túneles de IPsec. En esta configuración, asegúrese de que el dispositivo local inicie el túnel IPSec.

¿Puedo configurar mi propio servidor VPN en Azure y usarlo para conectar a mi red local?

Sí. Puede implementar sus propias puertas de enlace o servidores VPN en Azure bien desde Azure Marketplace o creando sus propios enrutadores VPN. Debe configurar las rutas definidas por el usuario en la red virtual para asegurarse de que el tráfico se enruta correctamente entre las redes locales y las subredes de la red virtual.

¿Por qué hay algunos puertos abiertos en mi puerta de enlace de red virtual?

Son necesarios para la comunicación de la infraestructura de Azure. Los certificados de Azure ayudan a protegerlos, ya que los bloquean. Sin los certificados apropiados, las entidades externas, incluidos los clientes de esas puertas de enlace, no podrán tener ningún efecto en esos puntos de conexión.

Una puerta de enlace de red virtual es fundamentalmente un dispositivo de host múltiple. Un adaptador de red se conecta a la red privada del cliente, y otro adaptador de red se orienta hacia la red pública. Las entidades de la infraestructura de Azure no pueden conectarse a redes privadas de clientes por motivos de cumplimiento, por lo que deben usar puntos de conexión públicos para la comunicación de infraestructura. Una auditoría de seguridad de Azure examina periódicamente los puntos de conexión públicos.

¿Puedo crear una instancia de VPN Gateway mediante la SKU básica en el portal?

No. La SKU básica no está disponible en el portal. Puede crear una instancia de VPN Gateway de SKU básica mediante la CLI de Azure o los pasos de Azure PowerShell.

¿Dónde puedo obtener más información acerca de los tipos de puerta de enlace, los requisitos y el rendimiento?

Vea los artículos siguientes:

Desuso de las SKU anteriores

Las SKU estándar y de alto rendimiento quedarán en desuso el 30 de septiembre de 2025. Puede ver el anuncio en el sitio de actualizaciones de Azure. El equipo del producto hará que una ruta de migración esté disponible para estas SKU el 30 de noviembre de 2024. Para obtener más información, consulte el artículo SKU heredados de VPN Gateway.

Por ahora, no tiene que realizar ninguna acción.

¿Puedo crear una nueva puerta de enlace que use una SKU estándar o de alto rendimiento después del anuncio de desuso del 30 de noviembre de 2023?

No. A partir del 1 de diciembre de 2023, no puede crear puertas de enlace que usen SKU estándar o de alto rendimiento. Puede crear puertas de enlace que usen SKU VpnGw1 y VpnGw2 por el mismo precio que las SKU estándar y de alto rendimiento, enumeradas respectivamente en la página de precios.

¿Cuánto tiempo se admitirán las puertas de enlace existentes en las SKU estándar o de alto rendimiento?

Todas las puertas de enlace existentes que usen SKU estándar o de alto rendimiento se admitirán hasta el 30 de septiembre de 2025.

¿Debo migrar mis puertas de enlace de la SKU estándar o de alto rendimiento en este momento?

No, no hay ninguna acción que deba realizar en este momento. Puede migrar las puertas de enlace a partir de diciembre de 2024. Enviaremos una comunicación con documentación detallada sobre los pasos de migración.

¿A qué SKU puedo migrar mi puerta de enlace?

Cuando la migración de SKU de puerta de enlace esté disponible, los SKU se podrán migrar de la siguiente manera:

  • De estándar a VpnGw1
  • De alto rendimiento a VpnGw2

¿Qué ocurre si quiero migrar a un SKU de AZ?

No puede migrar la SKU en desuso a una SKU de AZ. Sin embargo, todas las puertas de enlace que siguen usando la SKU estándar o de alto rendimiento después del 30 de septiembre de 2025 se migrarán y actualizarán automáticamente a las siguientes SKU de AZ:

  • De estándar a VpnGw1AZ
  • De alto rendimiento a VpnGw2AZ

Puede usar esta estrategia para que los SKU se migren y actualicen automáticamente a un SKU de AZ. Después, puede cambiar el tamaño del SKU dentro de esa familia de SKU si es necesario. Para información sobre los precios de SKU de AZ, consulte la página de precios. Para obtener información sobre el rendimiento por SKU, vea Acerca de las SKU de puerta de enlace.

¿Habrá alguna diferencia de precios para mis puertas de enlace después de la migración?

Si migra las SKU antes del 30 de septiembre de 2025, no habrá ninguna diferencia de precios. Los SKU VpnGw1 y VpnGw2 se ofrecen al mismo precio que los SKU estándar y de alto rendimiento, respectivamente.

Si no migra antes de esa fecha, los SKU se migrarán y actualizarán automáticamente a los SKU de AZ. En ese caso, hay una diferencia de precios.

¿Habrá algún impacto en el rendimiento en mis puertas de enlace con esta migración?

Sí. Se consigue un mejor rendimiento con VpnGw1 y VpnGw2. Actualmente, VpnGw1 a 650 Mbps proporciona una mejora del rendimiento de 6,5 veces al mismo precio que la SKU estándar. VpnGw2 a 1 Gbps proporciona una mejora del rendimiento de 5 veces al mismo precio que la SKU de alto rendimiento. Para más información sobre el rendimiento de las SKU, consulte Acerca de las SKU de puerta de enlace.

¿Qué ocurre si no migro las SKU antes del 30 de septiembre de 2025?

Todas las puertas de enlace que todavía usen SKU estándar o de alto rendimiento se migrarán automáticamente y se actualizarán a las siguientes SKU de AZ:

  • De estándar a VpnGw1AZ
  • De alto rendimiento a VpnGw2AZ

Enviaremos una comunicación antes de iniciar la migración en cualquier puerta de enlace.

¿La SKU básica de VPN Gateway también se retira?

No, la SKU básica de VPN Gateway no se retira. Puede crear una instancia de VPN Gateway usando la SKU básica a través de Azure PowerShell o la CLI de Azure.

Actualmente, la SKU básica de VPN Gateway solo admite el recurso de dirección IP pública de la SKU básica (que está en proceso de retirada). Estamos trabajando para agregar compatibilidad con el recurso de dirección IP pública de SKU estándar a la SKU básica de VPN Gateway.

Conexiones de sitio a sitio y dispositivos VPN

¿Qué tengo que tener en cuenta al seleccionar un dispositivo VPN?

Hemos validado un conjunto de dispositivos estándar VPN de sitio a sitio en colaboración con proveedores de dispositivos. Puede encontrar una lista de dispositivos VPN conocidos compatibles, sus instrucciones de configuración correspondientes o ejemplos, junto con especificaciones de dispositivos en el artículo Acerca de los dispositivos VPN.

Todos los dispositivos de las familias de dispositivos que aparecen como de compatibilidad conocida deberían funcionar con redes virtuales. Para ayudar a configurar el dispositivo VPN, consulte el ejemplo de configuración de dispositivos o el vínculo que corresponde a la familia de dispositivos adecuada.

¿Dónde puedo encontrar los valores de configuración de los dispositivos VPN?

En función del dispositivo VPN que tenga, es posible que pueda descargar un script de configuración del mismo. Para más información, consulte Descarga de scripts de configuración de dispositivos VPN para conexiones VPN S2S.

En los siguientes vínculos se proporciona más información de configuración:

Edición de ejemplos de configuración de dispositivos VPN

Consulte Edición de ejemplos de configuración de dispositivos.

¿Dónde encuentro los parámetros de IPsec e IKE?

Consulte Parámetros de IPsec/IKE predeterminados.

¿Por qué mi túnel de VPN basado en directivas deja de funcionar cuando el tráfico está inactivo?

Este es el comportamiento esperado para puertas de enlace de VPN basadas en directivas (lo que también se conoce como enrutamiento estático). Cuando el tráfico a través del túnel está inactivo durante más de 5 minutos, el túnel se descompone. Cuanto el tráfico comience a fluir en cualquier dirección, el túnel se restablecerá inmediatamente.

¿Puedo usar una VPN de software para conectarme a Azure?

Para la configuración de sitio a sitio entre locales se admiten los servidores de Windows Server 2012 con servicio de enrutamiento y acceso remoto (RRAS).

Otras soluciones VPN de software deberían funcionar con la puerta de enlace siempre que se ajusten a las implementaciones IPsec estándar del sector. Para obtener instrucciones de configuración y soporte técnico, póngase en contacto con el proveedor del software.

¿Puedo conectarse a una puerta de enlace de VPN a través de punto a sitio cuando se encuentra en un sitio que tiene una conexión de sitio a sitio activa?

Sí, pero las direcciones IP públicas del cliente de punto a sitio deben ser diferentes de las direcciones IP públicas que usa el dispositivo VPN de sitio a sitio; de lo contrario, la conexión de punto a sitio no funcionará. Las conexiones de punto a sitio con IKEv2 no se pueden iniciar desde la misma dirección IP pública donde está configurada una conexión VPN de sitio a sitio en la misma instancia de VPN Gateway.

Conexiones de punto a sitio

¿Cuántos extremos de cliente VPN puedo tener en mi configuración de punto a sitio?

Depende de la SKU de puerta de enlace. Para más información sobre el número de conexiones admitidas, consulte SKU de puerta de enlace.

¿Qué sistemas operativos de cliente puedo usar para las conexiones de punto a sitio?

Se admiten los siguientes sistemas operativos de cliente:

  • Windows Server 2008 R2 (solo 64 bits)
  • Windows 8.1 (32 bits y 64 bits)
  • Windows Server 2012 (solo 64 bits)
  • Windows Server 2012 R2 (solo 64 bits)
  • Windows Server 2016 (solo 64 bits)
  • Windows Server 2019 (solo 64 bits)
  • Windows Server 2022 (solo 64 bits)
  • Windows 10
  • Windows 11
  • macOS, versión 10.11 o posterior
  • Linux (strongSwan)
  • iOS

¿Puedo recorrer servidores proxy y firewalls con la funcionalidad de punto a sitio?

Azure admite tres tipos de opciones de VPN de punto a sitio:

  • Protocolo de túnel de sockets seguros (SSTP): una solución basada en SSL propietaria de Microsoft que puede atravesar firewalls, puesto que la mayoría de los firewalls abren el puerto TCP saliente que usa SSL 443.

  • OpenVPN: una solución basada en SSL que puede atravesar firewalls, puesto que la mayoría de los firewalls abren el puerto TCP 443 de salida que utiliza SSL.

  • VPN IKEv2: una solución VPN con IPsec basada en estándares que utiliza los puertos UDP 500 y 4500 de salida y el protocolo IP 50. Los firewalls no siempre abren estos puertos, por lo que existe la posibilidad de que la VPN IKEv2 no pueda recorrer servidores proxy y firewalls.

¿Si reinicio un equipo cliente con configuración de punto a sitio, se volverá a conectar la VPN de forma automática?

La reconexión automática es una función del cliente que se usa. Windows permite la reconexión automática mediante la característica de cliente VPN Always On.

¿Admite la configuración de punto a sitio el DDNS en los clientes VPN?

Las VPN de punto a sitio no admiten actualmente DNS dinámico (DDNS).

¿Pueden coexistir configuraciones de sitio a sitio y de punto a sitio en la misma red virtual?

Sí. Para el modelo de implementación de Resource Manager, debe tener un tipo de VPN basado en ruta para la puerta de enlace. Para el modelo de implementación clásica, necesita una puerta de enlace dinámica. No se admite la configuración de punto a sitio para puertas de enlace VPN de enrutamiento estático o puertas de enlace VPN basadas en directivas.

¿Se puedo configurar un cliente de punto a sitio para conectarse a varias puertas de enlace de red virtual al mismo tiempo?

En función del software cliente VPN que use, es posible que pueda conectarse a varias puertas de enlace de red virtual. Pero esto solo sucede si las redes virtuales desde las que se conecta no tienen espacios de direcciones en conflicto entre ellas o con la red desde la que se conecta el cliente. Aunque el cliente VPN de Azure admite muchas conexiones VPN, solo puede tener una conexión a la vez.

¿Puedo configurar un cliente de punto a sitio para conectarse a varias redes virtuales simultáneamente?

Sí. Las conexiones de cliente de punto a sitio a una instancia de VPN Gateway implementada en una red virtual emparejada con otras redes virtuales pueden tener acceso a las otras redes virtuales emparejadas, siempre y cuando cumplan determinados criterios de configuración. Para que un cliente de punto a sitio tenga acceso a una red virtual emparejada, la red virtual emparejada (la red virtual sin la puerta de enlace) debe configurarse con el atributo Usar puertas de enlace remotas. La red virtual con la instancia de VPN Gateway debe configurarse con Permitir tránsito de puerta de enlace. Para más información, consulte Información sobre el enrutamiento de VPN de punto a sitio.

¿Qué rendimiento puedo esperar en las conexiones de sitio a sitio o de punto a sitio?

Es difícil de mantener el rendimiento exacto de los túneles VPN. IPsec y SSTP son protocolos VPN con mucho cifrado. El rendimiento también está limitado por la latencia y el ancho de banda entre el entorno local e Internet.

En el caso de una instancia de VPN Gateway únicamente con conexiones VPN de punto a sitio IKEv2, el rendimiento total que puede esperar depende de la SKU de la puerta de enlace. Consulte SKU de puerta de enlace para más información sobre el rendimiento.

¿Puedo usar cualquier software de cliente VPN para las conexiones de punto a sitio que admita SSTP o IKEv2?

No. Solo puede usar el cliente VPN nativo en Windows para SSTP y el cliente VPN nativo en Mac para IKEv2. Sin embargo, puede utilizar el cliente OpenVPN en todas las plataformas para conectarse a través del protocolo OpenVPN. Consulte la lista de sistemas operativos cliente compatibles.

¿Puedo cambiar el tipo de autenticación de una conexión de punto a sitio?

Sí. En el portal, vaya a VPN Gateway>Configuración de punto a sitio. En Tipo de autenticación, seleccione el tipo de autenticación que desea usar.

Después de cambiar el tipo de autenticación, es posible que los clientes actuales no puedan conectarse hasta que genere un nuevo perfil de configuración de cliente VPN, lo descargue y lo aplique a cada cliente VPN.

¿Cuándo es necesario generar un nuevo paquete de configuración para el perfil de cliente VPN?

Al realizar cambios en las opciones de configuración de VPN Gateway P2S, como agregar un tipo de túnel o cambiar un tipo de autenticación, debe generar un nuevo paquete de configuración de perfil de cliente VPN. El nuevo paquete incluye la configuración actualizada que los clientes VPN necesitan para conectarse a la puerta de enlace P2S. Después de generar el paquete, use la configuración de los archivos para actualizar los clientes VPN.

¿Azure admite VPN IKEv2 con Windows?

IKEv2 se admite en Windows 10 y Windows Server 2016. Sin embargo, para poder usar IKEv2 en determinadas versiones del sistema operativo, tendrá que instalar las actualizaciones y establecer un valor de clave del Registro localmente. Las versiones del sistema operativo anteriores a Windows 10 no se admiten y solo pueden usar SSTP o el protocolo OpenVPN.

Nota:

Estos pasos no son necesarios en las compilaciones del sistema operativo Windows posteriores a Windows 10 versión 1709 y Windows Server 2016 versión 1607.

Para preparar Windows 10 o Windows Server 2016 para IKEv2:

  1. Instale la actualización en función de la versión del sistema operativo:

    Versión del SO Date Número/vínculo
    Windows Server 2016
    Windows 10 Versión 1607    		 17 de enero de 2018 KB4057142
    Windows 10 Versión 1703 17 de enero de 2018 KB4057144
    Windows 10 Versión 1709 22 de marzo de 2018 KB4089848

  2. Establezca el valor de clave del Registro. Cree o establezca la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayloadREG_DWORD del Registro en 1.

¿Cuál es el límite del selector de tráfico IKEv2 para las conexiones de punto a sitio?

Windows 10 versión 2004 (publicado en septiembre de 2021) aumentó el límite de selector de tráfico a 255. Las versiones anteriores de Windows tienen un límite de selector de tráfico de 25.

El límite del selector de tráfico en Windows determina el número máximo de espacios de direcciones en la red virtual y la suma máxima de redes locales, conexiones de red virtual a red virtual y redes virtuales emparejadas conectadas a la puerta de enlace. Los clientes de punto a sitio basados en Windows no se conectarán a través de IKEv2 si superan este límite.

¿Cuál es el límite del selector de tráfico OpenVPN para las conexiones de punto a sitio?

El límite del selector de tráfico para OpenVPN es de 1000 rutas.

¿Qué ocurre cuando se configuran SSTP e IKEv2 para conexiones VPN de P2S?

Cuando configura IKEv2 y SSTP en un entorno combinado que consta de dispositivos Windows y Mac, el cliente VPN de Windows siempre prueba primero el túnel IKEv2. El cliente vuelve a SSTP si la conexión IKEv2 no se realiza correctamente. MacOS solo se conecta a través de IKEv2.

Si tiene SSTP e IKEv2 habilitados en la puerta de enlace, el grupo de direcciones de punto a sitio se divide estáticamente entre los dos, por lo que los clientes que usan protocolos diferentes son direcciones IP de cualquier subintervalo. El número máximo de clientes SSTP siempre es 128, incluso si el intervalo de direcciones es mayor que /24. El resultado es un mayor número de direcciones disponibles para los clientes IKEv2. Para intervalos más pequeños, el grupo se reduce a la mitad de manera equitativa. Los selectores de tráfico que usa la puerta de enlace podrían no incluir el bloque Enrutamiento de interdominios sin clases (CIDR) para el intervalo de direcciones de punto a sitio, pero sí el bloque CIDR para los dos subintervalos.

¿Qué plataformas admite Azure para VPN P2S?

Azure es compatible con Windows, Mac y Linux para VPN de punto a sitio.

Ya tengo una puerta de enlace de VPN implementada. ¿Puedo habilitar una VPN IKEv2 o RADIUS en ella?

Sí. Sí, si la SKU de la puerta de enlace que usa admite RADIUS o IKEv2, puede habilitar estas características en las puertas de enlace ya implementadas mediante PowerShell o Azure Portal. La SKU de nivel Básico no admite RADIUS ni IKEv2.

¿Por qué me desconectan de mi cliente VPN de Azure? ¿Qué puedo hacer para reducir la frecuencia de desconexión?

Es posible que vea uno de los siguientes mensajes en los registros:

  • En el cliente VPN de Azure para Windows versión 3.4.0.0: "La autenticación con Microsoft Entra ha expirado. Debe volver a autenticarse en Entra para adquirir un nuevo token. El administrador puede ajustar el tiempo de espera de autenticación."
  • En el cliente VPN de Azure para macOS versión 2.7.101: "La autenticación con Microsoft Entra ha expirado, por lo que debe volver a autenticarse para adquirir un nuevo token. Intente conectarse de nuevo. El administrador configura las directivas de autenticación y el tiempo de espera en el inquilino de Entra."

La conexión de punto a sitio se desconecta porque el token de actualización actual en el cliente VPN de Azure, adquirido desde Entra ID, ha expirado o se ha convertido en no válido. Este token se renueva aproximadamente cada hora. Los administradores de inquilinos de Entra pueden ampliar la frecuencia de inicio de sesión agregando directivas de acceso condicional. Trabaje con los administradores de inquilinos de Entra para ampliar el intervalo de expiración del token de actualización.

Para obtener más información, consulte: Error de cliente VPN: La autenticación con Microsoft Entra expiró.

¿Cómo se puede quitar la configuración de una conexión P2S?

Puede quitar una configuración de P2S mediante los siguientes comandos de Azure PowerShell o la CLI de Azure:

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

Conexiones de punto a sitio con autenticación de certificado

¿Qué debo hacer si obtengo un error de coincidencia de certificado para una conexión de autenticación de certificado de punto a sitio?

Desactive la casilla Verificar la identidad del servidor validando el certificado. O bien, si crea el perfil manualmente, agregue el nombre de dominio completo (FQDN) del servidor junto con el certificado. Para ello, ejecute rasphone desde un símbolo del sistema y seleccione el perfil en la lista desplegable.

No se recomienda omitir la validación de la identidad del servidor en general. Sin embargo, con la autenticación de certificado de Azure, se usa el mismo certificado para la validación del servidor en el protocolo de túnel de VPN (IKEv2 o SSTP) y el protocolo de autenticación extensible (EAP). Dado que el protocolo de túnel de VPN ya está validando el certificado de servidor y el FQDN, es redundante validarlos de nuevo en EAP.

Recorte de pantalla que muestra las propiedades de la autenticación de punto a sitio.

¿Puedo usar mi propio CA raíz de PKI interna para generar certificados de conectividad de punto a sitio?

Sí. Anteriormente, solo podía usar certificados raíz autofirmados. Todavía puede cargar 20 certificados raíz.

¿Puedo usar certificados de Azure Key Vault?

No.

¿Qué herramientas puedo usar para crear certificados?

Puede usar su solución de infraestructura de clave pública (PKI) de empresa (la PKI interna), Azure PowerShell, MakeCert y OpenSSL.

¿Hay instrucciones para los parámetros y la configuración de certificados?

Para información sobre los formatos de archivo .cer y .pfx, consulte:

Para obtener el formato de archivo .pem, consulte:

Conexiones de punto a sitio con autenticación RADIUS

¿Se admite la autenticación RADIUS en todas las SKU de Azure VPN Gateway?

La autenticación RADIUS es compatible con todas las SKU excepto la SKU básica.

Si usa SKU heredadas, la autenticación RADIUS se admite en SKU de los niveles Estándar y Alto rendimiento.

¿Es compatible la autenticación RADIUS con el modelo de implementación clásica?

No.

¿Cuál es el período de tiempo de espera para las solicitudes RADIUS enviadas al servidor RADIUS?

Las solicitudes RADIUS están configuradas para expirar al cabo de 30 segundos. Actualmente no se admiten los valores de tiempo de espera definidos por el usuario.

¿Se admiten servidores RADIUS de terceros?

Sí.

¿Cuáles son los requisitos de conectividad para garantizar que la puerta de enlace de Azure pueda comunicarse con un servidor RADIUS local?

Se necesita una conexión VPN de sitio a sitio en el sitio local, con las rutas apropiadas configuradas.

¿Puede enrutarse el tráfico a un servidor RADIUS local (desde la instancia de VPN Gateway) a través de una conexión ExpressRoute?

No. Solo puede enrutarse a través de una conexión de sitio a sitio.

¿Ha cambiado el número de conexiones SSTP admitidas con autenticación RADIUS? ¿Cuál es el número máximo de conexiones SSTP e IKEv2 admitidas?

El número máximo de conexiones SSTP admitidas en una puerta de enlace con autenticación RADIUS no ha cambiado. Sigue siendo 128 para SSTP, pero depende de la SKU de puerta de enlace para IKEv2. Para más información sobre el número de conexiones admitidas, consulte Acerca de las SKU de puerta de enlace.

¿Cuál es la diferencia entre la autenticación de certificado a través de un servidor RADIUS y la autenticación de certificado nativa de Azure mediante la carga de un certificado de confianza?

En la autenticación de certificado RADIUS, la solicitud de autenticación se reenvía a un servidor RADIUS que realiza la validación del certificado. Esta opción es útil si desea integrarla con una infraestructura de autenticación de certificados a través de RADIUS de la que ya disponga.

Cuando se utiliza Azure para la autenticación de certificado, la instancia de VPN Gateway realiza la validación del certificado. Debe cargar la clave pública del certificado en la puerta de enlace. También puede especificar una lista de certificados revocados que no tendrán permiso para conectarse.

¿Admite la autenticación RADIUS la integración del servidor de directivas de red para la autenticación multifactor?

Si la autenticación multifactor está basada en texto (por ejemplo, SMS o código de verificación de aplicaciones móviles) y requiere que el usuario escriba un código o texto en la interfaz de usuario del cliente VPN, la autenticación no se realizará correctamente y no será un escenario compatible. Consulte Integración de la autenticación RADIUS de Azure VPN Gateway con el servidor NPS para la autenticación multifactor.

¿La autenticación RADIUS funciona con IKEv2 y VPN SSTP?

Sí, la autenticación RADIUS es compatible con IKEv2 y VPN SSTP.

¿La autenticación RADIUS funciona con el cliente de OpenVPN?

La autenticación RADIUS no es compatible con el protocolo OpenVPN.

Conexiones de red virtual a red virtual y de varios sitios

La información de red virtual a red virtual de esta sección se aplica a las conexiones de VPN Gateway. Para más información sobre el emparejamiento de redes virtuales, consulte Emparejamiento de redes virtuales.

¿Cobra Azure por el tráfico entre redes virtuales?

El tráfico entre redes virtuales dentro de la misma región es gratuito en ambas direcciones cuando se usa una conexión de puerta de enlace de VPN. El tráfico de salida de red virtual a red virtual entre regiones se cobra según las tarifas de transferencia de datos de salida entre redes virtuales en función de las regiones de origen. Para más información, consulte Precios de Azure VPN Gateway. Si conecta las redes virtuales mediante el emparejamiento de VNET en lugar de una puerta de enlace de red virtual, consulte Precios de Azure Virtual Network.

¿Viaja el tráfico entre dos redes virtuales a través de Internet?

No. Viaja por la red troncal de Microsoft Azure, no por Internet.

¿Puedo establecer una conexión de red virtual a red virtual entre inquilinos de Microsoft Entra?

Sí. Sí, las conexiones de red virtual a red virtual que usan instancias de VPN Gateway funcionan entre los inquilinos de Microsoft Entra.

¿Es seguro el tráfico entre dos redes virtuales?

El cifrado con IPsec e IKE ayuda a proteger el tráfico de red virtual a red virtual.

¿Necesito un dispositivo VPN para conectar redes virtuales?

No. La conexión simultánea de varias redes virtuales de Azure no requiere dispositivos VPN, a menos que sea necesaria la conectividad entre locales.

¿Deben estar mis redes virtuales en la misma región?

No. Las redes virtuales pueden estar en la misma región de Azure o en regiones distintas (ubicaciones).

Si las redes virtuales no están en la misma suscripción, ¿las suscripciones tienen que estar asociadas con el mismo inquilino de Microsoft Entra?

No.

¿Puedo usar una conexión entre redes virtuales para conectar redes virtuales en instancias independientes de Azure?

No. La conexión entre redes virtuales permite conectar redes virtuales dentro de la misma instancia de Azure. Por ejemplo, no puede crear una conexión entre instancias de Azure del gobierno estadounidense, chino o alemán con una instancia global de Azure. Considere la posibilidad de usar una conexión VPN de sitio a sitio en estos casos.

¿Puedo usar las conexiones entre dos redes virtuales con conexiones multisitio?

Sí. La conectividad de red virtual se puede usar de forma simultánea con VPN de varios sitios.

¿A cuántos sitios locales y redes virtuales se puede conectar una red virtual?

Consulte la tabla Requisitos de la puerta de enlace.

¿Puedo usar la conexión entre dos redes virtuales para conectar máquinas virtuales o servicios en la nube fuera de una red virtual?

No. VNet a VNet admite la conexión de redes virtuales. No admite la conexión de máquinas virtuales ni servicios en la nube que no estén en una red virtual.

¿Abarca redes virtuales un servicio en la nube o un punto de conexión de equilibrio de carga?

No. Un servicio en la nube o un punto de conexión de equilibrio de carga no puede abarcar varias redes virtuales, aunque estas estén conectadas entre sí.

¿Puedo usar un tipo de VPN basado en directivas para las conexiones entre dos redes virtuales o multisitio?

No. Las conexiones entre dos redes virtuales y multisitio requieren instancias de VPN Gateway con tipos de VPN basados en rutas (lo que antes se conocía como enrutamiento dinámico).

¿Puedo conectar una red virtual con un tipo de VPN basado en rutas a otra red virtual con un tipo de VPN basado en directivas?

No. Ambas redes virtuales deben usar VPN basadas en rutas (lo que antes se conocía como enrutamiento dinámico).

¿Comparten ancho de banda los túneles de VPN?

Sí. Todos los túneles VPN de la red virtual comparten el ancho de banda disponible en la instancia de VPN Gateway y el mismo contrato de nivel de servicio de tiempo de actividad de VPN Gateway en Azure.

¿Se admiten túneles redundantes?

Los túneles redundantes entre dos redes virtuales se admiten cuando la puerta de enlace de una red virtual está configurada como activa-activa.

¿Puedo tener espacios de direcciones superpuestos para configuraciones de red virtual a red virtual?

No. No puede tener intervalos de direcciones de IP superpuestos.

¿Puede haber espacios de direcciones superpuestos entre las redes virtuales conectadas y los sitios locales?

No. No puede tener intervalos de direcciones de IP superpuestos.

¿Cómo habilito el enrutamiento entre mi conexión VPN de sitio a sitio y ExpressRoute?

Si quiere habilitar el enrutamiento entre la rama conectada a ExpressRoute y la rama conectada a una conexión VPN de sitio a sitio, debe configurar Azure Route Server.

¿Puedo usar una instancia de VPN Gateway para el tráfico en tránsito entre mis sitios locales o a otra red virtual?

  • Modelo de implementación del Administrador de recursos

    Sí. Consulte la sección BGP y enrutamiento para más información.

  • Modelo de implementación clásica

    El tráfico en tránsito a través de una instancia de VPN Gateway es posible cuando se usa el modelo de implementación clásica, pero se basa en espacios de direcciones definidos estáticamente en el archivo de configuración de red. El Protocolo de puerta de enlace de borde (BGP) no se admite actualmente con redes virtuales de Azure e instancias de VPN Gateway a través del modelo de implementación clásica. Sin BGP, definir manualmente los espacios de direcciones de tránsito es difícil de hacer sin errores y no se recomienda.

¿Azure genera la misma clave precompartida de IPsec/IKE para todas mis conexiones VPN para la misma red virtual?

No. De forma predeterminada, Azure genera diferentes claves precompartidas para diferentes conexiones VPN. Sin embargo, puede utilizar la API de REST o el cmdlet de PowerShell Set VPN Gateway para establecer el valor de clave que prefiera. La clave debe contener únicamente caracteres ASCII imprimibles, a excepción del espacio, el guion (-) o la tilde (~).

¿Tengo más ancho de banda con más VPN de sitio a sitio que si tengo una única red virtual?

No. Todos los túneles VPN, incluidas las VPN de punto a sitio, comparten la misma instancia de VPN Gateway y el ancho de banda disponible.

¿Puedo configurar varios túneles entre mi red virtual y mi sitio local utilizando una VPN multisitio?

Sí, pero debe configurar BGP en ambos túneles de la misma ubicación.

¿Respeta Azure VPN Gateway la anteposición de la ruta de acceso de AS para influir en las decisiones de enrutamiento entre varias conexiones a mis sitios locales?

Sí, Azure VPN Gateway respeta la anteposición de la ruta de acceso del sistema autónomo (AS) para ayudar a tomar decisiones de enrutamiento cuando BGP esté habilitado. Se preferirá una ruta de acceso de AS más corta en la selección de la ruta de acceso de BGP.

¿Puedo usar la propiedad RoutingWeight al crear una conexión VPN VirtualNetworkGateway?

No. Esta configuración está reservada para las conexiones de puerta de enlace de ExpressRoute. Si quiere influir en las decisiones de enrutamiento entre varias conexiones, debe usar la anteposición de la ruta de acceso AS.

¿Puedo usar VPN de punto a sitio con mi red virtual con varios túneles VPN?

Sí. Puede usar las VPN de punto a sitio con las instancias de VPN Gateway para conectarse a varios sitios locales y a otras redes virtuales.

¿Puedo conectar una red virtual con VPN sobre IPsec a mi circuito de ExpressRoute?

Sí, se admite, Para más información, consulte Configuración de conexiones ExpressRoute y de sitio a sitio coexistentes.

Directiva de IPsec o IKE

¿Se admite la directiva IPsec o IKE personalizada en todas las SKU de Azure VPN Gateway?

La directiva IPsec o IKE personalizada se admite en todas las SKU de Azure VPN Gateway, excepto la SKU básica.

¿Cuántas directivas puedo especificar en una conexión?

Solo puede especificar una combinación de directivas para una conexión.

¿Puedo especificar una directiva parcial en una conexión (por ejemplo, solo algoritmos IKE, pero no IPsec)?

No, es preciso especificar todos los algoritmos y parámetros de IKE (modo principal) e IPsec (modo rápido). No se permite la especificación de una directiva parcial.

¿Qué algoritmos y niveles de clave admite la directiva personalizada?

En la tabla siguiente se enumeran los algoritmos criptográficos y los valores de clave admitidos que puede configurar. Es preciso seleccionar una opción en cada campo.

IPsec o IKEv2 Opciones
Cifrado IKEv2 GCMAES256, GCMAES128, AES256, AES192, AES128
Integridad de IKEv2 SHA384, SHA256, SHA1, MD5
DH Group (Grupo DH) DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, No
Cifrado IPsec GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, No
Integridad de IPsec GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Grupo PFS PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, No
Duración de SA del modo rápido (Opcional; valores predeterminados si no se especifican)
Segundos (entero; mínimo 300, valor predeterminado 27 000)
Kilobytes (entero; mínimo 1024, valor predeterminado 10 2400 000)
Selector de tráfico UsePolicyBasedTrafficSelectors ($True o $False, pero opcional; valor predeterminado $False si no se especifica)
Tiempo de expiración de DPD Segundos (entero; mínimo 9, máximo 3600, valor predeterminado 45)

  • La configuración de su dispositivo VPN local debe coincidir o contener los siguientes algoritmos y parámetros que se especifican en la directiva IPsec o IKE de Azure:

    • Algoritmo de cifrado de IKE (modo principal, fase 1)
    • Algoritmo de integridad de IKE (modo principal, fase 1)
    • Grupo DH (modo principal, fase 1)
    • Algoritmo de cifrado de IPsec (modo rápido, fase 2)
    • Algoritmo de integridad de IPsec (modo rápido, fase 2)
    • Grupo PFS (modo rápido, fase 2)
    • Selector de tráfico (si usa UsePolicyBasedTrafficSelectors)
    • Vigencias de SA (especificaciones locales que no necesitan coincidir)

  • Si se usa GCMAES para el algoritmo de cifrado IPsec, se debe seleccionar el mismo algoritmo GCMAES y longitud de clave para la integridad de IPsec. por ejemplo, use GCMAES128 para ambos.

  • En la tabla de algoritmos y claves:

    • IKE corresponde al modo principal o fase 1.
    • IPsec corresponde al modo rápido o fase 2.
    • El grupo DH especifica el grupo Diffie-Hellman utilizado en el modo principal o fase 1.
    • El grupo PFS especifica el grupo Diffie-Hellman utilizado en el modo rápido o fase 2.

  • La vigencia de SA del modo principal de IKE se fija en 28 800 en las puertas de enlace de VPN de Azure.

  • UsePolicyBasedTrafficSelectors es un parámetro opcional en la conexión. Si establece UsePolicyBasedTrafficSelectors en $True en una conexión, se configura la instancia de VPN Gateway para conectarse a un firewall de VPN basado en directivas locales.

    Si habilita UsePolicyBasedTrafficSelectors, asegúrese de que el dispositivo VPN tenga los selectores de tráfico coincidentes definidos con todas las combinaciones de los prefijos de red local (puerta de enlace de red local) hacia o desde los prefijos de red virtual de Azure, en lugar de una configuración de cualquiera a cualquiera. La instancia de VPN Gateway acepta el selector de tráfico que propone la instancia de VPN Gateway remota, independientemente de lo configurado en la instancia de VPN Gateway.

    Por ejemplo, si sus prefijos de red local son 10.1.0.0/16 y 10.2.0.0/16, y sus prefijos de red virtual son 192.168.0.0/16 y 172.16.0.0/16, debe especificar los siguientes selectores de tráfico:

    • 10.1.0.0/16 <====> 192.168.0.0/16
    • 10.1.0.0/16 <====> 172.16.0.0/16
    • 10.2.0.0/16 <====> 192.168.0.0/16
    • 10.2.0.0/16 <====> 172.16.0.0/16

    Parar más información sobre los selectores de tráfico basados en directivas, consulte Conexión de una instancia de VPN Gateway a varios dispositivos VPN locales basados en directivas.

  • Si se establece el tiempo de espera en períodos más cortos, IKE volver a especificar la clave de forma más agresiva. Después, la conexión puede parecer desconectada en algunos casos. Es posible que esta situación no sea deseable si las ubicaciones locales están lejos de la región de Azure en la que reside la instancia de VPN Gateway o si el estado del vínculo físico puede llegar a provocar la pérdida de paquetes. Por lo general, se recomienda establecer el tiempo de espera en entre 30 y 45 segundos.

Para información, consulte Conexión de una instancia de VPN Gateway a varios dispositivos VPN basados en directivas locales.

¿Qué grupos Diffie-Hellman admite la directiva personalizada?

En la tabla siguiente se muestran los grupos Diffie-Hellman admitidos en la directiva personalizada:

Grupo Diffie-Hellman Grupo DH Grupo PFS Longitud de clave
1 DHGroup1 PFS1 MODP de 768 bits
2 DHGroup2 PFS2 MODP de 1024 bits
14 DHGroup14
DHGroup2048		 PFS2048 MODP de 2048 bits
19 ECP256 ECP256 ECP de 256 bits
20 ECP384 ECP384 ECP de 384 bits
24 DHGroup24 PFS24 MODP de 2048 bits

Para más información, consulte RFC3526 y RFC5114.

¿Reemplaza la directiva personalizada los conjuntos de directivas IPsec o IKE predeterminadas en las instancias de VPN Gateway?

Sí. Después de especificar una directiva personalizada en una conexión, Azure VPN Gateway solo usa esa directiva en la conexión, como iniciador de IKE y como respondedor de IKE.

Si quito una directiva de IPsec o IKE personalizada, ¿se que la conexión desprotegida?

No, IPsec o IKE sigue ayudando a proteger la conexión. Una vez que se quita la directiva personalizada de una conexión, VPN Gateway vuelve a la lista predeterminada de las propuestas de IPsec o IKE, y vuelve a iniciar el protocolo de enlace de IKE con un dispositivo VPN local.

¿Afectarían a mi conexión VPN la incorporación o actualización de una directiva de IPsec o IKE?

Sí. Podría producirse una pequeña interrupción (unos segundos), ya que VPN Gateway anula la conexión existente y vuelve a iniciar el protocolo de enlace de IKE para restablecer el túnel IPsec con los nuevos parámetros y algoritmos criptográficos. Asegúrese de que el dispositivo VPN local también esté configurado con los algoritmos y niveles de clave coincidentes para minimizar dicha interrupción.

¿Se pueden usar distintas directivas en conexiones diferentes?

Sí. La directiva personalizada se aplica en función de la conexión. Puede crear y aplicar distintas directivas de IPsec o IKE en conexiones diferentes.

También puede elegir aplicar directivas personalizadas a un subconjunto de las conexiones. Las restantes usan los conjuntos de directivas de IPsec o IKE predeterminados de Azure.

¿Puedo usar una directiva personalizada en conexiones de red virtual a red virtual?

Sí. Puede aplicar directivas personalizadas tanto en conexiones entre entornos de IPsec como conexiones de red virtual a red virtual.

¿Es preciso especificar la misma directiva en los dos recursos de la conexión entre redes virtuales?

Sí. Un túnel entre redes virtuales consta de dos recursos de conexión en Azure, una para cada dirección. Asegúrese de que ambos recursos de conexión tengan la misma directiva. De lo contrario, no se establecerá la conexión de red virtual a red virtual.

¿Cuál es el valor predeterminado del tiempo de espera de DPD? ¿Se puede especificar otro tiempo de espera de DPD?

El tiempo de espera predeterminado de DPD es de 45 segundos en las instancias de VPN Gateway. Se puede especificar otro valor del tiempo de espera de DPD en cada conexión IPsec o de red virtual a red virtual. Dicho valor debe oscilar entre 9 y 3600 segundos.

Nota:

Si se establece el tiempo de espera en períodos más cortos, IKE volver a especificar la clave de forma más agresiva. Después, la conexión puede parecer desconectada en algunos casos. Es posible que esta situación no sea deseable si las ubicaciones locales están lejos de la región de Azure en la que reside la instancia de VPN Gateway o si el estado del vínculo físico puede llegar a provocar la pérdida de paquetes. Por lo general, se recomienda establecer el tiempo de espera en entre 30 y 45 segundos.

¿Funciona una directiva IPsec o IKE personalizada en conexiones ExpressRoute?

No. La directiva IPsec o IKE solo funciona en conexiones entre redes virtuales y VPN S2S a través de las instancias de VPN Gateway.

¿Cómo se crean conexiones con el tipo de protocolo IKEv1 o IKEv2?

Puede crear conexiones IKEv1 en todas las SKU de tipo VPN basadas en rutas, excepto la SKU básica, la SKU estándar y otras SKU anteriores.

Puede especificar un tipo de protocolo de conexión IKEv1 o IKEv2 al crear conexiones. Si no especifica un tipo de protocolo de conexión, se utiliza IKEv2 como opción predeterminada cuando proceda. Para más información, consulte la documentación del cmdlet de Azure PowerShell.

Para información sobre los tipos de SKU y la compatibilidad con IKEv1 y IKEv2, consulte Conexión de una puerta de enlace de VPN a varios dispositivos VPN locales basados en directivas.

¿Se permite el tránsito entre las conexiones IKEv1 y IKEv2?

Sí.

¿Puedo tener conexiones de sitio a sitio IKEv1 en la SKU básica para el tipo de VPN basado en rutas?

No. La SKU básica no admite esta configuración.

¿Puedo cambiar el tipo de protocolo de conexión después de crear la conexión (IKEv1 a IKEv2 y viceversa)?

No. Después de crear la conexión, no puede cambiar los protocolos IKEv1 e IKEv2. Debe eliminar y volver a crear una nueva conexión con el tipo de protocolo deseado.

¿Por qué se reconecta mi conexión IKEv1 con frecuencia?

Si el enrutamiento estático o la conexión IKEv1 basada en rutas se desconecta a intervalos rutinarios, es probable que se deba a que las instancias de VPN Gateway no admiten volver a especificar las claves in situ. Cuando se vuelve a especificar la clave del modo principal, los túneles IKEv1 se desconectan y tardan hasta 5 segundos en volver a conectarse. El tiempo de espera de negociación del modo principal determina la frecuencia para volver a especificar las claves. Para evitar estas reconexiones, vuelva a usar IKEv2, que admite volver a especificar las claves in situ.

Si la conexión se restablece a intervalos aleatorios, siga nuestra guía de solución de problemas.

¿Dónde puedo encontrar más información y pasos para la configuración?

Vea los artículos siguientes:

BGP y enrutamiento

¿Se admite BGP en todas las SKU de Azure VPN Gateway?

BGP se admite en todas las SKU de Azure VPN Gateway, excepto en la SKU básica.

¿Se puede usar BGP con puertas de enlace de VPN de Azure Policy?

No, BGP solo es compatible con puertas de enlace de VPN basadas en rutas.

¿Qué ASN puedo usar?

Puede usar sus propios números públicos del sistema autónomo (AS) o números ASN privados tanto para las redes locales como para las redes virtuales de Azure.

No puede usar los siguientes números ASN reservados:

  • Reservados por Azure:

    • ASN públicos: 8074, 8075, 12076
    • ASN privados: 65515, 65517, 65518, 65519, 65520

  • Reservados por IANA:

    • 23456, 64496-64511, 65535-65551, 429496729

Al conectarse a instancias de VPN Gateway, no puede especificar estos ASN para los dispositivos VPN locales.

¿Se pueden usar ASN de 32 bits (4 bytes)?

Sí, Azure VPN Gateway ahora admite ASN de 32 bits (4 bytes). Para usar ASN en formato decimal en la configuración, use Azure PowerShell, la CLI de Azure o el SDK de Azure.

¿Qué ASN privados se pueden usar?

Estos son los rangos de ASN privados que se pueden usar:

  • 64512-65514 y 65521-65534

Ni IANA ni Azure reservan estos ASN, por lo que puede asignarlos a su instancia de VPN Gateway.

¿Qué dirección utiliza Azure VPN Gateway para la dirección IP del par BGP?

De manera predeterminada, Azure VPN Gateway asigna una única dirección IP del intervalo GatewaySubnet para las instancias de VPN Gateway en modo activo/en espera, o bien dos direcciones IP para instancias de VPN Gateway en modo activo/activo. Estas direcciones se asignan automáticamente al crear la puerta de enlace de VPN.

Puede encontrar la dirección IP de BGP asignada mediante Azure PowerShell o Azure Portal. En PowerShell, use Get-AzVirtualNetworkGateway y busque la propiedad bgpPeeringAddress. En Azure Portal, en la página Configuración de puerta de enlace, fíjese en la propiedad Configurar ASN BGP.

Si los enrutadores locales de VPN utilizan direcciones IP (169.254.x.x) de la dirección IP privada automática (APIPA) como direcciones IP de BGP, es preciso especificar una o más direcciones IP de BGP de APIPA de Azure en su instancia de VPN Gateway. Azure VPN Gateway selecciona las direcciones de APIPA que se van a usar con el par BGP de APIPA especificado de la puerta de enlace de red local, o bien una dirección IP privada, en el caso del par BGP local que no sea APIPA. Para más información, consulte Configuración de BGP para Azure VPN Gateway.

¿Cuáles son los requisitos de las direcciones IP del par BGP en mi dispositivo VPN?

La dirección del par BGP local no debe coincidir con la dirección IP pública del dispositivo VPN ni con el espacio de direcciones de red virtual de VPN Gateway. Use otra dirección IP en el dispositivo VPN para la dirección IP del par BGP. Puede ser una dirección asignada a la interfaz de bucle invertido del dispositivo (puede ser una dirección IP normal o una dirección de APIPA).

Si el dispositivo usa una dirección de APIPA para BGP, es preciso especificar una o más direcciones IP de BGP de APIPA en la instancia de VPN Gateway, como se describe en Configuración de BGP para Azure VPN Gateway. Especifique estas direcciones en la puerta de enlace de red local correspondiente que representa la ubicación.

¿Qué debo especificar como mis prefijos de dirección para la puerta de enlace de red local al utilizar BGP?

Importante

Aquí se ha producido un cambio, con respecto al requisito que estaba documentado.

Azure VPN Gateway agrega internamente una ruta de host a la IP del par BGP local a través del túnel IPsec. No agregue la ruta /32 en el campo Espacio de direcciones, ya que es redundante. Si usa una dirección APIPA como dirección IP de BGP del dispositivo VPN local, no puede agregarla a este campo.

Si agrega otros prefijos en el campo Espacio de direcciones, se agregan como rutas estáticas en Azure VPN Gateway, además de las rutas aprendidas a través del protocolo BGP.

¿Se puede usar el mismo ASN para redes VPN locales y redes virtuales de Azure?

No. Si va a conectar redes locales y redes virtuales de Azure con el protocolo BGP, debe asignar diferentes ASN a cada una de ellas.

Las puertas de enlace de VPN de Azure tienen un ASN predeterminado de 65515 asignado, independientemente de que BGP esté habilitado, o no, para la conectividad entre locales. Para invalidar este valor predeterminado, asigne otro ASN al crear la puerta de enlace de VPN o cambie el ASN después de crearla. Tiene que asignar los ASN locales a las puertas de enlace de red local de Azure correspondientes.

¿Qué prefijos de dirección de instancias de Azure VPN Gateway se me anunciarán?

Las puertas de enlace anuncian las siguientes rutas a los dispositivos BGP locales:

  • Sus prefijos de dirección de red virtual
  • Los prefijos de dirección de cada puerta de enlace de red local conectada a la instancia de VPN Gateway.
  • Las rutas aprendidas de otras sesiones de emparejamiento BGP conectadas a la instancia de VPN Gateway, excepto la ruta o rutas predeterminadas que se superpongan con cualquier prefijo de red virtual.

¿Cuántos prefijos se pueden anunciar en Azure VPN Gateway?

Azure VPN Gateway admite hasta 4000 prefijos. Si el número de prefijos supera el límite, se elimina la sesión BGP.

¿Puedo anunciar la ruta predeterminada (0.0.0.0/0) a las instancias de VPN Gateway?

Sí. Tenga en cuenta que el anuncio de la ruta obliga a que todo el tráfico de salida de la red virtual vaya al sitio local. También impide que las máquinas virtuales de la red virtual acepten directamente la comunicación pública desde Internet, como Protocolo de escritorio remoto (RDP) o Secure Shell (SSH) desde Internet hasta las máquinas virtuales.

¿Puedo anunciar los mismos prefijos que mis prefijos de red virtual?

No. Azure bloquea o filtra el anuncio de los mismos prefijos que cualquiera de los prefijos de dirección de red virtual. Sin embargo, se puede anunciar un prefijo que sea un superconjunto de lo que contenga su red virtual.

Por ejemplo, si una red virtual usa el espacio de direcciones 10.0.0.0/16, se puede anunciar 10.0.0.0/8. Sin embargo, no se pueden anunciar el 10.0.0.0/16 ni el 10.0.0.0/24.

¿Se puede usar el protocolo de puerta de enlace de borde con las conexiones entre redes virtuales?

Sí. Puede usar BGP tanto para conexiones entre locales como para conexiones entre redes virtuales.

¿Puedo combinar BGP con conexiones no de BGP para mi puertas de enlace de VPN de Azure?

Sí, puede mezclar conexiones de BGP y no de BGP para la misma puerta de enlace de VPN de Azure.

¿Admite Azure VPN Gateway el enrutamiento del tránsito de BGP?

Sí. Se admite el enrutamiento del tránsito de BGP, pero las instancias de VPN Gateway no anuncian rutas predeterminadas a otros pares BGP. Para permitir el enrutamiento del tránsito entre varias instancias de VPN Gateway, es preciso habilitar BGP en todas las conexiones intermedias entre redes virtuales. Para más información, consulte Acerca de BGP y VPN Gateway.

¿Puedo tener más de un túnel entre mi red local y VPN Gateway?

Sí, puede establecer varios túneles VPN de sitio a sitio entre una instancia de VPN Gateway y la red local. Todos estos túneles se incluyen en el recuento total de túneles de las instancias de Azure VPN Gateway, y debe habilitar BGP en ambos túneles.

Por ejemplo, si tiene dos túneles redundantes entre su instancia de VPN Gateway y una de las redes locales, estos consumen dos de los túneles de la cuota total asignada a la instancia de VPN Gateway.

¿Puedo tener varios túneles entre dos redes virtuales de Azure con BGP?

Sí, pero al menos una de las puertas de enlace de la red virtual debe estar en una configuración activo/activo.

¿Se puede usar BGP para una VPN S2S en una configuración en que coexisten una VPN S2S y ExpressRoute?

Sí.

¿Qué debo agregar a mi dispositivo VPN local para la sesión de emparejamiento BGP?

Agregue una ruta de host de la dirección IP del par BGP de Azure al dispositivo VPN. Esta ruta apunta al túnel VPN de sitio a sitio de IPsec.

Por ejemplo, si la dirección IP del par VPN de Azure es 10.12.255.30, debe agregar una ruta de host para 10.12.255.30 con una interfaz de próximo salto de la interfaz de túnel IPsec coincidente en el dispositivo VPN.

¿Admite la puerta de enlace de red virtual BFD para las conexiones S2S con BGP?

No. BFD (Detección de reenvío bidireccional) es un protocolo que se puede usar con BGP para detectar el tiempo de inactividad del vecino más rápidamente que si se usan intervalos persistentes BGP estándar. BFD usa temporizadores de subsegundo diseñados para funcionar en entornos de LAN, pero no en las conexiones WAN o de la red pública de Internet.

En el caso de las conexiones a través de la red pública de Internet, no es inusual que algunos paquetes se retrasen, o incluso se eliminen, por lo que la introducción de estos agresivos temporizadores puede agregar inestabilidad, Esta inestabilidad podría provocar que BGP amortiguase las rutas.

Como alternativa, puede configurar su dispositivo local con temporizadores inferiores al intervalo de conexión persistente predeterminado de 60 segundos o al temporizador de retención de 180 segundos. Esta configuración da como resultado un tiempo de convergencia más rápido. Sin embargo, los temporizadores por debajo del intervalo persistente predeterminado de 60 segundos o del temporizador de retención predeterminado de 180 segundos no son confiables. Se recomienda mantener los temporizadores en los valores predeterminados o por encima de estos.

¿Las instancias de VPN Gateway inician conexiones o sesiones de emparejamiento BGP?

Las instancias de VPN Gateway inician sesiones de emparejamiento BGP con las direcciones IP del par BGP local especificadas en los recursos de puerta de enlace de red local mediante las direcciones IP privadas de las instancias de VPN Gateway. Este escenario se da con independencia de si las direcciones IP de BGP locales están en el intervalo APIPA o son direcciones IP privadas normales. Si los dispositivos VPN locales usan direcciones APIPA como IP de BGP, debe configurar el altavoz BGP para iniciar las conexiones.

¿Puedo configurar una tunelización forzada?

Sí. Consulte Configurar una tunelización forzada.

NAT

¿Se admite NAT en todas las SKU de Azure VPN Gateway?

NAT se admite en VpnGw2 hasta VpnGw25 y en VpnGw2AZ hasta VpnGw5AZ.

¿Puedo usar NAT en conexiones de red virtual a red virtual o P2S?

No.

¿Cuántas reglas NAT puedo usar en una puerta de enlace de VPN?

Puede crear hasta 100 reglas NAT (combinación de reglas de entrada y de salida) en una instancia de VPN Gateway.

¿Puedo usar una barra diagonal (/) en el nombre de una regla NAT?

No. Recibirá un error.

¿Se aplica NAT a todas las conexiones en una puerta de enlace de VPN?

NAT se aplica a las conexiones que tienen reglas NAT. Si alguna conexión no tiene ninguna regla NAT, no se le aplicará NAT. En la misma instancia de VPN Gateway, puede tener algunas conexiones con NAT y otras sin NAT que funcionen conjuntamente.

¿Qué tipos de NAT admiten las instancias de VPN Gateway?

Las instancias de VPN Gateway solo admiten NAT estática 1:1 y NAT dinámica. No admiten NAT64.

¿Funciona NAT en puertas de enlace VPN activo-activo?

Sí. NAT funciona en puertas de enlace VPN activo-activo y en espera activo. Cada regla NAT se aplica a una sola instancia de VPN Gateway. En puertas de enlace activa/activa, cree una regla NAT independiente para cada instancia de puerta de enlace mediante el campo Id. de configuración de IP.

¿Funciona NAT con las conexiones BGP?

Sí, se puede usar BGP con NAT. A continuación se indican algunas consideraciones importantes:

  • Para asegurarse de que las rutas aprendidas y las rutas anunciadas se traducen a prefijos de dirección posteriores a NAT (asignaciones externas) en función de las reglas NAT asociadas a las conexiones, seleccione Habilitación de la traducción de rutas BGP en la página de configuración de reglas NAT. Los enrutadores BGP locales deben anunciar los prefijos exactos definidos en las reglas IngressSNAT.

  • Si el enrutador VPN local usa una dirección normal que no es de APIPA y se intercala con el espacio de direcciones de la red virtual o con otros espacios de red locales, asegúrese de que la regla IngressSNAT traduzca la dirección IP del par BGP a una dirección única no superpuesta. Coloque la dirección post-NAT en el campo Dirección IP del par BGP de la puerta de enlace de red local.

  • NAT no es compatible con las direcciones BGP APIPA.

¿Debo crear las reglas DNAT correspondientes para la regla SNAT?

No. Una única regla de traducción de direcciones de red de origen (SNAT) define la traducción para ambas direcciones de una red determinada:

  • Una regla IngressSNAT define la traducción de las direcciones IP de origen que llegan a la instancia de VPN Gateway desde la red local. También controla la traducción de las direcciones IP de destino que salen de la red virtual hacia la misma red local.

  • Una regla EgressSNAT define la traducción de las direcciones IP de origen de la red virtual que salen de la instancia de VPN Gateway a redes locales. También controla la traducción de las direcciones IP de destino para los paquetes que llegan a la red virtual por medio de esas conexiones con la regla EgressSNAT.

En cualquier caso, no necesita reglas de traducción de direcciones de red de destino (DNAT).

¿Qué debo hacer si el espacio de direcciones de la puerta de enlace de red local o de red virtual tiene dos o más prefijos? ¿Puedo aplicar NAT a todos ellos o solo a un subconjunto?

Debe crear una regla NAT para cada prefijo, ya que cada regla NAT solo puede incluir un prefijo de dirección para NAT. Por ejemplo, si el espacio de direcciones de la puerta de enlace de red local se compone de 10.0.1.0/24 y 10.0.2.0/25, puede crear dos reglas:

  • IngressSNAT regla 1: Mapa 10.0.1.0/24 a 192.168.1.0/24.
  • IngressSNAT regla 2: Mapa 10.0.2.0/25 a 192.168.2.0/25.

Las dos reglas deben hacer coincidir las longitudes de los prefijos de dirección correspondientes. La misma guía se aplica a las reglas EgressSNAT para el espacio de direcciones de la red virtual.

Importante

Si vincula solo una regla a la conexión anterior, el otro espacio de direcciones no se traducirá.

¿Qué intervalos IP pueden usarse para la asignación externa?

La asignación externa admite cualquier intervalo IP adecuado que desee usar. Esto incluye las direcciones IP públicas y privadas.

¿Puedo usar reglas EgressSNAT distintas para traducir el espacio de direcciones de red virtual a distintos prefijos para redes locales?

Sí. Sí, puede crear varias reglas EgressSNAT para el mismo espacio de direcciones de red virtual y aplicar dichas reglas EgressSNAT a distintas conexiones.

¿Puedo usar la misma regla IngressSNAT en conexiones distintas?

Sí. Normalmente, se usa la misma regla IngressSNAT cuando las conexiones son para la misma red local, para proporcionar redundancia. Si las conexiones son para redes locales distintas, no se puede usar la misma regla de entrada.

¿Necesito tanto reglas de entrada como de salida en una conexión NAT?

Necesita tanto reglas de entrada como de salida en la misma conexión cuando el espacio de direcciones de red local se superpone con el espacio de direcciones de la red virtual. Si el espacio de direcciones de la red virtual es único entre todas las redes conectadas, no se necesitará la regla EgressSNAT en esas conexiones. Puede usar las reglas de entrada para evitar la superposición de direcciones entre las redes locales.

¿Qué puedo elegir como identificador de configuración de IP?

El Id. de configuración de IP es simplemente el nombre del objeto de configuración de IP que quiere que use la regla NAT. Con esta configuración, simplemente elija qué dirección IP pública de puerta de enlace se aplica a la regla NAT. Si no ha especificado ningún nombre personalizado al momento de la creación de la puerta de enlace, la dirección IP principal de la puerta de enlace se asigna a la configuración de IP predeterminada y la dirección IP secundaria se asigna a la configuración de IP activeActive.

Conectividad entre locales y máquinas virtuales

Si mi máquina virtual está en una red virtual y tengo una conexión entre locales, ¿cómo debo conectar a la máquina virtual?

Si tiene el RDP habilitado en la máquina virtual, puede conectarse a ella mediante la dirección IP privada. En ese caso, debe especificar la dirección IP privada y el puerto al que desea conectarse (normalmente el 3389). Tendrá que configurar el puerto del tráfico en la máquina virtual.

También puede conectarse a la máquina virtual mediante la dirección IP privada desde otra máquina virtual que se encuentre en la misma red virtual. Si se conecta desde una ubicación que esté fuera de la red virtual, no podrá usar RDP en la máquina virtual mediante la dirección IP privada. Por ejemplo, si tiene configurada una red virtual de punto a sitio y no establece una conexión desde su equipo, no podrá conectarse a la máquina virtual mediante la dirección IP privada.

¿Si mi máquina virtual está en una red virtual con conectividad entre locales, todo el tráfico de mi máquina virtual pasa a través de esa conexión?

No. Solo el tráfico que tiene una dirección IP de destino contenida en los intervalos de direcciones IP de red local de la red virtual que haya especificado pasa por la puerta de enlace de red virtual.

El tráfico que tenga una IP de destino ubicada dentro de la red virtual permanece en la red virtual. El tráfico restante se envía a las redes públicas a través del equilibrador de carga. O bien, si usa la tunelización forzada, el tráfico se envía a través de VPN Gateway.

Cómo se solucionan los problemas de una conexión RDP a una máquina virtual

Si tiene problemas para conectarse a una máquina virtual a través de su conexión VPN, compruebe lo siguiente:

  • Compruebe que la conexión VPN se ha establecido correctamente.
  • Compruebe que se conecta a la dirección IP privada de la máquina virtual.
  • Si puede conectarse a la máquina virtual mediante la dirección IP privada, pero no el nombre del equipo, comprueba que haya configurado el DNS correctamente. Para más información sobre cómo funciona la resolución de nombres para las máquinas virtuales, consulte Resolución de nombres para recursos en redes virtuales de Azure.

Cuando utilice una conexión de punto a sitio, compruebe los siguientes elementos adicionales:

  • Use ipconfig para comprobar la dirección IPv4 asignada al adaptador de Ethernet en el equipo desde el que va a conectarse. Si la dirección IP está dentro del intervalo de direcciones de la red virtual a la que se va a conectar o dentro del intervalo de direcciones de su grupo de direcciones del cliente VPN, se trata de un espacio de direcciones superpuesto. Cuando el espacio de direcciones se superpone de esta manera, el tráfico de red no llega a Azure. Permanece en la red local.
  • Compruebe que el paquete de configuración del cliente VPN se haya generado después de que se especificaran las direcciones IP del servidor DNS para la red virtual. Si actualizó las direcciones IP de servidor DNS, genere un nuevo paquete de configuración de cliente de VPN e instálelo.

Para más información acerca de la solución de problemas de una conexión RDP, consulte Solución de problemas de conexiones del Escritorio remoto a una máquina virtual de Azure.

Mantenimiento de puertas de enlace controladas por el cliente

¿Qué servicios se incluyen en la configuración de mantenimiento para el ámbito de las puertas de enlace de red?

El ámbito de puertas de enlace de red incluye recursos de puerta de enlace en servicios de redes. Hay cuatro tipos de recursos en el ámbito de puertas de enlace de red:

  • Puerta de enlace de red virtual en el servicio ExpressRoute.
  • Puerta de enlace de red virtual en el servicio VPN Gateway.
  • VPN Gateway (sitio a sitio) en el servicio Azure Virtual WAN.
  • Puerta de enlace de ExpressRoute en el servicio Virtual WAN.

¿Qué mantenimiento admite el mantenimiento controlado por el cliente?

Los servicios de Azure pasan por actualizaciones de mantenimiento periódicas para mejorar la funcionalidad, la confiabilidad, el rendimiento y la seguridad. Una vez configurada una ventana de mantenimiento para los recursos, el mantenimiento del sistema operativo invitado y el mantenimiento del servicio se realizan durante esa ventana. El mantenimiento controlado por el cliente no cubre las actualizaciones de host (más allá de las actualizaciones de host para Power, por ejemplo) y las actualizaciones de seguridad críticas.

¿Puedo recibir una notificación avanzada de mantenimiento?

En este momento, no se puede obtener una notificación avanzada para el mantenimiento de los recursos de puerta de enlace de red.

¿Puedo configurar una ventana de mantenimiento inferior a cinco horas?

Actualmente, debe configurar una ventana de cinco horas como mínimo en la zona horaria preferida.

¿Puedo configurar una ventana de mantenimiento distinta de la programación diaria?

En este momento, debe configurar una ventana de mantenimiento diaria.

¿Hay casos en los que no pueda controlar determinadas actualizaciones?

El mantenimiento controlado por el cliente admite actualizaciones del sistema operativo invitado y del servicio. Estas actualizaciones representan la mayoría de los elementos de mantenimiento que preocupan a clientes. Algunos otros tipos de actualizaciones, incluidas las actualizaciones de host, están fuera del ámbito de mantenimiento controlado por el cliente.

Ante un problema de seguridad de gravedad alta que pueda poner en peligro a los clientes, Azure podría tener que invalidar el control del cliente de la ventana de mantenimiento e insertar un cambio. Estos cambios no son frecuentes y solo los usamos en casos extremos.

¿Los recursos de configuración de mantenimiento deben estar en la misma región que el recurso de puerta de enlace?

Sí.

¿Qué SKU de puerta de enlace se pueden configurar para usar el mantenimiento controlado por el cliente?

Todas las SKU de Azure VPN Gateway (excepto la SKU básica) se pueden configurar para usar el mantenimiento controlado por el cliente.

¿Cuánto tiempo tarda la directiva de configuración de mantenimiento en ser efectiva después de asignarla al recurso de puerta de enlace?

Las puertas de enlace de red pueden tardar hasta 24 horas en seguir la programación de mantenimiento después de que la directiva de mantenimiento esté asociada al recurso de puerta de enlace.

¿Existen limitaciones en el uso del mantenimiento controlado por el cliente basado en la dirección IP pública de la SKU básica?

Sí. El mantenimiento controlado por el cliente no funciona con los recursos que usan direcciones IP públicas de SKU básica, excepto en el caso de las actualizaciones del servicio. Para estas puertas de enlace, el mantenimiento del sistema operativo invitado no sigue la programación de mantenimiento controlada por el cliente debido a las limitaciones de infraestructura.

¿Cómo debo planear las ventanas de mantenimiento al usar VPN y ExpressRoute en un escenario de coexistencia?

Al trabajar con VPN y ExpressRoute en un escenario de coexistencia o siempre que tenga recursos que actúen como respaldo, se recomienda configurar ventanas de mantenimiento independientes. Este enfoque garantiza que el mantenimiento no afecte a los recursos de copia de seguridad al mismo tiempo.

He programado una ventana de mantenimiento para uno de mis recursos en una fecha futura. ¿Se pausarán las actividades de mantenimiento en este recurso hasta entonces?

No, las actividades de mantenimiento no se pausarán en el recurso durante el período anterior a la ventana de mantenimiento programada. Durante los días no incluidos en la programación de mantenimiento, el mantenimiento continúa como de costumbre en el recurso.

¿Cómo puedo obtener más información sobre el mantenimiento de puertas de enlace controladas por el cliente?

Para más información, consulte el artículo Configuración del mantenimiento de puerta de enlace controlado por el cliente para VPN Gateway.

Contenido relacionado

"OpenVPN" es una marca comercial de OpenVPN Inc.