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

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 Standard para implementações de Gateway de VPN. Existem prazos de migração separados, dependendo do SKU do Gateway de VPN para o qual o seu gateway está configurado atualmente.

Importante

Para os prazos de migração previstos, consulte o artigo Gateway de VPN - O que há de novo.

Considerações sobre migração

Para migrar seu gateway, primeiro você precisa validar se seu recurso é capaz de migração. Aqui estão algumas situações comuns a ter em conta:

  • Para o SKU Basic do Gateway VPN:

  • Para os SKUs de Gateway VPN VpnGw1-5 e os SKUs Legadas (SKU High-Performance e SKU Padrão):

    • Antes de iniciar a migração para o gateway 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 em modo Ativo-Ativo para Point-to-Site (P2S), deve ser utilizado um IP Público não zonal.

    • A ferramenta de migração exige que a sub-rede gateway tenha pelo menos um espaço de endereçamento /27. Se a sua sub-rede de gateway tiver atualmente /28 ou menos, a migração falha e devolve uma mensagem de erro. Antes de iniciar a migração, expanda a sub-rede do gateway para /27 ou maior. Para adicionar múltiplos prefixos para uma subrede, veja adicionar múltiplos prefixos para sub-rede.

    • Se tiver ExpressRoute e VPN a coexistir: recomendamos considerar migrar primeiro os recursos IP Básicos para IP Standard na VPN .

FAQ

Dependendo do seu atual SKU de Gateway de VPN, pode ter dúvidas diferentes sobre o processo de migração. Aqui estão algumas perguntas frequentes para o ajudar a compreender melhor a migração.

VPN gateway SKUs VpnGw1-5

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

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

Quanto tempo demora cada etapa de migração?

As durações das etapas de migração podem variar de acordo com a complexidade do ambiente. Em média:

  • Preparação: 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.)
  • Compromisso: Normalmente até 30 minutos, com um máximo de 1 hora.

Quanto tempo posso esperar antes de realizar as alterações na migração?

A validação da migração é normalmente concluída num curto espaço de tempo. Aconselha-se os clientes a concluir a validação e a comprometer as alterações de migração dentro de alguns dias, pois não é recomendado deixar migrações pendentes por períodos prolongados. A duração real varia consoante o ambiente e as necessidades de validação.

Como a SKU do meu gateway será afetada após a migração do endereço IP público da SKU básica?

Depois de atualizar de um endereço IP público de SKU básico para um endereço IP público de SKU padrão, seu gateway de VPN SKU VPNGW1-5 será migrado para VPNGW1AZ-5. Como resultado, você pode ver o SKU alterado de um Non-AZ para um AZ-SKU. Para mais informações sobre o impacto do SKU, consulte o artigo Migração de SKU do Gateway.

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

  • Se usar a experiência de migração fornecida pela Microsoft, o endereço IP do seu gateway não mudará.
  • Se você excluir manualmente seu gateway de VPN atual que tenha 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 pela Microsoft.

Preciso tomar alguma medida para migrar?

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

Existem pré-requisitos de migração?

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

Posso alterar para um endereço IP público SKU padrão manualmente?

Sim, pode. Se você optar por fazer isso manualmente, precisará excluir o gateway antigo e, em seguida, criar um novo gateway em sua rede virtual. Quando você cria um novo gateway, seu gateway usará automaticamente um endereço IP público SKU padrão. 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 esta abordagem. Isso significa que você terá que garantir que o novo endereço IP seja atualizado em todas as suas ferramentas internas, conforme necessário.

A migração do gateway VPN vai afetar o tráfego ExpressRoute numa configuração coexistente?

No. Ao seguir a ordem de migração recomendada, migrar primeiro o gateway VPN não causa migração, nem perturba nem afeta o tráfego do ExpressRoute. A conectividade ExpressRoute mantém-se inalterada durante a migração do gateway VPN. Os clientes não devem esperar problemas de conectividade com o ExpressRoute ao migrar primeiro o gateway VPN.

Posso ativar a proteção DDoS durante a migração do gateway?

No. Enquanto o gateway estiver em migração (entre Executar e Confirmar), não faça quaisquer alterações ao IP público, gateway ou ligações. Ativar a proteção DDoS ou outras funcionalidades avançadas durante esta fase pode bloquear a migração ou impedir o retrocesso. Ative essas funcionalidades apenas depois de a migração estar totalmente concluída (após o Commit).

