UDR de Azure a unha pasarela VPN: un destino, non toda a saída

Engade unha ruta definida polo usuario para un prefixo externo, apúntaa á pasarela VPN e o tráfico segue saíndo polo camiño de internet de Azure. Ou sae correctamente e a resposta nunca volve. Ambos os resultados veñen do mesmo erro: tratar o seguinte salto de Azure como todo o deseño. A táboa de rutas só decide que saída toma un paquete dentro de Azure. O que lle pasa despois do túnel e como volve a resposta é unha segunda metade que ten que construír.

O seguinte salto é unha pasarela, non o IP dun aparello

Unha UDR envía un prefixo coincidente a un tipo de seguinte salto, e VirtualNetworkGateway é un tipo, non un enderezo. A xente pega o IP privado da pasarela nunha ruta VirtualAppliance e despois pregunta por que nada coincide, porque ese tipo espera unha NIC ou un balanceador de carga interno. A documentación de encamiñamento de Microsoft tamén limita o seguinte salto da pasarela a unha rede virtual cuxa pasarela sexa unha pasarela VPN. ExpressRoute, Route Server e un concentrador de Virtual WAN non se enderezan con esa opción.

Comprobe que ten realmente a rede virtual antes de escribir a ruta. Se o deseño encamiña a través dun concentrador, a ruta pertence ao propietario do encamiñamento do concentrador e non á rama que está a editar.

Lea a ruta efectiva antes de modificar nada

Azure combina rutas de sistema, prefixos aprendidos por BGP e UDR nunha táboa de rutas efectiva por NIC, e gaña o prefixo coincidente máis longo veña de onde veña. Para o mesmo prefixo, unha UDR gaña a unha ruta BGP. Ese ordenamento é a razón pola que unha UDR antiga dun experimento anterior pode superar en silencio o prefixo que acaba de aprender polo túnel.

Mire primeiro a táboa efectiva e despois decida se engade unha ruta ou substitúe unha:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Lea tamén a columna de orixe, non só o prefixo. Unha ruta co prefixo correcto e a orixe equivocada dille que obxecto editar e aforra engadir unha segunda ruta que perde contra a primeira.

Escriba a ruta co prefixo e a subrede reais

Use o prefixo real do destino, tomado do servizo ao que chega de verdade, en lugar dun rango público copiado dunha mensaxe de foro. Comece cun servizo aprobado antes de considerar unha ruta predeterminada que mova toda a saída. Despois asocie a táboa de rutas á subrede da carga de traballo. A subrede da pasarela ten os seus propios requisitos, e asociar alí a súa táboa rompe a pasarela en lugar de dirixir a carga.

Cree a ruta e logo vincule a táboa á subrede que aloxa a carga:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

A propagación tamén importa. Coa propagación BGP activada nesa táboa, os prefixos aprendidos aparecen xunto aos que escribiu, e un prefixo aprendido máis específico pode gañar a unha UDR máis ampla. Desactive a propagación só cando queira que o conxunto de UDR sexa autoritativo para esa subrede.

Complete a metade local ou o fluxo morre alí

A pasarela local debe aceptar a orixe de Azure, reenviala ao destino e permitir a aplicación. O seu camiño posterior pode ser unha saída a internet ou outro salto privado, pero esa decisión pertence ao plan e non á táboa de rutas de Azure. O fallo habitual é a volta. Un destino de internet non encamiñará unha orixe privada de Azure de volta cara a vostede, así que a resposta vai á súa propia pasarela predeterminada e morre, ou non sae nunca.

Dous deseños o resolven e non son intercambiables. Traduza a orixe na saída, de xeito que o destino responda a un enderezo público que posúe a rede local. Ou conserve a orixe e constrúa unha relación de retorno encamiñada para que as respostas volvan polo túnel. Escolla un e anote que enderezo verá a aplicación.

Os selectores e as listas de permitidos son algo aparte de todo isto. Escoller un seguinte salto de Azure non amplía os selectores de tráfico da VPN nin cambia a lista de orixes permitidas dun servizo externo.

Verifique coa orixe que observa o destino

Enhvíe a petición desde a carga real en lugar de desde un host de salto noutra subrede, e logo lea o enderezo de orixe que observou o destino. Ese único valor dille cal dos dous deseños de retorno está en marcha. Revise despois o camiño de resposta e confirme que o tráfico normal de administración cara á VM segue funcionando, porque unha ruta predeterminada engadida por accidente amósase como unha sesión SSH rota moito antes que como unha aplicación rota.

Un tránsito por un prefixo seleccionado é un cambio moito máis estreito que o túnel forzado. Mantéñao estreito e a reversión é borrar unha ruta.