FAQ do Gateway de VPN

Artigo
03/26/2024

Ligar às redes virtuais

Posso ligar redes virtuais em diferentes regiões do Azure?

Sim. Não há restrição de região. Uma rede virtual pode ligar a outra rede virtual na mesma região ou numa região do Azure diferente.

Posso ligar redes virtuais em diferentes subscrições?

Sim.

Posso especificar servidores DNS privados na minha rede virtual ao configurar um gateway VPN?

Se você especificou um servidor DNS ou servidores quando criou sua rede virtual, o Gateway VPN usa os servidores DNS especificados. Se você especificar um servidor DNS, verifique se o servidor DNS pode resolver os nomes de domínio necessários para o Azure.

Posso ligar a vários sites a partir de uma única rede virtual?

Pode ligar a vários sites com o Windows PowerShell e as APIs REST do Azure. Veja a secção das FAQ Conetividade Multilocal e VNet a VNet.

Existe um custo adicional para configurar um gateway VPN como ativo-ativo?

N.º No entanto, os custos de quaisquer IPs públicos adicionais serão cobrados em conformidade. Consulte Preços de endereços IP.

Quais são as minhas opções de ligação em vários locais?

As seguintes conexões de gateway de rede virtual entre locais são suportadas:

Site-to-site: Ligação VPN através de IPsec (IKE v1 e IKE v2). Este tipo de ligação requer um dispositivo VPN ou RRAS. Para obter mais informações, consulte Site a site.
Ponto a site: Conexão VPN sobre SSTP (Secure Socket Tunneling Protocol) ou IKE v2. Esta ligação não requer um dispositivo VPN. Para obter mais informações, consulte Ponto a site.
VNet-to-VNet: esse tipo de conexão é o mesmo que uma configuração site a site. A ligação VNet a VNet é uma ligação VPN através de IPsec (IKE v1 e IKE v2). Não requer um dispositivo VPN. Para obter mais informações, consulte VNet-to-VNet (VNet a VNet).
Rota Expressa: a Rota Expressa é uma conexão privada com o Azure a partir de sua WAN, não uma conexão VPN pela Internet pública. Para obter mais informações, consulte ExpressRoute Technical Overview (Descrição Geral Técnica do ExpressRoute) e as ExpressRoute FAQ (FAQ do ExpressRoute).

Para obter mais informações sobre conexões de Gateway VPN, consulte Sobre o Gateway VPN.

Qual é a diferença entre uma conexão site a site e ponto a site?

As configurações site a site (túnel VPN IPsec/IKE) estão entre seu local local e o Azure. O que significa que pode estabelecer uma ligação a partir de qualquer um dos computadores localizados no local para qualquer máquina virtual ou instância de função na sua rede virtual, dependendo de como escolher configurar o encaminhamento e as permissões. É uma ótima opção para uma conexão entre locais sempre disponível e é adequado para configurações híbridas. Este tipo de ligação depende de uma aplicação VPN IPsec (dispositivo de hardware ou aplicação de software), que tem de ser implementada na periferia da sua rede. Para criar esse tipo de conexão, você deve ter um endereço IPv4 voltado para o exterior.

As configurações ponto a site (VPN sobre SSTP) permitem que você se conecte de um único computador de qualquer lugar a qualquer coisa localizada em sua rede virtual. Utiliza o cliente VPN fornecido pelo Windows. Como parte da configuração ponto a site, você instala um certificado e um pacote de configuração de cliente VPN, que contém as configurações que permitem que seu computador se conecte a qualquer máquina virtual ou instância de função dentro da rede virtual. É ótimo quando pretende estabelecer ligação a uma rede virtual, mas não está no local. Também é uma boa opção quando você não tem acesso ao hardware VPN ou a um endereço IPv4 voltado para o exterior, ambos necessários para uma conexão site a site.

Você pode configurar sua rede virtual para usar site a site e ponto a site simultaneamente, desde que crie sua conexão site a site usando um tipo de VPN baseado em rota para seu gateway. Os tipos de VPN com base na rota são denominados gateways dinâmicos no modelo de implementação clássica.

Privacidade

O serviço VPN armazena ou processa dados de clientes?

N.º

Gateways de rede virtual

Um gateway de VPN é um gateway de rede virtual?

Um gateway de VPN é um tipo de gateway de rede virtual. Um gateway de VPN envia o tráfego encriptado entre a rede virtual e a sua localização no local através de uma ligação pública. Também pode utilizar um gateway de VPN para enviar tráfego entre redes virtuais. Ao criar um gateway de VPN, pode utilizar o "Vpn" do valor -GatewayType. Para obter mais informações, veja About VPN Gateway configuration settings (Acerca das definições de configuração dos gateway de VPN).

Por que não posso especificar tipos de VPN baseados em políticas e rotas?

A partir de 1º de outubro de 2023, você não poderá criar um gateway VPN baseado em política por meio do portal do Azure. Todos os novos gateways VPN serão criados automaticamente como baseados em rota. Se você já tiver um gateway baseado em políticas, não precisará atualizar seu gateway para baseado em rota. Você pode usar o Powershell/CLI para criar os gateways baseados em políticas.

Anteriormente, os SKUs de gateway mais antigos não suportavam IKEv1 para gateways baseados em rota. Agora, a maioria das SKUs de gateway atuais suporta IKEv1 e IKEv2.

Tipo de VPN de gateway	SKU do Gateway	Versões IKE suportadas
Gateway baseado em políticas	Básica	IKEv1
Gateway baseado em rota	Básica	IKEv2
Gateway baseado em rota	VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5	IKEv1 e IKEv2
Gateway baseado em rota	VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ	IKEv1 e IKEv2

Posso atualizar meu gateway VPN baseado em política para baseado em rota?

N.º Um tipo de gateway não pode ser alterado de baseado em política para baseado em rota, ou de baseado em rota para baseado em política. Para alterar um tipo de gateway, o gateway deve ser excluído e recriado. Este processo demora cerca de 60 minutos. Ao criar o novo gateway, não é possível manter o endereço IP do gateway original.

Exclua todas as conexões associadas ao gateway.
Exclua o gateway usando um dos seguintes artigos:
Crie um novo gateway usando o tipo de gateway desejado e conclua a configuração da VPN. Para conhecer as etapas, consulte o tutorial Site a site.

Posso especificar os meus próprios seletores de tráfego baseados em políticas?

Sim, os seletores de tráfego podem ser definidos por meio do atributo trafficSelectorPolicies em uma conexão por meio do comando New-AzIpsecTrafficSelectorPolicy PowerShell. Para que o seletor de tráfego especificado entre em vigor, verifique se a opção Usar seletores de tráfego baseados em política está ativada.

Os seletores de tráfego configurados personalizados serão propostos somente quando um gateway de VPN do Azure iniciar a conexão. Um gateway VPN aceita qualquer seletor de tráfego proposto por um gateway remoto (dispositivo VPN local). Esse comportamento é consistente entre todos os modos de conexão (Default, InitiatorOnly e ResponderOnly).

Preciso de um "GatewaySubnet"?

Sim. A sub-rede do gateway contém os endereços IP que os serviços do gateway de rede virtual utilizam. Você precisa criar uma sub-rede de gateway para sua rede virtual para configurar um gateway de rede virtual. Para funcionarem corretamente, todas as sub-redes do gateway têm de ter o nome "GatewaySubnet". Não atribua outro nome à sub-rede do gateway. E não implemente VMs ou quaisquer outros elementos na sub-rede do gateway.

Quando cria a sub-rede do gateway, especifica o número de endereços IP que a sub-rede contém. Os endereços IP na sub-rede de gateway estão alocados no serviço do gateway. Algumas configurações necessitam que sejam alocados mais endereços IP para os serviços de gateway do que outros. Pretende certificar-se de que a sub-rede do gateway contém endereços IP suficientes para acomodar o futuro crescimento e possíveis novas configurações de ligação adicionais. Por isso, apesar de poder criar uma sub-rede do gateway tão pequena como /29, recomendamos que crie uma sub-rede do gateway de /27 ou superior (/ 27, /26, /25, etc.). Observe os requisitos para a configuração que pretende criar e certifique-se de que a sub-rede do gateway que tem irá satisfazer essas necessidades.

Posso implementar Virtual Machines ou instâncias de função na minha sub-rede do gateway?

N.º

Posso obter o meu endereço IP do gateway de VPN antes de o criar?

Os recursos de IP público de SKU padrão do Azure devem usar um método de alocação estática. Portanto, você terá o endereço IP público para seu gateway VPN assim que criar o recurso IP público SKU padrão que pretende usar para ele.

Posso solicitar um endereço IP público estático para o meu gateway VPN?

Os recursos de endereço IP público padrão de SKU usam um método de alocação estática. No futuro, você deve usar um endereço IP público SKU padrão ao criar um novo gateway VPN. Isso se aplica a todas as SKUs de gateway, exceto a SKU básica. Atualmente, o SKU do gateway Básico suporta apenas endereços IP públicos de SKU Básico. Em breve, adicionaremos suporte para endereços IP públicos SKU padrão para SKUs de gateway básico.

Para gateways não redundantes de zona e não zonais que foram criados anteriormente (SKUs de gateway que não têm AZ no nome), a atribuição de endereço IP dinâmico é suportada, mas está sendo eliminada. Quando você usa um endereço IP dinâmico, o endereço IP não muda depois de ter sido atribuído ao seu gateway VPN. A única vez que o endereço IP do gateway VPN é alterado é quando o gateway é excluído e, em seguida, recriado. O endereço IP público do gateway VPN não muda quando você redimensiona, redefine ou conclui outras manutenções e atualizações internas do seu gateway VPN.

Como a aposentadoria básica de SKU do endereço IP público afeta meus gateways VPN?

