FAQ da WAN Virtual
A WAN Virtual do Azure está no GA?
Sim, a WAN Virtual do Azure está disponível em geral (GA). No entanto, a WAN Virtual consiste em vários recursos e cenários. Há recursos ou cenários na WAN Virtual em que a Microsoft aplica a marca de visualização. Nesses casos, o recurso específico, ou o cenário em si, está em Visualização. Se você não usar um recurso de visualização específico, o suporte regular do GA será aplicado. Para obter mais informações sobre o suporte à Pré-visualização, consulte Termos de Utilização Suplementares para Pré-visualizações do Microsoft Azure.
Que locais e regiões estão disponíveis?
Para obter informações, consulte Locais e regiões disponíveis.
O usuário precisa ter hub e falou com dispositivos SD-WAN/VPN para usar a WAN Virtual do Azure?
A WAN Virtual fornece muitas funcionalidades incorporadas em um único painel, como conectividade VPN site/site a site, conectividade User/P2S, conectividade ExpressRoute, conectividade de rede virtual, interconectividade VPN ExpressRoute, conectividade transitiva VNet-to-VNet, Roteamento centralizado, segurança do Firewall do Azure e do Firewall Manager, monitoramento, criptografia de Rota Expressa e muitos outros recursos. Você não precisa 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 WAN Virtual é uma arquitetura de hub e spoke com escala e desempenho integrados onde filiais (dispositivos VPN/SD-WAN), usuários (Clientes VPN do Azure, openVPN ou Clientes IKEv2), circuitos de Rota Expressa, redes virtuais servem como porta-vozes para hubs virtuais. Todos os hubs são conectados em malha completa em uma WAN Virtual Padrão, tornando mais fácil para o usuário usar o backbone da Microsoft para qualquer conectividade (qualquer falada). Para 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 Virtual WAN Partner CPE (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 WAN Virtual do Azure. Para conectividade VPN ponto-a-site/utilizador, suportamos o cliente VPN do Azure, OpenVPN ou cliente IKEv2.
Você pode desativar hubs totalmente entrelaçados em uma WAN Virtual?
A WAN Virtual vem em dois sabores: Basic 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 interligados e conectados automaticamente quando a WAN virtual é configurada pela primeira vez. O usuário não precisa fazer nada específico. O usuário também não precisa desativar ou habilitar a funcionalidade para obter hubs de malha. A WAN virtual fornece muitas opções de roteamento para direcionar o tráfego entre qualquer spoke (VNet, VPN ou ExpressRoute). Ele fornece a facilidade de hubs totalmente interligados e também a flexibilidade de roteamento de tráfego de acordo com suas necessidades.
Como as zonas de disponibilidade e a resiliência são tratadas na WAN virtual?
A WAN virtual é uma coleção de hubs e serviços disponibilizados dentro do hub. O usuário pode ter quantas WAN virtuais por sua necessidade. Em um hub WAN virtual, há vários serviços como VPN, ExpressRoute, etc. Cada um desses serviços é 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, o que acionará uma implantação da Zona de Disponibilidade. Todos os gateways são provisionados em um hub como ativo-ativo, o que implica que há resiliência interna em um hub. Os usuários podem se conectar a vários hubs se quiserem resiliência entre regiões.
Atualmente, o Firewall do Azure pode ser implantado para dar suporte a Zonas de Disponibilidade usando o Portal do Gerenciador de Firewall do Azure, PowerShell ou CLI. Atualmente, não é possível configurar um Firewall existente para ser implantado em zonas de disponibilidade. Você precisará excluir e reimplantar seu Firewall do Azure.
Embora o conceito de WAN Virtual seja global, o recurso de WAN Virtual real é baseado no Gerenciador de Recursos e implantado regionalmente. Se a própria região WAN virtual tiver um problema, todos os hubs nessa WAN virtual continuarão a funcionar como estão, mas o usuário não poderá criar novos hubs até que a região WAN virtual esteja disponível.
É possível compartilhar o Firewall em um hub protegido com outros hubs?
Não, cada Hub Virtual do Azure deve ter seu próprio Firewall. A implantação de rotas personalizadas para apontar o Firewall de outro hub seguro falhará e não será concluída com êxito. Por favor, considere converter esses hubs em hubs seguros com seus próprios firewalls.
Que cliente suporta a VPN (ponto a site) do Utilizador WAN Virtual do Azure?
A WAN Virtual suporta o cliente VPN do Azure, o Cliente OpenVPN ou qualquer cliente IKEv2. A autenticação Microsoft Entra é suportada com o Cliente VPN do Azure.É necessário um mínimo de SO cliente Windows 10 versão 17763.0 ou superior. O(s) cliente(s) OpenVPN pode(m) suportar autenticação baseada em certificado. Assim que a autenticação baseada em certificado for selecionada no gateway, você verá o arquivo .ovpn* para baixar para o seu dispositivo. O IKEv2 suporta autenticação de certificado e RADIUS.
Para 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 acontece para que cada instância de gateway possa alocar de forma independente IPs de cliente para clientes conectados e o tráfego da rede virtual seja roteado de volta para a instância de gateway correta para evitar salto de instância entre gateways.
Como faço para adicionar servidores DNS para clientes P2S?
Há duas opções para adicionar servidores DNS para os clientes P2S. O primeiro método é preferido, pois adiciona os servidores DNS personalizados ao gateway em vez do cliente.
Use o seguinte script do PowerShell para adicionar os servidores DNS personalizados. Substitua os valores do 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 estiver usando o Cliente VPN do Azure para Windows 10, você pode modificar o arquivo XML de perfil baixado e adicionar as <tags dnsservers><dnsserver<>/dnsserver></dnsservers> antes de importá-lo.
<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?
A tabela abaixo descreve o número de conexões simultâneas e a taxa de transferência agregada do gateway VPN ponto a site suportado em unidades de escala diferentes.
| Unidade de Escala | Instâncias de gateway | Conexões simultâneas suportadas | 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 libras esterlinas |
| 7 | 2 | 5000 | 3,5 Gbps |
| 8 | 2 | 5000 | 4 libras esterlinas |
| 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 libras esterlinas |
| 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 | 80 000 | 80 Gbps |
| 180 | 18 | 90000 | 90 Gbps |
| 200 | 20 | 100000 | 100 Gbps |
Por exemplo, digamos que o usuário escolha 1 unidade de escala. Cada unidade de escala implicaria um gateway ativo-ativo implantado e cada uma das instâncias (neste caso 2) suportaria até 500 conexões. Como você pode obter 500 conexões * 2 por gateway, isso não significa que você planeja 1000 em vez das 500 para essa unidade de escala. As instâncias podem precisar de manutenção durante as quais a conectividade para os 500 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 são implantados para fornecer capacidade adicional para conectar usuários. Cada par de instâncias suporta até 10.000 usuários adicionais. Por exemplo, se você implantar um Gateway com 100 unidades de escala, 5 pares de gateway (10 instâncias totais) serão implantados e até 50.000 (10.000 usuários x 5 pares de gateway) usuários simultâneos poderão se conectar.
Além disso, certifique-se de planejar o tempo de inatividade caso decida aumentar ou diminuir a escala na unidade de escala ou alterar a configuração ponto a site 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 taxa de transferência agregada de um gateway no hub virtual. 1 unidade de escala de VPN = 500 Mbps. 1 unidade de escala de ExpressRoute = 2 Gbps. Exemplo: 10 unidade de escala de VPN implicaria 500 Mbps * 10 = 5 Gbps.
Qual é a diferença entre um gateway de rede virtual do Azure (Gateway VPN) e um gateway VPN WAN Virtual do Azure?
A WAN Virtual oferece conectividade site a site em grande escala e foi criada para débito, escalabilidade e facilidade de utilização. Quando você conecta um site a um gateway VPN WAN virtual, ele é diferente de um gateway de rede virtual comum que usa um tipo de gateway 'VPN site a site'. Quando você deseja conectar usuários remotos à WAN Virtual, use um tipo de gateway 'VPN ponto a site'. Os gateways VPN ponto a site e site a site são entidades separadas no hub WAN Virtual e devem ser implantados individualmente. Da mesma forma, quando você conecta um circuito de Rota Expressa a um hub de WAN Virtual, ele usa um recurso diferente para o gateway de Rota Expressa do que o gateway de rede virtual regular que usa o tipo de gateway 'Rota Expressa'.
A WAN virtual suporta taxa de transferência agregada de até 20 Gbps para VPN e ExpressRoute. A Virtual WAN também tem automação para conectividade com um ecossistema de parceiros de dispositivos de filial CPE. Os dispositivos de ramificação CPE têm automação interna que provisiona automaticamente e se conecta à WAN Virtual do Azure. Estes dispositivos estão disponíveis num ecossistema crescente de parceiros de SD-WAN e de VPN. Consulte a lista de parceiros preferenciais.
Qual é a diferença entre a WAN Virtual e um gateway de rede virtual do Azure?
Uma VPN de gateway de rede virtual é limitada a 100 túneis. Para as conexões, deve utilizar a WAN Virtual para uma VPN de grande escala. Você pode conectar até 1.000 conexões de filial 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 filiais a uma única Região do Azure implantando vários hubs WAN Virtuais nessa Região do Azure, cada um com seu próprio gateway VPN site a site.
Qual é o algoritmo recomendado e os pacotes por segundo por instância site a site no hub WAN virtual? Quantos túneis há suporte por instância? Qual é a taxa de transferência máxima suportada em um único túnel?
A WAN virtual suporta 2 instâncias ativas de gateway VPN site a site em um hub virtual. Isso significa que há 2 conjuntos ativos-ativos de instâncias de gateway VPN em um hub virtual. Durante as operações de manutenção, cada instância é atualizada uma a uma, devido à qual um usuário pode experimentar uma breve diminuição na taxa de transferência agregada de um gateway VPN.
Embora a VPN WAN Virtual suporte muitos algoritmos, nossa recomendação é GCMAES256 para criptografia IPSEC e integridade para um desempenho ideal. AES256 e SHA256 são considerados de menor desempenho e, portanto, a degradação do desempenho, como latência e quedas de pacotes, pode ser esperada para tipos de algoritmos semelhantes.
Pacotes por segundo ou PPS é um fator do total # de pacotes e da taxa de transferência suportada por instância. Isto é melhor entendido com um exemplo. Digamos que uma instância de gateway VPN site a site de 1 unidade de escala de 500 Mbps seja implantada em um hub WAN virtual. Supondo um tamanho de pacote de 1400, PPS esperado para essa instância de gateway vpn em um máximo = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.
Virtual WAN tem conceitos de conexão VPN, conexão de link e túneis. Uma única conexão VPN consiste em conexões de link. A WAN virtual suporta até 4 conexões de link em uma conexão VPN. Cada conexão de link consiste em dois túneis IPsec que terminam em duas instâncias de um gateway VPN ativo-ativo implantado em um hub virtual. O número total de túneis que podem ser encerrados em uma única instância ativa é 1000, o que também implica que a taxa de transferência para 1 instância estará disponível agregada em todos os túneis que se conectam a essa instância. Cada túnel também tem determinados valores de taxa de transferência. Em casos de vários túneis conectados a um gateway de unidade de escala de menor valor, é melhor avaliar a necessidade por túnel e planejar um gateway VPN que seja um valor agregado para taxa de transferência em todos os túneis que terminam na instância VPN.
Valores para várias unidades de escala suportadas na WAN Virtual
| Unidade de escala | Taxa de transferência máxima por túnel (Mbps) | PPS máximo por túnel | Taxa de transferência máxima por instância (Mbps) | PPS máximo por instância |
|---|---|---|---|---|
| 1 | 500 | 47K | 500 | 47K |
| 2 | 1000 | 94K | 1000 | 94K |
| 3 | 1500 | 140K | 1500 | 140K |
| 4 | 1500 | 140K | 2000 | 187K |
| 5 | 1500 | 140K | 2500 | 234K |
| 6 | 1500 | 140K | 3000 | 281K |
| 7 | 2300 | 215K | 3500 | 328K |
| 8 | 2300 | 215K | 4000 | 374K |
| 9 | 2300 | 215K | 4500 | 421K |
| 10 | 2300 | 215K | 5000 | 468K |
| 11 | 2300 | 215K | 5500 | 515K |
| 12 | 2300 | 215K | 6.000 | 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 | 796 MIL |
| 18 | 2300 | 215K | 9000 | 843K |
| 19 | 2300 | 215K | 9500 | 889K |
| 20 | 2300 | 215K | 10000 | 936K |
Nota
Todos os números são baseados no algoritmo GCM.
Quais provedores de dispositivos (parceiros de WAN virtual) 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.º Pode utilizar qualquer dispositivo compatível com VPN que cumpra os requisitos para suporte de IPsec de IKEv2/IKEv1. A WAN Virtual também tem soluções de parceiros CPE que automatizam a conectividade com a WAN Virtual do Azure, facilitando a configuração de conexõ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 automação inclui carregar informações de filial, baixar a configuração do Azure, configurar túneis IPsec em hubs virtuais do Azure e configurar automaticamente a conectividade do dispositivo de filial para a WAN Virtual do Azure. Quando você tem centenas de filiais, conectar-se usando Parceiros CPE de WAN Virtual é fácil porque a experiência de integração elimina a necessidade de configurar, configurar e gerenciar a conectividade IPsec em grande escala. Para mais informações, veja Automatização de parceiro de WAN Virtual.
E se um dispositivo que estou a utilizar não estiver na lista de parceiros da WAN Virtual? Ainda posso usá-lo para me conectar à VPN WAN Virtual do Azure?
Sim, desde que o dispositivo suporte IPsec IKEv1 ou IKEv2. Os parceiros de WAN virtual automatizam a conectividade do dispositivo para os pontos finais da VPN do Azure. Isso implica automatizar etapas como 'upload de informações de filial', 'IPsec e configuração' e 'conectividade'. Como seu dispositivo não é de um ecossistema de parceiros de WAN Virtual, você precisará fazer o trabalho pesado de pegar manualmente a configuração do Azure e atualizar seu dispositivo para configurar a conectividade IPsec.
Como é que os novos parceiros que não estão listados na sua lista de parceiros de lançamento são integrados?
Todas as APIs WAN virtuais são OpenAPI. Você pode examinar a documentação Virtual WAN partner automation 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 que a empresa tenha concluído o trabalho de automação para seu dispositivo CPE com base nas diretrizes de automação fornecidas acima, você pode entrar em contato para azurevirtualwan@microsoft.com ser listado aqui Conectividade através de parceiros. Se você é um cliente que gostaria que uma determinada solução da empresa fosse listada como um parceiro de WAN Virtual, peça à empresa que entre em contato com a WAN Virtual enviando um e-mail para azurevirtualwan@microsoft.com.
Como a WAN Virtual está suportando dispositivos SD-WAN?
Os parceiros de WAN virtual automatizam a conectividade IPsec para pontos finais de VPN do Azure. Se o parceiro de WAN Virtual for um provedor de SD-WAN, estará implícito que o controlador SD-WAN gerencia a automação e a conectividade IPsec com os pontos finais da VPN do Azure. Se o dispositivo SD-WAN exigir seu próprio ponto de extremidade em vez da VPN do Azure para qualquer funcionalidade proprietária da SD-WAN, 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 suporta emparelhamento BGP e também tem a capacidade de implantar NVAs em um hub WAN virtual.
Quantos dispositivos VPN podem se conectar a um único hub?
Até 1.000 conexões são suportadas por hub virtual. Cada conexão consiste em quatro links e cada conexão de link suporta dois túneis que estão em uma configuração ativa-ativa. Os túneis terminam em um gateway VPN de hub virtual do Azure. Os links representam o link físico do ISP na filial/dispositivo VPN.
O que é uma conexão de filial com a WAN Virtual do Azure?
Uma conexão de uma filial ou dispositivo VPN na WAN Virtual do Azure é uma conexão VPN que conecta virtualmente o site VPN e o gateway VPN do Azure em um hub virtual.
O que acontece se o dispositivo VPN local tiver apenas 1 túnel para um gateway de VPN WAN Virtual do Azure?
Uma conexão WAN Virtual do Azure é composta por 2 túneis. Um gateway VPN WAN virtual é implantado em um hub virtual no modo ativo-ativo, o que implica que há túneis separados de dispositivos locais terminando em instâncias separadas. Esta é a recomendação para todos os utilizadores. No entanto, se o usuário optar por ter apenas 1 túnel para uma das instâncias do gateway VPN WAN Virtual, se por qualquer motivo (manutenção, patches, etc.) a instância do 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 VPN WAN Virtual?
O botão Redefinição de Gateway deve ser usado se todos os dispositivos locais estiverem funcionando conforme o esperado, mas a conexão VPN site a site no Azure estiver em um estado Desconectado. Os gateways VPN de WAN virtual são sempre implantados em um estado Ativo-Ativo para alta disponibilidade. Isso significa que sempre há mais de uma instância implantada em um gateway VPN a qualquer momento. Quando o botão Redefinição de Gateway é usado, ele reinicializa as instâncias no gateway VPN de forma sequencial para que suas conexões não sejam interrompidas. Haverá um breve intervalo à medida que as conexões passarem 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 alterará seus IPs públicos.
Esse cenário só se aplica às conexões S2S.
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 Microsoft mais próxima e, em seguida, para o hub virtual.
Existem novos recursos do Resource Manager disponíveis para a WAN Virtual?
Sim, a WAN Virtual tem novos recursos do Resource Manager. Para obter mais informações, consulte Descrição Geral.
Posso implantar e usar meu dispositivo virtual de rede favorito (em uma rede virtual 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 um dispositivo virtual de rede dentro do hub virtual?
Um Network Virtual Appliance (NVA) pode ser implantado dentro de um hub virtual. Para conhecer as etapas, consulte Sobre NVAs em um hub WAN virtual.
Uma VNet falada pode ter um gateway de rede virtual?
N.º A VNet spoke não pode ter um gateway de rede virtual se estiver conectada ao hub virtual.
Uma VNet falada pode ter um Servidor de Rotas do Azure?
N.º A VNet spoke não pode ter um Route Server se estiver conectada ao hub WAN virtual.
Existe suporte para BGP na conectividade VPN?
Sim, o BGP é suportado. Ao criar um site VPN, você pode fornecer os parâmetros BGP nele. Isso implica que todas as conexões criadas no Azure para esse site serão habilitadas 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 uma WAN Virtual com um hub e um vpnsite pode ser criada usando um modelo de início rápido. A WAN virtual é principalmente um serviço REST ou orientado por portal.
As VNets spoke conectadas a um hub virtual podem se comunicar entre si (V2V Transit)?
Sim. A WAN Virtual Padrão suporta conectividade transitiva VNet-to-VNet através do hub WAN Virtual ao qual as VNets estão conectadas. Na terminologia da WAN virtual, nos referimos a esses caminhos como "trânsito VNet WAN virtual local" para VNets conectadas a um hub WAN virtual dentro de uma única região e "trânsito VNet WAN virtual global" para VNets conectadas por meio de vários hubs WAN virtual em duas ou mais regiões.
Em alguns cenários, as VNets spoke também podem ser emparelhadas diretamente umas com as outras usando emparelhamento de rede virtual, além do trânsito VNet WAN virtual local ou global. Nesse caso, o emparelhamento VNet tem precedência sobre a conexão transitiva por meio do hub WAN virtual.
A conectividade entre ramificações é permitida na WAN Virtual?
Sim, a conectividade entre ramificações está disponível na WAN Virtual. A ramificação é conceitualmente aplicável a sites VPN, circuitos de Rota Expressa ou usuários de VPN ponto-a-site/usuário. A habilitação de ramificação para ramificação é habilitada por padrão e pode ser localizada nas definições de configuração da WAN. Isso permite que filiais/usuários VPN se conectem a outras filiais VPN e a conectividade de trânsito também é habilitada entre usuários VPN e ExpressRoute.
O tráfego de filial para filial atravessa a WAN Virtual do Azure?
Sim. O tráfego de filial a filial atravessa a WAN Virtual do Azure.
A WAN Virtual requer a Rota Expressa de cada site?
N.º A WAN virtual não requer a Rota Expressa de cada site. Seus sites podem estar conectados a uma rede de provedores usando um circuito de Rota Expressa. Para sites conectados usando a Rota Expressa a um hub virtual e VPN IPsec no mesmo hub, o hub virtual fornece conectividade de trânsito entre a VPN e o usuário da Rota Expressa.
Existe uma taxa de transferência de rede ou limite de conexão ao usar a WAN Virtual do Azure?
A taxa de transferência de rede é por serviço em um hub WAN virtual. Em cada hub, a taxa de transferência agregada de VPN é de até 20 Gbps, a taxa de transferência agregada de Rota Expressa é de até 20 Gbps e a taxa de transferência agregada de VPN de usuário/ponto a site é de até 200 Gbps. O roteador no hub virtual suporta até 50 Gbps para fluxos de tráfego VNet-to-VNet e assume um total de 2000 cargas de trabalho VM em todas as VNets conectadas a um único hub virtual.
Para garantir a capacidade inicial sem ter que esperar que o hub virtual se expanda quando mais taxa de transferência for necessária, você pode definir a capacidade mínima ou modificar conforme necessário. Consulte Sobre configurações de hub virtual - capacidade do hub. Para implicações de custo, consulte Custo unitário da infraestrutura de roteamento na página Preços da WAN Virtual do Azure.
Quando os sites VPN se conectam a um hub, eles o fazem com conexões. A WAN virtual suporta até 1000 conexões ou 2000 túneis IPsec por hub virtual. Quando os usuários remotos se conectam ao hub virtual, eles se conectam ao gateway VPN P2S, que suporta até 100.000 usuários, dependendo da unidade de escala (largura de banda) escolhida para o gateway VPN P2S no hub virtual.
Posso usar o NAT-T nas minhas conexões VPN?
Sim, a travessia NAT (NAT-T) é suportada. O gateway VPN WAN Virtual NÃO executará nenhuma funcionalidade semelhante a NAT nos pacotes internos de/para os túneis IPsec. 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?
Vá para o gateway VPN dentro de um hub no portal e, em seguida, 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 um único túnel VPN?
As soluções de dispositivo local podem aplicar políticas de tráfego para direcionar o tráfego através de vários túneis para o hub WAN Virtual do Azure (gateway VPN no hub virtual).
O que é arquitetura de trânsito global?
Para obter informações, consulte Arquitetura de 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: branch device -ISP-Microsoft> network edge-Microsoft> DC (hub VNet)->Microsoft network edge-ISP-branch>> device>
Neste modelo, do que precisa em cada site? Apenas uma ligação à internet?
Sim. Uma ligação à Internet e um dispositivo físico que suporte IPsec, de preferência dos nossos parceiros WAN virtuais integrados. Opcionalmente, pode gerir manualmente a configuração e a conectividade com o Azure a partir do seu dispositivo preferido.
Como faço para habilitar a rota padrão (0.0.0.0/0) para uma conexão (VPN, Rota Expressa ou rede virtual)?
Um hub virtual pode propagar uma rota padrão aprendida para uma conexão VPN/Rota Expressa de rede virtual/site a site se o sinalizador estiver '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 de Rota Expressa. Por padrão, esse sinalizador é desativado quando um site ou um circuito de Rota Expressa está 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 se origina no hub WAN Virtual; a rota padrão será propagada se já tiver sido aprendida pelo hub WAN Virtual como resultado da implantação de um firewall no hub ou se outro site conectado tiver o encapsulamento forçado habilitado. Uma rota padrão não se propaga entre hubs (inter-hub).
É possível criar vários hubs WAN virtuais na mesma região?
Sim. Os clientes agora podem criar mais de um hub na mesma região para a mesma 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, consulte a página de preferências de roteamento do hub virtual.
O hub WAN Virtual permite conectividade entre circuitos de Rota Expressa?
O trânsito entre ER-to-ER é sempre através do alcance Global. Os gateways de hub virtual são implantados em regiões DC ou Azure. Quando dois circuitos ExpressRoute se conectam via alcance global, não há necessidade de o tráfego vir de todos os roteadores de borda para o DC do hub virtual.
Existe um conceito de peso nos circuitos de Rota Expressa da WAN Virtual do Azure ou nas conexões VPN
Quando vários circuitos de Rota Expressa são conectados a um hub virtual, o peso de roteamento na conexão fornece um mecanismo para que a Rota Expressa no hub virtual prefira um circuito sobre o outro. Não há nenhum mecanismo para definir um peso em uma conexão VPN. O Azure sempre prefere uma conexão de Rota Expressa a uma conexão VPN em um único hub.
A WAN Virtual prefere a Rota Expressa à VPN para o Azure de saída de tráfego
Sim. A WAN Virtual prefere a Rota Expressa à VPN para a saída de tráfego do Azure. No entanto, você pode configurar a preferência de roteamento do hub virtual para alterar a preferência padrão. Para conhecer as etapas, consulte Configurar preferência de roteamento de hub virtual.
Quando um hub WAN Virtual tem um circuito de Rota Expressa e um site VPN conectado a ele, o que faria com que uma rota de conexão VPN fosse preferida em relação à Rota Expressa?
Quando um circuito de Rota Expressa é 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 de Rota Expressa da WAN Virtual que, por sua vez, aprendem rotas do roteador de hub virtual que controla todas as rotas entre quaisquer gateways na WAN Virtual. Os roteadores do Microsoft Edge processam rotas de Rota Expressa de hub virtual com maior preferência em relação às rotas aprendidas localmente.
Por qualquer motivo, se a conexão VPN se tornar o principal meio para o hub virtual aprender rotas (por exemplo, cenários de failover entre a Rota Expressa e a VPN), a menos que o site VPN tenha um comprimento de caminho AS maior, o hub virtual continuará a compartilhar rotas aprendidas de VPN com o gateway da Rota Expressa. Isso faz com que os roteadores do Microsoft Edge prefiram rotas VPN em vez de rotas locais.
Quando dois hubs (hub 1 e 2) estão conectados e há um circuito ExpressRoute conectado como uma gravata borboleta a ambos os hubs, qual é o caminho para uma VNet conectada ao hub 1 chegar a uma VNet conectada no hub 2?
O comportamento atual é preferir o caminho do circuito ExpressRoute em vez de hub-to-hub para conectividade VNet-to-VNet. No entanto, isso não é incentivado em uma configuração de WAN Virtual. Para resolver isso, você pode fazer uma das duas coisas:
Configure vários circuitos de Rota Expressa (provedores diferentes) para se conectar a um hub e use a conectividade hub-to-hub fornecida pela WAN Virtual para fluxos de tráfego entre regiões.
Configure o AS-Path como a preferência de roteamento de hub para seu hub virtual. Isso garante que o tráfego entre os 2 hubs passe pelo roteador de hub virtual em cada hub e use o caminho hub-to-hub em vez do caminho ExpressRoute (que atravessa os roteadores do Microsoft Edge). Para obter mais informações, veja Configurar a preferência de encaminhamento do hub virtual.
Quando há um circuito de Rota Expressa conectado como uma gravata borboleta a um hub WAN Virtual e uma VNet autônoma, qual é o caminho para a VNet autônoma chegar ao hub WAN Virtual?
Para novas implantações, essa conectividade é bloqueada por padrão. Para permitir essa conectividade, você pode habilitar essas alternâncias de gateway de Rota Expressa 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 WAN Virtual. Depois, o tráfego de VNet para VNet atravessará o roteador de hub WAN Virtual, que oferece melhor desempenho do que o caminho da Rota Expressa. O caminho da Rota Expressa inclui o gateway da Rota Expressa, que tem limites de largura de banda mais baixos do que o roteador do hub, bem como os roteadores Microsoft Enterprise Edge/MSEE, que é um salto extra no caminho de dados.
No diagrama abaixo, ambas as alternâncias precisam ser habilitadas para permitir a conectividade entre a VNet 4 autônoma e as VNets diretamente conectadas ao hub 2 (VNet 2 e VNet 3): Permitir tráfego de redes WAN virtuais remotas para o gateway de rede virtual e Permitir tráfego de redes WAN não virtuais para o gateway ExpressRoute do hub virtual. Se um Servidor de Rotas do Azure for implantado na VNet 4 autônoma e o Servidor de Rotas tiver ramificação para ramificação habilitada, a conectividade será bloqueada entre a VNet 1 e a VNet 4 autônoma.
Ativar ou desativar a alternância afetará apenas o seguinte fluxo de tráfego: tráfego fluindo entre o hub WAN Virtual e VNet(s) autônoma(s) através do circuito ExpressRoute. Ativar ou desativar a alternância não incorrerá em tempo de inatividade para todos os outros fluxos de tráfego (por exemplo, o site local para a VNet spoke 2 não será afetado, a VNet 2 para a VNet 3 não será afetada, etc.).
Os hubs podem ser criados em diferentes grupos de recursos na WAN Virtual?
Sim. Atualmente, essa opção está disponível somente via PowerShell. O portal da WAN Virtual requer que os hubs estejam no mesmo grupo de recursos que o próprio recurso da WAN Virtual.
Qual é o espaço de endereço de hub recomendado durante a criação do hub?
O espaço de endereço do hub WAN virtual recomendado é /23. O hub WAN virtual atribui sub-redes a vários gateways (Rota Expressa, VPN site a site, VPN ponto a site, Firewall do Azure, Roteador de hub virtual). Para cenários em que os NVAs são implantados dentro de um hub virtual, um /28 normalmente é esculpido para as instâncias NVA. No entanto, se o usuário provisionar vários NVAs, uma sub-rede /27 pode ser atribuída. Portanto, tendo em mente uma arquitetura futura, enquanto os hubs WAN virtuais são implantados com um tamanho mínimo de /24, o espaço de endereço de hub recomendado no momento da criação para a entrada do usuário é /23.
Existe suporte para IPv6 na WAN Virtual?
O IPv6 não é suportado no hub WAN Virtual e seus gateways. Se você tiver uma VNet que tenha suporte a IPv4 e IPv6 e quiser conectar a VNet à WAN Virtual, esse cenário não é suportado no momento.
Para o cenário de VPN de usuário ponto a site com fuga de internet via Firewall do Azure, você provavelmente terá que desativar a conectividade IPv6 em seu dispositivo cliente para forçar o tráfego para o hub WAN Virtual. Isso ocorre porque os dispositivos modernos, por padrão, usam endereços IPv6.
Qual é a versão de API recomendada para ser usada por scripts que automatizam várias funcionalidades da WAN Virtual?
É necessária uma versão mínima de 05-01-2022 (1 de maio de 2022).
Existem limites de WAN Virtual?
Consulte a seção Limites de WAN virtual na página Limites de assinatura e serviço.
Quais são as diferenças entre os tipos de WAN Virtual (Basic e Standard)?
Consulte WANs virtuais básicas e padrão. Para saber os preços, consulte a página Preços .
A WAN Virtual armazena dados de clientes?
N.º A WAN virtual não armazena dados de clientes.
Existem Provedores de Serviços Gerenciados que podem gerenciar a WAN Virtual para usuários como um serviço?
Sim. Para obter uma lista de soluções de Provedor de Serviços Gerenciados (MSP) habilitadas por meio do Azure Marketplace, consulte Ofertas do Azure Marketplace por parceiros MSP do Azure Networking.
Qual é a diferença entre o roteamento do hub WAN Virtual e o Servidor de Rotas do Azure em uma rede virtual?
O hub WAN Virtual do Azure e o Azure Route Server fornecem recursos de emparelhamento BGP (Border Gateway Protocol) que podem ser utilizados por NVAs (Network Virtual Appliance) para anunciar endereços IP do NVA para as redes virtuais do Azure do usuário. As opções de implantação diferem no sentido de que o Azure Route Server normalmente é implantado por uma VNet de hub do cliente autogerenciada, enquanto a WAN Virtual do Azure fornece um serviço de hub de malha total de zero toque ao qual os clientes conectam seus vários pontos finais de raios (Azure VNet, filiais locais com VPN site a site ou SDWAN, usuários remotos com VPN de usuário ponto-a-site/remoto e conexões privadas com a Rota Expressa) e desfrutam do emparelhamento BGP para NVAs implantados na VNet spoke junto com outros vWAN recursos como conectividade de trânsito para VNet-to-VNet, conectividade de trânsito entre VPN e ExpressRoute, roteamento personalizado/avançado, associação e propagação de rota personalizada, intenção/políticas de roteamento para segurança entre regiões sem problemas, firewall Secure Hub/Azure etc. Para obter mais detalhes sobre o emparelhamento BGP da WAN Virtual, consulte Como emparelhar BGP com um hub virtual.
Se estiver a utilizar um fornecedor de segurança de terceiros (Zscaler, iBoss ou Checkpoint) para proteger o meu tráfego de Internet, por que não vejo o site VPN associado ao fornecedor de segurança de terceiros 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 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 aparecerá no portal do Azure.
Para obter mais informações sobre as opções disponíveis de provedores de segurança de terceiros e como configurá-lo, consulte Implantar um provedor de parceiro de segurança.
As comunidades BGP geradas pelo local serão preservadas na WAN Virtual?
Sim, as comunidades BGP geradas pelo local serão preservadas na WAN Virtual. Você pode usar seus próprios ASNs públicos ou privados para suas redes locais. Não é possível usar os intervalos reservados pelo Azure ou IANA:
- ASNs reservados pelo Azure:
- ASNs públicos: 8074, 8075, 12076
- ASNs privados: 65515, 65517, 65518, 65519, 65520
- ASNs reservados pela IANA: 23456, 64496-64511, 65535-65551
Existe uma maneira de alterar o ASN para um gateway VPN?
N.º A WAN virtual não suporta alterações ASN para gateways VPN.
Na WAN Virtual, o que são os desempenhos estimados pelo SKU do gateway do ExpressRoute?
| Unidade de escala | Conexões por segundo | Mega-Bits 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 | 6000 | 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 |
Dimensione as unidades de 2 a 10, durante as operações de manutenção, mantenha o rendimento agregado. No entanto, a unidade de escala 1, durante uma operação de manutenção, pode ver uma ligeira variação nos números de rendimento.
Se eu conectar um circuito Local de Rota Expressa a um hub WAN Virtual, só poderei acessar regiões no mesmo local de metrô que o circuito Local?
Os circuitos locais só podem ser conectados a gateways de Rota Expressa em sua região correspondente do Azure. No entanto, não há limitação para rotear o tráfego para redes virtuais faladas em outras regiões.
Por que estou a ver uma mensagem e um botão denominado “Atualizar router para a versão mais recente do software” no portal?
Nota
A partir de janeiro de 2024, a equipe da WAN Virtual começou a atualizar os hubs virtuais para a versão mais recente. Se você não atualizou seu hub, mas agora percebe que a versão do roteador do hub diz "mais recente", então seu hub foi atualizado pela equipe da WAN virtual.
A infraestrutura baseada em Serviços de Nuvem em todo o Azure está sendo preterida. Como resultado, a equipe da WAN Virtual tem trabalhado na atualização de roteadores virtuais de sua infraestrutura atual de Serviços de Nuvem para implantações baseadas em Conjuntos de Escala de Máquina Virtual. 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 do hub WAN Virtual e vir essa mensagem e botão, poderá atualizar seu roteador para a versão mais recente clicando no botão. Se você quiser aproveitar os novos recursos da WAN Virtual, como emparelhamento BGP com o hub, terá que atualizar seu roteador de hub virtual por meio do portal do Azure. Se o botão não estiver visível, abra um caso de suporte.
Você só poderá atualizar seu roteador de hub virtual se todos os recursos (gateways/tabelas de rotas/conexões VNet) em seu hub estiverem em um estado bem-sucedido. Certifique-se de que todas as suas redes virtuais spoke estão em subscrições ativas/ativadas e que as suas redes virtuais spoke não são eliminadas. Além disso, como essa operação requer a implantação de novos roteadores de hub virtual baseados em conjuntos de dimensionamento de máquina virtual, você enfrentará um tempo de inatividade esperado de 1 a 2 minutos para o tráfego de rede virtual para rede virtual através do mesmo hub e de 5 a 7 minutos para todos os outros fluxos de tráfego através do hub. Dentro de 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 diz "Mais recente", a atualização do hub é feita. Não haverá alterações no comportamento de roteamento após essa atualização.
Há várias coisas a observar com a atualização do roteador de hub virtual:
Se você já configurou o emparelhamento BGP entre seu hub WAN Virtual e um NVA em uma VNet falada, então você terá que excluir e, em seguida, recriar o par BGP. Como os endereços IP do roteador de hub virtual mudam após a atualização, você também terá que reconfigurar seu NVA para emparelhar com os novos endereços IP do roteador de hub virtual. Esses endereços IP são representados como o campo "virtualRouterIps" no JSON de recursos do Hub Virtual.
Se você tiver um dispositivo virtual de rede (NVA) no hub virtual, terá que trabalhar com seu parceiro NVA para obter instruções sobre como atualizar seu hub WAN virtual.
Se o hub virtual estiver configurado com mais de 15 unidades de infraestrutura de roteamento, dimensione o hub virtual para 2 unidades de infraestrutura de roteamento antes de tentar atualizar. Você pode reduzir o hub para mais de 15 unidades de infraestrutura de roteamento depois de atualizar o hub.
Se a atualização falhar por qualquer motivo, seu hub será recuperado automaticamente para a versão antiga para garantir que ainda haja uma configuração funcionando.
Aspetos adicionais a ter em conta:
O usuário precisará ter uma função de proprietário ou colaborador para ver um status preciso da versão do roteador de hub. Se for atribuída a um usuário uma função de leitor para o recurso e a assinatura da WAN Virtual, o portal do Azure exibirá a esse usuário que o roteador do hub precisa ser atualizado para a versão mais recente, mesmo que o hub já esteja na versão mais recente.
Se você alterar o status da assinatura da rede virtual spoke de desabilitado para habilitado e, em seguida, atualizar o hub virtual, precisará 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 se propagar para um rótulo fictício).
Se o seu hub estiver conectado a um grande número de redes virtuais spoke (60 ou mais), você poderá notar que 1 ou mais pares de VNet spoke entrarão em um estado de falha após a atualização. Para restaurar esses emparelhamentos VNet para um estado bem-sucedido após a atualização, você pode configurar as conexões de rede virtual para se propagar para um rótulo fictício ou pode excluir e recriar essas respetivas conexões VNet.
Existe 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 é 1000.
Como é calculado o SLA da WAN Virtual?
A Virtual WAN é uma plataforma de rede como serviço que tem um SLA de 99,95%. No entanto, a WAN Virtual combina muitos componentes diferentes, como o Firewall do Azure, VPN site a site, Rota Expressa, VPN ponto a site e Hub de WAN Virtual/Dispositivos Virtuais de Rede Integrada.
O SLA para cada componente é calculado individualmente. Por exemplo, se a Rota Expressa tiver um tempo de inatividade de 10 minutos, a disponibilidade da Rota Expressa 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 falada conectada ao hub?
Sim, isso pode ser feito automaticamente, sem necessidade de 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 VNet aqui.
Manutenção de gateway controlado pelo cliente de WAN virtual
Quais serviços estão incluídos no escopo Configuração de Manutenção de Gateways de Rede?
Para WAN Virtual, você pode configurar janelas de manutenção para gateways VPN site a site e gateways de Rota Expressa.
Que manutenção é suportada ou não pela 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, a manutenção do SO convidado e do serviço é executada durante essa janela. Essas atualizações são responsáveis pela maioria dos itens de manutenção que causam preocupação para os clientes.
As atualizações de hardware de host subjacente e de infraestrutura de datacenter 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 em risco nossos clientes, o Azure pode precisar substituir o controle do cliente da janela de manutenção e implantar a alteração. Estas são ocorrências raras que só seriam usadas em casos extremos.
Posso receber uma notificação antecipada 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 inferior a cinco horas?
Neste momento, você precisa configurar uma janela mínima de cinco horas no seu fuso horário preferido.
Posso configurar um cronograma de manutenção que não se repita diariamente?
Neste momento, você precisa 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 elegível para manutenção controlada pelo cliente?
N.º
Quanto tempo leva para que a política de configuração de manutenção entre em vigor depois de ser atribuída ao recurso de gateway?
Pode levar até 24 horas para que os Gateways de Rede sigam o cronograma de manutenção depois que a política de manutenção for associada ao recurso de gateway.
Como devo planejar as janelas de manutenção ao usar VPN e ExpressRoute em um cenário de coexistência?
Ao trabalhar com VPN e ExpressRoute em um cenário de coexistência ou sempre que você tiver recursos atuando como backups, recomendamos a configuração de 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 para uma data futura para um dos meus recursos. As atividades de manutenção serão pausadas neste recurso até lá?
Não, as atividades de manutenção não serão pausadas no seu recurso durante o período anterior à janela de manutenção agendada. Para os dias não cobertos no seu cronograma de manutenção, a manutenção continua como de costume no recurso.
Próximos passos
Para obter mais informações sobre a WAN Virtual, consulte Sobre a WAN Virtual.