VPN IP privada do Azure sobre ExpressRoute sem NVA

O mito é que cifrar o tráfego sobre o peering privado do ExpressRoute exige um dispositivo virtual de rede. Não exige. O Azure suporta um Site-to-Site VPN Gateway cujo endpoint do túnel é um endereço RFC1918 privado transportado pelo circuito, e o dispositivo é opcional, não estrutural. O que o mito do dispositivo esconde é a parte que realmente dói: ativar o endpoint privado num objeto em vez de dois, e deixar uma rota de peering direto vencer silenciosamente sobre o caminho cifrado.

De onde veio o mito

A afirmação tem uma origem respeitável. Durante anos, a receita prática para IPsec sobre peering privado era uma NVA, porque o gateway gerido expunha apenas endpoints públicos. Isso mudou, e respostas escritas antes da mudança ainda são citadas em tópicos onde ninguém verifica a data. A correção é estreita: existe um gateway VPN com endereço privado, e ele muda o endpoint, não a lógica de encaminhamento à volta.

Nada disto reforma a NVA. Reforma a suposição de que um dispositivo é o único caminho para o requisito.

Ative o endpoint privado nos dois níveis

Comece por uma ligação de peering privado do ExpressRoute a funcionar e ligada à VNet que contém o gateway VPN. O lado local já deve alcançar os endereços privados relevantes através desse circuito, porque o túnel usará esses endereços como transporte. Depois o pré-requisito do gateway: o procedimento da Microsoft para VPN com IP privado exige um gateway construído sobre um recurso de IP público Standard. O endereçamento privado do túnel não elimina esse requisito, o que surpreende quem assume que «privado» significa «nenhum IP público em lado nenhum».

Agora ative o sinalizador nos dois locais. A configuração do gateway tem o seu próprio interruptor para IP privados, e a ligação Site-to-Site individual tem um segundo que faz essa ligação usar o endereço privado. Definir um e não o outro é a configuração incompleta mais comum; o túnel ou não é estabelecido ou é estabelecido para o endpoint errado.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Confirme os nomes das propriedades com a versão da CLI instalada, porque as etiquetas do portal e as propriedades da CLI nem sempre têm a mesma formulação. Um gateway ativo-ativo expõe dois endereços privados de túnel, e o dispositivo local precisa dos dois pares configurados se quiser que essa redundância signifique algo. O BGP não é necessário apenas para levantar este túnel de endereço privado, embora normalmente faça parte da forma como distribui os prefixos.

O segundo mito: um túnel estabelecido cifra o seu tráfego

Dois caminhos chegam agora à rede da aplicação: o caminho direto do peering privado e o caminho através da VPN. Ambos funcionam. Apenas um aplica esta camada IPsec. A Microsoft documenta que, quando prefixos idênticos são anunciados pelo ExpressRoute e pela VPN, o Azure prefere o caminho direto do ExpressRoute, pelo que um túnel saudável com contadores saudáveis não prova nada sobre onde foram os pacotes da aplicação.

Os métodos de encaminhamento documentados são um intervalo abrangente no ExpressRoute com um intervalo protegido mais específico na VPN, ou prefixos disjuntos nos dois caminhos. Por exemplo, o peering privado pode transportar 10.40.0.0/16 enquanto a VPN anuncia 10.40.12.0/24. O prefixo mais específico ganha e o resto do intervalo permanece direto.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Faça a mesma verificação na direção local, porque a preferência do seu router decide por onde sai o tráfego de saída. E mantenha o transporte do próprio túnel no caminho do ExpressRoute; uma rota que puxe o endpoint privado do gateway para dentro do túnel torna o túnel dependente de si próprio.

Decida o que acontece quando o túnel cai

Uma rota VPN mais específica desaparece quando o túnel cai, enquanto a rota direta mais ampla permanece. O tráfego flui então sem cifra e tudo parece saudável, o que é o pior modo de falha para um requisito que existe para garantir a cifra. Se o requisito proíbe esse retrocesso, o encaminhamento e a política de acesso têm de o dizer explicitamente em vez de confiarem na disponibilidade do túnel.

Anote que prefixos podem continuar diretamente acessíveis e quais têm de parar quando o caminho cifrado está ausente. Depois teste o caso permitido com tráfego real e compare os contadores de ligação, porque a tabela de rotas sozinha não lhe dirá se o requisito de cifra ainda se aplica.

Esse enquadramento também lhe permite avaliar uma NVA pelas suas funções reais, como vários túneis, débito ou inspeção do fornecedor, em vez de comprar uma porque o endpoint é privado.