Partilhar via

FAQ do Gateway de VPN

  • Artigo

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

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 se conectar a outra rede virtual na mesma região do Azure ou em uma região 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ê especificar um servidor ou servidores DNS (Sistema de Nomes de Domínio) ao criar sua rede virtual, o gateway de rede virtual privada (VPN) usará esses servidores DNS. Verifique se os servidores DNS especificados podem 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. Consulte a seção Perguntas frequentes sobre conectividade multissite e VNet-to-VNet.

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

N.º No entanto, os custos de quaisquer IPs públicos adicionais sã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?

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

  • Site-to-site: Ligação VPN através de IPsec (IKEv1 e IKEv2). Esse tipo de conexão requer um dispositivo VPN ou o Roteamento e Acesso Remoto do Windows Server. Para obter mais informações, consulte Criar uma conexão VPN site a site no portal do Azure.
  • Ponto a site: Ligação VPN através do protocolo SSTP (Secure Socket Tunneling Protocol) ou IKEv2. Esta ligação não requer um dispositivo VPN. Para obter mais informações, consulte Definir configurações do servidor para autenticação de certificado de Gateway VPN ponto a site.
  • VNet-to-VNet: esse tipo de conexão é o mesmo que uma configuração site a site. VNet-to-VNet é uma conexão VPN sobre IPsec (IKEv1 e IKEv2). Não requer um dispositivo VPN. Para obter mais informações, consulte Configurar uma conexão de gateway VPN VNet-to-VNet.
  • Azure ExpressRoute: ExpressRoute é uma ligação privada ao Azure a partir da sua rede alargada (WAN), não uma ligação VPN através da Internet pública. Para obter mais informações, consulte a visão geral técnica da Rota Expressa e as Perguntas frequentes sobre a Rota Expressa.

Para obter mais informações sobre conexões de gateway VPN, consulte 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) estão entre seu local local e o Azure. Você pode se conectar de qualquer um dos computadores localizados em suas instalações a qualquer máquina virtual (VM) ou instância de função em sua rede virtual, dependendo de como você optar por configurar o roteamento e as permissões. É uma ótima opção para uma conexão entre locais sempre disponível e é adequado para configurações híbridas.

    Esse tipo de conexão depende de um dispositivo VPN IPsec (dispositivo de hardware ou dispositivo de software). O dispositivo deve 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 sobre SSTP) permitem que você se conecte de um único computador de qualquer lugar a 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 localmente. 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 baseados em rota são chamados de gateways dinâmicos no modelo de implantação clássico.

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

Para um funcionamento normal, o gateway VPN deve estabelecer uma conexão segura com o plano 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 redes virtuais do Azure usam o serviço DNS interno do Azure (168.63.129.16) para resolver essas URLs públicas. Esse comportamento padrão ajuda a garantir uma comunicação perfeita entre o gateway de VPN e o plano de controle do Azure.

Ao implementar um DNS personalizado em uma rede virtual, é 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 VPN e o plano de controle. A falha na configuração de um encaminhador DNS para o DNS do Azure pode impedir que a Microsoft execute operações e manutenção no gateway de VPN, o que representa um risco de 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 rede virtual:

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

Dois clientes VPN conectados ponto a site ao mesmo gateway VPN podem se comunicar?

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

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

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

A Microsoft está ciente de relatórios sobre uma técnica de rede que ignora o encapsulamento VPN. Trata-se de uma questão que abrange toda a indústria. Ele afeta qualquer sistema operacional que implementa um cliente DHCP (Dynamic Host Configuration Protocol) de acordo com sua especificação RFC e tem suporte para rotas da opção DHCP 121, incluindo o Windows.

Como a pesquisa observa, as mitigações incluem a execução da VPN dentro de uma VM que obtém uma concessão de um servidor DHCP virtualizado para impedir que o servidor DHCP da rede local instale rotas completamente. Pode encontrar mais informações sobre esta vulnerabilidade na Base de Dados Nacional de Vulnerabilidades do NIST.

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 VPN, você usa o -GatewayType valor Vpn. 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 sã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 Azure PowerShell ou a CLI do Azure para criar os gateways baseados em políticas.

Anteriormente, as camadas de produto de gateway (SKUs) mais antigas 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, você deve excluir e recriar o gateway seguindo as etapas a seguir. Este processo demora cerca de 60 minutos. Ao criar o novo gateway, não é possível manter 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 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, você pode definir seletores de tráfego usando o trafficSelectorPolicies atributo em uma conexão por meio do comando New-AzIpsecTrafficSelectorPolicy do Azure PowerShell. Para que o seletor de tráfego especificado entre em vigor, certifique-se de habilitar seletores de tráfego baseados em políticas.

