Cenário: Encaminhar o tráfego através de NVAs através de definições personalizadas

Artigo
06/01/2023

Quando estiver a trabalhar com o encaminhamento do hub virtual do Azure WAN Virtual, tem muitas opções disponíveis para si. O foco deste artigo é quando pretende encaminhar o tráfego através de uma aplicação virtual de rede (NVA) para comunicação entre redes virtuais e ramos e utilizar uma NVA diferente para tráfego vinculado à Internet. Para obter mais informações, veja Acerca do encaminhamento do hub virtual.

Nota

Tenha em atenção que, para os cenários de encaminhamento abaixo, o hub WAN Virtual e o Spoke Rede Virtual que contêm a NVA têm de estar na mesma Região do Azure.

Design

Spokes para redes virtuais ligadas ao hub virtual. (Por exemplo, VNet 1, VNet 2 e VNet 3 no diagrama mais adiante neste artigo.)
VNet de serviço para redes virtuais em que os utilizadores implementaram uma NVA para inspecionar o tráfego não internet e, possivelmente, com serviços comuns acedidos por spokes. (Por exemplo, VNet 4 no diagrama posterior neste artigo.)
VNet de perímetro para redes virtuais em que os utilizadores implementaram uma NVA para serem utilizados para inspecionar o tráfego vinculado à Internet. (Por exemplo, VNet 5 no diagrama posterior neste artigo.)
Hubs para hubs WAN Virtual geridos pela Microsoft.

A tabela seguinte resume as ligações suportadas neste cenário:

De	Para	Spokes	VNet de Serviço	Ramos	Internet
Spokes	->	diretamente	diretamente	através da VNet de Serviço	através da VNet de Perímetro
VNet de Serviço	->	diretamente	n/a	diretamente
Ramos	->	através da VNet de Serviço	diretamente	diretamente

Cada uma das células na matriz de conectividade descreve se a conectividade flui diretamente através de WAN Virtual ou através de uma das redes virtuais com uma NVA.

Repare nos seguintes detalhes:

Spokes:
- Os spokes chegarão a outros spokes diretamente através WAN Virtual hubs.
- Os spokes irão obter conectividade aos ramos através de uma rota estática que aponta para a VNet do Serviço. Não aprendem prefixos específicos dos ramos, porque esses prefixos são mais específicos e substituem o resumo.
- Os spokes irão enviar tráfego da Internet para a VNet de Perímetro através de um VNet Peering direto.
Os ramos chegarão aos spokes através de um encaminhamento estático que aponta para a VNet do Serviço. Não aprendem prefixos específicos das redes virtuais que substituem a rota estática resumida.
A VNet do Serviço será semelhante a uma VNet dos Serviços Partilhados que tem de estar acessível a partir de todas as redes virtuais e de cada ramo.
A VNet de Perímetro não precisa de ter conectividade através de WAN Virtual, uma vez que o único tráfego que irá suportar vem através de peerings de rede virtual diretos. No entanto, para simplificar a configuração, utilize o mesmo modelo de conectividade que para a VNet de Perímetro.

Existem três padrões de conectividade distintos, que se traduzem em três tabelas de rotas. As associações às diferentes redes virtuais são:

Spokes:
- Tabela de rotas associada: RT_V2B
- Propagar para encaminhar tabelas: RT_V2B e RT_SHARED
VNets da NVA (VNet de Serviço e VNet do DMZ):
- Tabela de rotas associada: RT_SHARED
- Propagar para tabelas de rotas: RT_SHARED
Ramos:
- Tabela de rotas associada: Predefinição
- Propagar para tabelas de rotas: RT_SHARED e Predefinição

Nota

Certifique-se de que as VNets spoke não estão a propagar para a etiqueta Predefinida. Isto garante que o tráfego de ramificações para VNets spoke é reencaminhado para as NVAs.

Estas rotas estáticas garantem que o tráfego de e para a rede virtual e o ramo passa pela NVA na VNet do Serviço (VNet 4):

Descrição	Tabela de rota	Rota estática
Ramos	RT_V2B	10.2.0.0/16 -> vnet4conn
Spokes da NVA	Predefinição	10.1.0.0/16 -> vnet4conn

Agora, pode utilizar WAN Virtual para selecionar a ligação correta para onde enviar os pacotes. Também tem de utilizar WAN Virtual para selecionar a ação correta a tomar ao receber esses pacotes. Utilize as tabelas de rotas de ligação para o fazer, da seguinte forma:

Descrição	Ligação	Rota estática
VNet2Branch	vnet4conn	10.2.0.0/16 -> 10.4.0.5
Branch2VNet	vnet4conn	10.1.0.0/16 -> 10.4.0.5

Para obter mais informações, veja Acerca do encaminhamento do hub virtual.

Arquitetura

