Peering do Azure ou VPN de VNet para VNet? Decida antes de encaminhar

O Azure oferece pelo menos duas formas de conectar duas redes virtuais, e não são configurações intercambiáveis no mesmo objeto. O peering une as VNet no backbone da Microsoft sem gateway; uma VPN de VNet para VNet coloca uma relação IPsec entre dois gateways que você implanta, dimensiona e monitora. A decisão se resume a três condições, e se você não conseguir responder às três antes de acrescentar uma rota, está prestes a construir um contorno para um modelo que nunca escolheu.

Três condições que decidem o modelo

A primeira é se algo no requisito precisa de uma fronteira IPsec que seja sua e que você possa apontar. A segunda é se os espaços de endereçamento estão limpos e as duas VNet só precisam falar entre si. A terceira é quem é dono de qualquer caminho transitivo e da fatura do gateway. Responda nessa ordem, porque a primeira pode eliminar o peering por mais atraente que a segunda pareça.

O que ambos os modelos partilham é uma regra de endereçamento rígida: os espaços de endereçamento das VNet não podem sobrepor-se. Nem o peering nem uma VPN de VNet para VNet são uma forma suportada de tornar inequívocos dois intervalos idênticos, e uma sobreposição exige um desenho de mapeamento ou um redesenho, não outro tipo de ligação.

Condição 1: precisa de uma fronteira IPsec que seja sua?

O peering transporta o tráfego pelo backbone privado do Azure e não exige um gateway VPN para a própria ligação emparelhada. Isso é uma afirmação sobre transporte, não uma afirmação sobre cifra que possa entregar a um auditor como «executamos IPsec». Se o requisito nomeia um túnel configurado pelo cliente, uma política IKE específica ou uma fronteira que termina em equipamento que você controla, o peering não a satisfaz, por mais privado que seja o backbone.

Uma VPN de VNet para VNet fornece essa fronteira: dois gateways, uma relação IPsec/IKE, chaves partilhadas e toda a superfície operacional que a acompanha. Você herda o estado do túnel, a capacidade do gateway, os limites de SKU e a monitorização que prova que o túnel está ativo. Essa é a resposta correta quando o requisito trata especificamente dessa fronteira, descrita na visão geral do peering como um tipo de ligação distinto do peering.

Seja igualmente cuidadoso na direção oposta. «Precisamos de cifra entre VNet» muitas vezes é satisfeito pelo TLS da própria carga de trabalho, e então um gateway é um custo sem requisito por trás. Escreva a frase que o auditor vai ler antes de escolher o mecanismo.

Condição 2: a topologia é direta, ou algo precisa de transitar?

O peering não é transitivo. Duas VNet emparelhadas com um hub não ficam por isso ligadas entre si, e uma rota que parece funcionar numa direção é geralmente um peering que só alcançou Connected de um lado. Os dois lados devem existir e ambos devem mostrar Connected, e é a primeira coisa a verificar quando o tráfego desaparece em silêncio.

Se o requisito é alcançar a rede local através de um hub, o trânsito de gateway é um desenho separado com papéis específicos: o hub possui o gateway, o peering do spoke permite o trânsito de gateway e o spoke tem de permitir o tráfego reencaminhado. São propriedades do peering, não consequências automáticas de ligar as VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

A tabela de rotas efetiva é a resposta honesta a «o caminho existe?». Mostra o tipo de salto seguinte que a plataforma realmente usará, pelo que um peering que parece configurado mas não está ligado aparece como uma rota em falta ou errada e não como um mistério.

Condição 3: quem é dono do caminho transitivo e da fatura?

Cada salto adicional tem um dono. Com peering, uma nova VNet significa um novo par de peerings dos dois lados e, para trânsito, um hub que continua a reencaminhar tráfego e uma tabela de rotas que continua a apontar para ele. Com uma VPN, uma nova VNet significa outro gateway ou outra ligação num existente, com o seu próprio teto de capacidade a vigiar.

O custo segue a mesma forma mas não as mesmas rubricas: os encargos de peering são ligação e transferência de dados, enquanto uma VPN acrescenta horas de gateway e os seus próprios encargos de transferência. Compare o total para a topologia que vai realmente executar durante um ano, incluindo o segundo túnel e a monitorização, não o preço de uma ligação hoje. Inclua o trabalho que ninguém fatura: alguém tem de rodar chaves, vigiar o estado do túnel e responder ao alerta às três da manhã quando um gateway reinicia. Essa rubrica costuma decidir a discussão, porque é a única que nunca aparece num orçamento.

Escolha o que escolher, teste três fluxos: o previsto, um negado que deve continuar negado e o caso de recuperação em que o gateway do hub ou um peering está em baixo. Um modelo que só explica o caminho feliz não foi verificado, foi demonstrado.

Verifique a escolha contra a sua própria afirmação

Escreva uma frase que nomeie o modelo, a fronteira e o dono, e depois verifique que o estado implantado lhe corresponde. Para o peering isso significa ambos os estados de peering em Connected, a rota efetiva a mostrar o salto seguinte de peering para o prefixo de destino e nenhum gateway no caminho. Para uma VPN de VNet para VNet significa ambas as ligações em Connected, chaves e políticas coincidentes nos dois gateways e uma rota cujo salto seguinte é o gateway de rede virtual.

Se as verificações contradizem a frase, corrija primeiro a frase. A maior parte da confusão nestes desenhos vem de um híbrido que ninguém descreveu: um peering para a sub-rede da carga de trabalho, uma VPN para um serviço legado e uma tabela de rotas que prefere um deles em silêncio.