Compartilhar via

Perguntas frequentes de gateway de VPN

  • Artigo

Este artigo responde a perguntas frequentes sobre conexões entre locais do Gateway de VPN do Azure, conexões de configuração híbrida e gateways de rede virtual (VNet). Ele contém informações abrangentes sobre P2S (ponto a site), S2S (site a site) e configurações de VNet para VNet, incluindo os protocolos IPsec (Internet Protocol Security) e IKE (Internet Key Exchange).

Conectando-se a redes virtuais

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

Sim. Não há restrição de região. Uma rede virtual pode se conectar a outra rede virtual na mesma região ou em outra região do Azure.

Posso conectar redes virtuais em assinaturas diferentes?

Sim.

Posso especificar servidores DNS privados em minha VNet ao configurar o gateway de VPN?

Se você especificar um servidor ou servidores DNS (Sistema de Nomes de Domínio) ao criar sua rede virtual, o gateway de VPN (rede virtual privada) usará esses servidores DNS. Verifique se os servidores DNS especificados podem resolver os nomes de domínio necessários para o Azure.

Posso me conectar vários sites de uma única rede virtual?

Você pode se conectar a vários sites usando o Windows PowerShell e as APIs REST do Azure. Consulte a seção Conectividade multissite e de VNet para VNet das perguntas frequentes.

Há um custo adicional para configurar um gateway de VPN como ativo-ativo?

Não. No entanto, os custos para quaisquer IPs públicos adicionais são cobrados de acordo. Consulte Preços do endereço IP.

Quais são minhas opções de conexão entre locais?

O Gateway de VPN do Azure dá suporte às seguintes conexões de gateway entre locais:

Para saber mais sobre conexões de gateway de VPN, confira O que é o Gateway de VPN do Azure?.

Qual é a diferença entre conexões site a site e ponto a site?

  • As configurações site a site (túnel VPN IPsec/IKE) são entre o local e o Azure. Você pode conectar, a partir de qualquer um dos computadores localizados em suas instalações, qualquer VM (máquina virtual) ou instância de função em sua rede virtual, dependendo de como você escolhe configurar o roteamento e as permissões. É uma ótima opção para uma conexão entre locais sempre disponível e é bastante adequada para configurações híbridas.

    Esse tipo de conexão depende de um dispositivo DE VPN IPsec (dispositivo de hardware ou soft appliance). O dispositivo precisa ser implantado na borda da 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 no SSTP) permitem conectar, a partir de um único computador e de qualquer lugar, qualquer coisa localizada em sua rede virtual. Ele usa o cliente VPN interno do Windows.

    Como parte da configuração ponto a site, você instala um certificado e um pacote de configuração de cliente VPN. O pacote 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.

    Essa configuração é útil quando você deseja se conectar a uma rede virtual, mas não está localizado no local. Também é uma boa opção quando você não tem acesso a hardware de VPN ou a um endereço IPv4 voltado para o exterior, sendo que ambos são necessários para uma conexão site a site.

Você pode configurar sua rede virtual para usar as opções de site a site e ponto a site simultaneamente, desde que crie sua conexão site a site usando um tipo de VPN com base em rota para seu gateway. Tipos de VPN baseados em rota são chamados de gateways dinâmicos no modelo de implantação clássico.

Uma configuração incorreta do DNS personalizado interrompe a operação normal de um Gateway de VPN?

Para o funcionamento normal, o gateway de VPN precisa estabelecer uma conexão segura com o painel de controle do Azure, facilitada por meio de endereços IP públicos. Essa conexão depende da resolução de pontos de extremidade de comunicação por meio de URLs públicas. Por padrão, as VNets do Azure usam o serviço DNS do Azure interno (168.63.129.16) para resolver essas URLs públicas. Esse comportamento padrão ajuda a garantir a comunicação perfeita entre o gateway de VPN e o painel de controle do Azure.

Ao implementar um DNS personalizado em uma VNet, é crucial configurar um encaminhador DNS que aponte para o DNS do Azure (168.63.129.16). Essa configuração ajuda a manter a comunicação ininterrupta entre o gateway de VPN e o painel de controle. A falha ao configurar um encaminhador DNS para o DNS do Azure pode impedir a Microsoft de executar operações e manutenção no Gateway de VPN, representando um risco à segurança.

Para ajudar a garantir a funcionalidade adequada e o estado íntegro para seu gateway de VPN, considere uma das seguintes configurações de DNS na VNet:

  • Reverta para o padrão do DNS do Azure removendo o DNS personalizado dentro das configurações de VNet (configuração recomendada).
  • Adicione à sua configuração DNS personalizada um encaminhador DNS que aponta para o DNS do Azure (168.63.129.16). Dependendo das regras específicas e da natureza do DNS personalizado, essa configuração pode não resolver o problema conforme o esperado.

É possível haver uma comunicação entre dois clientes VPN conectados em ponto a site ao mesmo Gateway de VPN?

Não. Os clientes VPN conectados ponto a site ao mesmo gateway de VPN não podem se comunicar entre si.

Quando dois clientes VPN estão conectados ao mesmo gateway de VPN ponto a site, o gateway pode rotear automaticamente o tráfego entre eles determinando o endereço IP atribuído a cada cliente do pool de endereços. No entanto, se os clientes VPN estiverem conectados a gateways de VPN diferentes, o roteamento entre os clientes VPN não será possível porque cada gateway de VPN não tem conhecimento do endereço IP atribuído pelo outro gateway ao cliente.

Uma vulnerabilidade potencial conhecida como "visão de túnel" pode afetar conexões VPN ponto a site?

A Microsoft está ciente dos relatórios que discutem a técnica de rede que ignora o encapsulamento de VPN. Este é um problema em todo o setor. Ele afeta qualquer sistema operacional que implemente um cliente DHCP de acordo com sua especificação RFC e tenha suporte para rotas de Opção 121 do DHCP, incluindo o Windows.

Assim como as notas de pesquisa, as mitigações incluem a execução de VPN dentro de uma VM que obtém uma concessão de um servidor DHCP virtualizado para impedir que o servidor DHCP de redes locais instale totalmente as rotas. Você pode encontrar mais informações sobre essa vulnerabilidade no Banco de Dados de Vulnerabilidade Nacional NIST.

Privacidade

O serviço de VPN armazena ou processa os dados do cliente?

Não.

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 criptografado entre sua rede virtual e seu local em uma conexão pública. Você também pode usar o Gateway de VPN para enviar tráfego entre redes virtuais. Quando você cria um gateway de VPN, pode usar o valor -GatewayType de Vpn. Para saber mais, veja Sobre as configurações de Gateway de VPN.

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

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

Anteriormente, as SKUs (camadas de produto) de gateway mais antigas não dão suporte ao IKEv1 para gateways baseados em rota. Agora, a maioria dos SKUs de gateway atuais dá suporte a IKEv1 e IKEv2.

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

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

Não. Um tipo de gateway não pode ser alterado de baseado em política para baseado em rota e vice-versa. Para alterar um tipo de gateway, você precisa excluir e recriar o gateway seguindo as etapas a seguir. Esse processo leva cerca de 60 minutos. Ao criar o gateway, você não pode reter o endereço IP do gateway original.

  1. Exclua todas as conexões associadas ao gateway.

  2. Exclua o gateway usando um dos seguintes artigos:

  3. Crie um gateway usando o tipo de gateway que você deseja e conclua a configuração da VPN. Para ver as etapas, consulte o tutorial de site a site.

Posso especificar meus seletores de tráfego baseados em políticas?

Sim, você pode definir seletores de tráfego usando o atributo trafficSelectorPolicies em uma conexão por meio do comandol New-AzIpsecTrafficSelectorPolicy do Azure PowerShell. Para que o seletor de tráfego especificado entre em vigor, verifique se você habilitou os seletores de tráfego baseados em política.

Os seletores de tráfego configurados personalizados só são propostos quando um gateway de VPN inicia a conexão. Um gateway VPN aceita quaisquer seletores de tráfego propostos por um gateway remoto (dispositivo VPN local). Esse comportamento é consistente entre todos os modos de conexão (Default InitiatorOnly e ResponderOnly).

Preciso de uma sub-rede de gateway?

Sim. A sub-rede de gateway contém os endereços IP que usam os serviços de gateway de rede virtual. Você precisa criar uma sub-rede de gateway para sua rede virtual para configurar um gateway de rede virtual.

