FAQ da WAN Virtual

O Azure está WAN Virtual na AG?

Sim, a Azure WAN Virtual geralmente está disponível (GA). No entanto, WAN Virtual consiste em várias características e cenários. Existem funcionalidades ou cenários dentro de WAN Virtual onde a Microsoft aplica a etiqueta de pré-visualização. Nesses casos, a característica específica, ou o próprio cenário, está em Pré-Visualização. Se não utilizar uma funcionalidade de pré-visualização específica, aplica-se um suporte regular para a AG. Para obter mais informações sobre o suporte de pré-visualização, consulte Termos Complementares de Utilização para visualizações do Microsoft Azure.

Quais os locais e regiões disponíveis?

Para obter informações, consulte locais e regiões disponíveis.

O utilizador precisa de ter hub e falou com dispositivos SD-WAN/VPN para utilizar o Azure WAN Virtual?

WAN Virtual fornece muitas funcionalidades incorporadas num único painel de vidro, tais como conectividade VPN site/site-to-site, conectividade user/P2S, conectividade ExpressRoute, conectividade de rede virtual, Interconectividade VPN ExpressRoute, conectividade transitiva VNet-to-VNet, Encaminhamento Centralizado, segurança Azure Firewall e Gestor de Firewall, Monitorização, Encriptação ExpressRoute, e muitas outras capacidades. Não é preciso ter todos estes casos de uso para começar a usar WAN Virtual. Pode começar com apenas uma caixa de uso.

A arquitetura WAN Virtual é um hub e uma arquitetura falada com escala e performance construídas onde os balcões (dispositivos VPN/SD-WAN), utilizadores (Clientes Azure VPN, openVPN ou Clientes IKEv2), circuitos ExpressRoute, redes virtuais servem como porta-vozes para centros virtuais. Todos os hubs estão ligados em malha completa num Standard WAN Virtual facilitando o uso da espinha dorsal da Microsoft para qualquer conectividade (qualquer um falado). Para o hub e falou com dispositivos SD-WAN/VPN, os utilizadores podem instalá-lo manualmente no portal Azure WAN Virtual ou utilizar o WAN Virtual Partner CPE (SD-WAN/VPN) para configurar a conectividade com o Azure.

WAN Virtual parceiros fornecem automatização para conectividade, que é a capacidade de exportar a informação do dispositivo para o Azure, baixar a configuração Azure e estabelecer conectividade com o hub WAN Virtual Azure. Para a conectividade ponto-a-local/utilizador VPN, apoiamos o cliente Azure VPN, OpenVPN ou cliente IKEv2.

Pode desativar os centros totalmente misturados num WAN Virtual?

WAN Virtual vem em dois sabores: Básico e Standard. Na WAN Virtual Básica, os centros não são malhados. Num WAN Virtual Standard, os hubs são misturados e automaticamente ligados quando o WAN virtual é configurado pela primeira vez. O utilizador não precisa de fazer nada específico. O utilizador também não tem de desativar ou ativar a funcionalidade para obter centros de malha. WAN Virtual fornece-lhe muitas opções de encaminhamento para orientar o tráfego entre qualquer porta-voz (VNet, VPN ou ExpressRoute). Proporciona a facilidade de centros totalmente malhados, bem como a flexibilidade do tráfego de encaminhamento de acordo com as suas necessidades.

Como é que Zonas de Disponibilidade e resiliência são tratados em WAN Virtual?

WAN Virtual é uma coleção de centros e serviços disponibilizados dentro do centro. O utilizador pode ter o máximo de WAN Virtual por necessidade. Num hub WAN Virtual, existem vários serviços como VPN, ExpressRoute etc. Cada um destes serviços é automaticamente implantado em todo Zonas de Disponibilidade (exceto Azure Firewall), se a região apoiar Zonas de Disponibilidade. Se uma região se tornar uma Zona de Disponibilidade após a implantação inicial no hub, o utilizador pode recriar os gateways, o que irá desencadear uma implementação da Zona de Disponibilidade. Todos os gateways são a provisionados num centro como ativo, o que implica que há resiliência dentro de um centro. Os utilizadores podem ligar-se a vários centros se quiserem resiliência em todas as regiões.

Atualmente, Azure Firewall podem ser implementados para suportar Zonas de Disponibilidade usando Azure Firewall Portal, PowerShell ou CLI. Atualmente, não existe forma de configurar uma Firewall existente para ser implantada em zonas de disponibilidade. Terá de apagar e redistribuir o seu Azure Firewall.

Embora o conceito de WAN Virtual seja global, o recurso WAN Virtual real é Resource Manager e implantado regionalmente. Se a região wan virtual em si tiver um problema, todos os hubs nesse WAN virtual continuarão a funcionar como está, mas o utilizador não será capaz de criar novos hubs até que a região virtual wan esteja disponível.

Que cliente suporta o suporte do Azure WAN Virtual User VPN (ponto a local)?

WAN Virtual suporta cliente Azure VPN, Cliente OpenVPN ou qualquer cliente IKEv2. Azure AD autenticação é suportada com Azure VPN Client. É necessário um mínimo de Windows 10 versão 17763.0 ou superior ao cliente. Os clientes(s) OpenVPN podem suportar a autenticação baseada em certificados. Uma vez selecionado o auth baseado em cert no gateway, verá o ficheiro.ovpn* para descarregar para o seu dispositivo. O IKEv2 suporta a autenticação do certificado e do RADIUS.

Para a VPN do utilizador (ponto a local)- porque é que o pool de clientes P2S está dividido em duas rotas?

