Uma VNet Azure com peering precisa do seu próprio gateway VPN?

Surge uma nova VNet spoke, o hub já tem um gateway site-to-site a funcionar, e a pergunta óbvia é se é preciso pagar por um segundo gateway. Normalmente não: o trânsito de gateway permite ao spoke usar o gateway do hub através do peering. Três condições decidem se isso funcionará, e nenhuma delas é visível no badge de estado do peering. A conectividade do peering e a permissão para usar o gateway de outra pessoa são definições separadas, por isso duas VM que já conseguem fazer ping uma à outra não provam nada sobre o caminho VPN.

Primeira condição: o gateway e a ausência de um no spoke

O Azure suporta o trânsito de gateway para SKUs do VPN Gateway diferentes do Basic, e tanto o peering regional como o global o podem transportar. O spoke consome um gateway que não possui, pelo que não pode ter um próprio: se já existir um gateway no spoke, ou se já estiver selecionada uma opção de gateway remoto, a definição de trânsito pretendida ficará indisponível ou sem efeito. Verifique isso antes de depurar seja o que for, porque a caixa desativada é o sintoma, não a falha. Leia primeiro o SKU e o gateway existente e só depois olhe para as definições do peering.

Não elimine um gateway spoke existente para que a opção apareça enquanto não souber do que depende. A ordem de migração importa mais do que a caixa de verificação.

Segunda condição: uma definição em cada direção do peering

Um peering são dois objetos, um em cada VNet, e as definições de trânsito vivem em lados diferentes desse par. O peering do hub em direção ao spoke tem de permitir que o gateway do hub sirva o spoke; o peering do spoke em direção ao hub tem de aceitar o gateway do hub. o guia de trânsito de gateway da Microsoft designa-os por direção, que é a única forma de os manter corretos:

Um controlo etiquetado como remote muda de significado consoante o peering de que VNet está a editar, por isso leia a direção, não a palavra. Defina os dois lados, guarde e confirme que o peering reporta ligação nos dois locais.

Terceira condição: espaço de endereços e limites de permissões

O trânsito não pode fazer com que o mesmo prefixo de destino signifique duas redes, pelo que os intervalos do hub, do spoke e da rede local têm de ser disjuntos antes de algo disto funcionar. As VNet também podem estar em subscrições ou inquilinos diferentes; isso não é uma proibição, mas a identidade que cria ou atualiza cada peering precisa das permissões necessárias nessa rede. As alterações entre subscrições falham frequentemente por permissões, e o erro é fácil de ler mal como um problema de topologia.

Anote os intervalos e os proprietários antes da alteração. Adivinhar qualquer um deles produz um peering que liga e não encaminha nada.

Verifique com rotas efetivas, não com o estado do peering

Veja as rotas efetivas na interface de rede de uma carga de trabalho do spoke e encontre o prefixo local real. Verifique a tabela de rotas da sub-rede e se a propagação de rotas do gateway está desativada, porque uma rota definida pelo utilizador ou um dispositivo de inspeção podem sobrepor-se ao caminho que os indicadores do peering sugerem. Depois confirme o sentido inverso: a rede local tem de saber como chegar ao prefixo do spoke através da ligação site-to-site, quer por anúncios aprendidos, quer por uma rota explícita e uma entrada de rede protegida correspondente no dispositivo do cliente. Se o prefixo faltar em qualquer um dos lados, os indicadores do peering não são o que deve ser alterado.

Teste um serviço a partir de uma carga de trabalho do spoke e acompanhe a resposta. Um teste a partir do gateway VPN ou de uma VM do hub exercita um prefixo de origem e um caminho diferentes.

Se a topologia também serve clientes ponto-a-site, valide as respetivas rotas instaladas em separado. Os pacotes de cliente Windows podem precisar de regeneração após uma alteração de topologia, e isso é uma tarefa de encaminhamento do cliente, não uma prova de que a partilha do gateway falhou.

O que partilhar um gateway não concede

O trânsito de gateway é uma comodidade de encaminhamento, não uma autorização. Os grupos de segurança de rede, os filtros locais e as regras ao nível do serviço continuam a decidir o que uma carga de trabalho do spoke pode alcançar, por isso ative o serviço concreto de origem para destino em vez de assumir que o túnel partilhado permite tudo por trás dele.

O peering também não é transitivo como as pessoas esperam. Adicionar outro spoke, ou um ponto final privado, introduz os seus próprios requisitos de encaminhamento e acesso que a definição de trânsito existente não cobre.