Estamos tomando medidas para garantir a operação contínua de gateways VPN implantados que utilizam endereços IP públicos SKU básicos. Se você já tiver gateways VPN com endereços IP públicos SKU básicos, não há necessidade de tomar nenhuma medida.

No entanto, é importante observar que os endereços IP públicos básicos de SKU estão sendo eliminados. No futuro, ao criar um novo gateway VPN, você deve usar o endereço IP público SKU padrão. Mais detalhes sobre a aposentadoria de endereços IP públicos Basic SKU podem ser encontrados aqui.

Como é que o meu túnel VPN é autenticado?

A VPN do Azure utiliza a autenticação PSK (Chave Pré-partilhada). Geramos uma chave pré-partilhada (PSK) quando criamos o túnel VPN. Você pode alterar a PSK gerada automaticamente para a sua própria com o cmdlet set Pre-Shared Key PowerShell ou a API REST.

Posso utilizar a API Definir Chave Pré-Partilhada para configurar a minha VPN de gateway baseada em políticas (encaminhamento estático)?

Sim, o cmdlet do PowerShell e a API Definir Chave Pré-Partilhada podem ser utilizados para configurar VPNs (estáticas) baseadas em políticas e VPNs de encaminhamento (dinâmico) baseadas em políticas do Azure.

Posso utilizar outras opções de autenticação?

Estamos limitados a usar chaves pré-compartilhadas (PSK) para autenticação.

Como posso especificar que tráfego atravessa o gateway de VPN?

Modelo de implementação Resource Manager

PowerShell: utilize "AddressPrefix" para especificar o tráfego para o gateway de rede local.
Portal do Azure: navegue até o espaço de Endereço de Configuração > do gateway > de rede local.

Modelo de implementação clássica

Portal do Azure: navegue até as conexões > VPN de rede > virtual clássicas Conexões > VPN site a site Nome do site local Espaço > de endereço do cliente do site > local.

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

Sim, a travessia NAT (NAT-T) é suportada. O Gateway de VPN do Azure 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.

Posso configurar o meu próprio servidor VPN no Azure e utilizá-lo para estabelecer ligação à minha rede no local?

Sim, pode implementar os seus servidores ou gateways de VPN no Azure a partir do Azure Marketplace ou criar os seus próprios routers VPN. Você deve configurar rotas definidas pelo usuário em sua rede virtual para garantir que o tráfego seja roteado corretamente entre suas redes locais e suas sub-redes de rede virtual.

Por que determinadas portas são abertas no meu gateway de rede virtual?

Eles são necessários para a comunicação de infraestrutura do Azure. Eles são protegidos (bloqueados) por certificados do Azure. Sem certificados adequados, entidades externas, incluindo os clientes desses gateways, não poderão causar qualquer efeito nesses endpoints.

Um gateway de rede virtual é fundamentalmente um dispositivo multi-homed com uma NIC tocando na rede privada do cliente e uma NIC voltada para a rede pública. As entidades de infraestrutura do Azure não podem acessar redes privadas do cliente por motivos de conformidade, portanto, elas precisam utilizar pontos de extremidade públicos para comunicação de infraestrutura. Os pontos finais públicos são analisados periodicamente pela auditoria de segurança do Azure.

Posso criar um gateway VPN com o SKU do gateway básico no portal?

N.º O SKU básico não está disponível no portal. Você pode criar um gateway de VPN SKU Básico usando a CLI do Azure ou o PowerShell.

Onde posso encontrar informações sobre tipos de gateway, requisitos e taxa de transferência?

Consulte os seguintes artigos:

Descontinuação de SKUs para SKUs herdados

Os SKUs padrão e de alto desempenho serão preteridos em 30 de setembro de 2025. Pode ver o anúncio aqui. A equipa do produto irá disponibilizar um caminho de migração para essas SKUs até 30 de novembro de 2024. Para obter mais informações, consulte o artigo SKUs herdados do Gateway VPN. Neste momento, não há nenhuma ação que você precise tomar.

Posso criar uma nova SKU Padrão/Alto Desempenho após o anúncio de descontinuação em 30 de novembro de 2023?

N.º A partir de 1º de dezembro de 2023, você não poderá criar novos gateways com SKUs padrão ou de alto desempenho. Você pode criar novos gateways usando VpnGw1 e VpnGw2 pelo mesmo preço que as SKUs Standard e High Performance, listadas respectivamente em nossa página de preços.

Por quanto tempo meus gateways existentes serão suportados em SKUs padrão/de alto desempenho?

Todos os gateways existentes que usam SKUs padrão ou de alto desempenho serão suportados até 30 de setembro de 2025.

Preciso migrar minhas SKUs de gateway padrão/de alto desempenho agora?

Não, não há nenhuma ação necessária no momento. Você poderá migrar suas SKUs a partir de dezembro de 2024. Enviaremos uma comunicação com documentação detalhada sobre as etapas de migração.

Para qual SKU posso migrar meu gateway?

Quando a migração de SKU de gateway fica disponível, as SKUs podem ser migradas da seguinte maneira:

Padrão -> VpnGw1
Alto desempenho -> VpnGw2

E se eu quiser migrar para um AZ SKU?

Não é possível migrar sua SKU herdada para uma AZ SKU. No entanto, observe que todos os gateways que ainda estão usando SKUs padrão ou de alto desempenho após 30 de setembro de 2025 serão migrados e atualizados automaticamente para as seguintes SKUs:

Padrão -> VpnGw1AZ
Alto desempenho -> VpnGw2AZ

Você pode usar essa estratégia para que suas SKUs sejam migradas automaticamente e atualizadas para uma AZ SKU. Você pode então redimensionar sua SKU dentro dessa família de SKU, se necessário. Consulte a nossa página de preços para obter os preços do AZ SKU. Para obter informações de taxa de transferência por SKU, consulte Sobre SKUs de gateway.

Haverá alguma diferença de preço para meus gateways após a migração?

Se você migrar seus SKUs até 30 de setembro de 2025, não haverá diferença de preço. Os SKUs VpnGw1 e VpnGw2 são oferecidos pelo mesmo preço que os SKUs Standard e High Performance, respectivamente. Se você não migrar até essa data, suas SKUs serão automaticamente migradas e atualizadas para AZ SKUs. Nesse caso, há uma diferença de preço.

Haverá algum impacto no desempenho dos meus gateways com esta migração?

Sim, você obtém melhor desempenho com VpnGw1 e VpnGw2. Atualmente, o VpnGw1 a 650 Mbps fornece um 6,5x e o VpnGw2 a 1 Gbps fornece uma melhoria de desempenho de 5x ao mesmo preço dos gateways legados Standard e High Performance, respectivamente. Para obter mais informações sobre a taxa de transferência de SKUs, consulte Sobre SKUs de gateway.

O que acontece se eu não migrar SKUs até 30 de setembro de 2025?

Todos os gateways que ainda estão usando SKUs padrão ou de alto desempenho serão migrados automaticamente e atualizados para as seguintes SKUs AZ:

Padrão -> VpnGw1AZ
Alto desempenho -> VpnGw2AZ

A comunicação final será enviada antes de iniciar a migração em qualquer gateway.

O VPN Gateway Basic SKU também está se aposentando?

Não, o VPN Gateway Basic SKU veio para ficar. Você pode criar um gateway VPN usando a SKU do gateway Básico via PowerShell ou CLI. Atualmente, as SKUs de gateway básico do gateway VPN suportam apenas o recurso de endereço IP público Basic SKU (que está a caminho da desativação). Estamos trabalhando para adicionar suporte ao SKU de gateway básico do gateway VPN para o recurso de endereço IP público SKU padrão.

Conexões site a site e dispositivos VPN

O que devo considerar ao selecionar um dispositivo VPN?

Validamos um conjunto de dispositivos VPN padrão site a site em parceria com fornecedores de dispositivos. Pode encontrar uma lista de dispositivos VPN compatíveis conhecidos, exemplos ou instruções de configuração correspondentes e especificações de dispositivo no artigo About VPN devices (Acerca de dispositivos VPN). Todos os dispositivos das famílias de dispositivos listadas como compatíveis devem funcionar com a Rede Virtual. Para ajudar a configurar o dispositivo VPN, consulte o exemplo de configuração do dispositivo ou a ligação que corresponde a uma família de dispositivos adequados.

Onde posso encontrar as definições de configuração de dispositivos VPN?

Para transferir os scripts de configuração do dispositivo VPN

Consoante o dispositivo VPN que tiver, poderá transferir um script de configuração do dispositivo VPN. Para mais informações, consulte Transferir os scripts de configuração do dispositivo VPN.

Consulte as seguintes ligações para informações de configuração adicionais:

Para obter mais informações sobre os dispositivos VPN compatíveis, consulte VPN Devices (Dispositivos VPN).
Antes de configurar o dispositivo VPN, verifique a existência de Problemas de compatibilidade de dispositivos conhecidos para o dispositivo VPN que pretende utilizar.
Para ver as ligações para as definições de configuração de dispositivo, consulte Validated VPN Devices (Dispositivos VPN Validados). As ligações para a configuração do dispositivo são fornecidas numa base de melhor esforço. É sempre melhor verificar com o fabricante do dispositivo para obter as mais recentes informações de configuração. A lista mostra as versões que testamos. Se o seu SO não está nesta lista, é possível que a versão seja compatível. Contacte o fabricante do dispositivo para verificar se a versão do SO para o dispositivo VPN é compatível.
Para obter uma visão geral da configuração do dispositivo VPN, consulte Visão geral da configuração do dispositivo VPN.
Para obter informações sobre a edição de amostras de configuração do dispositivo, consulte Editing samples (Editar amostras).
Para requisitos criptográficos, consulte Sobre os requisitos criptográficos e gateways de VPN do Azure.
Para mais informações sobre os parâmetros de IPsec/IKE, consulte Sobre os dispositivos de VPN e os parâmetros de IPsec/IKE para ligações do Gateway da Rede Site-to-Site VPN. Esta ligação apresenta informações sobre a versão de IKE, Grupo Diffie-Hellman, Método de autenticação, encriptação e algoritmos hash, duração de SA, PFS e DPD, além de outras informações de parâmetros necessários para concluir a configuração.
Para os passos de configuração da política de IPsec/IKE, consulte Configurar política de IPsec/IKE para ligações VPN S2S ou VNet para VNet.
Para ligar vários dispositivos VPN baseados em políticas, veja Ligue gateways VPN do Azure a vários dispositivos VPN baseados em políticas no local com o PowerShell.