Todas as sub-redes de gateway precisam ser nomeadas como GatewaySubnet para funcionar adequadamente. Não dê outro nome à sua sub-rede de gateway. E não implante VMs ou qualquer outra coisa na sub-rede de gateway.

Quando você cria a sub-rede de gateway, pode especificar o número de endereços IP que contém a sub-rede. Os endereços IP na sub-rede do gateway são alocados para o serviço de gateway.

Algumas configurações exigem mais endereços IP a ser alocada para os serviços de gateway que outras pessoas. Verifique se a sub-rede do gateway contém endereços IP suficientes para acomodar o crescimento futuro e possíveis novas configurações de conexão.

Embora seja possível criar uma sub-rede de gateway tão pequena quanto /29, é recomendável criar uma sub-rede de gateway de /27 ou maior (/27, /26, /25 etc.). Verifique se sua sub-rede de gateway existente atende aos requisitos para a configuração que você deseja criar.

Posso implantar máquinas virtuais ou instâncias de função na minha sub-rede de gateway?

Não.

Posso obter o endereço IP do gateway de VPN antes de criá-lo?

Os recursos de IP público do SKU Standard do Azure devem usar um método de alocação estático. Você terá o endereço IP público para o gateway de VPN assim que criar o recurso de IP público do SKU Standard que pretende usar para ele.

Eu posso solicitar um endereço IP público para o meu gateway de VPN?

Os recursos do endereço IP público de SKU Standard devem usar um método de alocação estático. A partir de agora, você deve usar um endereço IP público de SKU padrão ao criar um novo gateway de VPN. Isso se aplica a todos os SKUs de gateway, exceto o SKU Básico. Atualmente, o SKU Básico dá suporte apenas a endereços IP públicos de SKU Básico. Estamos trabalhando na adição de suporte para endereços IP públicos do SKU Standard para o SKU Básico.

Para gateways que sem redundância de zonas e não são zonais, que foram previamente criados (SKUs de gateway que não têm AZ no nome), há suporte para a atribuição dinâmica de endereços IP, mas está sendo gradualmente descontinuada. Quando você usa um endereço IP dinâmico, o endereço IP não é alterado depois de ter sido atribuído ao gateway de VPN. A única vez em que o endereço IP de gateway de VPN é alterado é quando o gateway é excluído e, em seguida, recriado. O endereço IP público não é alterado quando você redimensiona, redefine ou conclui outras manutenções internas e atualizações do gateway de VPN.

Como a desativação de endereços IP públicos de SKU Basic afeta meus gateways de VPN?

Estamos tomando medidas para garantir a operação contínua de gateways VPN implantados que usam endereços IP públicos de SKU Básico, até a desativação do IP básico em setembro de 2025. Antes dessa desativação, forneceremos aos clientes um caminho de migração do IP Básico para o Standard.

No entanto, os endereços IP públicos de SKU Básico estão sendo eliminados gradualmente. A partir de agora, ao criar um gateway de VPN, você precisa usar o endereço IP público do SKU Standard. Você pode encontrar detalhes sobre a desativação de endereços IP públicos do SKU Básico no comunicado das Atualizações do Azure.

Como meu túnel VPN é autenticado?

O Gateway de VPN do Azure usa a autenticação PSK (chave pré-compartilhada). Geramos uma PSK durante a criação do túnel de VPN. Você pode alterar o PSK gerado automaticamente para o seu usando a API REST de chave pré-compartilhada definida ou o cmdlet do PowerShell.

Posso usar a API REST Definir chave pré-compartilhada para configurar minha VPN de gateway baseada em política (roteamento estático)?

Sim. Você pode usar a API REST de Chave Pré-Compartilhada definida e o cmdlet do PowerShell para configurar VPNs baseadas em políticas do Azure (estáticas) e VPNs de roteamento baseadas em rota (dinâmicas).

É possível usar outras opções de autenticação?

O uso de chaves pré-compartilhadas está limitado apenas para a autenticação.

Como especificar qual tráfego passa pelo gateway de VPN?

Para o modelo de implantação do Azure Resource Manager:

  • Azure PowerShell: use AddressPrefix para especificar o tráfego para o gateway de rede local.
  • Portal do Azure: acesse o gateway de rede local>Configuração>Espaço de endereço.

Para o modelo de implantação clássico:

  • Portal do Azure: navegue até a rede virtual clássica e acesse Conexões VPN>Conexões VPN Site a Site>Nome do site Local>Site local>Espaço de endereço do cliente.

Posso usar um NAT-T em minhas conexões VPN?

Sim, há suporte para NAT-T (travessia de conversão de endereços de rede). O Gateway de VPN do Azure não executa nenhuma funcionalidade semelhante ao NAT de/para túneis IPsec nos pacotes internos. Nessa configuração, verifique se o dispositivo local inicia o túnel IPsec.

Posso configurar meu próprio servidor de VPN no Azure e usá-lo para me conectar à minha rede local?

Sim. Você pode implantar seus gateways de VPN ou servidores no Azure por meio do Azure Marketplace ou criando seus roteadores de VPN. Você precisa configurar as rotas definidas pelo usuário em sua rede virtual para garantir que o tráfego seja roteado corretamente entre suas redes locais e as sub-redes da rede virtual.

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

Elas são necessárias para a comunicação de infraestrutura do Azure. Os certificados do Azure ajudam a protegê-los bloqueando-os. Sem certificados apropriados, entidades externas, incluindo os clientes desses gateways, não conseguirão causar efeitos nesses pontos de extremidade.

Um gateway de rede virtual é fundamentalmente um dispositivo multihomed. Um adaptador de rede toca na rede privada do cliente e um adaptador de rede está voltado para a rede pública. As entidades de infraestrutura do Azure não podem tocar em redes privadas de cliente por motivos de conformidade, devendo usar pontos de extremidade públicos para comunicação de infraestrutura. Uma auditoria de segurança do Azure examina periodicamente os pontos de extremidade públicos.

Posso criar um gateway de VPN usando o SKU de gateway Básico no portal?

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

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

Veja os artigos a seguir:

Substituição de SKUs mais antigos

As SKUs Standard e de Alto Desempenho serão descontinuadas em 30 de setembro de 2025. Você pode exibir o comunicado no site das Atualizações do Azure. A equipe do produto disponibilizará um caminho de migração para essas SKUs até 30 de novembro de 2024. Para obter mais informações, confira o artigo SKUs herdados de Gateways de VPN.

Neste momento, você não precisa tomar providências.

Posso criar um novo gateway que usa um SKU Standard ou de Alto desempenho após o comunicado de substituição em 30 de novembro de 2023?

Não. A partir de 1º de dezembro de 2023, você não pode criar gateways que usam SKUs Standard ou de Alto desempenho. Você pode criar gateways que usam VpnGw1 e VpnGw2 pelo mesmo preço que o dos SKUs Standard e de Alto Desempenho, listados respectivamente na página de preços.

Por quanto tempo meus gateways existentes terão suporte nos SKUs Standard e de Alto Desempenho?

Todos os gateways existentes que usam SKUs Standard ou de Alto Desempenho terão suporte até 30 de setembro de 2025.

É necessário migrar os gateways do SKU Standard ou de Alto desempenho agora?

Não, nenhuma ação é necessária no momento. Você pode migrar seus gateways a partir de dezembro de 2024. Enviaremos um comunicado com uma documentação detalhada sobre as etapas de migração.

Para qual SKU posso migrar meu gateway?

Quando a migração de SKUs de gateways estiver disponível, os SKUs poderão ser migrados da seguinte maneira:

  • Standard para VpnGw1
  • Alto desempenho para VpnGw2

E se eu quiser migrar para um SKU do AZ?

Você não pode migrar sua SKU preterida para um SKU do AZ. No entanto, todos os gateways que ainda estiverem usando SKUs Standard ou de Alto Desempenho após 30 de setembro de 2025 serão migrados e atualizados automaticamente para os SKUs do AZ conforme a seguir:

  • Standard para VpnGw1AZ
  • Alto desempenho para VpnGw2AZ

Você pode usar essa estratégia para que seus SKUs sejam migrados e atualizados automaticamente para um SKU do AZ. Em seguida, você pode redimensionar seu SKU dentro dessa família de SKUs, se for preciso. Para obter preços de SKU do AZ, consulte a página de preços. Para obter informações sobre a taxa de transferência por SKU, confira Sobre SKUs de gateway.

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

Se você migrar suas 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 Padrão e de Alto Desempenho, respectivamente.

