Como configurar políticas de roteamento e de intenção de roteamento do Hub de WAN Virtual
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, Solução de virtualização de rede de firewall de última geração (NGFW-NVA) ou solução de software como serviço (SaaS) 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 Intenção de roteamento está atualmente disponível no Azure público. O Microsoft Azure operado pela 21Vianet e Azure Governamental estão atualmente em roteiro.
- 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.
- 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.
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.
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.
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
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 o 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.
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
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.
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.