Como configurar políticas de roteamento e de intenção de roteamento do Hub de WAN Virtual

Artigo
10/14/2024

A intenção de roteamento do Hub de WAN Virtual permite configurar políticas de roteamento simples e declarativas para enviar tráfego para soluções de segurança bump-in-the-wire, como Firewall do Azure, Soluções de virtualização de rede ou Soluções SaaS (software como serviço) implantadas no hub de WAN Virtual.

Tela de fundo

As Políticas Roteamento e Intenção de Roteamento permitem configurar o hub de WAN Virtual para encaminhar o Tráfego Privado e Vinculado à Internet (Ponto a site, VPN de Site a site, ExpressRoute, Rede Virtual e Soluções de virtualização de rede) para um Firewall do Azure, NGFW (Solução de virtualização de rede de firewall de última geração), NVA (Solução de Virtualização de Rede) ou SaaS (Solução de Software como Serviço) de segurança implantada no hub virtual.

Há dois tipos de Políticas de Roteamento: Políticas de Roteamento de Tráfego Privado e de Tráfego de Internet. Cada Hub de WAN Virtual pode ter no máximo uma Política de Roteamento de Tráfego da Internet e uma Política de Roteamento de Tráfego Privado, cada uma com um único recurso de Próximo Salto. Embora o Tráfego Privado inclua prefixos de endereço de branch e de Rede Virtual, as Políticas de Roteamento os consideram como uma entidade dentro dos conceitos de Intenção de Roteamento.

Política de Roteamento de Tráfego de Internet: quando uma Política de Roteamento de Tráfego de Internet é configurada em um Hub de WAN Virtual, todas as conexões de branch [VPN de usuário remoto (VPN de ponto a site), VPN de site a site e ExpressRoute] e de rede virtual com esse Hub de WAN Virtual encaminham o tráfego vinculado à Internet para o Firewall do Azure, provedor de Segurança de Terceiros, Solução de virtualização de Rede ou para a solução SaaS especificado como parte da Política de Roteamento.

Em outras palavras, quando a Política de Roteamento de Tráfego de Internet for configurada em um hub de WAN Virtual, a WAN Virtual anunciará uma rota padrão (0.0.0.0/0) para todas as Soluções de virtualização de rede, Gateways e spokes (implantados no hub ou spoke).
Política de Roteamento de Tráfego Privado: quando uma Política de roteamento de tráfego privado é configurada em um hub de WAN virtual, todo o tráfego de rede virtual e branch de entrada e saída do Hub de WAN Virtual, incluindo o tráfego entre hubs, é encaminhado para o recurso de próximo salto do Firewall do Azure, Solução de virtualização de rede ou solução SaaS.

Em outras palavras, quando esse tipo de política é configurado no Hub de WAN Virtual, todo o tráfego de branch para branch, de branch para rede virtual, de rede virtual para branch e entre hubs é enviado por meio do Firewall do Azure, Solução de virtualização de rede ou solução SaaS implantado no Hub de WAN Virtual.

Casos de uso

A seção a seguir descreve dois cenários comuns nos quais as Políticas de Roteamento são aplicadas a hubs de WAN Virtual Seguros.

Todos os Hubs de WAN Virtual são seguros (implantados com o Firewall do Azure, NVA ou solução SaaS)

Nesse cenário, todos os hubs de WAN Virtual são implantados com um Firewall do Azure, NVA ou solução SaaS neles. Neste cenário, você pode configurar uma Política de Roteamento de Tráfego de Internet, uma Política de Roteamento de Tráfego Privado ou ambas em cada Hub de WAN Virtual.

Considere a configuração a seguir em que os Hubs 1 e 2 têm Políticas de Roteamento tanto para Tráfego de Internet quanto para Tráfego Privado.

Configuração do Hub 1:

Política de tráfego privado com o Hub de Próximo Salto 1 do Firewall do Azure, NVA ou solução SaaS
Política de tráfego de Internet com o Hub de Próximo Salto 1 do Firewall do Azure, NVA ou solução SaaS

Configuração do Hub 2:

Política de tráfego privado com o Hub de Próximo Salto 2 do Firewall do Azure, NVA ou solução SaaS
Política de tráfego de Internet com o Hub de Próximo Salto 2 do Firewall do Azure, NVA ou solução SaaS

A seguir estão os fluxos de tráfego que resultam dessa configuração.

Observação

O Tráfego de Internet precisa sair da solução de segurança local no hub, já que a rota padrão (0.0.0.0/0) não se propaga entre hubs.

De	Para	VNets do Hub 1	Ramificações do Hub 1	VNets do Hub 2	Ramificações do Hub 2	Internet
VNets do Hub 1	→	Hub 1 AzFW ou NVA	Hub 1 AzFW ou NVA	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 1 do AzFW, NVA ou SaaS
Ramificações do Hub 1	→	Hub 1 do AzFW, NVA ou SaaS	Hub 1 do AzFW, NVA ou SaaS	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 1 do AzFW, NVA ou SaaS
VNets do Hub 2	→	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS
Ramificações do Hub 2	→	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 1 e 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS

Implantar Hubs de WAN Virtual seguros e regulares

Nesse cenário, nem todos os hubs na WAN são Hubs de WAN Virtual Seguros (hubs que têm uma solução de segurança implantada neles).

Considere a configuração a seguir em que o Hub 1 (Normal) e o Hub 2 (Seguro) são implantados em uma WAN Virtual. O Hub 2 tem Políticas de Roteamento tanto para Tráfego de Internet quanto Privado.

Configuração do Hub 1:

N/D (não é possível configurar Políticas de Roteamento se o hub não for implantado com o Firewall do Azure, NVA ou solução SaaS)

Configuração do Hub 2:

Política de tráfego privado com o Hub de Próximo Salto 2 do Firewall do Azure, NVA ou solução SaaS.
Política de tráfego de Internet com o Hub de Próximo Salto 2 do Firewall do Azure, NVA ou solução SaaS.

A seguir estão os fluxos de tráfego que resultam dessa configuração. Os branches e as Redes Virtuais conectadas ao Hub 1 não podem acessar a Internet por meio de uma solução de segurança implantada no Hub porque a rota padrão (0.0.0.0/0) não se propaga entre hubs.

De	Para	VNets do Hub 1	Ramificações do Hub 1	VNets do Hub 2	Ramificações do Hub 2	Internet
VNets do Hub 1	→	Direto	Direto	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	-
Ramificações do Hub 1	→	Direto	Direto	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	-
VNets do Hub 2	→	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS
Ramificações do Hub 2	→	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS	Hub 2 do AzFW, NVA ou SaaS

Limitações conhecidas

