Sobre a migração de um endereço IP público de SKU Básico para SKU Standard

Este artigo explica o processo de migração de um endereço IP público de SKU básico para um endereço IP público de SKU Padrão para implantações de Gateway de VPN. Há cronogramas de migração separados, dependendo do SKU do Gateway de VPN que seu gateway está atualmente configurado para usar.

Importante

Para ver os cronogramas de migração previstos, consulte o artigo Gateway de VPN - Novidades.

Considerações sobre migração

Para migrar seu gateway, primeiro você precisa validar se o recurso é capaz de migrar. Aqui estão algumas situações comuns para estar ciente:

  • Para o SKU do gateway básico do Gateway de VPN:

  • Para as SKUs do Gateway de VPN VpnGw1-5 e as SKUs legadas (SKU de alto desempenho e SKU padrão):

    • Antes de iniciar a migração para o gateway de VPN, verifique se a sub-rede do gateway tem pelo menos três endereços IP disponíveis no prefixo atual.

    • Ao configurar um terceiro VIP no modo Ativo-Ativo para Ponto a Site (P2S), um IP público não zonal deve ser usado.

    • A ferramenta de migração requer que a sub-rede do gateway tenha pelo menos um espaço de endereço /27. Se a sua sub-rede de gateway for atualmente /28 ou menor, a migração falhará e retornará um erro. Antes de iniciar a migração, expanda a sub-rede do gateway para /27 ou maior. Para adicionar vários prefixos para uma sub-rede, consulte adicionar vários prefixos para sub-rede.

    • Se você tiver o ExpressRoute e a VPN coexistindo: recomendamos a migração dos recursos ip básicos para o IP Standard na VPN primeiro.

perguntas frequentes

Dependendo do SKU atual do Gateway de VPN, você pode ter perguntas diferentes sobre o processo de migração. Aqui estão algumas perguntas frequentes para ajudá-lo a entender melhor a migração.

Porta de entrada VPN, SKUs VpnGw1-5

Quanto tempo a migração de ponta a ponta normalmente leva?

O processo de migração inteiro geralmente leva até 2 horas, dependendo do tamanho e da configuração da implantação.

Quanto tempo cada etapa de migração leva?

As durações da etapa de migração podem variar com base na complexidade do ambiente. Em média:

  • Preparar: normalmente até 40 minutos, com um máximo de 1 hora.
  • Executar: leva cerca de 5 a 10 minutos. (Esta é a única etapa em que um breve tempo de inatividade é esperado.)
  • Confirmação: normalmente até 30 minutos, ccom no máximo 1 hora.

Quanto tempo posso esperar antes de confirmar minhas alterações de migração?

A validação de migração normalmente é concluída em um curto período de tempo. Os clientes são aconselhados a concluir a validação e confirmar alterações de migração dentro de alguns dias, pois não é recomendável deixar as migrações pendentes por longos períodos. A duração real varia de acordo com as necessidades de ambiente e validação.

Como minha SKU de gateway será afetada após a migração do endereço IP público do SKU Básico?

Após a atualização de um endereço IP público SKU Básico para um endereço IP público de SKU Standard, seu SKU de gateway de VPN VPNGW1-5 será migrado para VPNGW1AZ-5. Como resultado, você poderá ver a SKU alterada de uma SKU não AZ para uma SKU AZ. Para obter mais informações sobre o impacto da SKU, consulte o artigo "Migração de SKU do Gateway".

Meu endereço IP do gateway de VPN será alterado depois que meu endereço IP público for migrado?

  • Se você usar a experiência de migração fornecida Microsoft, o endereço IP do gateway não será alterado.
  • Se você excluir manualmente o gateway de VPN atual que tem um endereço IP público de SKU Básico e criar um novo gateway de VPN usando um endereço IP público de SKU Padrão, o endereço IP do gateway será alterado.

Haverá algum tempo de inatividade?

