UDR do Azure para um gateway VPN: um destino, não toda a saída

Você adiciona uma rota definida pelo usuário para um prefixo externo, aponta-a para o gateway VPN, e o tráfego continua saindo pelo caminho de internet do Azure. Ou sai corretamente e a resposta nunca volta. Os dois resultados vêm do mesmo erro: tratar o próximo salto do Azure como o projeto inteiro. A tabela de rotas só decide qual saída um pacote toma dentro do Azure. O que acontece com ele depois do túnel, e como a resposta retorna, é a segunda metade que você precisa construir.

O próximo salto é um gateway, não o IP de um appliance

Uma UDR envia um prefixo correspondente a um tipo de próximo salto, e VirtualNetworkGateway é um tipo, não um endereço. As pessoas colam o IP privado do gateway numa rota VirtualAppliance e depois se perguntam por que nada corresponde, porque esse tipo espera uma NIC ou um balanceador de carga interno. A documentação de roteamento da Microsoft também limita o próximo salto do gateway a uma rede virtual cujo gateway seja um gateway VPN. ExpressRoute, Route Server e um hub do Virtual WAN não são endereçados por essa opção.

Verifique o que a rede virtual realmente tem antes de escrever a rota. Se o projeto roteia por um hub, a rota pertence ao dono do roteamento do hub, não ao spoke que você está editando.

Leia a rota efetiva antes de alterar qualquer coisa

O Azure combina rotas do sistema, prefixos aprendidos por BGP e UDRs numa tabela de rotas efetiva por NIC, e o prefixo correspondente mais longo vence, venha de onde vier. Para o mesmo prefixo, uma UDR vence uma rota BGP. Essa ordem é o motivo pelo qual uma UDR antiga de um experimento anterior pode sobrescrever silenciosamente o prefixo que você acabou de aprender pelo túnel.

Olhe primeiro a tabela efetiva e depois decida se adiciona uma rota ou substitui uma:

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

Leia também a coluna de origem, não apenas o prefixo. Uma rota com o prefixo correto e a origem errada diz qual objeto editar, e evita adicionar uma segunda rota que perde para a primeira.

Escreva a rota com o prefixo e a sub-rede reais

Use o prefixo real do destino, retirado do serviço que você realmente alcança, em vez de um intervalo público copiado de uma postagem de fórum. Comece com um serviço aprovado antes de considerar uma rota padrão que move toda a saída. Depois associe a tabela de rotas à sub-rede da carga de trabalho. A sub-rede do gateway tem seus próprios requisitos, e associar sua tabela ali quebra o gateway em vez de direcionar a carga.

Crie a rota e depois vincule a tabela à sub-rede que hospeda 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 propagação também importa. Com a propagação BGP ativada nessa tabela, os prefixos aprendidos aparecem ao lado dos que você escreveu, e um prefixo aprendido mais específico pode vencer uma UDR mais ampla. Desative a propagação apenas quando quiser que o conjunto de UDRs seja autoritativo para essa sub-rede.

Conclua a metade local ou o fluxo morre ali

O gateway local precisa aceitar a origem do Azure, encaminhá-la ao destino e permitir o aplicativo. O caminho seguinte pode ser uma saída de internet ou outro salto privado, mas essa decisão pertence ao plano e não à tabela de rotas do Azure. A falha comum é o retorno. Um destino na internet não vai rotear uma origem privada do Azure de volta para você, então a resposta vai para o próprio gateway padrão e morre, ou nunca sai.

Dois projetos resolvem isso e não são intercambiáveis. Traduza a origem na saída, de modo que o destino responda a um endereço público que a rede local possui. Ou preserve a origem e construa uma relação de retorno roteada para que as respostas voltem pelo túnel. Escolha um e anote qual endereço o aplicativo verá.

Seletores e listas de permissão são separados de tudo isso. Escolher um próximo salto do Azure não amplia os seletores de tráfego da VPN e não altera a lista de origens permitidas de um serviço externo.

Verifique com a origem observada pelo destino

Envie a requisição a partir da carga real, e não de um host de salto em outra sub-rede, e depois leia o endereço de origem que o destino observou. Esse único valor diz qual dos dois projetos de retorno está em vigor. Verifique em seguida o caminho de resposta e confirme que o tráfego normal de gerenciamento para a VM ainda funciona, porque uma rota padrão adicionada por acidente aparece como sessão SSH quebrada muito antes de aparecer como aplicação quebrada.

Um trânsito por um prefixo selecionado é uma mudança muito mais estreita do que o túnel forçado. Mantenha-o estreito e a reversão é excluir uma rota.