A tabela a seguir descreve a disponibilidade da intenção de roteamento em diferentes ambientes do Azure.
- A intenção de roteamento não está disponível no Microsoft Azure operado pela 21 Vianet.
- O Palo Alto Cloud NGFW só está disponível no Azure Public. Entre em contato com a Palo Alto Networks para saber sobre a disponibilidade do Cloud NGFW no Azure Governamental e no Microsoft Azure operado pela Viacom.
- Os Dispositivos Virtuais de Rede não estão disponíveis em todas as regiões do Azure Governamental. Entre em contato com seu parceiro NVA sobre a disponibilidade no Azure Governamental.

Ambiente de Nuvem	Firewall do Azure	Solução de Virtualização de Rede	Soluções de SaaS
Público do Azure	Sim	Sim	Sim
Azure Governamental	Sim	Limitado	Não
Microsoft Azure operado pela 21Vianet	Não	No	No

A Intenção de Roteamento simplifica o roteamento gerenciando associações e propagações de tabela de rotas para todas as conexões (Rede virtual, VPN site a site, VPN ponto a site e ExpressRoute). As WANs Virtuais com tabelas de rotas personalizadas e políticas personalizadas não podem ser usadas com os constructos de Intenção de Roteamento.
O ExpressRoute criptografado (túneis VPN site a site em execução em circuitos do ExpressRoute) tem suporte em hubs em que a intenção de roteamento é configurada se o Firewall do Azure estiver configurado para permitir o tráfego entre pontos de extremidade de túnel VPN (IP privado Gateway de VPN IP privado e IP privado do dispositivo VPN local). Para obter mais informações sobre as configurações necessárias, consulte ExpressRoute criptografado com intenção de roteamento.
Não há suporte para os seguintes casos de uso de conectividade com a Intenção de Roteamento:
- As rotas estáticas em defaultRouteTable que apontam para uma conexão de Rede Virtual não podem ser usadas em conjunto com a intenção de roteamento. No entanto, você pode usar o recurso de emparelhamento BGP.
- Rotas estáticas na conexão de Rede Virtual com "propagação de rota estática" não são aplicadas ao recurso de próximo salto especificado em políticas de roteamento privado. O suporte para a aplicação de rotas estáticas em conexões de Rede Virtual à política de roteamento privado no próximo salto está no roteiro.
- A capacidade de implantar tanto um NVA de conectividade SD-WAN quanto um NVA de firewall separado ou uma solução SaaS no mesmo hub de WAN virtual está atualmente no roteiro. Após a intenção de roteamento ter sido configurada com a solução SaaS ou NVA de Firewall de próximo salto, a conectividade entre o NVA de SD-WAN e o Azure será afetada. Em vez disso, implante a solução de NVA de SD-WAN e NVA ou SaaS de Firewall em Hubs Virtuais diferentes. Alternativamente, você também pode implantar o NVA de SD-WAN em uma Rede Virtual spoke conectada ao hub e tirar proveito da capacidade de peering BGP do hub virtual.
- As Soluções de virtualização de rede (NVAs) podem ser especificadas como o recurso de próximo salto para intenção de roteamento se forem Firewall de última geração ou Firewall de última geração de função dupla e NVAs SD-WAN. Atualmente, o ponto de verificação, fortinet-ngfw e fortinet-ngfw-and-sdwan são as únicas NVAs qualificadas para serem configurados para ser o próximo salto para a intenção de roteamento. Se você tentar especificar outro NVA, a criação da Intenção de Roteamento falha. Você pode marcar o tipo de NVA acessando o Hub Virtual –> Soluções de virtualização de rede e examinando o campo Fornecedor. Palo Alto Networks Cloud NGFW também tem suporte como o próximo salto para a Intenção de Roteamento, mas é considerado um próximo salto do tipo solução SaaS.
- Os usuários da Intenção de Roteamento que desejam conectar vários circuitos do ExpressRoute para a WAN Virtual e desejam enviar tráfego entre eles por meio de uma solução de segurança implantada no hub podem habilitar a abertura de um caso de suporte para habilitar esse caso de uso. Confira habilitar a conectividade em circuitos do ExpressRoute para obter mais informações.

Limites de Espaço de Endereço da Rede Virtual

Observação

O número máximo de espaços de endereço de Rede Virtual que você pode conectar a um único hub de WAN Virtual é ajustável. Abra um caso de suporte do Azure para solicitar um aumento de limite. Os limites são aplicáveis no nível do hub de WAN Virtual. Se você tiver vários hubs de WAN Virtual que necessitam de um aumento de limite, solicite o aumento de limite para todos os hubs de WAN Virtual na sua implantação da WAN Virtual.

Para clientes que utilizam intenção de roteamento, o número máximo de espaços de endereço em todas as Redes Virtuais diretamente conectadas a um único hub Virtual WAN é 400. Esse limite é aplicado individualmente a cada hub de WAN Virtual em uma implantação de WAN Virtual. Os espaços de endereço da Rede Virtual conectados a hubs remotos (outros hubs de WAN Virtual na mesmo WAN Virtual) não são contabilizados para este limite.

Se o número de espaços de endereço de Rede Virtual diretamente conectados a um hub exceder o limite, habilitar ou atualizar a intenção de roteamento no Hub Virtual falhará. Para hubs já configurados com intenção de roteamento, onde os espaços de endereço da Rede Virtual excedem o limite como resultado de uma operação, como uma atualização de espaço de endereço da Rede Virtual, o novo espaço de endereço conectado pode não ser roteável.

Solicite proativamente um aumento de limite se o número total de espaços de endereço em todas as Redes Virtuais localmente conectadas exceder 90% do limite documentado ou se você tiver qualquer expansão de rede planejada ou operações de implantação que aumentem o número de espaços de endereço da Rede Virtual além do limite.

A tabela a seguir fornece exemplos de cálculos de espaço de endereço de Rede Virtual.

Hub Virtual	Contagem de redes virtuais	Espaços de endereço por Rede Virtual	Número total de espaços de endereço de Rede Virtual conectados ao Hub Virtual	Ação sugerida
Hub nº 1	200	1	200	Nenhuma ação necessária, monitore a contagem de espaços de endereço.
Hub nº 2	150	3	450	Solicitar aumento do limite para usar a intenção de roteamento.
Hub nº 3	370	1	370	Solicitar aumento do limite.

Você pode usar o seguinte script PowerShell para estimar o número de espaços de endereço em Redes Virtuais conectadas a um único hub de WAN Virtual. Execute esse script para todos os hubs de WAN Virtual na sua WAN Virtual. Uma métrica do Azure Monitor para permitir o rastreamento e a configuração de alertas em espaços de endereço de Rede Virtual conectados está no roteiro.

Certifique-se de modificar a ID do recurso do hub de WAN Virtual no script para que corresponda ao seu ambiente. Se você tiver conexões de Rede Virtual entre locatários, certifique-se de ter permissões suficientes para ler o objeto de conexão da Rede Virtual WAN, bem como o recurso da Rede Virtual conectada.

