¿Necesita una VNet de Azure con emparejamiento su propia puerta de enlace VPN?
Una VNet con emparejamiento puede usar la puerta de enlace VPN del hub con una SKU compatible y un ajuste en cada dirección del emparejamiento. Compruebe las rutas efectivas, no el estado del emparejamiento.
Aparece una VNet de spoke nueva, el hub ya tiene una puerta de enlace de sitio a sitio en funcionamiento, y la pregunta obvia es si hay que pagar por una segunda puerta de enlace. Normalmente no: el tránsito de puerta de enlace permite que el spoke consuma la puerta de enlace del hub a través del emparejamiento. Tres condiciones deciden si eso funcionará, y ninguna de ellas se ve en la insignia de estado del emparejamiento. La conectividad del emparejamiento y el permiso para usar la puerta de enlace de otro son ajustes separados, así que dos VM que ya se hacen ping no demuestran nada sobre la ruta VPN.
Primera condición: la puerta de enlace y la falta de una en el spoke
Azure admite el tránsito de puerta de enlace para SKU de VPN Gateway distintos de Basic, y tanto el emparejamiento regional como el global pueden transportarlo. El spoke consume una puerta de enlace que no posee, así que no puede tener una propia: si ya existe una puerta de enlace en el spoke, o ya hay seleccionada una opción de puerta de enlace remota, el ajuste de tránsito que desea no estará disponible o no será eficaz. Compruébelo antes de depurar nada, porque la casilla deshabilitada es el síntoma, no el fallo. Lea primero la SKU y la puerta de enlace existente, y luego mire los ajustes del emparejamiento.
No elimine una puerta de enlace de spoke existente para que aparezca la opción hasta que sepa de qué depende. El orden de migración importa más que la casilla.
Segunda condición: un ajuste en cada dirección del emparejamiento
Un emparejamiento son dos objetos, uno en cada VNet, y los ajustes de tránsito viven en lados distintos de ese par. El emparejamiento del hub hacia el spoke debe permitir que la puerta de enlace del hub sirva al spoke; el emparejamiento del spoke hacia el hub debe aceptar la puerta de enlace del hub. la guía de tránsito de puerta de enlace de Microsoft los nombra por dirección, que es la única forma de mantenerlos claros:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Un control etiquetado como remote cambia de significado según el emparejamiento de qué VNet esté editando, así que lea la dirección, no la palabra. Configure ambos lados, guarde y confirme que el emparejamiento informa de conexión en los dos lugares.
Tercera condición: espacio de direcciones y límites de permisos
El tránsito no puede hacer que el mismo prefijo de destino signifique dos redes, así que los rangos del hub, del spoke y de la red local deben ser disjuntos antes de que algo de esto funcione. Las VNet también pueden estar en suscripciones o inquilinos distintos; eso no es una prohibición, pero la identidad que crea o actualiza cada emparejamiento necesita los permisos requeridos en esa red. Los cambios entre suscripciones suelen fallar por permisos, y el error es fácil de malinterpretar como un problema de topología.
Anote los rangos y los propietarios antes del cambio. Adivinar cualquiera de los dos produce un emparejamiento que conecta y no enruta nada.
Verifique con rutas efectivas, no con el estado del emparejamiento
Mire las rutas efectivas en la interfaz de red de una carga de trabajo del spoke y encuentre el prefijo local real. Compruebe la tabla de rutas de la subred y si la propagación de rutas de puerta de enlace está deshabilitada, porque una ruta definida por el usuario o un dispositivo de inspección pueden anular la ruta que sugieren los indicadores del emparejamiento. Después confirme la otra dirección: la red local debe saber cómo llegar al prefijo del spoke a través de la conexión de sitio a sitio, ya sea mediante anuncios aprendidos o mediante una ruta explícita y una entrada de red protegida correspondiente en el dispositivo del cliente. Si falta el prefijo en cualquiera de los dos lados, los indicadores del emparejamiento no son lo que hay que cambiar.
Pruebe un servicio desde una carga de trabajo del spoke y siga la respuesta. Una prueba desde la puerta de enlace VPN o desde una VM del hub ejercita un prefijo de origen y una ruta distintos.
Si la topología también atiende a clientes de punto a sitio, valide sus rutas instaladas por separado. Los paquetes de cliente de Windows pueden necesitar regeneración tras un cambio de topología, y eso es una tarea de enrutamiento de cliente, no una prueba de que haya fallado el uso compartido de la puerta de enlace.
Qué no concede compartir una puerta de enlace
El tránsito de puerta de enlace es una comodidad de enrutamiento, no una autorización. Los grupos de seguridad de red, los filtros locales y las reglas de nivel de servicio siguen decidiendo a qué puede llegar una carga de trabajo del spoke, así que habilite el servicio concreto de origen a destino en lugar de suponer que el túnel compartido lo permite todo detrás de él.
El emparejamiento tampoco es transitivo como la gente espera. Añadir otro spoke, o un punto de conexión privado, introduce sus propios requisitos de enrutamiento y acceso que el ajuste de tránsito existente no cubre.