Se você não migrar até essa data, seus SKUs serão migrados e atualizados automaticamente para SKUs do AZ. Nesse caso, há uma diferença de preço.

Haverá algum impacto sobre o desempenho dos meus gateways com essa migração?

Sim. Você obterá um desempenho melhor com o VpnGw1 e o VpnGw2. Atualmente, o VpnGw1 a 650 Mbps fornece uma melhoria de desempenho de 6,5 vezes com o mesmo preço que o SKU Standard. VpnGw2 a 1 Gbps fornece uma melhoria de desempenho de 5 vezes com o mesmo preço que o SKU de Alto desempenho. Para obter mais informações sobre a taxa de transferência de SKU, consulte Sobre SKUs de gateway.

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

Todos os gateways que ainda usam SKUs Standard ou de Alto Desempenho serão migrados e atualizados automaticamente para os seguintes SKUs do AZ:

  • Standard para VpnGw1AZ
  • Alto desempenho para VpnGw2AZ

Enviaremos comunicação antes de iniciar a migração em qualquer gateway.

O SKU Básico do Gateway de VPN também está sendo desativado?

Não, o SKU Básico do Gateway de VPN não está sendo desativado. Você pode criar um Gateway de VPN usando o SKU Básico por meio do Azure PowerShell ou da CLI do Azure.

Atualmente, os SKUs Básicos de Gateway de VPN dá suporte apenas para o recurso de endereço IP público de SKU Básico (que está preste a ser desativado). Estamos trabalhando para adicionar suporte ao recurso de endereço IP público do SKU Standard para o SKU Básico de Gateway de VPN.

Conexões site a site e dispositivos VPN

O que devo considerar ao escolher um dispositivo VPN?

Validamos um conjunto de dispositivos VPN site a site padrão em parceria com fornecedores de dispositivos. Você pode encontrar uma lista de dispositivos VPN compatíveis conhecidos, suas instruções de configuração ou exemplos correspondentes e especificações de dispositivo no artigo Sobre dispositivos VPN.

Todos os dispositivos das famílias de dispositivos listadas como compatíveis e conhecidas devem funcionar com redes virtuais. Para ajudar a configurar seu dispositivo VPN, consulte o exemplo de configuração do dispositivo ou o link que corresponde à família de dispositivos apropriada.

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

Dependendo do dispositivo VPN que você tem, talvez seja possível fazer o download de um script de configuração do dispositivo VPN. Para saber mais, confira Fazer download dos scripts de configuração de dispositivo de VPN.

Os links a seguir fornecem mais informações de configuração:

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

Confira Edição de exemplos de configuração de dispositivo.

Onde encontro os parâmetros IPsec e IKE?

Veja Parâmetros IKE/IPsec padrão.

Por que meu túnel VPN baseado em políticas é desativado quando o tráfego está ocioso?

Esse comportamento é esperado para gateways de VPN baseados em política (também conhecidos como roteamento estático). Quando o tráfego sobre o túnel fica ocioso por mais de cinco minutos, o túnel é derrubado. Quando o tráfego começa a fluir em qualquer direção, o túnel é restabelecido imediatamente.

Posso usar VPNs de software para me conectar ao Azure?

Há suporte para servidores de Roteamento e Acesso Remoto do Windows Server 2012 para configuração entre locais site a site.

Outras soluções VPN de software devem funcionar com o gateway, contanto que estejam em conformidade com implementações de IPsec padrão do setor. Contate o fornecedor do software para obter instruções de configuração e suporte.

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

Sim, mas os endereços IP públicos do cliente ponto a site precisam ser diferentes dos endereços IP públicos usados pelo dispositivo VPN site a site, caso contrário, a conexão ponto a site não funcionará. Conexões ponto a site com IKEv2 não podem ser iniciadas a partir dos mesmos endereços IP públicos em que uma conexão VPN site a site esteja configurada no mesmo gateway de VPN.

Conexões ponto a site

Quantos pontos de extremidade do cliente VPN posso ter na minha configuração de ponto a site?

Isso depende da SKU de gateway. Para obter mais informações sobre o número de conexões com suporte, confira SKUs de Gateway.

Quais sistemas operacionais de cliente posso usar com ponto a site?

Há suporte para os seguintes sistemas operacionais de cliente:

  • Windows Server 2008 R2 (somente 64 bits)
  • Windows 8.1 (32 bits e 64 bits)
  • Windows Server 2012 (somente 64 bits)
  • Windows Server 2012 R2 (somente 64 bits)
  • Windows Server 2016 (somente 64 bits)
  • Windows Server 2019 (somente 64 bits)
  • Windows Server 2022 (somente 64 bits)
  • Windows 10
  • Windows 11
  • macOS, versão 10.11 ou posterior
  • Linux (strongSwan)
  • iOS

Posso atravessar proxies e firewalls usando a funcionalidade de ponto a site?

O Azure dá suporte a três tipos de opções de VPN ponto a site:

  • O SSTP (Secure Sockets Tunneling Protocol) é uma solução baseada em SSL da Microsoft que pode invadir firewalls, já que a maioria dos firewalls abre a porta TCP de saída, que usa SSL 443.

  • OpenVPN: é uma solução baseada em SSL que pode penetrar em firewalls, já que a maioria dos firewalls abre a porta TCP de saída, 443, usada pelo SSL.

  • VPN IKEv2: é uma solução de VPN IPsec baseada em padrões que usa as portas UDP de saída 500 e 4500 e o protocolo IP número 50. Nem sempre os firewalls abrem essas portas, por isso, há uma possibilidade de a VPN IKEv2 não conseguir 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 utilizado. O Windows dá suporte à Reconexão Automática por meio do recurso de cliente VPN Always On.

O ponto a site oferece suporte a DDNS nos clientes VPN?

No momento, o DDNS (DNS dinâmico) não é compatível com VPNs ponto a site.

As configurações site a site e ponto a site podem coexistir para a mesma rede virtual?

Sim. Para o modelo de implantação do Resource Manager, você precisa ter um tipo de VPN RouteBased para o gateway. Para o modelo de implantação clássica, você precisará de um gateway dinâmico. Não damos suporte a ponto a site para o roteamento estático de gateways de VPN ou gateways de VPN baseados em política.

Posso configurar um cliente de 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. Mas esse é o caso somente se as redes virtuais às quais você está se conectando não têm espaços de endereço conflitantes entre elas ou com a rede da qual o cliente está se conectando. Embora o cliente VPN do Azure dê suporte a muitas conexões VPN, você pode ter apenas uma conexão em um determinado momento.

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

Sim. Conexões de cliente ponto a site com um gateway de VPN implantado em uma VNet emparelhada com outras VNets podem ter acesso a outras VNets emparelhadas, desde que atendam a determinados critérios de configuração. Para que um cliente ponto a site tenha acesso a uma VNet emparelhada, a VNet emparelhada (a VNet sem o gateway) precisa ser configurada com o atributo Usar gateways remotos. A VNet com o gateway de VPN precisa ser configurada com Permitir o trânsito de gateway. Para saber mais, consulte Sobre o roteamento VPN ponto a site.

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

É difícil manter a taxa de transferência exata dos túneis de VPN. IPsec e SSTP são protocolos VPN de criptografia pesada. A latência e pela largura de banda entre seus locais e na Internet também podem limitar a taxa de transferência.

Para um gateway de VPN apenas com conexões de VPN de ponto a site IKEv2, a taxa de transferência total que você pode esperar depende do SKU do gateway. Para saber mais sobre taxa de transferência, confira SKUs de gateway.

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

Não. Você só pode usar o cliente VPN nativo no Windows para SSTP, e o cliente VPN nativo no Mac para IKEv2. No entanto, você pode usar o cliente OpenVPN em todas as plataformas para se conectar por meio do protocolo OpenVPN. Consulte a lista dos sistemas operacionais compatíveis de cliente.

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

Sim. No portal, acesse a Gateway de VPN>Configuração de ponto a site. Para o Tipo de autenticação, selecione os tipos de autenticação que você deseja usar.

Depois de você alterar o tipo de autenticação, os clientes atuais podem não conseguir se conectar até que você gere um novo perfil de configuração do cliente VPN, baixe-o e aplique-o a cada cliente VPN.

Quando preciso gerar um novo pacote de configuração para o perfil de cliente VPN?

Quando você faz alterações nas configurações do gateway de VPN P2S, como adicionar um tipo de túnel ou alterar um tipo de autenticação, é necessário gerar um novo pacote de configuração para o perfil do cliente VPN. O novo pacote inclui as configurações atualizadas que os clientes VPN precisam para se conectar ao gateway P2S. Após gerar o pacote, utilize as configurações contidas nos arquivos para atualizar os clientes VPN.