$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
  
foreach($connection in $hubVNETconnections) {
  try{
    $resourceURI = $connection.RemoteVirtualNetwork.Id
    $RG = ($resourceURI -split "/")[4]
    $name = ($resourceURI -split "/")[8]
    $VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
    $addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
  }
  catch{
    Write-Host "An error occurred  while processing VNET connected to Virtual WAN hub with resource URI:  " -NoNewline
    Write-Host $resourceURI 
    Write-Host "Error Message: " -ForegroundColor Red
    Write-Host $_.Exception.Message -ForegroundColor Red 
  }
  finally{
  }
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green

Considerações

Os clientes que estão usando o Firewall do Azure no hub de WAN Virtual sem a Intenção de Roteamento podem habilitar a intenção de roteamento usando o Gerenciador de Firewall do Azure, o portal de roteamento de hub de WAN Virtual ou por meio de outras ferramentas de gerenciamento do Azure (PowerShell, CLI, API REST).

Antes de habilitar a intenção de roteamento, considere o seguinte:

A intenção de roteamento só pode ser configurada em hubs em que não há tabelas de rotas personalizadas e nenhuma rota estática no defaultRouteTable com o próximo salto de Conexão de rede virtual. Para saber mais, veja Pré-requisitos.
Salve uma cópia dos seus gateways, conexões e tabelas de rotas antes de habilitar a intenção de roteamento. O sistema não salvará e aplicará automaticamente as configurações anteriores. Para obter mais informações, consulte estratégia de reversão.
A intenção de roteamento altera as rotas estáticas em defaultRouteTable. Devido a otimizações do portal do Azure, o estado de defaultRouteTable após a configuração da intenção de roteamento poderá ser diferente se você configurar a intenção de roteamento usando REST, CLI ou PowerShell. Para saber mais, confira rotas estáticas.
Habilitar a intenção de roteamento afeta o anúncio de prefixos para o local. Confira anúncios de prefixo para obter mais informações.
Você pode abrir um caso de suporte para habilitar a conectividade entre circuitos do ExpressRoute por meio de um dispositivo de firewall no hub. Habilitar esse padrão de conectividade modifica os prefixos anunciados para circuitos do ExpressRoute. Para obter mais informações, consulte Sobre o ExpressRoute.
A intenção de roteamento é o único mecanismo na WAN Virtual para habilitar a inspeção de tráfego entre hubs por meio de dispositivos de segurança implantados no hub. A inspeção de tráfego entre hubs também requer que a intenção de roteamento seja habilitada em todos os hubs para garantir que o tráfego seja roteado simetricamente entre dispositivos de segurança implantados em hubs de WAN Virtual.
A intenção de roteamento envia a Rede Virtual e o tráfego local para o recurso de próximo salto especificado na política de roteamento. A WAN Virtual programa a plataforma subjacente do Azure para rotear o tráfego local e de Rede Virtual de acordo com a política de roteamento configurada e não processa o tráfego por meio do roteador do Hub Virtual. Como os pacotes roteados por meio da intenção de roteamento não são processados pelo roteador, você não precisa alocar unidades de infraestrutura de roteamento adicionais para encaminhamento de pacote de plano de dados em hubs configurados com intenção de roteamento. No entanto, talvez seja necessário alocar unidades de infraestrutura de roteamento adicionais com base no número de Máquinas Virtuais em Redes Virtuais conectadas ao Hub de WAN Virtual.
A intenção de roteamento permite configurar diferentes recursos de próximo salto para políticas de roteamento privado e de Internet. Por exemplo, é possível definir o próximo salto para políticas de roteamento privado para o Firewall do Azure no hub e o próximo salto para a política de roteamento da internet para uma solução NVA ou SaaS no hub. Como as soluções SaaS e as NVAs de Firewall são implantadas na mesma sub-rede no hub de WAN Virtual, implantar soluções SaaS com uma NVA de Firewall no mesmo hub pode afetar a escalabilidade horizontal das soluções SaaS, pois há menos endereços IP disponíveis para expansão horizontal. Além disso, você pode ter no máximo uma solução SaaS implantada em cada hub de WAN Virtual.

Pré-requisitos

Para habilitar a intenção e as políticas de roteamento, o Hub Virtual deve atender aos pré-requisitos abaixo:

Não há tabelas de rotas personalizadas implantadas com o Hub Virtual. As únicas tabelas de rotas existentes são noneRouteTable e defaultRouteTable.
Você não pode ter rotas estáticas com o próximo salto de Conexão de Rede Virtual. As rotas estáticas em defaultRouteTable podem ter o próximo salto do Firewall do Azure.

A opção de configurar a intenção de roteamento fica desabilitada para hubs que não atendem aos requisitos acima.

Usar a intenção de roteamento (habilitar a opção entre hubs) no Gerenciador de Firewall do Azure tem um requisito adicional:

As rotas criadas pelo Gerenciador de Firewall do Azure seguem a convenção de nomenclatura de private_traffic, internet_traffic ou all_traffic. Portanto, todas as rotas em defaultRouteTable devem seguir essa convenção.

Estratégia de reversão

Observação

Quando a configuração de intenção de roteamento é completamente removida de um hub, todas as conexões para o hub são definidas para propagar para o rótulo padrão (que se aplica a "todos" os defaultRouteTables na WAN Virtual). Como resultado, se você estiver considerando implementar a Intenção de Roteamento na WAN Virtual, salve uma cópia de suas configurações existentes (gateways, conexões, tabelas de rotas) para aplicar se quiser reverter para a configuração original. O sistema não restaura automaticamente sua configuração anterior.

A Intenção de Roteamento simplifica o roteamento e a configuração gerenciando propagações e associações de rota de todas as conexões em um hub.

A tabela a seguir descreve a tabela de rotas associada e as tabelas de rotas propagadas de todas as conexões depois que a intenção de roteamento é configurada.

Configuração da intenção de roteamento	Tabela de rotas associadas	Tabela de rotas propagadas
Internet	defaultRouteTable	rótulo padrão (defaultRouteTable de todos os hubs na WAN Virtual)
Privado	defaultRouteTable	noneRouteTable
Internet e Privado	defaultRouteTable	noneRouteTable

Rotas estáticas em defaultRouteTable

A seção a seguir descreve como a intenção de roteamento gerencia as rotas estáticas em defaultRouteTable quando a intenção de roteamento está habilitada em um hub. As modificações feitas pela Intenção de Roteamento em defaultRouteTable são irreversíveis.

Se você remover a intenção de roteamento, precisará restaurar manualmente sua configuração anterior. Portanto, recomendamos salvar um instantâneo da sua configuração antes de habilitar a intenção de roteamento.

Gerenciador de Firewall do Azure e Portal do Hub de WAN Virtual

Quando a intenção de roteamento é habilitada no hub, as rotas estáticas correspondentes às políticas de roteamento configuradas são criadas automaticamente em defaultRouteTable. Essas rotas são:

Nome da rota	Prefixos	Recurso do Próximo Salto
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Firewall do Azure
_policy_PublicTraffic	0.0.0.0/0	Firewall do Azure

Observação

Todas as rotas estáticas em defaultRouteTable que contêm prefixos que não são correspondências exatas a 0.0.0.0/0 ou às super-redes RFC1918 (10.0.0.0/8, 192.168.0.0/16 e 172.16.0.0/12) são consolidados automaticamente em uma única rota estática, nomeada private_traffic. Prefixos em defaultRouteTable que correspondem às super-redes RFC1918 ou 0.0.0.0/0 são sempre removidos automaticamente depois que a intenção de roteamento é configurada, independentemente do tipo de política.

Por exemplo, considere o cenário em que defaultRouteTable tem as seguintes rotas antes de configurar a intenção de roteamento:

Nome da rota	Prefixos	Recurso do Próximo Salto
private_traffic	192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24	Firewall do Azure
to_internet	0.0.0.0/0	Firewall do Azure
additional_private	10.0.0.0/8, 50.0.0.0/24	Firewall do Azure

Habilitar a intenção de roteamento nesse hub resultaria no seguinte estado final de defaultRouteTable. Todos os prefixos que não são RFC1918 ou 0.0.0.0/0 são consolidados em uma única rota nomeada private_traffic.

Nome da rota	Prefixos	Recurso do Próximo Salto
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Firewall do Azure
_policy_PublicTraffic	0.0.0.0/0	Firewall do Azure
private_traffic	40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24	Firewall do Azure

Outros métodos (PowerShell, REST, CLI)

Criar a intenção de roteamento usando métodos que não sejam do Portal cria automaticamente as rotas de política correspondentes em defaultRouteTable e também remove todos os prefixos em rotas estáticas que são correspondências exatas a 0.0.0.0/0 ou às super-redes RFC1918 (10.0.0.0/8, 192.168.0.0/16 ou 172.16.0.0/12). No entanto, outras rotas estáticas não são consolidadas automaticamente.

Por exemplo, considere o cenário em que defaultRouteTable tem as seguintes rotas antes de configurar a intenção de roteamento:

Nome da rota	Prefixos	Recurso do Próximo Salto
firewall_route_ 1	10.0.0.0/8	Firewall do Azure
firewall_route_2	192.168.0.0/16, 10.0.0.0/24	Firewall do Azure
firewall_route_3	40.0.0.0/24	Firewall do Azure
to_internet	0.0.0.0/0	Firewall do Azure

A tabela a seguir representa o estado final de defaultRouteTable após a criação da intenção de roteamento ter êxito. Observe que firewall_route_1 e to_internet foram removidos automaticamente, pois o único prefixo nessas rotas foi 10.0.0.0/8 e 0.0.0.0/0. firewall_route_2 foi modificado para remover 192.168.0.0/16, pois esse prefixo é um prefixo agregado RFC1918.

Nome da rota	Prefixos	Recurso do Próximo Salto
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Firewall do Azure
_policy_PublicTraffic	0.0.0.0/0	Firewall do Azure
firewall_route_2	10.0.0.0/24	Firewall do Azure
firewall_route_3	40.0.0.0/24	Firewall do Azure

Anúncio de prefixo para o local

A seção a seguir descreve como a WAN Virtual anuncia rotas para o local depois que a Intenção de Roteamento foi configurada em um Hub Virtual.

Política de roteamento da Internet

Observação

A rota padrão 0.0.0.0/0 não é anunciada entre hubs virtuais.

Se você habilitar políticas de roteamento da Internet no Hub Virtual, a rota padrão 0.0.0.0/0 será anunciada para todas as conexões com o hub (conexões de Rede Virtual ExpressRoute, VPN site a site, VPN ponto a site, NVA no hub e BGP) em que Propagar rota padrão ou o sinalizador Habilitar segurança de Internet é definido como true. Você pode definir esse sinalizador como false para todas as conexões que não devem aprender a rota padrão.

Política de roteamento privado

Quando um hub virtual é configurado com uma política de Roteamento Privado, a WAN Virtual anuncia rotas para conexões locais da seguinte maneira:

As rotas correspondentes aos prefixos aprendidos com as conexões de Redes Virtuais do hub local, ExpressRoute, VPN site a site, VPN ponto a site, NVA no hub ou BGP no hub atual.
As rotas correspondentes aos prefixos aprendidos com as conexões de Redes Virtuais do hub remoto, ExpressRoute, VPN site a site, VPN ponto a site, NVA no hub ou BGP em que as políticas de Roteamento Privado são configuradas.
As rotas correspondentes aos prefixos aprendidos com conexões de redes virtuais do hub remoto, ExpressRoute, VPN site a site, VPN ponto a site, NVA no hub e BGP em que a Intenção de Roteamento não está configurada e as conexões remotas se propagam para defaultRouteTable do hub local.
Os prefixos aprendidos com um circuito do ExpressRoute não são anunciados para outros circuitos do ExpressRoute, a menos que o Alcance Global esteja habilitado. Se você quiser habilitar o trânsito do ExpressRoute para o ExpressRoute por meio de uma solução de segurança implantada no hub, abra um caso de suporte. Confira Habilitar a conectividade em circuitos do ExpressRoute para obter mais informações.

Cenários de roteamento de chaves

A seção a seguir descreve alguns cenários de roteamento de chaves e comportamentos de roteamento ao configurar a intenção de roteamento em um hub de WAN Virtual.

A conectividade de trânsito entre circuitos do ExpressRoute com intenção de roteamento

A conectividade de trânsito entre os circuitos do ExpressRoute na Virtual WAN é fornecida por meio de duas configurações diferentes. Como essas duas configurações não são compatíveis, os clientes devem escolher uma opção de configuração para dar suporte à conectividade de trânsito entre dois circuitos do ExpressRoute.

Observação

Para habilitar a conectividade de trânsito do ExpressRoute para o ExpressRoute por meio de um dispositivo de Firewall no hub com políticas de roteamento privadas, abra um caso de suporte com o Suporte da Microsoft. Essa opção não é compatível com o Alcance Global e exige que o Alcance Global seja desabilitado para garantir o roteamento de trânsito adequado entre todos os circuitos do ExpressRoute conectados à WAN Virtual.

Alcance Global do ExpressRoute: O Alcance Global do ExpressRoute permite que dois circuitos habilitados para o Alcance Global enviem tráfego entre si diretamente, sem transitar pelo Virtual Hub.
Política de roteamento privado de intenção de roteamento: a configuração de políticas de roteamento privado permite que dois circuitos do ExpressRoute enviem tráfego um para o outro por meio de uma solução de segurança implantada no hub.

A conectividade entre circuitos do ExpressRoute por meio de um dispositivo de Firewall no hub com uma política de roteamento privado de intenção de roteamento está disponível nas seguintes configurações:

Ambos os circuitos do ExpressRoute estão conectados ao mesmo hub e uma política de roteamento privado é configurada nesse hub.
Os circuitos do ExpressRoute estão conectados a hubs diferentes e uma política de roteamento privado é configurada em ambos os hubs. Portanto, ambos os hubs devem ter uma solução de segurança implantada.

Considerações sobre o roteamento com o ExpressRoute

Observação

As considerações de roteamento abaixo se aplicam a todos os Hubs virtuais nas assinaturas habilitadas pelo Suporte da Microsoft para permitir a conectividade do ExpressRoute com o ExpressRoute por meio de um dispositivo de segurança no hub.

Depois que a conectividade de trânsito entre circuitos do ExpressRoute usando um dispositivo de firewall implantado no Hub Virtual estiver habilitada, você poderá esperar as seguintes alterações de comportamento em como as rotas são anunciadas para o ExpressRoute local:

A WAN Virtual anuncia automaticamente prefixos agregados RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) para o local conectado ao ExpressRoute. Essas rotas agregadas são anunciadas além das rotas descritas na seção anterior.
A WAN Virtual anuncia automaticamente todas as rotas estáticas em defaultRouteTable para o local conectado ao circuito do ExpressRoute. Isso significa que a WAN Virtual anuncia as rotas especificadas na caixa de texto do prefixo de tráfego privado para o local.

