Por qué el punto a sitio necesita una puerta de enlace Azure VPN basada en rutas

Una puerta de enlace basada en directivas construye un túnel IPsec seleccionado por los selectores de tráfico y no tiene interfaz a la que entregar las rutas de los clientes. La conexión de punto a sitio es una función de enrutamiento: la puerta de enlace posee un grupo de direcciones de cliente e instala rutas hacia esos clientes en la red virtual. Esa discrepancia es la razón por la que el portal no muestra ninguna opción para agregarla. Nada en la puerta de enlace existente se puede alternar para producir la interfaz, así que el cambio es un reemplazo y no una edición de la configuración.

El orden importa más que los pasos individuales. Si te equivocas en la secuencia, la interrupción de sitio a sitio se extiende más allá de la ventana de mantenimiento.

Qué hace realmente una puerta de enlace basada en directivas

Una puerta de enlace basada en directivas compara los paquetes con los selectores de tráfico configurados en la conexión y envía las coincidencias a un solo túnel. No hay ninguna interfaz de túnel con dirección, y no aparece ninguna ruta por cliente en ningún lugar de la red virtual. La tabla de rutas simplemente recibe los prefijos locales que apuntan a la puerta de enlace. Ese modelo basta para una conexión de sitio a sitio entre dos espacios de direcciones fijos.

Una puerta de enlace basada en rutas funciona al revés: presenta una interfaz de túnel y las rutas deciden qué entra en ella. La conexión de punto a sitio, y cualquier diseño cuyo conjunto de pares cambie, dependen de que esa interfaz exista.

Por qué el grupo de clientes necesita esa interfaz

Cuando un portátil se conecta, la puerta de enlace le asigna una dirección del grupo de punto a sitio. La red virtual necesita entonces una ruta que diga que esa dirección es accesible a través de la puerta de enlace. Sin una interfaz de túnel no hay nada a lo que adjuntar esa ruta.

El grupo procede de un intervalo que tú designas, y la puerta de enlace asigna de él. Si ese intervalo se superpone con la red local o con una red virtual emparejada, el conflicto solo aparece después de que se conecte un cliente, que es un mal momento para descubrirlo. Reserva el grupo antes de que empiece la migración.

El tipo tampoco es una configuración por conexión. Una puerta de enlace tiene un solo tipo, y cada conexión que mantiene se comporta en consecuencia, así que un diseño mixto necesita una segunda puerta de enlace y no una segunda conexión.

El tipo queda fijado en la creación

Microsoft afirma que una puerta de enlace de red virtual no se puede cambiar entre basada en directivas y basada en rutas después del despliegue. No hay comando de conversión ni interruptor en el portal. Crear una segunda puerta de enlace en la misma subred tampoco es una solución alternativa, porque Azure permite una puerta de enlace por red virtual. Por tanto, la migración consiste en quitar, reconstruir y volver a conectar.

Eso también integra la decisión de SKU en la misma construcción. Pasar a un SKU mayor más adelante es otro reemplazo de puerta de enlace con otra interrupción.

Una puerta de enlace, una GatewaySubnet

La puerta de enlace vive en una subred llamada GatewaySubnet, y solo una puerta de enlace la ocupa. Dimensionar esa subred forma parte de la preparación, porque un SKU mayor necesita más direcciones y una subred no se puede reducir después. Anota la configuración actual de sitio a sitio, la clave compartida, la puerta de enlace de red local y las rutas efectivas antes de tocar nada. Luego trata la ventana como una interrupción, porque el túnel de sitio a sitio permanece caído hasta que se configura la nueva conexión.

Un orden de reconstrucción que mantiene acotada la interrupción: crea la puerta de enlace basada en rutas, vuelve a crear la conexión de sitio a sitio hacia la misma puerta de enlace de red local, confirma el túnel y una solicitud de host a host, y solo entonces añade punto a sitio y genera un paquete de cliente nuevo.

Qué no arregla el reemplazo

Un segundo límite pertenece al par y no a Azure. Un dispositivo local basado en directivas solo puede alcanzar la red virtual a la que se conecta, y no puede transitar hacia otras redes locales ni otras redes virtuales a través de la misma puerta de enlace. Reemplazar el lado de Azure no cambia lo que el par puede seleccionar.

Si el requisito es realmente tránsito entre sitios, la respuesta es un dispositivo par basado en rutas o una topología en la que cada destino termina por separado. Resuélvelo antes de prometer una fecha, porque el reemplazo de la puerta de enlace por sí solo no lo entregará.

Orden de las operaciones y las comprobaciones

Verifica cada capacidad por separado. Primero el estado del túnel de sitio a sitio y una solicitud de host a host, luego una conexión de punto a sitio y un recurso privado, luego cualquier ruta de tránsito que afirme el diseño. Un estado verde de la puerta de enlace solo demuestra que la asociación de seguridad se levantó, y nada más. Mantén las comprobaciones en ese orden para que un fallo señale la etapa que lo introdujo.

Vuelve a generar los paquetes de cliente tras cualquier cambio de topología y mantén el grupo lejos de cada intervalo local y emparejado. Las restricciones y las diferencias entre SKU se recogen en la referencia de configuración de Azure VPN Gateway.