O Azure oferece suporte à VPN IKEv2 com o Windows?

O IKEv2 é compatível com o Windows 10 e o Windows Server 2016. No entanto, para usar o IKEv2 em determinadas versões do sistema operacional, você precisa instalar as atualizações e definir um valor de chave do Registro localmente. Não há suporte para versões do sistema operacional anteriores ao Windows 10 e podem usar apenas o protocolo SSTP ou OpenVPN.

Observação

Os builds do sistema operacional Windows mais recentes do que o Windows 10 versão 1709 e do Windows Server 2016 versão 1607 não exigem essas etapas.

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

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

    Versão do SO Data Número/Link
    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 de 2018 BDC4089848

  2. Defina o valor da chave do Registro. Criar ou definir chave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload REG_DWORD no registro para 1.

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

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

O limite de seletor 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 para VNet e VNets correspondentes conectadas ao gateway. Os clientes ponto a site baseados em Windows não conseguirão se conectar por meio de IKEv2 se ultrapassarem esse limite.

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

O limite de seletores de tráfego para o OpenVPN é de 1.000 rotas.

O que acontece quando eu configuro SSTP e IKEv2 para conexões VPN de P2S?

Ao configurar tanto o SSTP como o IKEv2 em um ambiente misto composto por dispositivos Windows e Mac, o cliente VPN do Windows sempre tentará primeiro o túnel IKEv2. O cliente retornará ao SSTP se a conexão IKEv2 não for bem-sucedida. O macOS conecta-se somente por meio do IKEv2.

Quando você tem tanto SSTP quanto IKEv2 habilitados no gateway, o pool de endereços ponto a site é dividido estaticamente entre os dois e, portanto, os clientes que usam protocolos diferentes são endereços IP de um dos dois subintervalos. O número máximo de clientes SSTP é sempre 128, mesmo que o intervalo de endereços seja maior que /24. O resultado é um número maior de endereços disponíveis para clientes IKEv2. Para intervalos menores, o pool é dividido igualmente pela metade. Os seletores de tráfego usados pelo gateway podem não incluir o bloco CIDR (roteamento entre domínios sem classe) para o intervalo de endereços ponto a site, mas incluem o bloco CIDR para os dois subintervalos.

A quais plataformas o Azure dá suporte para VPN P2S?

O Azure é compatível com Windows, Mac e Linux para VPN P2S.

Eu já tenho um gateway de VPN implantado. É possível habilitar RADIUS e/ou IKEv2 VPN nele?

Sim. Se o SKU do gateway utilizado for compatível com RADIUS ou IKEv2, você poderá habilitar esses recursos nos gateways que já implantou por meio do Azure PowerShell ou do portal do Azure. Observe que o SKU Básico não oferece suporte a RADIUS ou IKEv2.

Por que estou sendo desconectado do meu cliente VPN do Azure? O que posso fazer para reduzir a frequência de desconexão?

Você deve ver uma das seguintes mensagens:

  • No cliente VPN do Azure para Windows ver. 3.4.0.0: "Sua autenticação com o Microsoft Entra expirou. Você precisa se autenticar novamente no Entra para adquirir um novo token. O tempo limite de autenticação pode ser ajustado pelo administrador."
  • No cliente VPN do Azure para macOS ver. 2.7.101: "Sua autenticação no Microsoft Entra expirou; você precisa se autenticar novamente para adquirir um novo token. Tente se conectar novamente. As políticas e o tempo limite de autenticação são configurados pelo seu administrador no locatário do Entra."

A conexão ponto a site se desconecta porque o token de atualização atual no cliente VPN do Azure, adquirido do Entra ID, expirou ou se tornou inválido. Esse token é renovado aproximadamente a cada hora. Os administradores de locatários do Entra podem estender a frequência de entrada adicionando políticas de acesso condicional. Trabalhe com os administradores de locatários do Entra para estender o intervalo de expiração do token de atualização.

Para obter mais informações, confira: Erro do cliente VPN: sua autenticação com o Microsoft Entra expirou.

Como fazer para remover a configuração de uma conexão P2S?

Você pode remover uma configuração P2S usando os seguintes comandos do Azure PowerShell ou da CLI do Azure:

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

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

Conexões ponto a site com autenticação de certificado

O que devo fazer se receber uma incompatibilidade de certificado para uma conexão de autenticação de certificado ponto a site?

Desmarque a caixa de seleção Verificar a identidade do servidor validando o certificado. Ou adicione o FQDN (nome de domínio totalmente qualificado) do servidor junto com o certificado quando você estiver criando um perfil manualmente. Você pode fazer isso executando rasphone em um prompt de comando e escolhendo o perfil na lista suspensa.

Em geral, não recomendamos ignorar a validação da identidade do servidor. Mas com a autenticação de certificado do Azure, o mesmo certificado é usado para validação de servidor no protocolo de túnel VPN (IKEv2 ou SSTP) e no EAP (Protocolo de Autenticação Extensível). Como o protocolo de túnel VPN já está validando o certificado do servidor e o FQDN, é redundante validá-los novamente no EAP.

Captura de tela que mostra as propriedades da autenticação ponto a site.

Posso usar minha AC raiz de PKI interna para gerar certificados para conectividade ponto a site?

Sim. Anteriormente, somente os certificados raiz autoassinados podiam ser usados. Você ainda pode carregar 20 certificados raiz.

Posso usar certificados do Azure Key Vault?

Não.

Quais ferramentas posso usar para criar certificados?

Você pode usar sua solução de PKI (infraestrutura de chave pública) corporativa (sua PKI interna), Azure PowerShell, MakeCert e OpenSSL.

Há instruções para configurações e parâmetros de certificado?

Para os formatos de arquivo .cer e .pfx, confira:

Para o formato de arquivo .pem, confira:

Conexões ponto a site com autenticação RADIUS

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

Há suporte para autenticação RADIUS para todos os SKUs, exceto pelo SKU Básico.

Se você estiver usando SKUs mais antigos, a autenticação RADIUS será suportada nos SKUs Standard e de Alto Desempenho.

Há suporte para autenticação RADIUS para o modelo de implantação clássico?

Não.

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

As solicitações RADIUS são definidas para tempo limite após 30 segundos. Atualmente, não há suporte para valores de tempo limite definidos pelo usuário.

Há suporte para os servidores RADIUS de terceiros?

Sim.

Quais são os requisitos de conectividade para garantir que o gateway do Azure seja capaz de acessar um servidor RADIUS local?

Você precisa de uma conexão VPN site a site com o site local, com as rotas apropriadas configuradas.

O tráfego para um servidor RADIUS local (do gateway de VPN) pode ser roteado por uma conexão de ExpressRoute?

Não. Ele só pode ser roteado através de uma conexão site a site.

Há uma alteração no número compatível de conexões SSTP na autenticação RADIUS? Qual é o número máximo compatível de conexões SSTP e IKEv2?

Não há alteração no número máximo compatível de conexões SSTP em um gateway com autenticação RADIUS. Ele permanece sendo 128 para SSTP, mas depende do SKU do gateway para IKEv2. Para obter mais informações sobre o número de conexões permitido, confira SKUs de gateway.

Qual é a diferença entre a autenticação de certificado por meio de um servidor RADIUS e a autenticação de certificado nativo do Azure por meio do upload de um certificado confiável?

Na autenticação de certificado RADIUS, a solicitação de autenticação é encaminhada a um servidor RADIUS que manipula a validação de certificado. Essa opção será útil se você quiser integrar-se a uma infraestrutura de autenticação de certificado já existente por meio do RADIUS.

Quando você usa o Azure para autenticação de certificado, o gateway de VPN executa a validação do certificado. Você precisa carregar a chave pública do certificado no gateway. Você também pode especificar a lista de certificados revogados que não podem se conectar.

A autenticação RADIUS dá suporte à integração do Servidor de Política de Rede para autenticação multifator?

Se a autenticação multifator for baseada em texto (por exemplo, SMS, código de verificação de aplicativo móvel) e exigir que o usuário insira um código ou texto na interface do usuário do cliente VPN, a autenticação não terá êxito e não será um cenário com suporte. Confira Integrar a autenticação RADIUS do gateway de VPN do Azure com o servidor NPS para autenticação multifator.

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

Sim, há suporte para a autenticação RADIUS tanto para IKEv2 quanto para SSTP VPN.

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