Devido a essas alterações de anúncio de rota, isso significa que o local conectado ao ExpressRoute não pode anunciar intervalos de endereços exatos para intervalos de endereços agregados RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Verifique se você está anunciando sub-redes mais específicas (dentro de intervalos de RFC1918) em vez de agregar super-redes e quaisquer prefixos na caixa de texto Tráfego Privado.

Além disso, se o circuito do ExpressRoute estiver anunciando um prefixo não RFC1918 para o Azure, verifique se os intervalos de endereços que você colocou na caixa de texto Prefixos de Tráfego Privado são menos específicos do que as rotas anunciadas pelo ExpressRoute. Por exemplo, se o Circuito do ExpressRoute estiver anunciando 40.0.0.0/24 do local, coloque um intervalo CIDR /23 ou maior na caixa de texto Prefixo de Tráfego Privado (exemplo: 40.0.0.0/23).

Os anúncios de rota para outros locais (VPN site a site, VPN ponto a site, NVA) não são afetados por habilitar a conectividade de trânsito do ExpressRoute para ExpressRoute por meio de um dispositivo de segurança implantado no hub.

ExpressRoute criptografado

Para usar o ExpressRoute Criptografado (túnel VPN site a site em execução em um circuito do ExpressRoute) com políticas de roteamento privado de intenção de roteamento, configure uma regra de firewall para permitir o tráfego entre os endereços IP privados do túnel do Gateway de VPN site a site do WAN Virtual (origem) e o dispositivo VPN local (destino). Para clientes que estão usando a inspeção de pacotes profundos no dispositivo Firewall, é recomendável excluir o tráfego entre esses IPs privados da inspeção de pacotes profundos.