Cada gateway tem duas instâncias, a divisão acontece para que cada instância de gateway possa alocar iPs de clientes independentemente para clientes conectados e o tráfego da rede virtual é encaminhado de volta para a instância de gateway correta para evitar o lúpulo de instância inter-gateway.

Como devo proceder para adicionar servidores DNS para clientes P2S?

Existem duas opções para adicionar servidores DNS para os clientes P2S. O primeiro método é preferido, uma vez que adiciona os servidores DNS personalizados ao gateway em vez do cliente.

  1. Utilize o seguinte script PowerShell para adicionar os servidores DNS personalizados. Substitua os valores para o seu ambiente.

    // Define variables
    $rgName = "testRG1"
    $virtualHubName = "virtualHub1"
    $P2SvpnGatewayName = "testP2SVpnGateway1"
    $vpnClientAddressSpaces = 
    $vpnServerConfiguration1Name = "vpnServerConfig1"
    $vpnClientAddressSpaces = New-Object string[] 2
    $vpnClientAddressSpaces[0] = "192.168.2.0/24"
    $vpnClientAddressSpaces[1] = "192.168.3.0/24"
    $customDnsServers = New-Object string[] 2
    $customDnsServers[0] = "7.7.7.7"
    $customDnsServers[1] = "8.8.8.8"
    $virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName
    $vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name
    
    // Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway
    createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers
    
    // Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway
    $P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName
    $updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers 
    
    // Re-generate Vpn profile either from PS/Portal for Vpn clients to have the specified dns servers
    
  2. Ou, se estiver a utilizar o Azure VPN Client para Windows 10, pode modificar o perfil descarregado do ficheiro XML e adicionar as <etiquetas dnsserver><<>/dnsserver></dnsservers> antes de o importar.

       <azvpnprofile>
       <clientconfig>
    
           <dnsservers>
               <dnsserver>x.x.x.x</dnsserver>
               <dnsserver>y.y.y.y</dnsserver>
           </dnsservers>
    
       </clientconfig>
       </azvpnprofile>
    

Na VPN (ponto a site) do Utilizador – quantos clientes são suportados?

O quadro abaixo descreve o número de ligações simultâneas e a produção agregada do gateway VPN ponto-a-local suportado em diferentes unidades de escala.

Unidade de Escala Instâncias gateway Conexões Simultâneas Apoiadas Produção agregada
1 2 500 0,5 Gbps
2 2 500 1 Gbps
3 2 500 1,5 Gbps
4 2 1000 2 Gbps
5 2 1000 2,5 Gbps
6 2 1000 3 Gbps
7 2 5000 3,5 Gbps
8 2 5000 4 Gbps
9 2 5000 4,5 Gbps
10 2 5000 5 Gbps
11 2 10000 5,5 Gbps
12 2 10000 6 Gbps
13 2 10000 6,5 Gbps
14 2 10000 7 Gbps
15 2 10000 7,5 Gbps
16 2 10000 8 Gbps
17 2 10000 8,5 Gbps
18 2 10000 9 Gbps
19 2 10000 9,5 Gbps
20 2 10000 10 Gbps
40 4 20 000 20 Gbps
60 6 30000 30 Gbps
80 8 40000 40 Gbps
100 10 50000 50 Gbps
120 12 60000 60 Gbps
140 14 70000 70 Gbps
160 16 80000 80 Gbps
180 18 90000 90 Gbps
200 20 100000 100 Gbps

Por exemplo, digamos que o utilizador escolhe uma unidade de escala de 1. Cada unidade de escala implicaria um gateway ativo implantado e cada uma das instâncias (neste caso 2) suportaria até 500 ligações. Uma vez que pode obter 500 ligações * 2 por gateway, não significa que planeie 1000 em vez dos 500 para esta unidade de escala. Podem ser necessários serviços durante os quais a conectividade para os 500 extras pode ser interrompida se ultrapassar a contagem de ligação recomendada.

Para portais com unidades de escala superiores a 20, são implantados pares adicionais de instâncias de gateways para fornecer capacidade adicional para ligar os utilizadores. Cada par de instâncias suporta até 10.000 utilizadores adicionais. Por exemplo, se implementar um Gateway com 100 unidades de escala, 5 pares de gateway (10 instâncias totais) são implantados e até 50.000 (10.000 utilizadores x 5 pares de gateway) podem ligar-se.

Além disso, certifique-se de planear o tempo de inatividade no caso de decidir escalar para cima ou para baixo na unidade de escala, ou alterar a configuração ponto-a-local no gateway VPN.

O que são unidades de escala de gateway de WAN Virtual?

Uma unidade de escala é uma unidade definida para escolher uma produção agregada de um gateway no centro virtual. 1 unidade de escala de VPN = 500 Mbps. 1 unidade de escala de ExpressRoute = 2 Gbps. Exemplo: 10 unidades de VPN à escala implicariam 500 Mbps * 10 = 5 Gbps.

Qual é a diferença entre um gateway de rede virtual Azure (VPN Gateway) e um gateway Azure Virtual WAN VPN?

A WAN Virtual oferece conectividade site a site em grande escala e foi criada para débito, escalabilidade e facilidade de utilização. Quando liga um site a um gateway Virtual WAN VPN, é diferente de um gateway de rede virtual regular que usa um tipo de gateway 'VPN site-to-site'. Quando pretende ligar utilizadores remotos ao VIRTUAL WAN, utilize um tipo de gateway 'VPN ponto a local'. As portas VPN ponto-a-local e local-a-local são entidades separadas no hub virtual WAN e devem ser implantadas individualmente. Da mesma forma, quando liga um circuito ExpressRoute a um hub Virtual WAN, utiliza um recurso diferente para o gateway ExpressRoute do que o gateway de rede virtual regular que utiliza o tipo de gateway 'ExpressRoute'.