Como posso editar os exemplos de configuração do dispositivo VPN?

Para obter informações sobre a edição de amostras de configuração do dispositivo, consulte Editing samples (Editar amostras).

Onde posso encontrar os parâmetros do IPsec e do IKE?

Para os parâmetros de IPsec/IKE, consulte Parameters (Parâmetros).

Por que motivo o meu túnel VPN baseado em políticas diminui quando o tráfego está inativo?

Este comportamento está previsto para gateways de VPN baseados em políticas (também conhecido como encaminhamento estático). Quando o tráfego sobre o túnel está inativo por mais de 5 minutos, o túnel é demolido. Quando o tráfego começa a fluir em ambos os sentidos, o túnel é restabelecido imediatamente.

Posso utilizar VPNs de software para ligar ao Azure?

Oferecemos suporte a servidores de Roteamento e Acesso Remoto (RRAS) do Windows Server 2012 para configuração entre locais site a site.

Outras soluções de VPN de software devem funcionar com o nosso gateway, desde que obedeçam às implementações de IPsec de norma da indústria. Contacte o fornecedor do software para as obter instruções de configuração e de suporte.

Posso me conectar a um gateway VPN via ponto a site quando localizado em um site que tem uma conexão ativa site a site?

Sim, mas o(s) endereço(s) IP(s) público(s) do cliente ponto-a-site devem ser diferentes do(s) endereço(s) IP(s) público(s) usado(s) pelo dispositivo VPN site a site, caso contrário, a conexão ponto a site não funcionará. As conexões ponto a site com o IKEv2 não podem ser iniciadas a partir do(s) mesmo(s) endereço(s) IP público em que uma conexão VPN site a site está configurada no mesmo gateway de VPN do Azure.

Ponto a site - Autenticação de certificado

Esta secção aplica-se ao Modelo de implementação Resource Manager.

Quantos endpoints de cliente VPN posso ter na minha configuração ponto-a-site?

Depende do SKU de gateway. Para obter mais informações sobre o número de ligações suportado, veja SKUs de Gateway.

Que sistemas operativos cliente posso utilizar com o ponto-a-site?

São suportados os seguintes sistemas operativos cliente:

Windows Server 2008 R2 (apenas 64 bits)
Windows 8.1 (32 e 64 bits)
Windows Server 2012 (apenas 64 bits)
Windows Server 2012 R2 (apenas 64 bits)
Windows Server 2016 (apenas 64 bits)
Windows Server 2019 (apenas 64 bits)
Windows Server 2022 (apenas 64 bits)
Windows 10
Windows 11
macOS versão 10.11 ou superior
Linux (StrongSwan)
iOS

Posso atravessar proxies e firewalls usando a capacidade ponto-a-site?

O Azure suporta três tipos de opções de VPN Ponto a site:

Secure Socket Tunneling Protocol (SSTP). SSTP é uma solução baseada em SSL proprietária da Microsoft que consegue penetrar firewalls, uma vez que a maioria das firewalls abre a porta TCP de saída que o SSL 443 utiliza.
OpenVPN. OpenVPN é uma solução baseada em SSL que consegue penetrar firewalls, uma vez que a maioria das firewalls abre a porta TCP de saída que o SSL 443 utiliza.
VPN IKEv2. IKEv2 VPN é uma solução VPN IPsec baseada em padrões que usa portas UDP de saída 500 e 4500 e protocolo IP nº 50. Os firewalls nem sempre abrem essas portas, então há uma possibilidade de a VPN IKEv2 não ser capaz de atravessar proxies e firewalls.

Se eu reiniciar um computador cliente configurado para ponto a site, a VPN se reconectará automaticamente?

A reconexão automática é uma função do cliente que está sendo usado. O Windows oferece suporte à reconexão automática configurando o recurso de cliente VPN Always On.

O ponto-a-site suporta DDNS nos clientes VPN?

Atualmente, o DDNS não é suportado em VPNs ponto a site.

Posso fazer com que as configurações Site-to-Site e ponto-a-site coexistam para a mesma rede virtual?

Sim. Para o modelo de implementação do Resource Manager, tem de ter um tipo de VPN RouteBased para o seu gateway. No modelo de implementação clássica, precisa de um gateway dinâmico. Não suportamos ponto a site para gateways VPN de roteamento estático ou gateways VPN baseados em políticas.

Posso configurar um cliente ponto a site para se conectar a vários gateways de rede virtual ao mesmo tempo?

Dependendo do software Cliente VPN usado, você poderá se conectar a vários Gateways de Rede Virtual, desde que as redes virtuais conectadas não tenham espaços de endereço conflitantes entre elas ou a rede de com o cliente esteja se conectando. Embora o Azure VPN Client suporte muitas ligações VPN, apenas uma ligação pode estar Ligada num dado momento.

Posso configurar um cliente ponto a site para se conectar a várias redes virtuais ao mesmo tempo?

Sim, as conexões de cliente ponto a site com um gateway de rede virtual implantado em uma VNet emparelhada com outras VNets podem ter acesso a outras VNets emparelhadas. Os clientes ponto a site poderão se conectar a VNets emparelhadas, desde que as VNets emparelhadas estejam usando os recursos UseRemoteGateway / AllowGatewayTransit. Para obter mais informações, consulte Sobre roteamento ponto a site.

Quanta taxa de transferência posso esperar por meio de conexões Site-to-Site ou ponto-a-site?

É difícil manter o débito exato dos túneis VPN. O IPsec e SSTP são protocolos VPN extremamente encriptados. O débito também é limitado pela latência e pela largura de banda entre o local e a Internet. Para um Gateway VPN com apenas conexões VPN ponto a site IKEv2, a taxa de transferência total que você pode esperar depende da SKU do Gateway. Para obter mais informações sobre o débito, veja SKUs de Gateway.

Posso usar qualquer cliente VPN de software para ponto a site que suporte SSTP e/ou IKEv2?

N.º Só pode utilizar o cliente VPN nativo no Windows para SSTP e o cliente VPN nativo no Mac para IKEv2. No entanto, pode utilizar o cliente OpenVPN em todas as plataformas para se ligar através do protocolo OpenVPN. Consulte a lista de sistemas operacionais clientes suportados.

Posso alterar o tipo de autenticação para uma conexão ponto-a-site?

Sim. No portal, navegue até a página de configuração ponto a site do gateway VPN -> Point-to-site. Em Tipo de autenticação, selecione os tipos de autenticação que deseja usar. Observe que, depois de fazer uma alteração em um tipo de autenticação, os clientes atuais podem não conseguir se conectar até que um novo perfil de configuração de cliente VPN tenha sido gerado, baixado e aplicado a cada cliente VPN.

O Azure suporta a VPN IKEv2 no Windows?

O IKEv2 é suportado no Windows 10 e Windows Server 2016. No entanto, para usar o IKEv2 em determinadas versões do sistema operacional, você deve instalar atualizações e definir um valor de chave do Registro localmente. As versões do SO anteriores ao Windows 10 não são suportadas e só podem utilizar o Protocolo SSTP ou OpenVPN®.

Nota

As compilações do sistema operacional Windows mais recentes que o Windows 10 Versão 1709 e o Windows Server 2016 Versão 1607 não exigem essas etapas.

Para preparar o Windows 10 ou o Windows Server 2016 para o IKEv2:

Instale a atualização com base na sua versão do sistema operacional:

Versão do Sistema Operativo	Date	Número/Ligação
Windows Server 2016 Windows 10, Versão 1607	17 de janeiro de 2018	KB4057142
Windows 10, Versão 1703	17 de janeiro de 2018	KB4057144
Windows 10, Versão 1709	22 de março, 2018	KB4089848

Defina o valor da chave de registo. Crie ou defina a chave "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” REG_DWORD no registo como 1.

Qual é o limite do seletor de tráfego IKEv2 para conexões ponto-a-site?

O Windows 10 versão 2004 (lançado em setembro de 2021) aumentou o limite do seletor de tráfego para 255. As versões do Windows anteriores a esta têm um limite de seletor de tráfego de 25.

O limite de seletores de tráfego no Windows determina o número máximo de espaços de endereço em sua rede virtual e a soma máxima de suas redes locais, conexões VNet-to-VNet e VNets emparelhadas conectadas ao gateway. Os clientes ponto a site baseados no Windows não conseguirão se conectar via IKEv2 se ultrapassarem esse limite.

O que acontece quando configuro o SSTP e o IKEv2 para ligações VPN P2S?

Quando você configura o SSTP e o IKEv2 em um ambiente misto (que consiste em dispositivos Windows e Mac), o cliente VPN do Windows sempre tentará o túnel IKEv2 primeiro, mas voltará para o SSTP se a conexão IKEv2 não for bem-sucedida. O MacOSX só liga através do IKEv2.

Quando você tiver o SSTP e o IKEv2 habilitados no Gateway, o pool de endereços ponto a site será dividido estaticamente entre os dois, de modo que os clientes que usam protocolos diferentes receberão endereços IP de qualquer subintervalo. Observe que a quantidade máxima de clientes SSTP é sempre 128, mesmo se o intervalo de endereços for maior que /24, resultando em uma maior quantidade de endereços disponíveis para clientes IKEv2. Para intervalos mais pequenos, a piscina será igualmente reduzida para metade. Os Seletores de Tráfego usados pelo gateway podem não incluir o CIDR do intervalo de endereços Ponto a Site, mas os dois CIDRs de subintervalo.