Você pode obter os endereços IP privados do túnel do Gateway de VPN site a site do WAN Virtual baixando a configuração de VPN e exibindovpnSiteConnections -> gatewayConfiguration -> IPAddresses. Os endereços IP listados no campo IPAddresses são os endereços IP privados atribuídos a cada instância da Gateway de VPN site a site usada para encerrar túneis VPN no ExpressRoute. No exemplo abaixo, os IPs de túnel no Gateway são 192.168.1.4 e 192.168.1.5.

 "vpnSiteConnections": [
      {
        "hubConfiguration": {
          "AddressSpace": "192.168.1.0/24",
          "Region": "South Central US",
          "ConnectedSubnets": [
            "172.16.1.0/24",
            "172.16.2.0/24",
            "172.16.3.0/24",
            "192.168.50.0/24",
            "192.168.0.0/24"
          ]
        },
        "gatewayConfiguration": {
          "IpAddresses": {
            "Instance0": "192.168.1.4",
            "Instance1": "192.168.1.5"
          },
          "BgpSetting": {
            "Asn": 65515,
            "BgpPeeringAddresses": {
              "Instance0": "192.168.1.15",
              "Instance1": "192.168.1.12"
            },
            "CustomBgpPeeringAddresses": {
              "Instance0": [
                "169.254.21.1"
              ],
              "Instance1": [
                "169.254.21.2"
              ]
            },
            "PeerWeight": 0
          }
        }

Os endereços IP privados que os dispositivos locais usam para encerramento de VPN são os endereços IP especificados como parte da conexão de link do site VPN.

Usando a configuração de VPN de exemplo e o site VPN acima, crie regras de firewall para permitir o tráfego a seguir. Os IPs do Gateway de VPN devem ser o IP de origem e o dispositivo VPN local deve ser o IP de destino nas regras configuradas.

Parâmetro de Regra	Valor
IP de origem	192.168.1.4 e 192.168.1.5
Porta de origem	*
IP de destino	10.100.0.4
Porta de destino	*
Protocolo	ANY

Desempenho do ExpressRoute Criptografado

Configurar políticas de roteamento privado com o ExpressRoute Criptografado roteia pacotes VPN ESP por meio do dispositivo de segurança do próximo salto implantado no hub. Como resultado, você pode esperar a taxa de transferência máxima de túnel VPN do ExpressRoute Criptografado de 1 Gbps em ambas as direções (entrada do local e saída do Azure). Para obter a taxa de transferência máxima do túnel VPN, considere as seguintes otimizações de implantação:

Implante o Firewall do Azure Premium em vez do Firewall do Azure Standard ou do Firewall do Azure Básico.
Verifique se o Firewall do Azure processa a regra que permite o tráfego entre os pontos de extremidade do túnel VPN (192.168.1.4 e 192.168.1.5 no exemplo acima) primeiro, fazendo com que a regra tenha a prioridade mais alta em sua política de Firewall do Azure. Para obter mais informações sobre a lógica de processamento de regras do Firewall do Azure, consulte Lógica de processamento de regras do Firewall do Azure.
Desative o pacote profundo para o tráfego entre os pontos de extremidade do túnel VPN. Para obter informações sobre como configurar Firewall do Azure para excluir o tráfego da inspeção de pacotes profundos, consulte a documentação da lista de bypass do IDPS.
Configure dispositivos VPN para usar GCMAES256 para Criptografia E Integridade IPSEC para maximizar o desempenho.

Roteamento direto para instâncias NVA para conectividade de função dupla e NVAs de firewall

Observação

O roteamento direto para a NVA de função dupla usada com políticas de roteamento privado na WAN Virtual só se aplica ao tráfego entre redes virtuais e rotas aprendidas via BGP a partir da NVA implantada no hub de WAN Virtual. A conectividade de trânsito do ExpressRoute e VPN para o local conectado à NVA não é roteada diretamente para instâncias NVA e, em vez disso, é roteada por meio do balanceador de carga da NVA de função dupla.

Determinados Dispositivos Virtuais de Rede podem ter tanto funcionalidades de conectividade (SD-WAN) quanto de segurança (NGFW) no mesmo dispositivo. Essas NVAs são consideradas NVAs de função dupla. Verifique se a NVA é ou não NVA de função dupla em parceiros de NVA.

Quando as políticas de roteamento privado são configuradas para NVAs de função dupla, a WAN Virtual anuncia automaticamente as rotas aprendidas com o dispositivo NVA do Hub de WAN Virtual para redes virtuais diretamente conectadas (locais), bem como para outros Hubs Virtuais na WAN Virtual com o próximo salto como a instância de NVA em oposição às NVAs de balanceador de carga interno.

Para configurações de NVA ativo-passivo em que apenas uma instância das NVAs está anunciando uma rota para um prefixo específico para WAN Virtual (ou o comprimento AS-PATH das rotas aprendidas com uma das instâncias é sempre a mais curta), a WAN Virtual garante que o tráfego de saída de uma Rede Virtual do Azure seja sempre roteado para a instância de NVA ativa (ou preferencial).

Para configurações de NVA do tipo ativo-ativo (várias instâncias de NVA anunciam o mesmo prefixo com o mesmo comprimento de AS-PATH), o Azure executa automaticamente o ECMP para rotear o tráfego do Azure para o local. A plataforma de rede definida pelo software do Azure não garante simetria no nível do fluxo, o que significa que o fluxo de entrada para o Azure e o fluxo de saída do Azure podem chegar a instâncias diferentes da NVA. Isso resulta em roteamento assimétrico, que é descartado pela inspeção de firewall com estado. Portanto, não é recomendável usar padrões de conectividade ativo-ativo em que uma NVA esteja se comportando como uma NVA de função dupla, a menos que a NVA possa dar suporte ao encaminhamento assimétrico ou à sincronização/compartilhamento de sessão. Para obter mais informações sobre se a NVA dá suporte ao encaminhamento assimétrico ou ao compartilhamento/sincronização de estado de sessão, entre em contato com seu provedor de NVA.

Como configurar a intenção de roteamento por meio do portal do Azure

A intenção de roteamento e as políticas de roteamento podem ser configuradas por meio do portal do Azure usando o Gerenciador de Firewall do Azure ou o portal de WAN Virtual. O portal do Gerenciador de Firewall do Azure permite que você configure políticas de roteamento com o recurso Firewall do Azure de próximo salto. O portal de WAN Virtual portal configurar políticas de roteamento com o recurso Firewall do Azure, Soluções de Virtualização de Rede de próximo salto implantadas dentro do Hub Virtual ou das soluções de SaaS.

Os clientes que usam o Firewall do Azure em um hub seguro de WAN Virtual tanto podem configurar o recurso "Habilitar inter-hub" do Gerenciador de Firewall do Azure como "Habilitado" para usar a intenção de roteamento quanto usar o portal de WAN Virtual para configurar o Firewall do Azure diretamente como o recurso de próximo salto para as políticas e intenções de roteamento. As configurações em ambas as experiências de portal são equivalentes; as alterações no Gerenciador de Firewall do Azure são refletidas automaticamente no portal de WAN Virtual e vice-versa.

Configurar políticas e intenção de roteamento por meio do Gerenciador de Firewall do Azure

As etapas a seguir descrevem como configurar as políticas de roteamento e intenção de roteamento no Hub Virtual usando o Gerenciador de Firewall do Azure. O Gerenciador de Firewall do Azure dá suporte apenas aos recursos do próximo salto do tipo Firewall do Azure.

Navegue até o Hub de WAN Virtual no qual você deseja configurar as Políticas de Roteamento.
Em Segurança, selecione Configurações de Hub Virtual Seguro e Gerenciar as configurações de roteamento e provedor de segurança para este Hub virtual seguro no Gerenciador de Firewall do Azure.
Selecione o hub no qual você deseja configurar as Políticas de Roteamento no menu.
Selecione Configuração de segurança em Configurações
Se quiser configurar uma Política de Roteamento de Tráfego de Internet, selecione Firewall do Azure ou o provedor de Segurança da Internet relevante na lista suspensa de Tráfego de Internet. Do contrário, selecione Nenhum
Se quiser configurar uma Política de Roteamento de Tráfego Privado (para tráfego de branch e de Rede Virtual) por meio do Firewall do Azure, selecione Firewall do Azure na lista suspensa de Tráfego Privado. Do contrário, selecione Ignorar Firewall do Azure.
Se você quiser configurar uma Política de Roteamento de Tráfego Privado e tiver branches ou redes virtuais que indicam prefixos não previstos em IANA e RFC1918, selecione Prefixos de Tráfego Privado e especifique os intervalos de prefixo fora de IANA e RFC1918 na caixa de texto que aparece. Selecione Concluído.
Selecione para Entre hubs a opção Habilitado. A habilitação dessa opção permite que suas Políticas de Roteamento sejam aplicadas à Intenção de Roteamento do Hub de WAN Virtual.
Selecione Salvar.
Repita as etapas 2 a 8 para outros Hubs de WAN Virtual Seguros nos quais você queira configurar Políticas de Roteamento.
Agora você está pronto para enviar o tráfego de teste. Confira se as Políticas de Firewall estão configuradas adequadamente para permitir/negar o tráfego com base nas configurações de segurança desejadas.

Configurar políticas e intenção de roteamento por meio do portal de WAN Virtual

As etapas a seguir descrevem como configurar as políticas de roteamento e intenção de roteamento no Hub Virtual usando o portal de WAN Virtual.

No link do portal personalizado fornecido no email de confirmação da Etapa 3 na seção Pré-requisitos, acesse o Hub de WAN Virtual no qual você deseja configurar as políticas de roteamento.
Em Roteamento, selecione Políticas de roteamento.
Se você quiser configurar uma Política de Roteamento de Tráfego Privado (para tráfego de branch e Rede Virtual), selecione Firewall do Azure, Solução de virtualização de rede ou soluções SaaS em Tráfego Privado. Em Recurso de Próximo Salto, selecione o recurso de próximo salto relevante.
Para configurar uma Política de Roteamento de Tráfego Privado e permitir que branches ou redes virtuais usem prefixos RFC1918 não IANA, selecione Prefixos adicionais e especifique os intervalos de prefixo RFC1918 não IANA na caixa de texto que aparece. Selecione Concluído. Adicione o mesmo prefixo à caixa de texto prefixo de Tráfego Privado em todos os Hubs Virtuais configurados com Políticas de Roteamento Privado para garantir que as rotas corretas sejam anunciadas para todos os hubs.
Se você quiser configurar uma Política de Roteamento de Tráfego de Internet, selecione Firewall do Azure, Solução de virtualização de rede ou solução SaaS. Em Recurso de Próximo Salto, selecione o recurso de próximo salto relevante.
Para aplicar sua configuração de políticas e de intenção de roteamento, clique em Salvar.
Repita com relação a todos os hubs para os quais você deseja configurar políticas de roteamento.
Agora você está pronto para enviar o tráfego de teste. Confira se as Políticas de Firewall estão configuradas adequadamente para permitir/negar o tráfego com base nas configurações de segurança desejadas.

Configurar a intenção de roteamento utilizando um modelo BICEP

Consulte o modelo BICEP para obter informações sobre o modelo e as etapas.

Solução de problemas

A seção a seguir descreve formas comuns de solucionar problemas ao configurar a intenção e as políticas de roteamento no Hub de WAN Virtual.

Rotas Efetivas

Observação

A obtenção das rotas efetivas aplicadas aos recursos de próximo salto da intenção de roteamento de WAN Virtual só tem suporte para o recurso de próximo salto especificado na política de roteamento privado. Se você estiver usando políticas de roteamento de Internet e privadas, verifique as rotas efetivas no recurso de próximo salto especificado na política de roteamento privado para ver os programas de WAN Virtual com rotas efetivas no recurso de próximo salto da política de roteamento da Internet. Se você estiver usando apenas políticas de roteamento da Internet, verifique as rotas efetivas em defaultRouteTable para exibir as rotas programadas no recurso de próximo salto da política de roteamento da Internet.

Quando as políticas de roteamento privado são configuradas no Hub Virtual, todo o tráfego entre redes virtuais e locais é inspecionado pelo Firewall do Azure, pela Solução de Virtualização de Rede ou SaaS no Hub Virtual.

Portanto, as rotas efetivas de defaultRouteTable mostram os prefixos agregados RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) com o próximo salto do Firewall do Azure ou da Solução de virtualização de rede. Isso reflete que todo o tráfego entre redes virtuais e branches é roteado para o Firewall do Azure, NVA ou solução SaaS no hub para inspeção.

Depois que o Firewall inspeciona o pacote (e o pacote é permitido por configuração de regra de firewall), WAN Virtual encaminha o pacote para seu destino final. Para ver quais rotas a WAN Virtual usa para encaminhar pacotes inspecionados, veja a tabela de rotas efetivas do Firewall ou da Solução de virtualização de rede.

A tabela de rotas efetivas do Firewall ajuda a restringir e isolar problemas na sua rede, como configurações incorretas ou problemas com determinados branches e Redes virtuais.

Solução de problemas de configuração

Se você estiver solucionando problemas de configuração, considere o seguinte:

Verifique se você não tem tabelas de rotas personalizadas ou rotas estáticas em defaultRouteTable com o próximo salto de Conexão de rede virtual.
- A opção de configurar a intenção de roteamento fica desabilitada no portal do Azure se a implantação não atender aos requisitos acima.
- Se você estiver usando a CLI, o PowerShell ou REST, a operação de criação da intenção de roteamento falhará. Exclua a intenção de roteamento com falha, remova as tabelas de rotas personalizadas e as rotas estáticas e tente criar novamente.
- Se você estiver usando o Gerenciador de Firewall do Azure, verifique se as rotas existentes em defaultRouteTable são nomeadas private_traffic, internet_traffic ou all_traffic. A opção de configurar a intenção (habilitar entre hubs) fica indisponível se as rotas forem nomeadas de forma diferente.
Depois de configurar a intenção de roteamento em um hub, verifique se todas as atualizações para conexões existentes ou novas conexões com o hub são criadas com os campos opcionais associados e propagados da tabela de rotas definidos como vazios. Definir as associações e propagações opcionais como vazias é feito automaticamente para todas as operações executadas por meio de portal do Azure.

Solucionar problemas de caminho de dados

Supondo que você já tenha consultado a seção Limitações Conhecidas, aqui estão algumas formas de solucionar problemas de datapath e conectividade:

Solução de problemas com rotas efetivas:
- Se as políticas de roteamento privado estiverem configuradas, você deve ver rotas com o Firewall do próximo salto nas rotas efetivas de defaultRouteTable para agregações RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) bem como quaisquer prefixos especificados na caixa de texto de tráfego privado. Verifique se todos os prefixos de Rede Virtual e locais são sub-redes dentro das rotas estáticas em defaultRouteTable. Se um local ou Rede Virtual estiver usando um espaço de endereço que não seja uma sub-rede dentro das rotas efetivas em defaultRouteTable, adicione o prefixo à caixa de texto de tráfego privado.
- Se houver Políticas de Roteamento de Tráfego de Internet configuradas, você deverá ver uma rota padrão (0.0.0.0/0) nas rotas efetivas de defaultRouteTable.
- Depois de verificar se as rotas efetivas de defaultRouteTable têm os prefixos corretos, veja as Rotas Efetivas da Solução de virtualização de rede ou Firewall do Azure. As rotas efetivas no Firewall mostram quais rotas a WAN Virtual selecionou e determina para quais destinos o Firewall pode encaminhar pacotes. Descobrir quais prefixos estão ausentes ou em um estado incorreto ajuda a restringir problemas de caminho de dados e apontar para a conexão VPN, ExpressRoute, NVA ou BGP correta para solucionar problemas.
Solução de problemas específica do cenário:
- Se você tiver um hub desprotegido (hub sem Firewall do Azure ou NVA) em sua WAN virtual, verifique se as conexões com o hub desprotegido estão se propagando para a defaultRouteTable dos hubs com a intenção de roteamento configurada. Se as propagações não forem definidas como defaultRouteTable, as conexões com o hub seguro não poderão enviar pacotes para o hub não seguro.
- Se você tiver políticas de roteamento da Internet configuradas, verifique se a configuração “Propagar rota padrão” ou “Habilitar segurança da Internet” está definida como “true” para todas as conexões que devem aprender a rota padrão 0.0.0.0/0. As conexões em que essa configuração é definida como “false” não aprenderão a rota 0.0.0.0/0, mesmo se as Políticas de roteamento da Internet estiverem configuradas.
- Se você estiver usando Pontos de Extremidade Privados implantados em Redes Virtuais conectadas ao Hub Virtual, o tráfego do local destinado a Pontos de Extremidade Privados implantados em Redes Virtuais conectadas ao hub de WAN Virtual por padrão ignora a intenção de roteamento do próximo salto do Firewall do Azure, NVA ou SaaS. No entanto, isso resulta em um roteamento assimétrico (que pode levar à perda de conectividade entre os pontos de extremidade privados e locais), pois os Pontos de Extremidade Privados em Redes Virtuais Spoke encaminham o tráfego local para o Firewall. Para garantir a simetria do roteamento, ative Políticas de rede da tabela de roteamento para pontos de extremidade privados nas sub-redes em que os pontos de extremidade privados estão implantados. A configuração de rotas /32 correspondentes aos endereços IP privados do Ponto de Extremidade Privado na caixa de texto Tráfego Privado não garantirá a simetria do tráfego quando as políticas de roteamento privado forem configuradas no hub.
- Se você estiver usando o ExpressRoute Criptografado com Políticas de Roteamento Privado, verifique se o dispositivo firewall tem uma regra configurada para permitir o tráfego entre o ponto de extremidade do túnel de IP privado do Gateway de VPN site a site do WAN Virtual e dispositivo VPN local. Os pacotes ESP (externo criptografado) devem criar log nos logs do Firewall do Azure. Para obter mais informações sobre o ExpressRoute Criptografado com intenção de roteamento, consulte a documentação do ExpressRoute Criptografado.
- Se você estiver usando tabelas de rota definidas pelo usuário em suas redes virtuais spoke, verifique se a opção “Propagar rotas de gateway” está definida como “Sim” na tabela de rotas. A opção “Propagar rotas de gateway” deve ser habilitada para que a WAN Virtual possa anunciar rotas para cargas de trabalho em redes virtuais spoke conectadas à WAN Virtual. Para obter mais informações sobre configurações de tabela de rotas definida pelo usuário, consulte Documentação de rotas definidas pelo usuário da rede virtual.