O WAN virtual suporta até 20-Gbps de produção agregada tanto para VPN como ExpressRoute. A WAN virtual também tem automatização para conectividade com um ecossistema de parceiros de dispositivos de filial CPE. Os dispositivos de filial CPE têm automatização incorporada que autoprovisiona e conecta-se ao Azure Virtual WAN. Estes dispositivos estão disponíveis num ecossistema crescente de parceiros de SD-WAN e de VPN. Consulte a lista de parceiros preferidos.

Como é que WAN Virtual é diferente de um gateway de rede virtual Azure?

Uma VPN de gateway de rede virtual está limitada a 30 túneis. Para as conexões, deve utilizar a WAN Virtual para uma VPN de grande escala. Pode ligar até 1.000 ligações de ramificação por hub virtual com um agregado de 20 Gbps por hub. Uma ligação é um túnel ativo-ativo do dispositivo VPN no local para o hub virtual. Você também pode ter vários hubs virtuais por região, o que significa que você pode conectar mais de 1.000 ramos a uma única região de Azure, implantando múltiplos centros de WAN Virtual naquela Região de Azure, cada um com o seu próprio portal VPN site-to-site.

WAN Virtual suporta 2 instâncias de gateway VPN ativas num centro virtual. Isto significa que existem 2 conjuntos ativos de instâncias de gateway VPN num centro virtual. Durante as operações de manutenção, cada instância é atualizada uma a uma, devido à qual um utilizador pode sofrer uma breve diminuição na produção agregada de um gateway VPN.

Embora WAN Virtual VPN suporte muitos algoritmos, a nossa recomendação é GCMAES256 para encriptação IPSEC e Integridade para um desempenho ideal. AES256 e SHA256 são consideradas menos performantes e, portanto, a degradação do desempenho, como a latência e as gotas de pacote, podem ser esperadas para tipos de algoritmos semelhantes.

Pacotes por segundo ou PPS é um fator do total # de pacotes e da produção suportada por instância. Isto é melhor entendido com um exemplo. Digamos que uma unidade de 1 escala 500-Mbps site-to-site VPN gateway instance é implantado em um hub WAN virtual. Assumindo um tamanho de pacote de 1480, espera-se PPS para aquela instância de gateway vpn no mínimo = [(500 Mbps * 1024 * 1024) /8/1480] ~ 43690.

WAN Virtual tem conceitos de ligação VPN, ligação de ligação e túneis. Uma única ligação VPN consiste em ligações de ligação. WAN Virtual suporta até 4 ligações numa ligação VPN. Cada ligação de ligação consiste em dois túneis IPsec que terminam em dois casos de um gateway VPN ativo implantado num centro virtual. O número total de túneis que podem terminar numa única instância ativa é de 1000, o que também implica que a produção para 1 instância estará disponível agregada em todos os túneis que se ligam a esse caso. Cada túnel também tem certos valores de produção. Para algoritmo GCM, um túnel pode suportar até um máximo de 1,25 Gbps. Em casos de múltiplos túneis ligados a uma porta de entrada de unidade de menor valor, o melhor é avaliar a necessidade por túnel e planear uma porta de entrada VPN que é um valor agregado para a produção em todos os túneis terminando no caso VPN.

Quais os fornecedores de dispositivos (WAN Virtual parceiros) são suportados?

Atualmente, muitos parceiros suportam a experiência de WAN Virtual totalmente automatizada. Para obter mais informações, veja Parceiros de WAN Virtual.

Quais são os passos de automatização dos parceiros da WAN Virtual?

Para obter os passos de automatização, veja Automatização dos parceiros da WAN Virtual.

Sou obrigado a utilizar um dispositivo de parceiro preferencial?

Não. Pode utilizar qualquer dispositivo compatível com VPN que cumpra os requisitos para suporte de IPsec de IKEv2/IKEv1. WAN Virtual também tem soluções parceiras cpe que automatizam a conectividade com a Azure WAN Virtual facilitando a configuração de ligações VPN IPsec em escala.

Como é que os parceiros de WAN Virtual automatizam a conectividade com a WAN Virtual do Azure?

As soluções de conectividade definida pelo software gerem, normalmente, os respetivos dispositivos de ramo com um controlador ou um centro de aprovisionamento de dispositivos. O controlador pode utilizar APIs do Azure para automatizar a conectividade à WAN Virtual do Azure. A automatização inclui o upload de informações do ramo, o descarregamento da configuração Azure, a criação de túneis IPsec em centros Virtuais Azure e a configuração automática da conectividade do dispositivo de ramificação para o Azure WAN Virtual. Quando se tem centenas de balcões, ligar-se usando WAN Virtual CPE Partners é fácil porque a experiência de embarque retira a necessidade de configurar, configurar e gerir a conectividade IPsec em larga escala. Para mais informações, consulte WAN Virtual automatização de parceiros.

E se um dispositivo que estou a usar não estiver na lista de parceiros WAN Virtual? Ainda posso usá-lo para ligar ao Azure WAN Virtual VPN?

Sim, desde que o dispositivo suporte iPsec IKEv1 ou IKEv2. WAN Virtual parceiros automatizam a conectividade do dispositivo para os pontos finais da Azure VPN. Isto implica automatizar etapas como 'branch information upload', 'IPsec e configuração' e 'conectividade'. Como o seu dispositivo não é de um ecossistema parceiro WAN Virtual, terá de fazer o levantamento pesado de tomar manualmente a configuração Azure e atualizar o seu dispositivo para configurar a conectividade IPsec.