Espera-se até 10 minutos de tempo de inatividade durante a experiência de migração fornecida Microsoft.

Preciso executar alguma ação para migrar?

A experiência de migração fornecida Microsoft é uma migração iniciada pelo cliente. Você precisará iniciar o processo de migração. Espera-se que o processo de migração leve até 10 minutos.

Há pré-requisitos de migração?

Verifique se a sub-rede do gateway tem espaço de endereço IP e tamanho de sub-rede corretos. Você precisará de pelo menos três endereços IP disponíveis no prefixo atual antes de executar a migração.

Posso alterar para um endereço IP público do SKU Standard manualmente?

Sim, você pode. Se você optar por fazer isso manualmente, precisará excluir o gateway antigo e criar um novo gateway em sua rede virtual. Ao criar um novo gateway, o gateway usará automaticamente um endereço IP público de SKU Standard. No entanto, se você optar por usar esse processo, incorrerá em tempo de inatividade enquanto o gateway antigo é excluído e o novo gateway é criado.

Se eu excluir e recriar meu gateway, meu endereço IP será alterado?

Sim, o endereço IP muda com essa abordagem. Isso significa que você precisará garantir que o novo endereço IP seja atualizado em todas as ferramentas internas, conforme necessário.

A migração do gateway de VPN afetará o tráfego do ExpressRoute em uma configuração coexistente?

Não. Ao seguir a ordem de migração recomendada, migrar primeiro o gateway de VPN não migra, interrompe ou afeta o tráfego do ExpressRoute. A conectividade do ExpressRoute permanece não afetada durante a migração do gateway de VPN. Os clientes não devem esperar problemas de conectividade do ExpressRoute ao migrar o gateway de VPN primeiro.

Posso habilitar a proteção contra DDoS durante a migração de gateway?

Não. Enquanto o gateway estiver em migração (entre Executar e Confirmar), não faça nenhuma alteração no IP público, gateway ou conexões. Habilitar a proteção contra DDoS ou outros recursos avançados durante essa fase pode bloquear a migração ou impedir a reversão. Habilite esses recursos somente depois que a migração for totalmente concluída (após a Confirmação).

Posso modificar meu IP, Gateway de VPN, sub-rede ou conexões durante a migração?

Não. Embora o Gateway de VPN esteja em migração (entre Executar e Confirmar), você não deve fazer nenhuma alteração no seguinte:

Endereço IP público Configuração de gateway de VPN Sub-rede do gateway Conexões

Fazer alterações durante essa fase pode colocar o gateway em um estado sem suporte ou travado, pois o fluxo de trabalho de migração não lida com atualizações simultâneas.

O que acontece se eu fizer alterações durante a migração e o gateway ficar preso?

Se o gateway entrar em um estado de migração paralisado ou irrecuperável devido a alterações feitas durante a migração:

O sistema pode não conseguir concluir ou reverter a migração. Nesses casos, a única opção de recuperação pode ser excluir e recriar o gateway.

SKUs do gateway VpnGw1-5 ativo-ativo

Por que meu Gateway de VPN Ativo-Ativo com P2S (Ponto a Site) exige um terceiro IP?

Gateways de VPN Ativo‑Ativo com P2S ativado exigem um terceiro IP para dar suporte ao ponto de extremidade P2S e aos dois IPs usados para instâncias Ativo‑Ativo.

A documentação diz que o terceiro IP público deve ser não zonal. Isso ainda é necessário?

Sim.
Para esse cenário, o terceiro IP público deve ser configurado sem zonas (não zonal) para garantir a compatibilidade com a configuração do Gateway de VPN e futuras operações de atualização.

Quando devo criar o terceiro IP público durante a migração?

O terceiro IP público deve ser criado e anexado ao Gateway de VPN até iniciar a migração (IP Padrão → Básico).

Isso garante que:

  • A configuração do gateway é concluída antes da migração
  • O processo de migração continua sem problemas de validação ou atualização