Os seletores de tráfego configurados de forma personalizada são propostos somente quando um gateway VPN inicia 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, InitiatorOnlye ResponderOnly).

Preciso de uma sub-rede de gateway?

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.

Todas as sub-redes de gateway devem ser nomeadas GatewaySubnet para funcionar corretamente. 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. 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 você possa criar uma sub-rede de gateway tão pequena quanto /29, recomendamos que você crie uma sub-rede de gateway de /27 ou maior (/27, /26, /25 e assim por diante). Verifique se a sub-rede do 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.º

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. 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. Este requisito aplica-se a todas as SKUs de gateway, exceto a SKU Básica. Atualmente, o Basic SKU suporta apenas endereços IP públicos Basic SKU. Estamos trabalhando para adicionar suporte para endereços IP públicos de SKU padrão para o SKU 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 ser 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 não muda quando você redimensiona, redefine ou conclui outras manutenções internas e atualizações do seu gateway VPN.

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

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

No entanto, os endereços IP públicos básicos de SKU estão sendo eliminados. No futuro, ao criar um gateway VPN, você deve usar o endereço IP público SKU padrão. Você pode encontrar detalhes sobre a desativação de endereços IP públicos de SKU Básico no anúncio de Atualizações do Azure.

Como meu túnel VPN é autenticado?

O Gateway de VPN do Azure usa a autenticação de chave pré-compartilhada (PSK). Geramos uma PSK quando criamos o túnel VPN. Você pode alterar a PSK gerada automaticamente para a sua própria usando a API REST set Pre-Shared Key ou o cmdlet 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 Definir Chave Pré-Compartilhada e o cmdlet do PowerShell para configurar VPNs baseadas em política (estática) do Azure e VPNs de roteamento (dinâmicas) baseadas em rota.

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

Você está limitado a usar chaves pré-compartilhadas para autenticação.

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

Para o modelo de implementação Azure Resource Manager:

  • Azure PowerShell: Use AddressPrefix para especificar o tráfego para o gateway de rede local.
  • Portal do Azure: vá para o espaço de endereço de configuração>do gateway>de rede local.

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

  • Portal do Azure: vá para a rede virtual clássica e, em seguida, vá para conexões>VPN Conexões>VPN site a site local Nome do site local>Espaço> de endereço do cliente.

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

Sim, a conversão de endereços de rede (NAT-T) é suportada. O Gateway de VPN do Azure não executa nenhuma funcionalidade semelhante a NAT nos pacotes internos de ou 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 próprios gateways ou servidores VPN no Azure a partir do Azure Marketplace ou criando 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. Os certificados do Azure ajudam a protegê-los bloqueando-os. Sem certificados adequados, entidades externas, incluindo os clientes desses gateways, não podem causar qualquer efeito 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 explorar as redes privadas do cliente por motivos de conformidade, portanto, elas precisam usar pontos de extremidade públicos para comunicação de infraestrutura. Uma auditoria de segurança do Azure verifica periodicamente os pontos de extremidade públicos.

Posso criar um gateway VPN usando o SKU 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 as etapas do Azure PowerShell .

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

Consulte os seguintes artigos:

Descontinuação de SKUs mais antigos

Os SKUs padrão e de alto desempenho serão preteridos em 30 de setembro de 2025. Você pode exibir o anúncio no site de Atualizações do Azure. 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 um novo gateway que use uma SKU padrão ou de 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, não é possível criar gateways que usem SKUs padrão ou de alto desempenho. Você pode criar gateways que usam SKUs VpnGw1 e VpnGw2 pelo mesmo preço que as SKUs Standard e High Performance, listadas respectivamente na página de preços.

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

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

Preciso migrar meus gateways do SKU Standard ou High Performance agora?

Não, não há nenhuma ação necessária no momento. Você pode migrar seus gateways 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 para VpnGw1
  • Alto desempenho para VpnGw2

E se eu quiser migrar para um AZ SKU?