Posso modificar o meu IP, Gateway de VPN, subnet ou ligações durante a migração?

No. Enquanto o gateway VPN estiver a ser migrado (entre Execute e Commit), não deve efetuar quaisquer alterações nos seguintes elementos:

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

Fazer alterações durante esta fase pode colocar o gateway num estado não suportado ou bloqueado, 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 bloqueado?

Se o gateway entrar num estado de migração preso 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 eliminar e recriar o gateway.

SKUs de gateway Active-Active VpnGw1-5

Porque é que o meu Active-Active Gateway de VPN com Point-to-Site (P2S) requer um terceiro IP Público?

Para gateways de VPN Active-Active com P2S ativado, é necessário um terceiro IP público para dar suporte ao ponto final P2S, juntamente com os dois IPs utilizados para instâncias Active-Active.

A documentação indica que o terceiro IP Público deve ser não zonal. Isto ainda é obrigatório?

Yes.
Neste cenário, o terceiro IP Público deve ser configurado sem zonas (não zonais) para garantir compatibilidade com a configuração 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 ligado ao Gateway de VPN antes de iniciar a migração (Basic → Standard IP).

Isto garante:

  • A configuração do gateway está completa antes da migração
  • O processo de migração decorre sem problemas de validação ou atualização

Como é que crio o IP público não zonal obrigatório?

Em regiões onde os IPs com redundância entre zonas são o padrão, deve criar o terceiro IP Público com a CLI do Azure, o PowerShell ou a API REST versão 2020-08-01 ou posterior, que define um IP Público não zonal / sem zona, garantindo que não são especificadas zonas de disponibilidade.

Isto permite que o IP Público seja criado numa configuração não zonal, o que é necessário para este cenário.

Posso usar um IP Público redundante de zona em vez de um IP não zonal para o terceiro IP P2S?

No.

Todos os IPs públicos associados a um Gateway de VPN devem usar uma configuração consistente. Usar um IP Público redundante de zona para o terceiro IP pode resultar em falhas de implementação ou atualização.

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

No.

Este requisito aplica-se especificamente a:

  • Gateways VPN Ativo-Ativo
  • Com o Point‑to‑Site (P2S) ativado

Como se comporta a migração para um gateway VPN Ativo-Ativo usando um IP Público Básico? Isso causa uma falha total do gateway?

No. Durante a migração de um IP Público Básico para um IP Público Padrão, o gateway VPN é transicionado como unidade e restabelece a conectividade como parte do processo de migração. A migração não move tráfego de uma instância de gateway para outra, nem resulta numa falha total do gateway. Podem ocorrer pequenas interrupções de conectividade durante a migração, à medida que as ligações são restabelecidas, mas o gateway não fica completamente offline.

Durante a migração, apenas os túneis numa instância específica do gateway sofrem interrupções enquanto a outra instância permanece ativa?

No. Espera-se que os túneis VPN sejam restabelecidos como parte do processo de migração, mas não são migrados nem falham de acordo com cada instância. Os túneis não devem ter flutuações devido à migração de instâncias individuais do gateway, e a migração não está limitada a instâncias específicas dentro de um gateway Ativo-Ativo.

Como deve ser descrito o tempo de inatividade para a migração do gateway VPN Ativo-Ativo?

A migração é uma operação disruptiva e pode resultar em breves interrupções de conectividade enquanto a configuração do gateway VPN é atualizada e as ligações são restabelecidas. Estas interrupções têm tipicamente duração de vários minutos e, na maioria dos casos, completam-se em aproximadamente 10 minutos, embora os tempos exatos não sejam garantidos e possam variar consoante a configuração e as condições da rede. Os clientes devem planear a migração durante uma janela de manutenção e garantir que as aplicações são resilientes a interrupções curtas de conectividade.

Vejo que o endereço IP do BGP entre pares muda após a migração. Tenho de atualizar os endereços IP do peer BGP depois de migrar um gateway VPN ativo-ativo para IP padrão?