Como faço para criar o IP público não zonal necessário?

Em regiões em que os IPs com redundância de zona são o padrão, você deve criar o terceiro IP público usando a CLI do Azure, o PowerShell ou a API REST versão 2020-08-01 ou posterior, configurando um IP público não zonal/sem zona e garantindo que nenhuma zona de disponibilidade seja especificada.

Isso permite que o IP público seja criado em uma configuração não zonal, o que é necessário para esse cenário.

Posso usar um IP público com redundância de zona em vez de um IP não zonal para o terceiro IP P2S?

Não.

Todos os IPs públicos associados a um Gateway de VPN devem usar uma configuração consistente. O uso de um IP público com redundância de zona para o terceiro IP pode resultar em falhas de implantação ou atualização.

Esse comportamento afeta todas as migrações Gateway de VPN?

Não.

Esse requisito se aplica especificamente a:

  • Gateways de VPN ativo-ativo
  • Com o Point-to-Site (P2S) habilitado

Como a migração se comporta para um gateway de VPN Ativo-Ativo usando um IP público básico? Isso causa uma interrupção total do gateway?

Não. Durante a migração de um IP público básico para um IP público padrão, o gateway de VPN é transitório como uma unidade e restabelece a conectividade como parte do processo de migração. A migração não move o tráfego de uma instância de gateway para outra e não resulta em uma interrupção completa do gateway. Interrupções de conectividade curtas podem ocorrer durante a migração à medida que as conexões são restabelecidas, mas o gateway não é totalmente offline.

Durante a migração, somente os túneis em uma instância de gateway específica experimentam a interrupção enquanto a outra instância permanece ativa?

Não. Espera-se que os túneis VPN sejam restabelecidos como parte do processo de migração, mas eles não são migrados nem redirecionados individualmente por instância. Os túneis não devem apresentar instabilidade devido à migração de instâncias individuais do gateway, e a migração não se limita a instâncias específicas dentro de um gateway ativo-ativo.

Como o downtime deve ser descrito para a migração do gateway de VPN Active‑Active?

A migração é uma operação de interrupção e pode resultar em breves interrupções de conectividade enquanto a configuração do gateway de VPN é atualizada e as conexões são restabelecidas. Essas interrupções normalmente têm vários minutos de duração e, na maioria dos casos, são concluídas em aproximadamente 10 minutos, embora os intervalos exatos não sejam garantidos e possam variar de acordo com as condições de configuração e de rede. Os clientes devem planejar executar a migração durante uma janela de manutenção e garantir que os aplicativos sejam resilientes a interrupções de conectividade curtas.

Vejo a alteração do endereço IP do par BGP após a migração. Preciso atualizar os endereços IP dos meus pares BGP após migrar um Gateway de VPN ativo-ativo para IP padrão?

Não. Embora o portal Azure exiba novos endereços IP par BGP após a migração, as configurações de BGP locais existentes continuam funcionando sem alterações. O Azure redireciona automaticamente o tráfego dos endereços IP de emparelhamento BGP originais para os endereços IP de emparelhamento BGP, preservando a conectividade e as sessões BGP.

Rotas e balanceadores de carga criados pelo cliente durante a migração do gateway de VPN

Preciso examinar qualquer configuração de rede personalizada antes da migração?

Sim. Revise quaisquer tabelas de rotas (UDRs), Load Balancers, firewalls ou NVAs criados pelo cliente que possam referenciar IPs privados da instância do Gateway de VPN (CAs do gateway). E verifique se a propagação de rotas BGP está desativada antes da migração. Se o seu ambiente usa emparelhamento de VNet, verifique se o Sync VNet Peering está habilitado durante a migração.

Quando devo atualizar essas configurações?

Após a etapa Executar, atualize as rotas criadas pelo cliente, os balanceadores de carga, as regras de firewall ou as configurações de NVA que referenciam os IPs da instância do gateway antigo.