Que outras plataformas não Windows e Mac suporta o Azure na VPN P2S?

O Azure suporta Windows, Mac e Linux para VPN P2S.

Já tenho um Gateway de VPN do Azure implementado. Posso ativar a VPN RADIUS e/ou IKEv2 no mesmo?

Sim, se a SKU de gateway que você está usando oferecer suporte a RADIUS e/ou IKEv2, você poderá habilitar esses recursos em gateways que já implantou usando o PowerShell ou o portal do Azure. O Basic SKU não suporta RADIUS ou IKEv2.

Como posso remover a configuração de uma ligação P2S?

Pode remover uma configuração P2S com a CLI do Azure e o PowerShell através dos seguintes comandos:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

CLI do Azure

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

O que devo fazer se estiver recebendo uma incompatibilidade de certificado ao me conectar usando a autenticação de certificado?

Desmarque "Verificar a identidade do servidor validando o certificado" ou adicione o FQDN do servidor junto com o certificado ao criar um perfil manualmente. Você pode fazer isso executando rasphone a partir de um prompt de comando e escolhendo o perfil na lista suspensa.

Ignorar a validação de identidade do servidor não é recomendado em geral, mas com a autenticação de certificado do Azure, o mesmo certificado está sendo usado para validação de servidor no protocolo de encapsulamento VPN (IKEv2/SSTP) e no protocolo EAP. Como o certificado do servidor e o FQDN já estão validados pelo protocolo de encapsulamento VPN, é redundante validar o mesmo novamente no EAP.

autenticação ponto-a-site

Posso usar minha própria autoridade de certificação raiz PKI interna para gerar certificados para conectividade ponto a site?

Sim. Anteriormente, só podiam ser utilizados os certificados de raiz autoassinados. Ainda pode carregar 20 certificados de raiz.

Posso usar certificados do Cofre de Chaves do Azure?

N.º

Que ferramentas posso utilizar para criar certificados?

Pode utilizar a sua solução de PKI de Empresa (o PKI interno), o Azure PowerShell, MakeCert e OpenSSL.

Existem instruções para parâmetros e definições de certificado?

Solução PKI de Empresa/Interno: Veja os passos para Gerar certificados.
Azure PowerShell: Veja o artigo Azure PowerShell para saber quais os passos a seguir.
MakeCert: Veja o artigo MakeCert para saber quais os passos a seguir.
OpenSSL:
- Ao exportar certificados, certifique-se de que converte o certificado de raiz para Base64.
- Para o certificado de cliente:
  - Ao criar a chave privada, especifique o comprimento como 4096.
  - Ao criar o certificado para o parâmetro -extensions, especifique usr_cert.

Ponto a site - autenticação RADIUS

Esta secção aplica-se ao Modelo de implementação Resource Manager.

Quantos endpoints de cliente VPN posso ter na minha configuração ponto-a-site?

Depende do SKU de gateway. Para obter mais informações sobre o número de ligações suportado, veja SKUs de Gateway.

Que sistemas operativos cliente posso utilizar com o ponto-a-site?

São suportados os seguintes sistemas operativos cliente:

Windows Server 2008 R2 (apenas 64 bits)
Windows 8.1 (32 e 64 bits)
Windows Server 2012 (apenas 64 bits)
Windows Server 2012 R2 (apenas 64 bits)
Windows Server 2016 (apenas 64 bits)
Windows Server 2019 (apenas 64 bits)
Windows Server 2022 (apenas 64 bits)
Windows 10
Windows 11
macOS versão 10.11 ou superior
Linux (StrongSwan)
iOS

Posso atravessar proxies e firewalls usando a capacidade ponto-a-site?

O Azure suporta três tipos de opções de VPN Ponto a site:

Secure Socket Tunneling Protocol (SSTP). SSTP é uma solução baseada em SSL proprietária da Microsoft que consegue penetrar firewalls, uma vez que a maioria das firewalls abre a porta TCP de saída que o SSL 443 utiliza.
OpenVPN. OpenVPN é uma solução baseada em SSL que consegue penetrar firewalls, uma vez que a maioria das firewalls abre a porta TCP de saída que o SSL 443 utiliza.
VPN IKEv2. IKEv2 VPN é uma solução VPN IPsec baseada em padrões que usa portas UDP de saída 500 e 4500 e protocolo IP nº 50. Os firewalls nem sempre abrem essas portas, então há uma possibilidade de a VPN IKEv2 não ser capaz de atravessar proxies e firewalls.

Se eu reiniciar um computador cliente configurado para ponto a site, a VPN se reconectará automaticamente?

A reconexão automática é uma função do cliente que está sendo usado. O Windows oferece suporte à reconexão automática configurando o recurso de cliente VPN Always On.

O ponto-a-site suporta DDNS nos clientes VPN?

Atualmente, o DDNS não é suportado em VPNs ponto a site.

Posso fazer com que as configurações Site-to-Site e ponto-a-site coexistam para a mesma rede virtual?

Posso configurar um cliente ponto a site para se conectar a vários gateways de rede virtual ao mesmo tempo?

Posso configurar um cliente ponto a site para se conectar a várias redes virtuais ao mesmo tempo?

Quanta taxa de transferência posso esperar por meio de conexões Site-to-Site ou ponto-a-site?

Posso usar qualquer cliente VPN de software para ponto a site que suporte SSTP e/ou IKEv2?

Posso alterar o tipo de autenticação para uma conexão ponto-a-site?

O Azure suporta a VPN IKEv2 no Windows?

Nota

As compilações do sistema operacional Windows mais recentes que o Windows 10 Versão 1709 e o Windows Server 2016 Versão 1607 não exigem essas etapas.

Para preparar o Windows 10 ou o Windows Server 2016 para o IKEv2:

Instale a atualização com base na sua versão do sistema operacional:

Versão do Sistema Operativo	Date	Número/Ligação
Windows Server 2016 Windows 10, Versão 1607	17 de janeiro de 2018	KB4057142
Windows 10, Versão 1703	17 de janeiro de 2018	KB4057144
Windows 10, Versão 1709	22 de março, 2018	KB4089848

Defina o valor da chave de registo. Crie ou defina a chave "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” REG_DWORD no registo como 1.

Qual é o limite do seletor de tráfego IKEv2 para conexões ponto-a-site?

O Windows 10 versão 2004 (lançado em setembro de 2021) aumentou o limite do seletor de tráfego para 255. As versões do Windows anteriores a esta têm um limite de seletor de tráfego de 25.

O que acontece quando configuro o SSTP e o IKEv2 para ligações VPN P2S?

Que outras plataformas não Windows e Mac suporta o Azure na VPN P2S?

O Azure suporta Windows, Mac e Linux para VPN P2S.

Já tenho um Gateway de VPN do Azure implementado. Posso ativar a VPN RADIUS e/ou IKEv2 no mesmo?

Como posso remover a configuração de uma ligação P2S?

Pode remover uma configuração P2S com a CLI do Azure e o PowerShell através dos seguintes comandos:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

CLI do Azure

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

A autenticação RADIUS é suportada em todos os SKUs de Gateway de VPN do Azure?

A autenticação RADIUS é suportada para todas as SKUs, exceto a SKU Básica.

Para SKUs herdadas, a autenticação RADIUS é suportada em SKUs padrão e de alto desempenho. Ele não é suportado no Basic Gateway SKU.

A autenticação RADIUS é suportada para o modelo de implementação clássica?

N.º A autenticação RADIUS não é suportada para o modelo de implantação clássico.

Qual é o período de tempo limite para solicitações RADIUS enviadas ao servidor RADIUS?

As solicitações RADIUS são definidas como tempo limite após 30 segundos. Os valores de tempo limite definidos pelo usuário não são suportados atualmente.

Os servidores RADIUS de terceiros são suportados?

Sim, os servidores RADIUS de terceiros são suportados.

Quais são os requisitos de conectividade necessários para garantir que o gateway do Azure é capaz de alcançar um servidor RADIUS no local?

É necessária uma conexão VPN site a site com o site local, com as rotas adequadas configuradas.

O tráfego para um servidor RADIUS no local (a partir do gateway de VPN do Azure) pode ser encaminhado através de uma ligação do ExpressRoute?

N.º Ele só pode ser roteado por uma conexão site a site.

Existe uma alteração no número de ligações SSTP suportadas com a autenticação RADIUS? Qual é o número máximo de ligações SSTP e IKEv2 suportadas?

Não há alteração no número máximo de conexões SSTP suportadas em um gateway com autenticação RADIUS. Permanece 128 para SSTP, mas depende do gateway SKU para IKEv2. Para obter mais informações sobre o número de ligações suportado, veja SKUs de Gateway.

Qual é a diferença entre fazer a autenticação de certificado usando um servidor RADIUS versus usar a autenticação de certificado nativo do Azure (carregando um certificado confiável no Azure)?

Na autenticação de certificados RADIUS, o pedido de autenticação é reencaminhado para um servidor RADIUS que processa a validação de certificados. Esta opção é útil caso queira integrar numa infraestrutura de autenticação de certificados que já tenha através de RADIUS.

Ao utilizar o Azure para a autenticação de certificados, o gateway de VPN do Azure realiza a validação do certificado. Tem de carregar a chave pública do certificado para o gateway. Também pode especificar uma lista de certificados revogados que não devem ter permissão para estabelecer ligação.

A autenticação RADIUS funciona com as VPN IKEv2 e SSTP?

Sim, a autenticação RADIUS funciona com as VPNs IKEv2 e SSTP.