Solução de problemas de roteamento do Firewall do Azure

Verifique se o estado de provisionamento do Firewall do Azure é bem-sucedido antes de tentar configurar a intenção de roteamento.
Se você estiver usando prefixos que não são do IANA RFC1918 nos branches/Redes Virtuais, especifique esses prefixos na caixa de texto "Prefixos Privados". Os "Prefixos Privados" configurados não se propagam automaticamente para outros hubs na WAN Virtual que foi configurada com a intenção de roteamento. Para garantir a conectividade, adicione esses prefixos à caixa de texto "Prefixos Privados" em cada hub que tenha a intenção de roteamento.
Se você tiver especificado endereços fora do intervalo RFC1918 como parte da caixa de texto Prefixos de Tráfego Privado no Gerenciador de Firewall, talvez precise configurar políticas SNAT no Firewall para desabilitar o SNAT em tráfego privado fora do intervalo RFC1918. Para obter mais informações, consulte Intervalos SNAT do Firewall do Azure.
Configure e exiba os logs do Firewall do Azure para ajudar a solucionar problemas e analisar seu tráfego de rede. Para obter mais informações sobre como configurar o monitoramento para o Firewall do Azure, confira o Diagnóstico do Firewall do Azure. Para obter uma visão geral dos diferentes tipos de logs de firewall, consulte Logs e métricas do Firewall do Azure.
Para obter mais informações sobre o Firewall do Azure, examine a Documentação do Firewall do Azure.