Como é que novos parceiros que não estão listados na sua lista de parceiros de lançamento ficam de bordo?

Todas as APIs wan virtuais são OpenAPI. Pode ressarçar a documentação WAN Virtual automatização de parceiros para avaliar a viabilidade técnica. Um parceiro ideal é o que tem um dispositivo que pode ser aprovisionado para a conectividade IKEv1 ou IKEv2 IPsec. Uma vez concluída a empresa o trabalho de automatização do seu dispositivo CPE com base nas diretrizes de automatização acima fornecidas, pode chegar para azurevirtualwan@microsoft.com ser listado aqui Conectividade através de parceiros. Se é um cliente que gostaria que uma determinada solução da empresa fosse listada como WAN Virtual parceiro, contacte a empresa WAN Virtual enviando um e-mail para azurevirtualwan@microsoft.com.

Como é que WAN Virtual suporta dispositivos SD-WAN?

WAN Virtual parceiros automatizam a conectividade IPsec com os pontos finais da Azure VPN. Se o parceiro WAN Virtual for um fornecedor SD-WAN, então está implícito que o controlador SD-WAN gere a automação e a conectividade IPsec com os pontos finais do Azure VPN. Se o dispositivo SD-WAN necessitar do seu próprio ponto final em vez de Azure VPN para qualquer funcionalidade proprietária da SD-WAN, pode implantar o ponto final SD-WAN num VNet Azure e coexistir com o Azure WAN Virtual.

WAN Virtual suporta o BGP Peering e também tem a capacidade de implantar NVA's num hub WAN virtual.

Quantos dispositivos VPN podem ligar-se a um único hub?

Até 1.000 ligações são suportadas por hub virtual. Cada ligação é constituída por quatro ligações e cada ligação suporta dois túneis que se encontram numa configuração ativa. Os túneis terminam num gateway VPN do hub virtual de Azure. As ligações representam a ligação FÍSICA ISP no dispositivo branch/VPN.

O que é uma ligação de ramo ao Azure WAN Virtual?

Uma ligação de um ramo ou dispositivo VPN para Azure WAN Virtual é uma ligação VPN que liga virtualmente o site VPN e o gateway Azure VPN em um hub virtual.

O que acontece se o dispositivo VPN no local só tiver um túnel para um gateway VPN WAN Virtual Azure?

Uma ligação WAN Virtual Azure é composta por 2 túneis. Um gateway VPN WAN Virtual é implantado num centro virtual em modo ativo, o que implica que existem túneis separados de dispositivos no local que terminam em instâncias separadas. Esta é a recomendação para todos os utilizadores. No entanto, se o utilizador optar por ter apenas um túnel para uma das instâncias de gateway VPN WAN Virtual, se por qualquer motivo (manutenção, patches, etc.) a instância do gateway for desligada, o túnel será movido para o caso ativo secundário e o utilizador poderá experimentar uma reconexão. As sessões de BGP não se movem em instâncias.

O que acontece durante um Gateway Reset num gateway VPN WAN Virtual?

O botão Gateway Reset deve ser utilizado se os seus dispositivos no local estiverem todos a funcionar como esperado, mas a ligação VPN local-local em Azure encontra-se num estado desligado. WAN Virtual as portas VPN são sempre implantadas num estado Active-Active para uma elevada disponibilidade. Isto significa que há sempre mais de um caso implantado numa porta de entrada VPN a qualquer momento. Quando o botão Gateway Reset é utilizado, reinicia as instâncias do gateway VPN de forma sequencial para que as suas ligações não sejam interrompidas. Haverá uma breve lacuna à medida que as ligações se movem de um caso para o outro, mas esta lacuna deve ser inferior a um minuto. Além disso, note que a reposição dos gateways não mudará os seus IPs públicos.

Este cenário aplica-se apenas às ligações S2S.

O dispositivo VPN no local pode ligar-se a vários centros?

Sim. O fluxo de tráfego, quando começa, é do dispositivo no local até à borda de rede mais próxima da Microsoft e, em seguida, para o centro virtual.

Existem novos recursos do Resource Manager disponíveis para a WAN Virtual?

Sim, WAN Virtual tem novos recursos Resource Manager. Para obter mais informações, consulte Descrição Geral.

Posso implementar e utilizar a minha aplicação virtual de rede favorita (numa VNet de NVA) com a WAN Virtual do Azure?

Sim, pode ligar a VNet da aplicação virtual de rede (NVA) favorita à WAN Virtual do Azure.

Posso criar um Aparelho Virtual de Rede dentro do centro virtual?

Um aparelho virtual de rede (NVA) pode ser implantado dentro de um hub virtual. Para passos, veja sobre a NVA's em um centro de WAN Virtual.

Um VNet falado pode ter uma porta de entrada de rede virtual?

Não. O VNet falado não pode ter uma porta de entrada de rede virtual se estiver ligado ao centro virtual.

Existe apoio para o BGP na conectividade VPN?

Sim, o BGP é suportado. Quando criar um site VPN, pode fornecer os parâmetros BGP nele. Isto implicará que quaisquer ligações criadas em Azure para esse site serão ativadas para BGP.

Existem informações de licenciamento ou de preços da WAN Virtual?

Sim. Veja a página Preços.

É possível construir uma WAN Virtual do Azure com um modelo do Resource Manager?