A autenticação RADIUS funciona com o cliente OpenVPN?

A autenticação RADIUS é suportada para o protocolo OpenVPN.

Ligações VNet a VNet e de Vários Sites

As perguntas frequentes sobre VNet-to-VNet aplicam-se a conexões de gateway VPN. Para obter informações sobre emparelhamento de rede virtual, consulte Emparelhamento de rede virtual.

O Azure cobra o tráfego entre VNets?

O tráfego de VNet-to-VNet dentro da mesma região é gratuito para ambas as direções quando você usa uma conexão de gateway VPN. O tráfego de saída de VNet-to-VNet entre regiões é cobrado com as taxas de transferência de dados entre VNet de saída com base nas regiões de origem. Para obter mais informações, consulte a página de preços do Gateway de VPN. Se você estiver conectando suas redes virtuais usando emparelhamento de rede virtual em vez de um gateway VPN, consulte Preços de rede virtual.

O tráfego VNet-to-VNet viaja pela Internet?

N.º O tráfego de VNet-to-VNet viaja pelo backbone do Microsoft Azure, não pela Internet.

Posso estabelecer uma conexão VNet-to-VNet entre locatários do Microsoft Entra?

Sim, as conexões VNet-to-VNet que usam gateways de VPN do Azure funcionam entre locatários do Microsoft Entra.

O tráfego VNet a VNet é seguro?

Sim, está protegido por encriptação IPsec/IKE.

Preciso de um dispositivo VPN para ligar VNets?

N.º A ligação de várias redes virtuais do Azure em conjunto não precisa de um dispositivo VPN, a menos que precise de conectividade em vários locais.

As minhas VNets precisam de estar na mesma região?

N.º As redes virtuais podem estar nas mesmas regiões ou em regiões (localizações) diferentes do Azure.

Se as redes virtuais não estiverem na mesma assinatura, elas precisarão ser associadas ao mesmo locatário do Ative Directory?

N.º

Posso utilizar VNet a VNet para ligar redes virtuais em instâncias do Azure separadas?

N.º A VNet a VNet suporta a ligação de redes virtuais na mesma instância do Azure. Por exemplo, não é possível criar uma conexão entre o Azure global e instâncias do Azure do governo chinês/alemão/dos EUA. Considere o uso de uma conexão VPN Site a Site para esses cenários.

Pode utilizar a VNet a VNet juntamente com ligações de vários locais?

Sim. A conectividade de rede virtual pode ser utilizada em simultâneo com VPNs de vários locais.

A quantos sites no local e redes virtuais pode uma rede virtual ligar?

Consulte a tabela de requisitos do gateway.

Posso utilizar a VNet a VNet para ligar VMs ou serviços cloud fora de uma VNet?

N.º A VNet a VNet suporta a ligação de redes virtuais. Ele não suporta a conexão de máquinas virtuais ou serviços de nuvem que não estão em uma rede virtual.

Um serviço de nuvem ou um ponto de extremidade de balanceamento de carga pode abranger redes virtuais?

N.º Um serviço de nuvem ou um ponto de extremidade de balanceamento de carga não pode se estender por redes virtuais, mesmo que elas estejam conectadas.

Posso usar um tipo de VPN Baseado em Políticas para conexões VNet-to-VNet ou Multi-Site?

N.º As conexões VNet-to-VNet e Multi-Site exigem gateways de VPN do Azure com tipos de VPN RouteBased (anteriormente chamados de roteamento dinâmico).

Posso ligar uma VNet com um Tipo de VPN RouteBased a outra VNet com um tipo de VPN PolicyBased?

Não, ambas as redes virtuais DEVEM usar VPNs baseadas em rota (anteriormente chamadas de roteamento dinâmico).

Sim. Todos os túneis VPN da rede virtual partilham a largura de banda disponível no gateway de VPN do Azure e o mesmo SLA do tempo de atividade do gateway de VPN no Azure.

Os túneis redundantes são suportados?

Os túneis redundantes entre um par de redes virtuais são suportados quando um gateway de rede virtual está configurado como ativo-ativo.

Pode ter espaços de endereços sobrepostos para configurações de VNet a VNet?

N.º Não pode ter intervalos de endereços IP sobrepostos.

Pode existir uma sobreposição de espaços de endereços entre as redes virtuais ligadas e os sites locais no local?

N.º Não pode ter intervalos de endereços IP sobrepostos.

Como faço para habilitar o roteamento entre minha conexão VPN site a site e minha Rota Expressa?

Se quiser habilitar o roteamento entre sua filial conectada à Rota Expressa e sua filial conectada a uma conexão VPN site a site, você precisará configurar o Servidor de Rotas do Azure.

Posso utilizar o gateway de VPN do Azure para transitar o tráfego entre os meus sites no local ou para outra rede virtual?

Modelo de implementação Resource Manager
Sim. Veja a secção BGP para obter mais informações.

Modelo de implementação clássica
É possível transitar o tráfego através do gateway de VPN do Azure com o modelo de implementação clássica, mas tal depende de espaços de endereços definidos estaticamente no ficheiro de configuração de rede. O BGP ainda não tem suporte com Redes Virtuais do Azure e gateways de VPN usando o modelo de implantação clássico. Sem o BGP, a definição manual dos espaços de endereços de trânsito é muito propensa a erros e não se recomenda.

O Azure gera a mesma chave pré-partilhada IPsec/IKE para todas as minhas ligações VPN para a mesma rede virtual?

Não, por predefinição, o Azure gera chaves pré-partilhadas diferentes para diferentes ligações VPN. No entanto, você pode usar a API REST ou o Set VPN Gateway Key cmdlet do PowerShell para definir o valor da chave de sua preferência. A chave DEVE conter apenas caracteres ASCII imprimíveis, exceto espaço, hífen (-) ou til (~).

Obtenho mais largura de banda com mais VPNs site a site do que com uma única rede virtual?

Não, todos os túneis VPN, incluindo VPNs ponto a site, compartilham o mesmo gateway de VPN do Azure e a largura de banda disponível.

Posso configurar vários túneis entre a minha rede virtual e o meu site no local através da VPN multilocal?

Sim, mas tem de configurar o BGP em ambos os túneis para a mesma localização.

O Gateway de VPN do Azure honra o Caminho AS pendente para influenciar as decisões de roteamento entre várias conexões com meus sites locais?

Sim, o gateway de VPN do Azure honra o Caminho AS pendente para ajudar a tomar decisões de roteamento quando o BGP está habilitado. Um caminho AS mais curto é preferido na seleção de caminho BGP.

Posso usar a propriedade RoutingWeight ao criar uma nova conexão VPN VirtualNetworkGateway?

Não, essa configuração é reservada para conexões de gateway de Rota Expressa. Se quiser influenciar as decisões de roteamento entre várias conexões, você precisa usar o AS Path prepending.

Posso usar VPNs ponto a site com minha rede virtual com vários túneis VPN?

Sim, as VPNs ponto a site (P2S) podem ser usadas com os gateways VPN que se conectam a vários sites locais e outras redes virtuais.

Posso ligar uma rede virtual com VPNs IPsec ao meu circuito ExpressRoute?

Sim, esta ação é suportada. Para obter mais informações, consulte Configurar a Rota Expressa e conexões VPN site a site que coexistem.

IPsec/política IKE

A política de IPsec/IKE personalizado é suportada em todos os SKU de Gateway de VPN do Azure?

A política IPsec/IKE personalizada é suportada em todas as SKUs do Azure, exceto a SKU Básica.

Quantas políticas posso especificar numa ligação?

Só pode especificar uma combinação de políticas para uma determinada ligação.

Posso especificar uma política parcial numa ligação? (por exemplo, apenas os algoritmos de IKE, mas não IPsec)

Não, tem de especificar todos os parâmetros e algoritmos de IKE (modo principal) e IPsec (modo rápido). A especificação parcial da política não é permitida.

Quais são os algoritmos e os principais pontos fortes suportados na política personalizada?

A tabela a seguir lista os algoritmos criptográficos suportados e os pontos fortes das chaves que você pode configurar. Tem de selecionar uma opção para cada campo.

IPsec/IKEv2	Opções
Encriptação IKEv2	GCMAES256, GCMAES128, AES256, AES192, AES128
Integridade do IKEv2	SHA384, SHA256, SHA1, MD5
Grupo DH	DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Nenhum
Encriptação do IPsec	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, Nenhum
Integridade do IPsec	GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Grupo PFS	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Nenhum
Duração de SA QM	(Opcional: os valores padrão são usados se não forem especificados) Segundos (número inteiro; mín. 300 /predefinição de 27000 segundos) KBytes (número inteiro; mín. 1024 /predefinição de 102400000 KBytes)
Seletor de tráfego	UsePolicyBasedTrafficSelectors ($True/$False; Opcional**, padrão $False se não especificado)
Tempo limite do DPD	Segundos (inteiro: min. 9/máx. 3600; padrão 45 segundos)