SKU Básica do Gateway de VPN

Posso criar um Gateway de VPN de SKU Básico com um endereço IP público de SKU básico?

Não, você não pode criar um Gateway de VPN de SKU Básico com um endereço IP público de SKU básico. Os Gateways de VPN com o novo SKU Básico exigem um SKU de endereço IP público Padrão.

Preciso migrar se tiver um Gateway de VPN de SKU Básico?

Os gateways de VPN do SKU Básico que atualmente aparecem como utilizando um endereço IP público de SKU Básico não usam o processo de migração para migrar para um SKU Padrão de endereço IP público. A única ação que você precisa executar é remover do seu gateway a referência ao IP público do SKU Básico.

Para obter etapas para remover a referência de IP público do SKU Básico, consulte Remover a referência de IP público do SKU Básico de um gateway de VPN do SKU Básico. O gateway continua a usar o mesmo endereço IP público. Somente a referência ao recurso de IP público do SKU Básico é removida do seu gateway.

Migração de back-end

Quando Microsoft executará a migração de back-end do meu gateway de VPN?

A partir de agosto de 2026, Microsoft migra automaticamente gateways de VPN qualificados que ainda não foram migrados por meio do autoatendimento. Como essa operação é gerenciada por Microsoft, você não receberá uma notificação de migração por gateway antes que a migração ocorra. Microsoft executa a migração fora do horário comercial com base no horário local regional do gateway para ajudar a minimizar o impacto do cliente.

Meu endereço IP público do gateway de VPN será alterado durante a migração?

Não. A migração atualiza o recurso de IP público do SKU Básico para o SKU Standard, mas o endereço IP público existente é mantido. Você não precisa realizar nenhuma ação para a atualização do IP público.

A migração causará tempo de inatividade ou interrupção de tráfego?

Sim. A migração causa uma breve interrupção de conectividade de até 10 minutos enquanto o gateway faz a transição para a nova infraestrutura de back-end. No entanto, determinadas configurações de gateway, como seletores de tráfego personalizados, Active-Active P2S, P2S baseado em CloudApp, RADIUS Remoto e outros casos de borda identificados, podem exigir a ação do cliente e podem causar impacto de conectividade se não forem corrigidas com antecedência.

Preciso executar alguma ação antes da migração de back-end?

Sim. Conclua a migração de autoatendimento (iniciada pelo cliente) antes que a migração de back-end comece. Esse processo ajuda você a validar seus padrões de tráfego específicos, aplicativos e topologia de rede, que Microsoft não podem testar totalmente em seu nome. Se você não realizar a migração de autoatendimento, a Microsoft poderá migrar automaticamente os gateways elegíveis durante a migração de back-end. Essa migração não é reversível. Microsoft também pode executar testes de grito em alguns gateways. Gateways determinados como inativos podem ser excluídos como parte do processo de desativação. Além disso, examine e corrija as configurações afetadas conhecidas, como seletores de tráfego personalizados, Active-Active P2S, P2S baseado em CloudApp e RADIUS Remoto, antes da migração para evitar possíveis problemas de conectividade.

O que acontece se eu não concluir a migração até 30 de junho de 2026?

A migração iniciada pelo cliente terminou em 30 de junho de 2026. Esperava-se que você concluísse a migração até esta data. Se você permanecer na plataforma herdada após 30 de junho de 2026, o SLA do serviço Gateway de VPN não o cobrirá mais até que a migração seja concluída. As solicitações de extensão até 31 de julho de 2026 são aprovadas automaticamente e não exigem revisão individual. A partir de agosto de 2026, a Microsoft planeja migrar os gateways de VPN elegíveis restantes que ainda não foram migrados. A Microsoft realiza migrações de back-end por região fora do horário comercial, e essas migrações podem resultar em uma breve interrupção de conectividade, semelhante à experiência de migração iniciada pelo cliente.

Próximas etapas

  • Last updated on