Gateway de VPN clássico para migração do Gerenciador de Recursos

Os gateways de VPN agora podem ser migrados do modelo de implantação clássico para o modelo de implantação do Resource Manager. Para obter mais informações, consulte Resource Manager e implantação clássica. Neste artigo, detalhamos como migrar de implantações clássicas para o modelo com base no Resource Manager mais recente.

Importante

Você não pode mais criar novos gateways de rede virtual para redes virtuais de modelo de implantação clássico (gerenciamento de serviço). Novos gateways de rede virtual só podem ser criados para redes virtuais do Resource Manager.

Os gateways de VPN começam com uma migração de VNet do clássico para o Resource Manager. Essa migração é feita por clientes com uma VNet por vez. Não há requisitos adicionais em termos de ferramentas ou pré-requisitos para iniciar a migração da VNet. As etapas de migração são idênticas à migração de VNet existente e são documentadas na página de migração de recursos IaaS.

Não há nenhum tempo de inatividade do roteiro de dados durante a migração da VNet e, portanto, cargas de trabalho existentes continuariam a funcionar sem perda de conectividade local durante a migração. O endereço IP público associado ao gateway de VPN não é alterado durante o processo de migração. Isso significa que você não precisará reconfigurar seu roteador local quando a migração for concluída.

Depois que a migração da VNet for concluída, o Azure tentará concluir o restante da migração de gateway para o Resource Manager. Se a migração de gateway não for bem-sucedida, os clientes poderão ser informados para excluir o Gateway de VPN (implantação clássica) e criar um novo gateway de VPN (Resource Manager). Se nenhuma ação for tomada pelo cliente, o Gateway de VPN existente (implantação clássica) poderá ser desativado. Os clientes podem visitar as perguntas frequentes para obter informações adicionais e minimizar o tempo de inatividade durante a migração do clássico para o Resource Manager.

O modelo no Resource Manager é diferente do modelo clássico e é composto de gateways de rede virtual, gateways de rede local e recursos de conexão. Eles representam o gateway de VPN, o site local representando o espaço de endereço local e a conectividade entre os dois, respectivamente. Quando a migração for concluída, seus gateways não estarão disponíveis no modelo clássico e todas as operações de gerenciamento em gateways de rede virtual, gateways de rede local e objetos de conexão deverão ser executadas usando o modelo do Resource Manager.

Localizar um gateway de VPN clássico

Para localizar um gateway de VPN clássico por meio do PowerShell, você precisará instalar o módulo de Gerenciamento de Serviços do Azure PowerShell. Comece aqui: Instalação do módulo de Gerenciamento de Serviços do Azure PowerShell. Para exibir recursos clássicos, você precisará de permissões de coadministrador ou proprietário. Não é possível usar cmdlets do Az para acessar recursos clássicos.

Para localizar um gateway de VPN clássico por meio do portal do Azure, abra o portal e pesquise "Rede virtual(clássica)". Selecione sua rede virtual clássica e navegue até o painel do gateway para encontrar seu gateway de rede virtual clássico.

Cenários com suporte

Os cenários mais comuns de conectividade VPN são cobertos pela migração do clássico para o Gerenciador de Recursos. Os cenários com suporte incluem:

• Conectividade de ponto a site
• Conectividade site a site com o Gateway de VPN conectado à localização local
• Conectividade VNet a VNet entre duas redes VNets usando gateways de VPN
• Várias redes virtuais conectadas à mesma localização local
• Conectividade de vários sites
• VNets com diagrama do túnel forçado

Os cenários que não têm suporte incluem:

• No momento, não há suporte para VNet com um gateway do ExpressRoute e um gateway de VPN.
• Cenários de tráfego em que as extensões de VM estiverem conectadas a servidores locais. As limitações de conectividade VPN de trânsito são detalhadas nas próximas seções.

Observação

A validação CIDR no modelo do Resource Manager é mais restrita do que no modelo clássico. Antes de migrar, verifique se os intervalos de endereços do clássico dados seguem um formato CIDR válido antes de iniciar a migração. A CIDR pode ser validada usando qualquer validador de CIDR comum. VNet ou sites locais com intervalos CIDR inválidos resultariam em estado de falha quando migrados.

Migração de conectividade VNet a VNet

A conectividade VNet a VNet no modelo de implantação clássico foi obtida ao criar uma representação de site local da VNet conectada. Os clientes precisavam criar dois sites locais que representassem as duas VNets que precisavam ser conectadas. Em seguida, elas eram conectadas às VNets correspondentes usando túneis IPsec para estabelecer a conectividade entre as duas VNets. Esse modelo tem desafios de gerenciamento, já que as alterações de intervalo de endereço em uma VNet também devem ser mantidas na representação do site local correspondente. No modelo do Resource Manager, essa solução alternativa não é mais necessária. A conexão entre as duas VNets pode ser obtida diretamente usando o tipo de conexão "Vnet2Vnet" no recurso de conexão.

Durante a migração da VNet, detectamos que a entidade conectada ao gateway VPN da VNet atual é outra VNet. Garantimos que, após a conclusão da migração de ambas as VNets, você não veja mais dois sites locais representando a outra VNet. O modelo clássico de dois gateways de VPN, dois sites locais e duas conexões entre eles é transformado no modelo do Resource Manager com dois gateways de VPN e duas conexões do tipo Vnet2Vnet.

Conectividade VPN de tráfego

É possível configurar gateways de VPN em uma topologia de tal forma que a conectividade local para uma VNet seja obtida pela conexão a outra VNet que esteja conectada diretamente ao local. Trata-se da conectividade VPN de tráfego em que as instâncias na primeira VNet são conectadas aos recursos locais por meio do trânsito para o gateway de VPN na VNet conectada que está conectada diretamente ao local. Para atingir essa configuração no modelo de implantação clássico, você precisaria criar um site local que tivesse agregado prefixos representando a VNet conectada e o espaço de endereço local. Esse site local representacional seria, então, conectado à VNet para obter conectividade de tráfego. Esse modelo clássico também traz desafios de gerenciamento semelhantes, pois qualquer alteração no intervalo de endereço local também deve ser mantida no site local que representa a agregação de VNet e local. A introdução do suporte a BGP em gateways compatíveis do Resource Manager com suporte simplifica a gerenciabilidade, pois os gateways conectados aprendem rotas do local sem modificações manuais de prefixos.

Como é possível transformar a conectividade VNet a VNet sem a necessidade de sites locais, o cenário de tráfego perde conectividade local para a VNet que estiver indiretamente conectada ao local. A perda de conectividade pode ser reduzida nas duas maneiras a seguir, após a migração ser concluída -

• Com a habilitação do BGP em gateways de VPN conectados juntos e ao local. A habilitação do BGP restaura a conectividade sem qualquer outra alteração de configuração, pois as rotas são aprendidas e anunciadas entre os gateways de VNet. Observe que a opção de BGP só está disponível em SKUs Standard ou superiores.
• O estabelecimento de uma conexão explícita da VNet afetada ao gateway de rede local que representa a localização local. Isso também exigiria a alteração da configuração do roteador local para criar e configurar o túnel IPsec.

Próximas etapas

Depois de aprender sobre o suporte à migração de gateway de VPN, acesse migração com suporte de plataforma de recursos de IaaS do clássico para o Gerenciador de Recursos para começar.