A configuração de dispositivo VPN local deve corresponder ou deve conter os seguintes algoritmos e parâmetros que especificar na política de IPsec/IKE do Azure:
- Algoritmo de encriptação IKE (Modo Principal / Fase 1)
- Algoritmo de integridade IKE (Modo Principal / Fase 1)
- Grupo DH (Modo Principal / Fase 1)
- Algoritmo de encriptação IPsec (Modo Rápido / Fase 2)
- Algoritmo de integridade IPsec (Modo Rápido / Fase 2)
- Grupo PFS (Modo Rápido / Fase 2)
- Seletor de tráfego (se UsePolicyBasedTrafficSelectors for usado)
- Os tempos de vida da SA são apenas especificações locais e não precisam corresponder.
Se o GCMAES for usado como para o algoritmo de criptografia IPsec, você deverá selecionar o mesmo algoritmo GCMAES e o comprimento da chave para integridade IPsec; por exemplo, usando GCMAES128 para ambos.
Na tabela Algoritmos e chaves:
- O IKE corresponde ao Modo Principal ou à Fase 1.
- IPsec corresponde ao Modo Rápido ou Fase 2.
- O Grupo DH especifica o Grupo Diffie-Hellman usado no Modo Principal ou na Fase 1.
- O Grupo PFS especificou o Grupo Diffie-Hellman usado no Modo Rápido ou na Fase 2.
O tempo de vida da SA do Modo Principal IKE é fixado em 28.800 segundos nos gateways de VPN do Azure.
'UsePolicyBasedTrafficSelectors' é um parâmetro opcional na conexão. Se você definir UsePolicyBasedTrafficSelectors para $True em uma conexão, ele configurará o gateway de VPN do Azure para se conectar ao firewall VPN baseado em política localmente. Se você habilitar PolicyBasedTrafficSelectors, precisará garantir que seu dispositivo VPN tenha os seletores de tráfego correspondentes definidos com todas as combinações de seus prefixos de rede local (gateway de rede local) de/para os prefixos de rede virtual do Azure, em vez de qualquer para qualquer. O gateway de VPN do Azure aceita qualquer seletor de tráfego proposto pelo gateway de VPN remoto, independentemente do que está configurado no gateway de VPN do Azure.

Por exemplo, se os prefixos de rede local são 10.1.0.0/16 e 10.2.0.0/16, e os prefixos de rede virtual são 192.168.0.0/16 e 172.16.0.0/16, tem de especificar os seletores de tráfego seguintes:
- 10.1.0.0/16 <====> 192.168.0.0/16
- 10.1.0.0/16 <====> 172.16.0.0/16
- 10.2.0.0/16 <====> 192.168.0.0/16
- 10.2.0.0/16 <====> 172.16.0.0/16
Para obter mais informações sobre seletores de tráfego baseados em políticas, consulte Conectar vários dispositivos VPN locais baseados em políticas.
Tempo limite do DPD - O valor padrão é 45 segundos nos gateways de VPN do Azure. Definir o tempo limite para períodos mais curtos fará com que o IKE rechaveie de forma mais agressiva, fazendo com que a conexão pareça estar desconectada em alguns casos. Isso pode não ser desejável se seus locais locais estiverem mais distantes da região do Azure onde o gateway VPN reside ou se a condição de link físico puder incorrer em perda de pacote. A recomendação geral é definir o tempo limite entre 30 a 45 segundos.

Para obter mais informações, veja Connect multiple on-premises policy-based VPN devices (Ligar vários dispositivos VPN baseados em políticas no local).

Que Grupos de Diffie-Hellman são suportados?

A tabela a seguir lista os grupos Diffie-Hellman correspondentes suportados pela política personalizada:

Grupo Diffie-Hellman	DHGroup	PFSGroup	Comprimento da chave
1	DHGroup1	PFS1	MODP de 768 bits
2	DHGroup2	PFS2	MODP de 1024 bits
14	DHGroup14 DHGroup2048	PFS2048	MODP de 2048 bits
19	ECP256	ECP256	ECP de 256 bits
20	ECP384	ECP384	ECP de 384 bits
24	DHGroup24	PFS24	MODP de 2048 bits

Consulte RFC3526 e RFC5114 para obter mais detalhes.

A política personalizada substitui os conjuntos de políticas predefinidos de IPsec/IKE para gateways de VPN do Azure?

Sim, quando uma política personalizada é especificada numa ligação, o gateway de VPN do Azure só irá usar a política na ligação, como iniciador IKE e dispositivo de resposta IKE.

Se remover uma política de IPsec/IKE personalizada, a ligação torna-se desprotegida?

Não, a ligação ainda estará protegida pelo IPsec/IKE. Quando remove a política personalizada de uma ligação, o gateway de VPN do Azure reverte para a lista predefinida de propostas de IPsec/IKE e reinicia o handshake IKE novamente com o dispositivo VPN local.

Adicionar ou atualizar uma política de IPsec/IKE pode atrapalhar a minha ligação VPN?

Sim, pode causar uma pequena interrupção (alguns segundos), pois o gateway de VPN do Azure quebra a ligação existente e reinicia o handshake IKE para restabelecer o túnel IPsec com os novos parâmetros e algoritmos criptográficos. Verifique se o dispositivo VPN local também é configurado com os algoritmos correspondentes e os principais pontos fortes para minimizar a interrupção.

Posso usar políticas diferentes em ligações diferentes?

Sim. A política personalizada é aplicada consoante a ligação. Pode criar e aplicar diferentes políticas de IPsec/IKE em diferentes ligações. Também pode optar por aplicar políticas personalizadas num subconjunto de ligações. As restantes utilizam os conjuntos de políticas predefinidas de IPsec/IKE do Azure.

Também posso usar a política personalizada na ligação de VNet para VNet?

Sim, pode aplicar a política personalizada em ligações entre locais de IPsec ou em ligações VNet para VNet.

É necessário especificar a mesma política em ambos os recursos de ligação de VNet para VNet?

Sim. Um túnel de VNet para VNet consiste em dois recursos de ligação no Azure, uma para cada direção. Confirme que os recursos de ligação têm a mesma política, senão a ligação VNet para VNet não é estabelecida.

Qual é o valor padrão de tempo limite do DPD? Posso especificar um tempo limite de DPD diferente?

O tempo limite padrão do DPD é de 45 segundos. Você pode especificar um valor de tempo limite DPD diferente em cada conexão IPsec ou VNet-to-VNet, de 9 segundos a 3600 segundos.

Nota

O valor padrão é 45 segundos nos gateways de VPN do Azure. Definir o tempo limite para períodos mais curtos fará com que o IKE rechaveie de forma mais agressiva, fazendo com que a conexão pareça estar desconectada em alguns casos. Isso pode não ser desejável se seus locais locais estiverem mais distantes da região do Azure onde o gateway de VPN reside ou quando a condição de link físico puder incorrer em perda de pacote. A recomendação geral é definir o tempo limite entre 30 e 45 segundos.

A política de IPsec/IKE personalizada funciona na ligação do ExpressRoute?

N.º A política de IPsec/IKE só funciona em ligações VPN S2S e VNet para VNet por meio de gateways de VPN do Azure.

Como faço para criar conexões com o tipo de protocolo IKEv1 ou IKEv2?

As conexões IKEv1 podem ser criadas em todas as SKUs do tipo VPN RouteBased, exceto a SKU Básica, a SKU Padrão e outras SKUs herdadas. Você pode especificar um tipo de protocolo de conexão de IKEv1 ou IKEv2 ao criar conexões. Se você não especificar um tipo de protocolo de conexão, o IKEv2 será usado como opção padrão quando aplicável. Para obter mais informações, consulte a documentação do cmdlet do PowerShell. Para tipos de SKU e suporte a IKEv1/IKEv2, consulte Conectar gateways a dispositivos VPN baseados em políticas.

É permitido o trânsito entre as ligações IKEv1 e IKEv2?

Sim. O trânsito entre conexões IKEv1 e IKEv2 é suportado.

Posso ter conexões IKEv1 site a site em SKUs básicas do tipo RouteBased VPN?

N.º O Basic SKU não suporta isso.

Posso alterar o tipo de protocolo de conexão depois que a conexão é criada (IKEv1 para IKEv2 e vice-versa)?

N.º Depois que a conexão é criada, os protocolos IKEv1/IKEv2 não podem ser alterados. Você deve excluir e recriar uma nova conexão com o tipo de protocolo desejado.

Porque é que a minha ligação IKEv1 se religa frequentemente?

Se o seu roteamento estático ou conexão IKEv1 baseada em rota estiver se desconectando em intervalos de rotina, é provável que isso se deva aos gateways VPN não suportarem rechaves in-loco. Quando o modo principal está a ser rechaveado, os túneis IKEv1 desligam-se e demoram até 5 segundos a voltar a ligar. O valor do tempo limite de negociação do modo principal determina a frequência das rechaves. Para evitar essas reconexões, você pode alternar para usar o IKEv2, que suporta rechaves in-loco.

Se a sua ligação estiver a voltar a ligar-se em momentos aleatórios, siga o nosso guia de resolução de problemas.

Onde posso encontrar informações e etapas de configuração?

Consulte os seguintes artigos para obter mais informações e etapas de configuração.

BGP e roteamento

O BGP é suportado em todos os SKUs do VPN Gateway do Azure?

O BGP tem suporte em todas as SKUs do Gateway de VPN do Azure, exceto a SKU Básica.

Posso usar o BGP com gateways VPN de Política do Azure?

Não, o BGP é suportado apenas em gateways VPN baseados em rota.

Que ASNs (Autonomous System Numbers) posso usar?

Pode utilizar os seus próprios ASNs públicos ou ASNs privados para as suas redes locais e redes virtuais do Azure. Não é possível usar os intervalos reservados pelo Azure ou IANA.

Os seguintes ASNs são 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 e 429496729

Você não pode especificar esses ASNs para seus dispositivos VPN locais quando estiver se conectando aos gateways de VPN do Azure.

Posso usar ASNs de 32 bits (4 bytes)?

Sim, o VPN Gateway agora suporta ASNs de 32 bits (4 bytes). Para configurar usando ASN em formato decimal, use o PowerShell, a CLI do Azure ou o SDK do Azure.

Que ASNs privados posso usar?

As gamas utilizáveis de ASNs privadas são:

64512-65514 e 65521-65534

Esses ASNs não são reservados pela IANA ou pelo Azure para uso e, portanto, podem ser usados para atribuir ao seu gateway de VPN do Azure.

Qual endereço o VPN Gateway usa para IP de mesmo nível BGP?