Uma configuração simples de um WAN Virtual com um hub e um vpnsite pode ser criada usando um modelo de arranque rápido. WAN Virtual é principalmente um serviço REST ou portal.

Os VNets falados ligados a um hub virtual podem comunicar entre si (V2V Transit)?

Sim. A Standard WAN Virtual suporta a conectividade transitiva VNet-to-VNet através do WAN Virtual hub a que os VNets estão ligados. Em WAN Virtual terminologia, referimo-nos a estes caminhos como "trânsito VNet WAN Virtual local" para VNets ligados a um hub Virtual Wan dentro de uma única região, e "global WAN Virtual VNets transit" para VNets conectados através de múltiplos centros de WAN Virtual em duas ou mais regiões.

Em alguns cenários, os VNets falados também podem ser diretamente espreitados uns com os outros usando o olhar de rede virtual, além do trânsito de WAN Virtual VNet local ou global. Neste caso, o VNet Peering tem precedência sobre a ligação transitiva através do WAN Virtual hub.

A conectividade entre ramificações é permitida na WAN Virtual?

Sim, a conectividade entre ramificações está disponível na WAN Virtual. O branch é conceptualmente aplicável aos utilizadores VPN, circuitos ExpressRoute ou utilizadores ponto a local/utilizador VPN. Ativar o ramo-a-ramo é ativado por predefinição e pode ser localizado nas definições de configuração WAN. Isto permite que os balcões/utilizadores VPN se conectem a outros balcões VPN e a conectividade de trânsito também está ativada entre utilizadores VPN e ExpressRoute.

O tráfego de ramo-a-ramo atravessa o WAN Virtual de Azure?

Sim. O tráfego de ramo-a-ramo atravessa a WAN Virtual de Azure.

Os WAN Virtual requerem ExpressRoute de cada site?

N.º WAN Virtual não requer ExpressRoute de cada site. Os sites podem estar ligados a uma rede de fornecedor através de um circuito do ExpressRoute. Para sites que estão ligados usando ExpressRoute para um hub virtual e IPsec VPN no mesmo hub, o hub virtual fornece conectividade de trânsito entre o utilizador VPN e ExpressRoute.

Existe um limite de produção ou ligação de rede ao utilizar o Azure WAN Virtual?

A produção de rede é per serviço num hub WAN virtual. Em cada hub, a produção agregada VPN é de até 20 Gbps, a produção agregada ExpressRoute é de até 20 Gbps, e o rendimento agregado VPN/VPN ponto-a-local é de até 20 Gbps. O router em hub virtual suporta até 50 Gbps para fluxos de tráfego VNet-vNet e assume um total de 2000 VM de carga de trabalho em todos os VNets ligados a um único hub virtual.

Para garantir a capacidade inicial sem ter de esperar que o hub virtual se escalone quando for necessária mais produção, pode definir a capacidade mínima ou modificar conforme necessário. Ver Sobre as configurações do hub virtual - capacidade do hub. Para obter implicações de custos, consulte o custo da Unidade de Infraestrutura de Encaminhamento na página de preços WAN Virtual Azure.

Quando os sites VPN se ligam a um hub, fazem-no com ligações. WAN Virtual suporta até 1000 ligações ou túneis 2000 IPsec por centro virtual. Quando os utilizadores remotos se ligam ao hub virtual, conectam-se ao gateway P2S VPN, que suporta até 100.000 utilizadores dependendo da unidade de escala (largura de banda) escolhida para o gateway P2S VPN no centro virtual.

Posso usar o NAT-T nas minhas ligações VPN?

Sim, nat traversal (NAT-T) é suportado. O gateway VPN WAN Virtual NÃO executará qualquer funcionalidade semelhante ao NAT nos pacotes internos de/para os túneis IPsec. Nesta configuração, certifique-se de que o dispositivo no local inicia o túnel IPsec.

Como posso configurar uma unidade de escala para uma definição específica como 20-Gbps?

Vá ao gateway VPN dentro de um hub no portal e, em seguida, clique na unidade de escala para alterá-la para a definição apropriada.

A WAN Virtual permite que o dispositivo no local utilize vários ISPs em paralelo, ou é sempre um único túnel VPN?

As soluções de dispositivos no local podem aplicar políticas de tráfego para orientar o tráfego através de vários túneis para o centro de WAN Virtual Azure (gateway VPN no centro virtual).

O que é a arquitetura de trânsito global?

Para obter informações, consulte a arquitetura da rede de trânsito Global e WAN Virtual.

Como é que o tráfego é encaminhado no backbone do Azure?

O tráfego segue o padrão: dispositivo de ramo ->ISP-Microsoft> rede edge-Microsoft> DC (hub VNet)->Microsoft rede edge-ISP-branch>>

Neste modelo, do que precisa em cada site? Apenas uma ligação à internet?

Sim. Uma ligação à Internet e dispositivo físico que suporta o IPsec, de preferência dos nossos parceiros WAN Virtual integrados. Opcionalmente, pode gerir manualmente a configuração e conectividade com o Azure a partir do seu dispositivo preferido.

Como devo proceder para permitir a rota predefinida (0.0.0.0/0) para uma ligação (VPN, ExpressRoute ou rede virtual)?

Um hub virtual pode propagar uma rota padrão aprendida para uma ligação VPN/ExpressRoute de rede virtual/local se a bandeira estiver 'Activada' na ligação. Esta bandeira é visível quando o utilizador edita uma ligação de rede virtual, uma ligação VPN ou uma ligação ExpressRoute. Por predefinição, esta bandeira é desativada quando um site ou um circuito ExpressRoute estão ligados a um hub. É ativado por padrão quando uma ligação de rede virtual é adicionada para ligar um VNet a um hub virtual.