Há suporte para autenticação RADIUS para o protocolo OpenVPN.

Conexões VNet a VNet e de vários sites

As informações da VNet para VNet nesta seção se aplicam a conexões de gateway de VPN. Para obter informações sobre o emparelhamento de rede virtual, consulte emparelhamento de rede Virtual.

O Azure cobra pelo tráfego entre VNets?

O tráfego de VNet para VNet na mesma região é gratuito para ambas as direções ao usar uma conexão de gateway de VPN. O tráfego de saída de rede virtual com rede virtual entre regiões é cobrado de acordo com as taxas de transferência de dados entre redes virtuais de saída com base nas regiões de origem. Para obter mais informações, confira Preços do Gateway de VPN do Azure. Se você estiver conectando VNets usando o Emparelhamento de VNet, em vez de Gateway de VPN, confira a página de preços de Rede Virtual do Azure.

O tráfego de Rede Virtual para Rede Virtual viaja pela Internet?

Não. O tráfego de rede virtual com rede virtual viaja pelo backbone do Microsoft Azure, não pela Internet.

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

Sim. As conexões de VNet a VNet que usam gateways de VPN funcionam entre locatários do Microsoft Entra.

O tráfego de VNet para VNet é seguro?

A criptografia IPsec e IKE ajuda a proteger o tráfego de VNet para VNet.

É necessário um dispositivo VPN para conectar redes virtuais?

Não. A conexão de várias redes virtuais do Azure entre si não exige um dispositivo VPN, a menos que a conectividade entre locais seja necessária.

Minhas redes virtuais precisam estar na mesma região?

Não. As redes virtuais podem estar na mesma região ou em regiões diferentes do Azure (locais).

Se as VNets não estiverem na mesma assinatura, as assinaturas precisarão ser associadas ao mesmo locatário do Microsoft Entra?

Não.

Posso usar VNet para VNet a fim de conectar a redes virtuais em instâncias separadas do Azure?

Não. VNet para VNet dá suporte à conexão de redes virtuais na mesma instância do Azure. Por exemplo, você não pode criar uma conexão entre a instância do Azure global e as instâncias chinesa, alemã ou do governo dos EUA. Considere o uso de uma conexão VPN site a site para esses cenários.

Posso usar Rede Virtual para Rede Virtual com conexões multissite?

Sim. Você pode usar a conectividade de rede virtual simultaneamente com VPNs de vários sites.

A quantos sites locais e redes virtuais uma rede virtual pode se conectar?

Confira a tabela requisitos de gateway.

Posso usar VNet para VNet para me conectar a máquinas virtuais ou serviços de nuvem fora de uma rede virtual?

Não. A rede virtual com rede virtual dá suporte à conexão de redes virtuais. Ele não dá suporte à 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ão. Um serviço de nuvem ou um ponto de extremidade de balanceamento de carga não pode abranger redes virtuais, mesmo que elas estejam conectadas entre si.

Posso usar um tipo de VPN baseada em política para conexões de VNet a VNet ou multissite?

Não. As conexões de VNet a VNet e multissite exigem gateways de VPN com tipos de VPN baseados em rota (anteriormente chamado de roteamento dinâmico).

Posso conectar uma VNet com um tipo de VPN baseado em rota a outra VNet com um tipo de VPN baseado em política?

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

Os túneis de VPN compartilham largura de banda?

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

Há suporte para túneis redundantes?

Os túneis redundantes entre um par de redes virtuais terão suporte quando um gateway de rede virtual estiver configurado como ativo.

Posso ter espaços de endereço sobrepostos para configurações de Rede Virtual para Rede Virtual?

Não. Você não pode ter intervalos de endereços IP sobrepostos.

Pode haver sobreposição de espaços de endereço entre as redes virtuais conectadas e sites local locais?

Não. Você não pode ter intervalos de endereços IP sobrepostos.

Como fazer para habilitar o roteamento entre minha conexão VPN site a site e o ExpressRoute?

Se você quiser habilitar o roteamento entre o branch conectado ao ExpressRoute e o branch conectado a um VPN site a site, precisará configurar o Servidor de Rota do Azure.

Posso usar o gateway de VPN do Azure para o tráfego entre meus sites locais ou para outra rede virtual?

  • Modelo de implantação do Gerenciador de Recursos

    Sim. Confira a seção BGP e roteamento para obter mais informações.

  • Modelo de implantação clássica

    O trânsito de tráfego por meio de um gateway de VPN é possível quando você usa o modelo de implantação clássico, mas ele depende de espaços de endereço definidos estaticamente no arquivo de configuração de rede. Atualmente, o BGP (Border Gateway Protocol) não é compatível com redes virtuais do Azure e gateways de VPN por meio do modelo de implantação clássico. Sem o BGP, a definição manual de espaços de endereço de trânsito é propensa a erros e não é recomendada.

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

Não. Por padrão, o Azure gera chaves pré-compartilhadas diferentes para conexões VPN diferentes. No entanto, você poderá usar a API REST Definir Chave de Gateway de VPN ou o cmdlet do PowerShell para definir o valor de chave que preferir. A chave precisa 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 de VPN, incluindo VPNs site a ponto, compartilham o mesmo gateway de VPN e a largura de banda disponível.

Posso configurar vários túneis entre minha rede virtual e meu site local usando uma VPN multissite?

Sim, mas você deve configurar o BGP em ambos os túneis para o mesmo local.

O Gateway de VPN do Azure respeita a precedência de caminho AS para influenciar as decisões de roteamento entre várias conexões com meus sites locais?

Sim, o Gateway de VPN do Azure honra a prefixação do caminho de AS (sistema autônomo) 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 conexão VPN VirtualNetworkGateway?

Não. Esse tipo de configuração é reservado para conexões de gateway do ExpressRoute. Caso deseje influenciar as decisões de roteamento entre várias conexões, use a precedência de caminho AS.

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

Sim. Você pode usar VPNs ponto a site com os gateways de VPN que se conectam a vários sites locais e outras redes virtuais.

Posso conectar uma rede virtual com VPNs IPsec a meu circuito ExpressRoute?

Sim, há suporte para isso. Para obter mais informações, confira Configurar conexões ExpressRoute e site a site coexistentes.

Política IPsec/IKE

A política de IPsec/IKE personalizada é compatível com todos os SKUs de Gateway de VPN do Azure?

A política de IPsec/IKE personalizada é compatível com todos os SKUs do Gateway de VPN do Azure, exceto pelo SKU Básico.

Quantas políticas eu posso especificar em uma conexão?

Você só pode especificar uma combinação de políticas para uma determinada conexão.

Posso especificar uma política parcial em uma conexão (por exemplo, apenas algoritmos IKE, mas não IPsec)?

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

A quais algoritmos e pontos fortes a política personalizada dá suporte?

A tabela a seguir lista as forças da chave e os algoritmos de criptografia configuráveis compatíveis. Você deve selecionar uma opção para cada campo.