Por padrão, o Gateway VPN aloca um único endereço IP do intervalo GatewaySubnet para gateways VPN em espera ativa ou dois endereços IP para gateways VPN ativos. Esses endereços são alocados automaticamente quando você cria o gateway VPN. Você pode obter o endereço IP BGP real alocado usando o PowerShell ou localizando-o no portal do Azure. No PowerShell, use Get-AzVirtualNetworkGateway e procure a propriedade bgpPeeringAddress . No portal do Azure, na página Configuração do Gateway, procure a propriedade Configurar ASN BGP.

Se seus roteadores VPN locais usarem endereços IP APIPA (169.254.x.x) como endereços IP BGP, você deverá especificar um ou mais endereços IP do Azure APIPA BGP em seu gateway de VPN do Azure. O Gateway de VPN do Azure seleciona os endereços APIPA a serem usados com o par BGP APIPA local especificado no gateway de rede local ou o endereço IP privado para um par BGP local não APIPA. Para obter mais informações, consulte Configurar BGP.

Quais são os requisitos para os endereços IP de mesmo nível BGP no meu dispositivo VPN?

Seu endereço de mesmo nível BGP local não deve ser o mesmo que o endereço IP público do seu dispositivo VPN ou do espaço de endereço de rede virtual do gateway VPN. Utilize um endereço IP diferente no dispositivo VPN do IP do elemento de rede BGP. Pode ser um endereço atribuído à interface de loopback no dispositivo (um endereço IP regular ou um endereço APIPA). Se seu dispositivo usa um endereço APIPA para BGP, você deve especificar um ou mais endereços IP APIPA BGP em seu gateway de VPN do Azure, conforme descrito em Configurar BGP. Especifique esses endereços no gateway de rede local correspondente que representa o local.

O que devo especificar como meus prefixos de endereço para o gateway de rede local quando uso o BGP?

Importante

Trata-se de uma alteração em relação ao requisito documentado anteriormente. Se você usar BGP para uma conexão, deixe o campo Espaço de endereço vazio para o recurso de gateway de rede local correspondente. O Gateway de VPN do Azure adiciona uma rota de host internamente ao IP de mesmo nível BGP local no túnel IPsec. Não adicione a rota /32 no campo Espaço de endereço . É redundante e se você usar um endereço APIPA como o dispositivo VPN local BGP IP, ele não poderá ser adicionado a este campo. Se você adicionar outros prefixos no campo Espaço de endereço , eles serão adicionados como rotas estáticas no gateway de VPN do Azure, além das rotas aprendidas via BGP.

Posso usar o mesmo ASN para redes VPN locais e redes virtuais do Azure?

Não, você deve atribuir ASNs diferentes entre suas redes locais e suas redes virtuais do Azure se estiver conectando-as junto com o BGP. Os gateways de VPN do Azure têm um ASN padrão de 65515 atribuído, quer o BGP esteja habilitado ou não para sua conectividade entre locais. Você pode substituir esse padrão atribuindo um ASN diferente ao criar o gateway VPN ou pode alterar o ASN depois que o gateway for criado. Você precisará atribuir seus ASNs locais aos gateways de rede local do Azure correspondentes.

Que prefixos de endereços irão os gateways de VPN do Azure anunciar-me?

Os gateways anunciam as seguintes rotas para seus dispositivos BGP locais:

Seus prefixos de endereço de rede virtual.
Prefixos de endereço para cada gateway de rede local conectado ao gateway de VPN do Azure.
Rotas aprendidas de outras sessões de emparelhamento BGP conectadas ao gateway de VPN do Azure, exceto para a rota padrão ou rotas que se sobrepõem a qualquer prefixo de rede virtual.

Quantos prefixos posso anunciar para o Gateway de VPN do Azure?

O Gateway de VPN do Azure suporta até 4000 prefixos. A sessão de BGP é ignorada se o número de prefixos exceder o limite.

Posso anunciar a rota predefinida (0.0.0.0/0) para gateways de VPN do Azure?

Sim. Observe que isso força todo o tráfego de saída da rede virtual em direção ao seu site local. Também impede que as VMs de rede virtual aceitem comunicações públicas diretamente da Internet, como RDP ou SSH da Internet para as VMs.

Posso anunciar os prefixos exatos como meus prefixos de rede virtual?

Não, anunciar os mesmos prefixos que qualquer um dos seus prefixos de endereço de rede virtual será bloqueado ou filtrado pelo Azure. Você pode, no entanto, anunciar um prefixo que é um superconjunto do que você tem dentro de sua rede virtual.

Por exemplo, se sua rede virtual usou o espaço de endereço 10.0.0.0/16, você pode anunciar 10.0.0.0/8. Mas você não pode anunciar 10.0.0.0/16 ou 10.0.0.0/24.

Posso usar BGP com minhas conexões entre redes virtuais?

Sim, você pode usar BGP para conexões entre locais e conexões entre redes virtuais.

Posso combinar ligações BGP com ligações não BGP para os meus gateways de VPN do Azure?

Sim, pode misturar ligações BGP e não BGP para o mesmo gateway de VPN do Azure.

O Gateway de VPN do Azure dá suporte ao roteamento de trânsito BGP?

Sim, o roteamento de trânsito BGP é suportado, com a exceção de que os gateways de VPN do Azure não anunciam rotas padrão para outros pares BGP. Para habilitar o roteamento de trânsito em vários gateways de VPN do Azure, você deve habilitar o BGP em todas as conexões intermediárias entre redes virtuais. Para obter mais informações, consulte Sobre o BGP.

Posso ter mais de um túnel entre um gateway de VPN do Azure e minha rede local?

Sim, você pode estabelecer mais de um túnel VPN site a site (S2S) entre um gateway de VPN do Azure e sua rede local. Observe que todos esses túneis são contados em relação ao número total de túneis para seus gateways de VPN do Azure e você deve habilitar o BGP em ambos os túneis.

Por exemplo, se você tiver dois túneis redundantes entre seu gateway de VPN do Azure e uma de suas redes locais, eles consomem 2 túneis da cota total para seu gateway de VPN do Azure.

Posso ter vários túneis entre duas redes virtuais do Azure com BGP?

Sim, mas pelo menos um dos gateways de rede virtual tem de estar na configuração de ativo-ativo.

Posso usar BGP para VPN S2S em uma configuração de coexistência do Azure ExpressRoute e S2S VPN?

Sim.

O que devo adicionar ao meu dispositivo VPN no local para a sessão de peering de BGP?

Adicione uma rota de host do endereço IP de mesmo nível BGP do Azure em seu dispositivo VPN. Essa rota aponta para o túnel VPN IPsec S2S. Por exemplo, se o IP de mesmo nível da VPN do Azure for 10.12.255.30, você adicionará uma rota de host para 10.12.255.30 com uma interface de próximo salto da interface de túnel IPsec correspondente em seu dispositivo VPN.

O gateway de rede virtual suporta BFD para conexões S2S com BGP?

N.º A Deteção de Encaminhamento Bidirecional (BFD) é um protocolo que você pode usar com o BGP para detetar o tempo de inatividade do vizinho mais rápido do que você pode usando "keepalives" BGP padrão. O BFD usa temporizadores subsegundos projetados para funcionar em ambientes LAN, mas não através da Internet pública ou conexões de rede de longa distância.

Para conexões pela internet pública, ter certos pacotes atrasados ou até mesmo descartados não é incomum, então introduzir esses temporizadores agressivos pode adicionar instabilidade. Essa instabilidade pode fazer com que as rotas sejam amortecidas pelo BGP. Como alternativa, você pode configurar seu dispositivo local com temporizadores menores do que o padrão, intervalo "keepalive" de 60 segundos e o temporizador de retenção de 180 segundos. Isto resulta num tempo de convergência mais rápido. No entanto, temporizadores abaixo do intervalo padrão de 60 segundos "keepalive" ou abaixo do temporizador de espera padrão de 180 segundos não são confiáveis. Recomenda-se manter os temporizadores em ou acima dos valores padrão.

Os gateways de VPN do Azure iniciam sessões ou conexões de emparelhamento BGP?

O gateway inicia sessões de emparelhamento BGP para os endereços IP de mesmo nível BGP locais especificados nos recursos do gateway de rede local usando os endereços IP privados nos gateways VPN. Isso é independentemente de os endereços IP BGP locais estarem no intervalo APIPA ou endereços IP privados regulares. Se seus dispositivos VPN locais usam endereços APIPA como IP BGP, você precisa configurar seu alto-falante BGP para iniciar as conexões.

Posso configurar o túnel forçado?

Sim. Veja Configurar imposição do túnel.

NAT

O NAT é suportado em todas as SKUs do Gateway de VPN do Azure?

NAT é suportado em VpnGw2~5 e VpnGw2AZ~5AZ.

Posso usar NAT em conexões VNet-to-VNet ou P2S?

N.º

Quantas regras NAT posso usar em um gateway VPN?

Você pode criar até 100 regras NAT (regras de entrada e saída combinadas) em um gateway VPN.

Posso usar / em um nome de regra NAT?

N.º Você receberá um erro.

O NAT é aplicado a todas as conexões em um gateway VPN?

NAT é aplicado às conexões com regras NAT. Se uma conexão não tiver uma regra NAT, a NAT não terá efeito nessa conexão. No mesmo gateway VPN, você pode ter algumas conexões com NAT e outras conexões sem NAT trabalhando em conjunto.

Que tipos de NAT são suportados nos gateways de VPN do Azure?

Apenas NAT estático 1:1 e NAT dinâmico são suportados. NAT64 NÃO é suportado.

O NAT funciona em gateways VPN ativos-ativos?

Sim. O NAT funciona em gateways VPN ativo-ativo e ativo-espera. Cada regra NAT é aplicada a uma única instância do gateway VPN. Em gateways ativos-ativos, crie uma regra NAT separada para cada instância de gateway por meio do campo "ID de configuração IP".

O NAT funciona com conexões BGP?