Solução de problemas de Soluções de Virtualização de Rede

Verifique se o estado de provisionamento da Solução de virtualização de rede é bem-sucedido antes de tentar configurar a intenção de roteamento.
Se você estiver usando prefixos que não são do IANA RFC1918 no local conectado ou Redes Virtuais, especifique esses prefixos na caixa de texto "Prefixos Privados". Os "Prefixos Privados" configurados não se propagam automaticamente para outros hubs na WAN Virtual que foi configurada com a intenção de roteamento. Para garantir a conectividade, adicione esses prefixos à caixa de texto "Prefixos Privados" em cada hub que tenha a intenção de roteamento.
Se você tiver especificado endereços fora de RFC1918 como parte da caixa de texto Prefixos de Tráfego Privado, talvez precise configurar políticas SNAT no NVA para desabilitar o SNAT em determinado tráfego privado fora de RFC1918.
Verifique os logs do Firewall de NVA para ver se o tráfego está sendo removido ou negado pelas regras de Firewall.
Entre em contato com seu provedor de NVA para obter mais suporte e diretrizes sobre solução de problemas.

Solucionar problemas de software como serviço

Verifique se o estado de provisionamento da solução SaaS é bem-sucedido antes de tentar configurar a intenção de roteamento.
Para obter mais dicas de solução de problemas, consulte a seção de solução de problemas na documentação de WAN Virtual ou consulte a documentação do Cloud NGFW da Palo Alto Networks.