IPsec/IKEv2 Opções
Criptografia IKEv2 GCMAES256, GCMAES128, AES256, AES192, AES128
Integridade IKEv2 SHA384, SHA256, SHA1, MD5
Grupo DH DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Nenhum
Criptografia IPsec GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, nenhum
Integridade IPsec GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Grupo PFS PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, nenhum
Tempo de vida de SA do Modo Rápido (Opcional; valores padrão, se não for especificado)
Segundos (inteiro; mínimo 300, padrão 27.000)
Quilobytes (inteiro; mínimo 1.024, padrão 10.2400.000)
Seletor de tráfego UsePolicyBasedTrafficSelectors($True ou $False, mas opcional; $False padrão, se não for especificado)
Tempo limite de DPD Segundos (inteiro; mínimo 9, máximo 3.600, padrão 45)

  • A configuração do dispositivo VPN local precisa corresponder ou conter os seguintes algoritmos e parâmetros que você especifica na política de IPsec ou IKE do Azure:

    • Algoritmo de criptografia IKE (Modo Principal, Fase 1)
    • Algoritmo de integridade IKE (Modo Principal, Fase 1)
    • Grupo DH (Modo Principal, Fase 1)
    • Algoritmo de criptografia 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 você usar UsePolicyBasedTrafficSelectors)
    • Tempos de vida de SA (especificações locais que não precisam ser correspondentes)

  • Se você usar GCMAES para o algoritmo de criptografia IPsec, precisará selecionar o mesmo algoritmo GCMAES e comprimento de chave para integridade IPsec. Por exemplo, use GCMAES128 para ambos.

  • Na tabela de algoritmos e chaves:

    • O IKE corresponde ao Modo Principal ou à Fase 1.
    • O IPsec corresponde ao Modo Rápido ou à Fase 2.
    • O grupo DH especifica o grupo Diffie-Hellman usando no Modo Principal ou na Fase 1.
    • O grupo PFS especifica o grupo Diffie-Hellman usado no Modo Rápido ou na Fase 2.

  • O tempo de vida da SA de modo principal IKE é fixo 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 para se conectar a um firewall VPN baseado em políticas locais.

    Se você habilitar UsePolicyBasedTrafficSelectors, verifique se o seu dispositivo VPN tem os seletores de tráfego correspondentes com todas as combinações dos prefixos de rede local (gateway de rede local) de ou para os prefixos de rede virtual do Azure, em vez de any-to-any. O gateway de VPN aceita qualquer seletor de tráfego proposto pelo gateway de VPN remoto, independentemente do que está configurado no gateway de VPN.

    Por exemplo, se os prefixos da rede local são 10.1.0.0/16 e 10.2.0.0/16, e os prefixos da rede virtual são 192.168.0.0/16 e 172.16.0.0/16, você precisa especificar os seguintes seletores de tráfego:

    • 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ítica, confira Conectar um gateway de VPN a vários dispositivos VPN baseados em políticas locais.

  • Definir o tempo limite como períodos mais curtos faz com que o IKE faça o rechaveamento de forma mais agressiva. Em seguida, a conexão pode parecer estar desconectada em algumas instâncias. Essa situação pode não ser desejável se os locais estiverem distantes da região do Azure onde o gateway de VPN reside ou se a condição de link físico puder causar perda de pacotes. Geralmente, recomendamos que você defina o tempo limite entre 30 e 45 segundos.

Para saber mais, confira Conectar um gateway de VPN a vários dispositivos VPN locais baseados em políticas.

A quais grupos Diffie-Hellman a política personalizada dá suporte?

A seguinte tabela lista os Grupos Diffie-Hellman correspondentes compatíveis com a 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

Para saber mais, confira RFC3526 e RFC5114.

A política personalizada substitui os conjuntos de políticas de IPsec/IKE padrão para gateways de VPN?

Sim. Depois que você especificar uma política personalizada em uma conexão, o Gateway de VPN do Azure usa apenas essa política na conexão, tanto como iniciador IKE quanto respondente IKE.

Se eu remover uma política de IPsec/IKE personalizada, a conexão ficará desprotegida?

Não, o IPsec/IKE ainda ajuda a proteger a conexão. Após você remover a política personalizada de uma conexão, o gateway de VPN reverterá para a lista padrão de propostas de IPsec/IKE e reiniciará o handshake do IKE com o dispositivo VPN local.

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

Sim. Isso pode causar uma interrupção pequena (alguns segundos) uma vez que o gateway de VPN subdivide a conexão existente e reiniciará o handshake do IKE para restabelecer o túnel IPsec com os algoritmos de criptografia e os parâmetros novos. Verifique se o dispositivo VPN local também está configurado com os algoritmos correspondentes e as restrições de chave para minimizar a interrupção.

Eu posso usar políticas diferentes em conexões diferentes?

Sim. Uma política personalizada é aplicada em uma base por conexão. Você pode criar e aplicar políticas de IPsec/IKE diferentes em conexões diferentes.

Também é possível aplicar políticas personalizadas em um subconjunto de conexões. As restantes usam os conjuntos de políticas de IPsec/IKE padrão do Azure.

Eu posso usar uma política personalizada em conexões de VNet para VNet?

Sim. Você pode aplicar uma política personalizada em conexões entre locais de IPsec e em conexões de VNet para VNet.

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

Sim. Um túnel de VNet para VNet consiste em dois recursos de conexão no Azure, uma para cada sentido. Verifique se ambos os recursos de conexão têm a mesma política. Caso contrário, a conexão de VNet para VNet não será estabelecida.

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

O tempo limite de DPD padrão é de 45 segundos em gateways de VPN. Você pode especificar um valor de tempo limite de DPD diferente em cada conexão IPsec ou VNet a VNet entre 9 segundos e 3.600 segundos.

Observação

Definir o tempo limite como períodos mais curtos faz com que o IKE faça o rechaveamento de forma mais agressiva. Em seguida, a conexão pode parecer estar desconectada em algumas instâncias. Essa situação pode não ser desejável se os locais estiverem distantes da região do Azure onde o gateway de VPN reside ou se a condição de link físico puder causar perda de pacotes. Geralmente, recomendamos que você defina o tempo limite entre 30 e 45 segundos.

A política de IPsec/IKE personalizada funciona em conexões ExpressRoute?

Não. Uma política IPsec/IKE só funciona em conexões VNet para VNet e VPN S2S por meio de gateways de VPN.

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

Conexões IKEv1 podem ser criadas em todos os SKUs do tipo VPN RouteBased, exceto pelo SKU Básico, SKU Standard e outros SKUs mais antigos.

Você pode especificar o tipo de protocolo de conexão 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, confira a documentação do cmdlet do Azure PowerShell.

Para obter informações sobre tipos de SKU e suporte para IKEv1 e IKEv2, confira Conectar um gateway de VPN a vários dispositivos VPN baseados em política local.

O tráfego entre conexões IKEv1 e IKEv2 é permitido?

Sim.

Posso ter conexões site a site do IKEv1 no SKU Básico para o tipo de VPN baseado em rota?

Não. O SKU Básico não dá suporte a essa configuração.

Posso alterar o tipo de protocolo de conexão após a conexão ser criada (IKEv1 para IKEv2 e vice-versa)?

Não. Depois de criar a conexão, você não poderá alterar os protocolos IKEv1 e IKEv2. Você precisa excluir e recriar uma conexão com o tipo de protocolo desejado.

Por que minha conexão IKEv1 está reconectando com frequência?

Se o roteamento estático ou a conexão IKEv1 baseada em rota estiver desconectando em intervalos de rotina, é provável que os gateways de VPN não deem suporte a rechaveamentos no local. Quando o modo principal estiver sendo rechaveado, os túneis IKEv1 serão desconectados e levarão até cinco segundos para reconectar. O valor de tempo limite de negociação do modo principal determinará a frequência de rechaveamentos. Para evitar essas reconexões, você pode alternar para o uso de IKEv2, que dá suporte a rechaveamentos no local.

Se sua conexão estiver se reconectando aleatoriamente, siga o guia de solução de problemas.

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

Veja os artigos a seguir:

BGP e roteamento

O BGP tem suporte em todas as SKUs de Gateway de VPN do Azure?

O BGP tem suporte em todos os SKUs de Gateway de VPN do Azure, exceto o SKU Básico.

Posso usar o BGP com gateways de VPN do Azure Policy?

Não, o BGP é compatível somente com gateways de VPN baseados em rota.

Quais ASNs posso usar?

Você pode usar seus ASNs (Números do Sistema Autônomo) públicos ou ASNs privados para redes locais e redes virtuais do Azure.

Você não pode usar os seguintes ASNs reservados:

  • Reservados pelo Azure:

    • ASNs públicos: 8074, 8075, 12076
    • ASNs privados: 65515, 65517, 65518, 65519, 65520

  • Reservados pela IANA:

    • 23456, 64496-64511, 65535-65551, 429496729

Não é possível especificar esses ASNs para seus dispositivos VPN locais ao se conectar a gateways de VPN.

Posso usar ASNs de 32 bits (4 bytes)?

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

Quais ASNs privados posso usar?

Os intervalos utilizáveis de ASNs privados são:

  • 64512-65514 e 65521-65534

Nem o IANA nem o Azure reservam essas ASNs, portanto, você pode atribuí-las ao gateway de VPN.

Que endereço o Gateway de VPN do Azure usa para o IP de par de BGP?

Por padrão, o Gateway de VPN do Azure alocará um endereço IP do intervalo GatewaySubnet para gateways de VPN em espera ativos ou dois endereços IP para gateways de VPN ativos/ativos. Esses endereços são alocados automaticamente quando você cria o gateway de VPN.

Você pode encontrar o endereço IP BGP alocado usando o Azure PowerShell ou o portal do Azure. No PowerShell, use Get-AzVirtualNetworkGateway e procure a propriedade bgpPeeringAddress. No portal do Azure, na página Configuração de Gateway, procure na propriedade da opção Configurar BGP ASN.

