Precisa unha VNet de Azure con emparellamento a súa propia pasarela VPN?
Unha VNet con emparellamento pode usar a pasarela VPN do hub cun SKU compatible e un axuste en cada dirección do emparellamento. Comprobe as rutas efectivas, non o estado do emparellamento.
Aparece unha VNet de spoke nova, o hub xa ten unha pasarela de sitio a sitio en funcionamento, e a pregunta obvia é se hai que pagar por unha segunda pasarela. Normalmente non: o tránsito de pasarela permite que o spoke consuma a pasarela do hub a través do emparellamento. Tres condicións deciden se iso funcionará, e ningunha delas se ve na insignia de estado do emparellamento. A conectividade do emparellamento e o permiso para usar a pasarela doutro son axustes separados, así que dúas VM que xa se fan ping non demostran nada sobre a ruta VPN.
Primeira condición: a pasarela e a falta dunha no spoke
Azure admite o tránsito de pasarela para SKU de VPN Gateway distintos de Basic, e tanto o emparellamento rexional como o global poden transportalo. O spoke consume unha pasarela que non posúe, así que non pode ter unha propia: se xa existe unha pasarela no spoke, ou xa hai seleccionada unha opción de pasarela remota, o axuste de tránsito que desexa non estará dispoñible ou non será eficaz. Comprobe isto antes de depurar nada, porque a caixa desactivada é o síntoma, non o fallo. Lea primeiro a SKU e a pasarela existente, e despois mire os axustes do emparellamento.
Non elimine unha pasarela de spoke existente para que apareza a opción ata que saiba do que depende. A orde de migración importa máis ca a caixa.
Segunda condición: un axuste en cada dirección do emparellamento
Un emparellamento son dous obxectos, un en cada VNet, e os axustes de tránsito viven en lados distintos dese par. O emparellamento do hub cara ao spoke debe permitir que a pasarela do hub sirva o spoke; o emparellamento do spoke cara ao hub debe aceptar a pasarela do hub. a guía de tránsito de pasarela de Microsoft os nomea por dirección, que é a única forma de mantelos 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 segundo o emparellamento de que VNet estea editando, así que lea a dirección, non a palabra. Configure ambos os lados, garde e confirme que o emparellamento informa de conexión nos dous lugares.
Terceira condición: espazo de enderezos e límites de permisos
O tránsito non pode facer que o mesmo prefixo de destino signifique dúas redes, así que os rangos do hub, do spoke e da rede local deben ser disxuntos antes de que algo disto funcione. As VNet tamén poden estar en subscricións ou inquilinos distintos; iso non é unha prohibición, pero a identidade que crea ou actualiza cada emparellamento necesita os permisos necesarios nesa rede. Os cambios entre subscricións adoitan fallar por permisos, e o erro é fácil de malinterpretar como un problema de topoloxía.
Anote os rangos e os propietarios antes do cambio. Adiviñar calquera dos dous produce un emparellamento que conecta e non encamiña nada.
Verifique con rutas efectivas, non co estado do emparellamento
Mire as rutas efectivas na interface de rede dunha carga de traballo do spoke e atope o prefixo local real. Comprobe a táboa de rutas da subrede e se a propagación de rutas de pasarela está desactivada, porque unha ruta definida polo usuario ou un dispositivo de inspección poden anular a ruta que suxiren os indicadores do emparellamento. Despois confirme a outra dirección: a rede local debe saber como chegar ao prefixo do spoke a través da conexión de sitio a sitio, xa sexa mediante anuncios aprendidos ou mediante unha ruta explícita e unha entrada de rede protexida correspondente no dispositivo do cliente. Se falta o prefixo en calquera dos dous lados, os indicadores do emparellamento non son o que hai que cambiar.
Probe un servizo desde unha carga de traballo do spoke e siga a resposta. Unha proba desde a pasarela VPN ou desde unha VM do hub exercita un prefixo de orixe e unha ruta distintos.
Se a topoloxía tamén atende clientes de punto a sitio, valide as súas rutas instaladas por separado. Os paquetes de cliente de Windows poden necesitar rexeneración tras un cambio de topoloxía, e iso é unha tarefa de encamiñamento de cliente, non unha proba de que fallase o uso compartido da pasarela.
Que non concede compartir unha pasarela
O tránsito de pasarela é unha comodidade de encamiñamento, non unha autorización. Os grupos de seguridade de rede, os filtros locais e as regras de nivel de servizo seguen decidindo a que pode chegar unha carga de traballo do spoke, así que habilite o servizo concreto de orixe a destino en lugar de supoñer que o túnel compartido o permite todo detrás del.
O emparellamento tampouco é transitivo como a xente espera. Engadir outro spoke, ou un punto de conexión privado, introduce os seus propios requisitos de encamiñamento e acceso que o axuste de tránsito existente non cobre.