Próximas etapas

Para obter mais informações sobre o roteamento do hub virtual, veja Sobre o roteamento do hub virtual. Para obter mais informações sobre a WAN Virtual, veja as Perguntas frequentes.

Compartilhar via

Como configurar políticas de roteamento e de intenção de roteamento do Hub de WAN Virtual

Tela de fundo

Casos de uso

Todos os Hubs de WAN Virtual são seguros (implantados com o Firewall do Azure, NVA ou solução SaaS)

Implantar Hubs de WAN Virtual seguros e regulares

Limitações conhecidas

Limites de Espaço de Endereço da Rede Virtual

Considerações

Pré-requisitos

Estratégia de reversão

Rotas estáticas em defaultRouteTable

Gerenciador de Firewall do Azure e Portal do Hub de WAN Virtual

Outros métodos (PowerShell, REST, CLI)

Anúncio de prefixo para o local

Política de roteamento da Internet

Política de roteamento privado

Cenários de roteamento de chaves

A conectividade de trânsito entre circuitos do ExpressRoute com intenção de roteamento

Considerações sobre o roteamento com o ExpressRoute

ExpressRoute criptografado

Desempenho do ExpressRoute Criptografado

Roteamento direto para instâncias NVA para conectividade de função dupla e NVAs de firewall

Como configurar a intenção de roteamento por meio do portal do Azure

Configurar políticas e intenção de roteamento por meio do Gerenciador de Firewall do Azure

Configurar políticas e intenção de roteamento por meio do portal de WAN Virtual

Configurar a intenção de roteamento utilizando um modelo BICEP

Solução de problemas

Rotas Efetivas

Solução de problemas de configuração

Solucionar problemas de caminho de dados

Solução de problemas de roteamento do Firewall do Azure

Solução de problemas de Soluções de Virtualização de Rede

Solucionar problemas de software como serviço

Próximas etapas

Comentários

Recursos adicionais