No. Embora o portal Azure exiba novos endereços IP BGP peer após a migração, as configurações BGP existentes on-premises continuam a funcionar sem alterações. O Azure redireciona automaticamente o tráfego dos endereços IP originais do par BGP para os endereços IP do par BGP, preservando a conectividade e as sessões BGP.

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

Preciso de rever alguma configuração de rede personalizada antes da migração?

Yes. Reveja todas as Tabelas de Rota (UDRs), Balanceadores de Carga, firewalls ou NVAs criadas pelos clientes que possam fazer referência a endereços IP privados da instância do Gateway de VPN (CAs do Gateway). E a propagação da rota BGP é alterada antes da migração. Se o seu ambiente usar peering VNet, certifique-se de que o Sync VNet Peering está ativado durante a migração.

Quando devo atualizar estas configurações?

Após a etapa de Execução, atualize quaisquer rotas, balanceadores de carga, regras de firewall ou configurações NVA criadas pelo cliente, que refiram aos IPs antigos da instância do gateway.

Gateway de VPN SKU Básico

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

Não, não pode criar um gateway VPN de SKU Básico com um endereço IP público de SKU Básico. Os novos gateways VPN SKU básicos requerem um endereço IP público padrão SKU.

Preciso migrar se tiver um gateway VPN SKU básico?

Gateways VPN de SKU Básico que atualmente estão a utilizar um endereço IP público de SKU Básico não utilizam o processo de migração para se moverem para um endereço IP público de SKU Padrão. A única ação que precisas de tomar é remover a referência IP pública do SKU básico do teu gateway.

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

Migração do backend

Quando é que a Microsoft irá realizar a migração backend do meu gateway VPN?

A partir de agosto de 2026, a Microsoft migra automaticamente os gateways VPN elegíveis que ainda não tenham sido migrados por autosserviço. Como esta operação é gerida pela Microsoft, não receberá uma notificação de migração por gateway antes da migração ocorrer. A Microsoft realiza a migração fora do horário comercial, com base no horário local regional do gateway, para ajudar a minimizar o impacto no cliente.

O endereço IP público do meu gateway VPN vai mudar durante a migração?

No. A migração atualiza o recurso IP público do SKU Básico para o SKU Padrão, mas o endereço IP público existente é mantido. Não precisas de tomar qualquer medida para a atualização pública do IP.

A migração vai causar interrupções ou perturbação do trânsito?

Yes. A migração provoca uma breve interrupção de conectividade de até 10 minutos enquanto o gateway transita para a nova infraestrutura de backend. No entanto, certas configurações de gateway, como seletores de tráfego personalizados, Active-Active P2S, P2S baseado em CloudApp, Remote RADIUS e outros casos extremos identificados, podem exigir ação do cliente e podem sofrer impacto na conectividade se não forem remediadas antecipadamente.

Preciso de tomar alguma ação antes da migração para o backend?

Yes. Conclua a migração de autosserviço (desencadeada pelo cliente) antes de começar a migração do back-end. Este processo ajuda-o a validar os seus padrões específicos de tráfego, aplicações e topologia de rede, que a Microsoft não pode testar totalmente por si. Se não efetuar a migração de autosserviço, a Microsoft poderá migrar automaticamente os gateways elegíveis durante a migração da infraestrutura de back-end. Esta migração não é reversível. A Microsoft também pode realizar testes de scream em alguns gateways. Gateways determinados como inativos podem ser eliminados como parte do processo de desativação. Além disso, reveja e corriga quaisquer configurações afetadas conhecidas, como seletores de tráfego personalizados, Active-Active P2S, P2S baseado em CloudApp e Remote RADIUS, antes da migração, para evitar potenciais 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 a 30 de junho de 2026. Esperava-se que completasses a migração até esta data. Se permanecer na plataforma antiga após 30 de junho de 2026, o SLA do serviço Gateway de VPN deixará de o abranger até que a migração esteja concluída. Os pedidos de extensão até 31 de julho de 2026 são automaticamente aprovados e não requerem revisão individual. A partir de agosto de 2026, a Microsoft planeia migrar os gateways VPN elegíveis que ainda não foram migrados. A Microsoft realiza migrações de backend regionalmente fora do horário comercial e estas podem resultar numa breve interrupção da conectividade, semelhante à experiência de migração iniciada pelo cliente.

Próximos passos

  • Last updated on