Não é possível migrar sua SKU preterida para uma AZ SKU. No entanto, todos os gateways que ainda estão usando o Standard ou High Performance SKU após 30 de setembro de 2025 serão migrados e atualizados automaticamente para os AZ SKUs da seguinte maneira:

  • Padrão para VpnGw1AZ
  • Alto desempenho para 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. Para obter os preços do AZ SKU, consulte a página de preços. 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 um melhor desempenho com VpnGw1 e VpnGw2. Atualmente, o VpnGw1 a 650 Mbps oferece uma melhoria de desempenho de 6,5x ao mesmo preço do SKU padrão. O VpnGw2 a 1 Gbps proporciona uma melhoria de desempenho de 5x ao mesmo preço do SKU de Alto Desempenho. 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 até 30 de setembro de 2025?

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

  • Padrão para VpnGw1AZ
  • Alto desempenho para VpnGw2AZ

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

O SKU BÁSICO DO VPN Gateway também está sendo desativado?

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

Atualmente, o VPN Gateway Basic SKU suporta apenas o recurso de endereço IP público Basic SKU (que está em um caminho para a desativação). Estamos trabalhando para adicionar suporte para o recurso de endereço IP público SKU padrão ao SKU básico do VPN Gateway.

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. Você pode encontrar uma lista de dispositivos VPN compatíveis conhecidos, suas instruções de configuração ou exemplos correspondentes e especificações do dispositivo no artigo Sobre dispositivos VPN.

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

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

Dependendo do dispositivo VPN que você tem, você pode ser capaz de baixar um script de configuração de dispositivo VPN. Para mais informações, consulte Transferir os scripts de configuração do dispositivo VPN.

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

  • Para obter informações sobre dispositivos VPN compatíveis, consulte Sobre dispositivos VPN.

  • Antes de configurar seu dispositivo VPN, verifique se há problemas conhecidos de compatibilidade do dispositivo.

  • Para obter links para definições de configuração do dispositivo, consulte Dispositivos VPN validados. Fornecemos os links de configuração do dispositivo com base no melhor esforço, mas é sempre melhor verificar com o fabricante do dispositivo as informações de configuração mais recentes.

    A lista mostra as versões que testamos. Se a versão do SO do seu dispositivo VPN não estiver na lista, poderá ainda ser compatível. Consulte o fabricante do dispositivo.

  • Para obter informações básicas sobre a configuração do dispositivo VPN, consulte Visão geral das configurações do dispositivo VPN do parceiro.

  • 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 obter informações sobre os parâmetros necessários para concluir a configuração, consulte Parâmetros IPsec/IKE padrão. As informações incluem versão IKE, grupo Diffie-Hellman (DH), método de autenticação, algoritmos de criptografia e hash, tempo de vida da associação de segurança (SA), sigilo de encaminhamento perfeito (PFS) e Dead Peer Detection (DPD).

  • Para obter as etapas de configuração da política IPsec/IKE, consulte Configurar políticas de conexão IPsec/IKE personalizadas para VPN S2S e VNet-to-VNet.

  • Para conectar vários dispositivos VPN baseados em políticas, consulte Conectar um gateway VPN a vários dispositivos VPN locais baseados em políticas.

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

Consulte Editando exemplos de configuração de dispositivo.

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

Consulte Parâmetros de IPsec/IKE predefinidos.

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

Esse comportamento é esperado para gateways VPN baseados em política (também conhecidos como roteamento estático). Quando o tráfego sobre o túnel está inativo por mais de cinco 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 do Windows Server 2012 para configuração site a site entre locais.

Outras soluções de VPN de software devem funcionar com o gateway, desde que estejam em conformidade com as implementações IPsec padrão do setor. Para obter instruções de configuração e suporte, entre em contato com o fornecedor do software.

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 os endereços IP públicos do cliente ponto a site devem ser diferentes dos endereços IP públicos que o dispositivo VPN site a site usa, 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 dos mesmos endereços IP públicos em que uma conexão VPN site a site está configurada no mesmo gateway VPN.

Ligações ponto a site

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 conexões suportadas, consulte 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 posterior
  • Linux (strongSwan)
  • iOS

Posso atravessar proxies e firewalls usando o recurso ponto-a-site?

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

  • Secure Socket Tunneling Protocol (SSTP): Uma solução proprietária da Microsoft baseada em SSL que pode penetrar firewalls porque a maioria dos firewalls abre a porta TCP de saída que o 443 SSL usa.

  • OpenVPN: Uma solução baseada em SSL que pode penetrar firewalls porque a maioria dos firewalls abre a porta TCP de saída que o 443 SSL usa.

  • IKEv2 VPN: Uma solução VPN IPsec baseada em padrões que usa as portas UDP de saída 500 e 4500, juntamente com o número de protocolo IP 50. Os firewalls nem sempre abrem essas portas, então há uma possibilidade de que o IKEv2 VPN não possa atravessar proxies e firewalls.

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