Se seus roteadores VPN locais usarem endereços IP APIPA (Endereço IP Privado Automático) (169.254.x.x) como endereços IP BGP, você precisará especificar um ou mais endereços IP BGP do Azure APIPA em seu gateway de VPN. O Gateway de VPN do Azure selecionará o endereço APIPA a ser usado com o par no nível de protocolo BGP APIPA local especificado no gateway de rede local ou o endereço IP privado para o par no nível de protocolo BGP local não pertencente ao APIPA. Para obter mais informações, consulte Configurar BGP para o Gateway de VPN do Azure.

Quais são os requisitos para obter endereços IP do par no nível de protocolo BGP em meu dispositivo VPN?

O seu endereço de par no nível de protocolo BGP local não pode ser o mesmo que o endereço IP público do dispositivo VPN nem do espaço de endereço da VNet do gateway de VPN. Use um endereço IP diferente no dispositivo VPN para o IP de par no nível de protocolo BGP. Ele poderá ser um endereço atribuído à interface de loopback no dispositivo (um endereço IP regular ou um endereço APIPA).

Caso o dispositivo use um endereço APIPA para o BGP, você deverá especificar o endereço IP BGP APIPA em seu gateway de VPN, conforme descrito em Configurar o BGP para o Gateway de VPN do Azure. Especifique esse endereço no gateway de rede local e correspondente que representa o local.

O que devo especificar como prefixos de endereço para o gateway de rede local ao usar o BGP?

Importante

Essa é uma alteração do requisito documentado anteriormente.

O Gateway de VPN do Azure adicionará de modo interno uma rota de host ao IP do par no nível de protocolo BGP local pelo túnel IPsec. Não adicione a rota /32 no campo Espaço de endereço, pois ela é redundante. Se você usar um endereço APIPA como o IP BGP do dispositivo VPN local, não poderá adicioná-lo a esse campo.

Caso você adicione outros prefixos ao campo Espaço de endereços IP, eles serão adicionados como rotas estáticas ao gateway de VPN do Azure, além das rotas obtidas por meio do BGP.

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

Não. Você precisará atribuir ASNs diferentes entre redes locais e redes virtuais do Azure caso os esteja conectando juntamente com o BGP.

Os gateways de VPN do Azure têm um ASN padrão de 65515 atribuído, mesmo que o BGP esteja habilitado ou não para uma conectividade entre locais. É possível substituir esse padrão atribuindo um ASN diferente ao criar um gateway de VPN ou você pode alterar o ASN depois de criar o gateway. Será necessário atribuir ASNs locais aos gateways de rede locais e correspondentes do Azure.

Quais prefixos de endereço os gateways de VPN do Azure anunciarão para mim?

Os gateways anunciarão as seguintes rotas para seus dispositivos BGP locais:

  • Seus prefixos de endereços de VNet
  • Prefixos de endereço para cada gateway de rede local conectado ao gateway de VPN
  • As rotas obtidas de outras sessões de emparelhamento via protocolo BGP conectadas ao gateway de VPN, exceto a rota padrão ou rotas sobrepostas com um prefixo de rede virtual

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

O Gateway de VPN do Azure é compatível com até 4.000 prefixos. A sessão BGP é descartada se o número de prefixos exceder o limite.

Posso anunciar a rota padrão (0.0.0.0/0) para gateways de VPN?

Sim. Tenha em mente que anunciar a rota padrão força todo o tráfego de saída da VNet em direção ao seu site local. Além disso, impedirá que as VMs da rede virtual aceitem uma comunicação pública da Internet de modo direto, como protocolo RDP ou SSH da Internet para as VMs.

A capacidade de anunciar prefixos exatos depende se o trânsito de gateway está habilitado ou não.

  • Quando o trânsito de gateway está habilitado: não é possível anunciar os prefixos exatos como prefixos de rede virtual (incluindo redes virtuais emparelhadas). O Azure bloqueia ou filtra o anúncio de qualquer prefixo que corresponda aos prefixos de endereço de rede virtual. No entanto, você pode anunciar um prefixo que seja um superconjunto do espaço de endereço da sua rede virtual. Por exemplo, se a sua rede virtual usar o espaço de endereço 10.0.0.0/16, você poderá anunciar 10.0.0.0/8, mas não 10.0.0.0/16 nem 10.0.0.0/24.
  • Quando o trânsito de gateway não está habilitado: o gateway não memoriza os prefixos da rede virtual emparelhada, permitindo que você anuncie os prefixos exatos como a sua rede virtual emparelhada.

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

Sim. Você poderá usar o BGP para conexões entre locais e conexões entre redes virtuais.

Posso combinar o BGP a conexões não BGP para meu gateways de VPN do Azure?

Sim, você pode combinar conexões BGP e não BGP para o mesmo gateway de VPN do Azure.

O Gateway de VPN do Azure é compatível com o roteamento de trânsito do BGP?

Sim. O roteamento de trânsito do BGP é compatível. Porém, os gateways de VPN não anunciam rotas padrão para outros pares no nível de protocolo BGP. Para habilitar o roteamento de trânsito entre vários gateways de VPN, você precisará habilitar o BGP em todas as conexões intermediárias entre redes virtuais. Para obter mais informações, confira Sobre o BGP e o Gateway de VPN.

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

Sim, você poderá estabelecer mais de um túnel VPN site a site entre um gateway de VPN e sua rede local. Todos esses túneis serão contados em relação ao número total de túneis de seus gateways de VPN do Azure. Além disso, você deverá habilitar o BGP em dois túneis.

Por exemplo, caso você tenha dois túneis redundantes entre o gateway de VPN e uma de suas redes locais, eles consumirão dois túneis da cota total de seu gateway de VPN.

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

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

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

Sim.

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

Adicione uma rota de host do endereço IP do par no nível de protocolo BGP do Azure ao dispositivo VPN. Essa rota apontará para o túnel VPN S2S IPsec.

Por exemplo, caso o IP do par de VPN do Azure seja 10.12.255.30, você deverá adicionar uma rota de host ao 10.12.255.30 com uma interface do próximo salto da interface de túnel IPsec correspondente em seu dispositivo VPN.

O gateway de rede virtual é compatível com o BFD para conexões site a site com o BGP?

Não. O BFD (Detecção de Encaminhamento Bidirecional) é um protocolo que pode ser usado com o BGP para detectar tempos de inatividade próximos mais rapidamente do que usando intervalos padrão de manutenção de atividade do BGP. O BFD usa temporizadores de subsegundos projetados para funcionar em ambientes de LAN, mas não em uma Internet pública nem em conexões WAN.

Para conexões por meio de Internet pública, ter determinados pacotes atrasados ou mesmo ignorados não é incomum. Portanto, introduzir esses temporizadores agressivos poderá adicionar instabilidade. Essa instabilidade pode fazer com que o BGP amorteça as rotas.

Como alternativa, será possível configurar seu dispositivo local com temporizadores menores do que o intervalo de "manutenção de atividade" padrão de 60 segundos ou menores que o temporizador de retenção de 180 segundos. Essa configuração resulta em um tempo de convergência mais rápido. No entanto, os temporizadores abaixo do intervalo padrão de 60 segundos "keepalive" ou abaixo do temporizador de retenção padrão de 180 segundos não são confiáveis. Recomenda-se manter os temporizadores nos valores padrão ou acima deles.

Os gateways de VPN iniciam conexões ou sessões de emparelhamento via protocolo BGP?

Os gateways VPN iniciam sessões de emparelhamento via protocolo BGP com os endereços IP do par no nível de protocolo BGP local especificados nos recursos de gateway de rede local usando os endereços IP privados nos gateways de VPN. Esse processo ocorre independentemente de os endereços IP do BGP local estarem no intervalo APIPA ou serem endereços IP privados regulares. Se os dispositivos VPN locais usarem endereços APIPA como IP do BGP, você precisará configurar seu alto-falante BGP para iniciar as conexões.

Posso configurar o túnel forçado?

Sim. Consulte Configurar o túnel forçado.

NAT

O NAT tem suporte em todos os SKUs de Gateway de VPN do Azure?

NAT é suportado em VpnGw2 a VpnGw25 e em VpnGw2AZ a VpnGw5AZ.

Posso usar o NAT em conexões VNet a VNet ou P2S?

Não.

Quantas regras de NAT posso usar em um gateway de VPN?

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

Posso usar uma barra (/) em um nome de regra NAT?

Não. Você receberá uma mensagem de erro.

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