A rota padrão não se origina no hub WAN Virtual; a rota padrão é propagada se já for aprendida pelo hub WAN Virtual como resultado da implantação de uma firewall no centro, ou se outro site conectado tiver um túnel forçado ativado. Uma rota predefinida não se propaga entre os centros (inter-hub).

É possível criar vários centros WAN virtuais na mesma região?

Sim. Os clientes podem agora criar mais do que um hub na mesma região para o mesmo Azure WAN Virtual.

Como é que o hub virtual de um WAN virtual seleciona o melhor caminho para uma rota a partir de vários centros?

Se um hub virtual aprende a mesma rota a partir de vários centros remotos, a ordem pela qual decide é a seguinte:

  1. O prefixo mais longo.
  2. Rotas locais sobre o interhub.
  3. Rotas estáticas sobre o BGP: Isto está em contexto para a decisão que está a ser tomada pelo router de hub virtual. No entanto, se o decisor for o gateway VPN onde um site anuncia rotas via BGP ou fornece prefixos de endereço estático, as rotas estáticas podem ser preferíveis nas rotas BGP.
  4. ExpressRoute (ER) sobre VPN: ER é preferido sobre VPN quando o contexto é um hub local. A conectividade de trânsito entre os circuitos ExpressRoute só está disponível através do Alcance Global. Portanto, em cenários em que o circuito ExpressRoute está ligado a um hub e há outro circuito ExpressRoute ligado a um centro diferente com ligação VPN, a VPN pode ser preferível para cenários inter-hub. No entanto, pode configurar a preferência de encaminhamento de hub virtual para alterar a preferência padrão.
  5. Comprimento do percurso AS (Os hubs virtuais preparam rotas com o caminho AS 65520-65520 quando as rotas publicitárias entre si).

O hub WAN Virtual permite a conectividade entre os circuitos ExpressRoute?

O trânsito entre o ER-ER é sempre através do alcance global. Gateways de hub virtuais são implantados nas regiões de DC ou Azure. Quando dois circuitos ExpressRoute se ligam via Alcance Global, não há necessidade de o tráfego vir dos routers de borda para o centro virtual DC.

Existe um conceito de peso nos circuitos Azure WAN Virtual ExpressRoute ou ligações VPN

Quando vários circuitos ExpressRoute estão ligados a um hub virtual, o peso do encaminhamento na ligação fornece um mecanismo para que o ExpressRoute no centro virtual prefira um circuito em vez do outro. Não há mecanismo para definir um peso numa ligação VPN. O Azure prefere sempre uma ligação ExpressRoute em vez de uma ligação VPN dentro de um único hub.

WAN Virtual prefere ExpressRoute em vez de VPN para a saída de trânsito do Azure

Sim. WAN Virtual prefere ExpressRoute em vez de VPN para a saída de tráfego de Azure. No entanto, pode configurar a preferência de encaminhamento de hub virtual para alterar a preferência padrão. Para etapas, consulte a preferência de encaminhamento de hub virtual Configure.

Quando um hub WAN Virtual tem um circuito ExpressRoute e um site VPN ligado a ele, o que faria com que uma rota de ligação VPN fosse preferida em vez do ExpressRoute?

Quando um circuito ExpressRoute está ligado a um hub virtual, os routers do Microsoft Edge são o primeiro nó de comunicação entre as instalações e o Azure. Estes routers de borda comunicam com os gateways WAN Virtual ExpressRoute que, por sua vez, aprendem rotas a partir do router de hub virtual que controla todas as rotas entre quaisquer portas de entrada em WAN Virtual. Os routers do Microsoft Edge processam rotas de hub virtual ExpressRoute com maior preferência sobre as rotas aprendidas a partir das instalações.

Por qualquer motivo, se a ligação VPN se tornar o meio principal para o centro virtual aprender rotas (por exemplo, cenários de failover entre ExpressRoute e VPN), a menos que o site VPN tenha um comprimento de AS mais longo, o hub virtual continuará a partilhar rotas aprendidas VPN com o gateway ExpressRoute. Isto faz com que os routers do Microsoft Edge prefiram as rotas VPN em vez de rotas no local.

Quando dois hubs (hub 1 e 2) estão ligados e há um circuito ExpressRoute ligado como um laço a ambos os centros, qual é o caminho para um VNet ligado ao hub 1 alcançar um VNet ligado no centro 2?

O comportamento atual é preferir o caminho do circuito ExpressRoute em vez do hub-para-hub para a conectividade VNet-to-VNet. No entanto, isto não é encorajado numa configuração WAN Virtual. Para resolver isto, pode fazer uma de duas coisas:

  • Configure vários circuitos ExpressRoute (diferentes fornecedores) para ligar a um hub e utilizar a conectividade hub-to-hub fornecida por WAN Virtual para fluxos de tráfego inter-região.

  • Configure AS-Path como a Preferência de Encaminhamento do Hub para o seu Hub Virtual. Isto garante que o tráfego entre os 2 hubs atravessa o router do hub Virtual em cada hub e utiliza o caminho hub-to-hub em vez do caminho ExpressRoute (que atravessa os routers microsoft Edge). Para obter mais informações, veja Configurar a preferência de encaminhamento do hub virtual.

Quando há um circuito ExpressRoute ligado como um laço a um hub WAN Virtual e um VNet não WAN Virtual, qual é o caminho para o VNet não WAN Virtual chegar ao centro de WAN Virtual?