A reconexão automática é uma função do cliente que você usa. O Windows suporta a reconexão automática através do recurso de cliente VPN Always On.

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

Atualmente, o DNS dinâmico (DDNS) não é suportado em 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ê deve ter um tipo de VPN baseado em rota para 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 que você usa, você poderá se conectar a vários gateways de rede virtual. Mas esse é o caso apenas se as redes virtuais às quais você está se conectando não tiverem 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 ofereça suporte a muitas conexões VPN, você pode ter apenas uma conexão a qualquer 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 VPN implantado em uma rede virtual emparelhada com outras redes virtuais podem ter acesso às outras redes virtuais 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) deve ser configurada com o atributo Usar gateways remotos . A VNet com o gateway VPN deve ser configurada com Permitir trânsito de gateway. Para obter mais informações, consulte Sobre 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 o débito exato dos túneis VPN. O IPsec e SSTP são protocolos VPN extremamente encriptados. A latência e a largura de banda entre suas instalações e a Internet também podem limitar a taxa de transferência.

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 ou IKEv2?

N.º Você pode usar apenas 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 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, vá para Configuração ponto a site do gateway>VPN. Em Tipo de autenticação, selecione o tipo de autenticação que deseja usar.

Depois de 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 de cliente VPN, baixe-o e aplique-o a cada cliente VPN.

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

Quando você faz alterações nas definições de configuração para o gateway VPN P2S, como adicionar um tipo de túnel ou alterar um tipo de autenticação, você precisa gerar um novo pacote de configuração para o perfil de cliente VPN. O novo pacote inclui as configurações atualizadas que os clientes VPN precisam para se conectar ao gateway P2S. Depois de gerar o pacote, use as configurações nos arquivos para atualizar os clientes VPN.

O Azure suporta a VPN IKEv2 no Windows?

O IKEv2 é suportado no Windows 10 e no 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 podem utilizar apenas SSTP ou o protocolo 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 IKEv2:

  1. 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

  2. Defina o valor da chave de registo. Crie ou defina a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload REG_DWORD chave no Registro 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 anteriores do Windows têm um limite de seletor de tráfego de 25.

O limite do 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-to-VNet e VNets emparelhadas conectadas ao gateway. Os clientes ponto a site baseados no Windows não conseguem se conectar via IKEv2 se ultrapassarem esse limite.

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

O limite do seletor de tráfego para OpenVPN é de 1.000 rotas.

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 tenta o túnel IKEv2 primeiro. O cliente retornará ao SSTP se a conexão IKEv2 não for bem-sucedida. O macOS liga-se apenas através do IKEv2.

Quando você tem o SSTP e o IKEv2 habilitados no gateway, o pool de endereços ponto a site é dividido estaticamente entre os dois, de modo que os clientes que usam protocolos diferentes são endereços IP de qualquer subintervalo. O número máximo de clientes SSTP é sempre 128, mesmo que o intervalo de endereços seja maior que /24. O resultado é um maior número de endereços disponíveis para clientes IKEv2. Para intervalos mais pequenos, a piscina é igualmente reduzida para metade. Os seletores de tráfego que o gateway usa 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.

Quais plataformas o Azure suporta para VPN P2S?

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

Já tenho um gateway VPN implantado. Posso ativar o RADIUS ou o IKEv2 VPN nele?

Sim. Se a SKU de gateway que você está usando oferecer suporte a RADIUS ou IKEv2, você poderá habilitar esses recursos em gateways que já implantou usando o Azure PowerShell ou o portal do Azure. O Basic SKU não suporta 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?

Poderá ver uma das seguintes mensagens:

  • No cliente VPN do Azure para Windows versão 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 versão 2.7.101: "Sua autenticação com o Microsoft Entra expirou, então você precisa se autenticar novamente para adquirir um novo token. Por favor, tente se conectar novamente. As políticas de autenticação e o tempo limite são configurados pelo 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 da ID do Entra, expirou ou se tornou inválido. Este 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, consulte: Erro do cliente VPN: sua autenticação com o Microsoft Entra expirou.

Como posso remover a configuração de uma ligaçã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 obtiver 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 nome de domínio totalmente qualificado (FQDN) do servidor junto com o certificado quando você estiver criando um perfil manualmente. Você pode fazer isso executando rasphone a partir de um prompt de comando e selecionando o perfil na lista suspensa.