O NAT é aplicado às conexões que possuem regras NAT. Se uma conexão não tiver uma regra de NAT, o NAT não terá efeito nela. No mesmo gateway VPN, você pode ter algumas conexões com NAT e outras conexões sem NAT trabalhando juntas.

Que tipos de NAT os gateways VPN suportam?

Os gateways VPN suportam apenas NAT 1:1 estático e NAT dinâmico. Eles não suportam NAT64.

O NAT funciona em gateways de VPN do tipo ativo-ativo?

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

O NAT funciona com conexões BGP?

Sim, você pode usar o BGP com o NAT. Algumas considerações importantes:

  • Para garantir que as rotas aprendidas e as rotas anunciadas sejam traduzidas para prefixos de endereço pós-NAT (mapeamentos externos) com base nas regras NAT associadas às conexões, selecione Habilitar tradução de rota BGP na página de configuração para regras NAT. Os roteadores BGP locais devem anunciar os prefixos exatos conforme definido nas regras IngressSNAT.

  • Se o roteador VPN local usar um endereço regular não APIPA e colidir com o espaço de endereço VNet ou outros espaços de rede local, certifique-se de que a regra IngressSNAT traduzirá o IP do par BGP em um IP exclusivo e não endereço sobreposto. Coloque o endereço pós-NAT no campo BGP peer IP address do gateway da rede local.

  • Não há suporte para NAT com endereços APIPA BGP.

É necessário criar as regras de DNAT correspondentes à regra SNAT?

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

  • Uma regra IngressSNAT define a tradução dos endereços IP de origem que chegam ao gateway VPN a partir da rede local. Ele também cuida da conversão dos endereços IP de destino que saem da rede virtual para a mesma rede local.

  • Uma regra EgressSNAT define a tradução dos endereços IP de origem da VNet que saem do gateway VPN para redes locais. Ele também trata da tradução dos endereços IP de destino dos pacotes que chegam à rede virtual por meio das conexões que possuem a regra EgressSNAT.

Em ambos os casos, você não precisa de regras de conversão de endereço de rede de destino (DNAT).

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

Você precisa criar uma regra NAT para cada prefixo, porque cada regra NAT pode incluir apenas 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:

  • IngressSNAT regra 1: Mapeie 10.0.1.0/24 para 192.168.1.0/24.
  • IngressSNAT regra 2: Mapeie 10.0.2.0/25 para 192.168.2.0/25.

As duas regras devem corresponder aos comprimentos dos prefixos de endereço correspondentes. A mesma diretriz se aplica às regras EgressSNAT para o espaço de endereço VNet.

Importante

Se você vincular apenas uma regra à conexão anterior, o outro espaço de endereço não será traduzido.

Quais 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 em diferentes prefixos para redes locais?

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

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

Sim. Normalmente você usa a mesma regra IngressSNAT quando as conexões são para a mesma rede local, para fornecer redundância. Não será possível usar a mesma regra de entrada se as conexões forem para redes locais diferentes.

Preciso de regras de entrada e saída em uma conexão NAT?

Você precisa de 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 da VNet. Se o espaço de endereço VNet for único entre todas as redes ligadas, não precisa da regra EgressSNAT nessas ligações. Você pode usar as regras de entrada para evitar a sobreposição de endereços entre as redes locais.

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

O ID de configuração IP é simplesmente o nome do objeto de configuração IP que você deseja que a regra NAT use. Com esta configuração, você está simplesmente escolhendo qual endereço IP público do gateway se aplica à regra NAT. Se você não especificou 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.

Conectividade entre locais e VMs

Se minha máquina virtual estiver em uma rede virtual e eu tiver uma conexão entre locais, como devo me conectar à VM?

Se você tiver um protocolo RDP habilitado para a sua VM, você pode se conectar à sua máquina virtual usando o endereço IP privado. Nesse caso, você especifica o endereço IP privado e a porta à qual deseja se conectar (normalmente 3389). Você precisa configurar a porta em sua máquina virtual para o tráfego.

Você também pode se conectar à sua máquina virtual com o endereço IP privado de outra máquina virtual localizada na mesma rede virtual. Você não poderá 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 tiver uma rede virtual ponto a site configurada e não estabelecer uma conexão do seu computador, você não poderá se conectar à máquina virtual com o endereço IP privado.

Se a minha máquina virtual estiver em uma rede virtual com conectividade entre locais, todo o tráfego de minha VM passará por essa conexão?

Não. Somente o tráfego com um destino IP contido em intervalos de endereços IP de rede local de rede virtual especificado por você passa pelo gateway de rede virtual.

O tráfego que tiver um destino IP localizado na rede virtual permanecerá na rede virtual. O outro tráfego é enviado pelo balanceador de carga para as redes públicas. Ou se você usar túnel forçado, o tráfego será enviado por meio do gateway de VPN.

Como eu faço para solucionar problemas de uma conexão de RDP para uma VM

Se você estiver tendo problemas para se conectar a uma máquina virtual por meio de sua conexão VPN, verifique os seguintes itens:

  • Verifique se a conexão VPN é estabelecida.
  • Verifique se você está se conectando ao endereço IP privado da VM.
  • Se você puder se conectar à VM usando o endereço IP privado, mas não o nome do computador, verifique se o DNS foi configurado corretamente. Para obter mais informações sobre como a resolução de nomes funciona para VMs, confira Resolução de nomes para recursos em redes virtuais do Azure.

Quando você se conectar via 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 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 pool de endereços de cliente VPN, isso será chamado de espaço de endereço sobreposto. Quando o espaço de endereço se sobrepõe dessa forma, o tráfego de rede não alcança o Azure. Ele 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 você 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 como solucionar problemas de conexões RDP, confira Solucionar problemas de conexões da Área de Trabalho Remota a uma VM.

Manutenção de gateway controlada pelo cliente

Quais serviços estão incluídos na configuração de manutenção para o escopo dos Network Gateways?

O escopo Network Gateways inclui recursos de gateway em serviços de rede. Existem 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 de VPN
  • Gateway VPN (site a site) no serviço WAN Virtual do Azure
  • Gateway ExpressRoute no serviço WAN Virtual

Qual manutenção é suportada 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 sistema operacional convidado e a manutenção do serviço serão executadas durante essa janela. A manutenção controlada pelo cliente não cobre atualizações de host (além das atualizações de host para Power, por exemplo) e atualizações críticas de segurança.

Posso receber uma notificação avançada da manutenção?

Nesse momento, não é possível obter notificação avançada para a manutenção dos recursos do Network Gateway.

Posso configurar uma janela de manutenção com menos de cinco horas?

Nesse momento, você precisa configurar uma janela de no mínimo cinco horas no fuso horário de sua preferência.

Posso configurar uma janela de manutenção diferente da programação diária?

Neste momento, é necessário 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 oferece suporte a atualizações de sistema operacional e serviços convidados. Essas atualizações representam a 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.

Se um problema de segurança de alta gravidade puder colocar os clientes em perigo, o Azure poderá precisar substituir o controle do cliente da janela de manutenção e forçar uma alteração. Essas alterações são ocorrências raras que usamos apenas 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 posso configurar para usar a manutenção controlada pelo cliente?

Todos os SKUs do Gateway de VPN do Azure (exceto o SKU Básico) podem ser configurados para usar a manutenção controlada pelo cliente.

Quanto tempo leva para que uma 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 os Gateways de Rede seguirem o cronograma de manutenção após a política de manutenção ter sido associada ao recurso do gateway.

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

Sim. A manutenção controlada pelo cliente não funciona para recursos que utilizam endereços IP públicos SKU Básico, exceto no caso de atualizações de serviço. Para esses gateways, a manutenção do sistema operacional convidado não segue o cronograma de manutenção controlado pelo cliente devido a limitações de infraestrutura.

Como devo planejar janelas de manutenção ao usar a VPN e o ExpressRoute em um cenário de coexistência?

Quando trabalhar com VPN e ExpressRoute num cenário de coexistência ou sempre que tiver recursos que funcionam como backups, recomendamos a criaçã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 desde recurso estão pausadas até então?

Não, as atividades de manutenção não são pausadas no seu recurso durante o período anterior à janela de manutenção agendada. Nos dias não incluídos no seu agendamento de manutenção, a manutenção continuará a ser feita no recurso como de hábito.

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

Para obter mais informações, consulte o artigo Configurar a manutenção de gateway controlada pelo cliente do Gateway de VPN.

Conteúdo relacionado

"OpenVPN" é uma marca comercial da OpenVPN Inc.