O comportamento atual é preferir o caminho do circuito ExpressRoute para o VNet não WAN Virtual para WAN Virtual conectividade. Recomenda-se que o cliente crie uma ligação Rede Virtual para ligar diretamente o VNet não WAN Virtual ao WAN Virtual hub. Em seguida, o tráfego VNet para VNet atravessará o router WAN Virtual em vez do caminho ExpressRoute (que atravessa os routers/MSEE da Microsoft Enterprise Edge).

Os centros podem ser criados em diferentes grupos de recursos em WAN Virtual?

Sim. Esta opção está atualmente disponível apenas através do PowerShell. O portal WAN Virtual requer que os hubs estejam no mesmo grupo de recursos que o próprio recurso WAN Virtual.

O espaço de endereço WAN Virtual recomendado é /23. WAN Virtual hub atribui sub-redes a vários gateways (ExpressRoute, VPN site-to-site, ponto a local VPN, Azure Firewall, Virtual hub Router). Para cenários onde os NVAs são implantados dentro de um hub virtual, um /28 é tipicamente esculpido para os casos de NVA. No entanto, se o utilizador providenciar várias NVAs, pode ser atribuída uma sub-rede /27. Portanto, tendo em conta uma arquitetura futura, enquanto WAN Virtual hubs são implantados com um tamanho mínimo de /24, o espaço de endereço recomendado no tempo de criação para o utilizador entrar é /23.

Pode redimensionar ou alterar os prefixos de endereço de uma rede virtual falada ligada ao centro de WAN Virtual?

N.º Atualmente, isto não é possível. Para alterar os prefixos de endereço de uma rede virtual falada, remova a ligação entre a rede virtual falada e o hub WAN Virtual, modifique os espaços de endereço da rede virtual falada e, em seguida, reco crie a ligação entre a rede virtual falada e o WAN Virtual hub. Além disso, a ligação de 2 redes virtuais com espaços de endereço sobrepostos ao centro virtual não é suportada atualmente.

Existe apoio ao IPv6 em WAN Virtual?

O IPv6 não é suportado no centro de WAN Virtual e nas suas portas. Se tem um VNet com suporte IPv4 e IPv6 e gostaria de ligar o VNet a WAN Virtual, este cenário não está atualmente suportado.

Para o cenário VPN do utilizador ponto-a-local com a fuga de internet através de Azure Firewall, provavelmente terá de desligar a conectividade IPv6 no seu dispositivo cliente para forçar o tráfego ao WAN Virtual hub. Isto porque os dispositivos modernos, por padrão, utilizam endereços IPv6.

É necessária uma versão mínima de 05-01-2022 (1 de maio de 2022).

Há limites WAN Virtual?

Consulte a secção limites WAN Virtual na página 'Assinatura' e limites de serviço.

Quais são as diferenças entre os tipos de WAN Virtual (Básico e Standard)?

Consulte AS WANs Virtuais Básicas e Padrão. Para obter preços, consulte a página de preços .

A WAN Virtual armazena os dados dos clientes?

Não. WAN Virtual não armazena nenhum dado do cliente.

Existem fornecedores de serviços geridos que possam gerir WAN Virtual para os utilizadores como um serviço?

Sim. Para obter uma lista de soluções do Managed Service Provider (MSP) habilitados através de Azure Marketplace, consulte Azure Marketplace ofertas dos parceiros MSP de Networking networking da Azure.

Como é que WAN Virtual encaminhamento do hub difere do Azure Route Server num VNet?

Tanto o Azure WAN Virtual hub como o Azure Route Server fornecem capacidades de observação do Border Gateway Protocol (BGP) que podem ser utilizadas por NVAs (Network Virtual Appliance) para anunciar endereços IP do NVA para as redes virtuais Azure do utilizador. As opções de implementação diferem no sentido de que o Azure Route Server é normalmente implantado por um hub de cliente auto-gerido VNet, enquanto a Azure WAN Virtual fornece um serviço de hub totalmente de malha de toque zero ao qual os clientes conectam os seus vários pontos finais de raios (Azure VNet, sucursais no local com VPN local ou SDWAN, utilizadores remotos com ligações ponto-a-local/utilizador remoto VPN e ligações privadas com ExpressRoute) e desfrutar de BGP Peering for NVAs implantados em falou VNet juntamente com outras capacidades vWAN, tais como conectividade de trânsito para VNet-to-VNet, conectividade de trânsito entre VPN e ExpressRoute, encaminhamento personalizado/avançado, associação de rotas personalizadas e propagação, intenção de encaminhamento/políticas para não atrasar segurança inter-região, firewall Secure Hub/Azure etc. Para mais detalhes sobre WAN Virtual BGP Peering, por favor veja Como espreitar o BGP com um hub virtual.

Se estou a usar um fornecedor de segurança de terceiros (Zscaler, iBoss ou Checkpoint) para proteger o meu tráfego de internet, porque não vejo o site VPN associado ao fornecedor de segurança de terceiros no Portal Azure?

Quando opta por implementar um fornecedor de parceiros de segurança para proteger o acesso à Internet para os seus utilizadores, o fornecedor de segurança de terceiros cria um site VPN em seu nome. Como o fornecedor de segurança de terceiros é criado automaticamente pelo fornecedor e não é um site VPN criado pelo utilizador, este site VPN não vai aparecer no Portal Azure.

Para obter mais informações sobre as opções disponíveis fornecedores de segurança de terceiros e como configurar isto, consulte implementar um fornecedor de parceiros de segurança.

As comunidades de BGP geradas por instalações serão preservadas em WAN Virtual?

