Migrar o Gateway de VPN da implementação Clássica para o Resource Manager

Os gateways 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 Modelo de implantação do Resource Manager. Neste artigo, discutimos como migrar de implantações clássicas para o modelo do Resource Manager.

Importante

Não é mais possível criar novos gateways de rede virtual para redes virtuais de modelo de implantação clássico (gerenciamento de serviços). Novos gateways de rede virtual podem ser criados somente para redes virtuais do Resource Manager.

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

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

Quando a migração da rede virtual for concluída, o Azure tentará concluir o restante da migração do gateway para o Gerenciador de Recursos. Se a migração do gateway não for bem-sucedida, os clientes poderão ser informados para excluir seu Gateway VPN (implantação clássica) e criar um novo gateway VPN (Gerenciador de Recursos). Se nenhuma ação for tomada pelo cliente, o Gateway 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 Gerenciador de Recursos.

O modelo do Resource Manager é diferente do modelo clássico e é composto por gateways de rede virtual, gateways de rede local e recursos de conexão. Eles representam o próprio gateway de VPN, o site local que representa 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.

Localizando um gateway VPN clássico

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

Para localizar um gateway VPN clássico através do portal do Azure, abra o portal e procure "Rede virtual (clássica)". Selecione sua rede virtual clássica e navegue até a folha do gateway para encontrar seu gateway de rede virtual clássico.

Cenários suportados

Os cenários de conectividade VPN mais comuns são cobertos pela migração clássica para o Gerenciador de Recursos. Os cenários suportados incluem:

• Conectividade ponto a site
• Conectividade site a site com o Gateway VPN conectado ao local
• Conectividade VNet-to-VNet entre duas VNets usando gateways VPN
• Várias redes virtuais conectadas ao mesmo local
• Conectividade multi-site
• VNets habilitadas para tunelamento forçado

Os cenários que não são suportados incluem:

• A VNet com um gateway de Rota Expressa e um gateway de VPN não é suportada no momento.
• Cenários de trânsito em que as extensões de VM estão conectadas a servidores locais. As limitações de conectividade de VPN de trânsito são detalhadas nas próximas seções.

Nota

A validação do CIDR no modelo do Resource Manager é mais rigorosa do que no modelo clássico. Antes de migrar, certifique-se de que os intervalos de endereços clássicos fornecidos estejam em conformidade com o formato CIDR válido antes de iniciar a migração. O CIDR pode ser validado usando qualquer validador CIDR comum. A VNet ou sites locais com intervalos CIDR inválidos quando migrados resultam em um estado de falha.

Migração de conectividade VNet-to-VNet

A conectividade VNet-to-VNet no modelo de implantação clássico foi obtida através da criação de uma representação local do site da VNet conectada. Os clientes eram obrigados a criar dois sites locais que representassem as duas redes virtuais que precisavam ser conectadas. Eles foram então conectados às VNets correspondentes usando o túnel IPsec para estabelecer a conectividade entre as duas VNets. Esse modelo tem desafios de capacidade de gerenciamento, uma vez que qualquer alteração no intervalo de endereços em uma VNet também deve ser mantida 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 redes virtuais pode ser obtida diretamente usando o tipo de conexão 'Vnet2Vnet' no recurso Conexão.

Durante a migração de VNet, detetamos que a entidade conectada ao gateway VPN da VNet atual é outra VNet. Garantimos que, uma vez concluída a migração de ambas as redes virtuais, você não verá mais dois sites locais representando a outra rede virtual. O modelo clássico de dois gateways VPN, dois sites locais e duas conexões entre eles é transformado no modelo do Resource Manager com dois gateways VPN e duas conexões do tipo Vnet2Vnet.

Conectividade VPN de trânsito

Você pode configurar gateways VPN em uma topologia de modo que a conectividade local para uma VNet seja obtida conectando-se a outra VNet diretamente conectada ao local. Trata-se da conectividade VPN de trânsito, em que as instâncias na primeira VNet são conectadas a recursos locais por meio do trânsito para o gateway VPN na VNet conectada diretamente ao local. Para obter essa configuração no modelo de implantação clássico, você precisa criar um site local que tenha prefixos agregados que representem a VNet conectada e o espaço de endereçamento local. Esse site local representacional é então conectado à VNet para obter conectividade de trânsito. O modelo clássico também tem desafios semelhantes de capacidade de gerenciamento, uma vez que qualquer alteração no intervalo de endereços local também deve ser mantida no site local representando a agregação de VNet e local. A introdução do suporte a BGP em gateways suportados pelo Resource Manager simplifica a capacidade de gerenciamento, uma vez que os gateways conectados podem aprender rotas locais sem modificação manual de prefixos.

Como transformamos a conectividade VNet-to-VNet sem exigir sites locais, o cenário de trânsito perde a conectividade local para a VNet que está indiretamente conectada ao local. A perda de conectividade pode ser atenuada das duas maneiras a seguir, após a conclusão da migração:

• Habilite o BGP em gateways VPN conectados entre si e ao local local. A ativação do BGP restaura a conectividade sem quaisquer outras alterações de configuração, uma vez que as rotas são aprendidas e anunciadas entre gateways VNet. Observe que a opção BGP só está disponível em SKUs padrão e superiores.
• Estabeleça uma conexão explícita da VNet afetada com o gateway de rede local que representa o local local. Isso também exigiria alterar a configuração no roteador local para criar e configurar o túnel IPsec.

Próximos passos

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