Não recomendamos ignorar a validação da identidade do servidor em geral. Mas com a autenticação de certificado do Azure, o mesmo certificado é usado para validação de servidor no protocolo de encapsulamento VPN (IKEv2 ou SSTP) e no protocolo de autenticação extensível (EAP). Como o protocolo de encapsulamento 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 própria autoridade de certificação raiz PKI interna para gerar certificados para conectividade ponto a site?

Sim. Anteriormente, você podia usar apenas certificados 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?

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

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

Para formatos de arquivo .cer e .pfx, consulte:

Para obter o formato de arquivo .pem, consulte:

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

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 anteriores, a autenticação RADIUS é suportada em SKUs padrão e de alto desempenho.

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

N.º

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

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

Há suporte para servidores RADIUS de terceiros?

Sim.

Quais são os requisitos de conectividade para garantir que o gateway do Azure possa alcançar um servidor RADIUS local?

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

O tráfego para um servidor RADIUS local (do gateway VPN) pode ser roteado através de uma conexão de Rota Expressa?

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

Há uma alteração no número de conexões SSTP suportadas com autenticação RADIUS? Qual é o número máximo de conexõ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 conexões suportadas, consulte Sobre 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 carregamento de um certificado confiável?

Na autenticação de certificado RADIUS, a solicitação de autenticação é encaminhada para um servidor RADIUS que lida com a validação do certificado. Esta opção é útil caso queira integrar numa infraestrutura de autenticação de certificados que já tenha através de RADIUS.

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

A autenticação RADIUS suporta a integração do Servidor de Políticas de Rede para autenticação multifator?