Sim, as comunidades de BGP geradas por instalações serão preservadas em WAN Virtual. Pode utilizar as suas próprias ASNs públicas ou ASNs privadas para as suas redes no local. Não pode utilizar as gamas reservadas pela Azure ou pela IANA:

  • ASNs reservadas por Azure:
    • Public ASNs: 8074, 8075, 12076
    • ASNs privados: 65515 65517, 65518, 65519, 65520
    • ASNs reservadas por IANA: 23456, 64496-64511, 65535-65551

Na WAN Virtual, o que são os desempenhos estimados pelo SKU do gateway do ExpressRoute?

Unidade de escala Ligações por segundo Mega-Bits por segundo Pacotes por segundo
1 unidade de escala
(2 instâncias)
14,000 2.000 200,000
2 unidades de escala
(4 instâncias)
28,000 4000 400,000
3 unidades de escala
(6 instâncias)
42,000 6000 600,000
4 unidades de escala
(8 instâncias)
56,000 8,000 800,000
5 unidades de escala
(10 instâncias)
70,000 10,000 1 000 000
6 unidades de escala
(12 instâncias)
84,000 12.000 1,200,000
7 unidades de escala
(14 instâncias)
98,000 14,000 1,400,000
8 unidades de escala
(16 instâncias)
112,000 16 000 1,600,000
9 unidades de escala
(18 instâncias)
126,000 18 000 1,800,000
10 unidades de escala
(20 instâncias)
140,000 20 000 2,000,000

Nota

*Os gateways ExpressRoute são implantados como n instâncias. Cada porta de entrada pode suportar até 100.000 pacotes por segundo.

As unidades de escala 2-10, durante as operações de manutenção, mantêm a produção agregada. No entanto, a unidade de escala 1, durante uma operação de manutenção, pode ver uma ligeira variação nos números de produção.

Por que estou a ver uma mensagem e um botão denominado “Atualizar router para a versão mais recente do software” no portal?

A equipa virtual WAN tem estado a trabalhar na atualização de routers virtuais da sua atual infraestrutura de Serviços cloud para implementações baseadas em conjuntos de escala de máquinas virtuais. Isto permitirá que o router de hub virtual esteja agora ciente da zona de disponibilidade. Se navegar para o seu recurso de hub VIRTUAL WAN e vir esta mensagem e botão, então pode atualizar o seu router para a versão mais recente clicando no botão. A infraestrutura baseada em Cloud Services está a depreciar-se. Se quiser tirar partido das novas funcionalidades de WAN virtual, como o BGP a espreitar pelo hub, terá de atualizar o seu router de hub virtual através do Portal Azure.

Só poderá atualizar o seu router de hub virtual se todos os recursos (gateways/tabelas de rota/conexões VNet) no seu hub estiverem num estado bem sucedido. Certifique-se de que todas as suas redes virtuais faladas estão em subscrições ativas/ativadas e que as suas redes virtuais faladas não são eliminadas. Além disso, uma vez que esta operação requer a implantação de novos routers de escala de máquinas virtuais baseados em routers de hub virtuais, você enfrentará um tempo de paragem esperado de 1-2 minutos para o tráfego VNet-vNet através do mesmo hub e 5-7 minutos para todos os outros fluxos de tráfego através do centro. Dentro de um único recurso Virtual WAN, os hubs devem ser atualizados um de cada vez em vez de atualizar vários ao mesmo tempo. Quando a versão router diz "Mais recente", então o hub é feito de atualização. Não haverá alterações no comportamento do encaminhamento após esta atualização, a menos que uma das seguintes seja verdadeira:

  • Se alguma das suas redes virtuais faladas estiver localizada numa região diferente do hub, então terá de eliminar e recriar estas respetivas ligações VNet após a realização da atualização. Isto irá garantir a sua conectividade com estes VNets falados.
  • Se já configurar o BGP entre o seu hub De WAN Virtual e um NVA num VNet falado, então terá de apagar e, em seguida, recriar o par BGP. Uma vez que os endereços IP do router de hub virtual mudam após a atualização, também terá de reconfigurar o seu NVA para acompanhar os novos endereços IP do router do hub virtual. Estes endereços IP são representados como o campo "virtualRouterIps" no JSON de Recurso do Centro Virtual.

Se a atualização falhar por qualquer motivo, o seu hub será recuperado automaticamente para a versão antiga para garantir que ainda existe uma configuração de funcionamento.

Nota

O utilizador terá de ter uma função de proprietário ou contribuinte para ver um estado exato da versão do router do hub. Se um utilizador tiver uma função de leitor para o recurso e subscrição Virtual WAN, então o portal Azure irá mostrar ao utilizador que o router hub precisa de ser atualizado para a versão mais recente, mesmo que o hub já esteja na versão mais recente.

Existe um limite de rota para os clientes OpenVPN que se ligam a um gateway Azure P2S VPN?

O limite de rota para clientes OpenVPN é de 1000.

Como é calculado o SLA Virtual WAN?

Virtual WAN é uma plataforma de networking como serviço que tem um SLA de 99,95%. No entanto, o VIRTUAL WAN combina muitos componentes diferentes, tais como Azure Firewall, VPN site-to-site, ExpressRoute, point-to-site VPN e Virtual WAN Hub/Eletrodomésticos Virtuais de Rede Integrada.

O SLA para cada componente é calculado individualmente. Por exemplo, se o ExpressRoute tiver um tempo de paragem de 10 minutos, a disponibilidade do ExpressRoute será calculada como (Minutos Máximos Disponíveis - tempo de inatividade) / Minutos Máximos disponíveis * 100.

Passos seguintes