Dois endereços VPN locais: dois pares Azure, não um

O diagrama tem dois links de internet na filial e um gateway VPN do Azure, então o gateway de rede local recebe os dois endereços públicos. Parece organizado e não funciona como o diagrama sugere. Cada dispositivo VPN local é uma relação de par separada, e o design de vários dispositivos da Microsoft dá a cada um seu próprio recurso de gateway de rede local e sua própria conexão. Adicionar um segundo endereço a um único recurso não cria um segundo par. Cria um recurso que não descreve corretamente nenhum dos dois dispositivos.

O mito: um gateway, dois endereços

Um gateway de rede local é a descrição de um par remoto: um endpoint público e os prefixos privados por trás dele. Não há maneira suportada de fazer esse recurso significar «qualquer um destes dois aparelhos».

A mesma confusão vai na outra direção, onde dois IPs públicos do Azure são lidos como prova de que existem dois gateways do Azure.

Conte os objetos, depois os túneis

Pegue dois dispositivos locais operados de forma independente, cada um com seu próprio endereço público e acesso às mesmas redes privadas, mais um gateway do Azure baseado em rotas no modo ativo-ativo. O gateway do Azure tem duas instâncias ativas com IPs públicos separados. Cada dispositivo local se conecta às duas instâncias. Essa é a malha completa, e a contagem de objetos decorre dela, não do diagrama.

A aritmética é curta o suficiente para colar no documento de design:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Um recurso de conexão pode transportar mais de um túnel subjacente, então quatro túneis não implicam quatro gateways de rede virtual. Dois IPs públicos do Azure também não são os mesmos objetos que os dois gateways de rede local que descrevem o site remoto.

O que o ativo-ativo acrescenta no lado do Azure

O ativo-ativo muda o gateway do Azure de uma instância ativa para duas, cada uma com seu próprio IP público, e é isso que torna uma malha completa possível. Não duplica a taxa de transferência de um único fluxo. Também não elimina a necessidade de o lado local suportar multipath de custo igual se os dois dispositivos encaminharem ao mesmo tempo. Confirme o modo do gateway, a SKU e a capacidade do dispositivo remoto antes de provisionar qualquer coisa.

Um gateway em espera passiva é um design perfeitamente válido; apenas produz uma contagem de túneis diferente.

O BGP torna os dois caminhos utilizáveis

Para o design de vários dispositivos, os dois dispositivos locais executam BGP. Dê a cada um um endereço de par BGP exclusivo e anuncie os mesmos prefixos privados pretendidos pelos caminhos relevantes. Os prefixos privados identificam as redes protegidas, enquanto os endereços públicos identificam onde terminam as conexões de transporte criptografadas. Confundir os dois produz um design em que todos os túneis estão ativos e as rotas estão erradas.

Planeje o roteamento de retorno e qualquer inspeção com estado que precise tolerar qualquer um dos dois caminhos. Uma sessão IKE saudável em cada endpoint não prova que uma carga de trabalho possa usar cada rota anunciada.

A seleção por fluxo não é agregação de largura de banda

O Azure seleciona um caminho por fluxo usando um hash sobre o endereçamento e as portas do fluxo. Em estado estacionário, os pacotes de um determinado fluxo TCP ou UDP normalmente seguem o mesmo túnel, e o lado local pode escolher outro túnel para a direção de retorno. Portanto, dois dispositivos e quatro túneis melhoram a disponibilidade, não a velocidade de uma transferência. Quando um slide do fornecedor promete agregação, ele descreve outro recurso ou um mal-entendido.

Teste com fluxos paralelos se quiser ver os caminhos se espalharem, e com um único fluxo se quiser ver o limite.

Qual redundância você realmente removeu

Dois endereços WAN em um único dispositivo melhoram as opções de link de acesso enquanto compartilham a energia, o software e o estado de falha desse dispositivo. Não são o mesmo que dois dispositivos, e nenhuma configuração do lado do Azure muda isso. Siga o design de WAN dupla ou cluster suportado pelo fornecedor em vez de inferir redundância pela contagem de endereços. Depois teste: remova um caminho de cada vez e confirme as rotas restantes mais uma troca real de aplicação nos dois sentidos.

Espere atrasos de detecção e convergência, e espere que algumas sessões existentes terminem.