Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
A WAN Virtual do Azure está em Disponibilidade Geral?
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 tag de pré-visualização. Nesses casos, o recurso específico, ou o cenário em si, está em Pré-visualização. Se não utilizar uma funcionalidade de pré-visualização específica, aplica-se o suporte normal do Google Analytics. 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 visualizar as regiões disponíveis para WAN Virtual, consulte Produtos disponíveis por região. Especifique o WAN Virtual como o nome do produto.
O utilizador precisa ter uma topologia hub-and-spoke com dispositivos SD-WAN/VPN para usar a WAN Virtual do Azure?
A WAN virtual oferece muitas funcionalidades integradas em um único painel de vidro. Isto inclui:
- Conectividade VPN de site para site
- Conectividade Utilizador/P2S
- Conectividade de Rota Expressa
- Conectividade de rede virtual
- Interconectividade VPN ExpressRoute
- Conetividade transitiva entre redes virtuais (VNet-to-VNet)
- Roteamento centralizado
- Segurança do Firewall do Azure e do Gerenciador de Firewall
- Monitoring
- Criptografia de Rota Expressa e
- Muitas outras capacidades
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), utilizadores (Clientes VPN do Azure, openVPN ou Clientes IKEv2), circuitos ExpressRoute e redes virtuais também servem como ramificações para hubs virtuais. Todos os hubs são conectados em configuração de malha completa numa malha WAN Virtual Padrão, tornando mais fácil para o utilizador usar o backbone da Microsoft para qualquer conectividade ponto a ponto (qualquer spoke). Para hub e spoke com dispositivos SD-WAN/VPN, os utilizadores podem configurá-los 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. É 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.
Por que estou vendo um erro sobre escopo inválido e autorização para executar operações em recursos de WAN virtual?
Se vir um erro no seguinte formato, certifique-se de que tem as seguintes permissões configuradas: Funções e permissões de WAN virtual
Formato da mensagem de erro: "O cliente com id {} de objeto não tem autorização para executar ação {} sobre o escopo {} ou o escopo é inválido. Para obter detalhes sobre as permissões necessárias, visite {}. Se o acesso tiver sido concedido recentemente, atualize as credenciais."
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, o PowerShell ou a CLI. Atualmente, não é possível configurar um Firewall existente para ser implantado em zonas de disponibilidade. Você precisa 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 da WAN virtual tiver um problema, todos os hubs nessa WAN virtual continuarão a funcionar. No entanto, o usuário não pode criar novos hubs até que a região WAN virtual esteja disponível.
Como faço para excluir ou limpar meus recursos de WAN Virtual?
Quando não precisar mais dos recursos que criou, exclua-os. Alguns dos recursos da WAN Virtual devem ser excluídos em uma determinada ordem devido a dependências. A conclusão da eliminação pode demorar cerca de 30 minutos.
Abra a WAN virtual que você criou.
Selecione um hub virtual associado à WAN virtual para abrir a página do hub.
Exclua todas as entidades de gateway seguindo a ordem abaixo para cada tipo de gateway. Isso pode levar 30 minutos para ser concluído.
VPN:
- Desconectar sites VPN
- Excluir conexões VPN
- Eliminar gateways VPN
ExpressRoute:
- Excluir conexões de Rota Expressa
- Excluir gateways de Rota Expressa
Repita para todos os hubs associados à WAN virtual.
Você pode excluir os hubs neste momento ou excluir os hubs mais tarde quando excluir o grupo de recursos.
Navegue até o grupo de recursos no portal do Azure.
Selecione Eliminar grupo de recursos. Isso exclui os outros recursos no grupo de recursos, incluindo os hubs e a WAN virtual.
É 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. Considere converter esses hubs em hubs seguros com seus próprios firewalls.
Que cliente é suportado pela VPN do utilizador (ponto a site) do Azure Virtual WAN?
A WAN Virtual suporta o cliente VPN do Azure, o Cliente OpenVPN ou qualquer cliente IKEv2. A autenticação do Microsoft Entra é suportada com o Cliente VPN do Azure. É necessário um mínimo de Windows 10 client OS 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 para utilizador, quantos clientes são suportados?
A tabela a seguir 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 | 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 1 unidade de escala. Cada unidade de escala implicaria na implementação de um gateway ativo-ativo, e cada instância (neste caso, 2) suportaria até 500 ligações. Como se pode obter 500 conexões * 2 por gateway, isso não significa que se planeie 1000 em vez das 500 para esta 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 planear para o tempo de inatividade caso decida aumentar ou diminuir a unidade de escala ou alterar a configuração ponto-a-site no gateway VPN.
Para a VPN de Utilizador (ponto a site), o aplicativo registado da Microsoft na Autenticação do Entra ID é suportado?
Sim, o aplicativo registrado pela Microsoft é suportado na WAN Virtual. Você pode migrar a sua VPN de Utilizador da aplicação registada manualmente para a aplicação registada pela Microsoft para uma conectividade mais segura.
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.
Você pode aumentar ou diminuir manualmente a unidade de escala do gateway com base em sua necessidade. Consulte Sobre as configurações do gateway WAN virtual para saber mais sobre as configurações do gateway.
Para obter mais informações sobre os limites de suporte para unidades de escala de gateway, consulte:
- Na Virtual WAN, quais são os desempenhos estimados pelo SKU do gateway ExpressRoute? para gateways ExpressRoute
- Qual é o algoritmo recomendado e os pacotes por segundo por instância site a site no hub WAN virtual? Quantos túneis são suportados por instância? Qual é a taxa de transferência máxima suportada em um único túnel? para Gateways VPN de Site para Site
- Para VPN de usuário (ponto a site) - quantos clientes são suportados? para Gateways VPN (ponto a site) do usuário
Qual é o impacto da alteração das unidades de escala de gateway para um gateway de Rota Expressa de WAN Virtual?
Ao alterar unidades de escala de gateway, esteja ciente das seguintes considerações:
Capacidade de tráfego: certifique-se de que as unidades de escala provisionadas possam dar suporte aos seus requisitos de tráfego.
Reconexões TCP: Você pode enfrentar reconexões TCP durante a alteração da unidade de escala, o que pode causar pequenas interrupções.
Impacto dos Pontos de Extremidade Privados: as alterações na unidade de escala podem afetar a conectividade dos Pontos de Extremidade Privados. Revise sua implantação e siga as práticas recomendadas descritas em Usar link privado na WAN virtual.
Para obter mais informações sobre unidades de escala de gateway e planejamento de capacidade, consulte Sobre configurações de gateway WAN virtual.
Qual é a diferença entre um gateway de rede virtual do Azure (Gateway VPN) e um gateway VPN WAN Virtual do Azure?
O WAN Virtual oferece conectividade sítio-a-sítio em grande escala e foi criado para largura de banda, escalabilidade e facilidade de utilização. Quando se conecta um site a um gateway VPN de WAN virtual, isto difere de um gateway de rede virtual comum que utiliza um tipo de gateway 'VPN de site a site'. Quando pretender conectar utilizadores remotos à WAN Virtual, utiliza um gateway do tipo '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 liga um circuito de ExpressRoute a um hub de WAN virtual, utiliza um recurso diferente para o gateway de ExpressRoute em relação ao gateway de rede virtual regular que utiliza o tipo de gateway 'ExpressRoute'.
A WAN virtual suporta taxa de transferência agregada de até 20 Gbps para VPN e ExpressRoute. A Virtual WAN também possui automação para conectividade com um ecossistema de parceiros de dispositivos CPE de sucursal. Os dispositivos de filial CPE têm automação incorporada 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 VPNs 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 em ambos os lados do dispositivo VPN local para o hub virtual. Você também pode ter vários hubs virtuais por região. Isso 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 de 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 são suportados 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 resultado do número total de pacotes e da largura de banda 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 capacidade de 500 Mbps seja implantada num hub WAN virtual. Supondo um tamanho de pacote de 1400, o PPS esperado para essa instância de gateway 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 consiste em conexões de link. A WAN virtual suporta até 4 conexões de link em uma conexão VPN. Cada ligação de link consiste em dois túneis IPsec que terminam em duas instâncias de um gateway VPN de alta disponibilidade, implantado num hub virtual. O número total de túneis que podem ser encerrados em uma única instância ativa é 1.000. Isso também implica que a taxa de transferência de uma instância está disponível agregada através de 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 múltiplos túneis conectados a um gateway de unidade de escala com menor valor, é melhor avaliar a necessidade por túnel e planear um gateway VPN que seja um valor agregado para a largura de banda em todos os túneis cujas terminações ocorrem 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 | 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 |
Note
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?
No. Pode utilizar qualquer dispositivo compatível com VPN que cumpra os requisitos da Azure 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 se tem centenas de filiais, conectar-se usando parceiros de CPE da WAN Virtual é fácil porque a experiência de integração elimina a necessidade de configurar, implementar e gerir 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 parceiro de WAN Virtual, você precisa 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 é aquele que tem um dispositivo que pode ser configurado para conectividade com IKEv1 ou IKEv2 IPsec. Assim que a empresa concluir o trabalho de automação para o seu dispositivo CPE com base nas diretrizes de automação anteriormente compartilhadas, pode entrar em contato com azurevirtualwan@microsoft.com para ser listado aqui em Conectividade por meio 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 de 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 o pareamento BGP e também tem a capacidade de implantar NVAs num hub da 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 está implantado num hub virtual em modo ativo-activo, o que implica que há túneis separados de dispositivos no local de origem que terminam 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 da 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 se movem entre instâncias.
O que acontece durante uma redefinição de gateway num gateway VPN de 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, redefinir os gateways não altera 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?
Yes. 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 a seguir, consulte Sobre as NVAs em um hub de WAN virtual.
Posso conectar uma rede virtual a um hub virtual em um locatário diferente?
Yes. Siga as orientações em Conectar redes virtuais entre locatários a um hub WAN virtual.
Uma VNet do tipo spoke pode ter um gateway de rede virtual?
No. 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?
No. A VNet spoke não pode ter um Servidor de Roteamento 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 estão habilitadas para BGP.
Existem informações de licenciamento ou de preços da WAN Virtual?
Yes. 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 comunicar-se entre si (V2V Transit)?
Yes. O Virtual WAN Standard suporta conectividade transitiva de VNet para VNet através do hub Virtual WAN ao qual as VNets estão conectadas. Na terminologia da WAN Virtual, referimo-nos a estes caminhos como "trânsito local da VNet na WAN Virtual" para VNets conectadas a um hub da WAN Virtual dentro de uma única região. "Global Virtual WAN VNet transit" é destinado a VNets ligadas através de múltiplos hubs de Virtual WAN em duas ou mais regiões.
Em alguns cenários, as VNets spoke podem também ser emparelhadas diretamente umas com as outras através de emparelhamento de rede virtual, além do trânsito de VNet em WAN virtual, seja 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. Branch é conceitualmente aplicável a sites VPN, circuitos ExpressRoute, ou utilizadores de VPN ponto-a-site/usuário. A comunicação entre sucursais está habilitada por padrão e pode ser localizada nas configurações da WAN. Isso permite que filiais e utilizadores de VPN se conectem a outras filiais VPN, e também ativa a conectividade de trânsito entre utilizadores de VPN e de ExpressRoute.
O tráfego de filial para filial atravessa a WAN Virtual do Azure?
Yes. O tráfego de filial a filial atravessa a WAN Virtual do Azure.
A Virtual WAN requer o ExpressRoute de cada localização?
No. A Rede WAN Virtual não requer o ExpressRoute de cada local. Os seus sites podem estar conectados a uma rede de fornecedores usando um circuito de ExpressRoute. 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 proteger a capacidade inicial sem 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, o fazem utilizando conexões. A WAN virtual suporta até 1.000 conexões ou 2.000 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 selecione a 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 local? Apenas uma ligação à internet?
Yes. 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?
Yes. Os clientes agora podem criar mais de um hub na mesma região para a mesma WAN Virtual do Azure.
Como é que o hub virtual numa WAN virtual seleciona o melhor caminho para uma rota a partir de múltiplos 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 ExpressRoute?
O trânsito entre ER-to-ER está disponível por meio de alcance global. Os gateways de hub virtual são implantados em regiões DC ou Azure. Quando dois circuitos ExpressRoute se conectam via Global Reach, não é necessário que o tráfego passe diretamente dos routers de borda para o datacenter do hub virtual.
A intenção de roteamento também pode ser usada com políticas de roteamento de tráfego privado para habilitar a conectividade de trânsito da Rota Expressa por meio de um dispositivo de segurança implantado no hub virtual.
Para obter mais informações, consulte Sobre o alcance global da WAN 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 ExpressRoute são conectados a um hub virtual, o peso de roteamento na conexão fornece um mecanismo para que o ExpressRoute no hub virtual prefira um circuito em relação ao 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 Virtual WAN prefere o ExpressRoute à VPN para o tráfego a sair do Azure.
Yes. A Rede WAN Virtual prefere o ExpressRoute à VPN para o escoamento 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 ExpressRoute é conectado a um hub virtual, os roteadores do Microsoft Edge são o primeiro nó para comunicação entre as instalações locais e o Azure. Esses roteadores de borda comunicam-se com os gateways ExpressRoute da WAN Virtual que, por sua vez, aprendem rotas do roteador de hub virtual que controla todos os caminhos entre quaisquer gateways na WAN Virtual. Os routers do Microsoft Edge processam as rotas de ExpressRoute de hub virtual com maior preferência em relação às rotas aprendidas nas instalações locais.
Por qualquer motivo, se a conexão VPN se tornar o meio principal para o hub virtual aprender as rotas (por exemplo, em cenários de failover entre ExpressRoute e VPN), a menos que o site VPN tenha um comprimento de caminho AS maior, o hub virtual continuará a compartilhar as rotas aprendidas de VPN com o gateway ExpressRoute. Isso faz com que os roteadores do Microsoft Edge prefiram rotas VPN em vez de rotas locais.
O ExpressRoute suporta roteamento ECMP (Equal-Cost Multi-Path) na WAN Virtual?
Quando 1 ou mais circuitos de Rota Expressa estão conectados a um hub de WAN Virtual, o ECMP permite que o tráfego de redes virtuais spoke para o local pela Rota Expressa seja distribuído em 2 circuitos de Rota Expressa (correspondentes a até 4 links de Rota Expressa) anunciando as mesmas rotas locais. Atualmente, o ECMP não está habilitado por padrão para hubs WAN virtuais. Para habilitar o ECMP para seu ambiente, você pode criar um mapa de rota para seu hub virtual. Quando você cria um mapa de rota, seu hub virtual é atualizado automaticamente para a versão de software mais recente que suporta ECMP, independentemente de esse mapa de rota ser aplicado em quaisquer conexões. Como resultado, você só precisa seguir as etapas de 1 a 7 em Como configurar mapas de rota. Se você não planeja usar o mapa de rota, pode excluí-lo depois que a etapa 7 for concluída, pois os hubs com um mapa de rota incorrerão em custo adicional. Recomendamos criar um mapa de rota em seu ambiente de teste e validar o roteamento e a conectividade antes de criar um mapa de rota em seu ambiente de produção.
Quando dois hubs (hub 1 e 2) estão conectados e há um circuito ExpressRoute ligado como uma gravata borboleta a ambos os hubs, qual é o caminho para uma VNet conectada ao hub 1 chegar a uma VNet conectada ao hub 2?
O comportamento atual é preferir o trajeto do circuito ExpressRoute em vez do hub para o hub para a conectividade entre VNets. 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 ExpressRoute conectado em configuração de 'bow-tie' a um hub WAN Virtual e a 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, pode activar essas opções de gateway de ExpressRoute na janela "Editar hub virtual" e na janela "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 entre redes VNet passará pelo hub do Virtual WAN, que oferece melhor desempenho do que o caminho do ExpressRoute. O caminho da Rota Expressa inclui:
- O gateway ExpressRoute, que tem limites de largura de banda mais baixos do que o roteador de hub
- e os roteadores Microsoft Enterprise Edge (MSEE), que são um salto extra no trajeto 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 opção afetará apenas o seguinte fluxo de tráfego: o tráfego fluindo entre o hub WAN Virtual e as 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.).
Quando atualizo uma conexão de Rota Expressa, isso afetará a conectividade de minhas outras conexões de Rota Expressa?
Quando você executa uma operação de criação, atualização ou exclusão em uma conexão de Rota Expressa, suas outras conexões de Rota Expressa parecerão estar em um estado de "atualização" no Portal. No entanto, a conectividade por meio dessas conexões de Rota Expressa não será afetada.
Por que a conectividade não funciona quando anuncio rotas com um ASN igual a 0 no AS-Path?
O Virtual WAN hub descarta rotas com um ASN igual a 0 no AS-Path. Para garantir que essas rotas sejam anunciadas com êxito no Azure, o AS-Path não deve incluir 0.
Os hubs podem ser criados em diferentes grupos de recursos na WAN Virtual?
Yes. 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 recomendado para um hub WAN Virtual é /23. É importante observar que o espaço de endereço do hub não pode ser modificado após a criação do hub. Para alterar o espaço de endereço do hub, você deve reimplantar o hub virtual, o que pode resultar em tempo de inatividade.
O hub WAN Virtual atribui automaticamente sub-redes do espaço de endereço especificado a vários serviços do Azure, incluindo:
- Roteador de hub virtual
- ExpressRoute
- VPN site a site
- VPN ponto a site
- Azure Firewall
Para cenários em que os NVAs (Network Virtual Appliances) são implantados dentro do hub virtual, uma sub-rede adicional é alocada para as instâncias NVA. Normalmente, uma sub-rede /28 costuma ser atribuída para um pequeno número de NVAs. No entanto, se vários NVAs forem provisionados, uma sub-rede /27 poderá ser alocada.
Para acomodar futuras necessidades de escalabilidade e arquitetura, embora o espaço de endereçamento mínimo para um hub WAN Virtual seja /24, é recomendável especificar um espaço de endereçamento /23 durante a criação do hub.
Existe suporte para IPv6 na WAN Virtual?
O IPv6 não é suportado no hub WAN Virtual e seus gateways. Se ligar uma rede virtual spoke com um intervalo de endereços de IPv6 ao Virtual WAN hub, somente a conectividade IPv4 com essa rede virtual spoke funcionará. A conectividade IPv6 com esta VNet spoke não é suportada.
Se você anunciar prefixos IPv6 no local, isso interromperá a conectividade IPv4 para seus recursos do Azure.
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?
Considere a secção Limites 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?
No. 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?
Yes. 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 do Azure Virtual WAN e o Azure Route Server oferecem capacidades de emparelhamento BGP (Border Gateway Protocol) que podem ser utilizadas por NVAs (Network Virtual Appliance) para anunciar os endereços IP a partir do NVA para as redes virtuais do Azure do utilizador. As opções de implantação diferem no sentido de que o Azure Route Server é normalmente implantado por uma VNet de hub autogerida pelo cliente, enquanto a WAN Virtual do Azure fornece um serviço de hub de malha total sem intervenção, ao qual os clientes conectam os seus vários pontos finais spokes (Azure VNet, filiais locais com VPN site-a-site ou SDWAN, utilizadores remotos com VPN de ponto-a-site/utilizador remoto e ligações privadas com ExpressRoute). Os clientes beneficiam do emparelhamento BGP para appliances de rede virtual (NVAs) implantados na VNet spoke, juntamente com outras capacidades do vWAN, 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, e intenções/políticas de roteamento para segurança inter-regiões sem complicações, 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.
As comunidades BGP geradas por pares BGP (em uma rede virtual anexada) serão preservadas na WAN virtual?
Sim, as comunidades BGP geradas por Peers BGP serão preservadas na WAN Virtual. As comunidades são preservadas no mesmo hub e nas conexões interhub. Isso também se aplica a cenários de WAN virtual usando políticas de intenção de roteamento.
Quais números ASN são suportados para redes locais conectadas remotamente que executam BGP?
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 os ASNs na WAN Virtual?
No. A WAN Virtual não suporta alterações ASN para Hubs Virtuais ou quaisquer gateways.
Na rede virtual, quais são os desempenhos estimados pelo gateway ExpressRoute SKU?
| Unidade de escala | Ligações por segundo | Megabits por segundo | Pacotes por segundo | Fluxos totais |
|---|---|---|---|---|
| 1 | 14,000 | 2,000 | 200,000 | 200,000 |
| 2 | 28,000 | 4,000 | 400,000 | 400,000 |
| 3 | 42,000 | 6,000 | 600,000 | 600,000 |
| 4 | 56,000 | 8,000 | 800,000 | 800,000 |
| 5 | 70,000 | 10,000 | 1,000,000 | 1,000,000 |
| 6 | 84,000 | 12,000 | 1,200,000 | 1,200,000 |
| 7 | 98,000 | 14,000 | 1,400,000 | 1,400,000 |
| 8 | 112,000 | 16,000 | 1,600,000 | 1,600,000 |
| 9 | 126,000 | 18,000 | 1,800,000 | 1,800,000 |
| 10 | 140,000 | 20,000 | 2,000,000 | 2,000,000 |
É importante considerar os seguintes pontos:
- Durante as operações de manutenção, as unidades de escala 2 a 10 mantêm seu rendimento agregado. No entanto, a unidade de escala 1 pode experimentar pequenas variações no rendimento durante essas operações.
- Independentemente do número de unidades de escala implantadas, se um único fluxo TCP exceder 1,5 Gbps, o desempenho do tráfego poderá diminuir.
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 ExpressRoute na sua região correspondente do Azure. No entanto, não há limitação para encaminhar o tráfego para redes virtuais spoke em outras regiões.
Por que o roteador de hub virtual requer um endereço IP público com portas abertas?
Esses pontos de extremidade públicos são necessários para que o SDN subjacente e a plataforma de gerenciamento do Azure se comuniquem com o roteador de hub virtual. Como o roteador de hub virtual é considerado parte da rede privada do cliente, a plataforma subjacente do Azure não consegue acessar e gerenciar diretamente o roteador de hub por meio de seus pontos de extremidade privados devido aos requisitos de conformidade. A conectividade com os pontos de extremidade públicos do roteador de hub é autenticada por meio de certificados, e o Azure realiza auditorias de segurança de rotina desses pontos de extremidade públicos. Como resultado, eles não constituem uma exposição de segurança do seu hub virtual.
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 peering. Tenha em atenção o seguinte:
- Não é necessário clicar no botão «Sincronizar» na folha de Emparelhamento. Depois que o espaço de endereço da VNet é alterado, o emparelhamento da VNet é sincronizado automaticamente com a VNet do hub virtual.
- Certifique-se de que o espaço de endereço atualizado não se sobreponha ao espaço de endereço para quaisquer VNets spoke existentes na sua WAN Virtual.
Você pode encontrar mais informações sobre como alterar o espaço de endereço da rede virtual em Criar, alterar ou excluir uma rede virtual.
Qual é o número máximo de endereços de rede virtual spoke suportados para hubs configurados com intenção de roteamento?
O número máximo de espaços de endereço em todas as Redes Virtuais diretamente conectadas a um único hub WAN Virtual é 600. Esse limite é aplicado individualmente a cada hub de WAN Virtual em uma implantação de WAN Virtual. Os espaços de endereço de rede virtual conectados a hubs remotos (outros hubs WAN virtuais na mesma WAN virtual) não são contados para esse limite.
Para obter mais informações sobre o limite e scripts de exemplo para determinar o número de espaços de endereço em Redes Virtuais conectadas a um hub WAN Virtual, consulte Limites de espaço de endereço de rede virtual com intenção de roteamento.
Posso usar o Azure Bastion com WAN Virtual?
Sim, mas há limitações. Consulte as Perguntas frequentes do Bastião do Azure para obter mais detalhes.
Manutenção de gateway sob controle do cliente de WAN virtual
Quais serviços estão incluídos no escopo da Configuração de Manutenção dos Gateways de Rede?
Para WAN Virtual, você pode configurar janelas de manutenção para gateways VPN site a site, gateways VPN ponto a site e gateways ExpressRoute.
Esse recurso também é suportado para Firewalls do Azure em hubs seguros de WAN Virtual.
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 portal?
Yes.
Preciso implantar uma unidade de escala mínima de gateway para ser elegível para manutenção controlada pelo cliente?
No.
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 que não estão cobertos no seu cronograma de manutenção, a manutenção continua normalmente nos recursos.
Existem limites para o número de rotas que posso anunciar?
Sim, há limites. O ExpressRoute suporta até 4.000 prefixos para emparelhamento privado e 200 prefixos para emparelhamento Microsoft. Com o ExpressRoute Premium, pode-se aumentar o limite para 10.000 rotas para peering privado. O número máximo de rotas anunciadas a partir do peering privado do Azure por meio de um Gateway do ExpressRoute em um circuito do ExpressRoute é de 1.000, que é o mesmo para circuitos do ExpressRoute padrão e premium. Para obter mais detalhes, poderá rever os limites de rota dos circuitos ExpressRoute na página Limites e Cotas de Assinatura do Azure. Note que, atualmente, a WAN Virtual não suporta anúncios de rotas IPv6.
Existem restrições sobre intervalos de IP que posso anunciar durante a sessão BGP?
Sim, há restrições. Prefixos privados (RFC1918) não são aceites para a sessão BGP de peer da Microsoft. No entanto, qualquer tamanho de prefixo até um prefixo /32 é aceite tanto na interligação privada como na interligação com a Microsoft.
O que acontece se o limite de rota BGP for excedido?
Se o limite de rota BGP for excedido, as sessões BGP serão desconectadas. As sessões são restauradas assim que a contagem de prefixos é reduzida abaixo do limite. Para obter mais informações, consulte os limites de rota dos circuitos ExpressRoute na página de Limites de Assinatura e Cotas do Azure.
Posso monitorar o número de rotas anunciadas ou recebidas em um circuito de Rota Expressa?
Sim, pode. Para obter as práticas recomendadas e a configuração para monitoramento de alertas baseado em métricas, consulte as práticas recomendadas de monitoramento do Azure.
Qual é a recomendação para reduzir o número de prefixos IP?
Recomendamos a agregação dos prefixos antes de os anunciar no ExpressRoute ou no gateway VPN. Além disso, você pode usar Mapas de Rotas para resumir rotas anunciadas de/para a WAN Virtual.
Posso usar tabelas de rotas definidas pelo usuário em redes virtuais spoke conectadas ao hub WAN virtual?
Yes. As rotas que o hub WAN Virtual anuncia para recursos implantados em Redes Virtuais conectadas são rotas do tipo Border Gateway Protocol (BGP). Se uma tabela de rotas definida pelo usuário estiver associada a uma sub-rede conectada à WAN Virtual, a configuração "Propagar rotas de gateway" deverá ser definida como "Sim" para que a WAN Virtual anuncie os recursos implantados nessa sub-rede. A plataforma de rede subjacente definida por software do Azure usa o algoritmo a seguir para selecionar rotas com base no algoritmo de seleção de rotas do Azure.
Por que enfrento problemas de conectividade depois de anunciar rotas do Azure de volta ao Azure?
Se você planeja remover as comunidades BGP do Azure da rede virtual e das rotas UDR, não anuncie essas rotas de volta para o Azure, pois isso causa problemas de roteamento. Não recomendamos anunciar rotas do Azure de volta ao Azure.
Próximos passos
Para obter mais informações sobre a WAN Virtual, consulte Sobre a WAN Virtual.