Perguntas frequentes sobre a WAN Virtual
A WAN Virtual do Azure está em GA?
Sim, a WAN Virtual do Azure está em GA (disponibilidade geral). No entanto, a WAN Virtual é composta por vários recursos e cenários. Existem recursos ou cenários na WAN Virtual nos quais a Microsoft aplica a marca Versão prévia. Nesses casos, o recurso específico ou o próprio cenário está em versão prévia. Se você não usar uma versão prévia do recurso específica, o suporte à GA regular será aplicado. Para saber mais sobre o suporte a Versões prévias, confira os Termos de uso complementares para versões prévias do Microsoft Azure.
Quais localizações e regiões estão disponíveis?
Para obter informações, confira Localizações e regiões disponíveis.
O usuário precisa ter hub e spoke com dispositivos SD-WAN/VPN para usar a WAN virtual do Azure?
A WAN virtual oferece várias funcionalidades inseridas em um só painel de controle, como conectividade VPN site/site a site, conectividade de usuário/P2S, conectividade do ExpressRoute, conectividade de rede virtual, interconectividade de VPN ExpressRoute, conectividade transitiva VNet a VNet, roteamento centralizado, Firewall do Azure e segurança do Gerenciador de Firewall, monitoramento, criptografia do ExpressRoute e diversas outras funcionalidades. Não é necessário ter todos esses casos de uso para começar a usar a WAN Virtual. Você pode começar com apenas um caso de uso.
A arquitetura da WAN Virtual é uma arquitetura de hub e spoke com dimensionamento e desempenho internos em que as ramificações (dispositivos VPN/SD-WAN), os usuários (clientes VPN do Azure, openVPN ou IKEv2), os circuitos do ExpressRoute e as redes virtuais funcionam como spokes para os hubs virtuais. Todos os hubs são conectados em malha completa em uma WAN Virtual Padrão, o que facilita para o usuário usar o backbone da Microsoft para conectividade de qualquer um para qualquer um (qualquer spoke). Para o hub e spoke com dispositivos SD-WAN/VPN, os usuários podem configurá-lo manualmente no portal da WAN Virtual do Azure ou usar o CPE do Parceiro da WAN Virtual (SD-WAN/VPN) para configurar a conectividade com o Azure.
Os parceiros de WAN Virtual fornecem automação para conectividade, que é a capacidade de exportar as informações do dispositivo para o Azure, baixar a configuração do Azure e estabelecer conectividade com o hub da WAN Virtual do Azure. Para a conectividade de VPN ponto a site/usuário, há suporte para o cliente VPN do Azure, OpenVPN ou IKEv2.
Você pode desabilitar hubs totalmente entrelaçados em uma WAN Virtual?
A WAN Virtual é fornecida em dois tipos: Básico e Standard. Na WAN Virtual básica, os hubs não são entrelaçados. Em uma WAN Virtual padrão, os hubs são entrelaçados e conectados automaticamente quando a WAN virtual é configurada pela primeira vez. O usuário não precisa fazer nada específico. Ele também não precisa desabilitar nem habilitar a funcionalidade para obter hubs entrelaçados. A WAN Virtual oferece várias opções de roteamento para direcionar o tráfego entre qualquer spoke (VNet, VPN ou ExpressRoute). Ela proporciona a facilidade de hubs totalmente entrelaçados e também a flexibilidade de roteamento de tráfego de acordo com suas necessidades.
Como as Zonas de Disponibilidade e resiliência são manipuladas na WAN Virtual?
A WAN Virtual é uma coleção de hubs e serviços disponibilizados dentro do Hub. O usuário pode ter tantas WANs Virtuais conforme a necessidade. Em um hub de WAN Virtual, há diversos serviços como VPN, ExpressRoute etc. Cada um deles será implantado automaticamente nas Zonas de Disponibilidade (exceto o Firewall do Azure) se a região oferecer suporte a Zonas de Disponibilidade. Se uma região se tornar uma Zona de Disponibilidade após a implantação inicial no hub, o usuário poderá recriar os gateways, disparando uma implantação de Zona de Disponibilidade. Todos os gateways são provisionados em um hub como ativo-ativo, o que significa que há resiliência interna em um hub. Os usuários poderão se conectar a vários hubs se desejarem resiliência entre regiões.
No momento, o Firewall do Azure pode ser implantado para dar suporte a Zonas de Disponibilidade usando o Portal do Gerenciador de Firewall do Azure, o PowerShell ou a CLI. No momento, não é possível configurar um Firewall existente para ser implantado nas zonas de disponibilidade. Você precisará excluir e reimplantar o Firewall do Azure.
Embora o conceito de WAN Virtual seja global, o recurso WAN Virtual real é baseado no Resource Manager e é implantado regionalmente. Se a região da WAN Virtual em si tiver um problema, todos os hubs nessa WAN Virtual continuarão a funcionar no estado em que se encontram, mas o usuário não poderá criar hubs até que a região da WAN Virtual esteja disponível.
É possível compartilhar o Firewall em um hub protegido com outros hubs?
Não, cada Hub Virtual do Azure precisa ter um Firewall próprio. A implantação de rotas personalizadas para apontar o Firewall de outro hub protegido falhará e não será concluída com êxito. Considere converter esses hubs em hubs protegidos com Firewalls próprios.
Com qual cliente a VPN de Usuário da WAN Virtual do Azure (ponto a site) é compatível?
A WAN virtual é compatível com cliente da VPN do Azure, cliente OpenVPN ou qualquer cliente IKEv2. A autenticação do Microsoft Entra é compatível com o cliente VPN do Azure. É necessário um sistema operacional cliente Windows 10 versão 17763.0 ou superior. Os clientes OpenVPN podem dar suporte à autenticação baseada em certificado. Depois que a autenticação baseada em certificado for selecionada no gateway, você verá o arquivo .ovpn* a ser baixado no dispositivo. O IKEv2 dá suporte à autenticação de certificado e RADIUS.
Na VPN de usuário (ponto a site), por que o pool de clientes P2S é dividido em duas rotas?
Cada gateway tem duas instâncias. A divisão ocorre para que cada instância de gateway possa alocar IPs de cliente de forma independente para clientes conectados e o tráfego da rede virtual seja roteado de volta para a instância de gateway correta para evitar o salto de instância entre gateways.
Como faço para adicionar servidores DNS a clientes P2S?
Há duas opções para adicionar servidores DNS aos clientes do P2S. O primeiro método é preferido, pois adiciona os servidores DNS personalizados ao gateway em vez do cliente.
Use o script do PowerShell a seguir para adicionar os servidores DNS personalizados. Substitua os valores de acordo com 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 serversOu, se você estiver usando o cliente VPN do Azure para Windows 10, poderá modificar o arquivo XML de perfil baixado e adicionar as marcas <dnsservers><dnsserver></dnsserver></dnsservers> antes da importação.
<azvpnprofile> <clientconfig> <dnsservers> <dnsserver>x.x.x.x</dnsserver> <dnsserver>y.y.y.y</dnsserver> </dnsservers> </clientconfig> </azvpnprofile>
Na VPN de usuário (ponto a site), há suporte para quantos clientes?
A tabela abaixo descreve o número de conexões simultâneas e a taxa de transferência agregada do Gateway de VPN ponto a site com suporte em unidades de escala diferentes.
| Unidade de Escala | Instâncias de Gateway | Conexões simultâneas com suporte | Taxa de transferência 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 | 5.000 | 3,5 Gbps |
| 8 | 2 | 5.000 | 4 Gbps |
| 9 | 2 | 5.000 | 4,5 Gbps |
| 10 | 2 | 5.000 | 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 | 20000 | 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 usuário escolha uma unidade de escala. Cada unidade de escala implica em um gateway ativo-ativo implantado e cada uma das instâncias (neste caso, 2) seria compatível com até 500 conexões. Como você pode obter 500 conexões * 2 por gateway, isso não significa que você planeja 1000 conexões em vez de 500 para essa unidade de escala. Pode ser necessário fazer a manutenção das instâncias, durante a qual a conectividade para as 500 instâncias extras pode ser interrompida se você ultrapassar a contagem de conexões recomendada.
Para gateways com unidades de escala maiores que 20, pares adicionais altamente disponíveis de instâncias de gateway serão implantados a fim de fornecer capacidade adicional para conectar usuários. Cada par de instâncias dá suporte a até 10.000 usuários adicionais. Por exemplo, se você implantar um Gateway com 100 unidades de escala, cinco pares de gateway (10 instâncias no total) serão implantados e até 50.000 (10.000 usuários x cinco pares de gateway) usuários simultâneos poderão se conectar.
Além disso, não se esqueça de planejar o tempo de inatividade caso você decida escalar ou reduzir verticalmente na unidade de escala ou alterar a configuração de ponto a site no gateway de VPN.
O que são unidades de escala de gateway da WAN Virtual?
Uma unidade de escala é uma unidade definida para escolher uma taxa de transferência agregada de um gateway no Hub virtual. 1 unidade de escala de VPN = 500 Mbps. 1 unidade de escala do ExpressRoute = 2 Gbps. Exemplo: 10 unidades de escala de VPN implicariam 500 Mbps * 10 = 5 Gbps.
Qual é a diferença entre um gateway de rede virtual do Azure (Gateway de VPN) e um gateway de VPN da WAN Virtual do Azure?
A WAN Virtual fornece conectividade site a site em larga escala e é criada visando produtividade, escalabilidade e facilidade de uso. Quando você conecta um site a um gateway de VPN da WAN Virtual, ele é diferente de um gateway de rede virtual comum que usa um tipo de gateway 'VPN site a site'. Quando você quiser conectar usuários remotos à WAN virtual, use um tipo de gateway 'VPN ponto a site'. Os gateways de VPN ponto a site e site a site são entidades separadas no hub da WAN Virtual e precisam ser implantados individualmente. Da mesma forma, quando você conecta um circuito de ExpressRoute a um hub de WAN Virtual, ele usa para o gateway de ExpressRoute um recurso diferente daquele usado pelo gateway de rede virtual regular, o qual usa o tipo de gateway 'ExpressRoute'.
A WAN Virtual dá suporte a uma taxa de transferência de agregação de até 20 Gbps para VPN e ExpressRoute. A WAN Virtual também tem automação para conectividade com um ecossistema de parceiros de dispositivo de ramificação CPE. Os dispositivos da ramificação CPE têm automação interna que provisiona automaticamente e se conecta à WAN Virtual do Azure. Esses dispositivos estão disponíveis em um ecossistema crescente de SD-WAN e parceiros de VPN. Confira a Lista de parceiros preferenciais.
Como a WAN Virtual é diferente de um gateway de rede virtual do Azure existente?
A VPN do gateway de rede virtual é limitada a 100 túneis. Para conexões, você deve usar a WAN Virtual para VPN em larga escala. É possível conectar até mil conexões de branch por hub virtual com a agregação de 20 Gbps por hub. Uma conexão é um túnel de ativo-ativo do dispositivo VPN local para o hub virtual. Também é possível contar com vários hubs virtuais por região, ou seja, você pode conectar mais de mil ramificações a uma só região do Azure implantando vários hubs de WAN Virtual nessa região do Azure, cada um com o próprio gateway de VPN site a site.
Qual é o algoritmo e os pacotes por segundo recomendados por instância site a site no hub da WAN Virtual? Quantos túneis têm suportados por instância? Qual é a taxa de transferência máxima com suporte em um único túnel?
A WAN Virtual dá suporte a duas instâncias de gateway de VPN site a site ativas em um hub virtual. Isso significa que há dois conjunto ativo-ativo de instâncias do gateway de VPN em um hub virtual. Durante as operações de manutenção, cada instância é atualizada uma a uma, o que pode fazer com que o usuário experimente uma breve redução na taxa de transferência agregada de um gateway de VPN.
Embora a VPN da WAN Virtual dê suporte a muitos algoritmos, nossa recomendação é usar o GCMAES256 para a Integridade e a Criptografia IPSEC para um desempenho ideal. O AES256 e o SHA256 são considerados com desempenho inferior e, portanto, uma degradação do desempenho, como latência e quedas de pacotes, pode ser esperada para tipos de algoritmo semelhantes.
Pacotes por segundo ou PPS é um fator do número total de pacotes e da taxa de transferência com suporte por instância. É mais fácil entender isso com um exemplo. Digamos que uma instância de gateway de VPN site a site de 500 Mbps de uma unidade de escala seja implantada em um hub de WAN Virtual. Supondo um tamanho de pacote de 1400, o PPS esperado para essa instância de gateway de VPN no máximo = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.
A WAN Virtual tem conceitos de conexão VPN, conexão de link e túneis. Uma única conexão VPN é composta por conexões de link. A WAN Virtual dá suporte a até quatro conexões de link em uma conexão VPN. Cada conexão de link é composta por dois túneis IPsec que terminam em duas instâncias de um gateway de VPN ativo-ativo implantado em um hub virtual. O número total de túneis que podem terminar em uma única instância ativa é de 1000, o que também implica que a taxa de transferência de uma instância estará disponível agregada em todos os túneis que se conectam a essa instância. Cada túnel também tem certos valores de taxa de transferência. Nos casos em que há vários túneis conectados a um gateway de unidade de escala de valor inferior, é melhor avaliar a necessidade por túnel e planejar um Gateway de VPN que seja um valor agregado da taxa de transferência em todos os túneis que terminam na instância de VPN.
Valores para várias unidades de escala com suporte em WAN Virtual
| Unidades da escala | Taxa de transferência máxima por túnel (Mbps) | Máximo de PPS por túnel | Taxa de transferência máxima por instância (Mbps) | Máximo de PPS por instância |
|---|---|---|---|---|
| 1 | 500 | 47K | 500 | 47K |
| 2 | 1000 | 94K | 1000 | 94K |
| 3 | 1500 | 140 mil | 1500 | 140 mil |
| 4 | 1500 | 140 mil | 2000 | 187K |
| 5 | 1500 | 140 mil | 2500 | 234K |
| 6 | 1500 | 140 mil | 3000 | 281K |
| 7 | 2300 | 215K | 3500 | 328K |
| 8 | 2300 | 215K | 4000 | 374K |
| 9 | 2300 | 215K | 4500 | 421K |
| 10 | 2300 | 215K | 5.000 | 468K |
| 11 | 2300 | 215K | 5500 | 515K |
| 12 | 2300 | 215K | 6000 | 562K |
| 13 | 2300 | 215K | 6500 | 609K |
| 14 | 2300 | 215K | 7000 | 655K |
| 15 | 2300 | 215K | 7500 | 702K |
| 16 | 2300 | 215K | 8000 | 749K |
| 17 | 2300 | 215K | 8500 | 796K |
| 18 | 2300 | 215K | 9000 | 843K |
| 19 | 2300 | 215K | 9500 | 889K |
| 20 | 2300 | 215K | 10000 | 936K |
Observação
Todos os números são baseados no algoritmo GCM.
Quais provedores de dispositivo (parceiros de WAN Virtual) são compatíveis?
Neste momento, muitos parceiros dão suporte à experiência de WAN Virtual totalmente automatizada. Para saber mais, confira Parceiros de WAN Virtual.
Quais são as etapas de automação de parceiro de WAN Virtual?
Para conhecer as etapas de automação de parceiro, confira Automação de parceiro de WAN Virtual.
Eu sou obrigado a usar um dispositivo de parceiro preferido?
Não. Você pode usar qualquer dispositivo com capacidade para VPN que siga os requisitos do Azure para suporte a IPsec IKEv2/IKEv1. A WAN Virtual também tem soluções de parceiros de CPE que automatizam a conectividade com a WAN Virtual do Azure, facilitando a configuração de conexões VPN IPsec em escala.
Como os parceiros de WAN Virtual automatizam a conectividade com a WAN Virtual do Azure?
Soluções de conectividade definidas pelo software normalmente gerenciam seus dispositivos de branch usando um controlador ou um centro de provisionamento de dispositivos. O controlador pode usar as APIs do Azure para automatizar a conectividade com a WAN Virtual do Azure. A automação inclui o upload de informações de ramificação, o download da configuração do Azure, a configuração de túneis IPsec em hubs virtuais do Azure e a configuração automática da conectividade do dispositivo de ramificação com a WAN Virtual do Azure. Quando você tem centenas de ramificações, é fácil conectar-se usando parceiros CPE da WAN Virtual, pois a experiência de integração elimina a necessidade de configurar e gerenciar a conectividade IPsec em larga escala. Para saber mais, confira Automação de parceiros de WAN Virtual.
E se um dispositivo que estou usando não estiver na lista de parceiros da WAN Virtual? Ainda posso usá-lo para se conectar à VPN de WAN Virtual do Azure?
Sim, desde que o dispositivo seja compatível com IPsec IKEv1 ou IKEv2. Os parceiros WAN virtuais automatizam a conectividade do dispositivo aos pontos de extremidade de VPN do Azure. Isso implica na automatização de etapas como 'upload de informações de branch', 'IPsec e configuração' e 'conectividade'. Como o dispositivo não é proveniente de um ecossistema de parceiros da WAN Virtual, você precisará ter o trabalho de realizar manualmente a configuração do Azure e atualizar o dispositivo para configurar a conectividade IPsec.
Como integrar novos parceiros que não estejam na lista de parceiros de lançamento?
Todas as APIs de WAN Virtual são OpenAPI. Você pode examinar a documentação automação do parceiro de WAN Virtual para avaliar a viabilidade técnica. Um parceiro ideal é aquele que tem um dispositivo que pode ser provisionado para conectividade IPsec IKEv1 ou IKEv2. Depois que a empresa tiver concluído o trabalho de automação para o dispositivo CPE com base nas diretrizes de automação fornecidas acima, você poderá entrar em contato com o azurevirtualwan@microsoft.com a ser listado aqui: azurevirtualwan@microsoft.com. Se você é um cliente que quer que a solução de uma determinada empresa seja listada como um parceiro de WAN Virtual, peça para a empresa entrar em contato com a equipe da WAN Virtual enviando um email para azurevirtualwan@microsoft.com.
Como o WAN Virtual dá suporte aos dispositivos SD-WAN?
Parceiros WAN Virtuais automatizam a conectividade IPsec com pontos de extremidade de VPN do Azure. Se o parceiro da WAN Virtual é um provedor de SD-WAN, está implícito que o controlador de SD-WAN gerencia a automação e a conectividade IPsec com os pontos de extremidade da VPN do Azure. Se o dispositivo de SD-WAN requer seu próprio ponto de extremidade de VPN do Azure para qualquer funcionalidade SD-WAN proprietária, você pode implantar o ponto de extremidade SD-WAN em uma Rede Virtual do Azure e coexiste com o WAN Virtual do Azure.Se o dispositivo SD-WAN requerer seu próprio ponto de extremidade em vez da VPN do Azure para qualquer funcionalidade SD-WAN proprietária, você poderá implantar o ponto de extremidade SD-WAN em uma rede virtual do Azure e coexistir com a WAN Virtual do Azure.
A WAN Virtual dá suporte ao emparelhamento BGP e tem a capacidade de implantar NVAs em um hub da WAN virtual.
Quantos dispositivos VPN podem se conectar a um único hub?
O hub virtual é compatível com até 1.000 conexões. Cada conexão é composta por quatro links, cada um dos quais dá suporte a dois túneis que estão em uma configuração ativo/ativo. Os túneis terminam em um VPN de gateway do hub virtual do Azure. Os links representam o link do ISP físico no dispositivo VPN/branch.
O que é uma conexão de ramificação WAN Virtual do Azure?
Uma conexão de uma ramificação ou de um dispositivo VPN com a WAN Virtual do Azure é uma conexão VPN que se conecta virtualmente com o site VPN e com o Gateway de VPN do Azure em um hub virtual.
O que acontece se o dispositivo VPN local tem apenas um túnel para um gateway de VPN da WAN Virtual do Azure?
Uma conexão da WAN Virtual do Azure é composta por dois túneis. Um gateway de VPN da WAN Virtual é implantado em um hub virtual no modo ativo-ativo, o que significa que há túneis separados de dispositivos locais que terminam em instâncias separadas. Essa é a recomendação para todos os usuários. No entanto, se o usuário optar por ter apenas um túnel para uma das instâncias de gateway de VPN da WAN Virtual e, se por algum motivo (manutenção, patches etc.), a instância de gateway for colocada offline, o túnel será movido para a instância ativa secundária e o usuário poderá experimentar uma reconexão. As sessões BGP não serão movidas entre instâncias.
O que acontece durante uma redefinição de gateway em um Gateway de VPN da WAN Virtual?
O botão Redefinição de Gateway deve ser usado quando os dispositivos locais estão funcionando conforme o esperado, mas as conexões VPN site a site no Azure estão no estado desconectado. Os Gateways de VPN da WAN Virtual sempre são implantados em um estado ativo-ativo para proporcionar alta disponibilidade. Isso significa que sempre há mais de uma instância implantada em um Gateway de VPN. Quando o botão Redefinição de Gateway é usado, ele reinicializa as instâncias no Gateway de VPN de maneira sequencial, para que as conexões não sejam interrompidas. Haverá uma breve lacuna quando as conexões mudarem de uma instância para outra, mas essa lacuna deve ser inferior a um minuto. Além disso, observe que a redefinição dos gateways não vai alterar os IPs públicos.
Esse cenário só se aplica às conexões site a site.
O dispositivo VPN local pode se conectar a vários hubs?
Sim. O fluxo de tráfego ao começar é do dispositivo local para a borda de rede da Microsoft mais próxima e, em seguida, para o hub virtual.
Há novos recursos do Gerenciador de recursos disponíveis para WAN Virtual?
Sim, a WAN Virtual tem novos recursos do Resource Manager. Para obter mais informações, confira a Visão geral.
Posso implantar e usar meu dispositivo virtual de rede favorito (em uma VNet NVA) com a WAN Virtual do Azure?
Sim, você pode conectar sua rede virtual de dispositivo virtual de rede (NVA) favorita à WAN Virtual do Azure.
Posso criar uma solução de virtualização de rede dentro do hub virtual?
Uma NVA (solução de virtualização de rede) não pode ser implantada em um hub virtual. Para obter as etapas, confira Sobre as NVAs em um hub da WAN Virtual.
Uma VNet spoke pode ter um gateway de rede virtual?
Não. A VNet spoke não poderá ter um gateway de rede virtual se estiver conectada ao hub virtual.
Uma VNet spoke pode ter um Servidor de Rota do Azure?
Não. A VNet spoke não poderá ter um Servidor de Rota se estiver conectada ao hub virtual WAN.
Há suporte para BGP na conectividade da VPN?
Sim, há suporte para BGP. Quando você cria um site VPN, você pode fornecer os parâmetros de BGP nele. Isso implica que todas as conexões criadas no Azure para o site serão habilitadas para BGP.
Há quaisquer informações de licenciamento ou preços para a WAN Virtual?
Sim. Confira a página Preços.
É possível construir a WAN Virtual do Azure com um modelo do Resource Manager?
Uma configuração simples de uma WAN Virtual com um hub e um vpnsite pode ser criada usando um modelo de início rápido. A WAN Virtual é basicamente um serviço controlado por REST ou pelo portal.
VNets spoke conectadas a um hub virtual podem se comunicar umas com as outras (Trânsito do V2V)?
Sim. A WAN Virtual padrão é compatível com a conectividade transitiva VNet a VNet por meio do hub da WAN Virtual ao qual as VNets estão conectadas. Na terminologia da WAN Virtual, nos referimos a esses caminhos como "trânsito de VNet de WAN Virtual local" para VNets conectadas a um hub de WAN Virtual em uma única região e "trânsito de VNet de WAN Virtual global" para VNets conectadas por meio de diversos hubs de WAN Virtual em duas ou mais regiões.
Em alguns cenários, VNets spoke também podem ser diretamente emparelhadas entre si usando o emparelhamento de rede virtual, além do trânsito local ou global de VNet da WAN Virtual. Nesse caso, o Emparelhamento VNet tem precedência sobre a conexão transitiva por meio do hub da WAN Virtual.
A conectividade de branch para branch é permitida na WAN Virtual?
Sim, a conectividade de branch para branch está disponível na WAN Virtual. A ramificação é conceitualmente aplicável ao site VPN, aos circuitos do ExpressRoute ou aos usuários de VPN ponto a site/de usuário. A conectividade branch a branch é habilitada por padrão e pode ser localizada em definições da Configuração de WAN. Isso permite que os usuários/branches de VPN se conectem a outros branches de VPN. A conectividade de trânsito também é habilitada entre os usuários de VPN e do ExpressRoute.
O tráfego de branch para branch atravessa a WAN Virtual do Azure?
Sim. O tráfego de branch para branch atravessa a WAN Virtual do Azure.
A WAN Virtual exige o ExpressRoute de cada site?
Não. A WAN Virtual não exige o ExpressRoute de cada site. Seus sites podem estar conectados a uma rede do provedor usando um circuito do ExpressRoute. Para sites conectados a um hub virtual usando o ExpressRoute, bem como VPN IPsec no mesmo hub, o hub virtual oferece conectividade de trânsito entre o usuário de VPN e do ExpressRoute.
Há um limite de taxa de transferência de rede ou de conexão ao usar a WAN Virtual do Azure?
A taxa de transferência de rede é de acordo com o serviço em um hub de WAN virtual. Em cada hub, a taxa de transferência agregada da VPN é de até 20 Gbps, a taxa de transferência agregada do ExpressRoute é de até 20 Gbps e a taxa de transferência agregada da VPN do Usuário/da VPN ponto a site é de até 200 Gbps. O roteador no hub virtual é compatível com até 50 Gbps para fluxos de tráfego de VNet a VNet e admite um total de 2 mil cargas de trabalho de VM em todas as VNets conectadas a apenas um hub virtual.
Para proteger a capacidade inicial sem precisar esperar que o hub virtual seja expandido quando uma taxa de transferência maior for necessária, defina a capacidade mínima ou modifique-a conforme necessário. Confira Sobre as configurações do hub virtual – Capacidade do hub. Para ver as implicações dos custos, confira o custo Unidade de Infraestrutura de Roteamento na página Preços da WAN Virtual do Azure.
Os sites de VPN se conectam a um hub por meio de conexões. A WAN Virtual é compatível com até mil conexões ou 2 mil túneis de IPsec por hub virtual. Quando usuários remotos se conectam ao hub virtual, eles se conectam ao gateway de VPN P2S, que é compatível com até 100 mil usuários, dependendo da unidade de escala (largura de banda) escolhida para o gateway de VPN P2S no hub virtual.
Posso usar um NAT-T em minhas conexões VPN?
Sim, o NAT-T (NAT Traversal) é compatível. O gateway de VPN da WAN Virtual NÃO executará nenhuma funcionalidade semelhante ao NAT de/para túneis IPsec nos pacotes internos. Nessa configuração, verifique se o dispositivo local inicia o túnel IPsec.
Como posso configurar uma unidade de escala para uma configuração específica, como 20 Gbps?
Procure o gateway de VPN em um hub no portal e clique na unidade de escala para alterá-la para a configuração apropriada.
A WAN Virtual permite que o dispositivo local utilize vários ISPs em paralelo ou sempre será um único túnel VPN?
As soluções de dispositivo local podem aplicar políticas de tráfego para direcionar o tráfego de vários túneis para o hub da WAN Virtual do Azure (gateway de VPN no hub virtual).
O que é a arquitetura de trânsito global?
Para obter informações, confira Arquitetura de rede de trânsito global e WAN Virtual.
Como o tráfego é roteado no backbone do Azure?
O tráfego segue o padrão: dispositivo branch -> ISP -> Borda da rede Microsoft -> Microsoft DC (hub VNet) -> Borda da rede Microsoft -> ISP -> dispositivo branch
Nesse modelo, o que você precisa em cada site? Apenas uma conexão com a Internet?
Sim. Uma conexão de Internet e um dispositivo físico que é compatível com IPsec, preferencialmente nossos parceiros de WAN Virtual integrados. Opcionalmente, você pode gerenciar manualmente a configuração e a conectividade com o Azure usando seu dispositivo preferido.
Como fazer para habilitar a rota padrão (0.0.0.0/0) de uma conexão (VPN, ExpressRoute ou rede virtual)?
Um hub virtual poderá propagar uma rota padrão aprendida para uma conexão VPN/ExpressRoute de rede virtual/site a site se o sinalizador for 'Habilitado' na conexão. Esse sinalizador fica visível quando o usuário edita uma conexão de rede virtual, uma conexão VPN ou uma conexão ExpressRoute. Por padrão, esse sinalizador é desabilitado quando um site ou um circuito ExpressRoute é conectado a um hub. Ele é habilitado por padrão quando uma conexão de rede virtual é adicionada para conectar uma VNet a um hub virtual.
A rota padrão não é originada no hub da WAN Virtual, ela é propagada quando o hub da WAN Virtual já a conhece como resultado da implantação de um firewall no hub ou se outro site conectado tiver habilitado o túnel forçado. Uma rota padrão não se propaga entre hubs (inter-hub).
É possível criar vários hubs de WAN virtual na mesma região?
Sim. Os clientes agora podem criar mais de um hub na mesma região para o mesmo WAN Virtual do Azure.
Como o hub virtual em uma WAN virtual seleciona o melhor caminho para uma rota de vários hubs?
Para obter informações, confira a página Preferência de roteamento do hub virtual.
O hub da WAN Virtual permite a conectividade entre circuitos do ExpressRoute?
O trânsito entre ERs é sempre por meio do alcance global. Os gateways do hub virtual são implantados no controlador de domínio ou em regiões do Azure. Quando dois circuitos do ExpressRoute se conectam por meio do Alcance Global, o tráfego não precisa vir dos roteadores de borda para o controlador de domínio do hub virtual.
Há um conceito de peso em circuitos de ExpressRoute de WAN Virtual do Azure ou conexões VPN
Quando vários circuitos de ExpressRoute estão conectados a um hub virtual, o peso de roteamento na conexão fornece um mecanismo para que o ExpressRoute no hub virtual dê preferência a um circuito em vez de outro. Não há nenhum mecanismo para definir um peso em uma conexão VPN. O Azure sempre prefere uma conexão do ExpressRoute em vez de uma conexão VPN em um único hub.
A WAN Virtual prefere o ExpressRoute em relação ao VPN para tráfego de saída do Azure
Sim. A WAN Virtual prefere o ExpressRoute em relação ao VPN para tráfego de saída do Azure. No entanto, você pode configurar a preferência de roteamento do hub virtual para alterar a preferência padrão. Para ver as etapas, confira Configurar a preferência de roteamento do hub virtual.
Quando um hub da WAN Virtual tiver um circuito do ExpressRoute e um site VPN conectado a ele, o que fará com que uma rota de conexão VPN seja preferencial em relação ao ExpressRoute?
Quando um circuito do ExpressRoute é conectado a um hub virtual, os roteadores do Microsoft Edge são o primeiro nó para comunicação entre o local e o Azure. Esses roteadores de borda se comunicam com os gateways do ExpressRoute da WAN Virtual que, por sua vez, aprendem as rotas do roteador do hub virtual, que controla todas as rotas entre todos os gateways da WAN Virtual. Os roteadores do Microsoft Edge processam as rotas do ExpressRoute do hub virtual com preferência mais alta em relação às rotas aprendidas localmente.
Se, por qualquer motivo, a conexão VPN se tornar o meio principal para o hub virtual conhecer rotas (por exemplo, cenários de failover entre o ExpressRoute e a VPN), a menos que o site VPN tenha um tamanho de caminho AS mais longo, o hub virtual continuará compartilhando as rotas de VPN conhecidas do gateway do ExpressRoute. Isso faz com que os roteadores do Microsoft Edge prefiram rotas VPN em detrimento das rotas locais.
Quando dois hubs (hub 1 e 2) estão conectados e há um circuito do ExpressRoute conectado como um laço para ambos os hubs, qual é o caminho para que uma VNet conectada ao hub 1 alcance uma VNet conectada ao hub 2?
O comportamento atual é dar preferência ao caminho do circuito do ExpressRoute em vez da conectividade hub a hub ou VNet a VNet. No entanto, isso não é recomendado em uma configuração de WAN Virtual. Para resolver isso, você tem duas opções:
Configurar vários circuitos do ExpressRoute (provedores diferentes) para conexão a um hub e usar a conectividade hub a hub fornecida pela WAN Virtual para fluxos de tráfego inter-regionais.
Configure AS-Path como a Preferência de Roteamento de Hub para seu Hub Virtual. Isso garante que o tráfego entre os dois hubs percorra o roteador de hub virtual em cada hub e use um caminho de hub a hub em vez do caminho do ExpressRoute (que percorre os roteadores do Microsoft Edge). Para obter mais informações, confira Configurar a preferência de roteamento do hub virtual.
Quando existe um circuito do ExpressRoute conectado como um laço a um hub de WAN Virtual e a uma VNet autônoma, qual será o caminho para que a VNet autônoma alcance o hub de WAN Virtual?
Para novas implantações, essa conectividade é bloqueada por padrão. Para permitir essa conectividade, você pode habilitar essas alternâncias de gateway ExpressRoute na folha "Editar hub virtual" e na folha "Gateway de rede virtual" no Portal. No entanto, é recomendável manter essas alternâncias desabilitadas e, em vez disso, criar uma conexão de Rede Virtual para conectar diretamente VNets autônomas a um hub de WAN Virtual. Posteriormente, o tráfego de VNet para VNet percorrerá o roteador do hub de WAN Virtual, que oferece melhor desempenho do que o caminho do ExpressRoute. O caminho do ExpressRoute inclui o gateway do ExpressRoute, que tem limites de largura de banda mais baixos do que o roteador de hub, bem como os roteadores do Microsoft Enterprise Edge/MSEE, que é um salto extra no datapath.
No diagrama abaixo, ambas as alternâncias precisam ser habilitadas para permitir a conectividade entre a VNet 4 autônoma e as VNets conectadas diretamente ao hub 2 (VNet 2 e VNet 3): permitir o tráfego de redes de WAN Virtual remotas para o gateway de rede virtual e Permitir o tráfego de redes não WAN Virtual para o gateway do ExpressRoute do hub virtual. Se um Servidor de Rotas do Azure for implantado na VNet 4 autônoma, e o Servidor de Rotas tiver branch a branch habilitado, a conectividade será bloqueada entre a VNet 1 e a VNet 4 autônoma.
A ativação ou a desativação da alternância só afetará o seguinte fluxo de tráfego: o tráfego que flui entre o hub da WAN Virtual e as VNets autônomas por meio do circuito do ExpressRoute. Habilitar ou desabilitar a alternância não incorrerá em tempo de inatividade para todos os outros fluxos de tráfego (por exemplo: site local para VNet 2 spoke não será afetado, VNet 2 para VNet 3 não será afetado, etc).
Os hubs podem ser criados em diferentes grupos de recursos na WAN Virtual?
Sim. Atualmente, essa opção só está disponível por meio do PowerShell. O portal da WAN Virtual exige que os hubs estejam no mesmo grupo de recursos que o recurso da WAN Virtual propriamente dito.
Qual é o espaço de endereço do hub recomendado durante a criação do hub?
O espaço de endereço do hub da WAN Virtual recomendado é /23. O hub da WAN Virtual atribui sub-redes a vários gateways (ExpressRoute, VPN site a site, VPN ponto a site, Firewall do Azure e roteador de hub virtual). Para cenários em que NVAs são implantados dentro de um hub virtual, um /28 normalmente é dedicado às instâncias de NVA. No entanto, se o usuário fosse provisionar vários NVAs, uma sub-rede /27 poderia ser atribuída. Portanto, tendo em mente uma arquitetura futura, enquanto os hubs da WAN Virtual são implantados com um tamanho mínimo de /24, o espaço de endereço do hub recomendado no momento da criação para entrada do usuário é /23.
Há suporte para IPv6 na WAN Virtual?
O IPv6 não é compatível com o hub da WAN Virtual e os respectivos gateways. Se você tem uma VNet compatível com IPv4 e IPv6 e deseja conectá-la à WAN Virtual, atualmente, não há suporte para esse cenário.
Para o cenário de VPN de usuário ponto a site com o detalhamento da Internet por meio do Firewall do Azure, você provavelmente terá que desativar a conectividade IPv6 no dispositivo cliente a fim de forçar o tráfego para o hub da WAN Virtual. Isso ocorre porque os dispositivos modernos usam endereços IPv6 por padrão.
Qual é a versão de API recomendada a ser usada por scripts que automatizam várias funcionalidades da WAN Virtual?
É necessário ter uma versão mínima de 05-01-2022 (1º de maio de 2022).
Há algum limite para a WAN Virtual?
Confira a seção Limites da WAN Virtual na página Limites de serviço e assinatura.
Quais são as diferenças entre os tipos de WAN Virtual (Básico e Standard)?
Consulte WANs virtuais Básicas e Standard. Para obter os preços, confira a página de Preços.
A WAN virtual armazena dados do cliente?
Não. A WAN Virtual não armazena nenhum dado do cliente.
Há Provedores de Serviço Gerenciado que podem gerenciar a WAN Virtual para usuários como um serviço?
Sim. Para obter uma lista de soluções de MSP (provedor de serviços gerenciados) habilitadas através do Azure Marketplace, confira Ofertas do Azure Marketplace de parceiros MSP de Rede do Azure.
Qual a diferença entre o roteamento do hub da WAN Virtual e o Servidor de Rota do Azure em uma VNet?
O Hub da WAN Virtual do Azure e o Servidor de Rota do Azure fornecem recursos de emparelhamento de BGP (Border Gateway Protocol) que podem ser utilizados pelas NVAs (soluções de virtualização de rede) para anunciar os endereços IP da NVA para as redes virtuais do Azure do usuário. As opções de implantação diferem no sentido de que o Servidor de Rota do Azure normalmente é implantado por uma VNet de hub do cliente autogerenciada, enquanto a WAN Virtual do Azure fornece um serviço de hub totalmente entrelaçado sem intervenção manual com o qual os clientes conectam os vários pontos de extremidade spokes (VNet do Azure, branches locais com VPN site a site ou SDWAN, usuários remotos com VPN de usuário remoto/ponto a site e conexões privadas com o ExpressRoute) e aproveitam o emparelhamento via protocolo BGP para NVAs implantadas na VNet spoke junto com outras funcionalidades de vWAN, como conectividade de trânsito para VNet a VNet, conectividade de trânsito entre VPN e o ExpressRoute, roteamento personalizado/avançado, associação e propagação de rota personalizada, intenção/políticas de roteamento para segurança inter-regional sem complicações, hub seguro/Firewall do Azure etc. Para obter mais detalhes sobre o emparelhamento via protocolo BGP da WAN Virtual, confira Como fazer o emparelhamento via protocolo BGP com um hub virtual.
Se eu estou usando um provedor de segurança de terceiros (Zscaler, iBoss ou Checkpoint) para proteger o tráfego da Internet, por que o site da VPN associado ao provedor de segurança de terceiros não aparece no portal do Azure?
Quando você opta por implantar um provedor de parceiro de segurança para proteger o acesso à Internet para seus usuários, o provedor de segurança de terceiros cria um site de VPN em seu nome. Como o provedor de segurança de terceiros é criado automaticamente pelo provedor e não é um site VPN criado pelo usuário, esse site VPN não aparece no portal do Azure.
Para saber mais sobre as opções disponíveis de provedores de segurança de terceiros e como configurá-las, confira Implantar um provedor de parceiro de segurança.
As comunidades do BGP geradas pelo local serão preservadas na WAN Virtual?
Sim, as comunidades do BGP geradas pelo local serão preservadas na WAN Virtual. Você pode usar ASNs públicos próprios ou ASNs privados para as redes locais. Não é possível usar os intervalos reservados pelo Azure nem pela IANA:
- ASNs reservados pelo Azure:
- ASNs públicos: 8074, 8075, 12076
- ASNs privados: 65515, 65517, 65518, 65519, 65520
- ASNs reservados pelo IANA: 23456, 64496-64511, 65535-65551
Tem como alterar o ASN para um gateway de VPN?
Não. A WAN Virtual não dá suporte a alterações ASN para gateways de VPN.
Na WAN Virtual, qual é o desempenho estimado pelo SKU do gateway do ExpressRoute?
| Unidades da escala | Conexões por segundo | Megabits por segundo | Pacotes por segundo |
|---|---|---|---|
| 1 unidade de escala |
14.000 | 2\.000 | 200.000 |
| 2 unidades de escala |
28.000 | 4.000 | 400.000 |
| 3 unidades de escala |
42.000 | 6.000 | 600.000 |
| 4 unidades de escala |
56.000 | 8,000 | 800.000 |
| 5 unidades de escala |
70.000 | 10.000 | 1\.000.000 |
| 6 unidades de escala |
84.000 | 12.000 | 1.200.000 |
| 7 unidades de escala |
98.000 | 14.000 | 1.400.000 |
| 8 unidades de escala |
112.000 | 16.000 | 1.600.000 |
| 9 unidades de escala |
126.000 | 18.000 | 1.800.000 |
| 10 unidades de escala |
140.000 | 20.000 | 2.000.000 |
Unidades de escala de 2 a 10, durante as operações de manutenção, mantêm a taxa de transferência agregada. No entanto, a unidade de escala 1, durante uma operação de manutenção, pode observar uma pequena variação nos números da taxa de transferência.
Se eu conectar um circuito do ExpressRoute Local a um hub de WAN Virtual, só conseguirei acessar regiões no mesmo local metro que o circuito local?
Os circuitos locais só podem ser conectados aos gateways do ExpressRoute na região do Azure correspondente. No entanto, não há nenhuma limitação para rotear o tráfego para redes virtuais spoke em outras regiões.
Por que estou vendo uma mensagem e um botão chamado "Atualizar roteador para a versão mais recente do software" no portal?
Observação
A partir de janeiro de 2024, a equipe de WAN Virtual começou a atualizar hubs virtuais para a versão mais recente. Se você não atualizou o hub, mas agora percebe que a versão do roteador do hub diz “mais recente”, o hub foi atualizado pela equipe de WAN Virtual.
A infraestrutura baseada em Serviços de Nuvem em todo o Azure é preterida. Como consequência, a equipe da WAN Virtual está trabalhando na atualização dos roteadores virtuais na atual infraestrutura dos Serviços de Nuvem para implantações baseadas em Conjuntos de Dimensionamento de Máquinas Virtuais. Todos os Hubs Virtuais recém-criados serão implantados automaticamente na infraestrutura mais recente baseada em Conjuntos de Dimensionamento de Máquinas Virtuais. Se você navegar até o recurso de hub da WAN Virtual e observar essa mensagem e esse botão, poderá atualizar o roteador para a última versão clicando no botão. Se você quiser aproveitar os novos recursos da WAN Virtual, como o emparelhamento via protocolo BGP com o hub, será preciso atualizar o roteador do hub virtual pelo portal do Azure. Se o botão não estiver visível, abra um caso de suporte.
Você só poderá atualizar o roteador do hub virtual se todos os recursos (gateways, tabelas de rotas e conexões VNet) no hub estiverem em um estado bem-sucedido. Verifique se todas as suas redes virtuais spoke estão em assinaturas ativas/habilitadas e se as redes virtuais spoke não foram excluídas. Além disso, como essa operação requer a implantação de novos roteadores de hub virtual baseados em conjuntos de dimensionamento de máquinas virtuais, você enfrentará um tempo de inatividade esperado de 1 a 2 minutos para o tráfego de VNet para VNet por meio do mesmo hub e de 5 a 7 minutos para todos os outros fluxos de tráfego por meio do hub. Em um único recurso de WAN Virtual, os hubs devem ser atualizados um de cada vez, em vez de atualizar vários ao mesmo tempo. Quando a Versão do Roteador informa "Mais recente", o hub está atualizado. Não haverá alterações de comportamento de roteamento após essa atualização.
Há várias coisas a serem observadas com a atualização do roteador do hub virtual:
Se você já tiver configurado o emparelhamento BGP entre o hub da WAN Virtual e uma NVA em uma VNet spoke, precisará excluir e recriar o par BGP. Como os endereços IP do roteador do hub virtual são alterados após o upgrade, você também precisará reconfigurar sua NVA para emparelhar com os novos endereços IP do roteador do hub virtual. Esses endereços IP são representados como o campo "virtualRouterIps" no JSON de Recurso do Hub Virtual.
Se você tiver um dispositivo virtual de rede (NVA) no hub virtual, precisará trabalhar com o parceiro do NVA para obter instruções sobre como atualizar o hub da WAN Virtual.
Se o hub virtual estiver configurado com mais de 15 unidades de infraestrutura de roteamento, reduza horizontalmente seu hub virtual para duas unidades de infraestrutura de roteamento antes de tentar atualizar. Você pode escalar de volta o hub para mais de 15 unidades de infraestrutura de roteamento depois de atualizar o hub.
Se a atualização falhar por qualquer motivo, o hub será recuperado automaticamente para a versão antiga para garantir que ainda haja uma configuração em funcionamento.
Informações adicionais importantes:
O usuário precisará ter uma função de proprietário ou colaborador para ver um status preciso da versão do roteador do hub. Se um usuário tiver uma função de leitor atribuída ao recurso e assinatura da WAN Virtual, o portal do Azure informará ao usuário que o roteador do hub precisa ser atualizado para a versão mais recente, mesmo que o roteador do hub já esteja nessa versão.
Se você alterar a assinatura da rede virtual spoke status de desabilitada para habilitada e atualizar o hub virtual, será necessário atualizar sua conexão de rede virtual após a atualização do hub virtual (por exemplo, você pode configurar a conexão de rede virtual para propagar para um rótulo fictício).
Se o hub estiver conectado a um grande número de redes virtuais spoke (60 ou mais), você poderá notar que 1 ou mais emparelhamentos de VNet spoke entrarão em um estado com falha após a atualização. Para restaurar esses emparelhamentos de VNet a um estado bem-sucedido após a atualização, você pode configurar as conexões de rede virtual para se propagarem para um rótulo fictício ou pode excluir e recriar essas respectivas conexões de VNet.
Há um limite de rota para clientes OpenVPN que se conectam a um gateway de VPN P2S do Azure?
O limite de rota para clientes OpenVPN é 1.000.
Como o SLA da WAN Virtual é calculado?
A WAN Virtual é uma plataforma de rede como serviço que tem um SLA de 99,95%. No entanto, a WAN Virtual combina vários componentes diferentes, como Firewall do Azure, VPN site a site, ExpressRoute, VPN ponto a site e hub/soluções de virtualização de rede integradas da WAN Virtual.
O SLA de cada componente é calculado individualmente. Por exemplo, se o ExpressRoute tiver um tempo de inatividade de 10 minutos, a disponibilidade do ExpressRoute será calculada como (Máximo de Minutos Disponíveis – tempo de inatividade) / Máximo de Minutos Disponíveis * 100.
Você pode alterar o espaço de endereço da VNet em uma VNet spoke conectada ao hub?
Sim, isso pode ser feito automaticamente sem necessidade de nenhuma atualização ou redefinição na conexão de emparelhamento. Você pode encontrar mais informações sobre como alterar o espaço de endereço da VNet aqui.
Manutenção de gateway controlada pelo cliente da WAN Virtual
Quais serviços estão incluídos no escopo da Configuração de Manutenção de Gateways de Rede?
Para WAN Virtual, você pode configurar janelas de manutenção para gateways de VPN site a site e gateways do ExpressRoute.
Qual manutenção tem ou não tem suporte da manutenção controlada pelo cliente?
Os serviços do Azure passam por atualizações de manutenção periódicas para melhorar a funcionalidade, a confiabilidade, o desempenho e a segurança. Depois de configurar uma janela de manutenção para seus recursos, as manutenções de Sistema Operacional Convidado e de Serviço serão executadas durante essa janela. Essas atualizações representam a maioria dos itens de manutenção que causam preocupação para os clientes.
As atualizações de infraestrutura de datacenter e hardware de host subjacentes não são cobertas pela manutenção controlada pelo cliente. Além disso, se houver um problema de segurança de alta gravidade que possa colocar nossos clientes em risco, o Azure poderá precisar ignorar o controle do cliente sobre a janela de manutenção e implementar a alteração. Essas ocorrências são raras e devem ser usadas somente em casos extremos.
Posso receber uma notificação avançada da manutenção?
No momento, a notificação avançada não pode ser habilitada para a manutenção dos recursos do Gateway de Rede.
Posso configurar uma janela de manutenção com menos de cinco horas?
Neste momento, é necessário configurar uma janela de no mínimo cinco horas no fuso horário de sua preferência.
Posso configurar um agendamento de manutenção que não se repete diariamente?
Neste momento, é necessário configurar uma janela de manutenção diária.
Os recursos de Configuração de Manutenção precisam estar na mesma região que o recurso de gateway?
Sim.
Preciso implantar uma unidade de escala mínima de gateway para ser qualificada para manutenção controlada pelo cliente?
Não.
Quanto tempo leva para que a política de configuração de manutenção entre em vigor após ser atribuída ao recurso de gateway?
Pode levar até 24 horas para os Gateways de Rede seguirem o cronograma de manutenção após a política de manutenção ter sido associada ao recurso do gateway.
Como devo planejar janelas de manutenção ao usar a VPN e o ExpressRoute em um cenário de coexistência?
Ao trabalhar com a VPN e o ExpressRoute em um cenário de coexistência ou sempre que você tiver recursos atuando como backups, é recomendável configurar janelas de manutenção separadas. Essa abordagem garante que a manutenção não afete seus recursos de backup ao mesmo tempo.
Agendei uma janela de manutenção de um dos meus recursos para uma data futura. As atividades de manutenção serão pausadas nesse recurso até essa data?
Não, as atividades de manutenção não serão pausadas em seu recurso no período anterior ao da janela de manutenção agendada. Nos dias sem cobertura do agendamento de manutenção, a manutenção continuará no recurso normalmente.
Próximas etapas
Para saber mais sobre a WAN Virtual, confira Sobre a WAN Virtual.