O diagrama seguinte mostra a arquitetura descrita anteriormente no artigo.

No diagrama, existe um hub; Hub 1.

O Hub 1 está diretamente ligado às VNets NVA VNet 4 e VNet 5.
Espera-se que o tráfego entre as VNets 1, 2, 3 e os ramos vá através da VNet 4 NVA 10.4.0.5.
Todo o tráfego vinculado à Internet das VNets 1, 2 e 3 deverá passar pela VNet 5 NVA 10.5.0.5.

Diagrama da arquitetura de rede.

Fluxo de trabalho

Para configurar o encaminhamento através da NVA, considere os seguintes passos:

Para que o tráfego com ligação à Internet seja encaminhado através da VNet 5, precisa das VNets 1, 2 e 3 para ligar diretamente através do peering de rede virtual à VNet 5. Também precisa de uma rota definida pelo utilizador configurada nas redes virtuais para 0.0.0.0/0 e próximo salto 10.5.0.5.

Se não quiser ligar as VNets 1, 2 e 3 à VNet 5 e, em vez disso, utilizar apenas a NVA na VNet 4 para encaminhar o tráfego 0.0.0.0/0 a partir de ramos (ligações VPN no local ou ExpressRoute), aceda ao fluxo de trabalho alternativo.

No entanto, se pretender que o tráfego da VNet para a VNet transite através da NVA, terá de desligar a VNet 1,2,3 do hub virtual e ligá-lo ou empilhá-lo acima da VNet NVA Spoke4. No WAN Virtual, o tráfego de VNet para VNet passa pelo hub de WAN Virtual ou pelo Azure Firewall de um hub de WAN Virtual (Hub seguro). Se as VNets utilizarem diretamente o VNet Peering, poderão comunicar diretamente ignorando o trânsito através do hub virtual.
Na portal do Azure, aceda ao hub virtual e crie uma tabela de rotas personalizada denominada RT_Shared. Esta tabela aprende as rotas através da propagação de todas as redes virtuais e ligações de ramo. Pode ver esta tabela vazia no diagrama seguinte.
- Rotas: Não precisa de adicionar rotas estáticas.
- Associação: Selecione VNets 4 e 5, o que significa que as ligações destas redes virtuais se associam à tabela de rotas RT_Shared.
- Propagação: Uma vez que pretende que todos os ramos e ligações de rede virtual propaguem as rotas dinamicamente para esta tabela de rotas, selecione ramos e todas as redes virtuais.
Crie uma tabela de rotas personalizada denominada RT_V2B para direcionar o tráfego das VNets 1, 2 e 3 para ramos.
- Rotas: Adicione uma entrada de rota estática agregada para ramos, com o salto seguinte como a ligação VNet 4. Configure uma rota estática na ligação da VNet 4 para prefixos de ramo. Indique o próximo salto como o IP específico da NVA na VNet 4.
- Associação: Selecione todas as VNets 1, 2 e 3. Isto implica que as ligações VNet 1, 2 e 3 serão associadas a esta tabela de rotas e poderão aprender rotas (estáticas e dinâmicas através da propagação) nesta tabela de rotas.
- Propagação: As ligações propagam rotas para encaminhar tabelas. Selecionar VNets 1, 2 e 3 permite propagar rotas das VNets 1, 2 e 3 para esta tabela de rotas. Não é necessário propagar rotas de ligações de ramo para RT_V2B, uma vez que o tráfego de rede virtual do ramo passa pela NVA na VNet 4.
Edite a tabela de rotas predefinida , DefaultRouteTable.

Todas as ligações VPN, Azure ExpressRoute e VPN de utilizador estão associadas à tabela de rotas predefinida. Todas as ligações VPN, ExpressRoute e VPN de utilizador propagam rotas para o mesmo conjunto de tabelas de rotas.
- Rotas: Adicione uma entrada de rota estática agregada para VNets 1, 2 e 3, com o salto seguinte como a ligação VNet 4. Configure uma rota estática na ligação da VNet 4 para prefixos agregados VNet 1, 2 e 3. Indique o próximo salto como o IP específico da NVA na VNet 4.
- Associação: Certifique-se de que a opção para ramos (VPN/ER/P2S) está selecionada, garantindo que as ligações de ramo no local estão associadas à tabela de rotas predefinida.
- Propagação de: Certifique-se de que a opção para ramos (VPN/ER/P2S) está selecionada, garantindo que as ligações no local estão a propagar rotas para a tabela de rotas predefinida.

Fluxo de trabalho alternativo

Neste fluxo de trabalho, não liga as VNets 1, 2 e 3 à VNet 5. Em vez disso, utilize a NVA na VNet 4 para encaminhar o tráfego 0.0.0.0/0 a partir de ramos (ligações VPN ou ExpressRoute no local).