Se a autenticação multifator for baseada em texto (por exemplo, SMS ou um 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 compatível. Consulte Integrar a autenticação RADIUS do gateway VPN do Azure com o servidor NPS para autenticação multifator.

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

Sim, a autenticação RADIUS é suportada para IKEv2 e SSTP VPN.

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

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

VNet-to-VNet e conexões multissite

As informações de VNet-to-VNet nesta seção se aplicam 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 Preços do Gateway de VPN do Azure. Se você estiver conectando suas redes virtuais usando o emparelhamento de redes virtuais em vez de um gateway de VPN, consulte Preços da Rede Virtual do Azure.

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 VPN funcionam entre locatários do Microsoft Entra.

O tráfego VNet a VNet é seguro?

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

Preciso de um dispositivo VPN para ligar VNets?

N.º Conectar várias redes virtuais do Azure juntas não requer um dispositivo VPN, a menos que você precise de conectividade entre 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, as assinaturas precisarão ser associadas ao mesmo locatário do Microsoft Entra?

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 chinesas, alemãs ou do governo 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. Você pode usar a conectividade de rede virtual simultaneamente com VPNs multissite.

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

Consulte a tabela de requisitos do gateway.

Posso usar VNet-to-VNet para conectar VMs ou serviços de nuvem 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 abranger redes virtuais, mesmo que elas estejam conectadas.

Posso usar um tipo de VPN baseado em política para conexões VNet-to-VNet ou multissite?

N.º As conexões VNet-to-VNet e multissite exigem gateways VPN com tipos de VPN baseados em rota (anteriormente chamados 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.º Ambas as redes virtuais devem usar VPNs baseadas em rota (anteriormente chamadas de roteamento dinâmico).

Os túneis VPN partilham a largura de banda?

Sim. Todos os túneis VPN da rede virtual compartilham a largura de banda disponível no gateway VPN e o mesmo contrato de nível de serviço para o tempo de atividade do gateway 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 a Rota Expressa?

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

Posso usar um gateway VPN para transitar tráfego entre meus sites locais ou para outra rede virtual?

  • Modelo de implementação Resource Manager

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

  • Modelo de implementação clássica

    O tráfego em trânsito por meio de um gateway VPN é possível quando você usa o modelo de implantação clássico, mas depende de espaços de endereço definidos estaticamente no arquivo de configuração de rede. Atualmente, o BGP (Border Gateway Protocol) não tem suporte com redes virtuais do Azure e gateways VPN por meio do modelo de implantação clássico. Sem 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é-partilhada IPsec/IKE para todas as minhas ligações VPN para a mesma rede virtual?

N.º Por padrão, o Azure gera diferentes chaves pré-compartilhadas para diferentes conexões VPN. No entanto, você pode usar a API REST set VPN Gateway Key ou o cmdlet PowerShell para definir o valor de 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.º Todos os túneis VPN, incluindo VPNs ponto a site, compartilham o mesmo gateway VPN e a largura de banda disponível.

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

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 respeita o caminho do sistema autônomo (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.º 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ê precisará usar o caminho AS pendente.

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

Sim. Você pode usar VPNs ponto a site com os gateways de VPN se conectando 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 coexistentes site a site.

IPsec/política IKE

Há suporte para uma política IPsec/IKE personalizada em todas as SKUs do Gateway de VPN do Azure?

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

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

Você pode especificar apenas uma combinação de política para uma conexão.

Posso especificar uma política parcial em uma conexão (por exemplo, apenas algoritmos 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 algoritmos e principais pontos fortes a política personalizada suporta?

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
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
Vida útil do Modo Rápido SA (Opcional; valores padrão se não especificados)
Segundos (inteiro; mínimo 300, padrão 27.000)
Kilobytes (inteiro; mínimo 1.024, padrão 10.2400.000)
Seletor de tráfego UsePolicyBasedTrafficSelectors$True( ou $False, mas opcional; padrão $False se não especificado)
Tempo limite do DPD Segundos (inteiro; mínimo 9, máximo 3.600, padrão 45)

  • Sua configuração de dispositivo VPN local deve corresponder ou conter os seguintes algoritmos e parâmetros especificados na política IPsec ou 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 você usar UsePolicyBasedTrafficSelectors)
    • Tempo de vida da SA (especificações locais que não precisam corresponder)

  • Se você usar GCMAES para o algoritmo de criptografia IPsec, deverá selecionar o mesmo algoritmo GCMAES e o mesmo 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.
    • 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 especifica 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 como $True em uma conexão, ele configurará o gateway VPN para se conectar a um firewall VPN local baseado em política.

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

    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 um gateway VPN a vários dispositivos VPN locais baseados em políticas.

  • Definir o tempo limite para períodos mais curtos faz com que o IKE volte a chavear de forma mais agressiva. A conexão pode então parecer desconectada em alguns casos. Essa situação 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 pacotes. Geralmente, recomendamos que você defina o tempo limite entre 30 e 45 segundos.

Para obter mais informações, consulte Conectar um gateway VPN a vários dispositivos VPN locais baseados em políticas.

Quais grupos Diffie-Hellman a política personalizada suporta?

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

Para obter mais informações, consulte RFC3526 e RFC5114.

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

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

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

Não, o IPsec/IKE ainda ajuda a proteger a ligação. Depois de remover a política personalizada de uma conexão, o gateway VPN reverte para a lista padrão de propostas IPsec/IKE e reinicia o handshake IKE com seu dispositivo VPN local.

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

Sim. Isso pode causar uma pequena interrupção (alguns segundos) à medida que o gateway VPN derruba a conexão existente e reinicia o handshake IKE para restabelecer o túnel IPsec com os novos algoritmos e parâmetros criptográficos. Certifique-se de que seu dispositivo VPN local também esteja 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. Uma política personalizada é aplicada por conexã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.

Posso usar uma política personalizada em conexões VNet-to-VNet?

Sim. Você pode aplicar uma política personalizada em conexões IPsec entre locais e conexões VNet-to-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. Verifique se ambos os recursos de conexão têm a mesma política. Caso contrário, a conexão VNet-to-VNet não será 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 em gateways VPN. Você pode especificar um valor de tempo limite DPD diferente em cada conexão IPsec ou VNet-to-VNet, de 9 segundos a 3.600 segundos.

Nota

Definir o tempo limite para períodos mais curtos faz com que o IKE volte a chavear de forma mais agressiva. A conexão pode então parecer desconectada em alguns casos. Essa situação 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 pacotes. Geralmente, recomendamos que você defina o tempo limite entre 30 e 45 segundos.

Uma política IPsec/IKE personalizada funciona em conexões de Rota Expressa?

N.º Uma política IPsec/IKE funciona apenas em conexões S2S VPN e VNet-to-VNet por meio dos gateways VPN.

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

Você pode criar conexões IKEv1 em todas as SKUs do tipo VPN baseadas em rota, exceto a SKU básica, a SKU padrão e outras SKUs anteriores.

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 Azure PowerShell.

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

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

Sim.

Posso ter conexões IKEv1 site a site na SKU básica para o tipo de VPN baseada em rota?

N.º O Basic SKU não suporta essa configuração.

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

N.º Depois de criar a conexão, não é possível alterar os protocolos IKEv1 e IKEv2. 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 seus gateways VPN não suportem 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 guia de resolução de problemas.

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

Consulte os seguintes artigos:

BGP e roteamento

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

O BGP é suportado 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 posso usar?

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

Não é possível usar os seguintes ASNs reservados:

  • Reservado pelo Azure:

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

  • Reservado por IANA:

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

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

Posso usar ASNs de 32 bits (4 bytes)?

Sim, o Gateway de VPN do Azure agora oferece suporte a ASNs de 32 bits (4 bytes). Para configurar usando ASN em formato decimal, use o Azure 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

Nem a IANA nem o Azure reservam esses ASNs, portanto, você pode atribuí-los ao seu gateway de VPN.

Que endereço o Gateway de VPN do Azure usa para IP de mesmo nível BGP?

Por padrão, o Gateway de VPN do Azure aloca um único endereço IP do GatewaySubnet intervalo 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 encontrar o endereço IP BGP alocado usando o Azure PowerShell ou o portal do Azure. No PowerShell, use Get-AzVirtualNetworkGatewaye procure a bgpPeeringAddress propriedade. 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 de endereçamento IP privado automático (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 VPN. 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 para o Gateway de VPN do Azure.

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 VNet 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 o seu dispositivo usa um endereço APIPA para BGP, você deve especificar um ou mais endereços IP APIPA BGP em seu gateway VPN, conforme descrito em Configurar BGP para Gateway de VPN do Azure. 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.

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 , porque ela é redundante. Se você usar um endereço APIPA como o dispositivo VPN local BGP IP, não poderá adicioná-lo 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.º 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ê precisa atribuir seus ASNs locais aos gateways de rede local do Azure correspondentes.

Que prefixos de endereço os gateways de VPN do Azure anunciam para mim?

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

  • Os seus prefixos de endereços VNet
  • Prefixos de endereço para cada gateway de rede local conectado ao gateway VPN
  • Rotas aprendidas de outras sessões de emparelhamento BGP conectadas ao gateway VPN, 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é 4.000 prefixos. A sessão de BGP é ignorada se o número de prefixos exceder o limite.

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

Sim. Lembre-se de que anunciar a rota padrão força todo o tráfego de saída de VNet em direção ao seu site local. Ele também impede que as VMs de rede virtual aceitem comunicação pública diretamente da Internet, como RDP (Remote Desktop Protocol) ou SSH (Secure Shell) 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 sua rede virtual (incluindo redes virtuais emparelhadas). O Azure bloqueia ou filtra o anúncio de quaisquer prefixos que correspondam aos seus prefixos de endereço de rede virtual. No entanto, você pode anunciar um prefixo que é um superconjunto do espaço de endereço da sua rede virtual. Por exemplo, se sua rede virtual usa o espaço de endereço 10.0.0.0/16, você pode anunciar 10.0.0.0/8, mas não 10.0.0.0/16 ou 10.0.0.0/24.
  • Quando o trânsito do gateway não está habilitado: o gateway não aprende prefixos de rede virtual emparelhados, permitindo que você anuncie os prefixos exatos como sua rede virtual emparelhada.

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

Sim. Você pode usar o 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 VPN não anunciam rotas padrão para outros pares BGP. Para habilitar o roteamento de trânsito em vários gateways VPN, você deve habilitar o BGP em todas as conexões intermediárias entre redes virtuais. Para obter mais informações, consulte Sobre BGP e VPN Gateway.

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

Sim, você pode estabelecer mais de um túnel VPN site a site entre um gateway VPN e sua rede local. 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 VPN e uma de suas redes locais, eles consumirão dois túneis da cota total para seu gateway VPN.

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

Sim, mas pelo menos um dos gateways de rede virtual deve estar em uma configuração ativa-ativa.

Posso usar o BGP para uma 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 rapidamente do que você pode usando intervalos de keepalive padrão do BGP. O BFD usa temporizadores subsegundos projetados para funcionar em ambientes LAN, mas não através da Internet pública ou conexões WAN.

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 o BGP amorteca as rotas.

Como alternativa, você pode configurar seu dispositivo local com temporizadores inferiores ao intervalo keepalive padrão de 60 segundos ou inferiores ao temporizador de retenção de 180 segundos. Essa configuração resulta em um tempo de convergência mais rápido. No entanto, temporizadores abaixo do intervalo de keepalive padrão de 60 segundos ou abaixo do temporizador de retenção padrão de 180 segundos não são confiáveis. Recomendamos que você mantenha os temporizadores em ou acima dos valores padrão.

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

Os gateways VPN iniciam 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. Esse processo é independente se os endereços IP BGP locais estão no intervalo APIPA ou são endereços IP privados regulares. Se seus dispositivos VPN locais usam endereços APIPA como o 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 para VpnGw25 e em VpnGw2AZ para VpnGw5AZ.

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 uma barra (/) 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 que têm 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 juntos.

Que tipos de NAT os gateways VPN suportam?

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

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:

  • Para garantir que as rotas aprendidas e as rotas anunciadas sejam convertidas em prefixos de endereço pós-NAT (mapeamentos externos) com base nas regras NAT associadas às conexões, selecione Habilitar conversã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 do 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 locais, certifique-se de que a regra IngressSNAT traduzirá o IP do par BGP para um endereço exclusivo e não sobreposto. Coloque o endereço pós-NAT no campo Endereço IP de mesmo nível 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 de conversão de endereços de rede de origem (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 VPN 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 VNet que saem do gateway VPN 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 das conexões que têm a regra EgressSNAT .

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

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 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 para o gateway de rede local consistir em 10.0.1.0/24 e 10.0.2.0/25, você poderá criar duas regras:

  • Regra 1 do IngressSNAT : Mapa 10.0.1.0/24 a 192.168.1.0/24.
  • Regra 2 do IngressSNAT : Mapa 10.0.2.0/25 a 192.168.2.0/25.

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

Importante

Se você vincular apenas uma regra à conexão anterior, 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?

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 é 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çamento da VNet. Se o espaço de endereço VNet for exclusivo entre todas as redes conectadas, você não precisará da regra EgressSNAT nessas conexões. Você pode usar as regras de entrada para evitar a sobreposição de endereços entre as redes locais.

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

ID de configuração IP é 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 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?

Se tiver o RDP ativado para a sua VM, pode ligar à máquina virtual através do 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.

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. Não é possível RDP para sua máquina virtual usando o endereço IP privado se você 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.º Somente o tráfego que tem um IP de destino contido nos intervalos de endereços IP da rede local da rede virtual que você especificou passa pelo gateway de rede virtual.

O tráfego que tem um IP de destino localizado dentro da rede virtual permanece dentro da rede virtual. Outro tráfego é enviado através do balanceador de carga para as redes públicas. Ou, se você usar o túnel forçado, o tráfego será enviado pelo gateway de VPN.

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.
  • Se você puder se conectar à VM usando o endereço IP privado, mas não o nome do computador, verifique se configurou o DNS corretamente. Para obter mais informações sobre como a resolução de nomes funciona para VMs, consulte Resolução de nomes para recursos em redes virtuais do Azure.

Quando você se conectar 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 pool de endereços do cliente VPN, é um espaço de endereço sobreposto. Quando o seu espaço de endereço se sobrepõe desta forma, o tráfego de rede não chega ao Azure. Mantém-se na rede local.
  • Verifique se o pacote de configuração do cliente VPN foi gerado depois de especificar os endereços IP do servidor DNS 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 na configuração de manutenção para o escopo 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 a site) no serviço WAN Virtual do Azure
  • Gateway de Rota Expressa no serviço WAN Virtual

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

Posso receber uma notificação antecipada da manutenção?

No momento, não é possível obter notificação avançada 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 um mínimo de uma janela de cinco horas no seu fuso horário preferido.

Posso configurar uma janela de manutenção diferente de uma 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 SO convidado e atualizações de 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.

Se um problema de segurança de alta gravidade puder colocar os clientes em perigo, o Azure pode precisar substituir o controle do cliente da janela de manutenção e promover uma alteração. Estas 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?

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

Quanto tempo leva para uma política de configuração de manutenção entrar 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. A manutenção controlada pelo cliente não funciona para recursos que usam endereços IP públicos SKU básicos, exceto no caso de atualizações de serviço. 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?

Quando você trabalha com VPN e ExpressRoute em um cenário de coexistência ou sempre que tiver recursos que atuam como backups, recomendamos configurar janelas de manutenção separadas. Essa abordagem garante que a manutenção não afete seus recursos de backup ao mesmo tempo.

Agendei uma janela de manutenção para uma data futura para um dos meus recursos. As atividades de manutenção estão pausadas neste recurso até lá?

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. 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 Configurar manutenção de gateway controlado pelo cliente para gateway VPN.

Conteúdos relacionados

"OpenVPN" é uma marca comercial da OpenVPN Inc.