Sim, você pode usar BGP com NAT. Aqui estão algumas considerações importantes:

Selecione Ativar conversão de rota BGP na página de configuração de regras NAT para garantir que as rotas aprendidas e as rotas anunciadas sejam convertidas para prefixos de endereço pós-NAT (mapeamentos externos) com base nas regras NAT associadas às conexões. Você precisa garantir que os roteadores BGP locais anunciem os prefixos exatos, conforme definido nas regras do IngressSNAT.
Se o roteador VPN local usar um endereço regular não APIPA e colidir com o espaço de endereço da rede virtual ou outros espaços de rede locais, verifique se a regra IngressSNAT traduzirá o IP do par BGP para um endereço exclusivo e não sobreposto e colocará o endereço pós-NAT no campo Endereço IP do par BGP do gateway de rede local.
NAT não é suportado com endereços BGP APIPA.

Preciso criar as regras DNAT correspondentes para a regra SNAT?

N.º Uma única regra SNAT define a tradução para ambas as direções de uma rede específica:

Uma regra IngressSNAT define a conversão dos endereços IP de origem que entram no gateway de VPN do Azure a partir da rede local. Ele também lida com a tradução dos endereços IP de destino saindo da rede virtual para a mesma rede local.
Uma regra EgressSNAT define a tradução dos endereços IP de origem da rede virtual que saem do gateway de VPN do Azure para redes locais. Ele também lida com a tradução dos endereços IP de destino para pacotes que entram na rede virtual através dessas conexões com a regra EgressSNAT.
Em ambos os casos, não são necessárias regras DNAT .

O que devo fazer se a minha rede virtual ou o espaço de endereço do gateway de rede local tiver dois ou mais prefixos? Posso aplicar NAT a todos eles? Ou apenas um subconjunto?

Você precisa criar uma regra NAT para cada prefixo que você precisa NAT porque cada regra NAT só pode incluir um prefixo de endereço para NAT. Por exemplo, se o espaço de endereço do gateway de rede local consistir em 10.0.1.0/24 e 10.0.2.0/25, você poderá criar duas regras, conforme mostrado abaixo:

Regra 1 do IngressSNAT: Mapa 10.0.1.0/24 a 100.0.1.0/24
Regra 2 do IngressSNAT: Mapa 10.0.2.0/25 a 100.0.2.0/25

As duas regras devem corresponder aos comprimentos de prefixo dos prefixos de endereço correspondentes. O mesmo se aplica às regras EgressSNAT para o espaço de endereçamento da rede virtual.

Importante

Se você vincular apenas uma regra à conexão acima, o outro espaço de endereço NÃO será traduzido.

Que intervalos de IP posso usar para mapeamento externo?

Você pode usar qualquer intervalo de IP adequado que desejar para mapeamento externo, incluindo IPs públicos e privados.

Posso usar regras EgressSNAT diferentes para traduzir meu espaço de endereço VNet para prefixos diferentes para redes locais diferentes?

Sim, você pode criar várias regras EgressSNAT para o mesmo espaço de endereço VNet e aplicar as regras EgressSNAT a conexões diferentes.

Posso usar a mesma regra IngressSNAT em conexões diferentes?

Sim, isso normalmente é usado quando as conexões são para a mesma rede local para fornecer redundância. Não é possível usar a mesma regra de Ingresso se as conexões forem para redes locais diferentes.

Preciso das regras de Ingresso e Saída em uma conexão NAT?

Você precisa das regras de Entrada e Saída na mesma conexão quando o espaço de endereço de rede local se sobrepõe ao espaço de endereço de rede virtual. Se o espaço de endereço da rede virtual for exclusivo entre todas as redes conectadas, você não precisará da regra EgressSNAT nessas conexões. Você pode usar as regras de Ingresso para evitar a sobreposição de endereços entre as redes locais.

O que eu escolho como "ID de configuração IP"?

"IP configuration ID" é simplesmente o nome do objeto de configuração IP que você deseja que a regra NAT use. Com essa configuração, você está simplesmente escolhendo qual endereço IP público do gateway se aplica à regra NAT. Se você não tiver especificado nenhum nome personalizado no momento da criação do gateway, o endereço IP primário do gateway será atribuído à configuração de IP "padrão" e o IP secundário será atribuído à configuração de IP "activeActive".

VMs e conectividade em vários locais

Se a minha máquina virtual estiver numa rede virtual e tiver uma ligação em vários locais, como devo estabelecer ligação à VM?

Tem algumas opções. Se tiver o RDP ativado para a sua VM, pode ligar à máquina virtual através do endereço IP privado. Nesse caso, deve especificar o endereço IP privado e a porta à qual quer ligar (normalmente, 3389). Terá de configurar a porta na sua máquina virtual para o tráfego.

Também pode ligar à máquina virtual através do endereço IP privado a partir de outra máquina virtual que esteja localizada na mesma rede virtual. Você não pode RDP para sua máquina virtual usando o endereço IP privado se estiver se conectando de um local fora da sua rede virtual. Por exemplo, se você tiver uma rede virtual ponto a site configurada e não estabelecer uma conexão a partir do seu computador, não poderá se conectar à máquina virtual por endereço IP privado.

Se a minha máquina virtual estiver numa rede virtual com conetividade em vários locais, todo o tráfego da minha VM passa por essa ligação?

N.º Apenas o tráfego que tem um IP de destino contido nos intervalos de endereços IP da Rede Local da rede virtual que especificou passará pelo gateway de rede virtual. O tráfego tem um IP de destino localizado na rede virtual e permanece na rede virtual. O outro tipo de tráfego é enviado através do balanceador de carga para as redes públicas, ou se a imposição do túnel for utilizada, é enviado através do gateway de VPN do Azure.

Como resolver problemas de uma ligação RDP numa VM

Se estiver a ter problemas para ligar a uma máquina virtual através da sua ligação VPN, verifique os seguintes itens:

Certifique-se de que a ligação VPN é efetuada com êxito.
Verifique se você está se conectando ao endereço IP privado da VM.
Caso consiga ligar-se à VM utilizando o endereço IP privado, mas não o nome do computador, certifique-se de que configurou o DNS corretamente. Para obter mais informações sobre como funciona a resolução de nomes para VMs, consulte o artigo Name Resolution for VMs(Resolução de Nomes para VMs).

Quando se liga através de Ponto a Site, verifique os seguintes itens adicionais:

Use 'ipconfig' para verificar o endereço IPv4 atribuído ao adaptador Ethernet no computador do qual você está se conectando. Se o endereço IP estiver dentro do intervalo de endereços da rede virtual à qual você está se conectando ou dentro do intervalo de endereços do seu VPNClientAddressPool, isso é chamado de espaço de endereçamento sobreposto. Quando o seu espaço de endereços se sobrepõe desta forma, o tráfego de rede não chega ao Azure e permanece na rede local.
Verifique se o pacote de configuração do cliente VPN foi gerado depois que os endereços IP do servidor DNS foram especificados para a rede virtual. Se atualizou os endereços IP do servidor DNS, gere e instale um novo pacote de configuração de cliente VPN.

Para obter mais informações sobre a resolução de problemas de uma ligação RDP, veja Troubleshoot Remote Desktop connections to a VM(Resolução de Problemas de ligações de Ambiente de Trabalho Remoto a uma VM).

Manutenção de gateway controlada pelo cliente

Quais serviços estão incluídos no escopo Configuração de Manutenção de Gateways de Rede?

O escopo Gateways de Rede inclui recursos de gateway em Serviços de rede. Há quatro tipos de recursos no escopo de Gateways de Rede:

Gateway de rede virtual no serviço ExpressRoute.
Gateway de rede virtual no serviço Gateway VPN.
Gateway VPN (Site-to-Site) no serviço WAN Virtual.
Gateway de Rota Expressa no serviço 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. As atualizações do host, além das atualizações do host (TOR, Power etc.) e das atualizações críticas de segurança, não são cobertas pela manutenção controlada pelo cliente.

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 uma janela de manutenção diferente da programação diária?

Neste momento, você precisa configurar uma janela de manutenção diária.

Existem casos em que não consigo controlar determinadas atualizações?

A manutenção controlada pelo cliente suporta atualizações do SO convidado e do serviço. Essas atualizações são responsáveis pela maioria dos itens de manutenção que causam preocupação para os clientes. Alguns outros tipos de atualizações, incluindo atualizações de host, estão fora do escopo da 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 enviar a alteração. Estas são ocorrências raras que só seriam usadas em casos extremos.

Os recursos de Configuração de Manutenção precisam estar na mesma região que o recurso de gateway?

Sim

Quais SKUs de gateway podem ser configurados para usar a manutenção controlada pelo cliente?

Todas as SKUs de gateway (exceto a SKU Básica para Gateway VPN) podem ser configuradas para usar manutenção controlada pelo cliente.

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.

Há alguma limitação no uso da manutenção controlada pelo cliente com base no endereço IP público SKU básico?

Sim. Os recursos de gateway que usam um endereço IP público de SKU Básico só poderão ter atualizações de serviço seguindo o cronograma de manutenção controlado pelo cliente. Para esses gateways, a manutenção do SO convidado NÃO segue o cronograma de manutenção controlado pelo cliente devido a limitações de infraestrutura.

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.

Como posso saber mais sobre a manutenção de gateway controlada pelo cliente?

Para obter mais informações, consulte o artigo Manutenção de gateway controlado pelo cliente do Gateway VPN.

Próximos passos

Para obter mais informações sobre o Gateway de VPN, veja About VPN Gateway (Acerca do Gateway de VPN).
Para obter mais informações sobre as definições de configuração do Gateway de VPN, veja About VPN Gateway configuration settings (Acerca das definições de configuração do gateway de VPN).

"OpenVPN" é uma marca comercial da OpenVPN Inc.