Como configurar políticas de encaminhamento e intenções de encaminhamento do Hub da WAN Virtual
A intenção de roteamento do Hub 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 o Firewall do Azure, Dispositivos Virtuais de Rede ou soluções de software como serviço (SaaS) implantadas no hub WAN Virtual.
Fundo
As Políticas de Intenção de Roteamento e Roteamento permitem configurar o hub WAN Virtual para encaminhar tráfego vinculado à Internet e Privado (VPN Ponto a Site, VPN Site a Site, Rota Expressa, Rede Virtual e Dispositivo Virtual de Rede) para um Firewall do Azure, Dispositivo Virtual de Rede de Firewall de Próxima Geração (NGFW-NVA) ou solução de software como serviço (SaaS) de segurança implantada no hub virtual.
Existem dois tipos de Políticas de Roteamento: Tráfego da Internet e Políticas de Roteamento de Tráfego Privado. Cada Hub 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 Next Hop. Enquanto o Tráfego Privado inclui prefixos de endereço de ramificação e 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 da Internet: Quando uma Política de Roteamento de Tráfego da Internet é configurada em um hub WAN Virtual, todas as ramificações (VPN de Usuário Remoto (VPN Ponto a Site), VPN Site a Site e Rota Expressa) e as conexões de Rede Virtual para esse Hub WAN Virtual encaminham o tráfego vinculado à Internet para o Firewall do Azure, provedor de Segurança de Terceiros, Dispositivo Virtual de Rede ou solução SaaS especificada como parte da Política de Roteamento.
Em outras palavras, quando uma Política de Roteamento de Tráfego da Internet é configurada em um hub de WAN Virtual, a WAN Virtual anuncia uma rota padrão (0.0.0.0/0) para todos os raios, Gateways e Dispositivos Virtuais de Rede (implantados no hub ou falado).
Política de Roteamento de Tráfego Privado: Quando uma Política de Roteamento de Tráfego Privado é configurada em um hub WAN Virtual, todo o tráfego de ramificação e Rede Virtual dentro e fora do Hub WAN Virtual, incluindo o tráfego entre hubs, é encaminhado para o recurso de solução Firewall do Azure Next Hop, Dispositivo Virtual de Rede ou SaaS.
Em outras palavras, quando uma Política de Roteamento de Tráfego Privado é configurada no Hub WAN Virtual, todo o tráfego de ramificação para ramificação, ramificação para rede virtual, rede virtual para ramificação e entre hubs é enviado por meio do Firewall do Azure, do Dispositivo Virtual de Rede ou da solução SaaS implantada no Hub WAN Virtual.
Casos de Utilização
A seção a seguir descreve dois cenários comuns em que as Políticas de Roteamento são aplicadas a hubs WAN virtuais protegidos.
Todos os Hubs WAN Virtuais são protegidos (implantados com o Firewall do Azure, NVA ou solução SaaS)
Nesse cenário, todos os hubs de WAN Virtual são implantados com uma solução de Firewall do Azure, NVA ou SaaS. Nesse cenário, você pode configurar uma diretiva de roteamento de tráfego da Internet, uma diretiva de roteamento de tráfego privado ou ambos em cada hub WAN virtual.
Considere a seguinte configuração, onde o Hub 1 e o Hub 2 têm Políticas de Roteamento para Tráfego Privado e da Internet.
Configuração do Hub 1:
- Política de Tráfego Privado com a solução Next Hop Hub 1 Azure Firewall, NVA ou SaaS
- Política de tráfego da Internet com a solução Next Hop Hub 1 Azure Firewall, NVA ou SaaS
Configuração do Hub 2:
- Política de Tráfego Privado com a solução Next Hop Hub 2 Azure Firewall, NVA ou SaaS
- Política de tráfego da Internet com a solução Next Hop Hub 2 Azure Firewall, NVA ou SaaS
A seguir estão os fluxos de tráfego que resultam de tal configuração.
Nota
O tráfego da Internet deve sair pela solução de segurança local no hub, pois a rota padrão (0.0.0.0/0) não se propaga entre hubs.
| De | Para | Hub 1 VNets | Filiais do Hub 1 | Redes virtuais do Hub 2 | Filiais do Hub 2 | Internet |
|---|---|---|---|---|---|---|
| Hub 1 VNets | → | Hub 1 AzFW ou NVA | Hub 1 AzFW ou NVA | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 1 AzFW, NVA ou SaaS |
| Filiais do Hub 1 | → | Hub 1 AzFW, NVA ou SaaS | Hub 1 AzFW, NVA ou SaaS | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 1 AzFW, NVA ou SaaS |
| Redes virtuais do Hub 2 | → | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS |
| Filiais do Hub 2 | → | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 1 e 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2AzFW, NVA ou SaaS |
Implantando Hubs WAN Virtuais seguros e regulares
Nesse cenário, nem todos os hubs na WAN são Hubs WAN Virtuais Seguros (hubs que têm uma solução de segurança implantada neles).
Considere a seguinte configuração, onde o Hub 1 (Normal) e o Hub 2 (Seguro) são implantados em uma WAN Virtual. O Hub 2 tem Políticas de Roteamento para Tráfego Privado e da Internet.
Configuração do Hub 1:
- N/D (não é possível configurar Políticas de Roteamento se o hub não for implantado com a solução Firewall do Azure, NVA ou SaaS)
Configuração do Hub 2:
- Política de Tráfego Privado com a solução Next Hop Hub 2 Azure Firewall, NVA ou SaaS.
- Política de tráfego da Internet com a solução Next Hop Hub 2 Azure Firewall, NVA ou SaaS.
A seguir estão os fluxos de tráfego que resultam de tal configuração. As filiais e 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 | Hub 1 VNets | Filiais do Hub 1 | Redes virtuais do Hub 2 | Filiais do Hub 2 | Internet |
|---|---|---|---|---|---|---|
| Hub 1 VNets | → | Direct | Direct | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | - |
| Filiais do Hub 1 | → | Direct | Direct | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | - |
| Redes virtuais do Hub 2 | → | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS |
| Filiais do Hub 2 | → | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 AzFW, NVA ou SaaS | Hub 2 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 o Azure Government estão atualmente no roteiro.
- A intenção de roteamento simplifica o roteamento gerenciando associações e propagações de tabelas de rotas para todas as conexões (Rede Virtual, VPN Site a Site, VPN Ponto a Site e Rota Expressa). WANs virtuais com tabelas de rotas personalizadas e políticas personalizadas, portanto, não podem ser usadas com as construções de intenção de roteamento.
- A Rota Expressa Criptografada (túneis VPN site a site executados em circuitos de Rota Expressa) é suportada em hubs onde 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 do Gateway VPN site a site e IP privado do dispositivo VPN local). Para obter mais informações sobre as configurações necessárias, consulte Rota expressa criptografada com intenção de roteamento.
- Os seguintes casos de uso de conectividade não são suportados 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 um NVA de conectividade SD-WAN e uma solução de Firewall NVA ou SaaS separada no mesmo hub de WAN Virtual está atualmente no roteiro. Depois que a intenção de roteamento é configurada com a solução SaaS do próximo salto ou o Firewall NVA, a conectividade entre o SD-WAN NVA e o Azure é afetada. Em vez disso, implante a solução SD-WAN NVA e Firewall NVA ou SaaS em diferentes Hubs Virtuais. Como alternativa, você também pode implantar o SD-WAN NVA em uma rede virtual spoke conectada ao hub e aproveitar o recurso de emparelhamento BGP do hub virtual.
- Os NVAs (Network Virtual Appliances) só podem ser especificados como o recurso do próximo salto para intenção de roteamento se forem Firewall de Próxima Geração ou Firewall de Próxima Geração de função dupla e NVAs SD-WAN. Atualmente, checkpoint, fortinet-ngfw e fortinet-ngfw-and-sdwan são os únicos NVAs elegíveis para serem configurados para serem o próximo salto para intenção de roteamento. Se você tentar especificar outro NVA, a criação da intenção de roteamento falhará. Você pode verificar o tipo de NVA navegando até o seu Hub Virtual -> Network Virtual Appliances e, em seguida, olhando para o campo Fornecedor . Palo Alto Networks Cloud NGFW também é suportado como o próximo salto para Intenção de Roteamento, mas é considerado um próximo salto do tipo solução SaaS.
- Os usuários com intenção de roteamento que desejam conectar vários circuitos de Rota Expressa à 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. Consulte a ativação da conectividade entre circuitos de Rota Expressa para obter mais informações.
Considerações
Os clientes que estão atualmente usando o Firewall do Azure no hub WAN Virtual sem Intenção de Roteamento podem habilitar a intenção de roteamento usando o Gerenciador de Firewall do Azure, o portal de roteamento do hub WAN Virtual ou por meio de outras ferramentas de gerenciamento do Azure (PowerShell, CLI, REST API).
Antes de habilitar a intenção de roteamento, considere o seguinte:
- A intenção de roteamento só pode ser configurada em hubs onde não há tabelas de rotas personalizadas e rotas estáticas no defaultRouteTable com conexão de rede virtual do próximo salto. Para obter mais informações, consulte os pré-requisitos.
- Salve uma cópia de 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 no defaultRouteTable. Devido às otimizações do portal do Azure, o estado do defaultRouteTable após a intenção de roteamento ser configurado pode ser diferente se você configurar a intenção de roteamento usando REST, CLI ou PowerShell. Para obter mais informações, consulte Rotas estáticas.
- A habilitação da intenção de roteamento afeta o anúncio de prefixos para o local. Consulte os anúncios de prefixo para obter mais informações.
- Você pode abrir um caso de suporte para habilitar a conectividade entre circuitos de Rota Expressa por meio de um dispositivo de Firewall no hub. Habilitar esse padrão de conectividade modifica os prefixos anunciados para circuitos de Rota Expressa. Consulte Sobre o ExpressRoute para obter mais informações.
- A intenção de roteamento é o único mecanismo na WAN Virtual para permitir 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 exige 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 WAN virtuais.
Pré-requisitos
Para habilitar a intenção e as políticas de roteamento, seu 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 que existem são noneRouteTable e defaultRouteTable.
- Não é possível ter rotas estáticas com a Conexão de Rede Virtual do próximo salto. Você pode ter rotas estáticas no defaultRouteTable ter o próximo salto do Firewall do Azure.
A opção para configurar a intenção de roteamento está esmaecida para hubs que não atendem aos requisitos acima.
Usar a intenção de roteamento (habilitar a opção interhub) 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 no defaultRouteTable devem seguir essa convenção.
Estratégia de reversão
Nota
Quando a configuração de intenção de roteamento é completamente removida de um hub, todas as conexões com o hub são definidas para se propagar para o rótulo padrão (que se aplica a 'todas' defaultRouteTables na WAN Virtual). Como resultado, se você estiver considerando implementar a intenção de roteamento na WAN virtual, deverá salvar uma cópia de suas configurações existentes (gateways, conexões, tabelas de rotas) para aplicar se desejar reverter para a configuração original. O sistema não restaura automaticamente a configuração anterior.
A intenção de roteamento simplifica o roteamento e a configuração gerenciando associações de rotas e propagações 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 associada | Tabelas 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 rotas estáticas no defaultRouteTable quando a intenção de roteamento está habilitada em um hub. As modificações que a intenção de roteamento faz no defaultRouteTable são irreversíveis.
Se você remover a intenção de roteamento, terá que restaurar manualmente a configuração anterior. Portanto, recomendamos salvar um instantâneo de sua configuração antes de habilitar a intenção de roteamento.
Gerenciador de Firewall do Azure e Portal de Hub WAN Virtual
Quando a intenção de roteamento está habilitada no hub, as rotas estáticas correspondentes às políticas de roteamento configuradas são criadas automaticamente no defaultRouteTable. Estas 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 | Azure Firewall |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure Firewall |
Nota
Todas as rotas estáticas no defaultRouteTable contendo prefixos que não correspondem exatamente a 0.0.0.0/0 ou às RFC1918 super-redes (10.0.0.0/8, 192.168.0.0/16 e 172.16.0.0/12) são automaticamente consolidadas em uma única rota estática, chamada private_traffic. Os prefixos em defaultRouteTable que correspondem RFC1918 supernets ou 0.0.0.0/0 são sempre removidos automaticamente quando 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 | Azure Firewall |
| to_internet | 0.0.0.0/0 | Azure Firewall |
| additional_private | 10.0.0.0/8, 50.0.0.0/24 | Azure Firewall |
Habilitar a intenção de roteamento nesse hub resultaria no seguinte estado final do defaultRouteTable. Todos os prefixos que não são RFC1918 ou 0.0.0.0/0 são consolidados em uma única rota chamada 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 | Azure Firewall |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure Firewall |
| private_traffic | 40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24 | Azure Firewall |
Outros métodos (PowerShell, REST, CLI)
A criação de intenção de roteamento usando métodos que não sejam do Portal cria automaticamente as rotas de política correspondentes no defaultRouteTable e também remove quaisquer prefixos em rotas estáticas que correspondam exatamente a 0.0.0.0/0 ou RFC1918 supernets (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 | Azure Firewall |
| firewall_route_2 | 192.168.0.0/16, 10.0.0.0/24 | Azure Firewall |
| firewall_route_3 | 40.0.0.0/24 | Azure Firewall |
| to_internet | 0.0.0.0/0 | Azure Firewall |
A tabela a seguir representa o estado final de defaultRouteTable após a criação da intenção de roteamento ser bem-sucedida. Observe que firewall_route_1 e to_internet foi removido automaticamente, pois o único prefixo nessas rotas era 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 | Azure Firewall |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure Firewall |
| firewall_route_2 | 10.0.0.0/24 | Azure Firewall |
| firewall_route_3 | 40.0.0.0/24 | Azure Firewall |
Anúncio de prefixo para 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 encaminhamento da Internet
Nota
A rota padrão 0.0.0.0/0 não é anunciada em hubs virtuais.
Se você habilitar as 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 (Rota Expressa de Rede Virtual, VPN Site a Site, VPN Ponto a Site, NVA no hub e conexões BGP) onde a rota padrão Propagar ou Habilitar o sinalizador de segurança da Internet está 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 locais da seguinte maneira:
- Rotas correspondentes a prefixos aprendidos de redes virtuais do hub local, ExpressRoute, VPN site a site, VPN ponto a site, conexões NVA-in-the-hub ou BGP conectadas ao hub atual.
- Rotas correspondentes a prefixos aprendidos de redes virtuais de hub remoto, Rota Expressa, VPN site a site, VPN ponto a site, conexões NVA no hub ou BGP onde as políticas de Roteamento Privado são configuradas.
- Rotas correspondentes a prefixos aprendidos de redes virtuais de hub remoto, Rota Expressa, VPN site a site, VPN ponto a site, conexões NVA-no-hub e BGP onde a intenção de roteamento não está configurada e as conexões remotas se propagam para a defaultRouteTable do hub local.
- Os prefixos aprendidos em um circuito de Rota Expressa não são anunciados para outros circuitos de Rota Expressa, a menos que o Alcance Global esteja habilitado. Se você quiser habilitar o trânsito da Rota Expressa para a Rota Expressa por meio de uma solução de segurança implantada no hub, abra um caso de suporte. Para obter mais informações, consulte Habilitando a conectividade entre circuitos de Rota Expressa.
Conectividade de trânsito entre circuitos de Rota Expressa com intenção de roteamento
A conectividade de trânsito entre circuitos de Rota Expressa na WAN Virtual é 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 oferecer suporte à conectividade de trânsito entre dois circuitos de Rota Expressa.
Nota
Para habilitar a conectividade de trânsito da Rota Expressa para a Rota Expressa por meio de um dispositivo de Firewall no hub com políticas de roteamento privado, abra um caso de suporte com o Suporte da Microsoft. Esta opção não é compatível com o Global Reach e requer que o Global Reach seja desativado para garantir o roteamento de trânsito adequado entre todos os circuitos de Rota Expressa conectados à WAN Virtual.
- Alcance Global da Rota Expressa: O Alcance Global da Rota Expressa permite que dois circuitos habilitados para Alcance Global enviem tráfego entre si diretamente sem transitar pelo Hub Virtual.
- Política de roteamento privado de intenção de roteamento: a configuração de políticas de roteamento privado permite que dois circuitos de Rota Expressa enviem tráfego um para o outro por meio de uma solução de segurança implantada no hub.
A conectividade entre circuitos de Rota Expressa por meio de um dispositivo de Firewall no hub com política de roteamento privado de intenção de roteamento está disponível nas seguintes configurações:
- Ambos os circuitos da Rota Expressa estão conectados ao mesmo hub e uma política de roteamento privada é configurada nesse hub.
- Os circuitos de Rota Expressa são conectados a hubs diferentes e uma política de roteamento privada é configurada em ambos os hubs. Portanto, ambos os hubs devem ter uma solução de segurança implantada.
Considerações sobre roteamento com a Rota Expressa
Nota
As considerações de roteamento abaixo se aplicam a todos os hubs virtuais na(s) assinatura(s) habilitada(s) pelo Suporte da Microsoft para permitir a conectividade da Rota Expressa com a Rota Expressa por meio de um dispositivo de segurança no hub.
Depois que a conectividade de trânsito entre circuitos de Rota Expressa usando um dispositivo de firewall implantado no Hub Virtual estiver habilitada, você poderá esperar as seguintes alterações no comportamento de como as rotas são anunciadas para a Rota Expressa local:
- A WAN virtual anuncia automaticamente RFC1918 prefixos agregados (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) para o local conectado à Rota Expressa. Estas rotas agregadas são anunciadas para além das rotas descritas na secção anterior.
- A WAN virtual anuncia automaticamente todas as rotas estáticas no circuito defaultRouteTable para ExpressRoute conectado localmente. 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 à Rota Expressa não pode anunciar intervalos de endereços exatos para RFC1918 intervalos de endereços agregados (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Certifique-se de que está a publicitar 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 da Rota Expressa estiver anunciando um prefixo não RFC1918 para o Azure, verifique se os intervalos de endereços colocados na caixa de texto Prefixos de Tráfego Privado são menos específicos do que as rotas anunciadas pela Rota Expressa. Por exemplo, se o Circuito de Rota Expressa estiver anunciando 40.0.0.0/24 localmente, 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 roteamento para outros locais (VPN site a site, VPN ponto a site, NVA) não são afetados ao habilitar a conectividade de trânsito da Rota Expressa para a Rota Expressa por meio de um dispositivo de segurança implantado no hub.
Rota Expressa Criptografada
Para usar a Rota Expressa Criptografada (túnel VPN site a site executado em um circuito de Rota Expressa) 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 VPN Site a Site da WAN Virtual (origem) e o dispositivo VPN local (destino). Para clientes que estão usando inspeção profunda de pacotes no dispositivo de firewall, é recomendável excluir o tráfego entre esses IPs privados da inspeção profunda de pacotes.
Você pode obter os endereços IP privados do túnel do Gateway VPN Site-to-site da WAN Virtual baixando a configuração VPN e visualizando vpnSiteConnections -> gatewayConfiguration -> IPAddresses. Os endereços IP listados no campo IPAddresses são os endereços IP privados atribuídos a cada instância do Gateway VPN Site a Site que é usado para encerrar túneis VPN pela Rota Expressa. 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 terminação VPN são os endereços IP especificados como parte da conexão de link de site VPN.
Usando a configuração VPN de exemplo e o site VPN de cima, crie regras de firewall para permitir o tráfego a seguir. Os IPs do Gateway VPN devem ser o IP de origem e o dispositivo VPN local deve ser o IP de destino nas regras configuradas.
| Parâmetro da regra | Value |
|---|---|
| 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 | QUALQUER |
Desempenho
A configuração de políticas de roteamento privado com Rota Expressa Criptografada roteia pacotes ESP VPN através do dispositivo de segurança do próximo salto implantado no hub. Como resultado, você pode esperar uma taxa de transferência máxima do túnel VPN da Rota Expressa Criptografada de 1 Gbps em ambas as direções (entrada do local e saída do Azure). Para atingir 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 Basic.
- 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 profunda de pacotes, consulte a documentação da lista de desvio do IDPS.
- Configure dispositivos VPN para usar GCMAES256 para criptografia e integridade IPSEC para maximizar o desempenho.
Configurando 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 WAN Virtual. O portal do Azure Firewall Manager permite configurar políticas de roteamento com o recurso de próximo salto do Firewall do Azure. O portal WAN virtual permite configurar políticas de roteamento com o recurso de próximo salto Firewall do Azure, Dispositivos Virtuais de Rede implantados no hub Virtual ou soluções SaaS.
Os clientes que usam o Firewall do Azure no hub protegido da WAN Virtual podem definir a configuração 'Habilitar interhub' do Gerenciador de Firewall do Azure como 'Habilitado' para usar a intenção de roteamento ou usar o portal da WAN Virtual para configurar diretamente o Firewall do Azure como o recurso do próximo salto para intenção e políticas de roteamento. As configurações em qualquer experiência de portal são equivalentes e as alterações no Gerenciador de Firewall do Azure são refletidas automaticamente no portal WAN Virtual e vice-versa.
Configurar a intenção e as políticas de roteamento por meio do Gerenciador de Firewall do Azure
As etapas a seguir descrevem como configurar a intenção de roteamento e as políticas de roteamento em seu Hub Virtual usando o Gerenciador de Firewall do Azure. O Azure Firewall Manager suporta apenas recursos de próximo salto do tipo Firewall do Azure.
Navegue até ao Hub de WAN Virtual no qual pretende configurar as Políticas de Itinerário.
Em Segurança, selecione Configurações de hub virtual seguro e, em seguida, Gerenciar configurações de roteamento e provedor de segurança para este hub virtual protegido no Gerenciador de Firewall do Azure.
Selecione o Hub no qual pretende configurar as suas Políticas de Encaminhamento no menu.
Selecione Configuração de segurança em Configurações
Se desejar configurar uma Política de Roteamento de Tráfego da Internet, selecione Firewall do Azure ou o provedor de Segurança da Internet relevante na lista suspensa de Tráfego da Internet. Caso contrário, selecione Nenhum
Se você quiser configurar uma Política de Roteamento de Tráfego Privado (para tráfego de filial e Rede Virtual) por meio do Firewall do Azure, selecione Firewall do Azure na lista suspensa para Tráfego Privado. Caso contrário, selecione Ignorar Firewall do Azure.
Se você quiser configurar uma Política de Roteamento de Tráfego Privado e tiver ramificações ou redes virtuais anunciando Prefixos de RFC1918 não IANA, selecione Prefixos de Tráfego Privado e especifique os intervalos de prefixos de RFC1918 não IANA na caixa de texto exibida. Selecionar Concluído.
Selecione Inter-hub a ser habilitado. Ativar esta opção garante que as suas Políticas de Encaminhamento sejam aplicadas à Intenção de Encaminhamento deste Hub de WAN Virtual.
Selecione Guardar.
Repita as etapas 2 a 8 para outros hubs de WAN Virtuais Seguros para os quais pretende configurar políticas de encaminhamento.
Neste momento, está pronto para enviar tráfego de teste. Certifique-se de que as Políticas de Firewall estão configuradas adequadamente para permitir/negar tráfego com base nas configurações de segurança pretendidas.
Configurar a intenção de roteamento e as políticas por meio do portal WAN Virtual
As etapas a seguir descrevem como configurar a intenção de roteamento e as políticas de roteamento em seu Hub Virtual usando o portal WAN Virtual.
No link do portal personalizado fornecido no e-mail de confirmação da Etapa 3 na seção Pré-requisitos , navegue até o hub WAN virtual no qual você deseja configurar 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 Filial e Rede Virtual), selecione Firewall do Azure, Dispositivo Virtual de Rede ou soluções SaaS em Tráfego Privado. Em Recurso de salto seguinte, selecione o recurso de salto seguinte relevante.
Se você quiser configurar uma Política de Roteamento de Tráfego Privado e tiver ramificações ou redes virtuais usando Prefixos de RFC1918 não IANA, selecione Prefixos Adicionais e especifique os intervalos de prefixos de RFC1918 não IANA na caixa de texto exibida. Selecionar Concluído. Certifique-se de que adiciona o mesmo prefixo à caixa de texto Prefixo de Tráfego Privado em todos os Hubs Virtuais configurados com Políticas de Encaminhamento Privado para garantir que as rotas corretas são anunciadas para todos os hubs.
Se quiser configurar uma Política de Roteamento de Tráfego da Internet, selecione Firewall do Azure, Dispositivo Virtual de Rede ou solução SaaS. Em Recurso de salto seguinte, selecione o recurso de salto seguinte relevante.
Para aplicar a intenção de roteamento e a configuração das políticas de roteamento, clique em Salvar.
Repita para todos os hubs para os quais gostaria de configurar as políticas de encaminhamento.
Neste momento, está pronto para enviar tráfego de teste. Certifique-se de que as suas Políticas de Firewall estão configuradas adequadamente para permitir/negar tráfego com base nas configurações de segurança pretendidas.
Configurar a intenção de roteamento usando um modelo BICEP
Consulte o modelo BICEP para obter informações sobre o modelo e as etapas.
Resolução de Problemas
A seção a seguir descreve maneiras comuns de solucionar problemas quando você configura a intenção de roteamento e as políticas em seu Hub WAN Virtual.
Rotas Efetivas
Quando as políticas de roteamento privado são configuradas no Hub Virtual, todo o tráfego entre as Redes Locais e as Redes Virtuais é inspecionado pelo Firewall do Azure, pelo Dispositivo Virtual de Rede ou pela solução SaaS no Hub Virtual.
Portanto, as rotas efetivas do defaultRouteTable mostram os RFC1918 prefixos agregados (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 do Dispositivo Virtual de Rede. Isso reflete que todo o tráfego entre Redes Virtuais e filiais é roteado para a solução Firewall do Azure, NVA ou SaaS no hub para inspeção.
Depois que o Firewall inspeciona o pacote (e o pacote é permitido por configuração de regra de Firewall), a WAN Virtual encaminha o pacote para seu destino final. Para ver quais rotas a WAN Virtual usa para encaminhar pacotes inspecionados, exiba a tabela de rotas efetiva do Firewall ou do Dispositivo Virtual de Rede.
A tabela de rotas eficaz do Firewall ajuda a reduzir e isolar problemas em sua rede, como configurações incorretas ou problemas com determinadas ramificações 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 no defaultRouteTable com conexão de rede virtual do próximo salto.
- A opção para configurar a intenção de roteamento fica esmaecida no portal do Azure se sua implantação não atender aos requisitos acima.
- Se você estiver usando CLI, PowerShell ou REST, a operação de criação de 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 recriar.
- Se você estiver usando o Gerenciador de Firewall do Azure, verifique se as rotas existentes no defaultRouteTable são nomeadas private_traffic, internet_traffic ou all_traffic. A opção para configurar a intenção de roteamento (habilitar interhub) ficará acinzentada se as rotas tiverem nomes diferentes.
- Depois de configurar a intenção de roteamento em um hub, certifique-se de que todas as atualizações de conexões existentes ou novas conexões com o hub sejam criadas com os campos opcionais da tabela de rotas associados e propagados definidos como vazios. Definir as associações e propagações opcionais como vazias é feito automaticamente para todas as operações executadas através do portal do Azure.
Solução de problemas do caminho de dados
Supondo que você já tenha revisado a seção Limitações conhecidas , aqui estão algumas maneiras de solucionar problemas de caminho de dados e conectividade:
- Solução de problemas com rotas eficazes:
- Se as Políticas de Roteamento Privado estiverem configuradas, você verá rotas com o Firewall de próximo salto nas rotas efetivas de defaultRouteTable para agregações de 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. Certifique-se de que todos os prefixos de Rede Virtual e locais sejam sub-redes dentro das rotas estáticas em defaultRouteTable. Se uma rede virtual ou local 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 as Políticas de Roteamento de Tráfego da Internet estiverem configuradas, você verá uma rota padrão (0.0.0.0/0) nas rotas efetivas de defaultRouteTable.
- Depois de verificar se as rotas efetivas do defaultRouteTable têm os prefixos corretos, exiba as Rotas Efetivas do Dispositivo Virtual de Rede ou do 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 reduzir os 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 não seguro (hub sem Firewall do Azure ou NVA) em sua WAN Virtual, verifique se as conexões com o hub não seguro estão se propagando para defaultRouteTable dos hubs com intenção de roteamento configurada. Se as propagações não estiverem 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 as 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 está definida como 'false' não aprenderão a rota 0.0.0.0/0, mesmo que as Políticas de Roteamento da Internet estejam configuradas.
- Se você estiver usando Pontos de Extremidade Privados implantados em Redes Virtuais conectadas ao Hub Virtual, o tráfego local destinado a Pontos de Extremidade Privados implantados em Redes Virtuais conectadas ao hub WAN Virtual ignorará por padrão a intenção de roteamento no próximo salto Firewall do Azure, NVA ou SaaS. No entanto, isso resulta em roteamento assimétrico (que pode levar à perda de conectividade entre pontos de extremidade locais e privados) como pontos de extremidade privados em redes virtuais spoke encaminham o tráfego local para o firewall. Para garantir a simetria de roteamento, habilite as políticas de rede da Tabela de Rotas para pontos de extremidade privados nas sub-redes onde os Pontos de Extremidade Privados são implantados. A configuração de rotas /32 correspondentes a endereços IP privados do Ponto Final 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 a Rota Expressa Criptografada com Políticas de Roteamento Privado, verifique se o dispositivo de Firewall tem uma regra configurada para permitir o tráfego entre o ponto de extremidade de túnel IP privado do Gateway VPN Site a Site da WAN Virtual e o dispositivo VPN local. Os pacotes ESP (externos criptografados) devem fazer logon nos logs do Firewall do Azure. Para obter mais informações sobre Rota Expressa Criptografada com intenção de roteamento, consulte a documentação da Rota Expressa Criptografada.
Solução de problemas de roteamento do Firewall do Azure
- Verifique se o estado de provisionamento do Firewall do Azure foi bem-sucedido antes de tentar configurar a intenção de roteamento.
- Se estiver a utilizar prefixos RFC1918 não IANA nas suas filiais/Redes Virtuais, certifique-se de que especificou 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 intenção de roteamento. Para garantir a conectividade, adicione esses prefixos à caixa de texto "Prefixos privados" em cada hub que tenha intenção de roteamento.
- Se tiver especificado endereços não RFC1918 como parte da caixa de texto Prefixos de Tráfego Privado no Gestor de Firewall, poderá ter de configurar políticas SNAT na Firewall para desativar o SNAT para tráfego privado não RFC1918. Para obter mais informações, consulte os intervalos SNAT do Firewall do Azure.
- Configure e exiba os logs do Firewall do Azure para ajudar a solucionar problemas e analisar o tráfego da rede. Para obter mais informações sobre como configurar o monitoramento para o Firewall do Azure, consulte o diagnóstico do Firewall do Azure. Para obter uma visão geral dos diferentes tipos de logs do Firewall, consulte Logs e métricas do Firewall do Azure.
- Para obter mais informações sobre o Firewall do Azure, consulte a Documentação do Firewall do Azure.
Resolver problemas de Aplicações Virtuais de Rede
- Verifique se o estado de provisionamento do Network Virtual Appliance foi bem-sucedido antes de tentar configurar a intenção de roteamento.
- Se estiver a utilizar prefixos RFC1918 não IANA nas suas Redes Virtuais ou locais ligadas, certifique-se de que especificou 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 intenção de roteamento. Para garantir a conectividade, adicione esses prefixos à caixa de texto "Prefixos privados" em cada hub que tenha intenção de roteamento.
- Se você tiver especificado endereços não RFC1918 como parte da caixa de texto Prefixos de tráfego privado, talvez seja necessário configurar políticas SNAT em seu NVA para desabilitar o SNAT para determinados tráfego privado não RFC1918.
- Verifique os logs do Firewall NVA para ver se o tráfego está sendo descartado ou negado pelas regras do Firewall.
- Entre em contato com seu provedor de NVA para obter mais suporte e orientação sobre solução de problemas.
Solução de problemas de software como serviço
- Verifique se o estado de provisionamento da solução SaaS foi 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 da WAN Virtual ou consulte a documentação do Palo Alto Networks Cloud NGFW.
Próximos passos
Para obter mais informações sobre roteamento de hub virtual, consulte Sobre roteamento de hub virtual. Para obter mais informações sobre a WAN Virtual, consulte as Perguntas frequentes.